Cross-contract access method and device, computer equipment and storage medium

Abstract

The invention relates to a cross-contract access method and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: determining a to-be-executed first contract; starting a contract process, and executing the first contract through the contract process; in the process of executing the first contract, if a cross-contract data access condition exists, performing permission check for a second contract pointed by the data access through a permission controller to obtain a check result; and under the condition that the checking result represents that access is allowed, performing cross-contract state operation for the second contract through the authority controller to realize cross-contract data access. By adopting the method, the cross-contract access efficiency can be improved, so that the execution efficiency of the block chain is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a cross - contract access method, device, computer device, storage medium, and computer program product. Background Art

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer - to - peer transmission, consensus mechanism, and encryption algorithm. Due to the characteristics of decentralization, immutability of information, and autonomy of the blockchain, it has received more and more attention and applications.

[0003] With the popularization and application of the blockchain, the services connected to the blockchain are becoming more and more complex. A smart contract is a computer protocol designed to spread, verify, or execute a contract in an informatized manner. As a key module carrying services in the blockchain, it supports increasingly complex actual service requirements.

[0004] Currently, in multiple application scenarios such as supply chain finance, cross - chain asset trading, and data sharing, there are cross - contract access services. In traditional solutions, cross - contract access between smart contracts usually needs to call the method of another contract to achieve, that is, on the basis of the contract process of a currently started smart contract, another process or coroutine of a smart contract is pulled up and rescheduled for execution. Since rescheduling and executing a process takes relatively more time, the cross - contract access efficiency is low. Summary of the Invention

[0005] Based on this, it is necessary to provide a cross - contract access method, device, computer device, computer - readable storage medium, and computer program product that can improve the cross - contract access efficiency and thus enhance the execution efficiency of the blockchain for the above - mentioned technical problems.

[0006] In a first aspect, this application provides a cross - contract access method. The method includes:

[0007] Determine a first contract to be executed;

[0008] Start a contract process and execute the first contract through the contract process;

[0009] During the execution of the first contract, if there is a situation of cross - contract data access, then perform permission verification on a second contract pointed to by the data access through a permission controller to obtain a verification result;

[0010] In the case where the verification result indicates permission to access, perform a cross - contract status operation on the second contract through the permission controller to achieve cross - contract data access.

[0011] In a second aspect, the present application also provides a cross - contract access device. The device includes:

[0012] A contract determination module, configured to determine a first contract to be executed;

[0013] A process startup module, configured to start a contract process and execute the first contract through the contract process;

[0014] An access permission verification module, configured to, during the execution of the first contract, if there is a cross - contract data access situation, perform a permission verification on a second contract pointed to by the data access through a permission controller to obtain a verification result;

[0015] A cross - contract operation module, configured to, when the verification result indicates permission to access, perform a cross - contract status operation on the second contract through the permission controller to achieve cross - contract data access.

[0016] In a third aspect, the present application also provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the steps of the above - mentioned cross - contract access method are implemented.

[0017] In a fourth aspect, the present application also provides a computer - readable storage medium. On the computer - readable storage medium, a computer program is stored, and when the computer program is executed by a processor, the steps of the above - mentioned cross - contract access method are implemented.

[0018] In a fifth aspect, the present application also provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the above - mentioned cross - contract access method are implemented.

[0019] The above cross - contract access method, device, computer device, storage medium, and computer program product determine a first contract to be executed and start a contract process to execute the first contract through the contract process. During the execution of the first contract, if there is a cross - contract data access situation, the permission controller is used to check the permissions of the second contract pointed to by the data access, and a check result is obtained. When the check result indicates permission to access, the cross - contract status operation for the second contract can be performed through the permission controller to achieve cross - contract data access. During the cross - contract access process, there is no need to start a process or coroutine for the contract method used to execute the second contract. The permission control of cross - contract data access can be directly implemented through the permission controller, thus achieving cross - contract data access. In this way, excessive process or coroutine scheduling is avoided, the consumption of system resources can be reduced, and frequent scheduling execution and switching during cross - contract data access can also be avoided, improving the cross - contract access efficiency. At the same time, by using the permission controller to check and call cross - contract operations during contract execution, the security and controllability of data access can be ensured. Description of the Drawings

[0020] Figure 1 It is an application environment diagram of the cross - contract access method in an embodiment;

[0021] Figure 2 It is a schematic structural diagram of a blockchain node in an embodiment;

[0022] Figure 3 It is a schematic structural diagram of a blockchain node in another embodiment;

[0023] Figure 4 It is a schematic flow diagram of the cross - contract access method in an embodiment;

[0024] Figure 5 It is a schematic diagram of the transaction execution process in an embodiment;

[0025] Figure 6 It is a schematic flow diagram of the cross - contract status operation in an embodiment;

[0026] Figure 7 It is a schematic flow diagram of changing the trust mapping relationship in an embodiment;

[0027] Figure 8 It is a schematic diagram of the trust contract scope mapping relationship in an embodiment;

[0028] Figure 9 It is a flowchart of the cross - contract access method in an embodiment;

[0029] Figure 10 It is a block diagram of the structure of the cross - contract access device in an embodiment;

[0030] Figure 11 It is the internal structure diagram of a computer device in an embodiment. Detailed implementation manners

[0031] In order to make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0032] Before making specific descriptions, some terms related to the present application will be described first.

[0033] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain, in essence, is a decentralized database, a string of data blocks generated by using cryptographic methods, and each data block contains information of a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0034] The blockchain underlying platform can include processing modules such as user management, basic services, smart contracts, and operation monitoring. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining the generation of public and private keys (account management), key management, and maintaining the correspondence between the real identity of the user and the blockchain address (permission management), and under the authorization, supervising and auditing the transaction situations of certain real identities, and providing rule configuration for risk control (risk control and auditing); the basic service module is deployed on all blockchain node devices, used to verify the validity of business requests, and record them on the storage after consensus for valid requests. For a new business request, the basic service first performs interface adaptation parsing and authentication processing (interface adaptation), then encrypts the business information through a consensus algorithm (consensus management), transmits it to the shared ledger completely and consistently after encryption (network communication), and records and stores it; the smart contract module is responsible for the registration and issuance of contracts, contract triggering, and contract execution. Developers can define contract logic through a certain programming language, publish it to the blockchain (contract registration), trigger the execution according to the logic of the contract terms by calling keys or other events, complete the contract logic, and at the same time provide functions for contract upgrade and cancellation; the operation monitoring module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation during the product release process, and visual output of the real-time state during product operation, such as: alarm, detecting network conditions, monitoring the health status of node devices, etc.

[0035] The platform product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can build on these basic capabilities and overlay the characteristics of the business to complete the blockchain implementation of the business logic. The application service layer provides application services based on the blockchain solution for business participants to use.

[0036] Smart Contract: A smart contract is a computer protocol designed to facilitate, verify, or enforce the negotiation or performance of a contract in an informational way. Smart contracts allow for trusted transactions without the need for a third party, and these transactions are traceable and irreversible.

[0037] Block Ledger: The block ledger is the core data structure in the blockchain system, used to store and manage all confirmed blocks. The block ledger is organized in a chain structure, where each block contains a set of transactions, a block header (including metadata such as the hash value of the previous block, timestamp, etc.), and other information. The block ledger provides a public and immutable transaction history for the blockchain system, ensuring the transparency and consistency of the system.

[0038] State Data: State data is the data structure used to represent the current state of the blockchain system. State data includes the balances of all accounts, the states of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a certain point in time. In the blockchain system, state data is usually stored in the form of a Merkle tree or other cryptographic data structures to ensure its integrity and security.

[0039] Transaction Pool: The transaction pool (also known as the memory pool or mempool) is a data structure in the blockchain network used to store pending transactions that have not yet been packaged into blocks. When a transaction processing requester submits a new transaction to the blockchain network, the transaction first enters the transaction pool. When a blockchain node is preparing to generate a new block, it selects a certain number of transactions from the transaction pool for packaging. The transaction pool helps improve the processing capacity of the blockchain system and can also be used as a strategy to let miners preferentially select transactions with higher transaction fees for packaging, thereby increasing the miners' income.

