Whiteboard Series with NEAR | Ep: 35 Ben Jones from Optimism

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

1. 0:03

   hi everyone this is Alex from near with me today is Ben Jones from optimism hi Ben everyone yeah very good and today we're going to be talking about optimistic roll-ups Ben was previously on whiteboard sessions maybe a year ago we were talking about plasma cash flow and which was another layer to solution but since then optimistic roll-up started a starting started getting popular so let's talk about them so Ben would you like to I guess introduce yourself again in case people

2. 0:41

   didn't watch the previous episode and talk a little bit about what optimistic roll-up are what the what problems they're trying to solve and how they work sure thing sure thing and that's right yes I am here back to back I guess now back at the near whiteboard talking about more stuff yeah so I'm Ben I work at a team called optimism and we're building a product called optimistic aetherium and it's a

3. 1:05

   scaling solution that like Alex said uses at its backbone a tech called optimistic roll-up and the goal is to scale aetherium and particularly our goal is to scale aetherium smart contracts so Alex when we were when we were last chat chatting on the on the you know near channel we were talking about something related to plasma and plasma was a really cool really awesome technology but it didn't have the properties that we wanted to get true

4. 1:35

   like aetherium style rich state sort of persistent adapts and so that is what optimistic roll-up sort of gives us very uniquely and so it is a layer to scaling solution this means that it makes an assumption that in the happy case a lot of things won't have to go on chain and then only in the sad case do they have to go on chain and so that allows you to scale up in the number of disputes and this gives you some scale cool lets Naveen

5. 2:08

   sweet okay so where would you like me to start in terms of framing like I could go way back and talk about layered like optimistic execution I could talk about like you know a bit of history of plasma I could dive in this particular solution trying to think of what is the best route to take us yeah definitely let's talk about opportunistic execution in general and yeah sure okay so you know

6. 2:37

   we have a class of technologies right let me let me just like start using this this lovely whiteboard here because I got to get I got to get some practice or my handwriting is gonna be horrible so we have this thing called layer 2 right what a weird way to write layer 2 layer 2 refers to a suite of designs and applications that you know arguably started with payment channels even not as early as Bitcoin and they utilize

7. 3:08

   something called optimistic execution this is one way to frame what they do right so let's just let's just write that of course I am biased towards this particular choice of words since I work at a company with an M at the end of optimist so you know I like this word a lot but like what is optimistic execution right well we have this this blockchain thing right we'll assume the

8. 3:35

   readers are familiar with that and the idea is you know these these black chains have it limited throughput right so you know if we have some chain you know argue with me about whether I'm pointing my arrow is the right way right there's this thing at the end of the day this this consensus system is still a computer and you know this from this state machine you know and it's replicated and the way that we replicate

9. 3:59

   it and achieve a consensus on it right basically like restricts us so you know we we can't like just like pump infinite things into this blockchain right it won't work so what do we do in the naive model of black chains we can think of the blockchain as like a ledger you know accounts or whatever we want to call it right so this is this is one model to think of a blockchain and so

10. 4:31

    you do your payment's and you put them on the ledger and it updates who has what based on how much you know Alice is ping Bob or whatever so optimistic execution is the idea that unfortunately this ledger is very limited so instead of making it a ledger of accounts what if we could make it a ledger of disputes and really you might you might even say settlement in a general case but it's interesting to think of this as just disputes so the idea is you know perhaps instead of Alice paying Bob five dollars

11. 5:08

    by submitting a transaction to the ledger of accounts and saying hey decrease my account by five dollars increase Bob's account by five dollars maybe there's a scheme in which Alice can just simply say here's a little update and here's what Alice has now and here's what bob has now and you don't have to actually check me on this but if anyone disagrees then they can trigger an event and check it and so you know this is an efficiency boost that allows you to pump more transactions through

12. 5:38

    the consensus right and one way to think about it is you don't go to court to cash a check right in the real world you go to court if the check bounces and so we want the ability to cash a bunch of checks in a way that doesn't go through the ledger of accounts and we use this court system that this strong property of trust that black chains provide only when there's some sort of problem a

13. 6:02

    dispute so does that make sense that sort of optimistic execution you know maybe at a high level yep that makes sense cool cool okay so I guess the next thing to talk about it would be to talk about maybe some specific examples of options to execution schemes and I'll talk about quickly I'll talk about them very briefly okay cool so one of them is called the State Channel as I mentioned

