Method, system and blockchain node for storing alliance information in blockchain

Abstract

A method, system, and blockchain node for storing alliance information in a blockchain, the method comprising: an institutional device of a first institution sends a request to a server for joining the institutional alliance; the server sends a first transaction to the blockchain for invoking a smart contract based on the request, for requesting that the first institution be added to the institutional alliance; a node in the blockchain stores the institutional identifier, first public key, and institutional information of the first institution in a contract state of the smart contract based on the first transaction; an institutional device of a second institution that has joined the institutional alliance obtains the first transaction from the blockchain, and sends a second transaction to the blockchain for invoking the smart contract based on the first transaction, the second transaction being used to indicate that the first institution is allowed to join the institutional alliance; and a node in the blockchain adds the institutional identifier, first public key, and institutional information of the first institution to the alliance information in the contract state of the smart contract based on the second transaction.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of computer technology, and more particularly, to a method, system, and blockchain node for storing alliance information in a blockchain. Background Art

[0002] Currently, regulators typically require institutions involved in significant transactions to fulfill their anti-illicit fund transfer obligations. This includes analyzing and reporting transaction data for large and suspicious transactions. However, information silos exist between institutions, making it difficult for them to identify suspicious users without sufficient information. Furthermore, when risk data or other data is shared across multiple institutions through platforms, there is a risk of theft or tampering. Summary of the Invention

[0003] The purpose of the present invention is to provide a method, system and blockchain node for storing alliance information in a blockchain, storing trusted alliance information in the blockchain through smart contracts in the blockchain, so that trusted units can share data between institutions based on the trusted alliance information, thereby improving the security of institutional data.

[0004] In a first aspect, this specification provides a method for storing alliance information in a blockchain, comprising:

[0005] An institution device of a first institution sends a request for joining the institution alliance to a server, wherein the request includes a first public key of the first institution and institution information of the first institution;

[0006] The server sends a first transaction to the blockchain to invoke the smart contract according to the request, where the first transaction includes the organization identifier of the first organization, the first public key, and the organization information, and is used to request that the first organization be added to the organization alliance;

[0007] The node in the blockchain stores the organization identifier of the first organization, the first public key, and the organization information in association with each other in the contract state of the smart contract according to the first transaction;

[0008] An institutional device of a second institution that has joined the institutional alliance obtains the first transaction from the blockchain, and sends a second transaction to the blockchain to invoke the smart contract based on the first transaction, where the second transaction includes an institutional identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance;

[0009] The node of the blockchain adds the organization identifier, the first public key, and the organization information of the first organization to the alliance information in the contract state of the smart contract according to the second transaction.

[0010] A second aspect of this specification provides a method for storing alliance information in a blockchain, performed by a blockchain node, the method comprising:

[0011] receiving a first transaction for invoking a smart contract sent by a server, wherein the first transaction includes an organization identifier, a first public key, and organization information of the first organization, and is used to request that the first organization be added to the organization alliance;

[0012] storing, in association with the first institution's organization identifier, the first public key, and the organization information in a contract state of the smart contract according to the first transaction;

[0013] receiving a second transaction sent by a second institution included in the institutional alliance, the second transaction invoking the smart contract and including an institution identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance;

[0014] According to the second transaction, the organization identifier, the first public key, and the organization information of the first organization are added to the alliance information in the contract state of the smart contract.

[0015] A third aspect of this specification provides a system for storing alliance information in a blockchain, including an institutional device of a first institution, a server, a blockchain, and an institutional device of a second institution, wherein the second institution is an institution that has joined the institutional alliance,

[0016] The organization device of the first organization is used to send a request for joining the organization alliance to the server, wherein the request includes the first public key of the first organization and the organization information of the first organization;

[0017] The server is configured to send a first transaction to the blockchain that invokes a smart contract according to the request, where the first transaction includes the organization identifier, the first public key, and the organization information of the first organization, and is configured to request that the first organization be added to the organization alliance;

[0018] The node in the blockchain is used to store the organization identifier of the first organization, the first public key, and the organization information in association with each other in the contract state of the smart contract according to the first transaction;

[0019] The institutional device of the second institution is configured to obtain the first transaction from the blockchain, and send a second transaction to the blockchain to invoke the smart contract based on the first transaction, wherein the second transaction includes an institutional identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance;

[0020] The node of the blockchain is further configured to add the organization identification, the first public key, and the organization information of the first organization to the alliance information in the contract state of the smart contract according to the second transaction.

[0021] A fourth aspect of this specification provides a blockchain node, including:

[0022] a receiving unit, configured to receive a first transaction for invoking a smart contract sent by a server, wherein the first transaction includes an institution identifier, a first public key, and the institution information of the first institution, and is used to request that the first institution be added to the institution alliance;

[0023] a storage unit, configured to store, in association with the contract state of the smart contract according to the first transaction, the organization identifier of the first organization, the first public key, and the organization information;

[0024] The receiving unit is further configured to receive a second transaction sent by a second institution included in the institutional alliance, the second transaction invoking the smart contract and including an institution identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance;

[0025] The storage unit is further configured to add the organization identifier, the first public key, and the organization information of the first organization to the alliance information in the contract state of the smart contract according to the second transaction.

[0026] A fifth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in the second aspect.

[0027] In an eighth aspect, this specification provides a blockchain node, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the second aspect is implemented.

[0028] In the embodiments of this specification, trusted alliance information is stored in the blockchain through smart contracts in the blockchain. TEE can obtain trusted alliance information from the blockchain and share risk data among multiple institutions based on the trusted alliance information, thereby avoiding the possibility of server malicious behavior, protecting user privacy and meeting compliance requirements in the business. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0030] Figure 1 A schematic diagram of a system in an embodiment of this specification;

