feat!: introduce block header into every smart contract execution context #5151
Conversation
mversic
requested review from
s8sato,
SamHSmith,
outoftardis,
Erigara,
0x009922,
DCNick3 and
dima74
as code owners
mversic
force-pushed
the
wasm_block_header_context
branch
7 times, most recently
from
9c8f8eb to
3437e43
Compare
mversic
force-pushed
the
wasm_block_header_context
branch
from
3437e43 to
3599869
Compare
mversic
force-pushed
the
wasm_block_header_context
branch
4 times, most recently
from
7c464b8 to
2daddf4
Compare
mversic
force-pushed
the
wasm_block_header_context
branch
from
2daddf4 to
0b133cb
Compare
…text Signed-off-by: Marin Veršić <[email protected]>
mversic
force-pushed
the
wasm_block_header_context
branch
from
0b133cb to
ce502ac
Compare
| fn get_smart_contract_context(state: &state::SmartContract) -> payloads::SmartContractContext { | ||
| payloads::SmartContractContext { | ||
| authority: state.authority.clone(), | ||
| curr_block: state.state.0.curr_block, |
There was a problem hiding this comment.
- smart contract and trigger execution (as latest current block header)
There seems to be an error on documentation side:
Since the execution phase of a smartcontract (wasm as a transaction executable) is different from that of a trigger, each pair (block height, what executions refer the block header) is as follows:
| >>>>>>>>>> | block committed | >>>>>>>>>> | triggers executed | |
|---|---|---|---|---|
current: StateTransaction.curr_block |
k-1 or k, transaction | k, trigger | ||
latest committed: CommonState.specific_state.curr_block |
k-1, query | k, query? |
So a smartcontract refers the current (validating) block header, not the latest one. On the other hand, it is true that a block header that a trigger refers is current and latest committed
EDIT:
I'm not sure about queries during a trigger execution. At least during a by-call trigger execution, it seems ExecuteTransaction state blindly lets a query pass. So far this issue hasn't surfaced because even if it were connected to visit_query, that would validate nothing
There was a problem hiding this comment.
You are correct. But this is only because our trigger execution model is broken
There was a problem hiding this comment.
Yes, when transaction and trigger execution are integrated and sequenced, such a discussion would be unnecessary
There was a problem hiding this comment.
so this should be fixed for queries that are executing as part of a transaction (like from inside a trigger). They should receive current block header instead of latest block header. Do you agree?
Any other issues to address?
closes #4958
Block header is provided as context of execution for:
As a consequence of this change block header variable was added to
StateBlockandStateTransaction. While doing this I get the feeling thatStateBlockcould take ownership of the whole block that it is validating