Can DFINITY, which specializes in underlying technologies, envision Web3 truly be realized?

Recommended: The market is bullish and bearish and encounters the situation in Ukraine, click here to join the PANews group to warm up

Original title: Interpretation of the new white paper of DFINITY, the public chain of potential stocks What is the underlying technology in the era of connecting Web 3.0?

Author: TinTinLand

1

Lead

At the beginning of February 2022, Dmail, the first private email DApp developed based on the DFINITY ecosystem, received strategic investment from Amino Capital. It is reported that Dmail can send emails to and from traditional mailboxes, and compared with traditional mailboxes, Dmail with blockchain attributes can also realize encrypted transmission of information and NFT of mailbox names. This is a preparation for communication software in the Web 3.0 era, which serves as the entrance to decentralized websites and DApps in the form of “digital identity”. The question I want to ask is, why did Dmail choose Dfinity?

Compared with the public chains of the blockchain, Dfinity has not emerged many times. There was no DeFi fire when there was a little spark, and there was no earning a seat in the first year of “NFT”. However, since its launch, it is not uncommon for people like Dmail to get a glimpse of what the specific implementation of Web 3.0 will look like.

DFINITY released the open-source version of the short video social software “CanCan” in July 2020, which we can simply benchmark against Douyin of Web 2.0. CanCan is based on DFINITY’s programming language, Motoko, and has less than 1,000 lines of code. This can be called amazing compared to the tens of millions of lines of code on Douyin and Facebook. At the same time, CanCan’s code is open source, and the ownership of the product does not belong to any centralized authority. On October 1 of the same year, DFINITY unveiled its governance system and token economic model, and the project’s valuation once reached $9.5 billion, ranking among the top five. At the end of December of the same year, the milestone evolution of the five networks from copper to mercury was completed. Dominic Williams, Founder and Chief Scientist of DFINITY Foundation, said at the “2020 FAT Value Era Summit Forum and Awards Ceremony” that the Internet computer is the third great innovation of blockchain.

This article will interpret the original text of DFINITY’s white paper, starting from the lowest logic of the official explanation, to see how DFINITY can start from technology, break the Internet big tech, and let various Web2.0 software use autonomous software and decentralized governance to achieve the synergy of open source business, so as to truly realize Web3.0; Readers with no experience in the blockchain industry may have a reading threshold when reading this article, but they are also welcome to comment on the questions that arise below, and they may get unexpected answers.

2

Outline

Throughout the history and current process of blockchain, BTC has brought the era of decentralized money, ETH represents the field of operating systems, Filecoin represents storage, and DFINITY represents the innovation of the computing field and the implementation of Web 3.0. Internet Computer (hereinafter referred to as IC) is the main network, is a layer 1 protocol, aiming to develop a decentralized public network, DFINITY is an open virtual blockchain computer and technology, extending the Ethereum ecosystem to a wide range of business application scenarios. In this article, we will use the official term “Internet Computer” in the white paper to refer to the “DFINITY” chain that is commonly used in the current communication scenario. This section mainly explains the technical terms involved in some ICs, as well as the differences in technology and implementation compared with other public chains, or the shining points in technology and function. It can be said that IC is a new attempt at the combination of scalability, decentralization, and security.

2.1 Consensus Protocol

Looking at IC and several other major public chains from the perspective of consensus protocols, IC adopts a hybrid model DAO-controlled network, which provides many of the benefits of a decentralized PoS protocol while having the efficiency of a permissioned protocol. Bitcoin, Ethereum, and Algorand consensus protocols are blockchain-based, using either Proof of Work (PoW) or Proof of Stake (POS). Although these protocols are fully decentralized, they are less efficient than permissioned protocols.

DAOs operate by a permissioned consensus protocol for each subnet, and a DAO decides which entities can provide copies of nodes, configures the network, provides public key infrastructure, and controls the version of the protocol in which copies of nodes are deployed. IC’s DAO is called the Network Nervous System (NNS) and is based on the Pos protocol, that is, relevant decisions are all decided by community members, and the voting power of community members is determined by the number of IC native governance tokens (ICPs) they stake in NNS. This PoS-based governance mechanism allows you to create new subnets and add or remove replicas of nodes from existing ones, as well as deploy software updates and make other adjustments to the IC.