[0031] Figure 2 This is a flow chart of a method for creating an alliance in a blockchain according to an embodiment of this specification;

[0032] Figure 3 This is a flow chart of a method for storing trusted alliance information in a blockchain according to an embodiment of this specification;

[0033] Figure 4 This is a flow chart of a method for sharing data between alliance organizations in an embodiment of this specification;

[0034] Figure 5 This is a schematic diagram of the process of generating a risk collection file in an embodiment of this specification;

[0035] Figure 6 This is an architectural diagram of a blockchain node in an embodiment of this specification. DETAILED DESCRIPTION

[0036] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0037] Data sharing is often a business necessity for institutions. A single institution often lacks sufficient information to process business, creating a need to obtain information from other institutions. For example, many countries' anti-illicit fund transfer compliance requirements require financial institutions to provide audit results. Currently, many central banks and major financial institutions are exploring the use of blockchain in this area to improve efficiency and accuracy and meet regulatory requirements. Furthermore, data, as a resource, is fundamental to many data applications and industrial development due to its liquidity and accessibility. However, protecting privacy during data exchange and sharing remains a major challenge for industrial development. This article will be explained using the aforementioned anti-illicit fund transfer example.

[0038] Anti-Money Laundering (AML) refers to measures to prevent illegal fund transfers that attempt to conceal the source and nature of proceeds from crimes such as drug-related crimes, organized crime, terrorist activities, smuggling, corruption, bribery, and crimes that disrupt financial management order. Common channels for illegal fund transfers involve a wide range of sectors, including banking, insurance, securities, and real estate. Most anti-illicit fund transfer efforts encompass three core areas:

[0039] 1. Customer Identity Verification System. When establishing business relationships or conducting transactions with customers, entities subject to anti-illegal fund transfer obligations must verify and record their customers' identities based on authentic and valid identification documents and promptly update their customer identity information during the duration of the business relationship.

[0040] 2. Suspicious Transaction Report (STR) System. Illegal capital flows are generally characterized by large amounts and unusual transactions. Therefore, the law stipulates a Suspicious Transaction Report (STR) system, requiring financial institutions to promptly report transactions exceeding certain thresholds and unusual transactions lacking legitimate purposes to the administrative department responsible for combating illegal capital transfers, as clues for investigating illegal and criminal activities.

[0041] 3. Customer identity information and transaction record preservation system Customer identity information and transaction record preservation refers to the financial institutions taking necessary measures in accordance with the law to preserve customer identity information and transaction information for a certain period of time, which can provide evidence support for tracing illegal and criminal activities.

[0042] The customer identity identification system, commonly known as "Know Your Customer" (KYC), refers to obtaining customer-related identification information, including understanding the customer's identity when establishing business with the customer, understanding the purpose of the transaction, understanding the source and destination of funds, and understanding the customer's long-term business activities and financial transactions. It is the basis for combating illegal fund transfers.

[0043] Different financial institutions have an obligation to review suspicious transactions. However, the transaction information and user information held by different financial institutions for the same user often differ. Consequently, the risk labels assigned to the same user after suspicious transaction analysis by different financial institutions may also differ. A risk label is a label agreed upon by multiple institutions to indicate the degree of risk. This risk label, for example, includes multiple preset labels, each of which indicates the user's illegal funds transfer risk level, the type of illegal behavior, or other information related to the user's illegal funds transfer risk. For example, risk labels may include riskH, riskM, and riskL, where riskH indicates high risk, riskM indicates medium risk, and riskL indicates low risk. A single user's risk label may include multiple risk labels, such as risk1 and riskH, where risk1 indicates a specific type of risk. If a financial institution wants to more accurately assign risk labels to a user, a better approach is to obtain the risk labels assigned to the same user by another (or more) financial institutions. Therefore, there is a need to share risk labels for the same user across different financial institutions.

[0044] Taking a customer's illegal funds transfer risk level as an example, different financial institutions may assign different illegal funds transfer risk levels to the same user after conducting suspicious transaction analysis. For example, Institution A may assign a high risk to user U1, while Institution B may assign a medium risk to the same user. If a financial institution wants to more accurately assign an illegal funds transfer risk level to a user, a better approach is to obtain the illegal funds transfer risk level labels assigned to the same user by another (or more) financial institutions. Therefore, there is a need to share the illegal funds transfer risk level labels of the same user across different financial institutions.

[0045] Figure 1 This is a system architecture diagram in the embodiment of this specification. Figure 1 As shown, institutional device 100, institutional device 200, and institutional device 300 can be computing devices of, for example, institutions A, B, and C, respectively. Institutions A, B, and C can be, for example, any of a financial institution, an insurance company, a trading institution, or the like. It will be understood that while three institutional devices are shown as an example, in practice, multiple institutional devices may be included. The institutional devices are equipped with a client of the anti-illegal funds transfer platform. Each institutional device can directly receive user information, and the client performs certain processing based on this user information, such as reviewing suspicious transactions as described above, thereby obtaining risk tags for each user.

[0046] Taking the example of a risk label specifically representing an illegal funds transfer risk level, institutions A and B can each assign an illegal funds transfer risk level to a user based on their own anti-illegal funds transfer audit capabilities. Consequently, the illegal funds transfer risk levels assigned by institutions A and B to user U1 may differ. For example, institution A may assign a "high risk level" to user U1, while institution B may assign a "medium risk level" to user U1. To obtain a more accurate illegal funds transfer risk level, multiple institutions can share the same user's illegal funds transfer risk level label via an anti-illegal funds transfer server (hereinafter referred to as the server) 400. Furthermore, during this risk data sharing process, multiple compliance requirements must be met. For example, the institution providing risk data during risk data sharing cannot know the institution querying the data it provided, the institution querying the risk data cannot know which institution provided the risk data, and the server cannot know which institution's data was queried, nor the plaintext data retrieved. These compliance requirements increase the difficulty of sharing and querying risk data.

