Add EIP-6493: SSZ Transaction Signature Scheme

[etan-status]

This PR builds on top of prior work from:

• @lightclient at 4844: use hash_tree_root for tx hash #6385

The signature malleability issue in the original PR is addressed by reusing the consensus compute_signing_root mechanism to link each hash with the transaction's underlying chain_id and tx_type.

Note that this makes the transaction hashes different from the plain hash_tree_root values. This means that if the transactions_root MPT is replaced with SSZ (EIP-6404), that the transaction_hash would need to be tracked separately, same as for legacy RLP-based transactions. This is mainly a cosmetic issue, not a practical one. In an SSZ tx tree, we could simply include both the HTR as well as the perpetual tx hash.

Cryptographic analysis may be necessary to determine the amount by which the hash collision probability is increased, if we use different hashing algorithms for transactions. On the other hand, using different algo for SSZ transactions reduces the impact of a custom network defining 0x05 as a RLP transaction that might serialize same as the blob SSZ transaction.

[eth-bot]

All reviewers have approved. Auto merging...

[etan-status]

Overall, these items need to be mixed into any SHA256 based signature:

1. The fact that this signature is for a transaction
2. Schema version describing how the tx was serialized
3. Spec namespace (to distinguish from Ethereum based L2 / Sidechains)
   All these items must be mixed in using static information based on the node configuration, not based on the dynamic network data.

Currently, this PR uses an approach as close as possible to the consensus specs:

1. DOMAIN_EXECUTION_TRANSACTION (in consensus: DomainType)
2. tx_type (in consensus: Version)
3. chain_id (in consensus: genesis_validators_root)

It doesn't necessarily have to be these constants, and it doesn't necessarily have to be the same schema from consensus. While both these tx signatures and the consensus signatures are SSZ based, they are not signed using the same key. For example, we could also just run uuidgen for each new TX type, instead of deriving a Domain from (1), (2), and (3).

For the perpetual TX hash, it could be relaxed, but the same information needs to be mixed into the hash if the goal is to create globally unique TX hashes (across chains).

[etan-status]

There is also https://eips.ethereum.org/EIPS/eip-2124, maybe the "genesis hash" would work to link the signature to the underlying spec document defining the tx type, as the consensus genesis_validators_root equivalent.

[etan-status]

For the signed_tx_hash, as it already includes the signature (which already signs over compute_transaction_domain), I think it may be possible to just use plain hash_tree_root. TBD.

[github-actions]

The commit 1e9e198 (as a parent of 0f13409) contains errors.
Please inspect the Run Summary for details.

[etan-status]

@lightclient

I moved the scheme for SSZ transaction signatures to a separate EIP (6493).

Note that this representation is for the way how signatures are signed, identified, and represented before inclusion in a block. For post-block-inclusion, there is EIP-6404.

The new signature scheme proposed here is close to what the "SSZ Union" approach in EIP-6404's test section is referring to, so it doesn't conflict with the approach based on "SSZ Union". For "SSZ Normalized" approach, the transaction's mempool encoding is not linked to the post-block-inclusion encoding, so there is no concern either.

[etan-status]

Also, @vbuterin , this is as close as I could get it to your post here: https://notes.ethereum.org/@vbuterin/transaction_ssz_refactoring
while fixing the malleability concerns as close as possible to how this was already solved in consensus.

Means, 1 more SHA256 needed to get from message.hash_tree_root() to sig_hash compared to your blog post there.

[etan-status]

Let's move discussion to here:
https://ethereum-magicians.org/t/eip-6493-ssz-transaction-signature-scheme/13050

[g11tech]

Suggested change

	sig_hash = compute_example_sig_hash(message)
	sig_root = compute_example_sig_root(message)

would this be clearer to convey that this goes into signature calc

[Pandapip1]

LGTM now (for a draft).