From this perspective, we can also understand why DFINITY calls IC a network of replicated state machines, because NNS itself is a replicated state machine. Like other state machines, they run on a specific subnet, and their membership is determined by the same PoS-based governance system mentioned above. At the same time, a database called a registry is maintained, which records which node replicas belong to which subnet, the public keys of the node replicas, and so on. Therefore, the DAO control network serves as a decentralized consensus protocol, allowing the IC to obtain effective consensus, but at the same time, because of the operation mechanism of the DAO, the IC also retains the existing advantages of decentralization.

The IC’s consensus protocol also uses public-key cryptography, such as the registry maintained by NNS to bind the public key to the node replica and subnet to form a whole, which is called chain-key cryptography, and the IC also envisions the communication model for the consensus protocol and the protocol that executes the replication state machine: it hopes to adopt a more feasible and robust asynchronous model (for any message sent, the adversary can delay the delivery of any message for an arbitrary time, so there is no time limit for the delivery of the message) to deal with Byzantine failures. However, at present, there is no known consensus model that is really feasible under the asynchronous model, and in the following interpretation of the IC architecture, this article will explain in more detail the technical approach to IC for this real-world situation.

2.2 Chain Key Cryptography

As mentioned above, IC’s consensus protocol also uses public-key cryptography - chain key cryptography, and there are several main parts that make up chain key cryptography. The first component of chain key cryptography is threshold signature: threshold signature is a mature cryptographic technique that allows a subnet to have a common verification signing key, and the corresponding signing private key is divided into multiple copies and distributed to the nodes in the subnet, while the allocation guarantees that the bad node cannot forge any signatures, and the private key fragment owned by the honest node allows the subnet to generate signatures that conform to IC principles and protocols.

A key application of these threshold signatures is that the individual output of one subnet can be verified by another subnet or by an external user, and the verification can be done simply by verifying the electronic signature implementation using the public verification signing key of the modified subnet (the first subnet).

As we can see, there are many other applications of these threshold signatures in the IC. One should be used to make each copy of a node in a subnet accessible to unpredictable pseudo-random digits (derived from such threshold signatures). This is the basis for the random beacons used by the consensus layer and the random tapes used by the execution layer.

To securely deploy threshold signatures, the IC employs an innovative Distributed Key Generation (DKG) protocol to construct a public signature verification key and provide each node replica with a fragment of the corresponding signing private key for the previously mentioned Byzantine failure and asynchronous models.

2.3 ICP

ICP has the following features:

NNS staking, i.e., facilitating network governance.

ICP can be used to stake in NNS to gain voting rights and thus participate in the DAO that controls the IC network. Users who stake tokens in NNS and participate in NNS governance also receive newly minted ICP tokens as voting rewards. The number of rewards is determined by the policies established and enforced by NNS.

Redeem Cycles, i.e. as a production power.

The ICP is used to pay for the use of the IC. More specifically, ICP can be redeemed for cycles (i.e., burned), which can be used to pay for the resources (storage, CPU, and bandwidth) used to create tanks and tanks. The ratio of ICP to cycle is determined by NNS.

Node providers are paid, i.e. given as rewards to participants.

ICP is used to pay node providers – entities that own and operate compute nodes to host the copies of the nodes that make up the IC. NNS regularly (currently monthly) determines the newly minted ICP that each node provider should receive and release it to their account. According to the policies established and enforced by NNS, the payment of ICP is premised on the node provider providing reliable services to the IC.

2.4 Execution of NNS

As mentioned earlier, the IC’s replication state machine can execute arbitrary programs. The basic computing unit in an IC is called a tank, and it is much the same concept as a process, containing the program and its state (which changes over time). The program of the tank is coded in WebAssembly (hereafter referred to as Wasm), which is a two-mechanism instruction format based on a stacked virtual machine. Wasm is an open-source standard, and although it was originally designed to enable high-performance applications on the web, it is also well suited for general-purpose computing.

