Implement EIP-2718 on Tomochain

[imterryyy]

Motivation

As part of our ongoing efforts to enhance the functionality and flexibility of our blockchain platform, Ethereum team are proposing the implementation of Ethereum Improvement Proposal (EIP) 2718 - Typed Transaction Envelope. This EIP introduces a standardized format for transactions, allowing for the inclusion of additional transaction types beyond the current simple value transfers.

Benefits

1. Extensibility: EIP-2718 allows for the inclusion of various transaction types, enabling the blockchain to support a wide range of applications and use cases. This flexibility opens doors for innovation and allows developers to build complex decentralized applications more efficiently.
2. Interoperability: The standardized format provided by EIP-2718 ensures that different transaction types can be understood and processed by all nodes on the network, regardless of their implementation.
3. Forward Compatibility: By adopting EIP-2718 early on, we ensure compatibility with future improvements and developments in the Tomochain ecosystem. As new transaction types are proposed and adopted by the community, our blockchain will be able to seamlessly incorporate them without requiring extensive protocol upgrades

Reference

1. EIP-2718: Typed Transaction Envelope

[imterryyy]

following this commit ethereum/go-ethereum@bbfb1e4

[imterryyy]

Currently, TomoChain only supports the "Legacy Transaction" format, which is encoded using the RLP (Recursive Length Prefix) method. The encoding follows the pattern rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s]), where the resulting byte array always starts with a byte greater than or equal to 0xc0.

However, there is a proposed improvement known as EIP-2718 by the Ethereum Team. This proposal suggests the creation of a new transaction type, which would be encoded using the format TransactionType || TransactionPayload (|| is the byte/byte-array concatenation operator.).

To differentiate between legacy transactions and the new typed transactions, clients can examine the first byte of the encoded transaction. If the byte falls within the range [0, 0x7f], it indicates a new transaction type. On the other hand, if the byte falls within the range [0xc0, 0xfe], it represents a legacy transaction type. The value 0xff is reserved for future use as an extension sentinel value and is not currently used in RLP encoded transactions.