Mining

Hash function

The 100-byte block header is hashed once by standard SHA-3. The mining algorithm is subject to change in Yesod. See our main post on Malkuth for the reasons why Zen Protocol initially uses a single hash function.

Difficulty adjustment

Difficulty targets are adjusted using an exponential moving average of solve-times. The smoothing factor is 1/28. The adjustment algorithm is one of the simplest in use, and is well-validated on several other blockchains.

Target block interval

The basic solve-time is about 237 seconds. This is adjusted by a factor of 0.982, to compensate for propagation and validation delays, giving a targeted solve-time of about 232 seconds.

A target block interval of about four minutes is comfortably long enough not to suffer from high orphan rates. Target solve-time is subject to change in Yesod. Issuance will not change — see the next section.

Thanks to zawy12 for his prior research in difficulty adjustment algorithms.

Issuance

Total supply of Zen Native Tokens

No more than 100 million Zen Native Tokens will ever be issued.

Initial supply

Twenty million tokens exist in the genesis block.

Issuance schedule

Zen Protocol uses Bitcoin-style halving periods, with issuance of 50 tokens per block in the first period, and periods of 800000 blocks, which is about 6 years.

The figure of about 50 tokens per block is subject to change in Yesod, if the block interval changes. The issuance schedule itself — how many tokens will be issued per hour on each date — is not.

Cryptography

Digests (Hashes)

Zen Protocol makes digests with a single application of SHA-3. For calculating merkle trees and other nested structures, tagged hashing is used, as described in our technical paper. This simply means tagging data with its type before hashing.

Public-key signature scheme

The same public key scheme as Bitcoin, ECDSA/secp256k1, is used. The implementation is by the standard libsecp256k1 library.

Conventions

Addresses

For the “old” address scheme, BIP32 derivation is supported: the registered BIP44 derivation path is 258.

For the new Bech32 address scheme, the registered BIP173 human-readable parts are zen for the mainnet, and tzn for the testnet.

Divisibility of tokens

One “Zen Native Token” is divisible into 10⁸ parts. This smallest unit of the native token is called a kalapa.

Capacity

Block weight limit

Zen Protocol has a single limit controlling the growth of the blockchain. All actions, such as contract execution, signature verification, or changes to a contracts data area, have some associated weight. The initial weight limit is two billion weight units (WUs) per block.

This is subject to change in Yesod and onwards. Decentralised control of the block weight limit is a primary objective of peer-to-peer governance.

Transaction weight

Each abstract computational cycle in a contract contributes 100 WU. Each public key witness validation contributes 100,000 WU, and each signed contract witness validation contributes 80,000 WU.

Activating a contract uses weight units equal to rlimit * queries / 100 , where rlimit and queries vary depending on the difficulty of proving the cost bounds on a contract.

These limits are subject to change in Yesod and beyond.

Transaction fees

There are no fixed transaction fees. The default client will add a fee for transactions which activate a contract, but not for other transactions. We don’t anticipate particularly high fees — Zen Protocol contracts are often even less expensive for nodes to verify than regular “send” transactions.

Activation sacrifice

Activating a contract currently requires a sacrifice of 1 Zen Native Token per kilobyte of contract code per 100,000 blocks.

Transaction throughput

Based on the above limits, Malkuth will be able to process about 60 transactions per second. This assumes an average of 1.5 pubkey-locked inputs per transaction, and negligible contract execution time.

This figure is reasonable for running a full node on consumer hardware, which is one of our aims for the Zen Protocol.