Whiteboard Series with NEAR | Ep: 40 Part 2, John Adler from Celestia (previously Lazy Ledger)

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

1. 0:04

   so now we go on to kind of the main topic of today's conversation now that we know all this which is lazy danger okay so as we said before uh let's draw our blockchain again here is our blockchain it's really nice that they have built-in arrows so here's our blockchain so we have our block headers right and they you know each uh each block header will have a transaction routing here right it's

2. 0:37

   going to have a transaction route in here somewhere in the block header that commits to all the transactions here so now we kind of note something interesting which is in order to solve double spending do we need to exclude invalid transactions by invalid transactions i mean you know a transaction that either double spends a utxo or one that spends an invalid nonce uh do we need to

3. 1:07

   exclude them to prevent double spending no no we just ignore them like exactly if if those we could have a blockchain where those transactions are still in the blocks but we just ignore them well effectively we're saying there's no such concept as an invalid transaction right yes that's exactly it right there's no such concept as an invalid transaction uh and we let the application that runs on top of this order data decide its own

4. 1:32

   validity rules the only thing that we're doing at the consensus process is ordering zeros and ones that's it and the answer is well yes we can do this and this also means that the blockchain no longer has to do execution and this is really good because the bottleneck right now by far in any contemporary blockchain is very much execution right uh you know we target uh you know we have some sort of virtual machine say the evm

5. 1:56

   we have an implementation of it you know saying geth and we target a particular amount of computing hardware for a full node you know say that's a computer a consumer laptop and then we have a particular validation rate so that's how fast we want to be able to catch up to the head of the chain and in ethereum it's somewhere around like 30 fold so if you take ethereum's 30 transactions per second or 15 multiply it by you know around 30

6. 2:19

   validation rate you get 450 which is you know around the limit of what geth can do if you just launch it on you know if you just run it locally so we know that you know this is that that's our bottleneck it's there's no consensus bottleneck here it's very much the execution it's very much the execution engine uh so being able to remove execution from the base layer and just saying well we're just going to order zeros and ones is good because now it means that we no longer have that

7. 2:44

   bottleneck okay so how does lazy ledger work so the way lazy ledger works is it commits to a list of messages let's call it message root where a message is just some zeros and ones and the message does not have any effect on the lazy ledger state and then kind of like the ideal academically lazy ledger lazy ledger has no state at all so the messages are just ones they don't affect uh the lazy letter state and in fact there is no daisy legislate

8. 3:15

   so what it will do is you know someone somehow we the the exact consensus process is orthogonal and you know you can use any consensus protocol on top of lazy ledger which one you use kind of influences how much state you'll need in practice uh if you're doing proof of work you don't need any state to manage block producers if you're doing proof of stake then you're going to need some state somewhere right as part of you know some consensus critical state somewhere uh

9. 3:40

   because you you know how else would you manage the validator set but you know that's that's that's basically like the bare minimum that you need everything else is just messages uh so as soon as you just have a bunch of zeros and ones uh and then lazy ledger doesn't doesn't execute them it just it just orders them uh and then if you want to check to see is this block valid you no longer need to execute the block

10. 4:03

    to check if the block is valid you only need to make sure that the block data is available right yeah so what this means is that uh a light node essentially has almost the same security guarantees as a full node like the light node is gonna do some random sampling uh and if you know they have a hundred light nodes and a hundred full nodes the full nose can also do that just as

11. 4:26

    random sampling and except for the one exception for this fraud proof here which a anyone can generate and b the nice thing is this is stateless uh unlike you know a state transition fraud proof the fraud proof of incorrect erasure coding is stateless which means like if one person checks one full block and tries to you know tries to construct a potentially fraud proof for that one block they don't need any previous blocks they

12. 4:51

    can do it entirely statelessly which is very good because it means that you can now distribute this work among many parties as opposed to acquiring one party with a very powerful computer that can fully validate you know say all transactions uh so this being stateless is like a is a makes it completely different and the particular implementation of lazy laser is a proof of work or proof of stake uh we can talk about the particular information in just a couple of minutes okay so we're starting from the general

