Taiga Interpreter API (Executor Node)

[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, execute needs to take in:

• all the values currently stored in the key-value-store under the keys in get_read_key_subspace(txRequest)
• txRequest

execute then needs to run txRequest.executable, which takes in:

• all the values currently stored in the key-value-store under the keys in get_read_key_subspace(txRequest)

and outputs

• all the new values to be stored in the key-value-store under the keys in get_write_key_subspace(txRequest)
• a set of proofs proving that those values are OK.

execute then 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 in get_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:

• root existence check(read)
• nullifier non-existence check and store(read and write)
• output note commitment(write)

@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 txRequest creator 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 txRequest was 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.

[ghost]

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]

I think, Taiga should not be concerned about the data store at all and should not see/use these APIs. There are several validity conditions for a transaction:

• NUL: Nullifiers have not been used yet (no double spend)
• COM: Commitments are not in the tree yet (no double mint)
• VP: All VPs are satisfied: app VPs, user VPs, Action circuit, etc.

IMO, Taiga should only be concerned with VP condition; NUL and COM should be checked somewhere else by whoever calls Taiga's execute API.

I may be missing something though.