leaf

Enterprise-level blockchain (also known as consortium blockchain) primarily addresses the blockchain technology needs of large companies, government agencies, and industry alliances, providing enterprise-level blockchain network solutions. The nodes in a consortium blockchain typically correspond to the organizational entities of each member, and the joining and exiting of nodes require authorization. Various organizations form a coalition of stakeholders to jointly maintain the healthy operation of the blockchain network.

Unlike private and public blockchains, enterprise-level blockchains focus more on the practical implementation of blockchain technology, with higher requirements for performance speed and security, member authentication management, and data privacy protection. In addition, the research and development of enterprise-level blockchains are often directly related to actual business scenarios, closely addressing industry pain points and providing a more comprehensive integrated blockchain solution for enterprise alliances.

The diagram illustrates the mutually reinforcing relationship between the consortium blockchain platform and blockchain applications. On one hand, the consortium blockchain platform provides the underlying technical support for the research and implementation of actual industry applications; on the other hand, industry applications and the validation of concepts also drive the continuous development and maturity of the consortium blockchain platform.

Hyperchain supports enterprises in rapidly deploying, expanding, and managing blockchain networks based on existing cloud platforms, providing real-time visual monitoring of the operational status of the blockchain network. It is a domestic blockchain core system platform that complies with ChinaLedger technical specifications. Hyperchain features a verification node authorization mechanism, multi-level encryption mechanism, consensus mechanism, and a Turing-complete high-performance smart contract execution engine, making it a fully functional and efficient foundational technology platform for consortium blockchains. In application scenarios aimed at enterprise and industry alliance needs, Hyperchain can provide high-quality underlying blockchain support technology platforms and convenient and reliable integrated solutions for multi-center applications such as asset digitization, data notarization, supply chain finance, digital invoices, and payment clearing.

The overall system architecture of Hyperchain is shown in the diagram.

For the enterprise-level consortium blockchain foundational technology platform, we mainly consider the following basic features:

• Participant member identity authentication and permission mechanism

• Security and privacy of commercial transaction data

• High transaction throughput and low transaction latency

• Secure and complete smart contract engine

• High user experience interoperability

For the participant member identity authentication and permission mechanism, the platform has the following functions.

• Autonomous coalition ACO. The platform permits the creation of autonomous member organizations within the consortium blockchain network, submitting proposals and organizing internal voting on status actions within the coalition, such as system upgrades, contract upgrades, member management, etc. This method provides an effective model for blockchain alliance governance.

• Member management. The platform achieves access control for coalition members through a CA system certification method, supporting both self-built CA and CFCA modes, and provides a hierarchical permission management mechanism for chain-level administrators, node administrators, and ordinary users, enabling different permission access control.

For the security and privacy of transaction data, the platform has the following functions.

• Multi-level encryption mechanism. A pluggable encryption mechanism is adopted, with different strategies for encrypting data, users, communication connections, etc., involved in the complete lifecycle of the business. Multi-level encryption ensures the security of platform data and fully supports national cryptographic algorithms.

• Privacy protection. The platform provides two mechanisms for privacy protection: Namespace partition consensus and privacy transactions. The partition consensus isolates the storage and execution space of sensitive transaction data, allowing some blockchain nodes to create their own partitions, where data transactions and storage among partition members are invisible to nodes in other partitions. Privacy transactions specify the relevant parties of the transaction at the time of sending, with transaction details stored only with the relevant parties. The hash of the privacy transaction is stored after consensus across the network, ensuring effective isolation of private data while allowing verification of the authenticity of the privacy transaction.

• Trusted data sources. The blockchain is a closed deterministic environment, and it cannot actively obtain real-world data outside the chain. The platform introduces an Oracle mechanism to support writing external information into the blockchain, completing data intercommunication between the blockchain and the real world. This oracle achieves trust endorsement through third-party trusted institution signatures, meeting the requirements for verifiable honesty.

For throughput and transaction latency, the platform has the following functions.

• Efficient consensus algorithm. The platform adopts the RBFT (Robust Byzantine Fault-Tolerant) consensus algorithm, which enhances the overall transaction throughput and system stability while ensuring strong consistency of node data. The TPS (transactions per second) reaches tens of thousands, with latency controllable within 300 ms. The platform can also use GPU-based signature verification acceleration to further enhance overall performance, fully meeting the needs of blockchain commercial applications, and supports dynamic node management and failure recovery mechanisms, enhancing the fault tolerance and availability of the consensus module. Future integrations of other consensus algorithms (such as RAFT) will be carried out to adapt to different business scenario requirements.

• Data separation. The ledger data in the blockchain is mainly divided into block data and state data. Considering that block data will continuously grow while state data will only be frequently updated, the platform introduces a Filelog storage engine to achieve separation of block data and state data, ensuring that read and write performance is not affected as the system data volume continues to increase.

For the secure and complete smart contract engine, the platform has the following functions.

• The platform supports multiple smart contract engines such as EVM, JVM, and HVM;

• Supports programming languages such as Solidity and Java;

• Provides comprehensive contract lifecycle management;

• Features programming-friendly, contract security, and efficient execution, adapting to complex and variable business scenarios.

For high user experience interoperability, the platform has the following functions.

• Data archiving. To address the issue of infinite growth of blockchain-stored data, we archive some old online data offline, while providing an Archive Reader for browsing archived data.

• Data visualization. To facilitate users in real-time checking the contract status data on the blockchain, the platform provides a data visualization component called Radar, which can import contract status data from the blockchain into relational databases (such as MySQL) while the blockchain operates normally, making contract status visualizable and monitorable, aiding business statistics and analysis.

• Message subscription. The platform provides a unified message subscription interface for external systems to capture and listen to changes in the blockchain platform's status, enabling message intercommunication on and off the chain, supporting subscriptions for block events, contract events, transaction events, system anomaly monitoring, and other events.

Next, taking Hyperchain as an example, we will elaborate on the core technical modules that constitute the enterprise-level blockchain platform, mainly analyzing the implementation principles of consensus algorithms, smart contracts, ledgers, security mechanisms, and data management.

The consensus algorithm is key to ensuring the consistency of ledger data among the nodes of the blockchain platform. Common distributed system consistency algorithms include PoW, PoS, Paxos, Raft, PBFT, etc. PoW relies on the computational power of machines to obtain the right to record the ledger, which is resource-intensive and has weak regulatory capabilities. The consensus for each transaction requires the participation of the entire network in computation, making it unsuitable for the regulatory and performance requirements of consortium chains. The main idea of PoS is that the difficulty of obtaining the right to record the ledger is inversely proportional to the amount of equity held, which performs better than PoW but still has weak regulatory capabilities. Paxos and Raft are mature solutions for consistency in traditional distributed systems, with high performance and low resource consumption, but they do not tolerate Byzantine nodes. The PBFT algorithm is similar to the processing flow of the Paxos algorithm, being a consensus mechanism that allows a minority to follow the majority through permissioned voting. This algorithm can tolerate Byzantine errors and allows the participation of strongly regulated nodes, offering high performance suitable for enterprise-level platform development. Currently, mainstream enterprise-level blockchain solutions like Fabric and Hyperchain provide implementations of PBFT. However, the native PBFT algorithm is not sufficiently reliable and flexible. The Hyperchain platform enhances reliability and flexibility, designing and implementing an improved algorithm for PBFT, namely RBFT.

