Dip 2242

dip: 2242 title: Transaction Postdata author: John Adler (@adlerjohn) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/dip-2242-transaction-postdata/3557 status: Stagnant type: Standards Track category: Core created: 2019-08-16 Created for Digitalia: 2025-01-07

Simple Summary¶

An additional, optional transaction field is added for "postdata," data that is posted on-chain but that cannot be read from the DVM.

Abstract¶

A paradigm shift in how blockchains are used has been seen recently in Eth 2.0, with the rise of Execution Environments (EEs), and stateless clients. This shift involves blockchains serving as a secure data availability and arbitration layer, i.e., they provide a globally-accepted source of available data, and process fraud/validity and data availability proofs. This same paradigm can be applied on Eth 1.x, replacing EEs with trust-minimized side chains.

Motivation¶

While DIP-2028 provides a reduction in gas cost of calldata, and is a step in the right direction of encouraging use of history rather than state, the DVM does not actually need to see all data that is posted on-chain. Following the principle of "don't pay for what you don't use," a distinct way of posting data on-chain, but without actually being usable within the DVM, is needed.

For trust-minimized side chains with fraud proofs, we simply need to ensure that the side chain block proposer has attested that some data is available. Authentication can be performed as part of a fraud proof should that data end up invalid. Note that trust-minimized side chains with validity proofs can't make use of the changes proposed in this DIP, as they required immediate authentication of the posted data. This will be the topic of a future DIP.

Specification¶

We propose a consensus modification, beginning at FORK_BLKNUM:

An additional optional field, postdata, is added to transactions. Serialized transactions now have the format:

"from": bytes20,
"to": bytes20,
"startGas": uint256,
"gasPrice": uint256,
"value": uint256,
"data": bytes,
"nonce": uint256,
["postdata": bytes],

with witnesses signing over the RLP encoding of the above. postdata is data that is posted on-chain, for later historical retrieval by layer-2 systems.

postdata is an RLP-encoded twople (version: uint64, data: bytes). 1. version is 0. 1. data is an RLP-encoded list of binary data. This DIP does not interpret the data in any way, simply considering it as a binary blob, though future DIPs may introduce different interpretation schemes for different values of version.

The gas cost of the posted data is 1 gas per byte. This cost is deducted from the startGas; if the remaining gas is non-positive the transaction immediately reverts with an out of gas exception.

Rationale¶

The changes proposed are as minimal and non-disruptive to the existing DVM and transaction format as possible while also supporting possible future extensions through a version code.

Backwards Compatibility¶

The new transaction format is backwards compatible, as the new postdata field is optionally appended to existing transactions.

The proposed changes are not forwards-compatible, and will require a hard fork.

Test Cases¶

TODO

Implementation¶

TODO

Copyright¶

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.