[0040] Transaction Context: Transaction context refers to all the information and states involved in the entire execution process of a transaction from initiation to completion in the blockchain network. These information and states include, but are not limited to:

[0041] Transaction Initiator: The user or contract that initiates the transaction, with a unique identifier (such as an address).

[0042] Transaction Receiver: The target user or contract of the transaction, also with a unique identifier.

[0043] Transaction content: Operations involved in a transaction, such as contract method calls, parameters, data reading and writing, etc.

[0044] Transaction signature: A digital signature used to verify the identity of the transaction initiator.

[0045] Transaction status: The status during the execution of a transaction, such as Read Set, Write Set, etc. The Read Set represents the data read during the execution of the transaction, and the Write Set represents the data that needs to be updated after the transaction execution.

[0046] Transaction result: The output after the transaction execution is completed, such as return value, event, error message, etc.

[0047] Among them, the transaction context manager is responsible for managing this information and status to ensure the correct execution, isolation, and atomicity of the transaction. During the execution of the smart contract, the transaction context manager updates the Read Set and Write Set according to the logic of the contract code to ensure data consistency.

[0048] Cross - contract State Operation: Cross - contract State Operation refers to the process in a blockchain where one smart contract accesses or modifies the state data of another smart contract. In practical applications, there may be dependencies or a need to share data between smart contracts, so cross - contract state operations are required.

[0049] The data processing method based on blockchain provided by the embodiments of this application can be applied to an application environment as Figure 1 shown. Among them, the blockchain network can be composed of multiple blockchain nodes. As Figure 1 shown in the application environment, there are multiple blockchain nodes 102. Different blockchain nodes 102 can communicate with each other through a network. For each blockchain node 102, it can obtain a transaction sent by a transaction processing requester. Based on the transaction data of the transaction, the blockchain node 102 determines the first contract to be executed, starts a contract process, and executes the first contract through the contract process. During the execution of the first contract by the blockchain node 102, if there is a situation of cross - contract data access, the permission controller is used to check the permission of the second contract pointed to by the data access, and a check result is obtained. When the check result indicates permission to access, the blockchain node 102 performs a cross - contract state operation on the second contract through the permission controller to achieve cross - contract data access.

[0050] In some embodiments, as Figure 2As shown, it is a schematic structural diagram of a blockchain node in a blockchain. For each blockchain node in the blockchain, the architecture shown in Figure 2 can be deployed. Figure 2 In Figure 2 , the blockchain node may specifically include multiple functional modules such as a network module, a verification module, a transaction pool module, a scheduling execution and verification module, a consensus module, and a storage module.

[0051] Among them, the network module is responsible for handling communications between blockchain nodes, including sending and receiving transactions, consensus information, block data, etc. It ensures that information in the blockchain network can be transmitted and synchronized among various nodes.

[0052] The verification module is responsible for performing certificate verification and permission verification on transactions to ensure the legality and security of transactions.

[0053] The transaction pool module is responsible for storing transactions to be processed and providing transaction data for the blockchain node. The transaction pool module sorts transactions according to strategies such as transaction fees and priorities for subsequent packaging into blocks.

[0054] The scheduling execution and verification module is responsible for obtaining transactions from the transaction pool and performing scheduling execution.

[0055] Consensus module: The consensus module is responsible for reaching a consensus on newly generated blocks to ensure that the entire blockchain network reaches an agreement.

[0056] Storage module: The storage module is responsible for storing data of the blockchain node, including the block ledger and status data.

[0057] In some other embodiments, referring to Figure 3 shown, it is a schematic structural diagram of a blockchain node in another embodiment. Figure 3 In Figure 3 , further functional refinement is performed on some modules of the blockchain node, specifically including:

[0058] The verification module may include a certificate verification module and a permission verification module. The certificate verification module is responsible for verifying the identity of the transaction processing requester. By checking the digital certificate and signature of the transaction processing requester, it ensures the legality of the transaction; the permission verification module is responsible for checking whether the transaction processing requester has the permission to execute the transaction, such as contract deployment, contract call permission, etc.

[0059] The scheduling execution and verification module specifically includes the following sub-modules:

[0060] Block transaction packager: According to the transactions in the transaction pool, pack the transactions into blocks according to a certain strategy. This may involve considerations of factors such as transaction fees and priorities.

[0061] Virtual Machine Engine: Executes contract code. The virtual machine engine needs to support multiple programming languages and smart contract standards to execute various smart contracts on the blockchain.

[0062] Block Generator: Generates new blocks based on the packaged transactions and consensus rules.

[0063] Contract Repository: Stores and manages deployed contracts. The contract repository needs to support functions such as contract version management and upgrade.

[0064] Transaction Context Manager: Responsible for managing context information during transaction execution, including read sets, write sets, etc.

[0065] Contract Permission Controller: Also known as the permission controller, it can implement permission control for cross-contract access. The contract permission controller realizes the authorization and restriction of contract data access through trusted user mapping, trusted contract mapping, and fine-grained trusted contract mapping.

[0066] Contract Process Pool: Manages contract processes to improve execution efficiency. The contract process pool can reuse existing processes to avoid the overhead caused by frequent creation and destruction of processes.

[0067] The storage module includes a block ledger and state data. Block Ledger: The block ledger is responsible for storing the block data that has passed consensus, forming the entire blockchain. State Data: The state data is responsible for storing the state information on the blockchain node, such as contract execution results, account balances, etc.

[0068] Among them, the blockchain node 102 can be various types of computer devices, such as specifically a terminal or a server. The terminal can be but is not limited to various desktop computers, laptop computers, smartphones, tablets, Internet of Things devices, portable wearable devices, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, intelligent vehicle-mounted devices, etc. The portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The server can be implemented by an independent server or a server cluster composed of multiple servers, and can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms. The terminal and the server can be directly or indirectly connected through wired or wireless communication methods. The embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, intelligent transportation, assisted driving, etc.

[0069] In one embodiment, as Figure 4As shown, a cross-contract access method is provided, which is described by taking any blockchain node in the blockchain network as an example, and includes the following steps:

[0070] Step 402, determine the first contract to be executed.

[0071] Among them, the first contract is the contract to be called in the pending transaction received by the blockchain node.

[0072] Specifically, the scheduling execution and verification module of the blockchain node can obtain the pending transaction from the transaction pool module, and further determine the first contract to be called and the contract method in the called first contract from the transaction data included in the pending transaction. The transaction data may include various information such as the contract to be called, the contract method of the contract, parameters, timestamp, caller information, etc.

[0073] In some embodiments, a transaction is generated by a transaction request processor and sent to a blockchain node. After the verification module of the blockchain node verifies the legitimacy of the received transaction, the transaction that has passed the legitimacy verification is stored in the transaction pool module of the blockchain node. Then, the scheduling execution and verification module of the blockchain node can obtain the pending transactions from the transaction pool module to determine the first contract to be executed.

[0074] In some embodiments, the transaction processing requester refers to the party that initiates the business data processing request in the blockchain-based business processing process. The requester can be a terminal device, such as a terminal that can receive user operation information such as a mobile phone used by a user, or an application, a small program, etc. In addition, the terminal device can also be a terminal used by an organization or institution, such as a computer used by an institution to authenticate the characteristic information provided by the plaintiff, a computer used by an employer to authenticate the certificate provided by an applicant, etc.

[0075] In some embodiments, the verification module may perform certificate verification and authority verification for the received transaction. When the verification module performs certificate verification on the received transaction, it may check the digital certificate and signature of the party generating the transaction. If the digital certificate and signature are legal, the certificate verification is passed; when the verification module performs authority verification on the received transaction, it may verify the authority level and access rights of the party generating the transaction. If it is determined that the party generating the transaction has the authority to execute the transaction, the authority verification is passed. When both the certificate verification and the authority verification indicate that the verification is passed, it is determined that the legality verification is passed.