1. Overview of RBFT

   The consensus module of Hyperchain adopts a pluggable modular design, allowing the selection and configuration of different consensus algorithms based on various business scenario needs, currently supporting the improved PBFT algorithm RBFT. Hyperchain optimizes the execution process of PBFT, adding mechanisms for active recovery and dynamic addition and deletion of nodes, greatly improving the reliability and performance of traditional PBFT. RBFT can control transaction latency within 300 ms and can support transaction volumes of tens of thousands per second, providing stable and high-performance algorithm guarantees for blockchain commercial applications. Below is a detailed explanation of the core algorithm of RBFT.

2. Regular Process of RBFT

   The regular process of RBFT ensures that all nodes in the blockchain process transactions from clients in the same order. RBFT has the same fault tolerance as PBFT, requiring at least 3f+1 nodes to tolerate f Byzantine errors. The example in Figure 6.3 shows the minimum number of cluster nodes, where the value of f is 1. In the figure, the Primary is the main node dynamically elected from the blockchain nodes, responsible for sorting and packaging client messages, while the Replica nodes are backup nodes that execute the same transaction logic as the Primary node. The Replica nodes can participate in the election of a new Primary node if the Primary node fails.

   The consensus of RBFT retains the original three-phase processing flow of PBFT (PrePrepare, Prepare, Commit), but intersperses an important transaction verification step.

The regular consensus process of the RBFT algorithm is as follows.

(1) The client sends the transaction to any node in the blockchain.

(2) The Replica node receives the transaction and forwards it to the Primary node, which can also directly receive transaction messages.

(3) The Primary packages the received transactions into a batch for verification, excluding any illegal transactions.

(4) The Primary constructs a PrePrepare message with the verified batch and broadcasts it to other nodes, broadcasting only the hash values of the batch transactions.

(5) The Replica receives the PrePrepare message from the Primary and constructs a Prepare message to send to other Replica nodes, indicating that this node has received the PrePrepare message from the Primary and acknowledges the batch sorting of the Primary.

(6) After receiving Prepare messages from 2f nodes, the Replica verifies the legality of the batch messages. Upon successful verification, it broadcasts a Commit message to other nodes, indicating its agreement with the Primary's verification results.

(7) The Replica nodes execute the transactions in the batch after receiving 2f+1 Commit messages and verify the execution results with the Primary node. Upon successful verification, the results will be written to the local ledger, and a checkpoint will be performed to validate the results, with checkpoint rules being configurable.

From the above regular process of RBFT, it can be seen that RBFT intersperses the transaction verification process throughout the consensus algorithm, achieving consensus on the results written to the block. First, after the Primary node receives the transaction, it verifies it, ensuring that the platform's computing power is not consumed by illegal transactions, allowing Replica nodes to efficiently handle Byzantine failures of the Primary node. Secondly, after the Replica nodes receive 2f Prepare messages, they verify the Primary node's verification results. If the results do not pass verification, a ViewChange message will be triggered, further ensuring the system's security.

In the PBFT algorithm, the participating nodes in the consensus can be divided into primary nodes (Primary) and secondary nodes (Replica). The secondary nodes will forward the transactions they receive to the primary node, whose most important function is to package all received transactions according to a certain strategy into blocks, allowing all nodes to participate in consensus verification. A natural question arises: if the primary node crashes, encounters a system error, or is compromised (i.e., becomes a Byzantine node), how can other secondary nodes promptly detect the primary node's anomaly and elect a new primary node to continue consensus? This is a critical issue to ensure the stability of BFT-type algorithms.

Both PBFT and RBFT introduce the concept of view (View), where each time a primary node is changed, the view is also switched. The view change (ViewChange) mechanism is key to ensuring the robustness of the entire consensus algorithm.

Currently, there are three detectable scenarios of Byzantine behavior from the primary node:

(1) The node stops working and no longer sends any messages;

(2) The node sends incorrect messages, which may include messages with incorrect content or malicious transactions. It is important to note that the message types here can be either batch or functional messages used for view changes;

(3) The node masquerades as a normal node and sends correct messages.

For scenario (1), the nullRequest mechanism ensures that a properly functioning primary node will send a nullRequest to all secondary nodes when no transactions occur, confirming the validity of this situation. If a secondary node does not receive the primary node's nullRequest within the specified time, it will trigger a view change behavior to elect a new primary node.

For scenario (2), when secondary nodes receive messages from the primary node, they will use the verification mechanism to check the content. If they find that the primary node's transactions contain transactions that do not conform to the required format or malicious transactions, they will initiate a view change to elect a new primary node.

For scenario (3), there is no need for concern. An extreme case is that if a Byzantine node behaves like a normal node, it can be considered not a Byzantine node, with the entire system ensuring the correctness of the results.

When secondary nodes detect any of the above anomalies from the primary node or receive view change messages from other f+1 nodes, they will broadcast view change messages across the network. When the new primary node receives N-f view change messages, it will send a NewView message. After receiving the NewView message, the secondary nodes will verify and compare the messages, and once the view change information is verified to be the same, they will officially change the view and print a FinishVC message, thus completing the entire view change process, as shown in Figure 6.5 (where ViewChange represents the view change, Primary represents the primary node, and Replica represents the secondary nodes).

During the operation of the blockchain network, due to network jitter, sudden power outages, disk failures, etc., some nodes may fall behind the majority of nodes in execution speed or crash directly. In such scenarios, nodes need to automatically recover and synchronize their ledgers to the current latest state of the blockchain to participate in subsequent transaction execution. To address this type of data recovery work, the RBFT algorithm provides a dynamic data automatic recovery mechanism.

The automatic recovery mechanism of RBFT actively requests block and consensus block information to quickly synchronize the storage of its own nodes with the latest storage state in the system. The automatic recovery mechanism greatly enhances the availability of the entire blockchain system. For convenience in recovery, RBFT sets checkpoints for the executed data, which are based on the results of network-wide consensus. This ensures that the data before each node's checkpoint is consistent. In addition to checkpoints, some data is stored as the current local execution progress that has not yet reached consensus. Thus, during the recovery process, the first step is to synchronize the local checkpoint with the checkpoints of other normal service nodes in the blockchain. The second step is to recover the data beyond the checkpoint. Figure 6.6 illustrates the concept of checkpoints, with the left side representing the checkpoint portion and the right side representing the current execution portion beyond the checkpoint. Figure 6.7 shows the basic processing flow of the automatic recovery mechanism.

In consortium blockchain scenarios, due to the expansion of the alliance or the exit of certain members, the consortium blockchain needs to support dynamic entry and exit services for members, while traditional PBFT algorithms do not support dynamic addition and deletion of nodes. To facilitate the control of member admission and exit, RBFT adds the capability to dynamically add and delete nodes without downtime in the PBFT algorithm. As shown in Figure 6.8, RBFT adds the algorithm processing flow for new nodes joining.

New nodes need to obtain certificates issued by a certificate authority, then send requests to all nodes in the alliance. After confirmation and agreement from each node, a network-wide broadcast will be made to other nodes in the alliance. When a node receives 2f+1 consent replies to join, it will establish a connection with the new node. Furthermore, when the new node connects with N-f (where N is the total number of nodes in the blockchain alliance) nodes, it can execute the active recovery algorithm to synchronize the latest state of the blockchain alliance members. Next, the new node requests to join the regular consensus process from the primary node. Finally, after the primary node confirms the new node's request, it will define which block number needs to change the total number of nodes N for consensus (ensuring that the new node's joining does not affect the original consensus, as the joining of the new node will change the network-wide consensus N, meaning that the value of f may change).

