Skip to content

Latest commit

 

History

History
70 lines (39 loc) · 4.56 KB

wip-0003.md

File metadata and controls

70 lines (39 loc) · 4.56 KB
Raw
    WIP: WIP-0003
    Layer: Consensus (hard fork)
    Title: WIT issuance schedule
    Author: Daniele Levi 
    Discussions-To: `#dev-general` channel on Witnet Community's Discord server
    Status: Final
    Type: Standards Track
    Created: 2020-08-17
    License: BSD-2-Clause

Abstract

Different options for the WIT token issuance schedule have been discussed by the Witnet community. The purpose of this document is to summarize the current state of the discussion, and to kickstart a final debate and voting phase that will lead to a final community decision on the matter.

Motivation and rationale of the Wit token

The Witnet Protocol runs on its own blockchain with a native token called WIT. The token is earned by nodes on the Witnet network (from now on: witnesses) when resolving data requests and mining blocks. WIT have the fundamental role of rewarding the nodes that abide by the protocol, and desincentivize dishonest and untrustworthy node behaviour.*

The WIT token is fundamental for the correct functioning of the Witnet network:

  • it is an incentive for witnesses to abide by the protocol. Clients spend WIT tokens to get witnesses to retrieve, attest and deliver information from the broader internet. Witnesses only get a share of these WIT tokens if they are in consensus with the rest of the network. Furthermore, if the client attaches a WIT collateral requirement to the request, witnesses risk to lose this collateral if they tamper with the data. This aims to achieve strong guarantees on the integrity of the information retrieved, attested and delivered.
  • WIT are an incentive for Bridges to perform their task reliably. Bridges are a special set of nodes who specialize in delivering the information retrieved and attested by witnesses to blockchains other than Witnet (e.g. Ethereum)
  • WIT issuance helps to successfully bootstrap the Witnet Network and incentivize its early adoption by rewarding witnesses that mine a block - bundling transactions together and including them in a valid block that is accepted by the network.

A successful bootstrapping of the network, with tens of thousands of nodes run by thousands of unaffiliated parties, is especially important because the security assumptions of the Witnet Protocol will likely hold true only at scale. To achieve a successful bootstrapping, block miners are rewarded with a certain amount of new tokens that are freshly created in every block, plus transaction fees (together: block rewards). These freshly minted WITs are the only way in which WIT tokens are issued, and their amount will decay over time according to the decreasing-issuance algorithm until eventually the majority of the block reward will be composed by transaction fees. Apart from subsidizing block creation, the newly minted WITs included in the block rewards will also serve the important function of subsidizing data requests during the first years in the network existence.

The decreasing issuance algorithm that asymptotically approaches zero is similar to the one implemented in both Bitcoin and Ethereum. Such an approach has proved to contribute significantly to the strong security properties of both protocols.

*This document has been kept as simple as possible on purpose, to focus solely on the WIT supply schedule. For more information on the protocol and how it works, and on what defines "dishonesty" and "untrustworthiness" in the Witnet network, please refer to: https://witnet.io

Original proposal outlined in the Witnet whitepaper (November 2017)

Block time: 90 seconds

WIT per block: 500, with a 50% reduction every 1,750,000 blocks (approximately 5 years).

Updated proposal 1 (Current testnet issuance schedule)

Block time: 45 seconds

WIT per block: 250. with a 50% reduction every 3,500,000 blocks (approximately 5 years).

Rationale: after some testing it looks like the network can work well with shorter (45s) blocks. Shorter blocks are generally preferred in order to have data requests that resolve faster. Compared with the original proposal, this option will likely distribute rewards among a higher pool of nodes.

Updated proposal 2

Block time: 45 seconds

WIT per block: 500, with a 50% reduction every 1,750,000 blocks (approximately 2,5 years).

Rationale: some members of the community feel that 5 year per halvening is too long.

Updated proposal 3

Block time: 45 seconds

WIT per block: 375, with a 50% reduction every 2,625,000 blocks (approximately 3,75 years).

Rationale: a middle ground between the original proposal and proposal 2.