6 posts tagged with "Blockchain"

A single month can tell us something useful about a validator's reward behaviour. It can also reflect an unusually large operating expense, a delayed transfer or a decision to add several months of rewards to self-stake at once.

In Introducing validator retainment and compound rates, I explained how monthly snapshots turn public balances, identity relationships and validator rewards into two measurements. Retainment measures reward retention within a publicly linked identity graph. Compounding measures rewards reflected in additional validator self-stake.

Polkadot should reduce the maximum number of validators a nominator can approve from sixteen to eight. Eight offers room for a resilient selection of active validators and additional choices, while narrowing the breadth of continuing support for accounts subject to that limit. The proposed transition would preserve existing longer lists, with their allowances decreasing as targets are removed. The objective is a more natural flow of support between validators, with informed nominator choices giving credible candidates a realistic route into the active set.

The case rests on two findings. Recently submitted full nomination lists overwhelmingly cover established winners, and the additional coverage available from very long lists has diminishing value in a mathematical continuity benchmark. Persistent nomination preferences also provide substantial backing to a subset of incumbents. Together, these findings justify reconsidering whether sixteen is an appropriate default allowance.

Measuring Polkadot at the operator level is harder than counting validators. One operator can run several validators, while a validator that appears independent may simply lack an explicit super-identity relationship connecting it to the rest of its operation.

Nominations provide another source of public evidence. When every account nominating an operator-unresolved validator belongs to the same registrar-attested identity graph, that convergence can be used to associate the validator with the operator behind the graph.

I call this method Nominator Identity Convergence. It is a deterministic, snapshot-based heuristic for finding probable operator associations that are not expressed directly by the validator account itself.

Polkadot lets a nominator approve as many as 16 validator candidates. In practice, that allowance is often treated as a 16-deep list of incumbent backups: choose as many validators from the current active set as possible so that at least one pays in the forthcoming era.

The election system does not require that strategy. Sixteen is a bound on the degree of the nomination graph, not a protocol estimate of how many active validators are needed for reward continuity. For an electing nominator, one nominated winner is sufficient for the election to assign the nominator's stake. The remaining approvals can therefore do useful work: help credible waiting validators enter the set and broaden the operator base that secures Polkadot.

Polkadot nominators tend to think in years. They bond DOT, select validators and accept the trade-offs of staking because they believe in the network over the long term.

Validators have a different set of day-to-day decisions. They earn DOT through staking and validator incentive programmes, then decide whether to compound it, hold it, move it elsewhere or sell it. Selling rewards can be entirely legitimate: operators have infrastructure, staff and tax costs. But when a validator consistently sells a large share of its rewards while its nominators continue to hold, the two groups may no longer have the same economic exposure.

Blockchains are often introduced as ledgers, but the more interesting engineering problem is state.

Modern chains maintain a large key-value database that changes every block: account balances, staking ledgers, governance tracks, scheduler queues, proxy definitions, identity records, parachain heads, smart contract storage, and anything else the runtime decides to persist.

That database needs a property that ordinary application databases do not usually need: anyone should be able to verify a small part of it without trusting the machine that served the data. This is where Merkle tries come in.

In this article I will walk through what Merkle tries are, how a typical database layout can support them, how querying works in a blockchain context, and how the Polkadot SDK implements the idea through its state trie stack.