13. 5:15

    one okay it was in general so the general is basically except for this raw proof stuff which we can ignore again because of the fact that we can distribute it and we don't need one very powerful computer you know a light node essentially has the same security as the same guarantees the full node because they both just you know check if the data is available and so long as there's sufficient number

14. 5:32

    of these nodes doing this then yes the data is available and yes it can be reconstructed and this is all you need to do and so let's have an application which wants to use lazy laser right yeah so so will fraud proves be something that lazy ledger provides to me so the fraud proofs the laser edger has natively are only for the data available like in the erasure coding here right and in our implementation it's also for

15. 5:56

    uh transactions that mutate the lazy ledger state such as basically just modifying the validator set which is you know again there's like a trivial state right so this is easy to do in terms of if it can support application layer fraud proofs and the answer is lazy ledger doesn't need to natively like the application can define its own fraud proof scheme and since the application like an uh now

16. 6:18

    we're gonna get into how applications work and we can talk about the name space merkle tree in a second uh so what you can do is you can have applications running on top of lazy ledger on top of the order of data and the laser the application can define entirely its own execution system which means you can get heterogeneous execution you can't do this in a sharded context you may have heard for instance heterogeneous sharding from polka dot but they don't really have

17. 6:43

    heterogeneous sharding because all of the all of their shards or para chains execution systems all need to compile down to wasm which has a common metering so they're not actually they don't have a different meaning for each para chain they all have the same metering so there's actually homogeneous shorting uh with lazy ledger we actually have true heterogeneous sharding you can define any like pre-compile you want in your application for instance no you could have a pre-compile that

18. 7:08

    does something like you know find a collision for sha-256 for one gas and you could do that in your application and laser ledger doesn't care because legi laser just ordering zeros and ones it doesn't actually execute anything so it allows for true heterogeneous shirting and it doesn't care what you do with the application letter there okay uh before we get a little bit deeper into your questions we can talk about the name says merkle tree uh namespace name

19. 7:32

    space miracle tree uh so what this does is it's it's a merkle tree uh as you may have guessed but essentially each leaf so here so here's leaf plum beef and here's our root you know your tree here uh each of these leaves is associated with a namespace id so there's going to be plus namespace id1 it's going to be namespace idm right and you may look at this and you might say well this looks kind of like a merkle sum tree for those of you who uh are maybe not familiar with merkel some trees uh it's

20. 8:19

    essentially a construction for doing fraud proof style things on bitcoin where each transaction you kind of add on some metadata of say how much how many fees this transaction pays and then what you do is when you want the hash like when you have an internal node you hash two leaves together you concatenate this extra data in the case of merkle sum tree would be the amount of fees in the case of the name says merkle tree it's the name space id

21. 8:44

    and you can kind of concatenate that together and you hash it so you kind of get as the root you get a commitment in this case for merkel some tree you get a commitment of all the fees that are collected in the block uh so it allows you to fraud proof of uh you know the the minor collected too many fees and they minted themselves too many coins in our case it allows us to have range proofs essentially that uh

22. 9:07

    that particular messages or messages from a particular namespace uh you can you can prove their inclusion uh so each leaf essentially is one namespace id associated with it uh internal nodes so an internal node has do those name spaces in any way so like the hash function that is used for the intermediate nodes and the merkle tree is it still just a sharper 56 or does it aggregate namespaces

23. 9:33

    in some special way you can think of it like a sha26 that outputs uh okay output it outputs a min and max name space id yeah so it's kind of solved yeah uh yeah so the so the internal nodes will have both a min and max so this is essentially a merkle interval tree and allows you to have range proof so then i can prove assuming that leaves are ordered by their namespace id you can prove that you you can provide a proof of all of all leaves for a particular

