An overview of the Truebit architecture and incentive structure - Harley Swick

go faster Rick 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 it's been some changes so I am the one speaking I am a core developer for trivet I've been working on drew bit 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 oh that one horrific shooting laser beams at every one of the pointer or I hope this change the slides which one the lower one though that's the other one I didn't try it already go okay so let me start with what true bid is true bid is a platform for running decentralized computation that typically doesn't fit within the gas limit so that's a big limitation of computation with aetherium is that 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 true before is for checking for whether or not people are doing the correct computation which is typically why 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 what the theory might 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 tip simple tap user right here and they sort of have a contract that's running a computation so one example might be life here actually so they're our first milestone for an application so maybe it's the life here transcoders or other users and they're triggering something here and then it will go and call it true bit contract and have them sort of create a task and it's pretty pretty simple like API and what will happen is that there are these true bit miners who are running computation off chain and they will be executing this ask 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 live fear they have things like FF probe or ffmpeg and we can actually compile that down to what was them and I'll just share a little quick thing why we're targeting wasum the reason why we're targeting was them 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 wasum because it's sort of like a good base layer for computation and you know there's projects like 'i was them and stuff like that so the c or c++ code gets compiled into web assembly blossom whatever you want to call it via Emscripten and we have software related to that then race the task and the different troop of miners will run that web assembly code using our off chain interpreter which is written in oak camel 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 etc we also have this and we also have the wasum task so it doesn't just get solved but there's you know obviously it's the blockchain so there's like money related to this in 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 and our incentive layer the cool thing about true--but 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 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 Troup it 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 etherion 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 web assembly it's an issue because the web assembly 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 up front like how much to pay someone for these different things because we don't exactly have like you know a theorem 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 is gonna cost me sometimes you don't know how much gas is gonna 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 you 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 the 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 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 aetherium 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 uh 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 life here submits a task I'm going to challenge it and even though I'm gonna lose it's still gonna delay what you're doing and so it's kind of a problem and that will kind of disincentivize people from like submitting tasks if you know that some not nice person is gonna like challenge you just for no reason so so we if anyone's familiar with true--but we sort of colloquially refer our what the was written in the tribute white paper as tribute classics so that involves four stairs jackpot and the way that works is that whenever someone like in 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 or related to the force error but this is an interesting way and we've actually been discussing another model which we call true bit beta where tasks ever gives you a test so like I said earlier it's um it's solution that's fine yeah so this is pretty basic but the idea is that true beta doesn't give a force 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-air 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--but OS so I didn't yeah it's kind of a buzzword e calling stuff OS but the idea is that we have a so the trivet nodes will have you know clients that are running off chain but there's like different versions of true--but out there and there's all these different pieces and so the idea was we could build this system called Trueba to OS or you can actually compose different modules together to build a sort of true--but 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 that's actually yeah so the way that life here works is that someone will submit the the code that they were running and their will so with life here people will actually already have submitted their solutions and the idea is that true--but will then run 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 its life here is an interesting case because you can kind of think is that the original solver as the person checking the original live peer 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 live care contracts themselves can't check like these video transcoding because it doesn't fit within you know like solidity so they would use true--but to sort of offload that and then get the correct solution but then how do you know if true--but did the right thing so that's why true but it has sort of like the extra level of security hopefully that answers the question you in the back which one tell me we're going to start no that's a great question actually so you could use different languages like rusts 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 web assembly 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 language is to sort of like target would be C in 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 the rust compilation where you can compile a rust into web assembly but I'm scripting is sort of like the main tool for compiling different languages into web assembly 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 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 will also be trying to sort of on board these other teams to use our tools I know so it depends because with the M scripting module wrapper we are doing some extra stuff in there so we're an inscription we have our own wrapper around that so there's some extra stuff however you can do like fairly simple like blossom tasks and I think you yeah you can run like just pretty basic web assembly 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 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 tasks they're given a time frame to do it and they run the computation and they submit the solution and and in most normal cases of true--but 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 a 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 there you are right so there 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 used these terms to it would probably be in the same machine so you'll be running solvers and verifier to the same machine but we use the terminology solver verifier to more make the distinctions when we're developing the code and also in the white paper because the 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 four stairs and the jackpots is really meant for incentivizing verifiers because incentivizing solvers is pretty easy like I can just submit a task in your the solver and I pay you to solve the 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 ones catch you a single winner yeah so in tribute beta I think we were playing around with multiple solvers but in true--but classic the way it works is that the miners choose so it's really just whoever calls register for tasks or like first and whoever it gets through through the like aetherium and then anyone else who tried to call that method it 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 on languages work but I 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 we've been a little busy with other stuff but it'll happen there's some there's art project 2 related to it so that's been making a lot of progress all right II think it's Christians hearing that please [Applause] and I feel here is that interference or I don't know huh