zsfelfoldi

---

eip: 7745 title: Light client and DHT friendly log index structure description: An efficient, light client and DHT friendly replacement for block header bloom filters author: Zsolt Felföldi (@zsfelfoldi) discussions-to: https://ethereum-magicians.org/t/eip-7745-two-dimensional-log-filter-data-structure/20580 status: Draft type: Standards Track category: Core created: 2024-07-17

zsfelfoldi

Mapping ethereum chain/state access interfaces to trusted and trustless API calls

ethclient (trusted)

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)

zsfelfoldi

Beacon light sync top level overview

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

zsfelfoldi

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) <[email protected]>	Draft	Standards Track	Interface	2022-11-04

zsfelfoldi

Beacon node light client API proposals

Zsolt Felfoldi [email protected]

The "complete beacon light client service dataset"

• is a lot smaller than a full CL node database but can do more
• can prove

zsfelfoldi

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:

zsfelfoldi

Notes on implementing uTP over the Geth DiscV5 implementation

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@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

zsfelfoldi

Proposal for a light client friendly log event search data structure

Author: Zsolt Felföldi ([email protected])

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

zsfelfoldi

Author: Zsolt Felfoldi ([email protected])

Call formats

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)