tip: 745
title: Introduce EIP-4844 and EIP-7516 instructions
author: lei19942016@hotmail.com
status: Final
type: Standards Track
category: VM
created: 2025-03-28
As part of the Ethereum Cancun upgrade, instructions in EIP-4844: Shard Blob Transactions and EIP-7516: BLOBBASEFEE instruction are required to be implemented to TRON.
Introduce BLOBHASH (0x49) and BLOBBASEFEE (0x4a) instructions.
It's important to note that this TIP only implements these instructions and does not include the actual blob transactions or the point evaluation precompiled contract(which will need a different address than 0x0a as it's used by ValidateMultiSign).
The Ethereum Cancun upgrade includes EIP-4844: Shard Blob Transactions and EIP-7516: BLOBBASEFEE Instruction.
The EIP-4844 introduces a new instruction BLOBHASH to get versioned hashes in blob transactions.
The EIP-7516 introduces a new instruction BLOBBASEFEE that returns the value of the blob base-fee of the current block it is executing in.
So to accommodate the changes in EVM due to the Cancun upgrade, we introduced this TIP.
Original motivation from EIP-4844:
Rollups are in the short and medium term, and possibly in the long term, the only trustless scaling solution for Ethereum. Transaction fees on L1 have been very high for months and there is greater urgency in doing anything required to help facilitate an ecosystem-wide move to rollups. Rollups are significantly reducing fees for many Ethereum users: Optimism and Arbitrum frequently provide fees that are ~3-8x lower than the Ethereum base layer itself, and ZK rollups, which have better data compression and can avoid including signatures, have fees ~40-100x lower than the base layer.
However, even these fees are too expensive for many users. The long-term solution to the long-term inadequacy of rollups by themselves has always been data sharding, which would add ~16 MB per block of dedicated data space to the chain that rollups could use. However, data sharding will still take a considerable amount of time to finish implementing and deploying.
This EIP provides a stop-gap solution until that point by implementing the transaction format that would be used in sharding, but not actually sharding those transactions. Instead, the data from this transaction format is simply part of the beacon chain and is fully downloaded by all consensus nodes (but can be deleted after only a relatively short delay). Compared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.375 MB per block and a limit of ~0.75 MB.
Original motivation from EIP-7516:
The intended use case would be for contracts to get the value of the blob base-fee. This feature enables blob-data users to programmatically account for the blob gas price, eg:
- Allow rollup contracts to trustlessly account for blob data usage costs.
- Blob gas futures can be implemented based on it which allows for blob users to smooth out data blob costs.
Because of the differences in fee models and transaction demands, we have not introduces the blob transaction and there will be some variations in the implementation of instruction functionality compared to EVM.
Add an instruction BLOBHASH (with opcode 0x49) which reads index from the top of the stack and places a single item with the value 0 onto the stack. The opcode has a energy cost of 3.
| Op | Input | Output | Cost |
|---|---|---|---|
| 0x49 | 1 | 1 | 3 |
Add a BLOBBASEFEE instruction with opcode 0x4a, with energy cost 2.
| Op | Input | Output | Cost |
|---|---|---|---|
| 0x4a | 0 | 1 | 2 |
BLOBBASEFEE returns a single value 0.
The opcode has a energy cost of 3.
The value of the blob base-fee is needed to process data-blob transactions. That means its value is already available before running the EVM code.
The instruction does not add extra complexity and additional read/write operations, hence the choice of 2 energy cost. This is also identical to TIP-318 (BASEFEE opcode)'s cost as it just makes available data that is in the header.
There are no known backward compatibility issues with this TIP.
The two instructions introduced in this TIP should always return 0 value.
This implementation does not support blob transactions, nor does it include the point evaluation precompiled contract. These features will be considered for implementation in future versions. The point evaluation precompiled contract will be addressed with an alternative address to avoid conflict with ValidateMultiSign at 0x0a
There are no known security implications with this TIP.
Copyright and related rights waived via CC0.