Unified representation and publishing method of multiple data types under blockchain

Abstract

The application relates to a unified expression and publishing method supporting various data types under a blockchain, and belongs to the technical field of computer blockchains, in particular to a unified expression and publishing method for relational data, diagram data, text data and key value data based on a blockchain. The application realizes high concurrency in execution and consensus stages, adopts a mixed storage mode to compress storage overhead, so as to realize low overhead, high performance and high scalability, and through design of a distributed application cooperative index, concurrent control is realized, consistency of each node and serializability of a submission result are ensured without additional communication overhead. The unified expression and publishing method and the related work flow designed in the application can provide a basis for data management, index design and other tasks in subsequent processes of the manufacturing industry, and can be widely migrated to other application scenarios of safety, confidentiality and unified data expression.

Description

Technical Field

[0001] This invention relates to a unified method for expressing and publishing multiple data types under blockchain, belonging to the field of computer blockchain technology, and more specifically to a unified method for expressing and publishing relational data, graph data, text data, and key-value data based on blockchain. Background Technology

[0002] The unified representation and publication of relational data, graph data, text data, and key-value data is one of the key factors in applying blockchain in manufacturing big data. Currently, the manufacturing industry is showing a trend towards informatization and intelligentization, thus generating massive amounts of data throughout the entire process of product development, production, and logistics. Manufacturing big data has significant value. Within enterprises, data can be used not only for product production control and supervision but also for optimizing production processes and improving future processes. When multiple manufacturing enterprises collaborate, a large amount of data is also involved. Enterprises need to collaborate through data sharing, ensuring the authenticity and reliability of the shared data, while not fully disclosing all internal production data. Therefore, the reliable sharing and efficient flow of different types of data is crucial for optimizing the collaboration process between manufacturing enterprises (applications).

[0003] To achieve collaboration among manufacturing applications, data modeling, storage, and exchange are necessary. Data sharing must meet the security and confidentiality requirements of collaborative scenarios. While ensuring the authenticity and reliability of shared data among collaborating enterprises, it's also crucial to prevent other enterprises from accessing internal private data. Traditional database methods offer high-performance, highly scalable, and low-overhead data storage and usage, but they often require separate storage and access methods for different types of heterogeneous data (such as relational, graph, text, and key-value data), and cannot meet the data confidentiality and security requirements of multi-enterprise collaboration in manufacturing. While popular blockchain technology offers data security, its publicly available complete ledger design limits the confidentiality of internal data stored uniformly on the blockchain. Furthermore, the append-only nature of the blockchain ledger, requiring each node to store the complete ledger containing all types of data and the entire world state, leads to rapidly increasing storage costs. Therefore, there is an urgent need for a method that provides unified data representation, security and confidentiality guarantees, and high performance with low overhead for manufacturing big data.

[0004] Intel SGX is designed to protect confidential information in applications, enabling it to resist malware attacks even when applications, operating systems, and BIOS are untrusted. By introducing new instruction sets and memory access technologies, SGX provides a trusted execution environment for user applications. Intel SGX is adaptable to enterprise-level scenarios and provides high availability, thus meeting the requirements of this invention for off-chain databases and making it suitable as the trusted execution environment needed in the system.

[0005] Therefore, how to use blockchain to solve the problems of excessive data volume, insufficient confidentiality guarantee, and the difficulty in uniformly expressing relational data, graph data, text data, and key-value data that are tightly coupled with system design; and how to propose a more convenient and reliable data usage solution for distributed application collaboration in manufacturing big data are problems that urgently need to be solved by those skilled in the art. Summary of the Invention

[0006] In view of this, the present invention provides a unified representation and publishing method for relational data, graph data, text data, and key-value data based on blockchain. It utilizes a blockchain platform with an execution-sorting-verification architecture to provide on-chain data and consensus services, providing the system with tamper-proof, decentralized, and traceable features. It utilizes Intel SGX to provide a trusted execution environment, ensuring the integrity of off-chain transaction execution results.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A unified representation and publishing method for relational data, graph data, text data, and key-value data based on blockchain, including a transaction execution phase and a transaction commit phase;

[0009] The transaction execution phase includes:

[0010] S11. The client generates blockchain transaction requests within or across applications as needed and sends them to the corresponding application's on-chain consensus node.

[0011] S12. The consensus node determines the transaction type and forwards the transaction request to any execution node within the application.

[0012] S13. After receiving a transaction request, the execution node classifies it according to the transaction type.