14. 6:30

    this is one of the earliest ones and in a state channel Alice and Bob commit some money into an escrow and they sign off chained messages so so you know it's hard yeah it's hard to figure out the best way to draw this but Alice and Bob are going to submit some money into an escrow right so there's Alice there's Bob right they put some money into an escrow there we go there's some money symbol uh-huh and then they do some off chain actions and basically basically what happens is

15. 7:11

    that's what occurs on Shane can you see that by the way did I just move it for you I'm moving I'm moving up through so I'm trying were you dropped fantastic oh thanks thanks so much so let's say that Alice and Bob put some money into an escrow right this is sort of the part that occurs on Shane and then we can do some things that are off chain right so if we say off chain over here so off chain basically Alice and Bob can do

16. 7:43

    these cryptographic io u--'s right they send back and forth some io u--'s right Alice says okay I'm gonna pay you a dollar now and then Bob says okay I'll pay you three dollars at a different time right and so on and so forth and the property is that even if there's a lot of iU I'll use pass back and forth at most even if there's a large number of these only one of them ever has to go

17. 8:12

    back into the escrow contract right so here let's do I love colors so let's try to get some colors in here only one right so in a state channel this ESCO contract only needs the most recent two sort of IOU state right the most recent set of affairs to be able to resolve how much money at a later point in time Alice and Bob get out right and so hence we have done some scaling right because

18. 8:42

    Alice and Bob transacted several times and the ledger did not make an update on the order of the number of those transactions it made enough on the order of you know to a deposit and a withdrawal right so that's how we get scaling and I think this is at state channels are a great example of why things like transactions per second right our little misleading in the in the crypto sphere I would say like one

19. 9:06

    of the most overused words and all of crypto is transactions per second and it's really not that meaningful because right here in a system that was designed for Bitcoin right forget all these other crazy scaling solutions with just you know small little four mega byte blocks we can theoretically do an infinite number of transactions per second right like Alice and Bob's ability to pass these io u--'s back and forth is only bounded by you know things like their

20. 9:30

    computational power and network latency but they can just send one sent transactions back and forth all day long right it wouldn't be a very meaningful scaling solution but it would be very high number of transactions per second right yeah yeah that's right also we have a very good episode episode 13 where we dive very deeply into in the channels in the payment channels yeah nice nice nice yep so payment channels

21. 9:54

    are so really cool and if you even get a little crazy you know you don't have to just do a payment on this channel you can do things like playing a chess game or some you know turn-based application or a poker game things of that nature so unfortunately the problem with payment channels is that Alice and this escrow contract right where Alice and Bob put money into right was only al it was only

22. 10:25

    Alice and Bob putting money into this X escrow and so like this participant set is limited right only Alice and Bob can trust in the payments that they're making in this channel right yeah so what we really like in the etherium world is this crazy ability to have these money Legos right where we could deploy all of these crazy smart contracts and they can talk to each other in weird ways and do crazy awesome things right and the problem with this

23. 10:58

    is that the set of features that you can do with such a limited participant that is you know similarly limited right so for example an auction you know doesn't really work with a payment channel right not at least in the same with the same properties that a l1 auction would have so like auction it doesn't really work right it doesn't really work with it with a peanut channel so we need something more so optimistic roll-up right is a scaling

24. 11:31

    solution that allows you to scale up in the you know in the number of disputes not in the number of in the amount of computation and it allows you to do so with pretty much identical properties to aetherium itself and so that's what's super exciting about it and particularly the property is that the data availability so let's let's just let's just make it quick a quick thing here oh are you the data availability right

25. 12:02

    so the the you know maybe a so data availability is like I think you know occasionally and overused words I guess what I would say is like transaction size you know transaction data size right this is limited by l1 mm-hmm and what basically the reason for that is that to send a transaction into into roll-up right and get it finalized you send it to l1 just like you would any other transaction the difference is that TX computation size is not right so this

26. 12:45

    is uh nathie reom your gas not you know limited and so this is the property that optimistic roll-up has and yeah I mean we can we can you know sketch out a very very naive sort of optimistic roll-up chain maybe as a starting point so let's scroll up okay so here's like the simplest possible possible way like you know like you know MV oru Minimum Viable or you and in fact this I will hide a particular detail here which involves a sort of the stateless execution nature

27. 13:24

    so there's stateless clients and you get a lot of performance benefits by doing that but actually the the minimum sort of viable version of this and all described here was actually I think we can lend credit to but Alec in 2014 he called this a shadow chain which is a you know honestly in some ways a cooler name then then or are you I cut it I kind of dig shadow chain but I also like are you especially since optimism is the name of my my team okay so here's a simple optimistic roll-up

