QED: A Horizontally Scalable, zk-Native Blockchain

Transcript

[Music] foreign [Music] okay fantastic all right um hello everyone uh let me just make sure I have this so I can click but yeah um hello everyone and uh and welcome I'm glad you can uh make it but uh yeah so today we're going to be introducing QED so uh we call ourselves the world's first ZK 2.0 blockchain um we're horizontally scalable and variable verifiably secure at Layer Two

um so we're essentially built to solve some of the main I guess pain points for for blockchain adoption that we currently see uh one being like the the state of web3 development tools and uh some of the rest of the ecosystem compared to um some of the web 2 languages um also with regards to scalability like right now we've seen l1s with serial State models max out at around 10 000 TPS um there's there's a CPU bottleneck and as we see with Moore's Law like we're probably not going to be getting um much faster and then also on the ux side like uh web3 right now isn't very competitive with web2 just in terms of like uh you know some of these very conversion sensitive uh experiences where whenever

you interact with blockchain you have to pay and wait uh for a transaction to be processed so um yeah if we look at the the current DK VMS right now they really don't solve any of these problems um they have the same like developer experience quality uh if not worse like um well Cairo may be a great language as well as move their the amount of tooling for the ecosystems is very very small and uh you know the developer Community is essentially like a three-figure you know under 1000 total developers uh compared to a lot of the other language ecosystems so really like if we want Mass adoption of users it's probably going to be necessary for us to also have mass adoption of you know the developer community at large and then on the the like TPS side I think starknet

recently hit 30 TPS so um you know that's great but uh it's not really making any Headway towards the ultimate sort of scaling dream of uh of blockchain and the capabilities of CK and then again on the user experience side we have the same sort of bungled user experience that often kills conversion so um so QED is uh quite quite a unique uh solution so we actually allow um developers to write ZK smart contracts in JavaScript in Python um and then we compile each of these contracts to a Merkle tree whose leaves is the verifier data of each of the ZK circuits which are allowed to operate on the that contract say tree and then in

addition we were horizontally scalable so we don't have a single state tree for each contract we have a a state tree for each contract for each user so because of that we can guarantee that there's no race conditions when you're building when you're proving transactions in a block in parallel since you know users can read from each other's States at the end of the previous block without being able to write to each other's state tree so as long as the um the user modifications to their own contract State trees are done serially you can parallelize like the sort of we so we have a recursive chain of proofs so the end proof um in a local chain of of proofs which amount to some transactions so essentially users can prove a bunch

of transactions locally submit a end proof which has recursively verified all the transaction proofs that they've made submit that to chain and then the actual process of building a block out of those end proofs like the the work that needs to be done by the network is fully parallelizable because we just have a structure of of uh proofs or of zero knowledge circuits we actually call it parth or parallel ascending uh tree hierarchy a recursive tree hierarchy um and uh yeah so we mirror the state of um like a large Merkle tree and the end result is of course with Merkle trees we can build them in parallel like for instance we can prove that certain users updates uh updated their trees up to a certain Merkel cap and you know we can do that like in parallel with another

part of the tree and so on and so forth and we arrive at a block time of around all of uh log 2 uh of n where n is the number of users that are submitting trends actions within a block so not only is the block time not contingent on the number of transactions processed in the block but also we have like very very very efficient block times just because you know all all Vlog 2 is is is is is pretty good so like just for some perspective like let's say four billion users submitted um transactions in a block uh you'd be looking at some something like 32 times the the amount of time it takes to prove a recursive proof that verifies uh in our case like a two to one so take two proofs um recursively verify them and then also uh

verify the associated Miracle proofs oh yeah and then also uh as I mentioned um like we prove every transaction so we're not like optimistic we actually uh are quite ideologically opposed to this kind of idea like we still believe that all transactions should be validated and um you know obviously if we can generate a single succinct block proof of all transactions then we can make that happen without sacrificing scalability um but yeah so we're super developer friendly um as I mentioned we we support vanilla JavaScript in Python so we've really taken a lot of measures to to make it as compatible as possible with vanilla JavaScript um you know obviously we can't have non-deterministic uh features of

JavaScript in a you know a ZK circuit building uh a platform like we don't have math.random right uh we don't have some i o functions some string building functions but all of the core like language features that JavaScript developers know and love as well as python um you know python like map operators and lambdas and so on and so forth we all have support so um because we support this sort of unmodified vanilla JavaScript we're able to inherit all of the tooling that there are you know million plus developer ecosystem has built so you know even if we really try to build out our solidity let's say tooling infrastructure it's very hard to compete with the number of man hours