[0013] S14. For internal transaction requests, the execution node calls the smart contract within the TEE to access the internal and public data of the corresponding application. The data types are relational data, graph data, text data, and key-value data. A read-write set is generated according to the smart contract execution logic. For cross-application transaction requests, the execution node calls the smart contract within the TEE to access only all public data. The data types can be relational data, graph data, text data, and key-value data. A read-write set is generated according to the smart contract execution logic.

[0014] S15. The execution node packages the read / write set and the execution proof provided by the TEE into a transaction proposal, signs the transaction proposal, and sends it to the consensus node within the same application.

[0015] The transaction commit phase includes:

[0016] S21. After receiving the transaction proposal result and its signature, the consensus node determines whether the transaction is an internal transaction or a cross-application transaction.

[0017] S22. For internal transaction proposals, a consensus on the order of the transaction is reached among all consensus nodes within the same application using a preset general consensus protocol. For cross-application transaction proposals, a consensus on the order of the transaction is reached among all consensus nodes across all applications using a preset general consensus protocol.

[0018] S23. After reaching a consensus on the order of transaction proposals, each consensus node independently verifies the signature of the trusted execution environment and the write set of the transaction based on the temporary data (partial Merkel-Patricia tree) maintained by the consensus nodes. Each consensus node uses multiple threads to verify internal transactions and cross-application transactions in parallel.

[0019] S24. After the legality of the transaction proposal is verified, the consensus node independently runs the conflict detection algorithm to detect read and write conflicts of the transaction by maintaining the distributed application collaboration index and abort transactions that may lead to non-serialization.

[0020] S25. After a transaction proposal passes the conflict detection, it waits for a block to be produced. Once the same type of transaction proposals waiting for block production meet the deterministic block production conditions, each consensus node will package the same type of transactions that have passed the conflict detection to generate a block, and update part of the Merkel-Patricia tree on the chain according to the transactions and execution proofs in the block.

[0021] S26. For blocks composed of cross-application transactions, the consensus node sends the block to all off-chain execution nodes; for blocks composed of internal transactions, the consensus node sends the block to the off-chain execution node of the corresponding application.

[0022] S27. After receiving the block, the execution node verifies the block and writes the updated transaction status data in the block into the database, thus completing the commit process.

[0023] Preferably, the blockchain transaction types mentioned in step S12 include internal transactions and cross-application transactions;

[0024] The internal transactions follow the application's internal workflow, read internal application data and cross-application data, and only update internal data. The execution nodes and consensus nodes of other applications do not participate in the processing of the internal transactions.

[0025] The cross-application transaction is a transaction in which consensus is reached jointly by the consensus nodes of all applications and only accesses the public database. During the lifecycle of the cross-application transaction, the consensus nodes of all applications need to reach consensus on its order and perform verification and conflict detection. The cross-application transaction only needs to be executed by one of the execution nodes.

[0026] Preferably, both the cross-application transaction and the internal transaction are executed in the Trusted Execution Environment (TEE) in the execution node. After the execution is completed, the TEE generates an execution proof of the execution result. The consensus node does not save the complete blockchain ledger and the state data, but only saves a portion of the Merkel-Patricia tree to verify the execution result based on the execution proof.

[0027] Preferably, during the consensus process, each consensus node of each application maintains a distributed application collaboration index and independently performs conflict detection on the internal transactions and the cross-application transactions, ensuring the serializability and consistency of the submission results without additional communication overhead.

[0028] Preferably, the system process and data types in this invention are completely decoupled. Only an off-chain trusted execution environment is needed to provide data integrity guarantees for the smart contract execution results. Depending on the smart contract logic, this invention supports the unified expression of the following four data types: Relational data: Traditional relational databases use a tabular storage method, storing data in rows and columns. Each record is identified as a tuple composed of a series of fields, belonging to a table. For relational data, this invention uniformly expresses it as a triple in the form of (primary key, table, attribute set); Graph data: In graph databases, data is often stored in a semi-structured form as vertices (nodes, components) and edges (relationships). In this invention, graph data is identified by edges and expressed as a triple in the form of (edge, start point, end point); Text data: The storage of text data often uses word position to represent it, storing the document ID, vocabulary, and the position where the vocabulary appears. In this invention, text data is uniformly expressed as a triple in the form of (document, word, location); key-value data: key-value data is a classic data type in blockchain, containing a key and its corresponding value. This invention, considering the source of this data—internal or public data of a specific application—expresses it as a triple in the form of (key, origin, value). In summary, this invention unifies the expression of common heterogeneous data types in manufacturing big data applications into a tuple format containing three items, facilitating collaborative data modeling in distributed manufacturing applications and fully meeting the processing requirements for multi-category heterogeneous data in manufacturing big data.

