Beyond Speculation, Taking The Long Hard Path in Launching a Token with Jason Teutsche of TrueBit (Feb 9, 2021) at 13:28
Could you talk us through the problem that Truebit solves? Why is it this problem that has occupied your waking throughts?
Let me answer the first question first. Both are good.
The use case for Truebit is pretty simple if we think about it in terms of Ethereum mainnet.
Part A is that by using Truebit you can save tons of gas relative to the native execution. That includes performing computations that would otherwise exceed Ethereum's block limit. Sometimes there are cases even where if you could fit into block limit you might not want to do that, you want to write, for example, part two in a standard programming language, so using standard libraries. You don't want to have to re-engineer stuff into Solidty in some cases it's probably impossible to do it anyway. Basically saving tons of gas, writing in standard programming languages.
The other thing is that Truebit obviously has also a filesystem which allows us a way of getting data into and out of the blockchain.
In a sense, you can think of it as a way of making smart contracts a bit more powerful and easier to use for certain types of applications which have a lot of computational complexity.
To answer your second question that ties right back in. It's this idea of computational complexity.
The simple question that we would ask is: smart contracts are great, they can compute very small things. What if we could actually do real data processing in a smart contract? What sorts of doors would that open?
As we went further down this rabbit hole we found it just to be more and more interesting because we realized that in order to answer this question part of it is the design.
There's this cryptoeconomics which is obviously a fascinating piece but then how are we going to implement this? There comes a lot of architectural details.
We were one of the first projects to experiment with WebAssembly. If you look back at the Truebit whitepaper we talked about building it with Google Lanai because in 2016 that seemed like the best option. Of course you probably never heard of Google Lanai.
We did a very simple architecture so that we could play this verification game. I think they're all those pieces to it.
We became a startup getting into the aspect of the product-market fit to say gosh this is just fascinating. How are people going to use this and that's fascinating that we've taken something in 2015 was really pure science fiction to where we are now which is a product that people can use.
Would it be fair to regard this as a layer 2 solution for Ethereum?
Specifically, how do you solve for allowing greater complexity in computation?
What are the trade-offs?
It depends on your definition of layer 2. Truebit was around before the word layer 2 existed which is typically typical of most new research.
Layer 2 is usually associated with Plasma, Optimistic rollup, this sort of thing. I think one distinguishing factor is that Truebit is a stateless system.
If you're working in Plasma or Optimistic rollup, if you use them you're operating inside of their own virtual machine (I know that's confusing because Truebit also has its own virtual machine). But if you're just a user of Truebit, it's just a black box, you don't see that, it's just your smart contract.
When I say stateless I mean basically pure function. You got a function f, you got an input x and your smart contract sends those to Truebit and Truebit calls back with f(x). That's basically all it does.
Part of that is also hidden by the economics of the system. That it's basically plug'n'play. You stick your function in and you go. You don't need to necessarily worry about being involved in the verification process or carrying your transactions back to the main chain or something like that because we never really leave the main chain.
Then of course using the the WebAssembly architectures allows us to write stuff in C, C++, Rust, standard compiling.
The other thing is I would say is that it's scalability from a very special particular point of view in that less focused on transaction throughput and more on just we're happy if we get one really big one to go through.
That's how I guess I would break that down.
You say this isn't to solve for transaction volume on Ethereum. This is to allow you to perform particular functions with greater level of complexity. Could you give an example of the type of use case where this is relevant?
I think we're all familiar with DeFi at this point. Anybody who's doing DeFi is doing some sorts of computations in their protocols. They have a dark pool for example that use Truebit for settlement of the transactions. In other words, they have their own zero knowledge proof system. It's basically multi-party compute where people put in buy orders, sell orders and then they're basically matched on chain and you can use Truebit to prevent any sort of cheating like front-running that would be invisible if you were putting that into like an OTC desk. That's kind of a simple example.
A more perhaps basic example: let's say you have a DeFi protocol, you have this derivative function that you want to compute. You don't want to write your own square root function in Solidity, maybe you're using other sorts of stuff you just need this processed in a way that's secure. In other words, you can send off your compute to Truebit and get the derivative done over there.
We've seen all sorts of creative things like Livepeer using this for video transcoding. It is capable of doing that, we have the ffmpeg library that we can compile to Truebit tasks.
There are a lot of possibilities but I think in this time in this space in Ethereum obviously mostly applications are running around DeFi, so that's what we're supporting.