28. 13:58

    contractor shadow chain right so let's define a data structure which is called the transition okay and a transition is a is a tuple of TX and a state right so a transition is a transitions a tuple of TX and state now the simplest way to have a roll-up chain is you have a array of transitions and anyone can call propose new trend this is you know extremely simplified but it'll get the

29. 14:44

    basic idea across propose new transition right and this will you know obviously accept a you know TX state right it'll accept this transition object right and this will and this will append to a so this will append to a list of transitions right so I'll I'll called T 0 it kind of sounds like time but we'll say how about TR 0 transition 0 transition 1 transition to but this has a problem right if I proposed a transition and while my transition is

30. 15:23

    being proposed someone else proposes transition my state will be incorrect right that is correct yeah that's a totally good point so this is like very very naive implementation so you're absolutely right in the scenario in which anybody can call propose new transition this would be a very unfortunate roll up scheme because you would have this race condition and you would probably end up with the property

31. 15:46

    that like only one person would be able to sort of make a valid thing you know admission proposal per block and it would just happen to be the the you know the person who paid the most gas right the person who wins the prior to gas auction so you're absolutely right so one simple way to remedy that is to imagine that a single party is allowed to propose these new transitions right and that would be a simple way to resolve this that single party knows do you know the exact ordering and the

32. 16:18

    states that are coming down and they can propose it right of course that would have a problem that would have that person went offline right and then and then that person would disappear so a better way to so a better way to do things you know I mean well maybe maybe just to finish this this analogy very quickly right there would be one other function here which would be prove fraud

33. 16:43

    right and this function would take in and index right and it would you know step one of proving fraud would be check you know very so we have a we have a state transition function that also hasn't defined here but you know execute TX is what we'll call that state transition function right execute TX which takes in a TX and the state and it outputs a new state right so what the last thing to do

34. 17:24

    after we've started putting you know this this array of transitions on chain is would be to prove that a transition is fraudulent right so how would you do that you would check that you know for index I right okay let's just let's just use I for the simplicity of writing so you would check that TR I minus one oh sorry actually let me rewrite that so we would prove that I'll scroll down a little bit nice so the first thing that you would do right is you would take the state at

35. 18:00

    the previous index right and you would apply the the IEEE transaction to it and see if you got the correct output right so here's what we would do we would say we would say check that execute TX of T our I minus 1 dot state comma T our I dot T X is not equal to TR I dot state right so there would be the basis of a frog proof you'd say hey this person lied they put down a a transition and they said if you apply this TX to the head

36. 18:48

    state then you will get this new head state right and so we can prove that this is not the case right and maybe we'll even maybe even we'll go we'll get a little color color get up in here oh yeah oh yeah there now we're talking now we're using we're going digital okay and then and then the second thing that you do right would be step two you know delete you know delete transition I

37. 19:18

    threw you know the end of you know you know the max delete the rest of them right okay so that's a super super super simple optimistic roller chain right so so I guess one problem here is that with every transaction we have to submit the whole state right which is going to on this exactly right exactly right exactly right so that that is that is definitely the case is that this state is going to

38. 19:45

    get very very big over time and and notably right notably the the array of transitions that we're storing here is being stored on chain and so if we said that would be like storing instead of the difference in this you know we maybe you could improve by storing the difference in the state right but you're still storing them in the night this super naive imitation the entire state

39. 20:07

    right and so that's totally right that's a no-go but it would fail because the a storage costs are vastly vastly vastly you know greater yeah absolutely right and so as we as we optimizing so so it so one thing is to remove the state from the from the chain data right I'm sorry from the from the etherium state is also is they're also go to remove transactions from the from the from the

40. 20:31

    state there is a that is correct and actually that is where the term roll-up comes from so which actually came from ZK roll-up so you do there there are basically two things you you what you end up with is a hash of the transaction and a hash of the the state and in fact and in fact of course you can do it as an accumulator so it doesn't have to be you know a linear number of hashes you can have it be a logarithmic you know on chain accumulator mm-hmm awesome and that's

41. 21:03

    exactly right and so the way that like the way that we get rid of so maybe maybe just to note this so I'll keep going down here I'm whoops oh man color-changing stuff there we go so like yeah like you know so like to remove the you know TX size right what we do is we store hash of the transactions right instead of storing the instead of storing the transactions themselves and of course the and this this sort of hashing process right really in fact is what happens it's a large number of

