 So, we're in the TruVet house in Marin, north of San Francisco with the full team. Robbie, Harley, Matt, Sammy got Fred back there as well, and Jason's mucking down the stairs. That is awesome. I had no idea. Yeah, it's a big showing. Yeah, I'm excited. I'm trying to figure out how, how, how's our bounty thing going. Hey guys. Hey, Hudson. Is there anything? Are you, are you going to, oh, I think they will send the links, and I, are you going to set up a recording thing and, okay, again, figure out how to record and livestream it? So, I can't livestream it because the internet connection at my Airbnb is not good enough, but what I can do is record it, so I'm going to record it, but I'll have to be on mute for, like, most of the time. Okay. Cool. Also, we both, both teams have recorded demos in advance of the TruVet piece working and then of the Doge submitter and agent also. So, we've sent those links via email. So, in addition to this recording, we can send those out because it's more of a deep dive demo. Okay. Perfect. Yeah. So, the other one, we took 20 minutes. Go ahead guys, whatever you want. Yeah, we took 20 minutes to demo it on Rink B and send the transactions live and we'll do, we'll do something similar on this call. Perfect. Cool. So, with that, you guys, the judges maybe want to give a quick shout out to the judges, maybe want to give a quick, you know, 30 second intro, who everybody is, and then we'll just kick off. Okay. So, do you think that everyone, Oh, should we, should we start to wait more? I think it's all three. I'm not sure who is here already and who is not. But here's an overview. Okay. I'm Alex Bondesande and I've been with Ethereum since a long time. I've helped set up the original bounty contract, which now has about 1491,000 eaters, which used to be a lot more last week. But hey, This is crypto. Anyway, I'm, I, I, I basically helped set that up. Back then because I thought it would be a good project and I sort of, that's how I got involved. And I believe right now we are talking about bounty of distributing about 20, 25% of that. Right. So that would be about 307, 272 eaters, Which is, I don't know how what's the price, but about $300,000. Of course, I would say with the current price or something like that. So this is the, this is mostly the goal of this meeting is to figure out if those, if, if all those guys out there in the teams have, have done a good job on actually worked on the, on the bridge, they promised they would, would be working on. And if so, I would be super happy to start, start the request and see those, those little dodges start rolling down bridge and crossing the, crossing the river. I, I even try, I have to say, I, I try to make a little, a little Shiba, you know, image for this, for this meeting, but I, but I, I didn't go through with it. But so I, I might still do it. I might still do a little Shiba, you know, crossing a bridge for, for this. So that's it for my introduction. Awesome. Okay. I'll dive in. Hi, I'm Ross. I'm one of the Dogecoin developers. I'm really excited to see this. And yeah, I mean, I'm, sorry, if I'm flicking over to the right, this is me reading the background material. Sorry, I haven't really had enough time to prep. I do apologize to everyone. But yeah, so looking this way, it's me reading background material, but it looks really exciting. And yeah, good luck, everyone. Sorry. I'll go ahead. I guess I'll just continue because I'm the other half of the Dogecoin Core development team that's active right now. I'm Max also known as Langehans. And yeah, I don't have anything else to say, I guess, but I'm just really excited to see this project going along. Okay, cool. So I'm Hudson. I am on the multi-sig for the Doge Ether Bridge contract. And I work at the Ethereum Foundation doing some internal communication, Reddit moderating, website redesign, documentation, and a bunch of other cool stuff. So I'm really excited to see this and yeah, I'm recording this. So because I'm like recording environment, I might have to put myself on mute for the rest of the time, but just know I'm cheering you guys on. Awesome. Thanks guys. So I think with that, Oscar, let's get started. There's Christian. Hi, Christian. Nice to see you. And make sure that the Piper introduced himself. Is Piper here? I'm here. Hi, I'm Piper. I run the Python team at the foundation and it's been around for a while. I'm on the multi-sig and I'm really excited to see that little pile of Ether potentially go somewhere after all of these months and years. Christian, all the judges are introducing themselves. So why don't you make it an honor? Yeah, let's say we prepare a presentation. Can you see my screen? Yeah. Yes, I was waiting for you just to see if Christian could also make a quick introduction. Not that he needs one, but just say hello. Hi, I'm Christian. I'm not a judge, right? Are you here as a participant then? I think you contributed some notes. Yeah, exactly. Shall we start then? Yeah. Yeah, let's do it. Cool. So, okay, let's start with how we plan the agenda for the goal. The idea is to first introduce ourselves and review the objectives and the stages of the project. And then we will explain the solution we created and do a demo of it. And we plan to do our thing in 30 minutes. And then you will have as much time as you want for question and answers. So thanks for being here. My name is Oscar. And I started working on this project in August. Before this, I built a two-way bag for RSK. When I started the project, I thought I could build the entire thing by myself. But soon after that, I realized it was a little bit more complicated. And I realized that we needed, like, a interdisciplinary team. And I found Trubit was already working on solving a key part of this problem. And so we joined Trubit, Confabric, and I. So now I will let Sina, Trubit, and Pablo, Confabric, to introduce ourselves and their team. Maybe Sina, you can start. Sure. So I'm Sina from Trubit. We're here with the whole team. Christian also contributed in a massive way to this project. And we really come in in the piece. So for this bridge to work, the Ethereum smart contract that we'll get into needs to verify Dogecoin's proof-of-work, which is the S-Crypt function. And that is both memory-hard and computationally intensive in a way that doesn't fit within the Ethereum block-cast limit. So we've built a, we've implemented Trubit, specific to the S-Crypt program, and are going to demo it on RinkB. Pablo? Pablo, I started Confabric in 2014. Working in different blockchain projects, especially in Ethereum. And we work with Oscar, with RSK, to build their bridge. And that's why he approached us to work for this bounty. And Ismael, he was the developer who was working with Oscar side-by-side in RSK bridge. I'm a junior developer at Confabric, and I've been working mostly on the door-to-layer part of the bridge project. But yeah, I can start all that long ago, so I can start watching the... Cool. So I will... Can you see my screen? Yeah. Ah, cool. Right, so let's continue with it. Yeah, they can. Okay, that's Tim. Now let's review the objective of the bounty. The idea is to create a fully decentralized bridge between Dogecoin and Ethereum. Many people also refer to it as a two-way peg. When I discussed the project with some people, many people ask me if this is kind of a decentralized exchange or kind of atomic swap. Those are different things to what we are doing, because in the bridge, the two-way peg we are creating, we are not converting one coin to another, but we are moving coins from one blockchain to another. So on the Dogecoin to Ethereum side, we allow users to move coins on the Dogecoin blockchain to an ERC-20 contract, which we call DogeToken. And then the second part is Ethereum to Dogecoin. We allow Doge and Holder to get their Dogecoin back on the Dogecoin blockchain. So, as I said, well, the project has two big parts, Dogecoin to Ethereum and Ethereum to Dogecoin, and we would like to map, like, project stages to bounty payments. So using the feedback Alex gave me, we are presenting this proposal. And today we are just presenting the Doge to Ethereum side. Since that part is not complete, we are not asking the entire 50%, but just 25%. Cool, let's review the solution. Are there any questions so far? Okay, I guess there aren't. Cool, so this... Sorry? Okay, sorry. This is kind of the big picture of the solution. On one end, that's the Dogecoin blockchain. And on the other end, there is the DogeToken contract. So if a user wants to send money from Dogecoin to Ethereum, she will have to create the Dogecoin transaction sending funds to a special address that we call the lock address. And then we have this piece of software we call DogeSubmiteration, which is constantly monitoring the Dogecoin blockchain for new transactions. And once it finds a transaction to this special address, it will relay that transaction to the DogeRelay. The DogeRelay will do a couple of checks and then notify DogeToken that there is a new transaction. And DogeToken will mean the same amount of, let's say, three Doge were sent. It will mean three new DogeToken minus fee. So DogeRelay, in order before sending the transaction to DogeToken, needs to do a couple of checks. The most important one is to make sure that the transaction is part of the Dogecoin blockchain and it's not made up. So in order to do that, DogeRelay needs a copy of the Dogecoin blockchain in the smart contract. Actually, it does not need the entire blockchain, but just the headers. So DogeSubmiteration will not only relay transactions, but also the Dogecoin block headers. So when DogeRelay receives a Dogecoin block header, it will check its message and it will add it to its copy of the Dogecoin blockchain. The thing is, one of the checks that need to be done is to validate the proof of work. To do that, we need to execute SCRIP, but as Cina was saying before, if you try to do that on chain, it will need like 300 million units of gas. So we integrated DogeRelay to the SCRIP interactive verification protocol that Trubit created. So before DogeRelay adds a header to its copy of the blockchain, it will send a header and a proposed hash to the Trubit contract. And after some time, the Trubit contract will reply that the block is okay and the DogeRelay contract will add it to its copy of the blockchain. Now I will pass on to Cina. He will explain in more detail how the Trubit protocol works. I have a question before we go on. Yeah, sure. Might be done, but how do we check that the headers represent the latest version of the Doge blockchain? Right, so the DogeRelay has a copy of the DogeCon blockchain. So as new blocks come in, they are being added to the blockchain. So in order for a block to be valid, it has to be connected to the previous block in the blockchain. And also anyone can submit a block to DogeRelay. So eventually all the blocks are being submitted. If anyone is submitted in valid blocks, they will be discarded, either because they break a rule that DogeRelay can check or because it breaks a rule that Trubit can check. I don't know if that answers the question. Okay, so let me see if I can explain it back to you. So basically what happened is that I will submit a block and if I submitted a block that has a larger, that is sort of a fork of the Dogecoin, then what will happen is that someone else can later submit another block there and you will be able to verify that that new block has a higher proof of work than the one that I had submitted, therefore mine is invalid, is that it? Yes, it is because DogeRelay, it's kind of a Dogecoin node. It has a large amount to the Dogecoin node, so it can know what blockchain is the best chain and what part of the blockchain are forced because of the proof of work. Okay. Yeah, that answers my question. Cool. Any other questions before we move on? Yes, actually. I wanted to ask sort of in that same vein in terms of chain reorgs on the Dogecoin chain side, is there anything in there built into Handel? I don't really know what the timeline here is, but is it possible for temporary small side chains to be validated and potentially coins to be issued through there and then the chain reorg happens and those headers are no longer valid and how is that handled or is it? Right, so that's a valid attack on the system. So to avoid that attack, what we request to a transaction is to have a number of confirmations, not just one confirmation. That's exactly what I was curious about. That answers my question. The exact number of headers that we will request in the production environment, it will be kind of a trade-off between how long we want to make users away and how costly is an attack of creating fake blocks. But yes, we do have transactions and aren't relayed until they have, let's say, 10 or 100 confirmations. Sounds good, thanks. More questions? Okay, so I guess I'll take it over from here. So like Oscar said, one of the main things that the Doge relay contract needs to do is verify the proof of work provided with one of these block headers that involves... I'm really sorry to interrupt you. I forgot to do one important thing that I have to do before you start, which is sending the Doge transaction that I will need in the demo. Yeah, first. Before I'm moving to Sina, let's go to my Doge client. I'm going to send a transaction to the lock address. I have to do this before Sina continues because if not, the transaction won't confirm in time. So let me copy the address. So this is the address. I'm going to send like 293. Okay, that's actually sent. Then confirm. Sina, you're good to go. Then we will go back to this point. Okay, just a quick question. Which address were you sending to? You were just sending to a custom address that locks it, right? It's not any particular address. Well, now a day we are sending to an address that actually is a burn address because we only have one system inside. We are burning Doge as we get the tokens. To be more technical, the address that you just saw is the address that matches the public key hash 3, which is impossible to get a private key that matches that. So we are basically burning Doge coins so far. Sweet. So like Oscar was saying, one of the main things that this Doge Relay contract needs to do in verifying a Doge header is to check its proof of work. And Doge's proof of work is the S-Crypt function. Doge was a fork of lucky coin, which is a fork of litecoin. And because of that, they all use S-Crypt. S-Crypt is a memory hard and computationally intensive function that involves 2,050 steps of the Salsa 8 hashing function executed one after another. And because of that, it doesn't fit within the Ethereum gas limit. And this contract can't simply take the plain text header fields, run the function on them, get the S-Crypt hash and compare them with the proof of work value, provide it and check that it's correct. So this made it a perfect use case for Trubit, which is what we've built. So I'm going to just share my screen now. Okay. Can you guys see everything? Is that a yes? Okay. So this is the GitHub repo for our project, github.com slash Trubit foundation slash script interactive. And we have this schematic of the protocol that I'm just going to walk you through. So there are two main participants in this protocol. There's the Trubit claimant up here and the Trubit verifier. So just to kind of help orient you, this is the Doge blockchain up here with new blocks getting created and everything below this line is happening inside of Ethereum. So the Trubit claimant is the person who provides a block header and claims that the script hash was correctly calculated from the plain text fields. They're providing, they're sending this transaction into the Doge relay contract, which actually just passes it on to the claim manager contract. So everything within this light green box over here is the Trubit protocol. So this calls a function called check script and really what it passes in at this point where we've abstracted away, we don't really care that this is a block header that we're talking about anymore. We just care that there's a plain text field. There's a hash and the Doge relay contract also passes a proposal ID, which we'll include in our callback to them. And this claim gets created here. So at this point, this claimant has staked their reputation and deposit and saying that this particular hash was correctly calculated from this plain text. Now, since you're within the Trubit protocol, these verifiers down here are, is anyone who's running a Trubit client on their computer? And these clients are configured to be listening for events inside the claim manager contract. And as a new claim gets created, what these guys do is basically take that plain text, locally run it through the script function, get the hash, compare it with the value in the claim. And if they agree, then there's no problem. They just kind of let the claim sit there and each claim kind of has this timer that's counting down. So if it goes for a certain number of blocks without getting challenged, it's deemed correct. And the claim manager contract at that point makes a script verified callback to the Doge relay saying that this proposal was deemed correct. But in the more interesting case, the verifier actually finds an issue with the hash and they find that they disagree. So at that point, they submit a challenge. They say challenge claim. And so the contract, the claim manager contract knows that there's a disagreement on what's happened here. So at this point, this kicks off to the script verifier contract saying using the function claim computation, passing in the input, output claimant, challenger, and the claim ID, which is kind of its unique ID. So this again is another layer of abstraction, which is the input is the plain text that was passed in. The output is the output of the program, which is the hash, the claimant and the challenger are the two addresses. And so if you think about, think back to the generic Troubled protocol as described in the white paper, I won't get into all those details, but that Troubled protocol allows you to include what the program is. So it's more generic. It's like, I claim that this output was generated from this input after being run through this particular program. But in this particular case, we know upfront that the program is Escript. So this is the Escript verifier contract instead of a generic Troubled contract, which is able to run any WebAssembly file. So at the point that this arrives, a verification game begins between the verifier and the claimant. And so I'll just give an overview of what happens here, which is one of the interesting parts of the Troubled protocol. It's an interactive game that allows most of the computation to be performed off-chain with one final step calculated on-chain. The insight here is that the verifiers and the claimant, or the particular verifier who's involved in this game, they actually agreed at time zero when they began running this program. So they had the same inputs and they had the same Escript function. So they agreed at time zero. And then after 2050 steps, they disagreed because they had different outputs. So the verifier sends a query in. The interactive game involves multiple rounds of query and response from the claimant. The verifier sends a query in saying, I know we agreed in the beginning. I know we disagreed at step 2050. What was your entire state at the halfway mark? So what was the merkle root of the state of your virtual machine at step 1024? And the claimant calculates that response with step and merkle root. Now this is sitting in here. The verifier again now compares their own state root at step 1024 with the one provided by the claimant. Now they can deduce, they can make the deduction here and that if their state roots agree, they know that the error occurred, that they basically agreed from step one to step 1024. So the error, the disagreements occurred in the second half of the computation. If their state roots disagree at this point already, they know that the disagreements occurred in the first half of the computation. So then the verifier with that knowledge either queries for step, for the midpoint of, you know, step 1024 and 2050, or the query for the midpoints of step zero and step 1025. So they basically break the computation into another half there. The claim does the calculation and responds. The verifier again does the same computation, queries another midpoint. So if you take this game to its conclusion, basically it's a binary search that's going from step zero to the final step, narrowing down the window of disagreement till it lands on the first step at which both of the verifier and claimant had the exact same state root. They ran one round of the SELSA 8 function and then they disagreed on the state after that. At that point, the computation is small enough that the script verifier actually runs it on chain. So you get the full security of the Ethereum network inside of here. All the miners execute the code. In this case, it would be on rink v. They get their state, calculate the root and compare it with what's the claimant had provided in this final step. If the root that the contract calculated agrees with the root that the claimant provided, then they know that the claimant was telling the truth. So this session decided callback goes back here saying that the claimant was the winner and the challenger was the loser. In the case where the roots disagreed, the script verifier sends the callback saying that the challenger was the winner and the claimant was the loser. So this protocol is crypto economic in the sense that both the verifier and the claimant had to have deposits inside the claim manager contract. So when the game resolves, one of them gets slashed. And that's basically it. And so if the claimant was proven correct, this claim is deemed incorrect and the doge relay never receives the callback. So this is where it ends up adding that block header back, block header to its list of doge headers. If the claim lives long enough and goes long enough without a challenge and wins against all challengers, then this callback is made saying that the script was verified. So effectively this protocol allows you to run the script function within Ethereum. And so I'll just go back here. So this is interesting to us for a number of reasons. First, it acts as a proof of concept for the generic trubit protocol, which would allow you to run anything on Ethereum. In this particular case, we've narrowed it to S scripts. Moreover, it's a cool demonstration of how this binary search would work and is just an interesting demo of the protocol. And lastly, it's helped us kind of... So we have, just to be clear, we have a security assumption in here that both... I guess I'll just go back here again. That both the claimant and the verifier are altruistic. So they're participating in this system without any expectation of profit. So in the generic trubit protocol, everyone is kind of brought into this economy with the expectation of gain. And the way that's achieved is there's rewards that are provided and there's this forced error mechanism that occasionally pays a jackpot out to the challenger. So that stuff is needed to build the generic trubit protocol, but it adds a number of more nuanced economic attack vectors that you need to protect against. And in this particular system, we're basically assuming that people are doing this altruistically. So with that, I'll open it up to questions and let me know. Okay. My first question. So what understanding you've built in Solidity or somehow in EVM, you've built the script computation in EVM or Solidity, right? So that's one of the assumptions. And it is a trubit. It can be a trubit, but it can be a script. It could be other things, right? Any other sort of other sort of computation, or like a single step on the EVM? Yeah. So the trubit protocol described in the white paper is able to run any WebAssembly module on chain, on Ethereum. And it does that by playing this binary search game in the instructions available and like the bytecode of that WebAssembly module. So, yeah, that's what the generic protocol allows you to do. In this particular case, we've taken the same idea, implemented scripts in the EVM. So there's, if you look inside of the GitHub repo, there are a number of the contracts that deal with computing a script. And Chris actually wrote the code for this originally. And basically you play the binary search game over each round of the Salsa 8 hash function. Okay, second question. So the risk we are facing here since, of course, all the members are altruistic is that there's always a chance that for some reason there are no verifiers of mine. Maybe for... And so a claim could be put there that isn't true. It's just nobody checked, nobody cared to check because nobody was mine, right? Yeah, so in the actual Trubit protocol, you as a verifier stand the chance of coming across a forced error and getting a large jackpot. And that's what incentivizes you to show up for every claim. In this current iteration of this project, we're making the assumption that the nodes are altruistic. And it kind of, this goes hand in hand with the design we use for the return peg. So from Ethereum to Doge, because there are different proposals there. The simplest one being a federated peg, which also relies on trust and altruism. So just as a short tangent, we're developing the Trubit incentive layer, which basically adds incentive to all of these network participants as a separate module that can overlay any verification game. So in parallel, as that gets developed, this escrow verification could use the same kind of security guarantees. And also Jason's over here so we can hear. Hi, I just wanted to elaborate a little bit on Stina's security assumptions and why they're realistic to have an altruistic model. First of all, anyone can jump in and challenge. So even if they're altruistic, any altruistic node can jump in and create a challenge. So that's open. The second thing is that unlike Trubit, which we imagine is like a scalable computer that can handle inferior, unbounded number of incoming tasks. We're only going to have the small number of tasks, which is like Calverman. Basically one task per block from Dogecoin. So that makes it a bound that can be handled on a single computer. And therefore if there's at least one honest person, we don't have to worry about it ever blowing up to something that they couldn't do on a laptop. Yeah, I was going to say it sounds like we could actually run this on existing Dogecoin infrastructure anyway, because we have various nodes just to make sure there's a backbone and doing a single script function per Dogecoin block is not an expensive operation. I mean, it sounds like this is going to run probably to be a lot of activity when we launch and then it will go quiet and it's going to have a background task. And obviously it sounds like we'll have people probably running Raspberry Pi's in their garage and eventually a couple of thousand dollars appears in their Raspberry Pi and they go, oh, we're going to do this sort of thing. Cool. And just to add to that. So one of the core properties of Trubit is you're kind of achieving consensus on the result of this computation, but Trubit really has what we call a unanimous consensus model. So as long as there's one honest verifier in the entire network, that will be enough to catch wrong claims. So like Jason said, because the scale of the program, because of the way it's structured, you just need a few honest nodes running on the network to get it working. You know, we'll leave this computer run. Everything is safe. Well, I would just add that if some sort of incentivization mechanism is actually needed or some sort of funding, we could also consider at the end of the whole process to leave, let's say, 10% of the bounties to be paid to those who are running and maintaining the system. I think that would be a fair use of the bounties, in my opinion. Of course, in other judgment way. No. Agreed. We still have the demo. Are there any other questions about this? In particular, we still have an open room for questions at the end. No questions so far. Okay. So let's go back to sharing my screen. Okay. Okay. So next thing to demonstrate the system working. Probably you remember a couple of minutes ago, I sent a drawing section on the Doshcom blockchain to this log address. And I sent 283 Dosh, sorry, Millie Dosh. There is one Dosh fee, but I actually just sent one, sorry, 0.283. Now, the thing that I'm going to demo is once you send the transaction, how you see that you get the tokens. So I'm going to open this transaction on a Doshcom blockchain explorer. So I consider inputs and outputs, the output of 0.283. Now the interesting thing that I need here is the input address. So I will copy the input address because this is the input, this is the address that is the one that matches the private key that sends the funds. And that private key should be the owner of the tokens on the Doshcom blockchain. So now I have this address, the next thing I have to do is to get my own private key, which you will be able to see, but don't steal my Doshcom please. So here I'm on the Doshcom client and I will ask it to print my private key and then I will use a tool to convert it to the Ethereum format. So this is the private key that sends the Doshcom transaction. I'm going to copy this and I'm going to use a utility created for our escape that is used to converting private keys and public keys. So using the private key, I just got, I get this private key which is an RSK address, but it uses the same format Ethereum use, so this is also Ethereum address. So now I am going to go to the Doshcom contract that you can see on Ethereum scan. I'm going to refresh my screen to get it updated. I'm crossing my fingers. Can you see my screen? Yeah, we can see. I hope that the private key there is something you just created for this presentation because otherwise we have to cut it out from the live publication on the internet. I'm open to lose for the Dosh. Okay. Thanks for the live presentation. Ethereum scan is done. Thank you. Thanks for the live presentation. Ethereum scan is taking its time. All right. So this is the token holder, so the people that already sent funds. So I'm going to search here for the address that I just got. So this is the address and this is 283 milli tokens. So here I can verify that I got the tokens of the Doshcom blockchain. Yay! Pablo, is the token transfer? Oh, yeah. Okay, so here are the token transfers. So this is just me trying this several times to make sure that it works. Another thing you can see is if you go, this is the Doshcom block explorer. I'm going to refresh in order to get the latest Doshcom block. So it's 2 million and then it's 393. And this is the Doshcom monitor scan. Refresh. I'm trying to check that the Doshcom blockchain on Doshrelay is also updated. The monitor scan not known. Any time there's a live demo, right? Yeah. Let's try this again. Wow. Working. Okay, yeah. So it's 393 and here, 393. Wow, good work. So this is Doshrelay and host token demo. Now I pass on to Sina to do a demo of the details of the script interactive protocol. Okay, quick question before. What are you constantly running you are running a relay that was getting the hash from the, getting the latest block from Dodge and putting it on the on the contract, right? Yes. Maybe I didn't hear the question properly. No. There is a nation running all the time. Yeah, yeah. Yeah. You didn't mention that. You didn't mention or show that you were running that process. So it's just, it's interesting. Nice. Yeah, this is the nation that Yeah. Yeah, this is the nation that the Doshrelay iteration is the one sending the information to Doshrelay. Questions or should I pass to Sina? All right. So let's get into the demo of interactive escrit verification. So I'm going to share my screen again. Can everyone see it? All right. So back to the GitHub repo. So this repo has all of the contracts and the client, which you run locally on your computer to participate in the network. So I set up the demo beforehand just so, you know, because this process takes a while and there's time amounts of blocks that need to pass. So I'm going to kind of show you what we did earlier this morning and we sent you a video of the recording of as it was happening, which is around 20 minutes long. So this first tab in my terminal to frame you is my local computer and basically I'm inside the escrit to interactive repo and the client, as the client I do, I get the status of the client. So this connects to the bridge says I have however much ether I have as much ether deposited into the client manager contract and this is my address and look this up on drinker B. So this is this particular address. And then the next thing that I do is the client can really do two things and back to the GitHub, we have this CLIJS which you can refer to to really see what's possible. There's the status, there's deposit with raw and one of the core functionalities is claim. So this is where you submit a claim. You pass in the block header, the hash and the proposal ID. So we basically created this simple mock for the doge relay contract that you're actually calling and then it sends it over to the client manager. So back to my terminal we see that we went npm start claim and this is a serialized doge block header in plain text and this is a wrong script hash. So we just made this up and this is the proposal ID that you're passing in. So this says as the claimant I've connected to the bridge I create a claim and then I'm waiting to defend the claim. So at this point this would just kind of wait here until the number of blocks is passing. So I'll take you over to my second tab this is a separate machine it's a digital ocean and if we scroll up basically I did npm start status different address, different deposits and I ran the client in monitoring mode with the auto challenge flag turned on. So this client is really the verifier in the system and it begins monitoring for claims it sees a claim get created and runs the script hash locally and sees that it's invalid. So at this point this challenger begins the process of enforcing the binary search and the first step that they query is the midpoint of the entire script process. So they query that and then we go back to this hash we see that the claimant defends step 1024 and back to the we see that the session steps it received the response for 1024 it compares it with its own state and in this particular case they agree so it queries for the midpoints of the second half so this number is the midpoint of these two steps. So the verification game proceeds with the challenger querying for finer and finer slices of the computation and back to the first tab the claimant is responding with their state roots and finally the verifier gets to queries for step 2048 which is because this is zero index this is actually the penultimate step and triggers this and which triggers the execution of the code on-chain and we see that the claimant loses the game so to kind of show you how this played out on ether scan we actually have a .en file that has the addresses of all the deployed contracts so the script verifier contract is back to the script verifier is this one where the verification game is happening so we take this address and I'll just open up a new tab so we see that there's a bunch of transactions from earlier today and if we the next thing we're going to do is go back to my terminal inside the window running as the claimant I'm going to take their address and you know just do a control find and we see that this is the game playing and you know there's sometimes scale transactions that we're going to try again so those types of things are accounted for so let's open up a few of these transactions so we see that we are calling the respond function so this tab was running the claimant I made a claim and basically after that I'm responding with the next tab you know another respond another respond so we are we were the claimant and we are responding at different steps and back to my second tab we go all the way up here and we see that the challenger's address is this one so a ring could be and we paste in or actually now I wanted to look at I'll do a control find inside the script verifier contract you know contract source the verifier so we see that these are transactions from the challenger so let's open up a few of these and we see that they're using their querying so they're querying for consecutive steps and eventually when you get to step 2048 which is the final there's a query and then this transaction is actually special so this is the one that looking at it you say it says perform step verification and it includes the pre-value, the post-value, the proofs and the address of the claim manager because it's needed for the callback so that's in the case of the challenge and then immediately after further down in these files so so here so that was we lost the game that was up here as the claimant then I submitted another claim the same serialized block header this time I passed in the correct script hash so it creates the claim it waits to defend the claim and no challenges come in so the claim is immediately successful so back to the challenger window we we see so here the the here the previous game ended you know ignore these these things will be washed over but so it's still monitoring the contract and it sees a new claim got created locally and sees that the script hash was valid so it actually like doesn't proceed with a challenge that's basically the system in effect and and the screen share so all the all the contracts are deployed to Wincabee and there's directions for installing the client it's a free entry system so you can just start running it like submitting script hashes with plain text and or verifying so we're looking forward to people starting to play around with this and an actual live demo was included in that video that I said so you can look at that lens okay so here's the question you don't need to keep the contract necessarily updated right you can so let's say that the bridge isn't being very used and then there's like only one or two persons in a single day that use the bridge you only need to start verifying and keep the dodge relay contract up to the latest blocks once you want to actually use it right so you can I can send the dodge and then start the whole process where I submit the block and then I submit the block to I submit and I submit the block to the verifier to make things and etc right I'm going to take that question the system that we require all dodge blocks to be relay to dodge relay it's not that you can stop relaying blocks and after three months you can start updating dodge relay with new blocks dodge relay is based on VPC relay for those of you that are familiar with it so it needs every block in order to check that the dodge block chain is complete and there are no yeah there are no fake blocks I don't know if that is the question so at least there's a planned extent at least I planned I would like to see that where you do not submit every single block you just submit the latest block or a block further ahead from the last known block and then you have a again an interactive game where you show that it's connected to the last known block right yes that's correct and actually that's one of the main reasons if it is like a beta and not the working system I'm going to share right away an issue that we have on our Github that that basically discusses that problem and proposes two different solutions let's say if I can pass it here so I copy to the chat so yeah basically this is kind of a solution to the problem that the system could even though we are using interactive skill verification still consumes a lot of gas per day so basically we have an idea how to solve that and it's written there we can discuss that during the question and answer section Cristian I don't know if I answer your question yeah answer mine I think shall we move to the summary and then to the questions or is there anything else well let's let's do summary and go to the questions so it's my screen share right yeah okay so to sum up you can go and test the system you can test the dodge relay on Robson and you can test the re-perification game in Brigaby I just sent a user manual before the presentation I hope you receive that that explain how to do the same thing that I shall steal so basically the system is composed of dodge relay, dodge token the Druvid script interactive verification and the related agent so the next steps of the project will be to finish the dodge to ethereum side and implement the ethereum to dodge side now there is room for all the you have already made a couple of questions but now it's a room to make the rest of the questions sorry I think we can cover this one earlier can you remind me what happens if there's a so a dodge coin block is orphaned after someone submits a transaction cleaning ethereum tokens am I correct in saying is there a window in which it's a verification window yeah so when you submit a dodge coin transaction one of the checks that is done is that the transaction is in a dodge coin block another check is to check that that block is part of the main chain and the third check is that the block where the transaction is included has at least n confirmations n could be 150 whatever number we finally decide but that's the security model for that attack I don't know if I answered the question or yeah that's good that's good I mean a lot of this I'm going to have to go over the code I think I understand all of it so far I mean how how are you feeling about the whole ethereum dodge side because we're obviously going to need to do some new op codes and how is that looking feeling comfortable about the whole thing I mean kind of in many ways do you need any help from us actually we will probably so far we I mean when we started the project we thought that we will be done by now but then we found out that yeah let's first concentrate on finishing the intro dodge coin side so I in the email I sent before I share a github repo a fork of dodge coin where we added a couple of new op codes this is not even an alpha but it's something that we were working on and we don't need any help from you so far as we make progress we will for sure contact you and show you what we are building I can also add to that so on the true bit side we've been we've been we've been actually thinking through various ways that you could build the reverse peg without a hard or a soft fork on the dodge coin side and we've come up with some crypto economics schemes you know leveraging Ethereum's ability to have smart contracts and now especially since we're available of the dodge coin blockchain inside of this dode relay so just to kind of share the very high level you know the one of the idea that we've already evolved past it would involve the operators of the bridge whoever whoever's address is dode is being sent to on the dode side actually depositing eith into the dode relay contract so having stake and then at that point they're responsible for relay transactions back and forth in a timely manner so if someone burns their eith dode tokens on the Ethereum side you know this other timer starts which says you have 20 doge blocks or 100 doge blocks to submit another doge miracle proof showing that money went from the bridge address to the person's address and that's and the idea has gone like a lot more interesting on that we're working on a paper with Jason and Christian so as another potential thing like we're going to collaborate with Oscar on this so we'll share that in the coming weeks as well well I don't have any questions I have a few comments I think I think it was a fantastic demo I'm very glad to see I had read about it but I think just seeing it in action is a whole other level and it's interesting to watch and I think it's clear to everyone that although it's a it started a funny project in a sense it is a project that is much bigger than just being a dodge coin Ethereum bridge right because you can see there there are a lot of applications outside of the streak dodge coin Ethereum community it's it helps a lot on Ethereum scalability it can be built as a bridge with other currencies which can help a lot I think the whole ecosystem making allowing smart contracts to be used in the ecosystem and allowing a lot more integration and I'm very happy that it has been so far I have a question for Christian Christian in fact I am under the impression that the dodge Ethereum project was a little bit precedes the Trubit protocol right and I if I'm not completely wrong I believe that I remember saying a few like that the Trubit was sort of inspired by a few early posts on Vitalik on how script verification could be done so there is a connection between like this whole process and Trubit isn't there or am I missing something? Yeah so the history was that yeah I think someone suggested the bridge I don't remember who that was and then I discussed with yeah I think Vitalik made a proof of concept to verify a script with basically repeated so just iteratively so splitting up a script across multiple blocks and then I discussed with them how that might be improved using binary search and in that discussion we came up with the general idea I think and then Vitalik met Jason at some conference and they talked about it and turned out that Jason and Vitalik had the same idea right? Yeah so in short Trubit is a solution to the dogetherian bridge that's why we did it I'm very happy to hear it We're very excited to build an implementation of Trubit for this bridge we've had versions of it on Testnet but last night Sammy who's also sitting here we're all living in this house in San Francisco and Sammy actually went home and we played a verification game around 7pm over the internet on Rinkbee which was really cool it was like a cool moment for the team awesome sharing this with you Are there more questions? Something I would like to comment on I hope that is still the case I have to admit that I wrote most of the internals of this script interactive verifier but I didn't have the time to participate in it for the development over the past weeks and months but it is written in a way such that so the on-chain part executes the final step to basically decide the game but during the game the off-chain components always have to submit their internal state at certain steps of the computation and it is written in a way such that the off-chain components use 99% of the on-chain code to actually compute this state that hopefully makes it quite resistant to yeah I mean it is the same implementation so they cannot be conflicting they cannot be kind of what you would call consensus bugs between the two implementations between the off and on-chain part To add to that it is actually super clever and blew us all away to see this original implementation yeah exaggerating script, runner, like the thing that people use off-chain to compute S script is the same code that the on-chain contract uses so inside of the client you are actually running an Ethereum client in dev mode that is executing stuff locally as a pure function so you are not writing anything to the blockchain just run that locally get the results back but eventually when you have narrowed it down to one step of the salsa 8 hashing function the same code is actually used by the on-chain contract so that is kind of to the internals of it you can abstract that away but it is kind of cool that ran that way I was wondering if you divide the whole process into like the 2050 iterations of salsa 8 how likely is it actually that the internal state diverts further out than the first few iterations like is it really needed to do this binary search because it would be more likely for the computation to diverge in the first iteration yeah so if someone is naively passing in a hash it is likely that it will diverge early on but if you are trying to build a protocol that is secure and can withstand any type of attack that you put towards it doing a binary search over the steps of the computation is the fastest way you can get to the solution so it is like login in the number of steps and which is 2050 in this case okay so this you know is that a sophisticated attacker crafted a solution that agreed and diverged 8 steps down the line okay that makes sense I got another question though Oscar you've shown how the private key is generated from the input address of the doge transaction what would happen for a transaction that has multiple inputs or like multiple dozen of inputs is it like just an index 0 yes the first input is the one the private key of the first input is the one that we get out of all the documents okay cool and maybe another one like how would a hard fork of the dogecoin blockchain play into this is this the same concept as a reorg or would there be some different factors to take into account here um the usually will follow the chain with the heaviest proof of work so in case of the hard fork um unless the hard fork is super hard fork meaning that it's incompatible with the previous chain which is probably very unlikely but if you are still compatible with the previous chain doge relay will just follow the chain with the heaviest proof of work what would happen if we switch the proof of work to SH8256 or to some other random algorithm I mean is there any ability to update doge relay later on and bug fix it or is it a far and forget and pray it was there was bug free launch I suppose we could hard fork the contract itself right we could always deploy a new contract and a set of tokens right I think that would break the verifier too yeah that's yeah that's correct what Alex was saying to answer the first question doge relay is not prepared to be updated as in this today if you plan to change the proof of work algorithm it will be a good idea to know about that soon but that's our state right now yeah no plans for that right now no worries no plans right now it may want to have some sort of complex you know six of nine signature the thing that we can get a federated update process if we absolutely have to get the doge coin and the Ethereum and devs from a number of other disparate organizations can get involved and apply bug fixes to the code we absolutely have to just so there is a backup in case of something I have to run but it has been great and have a great evening thank you thank you I will be disconnecting thank you for this demonstration before we disconnect maybe let's chat for just two minutes about next steps for the Grubby you want to yeah guys we just really I guess want to get this done as soon as possible and some guidance here would be helpful so would it be possible to kind of set a date for the next meeting or think through you know how did you guys see the next steps unfolding okay so here's how I see the next step unfolding I would first I would talk with the other judges to see if they first if they agree that this has been a good demonstration my opinion it's a resounding yes the second step would be does that merit 25% of the total boundary I think that's subjective but I don't I like the calculation of half half and half and I think that would be fair unless someone has another roadmap where there is something that we really really really need to make sure that okay so we really need let's say 10% to keep to keep the country running or something else but other if there's no if there's no nothing against that I would initiate a transaction to start to pay the first step of the boundary as soon as there is as soon as this video is published because I think it's nice to have the community know then the next step would be to you and then you would be the one discussing what do you believe is to like to be production ready and so we can work on the next boundary but I think that would be a whole new discussion my opinion okay so we'll wait on the response from the judges and then once that happens we'll come back to you with you know what we think the milestones are for each doge in production and a timeline that sounds perfect to me awesome thanks guys sweet thank you guys bye bye thank you bye bye