The dynamic deletion of RBFT nodes follows a similar process to that of dynamic addition, with the main processing functions illustrated in Figure 6.9, and the main process is as follows.

(1) The exiting node needs to call an RPC request to obtain its own hash value, then initiate an exit request to all nodes in the network.

(2) The administrator of the node receiving the deletion request confirms and agrees to the node's exit, then broadcasts a DelNode message to the entire network, indicating their agreement to the node's request to exit the blockchain consensus.

(3) When existing nodes receive 2f+1 DelNode messages, they update their connection information, disconnecting from the node requesting to exit. After disconnecting, they broadcast an AgreeUpdateN message to the entire network, indicating that the entire system should pause transaction processing to prepare for updating the total number of nodes participating in consensus N and view.

(4) When a node receives 2f+1 AgreeUpdateN messages, it updates the node system status.

Dynamic Node Exit Function Call

Thus, the requesting exit node officially exits the blockchain system.

This concludes the main algorithm flow of the improved consensus algorithm RBFT of Hyperchain. By adding verification steps in the regular consensus process, an automatic recovery mechanism for nodes, and functions for dynamic addition and deletion of nodes, RBFT is more stable, flexible, and efficient than the traditional PBFT algorithm, better meeting the production environment needs of enterprise-level consortium chains.

P2P networks serve as the channel for consensus and information transmission between nodes, forming the network foundation of Hyperchain.

The network communication module mainly consists of three sub-modules: Node, Peer, and encrypted transmission. The Node sub-module primarily provides gRPC calling services for this node, acting as a server. The Peer sub-module mainly serves as the client when this node requests other nodes. The encryption module uses the ECDH key agreement algorithm to generate a key recognized only between two nodes, and then uses an enhanced version of AES symmetric encryption to encrypt the data transmitted between nodes, ensuring data transmission security.

• The main architectural design of Hyperchain separates Peer and Node, with Peer providing message sending interfaces for upper-level modules. Node is primarily responsible for receiving messages and forwarding them to the upper layer: receiving information from each node and acting as a message distribution router, posting various messages to each layer. Both Peer and Node are managed through gRPCManager, controlling communication and distribution across layers, exposing interfaces for Peer while truly controlling the states of nodes. The P2P module also implements mutual separation of modules, controlled by a control layer, with each sub-module performing its designated function.

• Node Types

  Hyperchain nodes are divided into two categories: verification nodes (VP) and non-verification nodes (NVP):

  • Verification nodes refer to nodes participating in consensus verification within the blockchain network;

  • Non-verification nodes do not participate in consensus verification within the blockchain network, only participating in bookkeeping.

  NVPs are mainly used for transaction forwarding and disaster recovery, not processing transactions themselves or participating in consensus, thus relying on connected VPs to ensure final consistency with the entire network state. However, NVPs can receive transactions and forward the received transactions to connected VPs for processing.

  VPs do not actively connect to NVPs, so when a VP restarts, all connected NVPs will disconnect and will not automatically reconnect, requiring manual connection. NVPs have a complete state recovery mechanism, allowing timely synchronization after just starting up or due to other reasons causing state lag.

  Communication between VPs is established through gRPC remote calling services, forming a P2P network, where the gRPC service uses protobuf3 for data serialization and deserialization, ensuring data integrity and efficient and secure transmission.

• Flow Control Mechanism

  The underlying platform can control the traffic allowed to enter the blockchain system based on business needs. When the system traffic exceeds the set limit, excess traffic will be rejected. This prevents the processing time of nodes from being occupied by a large number of useless transaction requests, delaying other transactions, thus ensuring system security while meeting business requirements.

  Flow configuration for contract transactions and ordinary transactions can be done on demand through configuration files. Configuration items and information are as shown in the table.

Smart contracts are segments of code that can be automatically executed and deployed on the blockchain. In a broad sense, smart contracts include programming languages, compilers, virtual machines, events, state machines, fault tolerance mechanisms, etc. Among these, the programming language and the execution engine of smart contracts, i.e., the virtual machine, have a significant impact on application development. The virtual machine is encapsulated as a sandbox, completely isolating the entire execution environment. Smart contracts executed within the virtual machine cannot access network, file systems, or other system resources such as threads. Contracts can only make limited calls to each other.

Currently, there are three typical implementations of smart contract writing and execution environments:

(1) IBM's Hyperledger Fabric project uses Docker as the execution environment for smart contracts;

(2) The R3 Corda project uses JVM as the underlying execution environment for contracts;

(3) The Ethereum project uses Solidity for smart contract writing and executes it using an embedded Solidity virtual machine.

1. Smart Contract Execution Engine

   Since smart contracts are essentially executable script programs, there is a possibility of errors, which can even lead to serious issues or chain reactions. Therefore, the security of the smart contract execution engine is crucial for the security of enterprise blockchains.

   Solidity is a high-level programming language designed specifically for writing smart contracts, with syntax similar to JavaScript. It is very easy to write, is a Turing-complete language, and importantly, it is only used to implement the logical functions of contracts, providing no access to system resources (such as opening files or accessing underlying operating system resources), thus ensuring that smart contracts written in Solidity can and can only run in a sandbox independent of the operating system, without manipulating any system resources. In contrast, Fabric's Docker-based virtual machine does not impose special restrictions on the language, thus cannot guarantee complete security.

   Compared to Docker and JVM, the Solidity language and its smart contract execution engine have a smaller program size, finer control over resources, and can maximize the utilization of the open-source community's accumulation of technology and experience in smart contracts, improving the reusability of smart contracts. Therefore, the Hyperchain platform chooses Solidity for the implementation of smart contracts and has developed an efficient smart contract execution engine called HyperVM that supports Solidity execution.

   HyperVM is a pluggable smart contract engine framework of Hyperchain, allowing different smart contract execution engines to be integrated. Currently, it has implemented HyperEVM, which is compatible with Solidity, and HyperJVM and HVM, which support Java. Future integrations of other virtual machines such as WVM and JSVM will continue.

   • HyperEVM

   HyperEVM is a deeply restructured virtual machine designed to maximize the utilization of the open-source community's technology and experience in smart contracts, enhancing the reusability of smart contracts while being fully compatible with smart contracts developed on EVM. HyperEVM optimizes the performance of the smart contract virtual machine while maintaining compatibility with the Solidity development language, preserving the sandbox security model of the Ethereum virtual machine, implementing sufficient fault tolerance mechanisms, and performing system-level optimizations. Combined with environmental isolation, it ensures that contracts execute safely within a limited time, approaching the efficiency of binary native code.

   • HyperJVM

   HyperJVM provides a high-performance and secure execution sandbox for native Java smart contracts through microservice architecture design and multiple security check mechanisms. HyperJVM has the following advantages:

   • Supports Java language for smart contract development, significantly lowering the development threshold;

   • Supports complete smart contract lifecycle management, including contract deployment, upgrades, freezing, etc.;

   • Supports rich ledger operations, KV interfaces, batch processing, range queries, and columnar data operations;

   • Supports complex contract logic development and authorized cross-contract calls;

   • Supports custom event listeners for contracts.

   • HVM HVM (Hyperchain virtual machine) is a lightweight Java smart contract runtime integrated into Hyperchain. It provides a sandbox environment for executing smart contracts written in Java and can ensure its security through various means. On HVM, users can efficiently write simple yet powerful smart contracts. HVM has the following advantages:

   • Comprehensive support for contract lifecycle;

   • A more secure execution environment for Java language smart contracts;

   • A more efficient state space operation mechanism;

   • A more user-friendly programming interface solution.