42. 21:46

    transactions are submitted all at once and you store a miracle root of them because you might you might have 100 transactions but you only need one particular transaction that where things were fraudulent so you store Merkle groups and this is colloquially known as roll-up right and so this is what's done on CK roll-up this is what's done in optimistic grow up and the idea is that

43. 22:09

    even though we only store the hash of the transaction on chain it only the hashes in the state within the chain history is the entire transaction right because anyone who wants to come to the chain later on and verify needs to be able to get this transaction in the first place to verify that the hash is correct right otherwise it wouldn't know if the the if it should reject the block or not and so even though we've removed

44. 22:34

    the transaction from the state it is still there in the history all the full nodes had it and the source worth mentioning right that the the price to store something in the history over theorem is we we cheaper them right exactly right exactly right all data is is way way way cheaper and and the the ending to and a further intuition that's kind of nice there in general sometimes people hear roll-ups and they think and they they hear oh well you still have to put the transaction data on chain that

45. 23:07

    doesn't sound scalable to me right there's sort of two reasons to think that that's scalable one is exactly what you said is that it's much cheaper to store a piece of data in the chains history than it is to store it in the actual head state of the machine the other reason is that Moore's Law has continued following bandwidth where it's beginning to drop on execution so this is a this is actually what's nice on computation rather so this is kind of a nice

46. 23:33

    property is that it seems like Moore's law is continuing for bandwidth which is the only cost factor that goes into the this this property you know the cost whereas execution is falling off so we keep the execution off chain but we keep the bandwidth on chain we can keep following Moore's law right all right and so here so let me quickly I don't know if you were going to talk about it

47. 23:57

    next but I'm trying to see how these signatures of this methods will change once we do not have the entire list of transitions right but rather they have hashes so if I'm proposing new transition my transitional contains the immortal route of the states right that will be the result of applying the transaction right that is correct that is correct and so therefore there are proof fraud will have to contain the states themselves right so that we we can actually apply the transactions well

48. 24:31

    or I guess a subset of state which is sufficient with the witness right exactly right a subset with the witness and one thing one important note there is is that concept people often when people are learning about that concept there's a point a moment time which is that concept really clicks which is that this is very very similar to what's called the stateless client in aetherium and maybe a little bit more broadly in crypto now right so the stateless client is the idea that nodes don't store any

49. 25:03

    of the change state even of l1 other than an accumulation of it and when you apply a transaction you provide a witness to any parts of the state that you're accessing mm-hmm okay so I'm drawing a little go ahead the only other thing I would say it's funny enough in Bitcoin this has been called you tree EXO and it's it works almost the exact same way but for bitcoins ug EXO model

50. 25:27

    yeah I see okay so I'm doing at the bottom right so that they have the full understanding so assuming I can submit at least a set of transactions right so now my method what was it called above let me see it was called XCX proposed right yeah yeah yeah proposed okay so so so now my proposed will take a effectively a list of transactions right and the statute that I at the time that I claim will become the rule will be the route of the

51. 26:02

    of the state after applying these transactions right so internally internally this method will compute will in into the list of the transitions right it will append the a lot of house of transactions right maybe more color it may be something else you can and the state route I guess it's a it's a tuple yeah and so effectively so no transactions well I'm not I'm not that that that familiar with the theorem but my understanding that just by calling this method the transactions already in the history right because this some sort

52. 26:44

    of a cold data right exactly right it's in the correlator but only but only the half of the transactions ends up in the in the state right exam and and so this part that maybe change a color now and so the the part that is blue that can also be optimized to contain just the just a sort of accumulator so that on itself can be some sort of work exactly right mmm-hmm I see so so so the state that were surprised very little and so now

53. 27:13

    the method that is proof fraud yeah now it takes index but it also takes now so in the knife way that would be stayed before right yes state after we don't really need because we will get the state after and we can hash it and so from here so that is already sufficient well it's not quite sufficient also need the transaction itself right and because we only have the hash of them that's

54. 27:45

    greater submit index TX and the state route and so that on itself should already be sufficient well we also need some sort of witness that proves that the action corresponds to this half of transactions right that's right that's right you know we need some because that prove that and and if this is the accumulator and then you also need some witness that proves that so yeah so some number sufficient witnesses to show the

55. 28:08

    transaction case comes with the cash and so the next optimization is that if we have let's see so for example if this is the state right and so let's say my transaction read from disk several places yeah and then it wrote to these couple places right then I'm not submitting the entire state I'm submitting these parts of state that I changed right exactly and and more two proofs that they correspond to the states would write exactly and and so that would be or rather what I wanna be

