Home

Welcome to the polkadot-spec wiki!

Polkadot is primarily described by the Relay chain protocol; key logic between parachain protocols will likely be shared between parachain implementations but are not inherently a part of the Polkadot protocol.

Relay chain

The relay chain is a proof-of-stake blockchain in a similar balance/nonce mould to Ethereum, backed by a Web Assembly (Wasm) engine.

State & Transition Function

Its state is roughly similar to Ethereum: accounts are a mapping from a U64 account index to balance (U256) and either a nonce (U64) or code (H256, a SHA3 of Wasm code) and storage (H256, a Merkle-trie root for a set of H256 to U8[] mappings).

In reality almost all accounts would be basic and contain only two entries (balance and nonce). Code-bearing accounts ("high accounts") would fulfil specific functions (though over time these may expanded or contracted as changes in the protocol determine). The accounts can be listed:

• Account 0: Unauthenticated sender. Doesn't actually do anything but represents the unauthenticated (external transaction) origin.
• Accounts 1...: The basic accounts.
• Account ~6: Balances contract. Stores a mapping from U64 -> [U256 (balance), U64 (nonce)].
• Account ~5: Authentication account. Basic account lookup account. Stores a mapping U64 -> H160 providing a partial public-key derivative ("address", similar to an Ethereum address) for each account index. Can be used to register new accounts (in return for some price). All U64s begin at 0x1.
• Account ~4: Para-chain management account. Stores all things to do with para-chains including para-chain balances and current state.
• Account ~3: Consensus account. Stores all things consensus (including the proof-of-stake algorithm) and code is the relay-chain consensus logic.
• Account ~2: Administration account. Stores and administers low-level chain parameters. Can unilaterally read and replace code/storage in all accounts, create DOTs, &c. Hosts and acts on stake-voting activities.
• Account ~1: System origin. Doesn't actually do anything but represents the system origin.

For PoC-1, high accounts are likely to be built-in, though eventually they should be implemented as Wasm contracts.

The transition function may be compared to Ethereum, where:

is mostly similar to an unmetered variant of Ethereum runnong that all but removes smart contracts. Exceptions:

• Utilisation of Wasm engine for code execution rather than EVM.
• High accounts do not harbour or increment a nonce when deploying.
• Wasm intrinsics replace each of the EVM externality functions/opcodes:
  • CALLDATA* -> n/a (if coming straight from a transaction message data will be passed as bytes into the function)
  • BLOCKHASH -> blocks[]
  • TIMESTAMP -> current_time
  • NUMBER -> current_number
  • BALANCE -> n/a
  • ORIGIN -> n/a
  • GASPRICE -> n/a
  • EXTCODE -> n/a
  • COINBASE -> n/a
  • DIFFICULTY -> n/a
  • GASLIMIT -> n/a
  • GAS -> n/a
  • LOG* -> n/a
  • CREATE -> deploy (which takes a new account index and clobbers any existing code there; no init function is run).
  • CALL -> call
  • RETURN -> (return in Wasm)
  • CALLCODE/DELEGATECALL/SUICIDE -> n/a

Data structures are RLP-encoded using normative Ethereum RLP.

Transaction: [ destination: u64, function_name: string, message_data: [...] ]

• destination is the contract on which the function will be called.
• function_name is the name of the function of the contract that will be called.
• message_data are the parameters to be passed into the function; this is a rich data segment and will be interpreted according to the function's prototype. It should contain exactly the number of the elements as the function's prototype; if any of the function's prototype elements are structured in nature, then the structure of this parameters should reflect that. A more specific mapping between RLP and Wasm ABI will be provided in due course.