Truebit is a blockchain enhancement which enables smart contracts to securely perform complex computations in standard programming languages (e.g. C/C++/Rust). It can operate at a fraction of the cost of native gas. Any DApp can issue a computational task, and reputationless Miners receive token rewards for providing solutions.
Background
Truebit ranks among the earliest experiments in both cryptoeconomics and WebAssembly architecture (WASM). It currently exists as a fully-functional, high-performance, Soldity-compatible system. The platform enables DApps to leverage complex cryptographic primitives and other operations which exceed the gas limit. Truebit has led many popular community initiatives, including #ArtProject, ETH Prize, and Merry Merkle.
Implementation
We will adapt the Solidity-based version of Truebit for Nervos in order to enhance the functionality of CKB smart contracts. Truebit fits within Nervosâs design theme of conserving computational resources and is compatible with the platformâs Rust-based architecture. Along the way, the Truebit team may design and develop Solidity adaptation tools in conjunction with Nervosâs own Polyjuice initiative.
Technical specification
The components we propose to port onto Nervos are as follows.
On-chain stepper for simulating transitions between WASM snapshots and smart contract rules for âverification gamesâ
Truebitâs âincentive layerâ providing smart contract interface and cryptoeconomics for issuing and solving tasks
Truebit-OS command line client and filesystem
Token layer for pricing tasks
The whitepaper and token model provide more context for these technical contributions. Note that we can reuse some parts of Truebitâs existing off-chain interpreter and Toolchain for the CKB version. We will flesh out specs based on advice from Nervosâs core team and conclude integration with code testing and audits.
As far as I know, Truebit has been set to solve the gas limit problem on Ethereum. But on CKB, the layer1 is not used to do those calculations, verification on-chain and calcualtion off-chain. So what is meaning for CKB to use Truebit?
There is no doubt that Truebit maybe be useful on Nervosâs Layer2.
Truebit intersects multiple categories of the current call, including:
Smart contract language and tooling
Interoperability
Cryptographic primitives
We will develop new tools and techniques for generating Nervos smart contracts through the course of this ambitious, pioneering initiative. As indicated above, we foresee synergy with Polyjuice. Second, interoperability has been a primary application of Truebit since its inception. Truebit enables Ethereum smart contracts to check Dogecoinâs scrypt proof-of-work, a key ingredient in any two-way peg joining these two blockchains. Scrypt is one example of a cryptographic primitive which lies outside the reach of native smart contracts, however there are many others (for example, see âbilinear pairingsâ on Truebit-OS GitHub). Truebit allows smart contracts to conveniently integrate cryptographic primitives written in standard programming languages.
Could you be more specific on a technical level and what you will do?
How synergy with Ployjuice?
What you will do on interoperability? Like Bitcoin SPV enables CKB scripts to check Bitcoinâs proof -of-work. Would you enable CKB scripts to check Ethereumâs proof-of-work or even more?
Be more specific on how Truebit will allow smart contracts to conveniently integrate cryptographic primitives written in standard programming languages?
Given that Truebit is already implemented in Solidity, can you provide the thinking behind porting Truebit to Rust and re-working the architecture for the cell model versus directly building for Polyjuice?
Polyjuice is a tool for converting Solidity code into CKB.
@mathoticus It may be difficult to immediately convert Truebit smart contracts to Polyjuice given the preliminary state of that tool. While building Truebit directly to CKB architecture might prove a faster path to production, supporting the Polyjuice interface could benefit other existing Ethereum projects that wish to operate on Nervos. Truebitâs smart contracts may serve as an interesting pilot for Polyjuice as the interface develops.
@stwith One can use Truebit to check most proof-of-works, including Ethereumâs Ethash or Litecoinâs Scrypt. For proof-of-works whose verification involves lower computational complexity, such as Bitcoin, one could instead perform verification directly within the native smart contract. Even in this simpler case, however, one might still find it handy and perhaps more reliable to compile the original source code to a Truebit task rather than re-engineering it into a smart contract script. In order for a DAppâs smart contract to verify a proof-of-work hash using this method, the DApp would call to the Truebit smart contract, citing the appropriate task code and hash input, and then Truebit would reply back to the DApp with the hashed data.
Let us consider a second example for integrating a cryptographic primitive. Todayâs Nervos Talk post, zkp-toolkit-ckb, includes a proposal for developing a Rust-based version of a zero-knowledge protocol known as bulletproofs. Bulletproofs avoid the unfortunate trusted setup requirement common to most SNARKs but may require more compute resources for verification than native smart contracts can afford. By pairing Truebit with bulletproofs, one can obtain zero-knowledge proofs on-chain without trusted setup. Once one has compiled the code for bulletproof verification into a Truebit task, any DApp can cite that task together with an arithmetic commitment and a corresponding bulletproof and in return receive from Truebit confirmation that the bulletproof certificate is valid.
We have decided to integrate Truebit natively into Nervos and will decouple its development roadmap from Polyjuice.
Core tasks
Here are the development milestones.
Convert or design a Truebit task book and simple token contracts.
Convert existing Ethereum smart contracts to CKB, including the interpreter and interactive verification.
Convert the existing Truebit-OS client to Nervos.
Integrate and test the system.
Timeline
I estimate that the development process will take a total of 3 months. Each milestone above should take approximately 3 weeks.
Additional Polyjuice task
We shall determine scope of work, timeline, and feasibility for Polyjuice. We will investigate various methodologies and their respective performance and time-to-production tradeoffs.
Thanks! Several questions regarding the new roadmap:
The roadmap only mentions moving existing truebit interpreter to CKB, does that mean only the Truebit WASM interpreter will be included here? One thing I was wondering, is that if itâs possible to expand the truebit model to more interpreters. EVM, RISC-V can also be good candidates in addition to the WASM currently supported. In my opinion that will greatly expand the usability of truebit without affecting the core validation model.
While I do have great respect for truebit the product, personally Iâm more keen on enhancing on CKBâs infrastructure story right now. So another question here is: is it possible to split a core infrastructure part of the truebit validation model, and use it maybe elsewhere? For example, I see truebit-style validation a great fit for the dispute game in optimistic rollup design. I know this is slightly against your idea of launching truebit with its own economically well-designed tokens, but if the core infrastructure can be reused, I do see a greater usability of this proposal in the CKB ecosystem.
The roadmap indeed only includes porting the WASM interpreter, but we can certainly pursue other Truebit variants and enhancements that align with your mission (e.g. rollups). At this juncture, I recommend that we commence implementation with the generic construction I described above. Meanwhile we can continue to refine product specifications based on Nervos developer profile(s) and Dapp requirement(s).
Regarding underlying architecture, EVM is probably too complex for a verification game, but we could look more closely at RISC-V. What would you hope to gain by running Truebit via RISC-V instead of WASM?
Personally, I would be more interested in EVM, could you elaborate more on the complex part? Iâm not sure if I see the complication.
To me it actually is not about which VM we use to run Truebit, itâs more about designing Truebit as a flexible verification layer, that different developers can jump in and leverage truebit in their layer. And it really is up to the developers to say if they want WASM, RISC-V, EVM, or maybe even other VMs.
Does âEVMâ refer to the architecture for Truebitâs interpreter or the underlying blockchain? Can you unpack âleverage truebit in their layer?â
It refers to Truebitâs interpreter. The thing is: the most valuable part of Truebit to CKB, IMO, is the challenge and verification game involved. If we can model this part as an independent component, I personally feel it could be levaraged in other environments as well. Basically, anywhere a dispute game is involved, such as in optimistic rollup, Truebitâs verification game could be useful. And it doesnât really matter to me what interpreter is used in Truebit, as long as it is an deterministic one, we should be able to do bisect on them like Truebitâs verification game requires.