The IC provides a runtime environment for executing Wasm programs within the tank and communicating (via messaging) with other tanks and external users. While in principle it is possible to write a tank program in any language that compiles to Wasm, the aforementioned language called Motoko is very consistent with the semantics of IC operations and can be used in ICs.

Motoko is a strong-typed, actor-2-based programming program with built-in support for orthogonal persistence 3 and asynchronous messaging. Quadrature persistence means that the memory maintained by the tank is automatically persisted (i.e., it does not have to be written to a file). Motoko has a number of productivity and security features, including automatic memory management, generics, type inference, pattern matching, and arbitrary and fixed-precision arithmetic.

In addition to Motoko, the IC provides a message interface definition language and data format called Candid, which is used for fixed-type, high-level language, and cross-language interoperability. This makes it easy for any two tanks, even if written in different high-level languages, to communicate with each other. In order to provide full support for tank development for any given programming language, specific runtime support must be provided in addition to the Wasm compiler for that language. Currently, in addition to Motoko, the IC also fully supports tank development in the Rust programming language.

As a result, ICs support more secure and cross-language programming languages, which is one of the important factors that make developers more effective and secure in creating ICs.

2.5 NNS Decisions

In the DFINITY blockchain network, BNS (Blockchain Nervous System) is the governance system that the network operates on, and it is one of the most important building blocks in the blockchain network, which can automatically enter the system and have high authority. It takes on the role of a supernode. Anyone participates in NNS governance by staking ICP in so-called neurons. Neuron holders can propose and vote on how the IC should be changed, such as the topology of the subnet or the protocol. Neurons’ voting rights are PoS-based. Intuitively, the more ICP is staked, the more neuronal voting rights are greater. However, voting power also depends on other characteristics of neurons, such as neuronal holders who are willing to stake their tokens for a longer period of time, are given greater voting power.

Each proposal has a definite voting period. If, at the end of the voting period, a simple majority of those voting in favor of the proposal and the number of votes in favor exceeds the given quorum requirement for total voting rights (now 3%), the proposal is adopted. Otherwise, the proposal was rejected. In addition, at any time a supermajority (more than half of the total vote) is in favour or against the proposal, the proposal is accepted or rejected accordingly.

In more layman’s terms, the BNS governance process is divided into four phases: creating neurons, proposing, voting, and executing.

Create Neurons: As mentioned above, the blockchain Neurosystem allows users to use ICP to create voting neurons. Anyone can create a neuron, and in the future tens of thousands of neurons may be created, which will collectively express the will of the community, mediated through algorithms.

Proposals: Any user running neurons can make a proposal on BNS, and BNS will review the proposal based on the reasonableness of the proposal and whether it provides a solution. The user who makes the proposal needs to pay two fees: one is to pay the professional reviewers and the neurons who participated in the voting, and the other is the proposal deposit, which will be returned to the neuron after the proposal is adopted, and this amount can be set to incentivize high-quality proposals.

Voting: In addition to the proposer, other users also need to stake tokens to neurons during the voting phase and be able to choose to actively vote or follow the vote. Users with independent judgment ability can choose to actively vote, and the scenario of following voting is suitable for some users who cannot accurately judge proposals. After the voting time is closed, BNS collects the results of the neural network, and automatically determines whether the proposal is approved or not.

Implementation: Just now there is an interpretation of the IC consensus of the execution layer, what is the specific implementation of the implementation of the BNS governance system? THE PROPOSAL FOR PASSIVE EXECUTION MAINLY INVOLVES PARAMETER CHANGES TO SMART CONTRACTS ON DFINITY, SUCH AS THE STAKING PARAMETERS OF NEURONS. The updated proposal parameters will be passively written into the BNS smart contract database, and will take effect directly when they are executed later. There is a special case where the proposal is beyond the control of the BNS smart contract, for example involving the BNS regulatory level, which will require human active enforcement to override the “code is law” part of DFINITY. For example, modifying vulnerabilities in system code or freezing smart contracts or neurons that violate BNS regulations. The active execution process is implemented by invoking special opcodes added to the EVM. The operation of this step is more humane and reasonable, rather than the current “code is law” and “code is everything” in the current blockchain world. From the perspective of human nature, covering scenarios where code cannot make decisions can bring more effective and intelligent governance, and to some extent, it also truly touches the underlying intent of “consensus”.