24. 10:06

    namespace and then you know the whoever's verifying the proof knows that yes these are all the leads for a particular namespace uh uh so that yeah and we of course assume or you know we construct it in a way that you know the leaves are ordered by the namespace id uh so what this means is applications aren't just you know blobs floating around is that you know each message is going to be associated with a namespace id and kind of this allows for the

25. 10:30

    construction of what the paper calls virtual side chains or what we call more recently uh lazy ledger applications uh which you know it's essentially just a blockchain there's a blockchain but it commits this entire block you know it's associated with the namespace and just commits its entire block boom to lazy ledger just the whole block like imagine anything is this miracle chip per block is it just all the transactions in the block or is it all the transactions in

26. 10:53

    existence it's all the transactions in a block this is a per block oh that's per block okay yes uh we've been thinking if we can extend this to like cover multiple blocks to allow for to allow for like better better sampling of of you know across epochs and stuff uh that's kind of still that's kind of still a little bit of a research topic but for now there's this per block yeah yeah so this is kind of how how lazy the ledger works again is that

27. 11:17

    you can have an application just you know however it wants to reserve as name space lazy ledger doesn't care uh and then uh just you know just commits you can the the kind of the simplest case is that you know you have a blockchain and then just it takes this entire block and just puts it as a message on lazy ledger and lazy ledger will order them so what this means is that if you run multiple of these together on top of laser ledger

28. 11:41

    they essentially have shared security because they have the same data availability guarantees so that you can construct things like fraud proofs which allow you to run secure light clients for one virtual chain that one virtual side chain that talks to another virtual side chain so it's essentially you can think of them like shards at that point right well also when you say sharding right you can you can shard different things right so in this case

29. 12:06

    lazy ledger natively shards processing right because lazy ledger validators don't process anything laser ledger doesn't even because at no point to lazy ledger validators are they ever forced to validate any virtual sidechain right so so they allow but allows you it allows you to build an application that charts execution yes right you also short state naturally because again lazy legibilities don't store any state

30. 12:31

    right so it's on the application validators that store state but it doesn't shard networking right all the messages from all the virtual applications still have to go through the same uh ledger right that's correct yes yeah uh so in serenity for example uh all like in serenity for example if you're running you know validator in in serenity commonly called the ae2 and precisely in my opinion uh you

31. 13:00

    every single validator needs to that well they need to fully validate their the shower they are assigned to but they also need to run data availability checks on all the other shards right but they not uh if you if you consider a validator in the in the serenity they are a full node uh in the in the shorts they track right but they light client nodes in all other shirts right while in lazy ledger the actual validators that build the chain right the full nodes in terms of like if we separate then loading data

32. 13:33

    downloading transactions right and processing them so in lazy laser every validator is a full node in terms of downloading all the transactions but but no note not even light node in terms of processing them right while in in serenity in terms of both processing and downloading i'm a full node in one chart in the light node you know less data i'm not really fully convinced of that i'm not really fully convinced of that distinction in practice for two reasons uh the first reason is that as i said above

33. 14:04

    the kind of the thing that you need to do here is the the only the only reason that you need to fully download a block is to compute this fraud proof if you're not going to try to compute a fraud proof you never really need to fill you never need to fully download a block right you just check to see if it's available right uh but the thing is computing this fraud proof is stateless so instead so why don't you just take

34. 14:27

    like the validator set and just split it up into like 64 different chunks of validators and have them you know each validator just randomly assigns based on some vrf or just even some internal randomness you know 164th of each block or 164th of the blocks and then like you know every 64th block give or take on an expectation they just try to you know fully down the block and compute the thread proof and then you have the same thing right right you

35. 14:52

    can also assign if i understand the construction correctly right you can also assign actually 164th of the block right you can have every validator download some subset of rows and subset of columns yeah yeah you can do stuff like that too so yeah so in practice it's because of the fact that you can parallelize almost you know the things that computation here and you can parallelize across

