Before we talk about the PlatON testing, we need to figure out the difference between blockchain testing and traditional Internet testing. That is mainly reflected in the blurring of the system boundary: the former is not only between the front-end API and a certain blockchain node but also among a large number of blockchain nodes.

At the same time, it should be noted that the PlatON chain includes public chains and private chains that vary from each other in terms of management, user identity, the maximum number of nodes, etc. The testing needs to factor in all the modes, making the testing schemes and scenarios more complicated than in conventional testing.

Now let’s look at PlatON. First of all, it is not a product of exchange, but a basic ecological service based on blockchain technology and the value generated by chain technology. It has a different focus as well. PlatON testing will pay more attention to the base layer, such as the consensus algorithm, network, storage, and economic model.

Now let’s look at PlatON. First of all, it is not a business of an exchange, but a basic ecological service based on blockchain technology and the value generated by chain technology. The testing has a different focus. Our testing concentrates more on the base layer, such as consensus algorithm, network, storage, economic model, etc. This article will probe into the related details.

On-chain functions

This stage is also the main part of the PlatON testing, mainly involving the base layer and the business layer.

Giskard consensus

As a popular saying goes, “there will be no block without a consensus”. As the core attribute of the blockchain, the “consensus mechanism” determines the important features of the blockchain such as security, decentralization, and scalability, and ensures all nodes agree on transaction execution results.

PlatON’s Giskard consensus protocol is composed of the PlatON proof of stake (PPoS) and the Giskard Byzantine Fault Tolerance (BFT). PPoS selects validators participating in the consensus by means of staking, delegation and random selection. Giskard BFT uses a BFT-like algorithm to generate and verify blocks.

In terms of the Giskard consensus, we designed a verification scenario to cover the PlatON consensus module.

1.Verify the consensus on each stage

• viewChange: It checks the basic information of viewChange, including combinations of scenarios such as viewChange initiation and receipt to verify correctness.
• prepareBlock: It checks the prepareBlock messages and verifies prepareBlock in different states initiated after the viewChangeQC during the same window period.
• prepareVote: It checks the basic verification of prepareVote messages and verifies prepareVote in different window periods and different node states.
• VerifyQC: Including viewChangQC and prepareQC. It detects scenario verification under a different number of signatures.

2. Verification of consensus module in simulated Byzantine fault

• Giskard-Non-Byzantine fault: It simulates the verification of the consensus module in each phase with participating nodes in a non-Byzantine fault.
• Giskard-Byzantine fault: It simulates the verification of the consensus module in each phase with participating nodes in Byzantine faults, e.g. double signing and malicious cheating.

3. Verification of consensus module in abnormal scenarios

• Giskard-Node start and stop: It verifies the integrity and continuity of the consensus module through operations such as node start and stop, interval start and stop, and node recovery.
• Giskard-Message loss: It simulates discarded voting, prepareBlock and other scenarios to verify the effectiveness of consensus message delivery.
• Giskard-Fault tolerance: It verifies the fault tolerance of consensus by constructing a timeout and a harsh environment.

Through the above scenarios, we need to verify whether this consensus mechanism can complete the process from transaction triggering to data storage in the local database according to the expected algorithm and still work normally within the scope of fault tolerance and disaster tolerance. Before the blockchain platform goes live, the consensus algorithm used needs to be rigorously tested and verified, which involves aspects such as functions, security, and ease of use.

P2P network verification

Connection is mainly involved between nodes in a peer-to-peer process, between nodes and clients, and communication among off-chain institutions through on-chain nodes. Such connections can go smoothly generally under normal conditions, and the corresponding results can be queried using network connection commands and log information. The robustness of the connection is reflected by how well the system copes with an abnormal environment and whether the connection can return to normal after the environment gets normal.

Therefore, we need to consider the following aspects to verify the security of the P2P network:

1. Number of nodes

With different combinations of the number of nodes, we can verify whether the time requirement for message transmission in network communication is met and whether there are omissions or losses in the message transmission.

2. Network traffic

Monitoring network traffic is to verify whether the resources on the chain are consumed as expected during the operation of various business functions and node operations in a chain, so as to prevent abnormal traffic in the operation from triggering a disagreement on the chain.

3. Node discovery

We verify whether the caps on the number of static nodes, the number of active links and the number of passive links take effect during the interconnection of the nodes, by setting the number of seed nodes and the number of static nodes, and whether the chain runs stably with different numbers of nodes.

The transaction sent to the node should be able to be synchronized to other nodes in the network. Different blockchain platforms will adopt different synchronization logic according to the node type and networking mode. Block synchronization involves many scenarios. For example, new nodes entering the network, process restarting after suspension for a period of time, data loss arising from node failures, etc. will all trigger the block synchronization logic. Also, when there is no transaction in process, the state will still be synchronized among the nodes. Detailed and comprehensive verification, including cross-testing, is required for any of the above scenarios.

Block storage

The stability and correctness of the block storage constitute the major part of verification. It is also important to ensure consistency in the data between the nodes when it is successfully packaged on the chain.

Each node can decide the information to be stored according to different startup strategies. Generally, we will adopt the fast or full mode for verification according to the startup parameters and synchronization mode. In this case, we need to consider whether there are any omissions in the block information locally recorded when multiple transactions are sent. We also need to verify whether each node stores data stably and accurately in various combinations of business scenarios through a chaos model.