Ismail Khoffi & Mustafa Al-Bassam: Celestia – The Data Availability and Consensus Solution #359

Transcript

this is epicenter episode 359 with guests ishmael kofi and mustafa al-basam [Music] hi i'm sebastian cuccio and you're listening to epicenter the podcast where we interview crypto founders builders and thought leaders on this show we dive deep to learn how things work at a technical level and we fly high to understand visionary concepts and long-term trends if you like the podcast the best way to support us is to leave a review on apple podcasts now did you know that leaving an apple podcast review gives you a serotonin

boost that permeates throughout the rest of your day well if that sounds good to you if you want that jolt of happiness go to epicenter dot rocks slash apple on your mac your iphone or your ipad and leave us a five star apple review today our guests are ishmael kofi and mustafa al-basam and together they are the co-founders of lazy ledger now this is a project that i didn't know very much about before i heard this interview and actually if you go to their website there's very little there and it still feels fairly early but it's really interesting because it does something that we haven't really seen before at least not implemented in this way so lazy ledger is sort of a minimal viable blockchain it does timestamping and block ordering

and so the way to think about this the analogy is to think about bitcoin in the early days before ethereum when folks were building things like colored coin and counterparty essentially layer two systems on top of bitcoin that were leveraging bitcoin's consensus layer and what they were doing is they were using the op return field in bitcoin to store block hashes for their layer 2 blockchain lazy ledger kind of does this only it's purpose-built and scalable for that exact use case so obviously the implementation details are a lot more complex and sunny and brian go deep into the technical details during the interview but the vision is to create a modular plugable layer

one that does nothing but consensus and data availability there's no smart contracts or anything like that and it's great for people who want to just create their own blockchains without consensus they just dump their blocks on lazy ledger and it does the rest so you could say for example build a cosmos sdk chain or an evm chain you post your blocks on lazy ledger and it takes care of the rest so the reason why i think this is interesting beyond the technical implementation is that to me it shows a certain level of maturity of a technology ecosystem when different layers of the stack are starting to unbundle and uncouple from each other so we saw this in web 2 where we now have a very modular stack

all the way down from the infrastructure layer and going all the way up to the application layer when develop where developers can pick and choose the different components that they use to build their applications that are best suited for their apps and we're now starting to see this in the blockchain technology stack and lazy ledger is just one component it's the consensus component in that broader technology stack the other reason why i think this is interesting is its simplicity lazy ledger does one thing it does consensus-based time-stamped ordering of data and beyond crypto finance there's a whole universe of applications that exist that could leverage this very thing so if you look at the entire enterprise blockchain application space

i would say most of those applications are trying to establish a single source of truth between participants that don't trust each other and as we've seen a blockchain isn't always the best technology for these applications and so i think having something like lazy ledger as a publicly available single source of truth has tremendous potential for all kinds of applications outside of crypto finance if you're thinking of building a crypto finance application you should definitely check out algorand because their unique design makes it easy for developers to build sophisticated apps algorand is fast it's secure it scales it has instant finality and it's designed with all of the purpose-built

building blocks that you need to build your next defy app i'll tell you a little bit more about that during the interview but for now here's our conversation with ishmael kofi and mustafa al-basam hi so we're here today with ishmael coffee and mustafa albasan the co-founders of lazy ledger so lazy lecture is this very innovative new kind of blockchain layer 2 type protocol that we're going to dive into today so yeah thanks so much for joining us today guys thank you for having us thanks a lot for inviting us i'm very excited to be here yeah absolutely so am i well let's start there i mean mustafa you have like a

very interesting background i was watching this talk of years before at some hacker conference where he talked about all uh the the work he did in anonymous and this thing called lols do you mind going into a little bit like what's your history there and you know how did that lead you to crypto in the end sure so that was um actually a very long time ago when i was a teenager i was involved in various hacker groups and including anonymous and i co-founded a hacker group called dalsek which compromised many corporations and governmental entities this was when i'm about 15 16 years old and um in terms of um how it relates to

crypto i guess not much um but that was a very interesting time and i've moved on to other things i mean i guess there's at least like some kind of similarity in you know the both potentially these you know disruptive activities going against the status quo do you see some similarity there between the two fields or yeah i mean yeah i mean for sure i guess that's uh in that sense is quite similar to crypto in the sense that there's you know similar political ideals and sort of philosophies you know the hacker movement um and the and the crypto cypherpunk movement are all

interlinked with each other and i guess the i guess the ideals and that and kind of drove my activism as a teenager kind of also drives the same ideals that makes me very interested in cryptography which is to you know give people more freedom and back then it was motivated by freedom of speech and i guess um financial transactions are a form of speech and cryptocurrency allows people to transact money freely and so what were how did you like uh first get involved with the crypto space like what was your first foray into the field so i first kind of heard about bitcoin in um

2010 2009 but even before i heard about bitcoin i was always very interested in peer-to-peer systems in general like i was very interested in bittorrent for example and i was very closely following a website called the pirate bay which was like the biggest or still is the biggest torrent tracker and where people kind of upload copyrighted movies and software and uh that and the kind of the kind of idea of creating decentralized protocols was very interesting to me and um so one bitcoin when i had about bitcoin um that was naturally very interesting to me

i kind of um even though i heard about it kind of 2010 i only really got involved in a full-time capacity in 2016 when i started doing a phd in london at the university college london focusing on the topic of on-chain scalability and i was specifically very interested in that topic because i was very closely following the bitcoin community you know from 2010 onwards and um i was always thinking about the one megabyte block size limit um in bitcoin and even before there was a massive debate on the bitcoin community when the bitcoin the block size limits

