EthCC 2: Remco Bloemen

yeah all right hello everyone thank you for attending my closing keynote on scaling blockchains & D apps so some of you already know this yoke I got assigned the very last speaking slot and as my revenge I'm calling it the closing keynote and this is how having been advertising it so yeah if you're anything like me by now you cannot distinguish between your jetlag and sleep depravation anymore so I won't go into the mass of you and all these proofs and instead just talk about the general challenges of scaling blockchain let's start with so again I'm Remco I work for 0x org so 0x Doric is a decentralized exchange protocol what we're trying to work towards is create a tokenized world where all value can flow freely with this we mean that just in the way that the internet democratized the access to information we believe that blockchain technology will democratize the access to all sorts of tradable assets and we want to build the equivalent of HTTP and SMTP to make this happen so we focus on developing the core protocols to allow this smooth and liquid trading of assets and we do this according to three principles do the right thing consistently ship and focus on long term impact I would say this deck is very much about long term impact because scaling so I joined 0x actually I was one of their security auditors way back already but I joined him full-time a little over a year ago and my basic mandate there can be summarized as make sure 0x runs on the best technology now I've thought about this what is this exactly means it means that help out the technology projects that we currently build on it also means pick promising new technologies that we should be building on it means sabotaging products that we don't build on wait this doesn't align with our failures no I also help out other projects that might potentially be interesting to us and this is something I want to emphasize a little bit more what is so unique and wonderful about the ethereum space right now is that you have this ability to relatively freely and unconstrained lis work with some of the best and brightest minds in the crypto industry and honestly I cannot stress enough how unique it is there's there's a very decent chance that this will only last a couple more years and we should really enjoy this opportunity to like work with each other not against each other and work with each other towards this towards these common ideals of decentralization and open source this is like our one shot at proving this at scale and we should take it and make it work now speaking about Grand Challenges I think the main bottleneck right now is scaling now why scaling very simple right now we have more developers than users like the developer to use a ratio of etherium right now is unlike any other technology out there but we we cannot really handle volume of users yet and you may think that well let's wait for the users to come on first and then we'll deal with de load as it comes but this is honestly not how it works if you if you look at what what happened for example with IBM Maersk and their logistics blockchain or order really interesting applications of blockchain that we've been riling about pretty much since since aetherium and the smart contract idea launched you will see that a lot of them are now running on private chains and most of them do that not because they fundamentally hate public chains they do it because they cannot guarantee their stakeholders that they will hit their performance targets on the current chain so yeah a lot of a lot of new use cases like gaming logistics even prediction markets they don't really will run that well at scale on the current on the square current infrastructure so that needs to be addressed the other thing is that specifically with 0x in the exchange market like right now the exes don't have that much of a transaction volume if we take market share from quickly exchanges this will grow if we take on security tokens this will grow even further as we take on the transaction volumes of traditional exchanges if you get to more of a consumer end where we're going with this tokenized world you will rather be comparing yourselves to the volumes that the fees on network do handles and actually the reality is that we're shooting for way more than that we're shooting for a world where every single in-game asset that you're handling will be tradable in some form of a decentralized system so the actual volumes that we should be targeting for over a longer term horizon a way way larger than anything out there right now [Music] so what does this mean for scaling blockchains now scaling blockchains is not a new idea at all pretty much as soon as Bitcoin launched it was clear that it needs to scale in order to get widespread adoption aetherium is no different and people have been thinking long and hard about this problem already the general consensus around scaling right now is that we need a two-fold strategy called layer 1 and layer 2 layer 1 means scale the basic infrastructure scale the on the underlying blockchain there's a couple of really promising projects out there and not all of them are on this slide for sure and I will go into the details of like the various trade-offs that are making here and later the second is the layer 2 so ok let's say let's accept the fact that layer 1 has limitations how can we still build applications on top of this and and you can actually get some additional scaling benefits by by taking this separation into account the reason is that in most applications you have domain-specific knowledge you can make domain-specific security trade-off and the whole equation becomes a little bit easier to solve so you end up with next-level scaling solutions it can actually take the whole thing way further at zero X I'm very much researching this area in the context of decentralized exchanges we'll get into that later first I want to talk a little bit about layer 1 scaling now layer 1 scaling means a number of technologies this is far from exhaustive or comprehensive but in orange you will see the first one is sharding so instead of having every single node of the network re-evaluate every single transaction we sort of figure out a way to securely divide up the work among all the notes that alive and have everyone do some fragment of the total amount of work and basically combined we will do more than each of us could be doing individually while still retaining security this approach has a problem that you have these different environments that need to communicate with each other so you end up with systems that are fundamentally asynchronous I'll get into the implications of that later another big thing that etherium is likely to do in some future is called pruning right now aetherium keeps the entire state and history of every single transaction along on every full node in principle this is not necessary because in aetherium in order to securely know what the latest state is all you really need is the latest block the state that is attached to the latest block and the chain going back to the yin and Genesis block but you don't need historical transactions because unlike Bitcoin it's hiriam use this uses this state-based model where basically the latest block always contains all the information you need to know in order to make progress in this system yet we haven't really implemented that yet at this point we still store all of this data around transactions there so one of the things we can do is get rid of that some other things proof of steak Casper they have more to do about how you reach consensus how you get rid of like this this mining overhead state rent is another interesting one for DAP developers the the gas model needs to accurately reflect the underlying cost of the blockchain of operating it and any kind of discrepancy in there can lead to problems over time as this like discrepancy escalates one of the things we've really seen escalating is the cost of storage because right now in aetherium you pay a one-time fee to have your information stored forever and since we don't have charting yet also on every single note this cost obviously does not make a lot of sense so this is why state rent proposals are out there where instead of one a one-time fee you would have to incur an ongoing cash gasps fee to to keep your storage in a contract this has very far going implications for how we currently develop the app so I'll get into that in a moment another trend seems to be looking into blossom as an alternative to EVM vaasam has the the advantage that it's a little bit of a closer match to the underlying CPUs and it it has way more developer resources allocated to it by virtue of it being the standard in browsers and not all of that is entirely applicable in blockchain because the security model is slightly different but this seems to be some consensus that the future will be wasn't based at least this is what it it 2x Definity and polka dot are shooting for as far as I understand them then another development is to rely a little bit more on lifeline protocol so that we can have beefier machines do the full node stuff but still be able to give hard security guarantees to people who can not afford to run beefy servers and you can actually use zero knowledge proof Sanh on the layer one level to do scaling so instead of what happens now when you when you have mined a new block you send it to the network and then all the nodes on a network recompute the entire block and all its transactions in it to verify it and so instead of that you could imagine computing a zero knowledge proof that proves that this is a correct block and this this state update is correct and then all the other nodes will only have to verify a tiny little proof this is a very promising approach but as we will see later soon all these proofs are still relatively image here so this is not within the realm of feasibility soonish that being said there's a project called coda protocol that is already experimenting with this technology to do blockchain scaling now what do all these planned changes and necessary changes mean for the app developers it basically means that the future will be webassembly asynchronous and state rent and this in turn means that if you have a contract that currently does a mapping from address to something this will likely not work because this means that your contract has to store data for every single user which means that if I create a million fake accounts store some data in your contract and then disappear from the network you will end up paying state rent for all my data in eternity which you don't want to do so that doesn't scale you want to come up with better solutions there same weight transfer from as we do it now where when the call returns you know that the funds have been successfully received and all that this doesn't work in an asynchronous world and as far as I know we don't really know yet how to handle tokens in an asynchronous world this is somewhat of an open research question another a little bit more technical issue is applications that for their security depend on storing data in lock messages if we get to pruning of state then eventually these log messages will not be available anymore so you would maybe only have access to let's say the last year or the last three years worth of log messages if this breaks your application then you need to reconsider how you're using these log messages and one thing I'm fairly confident of is that no feasible long-term scaling future will contain anything close to EEOC 20 because it pretty much breaks all of these three concerns this means we need a we need to rethink how we're doing this whole ecosystem and one thing that's kind of surprised me in engaging in these conversations about all these different scaling proposals is how how under represented the majored app developers are I really urge the people that are working on large projects that have a big stake in the etherium ecosystem that know what is going on that understand the technology deeply to talk to their core deaths or at least attend the eighth magicians meetings listen in on the changes think about what these changes mean for your D app and maybe even give some ideas on hey if you do this and this way you would scale and it would help us don't don't bother them too much they're also quite busy and they're due and they're doing great work in general they they do know what is going on but yeah get involved make sure you have a scaling strategy in your organization now this sounds may be a little bit limp so I want to give a little glimmer of hope in there this is like a random idea I I I was originally planning to do it Eden fir as a hackathon project but ended up not being able to go there so I'm just trying it out there for anyone to do it each pair is if you like it it's a shard token it is a token that is fully shard a ball and doesn't maintain state per user so it would basically work in this future scenario and it works right now on EVM and on the on our current EVM the basic idea is that getting a little technical here really the basic idea is that you have this create opcode not even create to the original create will also work and it gives you a predictable address if some contract creates a new contract the address will be predictable which means that if you it's basically a hash of the current address and a nonce now if you have this nonce you can prove that this contract was created by another contract if you have a chain of these nonces you can prove that this contract was descendant from a common ancestor now if if my contract knows its own ancestry proof it can pass this along to another contract and prove to that contract that they are cousins that they are both descendants from the same ancestor contract now with this funny little primitive you can create a minting contract and then have it spawn different wallet contracts Andy's wallet holds the balance for some user and now when a user wants to transfer they can give the address of the recipient contract and the short token contract will call the receive function on the other wallet and a receive function will verify that yes we are indeed in the same family of token so I can accept your balance because this cannot be minted or double spent or a fake contract that pretends to be fell family like you can prove that contracts are in the same family securely and the funny thing is you don't ever have to call the original minting contract again so this is what makes it char double and sort of stay trend secure everyone just pays for their own wallet and the wallets can transfer funds directly to each other without having to go to a centralized ERC 20 token contract anyway a fun thing out there I hope someone picks it up so that's it for layer 1 scaling let's move to layer 2 scaling so this is sort of scaling strategies that you as a diab developer can use right now right away to make your idea better I like to put them in like sort of four quadrants there's basically two overall strategies that you can take here you can either put your data on chain or you can decide I'm not gonna store everything in storage I'm gonna leave some of it in some secondary system and another strategy you can do is how do you how do you prove your state transitions in your D app and you can you can do some you can do an honest proof approach where whatever you're submitting to the to the blockchain is always a full proof that whatever happened was entirely according to the rules of your D app or you can move to a fraud proof approach where you say where you basically say well here is the update trust me and if you don't believe it tell me and I will send more proof let's go over the basic approaches here so when it comes to storing data on chain like there's not much you can do really in this area you can do gasps goal thing to get the the transaction costs down basically just optimizing your EVM code you can invent some clever compression algorithms to reduce the cost of your transaction data are you fairly limited there when it comes to compressing sort of the evidence that you provide for a state update a simple thing you can do in some cases is signature aggregation where you use something like BLS to compress multiple signatures together you could for example use this in a Dex in a decentralized exchange scenario where you submit multiple orders and then an aggregate signature that is the sum total of all the signatures that prove all of the individual transactions you can also look at sort of semi zero knowledge proof tricks like some proofs where instead of providing all the balances you provide a proof that all the balances were computed correctly but honestly I think at this point it's worth just looking directly into zero knowledge proof which does allow you to do any arbitrarily complex claim and have a very concise proof of that and submit that concise proof now on the other end of the spectrum I'm where you sort of no longer submit proofs of correctness to the system but kind of keep even the state update proofs off chain you have the simple example is state channels where you have two parties or at least a very limited set of parties that send each other Sciences and they sort of maintain the state amongst themselves and only when they want to finalize the channel that they have or when someone is in a dispute with the other one would they actually submit things to the to the blockchain itself so this leads to a lot of optimizations because you don't have to submit every intermediate state update you just have to either do the last state update or escalate whenever something goes wrong in the protocol state channels have a significant advantage in that they're usually two parties and I know I'm right so I know you are wrong there is like it's security wise that the protocols are simple to design because there is always like if one part is right that must mean the other is wrong once you get to more complicated systems and then we get to what the early iterations of plasma were like like plasma cache for example and you have multiple participants this gets significantly more complex where now you have like escalating games like no I was not wrong he was wrong now he is was right the other one was wrong and you you basically have to iterate through a whole series of these operations and personally not a big fan of this approach because it it means a lot of overhead if something does get wrong it also means that you need to constantly monitor the blockchain to make sure that someone is not submitting something that is incorrect to thwart that day if invented slashing and what's ours and all sorts of added on complexity that will like do this for you they will monitor the side chain the D app for you to make sure that everything happens according to the rules and if it doesn't they will warn you and handle the fraud proof and the Unchained Court for you yeah and then on the other end of the data of chain spectrum we have different techniques where you can only store some sort of commitment to the data on chain and keep most of the data off chain so simple one there are miracle trees these are used in a lot of places already accumulators are sort of slightly fancier and more efficient versions of miracle trees but they don't do entirely the same thing it's more of a set where as a miracle tree you can do an array and there are factor commitments that add array-like functionality to the accumulators but again in this direction zero knowledge proof trump everything because you can just implement any arbitrary data structure and do any complex commitment scheme over there and you can run it fairly concisely so at zero x we pretty much concluded that yeah we don't want to do flawed proofs and have to deal with all the complexities of protocol design where you can unwind and revert state and all of that no we want to always be sure that whatever state is on chain is entirely valid and entirely correct we also don't want to mess with complicated commitment schemes so we we ended up with the upper right quadrant and just went full on zero knowledge proof at DEFCON 4 we got introduced to star war and since then we've been working with Stark we're very much on there Stark Dex approached to do batch settlement using Starks we managed to get the first stark very fire in EVM and funnily enough you don't really need pre-compiled so you can actually do it with current EVM without any kind of a hard fork necessary only takes five million gasps it's just it's not cheap but it's surprising that it works at all to be honest and 5 million is doable given how much of a scaling advantage it gives it's it's actually less gas than if we did those transactions in the traditional way significantly less gas so layer 2 at 0 X there is a couple of parallel initiatives going on so to say that we will be rolling out over the course of this year so the one I'm working on is the the settlement layer but in in parallel to this there is the trade execution coordinator which is sort of a optional add in surface that will do a transaction ordering for you according to different strategies this is an alternative to what some real layers are now doing which is a closed order book where you kind of miss out on the liquidity sharing aspects of Co X but instead you get to do councils of chain so there is a way to do this and still be able to have this open ecosystem that's one thing we're rolling out another one is that currently the sharing of order books happens through what we call the standard real layer API which is just an HTTP Jason endpoint that the real layers need to bring up and they sort of need to pull that we want to replace that with a peer-to-peer order book where new people can just join by joining the network and contribute to the order book people can plug in and get the latest state of the orders we're working on lip peer-to-peer on this one and we're actually extending the peer-to-peer with B's web RTC support this is something that's been on the roadmap for a while but they haven't gotten around to implement it yet so this will be our contribution and the cool thing about web RTC is that this allows you to create peer-to-peer connections directly from the browser so with this one in we can actually have audiobooks that go directly from someone's web tabs to somewhere some other traders web tab and in principle you need zero infrastructure in order to run a decentralized exchange so all of these are right now separate initiatives that build upon our existing smart contract infrastructure but ultimately they all combine in a very elegant way to basically form a side chain where the peer-to-peer order book is not really that much different from a mempool where the trade execution coordinator is really not that much different from a device for creating blocks of transactions and where the Starke batching mechanism is really not much more than a block sealing and consensus protocol and ultimately the consensus is hook backs into the etherium main net so yeah that is the sort of longer-term strategy to create this side chain so let me talk about zero knowledge proof for scaling and I've actually been told that I shouldn't call it your knowledge proof because we don't really use the zero knowledge aspect we just use the proof acts mask which makes sense we're not interested and we'll get into that but we're talking here about proof protocols and there are some optimizations you can do if you drop the zero knowledge requirement so what is the zero knowledge proof you have a basic function f of X and y equals E now F can be any function you want like you can literally throw a piece of Python code and it can to some extent be implemented in a zero knowledge proof the basic thing is that math is cheap in general but branch and checking that some value is less than is is relatively expensive and AES is expensive but multiplying numbers is cheap so how things work out in practice is it's kind of a learning experience at this point and the technology is not mature enough yet that you can just like as you would right solidity code do it without thinking too much it will get there over time it's just not there yet performance wise so at this point you need to be clever about designing your functions but this will improve all the time now once you have your function that represents what you want to compute in your cereal knowledge proof you have two inputs that you can that you can have you have your public input this is what you would share with the inside world and then you have a private input this is the zero knowledge part that you want to keep secret and then you have an output and the thing you're proving is that here I give you a value for X and a value for Z and I claim that I know a value Y that makes this equation true but I'm not going to tell you this Y and the proof protocol is actually it's D clever cryptography that allows me to convince you that I know this Y without revealing it if I just gave it to you you can just run the computation for yourself and convince yourself that my values were correct now this private input allow you to do privacy obviously you can do some things like hey here is a transaction and I'm not going to tell you for how much but I'm going to update the balances correctly for example but it's more interesting to use this for scaling because the cool thing is that these proves they don't grow in in the size of this private input like your private input can be really really large but I never have to tell you the private input so my proof can still be very small and this is where the scaling aspects come from in the case of a dexon REO the way it works is you have a function that verifies transactions and updates balances as a public input I take a merkel root of the old balances we come faults in our design and all traits tape we'll get into that and as a private input I give you the miracle proofs that relate everyone's balances to this to this root and a whole list of sign traits so that's a lot of data I'm putting in this private chain it's like a whole bunch of miracle proofs for everyone's balances all the transactions involved all the signatures everything and this F function will then verify these miracle proofs back to the root of everyone's balances update all these balances make sure that everyone has sufficient funds for the transactions check the signatures everything and outcomes at the end this F function computes a numerical tree with everyone's new updated balances and it outputs that numerical Merkle tree so again how does my proof look now so the proof works that here is the old merkel root and here is the new miracle root and I claim that I know all the miracle proofs and all the transactions that make this valid and this is where the amazing scaling comes from in in zero knowledge proof as a layer two solution so it's got a little bit more in depth in how how such a state update works so in the in the top row you see aetherium blocks and you see our little little contract running in there the contract currently has a state root that says state a now I submit a proof in to this contract that says hey the old root is a and the new root is B and here is a whole list of transactions that I'm not telling you but there is a proof of it so all of these different transactions you see there in gray you don't need to submit them to the blockchain anymore that is all sort of gas saved and instead you just have this one concise proof the contract sees this the contract verifies the zero knowledge proof it checks that the old root is indeed a as it remembered and then it updates it to the new room and then you create a new proof with all the new transactions that came in and so on and you keep updating this State Route now what do this state would look like there's actually two in our current design the first one is default route which is indexed by some fault ID and basically in each leaf of this thing we store three values the public key of the owner the token ID that identifies the token that is actually stored there and the amount of those tokens that are stored there next to that we have the trade route and it contains a trade idea and a simple boolean value telling you whether it's filled or not so this is to prevent sort of double execution of transactions one of the things our zero knowledge proof verifies is to make sure that this transaction hasn't been executed before so these transactions there's four main transactions there's a trade settlement a deposit to move funds into the sidechain a withdrawal to move funds out of the sidechain and an escape hatch that basically guarantees security in case the whole system breaks down or any of the components become malicious so the simplest ISTE trade settlement if you're a market maker you sign an order stating the the tokens that you're willing to pray to trade and at which price and you put it in the peer-to-peer order book now the taker at some point sees this order that's its signature and then submits it to the sidechain operator the operator collects many of these signed transactions and then combines them into a batch that updates the old Balance route to the New Balance route and then it submits this proof to the contract the contract verifies it and updates the route like you just saw so what if you want to take your tokens and put them into this sidechain so you send your tokens to the contract the contract now remembers in its contract storage that you made this deposit and it fires of an event the operator and sees this event and it includes a special deposit transaction in the batch and also adds it to the public input so this transaction is not hidden from the contract that it's actually included as one of the public inputs to the thing the contract receives this proof which has this deposit transaction as a public input so it sees the old route the new route and hey there is also a deposit transaction so now the contract checks do i have in my storage that this user actually deposited these funds and it sees yes indeed the user has it so it removes this storage slot and from now on the funds are moved to the side chain and of course if the user didn't make this deposit the operator should not include it and if it did it did occluded the proof simply gets rejected as invalid we draw all the sort of the opposite thing the user submits the signed withdrawal transaction to the operator the operator includes it but also includes it as a public input again the contract verifies the proof and sees that hey there is now I publicly known withdrawal transaction and the contract takes some of the tokens it has in its like funds and sends them back to the user that the that scientific role so far so good but as you notice this withdrawal requires you to deal with the operator what have you don't trust the operator this is where the escape hatch comes in the user tells the contract give me my money back and now the contract remembers that the users said this and again fires an event the operator should now include a proof that hey this was your balance as a public input the contract verifies this proof and sees this message and basically gives the user its entire balance back because this proof now says this was the users balance they're out of the system they won't go on so that's the end of that however the reason we did this escape hatch is because we don't trust the operator so what if the operator does nothing this is where it gets really interesting in all of these zero knowledge proof off chain data designs so we have the same step the user tells the give him a money back the contract remembers this in storage and fires an event but now the operator does nothing either it just continues running the system as if nothing ever happened or it fails to update blocks because the servers are offline or whatever anyway at some point the contract decides that hey it's been like more than two days now since this user requested their funds you should have been dealing this with with this by now I think you're a crook so now the user now the user can tell the contract like hey here I have my own proof that this was actually my balance give me my money back and the contract verifies the users own proof and gives the user the tokens back the reason that the contract cannot immediately accept the users proof for this is that it conflicts with the operations that are going on so you cannot have multiple people update the state route at the same time because that leads to clashing clashing state routes so in order for for this to happen first we need to kind of dismiss the operator as non-functioning and now we can say okay users are in charge you're entirely correct and you need the Merkel tree to do this so what you hit on here is indeed known as the data availability problem this is the main problem that layer to scaling solutions that use off chain data deal with going back to the on chain off chain debate the problem with on chain scaling is that with storing your data on chain is that you can never do better than some small factor improvement over the current system because ultimately all your transactions still have to be stored on chain even though you might be able to compress them to some extent by let's say leaving out the signatures but yeah in the end you would still need to reconstruct your data if you go if you want any kind of better than linear scaling you will need to have your data off chain but that introduces this problem where if you want to use this ultimate security escape mechanism you will hit into this problem that hey some piece of information that is kept off chain I now need in order to unwind my position in the system and it gets a little bit worse because usually you use Merkel trees here and the state food just keeps updating so if I know what my balance is right now and I know how it traces back to the state route that is stored on chain right now I might wake up tomorrow and see a new state route and not know anymore how to create a miracle proof from my balance to this new state route so somehow some surface needs to be out there that is able to provide you with this information in a way that you can rely on this thing being there for security this is to a large extent an open problem but it is not completely bad because you can you can do solutions that get you most of the way there the way we are going to solve it for our proof of concept end of this quarter is by having a committee of let's say around 20 data available the pro fighters once a new proof is generated the operator needs to send all the relevant data to all of these 20 committee members each of them signs off on this data stating that yes I've received this data correctly and I've also now shared it on let's say on my website on bitter end on ipfs wherever you want it they sign off on that fact the operator collects these signatures and the proof together with these signatures gets submitted to the smart contract and the smart contract verified that the committee has signed off on the availability so now your security changes from oh you need to trust the operator to have this data available to you need to trust that at least one committee member has this data available which is a significantly lesser security constraint but ideally you want to go even further than that so you can add some complications in there where you where the contract periodic challenges committee members to reveal their data where they have some stake in the protocol and they will get slashed if they are not able to provide this data on demand in sufficient time and so on but again open challenges data availability I would say is one of the biggest one right ones right now the other one is technological maturity of zero knowledge whose snarks here have a little bit of an advantage they've been around for longer there is existing tooling like socratis that give you domain-specific languages Starks are relatively new there are some supposes advantages improver time allowing to do more complicated things however right now we don't have like nice programming languages for them yet obviously this is something that will improve over time but in general the state of zero knowledge proof is relatively fresh this is technology that has been known for some decades now but initially soon all these proofs were in the order of megabytes terabytes you name it they were like not practically feasible and as this technology proved over time like they now barely hit the threshold where zero knowledge proves our meaningful in the context of financial transactions where the amount of compute you need to do is very very low and the value of a single computation is very very high so that's why they're finding applications here another thing I would like to stress is that if you use your knowledge proofs as a layer to scaling solution you're in a much much better position than if you use them for privacy because the problem is that C cache is an example of a project that is using stealing all this flows for privacy they recently discovered or actually in during the summer they discovered a serious flaw in the way they organize things that could potentially lead to a theft of funds and they've been fixing this in the background and they just published that this actually happened a month ago and the problem is that right now they don't even know if anyone else discovered this and exploited it because their coin is private they cannot see they cannot verify that things happen correctly if you use zero knowledge proofs as a layer to scaling solution you have a significant advantage in that you're not trying to hide what is actually going on and people can just tell you everything up and verify that everything was done correctly so this is why I'm handing it to you this is the perfect testing ground for serial knowledge proves better than the privacy stuff in my opinion the limitations of zero knowledge proof technology at the moment mean that we don't get to do all the things that you would expect from a decentralized exchange like the current design for example as I presented it here does not even allow you to partially fill an order an order is either filled in full or not at all obviously we want to have this as a feature before we consider this to be production grade and there's a bunch more features for example constellations that we want in there as well another is that as you notice I was talking about a single operator here which is arguably a point of centralization now the fact that we're using zero knowledge proves here and not fraud proof means that what this operator can do is limit basically limited to what miners can currently do which means transaction ordering and censorship but ideally we would have we would have some decentralization mechanism in here so you can have multiple operators so that you have some rough guarantee that well maybe one Operator is trying to censor you but you know what you can always spin up your own operator and include your own transactions open question wallets support go into that one a little bit on the next slide actually but basically zero knowledge proves require so right now aetherium uses SEC P 256 k1 which is a particular kind of elliptic curve unfortunately it is really really hard to implement specific curves in zero knowledge proof and rather you would take the elliptic curve that comes naturally in the zero knowledge proof system that you're working in because snarks are implemented on some form of elliptic curve cryptography and and starks similarly i implement it on finite fields and you want to use an elliptic curve that uses the same field in order to do the math efficiently problem is that wallets don't support this new curve contracts don't support this new curve so there's some proposals out there that i've been working on for the past couple of months hope hoping to get them into the next heart Fork the first one is a pre compile for generic elliptic curve so right now we basically have support we have some sort of support for sec P 256 k1 through easy recover we have some sort of support for the alt BN 128 curve that is used by some forms of snarks but we don't have like we can keep playing this game and keep adding curves but I would rather just have one contract where you can just enter your parameters of your curve and it will compute it for you this will allow all sorts of DAP developers that are working on their own customs your knowledge proof solutions to just use whatever curves works best for their system and have support in the itself for verifying things like signatures Peters and commitments whatever another fun one is actually the cost of that way but let's talk first a bit about the wallet support similarly to how you want to be able to verify these signatures in the contract you actually want to be able to produce these signatures in a wallet right now wallets can't do it there is no real way to add new crypto primitives to evolve it besides sort of asking meta masks in order to implement your custom crypto which doesn't really scale well so I wrote a proposal that allows you to compile your custom curve and cryptography and signing algorithm to webassembly and then basically upload the web assembly to your to the wallet and then a wallet will execute it in a in a secure way using your existing private key so you don't have to generate new key pairs and all that you can basically have a relatively smooth experience using serial knowledge proof based layer two solutions now cost of transaction data versus storage one thing I realized while working on this stuff so stark proofs are relatively large they they require five million gasp and out of that something like four and a half million is purely the cost of transaction data in general layer to scaling solutions no matter which strategy you really use they end up consuming a lot of transaction data at some point because if you if you put your data off chain there are points where you want to contest the result or prove something where you need to bring it back on chain again and usually when you do that you even need to include a fairly large miracle proof that attaches it back to whatever is stored on chain you can do the math on that and right now the cost of including a single 32 byte variable in transaction data is a little over 2,000 gasps reading a 32 byte variable for storage is 200 gasps we're seeing it - we're seeing a 10x differential here it is literally cheap to restart from storage and put it in transaction data it gets even worse once you include merkel proof if you want to include a merkel proof of let's say depth 32 which is what we're shooting for with this system you'll have to include 32 values the total gas is more than 70 k in this in this scenario so really everything screams at you to skip the layer two and just store it in storage and this is this is hitting all of the layer to scaling solution apps out there as far as I can tell so yeah there's a proposal out there to to change the gas cost on when it comes to transaction data other proposals were kind of aiming to better support in webassembly for certain crypto operations or maybe even lobby for web crypto itself to get better support for different critter algorithms like get it lower in the stack funny thing is I've been asking around in the web assembly community and basically some folks at Mozilla told me that yeah there was one guy from aetherium once and we haven't heard from them since so we really if we really want to use WEP assembly as a core technology in aetherium we really should be doing a better job representing ourselves and our needs at the web assembly committee so I'm I'm going to try and champion this proposal in there and then maybe some other ones and just get some representation there but this is also something we should do as a wider community anyway I wanted to go to one last challenge this is the one I wanted to save last because I think it's the most important one this is my homework assignment and I would say it's actually turning out to be the closing message of ECC we need layer 2 interoperability the big problem with all these layers to scaling solutions that we're building right now is that they become little silos that that force you to put your money in one specific D app and it locks it in that D app and doesn't allow you to do anything other than that the app and it completely destroys all of the cool stuff that we have with aetherium right now where we have all these amazing smart contracts that build on top of each other that 0x is a prime example of this like I've seen projects u0x in ways that I could never imagine just because we created this open API that have a that has a well-defined meaning and then people just run with it and get creative with it if we get to layer 2 scaling in the basic way we will lose all of this we need to think about how can we create this sidechain in such a way that you can use multiple applications on the on either on the same side chain or we can have efficient ways of transferring state between the different side chains nobody answers here yet but this is a discussion we should be having as a wider community all right that's it thank you I don't any questions thanks for the great talk Remco I wanted to briefly ask about sort of the differences between 0xs approach to this zero knowledge-based batch auction exchange and the diffusion project bike gnosis which seems to be doing something fairly similar from my conversations with them so for starters we're currently not shooting for a batch auction but a traditional continuous limit order model we can we can implement batch auctions on a different level as a trade execution coordinator and there's also alternative strategies that we consider worthwhile like selective delays where councils have a let's say to second priority overfill the basic idea here is to create a fair market place and right now the marketplaces are to the disadvantage of market makers you said that you think that the future of a blockchain is rather webassembly than Danny VM yet still you're proposing new functions to a VM so when do you think this feature is gonna hit us like how long does it how much time does a vm still have in your opinion I don't think it's gonna go away fully so one of the cool things that happened is that basically people that develop let's call it aetherium one point X said that you know what we're just gonna maintain this system indefinitely and make it competitive incrementally so this means that EVM will likely be around for a long time although maybe in a form quite unlike it is currently but through an incremental migration path there is some proposals out there right now shooting for the next hard work that all sorts of new up codes to the EVM that allow it to be a better target for native compilation for example I I think EVM has a good shot of being around for a while but I also think that EVM will sort of converge towards webassembly because webassembly is sort of already doing more or less the optimal thing here for the interval T part would you prefer polka dot purchase or cosmos or what kind of model with you those are all layer 1 solutions I'm talking about later - all right ok are you satisfied without payin 128 the security of that for the zero knowledge proof that you're thinking of including in 0x which ones OPN 128 the pairing curve we're using Starks Stark where is this Collier okay Stark where is this company in Israel founded by Le Pen's Hassan and Ali who were some of the pioneers of snarks in the first place and they now relatively recently came up with a better scheme that doesn't require pairing cryptography at all it has it has actually fairly simple mathematical foundations yeah but it's there's no precompose for that are you waiting for pre compiles or like I said the we can already do it in existing EVM we don't need any pre-compile we have implemented the whole thing in EVM assembly and got it to the point where it can run within let's say six million gasps isn't the block limit like four million gasps it's eight million okay if if we get these proposals and change the cost of transaction data visible chains because it's actually something like 1 million worth of compute and that's not even optimized yet if you look at snark base you and knowledge proves that have some amount of data input in it they also cost 1 million years so it's actually quite competitive already if you look at it that way last question [Applause]