zkSummit - Roll-up and Roll-out - James Prestwich (Co-founder, Summa)

Transcript

[Music] my name's James I co-founded Summa and storage and I'm an advisor at a couple places and right now I'm representing cross-chain group which is a trade group of cross-chain engineers who work on various problems of crushing communication and engineering on multiple chains okay so we're here to talk about roll-out but first we're gonna cover what a roll up is because roll out is an extension of the roll up scheme alright so this is not a formal description we're not going to go into any math I'm going to talk about a sketch of a system I think it's possible to build this idea is about seven days old so it's very high level

don't yell at me too much for it okay so ZK roll up I borrowed these slides from Barry white hat who's a great person ZK roll up is a scaling scheme for public blockchains it gives a constant factor improvement on throughput by putting data on chain and doing computation off chain so in ZK roll up we have transactions that affect a state tree we commit to the transactions and a proof of their validity on Shane so all of the transactions are published but not evaluated by the blockchain generally speaking this is what a

roll-up scheme does it puts transactions on chain and evaluates them off chain Zeke a rollup uses a validity proof so we have a snark that every tree state transition was valid all right the alternative is optimistic rola which is I borrowed these slides from the plasma group so they're completely different okay plasma group loves their emoji so optimistic roll-up as opposed to providing a validity proof we have the operator commit blocks of transactions that are not evaluated on Shane because it's a rollup and we wait for people to submit in validity proofs fraud proofs so blocks are accepted optimistically and if any off trained actor sees an

invalid block accepted there responsible for providing a proof of that blocks invalidity in this case that means that they instruct the main chain to evaluate the entire block of transactions against the state which can get quite expensive optimistic roll-up fraud proofs can be in the neighborhood of millions of gasps so can consume entire aetherium blocks but again like this is a rollup we have unchained data availability off chain data processing except in the worst case of fraud proof okay so typically speaking we have roll-ups they have one chain associated with them everything's going on to

aetherium role out we have the same scheme with any number of chains involved right so it's a sharded role up on all chains any chain that wants to implement this can join any operator can add any additional chain anytime okay so here's the goals of the system before we get into how it works we want a rollup we want it to support any number of block chains we want asset portability so you should be able to take your ether and move it through the roll-up to some other chain and we want no cross j communication in the traditional sense i keep dropping this thing i'm gonna put it down we want no crust strain communication in the traditional sense

this means no relays and no SPV proofs know like planting the change should be naive of each other we should not have state on one chain depending on the consensus process of the other and we want to a coherent authentication model we'll come back to that in a second because I want to explain exactly what it means so let's run through these goals real quick portability you should be able to take your ether move it to some other chain and move it back okay you should be able to do the same with arbitrary messages you should be able to move the message from one chain to the other potentially call some contract and send some results back so no direct cross-training communication so

typically when we have two chains the way they communicate is by referencing each other's consensus so we make a bunch of cross links we validate proof of work or proof of state this has an N squared problem when you have multiple chains it really like becomes a nice mess because you need every chain to light client every other chain we we don't want to do that we don't like N squared problems rollout kind of replaces this with a hub-and-spoke model where the hub is the roll-out chain so this is what we want we want no cross chain consensus references ok authentication model if you see a cross chain asset how do you

know that it's any good is this thing actually ether the idea of rollout is we can't decide on chain only off chain actors can decide whether the represented asset is equivalent to the native asset that belongs to another chain so when you represent ether on tezo's the tezo's chain does not know whether that is ether or not but any off trained actor that cares can verify that that asset is currently redeemable for ether on demand all right so these are not goals of the system we're not trying to make us a sink chain so we're not

trying to do the recursive snark thing we're not trying to deploy a new consensus system there should not be a proof of stake or proof of work system to extend the rollout we're not trying to create price pegs again we're going for asset redeem ability and portability we're not going for like perfect asset price correlation and we don't need to support arbitrary smart contracts in the rollout this is in contrast to optimistic roll-up which wants to support arbitrary smart contracts so that leads to the question like what is rollout you know if we have this system here that's got our money in it like what is that system okay which is what I'm gonna try to answer in the next

twenty minutes give or take so what is rollout it's a long transformers joke that I'm gonna skip over real quick roll out in the current conception is an extension of ZK roll-up so we're using zero knowledge validity proofs to achieve this okay so going back to roll up this is the general structure we have a tree that is the state of the roll-up it commits to a number of accounts each of which have a pub key and balance nonce and token identifier okay so roll-up can have multiple assets already that's very nice the way we're gonna end ZK roll-up commits state updates but not