started getting reached and transaction fees kind of skyrocketing skyrocketing there's a whole kind of huge debate about how we should scale bitcoin you know if on-chain scalability is even possible to do securely even before that i was actually very worried about this block size limit and you know permanent bitcoin community members like um gregory maxwell you know told me that this is this isn't really a problem and we shouldn't worry about this so i started doing research on unchanged scalability to figure out how we can actually scale blockchain securely in a decentralized way on layer one and uh as part of my phd i was a co-author on a paper called chain space

which was one of the first uh proposals for a sharding a charted blockchain design and that was later spun out into a company based in london and that company was um well actually the company was based in gibraltar but um developers were based in london and that company um was later acquired by facebook and now many of the people involved are working on facebook's libra project and ishmael how about you i know you have a lot of background as well and like distributed systems and peer-to-peer stuff how did you get involved with the space so i think the time frame is actually uh very similar to mustafa's so i was

interested in distributed systems and decentralized systems for a while and after after i finished my studies and i don't remember actually exactly when it was but around like 2015 i was like really interested and tried to get like more involved uh into it and i was working at the research institute at fraunhofer and like i was proposing to like do something into that direction and i was like uh believing that this is like this will get bigger and more relevant in the future but there was no space uh for for that in in that um job so basically i was looking around for something where i can like dive in more deeply into research but like

also um work a bit on like actually implementing uh real world systems and i found this exactly at epfl at the dds lab like the distributed and decentralized systems lab of brian ford where one of the goals was also to like scale bitcoin and um so like brian does basically everything and it was a very like very chaotic and very interesting year where i learned a lot where i was at epfl and we like um co-authored a bunch of papers there as well um one about like scaling bitcoin as well it's called bitcoin but also um

we did a bunch of research or like work in in privacy preserving technology and all this so this is where i think learned so much in like very little time because i had to because like i had to implement bunch of these systems um in a team though like it was not uh i was not like the the the only person in the team with like a team of three engineers which is quite unique i think at university or in academia yeah so after that i briefly started a phd as well and did a detour as in as in as a phd internship at google where i worked on something like uh konigs well basically it is conics so

it's like google has this project called key transparency which is very similar to conics but like they use a log to put designed basically they don't just chain it but like they put the tree roots the sparse mercury roots in the log and so basically after that i decided okay there's so much happening and there's so much going on it's probably not the best idea to stay in academia and also at that time i i met with zaki in london and he was already he was already kind of hinting that there might be hiring a tendermint and it took a few months later

that i actually almost a year later actually that i started the tournament as well and there i got pretty much involved in the in the like knee-deep implementation side of like layer one blockchains and so how did you guys end up meeting and like starting to work on lazy ledger so this is a very good question i i knew mustafa already for quite a while from like twitter and online and i've been going to these like hacker conferences um the cares communication congress where he's like also been always present and uh i think we met more and talked more during my time at epfl i guess and we

met at academic conferences and he approached me about lazy ledger at the the camp and yeah he had like this this research paper and i read it and i found like i didn't fully understand it in in when like when i first read it and i had a bunch of questions but like i immediately seen the potential there and uh yeah then we started working we started working on that um shortly after basically so basically i i asked ismail to join this ledger in the middle of a field about 50 50 miles north of berlin with a bunch of them yeah like a little hacker village back in january we interviewed steve

coquinos and sylvia mccally of al grand and during our conversation we talked about how algorithm's unique design makes it easy for developers to build sophisticated applications on their platform so what's great about algorand beyond the fact that it's fast it's secure it scales and it has instant finality is the fact that they've designed a layer 1 protocol with primitives that are purpose built for d5 so what that means is that they've taken some of the most common things that people do with smart contracts and they've embedded them right in the system right in the layer one so things like issuing tokens atomic transfers well these are built into the layer one and smart contracts are first class citizens on all grant so with these essential building blocks at your disposal you can build fast and secure defy apps in no time

to learn more about what algorand brings to the table and how to get started i would encourage you to check out algrand.com epicenter that lets them know that you heard about it from us and it takes you where you need to go to learn about their tech and with that we'd like to thank al goran for supporting the podcast [Music] so lazy ledger it like a lot of it's derived from like the the sort of like data availability paper that uh you co-authored from a couple of months ago so was was that paper like sort of like did you have that in in mind that hey i want to like create this like lazy ledger project and that paper was like sort of sort of the white paper for it or

did the paper come first and then after that you were like hey how do we build productionize this so you're referring to the paper that i wrote with vitali yeah i guess to give some context first about that paper um so that that was a paper about something um called fraud and data availability proofs and it was basically solving a fundamental problem in sharding was kind of like the missing piece of the puzzle or like not maybe the missing the biggest missing piece of the puzzle to make sharding complete uh which is well if you increase on chain three port if you increase the number of transactions

that people can post on the chain and regardless of how you do that whether it be through sharding or increasing the block size limit you also need a way for people to verify the entire chain efficiently and the question is like how can you do that uh without requiring everyone to download every single transaction in every single shard shot to make sure every single transaction is valid and that's very important to scale because the whole point of blockchains is that they're decentralized and the reason why they're decentralized is because anyone can publicly verify that the blockchain

is correct and the transactions are valid but you can't do that cheaply if there's a lot of transactions to verify and that's why the bitcoin community has been reluctant to increase the block size limit to more than one one about one megabyte because it would um it wouldn't make it possible anymore for people to verify um the blocks using raspberry pi's basically and so this so um there's this idea of fraud proofs and the idea of fraud proofs is that instead of verifying um instead of that instead of verifying every transaction yourself what you can do is you can assume that

the blocks are valid or specifically the blocks that have consensus are valid and if they're not then someone or any any person or any node on the network can generate a very succinct and small proof called a fraud proof and or more specifically what's called a state transition fraud proof to prove to you that block is invalid and you can reject that block and so therefore you can kind of indirectly verify the whole chain with very little resources but in order to for you to be able to do that another kind of prerequisite called data availability proofs because um you can only generate a fraud

