Miden - Unbounded Scalability, Privacy, and Safety

Transcript

Hello and welcome everyone. My name is Peter Robinson and this is Dominic Schmidt who is from Miden and he's going to tell us all about the Miden technology. Um so before you dive in and share your slides Dominic can you tell us a little bit about yourself? >> Yeah. Hi Peter. Hi everyone. Uh happy to be here and thanks for having me. Um at the moment I'm uh the co-founder of of mine uh together with Bobin and and Azim. Um like from my background I yeah I studied math and philosophy and then like did a little bit of risk management in a bank but uh quite early on I

started uh with Ethereum actually or like uh trying to scale Ethereum with the Raiden network which was one of the first uh scaling solutions. uh it didn't really work out but I like kept trying to scale or like think about bridging and worked with consensus and the metamas team uh and then I met Bobin and I went down the decay rabbit hole because I think like and I'm happy to present it today did this um that we can scale blockchains quite efficiently with client side proofs like we get other problems it's always a trade-off space but I think it's pretty interesting to uh finally scale um blockchains when we have client side zero knowledge proofs.

Um and yeah, this is what I'm going to present today. >> Wow, that sounds really interesting and I'm looking forward to your talk. So, please um present your slides. >> Yeah, sure. Second. Um yeah and since we are uh like a small group so to to speak uh please always when you have questions just jump in and um I should have slides for everything now like hopefully I have slides for your questions then as well. Um but yeah like um basically uh yeah some slides are from our pitch deck so they are

formulated a bit more aggressively but like this is basically the the problem that we want to solve. Um like we think that um with transparent blockchains and almost all blockchains are transparent. um uh like you cannot get mass adoption of crypto and mass adoption of crypto would mean that everyone every day like uses crypto like cash um like maybe they know it or maybe it's like deeply embedded into their uh infrastructure that they're using that they don't know it but like crypto should be used for like as a protocol for um asset exchange and this would be mass adoption but like we think with transparent chains this is

not possible and a transparent blockchain is just a blockchain that adheres to the dogma like very high level of um don't trust verify, right? Like every blockchain, but they use um they um um verify by re-executing transactions. So they must be transparent in a way that every participant of the blockchain or every block producer um needs to be able to re-execute a transaction it to their own local state or to the the database that they keep um to verify that Ellis indeed can send Bob five whatever Bitcoin, Ethereum um and this

is a transparent chain and um with these chains like you will always have limited scalability because like transaction reexecution blows uh up into like this execution bloat. we will always reach this problem because it goes up exponentially and uh eventually we will get state bloat uh meaning that you need to uh if you always need to be uh able to reync from Genesis um if you don't want to trust someone um but verify it yourself then uh like the more people blockchain uh to use a blockchain then like it will um lead to to huge uh state bloat and you

will not be able to uh look it up efficiently anymore. Uh and like another problem and this is a real problem for us. We think it will be a real problem for everyone is that you don't get real privacy with transparent chains. So um whenever you need to have all the data handy to re-execute every transaction um it is very hard to like everyone's activities will always be traceable easily and like you can already see that today when you use tools like chain analysis um it's just a bit expensive but these tools will get cheaper and cheaper and one day I will have on my uh mobile phone like a chain analysis tool and I get like enter uh Peter's Ethereum address and it will like give me every

action he always did on uh on Ethereum but maybe also on Solana and like it will trace the bridges and like maybe even link it to your uh to Peter's real world identity and this is already possible today it's just expensive using ch analysis because there are some human work involved um but like this will be um possible with AI and like in a world where everything is traceable that you ever did I would not want to use blockchain technology Um and so I would understand like that mass adoption will not be possible with transparent chains and um it is just an inherently unsafe environment. Um so um like if like smart contracts are honeypotss basically you

can exactly see who owns what and what are the biggest honey pots. Uh the whole code uh is visible for everyone uh and the whole state of the smart contract. uh bugs are actually easily exploitable in transparent chains and so um yeah we think we need to change that to reach mass adoption and um our solution is to move state execution to the client side. Um and that is when you think of um like in the beginning we had sequential execution uh when you think of Ethereum so users sign a transaction and the block producer like sequentially applies these transactions in a block um uh to the state and uh like it's about I don't

