4.4 Blockchain Low-level Layer Services

4.4.1 Security Mechanism

Improvements based on traditional Bitcoin encryption methods.

1）Symmetric encryption: Symmetric encryption is the fastest and easiest way to encrypt. The same secret key is used for encryption and decryption. Symmetric encryption usually uses relatively small keys, typically less than 256 bits. The size of the key should take into account both security and efficiency, which is a trade-off.

2）Asymmetric encryption: Asymmetric encryption provides a very secure method for data encryption and decryption, which uses a pair of keys, a public key and a private key. The private key can only be kept safely by one party and cannot be leaked, while the public key can be sent to anyone who requests it. Asymmetric encryption uses one of the pair of keys for encryption, while decryption requires the other key.

3）Private key: It is a 256-bit non-public random number, kept by the user and not open to the public. The private key is usually randomly generated by the system, and it is the only proof of the user's account usage rights and the ownership of assets in the account.

4）Public key: Publicly available, each private key has a matching public key. The ECC public key can be generated from the private key through a one-way, deterministic algorithm. Currently commonly used schemes include: secp256r1 (international general standard) secp256k1 (Bitcoin standard) and SM2 (Chinese national standard). The AirshipX control chain and initial data chain choose secp256r1 as the key scheme.

5）Hash algorithm: The hash algorithm usually refers to the Secure Hash Algorithm SHA, which is a series of encrypted hash functions designed by the National Security Agency and released by the National Institute of Standards and Technology (NIST), including SHA-1, SHA -224, SHA-256, SHA-384 and SHA-512 variants. Bitcoin currently uses the SHA-256 algorithm. Except for PoW, the other hash algorithms of AirshipX refer to SHA-256.

4.4.2 Consensus mechanism

At present, most of the blockchain applications choose the consensus mechanism based on the Raft algorithm. Raft is a distributed consensus algorithm released by Stanford. It is improved from the Paxos algorithm. It pays more attention to the understandability and ease of implementation of the protocol. It is characterized by at most 1 legal leader at any time, and the number of fault-tolerant nodes is N/ 2-1. The Raft algorithm is a simplified implementation of the Paxos algorithm. Its regulatory compliance, performance, resource consumption and fault tolerance are similar to Paxos. The Raft algorithm is applied to the GSTC.io chain and it is more efficient than the Paxos and PBFT algorithms, but at present, the industry applies Raft to the blockchain, mainly to elect a consensus node and keep accounting by this node. This scheme has the following problems：

1) The election of the consensus node does not take the block height of the node into consideration and cannot be effectively combined with the blockchain;

2) Elect a consensus node and let this node bookkeep continuously, this method comes with low fault tolerance;

3) At present, many schemes do not supervise consensus nodes enough, and cannot accomplish the dynamic joining and exit of consensus nodes.

Considering the above situation, the AirshipX project will choose the pbft algorithm to improve the deficiencies in the raft algorithm. This algorithm is similar to Paxos. It is also a consensus mechanism that uses permission voting and the minority obeys the majority to elect a leader for bookkeeping; but this consensus mechanism allows Byzantine fault tolerance. The consensus mechanism allows strong supervisory nodes to participate, has the ability to classify permissions, higher performance, and lower energy consumption. The algorithm will elect a leader jointly by the whole network nodes in each round of bookkeeping, allowing 33% of the nodes to do evil, and the fault tolerance is 33 %.

4.4.3 Cross blockchain communication protocol

The communication protocol between blockchains is similar to communication protocols such as TCP/IP in traditional networks, and messages are delivered by establishing reliable connections. The message is divided into two parts: the message header and the message information. The message header records the source, destination, length, category of the message. During the delivery process, the message header will be stripped and modified layer by layer, and the information will be transmitted to the destination of the message. In addition, message delivery is stateful, and the sender can know the current state of the communication based on the receiver's feedback.

A complete cross blockchain communication protocol mainly includes two parts, the communication address and the communication package.

The communication address includes the blockchain ID of the source blockchain (fromChainID) and the current blockchain height (Height). The communication packet is composed of two parts - the communication header (Header) and the communication information (Data). Among them, the communication header includes the starting blockchain ID (srcChainID), the target blockchain ID (dstChainlD), the communication status (Status), the communication time-to-live (TTL), and the trigger communication transaction. Communication information is not opened during the transfer process.

The communication state corresponds to the communication state mechanism in the network communication protocol. When a communication packet is sent, the communication status is "receive pending". When the receiver receives the message, it will return a communication packet to the sender, in which the communication status is "successfully sent". Received the communication packet identified by "Successful". The above is a successful communication. If a communication packet fails to be received during the process, for example, the receiver does not reply "successfully sent", the sender will resend the transaction after a certain period of time to try to establish communication again.

In addition to the above states, we also create a "connection timeout" state. When a transaction is sent from sub-chain 1 to sub-chain 2, it will indicate the specified time to live based on the block height of the link route. Before reaching the time to live, the link router will return the status of the communication result to the sub-chain. If the time to live is exceeded, the link router will directly return the "connection timeout" status to the sender. The sender subchain records this communication as a communication failure.

Similar to network communication, blockchain cross chain communication can also be attacked, especially DDoS attacks. Therefore, we need a communication verification mechanism that is easy to verify and difficult to forge to prevent the link from being paralyzed due to attacks.

The structure of the chain route mentioned earlier is a standard structure that we think child chains should conform to. Under the framework of the standard structure, it will be easier for the link router to verify the communication request sent by the sub-chain. As mentioned earlier, the sub-chain transmits the latest block and the vote of the latest block to the link at any time (Commit, when a transaction is sent from the sub-chain to the link, the transaction will be reflected in the communication address. The height of the block. We only need to find out whether this transaction exists in the block of this height. Because submitting the latest block and its vote (Commit) is enough to prove the authenticity of a block. The proof is as follows:

First of all, a block alone cannot prove its legitimacy. Because for an existing block, we can completely imitate a fake block that is illegal but conforms to the block structure. For example, we can modify the transaction in the data section of the block, and modify the transaction hash value located in the block header.

As mentioned earlier, after a block is proposed, it will go through two rounds of voting to reach consensus, and the votes of the second round of consensus will be temporarily stored and regarded as the part of the block generated in the next round that connects the previous block. Based on this, if the sub-chain submits a block and its vote at one time, we can prove the validity of this block within one round of block generation time. Instead of spending the generation time of two blocks, wait until the next block ii is generated, and verify the validity of the previous block through the authentication part of the previous block.

The process of verifying the legitimacy of an independent block through consensus is to first verify that the block has not been tampered with except for the block header through the block data in the block header and the hash value of the voting part. The voting (Commit) is more than 2/3 of the verification node of the chain and the signature corresponding to the block and block header cannot be tampered with once the node verification is completed, unless the sender of the message can control more than 2/3 of the verification on the chain at the same time People's private keys, otherwise no one can forge blocks.

4.44 Rights management

Every user of AirshipX has the opportunity to become a verification node. Each node in the blockchain will obtain a complete data record, and the owner of the rights and interests can be confirmed by the reliable and collective maintenance of the blockchain.