[0076] In some other embodiments, when the verification result of either the certificate verification or the permission verification indicates a failed verification, the execution process of the transaction is terminated. Specifically, it may include: if the certificate verification fails, a result indicating that the certificate verification fails is returned, and the execution process of the transaction is terminated; if the permission verification fails, a result indicating that the permission verification fails is returned, and the execution process of the transaction is terminated.

[0077] Step 404, start the contract process and execute the first contract through the contract process.

[0078] Among them, the contract process is a process stored in the process pool, and the process pool specifically refers to the contract process pool.

[0079] Specifically, the scheduling execution and verification module of the blockchain node can obtain an available contract process from the contract process pool, start the obtained contract process, and execute the first contract based on the started contract process, thereby processing the transaction by executing the first contract.

[0080] In some embodiments, during the process of processing the transaction by executing the first contract, the scheduling execution and verification module may include, but is not limited to, various operations such as transfer, query data, update status, data interaction, data access, etc.

[0081] In some embodiments, when the scheduling execution and verification module obtains a contract process from the contract process pool, it can obtain it based on the process resources, process status, process association relationship, etc. in the contract process pool. For example, the process association relationship includes the association relationship between the process and the contract, that is, each contract process in the contract process pool can respectively correspond to a matching contract. The scheduling execution and verification module can obtain the first contract identifier of the first contract to be executed, and based on the pre-set association relationship, determine the process in the contract process pool that matches the first contract identifier as the contract process.

[0082] In some embodiments, starting the contract process and executing the first contract through the contract process includes: obtaining an idle process from the process pool as the contract process; executing the statements in the contract method of the first contract through the contract process.

[0083] Among them, the idle process is a process that is not currently assigned to execute a contract or perform other tasks.

[0084] Specifically, the scheduling execution and verification module can obtain an idle process from the contract process pool and determine it as the contract process, and execute the statements in the contract method of the first contract through the contract process.

[0085] In the above embodiments, by reusing existing and idle processes, the blockchain node can avoid the overhead caused by frequently creating processes, reduce the resource consumption of the blockchain, and to a certain extent, can assist in improving the execution efficiency of the blockchain.

[0086] Step 406, during the execution of the first contract, if there is a cross-contract data access situation, the permission controller performs permission verification on the second contract pointed to by the data access to obtain a verification result.

[0087] Among them, cross-contract data access is a data operation process in a blockchain network where, during the execution of one contract, data of another contract needs to be accessed. The data operation process may include, but is not limited to, data acquisition, query, reading, and reading and writing.

[0088] In some embodiments, there are multiple scenarios that require cross-contract data access, such as supply chain finance, cross-chain asset trading, identity authentication and permission management, data markets and data sharing, and Internet of Things (IoT) device management, etc., which are multiple scenarios that require cross-contract operations.

[0089] The second contract is the contract indicated to be accessed in the contract method of the first contract during the execution of the contract method of the first contract. The data access of the first contract to the second contract may specifically include reading the data of the second contract or at least one of reading and writing the data of the second contract during the execution of the first contract.

[0090] The permission controller is the contract permission controller in the blockchain node. Through the permission controller, authorization and restriction of cross-contract data access can be achieved. The permission controller may specifically be a software component set in the blockchain node. When the blockchain node is started, the permission controller can be started, as well as other software components in the blockchain node, such as various functional modules like the transaction pool module and the verification module, so as to support actual business requirements.

[0091] Permission verification refers to the process of verifying whether there is permission to access another contract during the execution of any contract. Specifically, it may refer to the process of verifying whether there is permission to access the data of the second contract during the execution of the contract method of the first contract.

[0092] The verification result may include having access permission, not having access permission, etc. When it is determined that there is access permission to another contract during the execution of one contract, the verification result may further include the type of access permission. For example, the type of access permission may include read permission, read-write permission, write permission, etc.

[0093] Specifically, during the execution of the contract method of the first contract, the contract process can sequentially execute the statements of the contract method, determine the type of the statements, and determine whether there is a cross-contract data access situation based on the type of the statements. If there is a cross-contract data access situation, the contract process sends an interaction request, that is, a data access request, to the permission controller, and through the permission controller, performs a permission check on the second contract pointed to by the data access to determine whether the second contract can be accessed and how the second contract can be specifically accessed.

[0094] Step 408, in the case where the verification result indicates permission to access, perform a cross-contract status operation on the second contract through the permission controller to implement cross-contract data access.

[0095] Among them, the cross-contract status operation is a process of accessing or modifying the data of the second contract during the execution of the first contract.

[0096] Specifically, in the case where the verification result indicates permission to access, perform a read operation, a read-write operation, etc. on the second contract through the permission controller to implement cross-contract data access.

[0097] In some embodiments, when performing a cross-contract status operation, the permission controller can obtain and update the transaction status based on the context manager of the blockchain node to ensure the correct execution and isolation of the transaction.

[0098] In some embodiments, when the cross-contract status operation is a read operation, the permission controller can determine whether there is a read set matching the read operation in the context manager. If so, the permission controller can directly read the read set in the context manager. If there is no read set matching the read operation, the permission controller can read the read set matching the read operation from the state database, and then through the contract process, combine the obtained read set to execute the transaction.

[0099] In some embodiments, when the cross-contract status operation is a write operation, it means that the contract process can modify the data of the second contract read. The context manager can directly update the write set matching the write operation, and then can determine the data that needs to be updated in the state database after the transaction is executed.

[0100] In some embodiments, referring to Figure 5 As shown, it is a schematic diagram of the transaction execution process in a specific application, where Figure 5 The shown transaction execution process can be implemented based on Figure 3 the deployment architecture of the blockchain node in, and specifically can include the following steps:

[0101] After the transaction execution process starts, enter S501, and the user can specify the contract, method, parameters, etc. to be called through the terminal;

[0102] In S502, the terminal can package the above content to obtain the packaged content;

[0103] In S503, the terminal signs the above packaged content;

[0104] In S504, the terminal sends the above packaged content and signature to the blockchain node together. Specifically, the terminal can generate a transaction processing request based on the content and signature, and send the transaction processing request to the blockchain node;

[0105] In S505, the network module of the blockchain node receives the above transaction processing request;

[0106] In S506, the authentication module of the blockchain node performs certificate verification and signature verification on the above transaction processing request. If the verification passes, it enters S507; if the verification fails, it returns the result that the signature verification fails;

[0107] In S507, the authentication module performs permission verification on the above transaction processing request. If the verification passes, it enters S508; if the verification fails, it returns the result that the permission verification fails;

[0108] In S508, the transaction pool module receives the transaction to be processed;

[0109] In S509, the scheduling execution and verification module can periodically obtain transactions from the transaction pool module to determine the transactions to be processed;

[0110] In S510, the scheduling execution and verification module obtains an available contract process from the contract process pool to execute the transaction to be processed;

[0111] In S511, the contract process determines the contract to be called and the contract method in the contract to be called based on the obtained transaction to be processed, and executes the statements of the called contract method line by line;

[0112] In S512, during the execution of the contract process, it will determine whether there is a situation of cross - contract data access. If there is a situation of cross - contract data access, it will perform permission inspection in combination with S513. That is, in S513, when there is a situation of cross - contract data access, another contract process will not be started, but the permission inspection will be performed through the contract permission controller. After the permission inspection passes, in S514, direct read or write operations will be performed, that is, directly view the data of another contract or write data;

[0113] In S515, when all transactions in any block are executed, the consensus module of the blockchain node can initiate a consensus operation to determine whether the block consensus passes. If it passes, it goes to S516; otherwise, it directly ends the transaction execution process;

[0114] S516, all blockchain nodes append the block to the block ledger;

[0115] S517, all blockchain nodes update the data in the block to the state data, such as the latest result obtained from the contract execution.

