EthCC 2: Jorge Izquierdo

test hello everyone good afternoon thank you so much for for being here my name is Jorge I'm the CTO at a tower 1 1 which is the foundational team working on the on the Argonne project and it's always so great to be back in be back in Paris it's a very special place for us is the first conference at our iguana Verde there's a project and last year we actually sewed the first version of argon 0.5 which is the first version of argon that uses Aragon OS which is the same client that was released later in the year with on the mainland so for those that don't know Aragon is a project that is building at the retail jurisdiction that attempts to compete with LAN jurisdictions such as France Spain or Switzerland in value creation and allowing borderless value creation and company and organization creation it's built on the theorem virtual machine and as of this morning we had three hundred and fifty three thousand in on the theorem a net so last year we kind of presented that this might be possible right now there are three hundred and fifty thousand life and it's available both on the web and mobile right now and if you want to get the pure decentralized decentralize application experience of Aragon you can use it on the desktop as well but what I want to talk about today is about Aragon beaudion because bodine by default in order Aragon organizations Bodine is the default route authority of the Tao but what that means is that all the decisions in detail that are important enough start as the Bodeen have been the route authority and then that boding interface can give the decision power to other to other entities what it means is that there's a lot of boating going on so we care very deeply about boating and as of right now there are 1 million there have been 1 million dollars protected by Aragon boating and it hasn't been broken yet so we're very happy about that but today the talk is going to be about how to improve boating but there's a there's a concept that we that we built into boating that we're actually not going to be changing that is called forwarding and you may think that if a lot of things go by boating and governance structures get like more and more complex because you have like a boat that triggers another boat this might get very complicated to operate and to know what do you have to do if you want to perform an action so things too forward in this is something that in the Argonne client automatically can calculate what needs to happen so you just have an intent I want to upgrade my tau to the latest version of our gonna way soar I want to transfer a hundred tokens out of this douse bolt and you just do that as if you had complete power and then decline will know how to what scripts it has to has to create so that those scripts get voted on and the intent that you had actually happens so Aragon Bodeen v2 we're kind of calling our going boating v2 to like an umbrella of different improvements that we want to shape at the same time but the the two major improvements that we that we want to do and what the word changing is number one we are we're gonna be removing the mini-me token requirement for all our GaN Taos this is something that it's been great for us up until now but we've been getting a lot of existing projects that have a token or protocols that have a token and also want to use Aragon and right now it's like you kind of need to wrap your token into like a mini-me token and this is something that is becoming a UX hurdle and we will go deeply into into why we're doing that and the second thing that we that we're doing is that we want to make boudin really really cheap and buy really cheap it's like this is so this boating has to be so cheap that it doesn't even matter if you have to pay for it because the cost is so low it could be virtually virtually free and this of course will give a support for all ERC 20 tokens and it will allows us it will require us to do most of the boarding of chains that we don't have the because of bodom to all of the notes of the network regarding meaning me a bit of background on why we have to use many meme mini-me allows us to solve the double boating problem the issue with your seat 20 tokens in regards to Bowden is the DRC 20 tokens are completely fungible a token doesn't have a serial number so if you don't take any active measures do you don't really know if I token has voted only one time or if they have bought it twice with the same token and if you can do it twice you can do it infinity times so the idea would be if you don't take any measures you have your tokens in one account you vote for the proposal then you move them to another account you vote for the proposal again and that until you basically win the proposal so there are like two things that people have done to resolve this issue one is required to log the tokens in order to vote so in order for you to vote for the first time you have to send your tokens to another contract and then your tokens get locked there until you either with rode your boat or you or the boat is over and you cannot boat again this is a major UX issue that people really I mean there are enough problems with getting people to vote and if you have to make them send their token somewhere else that's like a bigger issue and then there's the mini-me approach and what minimi does is it takes it takes it it basically keeps the history of token balances that anyone had in the token so in a normal in a normal token do you just know what the most recent balances for someone but meaning me actually keeps track of okay if you transfer tokens at this particular birthdate I know how many tokens you had before and how many you had after so Bodeen app can ask for token balances at the end of a block number and for that a token can only be in one place at the end of a block number so for this weave for kind of getting this token snapshotting without actually having to put the the check point in in the token contract which is pretty expensive we've done something that is called DBM story proves that we're using them for beau diem but is actually usable for a lot more use cases would you want to achieve with evm storage proofs is you want to prove to a contract in this case it would be the boating contract what a particular storage value in another contract was at a pass block height in a way that you can effectively have check point in for any any storage value of any contract at any plug number it uses EAP 1186 I believe or if get proof that allows us to use this requires archive notes for generating probes not for verifying them allows us to get a proof in in two parts that we will see now so first we have the account proof and in the can proof is when we go from the blog hash of of the particular block number where we're checkpoint in to the storage root of that contract that we're interested in so here we start with the with the blockhouse that we take it as true we can get the block has by by us by running the the block has sub code and then you kind of have to follow the unicorn if you see it you start from the block has at that block height you submit the entire the entire block header you verified that actually that block header has us to the block has that you already have then from that block header you can extract the root of this state try this is the this is the try that has the state of all the theorem accounts for that at that block number and from there you can do a marker proof of the from that root until the account that you're interested in in this case it would be the token contract that you're interested in in its storage and then once you get down to that account you prove the state of the account at that block number you can extract from here the storage root for that for that contract at that block ID and once you do this once you can actually catch this and use it for all the proofs for all the storage probes that come now for four particular token balances in this case and with this is very simple the route that you have is the route of the storage drive for that contract so in case of a token it would contain the token balances the snaps to the token balances for for that token so what you have to do there is you just need to know Edward storage slot that the what starts low at a particular token holder balances and you just perform a proof there and effectively you get the D check pointed block token and balance for that token holder so this is the this is the first part of the mechanism you can see on the on the right you can really see but this is like the entire the entire proof that you split it into and on the left that you definitely cannot see is the is the actual proofs that you that you submit to the to the blockchain the absence of this is that you can take any year C 20 that is already deployed and basically convert it into a mini-me you can ask for checkpoint eight block balanced token balances and the greater thing is that snapshotting doesn't impose a cost on every transfer this is like the main issue with with meaning me right now that you basically duplicate the cost for token transfers because you don't need to just pay for moving balances but for actually making sure that you have a check point at that at that height the issue the main issue is that these proofs are pretty expensive right now they're like five hundred thousand class and it's a 500,000 gasps and then like some minor details like okay you can only get you can only start proving this for the last 256 blocks and something that you need to be careful because you're reading Ross storage and a VM wasn't designed so people could do this so you need to be careful with this so with this we we get into the second part it's like how can we get make boudin very very cheap especially if we're gonna add something that requires verifying a proof of 1/2 500,000 guys that you have to do for each boat and the did the the pattern that we're following here it's something that it's called optimistic contract Stud have been kind of put a name bye bye Dean or like Twitter's favorite role and the idea of optimistic contracts is that do you basically upload the computation from from all the nodes in the network so say if you have to do compute intensive transaction everyone in the network will forever have to reply the replay the transaction to make sure that the result is actually correct the issue with that is like when you are doing like you're repeating that and that's why it has such a certain such a high cost optimistic contracts actually offload that computation to just one incentivize party that will commit to a particular result of computation and they will say okay I this is the result that if you run this dysfunction you will get and I will I will bet one Eve that this is a result then other people or the challengers can check locally that that's actually the correct result and otherwise they can submit a they can submit a challenge and here I prepared some some code of how how the optimistic pattern looks like I will actually upload this later as I suggest but the gist of it is someone commits to a result they provide the input to the computation and then if someone someone has some time to challenge it if no one challenges it after a certain amount of time you just take that is true because anyone could have profited from the from the opportunity of saying that that computation was actually false and performing the computation on chain so with this idea of optimistic contracts is we've built this this protocol this layer 2 protocol that we're calling V R P which is the podium relay protocol and the idea of PRP it's very simple right now Aragon Bowden just works like imagine that this is like a national election and in Aragon podium right now everyone that wants to cast a boat you just send it directly to the to the government and the government counts one by one boat this is a very inefficient way of counting boats so what we do is like we kind of batch batch people into like putting their boats in ballets a lot of people check the boats in these different balance at the same time and then you kind of like some the parcel tallies and you get your final results and this is kind of the same idea rather than processing every boat and chain individually do you just have this this entity that's called like a real layer that will get all the boats they will verify the boats and then they will provide an a commitment saying okay I have all these boats here and I commit that the result of verifying all the balances here and some in all these boats and some in all these boats is going to be X amount of of boats so you take this as true unless someone submits the proof and if no one submits the proof you just basically have take that that parcel tally is true and you don't even verify any boat but again anyone could have like said okay this is if you count this boat on chain you will see that they some wrong or this entity actually had zero tokens instead of 1 million and actually version of VRP that we've been posting now we're calling it simple boat in relay protocol because we only allow weren't relayer to relay boats at the same time this allows us to simplify a lot of issues in regards to relay years Griffin each other with like boaters sending boats to multiple relays and this central V layer needs to be can be either centrally appointed like the organization said this entity is gonna be your relay or it can be auctioned because these relays can can earn fees this may be a centralization factor you may say the good thing is like even if there's just one relay that kind of relay boats they still will be penalized if fraud is detected so they cannot commit fraud the only thing is that this this V layer could censor some boats that they don't like but of course boaters can directly submit their their boat and people may look for solutions in case that someone is active every layers actively censoring to change the relay here for for future boats the bottleneck that we found with this VRP is that the knife implementation of optimistic requires you to pass the input of the computation that that is gonna be optimistically executed you have to send it in 2d to the blockchain and basically you need to log it this is the way that you ensure that the input data is available because you actually need to input data to perform a third probe so a simple idea would be okay then rather than submitting the full proof like the full input you just commit to the hash and then you relay like you can rely on the relay or making that data available for anyone to just get that data from ipfs or whatever and then submit for our probes but here we have like the like a pretty interesting data availability issue in which the the relay er actually doesn't need to they can submit a fake hash of the input if they don't have to submit the full input so that no one can actually look for that and the the issue with that is like if no one has the input they can commit fraud because no one can submitter can submit a flood proof if you don't have the input that matches D that matches the hash and the but the bigger issue is that this my contract doesn't know what is going on you cannot prove to a smart contract that a particular piece of data was wasn't available and even if you add like a mechanism that okay if someone asks for that data then they had the relay er has provided because the smart contract doesn't know that that data were actually wasn't available this is an opportunity to brief the relay er so you have like a big issue not making the data available with log and this is what creates a bigger bottleneck because you actually have to pay a 68 gasp per byte of of input data which foreboding it's quite because it's actually what becomes the bottom the scale in bottleneck so with this our latest research is been around this new mechanism that we're calling optimistic data availability and we're actually doing like another relay protocol that we're calling a PRP and the idea here is that rather than having just one validator like one v layer that can submit boats do you actually have a set of M validators and that could be a number like 11 or whatever and you actually decide randomly who of these validators will be appointed every layer per its period of time but they don't know beforehand so the idea here is that each of these validators should keep the keep indeed the entire input data in case that they became the real layer randomly and they can submit the the computation and earn the fees by would you achieve here as well is that all of these validators do you kind of know and they actually need to need to sign a message saying that they have to data before someone can submit it that day that they are able to submit a challenge also if even just one of these validators makes data publicly available on ipfs or whatever then anyone can submit challenges so you kind of move this you don't have to put the data in the in in the transaction but you still get into a situation that unless more than two-thirds of the validators conspired to keeping the direct the onus validators and there's this one person that is willing to submit a challenge then you're actually you're actually okay so with this we just made the first iteration of simple voting relay protocol open source today this is a fork of the current are gonna have there's still like a proof of concept but it's actually working with storage proofs and and everything and we're we're super happy to be advancing on that regard and yeah as a kind of like a tldr of the upgrades that work to into bowden where you see in storage proves to remove the mini-me requirement and get snaps to the token balances in in a very in a way that doesn't impact all the token transfers and we're working on these bowling relay protocols to aggregate both of chain and actually just made the just perform the minimum amount of computation regarding the bowtie lean on chain and still get elections that you can trust that they were in braked so yeah that's all the research is happening in the in the Argonne forum that you have the URL there and we have work opportunities to come work with us on these types of problems if they're interesting to you yeah thank you [Applause] can they take questions yep for the challenging phase what time modes the order of magnitude of the time most that you are working are you talking about hours days weeks months for the challenging so when one challenge and how this challenging how long does it take so that you consider how time happens until you consider that the voting is valid yeah there hasn't been like a lot of research into finding what these challenge periods have to be the de varville that you have to achieve is that what is the minimum amount of time that you have 100% certainty that you're gonna be able to include a transaction on chain and then the reward for the validator needs to be like one or two orders of magnitude more than the cost of getting the transaction including a chain because gas prices fluctuate entirely and this this could actually be a risk if the if the reward for a challenge becomes too low in regards to what it's cost because to to get the transaction included because the gas price spikes that could be an issue so I I don't have a specific answer but I would say like in the order of magnitude of days thank you for the dog do you think that the your data availability solution could be used for other of chain scalability protocols such as plasma we feel we've been very focused on our own our own on our own research but I think it could be it could be an interesting thing to explore at the end of the day here if you compare it to like a blockchain type protocol here like the real layer that you select randomly it could be like thought of as the block producer the the block author so I think the it could be it could definitely be used do you have an estimate for when you might be able to get this out and if it's if it's gonna be a while what can people do to get going quickly at this point yeah so the basic implementation of the protocol is VRP it's open source now like the the proof-of-concept is is working but again as I said this is this only gets a 10x improvement over over the current boat implementation a VRP is when you actually start getting like three to five orders of magnitude or more scalability but that's definitely there's a lot of uphill implementation work there so couldn't say this year maybe yeah thank you [Applause]