[RFC] New transaction model #8068
Conversation
rfcs/0041-new-transaction-model.md
Outdated
|
|
||
| ### Fees and proofs required | ||
|
|
||
| Instead of 2 proofs per transaction as is required now, we will switch to 2 proofs per "party". |
There was a problem hiding this comment.
If I understood correctly, all the parties within a transaction need to be included in one block. Like, including a payment in a block would mean including both the (or 3) parties in the scan state. Are we going to cap the number parties based on the scan state size?
Furthermore, seems like all the parties of a transaction and the ones that settles the fees need to be in the same tree so that the net fee excess is zero.
There was a problem hiding this comment.
This is a good point. We will need to think carefully about our block production logic in this transaction model.
There was a problem hiding this comment.
If I understood correctly, all the parties within a transaction need to be included in one block. Like, including a payment in a block would mean including both the (or 3) parties in the scan state. Are we going to cap the number parties based on the scan state size?
Good question. Just making sure I understand this correctly: do you mean all the parties need to be included in the same block or in the same tree? All the parties within a transaction would be in the same block, since a block contains a list of transactions and each transaction is a list of parties. I think we can actually avoid the requirement of all parties being in the same tree by having the ledger for the currently executing transaction as a kind of "hypothetical" state that gets committed once all the parties in the transaction have finished.
Furthermore, seems like all the parties of a transaction and the ones that settles the fees need to be in the same tree so that the net fee excess is zero.
Do you mean the corresponding fee transfers should be in the same tree? Actually how does this work now (isn't it the same problem)?
There was a problem hiding this comment.
do you mean all the parties need to be included in the same block or in the same tree?
The same block. This was to confirm if we'll need to cap the number of parties per transaction based on the scan state size.
Do you mean the corresponding fee transfers should be in the same tree? Actually how does this work now (isn't it the same problem)?
The parties of a transaction and the corresponding fee transfers should be in the same tree for the fee excess to be zero in the final merge proof. This is the case even now, just that it is always one transaction per leaf. So to add a transaction, in the worst case we'll need 3 leaves (1 transaction, 2 fee transfers). If the number of leaves in a tree <= 2 and we can't add any transaction because we can't fit in the required fee transfers, then we fill them with coinbase transactions (split the coinbase amount among two transactions). Now with each party occupying a leaf and there being arbitrary number of parties, it is not very clear what the optimal solution would be
There was a problem hiding this comment.
👍 Overall, this sounds like a good approach for our transaction model wrt supporting snapps. I think we should put a little more thought into how transaction ordering and transaction selection (for block production) will work in this model, because it does seem to drastically increase the complexity of those 2 algorithms. In particular, transaction sequencing seems tricky in the model, as does determining how to apply transactions from the pool in a way that can't deadlock transaction inclusion in blocks (in a decidable manor).
rfcs/0041-new-transaction-model.md
Outdated
| - Backwards compatibility | ||
| + Before changing the special case transactions into the above, we will have to make sure all signers are updated as the signed payload will change. | ||
| - Transaction pool sorting | ||
| + Currently, transactions in the transaction pool are sorted by sender by nonce. If general sequences of parties are allowed as transactions, this will not work and we will have to figure out another way to order things. |
There was a problem hiding this comment.
It would be nice to explore some ideas how we would sort the transaction pool in this transaction model, at least so that we have confidence there is a reasonable mechanism for doing so. In particular, it seems that transaction sequencing logic could get really complex with this transaction model.
rfcs/0041-new-transaction-model.md
Outdated
|
|
||
| If we do this in the most straightforward way, a payment would go from occupying one leaf in the scan state to either 2 or 3 (if there is a separate fee payer). However, the proofs corresponding to these leaves would be correspondingly simpler. That said, there probably would be some efficiency loss and so if we want to avoid that, we can make circuits that "unroll the loop" and execute several parties per circuit. | ||
|
|
||
| Specifically, for any sequence of authorization types, we can make a corresponding circuit to execute a sequence of parties with those authorization types. For example, it might be worth having a special circuit for the authorization type sequence `[ Signature; None ]` for a simple payment transaction that executes one party with a Signature authorization (the sender), and then one with no authorization (the receiver). |
There was a problem hiding this comment.
👍 I think special circuits that optimize common sequences like this is a good strategy here.
rfcs/0041-new-transaction-model.md
Outdated
|
|
||
| ### Fees and proofs required | ||
|
|
||
| Instead of 2 proofs per transaction as is required now, we will switch to 2 proofs per "party". |
There was a problem hiding this comment.
This is a good point. We will need to think carefully about our block production logic in this transaction model.
rfcs/0041-new-transaction-model.md
Outdated
| } | ||
| ] | ||
| ``` | ||
|
|
There was a problem hiding this comment.
How are these multiparty transactions agreed on by the parties? Are they constructed out-of-band and then broadcast in completed form or are partially signed transactions broadcast as each signer adds their "party" asynchronously?
rfcs/0041-new-transaction-model.md
Outdated
|
|
||
| A token swap trading `n` of token `A` from `sender_A` for `m` of token `B` from `sender_B`, plus a fee payment of `fee` from `fee_payer` would look like | ||
| ```ocaml | ||
| [ { authorization= Signature ... |
There was a problem hiding this comment.
Could it be useful to put all the signatures in one place so that they could be replaced with an aggregate signature at a later stage, or possibly aggregate signatures from the start?
rfcs/0041-new-transaction-model.md
Outdated
| ; predicate= (fun _ -> a.token_id == A && a.public_key == sender_B) | ||
| ; update= (fun a -> {a with balance= a.balance + n}) | ||
| } | ||
| ; { authorization= Signature ... |
There was a problem hiding this comment.
What does each signature sign? The whole transaction or just the party?
rfcs/0041-new-transaction-model.md
Outdated
| ## Potential issues | ||
|
|
||
| - Backwards compatibility | ||
| + Before changing the special case transactions into the above, we will have to make sure all signers are updated as the signed payload will change. |
There was a problem hiding this comment.
This would mean the Ledger signer would need to be updated and we are pretty tight on stack space there. It could be a challenge there to support the new format if the random oracle input is significantly bigger. We probably want to maintain a compact format for compatibility with resource constrained devices. Perhaps the new transaction model can already do this... just to call it out.
Add branching policy doc
…ixes Ledger export upgrades
|
!ci-build-me |
imeckler
requested review from
a team,
bkase,
psteckler and
aneesharaines
as code owners
|
!ci-build-me |
This proposes refactoring the transaction execution model, primarily to make it easy to implement Snapps transactions involving an arbitrary number of parties without having circuits that verify corresponding numbers of proofs. I.e., this model will make it possible to e.g., have a transaction involving 10 snapp accounts while only having a base transaction SNARK circuit that verifies a single proof.