fjl
commented
3 years ago @MicahZoltu I have made some updates, please check again.
Some of your concerns are valid, but I hope we can find an agreement about the scope of these validation rules. I added the rules here for two reasons:
(1) While it would be nice to refer to another specification, there is no complete specification of the Ethereum consensus rules. It's all scattered across the Yellow Paper and various EIPs.
(2) Even if such a specification did exist, the context of validation in the network protocol is different from the consensus. I've attempted to point this out more clearly in the latest changes. Transactions need special care because they must be relayed and validated before they are included in a block. The consensus rules only care about tx validity in blocks. In some cases, the validation rules for relay are stricter than the consensus rules because transaction exchange is subject to spam.
The purpose of the eth spec is documenting what the clients really do. In a perfect world, we would go as far as documenting the precise rules of the transaction pool here, including the rules for tx replacement and ordering. These things are very important for network health, but the consensus protocol will never be concerned with them.
This is also why I included the rules about tx gas. While future tx types may try to avoid having a nonce or gas, we already saw during the early account abstraction discussions that transactions must be statically verifiable enough to make tx exchange safe against spam. So if such tx types are ever defined, we will need to come up with new rules to make them safe, and the new rules need to be documented in the network protocol spec.
This adds a lot of new text to cover the encoding and validity of consensus objects. We previously referred to the 'main Ethereum specification' for that, but no such specification exists in practice.
There is also a new entry in the changelog to cover the addition of EIP-2718 typed transactions in the wire protocol.
Fixes #160