Transaction object

[bobbinth]

Transaction object is perhaps one of the more complicated objects in the rollup. The main reason is that there are actually several different ways to look at is depending on the context. So, before writing any code, I wanted to lay out my thoughts about all these variations in this note.

Overall, there are 3 different contexts for transactions objects:

1. Proven transactions. These are the transactions which get included into proof batches, and then get recorded into blocks. Proven transaction can be generated both locally (when the end user proves their transaction) or by the network (for network transactions).
2. Stateless transactions. These transactions contain the minimum amount of data needed for execution/proving. This implies that these transactions have already been executed (and thus we know exactly what data they need), but they have not yet been proven. Such transactions could be executed locally by users and then sent to the network to be proven by an operator.
3. Prepared transactions. These transactions have not been executed yet, and thus, we don't know what data they may need to request from the advice provider. All transactions start as "prepared" and then can transition either to "executed" or "proven" state like in the diagram below.

Below I'll describe each of these 3 contexts in more detail.

Proven transactions

This variant is perhaps the simplest one to describe. A proven transaction consists of the following components:

Field	Description
Account ID	The identifier of the account involved in the transaction.
Initial account hash	Hash of the account state at the beginning of the transaction. Technically, this is redundant because it should be possible to look up the hash based on the ID, but I think it doesn't hurt to include it here.
Final account hash	Hash of the account state at the end of the transaction.
Consumed note info	A list of tuples (nullifier, script_root) for all notes consumed by the transaction.
Created note info	A list of note hashes created by the transaction.
tx script root	MAST root of the transaction script for the transaction (if any).
Block reference	Hash of the last known block at the time the transaction was created.
Proof	STARK proof attesting to the correct execution of the transaction program.

The above info should be enough to verify that the transaction was executed correctly and to update Account DB, Note DB, and Nullifer DB accordingly. However, if the involved account/notes are stored on-chain, we need to include additional info. Specifically:

• For any created note which is to be stored on-chain (i.e., note hash starts with 00 or 01), we also need to include full note details (i.e., contents of note vault, root of note script etc.). This is one of the reasons why it is important to be able to determine if a note details are to be stored on chain by examining solely the note's hash.
  • One open question is how to ensure that the included script is indeed the script which the user wanted to include with the note. We can always verify that the script compiles to a specific MAST root, but this may not be enough.
• If the account is store on chain, we also need to include all info required to update the detailed account data (i.e., vault delta, storage delta, code delta etc.)
  • Similar open question to above: if the code was updated, how to ensure that the intended code has been attached to the transaction.

Stateless transactions

As mentioned previously, this variant contains the minimum info required to execute and prove a transaction. A stateless transaction consists of the following components:

Field	Description
Account ID	The identifier of the account involved in the transaction.
Initial account hash	Hash of the account state at the beginning of the transaction.
Invoked account methods	Code for methods invoked on the account during this transaction.
tx script	Code of the optional transaction script.
Consumed note Info	A list of tuples (nullifier, note_script) for all notes consumed by the transaction.
Block reference	Hash of the last known block at the time the transaction was created.
Advice transcript	A transcript of all data served by the advice provider during transaction execution.

The key component in the above is the "advice transcript". This will contain all the data that will be requested by the VM during transaction execution from the advice provider, but nothing more than that. An advice transcript may include the following info:

• Pre-images of the initial account state, consumed note hashes, last known block, etc.
• Inclusion proofs for all methods invoked on the account.
• Inclusion proofs for all consumed notes against the root of the Note DB.
• Storage access proofs.
• Vault access proofs.

To execute a stateless transaction, we would need to do the following:

1. Build a transaction program by combining note scripts, invoked account methods, and tx script.
2. Initialize the advice provider with data from advice transcript.
3. Execute and prove the program built in step 1 against the advice provider built in step 2.

The output of the above process would be the proven transaction object described previously.

Similarly to the proven transaction object, stateless transaction would need to include additional data when the account and/or created notes are stored on-chain.

Prepared transactions

TODO

[bobbinth]

I've rethought the transaction processing pipeline a bit. Now I think it could look more like this:

To briefly describe the process:

1. First a transaction gets compiled by the transaction compiler. The main job of the tx complier is to build a transaction program from account interface methods, note scripts, and tx script. We still need to figure out what's the best way to do this.
2. The output of the transaction compiler is a CompiledTransaction (described in a bit more detail here). This object is not meant for serialization - it will be passed in immediately to a subsequent component. Here, we'd have two options
3. The first option is to pass the compiled transaction to the transaction prover. In this case, the transaction prover will be responsible for loading all required account data (from the database or somewhere else), executing and proving the transaction. The output will be ProvenTransaction (described in some detail here).
4. The second option is to pass the compiled transaction to the transaction executor. Transaction executor would execute the transaction but not prove it. But just like transaction prover, it would be responsible for loading all required account data. The main contribution of the transaction executor is that it would build an advice transcript. This transcript will record all requests/responses to the advice provider so that the transaction could be replayed later.
5. The output of the transaction executor would be a PreparedTransaction (not yet described anywhere). This object can then be passed to the transaction prover for it to generate the proof - but in this case, since advice transcript is available, the prover would not need to retrieve account data from any external source.

Both PreparedTransaction and ProvenTransaction can be serialized and sent to the network. In case of ProvenTransaction the proof can be verified and the transaction would be added to the proven tx pool. In case of PreparedTransaction anyone can execute and prove it stalesly (since all relevant data would be included in the PreparedTransaction object).

[Dominik1999]

That looks cool. We could, in theory, have a market for PreparedTransactions to get proven.

Is there a way where a transaction could get executed but would fail the proving step? So when there are two conflicting PreparedTransactions only one can get proven, right?

[bobbinth]

We could, in theory, have a market for PreparedTransactions to get proven.

Yes - definitely. I think the biggest question here would be how to collect fees for this.

Is there a way where a transaction could get executed but would fail the proving step?

Not for honest users - but it would be possible for a malicious user to construct prepared transactions for which proof generation would fail.

So when there are two conflicting PreparedTransactions only one can get proven, right?

Conflicting transactions are different from invalid transactions. You can still be able to generate proofs for conflicting transactions, but only one of them would get included into a block.