ZK10: Hyperchains and Hyperbridges: How the ZK Stack will power the Internet of Value - Kalman Lajko

Transcript

foreign [Music] [Applause] hey so I'm Carmen lachko I'm from ZK Singh and I would like to talk to you about hyperscaling hyperscaling is a question of how an interconnected ecosystem of Roll-Ups should operate this is basically the same question as execution sharding just in the context of roll-ups so the first topic we should cover is interoperability and this is related to hyper Bridges hyper Bridges allow hyper chains to cheaply and trustlessly interoperate

The crucial part of this process is the message route which is a commitment to all the hyperbridge transactions happening inside a layer 2 ecosystem between different layer 2 Chains and this is the only part of the messages that is sent to L1 and the core message which actually contains all the information about the user's transaction is sent directly from the sending chain to the destination chain and it is there compared against this message route so hyper this allows hyper bridging to both be trustless and cheap and using this process it is possible to

get an ecosystem of interconnected hyper genes hyper Bridges allow General message passing and also assets to be passed from one chain to another so we get a unified liquidity across the whole ecosystem and then in order to ensure unified liquidity layer 1 assets need to be logged inside the shared bridge on layer one so interoperability is the first part of the puzzle but there are more questions such as how to organize a shape chains should you have layer freeze fractal scaling proofregregation and that's more that's the harder part now let's look at those so the first solution is proof aggregation with proof aggregation what

happens is that multiple blocks of a simple Hardware chain are first aggregated across time and then these proofs of different chains are aggregated and settled on layer one together now settlement on layer one is relatively expensive so in order to minimize fees it makes sense to settle less often but this is bad for hyper bridging because hyper bridging is only possible once settlement on layer 1 happens so for fast messaging this is not an ideal solution so to fix this we can have layer freeze and layer freeze can settle on a layer two and because it's a layer 2 settlement is much cheaper there and

this is basically the same hyper bridging process as we saw before but because it's happening on a layer 2 it can happen much more often and so bridging is much faster now if we look at more detail at what actually happens here is that the blocks and the proofs of different hyper chains are first aggregated across multiple chains and then the proofs of the layer 2 are aggregated across time so in a sense we are flipping the order of aggregation first of course chains and then across time however layer 3s still have some problem there are two main problems the first is scalability the layer 2 has a virtual

machine which cannot handle and arbitrarily literally large throughput and the second is that the layer 2 has a consensus mechanism which secures the layer 2 itself and this layer 2 might revert this consensus mechanism might revert and this will cause the layer freeze to revert as well uh so in order to solve this we need to solve scalability and this middleman problem that the layer 2 causes first for scalability we can just remove the layer 2's virtual machine and if we remove the layer to this virtual machine we can have a specialized proof there instead then we can have a scalable and solution that

is still good for fast messaging and this specialized proof would still have a message route so a hyperbridge transactions could be verified from there and this message route can be also imported back later there when the layer 3 settle on the specialized proof but we still have this metal man problem because the specialized proof will still have a consensus mechanism this is the aggregation layer in a sense so let's look at the consensus mechanism that this specialized proof requires it only needs a minimal consensus mechanism because it does not aggregate process user transactions it only processes

hyper chain proofs this means that finality can be much slower it also does not have uh storage requirements and it has minimal State because it only stores commitments to the hyper chains States this means that it has minimal data publishing and storage needs in conclusion this basically means that light clients are full nodes similar to data availability lifelines can contribute to this consensus mechanisms security okay so this hasn't solved the middleman problem yet but let's look at how layer 1 solves this metal man problem So currently layer 1 is the most

decentralized chain and we have a small number of Roll-Ups settling onto it so it is Unthinkable that the layer 1 would have major reorgs but in the future if you if the whole ecosystem is processing a hundred thousand TPS and we have a thousand roll ups then the total stake in all of the layer twos together might be bigger than the stake in the layer one to solve this we can use restaking all of the stake can be logged in layer one consensus mechanism and restate to be used in other consensus mechanisms and validators can be run for the layer 1 and the layer 2 consensus mechanism in parallel

this makes the layer one very secure as the stake securing the total ecosystem will be approximately equal to the stake securing layer 1. so this is how to solve the middle line problem and we can use the same solution for in the context of proof aggregation as well we have the proof aggregation layer with a specialized proof and we have the hyper chains the hyper chains have the traditional consensus mechanisms and the specialized proof only as the minimal consensus mechanism which can be uh verified by like science the hypertens are basically lifelines of the proof aggregation layer as they are using the

message route from there to use for their own messaging purposes and they also settle the message route inside the proof aggregation layer because it needs to be settled there so we can actually measure the acceptance of the specialized proofs consensus mechanism by measuring the message routes that are settled inside the proof aggregator so using this solution it is possible to solve the middleman problem and now we can have an ecosystem that has fast messaging that is scalable because it uses proof aggregation and it is also secure

because the stake is distributed in a manner such that the proof aggregator the stake is approximately equal to all the stake inside the ecosystem so finally I would like to cover one last topic which is cross hyper chain forced transactions this will be very important in the future because if we have a hundred thousand DPS then censorship resistance from the L1 will be very expensive because the layer 1 will only be able to process a certain number of transactions so it's very important to have Force transactions going from one hyper

chain to another and this would be through a similar process as normal hyper Bridges expect it wouldn't be a relayer that sends a transaction from one hyper chain to another it would be sent to the data availability layer and from here the receiving hyper chain could import it and uh to make sure that it is in indeed imported and executed the send message route and the received message route would have to be compared inside the proof aggregation layer now this is just an approximation Because the actual construction is much more complicated because different hyper

chains might settle at different moments but this is the main idea so using this construction we can have fast messaging we can also have scalability security and censorship persistence in the whole ecosystem thank you very much and if there's time for questions we have a few minutes for questions Round of Applause first okay these are lightning talks so we they're lightning questions also so any fast questions okay

really high level I mean we have a few of these like stack kind of projects like op stack or even Madara on starknet are how are you how does this come just fundamentally high level how is this so different or in terms of what we can do here versus all this other stuff so I would love to answer your question the problem is that most of these Stacks haven't really specified of what their Solutions will look like so as you mentioned Madera is just a as I understand the sequencer for layer freeze it's not the core part of the stalker never specified how their proof aggregation system will look like neither that polygon I can address

optimistic Solutions because for optimistic Roll-Ups it's much harder to have interoperability so every solution that uses ZK proofs will have much better interoperability than optimistic chains I think for us our biggest Advantage is our great proof system because I think our proof system and our VM implementation requires the least amount of ram GPU Ram to run so this means that the proofs can be generated in a decentralized manner which makes the whole ecosystem much more decentralized decentralized compared to other Solutions

okay we have one more question this might be a stupid question um I know that this architecture is trying to solve like the fragmentation of liquidity but are you also solving the fragmentation of like app deployments or infrastructure across these different environments like does a hyper chain one hyper chain two like those all have to integrate with fire Blocks individually or do Frameworks appear so that you kind of have this like shared uh like framework where they can all interoperate yeah so all of the chains should have the same API calls but if you want to deploy an account on a chain you will have to

deploy it on that chain specifically and there will be ways of natively so we will have methods of the concept of the same account of multiple chains so I think that will definitely help a lot but each chain will be its own chain basically thank you very much foreign