know like 25 million gas or so you can put in a block. So uh it's the number of transactions and um they are applied sequentially and then like in an evolution of that is uh like what you see on in Solana or SUI or maybe even block STM from Ethereum. So you have paralleled execution right? So um you would say users still sign transactions and block producers they apply transactions in parallel. Um if they do not depend on each other and uh like then you get like quite like significant increase in uh transaction throughput and latency. But um uh like it also

leads to centralized systems and like bigger um failure points in the middle. Whereas uh we suggest um state and execution should stay at the edge or should be pushed to the edge. So users should keep their own state and should execute their own transaction and the network only verifies zero knowledge proofs and um this is because like um yeah it's hard to create a zero knowledge proof uh but it's like very easy to verify it. uh you just check like a certain polomial and um so it's like in a sense exponentially faster than um re-executing a transaction and you get uh like real parallel

transaction execution um and um yeah just like you get some other benefits but also some other problems and this is what I want to talk about today. Um so yeah I skipped that. Yeah, like um just up front like we aim to like we on test net and we aim to be on mainet end of the year or maybe yeah January, February next year. Uh and then um uh we hopefully um increase and optimize um certain parts of our infra um to be um yeah to be able to compete with uh systems like Solana or Hyperliquid.

This is at least the goal uh that we have and um yeah maybe to um show you like our thinking um um is basically um like we have these two arcs where we try to combine scalability and privacy. And when you look at the upper arc um uh like the evolution from bitcoin to ethereum or the um the right yeah the the next step or why it was invented is basically they said like bitcoin is not programmable enough. So they came up with ethereum and then like uh the salana people said okay ethereum is just too slow. Let's make execution as synchronous.

Uh and then like another evolutionary step we see is that um uh when you store assets in the account itself as you do it in with SUI then um you can um have it even faster if it's not the problem that um um multiple users needs to uh access the same smart contract uh like an ERC20 contract for example uh then but assets live like every asset always lives in in the out then uh like you you get a synchronicity uh and um then uh like from SUI like we learned a lot from everything and like we hope we push it blockchain design one

step further uh uh learning all from these uh other systems and we say like okay let's move stating execution to the client side and this is even faster or like um uh like horizontally even more scalable But also like we have uh assets in the account and like make execution asynchronous and so on and so forth. And on the privacy side uh like after bitcoin there was zcash to say like okay let's make things more private and like a lot of our system is inspired from zcash. Um then we had Alo that said okay let's make privacy programmable not only asset exchange and um we try to uh improve ALO like on several points hopefully uh we we can make it because

it's a great system AO um but we try to not invent a new programming language and like are way more like we hope to be way more flexible in in our programming model uh with a more modern zero knowledge virtual machine. Um yeah, and now let's dive deep into it. So um or are there questions so far? Like this is the very short version and then I can uh I can just like give you now the long version about the architecture and everything.

Okay. So yeah, as I said like the blockchain the core blockchain problem that we think uh hinders us from uh mass adoption is actually this um verification by re-execution. So uh today it is like there's one block producer and he um produces like puts a lot of transactions in a block and then every other node in the network so to speak uh re-executes these uh like looks at a block and sequentially reexecutes them. um and applies them to the own state and uh that means like all the nodes need to keep track of the entire state like they had different methods how to do that um like in a Ethereum uh Merkel tree structure or like in a UTXO

structure like u but like in um at the base it's always the same like you need to have some sort or like or you need to have need to store this uh the whole state in some efficient way and this is ever growing and you need to like always re-execute all the transactions to be able to be sure that um Ellis has five bitcoin to send it to Bob and um we think uh yeah as I explained before like this doesn't really work uh we actually um think we need way more privacy and scalability and that's why we try to yeah propose another design um so actually we want what we want to achieve

is we don't want to reexecute all um computations and put all the data on chain and like we say we can't scale if we have to reexecute all computations and put all the data on chain. So actually like we have these two goals like we don't want it and it's also like a necessity. Privacy is uh like a fundamental human rights to us but it's also a practical necessity so to speak uh for scalability and um so what do we mean by privacy? So actually yeah there will be no mass adoption with basic privacy and there are several approaches to privacy but yeah client sidec proves this one. Um,

