Layer 2 Stage | From Nightshade to Starsight: The Evolution of NEAR Protocol Design

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:00

   for the first talk this afternoon we're going to have Bowen Wang from pagot who's going to be talking about the evolution of near protocol design so coming to you from San Francisco please welcome Bowen hey how's AR doing good cool um so uh as we introduce and Bowen from pakoda and today I want to talk about uh the evolution of the near protocol in the past several years and um where we're heading towards

2. 0:35

   next uh it be ideal if this works okay um so as you probably have heard of uh we started with n shade and this is the white paper that we published in 2019 and uh it details a design for completely shed blockchain uh so both transaction processing and state are fully shorted which at the time uh was not something that people people take for granted uh and one of the key Innovations of night sh is that it only

3. 1:04

   maintains one chain uh each sh does not maintain its own separate uh sh chain and this allows us to get around some of the very difficult problem uh like the atomist fail of cross chain transactions and another key feature of n shade is that the um execution is entirely asynchronous um no matter whether two contracts live on the same Shard or they live on different shards if you want to do a cross contract call between those two contracts uh the execution is always going to be

4. 1:35

   asynchronous and the security of n shade relies on fraud proofs so the assumption is that uh there is at least one on fisherman tracking uh Every Single Shard so that even if entire Shard is corrupted uh meaning that's controlled by uh malicious validators uh it is possible for the system to recover because fishermen can submit a fraud proof so that once the uh fraud proof is verified uh the state will roll back

5. 2:03

   so despite all the Innovations and simplifications in design ni shade is still a very complex protocol to implement uh so Alex and I came up with this four-phase approach to to actually get to ni shade uh in Phase zero we launch mainnet uh with with one Shard even though uh the all the code is written for uh many different shs and in phase one uh which we launched last year we introduced chunk only producers which adds some shy processing to the network

6. 2:33

   and according to the road map the next stage would be full n shade essentially implements with the original white paper um envisioned and it is a system where no validator would have to track our Shard so the entire system is fully shorted and after that uh the plan was to have this enhancement where the system would dynamically uh adjust based on the load it would change uh increase number of shards when there more load

7. 2:58

   and the decrease number of Shard when there SL load on the network so in the past several years of developing and evolving the road map uh what we realize is that um nade is a very elegant design but in practice there's just a big problem which is U fraud proofs so not only fraud proofs are quite difficult to implement um because essentially you need to have a way to uh stly verify that uh the invol state transation has happened um but

8. 3:29

   also so uh it is actually quite dramatic change to the network because when fraud proofs are verified we not only need to roll back the state of one sh but actually the state of state of all shards need to be rolled back simultaneously uh this is because otherwise someone can corrupt one Shard means 1 billion tokens send to another Shard and even if you roll back still with that Shard at the moment uh it doesn't solve the problem because the 1 billion uh token that are invad minted

9. 3:54

   already Live on another Shard so the state of all shards have to be rolled back at the same time and this can actually happen any time right it can happen when the epoch switch when the valet change when there's rearing or like when there's congestion on the network and there's like lot of corner cases to be accounted for and what makes things worse is that this mechanism is almost never expected to be triggering practice because as far as I'm concerned

10. 4:19

    uh there there has been no uh attack in the proof of stake War where an invis state transation has actually happened on the network due to malicious activities and um this makes it very difficult to test that this mechanism works correctly and the problem is that if this mechanism does does not work correctly it can actually accidentally slash people uh due to bugs under normal operation and that uh is actually quite

11. 4:44

    uh difficult to deal with so we ask ourselves the question is there an alternative and um there is so that's where status validation comes in so this is a different design where the system has two type of validator uh there is status validators who essentially receive the uh the chunks and also the state witness that are required to be able to verify the execution of those chunks and there is a separate set of

12. 5:15

    validators called trunk proposers uh essentially they're responsible for producing the trunks keeping track of the state locally produce State witness and distribute them to the rest of the network so the obvious question is like well how does this help uh so basically there are two important things with stus validation uh one is that um when you sample a uh subset of validators for A Single Shard from the

13. 5:39

    entire validator set um if there are a lot of validators the probability of A Shard getting corrupted can be made extremely small and the probability a sh getting corrupted meaning that uh it's controlled by majority of malicious validators and also the validator will actually shuffled on every single prod so essentially the rotation happens on every single block and because of that there is no way to adapt or corrupt the validators for given shart because um

14. 6:06

    you don't actually know who are The validators Who Going to validate for the next block because the shuffling actually relies on the randomness Beacon that you cannot bias and as a result the system is um probabilistically secure and with extremely high probability uh so roughly in practice means something like on the order of once every thousand years or once every 2,000 years the valida rotation of the fail and so in practice that can be considered secure and this allow us to essentially get rid of the

