The discussion on transaction calldata gas cost reduction—EIP-2028—yields numerous data points that support extremely aggressive reduction in costs of posting data on-chain, in order to curb state growth. This EIP introduces a separate field in transactions for data that is used exclusively for this purpose (i.e., not readable in the EVM).
Thanks @adlerjohn for building on top of 2028.
To be honest, I don’t see the point in having an extra field. As explained in the analysis, going through the EVM costs less than 0.3 gas per word. I don’t see the point of adding an extra field as it would create a formatting and development overhead without strong benefits.
This analysis, I’m presuming?
You’d have to account for the costs of Merkeizing the data (some schemes require this, rather than simple hashing), which would end up quite a bit higher. You’d also have to account for the cost of calldata itself, which is going to be 16 gas per byte. So the costs of performing this operation on-chain are actually quite high.
If you’re using fraud proofs, you can’t simply re-post a transaction and check the calldata, as the transaction’s calldata and the contract call’s calldata may be completely different:
https://twitter.com/nicksdjohnson/status/1155672897756774400
Additionally, the separate field is particularly useful for multi-threaded data availability, which is going to be the subject of a sister EIP.
How would it be different? Also, is not collecting the transmission data easy to extract from the sync?
If you want to push fraud proof, the first person to post the data needs to show the link between the statement and the data. Therefore, needs to be part of the EVM.
Did you read the linked Twitter thread? It actually answers this exact question.
Not really, at least not without breaking backwards compatibility.
https://twitter.com/nicksdjohnson/status/1155685078774820865
Yes, you would need to save something in state, in this case some unique identifier for the transaction. Unfortunately, I just realized there is no opcode for such an identifier (though one was proposed). It would be fairly trivial to implement as a dependency to this EIP, or this EIP could be wrapped into the sister one I mentioned above. I personally prefer the former, what do you think?
The linked ethresearch post describes how this would be done in a backwards-compatible manner:
Clients can then go through transactions in a block (or even in their mempool!) and compute the reduction, inlining the result into the appropriate transaction’s
calldata.
My bad! I did not see it was a twitter thread. Went right away on the multithread part. Getting back to you 
Haha it’s all good. I was actually confused as heck at first as well, when @Arachnid brought it up.
The essence is here:
with the note that “data only available to an archive node” isn’t easy to re-post on-chain in a provably attributable manner.
So, I’m going to reply superficially. I don’t see relying on archive node to be a no go as any full node can recreate an archive node. Data Availability for layer 2 is a worst case scenario mechanism. Using a simple calldata with a merklelizer precompile is probably the easiest path.
In any case, this is very superficial answer as I did not have the time to look at all the links you posted. Let me take some time to dive in and understand it better
I’m not sure I understand why this is a counterargument.
It seems like it would be quite easy to include fraud proofs in tx data, just send a tx to a noop contract (for exmple with code 0x00). To get your fraud proof, simply get the tx.data. What am I not getting here?
On another note, even if your tx would run out of gas, your postdata would still be available and serve its purpose. It doesn’t seem quite right from a design perspective to retain the same utility regardless of how much gas would be used.
The linked explanation is for sending from a contract, not sending to a contract. There’s no easy way to link calldata to a transaction’s data field, as the calldata may come from a contract (modifying data).
I agree. As written, that seems to be what happens. The EIP should be re-written to use the same semantics as calldata (which I’m assuming is: if the account doesn’t have enough gas to pay for calldata, then the transaction is invalid, rather than valid but reverting). Good catch.
The linked explanation is for sending from a contract, not sending to a contract. There’s no easy way to link calldata to a transaction’s
datafield, as the calldata may come from a contract (modifyingdata).
Exactly, this is why the linked explanation seems irrelevant to the topic at hand. Your proposal wouldn’t allow contracts to submit tx postdata either (because only EOA can make transactions).
There doesn’t seem to provide any substantial benefit over just using the tx.data field for your purposes
I agree! I split up the whole proposal into what will become a series of EIPs. This first one on its own is in fact basically pointless. See twitter thread 