proof for a block if the data for that block has been actually published by the miner or this or the block producer because what the miner might do is simply publish um the header of that block or what was called the block header but not actually publish the actual data in that block and so what data availability previews allow you to do is substantially convince yourself or efficiently convince yourself that the block has actually been published without downloading the block yourself now laser ledger uses this data availability proof primitive to make it very efficient for people to to prove um to themselves that the data has been

published in blocks however the idea of these ledger itself actually came about long before this pit this this fraud newspaper the idea of lazy ledger i started thinking about it when i was starting my phd i was thinking about what are some alternative design paradigms that we could use to to build layer ones or more specifically what what is the most minimal layer one you can build or like the most kind of modular basically one you can build to to build a cryptocurrency on or to allow for cryptocurrencies to exist and how can we scale that and so this data availability proves primitive and made that much more practical

and scalable cool thanks that was i think that was a great explanation already and sort of a great intro to lazy ledger before we go into kind of you know the details from lazy ledger i'm curious like what do you guys want the impact of lazy lecture to be so as i mentioned right legend ledger is um basically you can think of lazy ledger as a very basic layer one i would call it the minimum viable layer one so if you strip back layer one to its core components and you made it as scalable as possible using existing technology

you would get lazy ledger so effectively lazy ledger in simple terms is basically a a blockchain where people can dump arbitrary data onto it and that data gets ordered and the consensus nodes don't care or process what that data is and so you so it's basically a blockchain for dumping data on and you and the data gets ordered and you can use this as a primitive to build um all kinds of applications and blockchains now what this is really useful for or what this has impact for and i guess to explain the overall kind of vision is as follows so when bitcoin came about

um the the kind of vision for bitcoin was or i guess the technical architecture for bitcoin was that it was using a blockchain for one purpose or for or for one application and that application is cryptocurrency or payments or store value or depending on who you talk to so it's basically a single purpose blockchain then um ethereum came about and the idea of ethereum was um let's actually create a general purpose blockchain where you can for every application that has a kind of general purpose virtual machine where people can upload smart contracts and so those architectural versions were

like very stark opposites to each other and at the same time there was tendermint and tendermint was more similar to bitcoin's vision where the idea of tenement is that it allows you to create your own blockchain for your own application so and so at the moment basically if you wanted to create a application on a blockchain there's only really two ways to do that and the first way to do that is you use a shared execution environment or a shared computer like ethereum you you code up your smart contract you upload it to ethereum and your smart contract runs on the same i guess machine or the same chain as

everyone else's smart contract and that's basically the world computer model and that ethereum kind of created the and the problem with that is that um the ethereum virtual machine is very limited uh in terms of what you can deploy on it and it has very high gas costs if you want to build applications that the ethereum virtual machine does not natively support such as for example complicated cryptography or cryptographic proofs that don't have native built-in functionality in the evm so if you want to do that if you want to build more complicated applications that the epm doesn't support you have to basically build your own blockchain

using something like tendermint but the problem with tendermint is or not the problem but i guess the drawback of tender means is that or any kind of solution like tendermint is that you in order to create your own blockchain there's a huge overhead for creating your own blockchain there's a lot of work involved in creating your own blockchain because when you also when you create your own blockchain you also have to create your own layer one for that blockchain you have to create your own consensus layer and that consensus layer nowadays is usually based on proof of stake which is what tendermint provides for you and to do to deploy a proof of stake network it takes a lot of work you have to for example create a token sale you have to

make make sure that's distributed decentralized way you have to make sure there's lots of validators and so on and so forth so what late where latest ledger comes in laser laser based ledger provides a modular pluggable layer one that does nothing but consensus and data availability layer one uh the laser stage layer one does not do smart contracts or execution layer one the literature layer one basically does the does the core things that a layer one does and nothing else and that makes it very useful as a plugable layer one for people that want to create their own chains but don't want to go to the overhead

of having to create the consensus network instead they can simply plug laser ledger in to their chain as a consensus layer by simply dumping the change blocks on this ledger so could you maybe walk through a little bit of like the architecture how what that would look like and you know one way of thinking about it is like you're kind of building the minimum viable blockchain in the sense that it's basically just a time stamping system right like you're getting consensus on ordering of transactions but like nothing else about the transactions and so this was actually like the idea of a lot of the early bitcoin extensions things like colored

coins for example so could you maybe compare talk a little bit how these compare to those sure so uh yeah so before before ethereum existed there were various projects to kind of extend bitcoin to support many applications and the kind of like overall basis of those of those proposals was where to basically um embed data into bitcoin transactions and using an operation code called op return so when you submit a bitcoin transaction you can attach a bit of data to it and so that basically allows you to timestamp or get consents or order arbitrary data using the bitcoin blockchain and so

that's why projects like um colored coin and mastercoin effectively using bitcoin as a data layer um to dump data on and and that allows them to basically um create all these other applications um like smart contracts and other smart contracts but more like specific other applications that are relevant to bitcoin i kind of i guess um some people would say abusing the bitcoin blockchain by by dumping data that it was not designed to receive and the difference with lazy ledger is that lazy ledger is designed for that specific purpose and it's it's designed to be more scalable for that specific purpose in its architecture and also in its

primitives including data availability proofs which allows nodes to verify the entire lazy ledger chain without having to download every block which is what you would have to do in bitcoin um right now if you were running a master coin node you would need to download every single bitcoin block basically to make sure that the validity of the mask master coin data is valid i mean isn't one of the nice features in a way you could think of it proof of work is like a consensus protocol that directly incentivizes data availability because if you're not making your data available no one el no other miner is going to build on top

of your blocks maybe that's like a reason why bitcoin wouldn't need data availability proofs like if i had data and i wanted to make it available i could put it on the bitcoin blockchain and have with like very very high level of like certainty that that data will be available just because of the nature of the bitcoin network and like how widely distributed it is and the fact that it's proof of war kind of incentivizes widespread distribution of the data so why wouldn't i want to just do that so basically there's several things to this um so with bitcoin that's okay because bitcoin is like a single execution environment but the problem is with if you wanted to create kind of like a general purpose