3

Architecture Interpretation

The IC protocol consists of four layers (as shown in the figure below), namely the P2P layer, the consensus layer, the routing layer, and the execution layer. In this part, this paper only interprets the roles and functions of the four-layer architecture, and analyzes the construction of the overall architecture. FOR A MORE DETAILED UNDERSTANDING OF THE SPECIFIC TECHNICAL IMPLEMENTATION OF A PARTICULAR LAYER, PLEASE REFER TO THE ORIGINAL DFINITY WHITE PAPER.

3.1 P2P layer

The P2P layer serves as the layer in the Internet computer protocol layer for message fetching and ordering, and its task is to deliver protocol messages in a copy of the nodes of the subnet.

There are two types of protocol messages: messages used to achieve consensus and input messages initiated by external users.

We can understand that the P2P layer basically provides a “best effort” broadcast channel, i.e. if an honest node copy broadcasts a message, the message will eventually be received by all city nodes in the subnet.

The P2P layer is designed with the following goals:

Limited resources. All algorithms run with limited resources (memory, bandwidth, CPU).

Priority. Depending on specific attributes, such as type, size, and turn, different messages will be sorted with different priorities. And the rules for these priorities may change over time.

Highly efficient. High throughput is more important than low latency. THE HIGH THROUGHPUT IS ALSO THE REASON WHY DFINITY IS MORE EFFICIENT FROM THE BOTTOM THAN OTHER PUBLIC CHAINS.

Anti-DOS/SPAM. Failed nodes will not affect communication between honest node replicas.

3.2 Consensus Layer

3.2.1 Consensus Layer Overview

The task of the IC consensus layer is to sort the input messages to ensure that all replicas of the nodes process the input messages in the same order. There are many protocols in the literature that address this issue. IC adopts a new consensus protocol, which will be described in general language in this article. Any secure consensus protocol should ensure two attributes, which are roughly that:

Security: All replicas of nodes de facto agree to the same order of inputs.

Active: All node replicas should update their status one by one.

The design goal of the IC consensus layer is actually easy to understand: when there are individual malicious nodes, the performance will be degraded flexibly. Like many consensus protocols, the IC consensus protocol is blockchain-based. As the protocol progresses, the block tree with the genesis block as the root node will continue to grow. Each non-genesis block contains a payload, which consists of a series of inputs and the hash of the parent block.

Honest replicas have a consistent view of the chunk tree: Although each replica may have a different local view of the chunk tree, all replicas of the node see the same chunk tree. In addition, as the protocol progresses, there will always be a path in the block tree to finalize the block. Again, honest node replicas have a consistent view of this path: although each node replica may have a different local view of the path, all node replicas see the same path. The inputs in the load of the blocks along this path are the sorted inputs that will be processed by the execution layer of the IC.

The consensus protocol relies on electronic signatures to verify messages in a copy of a node. To achieve this, each copy of the node is associated with a public authentication key for the signing protocol. The correlation between the node replica and the public key can be obtained from the registry maintained by NNS. This is also in line with the role and role of chain-key cryptography in ICs mentioned above.

3.2.2 Assumptions

As discussed in Part II, IC proposes the following hypothesis:

A subnet contains n replicas of nodes, and a maximum of f

