OST: progress presentation on Mosaic- 1 by Benjamin Bollen

check the time so it's the hour maybe first the world on me so my name is Ben I started doing this line of work a couple of years ago started on a theorem in 2016 then I cut two years later and and then we started this company OST two years ago almost 2017 because we saw the blockchain hype happening and I was building on it theorem and I realized that if we can like move the infrastructure forward a lot of these things will potentially become winter and I did not care to create or destroy my new career with a winter so I really try to address sort of the question how do we how do we make it theorem 1x work and get to actual use cases and so since we've worked on what we now call mosaic and this is a short presentation on mosaic 1 which would be the first full map with open validators on it theorem on X but I'll get into that throughout the talk see how this works so the outline is very simple I want to say a few words about the theorem on X and then I was want to say something about mosaic the numbers are a little bit outdated but they haven't significantly changed so in April last year I checked ether scan and roughly we do like a hundred thousand one gas operations so additions per second on a theorem right now and I'm comparing apples with oranges so all the critical spirits like just bear with me on this slide can be very critical later but for every operation we do in the EVM we still have to also execute eat hash and I ran at some 150 terahertz so if you would say like 6000 operations per hash you roughly come to like 10 to the 17 operations which isn't bad because that's like world computer performance scale but we were wasting a lot of that right there's 12 orders of magnitude between the number of operations we execute in the AVM and the number of cycles or operations we do to get proof of work and so if you just like take a very standard thermodynamic argument you compute you divide the useful part by all the stuff done which is still ten to the seventeen you have an efficiency of zero I mean approximately zero and so the question is why do we care to run a machine at near zero efficiency like apparently we spend millions of dollars a day to keep this running because we mint eat and it has a stable value so we pay off the electricity bills why do we pay this cost like why why do we run the most one of I mean there's Bitcoin as well but like why do we run the most inefficient machine I can ever think of and keep running it and my argument is that it uniquely builds a collective state it solves a problem that we weren't able to solve before and I think that's why it's worth trying to improve the efficiency of it because it allows to connect otherwise unconnected isolated intelligence whether that's people companies edge devices but right now we're in a very very early age of of this machine of course and so then the question I asked like who is addressing the scalability for the existing ecosystem we're a lot of projects building this and maybe this is my cynical slide but polka-dot cosmos great projects but they're building a new ecosystem a theorem 2.0 yes but we've just stabilized phase zero and it will take a while before we get to like feature completion of what we have today and then the layer 2 solutions always scale one app at a time not a theorem 1x itself they don't aim to even extend the interface and a lot of them even restricts what's possible to back to you TXO transfers to just token transfers so that's why I'm as a ik is adapt to scale a theorem 1x itself and so my moonshot challenge I mean they were posing ourselves but happy to invite any - it can we make it theorem 1 X a hundred thousand times more powerful more efficient it will still be near zero efficiency I acknowledge that but it's already a lot more power that we'd get so that's the first part my short introduction of why I think this is worth trying and then to introduce mosaic itself it's really often said and it's partially a good analogy but I think it's not a very helpful analogy like blockchain is in the time of 1990s where the internet was then it wasn't very useful bla bla bla everyone like goes with this analogy I think it's not very helpful because it doesn't tell me how to build a better blockchain whereas if you think about the 1990s we had an Intel Pentium processor and it ran at 60 megahertz and then six years later we had 10 x10 and we had a Pentium tree which ran at 600 megahertz but 1999 I bring this up because it's also the introduction of the first GPU and the GPU was a card that you plugged into your existing computer to make it do more computations because it took another seven years before the first like desktop dual-core processor came around it wasn't an easy task it was also a different task so by 2006 in a video was that it's like GeForce 8 Series so instead this is just a historical fact I went over to Wikipedia earlier today and so my claim is or my my position is that I mean we'll all agree that like a theorem on X right now as sort of the Pentium and we're being generous right like we can't do that much on a theorem so it's a single core is really like almost an embedded device it's a very similar like constraints you'd have to solve for and of course like we're not 2006 or the 1990s so our version of like a dual or a multi-core processor will be one that runs with a thousand charts not will we won't go to two cores we'll go to a thousand but it's a hard problem and the question is can we not build a GPU in the meantime that gives us a hundred or a thousand additional course that we add on to a theorem on X so that we already get performance boost actually I want to make an additional point because we have a bit of time although I I don't want to make it too long because otherwise were here till 11:00 I think this analogy also really nicely illustrates sort of how the design philosophy is different like that's for ATM 2.0 don't have to care about which shard they're executing on which is somewhat similar to a multi-core processor whereas if you want a quote for a GPU you have to explicitly write your DAP for being able or your program to be able to use the video card capabilities and I think this is somewhat similar to what I'll explain here if you want to write your adapt to use mosaic as a DAP you'll have to ride additional contracts but it might be worth for some use cases and so so my claim is if it theorem is the world's computer CPU then mosaic is a GPU you connect to accelerate your computations and so what is the blockchain right like a blockchain has two parts it has a supply side and a demand side because it needs to be in economic equilibrium the whole point is that no one is this is doing this for for generosity it's a for profit motive to run a validator so if it's not profitable no one's going to keep running the chain and so on the supply side mosaic is a DAP a set of contracts on a theorem on X with an open set of validators and you need to stake eat and OST to finalize meta block chains and get rewards in from transaction fees in in OST on the demand side any developer can now deploy EVM contracts to one or more of these meta block chains or course I'll get into that and you can pass messages between between the chains so you can send both ERC 20 tokens or other message data from ATM 1 X 2 the score or back and then when within each core now you can comfortably run at 300 transactions per second plus and this will be the point you don't have to pay for proof of work and this is also where in 2015 this ID as well for me 2016 this ID really started in 2015 there was a huge Bitcoin for 3 run or Hart fork and it was cost but what was later described by Jason torch as now the name slips me but I'll just explain it sorry yeah the verifiers on it and so it's good to have backup there maybe that you need to be inefficient to make proof of work work because proof of work only works if the amount of time you're spending on verifying the actual transactions is negligible compared to starting to finding the next nonce and that was what happened in 2015 because a huge part of the mining pool effectively just said like you know what if we skip these 200 300 milliseconds of verifying in transactions where we have 200 300 milliseconds ahead of everyone else of finding answers and so for a while they were successful but eventually also they just started including bad transactions and then later on someone noticed and there had to be this huge ree-ree org of Bitcoin and so torch then still in academics I think and now through bit like analyze this and sort of very said there's this verifiers dilemma dilemma like proof-of-work only works if it's inefficient because you need to be negligible on the useful amount of computation but if we can build a POS system a proof of stake system on top of the proof of work that we're already expending then we can use the same bits that were already securing with proof of work to secure vastly more amount of work and we want to reward that work with just transactions these not with a fee to produce new blocks and find the nonce because that we know is inefficient and so I really want to go over like how the contracts work so these boxes are like representations of contracts on a theorem and so a validator joins a specific core so one of them by by depositing both eat and OSD on a theorem and initially somewhat connects to the previous talk so you you need to earn reputation throughout your life as a validator and we already the steak itself helps well so I don't want to get into this now but we can ask questions if you want the reputation in our case is earned throughout this process and it defines how much your reward is relative to the others but every vote counts for one so if you have a lot of money you need to create a lot of validators but we'll get to why it's still byzantine for talent and secure so plasma is based on fraud proofs right so you can only do certain stage transitions within plasma and then if any invalid transition would happen on the plasma chain now you need to report the fraud proof on Ani theorem and then people can exit bla bla here its traditional consensus engine so so I call this a meta block and a meta block chain because the idea is really just reimplemented a consensus engine add layer two and so the finalization a block is a Byzantine vote of the validators on a theorem okay but I mean as far as I know you can also put like a POS or POA or what what you want like kind of algorithm on plasma I think well I would love to have this conversation but I don't I'm not aware of any well I'm aware of some people working towards like full EVM capability on a plasma chain like leap Tao and so leave um and any very good friends with you on but I'm not aware of like them having a fully VM interface I'm working with so I mean yeah absolutely i I've been researching on the Casper so idiom 2.20 ffff perjury so how is different between the amount of money depositing for either you mosaic so I mean the reason I like the GPU analogy is because if you think of your old desktop it's a card you plug into it and so the same here like it's a set of contracts we deploy and then build out a validator pool and a demand side for it but anyone can take the same contracts and deploy them with their own group like it you can deploy multiple instances of this on a theorem a net no one's stopping you right so so the rules of like how much is staked depend on implementation and specifically in our case we are working on an algorithm for requiring that increasingly some percentage of the reward you earn you can take out but some percentage decided by the governance is added to the stake so that the stake keeps increasing and we start out with so that we can grow with demand because otherwise so it's close to a purist then POWs um ie will go through more details and maybe then it will become clear because we actually also rely on Casper effigy so so like in 2016 I built a theorem plus tournament and then I'm now sort of hopping using Casper effigy which sort of took inspiration from that and then using this add layer to to to build this layer to consensus engine so I'll talk about Casper in a sec thank you so next slide so as soon as you sort of well if you join on a theorem as a validator there's a concept of meta block opening which I won't go into detail because I wanted to sort of paint the big picture but just if you would take the quote like from the next meta block it has a specific meaning then the validator needs to join on this auxiliary system and on this auxiliary system he needs to play Casper FFG so why we want to do that is because we don't want to expend new proof-of-work or have other algorithms we just want to have a way to finalize chain history based on any block proposer mechanism but more detail we actually play this twice you need to play it once to observe the state of it theorem 1 X and agree on that and once to finalize your own chain so that you also have information being able to be transferred from a theorem 1 X on to the axillary system but now I don't know do people want me to explain it Kaspar effigy a bit or yes alright so Casper FFG works by finalizing a history after it's been published right so with tournament every block is only committed if it has a supermajority of two rounds from the validators with Casper FFG the original gadget was also to like take away the economic finality of proof-of-work so we don't really care anymore about which blocks are produced we still want to have some noise reduction of course but once the blocks exist now we're going to cast specific vote messages that need to and they're of the form where you identify a source and a target and so as soon as and then there's specific rules so the construction is such that there are specific rules that you can prove certain properties of these checkpoints and so specifically what you want is that there cannot be two contradicting histories of a live with a soup with more than a two-thirds majority and so that is then proven to not be possible unless you would sign contradicting vote messages and if those contradicting vote messages exist they're very easy to verify so we can easily slash you on a theorem 1 X immediately as soon as you try to finalize contradicting histories on the auxilary system as well because the vote message themselves are very clean and we know that if they exist you're accountable for it as a validator so if you see a history of supermajority vote messages finalizing a certain history now you know that this history is finalized I mean it's a little bit more complicated than that but that's sort of the the basics I hope I got that right but what is really nice now is that we have a really good noise reduction mechanism right because on this exhilaration the validators are playing Caspar FFG to finalize a history and now it takes a very specific form to bring back to et remain that to say like you know what this is our proposal of what has happened and it's we propose that is a valid finalization of the axillary system it's now a very condensed format and so we can present this to this core contract and if it's indeed valid like if it's satisfied all the constraints of Casper FFG now we know that least these validators of this score have a supermajority for it and if no one got slashed there wasn't a contradicting history but that's not enough because we don't want to weaken our security so imagine that you now know don't have one core but a thousand you now need to divide your validators over those thousand course and then I get a thousand times less steak representing any finalization so we want to make sure that the total stake in this chip I think of it as a chip now these days but like in this table is securing any of the course and I've been neglecting the side of the room I realize sorry and so that's why we in will we introduce a committee but in some sense you can think of it as a very as a traditional blockchain system right you some leader needs to propose a block and that is happening on the auxiliary system with the finalization of the side chain any finalized any segments on the auxiliary system that is finalized is a valid proposal you can now pre-commit this on the core contract with those validators to get it to be a valid proposal within the system and now we want to make sure that we commit it and so we only commit it oh how we committed is by in the near future selecting a random committee from all validators that now need to do a couple of things and so it's important that that they're randomly selected from all right because we want to have scalability if we would just ask all million validators to validate this transition of one core it wouldn't work if we would rely just on the core validators it would be weaken security so we want to randomly reselect from all validators now to be in this committee contract to evaluate this block proposal and in order to successful dude on these committee members they must be able to get the previous state of the core that was committed so the previous commit which might be like a day old we called need to be able to get the snapshot of that state database and then they need to be able to get all the transactions that are proposed state transition in this meta block and then what is important they need to prove that they recomputed the full state transition because otherwise they would just be lazy and they would wait for someone to show up with the result and now they were just like vote with whomever has done the work so we need to make sure that in the committee contract they also need to prove that they did the work namely get the old states recompute the state transition and then show that proof that they did the work and then it gets very interesting because the data availability problem is a really tough problem because it is subjective whether or not I get the data is a subjective question I might just have a lagging internet connection or the data might be being withheld from me so it's it's it's very hard to quantify that and but here we try to make an approximation to that because we're saying that this new newly selected committee in the future has to be able to get the old data and recompute it and so that's some approximation of the question were they able to get the data which is the data availability question and and so as a bit of context the reason that the data availability problem is really hard is because it theorem is like we said a Pentium one processor so I can't do a lot and if we would ask it to reevaluate all the data we wouldn't get scalability but if there would be a corrupt majority in the core then they're obviously not going to present the bad data that they want to get committed so you do need to address sort of an approximation of the data availability and and like I sort of said with the committee formation that's randomly selected we we've evaluated again the whole stake that was present in in the contract and we can support up to ten or a hundred thousand validators roughly we aim to have like a hundred perk or but of course this depends on demand if no one's using it there's no transactions fees paying for Valladares and it's not going to grow and so a last point and I'll get like back to higher level stuff and if there's questions also of course this wouldn't work if I need to wait for the finalization of a theorem to finalize my auxilary system before I know whether or not to send the bike so it's very important and I was a design principle from the start that the two systems are asynchronously connected so that there is no time constraint between the two and so whether this process of committing to a theorem takes a day or a week and happens once a day or once a week doesn't matter because the auxiliary system keeps finalizing at normal Casper FFG speed its own history and it knows that eventually if it needs to it eventually will be held responsible by a committee for any of the votes at any point those votes can be brought to to the committee contract and they will be held responsible and in a last point so we've established sort of an extension of a team and now we want to be able to transfer information between the two so we have a concept of message boxes there's an outbox and an inbox on both sides but if you have an out box on a theorem 1x you can put a message into that and then every time information like or consensus goes either way now you can improve all the messages that are in the outbox and send them to and copy them in the inbox and so that can be used for transfer locking up tokens and re minting them on the other side and relieving a nonce taking the same way or any stateful information you can pass true to this message box you can write your own for that matter and so how do you build on top of this so right now we have mistake zero we didn't call it that but now we call this mosaic one so we call what we have so far as X zero you can either work on the EVM interface and then you definitely need to talk to us because it's still a bit rough and all the code is and like get up OST open SC sorry but like I said we sort of wanted to make sure that they were real uses so we've also further polished this and for web 2 applications and if you go to platform OST comm it uses all the underlying architecture and you just have to like click through web pages to to use it but it uses like a contract framework that we call open St it has a noncustodial wallet for iOS and Android and then we have build a real layer service so meta transactions to contract wallets that you can implement in your own app to make transactions happen on mosaic 0 right now and also anything that's on mosaics 0 will will automatically move to mosaic 1 when it launches and then mosaic 1 is what we're actively working on you'll sort of notice that this is a little bit bare minimum like my slides are black and white and it's somewhat deliberate because as a company we want to build the demand side so we have this if you go to platform nord-ost it's all polished and documented etc and we think that's important to get like web 2 applications on board but that's on the demand side of the blockchain we explicitly don't want to own the supply side so the validator network we want it to be an open validator set we don't want to have our hands on it obviously will run Valladares in it but the whole point that is is sort of like done outside of the company is is to never have owned this this piece of code and so it's definitely sort of why I keep presenting here and so we're aiming to have a first version of that end of this year and today I created a new this court Channel - if you want to discuss you can join there and then so for example what have we already built so we have one application that is on a theory minute with mosaic zero and they're now rolling out to like beat the users so it's beta users of the application with real aetherium tokens and they had an internal point system that they called hornet because the app was called hornet and the app is a gay dating app by the way so people using this app have absolutely no interest in it theorem or cryptocurrencies they're there to find guys but they sort of have this internal community so if you translate or report bugs or moderate you earn points and that's where we started so we transform those points internal to the app to LGBT tokens and so right now it's a very limited use case but it helps us stay within legal constraints plus also test the technology because the app itself has like 30 million downloads we have 12,000 beta users and we're slowly rolling it out so in a week we have well it's a week and a half now so we're at seven hundred I will keep pushing that up to a few thousand but this was the whole idea for us this was like let's make sure that a theorem is used for real use cases and that means that people who don't know about the theorem can use it and that means that it also needs to be really really easy so where we do put a lot of our company focus is making this UX really easy and so what we developed for example is a smart contract wallet non-custodial that lives in your phone but you can recover the pin if you lose all your device if you lose all your devices you can recover access to the contract in a noncustodial way with just six digit in six twelve hours so there's a delayed function on the contract and it's a different talk but but it was very important for us that people who don't know about the theorem don't have to go write down twelve words in order to use this because then there will never be adoption of the technology and so that's sort of as a as a as a little bit of a self-promotion here the last slide Thanks [Applause]