15. 6:37

    fraud proofs that that is U the most difficult thing to implement in the nitrate design but that's not the only major benefit there are actually at least two other major benefits of the status validation design uh so one of them is that the cost of operating a validator is going to go down significantly because they don't actually need to track the state of sh locally and as a result they can operate much cheaper hardware and because of

16. 7:01

    that uh it potentially leads to more decentralization and more Val D draining the system uh another thing is that because only a few validators in the system needs to operate more expensive Hardware we can actually make it such that the state of the uh A Shard can be entirely held in memory and this would improve the the speed the performance of single sh dramatically because today we know that uh performance Bon that is mostly on state read and right and those

17. 7:26

    validators don't even need to operate super expensive Hardware either and this is because we're charting so we can essentially say that the uh state of each Single Shard is limited to say 50 GB and if you do that then ideally it should be able to fit into a 64 GB Ram machine uh which isn't really that expensive either so the team has already begun working on this new design a few months ago uh and we expect the engineering work to finish by the end of this year uh and actually release to Main that in

18. 7:59

    q1 2024 so it is worth highlighting that this design or like what we're implementing now actually completes the phase two of charting go where uh no vators need to track all shards uh despite it being a different design it does achieve what the uh the vision of the night shaped paper um says and we plan to have more optimizations in the future uh things like reducing the size of C witness uh improve network communication uh improve the reward structure and so on so forth

19. 8:30

    so in our pursuit of Excellence we never fail to ask ourselves a question of whether we can do better uh and in the status validation design um there is a essentially a different uh difficult problem which is that um the state witness uh it actually consists of the state touch during the execution alongside with some mirle proof that the the state actually belong to the correct

20. 8:52

    State as dictated by the state route um and uh the size of the state witness could be a concern especially when the network is under high load so that stay touch during the exclusion could be a lot and we're asking ourselves the question well is there a way we can get around that problem or at least uh mitigate it that's where saride comes in and before I talk about what starside actually is I want to take a quick

21. 9:18

    detour and talk about zero knowledge proofs uh one of the hottest Topic in blockchain today um I won't actually go into too much detail on how exactly zero knowledge Pro Works um only give a high level overview of what it can do and what can enable so essentially for an arbitrary computation P you can generate a zero knowledge proof to prove that the computation is down correctly and the proof is succinct meaning that the

22. 9:43

    verification time is poly logarithmic in the computation itself and depending on the construction it can also be constant time uh so meaning the verification is extremely fast um and also it hides input so that um the verifier doesn't necessarily need to know the input to the computation so for the for this presentation we'll mostly uh focus on the part that uh uh the succinctness

23. 10:07

    part meaning that the ver verification is extremely cheap um and because of those properties uh there not prove g r a lot of interesting possibilities uh they're very small very cheap to verify and verification of the proof is highly paralyzable because uh verification of each Pro is status you just verify the proof itself and you can verify like 10 proves at the same same time

24. 10:30

    and why is this important so if we think about uh what blockchains do one of the most important thing blockchains do is that they reach consensus on what the state is uh no matter where the blockchain is started um it's one of its main task is to actually agree on the state and today uh most blockchains do that um by verifying the computation uh so what that means is that let's say some nodee does computation let's say it produces Brock uh it does a computation

25. 10:57

    and it gets a new state rout and all the other nodes in the network um assuming let's say there's one Shard then all the other nodes in the network needs to redo the same computation to verify that computation is done correctly and that is actually a lot of overhead um so let's say you have 100 100 vat and essentially there like 100x computation overhead uh and thege proof actually

26. 11:20

    breaks away from that kind of Paradigm uh and it only adds a little bit of overhead because each verification is extremely cheap uh so on top of the original computation being down the overall uh overhead is quite minimal uh if we exclude um the proof generation time so what does this proof actually do so roughly it states that um there exist some chunk whose execution leads to the new State Route um and this proof has three parts uh the first part is that

27. 11:53

    this proof that uh shows that there exists some chunk that would has to the to the the given hash so the the the given hash is um a public input to the comput to the Z knowledge proof so basically both um prover and verifier knows about it and also has a pro that proves that the state used during the execution is correct meaning that it belongs to the uh correct status dictated by some State Route and finally it has this um most complex part that shows the uh the roundtime execution is

28. 12:23

    correct um and this essentially is a circuit that encodes entire uh near R time logic um so it's not not only just things like um transaction execution um of transfers and or like simple things like this but also includes a smart contract execution and because near use web assembly is a wrong time um it also proves to have assembly execution is part of this proof and um as you have