56. 28:49

    submitting it for the data if it's right but for the data right they still need to provide moral witness so that they can see so they can recompute the the updated cash right that's right yeah exactly cool okay so so how far are we from from like having not that minimum viable optimistic roll-up with all this oh we're pretty close we're pretty close so I mean we we did a we did a the first

57. 29:14

    public demo of roll-up Caldwell optimistic roll-up called unipeg we did that at Def Con last year there's a very separate conversation to be had about what it takes to build so there's like a big there's a big separate question here which is this this function executes TX right what does it look like because to really take advantage of this solution the applications built on top of it have to fit within this execute TX function

58. 29:47

    right and so you know in our case where we're building this as a layer on top of a cerium it becomes a very interesting problem well how do you design and execute TX function that is like application developer friendly right because the cool thing about this system is that because you know you basically have three properties right one property is that you have the avail an available head state right and

59. 30:12

    the reason for this is because all of the transaction data is available for in the chain history and so anyone who wants to can compute the head state from the available transaction data we have another nice property which is which is that that it is live at least you know as live as the l1 and we have a property that it's valid because we know that we can go and submit fraud if it's invalid

60. 30:38

    and correct it so that it is and those three those three properties are basically exactly the properties of a smart contract system right and now again that was how I started this was by saying what payment channels are good for one thing but we need another one so a lot of the work that we've put in over the past I know how many months has it been now five months is building this

61. 31:00

    thing called the ovm which is a EVM contained container so it allows you to run evey and EVM transaction as your execute T X function which turns out to be a separate very hard problem so we've had roll-ups without that for a while and EVM roll-ups are coming very soon it's very exciting and some of the ones so there all of you have to be what sort of what sort of personal mission they they running I actually don't know if there are any optimistic roll-ups

62. 31:30

    running in production today I don't think there are but although all the ones the majority of work has been done interpreting things like a state channel I mean a payment system right and so you build a very simple payment machine we did a demo with with it which used the unit swap functionality and we simply hard-coded and you know swap transition function that we had to write mm-hmm and

63. 31:51

    so is there so so the ovm that the Latia is proposing doesn't interpret EVM in EVM or is it somehow legend put underlying VM to doesn't of course make sense it was the latter I see this as efficiently as the underlying medium that's right I mean it's there's maybe there's maybe a 10% efficiency loss that comes with the way that the implementation works but it's it's very close to as efficient yes nice and so does my eatest oh yeah it's not

64. 32:25

    as naive as Oh a theorem is incomplete so we implement the EVM in a theory oh yeah that turns out to be you know a very difficult task yeah yeah so the ovm work just a little bit differently it instead it just adds a container contract which sort of enforces that another contract is running in a sandboxed environment I see cool and so and so that works with with a partial state with their

65. 32:48

    weaknesses that's right yep yep it has a that container has an interface which is called the state manager which is pretty much identical to like how guess or pie etherium implement implement their clients and that can be stateless or staple depending on whether you're on or off chain nice awesome yeah cool so it's also there's another topic which was sort of skipped I guess before which is

66. 33:11

    how do we how do we solve the problem that there's only like maybe it only works with a single block entity which can that's a great one yeah so let's go to the bottom at bottom and talking about that yes so I'll talk about to two iterations that you can build on this system the simplest way to remedy the problems let me just draw a line and I'll start drawing below there so the simplest way to remedy this problem of

67. 33:36

    well who has the responsibility to submit these to submit these transactions and why should we trust them to not halt our coins or censor our transactions right the simplest way is to split the function the proposal function into two functions so you have proposed T X right where you you know you send you know maybe a batch of transaction things right and then you say propose you know state route right

68. 34:10

    SR and that would be and that would be a batch of you know of state routes or maybe just one maybe you append them one at a time and that that is how that is like at its core the way that you the way that you enable this right so simply by taking these two proposal functions and splitting them up and saying okay either you propose a transaction and that transaction is just added in

69. 34:33

    whatever order that layer one added it or you propose a state route and that state route is a result of the transactions right and so this is sort of what allows you to break it up does that make sense go on step two so proposals are is the idea here that there's again only one entity which does that or or shall it accept index at which you are claiming the state route yeah so there's there's

70. 34:56

    a few different there's a lot of different models that you can go by generally state route proposal because it costs gas to prove fraud state route proposal should be bonded right so there should be some money associated with state route proposal and so maybe you say the person who made that bond you can make the bond to be at the time that you propose the state route you can even have a state route proposer that is the person with the highest bond right and