[0116] In the above cross - contract access method, the first contract to be executed is determined and the contract process is started to execute the first contract through the contract process. During the execution of the first contract, if there is a cross - contract data access situation, the permission controller is used to check the permission of the second contract pointed to by the data access to obtain a check result. When the check result indicates permission to access, the cross - contract state operation for the second contract can be performed through the permission controller to achieve cross - contract data access. During the cross - contract access process, there is no need to start a process or coroutine for executing the contract method of the second contract. The permission control of cross - contract data access can be directly achieved through the permission controller, thus realizing cross - contract data access. In this way, excessive process or coroutine scheduling can be avoided, the consumption of system resources can be reduced, and frequent scheduling execution and switching during cross - contract data access can also be avoided, improving the cross - contract access efficiency. At the same time, by using the permission controller to check and call cross - contract operations during the contract execution process, the security and controllability of data access can be ensured.

[0117] In some embodiments, the cross - contract access method further includes: during the execution of the first contract, determining whether the currently executed statement belongs to a cross - contract state operation statement; if it belongs to a cross - contract state operation statement, it is determined that there is a cross - contract data access situation.

[0118] Among them, the cross - contract state operation statement is a statement in the contract method, used to represent that cross - contract data access is required. In addition to the cross - contract state operation statement in the contract method, there can also be ordinary statements, statements for returning results, etc. Ordinary statements refer to statements that can be completed by the currently started contract process itself, and the statement for returning results is the statement for returning the result of the completed transaction execution.

[0119] Specifically, the contract process can execute the statements of the contract method of the first contract called line by line and determine whether the current statement is a cross - contract state operation statement. If it is a cross - contract state operation statement, it is determined that there is a cross - contract data access situation.

[0120] In some embodiments, when the contract process determines that the current statement is an ordinary statement, it can directly execute the current statement, and after the execution is completed, call the next statement of the current statement again until it stops when a preset stop condition is reached. For example, it can stop when all the statements of the contract method of the first contract have been executed.

[0121] In some other embodiments, when the contract process determines that the current statement is a statement for the return result, the contract process may return the result of the completed transaction execution to the scheduling execution and verification module. When the scheduling execution and verification model receives the result of the completed transaction execution, it determines that the transaction execution is completed.

[0122] In some embodiments, each statement in the contract method carries a statement identifier, so that different types of statements can be distinguished by the statement identifier. When the contract process determines that the statement identifier of the currently executed statement belongs to the target identifier, it determines that the current statement is a cross-contract status operation statement, where the target identifier may be the identifier corresponding to the set cross-contract status operation statement.

[0123] In the above embodiments, the blockchain node determines whether the currently executed statement is a cross-contract status operation statement, and when it determines that the currently executed statement is a cross-contract status operation statement, it determines that there is a cross-contract data access situation. Thus, by only judging the type of the currently executed statement, it can be determined whether there is a cross-contract data access situation, which can improve the cross-contract access efficiency.

[0124] In some embodiments, the permission controller performs permission verification on the second contract pointed to by the data access, and obtains a verification result, including: querying the pre-set trust mapping relationship through the permission controller; determining the second contract pointed to by the cross-contract data access; and performing access permission verification based on the trust mapping relationship and the second contract to obtain the verification result.

[0125] Among them, the trust mapping relationship is used to determine the access permission, the type of access permission, etc. in the process of cross-contract data access. When setting the trust mapping relationship, it can be set from multiple dimensions in the blockchain network, such as from the dimension of the transaction initiator, the dimension of the contract, the dimension of the transaction type, or the dimension of the transaction scenario, etc., without limitation here.

[0126] Specifically, when the contract process determines that there is a cross-contract data access situation, it can query the pre-set trust mapping relationship and the second contract pointed to by the cross-contract data, and determine whether the second contract is allowed to be accessed according to the trust mapping relationship, and further determine the specific type of access permission in the case that the second contract is allowed to be accessed.

[0127] In some embodiments, the trust mapping relationship may specifically include any object involved in the blockchain network, the object trusted by the object, and the permissions of the object trusted by it, etc. The specifically selected object is related to the setting dimension of the mapping relationship. For example, if the trust mapping relationship is set from the user dimension, the trust mapping relationship may be composed of any user, the user trusted by the user, the permissions of the user trusted by it, etc. For another example, if the trust mapping relationship is set from the contract dimension, the trust mapping relationship may be composed of a certain contract, the contract trusted by the contract, and the permissions of the contract trusted by the contract. For another example, if the mapping relationship is set from the dimension of the transaction type, the trust mapping relationship may be composed of a certain trading platform, the trading platform trusted by the trading platform, and the permissions of the trading platform trusted by the trading platform.

[0128] In some embodiments, when setting the trust mapping relationship, the blockchain node may represent different users based on the user identifier and represent different contracts based on the contract identifier. For the user identifier, contract identifier, etc., any identifier that can be used for identification, such as letters, numbers, and feature codes, can be used for setting, and no limitation is made here.

[0129] In the above embodiments, by obtaining the pre-set mapping relationship and the second contract pointed to by the data across contracts, the blockchain node can accurately check the access permissions, which can improve the execution efficiency of the blockchain and reduce resource consumption.

[0130] In some embodiments, the trust mapping relationship includes at least one of the trust user mapping relationship or the trust contract mapping relationship; based on the trust mapping relationship and the second contract, access permission checking is performed to obtain a checking result, including: performing access permission checking based on the trust user mapping relationship and the second contract; and / or, performing access permission checking based on the trust contract mapping relationship and the second contract to obtain a checking result.

[0131] Among them, the trust user mapping relationship is a mapping relationship set based on the user dimension, that is, from the dimension of the contract caller in the transaction; the trust contract mapping is a mapping relationship set from the contract dimension.

[0132] Specifically, when the permission controller conducts access permission verification based on the trust mapping relationship, it can adaptively select or combine different trust mapping relationships in combination with the actual transaction scenario, transaction content, cross-contract access efficiency, etc., to complete the access permission verification. Specifically, the permission controller can conduct access permission verification only through the trusted user mapping relationship and the second contract to obtain the verification result; it can also be that the permission controller conducts access permission verification only through the trusted contract mapping relationship and the second contract to obtain the verification result; it can also be that the permission controller combines the trusted contract mapping relationship, the trusted user mapping relationship and the second contract to conduct access permission verification to obtain the verification result.

[0133] In some embodiments, when establishing the trusted user mapping relationship, it can be established based on the contract creator; for different contract creators, the users they trust can be the same or different. When establishing the trusted user mapping relationship, it can be adaptively adjusted in combination with the actual transaction scenario, transaction platform, transaction type, etc. For example, for contract creator 1, the users it trusts can include two users, such as user 2 and user 3; for contract creator 2, the user it trusts can include one user, such as only user 2.

[0134] In other embodiments, for the same contract creator, the types of access permissions corresponding to the users it trusts can be different. For example, for contract creator 1, the users it trusts can include two users. For example, the type of access permission for user 2 is read / write, and for user 3, the type of access permission is write.

[0135] In some embodiments, when establishing the trusted contract mapping relationship, it can be established based on the contract; for different contracts, the contracts they trust can be the same or different. When establishing the trusted contract mapping relationship, it can be adaptively adjusted in combination with the actual transaction scenario, transaction platform, transaction type, etc. For example, for contract 1, the contract it trusts can include one contract, such as contract 2; for contract 2, the contracts it trusts can include two contracts, such as contract 3 and contract 4.

[0136] In other embodiments, for the same contract, the types of access permissions corresponding to the contracts it trusts can be different. For contract 2, the contracts it trusts include two contracts, such as contract 3 and contract 4. The type of access permission for contract 3 is read / write, and for contract 4, the type of access permission is write.

[0137] In some embodiments, when the permission controller checks the access permission based on the trusted user mapping relationship and the second contract, if it determines that the first contract does not have the permission to access the second contract, it ends the execution process of the current statement and executes the next statement of the current statement; if it determines that the first contract has the permission to access the second contract, the permission controller can further determine the type of access permission for the second contract based on the trusted user mapping relationship to obtain the verification result.

