Simple Rollup Design Discussion

[vivekvpandya]

Option 1:

1) Client gets current state for transfer from the substrate node via RPC. 2) Creates Proof of transfer with above state and records new and old state in receipt's journal. 3) Client sends proof with subxt to rollup pallet. 4) if verification succeeds and old state == current state on substrate node, rollup pallets accepts transaction and executes Balances pallet's appropriate API. 5) For some reason if old state upon which proof was created has changed , rollup rejects the proof.

What does above example serve?

• It is just shows Risc0 verification works in Substrate.
• Avoids complex signature checks on-chain.
• However it still executes balances API, which can be improved later.

Option 2:

if we can have an intermideary node say sequencer/accumulator which accepts transactions from various clients and runs some protocol to identify dependent/independent transactions checks if transfer satisfies arithmetic properties. then It creates a proof and journal with a vector of (account, old_balance, new_balance)
So if verifier accepts proof it can change balance of more than one account.

Ideally we want proof of proofs and verify single proof but AFAIK it is currently licensed in RISC0.

[justinfrevert]

I can't think of a different approach at the moment

[justinfrevert]

Comments on Option 1(by number)

1. I'd think we'd want some formal representation of the balances state, but I guess we can query the specific balance data required in order to get started quickly.
2. Needs investigation on how to batch transactions Four: I wonder if this is a safeguard against other proof submissions changing the state before us. Perhaps we could optimize with some validate_unsigned/TransactionValidity stuff when guards against that. But unsure if that's the intent.

[vivekvpandya]

I wonder if this is a safeguard against other proof submissions changing the state before us.

that's the intent, we could prevent any other way of changes in balance by using certain maintenance pallet which prohibits certain extrinsic of pallet balances or assets.

[justinfrevert]

I still have one question: Can you expand on what you're suggesting for an intermediary node plus its relationship with the verifier? I can imagine this to be a number of things

[vivekvpandya]

I still have one question: Can you expand on what you're suggesting for an intermediary node plus its relationship with the verifier? I can imagine this to be a number of things

So the idea is that a intermediary node can collect transaction requests and group them based if they are independent or not etc. Then create a proof for say X number of such transfers together and send proof (it can be also made periodic i.e if there are already Y seconds passed and we don't have X transfers it will create proof for whatever it has) Then verifier can verify this single proof for X transfers

[justinfrevert]

I still have one question: Can you expand on what you're suggesting for an intermediary node plus its relationship with the verifier? I can imagine this to be a number of things

So the idea is that a intermediary node can collect transaction requests and group them based if they are independent or not etc. Then create a proof for say X number of such transfers together and send proof (it can be also made periodic i.e if there are already Y seconds passed and we don't have X transfers it will create proof for whatever it has)

Then verifier can verify this single proof for X transfers

Independent here meaning not part of a batch transaction? Understood. It's clear the sequencer should form batch txes regardless

[justinfrevert]

I guess Option two is a bit more of a running example, and option one is a bit more POC, where option one does not have a real entrypoint. Number two also specifies the batching more clearly. For the first reason, I'm leaning more towards option one.

[justinfrevert]

@vivekvpandya i am still understanding the role of the sequencer + its typical relationships in the rollup architecture Can you let me know if this is the proper understanding?

[vivekvpandya]

@vivekvpandya i am still understanding the role of the sequencer + its typical relationships in the rollup architecture Can you let me know if this is the proper understanding?

So Risc0 generates a proof of a loop which checks validity for transfers , so we have proof and in journal we can add Vec<(account,old_bal,new_bal)> and then if proof verifies fine for given inputs that means we can update balance for all account in Vec<> specified in journal does this seem feasible and correct?

[justinfrevert]

@vivekvpandya generally the structure makes sense, though I am not clear on the inclusion of the old_bal. How do you see this value being used? I'd guess that we would already be performing some check on the old balance when we do the checks in the prover.

[vivekvpandya]

@vivekvpandya generally the structure makes sense, though I am not clear on the inclusion of the old_bal. How do you see this value being used? I'd guess that we would already be performing some check on the old balance when we do the checks in the prover.

So I think old_bal is only needed if there are other extrinsics (non-ZK) which also able to change the state. Otherwise I think its fine. Also I don't recall correctly but if proof verification requires old_bal then we don't need old_bal in receipt.

[justinfrevert]

Sorry for the radio silence. Will have some more time in the next week or so.

I think another challenge will be figuring out how to wrap the risc0 guest in some sort of long-running task/server on the client from which the client can then repeatedly request proofs.

[justinfrevert]

Sorry for the radio silence. Will have some more time in the next week or so.

I think another challenge will be figuring out how to wrap the risc0 guest in some sort of long-running task/server on the sequencer's client from which the client can then repeatedly request proofs.

[vivekvpandya]

Yes that can be a linux demon process which can just accept transactions through CLI or expose web service.

On Sun, Apr 30, 2023, 12:38 AM justinFrevert @.***> wrote:

Sorry for the radio silence. Will have some more time in the next week or so.

I think another challenge will be figuring out how to wrap the risc0 guest in some sort of long-running task/server on the client from which the client can then repeatedly request proofs.

— Reply to this email directly, view it on GitHub https://github.com/justinFrevert/substrate-web3athon-2023/issues/1#issuecomment-1528852462, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGZYBFXN2RZB5QO7QAX5ZDXDVRJ7ANCNFSM6AAAAAAXE5VKGY . You are receiving this because you were mentioned.Message ID: @.***>