it would be good to repeat some of the core motivation from related RSKIPs (28, 214).
This will reveal my ignorance of how the EVM uses calldata. Would it be possible to partially remove some of the call data, while keeping the rest: i.e. encode 2 sets of call data (within the single RLP structure) so there is a datastring ecd_r (remove by default) and ecd_k (keep by default)?
Does the section on Blockchain synchronization need to be part of this RSKIP, or can it be separate?
Regarding your question (2): Would it be possible to partially remove some of the call data, while keeping the rest: i.e. encode 2 sets of call data (within the single RLP structure) so there is a datastring ecd_r (remove by default) and ecd_k (keep by default)?
The RSKIP does not remove the standard calldata, it just adds a new calldata field, so you can have non-ephemeral calldata together with ephemeral calldata.
The RSKIP does not allow to mix in the same transaction keep-by-default ephemeral calldata with remove-by-default ephemeral calldata, but I can’t find any good use for that. You can always send two transactions, each with a different type of ephemeral data.
Regarding (3) : Does the section on Blockchain synchronization need to be part of this RSKIP, or can it be separate?
It could, but then both RSKIPs would need to be activated together, because you can’t implement ephemeral calldata without some modification of the blockchain synchronization protocol.
However, a different synchronization protocol could be adopted (I analyzed another sync protocol before choosing the one in the RSKIP).
So the answer is yes, the sync protocol could be moved to another RSKIP, and that may be a better approach.
Perhaps consider adding more details on which fields are included and/ excluded in the computation of the 2 different hashes (in your slides you had a diagram for this, IIRC)
I think it might be clearer if ecdHash is renamed to ecdCustomHash or ecdUserHash, because that’s how it was described.
A week ago Vitalik proposed EIP-4844: Shard Blob Transactions which tries to solve the same problem in a similar way (although it also tries to be sharding-compatible).
Note that we identified this improvement back to 2016. That’s 5 years before rollups went into production.