[0047] The server 400 includes a trusted unit, which can be any computing unit that can process private data or confidential data and protect data from leakage. The trusted unit includes, for example, a trusted execution environment (TEE), a computing device in a trusted organization, etc. Figure 1 The example of TEE40 as a trusted unit is shown in FIG. The following description uses TEE40 as an example of a trusted unit. Each institution device can send the desensitized and encrypted ciphertext risk data to the server 400, and the server 400 stores the ciphertext risk data of each institution locally or in a file storage server ( Figure 1 (not shown). TEE 40 can receive the address where encrypted risk data is stored from server 400, obtain the encrypted risk data from the address, decrypt the encrypted risk data to obtain the risk data of each institution, then fuse the risk data of multiple institutions and return the fused data to the devices of each institution, thereby sharing data among the institutions while protecting user privacy.

[0048] In the related art, the server 400 also provides the public key of each institution to TEE40, and TEE40 uses the public key of each institution to encrypt the data to be sent to each institution to obtain ciphertext data, and sends each ciphertext data to the institutional equipment of each institution. In this related art, the server 400 may provide its own public key to TEE40 instead of the public key of the institution, so that TEE40 uses the public key of the server to encrypt the data sent to the institution to obtain ciphertext data. After TEE40 sends the ciphertext data to the server, the server can use its own private key to decrypt the ciphertext data, thereby stealing the data shared between institutions. Alternatively, the server 400 may forge the risk data and public key of the institution in order to participate in the institutional data sharing, thereby stealing the risk data of other institutions and providing forged risk data to other institutions. Therefore, it is necessary to ensure that TEE can obtain the public key and data of the real institution or the institution in a specific range (such as a specific alliance) to ensure data security during the institutional data sharing process.

[0049] In the embodiments of this specification, each mechanism device can be used with Figure 1 The blockchain 500 in the blockchain is connected, specifically, it is connected to a node in the blockchain to join the organization alliance by sending a transaction to call a smart contract to the blockchain, and the information of the organization joining the alliance is stored in the contract state of the smart contract. TEE40 can be connected to the blockchain 500, or TEE40 can be connected to the blockchain 500 by connecting to an oracle to obtain the alliance information of the trusted organization alliance from the blockchain 500, and based on the alliance information, data sharing between institutions is carried out to ensure data security. It can be understood that Figure 1 Although the trusted unit is shown to be located inside the server 400, the embodiments of this specification are not limited to this. The TEE can also be located in another computing device, and the server 400 can be connected to the TEE by connecting to the computing device.

[0050] Figure 2 This is a flow chart of the method for creating an alliance in a blockchain in the embodiment of this specification. Figure 2 The organization device in the above example can be an organization device of the alliance creation organization, which can be, for example, Figure 1 The mechanism device 200 or the mechanism device 300 in the embodiment will be described below using the mechanism device 200 as an example.

[0051] like Figure 2 As shown, in step S201, the organization device 200 sends an alliance creation request to the server 400, and the request includes the public key and organization information of organization B.

[0052] The organization information shown includes, for example, the qualification information, certificates, licenses, etc. of organization B, which are used to verify the identity of organization B.

[0053] In step S203, the server 400 sends a transaction Tx1 to the blockchain to call the smart contract (hereinafter referred to as the contract) C1. The transaction Tx1 includes the organization identification, public key and organization information of organization B.

[0054] For example, transaction Tx1 may call a function for creating an alliance in C1 to indicate that transaction Tx1 is used to create an alliance.

[0055] In one embodiment, the server 400 may generate a DID (e.g., DIDb) for organization B based on the public key of organization B, and include DIDb in transaction Tx1 as the organization identifier of organization B. After generating DIDb, the server 400 may return DIDb to the organization device 200, so that the organization device 200 can send transactions to the blockchain using DIDb as the blockchain account.

[0056] It should be understood that in the embodiments of this specification, DIDb is not limited to being generated by the server. Alternatively, DIDb can be generated by the organization device 200 based on the public key of organization B and included in the alliance creation request. Furthermore, the organization identifier of organization B is not limited to its DID, but can be another identifier that uniquely identifies organization B.

[0057] In step S205, the blockchain node stores the alliance information in the contract status of contract C1 according to transaction Tx1, and adds the organization identification, public key and organization information of organization B to the alliance information.

[0058] After receiving transaction Tx1, a node in the blockchain broadcasts it to the blockchain, allowing every node in the blockchain to execute it. Typically, after reaching consensus on executing Tx1, each node in the blockchain begins executing it. The blockchain node creates alliance information in the contract state of contract C1. This information includes the organization identifier, public key, and information of organization B. The blockchain node also records organization B as the alliance-creating organization in the alliance information, in association with DIDb.

[0059] After confirming that transaction Tx1 is executed, the institution device 200 can query the information corresponding to institution B's DIDb by sending a transaction to call contract C1 to the blockchain to verify whether the server has stored the correct information in the blockchain.

[0060] Figure 3 This is a flow chart of a method for storing trusted alliance information in a blockchain in an embodiment of this specification. It is assumed that the institution A corresponding to the institution device 100 is an institution to be included in the institution alliance, and the institution B corresponding to the institution device 200 is an institution that has already joined the institution alliance. Figure 3The organization that has joined the alliance is not limited to organization B, for example, it can also be organization C.

[0061] like Figure 3 As shown, first, in step S301, the organization device 100 sends an alliance joining request to the server, and the request includes the public key and organization information of organization A.

[0062] Before requesting to join the alliance, organization A can first verify the authenticity of the information of organizations already participating in the alliance by sending a transaction to the blockchain that invokes contract C1. For example, after obtaining the public key and organization information corresponding to organization device 200, organization device 100 can request verification from organization B that the public key is indeed its own. After verification is successful, organization A can send an alliance joining request to the server, which may include organization A's public key and organization information.

[0063] In step S303, the server 400 sends a transaction Tx2 for calling the contract to the blockchain. The transaction Tx2 includes the organization identification, public key and organization information of organization A.

[0064] The server 400 may send a transaction Tx2 to any node in the blockchain 500. In the transaction Tx2, for example, a function for joining the alliance in the contract C1 may be called to instruct the institution A to join the institution alliance.

[0065] In one embodiment, the server 400 may generate a DID (e.g., DIDa) for organization A based on the public key of organization A, and include DIDa in transaction Tx2 as the organization identifier of organization A. After generating DIDa, the server 400 may return DIDa to the organization device 100, so that the organization device 100 can send transactions to the blockchain using DIDa as the blockchain account.

[0066] It is understandable that the server 400 is not limited to using the organization's DID as the organization identifier, and may also use other organization identifiers of the organization for uniquely identifying the organization, such as the organization name, organization code, etc., without limitation.

[0067] In step S305, the node in the blockchain stores the organization identification, public key and organization information of organization A in the contract state of contract C1 according to transaction Tx2, and stores transaction Tx2.

[0068] After receiving transaction Tx2, the blockchain node executes it. Based on the execution of Tx2, the node stores the identifier, public key, and information of Institution A in the contract state of contract C1, for example, in the list of institutions to join the alliance, to prepare for joining the alliance. Furthermore, after executing the block containing Tx2, the node stores the block in the block database. This block includes data such as the transaction body and transaction receipt for Tx2.

[0069] In step S307, the institutional device 200 obtains transaction Tx2 from the blockchain.

[0070] In the first embodiment, the contract C1 pre-sets that the alliance creation organization (i.e., organization B) will review and approve the organizations to be included. According to this setting, the organization device 200 corresponding to the creation organization (i.e., organization B) can regularly pull blocks from the blockchain. After pulling the block, it determines whether the block includes a transaction requesting the organization to join the alliance, and approves the organization to be included in the alliance based on the transaction. Specifically, the organization device 200 obtains the transaction Tx2 from the pulled block, and approves it based on the public key and organization information of organization A included in the transaction Tx2. The organization device 200 can first verify with the organization device 100 whether the public key in the transaction Tx2 is the public key of organization A. After the verification is passed, it determines whether organization A can join the alliance based on the organization information.

[0071] In a second embodiment, contract C1 pre-configures that one or more organizations already in the alliance will review and approve potential organizations. The organization is allowed to join the alliance only if the number of organizations with approved results (i.e., organizations allowed to join the alliance) meets preset conditions. These conditions may include: the number of organizations with approved results equals a preset value; the ratio of the number of organizations with approved results to the number of organizations already in the alliance equals a preset value; and so on.

[0072] According to this setting, each institution that has joined the alliance (including institution B) can regularly pull blocks from the blockchain. After pulling the block, it determines whether the block includes a transaction requesting the institution to join the alliance, and approves the institution to join the alliance based on the transaction.

[0073] In step S309, the institutional device 200 sends a transaction Tx3 to the blockchain to call the contract C1. The transaction Tx3 includes the institutional identification and approval information of the institution A.

[0074] In the first embodiment described above, if the approval of organization A is passed, the organization device 200 sends a transaction Tx3 to any node in the blockchain, invoking contract C1. Transaction Tx3, for example, invokes the approval result function of contract C1. Assuming the approval result is passed, the organization device 200 includes organization A's DIDa and information indicating approval in transaction Tx3, indicating that organization A is allowed to join the alliance.

[0075] In the second embodiment described above, when the approval of institution A is passed, the institutional devices of each institution that has joined the alliance send a transaction to call contract C1 to any node in the blockchain, so as to include the approval result of institution A in the transaction.

[0076] In step S311, the blockchain node updates the alliance information in the contract status of contract C1 according to transaction Tx3 and stores the data of transaction Tx3.

[0077] In the first embodiment described above, after receiving transaction Tx3, the blockchain node executes transaction Tx3. Specifically, after determining that institution B has approved institution A based on transaction Tx3, the blockchain node adds institution A's organization identifier, public key, and information to the alliance information in the contract status of contract C1, indicating that institution A has joined the alliance. The blockchain node may also delete institution A's information from the list of institutions to join the alliance. Furthermore, after executing the block containing transaction Tx3, the blockchain node stores the block in the block database. This block includes data such as the transaction body and transaction receipt of transaction Tx3. The transaction receipt of transaction Tx3 may include the execution result of transaction Tx3, which, for example, indicates that institution A has joined the alliance.

[0078] In the second embodiment described above, a parameter N corresponding to institution A is set in the contract status of contract C1. This parameter N is used to record the number of institutions that have approved institution A. Each time a blockchain node receives a transaction containing an approval result for institution A from an alliance institution, if the approval result in the transaction is passed, the parameter N is incremented by 1, and a determination is made as to whether the updated parameter N meets the above-mentioned preset conditions. If so, the subsequent step S311 is executed. If not, it is determined that institution A cannot yet join the alliance. Assuming that after receiving transaction Tx3 sent by institution device 200, the blockchain node updates parameter N and determines that parameter N has met the above-mentioned preset conditions, the information of institution A is added to the alliance information to indicate that institution A has joined the alliance. At the same time, the information indicating that institution A has joined the alliance is included in the receipt of transaction Tx3 as the execution result of transaction Tx3.

[0079] In step S313, the server obtains the data of transaction Tx3 from the blockchain, and obtains the information of institution A joining the alliance based on the data of transaction Tx3.

[0080] After sending transaction Tx2 to the blockchain, the server can pull blocks from the blockchain. After pulling the blocks, the server determines whether the blocks include a transaction (for example, transaction Tx3) sent by a device of an organization that has joined the alliance and includes an approval result for organization A. After obtaining transaction Tx3 from the pulled blocks, the server determines that organization A has joined the alliance based on the receipt of transaction Tx3.

[0081] In step S315 , the server returns the information that organization A has joined the alliance to the organization device 100 .

[0082] In passing Figure 3 After the alliance information is stored in the blockchain using the method shown, the information of the institutions included in the alliance information is authentic and trustworthy. Therefore, the alliance information can be used in scenarios where institutions share data to avoid risks such as data leakage.

[0083] Figure 4 This is a flow chart of a method for sharing data between alliance organizations in an embodiment of this specification. Figure 4 The organization device in the example may be an organization device of any organization included in the alliance. The following description will be made using the organization device 100 as an example.

[0084] like Figure 4 As shown, first, in step S401 , the mechanism device 100 sends a ciphertext data request to the server 400 .

[0085] This encrypted data request is used to request data provided (shared) by one or more organizations in the alliance. This encrypted data request is generated, for example, by encrypting the data request using the public key of the TEE. This prevents the plaintext data request from being accessible outside the TEE of server 400, further protecting user privacy.

[0086] In one embodiment, the institution device 100 may use the TEE's public key to perform envelope encryption on the data request. Specifically, the institution device 100 may use a symmetric key to encrypt the data request to generate a ciphertext data request, encrypt the symmetric key using the TEE's public key to generate a ciphertext key, and send the ciphertext key together with the ciphertext data request to the server 400. By using the TEE public key to perform envelope encryption on the data request, compared to directly encrypting the data request using the TEE public key, symmetric encryption has a smaller computational load than asymmetric encryption and the symmetric key has a smaller data size. Therefore, the computational load during encryption and decryption is reduced, shortening the encryption and decryption time.

[0087] It is understandable that encryption is not limited to using the TEE's public key. For example, other asymmetric keys or symmetric keys can be negotiated between the TEE and the institution's device for encryption.

[0088] TEE is a secure extension of CPU hardware, a trusted execution environment that is completely isolated from the outside world. Currently, the industry is paying close attention to TEE solutions, and almost all major chip and software alliances have their own TEE solutions, such as the TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions), ARM Trustzone, and AMD PSP (Platform Security Processor) in hardware. TEE can act as a hardware black box, preventing even the operating system from peeking at the code and data executed within the TEE. These operations can only be performed through predefined interfaces within the code. In terms of efficiency, due to the black box nature of the TEE, operations performed within the TEE are performed on plaintext data, rather than the complex cryptographic operations used in homomorphic encryption, resulting in virtually no loss in computational efficiency.

