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. Additionally, 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, the 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

Regarding 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, allowing for submission and internal voting on status actions within the coalition, such as system upgrades, contract upgrades, member management, etc. This approach provides an effective model for blockchain alliance governance.

• Member management. The platform achieves access control for coalition members through a CA system certification approach, 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 controls.

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 encryption 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, making data transactions and storage between partition members 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 in the public ledger after consensus across the network, ensuring effective isolation of privacy 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 signatures from third-party trusted institutions, 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 improve 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 needs.

• Data separation. The ledger data in the blockchain is mainly divided into block data and state data. Considering that block data will continue to 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 various smart contract engines, including 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 unlimited growth of blockchain-stored data, we archive some old online data offline, providing an Archive Reader for browsing archived data.

• Data visualization. To facilitate real-time consultation of 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 in 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 between on-chain and off-chain, supporting subscriptions for block events, contract events, transaction events, system exception monitoring, and other events.

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

Consensus algorithms are key to ensuring the consistency of ledger data across nodes in 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 in the ledger, which is resource-intensive and has weak regulatory capabilities. Achieving consensus for each transaction requires the entire network to participate in the computation, making it unsuitable for the regulatory and performance requirements of consortium chains. PoS's main idea is that the difficulty of obtaining recording rights is inversely proportional to the amount of equity held, which performs better than PoW but still has weak regulatory issues. Paxos and Raft are mature solutions for consistency in traditional distributed systems, offering high performance and low resource consumption but lacking fault tolerance for Byzantine nodes. The PBFT algorithm is similar to the processing flow of the Paxos algorithm and is a consensus mechanism based on permission voting, where a minority obeys the majority. This algorithm can tolerate Byzantine errors and allows participation from strongly regulated nodes, demonstrating 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 an improved algorithm for PBFT, namely RBFT.

1. Overview of RBFT

   Hyperchain's consensus module adopts a pluggable modular design, allowing for 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 proactive recovery and dynamic node addition/removal mechanisms, significantly 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. RBFT Regular Process

   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 capability 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, with f equal to 1. In the diagram, the Primary is the dynamically elected primary node among the blockchain nodes, responsible for sorting and packaging client messages, while Replica nodes are backup nodes that execute the same transaction logic as the Primary node. Replica nodes can participate in the election of a new Primary node when the Primary node fails.

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

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 value 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 node'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 used for result validation, with checkpoint rules being configurable.

From the above RBFT regular process, 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, the Primary node verifies the transaction upon receipt, 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 receiving 2f Prepare messages, the Replica verifies the verification results of the Primary node. If the verification fails, it triggers a ViewChange message, further ensuring the system's security.

In the PBFT algorithm, the nodes participating in consensus can be divided into primary nodes (Primary) and backup nodes (Replica). The backup 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: how can other backup nodes promptly detect anomalies in the primary node, such as crashes, system errors, or being compromised (i.e., becoming a Byzantine node), and elect a new primary node to continue consensus? This is a critical issue that must be resolved to ensure the stability of BFT-type algorithms.

