title | description | author | discussions-to | status | type | category | created |
---|---|---|---|---|---|---|---|
<New log filter data structure> |
<An efficient and light client friendly replacement for block header bloom filters> |
<Zsolt Felföldi (@zsfelfoldi)> |
<URL> |
Draft |
<Standards Track> |
<Core> |
<2024-06-20> |
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
- is a lot smaller than a full CL node database but can do more
- can prove
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)