--- tags: london --- # London JSON RPC Considerations ## 1. `eth_call` Question by @holiman in [discord](https://discord.com/channels/595666850260713488/745077610685661265/850292928357072926): > When executing an `eth_Call` on 1559 rules, what do other clients use for `baseFee`? There are two parts to this: one being what the `BASEFEE` opcode. the other is that it affects the `gasPrice`. So previsouly, geth used a 0 gasPrice for evaluating a call, and the address 0x000... as the sender. But since price was 0, it doesn't matter if the balance is zero. If we use a non-zero value for gasprice, we somehow need the 'sender' account to have a balance. **Option 1.1**: Set all fields to 0, unless specified by the user. For example: * A `from,to,value,data,nonce` transaction sent to `eth_call` would only do nonce validation for the given from and set `BASEFEE` opcode and `GASPRICE` opcode to 0? * If the transaction includes `gas, maxFeePerGas, maxPriorityFeePerGas`, then set the `BASEFEE` and `GASPRICE` * **Option 1.1.1:** Set `BASEFEE`and `GASPRICE` to **???** (most recent block seen? "pending" block?) ## 2. `effectiveGasPrice` in `eth_getTransactionReceipt` Some projects would like to have `effectiveGasPrice` in `eth_getTransactionReceipt` ([example discord conversation](https://discord.com/channels/595666850260713488/804019759934078987/848916600131551283)). A PR is now open to add it: https://github.com/ethereum/eth1.0-specs/pull/206 There doesn't seem to be any pushback on it. A proposed alternative was to include `effectiveGasPrice` in the transaction object itself and return it in `eth_getTransactionBy*` APIs, but because most extra information today is in receipts, that idea was discarded. **Option 2.1**: Add `effectiveGasPrice` to `eth_getTransactionReceipt` ([Spec PR](https://github.com/ethereum/eth1.0-specs/pull/206 )) **Option 2.2**: Add `effectiveGasPrice` to `eth_getTransactionBy*` **Option 2.3**: Something else? ## 3. `eth_maxPriorityFeePerGas` vs. `eth_feeHistory` There has been a lot of back and forth about different possibilities for the gas price oracle and for fee estimation. For Geth, the current post-London GPO implementation is as follows ([link](https://github.com/ethereum/pm/issues/328#issuecomment-853234014)): > * eth_gasPrice before London uses the current algorithm (deliberately won't say) > * eth_gasPrice after London will return the exact same number based on the total fees paid (tip + base) Geth also currently implements `eth_maxPriorityFeePerGas` which, after London, returns `eth_gasPrice - baseFee`. On the Gas API call, it was mentioned that we should not provide a single number for wallets to use as this could distort the 1559 mechanism. Instead, clients should provide data about the gas usage and fees paid in the previous blocks and let wallets estimate the `maxPriorityFeePerGas` based on that data. A [Wishlist](https://hackmd.io/@timbeiko/1559-api-wishlist) of data was put together, and, based on this, a [`feeHistory` API](https://gist.github.com/zsfelfoldi/473e29106d38525de6b4413e2ebcddf1) has been proposed. We need to decide if we go with `maxPriorityFeePerGas` or `feeHistory`. **Option 3.1**: `maxPriorityFeePerGas` **Option 3.2**: `feeHistory` **Option 3.3**: Something else?
Last changed by  
 
Tim Beiko
1964

Read more

Ethereum Forschungsingenieurtagung

The Ethereum Foundation is organizing an L1 research and engineering workshop in Berlin at web3.hub on June 9-13, 2025. Expect a mix between past interop events and R&D workshops! Workshop Structure & Goals Implementation Tracks Two parallel client engineering tracks will run for the entire week: Fusaka Interop & Performance Engineering, with the following goals: Run an all-client Fusaka devnet that steadily handles 12 blobs per block being submitted with the same architecture as mainnet (external builders, realistic L2 transaction payloads, etc.).Stretch Goal: Run a PeerDAS devnet with 24, 36 & 48 blobs per block being submitted without crashing. Run all clients in high gas settings to benchmark their opcode/precompile performance, get state growth benchmarks and analyze CL security implications.

6/7/2025
Pectra Interop Milestones

Useful links: Nyota Interop Milestones Verkle Interop Milestones PeerDAS Interop Milestones Nyota Agenda Interop Milestone Tracker :::info All milestones in this document are based on the pectra-devnet-0 specs.

5/22/2024
Nyota Interop Milestones ✨

[toc] Context The purpose of Nyota is to work together on Pectra, Verkle & PeerDAS ✨ By bringing together the various client, testing and research teams involved in these efforts, we can accelerate progress on finding+fixing cross-client issues, finalizing specs, and getting these upgrades shipped. As such, the three high-level goals for Nyota are: Pectra: all-client-pairs devnet running smoothly

5/21/2024
Besu Client Incentive Program - August 2023 Changes

Important note: this program superceeds any previous version of the Besu Client Incentive Program, including the one publicly shared on the Hyperledger Besu Wiki. [toc] Context The Ethereum Foundation's Client Incentive Program aims to incentivize client teams to build performant software for use on the Ethereum mainnet. Generally, client implementation are maintained by a single organization, and CIP grants have been offered to the organizations who maintain these clients. Due to its different maintainership structure, Hyperledger Besu's program was designed to accomodate a more diverse set of contributors. A version of the Hyperledger Besu CIP refleting this is available here.

10/14/2023
Read more from Tim Beiko
Published on HackMD