[0089] Take Intel SGX (hereafter referred to as SGX) technology as an example. Blockchain nodes can create enclaves (enclaves or enclaves) as TEEs based on SGX technology. Specifically, the server can use the newly added processor instructions in the CPU to allocate a portion of the EPC (Enclave Page Cache) in the memory to reside in the above enclave. The memory area corresponding to the above EPC is encrypted by the memory encryption engine MEE (Memory Encryption Engine) inside the CPU. The content in this memory area (code and data in the enclave) can only be decrypted in the CPU core, and the key used for encryption and decryption is only generated and stored in the CPU when the EPC is started. As can be seen, the enclave's security boundary only includes itself and the CPU. No software, privileged or unprivileged, can access the enclave. Even the operating system administrator and the VMM (Virtual Machine Monitor, also known as the hypervisor) cannot affect the code and data in the enclave, thus ensuring extremely high security. Furthermore, under the premise of the above security guarantees, the CPU can process plaintext data in the enclave with extremely high computing efficiency, thus balancing data security and computing efficiency. Data entering and leaving the TEE can be encrypted to ensure data privacy.

[0090] Before being used, the TEE can prove its trustworthiness to the user. This process may involve a remote attestation report. The remote attestation report is generated during the remote attestation of the TEE. The remote attestation report can be generated by an authoritative authentication server after verifying the self-referral information generated by the TEE. This remote attestation report can be used to demonstrate the trustworthiness of the TEE.