state to chain so what we're gonna do the same thing however we're going to take the roll-up tree and shard it we're gonna make multiple sub trees each of which is associated with a specific blockchain you can add sub trees to this construction at any time there's no special state transition required to do that okay so we're gonna have one sub tree that's tezo's that has all of the tezo's associated balances one that's ether and has all of the ether associated balances this does not mean that that sub tree only has tessie's in

it or that it only has or that the each sub tree only has ether in it they can host any asset when you are outside of your native chain your asset is namespaced it has a identifier that specifies its origin so things that are that originate are native to the eath can be held in the tezo sub tree and vice versa we are sharding this so that we can separate state updates into different blobs that go on different chains so we separate transactions that affect the tezo's associated sub tree from transactions that affect the ether

associated sub tree and when we commit those to chain well okay so let's back up for a second we can have any number of sub trees we can add these anytime want the security model is that off chain actors have all of the information necessary to verify the system state and validity but the chains do not so we have multiple different sub trees associated with different chains the rollout chain gets updated by applying all of these transactions to the affected trees and going from a old rollout route to a new rollout route and we produce a validity proof of the tree

state transition so this is a zero knowledge proof some sort of snark potentially a recursive Starke depending on how complex this is to implement that these transactions took the tree from this root to the next root that we produced a valid new block and we build that into a chain we can take transactions apply them to the old root generate the validity proof and repeat indefinitely okay so we take those transactions and we shard them when we commit to chain so we have this rollout state update that updates the entire off

chain system with all of the transactions but when we commit it to chain we don't put all the transactions on a chain the tezo's chain sees the tezo's subtree transactions the dot chain sees the dot subtree transactions and the ether chain sees the ether sub tree transactions each chain verifies its own peg in in pay gap transactions and verifies the validity proof of the whole system ok so we have this like really small rollout update commitment that is different for each chain each chain commits to the validity proof of the entire state transition and to the availability of a subset of those

transactions the sub set of transactions that affects its sub tree ok and it looks kind of like this this is what the etherium chain actually sees is the old root the new root the transition validity proof and the etherium subset of transactions all right so it looks kind of like this is the etherium chain is progressing the rolap chain is progressing except I got the numbering backwards so just ignore that part I threw these slides together last night don't worry about it okay so the roll-out chain is progressing the etherium chain is referencing update proofs and it's making available the

etherium subtree transactions so we actually want to share that proof between multiple different updates and so the tezo's chain over here on the right side is seeing the same proof but a different subset of transactions and it's seeing the same roots but a different subset of transactions okay so we have this rollout chain that's progressing it's being referenced by multiple chains each of which sees validity proofs for the state updates okay so we kind of use this to achieve indirect cross chain communication and the tree transition rules are critical to doing that the only other system that

achieves indirect frustrating communication that's been explored is atomic swaps and atomic swaps the way they work is that both chains commit to some off chain information right and that's essentially the same way we're doing this both chains also in the atomic swap commit to the state update rules which are related but not identical on each chain so these are the state update rules for our indirect restrain communication so on the left side we have what has to be snarky and on the right side we have what has to be verified in the chains consensus process smart contracted so the snark needs to support tagged assets it needs to ensure

that supply is preserved of any given asset across any tree state transition and it needs to support transferring between sub trees so we need to have a full system proof that verifies that it is preserved even when moving a leaf from one sub tree another okay and the chain needs to verify entry and exit into the rollout so when you move ether from aetherium to the rollout the chain needs to verify that and vice versa and it needs to verify that transactions creating the state update are available okay so these are permitted you can move funds from one leaf to another leaf even in another subtree and those are verified by the snark and you

can move things on and off of a subtree but only to its associated chain and that's verified by the main chain just like in zk roll-up but now it's a subset of the system that goes to a single chain rather than the whole system so who makes blocks in the roll-up chain this is kind of an open question but we have a few different models we know how to do this inside chains it's a question of what is most expedient to apply we can have a trusted single operator we can have a bonded single operator we can have bonded Federation's we could even

potentially make an entire block chain that runs the rollout but I'd rather not do that because I don't like deploying new consensus systems so I think it's most likely that we see bonded single operator or bonded Federation and there's some really cool properties of bonding in this system that don't apply to any other system that we can talk about afterwards if we have time okay so let's look at the bonding case really quick we've said that the main chain needs to verify certain things right so what do we need to actually verify what can we slash if the operator is malicious or broken or Byzantine in some

way so double updates to roll-out blocks at the same height as obviously should be slash shovel we don't want that to happen that could partition tezo's onto one history and ether onto another and that's bad unavailability if the etherium chain stops receiving rollout updates but the tezo's chain continues receiving those updates we should be able to slash that in some cases and liveness failure if the whole rollout stops we should be able to slash that okay so double updates are equivocation it's pretty straightforward what that is it's two blocks at the same