[0029] Preferably, the off-chain database is any type of database, including relational databases, graph databases, text databases, and key-value databases.

[0030] Beneficial effects

[0031] As can be seen from the above technical solutions, compared with the prior art, this invention discloses a unified representation and publishing method for relational data, graph data, text data, and key-value data based on blockchain. It utilizes blockchain to provide on-chain data and consensus services, offering the system features such as tamper-proofing, decentralization, and traceability. It also utilizes Intel SGX to provide a trusted execution environment, ensuring the integrity of off-chain transaction execution results.

[0032] This invention addresses the needs of distributed application collaboration scenarios in the manufacturing industry for unified data storage, access, and data security and confidentiality. Based on blockchain, it designs a unified data representation and publishing method that includes relational data, graph data, text data, and key-value data. This method supports distributed applications in the manufacturing industry to collaborate securely and reliably through data sharing and value exchange while ensuring internal data confidentiality. The invention achieves high concurrency in the execution and consensus phases and employs a hybrid storage approach to reduce storage overhead, achieving low overhead, high performance, and high scalability. Furthermore, it uses a distributed application collaboration index for concurrency control, ensuring consistency among nodes and serializable submission results without requiring additional communication overhead. The unified data representation and publishing method and related workflows designed in this invention can provide a foundation for data management, index design, and other tasks in subsequent processes in the manufacturing industry, and can be widely migrated to other application scenarios requiring security, confidentiality, and unified data representation. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the overall process structure of the method provided by the present invention;

[0034] Figure 2 This is a flowchart of the transaction commit phase in the method provided by the present invention;

[0035] Figure 3 This is a schematic diagram of the ledger structure in the method provided by the present invention. Detailed Implementation

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0037] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] This invention discloses a unified representation and publishing method for relational data, graph data, text data, and key-value data based on blockchain, including a transaction execution phase and a transaction commit phase;

[0039] The transaction execution phase includes:

[0040] S11. The client generates blockchain transaction requests within or across applications as needed and sends them to the corresponding application's on-chain consensus node.

[0041] S12. The consensus node determines the transaction type and forwards the transaction request to any execution node within the application.

[0042] S13. After receiving a transaction request, the execution node classifies it according to the transaction type.

[0043] S14. For internal transaction requests, the execution node calls the smart contract within the TEE to access the internal and public data of the corresponding application. The data types can be relational data, graph data, text data, and key-value data. A read-write set is generated according to the smart contract execution logic. For cross-application transaction requests, the execution node calls the smart contract within the TEE to access only all public data. The data types can be relational data, graph data, text data, and key-value data. A read-write set is generated according to the smart contract execution logic.

[0044] S15. The execution node packages the read / write set and the execution proof provided by the TEE into a transaction proposal, signs the transaction proposal, and sends it to the consensus node within the same application.

[0045] The transaction commit phase includes:

[0046] S21. After receiving the transaction proposal result and its signature, the consensus node determines whether the transaction is an internal transaction or a cross-application transaction.

[0047] S22. For internal transaction proposals, a consensus on the order of the transaction is reached among all consensus nodes within the same application using a preset general consensus protocol. For cross-application transaction proposals, a consensus on the order of the transaction is reached among all consensus nodes across all applications using a preset general consensus protocol.

[0048] S23. After reaching a consensus on the order of transaction proposals, each consensus node independently verifies the signature of the trusted execution environment and the write set of the transaction based on the temporary data (partial Merkel-Patricia tree) maintained by the consensus nodes. Each consensus node uses multiple threads to verify internal transactions and cross-application transactions in parallel.

[0049] S24. After the legality of the transaction proposal is verified, the consensus node independently runs the conflict detection algorithm to detect read and write conflicts of the transaction by maintaining the distributed application collaboration index and abort transactions that may lead to non-serialization.

[0050] S25. After a transaction proposal passes the conflict detection, it waits for a block to be produced. Once the same type of transaction proposals waiting for block production meet the deterministic block production conditions, each consensus node will package the same type of transactions that have passed the conflict detection to generate a block, and update part of the Merkel-Patricia tree on the chain according to the transactions and execution proofs in the block.