71. 35:23

    so that's you know that's one note associated with state route proposal in principle though it can be anyone and anyone who proposes an invalid state can be can be penalized and so one one important note here right is that an invalid state route does not affect the chain the the the liveness properties of the chain right so let's say like here let's say we have like these two chains and the top chain is a chain of texas

72. 35:46

    right so we have like TX 0 right you know then you can like add a new one right and then we can add another one and another one gets added on right well let's say over here like State Route is proposed here and then State Route is proposed here and then State Route is proposed here and it's like it's red we don't we it's a bad state route proposal right everyone who's honest who's watching the transactions knows that it's invalid and knows what the real state is going to end up being resolved to so you can

73. 36:19

    continue to add on here without any without any concern for the fact that this State Route proposal was wrong as long as this thing gets cancelled in time it does not affect the be like latency of the system you're still just following along the transactions and the transactions you know are doing their thing right yeah I guess my question was also around the fact that if proposals are doesn't take the index right it

74. 36:43

    could happen again that I'm proposing the correct state route but someone else proposed the state route for the same time stamp and so mice truth is a pendant for thee right so you could you could add an index to it okay I think the sir I think in in practice there's a few practical considerations here so one of the practical considerations is that the ability to have a lie can party that aggregates

75. 37:06

    many transactions and submits them all at once is like a very useful service provider and it also affords some gas benefits because it can amortize some of the gas costs as well as as well as there's other crazy things so in the long term what you'll be able to do is use BLS signature aggregation and you'll be able to aggregate a bunch of users transactions to have only one signature and so then in roll-up gets really cheap because you you amortize the cost of you

76. 37:31

    know what would normally be a 65 byte you know ECS a signature so this service provider and kind of needs to be there and it's very useful so pragmatically speaking usually will have the that person be just one that'd be just one person with the property you know with the property that they go away after some amount of time anyone can propose for example yeah that makes sense oh so so so one thing I wanted to discuss briefly was it was like slightly orthogonal to everything we discussed before I was I was I wanted to discuss

77. 38:03

    sort of the future with multiple optimistic roles but if there's something else fundamental we didn't discuss yet we should probably do that first sure yeah I'll talk about well there's a couple other other interesting things so one one one interesting note and is that if we stay here and you know look at these state routes right these state routes have a have a they have a cost right there are 32 byte hashes of call data and so there are more complex there are more complex dispute games that you can build that basically allow

78. 38:36

    you to optimistically skip state routes in the middle so for example imagine that none of these statements were proposed at once and instead we proposed a state route every one two three four or five six transactions right this does not require you to execute execute all six transactions to prove that that from here to here is invalid one thing that you can do is you can initialize like a

79. 38:59

    true bit style dispute game that does a bisection game that says okay we disagree you disagree about the state route here we both disagree about the state route here let's see if we disagree about the state route in the middle and then we both say what we what we think it's going to be in the middle and we say okay we agree about the middle one so it must be one of these two guys so what do you think for this one and you eventually find

80. 39:22

    exactly where the source of the dispute really is so that's one that's one other interesting optimization but then becomes interactive read because you would have every state route and the misfit non-interactive it does it has become interactive yeah and so there's like it's definitely very nice to have a system that is not interactive but it is something you can do another property that I will shout out that is unique

81. 39:46

    that is somewhat tangential although we find it conceptually easier to think about it at the at the add the at the roll-up level but really you can think of it you could implement it on the application level is one really nice feature about having a single sort of person who is going to roll up these transactions is that that person has strong private knowledge about what the state is going to be and it has knowledge of that you know in in like

82. 40:18

    basically an instant latency right as soon as it makes the decision of how it's going to post some transactions it knows what the future state of the system will be mm-hmm and so this is a nice property because if you trust that person or and especially in some applications it's especially useful if you that you can believe that this person will you know makes me be sign a tribute Abul promise that they will include your transaction and they'll go do it and this gives you some really nice user experience of course it comes

83. 40:48

    with the problem of it comes with the problem of censorship that we talked about where how do you prevent this party from for instance not including your transactions and then you're unable to withdraw and so what you can do is you can have a slow q u-- e and egg-like canonical transaction chain so this is this is what we do at our implementation and basically anyone can in a permissionless way upend transactions to this slow queue right so so smoke you in fact when it