we think it it might be a good way to privacy because like if you try to encrypt uh data uh or hide data on a transparent chain to achieve privacy um like it's always more expensive and slows the blockchain even more down uh like by around 10x. So um um like I think or we think offchain execution or clients and proofs is like the way to privacy that scales the best um and yeah like without ofch data execution is just way more expensive when you like use tornado cache or rail gun today on Ethereum it's just like 10x more expensive um and for scalability what do we mean

by that like uh we assume that maybe even some AI agents or so will have an Ethereum account one day or like a blockchain account. So we think in the ballpark of 10 billion accounts. Um maybe we need 100,000 uh TPS uh like at the moment we don't need that actually. But like if we really want to replace cash one day or Visa one day uh like that really it's like blockchain is a backbone of the financial system uh worldwide then like somehow we need to reach that and um we assume there will be non-trivial transactions. So uh some kind of smart accounts talking to each other or like some swaps and um this is what we want with scalability. So when

we look at the sheer numbers uh in terms of state what we would need like if we assume that one account is 400 bytes big this is the current average we would need 4 terabyte of state this is manageable uh like in in a bigger computer uh in RAM probably like if we assume that um assets would be in the account to make it more asynchronous then you would get like to 40 terabyte uh of state requirements um like which is already quite a lot to make it efficient uh like an execution uh for 100,000 uh TPS you need around uh 10 billion uh gas per second which is

like um Ethereum and all layer 2 together like uh they achieve I think uh 100 million at the moment so it's like an increase of 1,000x uh that you would need like it's not impossible but it's also quite a stretch. Um and then even if you think that yeah also the transactions grow gas wise uh then you would need uh like way more. So um yeah like at least the the current uh like with our current technology uh it would be hard to achieve uh this kind of bus adoption. Um and uh like another huge problem is actually uh bandwidth. Um so you need

like if you want to have 100,000 TPS then somehow you need to send this data around. So you need uh yeah 10 megabytes per second in a network or uh if you have bigger transactions maybe 60 uh megabytes per second and like I think at the moment we are at 2.5 kilobytes per second in Ethereum if I'm not mistaken somewhere no at the moment we are at 2.5 megabytes per second. So uh yeah this is achievable like it's a four four-fold increase um to um yeah to get to this like mass adoption like scalability.

Um okay so and then like uh in chop yeah computation as you probably know uh like normally computation works like on an Ethereum level that all users sign transactions send it to Ethereum. So this is the original model. We have the like layer two model where um uh yeah most this is not right slightly the rollup model basically uh so where transactions are batched and proven by the L2 and then you send uh um uh you verify them somehow uh on Ethereum itself and by client side proven uh means basically to us that uh transactions are um executed and proven by the user on this local device and

then um layer 2 or Ethereum itself would verify uh these proofs. Um and yeah like this would be like what we suggest like the third one and the same for data like originally all the data goes to Ethereum leading to this state load um like the the rollup model or like validium model. You can say most data goes to um the layer two or to the layer one. Uh you can compress it or do like some tricks with state diffs um to make it more efficient. But if you really want to have this layer 2 security, you need to use uh the layer one as like a data

availability layer. Um and uh in the Validium model, you can say okay the data goes to a separate DA layer uh and you only put the proofs on to Ethereum. Um for systems like maiden uh you can say like okay most data can stay with the user actually and the layer 2 only tracks a commitment. So what we suggest basically and I will show you how is uh actually that every user can act as its own validium or layer like or yeah zk roll up like the user can decide but basically the even the layer 2 just tracks a commitment of all my data and uh I am responsible to uh store my own data and this like leads to

a network that is way more more efficient. Um so yeah what we want is basically that users execute and prove most transactions themselves then the network doesn't have to do it which is more cheap and better like it scales better and uh the user store a private state locally uh so only the commitments uh go on chain and um basically like you have a chain a lot with a lot of commitments that you can even reduce like in a numerical tree like structure to one commitment and then um this is super Um and now I'm finally here to explain you how we plan to do that. So or like how we do it like we already are tested.

So um basically miden is modeled after the actor model. This is the core idea like we combine the actor model which is a well-known model in computer science um together with uh CK like an efficient CKVM. But how does it work? The actor model you can think of like a database uh with different actors and every actor is a little state machine responsible for its own state and this little state machine has an inbox. So actor A can send a message to actor B um and like when actor B then gets this message in its inbox and actor B can change its state uh according to this message if like but it's actor B is responsible for its own state. So it has like some rules