[0051] S26. For blocks composed of cross-application transactions, the consensus node sends the block to all off-chain execution nodes; for blocks composed of internal transactions, the consensus node sends the block to the off-chain execution node of the corresponding application.

[0052] S27. After receiving the block, the execution node verifies the block and writes the updated transaction status data in the block into the database, thus completing the commit process.

[0053] To further optimize the above technical solution, the blockchain transaction types mentioned in step S12 include internal transactions and cross-application transactions;

[0054] The internal transactions follow the application's internal workflow, read internal application data and cross-application data, and only update internal data. The execution nodes and consensus nodes of other applications do not participate in the processing of the internal transactions.

[0055] The cross-application transaction is a transaction in which consensus is reached jointly by the consensus nodes of all applications and only accesses the public database. During the lifecycle of the cross-application transaction, the consensus nodes of all applications need to reach consensus on its order and perform verification and conflict detection. The cross-application transaction only needs to be executed by one of the execution nodes.

[0056] To further optimize the above technical solution, both cross-application transactions and internal transactions are executed in the Trusted Execution Environment (TEE) in the execution node. After execution, the TEE generates an execution proof of the execution result. The consensus node does not save the complete blockchain ledger and state data, but only saves a portion of the Merkel-Patricia tree to verify the execution result based on the execution proof.

[0057] To further optimize the above technical solution, during the consensus process, each consensus node of each application maintains a distributed application collaboration index and independently performs conflict detection on the internal transactions and the cross-application transactions, ensuring the serializability and consistency of the submission results without additional communication overhead.

[0058] To further optimize the above technical solution, the system process and data types in this invention are completely decoupled. Only an off-chain trusted execution environment is needed to provide data integrity guarantees for the smart contract execution results. Depending on the smart contract logic, this invention supports the unified expression of the following four data types: Relational data: Traditional relational databases use a tabular storage method, storing data in rows and columns. Each record is identified as a tuple composed of a series of fields, belonging to a table. For relational data, this invention uniformly expresses it as a triple in the form of (primary key, table, attribute set); Graph data: In graph databases, data is often stored in a semi-structured form as vertices (nodes, components) and edges (relationships). In this invention, graph data is identified by edges and expressed as a triple in the form of (edge, start point, end point); Text data: The storage of text data often uses word position to represent it, storing the document ID, vocabulary, and the position where the vocabulary appears. In this invention, text data is uniformly expressed as a triple in the form of (document, word, location); key-value data: key-value data is a classic data type in blockchain, containing a key and its corresponding value. This invention, considering the source of this data—internal or public data of a specific application—expresses it as a triple in the form of (key, origin, value). In summary, this invention unifies the expression of common heterogeneous data types in manufacturing big data applications into a tuple format containing three items, facilitating collaborative data modeling in distributed manufacturing applications and fully meeting the processing requirements for multi-category heterogeneous data in manufacturing big data.

[0059] To further optimize the above technical solution, the off-chain database can be any type of database, including system databases, graph databases, text databases, and key-value databases.

[0060] This embodiment is a unified representation and publishing method based on blockchain for relational data, graph data, text data, and key-value data. The embodiment includes six entities: manufacturing applications, clients, consensus nodes, execution nodes, and off-chain databases.

[0061] The manufacturing applications in the examples are distributed applications that collaborate through data sharing between different enterprises. They generally belong to an organization or enterprise, and each manufacturing application includes at least one client, one consensus node, and one execution node with a trusted execution environment and off-chain database.

[0062] In this embodiment, the client implementation is no different from that of a regular blockchain client; both can be implemented via command line or SDK. However, the following operations and structure of the client need to be modified:

[0063] (1) Since the client belongs to a specific manufacturing application, it can only connect and communicate with consensus nodes within the same application. In order to ensure the confidentiality of data within each application, the client cannot send transaction requests to consensus nodes belonging to other applications.

[0064] (2) Clients can initiate two types of transactions: intra-application transactions and cross-application transactions. Therefore, different structures need to be designed for the two types of transactions. Intra-application transactions can read both internal and public data of the application and only update internal data, while cross-application transactions only read and write public data.

[0065] The consensus node in this embodiment is functionally similar to the sorting node in a blockchain under the EOV architecture, but with the following differences:

[0066] (1) Consensus nodes need to distinguish between two different types of transactions: internal transactions only reach consensus on consensus nodes within the application, while cross-application transactions reach consensus on all consensus nodes.

[0067] (2) Consensus nodes do not store complete state data and blockchain ledgers, but only store a portion of the Merkel-Patricia tree for verification of transaction read-write sets.

