[Docs]: Update Transaction

[phklive]

In this PR I propose to update the Transaction section of the Miden documentation:

• more explanative
• more approachable for new developers
• shortened
• simplified
• re-phrased
• updated structure

Additional questions:

• How can we describe the different components of a transaction considering that there is no Transaction object but two:

1. ExecutedTransaction
2. ProvenTransaction

Closes: 0xPolygonMiden/miden-docs#15

[bobbinth]

Thank you! Looks good. I left some comments inline. Overall, I think we are missing quite a bit of content. Basically, we want the user to come away from this section knowing how transactions work and what one can do with them. This needs to be high-level content but it needs to be comprehensive. For example, we don't need to explain about kernels, execution contents, procedure names etc. but we probably should cover how how notes are executed, why we need transaction scripts, who defines note sequencing, how can transactions be authenticated (e.g., do they need to be signed like in other chains?) etc.

[bobbinth]

To me this digram is somewhat confusing. I would use something simpler (which have a simpler version in the deck). The proportions of the graphic are also off (it is too big).

[bobbinth]

I think we are missing quite a bit of information about what transactions are and what they can do and maybe this is the section this info is supposed to go to? The things we should cover (at the high level):

• How transaction execution flows - e.g., note scripts are executed one by one, this sequence is defined by whoever crates the transaction, note scripts can call procedures exposed by the account interface - but they cannot do arbitrary things etc.
  • We could give a bit of info about things like note inputs and note args and how they affect note execution - but maybe that's too much and should go somewhere else.
• I would explain a bit more about the transaction script and why it is needed. maybe give a couple of examples of what it is used for (same goes for notes).
• We should also mention other interesting things about transactions - e.g., that it is possible set transaction expiration height (both accounts and notes can do this), that we can read states of other accounts in a transaction (via foreign procedure invocation).

We don't need to go into all of the above topics in depth, but we should make sure a somewhat technical person can come away with good understanding of how transactions work and what they provide.

I would also add a "real-world" example of how transactions accomplish some task - e.g., transferring funds from one account to another.

[bobbinth]

I know this comes from our deck, but this diagram is actually not correct. All steps happen in both cases - just who does them differs.

[bobbinth]

I think we can improve this section to make sure it really stands out. Local transactions is something that most other chains cannot do. They basically enabled theoretically unbounded computation complexity (e.g., no more gas limits). I would also make sure that this is not just for users - apps can benefit from this too. e.g., we can have apps running their logic off-chain (either in a centralized or decentralized mode) to minimize fees, not be subject to network congestion etc.

[bobbinth]

The first point is not correct - I would get rid of it. Network transactions are there basically for 2 reasons:

1. Handling of public shared state. This is an important thing to cover somewhat in depth because after reading about local transactions, savvy developers will immediately have questions about how how public shared state works.
2. Ensuring liveness for public accounts. This is something we haven't really covered previously, but is a pretty cool thing which would basically let the network update some accounts only during some blocks. For example, let's say for 59 minutes of every hour only some permissioned set of entities can update a given account, but every last minute of the hour, the network can do it. This way, as long as the permissioned set does what it is supposed to, the computational burden on the network is minimal. But if the permissioned set stops working, the network could still update the account (though at a much slower pace).

[phklive]

Could you clarify why the first point is not true?

I have the feeling that the second point is a very specific use case of networked tx's and does not really have it's place there. But it could be argued.

[bobbinth]

Could you clarify why the first point is not true?

Network transactions do not help resource-constrained clients. That is, for the network transaction to happen, the client still needs to put a note intended for this transaction on-chain. So, they still need to generate a proof for this transaction. What helps resource-constrained clients is delegated proving - but that's different from network transactions.

I have the feeling that the second point is a very specific use case of networked tx's and does not really have it's place there. But it could be argued.

Yeah, we probably don't need to describe it in such detail but maybe there is a good way to mention it in 1 - 2 sentences as an example of what network transactions could be used for.

[phklive]

Network transactions do not help resource-constrained clients. That is, for the network transaction to happen, the client still needs to put a note intended for this transaction on-chain. So, they still need to generate a proof for this transaction. What helps resource-constrained clients is delegated proving - but that's different from network transactions.

Does that mean that in Miden there is no way for a user to make a transaction without executing the VM and Prover?

Would a user have the ability to make a transaction like in Ethereum by simply signing a message? ( I guess this would work for public accounts but not for local / private accounts )

[bobbinth]

Does that mean that in Miden there is no way for a user to make a transaction without executing the VM and Prover?

Without executing - no, without proving, yes. That is, the user could execute a transaction but delegate proving to someone else (at the expense of giving up privacy to this someone).

Would a user have the ability to make a transaction like in Ethereum by simply signing a message? ( I guess this would work for public accounts but not for local / private accounts )

Doing something like this today would be pretty difficult. The biggest question is, what message would the user sign? For example, if we want someone else to execute a transaction on our behalf, we need to give them enough info to complete the transaction. Currently, the means a signature over a message that is derived from: initial account state, final account state, all input notes of the transaction, all output notes of a transaction. If someone can produce such a message (and a corresponding signature), then someone else can create a transaction for them.

However, building such a messages for a general transaction would mean executing the VM (to get the final state of the account and output notes). For a specialized transaction, we can probably compute these without running the VM (e.g., if we consume a P2ID note, we know how the account will be updated - so, no need to run the VM to get the account's final state).

Another option could be to re-define what is being signed (and this can be specified on per-account basis). Maybe it is enough to sign over initial account state + input notes, but this needs to be analyzed more carefully to make sure we don't open up any attack vectors.

[bobbinth]

I'm not sure we need to mention compilation/execution/proving in this section - it feels like lower-level details that can be explained somewhere else. I would talk about proving costs and delegated proving though - but maybe as a part of some other section above.

[phklive]

Thank you! Looks good. I left some comments inline. Overall, I think we are missing quite a bit of content. Basically, we want the user to come away from this section knowing how transactions work and what one can do with them. This needs to be high-level content but it needs to be comprehensive. For example, we don't need to explain about kernels, execution contents, procedure names etc. but we probably should cover how how notes are executed, why we need transaction scripts, who defines note sequencing, how can transactions be authenticated (e.g., do they need to be signed like in other chains?) etc.

Indeed, this was a first pass where I mainly remove the unnecessary things and update to the new style. There is definitely some content missing indeed.