The goal of this thread is to come to a rough consensus on the JSONRPC changes required to support EIP-1559 type 0x2 transactions. I’ve placed it here in Primordial Soup vs in the EIP section since as @matt has pointed out over on Discord the JSONRPC spec is moving out to GitHub - ethereum/eth1.0-specs: Specifications for the Ethereum 1.0. Tracking network upgrades..
Anyways, before we get to deep into naming things (the hardest part of Computer Science ) I think we need to agree on what JSONRPC changes are needed for type 0x2 transactions.
To recap, there are a couple places where transaction objects are serialized as JSONRPC results:
- In response to the
- In response to the various block-returning RPCs like
eth_getBlockByNumberwhere the second argument to return full tx bodies is
- As part of the
At least in geth, all of these locations use the same tx marshalling code, I suspect most clients are probably similar (though I’m not sure if txpool_content is supported in all clients).
For the first two cases, I think it’s generally a good thing that a JSONRPC consumer is able to “recreate” the transaction hash from the returned JSONRPC result. As such, I think all the new consensus-level fields in EIP-1559 should be available in the JSONRPC.
To recap, the consensus fields in 1559 txs are:
The twelve fields in the RLP-encoded tx body
chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, access_list, signatureYParity, signatureR, signatureS
Clients have already standardized on including
accessListfor EIP-2718/-2930 txs in Berlin, so I think including these fields for 1559 txs is pretty non-controversial. Likewise clients have continued to return the
That leaves the following new consensus-level fields:
And importantly, the following existing fields no longer have obvious corresponding consenus-level 1-to1s:
Digging into the details of EIP-1559, there are a couple new “intermediate” levels which, while not required for consensus per se, could be considered useful to JSONRPC tx consumers taken from the implementation pseudo-code.
# priority fee is capped because the base fee is filled first priority_fee_per_gas = min(transaction.max_priority_fee_per_gas, transaction.max_fee_per_gas - block.base_fee_per_gas) # signer pays both the priority fee and the base fee effective_gas_price = priority_fee_per_gas + block.base_fee_per_gas
The intermediate values are
So, to summarize, there are 5 potentially new fields to include, and 1 field that is no longer relevant.
I’ll add my proposed changes in a reply to this initial message, to try to keep the top-level post in this thread as “objective” as possible.