[0068] The execution node in this embodiment is functionally similar to the peer in the blockchain under the EOV architecture, storing the blockchain ledger and state data and executing transactions, but it includes the following differences:

[0069] (1) The ledger stored by the execution node is not the complete ledger, but a partial view of the DAG ledger. The execution node within each application cannot observe the internal transactions and state data of other applications in the DAG ledger.

[0070] (2) Depending on the type of transaction. The data accessed by the execution node when executing a transaction is different. Specifically, an application-internal transaction can read both the application's internal and public data, and only update the internal data, while a cross-application transaction only reads and writes public data.

[0071] (3) The execution node executes the transaction in the trusted execution environment and generates an execution certificate for the consensus node to verify the integrity of the transaction execution.

[0072] In this embodiment, the off-chain database can, in principle, use various types of databases, including relational databases, graph databases, text databases, and key-value databases.

[0073] The relationships and data exchanges between the aforementioned entities are as follows: Figure 1 As shown, the details of the overall system process will be elaborated in the following sections based on the system transaction execution phase and the result submission phase.

[0074] After each entity is initialized, the transaction execution phase and the transaction commit phase are entered sequentially. The specific implementation method will be described in detail below based on the example.

[0075] First, the execution node connects to the SGX Trusted Execution Environment. The smart contract is executed within SGX, and complete state data is stored in non-TEE storage on the execution node. However, when the corresponding data is accessed, a read result with attached proof of read access is returned to SGX.

[0076] If the smart contract required by the client has not yet been deployed on the blockchain, it is necessary to write the smart contract in accordance with the relevant blockchain rules and deploy it on the blockchain platform. After the smart contract is compiled, in the example, a transaction request containing the smart contract Create method is sent to install the smart contract on the chain.

[0077] Users construct transactions according to their needs using methods provided by the client and submit them to the consensus node. The consensus node forwards the transactions to execution nodes within the same application. Transactions are divided into intra-application transactions and cross-application transactions. As shown above, the transaction request includes the address of the smart contract to be called, parameters, identifiers for accessing internal or public data, and the client's signature.

[0078] Execution nodes need to perform different processing procedures for two types of transactions. For internal transactions, execution nodes access both the internal database and the cross-application database simultaneously, execute the transaction within the TEE, and send the signed transaction proposal to the consensus node of the same application. For cross-application transactions, execution nodes only access the cross-application database, execute the transaction within the TEE, and send the signed transaction proposal containing the execution proof to the corresponding consensus node required by the consensus protocol.

[0079] Once the execution process is complete, the transaction proposal, including the execution result and proof of execution, is sent to the client, initiating the transaction commit phase. The overall process is as follows: Figure 2 As shown below, the specific implementation method will be described in detail with reference to the flowchart and examples.

[0080] When a consensus node receives the execution result from the execution node, it needs to determine the type of transaction. For internal transaction proposals, a pre-defined general consensus protocol is used among all consensus nodes within the same application to reach a consensus on the order of the transaction. For cross-application transaction proposals, a pre-defined general consensus protocol is used among all consensus nodes across all applications to reach a consensus on the order of the transaction.

[0081] After consensus nodes or all consensus nodes of the same application reach a consensus on the order of transaction proposals, each consensus node independently verifies the signature of the trusted execution environment and the write set of the transaction based on the partial Merkel-Patricia tree maintained on the chain. Each consensus node uses multiple threads to verify internal transactions and cross-application transactions in parallel.

[0082] After cross-application or internal transactions pass verification, the consensus nodes of the corresponding applications independently run conflict detection algorithms. These algorithms detect read / write conflicts by maintaining a distributed application collaboration index, and abort transactions that may lead to non-serialization. Once a transaction passes conflict detection, its proposal awaits block production. When similar transaction proposals waiting for block production meet the deterministic block production conditions, each consensus node packages the conflict-detected similar transactions into a block. Figure 3 The chain is organized in the form of a directed acyclic graph (DAG) ledger, and the Merkel-Patricia tree on the chain is updated based on the transactions and execution proofs in the blocks;

[0083] For blocks composed of cross-application transactions, the consensus node sends the block to all off-chain execution nodes. For blocks composed of internal transactions, the consensus node sends the block to the off-chain execution node of the corresponding application. After receiving the block, the execution node verifies the block and writes the updates to the state data of the transactions in the block into the database, thus completing the commit process.

[0084] This concludes the complete lifecycle of a cross-application transaction or an internal transaction.