data availability layer you can't just rely on the consensus and the word of the consensus to tell you that the data is valid uh for two reasons so first of all the threat model of bitcoin and ethereum are such that um even if the consensus even if there's a 51 attack on the consensus that the consensus cannot steal money or cannot insert malicious state into the chain the only thing they can do is sense the transactions or reverse transactions now with applications or with um blockchains that simply or or solutions like optimistic rollup side chains

that use a data availability layer like baseledger if you configure the nodes in those systems to simply trust the consensus to tell you that the data is available then if the consensus is dishonest then they could potentially lie to you and inject invalid state to the system that you would never know about and that significantly increases the incentive for doing a 50 or mass attack because the financial reward for doing a 51 attack no longer becomes you just double spending a transaction but the reward becomes potentially injecting military state that generates unlimited money or steal

people's money so that's the first reason and second reason is that with a general purpose data over the birth layer there may be many different applications or chains that don't necessarily connect to each other or are independent of each other that are using the same data availability layer and you don't want to end up in a situation where you effectively have to download every single you have download irrelevant data for other chains to verify the data for your chain and so data availability proofs allow you to verify um that the kind of the data for the entire system is available without downloading the data for other

changes so one of the advantages here would be it's very good at like domain separating and like querying this so like one of the problems if i wanted let's say uh i wanted to store data on bitcoin like as an example you know i had this idea once of storing uh all tendermint uh like cosmos hub uh validator set changes on the bitcoin blockchain so it it's there as like a long-range attack prevention but then the problem there is that finding one of these transactions on the bitcoin blockchain is really hard you kind of have to like scan through every transaction and so one of the benefits of having a specialized like something that's specialized for data availability is it will be very it's much easier for me to like query

for particular properties of transactions yeah exactly so uh because with laser ledger we expect the chain to be used by many different applications or side chains or execution environments that coexist with each other that don't necessarily communicate with each other and so we need an efficient way to allow nodes in each of these applications to query the data relevant to the specific application without having to care about the data for other applications and the way that we achieve this is we basically um use something called a namespaced merkle tree

which is kind of like a kind of like a modified malware tree that basically allows you to query for specific messages in that tree for specific applications and each application has what's called its own namespace identifier so you basically query for the namespace identifier that you're interested in and you can very kind of efficiently kind of verify that yes the node that you're looking to has given you all the relevant transactions for the application that are in that block so i mean you mentioned read like any ethereum for example right like you

you have this transaction ordering but you also have to transaction execution and so you guys are getting rid of that part so i'm curious like what are the downsides of this you know what you give up yeah so it's a good question right so you can think of it basically as we're pushing the execution to layer two and uh in terms of what you give up it kind of depends on as we mentioned or to clarify um there is no kind of user execution environment on lazy ledger therefore developers have to define their own execution environments using something like cosmos

or the ethereum virtual machine or one of the many optimistic roll-up sidechain implementations out there just on that so developers have to define their own execution environment like let's say using cosmos as an example can you explain what that would actually look like if somebody wanted to to do something like that sure so effectively i guess as i mentioned lazy ledger is basically a chain where people dump arbitrary data onto it or any data they want onto it and that data gets included in the blocks and the blocks get ordered and and each application has its own name space id so if you were to build a

cosmos sdk uh based chain that wanted let's say you okay let's say for example that you wanted to build a cosmos sdk app but you do not want to go to the overhead of having to actually create your own uh proof of stake network using tendermint so what you would do is you would you would create your own cosmos sdk chain and then you would post the blocks of those christmas of the cosmos sdk chain directly on lazy ledger and that would basically give you consensus for that cosmos sdk chain because the blocks immediately get ordered and so it's like that the blocks are within the laser ledger blocks

so it's kind of like a sub blocks if you like when you keep agreement about like how to execute those blocks and like let's say let's say there's like a now we have an upgrade of this like cosmos sdk chain and like you know in cosmos we know this process okay on chain governance and then hard fork and whatnot like what would that look like here so that's all defined on layer two because on the lace ledger layer one the laser led layer one has no concept of what transactions are valid or not instead all of those concepts are defined by the users or by the or by the cosmos sdk

app itself so all the users that use the your cosmos sdk app will know which transactions are valid or not because they have the code for your cosmos sdk app and so because your the code for your cosmos sdk app basically defines what the execution rules are and what transactions are valid or not maybe i can add to this like you can still have like governance proposals and and all this like on on the optimistic wall app right i mean you you could basically have something um built completely with the cosmos sdk but you replace for instance like this is uh

how like from an implementation point of view where we're looking at it right now is from you use the cosmos sdk you can use all the modules but you replace on the optimistic roll-up you replace tenement which like additionally provides consensus which you don't need in the in the optimistic wall up you would replace it with another what's called like abci client so we we would um implement our own node that like fulfills the the tenement side of the of the abci contract this would be used instead and then you could ideally could use all the sdk modules for instance don't you still need consensus though for on the state route like let's say because you know

the lazy lecture side is giving you consensus on transaction ordering but then that would mean that anyone who wants to interact with this chain now has to like actually run all the software but realistically oftentimes like clients just want to query something that's currently in state and so for that you want some sort of consensus on state route yeah that that's right so so i guess i think this is a good point to kind of talk about a little bit about optimistic roll-ups and um assuming that your your listeners might not be familiar with them this is basically our answer to kind of consensus on stage roots if you like so going back to the kind of cosmos sdk example you might have you might create your own

cosmos app and you post the blocks for the cosmos app onto lazy ledger and these blocks have block headers and these block headers contain stage routes and these stage routes can be used by like clients so then the question kind of becomes i mean i guess that kind of answers your question partially but then the other question kind of becomes um well who gets to actually post these blocks i'm like what if people post invalid blocks and the way that kind of optimistic roll-ups work optimistic roll-ups is basically this kind of sidechain technology where you can create side chains that use

