Felföldi Zsolt 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

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

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

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) {

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

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)

Author: Zsolt Felfoldi ([email protected])

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.

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

	INFO [05-20\|10:03:41.074] Imported new chain segment blocks=1 txs=0 mgas=0.000 elapsed="562.109µs" mgasps=0.000 number=22737 hash=24fa29..2ec86d dirty=0.00B
	INFO [05-20\|10:04:11.021] Imported new chain segment blocks=1 txs=0 mgas=0.000 elapsed="583.387µs" mgasps=0.000 number=22738 hash=02c997..90467e dirty=0.00B
	panic: runtime error: invalid memory address or nil pointer dereference
	[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x540324]

	goroutine 49 [running]:
	math/big.(*Int).Cmp(0xc01075c220, 0x0, 0xffffffffffffffff)
	/usr/local/go/src/math/big/int.go:328 +0x44
	github.com/ethereum/go-ethereum/core.(*StateTransition).preCheck(0xc0121efc00, 0xc000234b40, 0xc000234b80)
	/home/fefe/go/src/github.com/ethereum/go-ethereum/core/state_transition.go:220 +0xdc