[0085] This invention constructs a unified representation and publishing method for relational data, graph data, text data, and key-value data based on blockchain. This helps distributed applications in the manufacturing industry to collaborate securely and reliably through data sharing and value exchange while ensuring internal data confidentiality. The invention achieves high concurrency in the execution and consensus phases and employs a hybrid storage approach to compress storage overhead, achieving low overhead, high performance, and high scalability. Furthermore, it uses a distributed application collaboration index for concurrency control, ensuring consistency among nodes and serializability of commit results without requiring additional communication overhead. The EOV architecture blockchain used provides immutability and traceability, while Intel SGX technology provides security guarantees for off-chain transaction execution.

[0086] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0087] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1.A method for unified expression and publishing of multiple data types under blockchain, characterized in that: The method comprises a transaction execution phase and a transaction submission phase. The transaction execution phase comprises: S11.A client generates a blockchain transaction request within an application or across applications according to requirements, and sends the request to a corresponding on-chain consensus node of the application. S12.The consensus node determines the transaction type and forwards the transaction request to any execution node within the application. S13.The execution node classifies the transaction according to the transaction type after receiving the transaction request. S14.For an internal transaction request, the execution node calls a smart contract within a TEE, accesses internal data and public data of the corresponding application, and generates a read-write set according to the execution logic of the smart contract. For a cross-application transaction request, the execution node calls a smart contract within a TEE, only accesses all public data, and generates a read-write set according to the execution logic of the smart contract. S15.The execution node packages the read-write set and the execution proof provided by the TEE into a transaction proposal, signs the transaction proposal, and sends it to the consensus node within the same application. The transaction submission phase comprises: S21.After receiving the transaction proposal and its signature, the consensus node determines whether the transaction is an internal transaction or a cross-application transaction. S22.For an internal transaction proposal, a consensus is reached among all consensus nodes within the same application using a preset general consensus protocol. For a cross-application transaction proposal, a consensus is reached among all consensus nodes of all applications using a preset general consensus protocol. S23.After the consensus on the order of the transaction proposal is reached, each consensus node independently verifies the trusted execution environment signature and the write set of the transaction according to the partial Merkle-Patricia tree maintained by the consensus node, and each consensus node uses multiple threads to verify internal transactions and cross-application transactions in parallel. S24.After the legality of the transaction proposal is verified, the consensus node independently runs a conflict detection algorithm to detect read-write conflicts of the transaction by maintaining a distributed application collaboration index, and stops transactions that may cause non-serializable transactions. S25.After the transaction proposal passes the conflict detection, it waits for block generation. After the same type of transaction proposal reaches the deterministic block generation condition, each consensus node packages the same type of transaction that passes the conflict detection to generate a block, and updates the partial Merkle-Patricia tree on the chain according to the transactions and execution proofs in the block. S26.For a block composed of cross-application transactions, the consensus node sends the block to all off-chain execution nodes. For a block composed of internal transactions, the consensus node sends the block to the off-chain execution nodes of the corresponding application. S27.After receiving the block, the execution node verifies the block and writes the updates of the transactions in the block to the database to complete the submission process. 2.The method according to claim 1, characterized in that: The data types are relational data, graphical data, text data, and key-value data. 3.The method of claim 1, wherein the blockchain transaction types include internal transactions and cross-application transactions. 4.The method of claim 3, wherein the internal transactions follow an internal workflow of an application, read internal data and cross-application data, and only update internal data, and other execution nodes and consensus nodes of other applications do not participate in the internal transaction processing. 5.The method of claim 4, wherein the cross-application transactions are transactions that access only a public database, and a consensus of all consensus nodes of all applications is required in the life cycle of the cross-application transactions, and the cross-application transactions need to be verified and conflict detected by all consensus nodes, and the cross-application transactions only need to be executed by one execution node. 6.The method of claim 5, wherein the cross-application transactions and the internal transactions are executed in a trusted execution environment (TEE) of the execution node, and an execution proof of the execution result is generated by the TEE after the execution is completed. 7.The method of claim 6, wherein in the consensus process, each consensus node of each application independently detects conflicts of the internal transactions and the cross-application transactions by maintaining a distributed application collaboration index, and ensures serializability and consistency of the submission result without additional communication overhead. 8.The method of claim 7, wherein the relational data is expressed as a triple of a primary key, a table, and an attribute set. 9.The method of claim 8, wherein the off-chain database is any type of database, including a relational database, a graph database, a text database, and a key-value database. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​

Images