84. 41:24

    happens to be under layer one it's on the layer one exactly right exactly right and we're building up and you know maybe let's say we're building up this canonical TX chain here now what you do is you you implement a small time delay between the time at which the a transaction was put into the slow queue right and then it must be and then after this time elapses it must be moved into the canonical transaction chain there's no other valid action other than moving

85. 41:55

    it into the canonical transaction Shane but in the meantime in the meantime you know in this short period of time in which it sits in the queue you can have one party which we call the sequencer and that sequencer can insert transactions in front ha and this allows and this allows the sequencer to continuously provide instant promises and have private knowledge of exactly what the state will be while still

86. 42:22

    maintaining the censorship resistance properties via this sort of escape hatch slow queue mechanism right so you can get crazy with these sorts of designs so in fact a sequencer in the worst case I'm sorry in the in the worst case they will be able to to force someone to pay on chain transaction fee for their transaction that's right that's right and and of course they pay a non change it's still a rollup transaction right so they other than this like amortization

87. 42:51

    cost that we were talking about those costs are very very those cost will be very very similar so yeah in the worst case they can they can push them into the other chain yeah and that gives you some really nice UX for a lot of applications yeah and so I guess another question they have is because all the transactions still end up on the etherium blockchain right I think there are two interesting aspects to it so one of them says that while the first optimistic crough which comes the

88. 43:23

    theorem will scale quite a lot right you can note you cannot scale it so effectively all the optimistic hopes combined collectively will of the scale be the same we're the same fact that has a single optimist to crawl up right because they all share the the capacity of the etherium blocks and that is the bottleneck for them right yes I say it again I think it does but I want to know it precisely what the question also the time to say is that with the so for example with the state channels right you mentioned at the

89. 43:53

    beginning that it is in theory it can scale infinitely right so if we open 1 million state channels it will be one half times more more transactions per second right then a single state state channel while with the optimistic roll-ups no matter how many optimistic roll ups turn from from different entities potentially right operate on the theorem they collectively have the same throughput as a single optimistic

90. 44:16

    roll-up would have on the theorem right yeah yeah so the that's correct and I try to live to this earlier by saying that we should be optimal like what are the bounds of that of that what what aren't what are those limits right there's limits aren't very large right like if we look at like high powered data availability you know sort of engines like you know ease to right as an example well I you know the last time we did the numbers you know you get like 100 100k TPS pretty easily right and I

91. 44:48

    hate the word TPS but you know as an approximation and so those those numbers like will go very large and in general roll ups scale linearly with the number of shards okay so as as the layer 1 sharding improves right the the role of throughput improves and the other thing that we continue to see continue to see why you might like the the Moore's Law the Moore's law for bandwidth has continued going up so you know we can we like can be more confident that like the bandwidth of these Bachchan's will be

92. 45:25

    increasing at a more rapid pace than the execution and someone you're saying it scales linearly with number of shirts affect you all you care about is how much data the shorts can store right you don't you don't really need execution from the shorts right correct correct they're they're they're the yeah and and that's why again it is tricky like TPS is so tricky like you know one thing for example that you have to prevent in this scheme is you still have to have an ocean of gas right so for example like it's not sufficient to

93. 45:57

    use l1 as the anti-ddos for this system because you might for instance submit a transaction that you know calls while true right and then we'll just like you know never halts so yeah I forgot exactly where I was going with that but you but but you do do gas metering and and so you know you know instead of doing well true if you have for you know you know a for loop that iterates over a

94. 46:22

    bajillion cycles you know you can you can do that and you know get a lot more throughput that is quote nonlinear in some sense but that can be that's that should be handled on v4 VM levels right correct exactly right yeah yeah and again we're lucky enough to be able to borrow that gas metering so and another interesting thing is so assuming that for a while up to mystic ropes are going to run even the thin one point all right if we do like very quick computation

95. 46:56

    it seems that so let's say majority of computation most optimistic roll-up then a theorem block size will increase dramatically right so today when everything is like 20 kilobytes right and then it would become the content kilobytes or 200 kilobytes per block so so do you have any insight into how that can affect the chain like we have higher uncle rates or anything like that right so I mean currently currently like

96. 47:20

    aetherium is lobbying to bring to like so I don't know how many months ago was now could have even been closer to a year than then measuring in months ago now but recently actually lowered the cost of called data way down particularly to support roll-ups because because it was it was considered and it seemed like call data was overpriced and that we weren't gonna kill the uncle rate if we do this I see ok so some