36. 15:14

    across even multiple blocks uh because of the fact that everything is stateless it means that you in practice is not there's not a really good it's not really a problem okay uh i think you had a few questions earlier i think i answered some of them but you probably some other ones are oh so one one thing you asked which i remember now is prove work of proof of stake yes uh so and what is the consensus yes

37. 15:38

    yes uh so we you know we can start with that and then presumably we have other questions and then you can ask them so in terms of you know the technical stuff that i have to introduce um this is basically it so now it's it's basically you can ask any questions you want so proof of work approve of stake how we're implementing this not how it's done in academia right so we went with proof of stake and specifically the tendermint consensus protocol because it offers pretty fast finality guarantees

38. 16:02

    pretty good security guarantees and pretty good performance and it's one of those things that you know it it is working there in production right cosmos uses tendermint many cosmos zones use tendermint uh so it's been around for a decent amount of time and they have a pretty good developer ecosystem and whatnot uh so you know it's one of those things where we don't really care what consensus protocol the lazy ledger the lazy ledger chain uses because

39. 16:25

    there's a need to use a particular one uh but in terms of if we had to choose one you know tendermint is probably the most mature at this point in terms of proof of mistake now you might say why not proof of work prove work seems amazing you don't need any state to manage the validator set and proof of stake improve of work right because it's managed implicitly through through the through the work uh and uh and so you know and the block headers are cheaper and stuff but the problem with proof-of-work is

40. 16:51

    you kind of don't have this deterministic or like immediate finality as soon as a block as soon as block is there which you get out of bft protocols and proof of work is it's it's probabilistic which is and then you have things like variable block times and whatnot so it makes things generally just not as good and i recently posted a thread on twitter about accountable safety by recently i mean at the time of

41. 17:15

    this recording uh not when it's when this whites not when their youtube recording is out uh about accountable safety so one thing that the ethereum space has kind of been pushing very hard which we should admire them for is the concept of accountable safety so if a reorg happens if an equivocation happens which you know you know that happens and usually the chain stops at that point because you know it says okay there's a safety violation

42. 17:39

    so you know it happens uh what this means is you can identify at least one third of stakers and then through off-chain coordination you can you can burn their stake and this is really really good because it means that you can penalize specifically attackers and this isn't something that you can do in proof of work right in proof-of-work if a majority of miners re-org the chain you can't really penalize just thumb right like the only thing you can

43. 18:04

    do is you know you either tank the price of the coin forever which isn't really great it's kind of brittle or you change the proof of work algorithm which is now you're hurting everyone you're not just hurting the miners that attacked uh so proof of stake has this notion or you know modern proof of stake protocols have this notion of accountable safety uh which gives it which allows it to have you know kind of very strong security guarantees uh you know it makes it very costly to

44. 18:28

    attack the system and therefore it can have a much smaller security budget yep yeah that's great uh zaki zaki from cosmos once told me that if you are using vft consensus you you should be using tendermint i kinda agree with him at least as of today i think that is it it is indeed the most mature consensus yeah as the beam goes it's uh it's it's it's it's all be it's it's all tendermint and then nozaki goes yep it always has been you know you know a lot of these proofs

45. 18:59

    that protocols reduce in some way and what not into some variation of tendermint well yep they use hot stuff but it's it's similar cool so another question i have so let's say i'm building an application right uh if i'm building an application i use laser laser as my data availability uh layer now uh in order to have uh state validity fraud proofs i need uh annotated uh state routes

46. 19:25

    yeah so the simplest way i see is i will just submit an extra transaction which says oh up until now this is the state route we have right or or rather i guess will we just submitting the statement after every transaction or uh so how the application does it is application dependent right but do they need to have like my question is can they use in the like it's pretty easy to build if i have another network you know where people agree on something like for example they order transactions they compute the state route and they submit it to lazy ledger