[0091] For example, before the institutional device 100 uses the public key of the TEE to encrypt the data request, it can first verify whether the TEE is trustworthy. Specifically, the institutional device 100 can challenge the TEE and receive the remote attestation report returned by the TEE. After obtaining the remote attestation report, the institutional device 100 can verify the signature of the remote attestation report based on the public key of the authoritative authentication server. If the verification passes, it can be confirmed that the TEE is trustworthy. Specifically, after receiving the verification request, the TEE generates authentication information based on its internal mechanism, and sends the authentication information and the hardware public key of the TEE to the institutional device 100. The authentication information includes, for example, the signature information, hardware information and software information of the TEE. Among them, the signature information is generated, for example, by the hardware key of the TEE; the hardware information includes, for example, various hardware indicators, such as CPU main frequency, memory capacity, etc.; the software information includes the code hash value, code name, version, operation log, etc. of each program. As known to those skilled in the art, a TEE can use its memory hardware to perform "measurements" of the program running within it, such as obtaining the program's code hash value, the hash value of the program's memory usage at a specific execution point, and so on. This "measurement" information of the program is included in the authentication information. Because this "measurement" information is executed by the TEE itself (the memory hardware) without involving any software or operating system, it is authentic and trustworthy. After receiving the authentication information, the institutional device 100 can send it to the TEE's remote authentication server, thereby receiving a remote attestation report for the TEE from the server. The remote attestation report includes the identity verification of the TEE and verification of the program executing within the TEE. Based on this remote attestation report, the institutional device 100 can determine that the TEE is trustworthy and that the query results obtained through the TEE are trustworthy. Furthermore, the institutional device 100 can locally store the TEE's hardware public key for subsequent verification of the TEE's signature. The TEE stores a public-private key pair, with the private key securely stored within the TEE. The content transmitted by the TEE can be signed with the private key stored in the TEE, thereby proving that it is the result of execution by the TEE.

