joebebel
commented
1 year ago Ideally, from Taiga's perspective, it just sees an abstract data store with the operations that Xuyang described. We should specify the exact requirements/guarantees for the root_check, nullifier_nonexistence_check_and_store, and output_note_store operations, and then describe how it maps onto Typhon reads and writes.
There are some nontrivial steps here, because this involves adding the output note commitments to the note commitment Merkle tree (thus creating new roots), and as Isaac said, maybe we can do some of these operations in a few different ways, which might be more efficient.
bazzilic
Taiga interpreter API exposed to the Executor Node.
execute(txRequest, read_key_subspace, write_key_subspace)For better context, copying over a short discussion on this issue that took place in Slack:
@bazzilic: If I am not wrong, read and write keys are out of the scope of Taiga, so this API signature probably needs to be different somehow.
@isheff: Technically,
executeneeds to take in:get_read_key_subspace(txRequest)txRequestexecutethen needs to runtxRequest.executable, which takes in:get_read_key_subspace(txRequest)and outputs
get_write_key_subspace(txRequest)executethen needs to check those proofs, and if they are ok, return the new values to be stored in the key-value-store under the keys inget_write_key_subspace(txRequest)to Typhon, which stores them.I'm not sure whether we also want to return and store the proofs. I suppose full nodes might want them.
Also, this still ignores the question of gas, which we should address at some point.
@bazzilic: my point was that Taiga (IIUC) is agnostic of the underlying data storage model, which might or might not be key-value. So to Taiga, Typhon key subspaces don’t mean much.
@isheff: well, we need to structure all the current state it needs to read, and all the new state it needs to write. I don't think Taiga can be completely agnostic to how that is organized.
@bazzilic: True. We need to figure out how state is structured in Taiga and I think the API should resemble that, and then there might be an adapter between typhon data model and taiga data model, which probably can be part of the Scaffolding: Typhon calls an “execute API” in Scaffolding with the typhon data model, and Scaffolding calls Taiga API with the Taiga data model. This way we can keep stuff clean and separated. @XuyangSong maybe you can help with some context on how Taiga stores state? I.e., since Taiga produces a state transition, then there should be the initial state in some form and then the state “delta” in some form… right? How are these stored in Taiga?
@XuyangSong: For Taiga state transition, I can list some in shielded tx:
@isheff: so, the nullifier non-existence check and the output note commitment check can be mapped fairly directly to key-value reads and writes
the root existence check can be done a coupe of ways: one is to use a signed state root as part of the proof, so we don't actually have to read anything from state at runtime: the
txRequestcreator acquires a (possibly old) signed state root in advance.For plaintext transactions however, we want to be able to read / manipulate state that has changed since the
txRequestwas sent into the mempool. For this, we have to have some kind of way of identifying the relevant piece of state (a "key") and some notion of the current state in that piece (a "value"), so we kind of need something like a key-value-store abstraction.