47. 19:56

    but can i do that without having an extra an extra protocol between the nodes can i only do it using lazy ledger plus generally that makes things messy to kind of determine an arduino and this kind of boils down to a lot of leader selection processes in optimistic roll-ups especially on ethereum and i wrote some posts about this you know on merge consensus and whatnot but you know what you want is just

48. 20:20

    ideally a permissionless consensus process how you determine the value the leader is is irrelevant for an optimistic rollup this has to be you know deterministic and the leader selection should be verifiable by ethereum proper uh in the case of optimistic props and i'll explain how this you know bridges to lazy ledger uh so you know so one way you can do is you can say uh you know whoever submits the block first they're the leader right another way you could do it is you

49. 20:43

    run you run some small process that does something you say round robin or you know you run some rando or something and you randomly select a leader uh so you you you can do these things but the trick is all these processes to elect a leader you can you don't like the way it works in the theorem because of how ethereum is kind of limited in its execution system the leader of selection needs to kind of be verifiable by ethereum proper in laser ledger if you're building a lazy ledge of native application you don't really

50. 21:15

    care like lazy ledger doesn't care who the leader is so basically anyone can submit a block at any time and kind of to give you some intuitions about this is imagine that you're in a in bitcoin for instance do you agree that someone could just create a bitcoin block and just distribute it up in the network yeah so now imagine you take that block and you just put it put it as a message on lazy ledger so note that the person who puts it as a

51. 21:38

    message on lazy ledger doesn't need permission from lazy ledger and it doesn't need permission from anyone inside this this virtual sidechain just like how a miner doesn't need permission from the other it doesn't need permission from the bitcoin network to mine a block and distribute it to the peer-to-peer network right the trick is you need that uh you need to have you you need to have

52. 22:01

    it so that verifying if a block header is valid in other words if you know if the leader if the presumed leader had the right to produce this block needs to be exponentially cheaper than verifying the full block as long as you have a condition like that then there's there's no there's no problem if anyone can submit any message for any namespace id and you don't care it's like imagine someone goes on bitcoin and they try to distribute an ethereum block header

53. 22:26

    throughout the peer-to-peer network nothing nothing bad happens right it just gets dropped like in this case okay someone includes you know an ethereum virtual sidechain block header in the bitcoin virtual side chain so the bitcoin nodes the bitcoin virtual sidechain nodes which are you know running the application they see that you know they see this this clear this thing clearly doesn't belong here so they just ignore it just like just like they would in the peer-to-peer network

54. 22:51

    does that answer your question yes yes i think so in fact the point is uh i guess my question was whether it's the case that uh uh there is some way of building applications which is simpler than building an optimistic crop no right uh yes and no uh it's slightly similar than an optimistic roll-up because you're not limited by the evm how the application itself decides the fraud proofs is not you don't have to implement say you know interpreter in the evm

55. 23:23

    and implementing an interpreter for fraud person evm is actually not trivial but it's especially doing in a gas in a you know in a way that doesn't use up all the gas is non-trivial here you have access to native code to execute the fraud proofs which means that things get much easier on that front also in terms of things like timing and whatnot uh you can imagine for example a gossip network overlaid on top of the lazy ledger nodes

56. 23:46

    for each virtual sidechain right so it's like a it's like a just some subset of the nodes and they're gossiping based on your topic so each topic is the same namespace id uh so people can actually or you can have fraud proofs for a virtual sidechain be gossiped around in the peer-to-peer network which is something that you can't do in an optimistic grow up right an optimistic grow up you have to post the fraud proof on ethereum with with laser ledger

57. 24:11

    like native virtual side chains you can actually distribute the the fraud proofs in the peer-to-peer network and they'll actually take effect even if you know even if it takes a long time to get the fraud proof included in lazy ledger uh the kind of off-chain applications are still going to take that into account so in some ways it's like it's slightly easier in some ways because you don't have to worry about

