Update EIP-4844: de-sszify spec#6985
Merged
eth-bot merged 7 commits intoethereum:masterfrom May 16, 2023
Merged
Conversation
github-actions
bot
added
c-update
Collaborator
|
✅ All reviewers have approved. |
hwwhww
reviewed
May 4, 2023
dankrad
suggested changes
May 16, 2023
dankrad
previously approved these changes
May 16, 2023
Co-authored-by: dankrad <mail@dankradfeist.de>
Co-authored-by: dankrad <mail@dankradfeist.de>
Co-authored-by: dankrad <mail@dankradfeist.de>
Member
Author
|
@dankrad previously approved, but I didn't realize I needed to rebase. I will go ahead with merge since the rebase was rather straightforward. |
eth-bot
approved these changes
May 16, 2023
Collaborator
eth-bot
left a comment
eth-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
Merged
5 tasks
This was referenced May 17, 2023
holgerd77
reviewed
May 22, 2023
| and `access_list` follows [EIP-2930](./eip-2930.md). | ||
|
|
||
| The signature is verified and `tx.origin` is calculated as follows: | ||
| The `max_fee_per_data_gas` is `uint256` and the `blob_versioned_hashes` field represents a list hash outputs from `kzg_to_versioned_hash`. |
Contributor
There was a problem hiding this comment.
"represents a list hash outputs" something is wrong here. 🤔
holgerd77
reviewed
May 22, 2023
| This EIP introduces a transaction type that has a distinct mempool version (`BlobTransactionNetworkWrapper`) and execution-payload version (`SignedBlobTransaction`), | ||
| with only one-way convertibility between the two. The blobs are in the `BlobTransactionNetworkWrapper` and not in the `SignedBlobTransaction`; | ||
| This EIP introduces a transaction type that has a distinct mempool version and execution-payload version, | ||
| with only one-way convertibility between the two. The blobs are in the network representation and not in the consensus representation; |
Contributor
There was a problem hiding this comment.
Maybe I misread, but should this read "not in the execution implementation"? 🤔
1 task
8 tasks
20 tasks
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I'd like to propose removing SSZ entirely from the EL side of 4844.
The only real value in blob transactions being SSZ encoded (as specified) is that the CL is able to parse the transaction and easily access
blob_versioned_hashes. I don't have a great solution to this if they aren't SSZ encoded. Ultimately it seems that either i) one of the layers implements the other layer's serialization scheme or ii) the engine api is extended to resolve blob hashes given a blob tx (may not even be efficient enough).I think adding RLP into the CL requires much less decision making than supporting SSZ in the EL. It's already clear how to lay transactions out, calculate their sig hashes and standard hashes, etc. CLs simply need to search through the opaque blobs, find the blob txs, then RLP decode them.
If we do end up going forward with SSZ in 4844, it is almost a certainty that either i) we have to change something about it in the future (defeating the purpose a bit) or ii) we are unnecessarily constrained when we do decide make the full transition to SSZ.
The least risky option appears to be making 4844 transactions RLP. I would love if we were to spend time and figure out how to apply SSZ properly (à la EIP-6404), but it doesn't seem there is interest in that route at the moment. So given all that, I believe RLP is the best path forward.