I’ve got some questions about the state architecture after reading the state architecture report. A lot of them are related to shielded execution specifically, but some aren’t.
Analysing State Architecture for Shielded Execution: post-ordering execution becomes irrelevant[1], so all of the mechanisms that cannot meaningfully exist without post-ordering execution become irrelevant as well
Post-ordering execution implies incomplete in some sense transactions, e.g., when the resource to be consumed is not known before ordering. This is not possible for shielded execution since only valid shielded transactions can be ordered, and validity implies that all proofs verify and the transaction balances. Such shielded transaction can be augmented with a transparent part, but the transparent part cannot enter the same execution context (it makes the logic proofs invalid) and has to balance separately (because the shielded part must already be balanced), so it doesn’t seem very connected to the shielded state transition and, it seems, can be considered a separate transaction. I’m not sure how it works in mixed transactions that contain shielded and transparent resources as a part of the same action.
To more conveniently refer to the state components, I made a diagram summarising them.
- Commitment keys inclusion proofs
- I assume by inclusion proofs here we imply the accumulator witness and the accumulated value (referred to as an inclusion root in the report) needed to prove inclusion. The accumulated value must be checked against the list of existing inclusion roots
- (PostOE) Prove the existence of a recent commitment is not possible for shielded resources because the only recognised proof of existence is the inclusion proof (a part of the compliance proof specifically). I know it is already post-ordering, but still wanted to explicitly say that.
- Blob storage.
- The report says that it generally makes sense for the data known in advance to be included directly than via the blob storage. In shielded execution, the data is always known in advance because it has to be proven in advance [2]. That implies that the role of the blob storage for shielded resources is much less important compared to transparent resources.
- If the role of the blob storage is not crucial for shielded resources, the authentication mechanism for the deletion criteria in the shielded case becomes also much less relevant. This question is also related to the question of specifying per-node storage and blob storage writes separately[3].
- Another question is about requesting to store a blob. The report specifies that the blob has to be included in
appdata[4], but the primary role of theappdatafield is to contain the instance for the logic proof verification. This implies either:- the whole instance is a blob - unlikely due to the structural difference
- the instance contains the blob to be stored: meaning that logic has to verify the validity of the blob. At the same time, the blob will contain the data about the resource it is associated with, so it kind of introduces a circular reference problem
- the instance is processed in order to create a blob out of it. This would require to specify how it is processed exactly (there are must be structures that allow the creator to specify what parts of the instance to include/exclude)
Other questions about the report:
- When might we want to store unit instead of an inclusion proof under the commitment key? It feels like it is supposed to help when we can’t prove inclusion. Is it for when the commitment is already created, but the commitment accumulator isn’t updated yet?
- Where is the commitment accumulator itself stored (i.e., not just the leafs and the roots, but the intermediate nodes)? How are inclusion proofs computed without the intermediate nodes? Are they recalculated each time?
cc @isheff
Except the processing that doesn’t require changing the transaction structure. Not sure if it actually counts as post-ordering execution the way we define it, but it is post-ordering something ↩︎
Leaving the proof to be completed later makes little practical sense since there is no way to distinguish an invalid transaction from a valid but delayed one + whoever creates the proof, needs to know the data. It can probably be arranged for a high fee, but there are a lot of other questions about how it would work in that case and it generally seems like an exotic idea to me ↩︎
If we decide to proceed with splitting, I think we should have a separate discussion on the properties related to each storage writes and the corresponding deletion criteria ↩︎
this part is included in the section 7.3 which talks about post-ordering execution, but it seems that it is supposed to apply to the shielded case as well ↩︎