58. 24:33

    timing as much for fraud proofs you don't have to worry about building an interpreter for your execution system and gas limits and whatnot uh so in that sense it's easier in terms of uh yeah and in terms of things like you know bootstrapping a new chain uh one slight issue with cosmos zones is you have to bootstrap their security right like every single cosmos zones need to have a validator set uh you know you have to run proof of stake uh it needs to have its own

59. 24:57

    security guarantees and and you know and so on right uh with laser ledger you don't really need a big you know validator set to improve stake you just need some way of deciding a leader for the next block of the virtual side chain and that can be very simple right then you can do that and say like you know some other application that that's all it does it just you know the size leaders for for these virtual side chains yeah and i have one more question which is a

60. 25:21

    little bit uh i would say it's slightly orthogonal but uh but it's interesting because you mentioned sharding right so uh if we compare cosmos versus uh well i would put polka dot and near into the same bucket from this perspective on cosmos uh if you have two zones right so charging is is only meaningful in my opinion if if there is way at least to move assets between applications i ideally do something more

61. 25:47

    than that right but let's say we just want to move assets so on cosmos uh if you move assets from one zone to another uh then uh then what happens if then we later realize that the first zone was actually corrupted uh and the and the because the second zone they will be acting as a light client right so at the light time they verified the the root it was correct miracle proof matched so let's say later we actually do realize that there was an invalid state transition right so in cosmos

62. 26:18

    they they effectively have a philosophy which says there's no such thing as a valid state transition any state transition on which tendermint consensus which is valid by definition right so if state road does not match transactions that is still a valid state transition as long as tendermint consensus is reached so from this perspective you don't need any fraud proofs but in polkadot and in here if you uh submit a cross-chain communication

63. 26:43

    from one chart to another or from one parachute in case of polkadot to another and then later it turns out that the first part chain had an invalid set transition what happens that in both near and polka dot both chains will get rolled back right but in lazy ledger the latter is definitely not something that is easily implementable unless unless those shards in in advance agree upon having this trade

64. 27:07

    security right so so do you have any thinking around how that will be happening yeah so uh first of all kind of a few notes which is that unlike uh say cosmos zones or just new side chains uh if uh if the virtual applications uh or virtual sidechains on top of laser ledger uh make use of lazy ledger as a data availability layer then you can be guaranteed that since data is available fraud proofs can always be made which is something that you can't guarantee with sidechains uh so one thing that's nice is cosmos zones if they want to they don't have to but if

65. 27:38

    they want to they can opt in and essentially just post all their blocks to lazy ledger so this will allow them to share security uh so in terms of how fraud for how fraud proofs work and how you know different virtual side chains that are like shards would communicate the answer is it specifically depends on what the execution system wants to do so one potentially nice thing is you

66. 28:01

    don't have to worry about rollbacks lazy ledger doesn't have to worry about rollbacks right rollbacks in terms of the state of these virtual side chains is only determined by what the virtual side changement at laser led you don't have to worry about lazy ledger rolling back because one this one virtual sidechain had had some invalid state transition in it right and in shorting systems you know one shard has an invalid state that's when things get really messy right because then it's like

67. 28:25

    you roll back just a shard then people you keep the money they're stolen you roll back the whole system then things get a bit messy right so there's like this is this is a little bit tricky there well those ledger you don't want to worry about that because it's something it's all done at the application layer so uh essentially two applications would have to kind of agree to be part of a network with shared security where they'll you know accept

68. 28:49

    uh you know accept being able to process fraud proofs uh this is assuming that you don't go the optimistic role upgrade where let's say you have like one virtual machine that's touring complete with a high gas limit that allows for you know trussless two-way bridges and then uh different virtual virtual side chains can use this as a hub one option is you're having a hub kind of like you know you just run like the evm for instance right some turing

69. 29:15

    complete virtual machine and this acts as a hub that you know various virtual surgeons can use to to move assets around uh indirectly the other alternative is you know they can communicate directly with each other uh without going through this hub and this essentially means that you know they would have to run you know to have to to be secure they would have to run both the light client of you know the other virtual side chains which in this case like

