Update EIP-4844: hash_tree_root based transaction hashes

This PR builds on top of prior work from:
- @lightclient at ethereum#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.

EIPS/eip-4844.md

@@ -8,7 +8,7 @@ status: Review
 type: Standards Track
 category: Core
 created: 2022-02-25
-requires: 1559, 2718, 2930, 4895
+requires: 155, 1559, 2718, 2930, 4895
 ---
 
 ## Abstract
@@ -161,12 +161,29 @@ The execution layer verifies the wrapper validity against the inner `Transaction
   random evaluation at two points derived from the commitment and blob data)
 
 
-The signature is verified and `tx.origin` is calculated as follows:
+To derive the originally signed transaction hash and the perpetual transaction hash, additional information that encodes the [EIP-155](./eip-155.md) chain ID and the [EIP-2718](./eip-2718.md) transaction type is linked with the transaction. This additional information ensures global uniqueness for those transaction hashes across chains. This derivation uses the consensus definitions for [`DomainType`](https://github.com/ethereum/consensus-specs/blob/67c2f9ee9eb562f7cc02b2ff90d92c56137944e1/specs/phase0/beacon-chain.md#custom-types), [`Domain`](https://github.com/ethereum/consensus-specs/blob/67c2f9ee9eb562f7cc02b2ff90d92c56137944e1/specs/phase0/beacon-chain.md#custom-types), and [`compute_signing_root`](https://github.com/ethereum/consensus-specs/blob/67c2f9ee9eb562f7cc02b2ff90d92c56137944e1/specs/phase0/beacon-chain.md#compute_signing_root).
 
 ```python
-def unsigned_tx_hash(tx: SignedBlobTransaction) -> Bytes32:
-    # The pre-image is prefixed with the transaction-type to avoid hash collisions with other tx hashers and types
-    return keccak256(BLOB_TX_TYPE + ssz.serialize(tx.message))
+class ExecutionForkData(Container):
+    version: Bytes4
+    chain_id: uint256
+
+DOMAIN_EXECUTION_TRANSACTION = DomainType('0x00800000')
+
+def compute_transaction_domain(tx_type: uint8, chain_id: uint256) -> Domain:
+    fork_data_root = hash_tree_root(ExecutionForkData(
+        version=[tx_type] + 3 * [uint8(0)],
+        chain_id=chain_id,
+    ))
+    return Domain(DOMAIN_EXECUTION_TRANSACTION + fork_data_root[:28])
+```
+
+The signature is verified and `tx.origin` is calculated as follows, using
+
+```python
+def unsigned_tx_hash(tx: SignedBlobTransaction) -> Root:
+    domain = compute_transaction_domain(BLOB_TX_TYPE, tx.message.chain_id)
+    return compute_signing_root(tx.message, domain)
 
 def get_origin(tx: SignedBlobTransaction) -> Address:
     sig = tx.signature
@@ -178,9 +195,12 @@ The hash of a signed blob transaction should be computed as:
 
 ```python
 def signed_tx_hash(tx: SignedBlobTransaction) -> Bytes32:
-    return keccak256(BLOB_TX_TYPE + ssz.serialize(tx))
+    domain = compute_transaction_domain(BLOB_TX_TYPE, tx.chain_id)
+    return compute_signing_root(tx, domain)
 ```
 
+When representing the transaction as part of the [execution block header's `txs-root`](https://github.com/ethereum/devp2p/blob/bd17dac4228c69b6379644355f373669f74952cd/caps/eth.md#block-encoding-and-validity) Merkle-Patricia Trie, `signed_tx_hash(tx)` is embedded instead of the transaction's raw network representation.
+
 ### Header extension
 
 The current header encoding is extended with a new 256-bit unsigned integer field `excess_data_gas`. This is the running