[0138] In other embodiments, if the permission controller determines, based on the trusted user mapping relationship, that the first contract has the permission to access the second contract, the permission controller can further determine whether the parameter identifier corresponding to the cross-contract data access is within the permitted access range of the second contract based on the pre-set trusted contract range mapping relationship. If it is within the set permitted range, it determines the type of access permission corresponding to the parameter identifier; if it is not within the set permitted range, it can still determine that the first contract does not have the permission to access the second contract, end the execution process of the current statement, and execute the next statement of the current statement. By combining the trusted contract range mapping relationship for another permission check, the cross-contract data access is not only limited to the authorization and restriction at the contract level, which can meet the requirements in complex scenarios and make the access control between contracts more flexible and secure.

[0139] In some embodiments, when the permission controller determines, based on the trusted contract mapping relationship, that the first contract does not have the permission to access the second contract, it ends the execution process of the current statement and executes the next statement of the current statement; if it determines that the first contract has the permission to access the second contract, the permission controller can further determine the type of access permission for the second contract based on the trusted contract mapping relationship to obtain the verification result.

[0140] In other embodiments, if the permission controller determines, based on the trusted contract mapping relationship, that the first contract has the permission to access the second contract, the permission controller can further determine whether the parameter identifier corresponding to the cross-contract data access is within the permitted access range of the second contract based on the pre-set trusted contract range mapping relationship. If it is within the set permitted range, it determines the type of access permission corresponding to the parameter identifier; if it is not within the set permitted range, it can still determine that the first contract does not have the permission to access the second contract, end the execution process of the current statement, and execute the next statement of the current statement. By combining the trusted contract range mapping relationship for another judgment, the cross-contract data access is not only limited to the authorization and restriction at the contract level, which can meet the requirements in complex scenarios and make the access control between contracts more flexible and secure.

[0141] In some embodiments, the permission controller may perform access permission verification in combination with the trusted user mapping relationship, the trusted contract mapping relationship, and the second contract. For example, the permission controller may perform access permission verification based on the trusted user mapping relationship to obtain a first verification result, perform verification based on the trusted contract mapping relationship to obtain a second verification result, and combine the first verification result and the second verification result to obtain a verification result.

[0142] For another example, the permission controller may first perform access permission verification based on the trusted user mapping relationship and the second contract. When the determined verification result indicates that the first contract does not have access permission, the permission controller may then perform access permission verification based on the trusted contract mapping relationship to determine whether the second contract allows the first contract to access.

[0143] For another example, the permission controller may first perform access permission verification based on the trusted contract mapping relationship and the second contract. When the determined verification result indicates that the first contract does not have access permission, the permission controller may then perform access permission verification based on the trusted user mapping relationship to determine whether the second contract allows the first contract to access.

[0144] In other embodiments, when the permission controller determines, in combination with the trusted user mapping relationship and the trusted contract mapping relationship, that the first contract has access permission to the second contract, the permission controller may still further determine, based on the pre-set trusted contract scope mapping relationship, whether the parameter identifier corresponding to the cross-contract data access is within the allowed access scope of the second contract. If it is within the set allowed access scope, the permission controller determines the type of the access permission corresponding to the parameter identifier; if it is not within the set allowed scope, the permission controller may still determine that the first contract does not have permission to access the second contract.

[0145] In some embodiments, referring to Figure 6 shown, it is a schematic flowchart of a cross-contract status operation in an embodiment. Among them, Figure 6 the cross-contract status operation process shown may be implemented based on Figure 3 the deployment architecture of the blockchain nodes in, and specifically may include the following steps:

[0146] After the cross-contract status operation process starts, it enters S601, and the contract process executes the statements of the contract method called by the transaction line by line;

[0147] S602, the contract process determines whether the current statement is a cross-contract status operation statement. If so, it goes to S604; otherwise, it goes to S603;

[0148] S603, the contract process determines whether the current statement is a statement for returning a result. If so, it goes to S607; otherwise, it goes to S605;

[0149] S604, the contract process sends an interaction request to the permission controller;

[0150] S605, the current statement is an ordinary statement, that is, a statement that the contract process can complete by itself. The contract process executes the current statement and returns to S601;

[0151] S606, the contract permission controller checks the trusted user mapping to see if the contract creator being operated on trusts the current user and if the permissions are satisfied. If so, go to S611; otherwise, go to S608;

[0152] S607, the scheduling execution and verification module receives the result of the completion of the contract process transaction execution and goes to S609;

[0153] S608, the contract permission controller checks the trusted contract mapping to see if the contract being operated on trusts the current contract and if the permissions are satisfied. If so, go to S611; otherwise, go to S610;

[0154] S609, the transaction execution is completed, and it ends;

[0155] S610, return an error that the access permission is not satisfied and return to S601;

[0156] S611, the permission controller obtains and updates the transaction status from the transaction context manager;

[0157] S612, if the current operation is a read operation, go to S613; otherwise, go to S616;

[0158] S613, check if there is a read set in the transaction context manager. If so, go to S614; otherwise, go to S615;

[0159] S614, the transaction context manager directly returns the read set result, and the transaction context returns the result;

[0160] S615, the transaction context manager obtains the read set result from the status database, and the transaction context returns the result;

[0161] S616, the transaction context manager updates the write set, and the transaction context returns the result.

[0162] In the above embodiments, the permission controller can determine whether the first contract has the access permission to the second contract through at least one of the trusted user mapping relationship or the trusted contract mapping relationship, and directly implement the permission control of cross-contract data access through the permission controller, so as to achieve cross-contract data access. In this way, excessive process or coroutine scheduling can be avoided, the consumption of system resources can be reduced, and frequent scheduling execution and switching during cross-contract data access can also be avoided, improving the cross-contract access efficiency.

[0163] In some embodiments, access permission verification is performed based on the trusted user mapping relationship and the second contract, including: obtaining the caller information of the caller who invokes the first contract and the creator information of the creator of the second contract; determining whether the creator of the second contract trusts the caller based on the caller information, the creator information, and the trusted user mapping relationship.

[0164] Among them, the caller information is used to identify the caller of the first contract; the creator information is used to identify the creator of the second contract.

[0165] Specifically, the permission controller can obtain the caller information and the creator information, and determine whether the caller of the first contract is a user trusted by the creator of the second contract in the trusted user mapping relationship based on the caller information, the creator information, and the trusted user mapping relationship.

[0166] In a specific embodiment, the permission controller can determine whether there is a caller of the first contract among the users trusted by the creator of the second contract based on the trusted user mapping relationship. Specifically, it can find the user information of the trusted user corresponding to the creator information in the trusted user mapping relationship based on the creator information. Further, the permission controller can match the caller information with the determined user information of the trusted user to determine whether the caller of the first contract is a user trusted by the creator of the second contract. For example, if the caller information includes a caller identifier and the user information includes a user identifier, the permission controller can determine whether there is a user identifier that is the same as the caller identifier, and then determine that the caller of the first contract is a user trusted by the creator of the second contract when it is determined that there is a user identifier that is the same as the caller identifier.

[0167] In the above embodiments, the permission controller can quickly determine whether the first contract has the access permission to access the second contract based on the trusted user mapping relationship, which can not only reduce the consumption of system resources but also improve the cross - contract access efficiency.

[0168] In some embodiments, access permission verification is performed based on the trusted contract mapping relationship and the second contract, including: obtaining the first contract identifier of the first contract and the second contract identifier of the second contract; determining whether the second contract trusts the first contract based on the first contract identifier, the second contract identifier, and the trusted contract mapping relationship.

[0169] Among them, the first contract identifier is used to identify the first contract, and the second contract identifier is used to identify the second contract. The first contract identifier and the second contract identifier can be identified by any identifier such as letters, numbers, and feature codes, and are not limited herein.

[0170] Specifically, the permission controller may obtain the first contract identifier and the second contract identifier, and based on the first contract identifier, the second contract identifier, and the trust contract mapping relationship, determine whether the first contract exists in the trust contracts trusted by the second contract in the trust contract mapping relationship. If it exists, it is determined that the second contract trusts the first contract; if it does not exist, it is determined that the second contract does not trust the first contract. When it is determined that the second contract trusts the first contract, it indicates that the first contract has the permission to access the second contract; when it is determined that the second contract does not trust the first contract, it indicates that the first contract does not have the permission to access the second contract.