• Design Principles of HyperVM

  The design of HyperVM is shown in Figure 6.11, with the main components including a compiler for contract compilation, an optimizer for code execution optimization, an interpreter for executing contract bytecode, a security module for controlling the security of the contract execution engine, and a state management module for interaction between the virtual machine and the ledger.

This is a typical flowchart for executing transactions in HyperVM. After executing a transaction, HyperVM returns an execution result, which is stored in a variable called transaction receipt. Subsequently, the platform client can query the transaction result based on the transaction hash.

The specific execution process of HyperVM is as follows.

(1) HyperVM receives the transaction passed from the upper layer and performs preliminary verification.

(2) It determines the type of the transaction; if it is a contract deployment, it executes step (3), otherwise it executes step (4).

(3) HyperVM creates a new contract account to store the contract address and the code after contract compilation.

(4) HyperVM parses the transaction parameters and other information in the transaction and calls its execution engine to execute the corresponding smart contract bytecode.

(5) After the instruction execution is completed, HyperVM checks whether it has halted; if not halted, it jumps to step (2), otherwise it executes step (6).

(6) It checks whether the halt state of HyperVM is normal; if normal, it ends execution, otherwise it executes step (7).

(7) It performs an Undo operation, rolling back the state to before the execution of this transaction, ending the transaction.

The instruction set module in Figure 6.12 is the core of the HyperVM execution module. There are two implementations for executing instructions: one based on bytecode execution and a more complex and efficient Just-in-time compilation (JIT).

The bytecode execution method is relatively simple; the virtual machine implemented by HyperVM will have an instruction execution unit. This unit will continuously attempt to execute the instruction set, and if it does not complete within a specified time, the virtual machine will interrupt the computation logic and return a timeout error message to prevent the execution of malicious code in smart contracts.

The JIT execution method is relatively complex. Just-in-time compilation, also known as dynamic compilation, is a form of dynamic compilation that improves program execution efficiency. Programs typically run in two ways: static compilation and dynamic interpretation. The former means that the program is entirely translated into machine code before execution, while the latter means that it is translated while being executed. The JIT compiler combines static compilation and dynamic interpretation, compiling source code line by line while caching the translated code. This approach reduces performance loss. The code compiled in JIT mode can handle delayed binding and enhance security. The main steps of executing smart contracts in JIT mode include:

(1) Encapsulating all information related to the smart contract in a contract object, then using the hash value of that code to check whether the contract object has been stored and compiled. The contract object has four common states: contract unknown, contract compiled, contract ready for JIT execution, and contract error.

(2) If the contract state is ready for JIT execution, HyperVM will choose the JIT executor to execute the contract. During execution, the virtual machine will further compile the compiled smart contract into machine code and deeply optimize instructions such as push and jump.

(3) If the contract state is unknown, HyperVM first checks whether the virtual machine is forced to execute JIT. If so, it compiles in sequence and executes using JIT instructions. Otherwise, it starts a separate thread for compilation while the current program still uses ordinary bytecode compilation. When the virtual machine encounters the same encoded contract again in the next execution process, it will directly choose the optimized contract. This way, the instruction set of the contract has been optimized, significantly improving the efficiency of contract execution and deployment.

The blockchain is essentially a distributed ledger system, so the design of the ledger system in the blockchain platform is crucial. The ledger design of Hyperchain mainly includes three parts: first, customer transaction information is stored using a chain structure in the blockchain, ensuring that customer transactions are difficult to tamper with and traceable; second, an account system model is used to maintain the state of the blockchain system, as shown in the contract state portion of Figure 6.13; finally, to quickly determine whether key information such as ledger information and transaction information exists, the ledger uses an improved version of the Merkle tree for related information storage.

The block structure is divided into two parts: the block header and the transaction list. The block header records some fixed-size block metadata information, while the transaction list records all transaction information included in that block. The specific definitions of the corresponding storage contents in the block are as shown in the table.

The block header undergoes SHA256 hashing to generate a hash value, which can be used as a digital fingerprint uniquely identifying that block in the blockchain. Additionally, the block header information references the hash value of the previously generated block, meaning that each block contains the hash value of its parent block. Through this method, all blocks are linked into a vertical chain structure, allowing for iterative access to parent blocks, ultimately tracing back to the genesis block (the first block) of the blockchain.

Due to this special chain structure design, any changes to the parent block will also change the hash value of the parent block, forcing the "parent block hash value" field in the child block to change, resulting in a change in the generated child block hash value. Hyperchain nodes compare the latest block hashes at every checkpoint; if the latest block hash maintained locally matches the latest block hash maintained by the blockchain network, it can be confirmed that the locally maintained blockchain information is legitimate; otherwise, it indicates that the local node has become a "Byzantine node."

Definition of Hyperchain Block Header

Definition of Transaction Structure

In addition to maintaining blockchain data, the Hyperchain system also maintains the current state information of the system. Unlike the Bitcoin system, which uses the UTXO model, Hyperchain adopts an account model to represent system states.

When a Hyperchain node receives a "pending" transaction, it is first handed over to the execution module for execution. After the transaction execution is completed, it will change the state of the relevant contract account. For example, if user A initiates a transaction calling the deployed contract B, the variable value b in contract B changes from 0 to 1 and is persisted in the contract state.

Each transaction execution signifies a transfer of the contract account state, representing a state transfer of the system ledger. Therefore, Hyperchain can also be regarded as a state transfer system.

In the Hyperchain ledger, the state information of all contracts on the chain is recorded. The metadata of contract states includes the following fields, as shown in the table.

In addition to the above metadata, contract accounts also have two data fields: executable code and variable storage space. The executable code is a set of instructions encoded as a byte array, and each invocation of the contract is essentially the execution of this executable code. The variables defined in the contract are stored in the storage space belonging to the contract. The schematic diagram of the contract account storage space is shown in the figure.

The storage space is logically composed of a contiguous area of storage units (to save disk storage space, empty storage units are not written to disk). Each storage unit is called a slot, with a size of 32 bytes. Contract variables obtain their index addresses in the storage space during the contract compilation phase, and the contents are stored in the corresponding slots.

A simplified diagram of contract state data is shown in the figure.

After processing the transactions included in the block sequentially, the contract account transitions from its original state to a new state. To quickly generate a hash value that identifies the new state of all contract accounts, the Hyperchain system introduces the Merkle tree for hash calculations. Next, we will briefly introduce the structure and function of the Merkle tree.

The Merkle tree is a hash binary tree, a data structure used for quickly summarizing and verifying the integrity of large-scale data. This binary tree contains cryptographic hash values. In the Bitcoin network, the Merkle tree is used to summarize all transactions in a block while generating a digital fingerprint for the entire transaction set, providing an efficient way to verify whether a block contains a specific transaction. However, traditional Merkle trees perform poorly when facing high-frequency massive data, and their computational performance cannot meet the needs of consortium chains. Therefore, Hyperchain has designed a HyperMerkle tree that combines the advantages of both Merkle trees and hash tables, greatly improving the speed of ledger hash calculations.

Traditional Merkle trees are constructed from the bottom up, as shown in Figure 6.17, starting with four data blocks L1, L2, L3, and L4 to build the Merkle tree. First, the data of these four data blocks is hashed, and the hash values are stored in the corresponding leaf nodes. These leaf nodes are Hash0-0, Hash0-1, Hash1-0, and Hash1-1.

