Package ethclient implements interface calls by directly calling the respective RPC API call. It requrired a trusted API endpoint because it does not verify the received results.
BlockByHash(ctx context.Context, blockHash common.Hash) (*types.Block, error)
eth_getBlockByHash(blockHash, fullTxs=true)
BlockByNumber(ctx context.Context, blockNumber *big.Int) (*types.Block, error)
This document gives a top level view of the blsync PR in order to help the review/merge process. It describes the most important mechanisms and data structures and how they are used in this PR (sometimes also how they are going to be used later).
The current PR implements an MVP feature called blsync that can light sync the beacon chain from a beacon node that supports the light_client REST API namespace (Lodestar or Nimbus) and drive an EL node through the engine API. Its components are sometimes more general purpose though as they are also intended to be part of the new full featured PoS capable Geth light mode. Note that a significant part of this PR (more specifically light.LightChain, merkle.MultiProof, sync.HeaderSync, sync.StateSync) are only used here in order to get the finalized block hash out of the beacon state. It is a possible option to strip down the PR even further by removing this featu
| eip | title | description | author | status | type | category | created |
|---|---|---|---|---|---|---|---|
<to be assigned> |
Beacon State API endpoint |
A proposal for a general purpose beacon state access endpoint in the `light_client` API |
Zsolt Felföldi (@zsfelfoldi) <zsfelfoldi@ethereum.org> |
Draft |
Standards Track |
Interface |
2022-11-04 |
Zsolt Felfoldi zsfelfoldi@ethereum.org
| Instructions for testing LES/5 (proof-of-stake light client) on the Kiln testnet | |
| - build the geth branch: | |
| git clone https://github.com/zsfelfoldi/go-ethereum.git -b les5 | |
| - build the latest master version of lodestar: | |
| git clone https://github.com/ChainSafe/lodestar.git | |
| yarn && yarn build | |
| - build instructions: | |
| https://github.com/ChainSafe/lodestar/ | |
| - pull the merge testnet configs repo: |
The uTP-over-DiscV5 document specifies that all uTP traffic is encapsulated into TALKREQ packets while TALKRESP is not used. The problem is that the current DiscV5 implementation kind of insists on doing TALKREQ / TALKRESP packet exchanges and expects a response to every request. See the existing interface here:
type TalkRequestHandler func(enode.ID, *net.UDPAddr, []byte) []byte
func (t *UDPv5) RegisterTalkHandler(protocol string, handler TalkRequestHandler) {
func (t *UDPv5) TalkRequest(n *enode.Node, protocol string, request []byte) ([]byte, error) {
| zsfelfoldi@zsfelfoldi-desktop:~/go/src/github.com/ethereum/hive$ ./hive --sim 'ethereum/rpc$' --sim.limit /LES --client go-ethereum --loglevel 5 --docker.output | |
| DBUG[02-14|15:02:22] docker daemon online version=20.10.11 | |
| INFO[02-14|15:02:22] building 1 clients... | |
| INFO[02-14|15:02:22] building image image=hive/clients/go-ethereum:latest dir=clients/go-ethereum nocache=false pull=false | |
| Step 1/14 : ARG branch=latest | |
| Step 2/14 : FROM ethereum/client-go:$branch | |
| ---> 429f106d4de2 | |
| Step 3/14 : RUN apk add --update bash curl jq | |
| ---> Using cache | |
| ---> 38f19e4fbf38 |
Author: Zsolt Felföldi (zsfelfoldi@ethereum.org)
Note: this is an informal write-up and the exact details of the data structure presented here might need further clarification. If there seems to be interest in this idea and no one finds any major holes in it then I want to write a proper EIP for this.
Here I attempt to solve two problems with our current bloom filter based log event search mechanism. One of them concerns both full and light clients: the bloom filter size is fixed and does not adapt to the increased number of log events per block due to increased gas limit. This leads to too many false positive matches, rendering the whole bloom filter mechanism almost ineffective. The other issue concerns light clients: even if we increase the bloom filter size, using the filters with a light client is only possible if the client syncs up the header chain. Geth light client did that until now but after the merge this practice becomes
Author: Zsolt Felfoldi (zsfelfoldi@ethereum.org)
This proposal defines a new GPO API function for new EIP-1559 compatible wallets:
feeHistory(blockCount, lastBlock) (firstBlock, []baseFee, []gasUsedRatio)
feeHistory(blockCount, lastBlock, []rewardPercentile) (firstBlock, [][]reward, []baseFee, []gasUsedRatio)
Author: Zsolt Felfoldi (zsfelfoldi@ethereum.org)
This proposal describes an EIP-1559 compatible priority fee suggestion scheme that can be considered a generalization of the current "gas price oracle" implemented in Geth. We define minReward for each block so that it is either the smallest effective miner reward paid in a given block or a low (user specified, cca 5-10%) percentile of tx miner rewards in ascending order, weighted by gas used. The latter option is slightly more complex to calculate but also more reliable because it can't be distorted by miner created transactions where the paid priority fee is not really meaningful.
Instead of suggesting a single priority fee value based on the minReward of a fixed number of recent blocks, this scheme has a positive integer parameter i which means the API can choose to display a series of values which might also be more informative to the user. Using a single value of i is also possible, a value of 3 or 4 yields a behavior similar to the current GPO.