[0092] Specifically, the data request corresponding to the encrypted data request (i.e., the plaintext data request) may include the risk data in institution A, and the risk data includes the user identifications and risk labels of multiple users in institution A. The data request is used to obtain the risk labels of the multiple users in other institutions in the alliance by fusing with the risk data of other institutions, so as to more accurately judge the user's risk level.

[0093] The organization device 100 may use its own private key to sign the ciphertext data request, and send the DID (eg, DIDa) of the organization device 100 , the ciphertext data request, and the signature to the server 400 .

[0094] At the same time, the institutional devices of other institutions in the alliance can send encrypted data requests to the server similarly to the institutional device 100, and the data request corresponding to the encrypted data request includes the risk data of the institution.

[0095] In step S403 , the server 400 provides the organization identification and the corresponding ciphertext data request to the TEE.

[0096] After receiving the ciphertext data request from each institutional device, the server 400 may store the ciphertext data request in the server or in a storage server outside the server, and obtain the storage address of the ciphertext data request.

[0097] Afterwards, the server 400 may send the DID list of each organization and the file address of the ciphertext data request corresponding to each DID to the TEE. The TEE may read the ciphertext data request corresponding to each DID from the file address corresponding to each DID.

[0098] In one embodiment, the server also provides the signature of the ciphertext data request using the private key of DIDa of organization A to the TEE.

[0099] In one embodiment, the server may also provide the pre-acquired public key of DIDa of organization A to the TEE.

[0100] In step S405, TEE obtains alliance information from the blockchain.

[0101] Specifically, the TEE can obtain information from the blockchain through an oracle. The TEE sends a request to the oracle for alliance information on the blockchain. In response to this request, the oracle sends a transaction Tx4 to the blockchain, invoking contract C1 to query the alliance information in the contract state of contract C1. After executing transaction Tx4, the node in the blockchain obtains the alliance information from the contract state of contract C1 and returns it to the oracle, which then returns the alliance information to the TEE.

[0102] Through the above Figure 2 and Figure 3 The description of the method shown shows that the alliance information obtained by TEE from the blockchain is authentic and reliable. In this way, TEE shares data between institutions based on this alliance information, avoiding the risks of data leakage or data tampering caused by malicious server behavior as described above.

[0103] In step S407, TEE verifies the organization identifier based on the alliance information. After the verification is passed, it decrypts the encrypted data request to obtain the data request.

[0104] In one embodiment, the TEE verifies that the organization identifiers of each organization sending the encrypted data request are included in the alliance information. If the verification is successful, it can be proved that the organization sending the encrypted data request is an alliance organization. Therefore, the TEE's private key can be used to decrypt the encrypted data request to obtain the data request, and the organization can provide the data provided by other alliance organizations according to the data request.

[0105] In one embodiment, after the TEE verifies the organization identification, the TEE can also use the public keys of each organization included in the alliance information to verify the signatures of each organization received, and only decrypt the ciphertext data request if the verification is successful.

[0106] In one embodiment, after the TEE successfully verifies the organization identification, it can use the alliance information to verify the public keys of each organization received. Only when the verification is successful can the signature of each organization be verified.

[0107] In step S409, TEE obtains data according to the data request, encrypts the data using the institution's public key, and obtains ciphertext data.

[0108] Specifically, if risk data is included in the data requests from various institutions, the TEE, after receiving the data requests from each institution, retrieves the risk data files for each institution from the data requests. The TEE can then generate a risk union file based on the risk data files for each institution. The risk union file includes multiple rows corresponding to all risky users included in the multiple institutions. Each row includes a user ID, a risk tag set, and an institution set. The risk tag set is retrieved from the multiple risk data files, and the institution set includes the institution ID of the institution providing the risk tag.

[0109] Figure 5 This is a schematic diagram of the process of generating the risk collection file F4 in the embodiment of this specification. Figure 5The upper middle portion schematically illustrates the risk data files for each institution. Institution A's risk data file corresponds to its institution identifier DIDa, Institution B's risk data file corresponds to its institution identifier DIDb, and Institution C's risk data file corresponds to its institution identifier DIDc. Each risk data file shows the user ID and corresponding risk label of the risk user in each institution, and multiple rows in the risk data file can be arranged in ascending order of user ID.

[0110] When merging multiple risk data files in TEE, such as Figure 5 As shown in , first, the minimum user ID is indicated by a pointer to each risk data file. Figure 5 Among the user IDs indicated by the pointers in the three risk data files, the user ID of institution A is the smallest ID. Therefore, Figure 5 ID1{risk1}{DIDa} is written in the first line of the risk union file shown below, that is, {risk1} is the risk label set of ID1 in multiple risk data files, and {DIDa} is the set of institution identifiers that provide labels in the risk label set.

[0111] After recording the information corresponding to ID1 in the risk union file, the pointer is pointed to the next row in the risk data file of institution A, that is, the row corresponding to ID3, and the above process is repeated. Specifically, after determining that the minimum ID indicated by the three pointers is ID2, the information corresponding to ID2 "ID2{risk2, riskL}{DIDb, DIDc}" is recorded in the second row of the risk union file. Through the same process as above, after traversing all the rows in each risk data file using the pointer, we can get Figure 5 The risk union file shown below.