70. 29:40

    a like client of the other virtual sidechains is pretty easy because it's not much more work than just running a lazy ledger like client right and you're downloading a few extra block headers and they would need to have some way of executing fraud proofs for yeah for for the state validity and how you do that is kind of an implementation detail on one on one hand on the other hand it's a tricky implementation detail yes

71. 30:04

    because you know the ideal situation is each uh each namespace or each application let's say because your namespaces are permissionless let's say each application defines and then the ideal case uh this is something we're still ironing out but you know let's say each application defines in wasm code or you know evm code or something how to execute fraud proofs uh and then you know if you want to execute a fraud proof you just take the fraud proof and load it into this execution engine and so you see it as true or false so that's kind of uh

72. 30:35

    you can either do that or you can run native code uh native code is a bit trickier because you know there's possibilities for you know resource exhaustion attacks and exploits and whatnot but you know you just have you just need some standardized way which technically doesn't have to be it's not enforced by lazy ledger applications can do whatever they want right and i'm going to guess that in the future there's going to be multiple standards for how to define this you just need to have some standard

73. 30:59

    standard of being able to essentially load the execution the execution engine and you know how to be able to process a fraud proof right so the way the way i hear your answer is that or rather the the the next step i see happening is you know like polka dot near serenity all the systems that today have their own data availability schemes they all started before there was any data availability standard right so if we imagine lazy ledger becoming the de facto data availability

74. 31:31

    standard then it's just that the next if there's a next generation of blockchains they will just have one less problem to solve right they can just resort to using lazy ledger as a data availability and then they can like you know polkadot can build their pirate chains with their specific way of state validity proofs and rolling back the relation is it called delay chain yeah relate chains yeah uh yeah and that's actually a good

75. 31:54

    point that you bring up which is what i want to touch on which is that uh lazy ledger doesn't inherently compete with any other layer one because it can't it doesn't have a native execution layer uh and in lazy ledger and this is kind of one thing i want to make extra clear so no one calls me like a shield or anything laser ledger does not provide a scalable execution layer what it provides is a scalable data availability layer in other words you can just fit a whole bunch of

76. 32:19

    bytes per second through it with high security guarantees uh like the highest security guarantees and the most bites per second because it completely removes execution uh if you want to build a scalable execution layer on top of it this could be shorting uh this could be you know you exploit a whole bunch of parallelism like like the slanted guys right you have like a really optimized like down

77. 32:40

    bare metal execution system and you can build that you can build any execution system you want on top of laser ledger but laser ledger native doesn't provide on its own uh any execution system let alone a scalable one so in that sense uh it's laser ledger is nice because it's completely agnostic in which blockchains can use it for our data availability layer right so like you said you know nier can use it polkadot can use it serenity you can use it ethereum

78. 33:06

    can use it bitcoin can use it uh you know celina can use it all of these chains can use it you know cosmos can use it uh all these chains can use it and now you can actually you know do this you know scaling by altcoins thing which you know used to be terrible because you lose security now they all have the shared security and in fact you know potentially additive security if they all pay fees together uh and then they can actually you know you can actually now do

79. 33:29

    proper uh you know experimentation with various execution engines various trade-offs and whatnot all without losing you know security guarantees right yeah that's great uh and well the last question i have uh is uh uh lazy ledger still needs to do some uh like first of all if it's proof of stake right besides maintaining validators set we also need to be paying them rewards right also uh as transactions are being submitted there's got to be

80. 33:59

    it cannot be free right transactions must be like something must be paid when the transaction is submitted right so that means that lazy laser at least implements the very basic transfers functionality right yes uh so i can go over that uh briefly in terms of uh so first the kind of ideal idealized situation that was presented in the paper uh which is that you just run a virtual you run a virtual sidechain and that virtual sidechain