a another layer one as a data availability layer and the whole kind of concept is that it's it's on-chain data availability but off-chain execution so the execution for your side chain happens of chain but the the data availability for your side chain happens on chain on on some other layer one like ethereum or lazy ledger so in optimistic roll-ups um there's something or there's a node called the the aggregator and the job of the aggregator is to collect transactions for that sidechain and to aggregate them into blocks and then submit that block

to the data availability layer now what happens if the aggregator submits that invalid block and so first of all i should add by the way um in many of these optimistic world proposals anyone can be an aggregator and so the question is what if the aggregator submits invalid block then what would happen is basically a ford proof can be generated and because the data for that block is available to everyone because it's been published on the data availability layer and because that's the case anyone that's watching the change can generate a fraud proof to prove that they may they have generated an invalid block with an invalid state route

so is lazy ledger going to provide this sort of fraud proof place to like do fraud proofs or would that happen on another chain like ethereum uh well i mean the fraud proves themselves they don't have to be posted on chain uh i mean the fraud proof system is a is also a layer i mean like the challenge game that like where would the challenge game take place um so so that depends on the layer two because all of this execution stuff is orthogonal to the or or irrelevant to this layer one so on layer two there's different ways of doing it and i guess the simplest way of doing it is um basically it's the case that each kind of optimistic roll-up chain has its own kind of sub network

where like the users of that of that chain communicate with each other and if someone generates a fraud proof then that fraud proof gets generally gets distributed and propagated across that side chains peer-to-peer network and that allows all the users in that side chain to uh verify that the block is actually invalid also i know you guys have a third team member uh john adler and i believe he also has another project he works on called fuel labs which is like an optimistic roll-up system on ethereum so what's sort of like the relationship between two these two projects john is like the chief research officer at um lazy ledger well not liked but

he's the gcps officer he uh he's also working he's actually the person he proposed i had the optimistic roll-ups a year ago and fueled labs is basically um a optimistic roll up a sidechain library for ethereum or specifically it's an evm based or evm compatible actually have optimistic roll-up implementation that allows you to do payments and so the idea is that in the future um fuel labs will also support other data available layers other than ethereum and such as laser ledger

and the main advantage of that is that because these ledger is designed from the ground up to be a scalable data available layer and you'll be able to process much more transactions on laser ledger than ethereum so like you know i'm not i'm more familiar with like the optimism team's roll-up design but there you know i send transactions to the operator and then the operators uh put them onto you know for that they just store it in the call data of an ethereum block so in your model where like a lazy ledger plus a roll up are users submitting transactions to the operator who then

puts a block and stores them on lazy ledger or are users submitting transactions directly to lazy ledger and then the operator picks them off from the lazy lecture chain no so so it's the first one so the um the users submit the transactions directly to the aggregator and then the aggregator aggregates them into a single block and that's the block that gets posted onto um as ledger but i should say that the original model of lazy ledger was actually the second option because um either this ledger paper was released before the idea of optimistic wall-ups came about and so the original model

was that simply users would simply submit the transactions directly onto the onto the ledger main chain but that had some major drawbacks because specifically because it meant that every users have to basically process every everyone else's or the users have to specifically process every other user's transaction and like clients won't be supported because there's no kind of fraud proofs involved and there's no aggregator to create a state route i'm curious about transaction fees in this world would you have potentially like transaction fee on the lazy leisure level and then potentially also transaction fees

on the level of the particular application running on it and like how do you see that working yeah so there'll definitely be a transaction fees on the laser ledger main chain and these will basically be very straightforward it's basically storage fees because on the laser ledger main chain nodes don't actually process or care about the contents of your messages and transactions they simply just take them and put them on the chain so there's no cost to ex there's no execution costs or considerations yeah exactly more like in bitcoin right where it's basically depending on the size exactly so the transaction fees

will be solely dependent on the size of the transactions and that being said um you can you can implement gas fees on the execution environments or the layer 2 chains that people build on this ledger so if and that's that would be specifically useful if you wanted to create a general smart contract platform using this ledger as a data flow point layer then you can implement gas feeds however um the main kind of the main vision for lace ledger i i envision is that people will use it to build app specific chains i.e uh chains for their own for one app each app has

its own chain and in that model you don't really need them gas fees because like you can just directly hard code the um kind of the the fees for the actual transactions in your app because there's like limited amount of you know methods in in the app yeah i'm also curious so you have these different apps then to what extent would different apps that are running on top of lazy ledger be interoperable you know like via and yeah how would that work sure so um the interoperability aspect is also a layer 2 concern and is dependent on the execution environment that chains use if the chains are using

it using a cosmos sdk based execution environment then they could use ibc or which is short for the inter blockchain communication protocol which is the protocol that cosmos has developed to allow cosmos chains to communicate with each other so that's on the layer two layer two side of things on the layer one side of things we want to make it possible for people on other other layer ones like ethereum to develop smart contracts that use laser ledger as a data availability layer so so for example like you might develop an ethereum smart contract that is very data heavy and you might

want to you might find it cheaper to post that data on lazy ledger but you will need a way for that ethereum smart contract to verify that that data has been posted on this ledger and so for that we're developing um a laser ledger ethereum bridge where basically the laser ledger block headers are posted onto the ethereum chain that will allow you to verify that certain pieces of data have been included in this ledger via an ethereum smart contract so one of the main things about this lazy ledger project is like it's not just you know you could have just you know a tendermint chain chugging along and then

restoring transactions on there and you could do all this like uh layer two like stuff but on top of that you all guys also do these like sort of data availability guarantees for each all the transactions so before we even get into how those proofs work i'm kind of actually struggling a little bit to seeing why they're necessary because if you have a tendermint chain isn't that already giving you some sort of data availability because let's say you have a hundred validators on your tendermint chain tenor main consensus as long as you have some honest validators they're not supposed to sign pre-votes unless they have

