 Thanks, everyone. So I'm Jason Toych, and we talk about Trubit. So in what sense am I introducing the Trubit virtual machine? Some of you remember last year, DevCon 2. Christian, right yesterday, also gave a talk on Trubit. So I'm pleased to announce here today that Trubit is up on the Covan test net. You can take a piece of C or C++ code and run a verification game up there. All the code is up on our GitHub. It's all open source, so dig right in. And I'd also like to thank all of our, in addition to our core team, all of our open source contributors who have been making that into a reality. We are especially senior at Vivian and Harley Swift. So some of you may be old enough to remember. Before Bitcoin, there was a thing called Big Data. And you could actually store stuff on your computer. You could use the computer to compute stuff. And there was even some privacy features. Well, Ethereum sacrificed all of these for a property we called immutability. And that's what makes blockchains amazing. They're immutable. They have some sort of democratic, equality properties to them. But we are, so it's time to bring the Big Data back onto the blockchain. So Trubit is taking this piece right here, computation. And that's what we're bringing onto the blockchain. So and there's also a communication component to it. Just like you have the internet for Big Data, where we're looking at something like Doge Ethereum Bridge, a way of bringing existing bridge. Take the tokens off Dogecoin and put them on Ethereum and back. So that's the functionality we're talking about here. So Trubit is a scalability solution. And in terms of the storage piece, I'm talking about Trubit as a scalability solution for computation. But if you look at the storage situation, there are a lot of projects already looking in that space already. Most of them are more focused on privacy than data availability. But there is interesting things going on in the storage department. In fact, there's interesting stuff going on everywhere. I guess that's why we're here. But what is it about Trubit? What are we here to talk about today is a process which we call interactive verification. And Trubit is focused on large transactions. So we've had a few talks just recently about sharding. So Trubit is not going to assume that you can take your transaction set and break it up into smaller pieces. You have a massive transaction that's coming in, and you have to process it. So that's what Trubit is all about. OK, so what's the problem? What are we trying to solve here? I guess I don't really have to tell this audience what a smart contract is. But I do want to point out a sort of critical property of the smart contract is that they only, this sign at the bottom which you can see now says small computations only. You're not running computations that run for hours or even minutes. I mean, they don't even run for a second. So that's what we mean by scalability. Computations actually run. So the length of the computation you can run is bounded by Ethereum's gas limit. So the obvious thing, let's get the elephant out of the room. Why don't we just dump the gas limit? So first, so what is the gas limit? Ethereum meters smart contract storage and compute resources with a measurement they call gas. And the gas limit is the maximum amount of gas that you can allow per block. It's not per stringent transaction, it's per block. And so why do we have the gas limit? That's a question. So reason A, is it because every miner has to replicate every Ethereum computation? It's because removing the gas limit would leave Ethereum vulnerable to denial of service attacks. Is it C because the gas limit helps incentivize verification? Or is it just that Vitality Transsegrity doesn't want Ethereum to scale? Well, I think we can quickly cross out D because it's not a secret anymore. I told this same joke a few weeks ago at CESC. So now what I do want to do is convince you that C is, well, I say all these answers are true, but C is more true than all the others. So this is what I want to convince you in the next three slides that C is actually the right answer to this question. So let's see what happens without the gas limit. OK, so no gas limit. You have a guy with two pointy horns comes in with a heavy transaction. He incentivizes it nicely. So someone is bound to pick it up. You put a nice, big transaction fee. So a miner comes in, mines the block. He says, sure, I'll include that because he's got an incentive for it. And what do the rest of the miners do? They just get completely confused, right? Because they will, why are they confused? So this is a let's look at a little bit into their confusion. So what are they confused about? So this is actually a principle which we call the verifier's dilemma. So in the case of a heavy transaction, what should a rational miner do? Rational miner being somebody who likes to earn more ether. So number one, skipping verification affords an advantage in the mining race. So therefore, he has a reason to skip the verification. Mining on the wrong chain, on the other hand, means that other miners will ignore the found blocks. So therefore, you should skip the verification. So it should be clear from looking at these two statements that rationality doesn't actually help you decide what to do. So the miners want to do whatever other miners are doing. So that's the verifier's dilemma. So what is Trubit? Trubit is a solution to this verifier's dilemma. It sort of makes it so we put everything off chain so you don't actually have to deal with heavy transactions on chain. What we've sort of observed in blockchains, and this is kind of the miracle of the whole thing, miners are willing to do a small amount of work for free. And then you don't have a verifier's dilemma. So here with Trubit, we are going to give Ethereum a computational boost by doing the heavy work off chain. So the goals of the protocol is that anyone can offer a reward for performing a computational task. Anyone can solve a task in exchange for a reward. The protocol most importantly guarantees correctness of solutions. And here by anyone, I mean anyone. That means a smart contract, pseudonymous identity, or the bots that came up in the earlier talk this afternoon. And so if you want to say formally, what is Trubit? It's an Ethereum smart contract. That's one part of it. But it's also a new off chain architecture. So I'm going to walk us through these two pieces in the remaining time. So let me try to explain how the let's look at the architecture piece first. Just as an overview. So Trubit is a unanimous consensus algorithm. Unlike Ethereum, which you sort of have majority vote on the miners, people say like this, anyone in Trubit can challenge a computation by taking it to court, so to speak. And who sits in the court? Well, it's your miners from the Ethereum network are sitting in this court. They're always right, but they have very limited computational bandwidth. As we just see, because of the gas limit, because of the verifier's dilemma, you're stuck with that. So what can we do? So you have a solver who comes in with a data computation, and then a challenger who comes in and says, well, you're wrong. And the solver doesn't actually say let's play a verification game. He gets forced to play a verification game. He gets taken to court. So what does the court do? It tries to pinpoint the place where they're disagreeing. So you have a solver and the challenger. They enumerate their computation states. They do all this off-chain. And then the judges are going to enforce the binary search to find the first step in the computation where they disagree. So solver says, here, he kicks out his. Obviously, they agreed on the green means they agreed. So they agreed on the first step, because that's the input it's just given. And they didn't agree on the end, or they wouldn't have been in the court in the first place. So he says, do you agree halfway through? Challenger says, no, I don't agree on that. So we mark that as red. Do you agree it's step n over 4? He says, yeah, OK, agree it's step n over 4. What about 3n over 8? So we're just getting the now we're there. These are close enough. You can actually run this one step of the computation. You can do it on chain, because it's small. And it's important to note here that the computational steps have to be absolutely identical across all the platforms in order to rule fairly on the final check. There's no notion of one step if everybody's running a different set of steps. So the judges have to make sure that that's the key property of our architecture is that all the steps are exactly the same. OK, so what happens here? So here was the last step where they agreed. And here's the step where they disagreed. This is what the this step was, of course, provided by the solver. So he's saying, so I'm talking about this. This is a picture of a Merkle tree, because you can optimize space on the blockchain. We represent these states and form a Merkle tree. But you can think of it as a Turing machine. So you said you have a machine. It's in state Q0. It sees a 1. So then the program, he's claiming that the program says, write a 0, change to state Q1, and move to the left. If you don't know what a Turing machine is, that's fine. Just note that whatever the judge said, he noticed that it did something different than what the solver claimed it would. So the solver is wrong, so the challenge is justified, and that forfeit is now deposited. Forfeit, the deposit is forfeited. So now let's look at the other piece, the smart contract piece, which is sort of the crypto economic innovation part of this project. So how do you actually ensure that this verification actually occurs, right? What if nobody shows up to take you to court, then there's no, it doesn't really work. So how do you make sure that people actually use the court the way it's supposed to be used? So the second idea, you offer awards for checking computations, just pay everybody who checks. So now how do you know that they checked? Well, you go back and run the computation yourself. I mean, you check that they checked? Well, you might as well have just done the thing yourself in the first place. So this incentivizes participation if you pay people, but it doesn't incentivize correctness. So idea three would be that you offer awards for finding bugs. So this gives you correctness, but it doesn't incentivize participation when there are no bugs. So it's the opposite problem. So essentially we have the problem that these verifiers stop paying attention if they don't expect to receive any rewards. Okay, this brings us to our final scalability idea for this talk, which we call forced errors. And that is that we're gonna offer a bug bounty and provide expectation that bugs will exist. And so this is actually what Trubit does. We are occasionally, the protocol pays solvers for submitting incorrect solutions. You have to get it wrong. So the dispute resolution ensures correctness whenever forced errors are not in effect. What do I mean by that? Since you're only having maybe one out of a thousand times you might have a forced error, but the idea is that every verifier doesn't know when the forced error is gonna come, so they're just gonna check everything. So most of the time the verifiers think they're getting paid and the solver thinks someone's going to watch, and therefore he gives the right answer. So, and ideally if we made our compiler exactly right on this architecture, no one's ever gonna go to court. This subroutine is never even gonna be executed. So that's a lot of work for code that you're never gonna run. Now, if you only remember one slide from my talk, please look at this one. This is a picture of an illustration of Ruvier's, Simon de Ruvier's, Panoptic computer, which is based on Bentham's Panopticon, and which has physical manifestations in the State Penitentiary in Joliet, Illinois, the Presidium Adele in Isla de Pinos in Cuba, and it's a prison, okay? So you have in the middle there's a watch tower, with someone who's looking around into all of these cells. There's a bright light, so they can't see what he's looking at. But out of fear that the guards in the watch tower is actually looking at them, they actually behave correctly. So that's the principle of the Panoptic computer. It's all about, you imagine that these people sitting up here are all performing the computations, and they do it correctly because they think they're being watched. So, and I just quote from Michael Foucault, who is also an important figure in the, he wrote a book in the 1970s about panopticism. We have seen that anyone may come and exercise in the central tower the functions of surveillance. So anybody can sit in there. Now there's no reputation, this is exactly an illustration of Trubit, because there's no reputation in Trubit. Anyone can come in and do that. So let me, in the last few minutes, talk about the developments that we're going on with, with Trubit right now. So the Trubit virtual machine, when I speak of the virtual machine, I mean specifically this new architecture that's offside, not the, which is part off-chain, but also your on-chain stepper, which allows judges to participate in this mechanism. So, as I mentioned before, the tasks have to compile and execute identically on all machines. Otherwise there's no notion of step, and the judges can't really participate. So they all have to be the same. The other thing is that your single computation step on the TVM has to be running within Ethereum's gas limit itself. So to this, and not only that, you also have to, the space required to describe a state change also has to fit inside Ethereum transaction. So we, ideally you'd use a Turing machine, as I said before, but there's no, at least I haven't found any code that takes a bit of C code and turns it into a Turing machine. So we had to do the next best thing, which is go to WebAssembly, and we even broke that down further. It's, we have, each WebAssembly step is broken down into basically 16 sub-steps, sort of. So this is, this was a, we have these properties of our architecture. So if you look at what does it look like overall, the picture of the TVM. So you have your C and C++ code that's coming in to, you wanna run this task. So your smart contract needs some computational boost. So you have a C or C++ code that says the task that it wants performed and it wants to ensure that it's done correctly. You can use this property called in, unscripten, which we use to transform the C++ code into the WebAssembly code. Now that WebAssembly code is used in two places. It's used both off-chain in this off, we use the OCaml reference interpreter to generate the states. The list of computation steps that are gonna go through on the computation. That's used by the solvers and the verifiers. Meanwhile, the task giver pitches this wasm task actually onto, he commits the task to the chain itself so that it's enforceable. So the judges can do it there. And then all of this stuff about the incentives that we discussed before in the forced errors are monitored there. And we have this, this is what holds the money that pays out some of the incentives. And here's where the judges live. This is where, that's on chain and it runs one step. Now I wanna point out that we do have a new file system for Trubit, which is basically has, well it currently has two flavors. One is, even if you store the date on the chain, you still need a file system to access it on the blockchain. So you can put your date on the chain and the advantage there is that it stays there. But this advantage is you can't put very much. IPFS on the other hand, you can store whatever you want, but data availability, well ideally we want a system that has both of these properties. The data is available and you can put stuff there. So to be continued. So let me just wrap things up. We're in the process of one of the first applications of Trubit is gonna be the Doge Ethereum bridge. And we've got the code ready on the Ethereum side, but we need to reach out to the Dogecoin community and get them to put in the new op code that we need, which is gonna be something that allows people to take Dogecoin off the Dogecoin network and put it on to like lock it on the Dogecoin side, unlock it on Ethereum, use it in a smart contract, whatever, and then lock and unlock, send it back, it's a Doge again. And in order to reach out to people, we are instituting a new public art project. So I'm calling everyone who's interested in being part of this amazing movement. This is a once in a lifetime opportunity. Come talk to me after this talk. As I mentioned earlier, we're live on Covontestnet and all of our code is up on GitHub. Check us out on Trubit, follow us on Reddit, Medium, GitHub, Twitter, and Facebook. And thanks everybody.