39638c81c5
The total difficulty is the sum of all block difficulties from genesis to a certain block. This value was used in PoW for deciding which chain is heavier, and thus which chain to select. Since PoS has a different fork selection algorithm, all blocks since the merge have a difficulty of 0, and all total difficulties are the same for the past 2 years. Whilst the TDs are mostly useless nowadays, there was never really a reason to mess around removing them since they are so tiny. This reasoning changes when we go down the path of pruned chain history. In order to reconstruct any TD, we **must** retrieve all the headers from chain head to genesis and then iterate all the difficulties to compute the TD. In a world where we completely prune past chain segments (bodies, receipts, headers), it is not possible to reconstruct the TD at all. In a world where we still keep chain headers and prune only the rest, reconstructing it possible as long as we process (or download) the chain forward from genesis, but trying to snap sync the head first and backfill later hits the same issue, the TD becomes impossible to calculate until genesis is backfilled. All in all, the TD is a messy out-of-state, out-of-consensus computed field that is overall useless nowadays, but code relying on it forces the client into certain modes of operation and prevents other modes or other optimizations. This PR completely nukes out the TD from the node. It doesn't compute it, it doesn't operate on it, it's as if it didn't even exist. Caveats: - Whenever we have APIs that return TD (devp2p handshake, tracer, etc.) we return a TD of 0. - For era files, we recompute the TD during export time (fairly quick) to retain the format content. - It is not possible to "verify" the merge point (i.e. with TD gone, TTD is useless). Since we're not verifying PoW any more, just blindly trust it, not verifying but blindly trusting the many year old merge point seems just the same trust model. - Our tests still need to be able to generate pre and post merge blocks, so they need a new way to split the merge without TTD. The PR introduces a settable ttdBlock field on the consensus object which is used by tests as the block where originally the TTD happened. This is not needed for live nodes, we never want to generate old blocks. - One merge transition consensus test was disabled. With a non-operational TD, testing how the client reacts to TTD is useless, it cannot react. Questions: - Should we also drop total terminal difficulty from the genesis json? It's a number we cannot react on any more, so maybe it would be cleaner to get rid of even more concepts. --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com> |
||
|---|---|---|
| .. | ||
| internal | ||
| README.md | ||
| crawl.go | ||
| discv4cmd.go | ||
| discv5cmd.go | ||
| dns_cloudflare.go | ||
| dns_route53.go | ||
| dns_route53_test.go | ||
| dnscmd.go | ||
| enrcmd.go | ||
| keycmd.go | ||
| main.go | ||
| nodeset.go | ||
| nodesetcmd.go | ||
| rlpxcmd.go | ||
| runtest.go | ||
README.md
The devp2p command
The devp2p command line tool is a utility for low-level peer-to-peer debugging and protocol development purposes. It can do many things.
ENR Decoding
Use devp2p enrdump <base64> to verify and display an Ethereum Node Record.
Node Key Management
The devp2p key ... command family deals with node key files.
Run devp2p key generate mynode.key to create a new node key in the mynode.key file.
Run devp2p key to-enode mynode.key -ip 127.0.0.1 -tcp 30303 to create an enode:// URL
corresponding to the given node key and address information.
Maintaining DNS Discovery Node Lists
The devp2p command can create and publish DNS discovery node lists.
Run devp2p dns sign <directory> to update the signature of a DNS discovery tree.
Run devp2p dns sync <enrtree-URL> to download a complete DNS discovery tree.
Run devp2p dns to-cloudflare <directory> to publish a tree to CloudFlare DNS.
Run devp2p dns to-route53 <directory> to publish a tree to Amazon Route53.
You can find more information about these commands in the DNS Discovery Setup Guide.
Node Set Utilities
There are several commands for working with JSON node set files. These files are generated by the discovery crawlers and DNS client commands. Node sets also used as the input of the DNS deployer commands.
Run devp2p nodeset info <nodes.json> to display statistics of a node set.
Run devp2p nodeset filter <nodes.json> <filter flags...> to write a new, filtered node
set to standard output. The following filters are supported:
-limit <N>limits the output set to N entries, taking the top N nodes by score-ip <CIDR>filters nodes by IP subnet-min-age <duration>filters nodes by 'first seen' time-eth-network <mainnet/sepolia/holesky>filters nodes by "eth" ENR entry-les-serverfilters nodes by LES server support-snapfilters nodes by snap protocol support
For example, given a node set in nodes.json, you could create a filtered set containing
up to 20 eth mainnet nodes which also support snap sync using this command:
devp2p nodeset filter nodes.json -eth-network mainnet -snap -limit 20
Discovery v4 Utilities
The devp2p discv4 ... command family deals with the Node Discovery v4
protocol.
Run devp2p discv4 ping <enode/ENR> to ping a node.
Run devp2p discv4 resolve <enode/ENR> to find the most recent node record of a node in
the DHT.
Run devp2p discv4 crawl <nodes.json path> to create or update a JSON node set.
Discovery v5 Utilities
The devp2p discv5 ... command family deals with the Node Discovery v5
protocol. This protocol is currently under active development.
Run devp2p discv5 ping <ENR> to ping a node.
Run devp2p discv5 resolve <ENR> to find the most recent node record of a node in
the discv5 DHT.
Run devp2p discv5 listen to run a Discovery v5 node.
Run devp2p discv5 crawl <nodes.json path> to create or update a JSON node set containing
discv5 nodes.
Discovery Test Suites
The devp2p command also contains interactive test suites for Discovery v4 and Discovery v5.
To run these tests against your implementation, you need to set up a networking environment where two separate UDP listening addresses are available on the same machine. The two listening addresses must also be routed such that they are able to reach the node you want to test.
For example, if you want to run the test on your local host, and the node under test is also on the local host, you need to assign two IP addresses (or a larger range) to your loopback interface. On macOS, this can be done by executing the following command:
sudo ifconfig lo0 add 127.0.0.2
You can now run either test suite as follows: Start the node under test first, ensuring
that it won't talk to the Internet (i.e. disable bootstrapping). An easy way to prevent
unintended connections to the global DHT is listening on 127.0.0.1.
Now get the ENR of your node and store it in the NODE environment variable.
Start the test by running devp2p discv5 test -listen1 127.0.0.1 -listen2 127.0.0.2 $NODE.
Eth Protocol Test Suite
The Eth Protocol test suite is a conformance test suite for the eth protocol.
To run the eth protocol test suite against your implementation, the node needs to be initialized
with our test chain. The chain files are located in ./cmd/devp2p/internal/ethtest/testdata.
-
initialize the geth node with the
genesis.jsonfile -
import blocks from
chain.rlp -
run the client using the resulting database. For geth, use a command like the one below:
geth
--datadir
--nodiscover
--nat=none
--networkid 3503995874084926
--verbosity 5
--authrpc.jwtsecret 0x7365637265747365637265747365637265747365637265747365637265747365
Note that the tests also require access to the engine API. The test suite can now be executed using the devp2p tool.
devp2p rlpx eth-test \
--chain internal/ethtest/testdata \
--node enode://.... \
--engineapi http://127.0.0.1:8551 \
--jwtsecret 0x7365637265747365637265747365637265747365637265747365637265747365
Repeat the above process (re-initialising the node) in order to run the Eth Protocol test suite again.