I assume “precompiles” are vetted before they get included in the state.
Nope! BTW I just renamed “precompile” to “execution script” to clarify that these aren’t like eth1 precompiles. There’s two major use cases for execution scripts:
- As the code that is used to execute top-level transactions.
- As functions that can get called by other code, where those functions represent code that is expected to get executed many times by many different actors, and so benefits from being stored once in the beacon chain rather than in every shard and from being stored by clients in compiled form so it can get executed much more quickly.
Q: Why is there a need to execute raw code? This is dynamic data and makes verification of the “precompile” much harder.
The execution scripts on the beacon chain are meant to be very few in number, perhaps a few thousand at most. There’s not enough space on the beacon chain to hold code for every user. So the way that user-level code would be stored is that it would be stored in storage slots on the shards, and then the execution scripts would handle the logic of “treat this storage data as contract code, treat this other storage data as contract storage, and execute the code with storage and tx data as input”.
Q: Is this execution starting off with its own
MAX_TX_GAS_LIMITor whatever is left at the time of calling it?
Removed MAX_TX_GAS_LIMIT for the moment. The goal is that there is N total gas per block that gets assigned to transactions in that block; if that N gas runs out before all the transactions get processed, then the remaining transactions would either get skipped over or they would get processed with some minimum quantity of gas that lets them do basic operations but not more.