tip: 745
title: Introduce EIP-4844 and EIP-7516 instructions and precompile contracts
author: lei19942016@hotmail.com
status: Last Call
type: Standards Track
category: VM
created: 2025-03-28
As part of the Ethereum Cancun upgrade, instructions and precompile contracts in EIP-4844: Shard Blob Transactions and EIP-7516: BLOBBASEFEE instruction are required to be implemented to TRON.
Introduce the BLOBHASH (0x49) instruction, BLOBBASEFEE (0x4a) instruction and a point evaluation precompile(0x2000A).
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, and a point evaluation precompile that verifies a KZG proof.
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.
Add a precompile at 0x2000A that verifies a KZG proof which claims that a blob (represented by a commitment) evaluates to a given value at a given point.
The precompile costs 50000 and executes the following logic:
def point_evaluation_precompile(input: Bytes) -> Bytes:
"""
Verify p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof.
Also verify that the provided commitment matches the provided versioned_hash.
"""
# The data is encoded as follows: versioned_hash | z | y | commitment | proof | with z and y being padded 32 byte big endian values
assert len(input) == 192
versioned_hash = input[:32]
z = input[32:64]
y = input[64:96]
commitment = input[96:144]
proof = input[144:192]
# Verify commitment matches versioned_hash
assert kzg_to_versioned_hash(commitment) == versioned_hash
# Verify KZG proof with z and y in big endian format
assert verify_kzg_proof(commitment, z, y, proof)
# Return FIELD_ELEMENTS_PER_BLOB and BLS_MODULUS as padded 32 byte big endian values
return Bytes(U256(FIELD_ELEMENTS_PER_BLOB).to_be_bytes32() + U256(BLS_MODULUS).to_be_bytes32())The precompile MUST reject non-canonical field elements (i.e. provided field elements MUST be strictly less than BLS_MODULUS).
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 precompile has a energy cost of 50000.
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 following is a practical example:
versionedHash: 0x015a4cab4911426699ed34483de6640cf55a568afc5c5edffdcbd8bcd4452f68
z: 0x0000000000000000000000000000000000000000000000000000000000000065
y: 0x60f557194475973322b33dc989896381844508234bfa6fbeefe5fa165ae15a0a
commitment: 0xa70477b56251e8770969c83eaed665d3ab99b96b72270a41009f2752b5c06a06bd089ad48952c12b1dbf83dccd9d373f
proof: 0x879f9a41956deae578bc65e7133f164394b8677bc2e7b1356be61d47720ed2a3326bfddebc67cd37ee9e7537d7814afe
expected return value: 0x000000000000000000000000000000000000000000000000000000000000100073eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001
There are no known security implications with this TIP.
Copyright and related rights waived via CC0.