height we can actually just burn them down because one validity proof was published on tezo's and one was on aetherium they're both public everyone can see them anyone could submit them to the other chain and we can slash the operator on every chain to valid proofs at the same height can be slashed everywhere because it's public information okay unavailability this is a little complex because it can be available on etherium but not on tezo's so the rollout could be making progress one place but not other places slashing in this case has to assume that eventually the rollout either dies or starts making progress on that chain

again so there's a lot of subtleties here you know we can't punish the operator if tezo's is just congested and the operator can't get a block on the chain so that means we need to have this kind of failure case where a specific subtree is allowed to stop making progress if you can't get a update on - tez OHS you should be able to just hope the tezo subtree as the operator safely and not be slashed this means service degradation for anyone using that subtree but that the rest of this system can continue unaffected we need to allow one update but not two consecutive updates without data availability one

update could be just you know the chains busy and you can't get a transaction right now but two updates in a row without making data available to that subtree is obviously malicious that's the operator withholding blocks okay so we can have localized slashing in this case specifically if tezo's sees two validity proofs that attest to a new tezo subtree in a row without seeing the Associated transactions then the tezo's chain can slash pretty permanently so only one chain is aware of this unavailability but all off chain actors are aware and so the off chain actors

can see whether the operator properly halted the subtree or not and decide whether the tezo's subtree and tezo's rollout namespaced assets are still worth anything well we're gonna skip over this because I worked it into the previous slide but in the case of liveness failure liveness failure is a little complicated like what if the rollout halts altogether we have some ideas in this direction but it's mostly around progressive slashing over time and there's open questions around how does this interact with rotating operators so I've touched on this briefly earlier let's talk about

reasoning about cross train assets roll out should have basically the same asset authentication model as IBC in cosmos which is you know the local chain knows that this is a representation of a remote asset and knows that it came from this communication channel but does not know whether the origin of that message is any good whether the assets worth anything whether their own chain is still progressing all of that is left up to off chain actors to decide so like we can tell where it came from or you know where it says it came from we can tell that it's a representation of something but off chain actors are responsible for figuring out whether it's worth anything

at all octane actors fortunately can tell whether or not the rollout is valid and a really cool property here is that they can sync only the subset of roll-out sub trees that they care about so if I don't care about dots I don't have to sync that sub tree to know whether a tezo's asset on aetherium is valid okay so off chain actors can tell whether the rollouts valid live weather the assets likely to be redeemable on their home native chain and if not they can bail from that asset we're gonna come back to this in a second because it creates a really cool property we have failure modes which we've mostly talked about already

we have local halt so the sub-tree halts some subtree or some like number of sub trees halt we can have a full system halt due to equivocation or due to a liveness failure and this does actually permit inflation but only of represented assets not native assets an inflation will force permanent unavailability on some chain and will be immediately visible to off chain actors so how this is achieved is the operator can accept slashing on tezo's to inflate any tezo's namespaced asset this is any asset that's native to the Tasos chain and they can make an

improper tree state transition when pegging assets into this rollout from tezo's because the tezo's chain is no longer validating their updates because they have accepted that they will be slashed on tezo's so anyone holding tezo's namespaced assets whether it's in the rollout or on another chain loses redeem ability of that asset so there's actually fairly high damage from this but the operator can't monetize the attack and will lose money as a result you can't monetize it because no person will be willing to accept the inflated asset for value so again we're falling back to the authentication model of off chain actors decide what it's worth okay

this creates kind of a cool property is that sub trees fail separately the actual like chance that the system is a whole will fail is fairly low and any individual sub tree failure only affects people holding assets namespaced to that sub tree okay so the big like open question right now is how do we rotate operators we don't want to have a single trusted operator forever and you cannot bond a single operator forever bonds need to have a time duration which implies that we need to rotate at some point my current thinking is that operator rotation needs to be done within the rolap tree because

that's the only way to have global eventual knowledge of the operator update if you do it on a specific chain the other chains can't authenticate that it was done correctly but that leads to the other like cool property if the operator is selected on the sub on the roll-up tree they can also be bonded on the roll-out tree and bonding the operator on the roll-out tree creates this really cool effect which is if you bond the operator on each sub tree and that sub tree halts the operator automatically loses money like it just happens immediately it's not a result of protocol action that

their bond is slashed it's a direct result of them halting the tree that held their bond okay so we have about five ten minutes for questions again this is a very high level system sketch we haven't implemented any of this and it's based on as of yet barely implemented ZK roll-up stuff alright questions I think this system isn't resilient though against underlying chain failure the if tezo's fails the tens of sub-tree fails okay any tezo's namespaced asset is no longer worth anything okay what about an eighth asset that moved into the tezo's namespace also failed so anything that is specifically if tezo's