[0112] After generating the risk union file, the TEE can generate data files to be sent to each organization based on the risk union file. Taking organization A as an example, the TEE can traverse each row in the risk union file. When the organization set in that row includes "DIDa", the user ID and risk tag set in that row are recorded in the data file of organization A. In this way, for example, the data file shown in the following table can be obtained:

[0113] ID1{risk1} ID3{risk3,riskM} ID5{risk3,riskH} ID6{riskH,riskM} …

[0114] That is to say, the data file (i.e., data) to be sent to institution A includes a set of risk labels of all users in the risk data file of institution A. This set of risk labels is obtained by merging the risk data files of various institutions, that is, other institutions also share their risk data into the data file to be sent to institution A.

[0115] Afterwards, TEE encrypts the data to be sent to organization A based on the public key of organization A to obtain ciphertext data, where the encryption is, for example, directly encrypting the data using the public key of organization A, or using the public key of organization A and a symmetric key to perform envelope encryption on the data.

[0116] TEE encrypts the data shown in the above table by using the public key of organization A, so that the server 400 cannot read the data, thereby further protecting the user's privacy.

[0117] In this data sharing scenario, TEE can similarly obtain data to be sent to other organizations and similarly generate encrypted data to be sent to other organizations.

[0118] In step S411 , the TEE sends the encrypted data to the server 400 .

[0119] Specifically, TEE can store the encrypted data outside the TEE (ie, the above-mentioned EPC) and send the storage address to the server, so that the server 400 can read the encrypted data.

[0120] In step S413, the server sends the encrypted data to the institution device.

[0121] In step S415 , the organization device 100 decrypts the ciphertext data using the private key of organization A to obtain the requested data.

[0122] In the embodiments of this specification, TEE obtains trusted alliance information from the blockchain and shares risk data among multiple institutions based on the trusted alliance information, thereby avoiding the possibility of server malicious behavior, protecting user privacy and meeting compliance requirements in the business.

[0123] Figure 6 This is a structural diagram of a blockchain node in an embodiment of this specification, including:

[0124] A receiving unit 61 is configured to receive a first transaction for invoking a smart contract sent by a server, wherein the first transaction includes an organization identifier, a first public key, and organization information of the first organization, and is configured to request that the first organization be added to the organization alliance;

[0125] a storage unit 62 configured to store, in association with the first institution's organization identifier, the first public key, and the organization information in the contract state of the smart contract according to the first transaction;

[0126] The receiving unit 61 is further configured to receive a second transaction sent by a second institution included in the institutional alliance, the second transaction invoking the smart contract and including an institutional identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance;

[0127] The storage unit 62 is further configured to add the organization identifier, the first public key, and the organization information of the first organization to the alliance information in the contract state of the smart contract according to the second transaction.

[0128] The embodiment of this specification also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the following Figure 2 、 Figure 3 or Figure 4 The method shown.

[0129] The embodiment of this specification also provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the following is achieved: Figure 2 、 Figure 3 or Figure 4 The method shown.

[0130] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0131] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0132] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0133] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0134] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0135] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0136] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0137] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0138] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0139] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0140] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0141] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0142] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0143] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0144] The foregoing description is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. Those skilled in the art will appreciate that various modifications and variations of one or more embodiments of this specification are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification are intended to be included within the scope of the claims.

Claims

1. A method for storing alliance information in a blockchain, comprising: An institution device of a first institution sends a request for joining the institution alliance to a server, wherein the request includes a first public key of the first institution and institution information of the first institution; The server sends a first transaction to the blockchain to invoke the smart contract according to the request, where the first transaction includes the organization identifier of the first organization, the first public key, and the organization information, and is used to request that the first organization be added to the organization alliance; The node in the blockchain stores the organization identifier of the first organization, the first public key, and the organization information in association with each other in the contract state of the smart contract according to the first transaction; An institutional device of a second institution that has joined the institutional alliance obtains the first transaction from the blockchain, and sends a second transaction to the blockchain to invoke the smart contract based on the first transaction, where the second transaction includes an institutional identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance; The node of the blockchain adds the organization identifier of the first organization, the first public key, and the organization information to the alliance information in the contract state of the smart contract based on the second transaction, wherein the alliance information is used to share risk data among multiple organizations.

2. The method according to claim 1, further comprising: The organization device of the third organization sends a creation request for creating the organization alliance to the server, wherein the request includes the first public key of the third organization and the organization information of the third organization; The server sends a third transaction for invoking the smart contract to the blockchain according to the creation request, wherein the third transaction includes the organization identifier, public key, and organization information of the third organization, and is used to request the creation of the organization alliance; The node of the blockchain creates the alliance information of the institutional alliance in the contract state of the smart contract based on the third transaction, and adds the institutional identification, public key and institutional information of the third institution to the alliance information.

3. The method according to claim 1 or 2, further comprising: The server obtains information indicating that the first institution has successfully joined the alliance from the blockchain, and returns information indicating that the first institution has successfully joined the alliance to the institutional device of the first institution.

4. The method according to claim 1 or 2, comprising: The institutional device of the first institution sends a ciphertext data request to the server, where the ciphertext data request is generated by encrypting a data request, and the data request is used to obtain first data provided by one or more fourth institutions included in the institutional alliance; The server provides the organization identification of the first organization and the ciphertext data request to the trusted unit; The trusted unit obtains the alliance information from the blockchain by sending a fourth transaction to the blockchain that invokes the smart contract; after verifying the organization identifier of the first organization based on the alliance information, decrypts the ciphertext data request, obtains a data request, obtains the first data based on the data request, encrypts the first data based on the first public key to obtain first ciphertext data, and provides the first ciphertext data to the server; The server returns the first ciphertext data to the mechanism device; The mechanism device decrypts the first ciphertext data to obtain the first data.