that have already been invested in all of these like mature languages so um so yeah like uh our value proposition to developers is more just blockchain development with zero learning curve so um I think this also makes us a little bit we're a little bit different than other projects in our approach to this like we're not trying to cannibalize existing solidity developers and you know we we encourage and love like ethereum ecosystem projects and TK VMS and so on and so forth we're just trying to like bring more developers into the ecosystem that you know previously I guess uh weren't able to benefit from blockchain so um we already have like a full IDE and uh we have an internal test net we'll be launching test net in a few

months but uh yeah like um this is just an example of some of the tooling that we have like we have a visual debugger um this is something that like remix has lacked like a good visual debugger for a long time like it has a debugger but it kind of doesn't work like yeah but um yeah we have like we we try to make everything as nice as possible um it's it's a lot easier to debug or JavaScript contracts than um any other ZK VMS contracts and yeah we have uh right now about uh 20 devs who are working purely on just building out developer tools um you know ux improvements making it as easy as possible for non-blockchain folks to you know build on QED um one of the advantages of using

JavaScript is that uh llms are very good at writing JavaScript in Python because a lot of their Corpus they're a lot of their training data from GitHub was JavaScript and python because it makes up such a large amount of just the data on the internet that is related to code so it's very good we have Integrations with gpt4 and Claude 2. we're leaning towards claw two just because uh it has a larger context so the larger the context is the more sort of best practices we can tell the llm before we actually ask for for user responses but um the main takeaway is you can essentially just write a contract and markdown with each function sort of saying what you want it to be and then it will automatically generate the ABI and the contract code for you and then um you know as we see nowadays like

everyone is getting their their contracts you know evaluated by third-party security forms or audited so I think like this actually can be a viable solution as long as there's a third-party auditor um you know making sure that there are no implementation bugs and so on and so worth but generally people are doing that anyways so uh for for some contracts this may be quite an interactive solution but yeah I can go over here I don't think we have much time but uh yeah so our our flow is like quite quite simple um you just compile your contract uh you recursively prove all of uh the transactions that you want to make locally so

um you know whenever you are sending a transaction on another blockchain generally the user flow has to be interrupted and they have to like you know sign and pay a gas fee but with us essentially the dab can decide when that's appropriate um we also have some mechanisms for for doing delegations so that you can get sort of like sub finality for third-party applications um we do that by saying like Okay for the next 30 minutes uh any transactions that I send must be signed by myself and another third party so we can guarantee you know we can guarantee to dapps that like if you send your approved chain to them or one of the the end caps of your proof chain to a third party that's allowed to submit for you they know that

you're not going to submit conflicting transactions within that period period so that they don't have to actually pay the gas fee and they can you know have like game logic or you know other other sort of mission critical logic um run under the assumption that these transactions have been executed um and yeah so every every block proof of ours proves every transaction in the block um so we have as I mentioned recursive tree hierarchy of of proofs and uh we have a single block proof which proves every transaction in the block as well as recursively verifying the previous block proof so therefore every block proof by induction proves every transaction that has been executed in the Chain's history we also have in that proof in the public inputs the um the start and end State routes so you have a single state route that has like you

know all the data of the chain if you want to let's say on L1 you know grab some data or maybe I'm like bridging tokens from L2 to L1 just provide a miracle proof and you'll be good to go so so yeah um we end to end prove everything even if there's no 51 attack with QD because you just you know you can't like generate a false proof but uh yeah so um I don't think we have much time two minutes oh okay great yeah so um just to like uh kind of look at the reason why because I know it's like quite bold to say like oh we are with ZK 2.0 right like a lot of people like to give themselves

generational boost but um you know we we believe it's it's warranted just because uh usually like major version increases happen when you get benefits or positives without any trade-offs So like um let's say a laptop from 10 years ago the processor was slower and it was it had less cores or less less Hardware threads right is there any trade-off for having faster laptops now no right it's not like something else had to get worse for something else to get better and that's why we we increment the version of the processor right so um so like as I mentioned because we have a the like because we take the step of isolating the user's State or the user state that

can be writable by the user um within a given transaction we get the benefit of just being able to execute all the transactions in parallel because you know we eliminate any chance of race condition so we have like hard guarantees against race conditions um and then also because we support JavaScript in Python for normal web 2 developers we support all the tools that they already are used to working with out of the box so uh yeah and uh like as I mentioned um you know we proved transactions in the background and users are only prompted when the DAP wants um to submit the transactions to chain so as like adapt developer much like a you know web 2 or or a games developer you

can decide when in your user flow it's appropriate to like ask the user to pay for something or to interrupt them at a time when you think that it has the least risk to your like conversion um because you know if at the very beginning you ask them to do some of these things the user just leaves the application right um and uh yeah we have um uh our our white paper will be coming out quite soon we have some other talks at CK day if anyone else is coming um but uh yeah we have some information on our Twitter about our abstraction um uh our censorship resistance is also quite good um we'll we'll have that more information in the white paper has a little bit to do with our tokenomics in the proofing structure but uh yeah so maybe I could just show everyone like

