norswap / nanoeth Goto Github PK

There are a few things that should be added to transaction tests, for completeness' sake:

• testing chain IDs of 0 and very high chain IDs
• testing EIP-2930 transactions (access lists)
• testing EIP-1559 transaction (base fee + miner tip separation)

"Transaction tests" are tests that focus on validating the format of transactions (i.e. they are not run against any state).

The last two items above are at least partially tested in the block tests (whose purpose is to validate blocks and test transitions), but it would be cleaner to have separate transaction-level tests.

You probably want to add entries to OwnTransactionData

This could also be an upstream contribution to https://github.com/ethereum/tests (note that you will need to generate the transactions by first making a "filler file" and using an existing client (probably geth?) to generate the actual test file).

The methods in DebugUtils might be useful.

As always, feel free to contact me for more info.

Currently, we only test that we are able to prove valid Merkle proofs. For completeness we should also generate invalid Merkle proofs, and test that we fail to prove them.

Proof verification logic:

Existing Merkle proof tests:

Be sure to read the README on Merkle trees.

Most of the tests run for nanoeth are against data from the shared tests of the ethereum/tests repo.

We are currently compatible with release 9.0.5, but release 10 came out, and it significantly regenerated all the tests. We need to test to see if we're still compatible and test formats did not change too much.

Significantly (and not documented on the release page), fork names in transactions tests have changed: ethereum/tests#906

(For essentially context on Merkle/Patricia tree in nanoeth, read here.)

Currently, the Merkle tree implementation assumes, when performing insertion, that Merkle trees are "complete", i.e. that we have all the nodes. So whenever we try to insertion a key-value pair in a node, it will try to "merge" this with the child node, which we might not have. (This discussion applies to store-backed trees — there is no such thing as a partial linked tree.)

Mostly, this is fine, but we would like the ability to "fill in" a partial Merkle tree, with a set of key-value pairs (filling a tree with nodes we got from the network is very easy: we just add them to the store). This is required for snap sync which sends a range of key-value pairs, along with two Merkle branch: one for the first key and one for the last key.

Concretely speaking, this means this needs to be integrated with the (unimplemented) batch-insertion function described in #6

We need to handle the lack of a node referenced by its cap value, batch-insert the entries as though that node did not exist, then verify that the cap value for the subtree match that of the original cap value.

Blocked by: #6

Javadoc supports adding package-level documentation, by adding it in a package-info.java file in the package.
See this link to see what that looks like.

Currently, there is a lot of useful documentation in README.md files in most packages, however this information is not being carried over to the Javadoc, creating an unfortunate fragmentation of the documentation.

It would be neat if someone could come up with a script that would automatically render the Markdown to HTML, then take that HTML and wrap it in a package-info.java file.

Bonus points if this can be done entirely from within the Gradle build script.

As a first easy step, it would be nice to:

• add links to README files in manually create package-info.java files

As explained here, while running transactions we ideally write state change to a cache (a hashmap), then we batch-insert all transactions into the tree. This batch insertion logic needs to be written.

1. Sort entries by key lexical ordering.
2. Implement a recursive tree-walk (a method on PatriciaNode, implemented on its subclasses) which takes a list of entries (and potentially an index in the list?) and batch inserts entries, using the assumption that the list is sorted.

EIP-1559 introduces the separation between base fee and miner tip. The transaction format already accounts for this separation, but we currently do not validate the base fee value in the block validation logic:

EIP-1559 has strict rules on how the base fee must change, in relation to the gas limit. It might also be necessary to actually. The block header will probably need to change to include the base fee.

We can test things by running the London tests from ethereum/tests