Truebit on Nervos

[truja]

Project

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.

[stwith]

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.

[JackXiao]

I think It is Layer2 protocol instead of Dev Infrastructure, what does it could bring to Nervos infrastructure development？

[truja]

Truebit intersects multiple categories of the current call, including:

1. Smart contract language and tooling
2. Interoperability
3. 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.

[stwith]

RFC: Nervos Ecosystem Grants Program

Round 2 RFC specification has been updated and now must include:

“additional information on how it’ll work specifically with CKB and its programming model”

This is to make sure all applicants have researched and considered CKB and the programming model for their proposed implementation.

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?

[mathoticus]

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?

[truja]

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.

[truja]

Update

We have decided to integrate Truebit natively into Nervos and will decouple its development roadmap from Polyjuice.

Core tasks

Here are the development milestones.

1. Convert or design a Truebit task book and simple token contracts.

2. Convert existing Ethereum smart contracts to CKB, including the interpreter and interactive verification.

3. Convert the existing Truebit-OS client to Nervos.

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

[xxuejie]

Thanks! Several questions regarding the new roadmap:

1. 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.
2. 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.

[truja]

Hi @xxuejie,

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?

[xxuejie]

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.

[truja]

Does “EVM” refer to the architecture for Truebit’s interpreter or the underlying blockchain? Can you unpack “leverage truebit in their layer?”

[xxuejie]

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.

[truja]

We can do that.