the full block proposal so the just the fact that you have as long as you have one-third validators being honest in the sense that they're not just signing stuff without getting the proposal you're kind of guaranteed that all the honest validators all the honest validators at least have access to the data so why is that not sufficient sure so this is going back to the um threat models so one third module or one security model might be put for data availability might be as you described which is let's just assume that uh two-thirds of validators are honest

and they will only sign valid blocks or even one-third has to be honest sorry one said yeah i have to be honest and and and you sign they were only saying valid blocks when you say that that sounds very reasonable but when you actually compare this to the um bitcoin and ethereum security model and you understand the applications of this this is much much less secure than those models because with bitcoin and ethereum at the moment if there's a 51 attack and the consensus goes rogue and dishonest the worst thing that could happen is that the rogue and malicious consensus can either censor transactions or undo

transactions what they can't do they can't inject or insert invalid transactions to the chain and they also can't hide transactions so they can't make data unavailable um because like the kind of validity rule on bitcoin ethereum is such that the full nodes also verify the data availability of the chain if you start assuming that one third of validators are honest for other things not just for double spending if you start assuming that they're honest for things like data availability and validity of state that completely

changes the threat model and that completely changes incentives for doing such an attack because at the moment there isn't really a big incentive for doing a 50 or 51 attack because from from economic perspective at least because the worst thing you can do is um undo transactions and do double spending attacks so like maybe you can like buy maybe maybe the best case scenario you can buy a tesla or something with bitcoin or some expensive car like let's say it's worth 100k or something some some supercar and then like do a 51 percent attack and then undo that and do that transaction and you've got a free sports car but um that's for the bitcoin model but

if you start assuming um the consensus is honest for other things like state availability then the consensus can steal everyone's money so like that's a lot more profitable than getting a free sports car yeah so you need one third honest but you can turn that into like one-third rational by adding in like challenge game so let's say okay here's an example let's say i i create tournament and then i say okay in the next every validator gets a random challenge saying like hey give me the nth leaf in the merkle tree and every validator has to with their next vote like uh in like

consensus they have to include their piece in that and so now it's and if they don't then they're like slashable right or their votes just don't get counted and so now you suddenly turn that honesty assumption into like a rationality assumption where okay every validator now does have an incentive to not they will say i need the data before i sign a pre-vote because if i don't get the data i'm not going to be able to answer the challenge next time and so now you're not even depending on honesty anymore right by the way so what you're proposing is basically um i guess a naive um protocol to prove data availability

which is basically you know what what would what we're doing right yeah so at that point i think we kind of agree that you do need data availability you need to kind of verify or like i guess like you you need to i guess okay i guess what you're saying is slightly different in the sense that the node the end clients themselves aren't verifying data availability but you're kind of incentivizing um miners to be honest so what your propriety so what you're proposing is basically um something similar to what's called a proof of custody scheme well what that basically that proves that um so i mean there's two problems that you proposed

so the first problem that that allows the miners to prove that they have the data but it does not prove that they've actually published the data like that's the first problem and because they're only publishing a very small part up there and then the second problem is i guess kind of related to the first problem which is that that only proves that they have a very small path of data well in reality you need 100 of data to be available because you can hide an invalid transaction in a very small part of the block just like 100 bytes but it's but it's random right so that's so the part that they're challenged with is going to be random so they need to

have the whole block in order to have guarantees that they could provide a random data and the the point here is it's turning it so you only need one honest validator to make sure the data is available right so you're no longer depending on like all validators being honest or the proposer being honest or one-third being honest as long as you have one honest validator the data will be available how how like which part of the block or like how much of the block will they have to publish in the challenge like let's say like one percent for example right and so that's not that's not good enough because um that means this is effectively a 99 chance of them winning um the challenge without actually having that there so

that's the yeah so what that's what that's why we use erasure coding uh in data availability proofs because like because our data availabilities brief um scheme is basically a glorified version of whatever post using like some fancy stuff like erasure coding to make the probability of this some of these is a very high probability um guarantee that the data is actually published i'm happy to kind of go into detail a little bit to explain how the scheme works yeah that'd be great sure yeah i mean that's a good kind of place to start so the way it works is basically so first of all i should explain what erasure coding is right erasure coding is this kind of

like mathematical primitive a very old mathematical primitive that was i think first discovered in about the 50s and it's a piece of technology using all kinds of like technology like cd cd-roms and satellites and stuff like that and what basically allows you to do is um if you have a piece of data let's say one megabyte big and let's say you lose some of that data or let's say you lose half of that data so let's say whether you're running with your one megabyte one megabyte file you lose 500 kilobytes of the data and you can still recover the entire one megabyte file

with only half half there because what you basically do is let's say you have a 500 kilobyte file what you do is you you apply this erasure coding scheme onto it and what that does is it it blows up that file to one megabyte big and the kind of extra 500 kilobytes of that file is not your original laser but what's called the erasure code which is kind of like and which is kind of like this kind of like um all goes to mathematics of it but it's basically it creates extra redundancy for your file such that it makes it such that if you

lose half of data you can recover the whole data thanks to this extra part of the file that you included called the erasure code so so what we do basically is when we create a new block usually in bitcoin ethereum when a miner creates a block they commit to a medical route of all data in that block and so what we say is is that instead of committing to the numerical routes of data of that block you commit to the erasure coded version of the data of that block so if the block was originally one megabyte big and there's one megabyte of transactions you apply the coding scheme onto it

and the block the transaction size becomes two big two megabytes big the latter one megabyte becomes the code itself and then you commit to the medical root of that data which is block header and so what that creates is basically this property where let's suppose a minor is malicious and wants to hide even one single byte in that block let's say they want to withhold one byte in that block in order to hold one byte of that block they have to withhold half the block because they can't just hold one by after block because um you can become you can recover that byte from the erasure code the only way you can hide that byte is