Both PBFT and RBFT introduce the concept of views (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 Byzantine behaviors of 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 type here could be a 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 can ensure that a correctly behaving primary node sends a nullRequest to all backup nodes when no transactions occur, confirming the validity of this situation. If a backup node does not receive the primary's nullRequest within the specified time, it will trigger a view change behavior to elect a new primary node.

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

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

When a backup node detects any of the above anomalies in the primary node or receives view change messages from other 2f+1 nodes, it will broadcast a view change message 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 backup nodes will verify and compare the messages, and upon verifying that the view change information is the same, they will formally change the view and print a FinishVC message, thus completing the entire view change process, as shown in Figure 6.5 (where ViewChange represents view change, Primary represents the primary node, and Replica represents backup 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 directly crash. In such scenarios, nodes need to automatically recover and synchronize the ledger to the current latest state of the blockchain to participate in subsequent transaction executions. To address this data recovery task, 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 nodes with the latest storage state in the system. The automatic recovery mechanism greatly enhances the availability of the entire blockchain system. For ease of recovery, RBFT sets checkpoints for the executed data, which are based on the results of consensus across the network. 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 portion of 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 removal of nodes. To facilitate the control of member admission and exit, RBFT adds the capability to dynamically add and remove 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 and then send requests to all nodes in the alliance. After confirmation and agreement from each node, a 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. Next, 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 proactive recovery algorithm to synchronize the latest status of the blockchain alliance members. Finally, the new node requests to join the regular consensus process from the primary node. After confirming the new node's request, the primary node 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 addition of the new node will change the overall consensus N, meaning that the value of f may change).

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

(1) The exiting node needs to call an RPC request to obtain its hash value and 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 agreement to the node's request to exit the entire blockchain consensus.

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

(4) When nodes receive 2f+1 AgreeUpdateN messages, they update the node system status.

Dynamic Node Exit Function Call

At this point, 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, enhancing the automatic recovery mechanism for nodes, and adding dynamic node joining and deletion functions, RBFT is more stable, flexible, and efficient than the traditional PBFT algorithm, better meeting the production environment needs of enterprise-level consortium blockchains. Dynamic Node Exit Function Call

At this point, 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, enhancing the automatic recovery mechanism for nodes, and adding dynamic node joining and deletion functions, RBFT is more stable, flexible, and efficient than the traditional PBFT algorithm, better meeting the production environment needs of enterprise-level consortium blockchains.

The P2P network is the channel for consensus and information transmission between nodes, serving as 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, existing as a server. The Peer sub-module mainly acts as a 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 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-layer modules. Node is primarily responsible for receiving messages and forwarding them to the upper layers: 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, which controls communication and distribution across layers, implementing the external exposure of Peer interfaces and truly controlling the states of various nodes. The P2P module also implements mutual separation of each module, 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 them to synchronize promptly after just starting up or due to other reasons causing state lag.

  VPs communicate through gRPC remote calling services to form 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 system traffic exceeds the set limit, the excess will be rejected. This prevents excessive useless transaction requests from occupying node processing time and delaying other transactions, thereby ensuring system security while meeting business requirements.

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

Smart contracts are segments of automatically executable programs deployed on the blockchain. In a broad sense, smart contracts encompass programming languages, compilers, virtual machines, events, state machines, fault tolerance mechanisms, etc. Among these, the programming language and the execution engine of smart contracts, namely 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 could 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 (e.g., opening files, accessing underlying operating system resources, etc.), thus ensuring that smart contracts written in Solidity can only run in a sandbox independent of the operating system and cannot manipulate 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 resource control granularity, and using Solidity can maximize the utilization of the open-source community's accumulated technology and experience in smart contracts, improving the reusability of smart contracts. Therefore, the Hyperchain platform chooses Solidity for smart contract implementation and has developed an efficient smart contract execution engine, HyperVM, that supports Solidity execution.

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

   • HyperEVM

   HyperEVM is a deeply restructured virtual machine designed to maximize the utilization of the open-source community's accumulated technology and experience in smart contract technology, 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, retaining 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 checks. 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 contract custom event listening.

   • 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 contract lifecycle support;

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

   • A more efficient state space operation mechanism;

   • A more user-friendly programming interface solution.

   • HyperVM Design Principles

   The design of HyperVM is illustrated in Figure 6.11, with 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 safety 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. The platform client can then 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 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 compiled from the contract.

(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, it jumps to step (2); otherwise, it executes step (6).

(6) It checks whether the halt status 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 this transaction execution, 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: 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 instruction execution 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, thus preventing malicious code execution within smart contracts.

The JIT execution method is relatively complex. JIT, also known as Just-in-time compilation, is a form of dynamic compilation that improves program execution efficiency. Typically, programs can 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 executing. The JIT compiler combines static compilation and dynamic interpretation, compiling source code line by line while caching the translated code. The benefit of this approach is that it reduces performance loss. JIT-compiled code can handle delayed binding and enhance security compared to statically compiled code. The JIT mode for executing smart contracts mainly includes the following steps.

(1) All information related to the smart contract is encapsulated in a contract object, and then the hash value of the code is used to check whether the contract object has been compiled and stored. 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, jump, etc.

(3) If the contract state is unknown, HyperVM first checks whether the virtual machine is forced to execute JIT; if so, it compiles in order and executes using JIT instructions. Otherwise, it opens a separate thread for compilation while the current program continues to use ordinary bytecode compilation. When the virtual machine encounters the same encoded contract again in the next execution process, it will directly select the optimized contract. This way, the instruction set of the contract, having been optimized, can significantly improve 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. Hyperchain's ledger design mainly includes three parts: first, customer transaction information is stored using a blockchain's chain structure, 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 section 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 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, and by continuously iterating to access parent blocks, one can ultimately trace 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 hash every checkpoint; if the locally maintained latest block hash matches the latest block hash maintained by the blockchain network, it can be determined that the locally maintained blockchain information is legitimate; otherwise, it indicates that the local node has become a "Byzantine node."

Hyperchain Block Header Definition

Transaction Structure Definition

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 contract state metadata includes the following fields, as shown in the table.

In addition to the above metadata, the contract account has two data fields: executable code and variable storage space. The executable code is a set of instructions encoded as a byte array, and each contract call 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 diagram illustrates the storage space of the contract account.

The storage space is logically composed of a contiguous array 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 their 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 computation. Next, we will briefly introduce the structure and function of the Merkle tree.

A Merkle tree is a hash binary tree, used as a data structure 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, generating a digital fingerprint for the entire transaction set and providing an efficient way to verify whether a transaction exists in a block. However, traditional Merkle trees perform poorly when faced with high-frequency massive data, and their computational performance does not meet the needs of consortium chains. Therefore, Hyperchain has designed a HyperMerkle tree that combines the advantages of both Merkle trees and hash tables, significantly improving the speed of ledger hash computation.

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. First, the data of these four 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-level 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 with 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 where batch transaction data is hashed and cannot meet the needs of rapidly computing 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 set 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 calculation 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, using the chaining method to handle hash collisions.

(2) For each modified leaf node, the hash is recalculated, with the input being the content of the leaf node; after the calculation is completed, 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 previous calculation); after the calculation is completed, 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 known as 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 a modification occurs, 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 to 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 to the HyperMerkle tree, and the output is stored in the block, serving as the identifier for the current state of the contract account set.

An enterprise-level blockchain platform is essentially a consortium chain. The term "consortium chain" encompasses two meanings: 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 cryptographic multi-level encryption mechanism, using secure encryption algorithms to comprehensively encrypt user information at multiple levels, including transaction networks, transaction parties, and transaction entities, and also proposes a CA-based permission control mechanism. Additionally, to meet the high scalability and high availability requirements of enterprise-level blockchain platforms, the platform has introduced data management, message subscription, and other functions.

To enhance data security and privacy protection while supporting flexible and independent business scenarios, Hyperchain implements partition consensus for internal transactions in the blockchain network through a Namespace mechanism. Users can divide 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, preventing interference between transactions in different spaces.

A single Hyperchain node can choose to participate in one or more Namespaces according to 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, and the access of nodes in the Namespace is controlled through CA certification, allowing for dynamic joining and exiting.

The verification, consensus, storage, and transmission of transactions with specific Namespace information only occur among nodes participating in that Namespace. Transactions between different Namespaces can be executed in parallel. For example, in Figure 6.19, 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 in both namespace1 and namespace2, but the ledgers in namespace1 and namespace2 are isolated and invisible to each other.

To provide a more granular privacy protection solution for the consortium chain, 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 level, 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 privacy 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 / Hashed 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 privacy data. Alternatively, original data and files can be stored off-chain, with only their digital summaries saved on-chain through hashing, addressing both data capacity and sensitivity issues.

• Contract Access Control

  Contract coders can use smart contracts and access control policies to restrict the roles and users accessing data, 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, thereby implementing access permission control.

Hyperchain adopts a pluggable multi-level encryption mechanism, applying different encryption strategies to data, users, communication connections, and other aspects 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 the input's space, and hash functions possess 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 different 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) to sign transactions, 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 the elliptic curve cryptosystem (ECC) is much higher than that of traditional discrete logarithm systems, resulting in smaller computational parameters, shorter keys, faster operation speeds, and shorter signatures.

Hyperchain implements the digital signature algorithm using both the secp256k1 curve and the r1 curve, allowing users to choose and sign transactions on the platform, ensuring the correctness and integrity of transactions. The platform also supports using this algorithm to sign and verify messages between nodes, ensuring the correctness and integrity of message communication between nodes. Considering the complex calculations involved in the digital signature and verification processes, 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, session keys are used to encrypt transmitted information, preventing 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 needing to exchange any private information in advance.

In Hyperchain, the ECDH protocol is first used to exchange shared keys, as illustrated 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 public keys of both parties but cannot generate the 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. Based on secure identity authentication, the established secure channel can confirm the legitimacy of both parties' identities, and symmetric encryption can significantly improve communication efficiency since identity does not need to be authenticated for every communication.

• Ciphertext Transmission Based on Symmetric Encryption

  After the communication parties negotiate a shared confidential key, Hyperchain ensures ciphertext transmission between nodes based on symmetric encryption algorithms, making it more difficult to computationally crack the transmitted content, thus 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 parts.

  • 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 to encrypt and decrypt 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 enabled in Hyperchain, using certificates issued by TLSCA for secure communication. 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 Secret Support

  Compared to other blockchain platforms, Hyperchain has a significant advantage in encryption algorithms: it fully supports the integration of national secret algorithms. Currently, Hyperchain has integrated national secret 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 certificates for certification authorities and role certificate admission certification 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 on-chain services; otherwise, they cannot join the corresponding Namespace.

Additionally, Hyperchain's ECert design has two implementations. Institutions holding ECert1 not only have the permission to interact with Hyperchain on-chain services but can also issue TCert (transaction certificate) transaction certificates downwards. Transaction certificates are used to achieve pseudo-anonymous transactions, which must be carried by clients 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 role certificate authority that has the authority 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 exists only as a certificate for identity proof 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 publishable.

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 hosted RA service that issues and verifies certificates through CFCA's hosted 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. The purchased certificates are configured in the SDK, and 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 check whether the certificate has been blacklisted.

  In terms of JavaSDK, when the SDK sends SDKCert, it selects the corresponding signing algorithm for the transmitted content based on CFCA's feature switch. The SDK and Hyperchain's CFCA feature switches need 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/private keys needs to be generated. When starting, each node first generates a self-signed certificate based on the public key and then generates the root certificate.

    When issuing sub-certificates, they can be generated from the root certificate of this node for specified types of sub-certificates (ECert, RCert, TCert, and SDKCert), or users can provide public keys to the issuer, which will then issue sub-certificates.

  • 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 requesting 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 to be 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 contains all digital certificates that are revoked but still within their validity period.

    Additionally, digital certificates may also be revoked before their expiration date. For example, in special cases: if a certificate user misuses the certificate for improper purposes and the CA discovers it, or if government agencies or other authoritative departments request revocation 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, and the other is for users to manage 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 for signing transactions.

  If the user's private key is lost, 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 both 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 manage the complete public/private key pair themselves 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's 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 its own administrator smart contract, which can only transfer assets for its own customers).

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

  • When generating the user's key pair, 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.

  • When the user's private key is lost, they submit 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 user's previous public key address to the user's new public key address, signing the transaction with the bank's private key. The transaction record of this asset transfer 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 use the new private key to conduct transfers and other transactions with the original assets. 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 using the new public key address, while transactions before the private key change can be traced back using 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 problem in the new generation of the internet and the credit issue in 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 the 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 conflict between the multi-center and tamper-resistant characteristics of the blockchain and practical engineering, Hyperchain proposes an effective governance mechanism called ACO (Autonomous Coalition Organization) that can promote self-improvement of the blockchain. When the initial protocol fails to meet practical needs or when irreconcilable special conflicts arise during the operation of the blockchain network, requiring protocol upgrades, these conflicts can be properly resolved through the autonomous governance of the 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 the negotiation results (distributed CA), ensuring that the member change process retains a decentralized characteristic while maintaining transparency throughout the negotiation process.

  (2) Smart contract upgrades. Upholding the design philosophy that initial trust comes from offline governance and subsequent trust comes 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, a proposal is 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 issue of blockchain contracts.

  (3) Upgrades of the consortium blockchain system. System upgrades are divided into two types: public chain hard fork non-compatible upgrades and consortium chain manual compatible upgrades offline. However, such upgrades often require lengthy offline business negotiations and are typically completed manually by operations personnel, which is extremely primitive and inefficient. Hyperchain proposes an effective online negotiation system collaborative upgrade mechanism, enabling 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 safeguard 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 the coalition institutions, rather than being dominated by a single entity. The specific voting rules are negotiated offline by the coalition institutions and written into the Genesis block. Any subsequent changes must follow the previously agreed-upon rules for a round of voting to be completed. 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 operational administrators by various coalition institutions. Node administrators issue access certificates (SDKCert) to users, controlling their access to SDK interface permissions. 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 SDK, such as permissions to call contracts, access blocks, etc. Chain-level administrators automatically carry 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-layer 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 within the contract, setting permission controls for some high-privilege functions so that only fixed address callers can invoke those functions, thereby implementing 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 types of event subscriptions will be supported in the future, such as transaction status change messages. The subscription system for messages 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. The upstream data is obtained through the event router, data filtering and pushing is completed by the message subscription system itself, and downstream data export is completed through the RPC module.

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

  (1) An external user initiates a subscription request;

  (2) Hyperchain returns a subscription ID;

  (3) The external user obtains the subscribed messages based on the subscription ID through either active polling or passive pushing.

• Specific Implementation

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

  WebSocket is a method provided by the system for network communication, involving both parties in communication, 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, while 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 needing to connect directly. 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 that connects to the RabbitMQ-broker, 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 and the name of the exchange to the user;

  (2) Users normally use the platform to send transactions. When events corresponding to the routing keys 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.

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 complete 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, so Hyperchain provides a contract data parsing solution based on source code analysis. Through this method, institutions can obtain the contract source code, contract address, and the key set of contract data, and utilize the data visualization services provided by Hyperchain to parse the data of the contract, exporting the plaintext data of the contract for auditing, analysis, and other tasks. Institutions without the contract source code, contract address, or contract data key set cannot parse the plaintext data. The process of contract data parsing is illustrated in the figure.

In a data parsing process, three necessary prerequisites are required:

(1) Possession of the contract source code;

(2) Possession of the contract address;

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

The main data in smart contracts are organized and managed using basic data structures like maps. The data of a map can be likened to a table in a traditional relational database, and the prerequisite for parsing data in a map is to possess 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 under the premise of not leaking, this portion of data can only be parsed by itself.

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

More importantly, Hyperchain views Radar as an important tool for obtaining analyzable high-quality data. After acquiring this data, users can perform data processing, data 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, if a user wants to archive data for a specific blockchain node, they must create a state snapshot of the blockchain at a certain point in the past. When a user performs data archiving, they can archive and dump 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 has been updated three times, with the local latest block height 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 numbers 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 figure.

The normal state transition of the blockchain is a process of continuously updating the endpoint of the state, while data archiving can be viewed as a process of updating the starting point of the blockchain state to the endpoint.

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

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

Hyperchain implements 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 to implement 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 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 builds a blockchain platform that meets enterprise needs from the following aspects.

First, the Hyperchain platform adopts ACO autonomous governance and CA system certification for member management, providing a comprehensive protection mechanism for member admission, identity authentication, and permission management. Second, based on optimizing traditional PBFT, it has designed and implemented a flexible, efficient, and stable consensus algorithm RBFT, providing a solid algorithmic foundation for enterprise-level blockchain platforms and improving the throughput of transaction data. Moreover, in supporting smart contracts, it has chosen the Solidity language, which is active in the open-source field, and independently developed the lightweight sandbox smart contract engine HVM, providing comprehensive contract lifecycle management, as well as a friendly programming environment with contract security and efficient execution. Third, in the design of the blockchain ledger, it has chosen a ledger system different from Bitcoin and adopted a method of separating block data and state data storage to improve data processing speed. Additionally, the Hyperchain platform enhances the security level of enterprise-level blockchains through partition consensus, privacy transactions, and other methods, encrypting transactions, transaction links, application development packages, and more. Finally, to improve the usability and interactivity of enterprise-level blockchains, the Hyperchain platform provides message subscription, data visualization, data archiving, and other functions, greatly increasing the utilization of transaction data.