Deduplication of `Message.gas_price` and `Message.origin`

What is wrong?

The Message.gas_price and Message.origin are copied for every level of computation during VM execution, despite them remaining constant for the entire context of the VM execution.

It would be nice to remove this duplication in favor of having these values stored in one location.

Also see: sighash from https://github.com/ethereum/py-evm/pull/259/files

How can it be fixed

Implement a TransactionContext object, similar to the ExecutionContext object introduced in #273

This would be an object that we treat as immutable which houses information like gas_price, and sighash for the in-progress sharding work.

Since the info for this object will change over time with changes to the VM rules we should use the following API to allow for changing out the class which contains this data.

# vm_state.py

class VMState:
    transaction_context_class = None  # must be set in individual VMState classes

    @classmethod
    def get_transaction_context_class(cls):
        # error check to be sure it's set
        return self.transaction_context_class

Then, within the VMState.execute_transaction implementation, after the message instance is created, we should also generate the transaction context instance.

Then, we modify vm_state.get_computation to take both message and transaction_context as arguments. The transaction_context should be stored on the Computation object. When child computations are spawned, this object should be passed into those instances.

Any opcodes which previously accessed values from the Message which now reside on the TransactionContext object will need to be updated.

[pipermerriam]

@lrettig this would be a good issue for you to look into.

[lrettig]

Do we want to include message.is_static here as well? Per https://github.com/ethereum/EIPs/blob/master/EIPS/eip-214.md, this appears to be static in sub-calls.

Update: @pipermerriam says: “Should not be included. It’s included in sub calls only once set so while it can’t toggle back and forth, it can change from one computation to the next. Check out the static call opcode.”