Genesis and network identity

Every Ting network starts from a genesis configuration: a short, fixed list of parameters that each node pins before it joins. Two nodes with different configurations are on different networks, even when they run the same software.

What genesis fixes#

Every other rule, from instructions and charges (the price list included) to module-shape bounds and voting thresholds, belongs to the protocol version rather than to genesis. Genesis chooses numbers; it cannot change behavior.

The configuration bytes#

The configuration is canonically encoded with its fields in this order, which always takes 150 bytes:

GenesisConfig {
    protocol_version:   u16 = 1
    genesis_timestamp:  u64              // seconds
    initial_target:     u256be
    pow_limit:          u256be
    target_interval:    u32              // seconds
    half_life:          u32              // seconds
    vote_epoch_length:  u32              // blocks
    initial_limits:     ResourceVector
    minimum_limits:     ResourceVector
}

A ResourceVector is four u64 values in the order C, S, D, G, one per resource counter. A configuration is valid only when:

• every capacity, initial and minimum, is positive, and each minimum is at most its initial value. There is no maximum: capacity voting can raise capacities without limit;
• the initial target lies between 1 and pow_limit, inclusive;
• the target interval, the half-life and the voting epoch length are positive;
• the minimum D capacity is at least 302, so that an empty block with empty producer data always fits its data allowance.

ChainId#

The canonical bytes of the configuration hash to the ChainId. It identifies the network everywhere: in every block header, inside every TransactionId and ContractId, and in the first message between two peers. A transaction prepared for one network has a different ID, and different effects, on another.

ChainId        = H("chain", encode(GenesisConfig))
GenesisBlockId = H("genesis", ChainId)

H is the domain-separated hash. A node pins the configuration, or its digest, before it joins a network. A peer can never choose a node's genesis for it.

The genesis anchor#

Genesis is not a mined block. It is a fixed anchor at height 0 whose identifier is the GenesisBlockId. Its timestamp is the genesis timestamp, its target is the initial target, its state is empty and its accumulated work is zero. It has no transactions, no receipts, no capacity votes and no reward. The first mined block has height 1 and names the GenesisBlockId as its parent.

Production and development#

ting init writes the production network's genesis, which is built into the node and uses the production profile below. ting init --dev writes the development genesis, for a chain to experiment on: the experimental profile below with a voting epoch of 20,160 blocks. ting init --genesis FILE imports any other configuration, which is how several nodes join the same network.

Production profile#

• Capacities were measured so that the worst possible block, full of the slowest compute per C and of state writes, takes about a second on a slow processor core with the reference node.
• Floors keep every reference program usable and deployable even when a majority votes capacity down: the largest reference transactions, such as a recovery and a savings cancel in one batch, or a sponsored cancel with P-256 keys, need up to about 36 million C and 44 S.
• Data and growth bound the chain to at most about 138 GB of blocks and 69 GB of new state a year at the initial capacities; votes move both.
• The half-life was chosen by simulating the loss and the arrival of hashpower: 12 hours keeps target noise near 3.5%, and after 90% of the hashpower leaves, block times are back under 90 seconds within about two days.
• The PoW limit lets one ordinary machine keep a nearly abandoned chain moving at about a block a minute.

Experimental profile#

The experimental profile is one reproducible configuration for prototypes and tests. Every field is fixed, the timestamp and the initial target included, so it always has the same ChainId; it is the genesis of the protocol vectors. Its values are not production capacities, and its targets are easy, so that any computer mines a block almost at once. The development genesis is this profile with a voting epoch of 20,160 blocks, about 14 days at the target rate, in place of 4. Values marked genesis are configuration fields. Values marked protocol are rules of the protocol version, listed here so that the whole profile is in one place.

The voting rows are explained in capacity voting, the prices on the price list and the module bounds in validation.

Initial and minimum capacities form a single explicit commitment in genesis, and so in the ChainId. Benchmarking chooses capacity numbers; it never redefines what a unit of C, S, D or G means. The real duration of an epoch varies with block arrival and with changes in hashpower.