Native interoperability begins: the genesis block of Polkadot

6 min readFeb 22, 2024

--

A deep dive into the heart of the Polkadot blockchain revolution: discover how its genesis block ushered in the era of native interoperability.

Versione italiana dell’articolo disponibile Qui; Italian Version available Here.

the starting point for native blockchain interoperability

TL;DR; Discover how Polkadot’s native interoperability blockchain was initiated.

Starting from a controlled phase with the Proof of Authority consensus algorithm, Polkadot has embarked on a journey towards maximal decentralization. Let’s delve into the role of the Web3 Foundation in the launch and configuration of the first block.

Disclaimer:
The content presented in this article is created entirely by human writers WITHOUT the use of AI or automated writing tools.

Introduction

The genesis of Polkadot followed a different path compared to networks seen so far (see my articles on Bitcoin and Ethereum); echoing Gavin Wood’s words, Polkadot’s mainnet was launched as a “network candidate” to become the mainnet; “first chain candidate (“CC1”)”, as the Polkadot network was referred to at its launch on May 26, 2020, 17:36:21, Zug time.

The network, in fact, was initially launched as a “proof of Authority” network, where validators earn the right to generate new blocks through a rigorous evaluation process. This model limits access to block generation to a restricted and reliable number of validating entities, selected by the foundation, thus ensuring the network’s security. Initially, governance was also centralized, entrusted to a super-user under the control of the Web3 Foundation to allow for the proper launch of the network and the timely and punctual management of necessary updates. This further underscores how Polkadot’s transition to an open network was gradual, determined by the foundation’s approval of the adequacy of the release candidate (at the time of CC1 launch, the foundation did not exclude the possibility of launching other versions of the chain candidate).

On June 18, 2020, once the Web 3 Foundation was confident in the stability of the network and a sufficient number of independent validators had joined and were active on the network, the super user initiated the first validator election, effectively transitioning to a Nominated Proof of Stake network.

On July 20, 2020, the superuser module was removed via a runtime upgrade, transferring chain governance into the hands of token holders, transitioning to a network without control by a central authority, to a decentralized governance system subject to a proposal and voting process in which any token holder can participate.

The Genesis Block of Polkadot

At the launch of Polkadot, two crucial blocks characterized the genesis process. The first, block 0, represents the foundational configuration serving as the root for the blockchain.

In the Polkadot block 0, we observe that no validator is assigned, as this initial block is of a technical nature and primarily serves as a foundation for the network’s launch. At this stage, the system has not yet established the participants who will act as validators to confirm subsequent transactions. This block constitutes a crucial starting point, fundamental for the initial configuration and architecture of the Polkadot blockchain, preparing it for optimal operation as the network continues to operate.

If we take a look at block 1 we find the actual validator who validated the block starting the chain.

The first block ( #1) of Polkadot was created via proof of authority validation

So let’s try to analyze how the genesis configuration for the polkadot network occurred by analyzing the genesis configuration files of the network.

From the Polkadot client, used to start a test network with the platform’s functionality, we can see that the Genesis configuration occurs through the definition of specific parameters within a JSON file.

At the time of starting the Mainet CC1, the polkadot software was version v0.8.0

Startup version of the polkadot software when launching the Release Candidate

The Configuration of the Polkadot Network

We find the file of the various configurations at path polkadot/node/service/chain-spec/

Network Configuration Json File (polkadot / kusama e varie testnet)

Analyzing the Polkadot file, we notice that the genesis component is in raw format, making it effectively impossible to read as it is not rendered in a user-readable format.

the Json configuration file is not Human Readable

To analyze the network configuration in order to understand how it was set up to generate the first genesis block, we proceed by generating a similar file using the Polkadot client from the development network. This will allow us to obtain a user-readable file.

polkadot build-spec --chain "polkador-dev" > Polkador-spec.json

Let’s briefly look at the main parameters of the configuration

Name & ID: define the Network Name and Network Identifier
chainType: define the Mainnet (“Live”) or the development network
bootNodes: when you first start a node, it must be able to find a way to find other nodes in the network. For this purpose, “bootnodes” are needed. Once it finds the first startup node, it can use that node’s connections to continue expanding and fulfilling its role in the network

telemetryEndpoints: it indicate the telemetry services address that the polkadot network uses to monitor the nodes operating characteristics

Section of the configuration Json most linked to the consensus algorithm

Then it starts the section related to the Genesis and to the consensum algorithm:

babe: Blind Assignment for Blockchain Extension, block generator parameters
Balances: initialization balance of pre-feeded adresses (Presales e ICO)

We then find the configuration of validators and components of the GRANDPA algorithm that defines which changes are the final ones.

All the configuration parameters of the network parameters are therefore present, such as the maximum size of the queues.

Conclusions

We have thus examined the initial configuration of the Polkadot network, as well as identified where it is possible to adjust parameters to launch development and test networks in a sandbox environment. Polkadot had a controlled start, beginning with a Proof of Authority and then transitioning to a Proof of Stake, before enabling on-chain governance and disabling the superuser SUDO during subsequent updates after the first blocks. The Web3 Foundation has followed and supervised the network launch, transitioning from a candidate mainnet (CC1) to the current live mainnet, where the genesis block was configured as outlined above.

References: