STUB: New transaction format

See sharding doc

• Update Transaction format (depend on #203 and #192) The format of a transaction now becomes:

  [
      chain_id,      # 1 on mainnet
      shard_id,      # the shard the transaction goes onto
      target,        # account the tx goes to
      data,          # transaction data
      start_gas,     # starting gas
      gasprice,      # gasprice
      access_list,   # access list (see below for specification)
      code           # initcode of the target (for account creation)
  ]
  

~- [ ] Update apply_transaction function procedure~

[vbuterin]

There needs to be a way to construct the access list without prior knowledge. So there should be a execution mode that works with an empty access list (or a placeholder) and that keeps track of which storage slots are accessed.

IMO doing this with an execution mode is a bad idea; it would break in any scenario where the keys accessed depend even slightly on variables that could be affected by third parties. The access lists should be generated by something which gets added to Viper; you would pass a function name and arguments and Viper would reply back with what addresses and storage keys could get read or written.

For now, I recommend that we stick to setting the access list to be the sender and receiver, including their entire storage, and possibly add a field for “manually add an additional address” for transactions to contracts that trigger payouts to third-party addresses; don’t bother doing partial storage witnesses until later. Even sender and receiver only covers a huge number of use cases.

Good point, my guess is that with stateless clients gas costs of state access in general will need to be revised significantly.

Yep! My personal preference at the moment BTW is that we charge a clean 4 gas per byte for all transaction or witness data, and we compute witness sizes based on the trie/state root at the start of collation execution (ie. part of the witness verification step of verifying a collation).

Regarding cost of SLOAD and SSTORE, I recommend just keeping the status quo for now.

I think there would be something like check_PAYGAS_execution which basically acts like execute_transaction but with a gas limit(specified by miner?) and returns True if PAYGASopcode is execute or returnFalse` if gas limit reached.

I think the solution may be simpler. Rather than just returning success or failure, we could return two kinds of failure, one where PAYGAS is executed, and if so with what gasprice, and the other where PAYGAS is not executed.

[jannikluhn]

I’m gonna start working on this, but disregard any account abstraction stuff for the moment (as there’s no clear/single specification yet). So the transaction object will include nonce and signature. Removing those should be trivial later.