 Hi, everyone. I'm Harley. I came all the way here from Dallas, Texas, actually, so pretty far. Jason, the original speaker. Also, our other original speaker was not here as well, so there's been some changes. So I am the one speaking. I am a core developer for Trubit. I've been working on Trubit for about six months now, so it's been a while. We have a lot of pretty exciting things. Oh, how do I change the slides? Up here? Okay. Perfect. I can do that. So, clicker. Yeah. Is it working? Oh, that one. Perfect. I was just shooting laser beams at everyone. Oh, the pointer, or I thought this changed the slides. Yeah. Oh, which one? The lower one. That's the other one I didn't try. Alrighty. Okay, so let me start with what Trubit is. Trubit is a platform for running decentralized computation that typically doesn't fit within the gas limit, so that is a big limitation of computation with Ethereum. It's at this gas limit, which is there for a very good reason, but not all applications, you know, can really fit in that, and you still want to be able to mostly what you use Trubit for is for checking for whether or not people are doing the correct computation, which is typically what you use a blockchain for. So, yeah, the problem is that decentralized computation is expensive, like we talked about, or I mentioned earlier, you have the gas limit, you also just, you know, have to run stuff with Ethereum and pay for gas. The other thing is that, yeah, and decentralized computation is bounded by the gas limit. So, like I said, Web 3.0, it can't quite happen because we need to really scale up the level of computation that we can do. So, this is a pretty simple diagram for how it works. So, we have a simple DAP user right here, and they sort of have a contract that's running a computation. So, one example might be LiveFair, actually. So, they're our first milestone for application. So, maybe it's the LiveFair transcodeers or other users, and they're triggering something here, and then it will go and call Trubit contract and have them sort of create a task. And it's pretty simple, like API. And what will happen is that there are all these Trubit miners who are running computation off-chain, and they will be executing this task. So, and here is where it gets a little bit more complicated. So, we have, here is our C++ code. So, in the case of LiveFair, they have things like FFprobe or FFmpeg, and we can actually compile that down to Wasm. And I'll just share a little quick thing why we're targeting Wasm. The reason why we're targeting Wasm is that it's supported by all browsers, and it's a computation platform that a lot of different languages can target and use. So, we want to target Wasm because it's sort of like a good base layer for computation, and, you know, there's projects like eWasm and stuff like that. So, the C or C++ code gets compiled into WebAssembly, Wasm, whatever you want to call it, via M-scripten, and we have software related to that. Then we'll trace the task, and the different trubit miners will run that WebAssembly code using our off-chain interpreter, which is written in OCaml. And there's a bunch of different steps that go on with that, but eventually the, you know, different data or whatever can get uploaded to the blockchain, or it could be IPFS, et cetera. We also have this, we also have the Wasm task, so it doesn't just get solved, but there's, you know, obviously it's a blockchain, so there's like money related to this. And the way it works is that the task giver will give a reward and a minimum deposit, and so there's different staking. So, if at any point someone doesn't follow our protocol and it can be proven, then those people will be slashed. And that is all handled in our incentive layer. The cool thing about trubit is that, you know, if someone does the computation, and what if they don't do it right? Well, the way it works is that you can run pretty much 99% of the code off-chain, and then you can use a sort of our on-chain stepper, what we also call dispute resolution layer, to actually prove fraud. And then those people will get slashed. And so those are some of the related inputs and outputs. So, I already discussed about WebAssembly, so I won't go into that too much. So trubit is, I like to think of it as a very elegantly simple system. The verification game is pretty simple. It was actually created by Christian over here, related to solving the Doge Ethereum bridge. But there are obviously, with any, you know, programming or software, there are like interesting design challenges, and this is a very new space. So, one issue is floating point. And the reason why floating point is an issue is because it's, for WebAssembly, it's an issue because the WebAssembly spec doesn't specify how it's supposed to happen because they want it to be optimized by certain hardware. Well, obviously, if you're hashing different floating point numbers, no matter even if they're, you know, very, very similar, they're going to give different hashes, so you don't have determined a computation. And Sammy, actually, our other developer has developed some interesting floating point emulation, and there's different ways to sort of solve this problem. The other thing is determining the task reward. So this is kind of related to, like, how much do you know, how do you know upfront, like, how much to pay someone for these different things? Because we don't exactly have, like, you know, Ethereum, you can kind of get estimates for gas, so it's a similar issue. Like, you know how much, you don't really, you know how many, like, steps it's going to cost, but sometimes you don't know how much gas is going to cost and things like that. So that's an interesting problem that we've been working on. Another, probably the biggest limitation for us is because, you know, obviously we want to do big computations, which usually requires big data. The biggest issue is, you know, having this data availability problem. And this is a really tough problem that, you know, that everyone, I think, in this space is sort of facing. And so we're definitely looking into different ways to solve that and other people, how they're solving it. So other issues are around token mechanics, you know, how do you relate token mechanics to all these different, you know, computations. So, like, you're pricing the computation, but if your token is, like, deflating and things like that, so there's, like, all these crazy variables that go into this. Exchange rates, like, you know, how much, if you're exchanging Ethereum into a true-bit token or whatever, like, how do you know how that's related to the computation? So these are interesting problems. The other thing is what's called a dandelion attack, and it's a pretty interesting one. So let's say you're a live-fear task giver, and then some malicious person like Sammy over here says that every time that live-fear submits a task, I'm going to challenge it. And even though I'm going to lose, it's still going to delay what you're doing. And so that's kind of a problem. And that will kind of dissentivize people from, like, submitting tasks if you know that some not-nice person is going to, like, challenge you just for no reason. So we, if anyone's familiar with true-bit, we have sort of colloquially refer what was written in the true-bit white paper as true-bit classics. So that involves forced errors and a jackpot. And the way that works is that whenever someone, like, at a probabilistic rate, when someone submits a solution, they also submit a fake solution. And this is to check if verifiers are actually checking or not. And so if verifiers are incentivized to challenge because, or to least check, because they want to get this jackpot related to the forced error. But this is an interesting way. And we've actually been discussing another model, which we call true-bit beta, where task ever gives you a test. So, like I said earlier, submit solution, that's fine. Yeah, so this is pretty basic. But the idea is that true-bit beta doesn't give a forced error. And the reason why that's difficult and not yet implemented is because the forced error is really key for incentivizing verifiers. And we really want verifiers to, you know, check stuff, because that's how you get security. So how do you, you know, incentivize verifiers without sort of this interesting forced error jackpot mechanism that has its own sort of related problems? And there's some extra stuff that Jason would have been much better at explaining than me. But so that's it. Any questions? Oh, I can talk about it if you want, but do I have to? Oh, I guess I could talk about something else. So the thing I've been working on is true-bit OS. So I didn't, yeah, it's kind of a buzzwordy calling stuff OS. But the idea is that we have a, so the true-bit nodes will have, you know, clients that are running off-chain. But there's, like, different versions of true-bit out there, and there's all these different pieces. And so the idea was we could build this system called true-bit OS where you can actually compose different modules together to build the sort of true-bit client that you want for your specific problem. And we're actually, it's pretty close to being done, and we'll be using it for the life here integration. So anyone wants to check that out on our github? Yeah, so that's actually it. Yeah, so the way that life here works is that someone will submit the code that they were running, and there will, so with life here, people will actually already have submitted their solutions. And the idea is that true-bit will then rerun that computation, and then a solver will run that and run it again. And then a verifier will check that solver. But you can kind of, it's, life here is an interesting case because you can kind of think as that the original solver as the person checking the original life here people as well. So that's kind of how that example works. What they would be doing is they would simply just be checking that the solution that the original that came from life here was actually correct. And so that way, because the life here contracts themselves can't check, like, these video transcodings because it doesn't fit within, you know, like, solidity. So they would use true-bit to sort of offload that and then get the correct solution. But then how do you know if true-bit did the right thing? So that's why true-bit has sort of, like, the extra level of security. Hopefully that answers the question in the back. Which one? Tell me when to stop. No, that's a great question, actually. So you could use different languages like Rust. So one thing is that WebAssembly doesn't support garbage collection. So that is an interesting detail. So that's why other languages may not exactly be supported. However, it is certainly possible and people have compiled, like, different languages like Python or like C-sharp to WebAssembly. So that could be possible. There's definitely, I don't see any reason why we can't support those languages. But at the moment, the best languages to sort of, like, target would be C and C++ or Rust or any sort of non-garbage collected language. So Rust is an interesting case because they're trying to be sort of, like, the language for WebAssembly. So there's, like, some sort of, like, native Rust compilation where you can compile Rust into WebAssembly. But M-script is sort of, like, the main tool for compiling different languages into WebAssembly. I would say development is going pretty well. I guess it depends on who you ask. But, yeah, we don't have, like, a really specific roadmap. But the biggest milestone that we're sort of targeting right now is the live peer integration. And so once we kind of have that, then we'll be ready to sort of support other teams. And we've had a bunch of other projects like Ocean Protocol and Aragon who've also wanted to build on it. So we'll pretty much just be, as we're developing it, we'll also be trying to sort of onboard these other teams to use our tools. I know. So it depends because with the M-script and module wrapper, we are doing some extra stuff in there. So we're an M-script and we have our own wrapper around that. So there's some extra stuff. However, you can do, like, really simple, like WASM tasks. And I think you, yeah, you can run, like, just pretty basic WebAssembly stuff that you haven't sort of, like, pre-processed. But anything sort of more complex, you sort of need to do this pre-processing stuff. Yeah. So in the white paper, it hasn't changed too much. But, yeah, so a solver is just someone who is waiting for a task to be created. They commit to solving that task. They're given a time frame to do it. And they run the computation and they submit the solution. And in most normal cases of Trubit, no one will challenge. And then they get their money and they go on their way. Now in the case where a verifier, so what they'll be doing is they'll be watching for solutions to be submitted. So there's some event, right? And so they will then go and get the code, they'll download it, they'll check it themselves. And if they're like, Hey, you didn't do this, isn't correct. And then they'll go and challenge it. And then they, so the verifier is sort of the other party in the verification game, as opposed to the solver. It's, yeah, yeah, they're, you are right. So they are, it's pretty much the same code. But in terms of like, just who is like sort of playing the game, we sort of use these terms to, it would probably be in the same machine. So you'd be running solvers and verifiers in the same machine. But we use the terminology solver and verifier to more make the distinctions when we're developing the code. And also in the white paper, because they, the code is very similar, but slightly different in terms of what methods they call. Yeah, so that's what the white paper goes in. So the white paper, the forced errors in the jackpots is really meant for incentivizing verifiers. Because incentivizing solvers is pretty easy. Like I can just submit a task and you're the solver and I pay you to solve a task, right? But you're sort of not incentivized to really give me the right answer. You're kind of incentivized to give me 42 every single time, unless someone's like actually checking you, right? Because you don't want to waste your computational resources if no one's gonna catch you a single winner. Yeah. So in tribute beta, I think we're playing around with multiple solvers. But in tribute classic, the way it works is that the miners choose. So it's really just whoever calls register for task, or like, first, and whoever gets through to the like, Ethereum, and then anyone else who tried to call that method will just revert on them. So and they could become verifiers if they wanted to. Yeah, I don't see why not. I guess you would guess it depends on how the smart contracts work. I haven't really looked into like how other EVM based languages work. But I don't see any reason why not. Yeah, ready all great questions. The what? Oh, the Doge bridge? Yeah, yeah, it's coming along. We've been a little busy with other stuff. But it'll happen. There's some there's an art project to related to it. So that's been making a lot of progress. Alrighty. Christian sir, please. Security scan. I have a film here. Is it interference or I don't know?