uh when it changes its state and if it does uh change its state then it can send messages out to other actors uh to trigger state changes there and this can happen completely asynchronously. So actor A can send a message to actor B and actor C and then at the same time B and C can change their state according to some rules and then like the network basically it's like uh full of little state machines sending messages asynchronously to each other. This is the actor model and um the cool thing is that yeah messages are produced and consumed synchronously and um we say you can build a blockchain with that. So um like our actors are accounts and you can think of Ethereum

smart contracts actually they look pretty similar as Ethereum smart contracts. So they can store assets like in this account one for example you have 10 maiden tokens in the account and it has some code interface with which you can interact with. It has like some storage where you can store data or um some variables and um it has um a nons like our actors are basically accounts or smart contracts and the accounts can send messages to each other which we call nodes. So we combine Ethereum's account model with Bitcoin's UTXO model and Ethereum accounts are our actors and these UTXO like structures uh uh nodes

and uh basically you can think of like account one in a first transaction we define like we redefine what a transaction is a transaction in Miden is the state transition of a single account like whenever one account changes its state we call that a transaction And like so in a first transaction, count one creates a node or a message that now carries three um min tokens. So these assets can live in these basic entities which are actors and like which are accounts and nodes. uh and like um in nodes there they can live assets or in uh accounts and so in the first transaction account one creates a node

carrying three assets uh three mining tokens and in a second transaction uh account two can consume this node and changes its state and like whenever an account changes the state we call it a transaction. So basically we need two transactions um to transfer an asset from account one to account two and um this is completely independent from the state of the rest of the network. This is how we replicate the actor model, right? So like um there's a transaction whenever an account uh changes its state and like you can like as a result of your state change there is a node or like there can be a node and uh you can like in a transaction consume or produce nodes and um like

this is how an account look like as I said like it's pretty similar to Ethereum. It has an ID. It has a nons some uh code uh um like some storage and like assets. you can store many different assets like on Ethereum can only store ether in an account like in a in a native account and like the rest of the assets are stored in these ERC20 like structures and as I said before like we follow the SUI model actually we think it's cool if you store all the assets in an account and there are no ESC20 kind of contracts because then it's like way easier to parallelize things um and um yeah like um this is how an account look like and a note basically at least like an ephemeral

object like it's yeah you can think of bitcoins udxo nodes it's a bit more uh advanced in a sense that like nodes have scripts like also executable code uh that cannot be changed and uh like whenever you want to consume a node you have to execute the script um so you this is basically you encode into the script spend conditions of the node um and I can say every like whoever wants to consume this node needs to do xyz or needs to read the Oracle data there and I don't know do whatever and then like when you prove that you can you have done all this uh then uh you are able to consume the node and like get the assets from from this node uh nodes

have like inputs um uh like which can be injected in the code a serial number and assets and um basically this is yeah as I said like a transaction is like this is inspired by Solana when You think of like a Solana program which is a stateless program. It's the same with a transaction. Basically, it's a stateless program that injects or like as an input has the account and gets the account in a new state, right? Uh and uh other inputs are like up to 1,000 nodes and uh gets up to 1,000 nodes out. But uh like a transaction, so it always only involves a single account and this is needed for to get this a synchronicity.

That's why I can create a transaction, execute a transaction at the same time as Peter and um now like this is how we replicate the actor model basically in Miden. So we change the state model of Ethereum and kind of got inspired by yeah Bitcoin, Ethereum and SUI u and this is what looks like right. So you have actors, they send messages to each other or accounts, they send nodes to each other. And um the cool thing now is that because like this transaction program, the stateless transaction program is written in uh in a way such that our zero knowledge virtual machine understands it. I can create a proof for every transaction. Meaning that for

every local state change, I can run it in our zero knowledge virtual machine, which is just a virtual machine that always creates a zero knowledge proof of the correct execution of my program. And my program is a transaction kernel. So I run a transaction in Maiden, I get always a zero notch proof out of it. So for every transaction, there's always a zero notch proof. And then uh I just send this zero not proof to the network together with some new data like sometimes I need to say here are I have new nodes or um but like that means for every transaction like local state change I can create a zero knowledge proof and the network doesn't even need to know what happened in my transaction