if you can if you if you hide or if you withhold half of that block and so that basically makes it possible to create this kind of challenge scheme based on random sampling because let's say that you're a client or you're a nerd that wants to check that all the data in the block has been published but you're too lazy or you don't have the resources to download the entire blog so what you do is you ask any leader of the network to give you 10 for example 10 random pieces of the block and for each for for each sample that you ask

in that block there's a 50 chance that you will hit the portion of the block that has been withheld right and then if you do two samples there's a 75 chance if you do three samples there's 87.5 chance and so on and so forth until you get to a situation where you do 16 samples there's a 99 chance that you've sampled a part of the block the the half of the block that the miner has withheld and therefore you will not get a response to your sample request and therefore you can assume that the block is not available doesn't that assume that the miner like

pre-decided what to withhold like let's say the original data is 100 bytes the new encoded data is 200 bytes no matter what i request for the first 99 the miner will be like oh yeah here's the right here's the thing it's only when i hit the 100th request then the miner will say i'm going to stop now i'm not going to reply yeah that's that's exactly right so in order for this scheme to work there has to be a minimum number of nodes that are actually sampling enough samples from each block such that the miner is forced to release more than half of the block and under a naive kind of or basic network model then

the miner could uh successfully pass all the sampling challenges for the for those first few like clients and then whether that's acceptable or not depends on how big a network is so with bitcoin for example there's one million like clients uh according to google play's bitcoin wallet downloaded statistic and um with reasonable net parameters you can only fool a couple hundred like clients so there's a very few like that's a very few number of like clients such that the attack is not really worth the cost however if that's not acceptable to you or if you have a much smaller network then you can um

use a more advanced network model such that you make each sampling request through a mixed network or you use um a kind of uh onion network like tor and you kind of add a mix network on top of that and it basically makes it such that each sampling request is um sent a kind of like a uniformly random time and that makes it impossible for the binary to link each sample request to each specific like client and that basically thwarts that attack but so is the idea here that like clients would inform each ot are like let's say let's say there's a

hundred like clients right talking to a validator and for ninety percent of them the validator can't ends up not responding like properly but for ten percent of them it's like you know they got it got lucky and they only requested stuff that wasn't withheld so how are like clients supposed to like inform each other saying like hey you know maybe in your challenge game with the miner it looked available but to me it didn't work out how do they inform each other of this uh well i mean there's no need to inform each other and the data availability kind of challenge does not require any cooperation and well i mean not i mean the data availability proves

themselves they don't doesn't require any cooperation between like clients and you only need to verify it for yourself to be convinced but yeah let's say like you know back to the attack i was describing earlier where like it gives 40 the miner gives 49 of the data to anyone and it could be a different 49 but the all the like clients need a way of like coordinating let's say the yeah let's say the miner only gives 49 to anyone the al all the like clients now need a way of like combining their own 49 percent to like recreate the original yeah that's right data right yeah so they need to cooperate to um share the data with each other but they they don't need to cooperate

for the actual part of convincing themselves whether their data is available or not so they have so they do have to cooperate to reach to work together to reconstruct there and you can basically use bittorrent for this for example you can basically represent the block as a bittorrent file and different peers in that bittorrent file can have different chunks and they can share share with each other yeah any any peer-to-peer network works like because they also use ipfs or whatever yeah so one of the challenges here is how do you turn this into a non-interactive proof right like so i i see this is sort of a very interactive game i can convince

myself but that like data is available but like on roll up let's say i have a roll up on ethereum i need to tell the before the smart contract ethereum should accept the state route it should have some non-interactive proof that the data is available so how do i construct that yeah so um i've been i and others have been thinking about and non-interactive proofs a lot um so i mean there's different definitions of non-interactive proof if you're talking about like can i generate some string of data and i i can give you that string up to conv and that string of data can convince you that some other piece of data is

available on that on the internet as far as i know that's not possible um i've tried to construct schemes do this but um require a lot of assumptions and basically it's not really practical however if you're talking if you're talking about more generality the goal of like verifying data availability proofs on ethereum and there's there's two ways of looking at this well with our current plan to create a laser ledger to ethereum bridge the ethereum part of the bridge does not verify that availability proofs for this ledger and therefore on the ethereum ethereum side of the bridge

does make a um on this majority assumption for the consensus and it assumes the consensus is honest and his only signing blocks are actually available uh which is problematic for the reasons that i propose but it's okay for certain applications that i can describe later the second way of looking at it is there have been proposals in ethereum research to kind of allow ethereum to and vitalik has also made this proposal to allow ethereum to validate user specified data availability routes and that will basically make it possible for ethereum to verify

data availability proofs for third party chains so that you can basically submit like um the medical route of some data to ethereum and this could be like a special op code that is added in the future hard fork and the ethereum chain would basically verify the data availability of of this other specified medical route using its availability proofs by making the sampling requests and the node the the nodes that are verifying the chain itself to have to do this okay cool ishmael i'm because you mind diving into a little bit i mean you guys are built like what's kind of the connection between like lazy ledger and like cosmos sdk

or is this currently being developed like us yeah can you expand a bit on that sure so the current plan is to use so for the lazy ledger layer one we will use tenement for consensus and mustafa originally proposed to not have any state execution on on the layer one so it's like the the purest form of lazy ledger um but then we'd have to define um we would have to define the pos layer like a proof of stake layer as well as a rollup so and then as we have to do this execution anyway so i think for a first implementation we will go with using the cosmos sdk as much as possible and do

that part of the execution like the minimal amount of execution to have like a proof of stake network on the uh layer one so on lazy ledger basically and then so in that sense we will use the the the cosmos sdk as much as possible and then for the optimistic rollups one way to to build these is to use um the sdk as well ideally we would like abstract away is the wrong word because like it's already abstracted way through abc i you would like yeah we will remove tenement from the cosmos sdk in their sense that like the dependence on that and write our own abci client for instance and then people could use