After assigning values to the lowest layer leaf nodes, the values of non-leaf nodes are calculated by concatenating the hash values of adjacent leaf nodes and using this as input to compute the hash, resulting in the hash value of the parent node of this pair of leaf nodes.

Continuing similar operations until only one node remains at the top, which is the Merkle root. The hash value of the root node represents the identifier for this batch of data blocks.

This traditional Merkle tree is only suitable for scenarios like the Bitcoin system for hashing batch transaction data and cannot meet the rapid calculation needs of ledger hashes in consortium chains. Therefore, Hyperchain has redesigned the HyperMerkle tree, incorporating characteristics of hash tables.

The HyperMerkle tree is a multi-way tree built on a hash table, where each storage unit of the hash table is a leaf node of the HyperMerkle tree, and all leaf nodes are called n layer nodes. Several adjacent leaf nodes are summarized into a parent node, and the resulting parent node collection is called n-1 layer nodes. This recursive operation continues until only one node remains at the top, which is the root node of the HyperMerkle tree. Each parent node maintains a list of child node hash values. The structure of the HyperMerkle tree is shown in the figure.

A single computation process of a HyperMerkle tree is as follows.

(1) Each element in the input data set is hashed to different positions based on its key value, and in case of hash collisions, the chaining method is used to handle them.

(2) For each modified leaf node, the hash is recalculated, with the input being the content of the leaf node; after the calculation, the result is written into the hash list of the corresponding parent node's child nodes.

(3) For each modified n-1 layer node, the hash is recalculated, with the input being the hash list of the child nodes (the hash values of child nodes not involved in this calculation use the values from the last calculation); after the calculation, the result is written into the hash list of the corresponding parent node's child nodes.

(4) Repeat step (3) until reaching the 1 layer node. The 1 layer node is also called the root node, and the current hash value of the ledger is represented by the hash value of the root node.

(5) Persist the content of all nodes recalculated in this process.

A HyperMerkle tree maintains a batch of data, and each time it is modified, only the modified parts are recalculated for hashing, significantly improving computational efficiency.

In Hyperchain, the HyperMerkle tree specifically performs hash calculations for two parts: the hash calculation of the contract account storage space and the hash calculation of the contract account set.

For each contract account, the content of the storage space is the input for the HyperMerkle tree, and the output is stored in the metadata of the contract account; for the contract account set, the content of each contract is the input for the HyperMerkle tree, and the output is stored in the block, serving as the identifier for the current state of the contract account set.

Enterprise-level blockchain platforms are also known as consortium chains. The term "consortium chain" has two layers of meaning: first, it is a blockchain; second, it is characterized by a limited membership alliance. Therefore, in designing the security mechanisms for enterprise blockchain, it is necessary to consider both the trust issues among members faced by traditional blockchains and the security management mechanisms for member admission and exit. To this end, the Hyperchain platform proposes a multi-level encryption mechanism based on cryptography, using secure encryption algorithms to comprehensively encrypt user information at multiple levels, such as transaction networks, transaction parties, and transaction entities, and also proposes a CA-based permission control mechanism. Additionally, to meet the high scalability and availability requirements of enterprise-level blockchain platforms, the platform has launched data management, message subscription, and other functions.

To enhance data security and privacy protection and support flexible and independent business scenarios, Hyperchain implements partition consensus for internal transactions in the blockchain network through a Namespace mechanism. Users can categorize business transactions according to Namespace, with nodes in the same Hyperchain consortium blockchain network forming sub-networks based on the businesses they participate in, achieving physical isolation between different businesses like boxes, ensuring that transactions in each space do not interfere with each other.

A single Hyperchain node can choose to participate in one or more Namespaces based on its business needs. As shown in Figure 6.19, Node1, Node2, Node4, and Node5 form namespace1, while Node2, Node3, Node5, and Node6 form namespace2. Here, Node1 only participates in namespace1, while Node2 participates in both namespaces. The entry and exit of nodes in the Namespace are controlled through CA certification.

The verification, consensus, storage, and transmission of transactions with specific Namespace information occur only among nodes participating in that Namespace, allowing for parallel execution of transactions between different Namespaces. For example, Node1 can only participate in the verification of transactions in namespace1 and maintain the corresponding ledger, while Node2 can participate in transaction execution and ledger maintenance for both namespace1 and namespace2, but the ledgers in Node2 for namespace1 and namespace2 are isolated and invisible to each other.

To provide a more granular privacy protection solution for consortium chains, Hyperchain mainly implements the notarization of privacy transactions, as well as the deployment, invocation, and upgrading of privacy contracts.

Hyperchain supports privacy protection at the transaction granularity, specifying the relevant parties of the transaction when sending it. The transaction details are stored only with the relevant parties, and the hash of the privacy transaction is stored in the public ledger after consensus across the network, ensuring effective isolation of private data while allowing verification of the authenticity of the privacy transaction.

The diagram illustrates the processes and differences between privacy transactions and ordinary consensus transactions.

• Encrypted On-chain / Hash On-chain

  For certain highly sensitive information that does not have a strong correlation with transactions and ledgers, data can be symmetrically encrypted before being put on-chain, protecting private data. Alternatively, original data and files can be stored off-chain, with only their digital summaries saved on-chain via hashing, addressing both data capacity and sensitivity issues.

• Contract Access Control

  Contract coders can use smart contracts and access control policies to restrict access to data based on roles and users, customizing different contract function access permissions for nodes, roles, and users within the contract. Contract coders can set permission controls for some high-privilege functions in the contract, allowing only fixed address callers to invoke those functions, thus achieving access permission control.

Hyperchain adopts a pluggable multi-level encryption mechanism, applying different encryption strategies to data, users, and communication connections involved in the complete lifecycle of the business, allowing enterprise users to choose encryption methods according to specific business scenarios while ensuring system security and efficiency.

1. Hash Algorithms

   Hash algorithms can transform inputs of any length into fixed-length outputs (hash values), with the hash value's space typically much smaller than that of the input, and hash functions exhibit irreversibility, meaning the original content cannot be inferred from the hash value.

• Hash algorithms are widely used in the Hyperchain platform, for example, in transaction summaries, contract addresses, user addresses, etc. Hyperchain provides pluggable hash algorithm options with varying security levels. The security levels range from low to high, including SHA2-256, SHA2-384, etc. These hash algorithms can generate controllable, irreversible digital fingerprints for messages, ensuring data security on the platform.

• ECDSA-based Transaction Signatures

  To prevent transaction tampering, Hyperchain employs the mature Elliptic Curve Digital Signature Algorithm (ECDSA) for transaction signing, ensuring identity security on the platform. The signing process is illustrated in the diagram.

The security of the elliptic curve cryptosystem is based on the difficulty of solving the elliptic curve discrete logarithm problem. Since there is no sub-exponential time solution to this problem, the unit bit strength of elliptic curve cryptography (ECC) is much higher than that of traditional discrete logarithm systems, resulting in smaller computational parameters, shorter keys, faster computation speeds, and shorter signatures.

Hyperchain implements the digital signature algorithm using secp256k1 and r1 curves, allowing users to choose and sign transactions on the platform, ensuring the correctness and integrity of transactions. The platform also supports using this algorithm for message signing and verification between nodes, ensuring the correctness and integrity of message communication between nodes. Considering the complex calculations involved in digital signatures and signature verification, Hyperchain adopts the elliptic curve encryption standard encapsulated in C language, achieving better performance in signing and verification.