it just needs to know this is my old commitment this is my new state commitment and here's a proof that you can change that meaning that every account looks like from the perspective of miden every user account or every smart contract always looks like a zero notch uh uh zero notch rollup looks like from the perspective of Ethereum right so you have the state the old state route the new state route and here's a proof like the rollup operator sends a proof to Ethereum and says like okay this is a valid state change and this is how um every user on Maiden uh basically or every account on Maiden can change its state um and so like stay private.

So in this transaction proof you don't need to know what happened inside um and yeah basically these transaction proofs then they get sent to um the the nodes like at the moment it's a centralized node but we also want to get decentralized obviously uh like and then they they get the batched together like this is a step that you probably know it's uh in used in recursive verification. So there's a virtual like zero knowledge virtual machine again and that inside this virtual machine you verify five proofs like in a batch and then you get one zero knowledge proof out that says like you correctly verified five proofs and then you can

basically reduce these five proofs to one proof and you can do that several times and in the end you get one block proof and like a block describes the state transitions or transactions of every account in a certain period of time and like you can condense that to one zero proof. Uh and this you can then send to Ethereum uh to yeah basically make it secure as long as you trust that like yeah like you trust the math involved that you can stack these proofs together and um I put it but this is the idea. Um yes and these transaction proofs they can be done locally and uh the cool thing is in parallel um because it only

involves this your one uh uh account and uh so you can like in theory reach very very high TPS like in theory 1 million people or even more can do that in uh in parallel. uh but obviously you reach uh like in this batching step you reach the the the scala like the scalability in terms of uh a throughput uh bottleneck uh because the question is like how fast can like how many proofs can you verify in one batch in this recursion step and uh this is what we are optimizing like we think we can easily get to uh uh 10,000 um bps so to speak Um um yeah when when we use this um like there

there's a dedicated hardware chip for uh for pro3 which is a system that we then use uh to to get these numbers because uh yeah there's everywhere repro like um like the maidenv is like a custom like uh a customuilt virtual machine for uh blockchain use usage. like it's um uh like the the RAM requirements are pretty low compared to other leakms and so we can um like make a lot of usage of these like FPGA chips uh or like VPUs from fabric for example and then like to get to 10,000 DPS like if the batch producers or batching nodes and um uh

would use this chip then 10,000 DPS is like in the recussion step uh possible but after that we also hit some bandwidth problems so um we would need to wrap the proof again into another zero knowledge system like a cross 16 or so uh to be able to reduce it and then you can send it around in a decentralized network. But in theory like yeah like this is the bottleneck this um how you can recursively batch uh and put them together in a block. But verification is like super fast and um you can try it later. I can send you some links of our online playground and um so yeah in theory this system is highly parallelizable and um scales quite well. Uh but like when you put

execution and state to the user you get other problems obviously like this these are the trade-offs. like the user doesn't only need to store like his private key which is already a problem for a lot of people but uh you only you also need to store your state like no one can recover that uh whereas normally the blockchain is your database and um uh obviously it's a latency as well if a user executes like creates a zero notch proof in his browser uh like we our goal is to get it done one second but obviously um Um yeah at the moment in the browser it's like without like with delegated proving so like if some other server rates you approve then you get it

in 1 second but like it would be 10 seconds in the browser like in Rust it's already in 1 second but um yeah we hope to to get it done but like yeah latency and state storage requirements are uh the problems of this system then but like yeah so obviously another problem is that um uh a public shared state and this is what you want to achieve with blockchains. So we don't only want to do payments but uh for that we also have um like network transactions. So you can also uh basically uh let the network prove and execute your transaction and that is when you have like a smart contract state like an AMM or so um that you cannot really uh execute locally um um or like when several people want

to execute the same smart contract locally then you have these nasty race conditions obviously that you cannot really solve on a protocol level and for that we have network accounts and network transactions and then you like yeah protocol wise use a smart contract like almost like on Ethereum. So um like in our system we try to push state and execution as much to the user as you can but uh whenever like and like the so that the network um like for these minimal use like for these use case where you really need it you can still use it like um with a network transaction basically. Um yeah so and then like accounts can be fully public