[0171] In the above embodiment, the permission controller can quickly determine whether the first contract has the access permission to the second contract based on the trust contract mapping relationship, which can not only reduce the consumption of system resources but also improve the cross-contract access efficiency.

[0172] In some embodiments, the trust mapping relationship includes a trust contract scope mapping relationship. The access permission verification is performed based on the trust mapping relationship and the second contract, and the verification result includes: determining the parameter identifier corresponding to the cross-contract data access; if it is determined based on the trust contract scope mapping relationship that the first contract is a contract trusted by the second contract and the parameter identifier is within the allowed access range of the second contract, it is determined that the verification result is allowed access.

[0173] Among them, the trust contract scope mapping relationship is a more fine-grained trust mapping relationship set on the basis of the trust contract mapping, that is, a fine-grained trust contract mapping relationship. The trust contract scope mapping relationship sets the allowed access range of the contract, that is, it stipulates which parameters of a certain contract are allowed to be read by another contract or allowed to be read and written by another contract. When setting the allowed range of the contract, it can be adaptively set based on the business type, transaction scenario, transaction party type, contract type, etc. in the blockchain network.

[0174] The parameter identifier is used to identify the type of the parameter to be actually processed in the cross-contract data access. The parameter identifier can be identified by any identifier such as letters, numbers, and feature codes, and there is no limitation here.

[0175] Specifically, the permission controller may obtain the first contract identifier and the second contract identifier, and based on the first contract identifier, the second contract identifier, and the trust contract scope mapping relationship, determine whether the first contract exists in the trust contracts trusted by the second contract in the trust contract scope mapping relationship. If it exists, it is determined that the second contract trusts the first contract; if it does not exist, it is determined that the second contract does not trust the first contract.

[0176] Further, based on the second contract trusting the first contract, the permission controller will also determine whether the parameter identifier is within the permitted access range of the second contract based on the parameter identifier corresponding to the cross-contract data access and the mapping relationship of the trusted contract scope. When it is determined that the parameter identifier is within the permitted access range of the second contract, the verification result is permission to access.

[0177] In some embodiments, in the mapping relationship of the trusted contract scope, the permitted access range of a contract can be set based on a key (KEY), letters, numbers, etc. For example, when using a KEY to set the permitted access range, the permitted access range can be the key range determined by the KEY.

[0178] In some embodiments, for the same contract, among the contracts it trusts, the permitted access ranges can be set differently, or of course, the same; correspondingly, the types of access permissions of the contracts trusted by the same contract can be the same or different.

[0179] In some embodiments, referring to Figure 7 the shown mapping relationship of the trusted contract scope, for Contract 1, the contracts it trusts can include Contract 3 and Contract 4. For Contract 3, the key range of the contracts it trusts is Key 1 - Key 5; for Contract 4, the key range of the contracts it trusts is Key 7. For Contract 2, the contracts it trusts can include Contract 1. When the key range of the trusted contract of Contract 1 is Key 8 - Key 12, the permission is read / write, and when the key range of the trusted contract is Key 101, the permission is read / write.

[0180] In other embodiments, in the case of cross-contract data access, if the permission controller determines that Contract 1 is a trusted contract of Contract 2, the permission controller can further determine whether the parameter identifier corresponding to the cross-contract data access is within the permitted range. For example, as shown in Figure 7 When the parameter identifier is Key 7, it means that the parameter identifier is not within the permitted range, and it is determined that Contract 1 does not have the access permission to Contract 2. When the parameter identifier is Key 9, it means that the parameter identifier is within the permitted range, and it is determined that Contract 1 has the access permission to Contract 2, and the type of access permission is read / write.

[0181] In the above embodiments, in the above embodiments, the permission controller can determine whether the first contract has the access permission to the second contract based on the mapping relationship of the trusted contract scope. The mapping relationship of the trusted contract scope supports permission verification according to the fine-grained permitted range, making the access control between contracts more flexible and secure.

[0182] In some embodiments, the cross - contract access method further includes: obtaining a transaction for changing the trust mapping relationship; if the trust mapping relationship to be changed is a trust user mapping relationship, updating the contract creator trusted by the initiator of the transaction based on the transaction content; if the trust mapping relationship to be changed is a trust contract mapping relationship, updating the trust contract of the contract created by the initiator of the transaction based on the transaction content; if the trust mapping relationship to be changed is a trust contract scope mapping relationship, updating at least one of the following based on the transaction content: the trust contract of the contract created by the initiator of the transaction, the permitted access scope of the trust contract of the contract created by the initiator of the transaction.

[0183] Specifically, when a blockchain node receives a transaction for changing the trust mapping relationship, it can first determine the type of the trust mapping relationship to be changed, and update the trust mapping relationship according to the determined type of the trust mapping relationship.

[0184] In some embodiments, if the trust mapping relationship is a trust user mapping relationship, the blockchain node can determine the initiator of the transaction, generate a write set for the transaction to change the trust user mapping relationship, and based on the write set, update the contract creator trusted by the initiator of the transaction in the historical trust user mapping relationship.

[0185] In some embodiments, if the trust mapping relationship is a trust contract mapping relationship, the blockchain node can determine the contract created by the initiator of the transaction, generate a write set for the transaction to change the trust contract mapping relationship based on the transaction content, and based on the write set, update the trust contract of the contract created by the initiator of the transaction in the historical trust contract mapping relationship.

[0186] In some embodiments, if the trust mapping relationship is a trust contract scope mapping relationship, the blockchain node can determine the contract created by the initiator of the transaction, generate a write set for the transaction to change the trust contract scope mapping relationship based on the transaction content, and based on the write set, update at least one of the trust contract of the contract created by the initiator of the transaction and the permitted access scope of the trust contract of the contract created by the initiator of the transaction in the historical trust contract scope mapping relationship.

[0187] In the above - mentioned embodiments, the blockchain node can change each trust mapping relationship according to the actual needs, thereby improving the flexibility and security in the cross - contract access process.

[0188] In some embodiments, as Figure 8 shown, it is a schematic flowchart of changing the trust mapping relationship in an embodiment, where Figure 8 the shown process of changing the trust mapping relationship can be implemented based on the deployment architecture of the blockchain node in Figure 3 and specifically may include the following steps:

[0189] S801, the user can specify the trust mapping relationship to be changed through the terminal;

[0190] S802, the user can pack the parameters involved in S801 through the terminal to obtain the packed content;

[0191] S803, the user can sign the above-mentioned packed content through the terminal;

[0192] S804, the user can generate a transaction processing request for the above-mentioned packed content and signature through the terminal, and send the transaction processing request to the blockchain node;

[0193] S805, the network module of the blockchain node receives the above-mentioned transaction processing request;

[0194] S806, the authentication module of the blockchain node verifies the certificate and signature of the above-mentioned transaction processing request; if the verification passes, go to S807, if the certificate and signature verification fails, go to S818, and return the result of signature verification failure.

[0195] S807, the authentication module verifies the permissions of the above-mentioned request. If the verification passes, go to S808. If the permission verification fails, enter S817 and return the result of permission verification failure.

[0196] S808, the transaction pool module receives this transaction;

[0197] S809, the scheduling execution and verification module periodically fetches transactions from the transaction pool and fetches this transaction;

[0198] S810, if the mapping to be changed is the trusted user mapping relationship, the scheduling execution and verification module generates a change write set for the trusted user mapping, and the user ID (Identity document) needs to be the current user;

[0199] S811, if the mapping to be changed is the trusted contract mapping relationship, the scheduling execution and verification module generates a change write set for the trusted contract mapping, and the contract needs to be created by the current user;

[0200] S812, if the mapping to be changed is the fine-grained trusted contract mapping relationship, that is, the trusted contract scope mapping relationship, the scheduling execution and verification module generates a change write set for the trusted contract mapping, and the contract needs to be created by the current user;

[0201] S813, store this transaction in the block and send it to all blockchain nodes through the consensus module for consensus;