• ECDH-based Key Agreement

  During network communication, using session keys to encrypt transmitted information can prevent hackers from eavesdropping on confidential messages for fraudulent activities. Hyperchain implements the Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol to establish session keys and mutual authentication between users in the network, ensuring that both parties can create a shared confidential protocol over insecure public media without exchanging any private information in advance.

In Hyperchain, the ECDH is first used to achieve the exchange of shared keys, as shown in Figure 6.22. The ECDH algorithm establishes a secure channel for key agreement based on secure identity authentication. Any organization intercepting the exchange can replicate the public parameters and the public keys of both parties, but cannot generate a shared confidential protocol from the publicly shared values. After negotiating the shared public key, symmetric encryption is used to greatly enhance communication efficiency.

• ECDH key agreement plays an important role in identity authentication and transaction security. The secure communication channel established through key agreement enables secure information exchange, ensuring communication security on the platform. The secure communication channel established based on secure identity authentication can confirm the legitimacy of both parties' identities, and symmetric encryption can significantly improve communication efficiency, as it eliminates the need for identity verification with each communication.

• Ciphertext Transmission Based on Symmetric Encryption

  After the communication parties negotiate a confidential shared key, Hyperchain ensures ciphertext transmission between nodes based on symmetric encryption algorithms, making it more challenging to crack the transmitted content computationally, thereby ensuring high security for message transmission on the platform.

  Symmetric encryption, also known as conventional encryption, private key encryption, or single-key encryption, consists of five components.

  • Plaintext: The original message or data, serving as input to the algorithm.

  • Encryption algorithm: The encryption algorithm performs various substitutions and transformations on the plaintext.

  • Secret key: The algorithm's input, which the algorithm relies on for substitution and transformation.

  • Ciphertext: The scrambled message, serving as the output of the encryption algorithm, depending on the plaintext and secret key. For a given message, two different secret keys will produce different ciphertexts.

  • Decryption algorithm: Essentially the inverse operation of the encryption algorithm. It uses the ciphertext and secret key to produce the original plaintext. Hyperchain supports the AES (Advanced Encryption Standard) algorithm, which is an iterative symmetric key block cipher based on permutation and substitution operations. It can use 128-bit, 192-bit, and 256-bit keys, encrypting and decrypting data in 128-bit (16-byte) blocks.

• Transport Layer Security

  In addition to the aforementioned key agreement and ciphertext transmission, Hyperchain nodes also ensure communication security through Transport Layer Security (TLS). TLS can guarantee the security of information transmission at the transport layer and is currently a widely used standard for network transmission implementation, adopted in almost all secure network transmissions, such as Google, Taobao, Baidu, WeChat, etc.

  Transport layer security is a default feature of Hyperchain, using certificates issued by TLSCA for secure communication. This means that during network transmission, it is necessary to verify the security of the transport layer security protocol certificate. If the verification passes, normal network communication can proceed; otherwise, network communication cannot occur. This option is configurable.

• National Cryptography Support

  Compared to other blockchain platforms, Hyperchain has a significant advantage in cryptographic algorithms: it fully supports the integration of national cryptographic algorithms. Currently, Hyperchain has integrated national cryptographic algorithms SM2, SM3, and SM4, complying with SSL VPN technical specifications.

  Among them, SSL VPN includes various network communication protocols, replacing OpenSSL; SM2 is a public key cryptographic algorithm standard based on elliptic curve cryptography, including digital signatures, key exchanges, and public key encryption, replacing international algorithms such as RSA, Diffie-Hellman, ECDSA, and ECDH; SM3 is a cryptographic hash algorithm, replacing international hash algorithms such as MD5, SHA-1, and SHA-256; SM4 is a block cipher algorithm, replacing international symmetric encryption algorithms such as AES, DES, and 3DES.

Hyperchain mainly conducts identity authentication through a CA system, adopting a simplified certificate issuance system, as shown in the diagram.

Root.ca (root certificate authority) represents the trust anchor in the PKI system. The root CA is the top-level CA in the PKI hierarchy, responsible for issuing certificate authentication authorities and role certificate admission authentication authorities.

ECert (enrollment certificate) is the admission certificate, and ECA (enrollment certificate authority) is the authority that issues admission certificates, which can issue node admission certificates downwards. Only nodes holding ECert can interact with Hyperchain services on the chain; otherwise, they cannot join the corresponding Namespace.

Additionally, Hyperchain's ECert design has two implementations. Institutions holding ECert1 not only have the right to interact with Hyperchain services on the chain but can also issue TCert (transaction certificate) transaction certificates downwards. Transaction certificates are used to achieve pseudo-anonymous transactions, which must be carried by customers when initiating transactions. The client will use the private key matching the TCert to encrypt the transaction. TCert can be applied for online, issued by various nodes, and each transaction is signed with a new TCert, achieving relative anonymity for each transaction while allowing the issuer to review it.

RCA (role certificate authority) is the authority that issues role certificates. This authority has the power to issue RCert (role certificate). RCert is mainly used to distinguish between verification nodes and non-verification nodes in the blockchain. Only those with RCert are considered verification nodes in the blockchain and participate in consensus among blockchain nodes. Like TCert, RCert only serves as an identity proof certificate and cannot issue certificates downwards.

Hyperchain's certificates comply with the ITU-T X.509 international standard, containing only public key information without private key information, making them publicly available.

At the same time, the Hyperchain platform integrates CFCA (China Financial Certification Authority) to implement digital certificate management functions, meeting the needs of institutions such as banks or financial companies that have high security and authority requirements for certificate systems. The CFCA certificate system is shown in Figure 6.24, providing two service modes: CRL mode and RA mode. CRL is a managed RA service for issuing and verifying certificates through CFCA's managed RA service, while the RA mode is a locally deployed privatized RA service for issuing and verifying certificates. Currently, both modes have been integrated into the platform.

• The CFCA certificate system can be applied to verify the certificates and validity of Hyperchain node verification SDK. Users can configure the purchased certificates in the SDK, while Hyperchain nodes need to configure the verification certificate chain provided by CFCA. When the SDK sends a certificate to the node, Hyperchain will verify the certificate and its validity, while also needing to obtain the CRL through a network request to verify whether the certificate has been blacklisted.

  In terms of JavaSDK, when sending SDKCert, the SDK selects the corresponding signing algorithm for the transmitted content based on the CFCA feature switch. The CFCA feature switch of the SDK and Hyperchain needs to remain consistent, either both enabled or both disabled.

• Certificate Management

  Hyperchain provides a supporting tool for certificate management called certgen, mainly used to generate and manage related CA certificates and digital certificates, with functions including certificate issuance, public/private key generation, and certificate verification.

  • Certificate Issuance

    Before starting the node, a pair of public and private keys must be generated. When the node starts, each node first generates a self-signed certificate based on the public key and generates a root certificate from it.

    When issuing sub-certificates, a specified type of sub-certificate (ECert, RCert, TCert, and SDKCert) can be generated from the root certificate of this node, or the user can provide the public key to the issuer, who will then issue the sub-certificate.

  • Node Admission

    New nodes first send admission requests to each node. All VP nodes on the chain query the CA public key certificate of the applying node based on its handshake information and use the public key certificate for signature verification. They then vote on whether to allow the node holding that CA certificate to join. If allowed, they will issue an ECert certificate for this node, and the new node will also issue an ECert certificate to the nodes it applied to.

  • Certificate Verification

    Certgen provides certificate verification services, checking whether the certificate was issued by a CA certificate, whether the signature is valid, and whether it is a CA certificate capable of issuing sub-certificates.

  • Certificate Revocation

    Certificate revocation generally occurs when a user's personal identity information changes, a private key is lost, leaked, or suspected of being leaked. The general steps are: first, the certificate user submits a revocation request to the CA, and then the CA places this certificate on a publicly published certificate revocation list, which includes all digital certificates that are within their validity period but have been revoked.

    Additionally, digital certificates may also be revoked before their expiration date. For example, in some special cases: if the certificate user improperly uses the certificate and the CA discovers it, or if government agencies or other authoritative departments request the certificate to be revoked for some reason.