and then you can think of like on Ethereum so the full data is on the on chain and in the block explorer I can look at every storage slot of this smart contract or they can uh be just with this commitment as I explained before um and then no one knows anything and you just know the the state commitment of this account and then every account is only 40 bytes uh which is quite nice um but users are free to choose whichever model they want like a public account or a private account. Public accounts might be useful if you I don't know like you want to build a simple counter contract then it's a public account everyone can see the state of the counter uh but if you like your private wallet or your nose is safe uh might make more sense if uh I keep it

private and I have like a lot of backups for my state and so this is like these are the two storage modes public and private as I said like uh accounts are also like stored in a merry like structure but um like an account can be public and then you see all the assets storage code and nons whereas when it's private then everything you see is just like a commitment to this um account state and so in that sense privacy like this is a paradigm shift like it's cheaper option on maiden whereas on ethereum it's the more expensive option right so on ethereum everything is public but then you hide it and you pay for it whereas on maiden um you can choose like private or public but like public means you put more data on chain

So you pay more for it. So privacy is the cheaper option on Maiden. That's why like like privacy for us is a means for scalability. The more people who use Miden privately, the better the chain would scale. Um and the same for nodes like nodes are you can think of nodes are like ephemereral smart contracts so to speak or like shortlived objects. Uh but they can also be like public or private. So I can uh have a public node and then everyone sees like what's the content of the nodes like I can still say only Peter can consume it uh but like everyone will see it and then like it's just easy for I don't know if I don't really care about privacy in that

sense I can use the blockchain as a transport layer so to speak uh and private nodes like would work quite similar to Ccash um where yeah like you would only see a commitment and no one can know is this like from whom uh this node or is it already consumed or not? Uh and what's inside this node and then I have like a side channel to Peter I always use you as an example now would have a side channel to Peter to send him the data and he can consume this note. Um yeah the node database is just like um um also to achieve this parallelism uh is like an append only accumulator.

It's a Merkel mountain range so to speak. So everyone like we can just add new nodes to this uh accumulator and uh I can never change or delete a node uh in that sense uh I can just add stuff to this database and um the cool thing is that like I don't need to have the latest state to be able to add stuff to it and I can still create a valid proof um that ex it exists now in database and um that's quite like a cool data structure but in yeah it So it's a bit different than on Bitcoin with this UTXO database, but yeah, I'm happy to dive into that as well. And then there is this nullifier database to achieve privacy. So we store in the node

database, you store these are the nodes that exist either public or private and nothing more. Um and then there's the nullify database where you say, okay, these are the nodes that um were already consumed. And so we have this in two separate databases to um uh to break the linkability. So when I consume a node that no one knows um which the existing nodes now I have consumed but I still want to prevent double spend. And this is actually quite interesting. So like every node has a unique nullifier and a unique uh note ID and you can think of I know like it's just two different ways of hash to to hash the data inside the

note. So when you think of a node that has three data fields and if you hash ABC for example uh like then it's the node ID and this is what we store in the um a node database and when you hash um CBA um it's a different hash and then this is the nullifier but like these two hashes they are not linkable if you only know the hashes but if you have the node data then it's quite easy to like see that this nullifier belongs to this node. So um that means like an external observer who just sees these two hashes knows only that okay this node existed and there's another node that was consumed um and if you have the real node data um then you can consume a node

and like create a valid nullifier basically and uh create a valid node ID. I have a slide for this later, but it's actually quite a nice system uh that you can um only create these nullifiers um or compute them correctly if you have the whole data. Uh so I need the whole data to consumer node. Uh but everyone can verify that this is like a valid nullifier basically but no one can link them together. This system is from from Ccash. Yeah. Um so yeah, we follow that here and yeah, this is then what we have like as a global state on Miden, right? So uh um like this is how the like the the block producers see the network. They have this account DB, the nodes DB and

the nullifier DB and um like this is a block then like the updated accounts and either be public or private like so for private accounts it would just be always a new state commitment. Uh for public accounts it would be the full data you have the created nodes. For private nodes it would just be like these are new nodes and here's the commitment. or public nodes. It will always be like these are the new nodes and they look like this. And then uh the nullifiers is just like a set of um nullifiers um like yeah like inverted hashes of like or uh hashes of node data that you cannot really link to node ids. Um yeah and this is like the cool thing is now um uh