the sdk to write their optimistic wall apps yeah cool very interesting well i mean let's dive into a little bit like if lazy ledger launches as this layer one like how do you think that will kind of compete with other layer ones you know whether that's an ethereum or solana or various others that are coming along yeah how will it differentiate and for what kind of use cases do you think will be better or worse versus those one that i'd actually be especially interested in is file coin how does like sort of how do you see this in comparison to file coin as well as far as i understand for instance fight coin doesn't do ordering right

like it's it's more of a like dumping data only right and i think um in lazy ledger like if you if your application needs to dump data like it needs the ordering of that data then you would you you would prefer lazy later but if the roll-up operator is the one picking the order and then submitting it to the lazy ledger chain then well depends what you what you say the data is and and when i like when i said like the data um i was speaking more or generally in that case the data would be the roll-up the block itself so and then obviously you'd have an ordering travel chain um but like for other applications um it could be like ethereum applications you you need

um to dump data to be available but also like ordered that then you couldn't just use uh vitecoin as far as i understand back to brian's question right you asked like what kind of applications would like preferably build on on lazy ledger i think if you want to build like a application specific blockchain or like uh you have a cool idea for your fancy um blockchain and decentralized app so you could do this um with lazy ledger in a very simple way because like you you don't need to assemble that that validator set like the the proof of stake network as mustafa mentioned earlier

so like you'd have the easiness of like ethereum of like deploying a smart contract and and you could launch here you could launch your app without um any any further hassle basically like in an ideal world you could like just deploy it in like in a few minutes basically that would be a deal cool and when this lazy ledger chain launches i mean if it's it's a proof-of-stake chain right so i guess it will have some sort of staking token do you see any other role for that token besides just you know validators putting up a bond right it will also be used to um pay the fees to submit the data

right probably i mean mustafa can say more to that but like probably the optimistic wall up chains could also use the lazy ledger native token they don't need to to define their own token if they don't want to right like if you need a token on your chain you could just also use that right yeah so it can be used as a um as a payment token as well more generally if if the if chain's building on this edge you want to use it as that but um i mean the beauty of it though is that you don't have to and um you can actually build uh chains on top of place ledger where users have no interaction whatsoever with

laserjust token and so um you don't really have to kind of force users to use some other token but the block aggregators or the block proposers still pay for the storage fees in this ledger in these ledger tokens but the users does not have to be do not have to be exposed to that at all because they can simply um do like a currency conversion where the users pay for paid aggregators in some different currency and the aggregator does a currency exchange ledger and pays for the ledger storage fees in the next ledger token exactly so it's optional yeah but i mean to you uh to go back to your kind of um

question about how does laser ledger differentiate from other layer ones so i am pretty much definitely layer one has a very similar value proposition and this ledger has a very very different value proposition the value proposition of most layer ones like let's say or avalanche or algorand and so on and so forth near protocol dfinity so on and so forth thereby propositions effectively to create like the coolest new like layer one with a superior execution environment that's more scalable than anyone else's and they're all doing that under the world computer model so they're all like basically creating competing computers

and they're trying to attract developers to them to use those to build applications on top of them using their execution environments using whatever programming languages they provide you know whereas lazy ledger's very proposition is actually we're just providing a very minimal modular pluggable layout one and the developers actually should just create their own app specific chains using whatever kind of execution environment they want and i think this is a very very useful piece of infrastructure that does not exist yet because it makes it makes it basically the the the end goal is it for the first time in history it makes it possible for people to deploy their own blockchains in a

decentralized way very very quickly um in minutes possibly without having to go to the overhead of deploying a new consensus network and i think this is comparable in terms of impact i think this is comparable to um what the cloud or what virtual machines did for the internet because cloud uh virtual machines and services like amazon ec2 made it possible for the first time for uh developers to deploy their own virtual servers with their own execution environments on the internet whereas previously if they wanted to do that they have to have to have a physical server and put that in the data center or in

their own home for example or they would have to use someone else's server uh with their with a limited execution environment like back in the day it was geocities for example and more modern ones would include bluehost but virtual machines allow people to actually create their own servers with their own execution environments and i think that's really what drove like the kind of later stages of web 2.0 development as it allowed people to you know use things like docker containers and all kinds of new environments and languages like ross and ruby and python and stuff like that that just weren't available on shared web hosts like bluehost or dreamhost or geocities cool amazing like what's the what's the

timeline for you guys to launch lazy ledger when is it when can people use it and build on it yeah so it's still very early stages and um we're just at the moment we're just um completing the legal aspects of our seed round so we and that will allow us to hire entire developers but uh we expect to have a test net release within about 9 to 12 months and then the main net release within 12 months after that but before then we'll have a definitely sooner for people to play with and and experiment with we have a lot of activity on github at the moment so if you go to github.comledger we're actively developing the project there and we also welcome community

kind of contributions and input for anyone that's interested in following the project cool uh thanks so much for joining us today guys i think there was a very interesting to dive into this and definitely seems like a you know really radically new approach to doing this so i'm excited to see what the impact will be thanks for having us it's great to talk to you thank you very much thank you for joining us on this week's episode we release new episodes every week you can find and subscribe to the show on itunes spotify youtube soundcloud or wherever you listen to podcasts and if you have a google home or alexa device you can tell it to listen to the latest episode of the epicenter podcast go to epicenter.tv subscribe for a full

list of places where you can watch and listen and while you're there be sure to sign up for the newsletter so you get new episodes in your inbox as they're released if you want to interact with us guests or other podcast listeners you can follow us on twitter and please leave us a review on itunes it helps people find the show and we're always happy to read them so thanks so much and we look forward to being back next week foreign