97. 47:44

    smart people get think about it smart smart people didn't think about it and there's even proposals to lower it further another and like another and other obvious step that you can take is you can basically add a you know a new opcode to the EVM or like a new pre-compile however you want to think about that allows you to simply check the availability of data and that's all that you can do and you know maybe it automatically you know Merck Eliza's it

98. 48:08

    and so that would allow you to not not have like the VM be any part of the constraint at all and it's just pure bandwidth yeah so so is there anything else important we didn't discuss about optimistic roll-ups um let me think let me think I think we I think we hit the big points so there's one interesting topic which many many proponents of ZK roll-ups bring up right that if you have quite a quite a bit of assets in the optimistic crawl up it might become

99. 48:39

    reasonable for for the miners to get involved and stop censoring the disputes right for sufficiently long until until there is a until the dispute period ends right so so is it is it a valid concern and are there any ways to get around it definitely a valid concern so this is like we often call this internally like the parasitic l2 arguments which is fun the the answer is for in optimistic

100. 49:12

     execution schemes you can't really get around that so you have to be careful because and and maybe a better way to phrase it is that layer two systems are an intrinsic source of MeV of miner extractable value and and and even to the extent that like you said you can do something called a time bandit attack where miners Shack the value can be retro actively stolen by another by

101. 49:36

     another miner who 51% attacks the chain and moves forward I see there's there's not there's not a ton you can do about this particularly on each one now outside of like you know governance concerns so like you know if I if I miss food period is gonna end up being a week if the Assyrian chain was 51% attack or censorship attacked for a week would there you know would there be a governance saying where you know people decide to fork who knows you know

102. 50:01

     hard to say in in East 2.0 like user you know user you know soft Forks for you know for like sort of subjective realizations of censoring or is going to be a part of the part of the protocol and the you know social consensus around what Paul so we're helped there with having said I'm a huge fan of zero knowledge groups like if there was a zero knowledge EDM that I thought was a short-term Bible I would be jumping all over that like our goal is to be very very pragmatic we're

103. 50:35

     not tied to optimistic roll-up because it is the scaling solution we're tied to it because it gives a reasonable set of properties that we think are worthwhile and it does it today so if you know when ziran windsor knowledge proofs start going crazy and are way easier to develop on and so on and so forth um we totally should have more zero knowledge groups you know I'm a huge fan huge fan awesome and the last question I have is

104. 51:00

     certainty in terms of optimistic roll-ups appearing in production the other thing is going to be more like a single chemist acrylic which has multiple contracts which interact with each other within a single state right within a single VM or like I don't know how to like with a single container right or do you envision it more like multiple optimistic ropes that have a way to communicate between them and if the latter then how the communication will happen it's a really good question

105. 51:25

     and there are limitations after which you know verifier costs are going to get so large that if users aren't willing to accept those verifier costs or they're not willing to accept that there exists out there one you know honest verifier then you they and you may need to to to spread them out so especially in like you know super quadratically crazy sharded systems where the amount of available data is just insane and that

106. 51:49

     computation is insane then you're going to need multiple roll-up chains in the short term we have pre have put a strong emphasis on making a rollup chain that supports contract deployment and supports the sort of money lego features that we see on a cerium the only other thing I was going to say is those like tools like I actually think you guys at near are doing a great job of like I think you guys have an async await for

107. 52:12

     cross shard communication or whatever like asynchronous communication between apps in the decentralized context is going to be super important but it's not there yet I don't think so I would say that one other one one thing that has less whiteboard II to call out is that this this screen that we have right here actually with this sequencer is related to a really cool sort of economic construction that we're working on called neva minor extractable value

108. 52:39

     auctions mm-hmm and basically the idea is that this purpose sequencers ability to order transactions the that privileged position in addition to enabling you to give out these sort of low latency promises of what you're going to decide the state is that prioritized position is like very valuable and more normally that value goes to minors and frontrunners and we're super excited that in layer two you have a nice clean way to actually be

109. 53:11

     able to basically you know sell that that right off and repurpose that to do something that's much more useful like public looks Goods funding right or or you know I know you guys are doing cool stuff with like giving out you know rewards to people based on the gas that their contracts used so we think that being able to sell off the right to be a sequencer is an awesome way to like

110. 53:33

     monetize get rid of something that users see is a downside by turning into a good thing so that's um I guess the only other thing I'd mention yeah cool okay cool great so so thanks a lot for explaining the opportunity to crops that was I guess a great episode and absolutely well yeah hopefully not the last time we were talking in this format awesome thanks so yeah once we have shining we'll have a third one you know it's