81. 34:23

    does things like manage the validator set handles fee payments and whatnot and that's kind of the idealized version uh in practice it's the case that if you have something that's consensus critical then you might as well just try not like it's just it's simpler if you're just trying to then you don't have to go through different levels and direction you don't have to worry about constrained execution environments and so on you just you know just enshrine it and just do it natively so lazy ledger since we're

82. 34:47

    using proof of stake like you said and since we want to pay for fees both of those things uh there is like a very very minimal execution execution system in our current design of laser ledger and basically the only thing it does is it manages validator set and it handles free payments that's all it does right so um so so let me think how it fits because because until until this moment right we assumed that like like for example that no validator needs to execute all the transactions right

83. 35:19

    so other transactions that that change the state are they in a separate sort of zone in the block yeah which is which is heavily limited yeah so what we do is we have a reserved namespace for consensus critical consensus critical messages uh and another you know any other namespace is used for in arbitrary messages so these consensus critical messages like transactions and whatnot

84. 35:42

    uh yeah we we we're going to you know heavily restrict how how much how much how many how many of those can be in a block so that you know running a full node maybe you can even do it on the phone because you know just just watch just moving balances around and you're just doing a small number of those right and and i presume that actual transfer of lazy ledger native currency whatever it is is not the intended use case right so if you want to be transferring or exchanging

85. 36:05

    you you should be moving to uh to one of the l2s built on top right so so the transactions effectively should only be happening if a i actually want to become and or stop being a validator right or if if i want to move my lazy ledger coins to some side chain or or take them out right so so that should be relatively so it's basically that and paying for fees because each matters needs to have a fee payment associated with it but can can this not be solved using the sum tree the same merkle tree

86. 36:40

    uh as opposed to what uh also i thought you're suggesting that the messages that uh the transactions that pay for the messages also go into this restricted part of the block yeah while it feels to me that because you're paying for every message included into the block then we can just have uh uh well right now i'm discussing like something that's technically you can consider like a design detail uh so if you're saying could you do this the other thing then the answer is well maybe you could do this other thing i'm just describing the way we've done it

87. 37:10

    now so the way we've done it now uh you know how the like opera turn works in bitcoin no because like uh okay very briefly the the the op return is just like upper turn and then some bytes of data and then that output becomes prunable it's unspendable but it means that you can record those like i think it's 80 bytes or something along those lines of data and in the bitcoin blockchain and then and there's no reason to stop at an ad you can make it a gigabyte if you want

88. 37:35

    uh the problem of doing it that way is that in order to fully validate this chain or the sanctity of the coin you still download all those opportune datas but you shouldn't have to so the way you've done a lazy ledger is essentially a transaction that pays for a message but you don't include the message in the transaction you just include a hash of it another message is going to be somewhere else in the block i see so

89. 37:58

    so the intended use case is that messages are pretty large right so people say messages could be very very large yes i see i see right that makes sense cool okay so so i don't have any more questions so that was that was a lot of interesting information and i guess data availability is uh not something we discussed frequently on the whiteboard sessions so i think it's uh overall was a a lot of new information for many people

90. 38:31

    so thanks a lot for uh for coming and uh we always ask one final question which is not technical which is how soon is the is the launch i'm gonna pull out a meme and say 18 months but uh but but unironically on on ironically so some uh the nice thing about lazy ledger is that you know the system that i've described here if you think about it since there's no high performance you know uh execution system since there's no you know like rapidly switching your gossip network of shards around and your

91. 39:04

    subcommittees and all that stuff it's actually fairly straightforward right yeah the the trick is you know you have to understand how data availability approves work and the implications of them and you know make sure you design things like transaction systems that don't include entire messages and stuff like that uh but you know once you have these details in place then it's just really just a matter of implementation there's not really any unanswered research questions in this that's the nice thing uh so yeah we expect we expect you know

92. 39:27

    somewhere you know you keep on lookout somewhere you know 18 months in that time range for a test net pessimistically awesome great sounds great okay again thanks thanks a lot for coming you