Nice to see that the new transaction format replaces the RLP transaction encoding with SSZ and moves
chain_id to be a field allowing for using
boolean for `y_parity.
There’s potential for some optimisation here at the expensive of some clarity: EIP-2098: Compact Signature Representation
Was this discussed yet?
parity field seems to have a 1 byte overhead so this is neglible.
intrinsic_gas = 20000 # G_transaction, previously 21000
If the intent is to change
G_transaction from 21000 to 20000 that should be a separate EIP that includes rationale for the change just like every other gas cost change.
If the intent is to have this specific transaction type have a different intrinsic cost from other transactions then this EIP should include rationale on why these transactions have a lower base operational overhead than other types of transactions.
If the intent is to try to incentivize certain behaviors, we should not be hijacking our operational cost pricing mechanism to try to achieve that.
Great proposal! Quick question, @protolambda , why does the signature cover the blob-data, instead of only covering the commitment(s) to the blob-data? It seems that for Danksharding, validators will not be receiving all of the blobs (only the commitments), yet they’ll still have to verify the signatures.
I made this for myself, just so I can anticipate what this will do to the nodes running on my machines. Sorry for any mistakes. I’ll correct it if there are any. Please let me know.
Thought I’d share:
Can we add something like below from 2718 to the beginning of the specification section to define the
|| operator? It’s used in several places in the EIP and can be interpreted in a variety of ways, depending on which programming language(s) one happens to be familiar with.
|| is the byte/byte-array concatenation operator.