29. 12:49

    probably have heard yesterday this is the theam initiative that we're working on with the polygon team so despite all the magical properties of zero knowledge proof uh they're not without problems so one of the biggest problem with zero knowledge proof today is that um proof generation is quite slow uh so the most performance uh DK system today has a slow down factor of roughly 10,000x uh

30. 13:17

    meaning that it takes 10,000x uh more time to generate the proof compared to the native execution itself uh and that number is going down uh pretty dramatically over the past several years and we do expect that number to go down dramatically over the next several years as well due to Innovations both on the proving system and on the engineering side uh however there's still a problem

31. 13:40

    let's say the overhead gets uh down to 100x meaning that the proof generation time is 100x execution time we still cannot integrate into the protocol as is and that is because near is designed to have fast finality very low block time and and blocks produced very fast it's not designed for this um system where there is 100 act overhead between consensus and execution that is what motivated us to design staright uh a zentric sharting

32. 14:13

    model so roughly what this says is that uh consensus would run separately from execution and only agrees on the transaction to be included in Brock and the people who execute uh the Brock the trunks uh let's say we still call them trunk propos users um they would execute the the chunks and generate the proof for um the state transition and once the proof generation is complete um the proof would get committed back into the blockchain and get validated through consensus and those proes ATT test um to

33. 14:45

    boast the the new state rout as claimed by the trunk proposers as well as the new uh outgoing State rout uh so that there can be cross sh communication um and with techniques like proof compression or proof recursion this design can actually scale to quite a large number of shards even if we just put the proof directly in the block uh so in terms of scalability uh we see that uh star side is as good as

34. 15:10

    night shade so this is kind of an illustration of uh what I mean by consensus running separately from execution uh so as you can see uh this is showing the execution of one chart uh it's not necessarily the case that there is a new state root update after every single block it could be that um um whoever does the execution um execute several blocks together because it's run always running behind

35. 15:34

    consensus so it always has something to execute at some point once it generates the D knowledge Pro it will commit the Z knowledge Pro back into the uh the consens the the blockchain so the there are two major advantage of the staright design one is that the design is extremely simple um except the vck part so there's no validated rotation there's no fraud proof or state act that's that is one of

36. 16:00

    the main difficulty in the nitrate design and because the new state rout are essentially automically committed back to the blockchain meaning that they are either immediately accepted through consensus because all the validators would valid do not approv or they're immediately rejected as invalid uh this is this simplifies a lot of the design challenges we had uh in nitrate or um similarly in the stus validation design

37. 16:23

    and the design is also very versatile it doesn't dictate how the chunk proposers should package transactions um they can potentially even be shared across multiple different shards and so on so forth and more importantly doesn't really dictate what how the wrong time should actually work for each chart as long as Z knowledge proof can be generated for the state transition and this gave rise to a lot of interesting possibilities so for

38. 16:46

    example we can have multiple execution environment within the same network potentially we can have wasum evm move or some other custom virtual machines and it's also possible to conceive a future with we we have both synchronous execution and asynchronous execution within the same network so for example we can have wasm execution environment similar to what n has today with async

39. 17:08

    execution and evm with synchronous execution so this is kind of a comparison between nitrate and staright um and in um in terms of SEC security nitade relies on system having on a fisherman and star side does not rely on any additional security um other than the B uh bft assumption and they both have very high skillability and star side has much higher decentralization Factor because verifying the state transition is extremely cheap can even do that in the browser uh and even though star side

40. 17:42

    somewhat sacrifice onchain finality as we seeing in practics that's not that big of concern because uh the rpcs can actually as long as they have the transactions they can execute them and provide this kind of optimistic State finality and for people who want more uh kind of of security from the chain itself uh they can get it when the zerge proof is committed back to chain and assuming on 100x slow down factor is

41. 18:06

    like 1 to 2 minute delay which um in the grand scheme of ss uh is considered to be acceptable and uh in terms of execution environment today the NIT design relies on web assembly and in store side is pretty much any execution environment that can be proved uh in the king so in um in s the Manet launch in 2020 we've had 34 protocol upgrades and uh we're constantly searching for uh ways to improve the protocol exploring

42. 18:38

    different frontiers of the blockchain research and try to improve the usability scalability and decentralization of the near protocol and star side is just one of those effort to explore uh the next stage of evolution for the near protocol and we are working on a white paper that uh documents the details of the star side design I hope to publish that that somewhere in early 2024 so stay tuned for that and that's it

43. 19:16

    thanks