A token-based roadmap to trustless computation

Over the past three years, the TrueBit protocol has bootstrapped from a consensus computer to a verification game to a full-fledged computation oracle. A couple weeks ago, Sina Habibian gave a live demo of “TrueBit Lite” over Ethereum’s Rinkeby testnet. With deployable technology now in hand, we approach a long-awaited moment of truth. Will rationality, as posited in the TrueBit whitepaper, suffice to secure a real network?

Miners, also known as “Solvers” and “Verifiers,” will soon not only play a critical role in maintaining TrueBit’s integrity but also permit TrueBit to scale its computational bandwidth. In exchange for dedicating valuable, computational resources, miners receive rewards. In contrast to Bitcoin mining, TrueBit mining requires no specialized hardware to participate, however, also unlike Bitcoin, miners in TrueBit cannot simply switch on their computers and immediately support the network. For security reasons, each TrueBit miner must deposit tokens into a smart contract before earning rewards. From whence would the first miners obtain such deposits? One option would be to use existing token distribution(s); another would be to create an entirely new distribution.

TRU token mechanics

Like the TrueBit protocol, the TRU token will itself be a scalability solution. The primary function of TRU is to reward Verifiers for correctly performing computational tasks.

TrueBit, as described in the whitepaper, begins with a philanthropic donation to a “jackpot repository” from which the protocol distributes rewards to Verifiers. The jackpot repository’s value bounds the system’s computational power, as finite capital can only incentivize Verifiers to perform finitely many computation steps. One can circumvent this finite bound by minting new tokens on the fly. In this protocol variant, TrueBit would burn the non-remunerated portion of each Task Giver’s payment and mint a jackpot for Verifiers on the occasion of a “forced error.” While computation power still remains bounded by the total number of tokens in circulation, in practice no real constraint exists so long as the computation potential in this set of tokens represents more entropy than exists in our physical universe. Thanks to Zack Lawrence for suggesting this technique.

While the preliminary incarnation of TrueBit will inhabit Ethereum’s blockchain, one may adapt it for other ecosystems as well. The option to mint TRU on multiple blockchains not only enables universal scalability but also offers local autonomy benefits and cross-chain symmetry. One may transfer TRU tokens across blockchains by burning them on one blockchain while minting them on another. Such transfers would be impossible in a TrueBit system using ETH alone because ETH only mints through block rewards; indeed ETH cannot be born elsewhere than Ethereum. Finally, burning in token transfers may offer greater security than traditional 2-way peg locking mechanisms since burned tokens have no chance of unexpectedly walking off. This burning feature becomes particularly useful when a token traverses more than a single pair of blockchains.

TrueBit’s network has substantial upfront token costs. Not only does the initial jackpot repository require a large deposit to kickstart the system, but so may each successive upgrade. Experimental protocol cryptoeconomics and smart contract codes require calibration and maintenance. In particular, token reserves will test the protocol’s empirical parameters and security features. The TrueBit protocol must run with “real” money, through a stream of tasks, in order to “prove” its security guarantees. An infusion of new tokens not only ensures sufficient supply for these purposes but generates necessary value for the network.

Ideally, TrueBit’s core team should vanish after a flawless protocol launch, leaving behind an eternally self-sustaining, self-governing, trustless system. That’s the dream of decentralization, but we’re still far from achieving it. Section 5.5 of the TrueBit whitepaper, for example, describes a vulnerability resulting from the current lack of an exchange rate oracle. Regardless of whether TrueBit uses a jackpot repository or a burn-and-mint system, the protocol still lacks a secure and sustainable way of trustlessly maintaining a stable token supply.

1. An inflationary system may invite denial-of-service as Task Givers solve their own tasks.
2. Deflation through burning causes token shortage and hence raises the problem of redistribution.
3. Refunding or redistributing Task Giver payments which do not pay out as rewards may incentivize Sybil attacks due to “exponential dropoff” (Section 5.3 of the whitepaper).

An on-chain system for managing TRU supply might well demand computation power from TrueBit itself :) While TrueBit may relieve some immediate gas demands in Ethereum, eventually the system will require a more substantive storage features and hence may appeal to tools such as nondeterminism (Section 7.4 of the whitepaper) or data oracles. In summary, TRU tokens can manually incentivize TrueBit’s research and engineering to disappear itself and minimize future interventions, thereby increasing the network’s decentralized utility.

The road ahead

I’d like to pause and make a prediction: 2018 will be the year of two-token models. To date, we’ve even seen some cryptocurrency stablecoins with three-token models like Basecoin and Maker. With the exception of Bitcoin’s clientele, who primarily use their tokens for hodling, utility consumers generally favor spending stable-value coins in exchange for services. Cryptocurrency investors, on the other hand, traditionally have held the same coins as consumers hoping that their value increases. At least one of these two groups will eventually become disappointed with any single-token model. We witness this phenomenon in Ethereum. As the price of ETH rises, the cost of using Ethereum smart contracts becomes prohibitively expensive, and fewer users can afford to use the system.

In order to decouple utility from rewards, the protocol must assign TRU tokens to a unique role among these two functions. Applying TRU to network rewards incentivizes token holders to maintain their support of the network community even after obtaining tokens. Task Givers, on the other hand, may wish to pay for network services in a variety of different coins. Decentralized exchange platforms, such as 0x or Kyber, offer potential benefits for TrueBit applications.

The TrueBit protocol leaves room for enhancements in communication efficiency, speed, versatility, and security. Zack Lawrence recently introduced TrueBit Beta, a protocol proposal which eliminates TrueBit’s forced error mechanism. We continue to investigate means of improving cryptoeconomic security and developing macroeconomic solutions for stabilizing token supply.

Individuals and organizations who have an interest in participating in the TrueBit network may eventually obtain tokens to distribute in the form of computational tasks. While the precise distribution method(s) have yet to be determined, the basic criteria for participation would include:

1. having a functional system,
2. demonstrating a technical need for TrueBit, and
3. committing to issue some volume of tasks to the network.

Submitting tasks for which one already knows the solution would categorically not merit a discounted token distribution.

Token incentives have become unexpectedly powerful tools. As with any decentralized game, however, each individual can choose to contribute to either a shared vision or to a tragedy of the commons. By patiently growing network effects, we can together build a treasure of truly trustless systems.