Failed node replicas may exhibit arbitrary, malicious (i.e., Byzantine failure) behavior. We assume that the communication is asynchronous and that there is no prior limitation on message latency between node replicas, i.e., the asynchronous model mentioned above. At this point, the scheduling of the messaging may be completely hostile. Under this weak communication assumption, the IC consensus protocol can ensure security. But to ensure activity, we need to assume a certain form of partial synchronization, meaning that the network remains periodically synchronized at short intervals. Under this synchronization interval, all unsubmitted information will be submitted within the time, i.e., a fixed time limit δ. The time limit δ is not known in advance (the protocol initializes a reasonable boundary value but dynamically adjusts the value and increases the limit value when the time limit is too small). Regardless of whether the network is asynchronous or partially synchronous, we assume that messages sent by an honest node replica to another node replica will eventually be delivered.

3.2.3 Protocol Overview

Like many consensus protocols, the IC consensus protocol is blockchain-based. As the protocol progresses, block trees (see 3.2.4 for example) with the genesis block as the root node will continue to grow. Each non-genesis block contains a payload, which consists of a series of inputs and the hash of the parent block. Honest replicas have a consistent view of the chunk tree: Although each replica may have a different local view of the chunk tree, all replicas of the node see the same chunk tree. In addition, as the protocol progresses, there will always be a path in the block tree to finalize the block. Similarly, honest node replicas have a consistent view of this path, and although each node replica may have a different local view of the path, all node replicas see the same path. The inputs in the loads of the blocks along this path have been sorted and processed by the execution layer, which is interpreted in the previous section.

3.2.4 Practical example

The image below shows a block tree. Each block is marked with a block height (30, 31, 32, ··· ) and the ranking of block generators, which shows that each block in the block tree is notarized and marked with the symbol N. This means that the notarized blocks in each block tree are supported by the notarization of at least n-f copies of different nodes. It can be found that there can be more than one notarized block at the specified block height. For example, at block height 32, we can see 2 notarized blocks, one proposed by the block generator in rank 1 and the other proposed by rank 2, and the same thing happens at block height 34. We can also see that blocks with a height of 36 are also explicitly confirmed, as identified by the symbol F. This means that n-f copies of different nodes have supported the final confirmation of the block, which means that these node copies (or at least the honest node copies of these) do not support the notarization of any other block. All ancestors whose block is filled with gray are considered to have received implicit final confirmation.

**3.2.5 Impartiality **

Fairness is the foundation of consensus, so another important attribute in consensus protocols is fairness. Rather than setting a universal definition, we simply observe that invariance of life implies a useful fairness property. To recap, invariance essentially means that in any round, when the masternode is honest and the network is synchronized, the block proposed by the masternode will also be finalized. In the turn in which this happens, the honest master node actually ensures that it contains all the inputs it knows about in the load of the block (depending on the module limits of the load size). So, roughly speaking, any input that is propagated to a sufficient number of node copies will most likely be included in the final confirmed block within a reasonable amount of time.

3.3 Routing Layer

As mentioned earlier, the basic computing unit in the IC is called a tank. The IC provides the operating environment in which programs can be executed in the tank and can communicate (via message) with other tanks and external users. The consensus layer packs the input into the load of the block, and as the block is confirmed by the reddest, the corresponding load is passed to the message routing layer and processed by the execution environment. The execution layer then updates the state in the corresponding tank in the replication state machine and hands off the output to the message routing layer for processing.

It is necessary to distinguish between two types of inputs:

Ingress Message: A message from an external user.

Cross-subnet messages: Messages from tanks in other subnets.

We can also distinguish between two types of output:

Ingress message response: The response to the ingress message (which can be retrieved by external users).

Cross-subnet messages: Messages that are transmitted to other subnet tanks.

When loads from consensus are received, the inputs in those loads are placed into different input queues. For each tank C under a subnet, there are multiple input queues: an ingress message to C, a separate tank C’ to communicate with C, and a cross-subnet message from C to C’.

In each round, the execution layer consumes some of the inputs from these queues, updates the replication state in the corresponding tank, and places the outputs in a different queue. For each tank under a subnet, there are multiple output queues: for each tank that communicates with, there is a queue for cross-subnet messages from C to C’. The routing layer of the message takes the messages in the message queue and places them into the subnet-to-subnet traffic to be processed by the cross-subnet transport protocol, which actually transmits the messages to other subnets.

