Implement EIP232 new transaction format

[NIC619]

What is wrong?

Discussion started in #326 which are about how to supply salt value to contract-creating transaction in Sharding where CREATE2 style contract creation is implemented. CREATE2 takes in a value salt and init code code, address of the new contract is derived from hashing these two values together: sha3(salt | code).

In the short term, we can simply add a salt field in transaction format, but this field is only useful in contract creation transactions. EIP232 provides a more elastic format which adopts the notion of a version(or format) number. With EIP232 we can assign different type of transaction with different version/format number which corresponds to different transaction format.

How can it be fixed

Implement EIP232 in Sharding.
@pipermerriam provides a rough sketch of the possible implementation in the thread(#326 (comment)):
Quote:

class EIP232Transaction(rlp.Serializable):
    fields = (
        ('version', ...),
        ('inner_data', sedes.binary),
    (
    transaction_formats = {
        1: TransactionFormatA,
        2: TransactionFormatB,
    }

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.txn_data = rlp.decode(self.inner_data, sedes=self.transaction_formats[self.version])

    def __getattr__(self, name):
        return getattr(self.txn_data, name)

We have an outer transaction class which contains a mapping of version numbers to inner transaction classes. Then, during initialization, we decode the outer data packet, and then lookup the appropriate inner transaction class and use it to decode the inner data packet. Then we put some convenience APIs on the outer class to allow direct property access to the inner transaction properties.

[hwwhww]

deactivate