[0202] S814, determine whether the consensus passes. If it does, go to S815; otherwise, end the process;

[0203] S815, all blockchain nodes append the block to the block ledger;

[0204] S816, all blockchain nodes update the data in the block to the state data, such as the latest result obtained from contract execution;

[0205] S817, return the result that the permission verification fails;

[0206] S818, return the result that the signature verification fails.

[0207] In some embodiments, cross - contract state operations for the second contract are performed through a permission controller, including: if the cross - contract state operation for the second contract is a read operation, the permission controller determines whether there is a read set in the context manager that matches the read operation; if so, directly return the read set result, otherwise, obtain the read set result from the state database through the context manager.

[0208] Specifically, when the cross - contract state operation is a read operation, the permission controller can determine whether there is a read set in the transaction context manager. If there is a read set, the transaction context manager directly returns the read set result, so that there is no need to obtain the read set from the state database, which can improve the cross - contract access efficiency. If there is no read set in the transaction context manager, then obtain the read set result from the state database.

[0209] In the above - mentioned embodiments, during the process of the permission controller performing cross - contract state operations for the second contract, for a read operation, the permission controller can first determine whether there is a corresponding read set in the transaction context manager. If so, the transaction context manager directly returns the read set result, which can improve the cross - contract access efficiency.

[0210] In some embodiments, cross - contract state operations for the second contract are performed through a permission controller, including: if the cross - contract state operation for the second contract is a read - write operation, the context manager is instructed to update the write set that matches the read - write operation in the state database.

[0211] Specifically, when the cross - contract state operation for the second contract is a read - write operation, the data in the second contract can be changed, and the permission controller can instruct the context manager to update the transaction execution result obtained after the read - write operation in the state database.

[0212] In the above - mentioned embodiments, for the case of a read - write operation, the permission controller can instruct the context manager to update the write set that matches the read - write operation in the state database, so that the transaction execution result on the blockchain can be updated in a timely manner.

[0213] Taking an actual application scenario as an example, the cross - contract access method of the present application will be described in detail as follows:

[0214] Taking the cross - contract access method provided by the present application applied in the supply chain finance scenario as an example, in the supply chain finance scenario, multiple participants (such as suppliers, manufacturers, logistics companies, and financial institutions) need to share and access each other's data. The cross - contract access method provided by the present application can ensure that each participant can quickly access the data of other contracts on the premise of ensuring data security and privacy, improving the efficiency of the entire supply chain finance system.

[0215] Refer to Figure 9 As shown, the supplier can send the transaction n to be processed to the blockchain node. The transaction n to be processed can include various information such as the transaction ID, the contract to be called by the supplier, the contract method to be called, parameters, caller information, and timestamp.

[0216] Based on the received transaction to be processed, the blockchain node sends the transaction to be processed to the contract process for execution, that is, starts the contract process to execute the transaction to be processed. During the processing, the contract specified in the transaction and the contract method will be called, and then the statements in the method will be executed.

[0217] During the execution of the statements, there may be cross - contract state operation statements, that is, it is necessary to call other contracts to process the transaction. Here, it is not necessary for the contract process to start a new contract process or send a message to a new contract process. It only needs to query the trust mapping relationship through the permission controller. When it is determined that the current contract is allowed to access the new contract based on the trust user mapping relationship and the trust contract mapping relationship, the management and execution of the transaction context can be carried out.

[0218] Among them, Figure 9 the trust user mapping relationship in includes the user ID item, the trusted user ID item, and permissions. For user 1, its trusted users include user 2 and user 3. The permission of user 2 is read, and the permission of user 3 is read - write; for user 2, its trusted user includes user 1, and the permission of user 1 is read.

[0219] Figure 9 the trust contract mapping relationship in includes the contract name item, the trusted contract name item, and permissions. For contract 1, its trusted contracts include contract 3 and contract 4. The permission of contract 3 is read - write, and the permission of contract 4 is read; for contract 2, its trusted user includes contract 1, and the permission of contract 1 is read.

[0220] Among them, for each transaction, in the transaction context manager, the corresponding read set and write set are recorded. Among them, the read set may include Contract 1 - Parameter ID 1; Contract 2 - Parameter ID 2; and the write set may include Contract 1 - Parameter ID 1 - Parameter 1; Contract 2 - Parameter ID 1 - Parameter 1. After the transaction execution is completed, the data in the status database is updated.

[0221] Among them, in addition to the supply chain finance scenario, the cross - contract access method provided by this application can also be applied to multiple scenarios such as cross - chain asset transactions, identity authentication and permission management, data markets and data sharing.

[0222] Among them, in the blockchain asset transaction scenario, users may need to exchange assets on different chains. The cross - contract access method provided by this application can achieve efficient cross - contract state operations, enabling users to perform fast and secure asset transfer and transactions between contracts on different chains.

[0223] Identity authentication and permission management: In multiple application scenarios, users need to perform identity authentication and permission management for different systems or platforms. The cross - contract access method provided by this application can achieve fine - grained management of user identities and permissions, enabling users to perform secure and convenient identity authentication and permission control between different systems or platforms.

[0224] Data markets and data sharing: In the data market and data sharing scenarios, data providers and consumers need to exchange data while ensuring data security and privacy. The cross - contract access method provided by this application enables data providers to flexibly authorize data consumers to access specific data while ensuring data security.

[0225] Internet of Things (IoT) device management: In the IoT scenario, a large number of devices need to perform data exchange and device control. The cross - contract access method provided by this application can achieve fast device data exchange, and fine - grained access control can ensure that devices perform data access and control while ensuring security.

[0226] The cross - contract access method provided by this application realizes the ability to directly read and write data between contracts, greatly improving the execution efficiency and reducing resource consumption. At the same time, through the permission controller, the mapping of trusted users, the mapping of trusted contracts, and the fine - grained mapping of trusted contracts are realized, ensuring the security and controllability of data access. This solution not only improves the performance of blockchain applications but also provides strong support for contract interoperability in complex scenarios, with broad application prospects.

[0227] It should be understood that although the steps in the flowcharts involved in the above-described embodiments are sequentially shown according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this document, there is no strict order limit for the execution of these steps, and these steps can be executed in other orders. Moreover, at least some of the steps in the flowcharts involved in the above-described embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least some of the steps or stages in other steps or other steps.

[0228] Based on the same inventive concept, an embodiment of the present application further provides a cross-contract access device for implementing the cross-contract access method described above. The implementation solution provided by this device for solving problems is similar to the implementation solution described in the above method. Therefore, the specific limitations in one or more embodiments of the cross-contract access device provided below can refer to the limitations on the cross-contract access method in the above text, and will not be repeated here.

[0229] In one embodiment, as Figure 10 shown, a cross-contract access device 1000 is provided, including: a contract determination module 1002, a process startup module 1004, a permission verification module 1006, and a cross-contract operation module 1008, where:

[0230] The contract determination module 1002 is used to determine the first contract to be executed.

[0231] The process startup module 1004 is used to start the contract process and execute the first contract through the contract process.

[0232] The permission verification module 1006 is used to, during the execution of the first contract, if there is a cross-contract data access situation, perform permission verification on the second contract pointed to by the data access through the permission controller to obtain a verification result.

[0233] The cross-contract operation module 1008 is used to, when the verification result indicates permission to access, perform cross-contract status operations on the second contract through the permission controller to achieve cross-contract data access.

[0234] In some embodiments, the contract determination module 1004 is further used to obtain an idle process from the process pool as the contract process; and execute the statements in the contract method of the first contract through the contract process.

[0235] In some embodiments, the cross - contract access further includes a judgment module; the judgment module is further configured to, during the execution of the first contract, determine whether the currently executed statement belongs to a cross - contract status operation statement; if it belongs to a cross - contract status operation statement, it is determined that there is a situation of cross - contract data access.

[0236] In some embodiments, the permission verification module 1008 is further configured to query a pre - set trust mapping relationship through a permission controller; determine the second contract pointed to by the cross - contract data access; perform access permission verification based on the trust mapping relationship and the second contract to obtain a verification result.

