The precompile pointevaluation internally depends on another precompile sha256. This looks like design mistake: the hash function cannot be changed by users. None of the rationale or comments here explain this decision.
Congrats! As this is going to final soon, Congrats on authors and developers who work days and nights to carry out EIP-4844, hurah!!!
I know the implementation is done mostly, comments here are mostly about editorial clarification to ensure a smooth finalization.
- for a hash specification, such as
keccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes]))
can I suggest we specify the length of data? I know itās probably implied in the execution-spec, but sometimes when itās implied, we donāt know for sure, resulting in confusions that need to be resolved, such as this attempt EIP-2294: Explicit bound to Chain ID size
- This āMUST NOTā specification seems unenforcable from what it reads today.
Nodes MUST NOT automatically broadcast blob transactions to
their peers. Instead, those transactions are only announced using NewPooledTransactionHashes messages, and can then be
manually requested via GetPooledTransactions.
Maybe a better way to say it is that
Nodes MUST ONLY rely on NewPooledTransactionHashes
messages for announcement, and Nodes MUST provide a pull
interface for query named `GetPooledTransactions` etc.
- A rationale discussion of
POINT_EVALUATION_PRECOMPILE_GASto be specified as50000was not included in the Rationale section. I have no doubt deep thoughts has been put in to finding the right amount. But it would be good if authors could include that analysis in this proposal.
I would like to see the nomenclature around the āgas priceā/ābase feeā changed to be consistent with type 2 transactions and London blocks. I have created a PR that just renames āgas priceā to ābase feeā throughout the document. I donāt believe this has any actual impact on the specification itself or consensus, but it is useful for communication within the community to use consistent naming for similar concepts, and as we start working on standardizing the 4844 JSON-RPC methods it may become necessary to standardize on a name.
2 Likes
This EIP does not make it clear to users or node implementations how users would send blob transactions. Is there going to be a new eth_sendBlobTransaction RPC call or will nodes accept the encoded form at eth_sendTransaction as given in the Networking section, which, if I am not mistaken, does not even include the EIP-2718 number for blobs (3)?
edit: The networking section is not very clear, imo it should also mention that the TransactionType is BLOB_TX_TYPE again. Yes, you send it through eth_sendTransaction but with the transaction type (0x03) prepended to that rlp array it says in that section.
Amazing to see the progress on this EIP. I have a question regarding the behaviour of a node after MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS if it hasnāt been able to download the blob before, or alternatively a node that comes online after MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS has passed. Will such a node continue to try to download the blob and, if it fails, will it consider the block to be valid? At what point will nodes assume that old blobs were/are available even if they never downloaded them?
The relevant section of the consensus spec seems to be in fork-choice.md:
The block MUST NOT be considered valid until all valid Blobs have been downloaded. Blocks that have been previously validated as available SHOULD be considered available even if the associated Blobs have subsequently been pruned.
Although it doesnāt say what a node would do after MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, am I correct in assuming that a node would attempt to confirm availability even after MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS?