# Ephemeral Calldata RSKIP281
**URL:** https://research.rsk.dev/t/ephemeral-calldata-rskip281/241
**Category:** RSKIP
**Created:** [October 6, 2021, 11:48pm UTC](https://research.rsk.dev/t/ephemeral-calldata-rskip281/241 "2021-10-06T23:48:37Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@shreemoy](https://research.rsk.dev/u/shreemoy)
#### Post date: [October 6, 2021, 11:48pm UTC](https://research.rsk.dev/t/ephemeral-calldata-rskip281/241/1 "2021-10-06T23:48:37Z")
Hi @SergioDemianLerner
Just some comments about the new [RSKIP281](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP281.md)
- 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?
---
### Author:  [@SergioDemianLerner](https://research.rsk.dev/u/SergioDemianLerner)
#### Post date: [October 7, 2021, 2:55am UTC](https://research.rsk.dev/t/ephemeral-calldata-rskip281/241/2 "2021-10-07T02:55:19Z")
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
---
### Author:  [@bguiz](https://research.rsk.dev/u/bguiz)
#### Post date: [October 30, 2021, 1:59am UTC](https://research.rsk.dev/t/ephemeral-calldata-rskip281/241/3 "2021-10-30T01:59:48Z")
Following on from the community call last night:
- 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.
---
### Author:  [@SergioDemianLerner](https://research.rsk.dev/u/SergioDemianLerner)
#### Post date: [March 16, 2022, 2:31pm UTC](https://research.rsk.dev/t/ephemeral-calldata-rskip281/241/4 "2022-03-16T14:31:29Z")
> [@bguiz](#):
>
> I think it might be clearer if `ecdHash` is renamed to `ecdCustomHash` or `ecdUserHash` , because that’s how it was described.
Noted.
A week ago Vitalik proposed [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) 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.
---
### Author:  [@bguiz](https://research.rsk.dev/u/bguiz)
#### Post date: [March 17, 2022, 3:33am UTC](https://research.rsk.dev/t/ephemeral-calldata-rskip281/241/5 "2022-03-17T03:33:11Z")
> [@SergioDemianLerner](#):
>
> Note that we identified this improvement back to 2016.
We’re so far ahead of the curve sometimes 😉