fails anything that's tezo's namespace fails and anything in the tezo's chain or tezo subtree fails so your eath liability like your eath damage is limited to the amount of etherium ether currently represented within the tezo subtree and the tezo's main chain any ether represented in any other subtree or any other chain will still be redeemable if there's a publicly known vulnerability difference between chains don't I have an incentive to take my assets denominated in the vulnerable

chains and then convert them into the more reliable namespace running away from tasers in two E's for example well you can convert your tessie's you can sell your tessie's for ether but again like we were talking with lucky if the tezo's chain fails or if tezi czar inflated your ether represented tessie's will not be worth anything so you can like get a representation of tessie's on ether but you still can't escape you know the tezi assets value reliance on the tezo's chain this curious if you've thought about

ways of composing us with like shielded pools and a totally pie-in-the-sky future where say the role of chain is using the same proof system as the one with a shielded pool and he could potentially use like a recursive proof instead of doing the kind of like transaction balancing and proof of supply a kind of stuff so I think you can do that like I think that there is a possible future where the rollout chain is like fully recursive and everything snarks all the way down and there's one summery snark first aid update you could even probably make it succinct so that you're catching up on the whole pass validity that is significantly more complex than I could reason about within the last

week or two is there a way to support you TXO change things that don't have native smart contract systems built into them you can always hard work in an application specific like protocol rule that creates these rules as a consensus rule would like a side chain kind of mechanism also work or yes with like a bunch of caveats and engineering difficulties fair enough thanks yeah like given this model walks under the model where like operator supposed to

how very high computation power and in the cases where like you have a time window I guess to submit validity proofs so well like it's like it could like run into cases where like you can't like really generate proofs within that time window because like you're assuming that like operator will be the but will the one like with the a6 and superior hardware like there could be a computation like sort of generating proof that not be possible by say someone what someone like trying to like there needs to be another right well the nice thing here is that uh you never need to make an invalidity proof

the only thing that you as the user of the system would have to do is submit to valid but equivocating proofs that the operator created so if you can show that the operator committed to two different state updates at the same height on different chains which they are required to publish the validity proof that they created in order to do that then they get slash right but you as a user never need to create any sort of snark or zkp that describes the system state at all so that's what I'm saying I'm not concerned about equivocating proofs I am concerned about either the proof itself

it's like the state transition is like there's a state-run gist there's a proof for invalid state transition that someone generated and submitted that proof is verified but like it's not a valid proof like it's not a valid state transition you should not be able to generate a valid zkp of an invalid statement zk peas have soundness as a property right hi I want to ask you whether it makes sense for why do you think this will be

a long-running change instead of which is a referral chain that you know whenever you want to question like a transaction you said you started s up with a ideally a time limit and you know after certain time it has an incentive for the operator to actually you know pull everything out of the system and next time you start again so I mean have yourself about that I think that's really interesting it does kind of found like the scaling benefits of a system like this because you know like one of the cool properties is that roll out should legitimately help any chain it's deployed on process more transactions but having like a bounded period of time

for this roll out chain would solve a lot of like operator rotation and bonding issues well the idea is always if you have a like a way to set a stop I mean you can anybody can can start setting this up and you have multiple parallel operations that's true only to a certain extent like consider aetherium has a block gas limit and can only do a few zero knowledge proof verifications per block so if you have too many ZK roll-ups running with the same change they'll be competing for block space there is an upper limit to how many of these systems can be simultaneously deployed on the same chain without breaking each other one of the big

downsides have roll-up and any like layer 2 system what follower question is how do you handle the asynchronous nature of the withdrawal from the system the asynchronous nature of withdrawal from the system right so I mean you deposit something you say into a system and then you can tassels right and then you took our Tasos but in the whole like how do you handle that right it's kind of really interesting because time in this system is not intuitive because different chains can receive the same state commitments at different wall clock times so there's even cases in which an asset can reach the destination

before it has left the host from the subjective perspective of the host so we don't generally worry about that the zero knowledge that roll out chain is a unified tick for this system across all chains chains might learn that the clock is tickin other chains but it shouldn't matter and again like the goal here is that you can reason about the assets namespace within a specific chain right the goal is that if tezo's halts you should be able to tell and even if tezo's is like five rollout blocks behind we can still tell that it halted and off trained actors can act you know

according to whatever they do when tezo's fails so we leave what to do with asynchrony problems up to the people who are holding the assets involved operator need to send it as I told them not not exactly the operator will get slashed if those transactions exists but are not eventually made available to the chain but they don't exactly need to send main chain transactions to people you