In addition to these output queues, there is also a historical data structure for ingress messages. Once an ingress message has been processed by the tank, the response to that ingress message is recorded in that data structure. At this point, the external user who provided the ingress message will be able to get the relevant response. (Note: Ingress history does not keep a complete history of all ingress messages).

There are two points that need to be clarified, first, the state of the node replica includes the state of the tank as well as the “system state”. “System State” includes the queues, data flows, and data structures of the ingress history mentioned above. As a result, both the message routing layer and the execution layer are involved in updating and maintaining the replica state of the subnet. This state should all be updated with complete determinism, so that all nodes maintain the exact same state.

The second point to note is that the consensus layer precedes the message routing layer and the execution layer, which means that any forks in the consensus blockchain have already been resolved before the load is passed. In fact, the consensus layer allows for early operation and does not need to be on the same schedule as the message routing layer.

The explanation and explanation of the routing layer give us a clearer understanding of how the consensus protocol is transmitted to and from the consensus protocol through message routing, and how it is connected to the execution layer, so as to promote the coordination and consistency of the consensus protocol.

3.4 Execution Layer

The execution environment processes one input at a time, which is taken from one of the input queues and directed to a tank, depending on the state of the input and the tank, the execution environment updates the state of the tank and can additionally add messages to the output queue. and update the ingress history (possibly along with the response to the previous ingress message). In a given turn, the execution environment will process multiple inputs. The scheduler determines which inputs will be executed in what order for a given turn. Instead of going into too much detail about the scheduler, we’ll highlight some of the goals:

It must be deterministic, i.e. depend solely on the given data;

It should distribute the workload fairly across tanks (but optimize for throughput rather than latency).

The number of work completed in each round is measured in cycles and should be close to some predetermined quantity.

Another task that the execution environment must deal with is the situation where one of the tanks of one subnet produces messages across subnets faster than the other subnets can consume. In response to this situation, we implemented a self-regulatory mechanism for slowing down the production tank. There are many other resource management and bookkeeping tasks that need to be handled by the runtime environment, but all of these tasks must be handled deterministically.

4

Chain Key Cryptography

In the synopsis, we explain that the consensus protocol of the IC also uses the public key cryptography technique - chain key cryptography, and an important part of chain key cryptography is threshold signature. In fact, chain-key cryptography encompasses a complex set of techniques used to robustly and securely maintain blockchain-based replication state machines over time, collectively known as chain evolution techniques. Each subnet operates within epochs that contain multiple rounds (usually about a few hundred). The chain evolution technology enables many of the basic maintenance tasks that are performed on a per-epoch basis: garbage collection, fast forwarding, subnet member changes, active secret forwarding, and protocol upgrades.

The understanding of the chain evolution technology, that is, the understanding of the technical implementation of the IC consensus protocol security. Chain evolution technology consists of two basic components: summary blocks and catch-up packages (CUPs).

4.1 Summary Block

The first block of each epoch is the digest block. The summary block contains special data that is used to manage key fragments for different threshold signature schemes. There are two threshold signature schemes:

In a scenario with a threshold structure of f + 1/n, a new signing key is generated for each epoch;

In a scenario with a threshold structure of n-f/n, the signing key is re-shared once per epoch.

Scenarios with low thresholds are used for random beacons and random tapes, while scenarios with high thresholds are used to verify the replication status of the subnet. Recall that the DKG protocol requires that for each signing key, there is a set of dealings, and each node replica can obtain its signature key fragment non-interactively based on this set of dealings. Recall again, among other things, NNS maintains a registry that determines subnet members. The registry (and subnet members) change over time. As a result, subnets must agree on the version of the registry to be used at different times and for different purposes. This information is also stored in the summary block.

4.2 CUPs

With the summary out of the way, let’s take a look at catch-up packages, or CUPs. Before we elaborate on the CUP, we first need to point out one detail of random beacons: the random beacons of each round depend on the random beacons of the previous round. It is not a fundamental feature of the CUP, but it influences the design of the CUP. A CUP is a special (not on the blockchain) message that has everything a node needs to work at the starting point of an epoch without knowing any information about the previous epoch. It contains the following data fields:

The root of the Merkel hash tree for the entire replicated state (as opposed to the partial state of each round of validation in Chapter 1.6).

epoch.

Random beacon for the first round of epoch.

The threshold signature of the subnet for (n - f)/n for the above fields.

In order to generate a CUP for a given epoch, the node replica must wait until the digest block of the epoch has been finalized and the corresponding round state has been verified. As mentioned earlier, the entire replication state must be processed into a Merkle tree by a hash function. While there are many techniques used to speed up this process, the cost is still significant, which is why each epoch is only processed once. Because the CUP contains only the root of this Merkle tree, we use a state synchronization subprotocol that allows the node replica to extract whatever state it needs from the peer. Again, we’ve used a lot of technology to speed up this process, and it’s still costly. Because we use high-threshold signatures for CUPs, we can guarantee that there is only one valid CUP on any epoch, and that state can be extracted from many peers.

4.3 Chain Evolution Technology Implementation

Garbage collection: Because the CUP contains information about a particular epoch, each copy of the node can safely purge all processed inputs prior to that epoch, as well as the consensus layer messages that ordered those inputs.

Fast forwarding: If a replica of a node in a subnet lags significantly behind its synchronous node (because it is down or disconnected for a long time), or if a new replica of the node is added to the subnet, they can quickly forward to the starting point of the latest epoch without having to run the consensus protocol and process all the input before that point. This copy of the node can be done by getting the latest CUP. With the digest blocks and random beacons contained from the CUPs, as well as (not yet cleared) consensus messages from other node copies, the node replica can run the consensus protocol forward from the starting point of the corresponding epoch. The node can also use the state synchronization subprotocol to get the replication state at the beginning of the corresponding epoch, so that it can also start processing the inputs generated by the consensus layer.

The following diagram depicts fast forwarding. Here, let’s assume that we need a node replica that needs to catch up at the epoch starting point, (let’s say) with a block height of 101 and a CUP. This CUP contains the root of the replicated Merkle tree with a block height of 101, a summary block with a block height of 101, and a random beacon with a block height of 101. The node uses the state synchronization subprotocol to get all replication status of block height 101 from its peers and verifies this state with the Merkle tree in the CUP. After obtaining this state, the node copy can participate in the protocol, obtain blocks with block height of 102, 103, etc. (and other consensus-related messages) from the peer, and update the copy of its replication state. If its peers have confirmed blocks at a higher level, the copy of the node will process (as well as notarize and finalize) those finalized blocks obtained from the peers as soon as possible (as fast as the execution layer allows).

5

Epilogue

Like Ethereum, DFINITY’s vision is to build the “world’s supercomputer”, through the aforementioned partial interpretation and technical explanation of its white paper. ICs under this vision have a great opportunity to be realized.

We can see the technological innovation and technical feasibility of IC to realize its vision from the hybrid model DAO of the consensus protocol, from the technological innovation of fast block generation and high throughput, and from the BNS neuron system and its ecological governance scheme. Unlike the current Ethereum code, which is law, IC code governance adds elements of crowd wisdom to the foundation, not with the goal of establishing a perfect code architecture, but with the goal of the system being able to quickly adjust the rules. This is not only a technological creation, but also a shining human nature. In the blockchain world, the establishment, maintenance and modification of consensus cannot be just codified, but the essence of the core should be people. Valid and fair consensus between human-centric groups is at the heart of the blockchain industry and the attraction of many decentralized Dapps.

This article cites and interprets some of the contents of the IC white paper, which describes more details about NNS, the authentication status of each round of subnets on the consensus layer, the query and update calls of entry messages, distributed key distribution in chain key cryptography, PVSS schemes, basic protocols and resharing protocols, and so on. For developers who want a more comprehensive and detailed understanding of the underlying technology of the IC, reading the original white paper can provide more detailed explanations and explanations.