5. The method according to claim 1 or 2, further comprising: The server generates an organization identifier of the first organization according to the first public key, and returns the organization identifier of the first organization to the organization device of the first organization.

6. The method according to claim 1 or 2, further comprising: An institutional device of one or more fifth institutions that have joined the institutional alliance sends a fifth transaction to the blockchain for invoking the smart contract, where the fifth transaction includes an institutional identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance; When executing each of the fifth transactions, the nodes in the blockchain increment the number of institutions that the first institution is allowed to join the institutional alliance, as recorded in the contract state, by 1, and if it is determined that the number of institutions does not meet a preset condition, the alliance information is not updated; The node in the blockchain adds the organization identifier, the first public key, and the organization information of the first organization to the alliance information in the contract state of the smart contract according to the second transaction, including: the node in the blockchain adds 1 to the number of organizations according to the second transaction, and when it is determined that the number of organizations meets a preset condition, adds the organization identifier, the first public key, and the organization information of the first organization to the alliance information.

7. The method according to claim 4, further comprising: When the first institution's device sends the ciphertext data request to the server, the first institution's device also sends a signature of the first institution on the ciphertext data request to the server, where the signature is generated based on a first private key corresponding to the first public key; The server provides the signature to the trusted unit; Before requesting decryption of the ciphertext data, the trusted unit uses the first public key to verify the signature, and requests decryption of the ciphertext data if the verification passes.

8. The method according to claim 4, further comprising: The server will pre-acquire the first public key of the first institution and provide it to the trusted unit together with the ciphertext data request. After obtaining the alliance information from the blockchain, the trusted unit will verify the first public key provided by the server based on the alliance information.

9. According to the method according to claim 4, the data request includes the risk data of the first institution, and the risk data includes the user identification and risk label of the first user in the first institution; the first data includes the user identification and a first risk label set of the first user in the first institution, and the first risk label set is generated by the trusted unit based on multiple risk data from multiple institutions in the institutional alliance.

10. The method according to claim 4, wherein the ciphertext data request is generated by encrypting using a symmetric key, and the method further comprises: The institutional device of the first institution uses the public key of the trusted unit to encrypt the symmetric key to generate a ciphertext key, and sends the ciphertext key together with the ciphertext data request to the server. The server provides the ciphertext key together with the institutional identification of the first institution and the ciphertext data request to the trusted unit.

11. The method according to claim 3, wherein the server obtains information from the blockchain indicating that the first institution has successfully joined the alliance, comprising: The server obtains, from the blockchain, one or more blocks generated after sending the first transaction, obtains an execution result of the second transaction from the one or more blocks, and obtains, from the execution result of the second transaction, information indicating that the first institution has successfully joined the alliance.

12. The method according to claim 4, wherein the trusted unit obtains the alliance information of the organization alliance from the blockchain, comprising: The trusted unit instructs the oracle to send the fourth transaction to the blockchain to obtain the alliance information from the blockchain.

13. A method for storing alliance information in a blockchain, performed by a blockchain node, the method comprising: Receiving a first transaction for invoking a smart contract sent by a server, wherein the first transaction includes an organization identifier, a first public key, and organization information of a first organization, and is used to request that the first organization be added to an organization alliance; storing, in association with the first institution's organization identifier, the first public key, and the organization information in a contract state of the smart contract according to the first transaction; receiving a second transaction sent by a second institution included in the institutional alliance, the second transaction invoking the smart contract and including an institution identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance; According to the second transaction, the organization identifier, the first public key, and the organization information of the first organization are added to the alliance information in the contract state of the smart contract, wherein the alliance information is used to share risk data among multiple organizations.

14. A system for storing alliance information in a blockchain, comprising an institutional device of a first institution, a server, a blockchain, and an institutional device of a second institution, wherein the second institution is an institution that has joined the institutional alliance. The organization device of the first organization is used to send a request for joining the organization alliance to the server, wherein the request includes the first public key of the first organization and the organization information of the first organization; The server is configured to send a first transaction to the blockchain that invokes a smart contract according to the request, where the first transaction includes the organization identifier, the first public key, and the organization information of the first organization, and is configured to request that the first organization be added to the organization alliance; The node in the blockchain is used to store the organization identifier of the first organization, the first public key, and the organization information in association with each other in the contract state of the smart contract according to the first transaction; The institutional device of the second institution is configured to obtain the first transaction from the blockchain, and send a second transaction to the blockchain to invoke the smart contract based on the first transaction, wherein the second transaction includes an institutional identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance; The node of the blockchain is further configured to add the organization identifier, the first public key, and the organization information of the first organization to the alliance information in the contract state of the smart contract according to the second transaction, wherein: The alliance information is used to share risk data among multiple institutions.

15. A blockchain node, comprising: A receiving unit, configured to receive a first transaction for invoking a smart contract sent by a server, wherein the first transaction includes an organization identifier, a first public key, and organization information of a first organization, and is used to request that the first organization be added to an organization alliance; a storage unit, configured to store, in association with the contract state of the smart contract according to the first transaction, the organization identifier of the first organization, the first public key, and the organization information; The receiving unit is further configured to receive a second transaction sent by a second institution included in the institutional alliance, the second transaction invoking the smart contract and including an institution identifier of the first institution, indicating that the first institution is allowed to join the institutional alliance; The storage unit is further used to add the organization identification, the first public key and the organization information of the first organization to the alliance information in the contract state of the smart contract according to the second transaction, wherein the alliance information is used to share risk data among multiple organizations.

16. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to claim 13.

Images