• Key Management

  For user public/private key pairs, Hyperchain provides two key management modes: one is to entrust the private key to banks and third-party institutions for custody, and the other is for users to keep it themselves. Both management modes are equipped with corresponding key recovery solutions.

  (1) When issuing the user's private key, it is split into two parts and encrypted separately, with one part entrusted to the bank and the other to a trusted third-party institution, ensuring that no single institution can independently steal the user's private key to sign transactions.

  If the user loses their private key, the institution will conduct identity verification offline. Once verified, the private key recovery process will be initiated. The user will obtain parts of the private key from the two custodial institutions, decrypt and piece them together, ultimately obtaining the complete private key. This private key will be identical to the user's original private key and can continue to be used for signing transactions.

  (2) Users keep the complete public/private key pair without backup.

  If the user's private key is lost, it cannot be recovered. The bank will generate a new private key for the user and call a super administrator smart contract in the background to transfer the user's original assets to the new public key address. This solution relies on the following operations.

  • Based on the existing business contract, a separate super administrator smart contract is designed (each bank has a separate administrator smart contract that can only transfer assets for its own customers).

  • The relevant contract for the user's assets must record the public key address of the user's opening bank.

  • When the user's key pair is generated, the corresponding public key address is stored in the bank's database, forming a mapping relationship (user account/identity information → public key address), where the user's identity information can be verified offline.

  • After the user loses their private key, they initiate a private key reset request to the bank. The bank first verifies the user's identity and, upon confirmation, initiates the asset transfer process. The system generates a new public/private key pair, retrieves the user's previous public key from the database, and then calls the super administrator smart contract to transfer all existing assets corresponding to the previous public key address to the user's new public key address, signing the transaction with the bank's private key. This asset transfer transaction record is also recorded on the blockchain and can be publicly queried.

  • The new public key address is added to the database (the user's original public key address is not deleted).

  Once the assets are transferred to the user's new public key address, the user can perform transfers and other transactions using the new private key. When the user queries historical transactions, they will obtain all public key addresses from the database. Transactions after the private key change will be queried through the new public key address, while transactions before the private key change can be traced through the previously used public key address.

• The blockchain has attracted widespread attention due to its decentralized and tamper-resistant characteristics, being considered a solution for the value exchange issues of the new generation of the internet and the credit issues of network transmission. However, in engineering practice, the multi-center and tamper-resistant characteristics that endow the blockchain with trustworthy attributes often bring many usage limitations. A prominent issue is the upgrading of smart contracts. It is well known that no system is without vulnerabilities, and no system can determine all requirements at the design stage. The immutability of blockchain conflicts with the need for iterative updates in engineering, and resolving this conflict requires strong decision-making. However, existing blockchain systems lack effective governance mechanisms to make reasonable and democratic decisions.

  To resolve the contradictions between the multi-center and tamper-resistant characteristics of blockchain and practical engineering, Hyperchain proposes an effective governance mechanism called ACO (Autonomous Coalition Organization) that promotes self-improvement of the blockchain. When the initial protocol cannot meet practical needs or when special contradictions arise during the operation of the blockchain network that are difficult to reconcile, and the protocol needs to be upgraded, these contradictions can be properly resolved through the autonomous coalition mechanism of ACO.

  The advantages of the ACO autonomous coalition mechanism proposed by Hyperchain are reflected in the following three aspects.

  (1) Changes in coalition members. Changes in existing consortium blockchain system members are often strongly tied to identity authentication, which is usually authorized by a third-party CA, becoming the only strong center in a multi-center blockchain system. This approach not only poses a single point of failure risk but also significantly reduces the overall security and credibility of the blockchain system. The ACO mechanism utilizes smart contracts as a negotiation platform for changes, using data certificates self-issued by nodes as proof of negotiation results (distributed CA), ensuring that the member change process retains a multi-center characteristic while keeping the entire negotiation process open and transparent.

  (2) Smart contract upgrades. Upholding the design philosophy that initial trust stems from offline governance and subsequent trust arises from online governance, the ACO mechanism provides an effective governance method for contract upgrades: coalition members specify upgrade strategies in advance and write them into smart contracts. When an upgrade is needed, proposals are initiated and voted on by coalition members, and the smart contract automatically executes the corresponding proposal after collecting votes, using permission-controlled contract self-upgrade instructions to resolve the upgrade issues of blockchain contracts.

  (3) Upgrading the consortium blockchain system. System upgrades are divided into two types: public chain hard fork non-compatible upgrades and consortium chain offline manual compatible upgrades. However, such consortium chain upgrades often require lengthy offline business negotiations and are usually completed manually by operation and maintenance personnel, which is extremely primitive and inefficient. Hyperchain proposes an effective online negotiation system collaborative upgrade mechanism that enables efficient automated synchronous upgrades of the system.

• Permission Management

  To meet the needs of richer and more complex business application scenarios, Hyperchain proposes a hierarchical permission management mechanism to further ensure business privacy and security.

  (1) Chain-level administrators: Participate in blockchain-level permission management, including node management, system upgrades, and contract upgrade permission control, often designated as internal super administrators by various coalition institutions. Permissions for node admission, system upgrades, and contract upgrades at the chain level must be decided by voting among coalition institutions, rather than being dominated by a single entity. The specific voting rules are negotiated offline by each coalition institution and written into the Genesis block. Any subsequent changes must follow the previously agreed-upon rules for a round of voting to complete the change. Chain-level permission management requires the assistance of the aforementioned autonomous coalition organization (ACO).

  (2) Node administrators: Participate in node-level permission management, including controlling node access permissions, often designated as operation and maintenance administrators by various coalition institutions. Node administrators issue access certificates (SDKCert) to users, controlling user access to SDK interfaces. Requests with node access certificates will only be processed by that node. Node administrators can issue certificates through the client, configure user permission tables, and allocate user access permissions to the SDK, such as permissions to call contracts, obtain blocks, etc. Chain-level administrators are default holders of node access certificates SDKCert.

  (3) Users: Ordinary users participating in on-chain business scenarios. Users can hold certificates issued by different nodes and initiate transactions to different nodes. The specific permissions of users in corresponding business scenarios are defined by the upper-level business system. In the future, the platform can abstract a series of general permission management interfaces for better permission management at the business layer.

  At the business level, Hyperchain has set up contract access control, allowing contract coders to customize access permissions for contract functions, setting permission controls for some high-privilege functions so that only fixed address callers can invoke those functions, thus achieving access permission control.

Hyperchain, as a shared state blockchain implementation, operates through continuous state transitions. Each state transition generates a corresponding series of events, marking this state transition. Therefore, to allow external users to better monitor the state changes of Hyperchain, we provide a set of unified message subscription interfaces for external systems to capture and listen to changes in Hyperchain's state, serving as a message channel for communication between smart contracts and the outside world.

Currently, external users can easily listen to three types of events through the message subscription system:

(1) A new block is generated;

(2) A new event is generated by a contract;

(3) An exception occurs in the system. More event subscription types will be supported in the future, such as transaction status change messages. The message subscription system is encapsulated on the Hyperchain event routing module, with its architecture shown in the diagram.

• This system has a three-layer structure, logically divided into upstream data collection, data filtering and pushing, and downstream data export. Upstream data is obtained through the event router, data filtering and pushing are completed by the message subscription system itself, and downstream data export is completed through the RPC module.

  The use of message subscription is very simple, with the general process as follows:

  (1) External users initiate a subscription request;

  (2) Hyperchain returns a subscription ID;

  (3) External users can obtain the subscribed messages through either active polling or passive pushing methods based on the subscription ID.

• Specific Implementation

  Hyperchain has implemented the message subscription function based on both WebSocket and MQ (message queue).

  WebSocket is a method provided by the system for network communication, involving both communication parties, namely the client (Client) and the server (Server). The publish-subscribe model requires the server to maintain a list of connected clients, and a reliable long connection must be established between the client and server. The server's socket needs to create a Listener to listen for client connections, and the client can only exchange messages after connecting to the server.

  MQ is a communication method that adds a container for saving messages, allowing the server and client to communicate by reading and writing messages from input and output queues without direct interconnection. The exception recovery mechanism provided by MQ resolves the issue of message loss due to connection disconnections in the WebSocket message subscription system. The platform's MQ service requires users to independently start a RabbitMQ server, which is referred to as the RabbitMQ-broker. The MQ service provided by the platform acts as a producer client, responsible for pushing platform messages to the RabbitMQ-broker; the message consumer acts as a consumer client, establishing a connection with the RabbitMQ-broker and waiting for messages pushed from the RabbitMQ-broker.

  The specific usage method of the MQ service is as follows.

  (1) Users register their message queue with the platform, specifying the routing key (RoutingKey) set required by the queue; the platform will create the queue and start the service, returning the name of the queue along with the exchange name to the user;

  (2) Users normally use the platform to send transactions. When events corresponding to the routing key occur, messages will be automatically pushed to the RabbitMQ-broker by the MQ service;

  (3) Users can obtain the subscribed information through active querying or passive pushing methods.

To maintain the privacy of contract data, all smart contracts deployed on the Hyperchain platform use complex encoding methods for their underlying data, ensuring that even if blockchain nodes have access to the entire blockchain data, they cannot obtain the plaintext information of the contract data.

However, some institutions need to analyze or audit the contract data stored on the blockchain. Therefore, Hyperchain provides a contract data parsing solution based on source code analysis. Through this method, institutions can parse the contract data and export the plaintext data for auditing and analysis, provided they have the contract source code, contract address, and contract data key set; other institutions without the contract source code, contract address, and contract data key set cannot parse the plaintext data. The process of contract data parsing is illustrated in the diagram.

In a data parsing process, three necessary prerequisites are:

(1) Having the contract source code;

(2) Having the contract address;

(3) Having the key set of the contract data.

The main data in smart contracts is organized and managed using basic data structures such as maps. The data in a map can be likened to a table in a traditional relational database, and the prerequisite for parsing data in a map is to have the key set of all key-value pairs stored in the map. Therefore, for a participating institution, the key set corresponding to the data it generates can be maintained by itself, and this part of the data can only be parsed by itself without leakage.

Finally, the data can be imported into a relational database (such as MySQL) for analysis or auditing, as shown in the diagram.

More importantly, Hyperchain views Radar as an important tool for obtaining analyzable high-quality data. After obtaining this data, users can perform data processing, analysis, and other operations to mine the hidden value within the data.

As the blockchain runs over time, the storage capacity of the blockchain will grow linearly, and the speed of this data growth may even exceed the growth rate of storage media capacity. Therefore, blockchain data storage will become a significant factor limiting the development of blockchain technology. To address this pressing issue, Hyperchain proposes a method for blockchain data archiving, allowing the entire blockchain system to dynamically archive data without downtime.

The blockchain data archiving method provided by Hyperchain is based on state backup. In simple terms, when a user wants to archive data for a particular blockchain node, they must create a snapshot of the blockchain at a past moment; when archiving data, the user can archive all blockchain data (including block data, transaction data, receipt data, etc.) prior to the snapshot point to alleviate the storage pressure on the blockchain node.

Once the snapshot is created, the node undergoes three state transitions, and the world state experiences three updates, with the local latest block height also updated to 97.

At this point, the user initiates a data archiving request, asking to dump and archive all blockchain data prior to the snapshot point. The node will dump the block data from block number 0 to 93 and the corresponding transaction receipts, updating the local genesis state content to the previously backed-up snapshot state, with the genesis block updated to block number 94, as shown in the diagram.

The normal state transition of the blockchain is a process where the endpoint of the state continuously updates forward, while data archiving can be viewed as a process where the starting point of the blockchain state updates towards the endpoint.

The aforementioned data archiving targets blockchain data, while the smart contracts deployed on the blockchain also have significant storage demands to record large amounts of business data. For this part of the data, Hyperchain provides another archiving mechanism. Users only need to initiate a transaction with a special marker, calling a custom archiving function in the smart contract to achieve data dumping. Contract coders can implement any logic for the archiving function in the contract to meet different business needs. Hyperchain also introduces an Archive Reader for convenient future access to archived data.

The unit bit strength of elliptic curve cryptography is much higher than that of traditional discrete logarithm systems. Since all signature verification requests are stored in fixed-size blocks, with a large number of requests per block, and requiring programs to complete computations quickly with high response time requirements, hardware acceleration of the elliptic curve signature algorithm is necessary to achieve faster signature computations.

Hyperchain has implemented a GPU-accelerated verification signature algorithm based on existing relevant theories. GPUs have far more computing units than CPUs and excel at large-scale concurrent computations. Therefore, the platform uses NVIDIA's GPGPU and CUDA as the development environment, implementing elliptic curve scalar multiplication operations in parallel using GPUs. Figure 6.32 illustrates the processing flow of this algorithm.

Using the enterprise-level blockchain platform Hyperchain as an example, we have introduced the implementation principles of the core components that constitute the enterprise-level blockchain platform. Unlike public and private chains, enterprise-level blockchains directly address the needs of enterprise-level applications, imposing stricter requirements on the security, privacy, usability, flexibility, and performance of blockchain systems. The Hyperchain enterprise-level blockchain platform is built to meet enterprise needs based on the following points.

First, the Hyperchain platform adopts ACO autonomous coalition and CA system certification for member management, providing comprehensive protection mechanisms for member admission, identity authentication, and permission management. Second, the platform designs and implements a flexible, efficient, and stable consensus algorithm RBFT based on optimizing traditional PBFT, providing a solid algorithmic foundation for the enterprise-level blockchain platform and improving the throughput of transaction data. Moreover, in supporting smart contracts, it chooses the Solidity language, which is active in the open-source field, and independently develops the lightweight sandbox smart contract engine HVM, providing comprehensive contract lifecycle management, as well as a friendly programming environment that is secure and efficient in contract execution. Third, in the design of the blockchain ledger, it opts for a ledger system different from Bitcoin, employing a method of separating block data and state data storage to enhance data processing speed. Additionally, the Hyperchain platform strengthens the security level of enterprise-level blockchains systematically through privacy protection at the business layer and transaction layer, encrypting transactions, transaction links, application development packages, and more. Finally, to improve the usability and interactivity of enterprise-level blockchains, the Hyperchain platform offers functions such as message subscription, data visualization, and data archiving, greatly enhancing the utilization of transaction data.