[0237] In some embodiments, the trust mapping relationship includes at least one of a trust user mapping relationship or a trust contract mapping relationship; the permission verification module 1008 is further configured to perform access permission verification based on the trust user mapping relationship and the second contract; and / or perform access permission verification based on the trust contract mapping relationship and the second contract to obtain a verification result.

[0238] In some embodiments, the permission verification module 1008 is further configured to obtain the caller information of the caller who calls the first contract and the creator information of the creator of the second contract; determine whether the creator of the second contract trusts the caller based on the caller information, the creator information, and the trust user mapping relationship.

[0239] In some embodiments, the permission verification module 1008 is further configured to obtain the first contract identifier of the first contract and the second contract identifier of the second contract; determine whether the second contract trusts the first contract based on the first contract identifier, the second contract identifier, and the trust contract mapping relationship.

[0240] In some embodiments, the permission verification module 1008 is further configured to determine the parameter identifier corresponding to the cross - contract data access; if it is determined based on the trust contract scope mapping relationship that the first contract is a contract trusted by the second contract and the parameter identifier is within the allowable access range of the second contract, it is determined that the verification result is allow access.

[0241] In some embodiments, the cross - contract access device further includes a trust mapping relationship change module; the trust mapping relationship change module is configured to obtain a transaction for changing the trust mapping relationship; if the trust mapping relationship to be changed is a trust user mapping relationship, update the contract creators trusted by the initiator of the transaction based on the transaction content; if the trust mapping relationship to be changed is a trust contract mapping relationship, update the trusted contracts of the contracts created by the initiator of the transaction based on the transaction content; if the trust mapping relationship to be changed is a trust contract scope mapping relationship, update at least one of the following based on the transaction content: the trusted contracts of the contracts created by the initiator of the transaction, the allowable access range of the trusted contracts of the contracts created by the initiator of the transaction.

[0242] In some embodiments, the cross - contract operation module 1008 is further configured to, if the cross - contract status operation for the second contract is a read operation, determine whether there is a read set matching the read operation in the context manager through the permission controller; if so, directly return the read set result; otherwise, obtain the read set result from the status database through the context manager.

[0243] In some embodiments, the cross - contract operation module 1008 is further configured to, if the cross - contract status operation for the second contract is a read - write operation, instruct the context manager to update the write set matching the read - write operation in the status database.

[0244] Each module in the above cross - contract access device can be implemented in whole or in part by software, hardware, and their combination. The above - mentioned modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above - mentioned modules.

[0245] In one embodiment, a computer device is provided. The computer device can be a server or a terminal, and its internal structure diagram can be as Figure 11 shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O), and a communication interface. Among them, the processor, the memory, and the input / output interface are connected through the system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non - volatile storage medium and an internal memory. The non - volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non - volatile storage medium. The database of the computer device is used to store transaction data. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals through a network connection. When the computer program is executed by the processor, a cross - contract access method is implemented.

[0246] Those skilled in the art can understand that Figure 11 the structure shown in

[0247] In one embodiment, a computer device is further provided, which includes a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above-mentioned method embodiments are implemented.

[0248] In one embodiment, a computer-readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0249] In one embodiment, a computer program product is provided, which includes a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0250] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions.

[0251] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memories can include read-only memory (ROM), magnetic tapes, floppy disks, flash memories, optical memories, high-density embedded non-volatile memories, resistive random access memories (ReRAM), magnetoresistive random access memories (MRAM), ferroelectric random access memories (FRAM), phase change memories (PCM), graphene memories, etc. Volatile memories can include random access memory (RAM) or external cache memories, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logics, data processing logics based on quantum computing, etc., without limitation.

[0252] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0253] The above-described embodiments only represent several implementation manners of the present application. Their descriptions are relatively specific and detailed, but they should not be construed as limiting the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A cross - contract access method, characterized in that, The method includes: Determine a first contract to be executed; Start a contract process and execute the first contract through the contract process; During the execution of the first contract, if there is a cross - contract data access situation, perform permission verification on a second contract pointed to by the data access through a permission controller to obtain a verification result; In the case where the verification result indicates permission to access, perform a cross - contract status operation on the second contract through the permission controller to achieve cross - contract data access.

2. The method according to claim 1, characterized in that, The starting of the contract process and the execution of the first contract through the contract process include: Obtain an idle process from a process pool as the contract process; Execute the statements in the contract method of the first contract through the contract process.

3. The method according to claim 2, characterized in that, The method further includes: During the execution of the first contract, determine whether the currently executed statement belongs to a cross - contract status operation statement; If it belongs to the cross - contract status operation statement, determine that there is a cross - contract data access situation.

4. The method according to claim 1, characterized in that, The performing of permission verification on a second contract pointed to by the data access through a permission controller to obtain a verification result includes: Query a pre - set trust mapping relationship through the permission controller; Determine the second contract pointed to by the cross - contract data access; Perform access permission verification based on the trust mapping relationship and the second contract to obtain a verification result.

5. The method according to claim 4, wherein The trust mapping relationship includes at least one of a trust user mapping relationship or a trust contract mapping relationship; The performing of access permission verification based on the trust mapping relationship and the second contract to obtain a verification result includes: Perform access permission verification based on the trust user mapping relationship and the second contract; And / or, perform access permission verification based on the trust contract mapping relationship and the second contract to obtain a verification result.

6. The method according to claim 5, characterized in that, The performing of access permission verification based on the trust user mapping relationship and the second contract includes: Obtain the caller information of the caller that calls the first contract and the creator information of the creator of the second contract; Based on the caller information, the creator information, and the trust user mapping relationship, determine whether the creator of the second contract trusts the caller.

7. The method according to claim 5, wherein The performing of access permission verification based on the trust contract mapping relationship and the second contract includes: Obtain the first contract identifier of the first contract and the second contract identifier of the second contract; Based on the first contract identifier, the second contract identifier, and the trust contract mapping relationship, determine whether the second contract trusts the first contract.

8. The method according to claim 4, characterized in that The trust mapping relationship includes a trust contract scope mapping relationship. The performing of access permission verification based on the trust mapping relationship and the second contract to obtain a verification result includes: Determine a parameter identifier corresponding to the cross - contract data access; If, based on the trust contract scope mapping relationship, it is determined that the first contract is a contract trusted by the second contract and the parameter identifier is within the allowed access range of the second contract, determine that the verification result is permission to access.

9. The method according to claim 4, characterized in that The method further includes: Obtain a transaction for changing the trust mapping relationship; If the trust mapping relationship to be changed is a trusted user mapping relationship, update the contract creator trusted by the initiator of the transaction based on the transaction content; If the trust mapping relationship to be changed is a trusted contract mapping relationship, update the trusted contract of the contract created by the initiator of the transaction based on the transaction content; If the trust mapping relationship to be changed is a trusted contract scope mapping relationship, update at least one of the following based on the transaction content: the trusted contract of the contract created by the initiator of the transaction, the allowed access scope of the trusted contract of the contract created by the initiator of the transaction.

10. The method according to claim 1, wherein Perform a cross - contract state operation on the second contract through the permission controller, including: If the cross - contract state operation on the second contract is a read operation, determine whether there is a read set in the context manager that matches the read operation through the permission controller; If so, directly return the read set result, otherwise, obtain the read set result from the state database through the context manager.

11. The method according to claim 1, characterized in that, Perform a cross - contract state operation on the second contract through the permission controller, including: If the cross - contract state operation on the second contract is a read - write operation, instruct the context manager to update the write set in the state database that matches the read - write operation.

12. A cross - contract access device, characterized in that, The device includes: A contract determination module for determining a first contract to be executed; A process startup module for starting a contract process and executing the first contract through the contract process; A permission verification module for, during the execution of the first contract, if there is a cross - contract data access situation, performing a permission verification on the second contract pointed to by the data access through a permission controller to obtain a verification result; A cross - contract operation module for, when the verification result indicates allowed access, performing a cross - contract state operation on the second contract through the permission controller to achieve cross - contract data access.

13. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When this computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 11.

Images