for decentralization like if I would have 100 different block producers um they like the they only always need the a commitment to all this data to be able to produce a new block or to verify a block. Meaning that um even for public accounts like in theory like the first validator could store all the public accounts that start with A but the second uh block producer could then for all accounts that start with A only store the commitment even if he knows the public data but just to like prevent state bloat in a sense like it's just like someone needs to store uh uh the full data but you could still verify a proof against only this uh commitment

and so like not every validator or like um block producer needs to know the same data to be able to produce blocks and so um you can have like a different way of thinking of um preventing state load uh like in theory like if indeed 10 billion people produce miden that will come in handy uh if we don't reach that and uh will not be that useful um but yeah so this is basically our like storage and execution opt So you could have onchain data like these public account, public nodes and network execution and then it's kind of the similar system as you have on Ethereum.

Um you can have uh also local execution um and off-chain data and then you would have completely uh private transactions and uh way more scalable um transactions that happen and um yeah this is like um as what I said before like if account one sends a note to account two then in a first transaction like this is what I showed before right so on one changes it state creates a node and then in the first transaction you would record a note in the nodes database. So this is just like it's like the node ID basically um is the hash of these data fields ABC so to speak. Um and then um account two somehow knows these data

fields ABC like because account like the user of account sends him the node data via signal or so uh or email or like we have a transport layer for private nodes as well and then account two like would consume this node because he has the data and create a nullifier like another hash the node data and send it to the network and say like look I correctly consumed this node here's the proof for it and here's the new nullifier for you to add as a result of this transaction uh uh program. And then um the the my node or the network could say okay yeah that's true and here's a new nullifier and then like this node is consumed. So whenever someone else tries to record the same nullifier then obviously the

nullifier is already there but no one can link these two things together. Um yeah that's like I know it was a very long monologue and I'm happy to answer questions or jump in. Yeah, I think um there are a few questions. I know that Dev put one in and I put a few in, some of which I think you've now answered, but um Dev said where uh where are the script where do the scripts reside? Is that part of a smart contract or operates in the protocol level?

>> Um yes. Yes. Like the um so there are two scripts like best I show you in the block explorer itself. Then um do you see my explorer now? >> Uh yes. >> Yes. Okay cool. So like there there are two parts of code like there is account code right. So here is a public account for example and there I can see um like this is the account code like it looks a bit ugly yet like we have a rust compiler but not yet updated but this is like so it lives just in the account like it's a data field in the account but this is a public account. So I can look at it uh uh onchain like this is the same as when you would go on ether scan to a smart contract and you can see

the code. I can even interact with this code like I can uh yeah as with Ethereum and then there are nodes um and yeah created nodes for example when I look at a public node then you would have the same like here is the script of the node like these are like this are the encoded span conditions like at the moment in our assembly language again which is uh like hopefully in four weeks we have the full compiler. So uh the scripts uh uh live with the um the account code lives with the account. The node scripts like I said data field in the nodes uh and then there's um um a transaction script which uh like a user

can add to this transaction program uh in the end to like for example sign a transaction. Um and then uh you have just the the transaction kernel basically which puts all these things together uh uh like uh it you tell the transaction kernel uh I want to consume these five nodes. this is their script and I want to execute them against this account. Uh and then um the transaction kernel like puts all this minor assembly code together or like in the future rust code together and then uh it executes that um and so yeah the script lives always with the objects itself. I hope this answers your question.

>> Yeah, it makes sense to me. So, um I think it's um and yes, uh Dev said yes, it does. >> Okay. Uh I I had a question about so which I think I know the answer to anyway but if the pre-state proof um so in a when you're posting a proof you're going to have a pre-state postate and I guess if the pre-state doesn't match the current state then the proof gets rejected I guess. >> Yes. Yes. You can think of like a maybe I can show you as well.

Um yeah like uh like the zero knowledge proof has always like a public input and a private input, right? Um and like uh in the public input there would be um the the old state and the new state and um like yeah this would be like or the old state commitment and a new state commitment and um this must match what the um verify has like in his database basically. Um it's the same way as like it would be rejected in a zero knowledge roll up on Ethereum. If you would say uh like this either not the old state, it doesn't match, then the proof would be rejected anyway. And like or if like the proof would result in a different um

