Ethereum Foundation Ethereum Berlin Meetup, 31 May 2018

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Berlin Ethereum Meetup 2018.05.31

A

Go faster, Rick, hi.

B

A

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.

A

B

A

That one horrific shooting laser beams at every one of the pointer or I hope this change. The slides.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

C

A

Some extra stuff that Jason would have been much better at explaining than me, but so that's it any questions. Oh.

A

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.

A

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,.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

It will also be trying to sort of on board these other teams to use our tools. I know.

A

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.

A

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.

A

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.

A

It's yeah yeah there.

A

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.

A

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.

A

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.

A

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.

A

Ready all great questions.

A

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.

A

All right, II think it's Christians hearing that please.

C

A

I feel here is that interference or I don't know.

C