a quick demo so um because we can prove transactions in parallel our block times can be very very fast even if we have like you know hundreds of thousands if not millions or even billions of users um you know submitting transactions at a time so here we have like uh on openc a denim Dynamic nfts States updating in real time so what's happening here is we're proving locally that uh I you know hit someone right and then after that we're submitting our proof to the chain it's aggregating the global State and then on openc we have a um an HTML application that's essentially just hitting our API requesting the latest proof uh the latest block proof as well as a Merkle

proof of the storage slot which holds the counter for this sword and you know because we store these HTML uh viewers um an immutable storage um you know you're guaranteed that whatever you see on openc is the actual value of the state of on the Block chain and that um you know it has correctly verified uh that the state that you're seeing is correct so this is important if the metadata of the dynamic nft affects the value of the nft because of course like you know if it's a level 10 or a level a thousand you know Warrior whatever this may have a great impact on like the price of this item so uh yeah metadata matters

but um yeah uh we also have some solutions for for privacy and AI so the great thing about having paralyzable State um is that you can prove transactions locally and that means that you can do computations with sensitive user data and be guaranteed that the sensitive user data never has to leave the user's device so you don't need fhe which is going to be very very expensive to do in zkp like zkp like non-native operations are already very very expensive it takes a long time to prove and it gets even worse with fhe but um you know if you prove locally you avoid that entirely and uh yeah so like we can do like AI inference we made a tensorflow um we have Kara support for coming very soon it just tensorflow Lite

was a little bit easier to Port um but uh yeah we have some uh some like model hierarchies that uh essentially like we can retrain existing pre-trained models to uh be hierarchical so that you have like descending smaller and smaller and smaller circuits which is very important for like parallelizing them if you want to do zkml um but yeah so we we uh we're there's a paper called split net that you guys can check out if if you're interested in that but uh yeah so we want to have like very easy sort of drag and drop pre-trained models into our IDE and and be able to do um AI inference on chain so yeah um we have uh some great Partners uh

already um you know we'd love to bring on more and uh yeah we just recently signed Universal so we're very excited about that um but uh yeah if anyone has any questions you know please let me know um I'll be walking around and uh yeah I'm curious I think we have a little bit of time does anyone have any questions yes questions okay thank you oh yeah maybe just oh really quickly a bit about a bit about myself so um I come from like the the video game security industry so I was a member of Xbox underground which is like a hacking Collective when I was naive and and in my youth um uh I also uh built mod P

which is the world's largest Minecraft um Pocket Edition like mobile edition of Minecraft modding platform had over 150 000 developers 20 million installs um and then uh you know also as our advisor we have Scott that just joined us um one of the co-founders of Bitcoin so I'm you know very happy to have you know some Titans of the ethereum open source ecosystem on board as well but yeah please thank you thank you uh just a quick question could you tell us a bit more about the uh you talked about the how you had a decentralized network to submit to prove uh transactions is it uh decentralized in a point where every user could on its own submit approve yes what's the economic model behind it so

yes this is very key as well so um the the the the requirements to actually participate in decentralized proving are very very low in terms of both hardware and like I guess like you don't have to have token state for you to participate in this process and also we allow for um data availability nodes let's say nodes that are you know incentivizing people to or or rather um that are like storing the global State and providing information required for provers to do their job they can provide data encapsulated within proof such that if you then use their data to um like essentially generate a decentralized mining proof um and contribute to the network the

reward fee is split between the data availability node and and the user and with a few of those transactions you actually have enough tokens rewarded so that you don't have to pay a gas fee so as a user if I just do like about 500 milliseconds of work I don't need to pay gas to submit transactions so if you want to onboard users without like having them have to go to like a centralized exchange like buy and answer some of the other evil folks and and purchase tokens and go through kyc you could just you know give them 500 milliseconds of of proving time and that is that will be sufficient to submit one transaction and this is all also one of the great benefits of like having um you know having like constant essentially

work that needs to be done by the network to process transactions because you're literally like the the only really hard work being done by the network is just taking a bunch of proofs and verifying them in in higher order or in a recursive proof so yeah great question any other questions okay well thank you guys for bearing with me um I know our talk wasn't scheduled so I'm very appreciative to those who sat and like stood by I think there was a scheduling glitch so we didn't have many in attendance but thank you for for listening to me talk and uh yeah I'll be Meandering around again I'll be at Sea day um but uh oh yeah this is just some random gobbledygook yeah um you can uh

check us out it's here's the website if you guys are interested I don't think we have it in the deck so I apologize but uh yeah we'll be kind of hanging out um thank you guys for your your time yeah that's it thank you [Music]