Ephemeral Calldata RSKIP281

Hi @SergioDemianLerner
Just some comments about the new RSKIP281

  • 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?

Hi Shreemoy,

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.

regards