state, then it would also be rejected. Like these public inputs uh basically are defined that you need them uh uh to send to the verifier uh to be able to verify it. But since it's only commitments um like you don't know what's behind this these commitments but yeah pre-state and post state is like uh public output so to speak or the post state is the public output of a pro >> yeah that all makes sense. Um the other another question is so if the notes are going to be stored on the blockchain um do the unspent notes like do they become state bloat essentially?

>> Um uh yes and no like um yes uh so um like if um yeah like we uh at the moment it's not a problem yet. uh and like if it's private nodes then it's like slowly increasing uh but like we need to like we have a system of apps that um you can then also like all unspent nodes uh you put them into like a structure where like let's say after one year or so uh if you haven't uh uh uh consumed your node then um like it's still possible but you need to store like a merke inclusion proof locally for example uh so at some point they would

be need to discard it. Uh or like at least um someone else needs to store like you would only store the commitment anymore if this really becomes a problem like offstate load or yeah you need a separate data availability uh layer. The same for nullifiers like it in like it just grows much slower than on transparent blockchains. Uh we think uh but it's still like eventually you will run in a state thing or also just with the commitments probably. Um so you need to have a commitment for old commitments and then store this data somewhere else.

But yeah, you will run into similar problems. >> Yeah. Yeah, it makes sense. It makes sense. I think the other two questions I had um which was so if you're going to if everyone's got going to own their own state does that mean they have to use Google Drive or Apple iCloud or some other um solution to make sure they don't lose their own data and I think the it sounds like the answer is yes. Uh yes like yeah at the mo yeah at the moment it's like Google cloud and your local machine uh we are working with like um a company now uh for private state uh management solutions and like there are there could be decentralized solutions like IPFS or

>> yeah even Celestia or a whale um and also like you need for private shared state you need a more sophisticated solution uh uh like when we share a multisc together for example And um yeah there are some decentralized or centralized solutions um where you can store that and use that hopefully it will be abstracted away from the user completely but the app producer needs to think like the app developer needs to think about it. >> Yeah for sure for sure yeah and and then you said that private notes need to be communicated offchain somehow. So yeah which yeah so that's the answer to that question. So, I think we've you've done all the questions. Um, and no one's jumped in with more questions, so I

think you're all good. >> Perfect. Can I show your uh >> Oh, yes. Yeah, the merch store is still there. Um, which is which is good. Buy a t-shirt. Uh, next slide. And, um, yes, we've got some more talks coming up. um a new a a new way of thinking about data access for blockchain. Um I'm going to go do a deep dive on 7702 and then um Paul Bose has got a a um thought on um circle currency protocol um which is a new way of thinking about sharing money. Um yeah, so anyway, some exciting talks coming up. Um yeah, and

we've if you're here today, we're on YouTube. If you're on YouTube, join the talks live and ask the speakers some tricky questions. There's a big long um Slack invite link. Um and as well, every now and again, we have example code. Um yeah, so there you go. So Dominic, that was awesome. Thank you very much for um giving us the latest um I mean so you gave a talk about what two years ago on miden and it the world has changed a lot with miden I think your your your conception of the ideas has evolved so much and it's really wonderful to see.

Yeah. Yeah. It's like uh but it's also like for a very long time in the making I guess uh like at least Bob and u like he yeah developed this very fast zero knowledge virtual machine for blockchain use case like already like in Facebook like with their currency and then like so he started 2017 or so with it. >> Yeah >> it's a very long development. >> Oh good things take time you know. I I I am sure when people were working on the wheel back quite a long time ago, they didn't, you know, wheel 1.0, you know, like didn't just happen like overnight.

There was probably a few iterations. >> Yeah, it's true. But yeah, if you want, you can also like I want to show you the like this is a super easy way to interact with uh Miden. I just share it here in the chat. Um, but yeah, you can try out our playground and send around some transactions and there's no assembly coding or so needed. It's just a playground where you can use it in the browser and do some client side transactions. >> Great. And I'll share that link um in the description of the YouTube video too so people can easily get to it. So look um thank you very much um again and very good to see you and um yeah thank you

>> wish you all the best. Bye guys. >> Thank you. Bye bye. Bye.