Principle and design goals

Technology implementation

Consensus mechanism

Proof-of-stake mechanism 

Overview 

Our proof-of-stake mechanism is a mix of several ideas, including Slasher[1], chain-of-activity[2], and proof-of-burn. The following is a brief overview of the algorithm, the components of which are explained in more details below. 

Each block is mined by a random stakeholder (the miner) and includes multiple signatures of the previous block provided by random stakeholders (the signers). Mining and signing both offer a small reward but also require making a one year (unbonding will happen after one cycle, and not one year as initially suggested. Prolonging the period longer than a cycle did not really improve security at the cost of immobilizing a lot of capital) safety deposit to be forfeited in the event of a double mining or double signing.
The protocol unfolds in cycles of 2048 blocks. At the beginning of each cycle, a random seed is derived from numbers that block miners chose and committed to in the penultimate cycle, and revealed in the last. Using this random seed, a follow the coin strategy is used to allocate migning rights and signing rights to a specific addresses for the next cycle. See figure 1.

Accounts and transactions

Smart contract system

Contract type 

In lieu of unspent outputs, Tezos uses stateful accounts. When those accounts specify executable code, they are known more generally as contracts. Since an account is a type of contract (one with no executable code), we refer to both as ”contracts” in full generality. Each contract has a “manager”, which in the case of an account is simply the owner. If the contract is flagged as spendable, the manager may spend the funds associated with the contract. In addition, each contract may specify the hash of a public key used to sign or mine blocks in the proof-of-stake protocol. The private key may or may not be controlled by the manager.

Origination 

The origination operation may be used to create a new contract, it specifies the code of the contract and the initial content of the contract’s storage. If the handle is already the handle of an existing contract, the origination is rejected (there is no reason for this to ever happen, unless by mistake or malice). A contract needs a minimum balance of 1 to remain active. If the balance falls below this number, the contract is destroyed. 

Transactions 

Such a transaction can be sent from a contract if signed using the manager’s key or can be sent programmatically by code executing in the contract. When the transaction is received, the amount is added to the destination contract’s balance and the destination contract’s code is executed. This code can make use of the parameters passed to it, it can read and write the contract’s storage, change the signature key and post transactions to other contracts. The role of the counter is to prevent replay attacks. A transaction is only valid if the contract’s counter is equal to the transaction’s counter. Once a transaction is applied, the counter increases by one, preventing the transaction from being reused. Thetransactionalsoincludestheblockhashofarecentblockthattheclient considers valid. If an attacker ever succeeds in forcing a long reorganization with a fork, he will be unable to include such transactions, making the fork obviously fake. This is a last line of defense, TAPOS is a great system to prevent long reorganizations but not a very good system to prevent short term double spending. The pair (account_handle, counter) is roughly the equivalent of an unspent output in Bitcoin.

Storage fees 

Since storage imposes a cost on the network, a minimum fee of ꜩ 1 is assessed for each byte increase in the storage. For instance, if after the execution of a transaction, an integer has been added to the storage and ten characters have been appended to an existing string in the storage, then ꜩ 18 will be withdrawn from the contract’s balance and destroyed.

Code 

The language is stack based,with high level data types and primitives and strict static type checking. Its design is insipired by Forth, Scheme, ML and Cat. A full specification of the instruction set is available in[5]. This specification gives the complete instruction set, type system and semantics of the language. It is meant as a precise reference manual, not an easy introduction.
Fees 

So far,this system is similar to the way Ethereum handles transaction. However, we differ in the way we handle fees. Ethereum allows arbitrarily long programs to execute by requiring a fee that increases linearly with the program’s executing time. Unfortunately, while this does provide an incentive for one miner to verify the transaction, it does not provide such an incentive to other miners, who must also verify this transaction. In practice, most of the interesting programs that can be used for smart contracts are very short. Thus, we simplify the construction by imposing a hard cap on the number of steps we allow the programs to run for.

Cryptography

Distributed storage protocol

Cross-chain and exchange technology

Special technology

Economic model and incentive

Economy 

Coins 

There are initially 10000000000 (ten billion) coins (the initial extent of the token supply will be the number of tokens issued during the crowdsale and not specifically “10 billion”, which was merely a placeholder. This change in size has no effect on the principal at hand), divisible up to two decimal places (for thesakeofprecisionwemayinactualitybeusingeightdigitsafterthedecimal). We suggest that a single coin be referred to as a “tez” and that the smallest unit simply as a cent. We also suggest to use the symbol ꜩ (\ua729, “Latin small letter tz”) to represent a tez. Therefore 1 cent = ꜩ0.01 = one hundreth of a tez.

Mining and signing rewards 

We conjecture that the security of any decentralised currency requires to incentivize the participants with a pecuniary reward (we are in the process of finalizing the rewards schedule at the moment). As explained in the position paper, relying on transaction costs alone suffers from a tragedy of the commons. In Tezos, we rely on the combination of a bond and a reward. 

Lost coins 

In order to reduce uncertainty regarding the monetary mass, addresses showing no activity for over a year (as determined by timestamps) are destroyed along with the coins they contain (inactive addresses will no longer lose their funds after one year as initially proposed in the white paper, they will only lose their staking rights until they become active again. What it means is that if an address is inactive, it will not be selected to create blocks (which would slow down the consensus algorithm), and it will not be allowed to vote until it is reactivated (to avoid uncertainty about participation rate).

Amendment rules 

Amendments are adopted over election cycles lasting N=131072 blocks each. Given the a one minute  block interval,this is about three calendar months. The election cycle is itself divided in four quarters of  32768 blocks. This cycle is relatively short to encourage early improvements,but it is expected that further amendments will increase the length of the cycle(protocol upgrade votes will be much more frequent in the first year in order to allow for rapid iteration. As a security measure,the Tezos foundation will have a veto power expiring after twelve months, until we rule out any kinks in the voting procedure). Adoption requires a certain quorum to be met. 

Governance mechanism

Applications