Felföldi Zsolt zsfelfoldi

Proposal for a light client friendly log event search data structure

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)

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 (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.

EIP-1559 transaction pool design improvement proposal

Author: Zsolt Felfoldi (zsfelfoldi@ethereum.org)

New difficulties introduced by EIP-1559

Transaction pools currently order transactions based on a single metric (gasPrice), fetching the highest elements when constructing a new block and discarding the lowest elements when the pool is full. With EIP-1559 transaction ordering becomes more difficult because the effective miner reward (MIN(tx.tip, tx.feeCap-headBlock.baseFee)) depends on the latest block's base fee. A new EIP-1559 compatible pool design suggested by this proposal and implemented in this pull request orders transactions primarily based on feeCap in the eviction queue while the current efferctive reward is used for block construction. This is a good first approach because inclusion chance correlates with feeCap on the low end. The only potential danger is that `feeCap

A pay-for-storage model for evolving tree hashed data structures

Author: Zsolt Felfoldi (zsfelfoldi@ethereum.org)

This proposal describes a relatively lightweight and easy to maintain structure that is directly applicable for the implementation of a "storage fee" scheme on the EVM state and is also flexible enough to accomodate future storage schemes. It allows renting each account and contract storage entry separately, solving the problem of funding contracts with many user entries like ERC-20 tokens. Its economic model lets users know the exact expiration time of their entries when paying for rent. It does not need removal transactions, allows lazy garbage collection but still avoids "tree rot" (scenarios where it's not instantly clear whether a transaction is executable or not). The economic model can also be considered separately from the proposed data structure. It might require some more formal study but I believe it has good stability/fairness properties.

Data structure

We differentiate betw

@fjl @holiman and anyone who might be interested (whenever you have free time, not urgent) : this is a WIP PR (absolutely untested and partly unfinished) where I implemented a fairly simple (400 LOC total + utils.WeightedRandomSelect, does not use the NodeStateMachine :) ) DDoS protector. The reason I spent time with it at this early stage is that I think the token market interface really needs to be designed with this aspect in mind. Polling rates and unhealthy competition (arms race) can be a problem with markets, especially in a decentralized and uncontrolled, somewhat chaotic environment. The reason I am showing it to you is because I think something like this could be a recommendation (maybe even an EIP) for our entire DHT and I am interested in your opinons from both a security and DHT centric perspective. So basically what it does is

keeps request queues by both IP address (string) and enode.ID
has a single processing loop that even does time.Sleeps between serving them so that the DHT logic

	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

	fefe@i7-6700 ~/go/src/github.com/ethereum/go-ethereum $ ./geth --datadir "/media/1TB/.ethereum" --cache 4096 --port 30304 --lightserv 50 console
	INFO [02-09\|11:37:19.499] Starting Geth on Ethereum mainnet...
	INFO [02-09\|11:37:19.500] Maximum peer count ETH=50 LES=100 total=150
	INFO [02-09\|11:37:19.500] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory"
	WARN [02-09\|11:37:19.507] The flag --lightserv is deprecated and will be removed in the future, please use --light.serve
	INFO [02-09\|11:37:19.507] Set global gas cap cap=25000000
	INFO [02-09\|11:37:19.507] Allocated trie memory caches clean=614.00MiB dirty=1024.00MiB
	INFO [02-09\|11:37:19.507] Allocated cache and file handles database=/media/1TB/.ethereum/geth/chaindata cache=2.00GiB handles=32768
	INFO [02-09\|11:37:21.913] Opened ancient database database=/media/1TB/.ethereum/geth/chaindata/ancient
	INFO [02-09\|11:37:21.922] Initiali

	// NewMerkleTree constructs a merkle tree with given entries.
	func NewMerkleTree(entries []Entry) MerkleTree {
	if len(entries) == 0 {
	return nil
	}
	// Assign an unique salt for each entry. The hash
	// of entry is calculated by keccak256(value, salt)
	// so we can preserve the privacy of given value.
	for _, entry := range entries {
	entry.salt = rand.Uint64()