Multi-publisher anonymous certificate for a permissioned blockchain

Abstract

A user of a blockchain network can obtain a certificate for the user from an issuer, the certificate being based on one or more attributes of the user, wherein the issuer is selected from one or more authorized issuers, and wherein the certificate includes a signature and a key on the one or more attributes; generate an operation consisting of a payload and a second signature; compute a commitment to a public key of the issuer; prove, using a one-out-of-many proof, that the commitment is a valid commitment to the public key of one of the authorized issuers; prove, using a zero-knowledge proof, knowledge of the signature and the certificate under the public key of the issuer; and prove, using a knowledge proof, the signed key and the value of the attribute.

Description

Background Technology

[0001] This disclosure relates to the processing of operations on blockchain networks, and more specifically to multi-publisher anonymity certificates for permissioned blockchains.

[0002] A blockchain is a list of cryptographically linked records called blocks. Blockchain networks can be used to manage different types of operations by multiple parties. Summary of the Invention

[0003] Embodiments of this disclosure include systems, methods, and computer program products for multi-publisher anonymity certificates for permissioned blockchains in a blockchain network.

[0004] Embodiments of this disclosure include a system comprising a memory and a processor communicating with the memory, the processor being configured to perform operations including: obtaining a certificate for the user from an issuer, the certificate being based on one or more attributes of the user, wherein the issuer is selected from one or more authorized issuers, and wherein the certificate includes a signature and a key regarding the one or more attributes; generating an operation by the user consisting of a payload and a second signature; calculating a commitment to the issuer's public key by the user; proving by the user, using a one-out-of-many proof, that the commitment is a valid commitment to the public key of one of the authorized issuers; proving by the user, using a zero-knowledge proof, a knowledge proof of the signature and the certificate under the issuer's public key; and proving by the user, using a knowledge proof of the signed key and the value of the attribute.

[0005] Additional embodiments of this disclosure include a method comprising: obtaining a certificate for the user from a publisher, the certificate being based on one or more attributes of the user, wherein the publisher is selected from one or more authorized publishers, and wherein the certificate includes a signature and a key regarding the one or more attributes; generating an operation consisting of a payload and a second signature by the user; calculating a commitment to the publisher's public key by the user; proving by the user, using one-to-many proofs, that the commitment is a valid commitment to the public key of one of the authorized publishers; proving by the user, using zero-knowledge proofs, knowledge proofs of the signature and the certificate under the publisher's public key; and proving by the user, using knowledge proofs of the signed key and the values ​​of the attributes.

[0006] Other embodiments of this disclosure include a computer program product comprising a computer-readable storage medium having program instructions included therewith, the program instructions being executable by a processor to cause the processor to perform a method comprising: obtaining a certificate for the user from a publisher, the certificate being based on one or more attributes of the user, wherein the publisher is selected from one or more authorized publishers, and wherein the certificate includes a signature and a key regarding the one or more attributes; generating an operation consisting of a payload and a second signature by the user; calculating a commitment to a public key of the publisher by the user; proving by the user, using a one-to-many proof, that the commitment is a valid commitment to a public key of one of the authorized publishers; proving by the user, using a zero-knowledge proof, a knowledge proof of the signature and the certificate under the public key of the publisher; and proving by the user, using a knowledge proof of the signed key and the value of the attribute.

[0007] The above overview is not intended to describe every illustrated embodiment or implementation of this disclosure. Attached Figure Description

[0008] The accompanying drawings, which are included in and form a part of this disclosure, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of certain embodiments and do not limit the scope of the disclosure.

[0009] Figure 1 A network diagram of a system including a database according to an exemplary embodiment is shown.

[0010] Figure 2A An example blockchain architecture configuration is shown according to an example embodiment.

[0011] Figure 2B This illustrates a blockchain transaction process according to an example embodiment.

[0012] Figure 3A A licensed network is shown according to an example embodiment.

[0013] Figure 3B Another licensed network according to an example implementation is shown.

[0014] Figure 3C An unlicensed network is shown according to an example embodiment.

[0015] Figure 4A This illustrates the process of adding a new block to a distributed ledger according to an example embodiment.

[0016] Figure 4B The contents of a new data block are shown according to an example embodiment.

[0017] Figure 4C A blockchain of digital content is illustrated according to an example embodiment.

[0018] Figure 4D A block is shown that can represent the structure of a block in a blockchain, according to an example embodiment.

[0019] Figure 5 A high-level block diagram of an exemplary computer system, according to embodiments of the present disclosure, is shown that can be used to implement one or more of the methods, tools, modules, and any associated functions described herein.

[0020] Figure 6 A flowchart illustrating an example method for a multi-publisher anonymous certificate for a permissioned blockchain in a blockchain network, according to an example embodiment, is shown.

[0021] While the embodiments described herein are subject to various modifications and alternatives, their details have been illustrated by way of example in the accompanying drawings and will be described in detail. However, it should be understood that the specific embodiments described are not intended to be limiting. Rather, the invention is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure. Detailed Implementation

[0022] This disclosure relates to the processing of operations on a blockchain network, and more specifically to multi-publisher anonymity certificates for permissioned blockchains in a blockchain network.

[0023] It will be readily understood that, as generally described and illustrated in the accompanying drawings, the components of the present invention can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of at least one embodiment of the method, apparatus, non-volatile computer-readable medium, and system illustrated in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments.

[0024] In one or more embodiments, the immediate features, structures, or characteristics described throughout this specification may be combined or removed in any suitable manner. For example, the use of phrases such as “exemplary embodiment,” “some embodiments,” or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment. Therefore, the phrases “exemplary embodiment,” “some embodiments,” “other embodiments,” or other similar language appearing throughout this specification do not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Moreover, any device depicted in the figures may be a different device. For example, if a mobile device is shown as transmitting information, a wired device may also be used to transmit that information.

[0025] Furthermore, although the term "message" may be used in the description of the implementation, the application can be applied to many types of networks and data. Moreover, although specific types of connections, messages, and signaling may be described in exemplary embodiments, this application is not limited to specific types of connections, messages, and signaling.

[0026] In some embodiments, the method, system, and / or computer program product utilizes a decentralized database (such as a blockchain) as a distributed storage system comprising multiple nodes communicating with each other. The decentralized database comprises an append-only immutable data structure similar to a distributed ledger capable of maintaining records among mutually untrusted parties. Untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records, and there is no consensus among the distributed peers. For example, peers may execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build a hashchain on the blocks. For consistency, this process forms a ledger by ordering storage transactions as needed.

[0027] In different embodiments, permissioned and / or permissionless blockchains can be used. In public or permissionless blockchains, anyone can participate without a specific identity (e.g., maintaining anonymity). Public blockchains can involve local cryptography and use consensus based on different protocols (such as proof-of-work). On the other hand, permissioned blockchain databases provide secure interactions between a group of entities that share common goals but do not fully trust each other, such as businesses exchanging funds, goods, information, etc.

[0028] Furthermore, in some embodiments, the method, system, and / or computer program product may utilize a blockchain that operates arbitrary, programmable logic tailored for a distributed storage scheme and referred to as a "smart contract" or "link code." In some cases, dedicated link code, referred to as system link code, may exist to manage functions and parameters. The method, system, and / or computer program product may further utilize smart contracts, which are trusted distributed applications that leverage the tamper-proof properties of the blockchain database and a fundamental protocol between nodes, referred to as an authorization or authorization policy. Blockchain transactions associated with this application can be "signed" before being submitted to the blockchain, while unsigned transactions are ignored.

[0029] The endorsement policy allows the linker code to specify the endorsers for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to validate it. After validation, the transaction enters the ordering phase, where a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks.

[0030] In some embodiments, the method, system, and / or computer program product may utilize nodes as communication entities within a blockchain system. A "node" is defined in the sense that multiple nodes of different types can run on the same physical server, and can perform logical functions. Nodes are grouped in trust domains and associated with logical entities that control them in different ways. Nodes may include different types, such as client or commit-client nodes, which submit transaction calls to signers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes).

[0031] Another type of node is the peer node, which receives transactions submitted by clients, submits transactions, and maintains the state and copy of the blockchain's ledger of transactions. Peers can also act as endorsers, although this is not mandatory. Ordering service nodes, or orderers, are nodes that run communication services to all nodes. In some instances, ordering service nodes implement delivery guarantees, such as broadcasting to every peer in the system, when committing / confirming transactions and modifying the world state of the blockchain. The world state is another name for the initial blockchain transaction, and it typically includes control and setup information.

[0032] In some embodiments, the methods, systems, and / or computer program products may utilize a ledger, which is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions may be caused by link code calls (e.g., transactions) submitted by participants (e.g., client nodes, ordering nodes, signer nodes, peer nodes, etc.). Each participant (such as a peer node) may maintain a copy of the ledger. In some embodiments, a participant is a party involved in the operation (e.g., an organization with nodes on a blockchain network). A transaction may result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as creation, update, deletion, etc. The ledger includes a blockchain (also called a chain) for storing immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0033] In some embodiments, the methods, systems, and / or computer program products described herein can utilize a chain, which is a transaction log structured as hashed linked blocks, with each block containing a sequence of N transactions, where N is equal to or greater than 1. The block header includes hashes of the block's transactions and hashes of the headers of previous blocks. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents every transaction that has appeared before on the chain, thus ensuring that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (e.g., local, attached storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

[0034] The current state of an immutable ledger represents the latest value of all keys included in the chain's transaction log. Because the current state represents the latest key value known to the channel, it is sometimes referred to as the world state. Chain calls execute transactions targeting the ledger's current state data. To enable these chained code interactions, the latest values ​​of keys can be stored in a state database. The state database can simply be an indexed view of the chain's transaction log; therefore, it can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when peer nodes start up and before accepting transactions.

[0035] The difference between blockchain and traditional databases is that blockchain is not a centralized store, but a decentralized, immutable, and secure store where nodes can share changes to records in the store. Some inherent properties of blockchain that contribute to its realization include, but are not limited to, the immutable ledger, smart contracts, security, privacy, decentralization, consistency, authentication, and accessibility described further herein.

[0036] Specifically, blockchain ledger data is immutable, and it provides an efficient method for processing operations within a blockchain network. Furthermore, the use of encryption in blockchain provides security and establishes trust. Smart contracts manage the state of assets to complete their lifecycle, thus dedicated nodes ensure that blockchain operations with anonymity requirements can securely submit their operations to the blockchain network. Example blockchains are permissioned and decentralized. Therefore, each end user can have its own copy of the ledger to access. Multiple organizations (and peers) can be bound together on the blockchain network. Key organizations can act as authorized peers to verify the execution results of smart contracts, read-set, and write-set operations. In other words, the inherent characteristics of blockchain provide an efficient implementation for processing private transactions within a blockchain network.

[0037] One benefit of the exemplified embodiments is that they improve the functionality of computing systems by implementing methods for processing private transactions within a blockchain network. Through the blockchain system described herein, a computing system (or a processor within a computing system) can perform functions utilizing a blockchain network for private transaction processing by providing access to capabilities such as distributed ledgers, peer-to-peer mechanisms, cryptography, MSPs, and event processing. Furthermore, blockchain enables the creation of business networks and allows any user or organization to participate. Thus, the blockchain is more than just a database. It has the ability to create user networks and onboard / offboard organizations to collaborate and execute service processes in the form of smart contracts.

[0038] Furthermore, traditional databases may not be useful for implementing the exemplary embodiments because they do not involve all parties on the network, do not create trusted collaboration, and do not provide efficient methods for securely and efficiently submitting operations. Traditional databases do not provide tamper-proof storage and do not offer guaranteed valid transactions. Therefore, the exemplary embodiments provide specific solutions to the problems in the domain / field of anonymously submitting operations in a blockchain network.

[0039] Figure 1 A logical network diagram 100 for smart data annotation in a blockchain network is shown according to an exemplary embodiment.

[0040] refer to Figure 1Example network 100 includes node 102 connected to other blockchain (BC) nodes 105 representing an organization of document owners. Node 102 may connect to blockchain 106, which has a ledger 108 for storing data 110 to be shared among nodes 105. While this example describes only one node 102 in detail, multiple such nodes may connect to blockchain 106. It should be understood that node 102 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of node 102 disclosed herein. Node 102 may be a computing device or server computer, etc., and may include processor 104, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or another hardware device. Although a single processor 104 is depicted, it should be understood that node 102 may include multiple processors, multiple cores, etc., without departing from the scope of the node 102 system. Distributed file storage 150 is accessible by processor node 102 and other BC nodes 105. The distributed file storage 150 can be used to store documents identified in the ledger 108.

[0041] Node 102 may also include a non-transitory computer-readable medium 112, which may have machine-readable instructions stored thereon that are executable by processor 104. Examples of machine-readable instructions are shown as 114-118 and discussed further below. Examples of non-transitory computer-readable medium 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, non-transitory computer-readable medium 112 may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), hard disk, optical disk, or other types of storage devices.

[0042] Processor 104 can execute machine-readable instructions 114 that associate users with tuples. As described above, blockchain ledger 108 can store data 110 to be shared among nodes 105. Blockchain network 106 can be configured to use one or more smart contracts to manage transactions among multiple participating nodes. Documents linked to annotation information can be stored in distributed file storage 150. Processor 104 can execute machine-readable instructions 116 that associate publishers with PK public keys. Processor 104 can execute machine-readable instructions 118 that are signed by users for operations.

[0043] Figure 2A This illustrates a blockchain architecture configuration 200 according to an example embodiment. (Refer to...) Figure 2AThe blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain nodes 202. Blockchain nodes 202 may include one or more peer nodes 204, 206, and 208 (these four nodes are depicted only as an example). These nodes participate in many activities, such as the blockchain transaction addition and confirmation process (consistency). One or more of blockchain nodes 204-210 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain nodes 202 in the architecture 200. Blockchain nodes 204-210 may initiate blockchain authentication and attempt to write to the blockchain immutable ledger stored in blockchain layer 216, a copy of which may also be stored on the supporting physical infrastructure 214. The blockchain configuration 200 may include one or more applications 224 linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., linker code, smart contracts, etc.). The stored program / application code 220 may be created according to a custom configuration sought by the participants and may maintain the participants' own state, control their own assets, and receive external information. This can be deployed as a transaction and installed on all blockchain nodes 204-210 via attachment to the distributed ledger.

[0044] The blockchain infrastructure or platform 212 may include different layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure 214, which can be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 216 may expose an interface that provides access to the handler code 220 and the virtual execution environment necessary to participate in the physical infrastructure 214. The cryptographic trust service 218 can be used to verify transactions (such as asset exchange transactions) and maintain information privacy.

[0045] Figure 2AThe blockchain architecture configuration 200 can process and execute program / application code 220 via one or more interfaces and services exposed by the blockchain platform 212. Code 220 can control blockchain assets. For example, code 220 can store and transfer data and can be executed by nodes 204-210 in the form of smart contracts and associated chained code, which has conditions or other code elements subject to its execution. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or other notifications of changes, updates, etc. Smart contracts themselves can be used to identify rules associated with authorization and access requirements and use of the ledger. For example, document attribute information 226 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The result 228 of this processing can include multiple linked shared documents. Physical infrastructure 214 can be used to retrieve any data or information described herein.

[0046] Smart contracts can be created using high-level applications and programming languages ​​and then written to blocks in a blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that can be performed in response to the fulfillment of conditions associated with the smart contract. Execution of a smart contract can trigger trusted modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated across a distributed network of blockchain peers using one or more consensus protocols.

[0047] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the outputs of different logical operations to the blockchain. The code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by smart contracts is stored in memory by the provisioned execution environment and then deleted once the data needed by the blockchain is identified.

[0048] Linking code can include a code interpretation of a smart contract with additional features. As described herein, linking code can be program code deployed on a computing network, where it is executed and verified together by a chain confirmer during the shared process. Linking code receives hashes and retrieves hashes from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the linking code sends an authorization key to the requested service. Linking code can write data associated with cryptographic details to the blockchain.

[0049] Figure 2B A blockchain according to an example embodiment is shown (e.g., Figure 1 The example shown is a blockchain transaction flow 250 between nodes of blockchain 106. (See also...) Figure 2B A general description of transaction flow 250 will be given below, followed by more specific examples. Transaction flow 250 may include a transaction proposal 291 sent by application client node 260 to first accrediting peer node 281. First accrediting peer 281 may verify the client signature and execute the chaining function to initiate the transaction. Output may include the chaining result, a set of key / value versions read in the chaining (read set), and a set of key / value versions written in the chaining (write set). If approved, proposal response 292 is sent back to client 260 along with the accrediting signature. Client 260 assembles the signature into a transaction payload 293 and broadcasts it to ordering service (fourth peer) node 284. Ordering service node 284 then delivers the ordering transaction as a block to all additional peers 281, 282, and 283 on the same channel. Each additional peer 281-283 may verify the transaction before it is committed to the blockchain. For example, peers 281-283 can check the signature policy to ensure that the correct allocation of peers specified in transaction proposal 291 has signed the result and verified the signature on transaction payload 293. In some embodiments, one or more of the peers may be manager nodes.

[0050] A more specific description of transaction flow 250 can be understood through a more concrete example. First, client node 260 initiates transaction proposal 291 by constructing and sending a request to first peer node 281, which is the signer. Client 260 may include an application utilizing a supported software development kit (SDK) that leverages available APIs to generate transaction proposals. A proposal is a request to call a linker function to allow data to be read and / or written to the ledger (i.e., writing new key-value pairs for assets). The SDK can act as a shim to encapsulate the transaction proposal into an appropriate architectural format (e.g., a protocol buffer over a remote procedure call (RPC)) and use the client's cryptographic certificate to generate a unique signature for the transaction proposal.

[0051] In response, the accredited peer 281 verifies that (a) the transaction proposal is well-formed, (b) the transaction has not been committed in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in this instance, client 260) is properly authorized to execute the proposed operation on the channel. The accredited peer 281 can take the transaction proposal input as arguments to the invoked linker function. The linker is then executed against the current state database to produce transaction results including response values, a set of reads, and a set of writes. However, no ledger is updated at this time. This set of transaction results, along with the signature of the accredited peer 281, is passed back to client 260's SDK as a proposal response 292, which parses the payload consumed by the application.

[0052] In response, the application of client 260 checks / verifies the signature of the approved peer 281 and compares the suggested response 292 to determine if the suggested response 292 is valid. If the linker only queries the ledger, the application will check the query response and will generally not commit the transaction to the ordering service node 284. If the client application intends to commit the transaction to the ordering service node 284 to update the ledger, the application determines whether the approval policy specified before the commit has been satisfied (i.e., whether all peer nodes approve the transaction). Here, client 260 may include only one of the many parties to the transaction. In this case, each client may have its own approval node, and each approval node may be required to approve the transaction. This architecture allows the signature policy to be enforced by the peers and maintained during the commit verification phase, even if the application chooses not to check the response or otherwise forwards the unpersonalized transaction.

[0053] After a successful check, client 260 assembles the signatures into transaction 293 and broadcasts the transaction proposal and response to ordering node 284 within the transaction message. Transaction 293 may contain a read / write set, the signatures of the acknowledging peers, and the channel ID. Ordering node 284 does not need to check the entire contents of the transaction in order to execute its operation. Instead, ordering node 284 can simply receive transactions from all channels in the network, sort them chronologically by channel, and create a transaction block for each channel.

[0054] The block of transaction 293 is delivered on the channel from sorting node 284 to all other peer nodes 281-283. Transaction 294 within the block is validated to ensure any approval policies are met and to ensure the ledger state for the read set variable remains unchanged, as the read set was generated by the transaction execution. Transaction 294 within the block is marked as valid or invalid. Furthermore, in operation 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events are emitted to notify clients that transaction (invocation) 293 has been immutably appended to the chain, and to notify whether transaction 293 has been validated or invalidated.

[0055] Figure 3A An example of a permissioned blockchain network 300 characterized by a distributed, decentralized peer-to-peer architecture, according to an example embodiment, is shown. In this example, a blockchain user 302 can initiate transactions to a permissioned blockchain 304. In this example, transactions can be deployments, invocations, or queries, and can be published via client-side applications utilizing the SDK, directly through APIs, etc. Network 300 can provide access to regulators 306, such as auditors. A blockchain network operator 308 manages member permissions, such as registering regulator 306 as an "auditor" and blockchain user 302 as a "client." Auditors can be limited to querying the ledger, while clients can be authorized to deploy, invoke, and query certain types of linker code.

[0056] Blockchain developer 310 can write linking code and client-side applications. Blockchain developer 310 can directly deploy the linking code to network 300 via an interface. To include certificates from legacy data source 312 in the linking code, developer 310 can use an out-of-band connection to access the data. In this example, blockchain user 302 connects to the permissioned blockchain 304 through one of peer nodes 314 (any of reference nodes 314a-e). Before any transaction, peer node 314 (e.g., node 314a) retrieves user 302's registration and transaction certificates from a certificate authority 316 that manages user roles and permissions. In some cases, blockchain users must possess these digital certificates to conduct transactions on the permissioned blockchain 304. Meanwhile, users attempting to utilize the linking code may be required to verify their certificates on legacy data source 312. To confirm user 302's authorization, the linking code can use an out-of-band connection to that data via legacy processing platform 318.

[0057] Figure 3BThis illustrates another example of a permitted blockchain network 320 characterized by a distributed, decentralized peer-to-peer architecture, according to an example embodiment. In this example, blockchain user 322 can submit transactions to a permitted blockchain 324. In this example, transactions can be deployments, invocations, or queries, and can be published via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 326, such as auditors. Blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and blockchain user 322 as "clients." Auditors can be restricted to querying the ledger only, while clients can be authorized to deploy, invoke, and query certain types of linker code.

[0058] Blockchain developer 330 writes the linker code and client-side application. Blockchain developer 330 can deploy the linker code directly to the network via an interface. To include certificates from traditional data source 332 in the linker code, developer 330 can use an out-of-band connection to access the data. In this example, blocking chain user 322 connects to the network via peer node 334 (any of reference nodes 334a-e). Before any transaction, peer node 334 (e.g., node 334a) retrieves the user's registration and transaction certificates from certificate authority 336. In some cases, blockchain users must possess these digital certificates to conduct transactions on the permissioned blockchain 324. Meanwhile, users attempting to utilize the linker code may be required to verify their certificates on traditional data source 332. To confirm the user's authorization, the linker code can use an out-of-band connection to that data via traditional processing platform 338.

[0059] In some embodiments of the invention, the blockchain herein may be a permissionless blockchain. In contrast to permissioned blockchains that require permission to join (e.g., blockchains 304 and 324), anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network by submitting a transaction, thus adding entries to the ledger. Furthermore, all parties have the option to run nodes on the system and employ a mining protocol to help verify transactions.

[0060] Figure 3CA network 350 according to an example embodiment is shown, where transactions are processed by a permissionless blockchain 352 comprising a plurality of nodes 354. A sender 356 wishes to send payment or some other form of value (e.g., contract, medical record, agreement, goods, services, or any other asset that may be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In some embodiments, each of the sender device 356 and the receiver device 358 may have a digital wallet (associated with blockchain 352) that provides a user interface control and display of transaction parameters. In response, the transaction is broadcast across blockchain 352 to nodes 354 (referencing any of nodes 354a-e).

[0061] Based on the network parameters of blockchain 352, nodes use verification module 360 ​​to verify transactions according to rules established by the creator of permissionless blockchain 352 (which can be predefined or dynamically assigned). For example, this can include verifying the identities of the parties involved. Transactions can be verified immediately, or they can be queued with other transactions, and node 354 determines whether the transaction is valid based on the network rule set.

[0062] In structure 362, valid transactions are formed into blocks and sealed with locks (hashes). This process can be performed by nodes in mining nodes 354. Mining nodes can utilize additional software specifically designed for mining and creating blocks for the permissionless blockchain 352. Each block can be identified by a hash (e.g., 256 bits) created using an algorithm agreed upon by network 350. Each block may include a header, a pointer or reference to the hash of the header of a previous block in the chain, and a set of valid transactions. The reference to the hash of a previous block is associated with the creation of a secure, independent chain for the block.

[0063] Before a block can be added to blockchain 352, it must be verified. Verification of the permissionless blockchain 352 can include proof-of-work (PoW), which is the solution to a puzzle derived from the block header. While in Figure 3C Not shown in the example, but another process used to verify blocks is proof-of-stake. Unlike proof-of-work, where the algorithm rewards miners who solve mathematical problems with proof-of-stake, the creator of a new block is chosen deterministically based on their wealth, also defined as "staking". A similar proof is then performed by the chosen / selected node.

[0064] Using the mining module 364, nodes attempt to resolve a block by incrementally changing a variable until the solution satisfies the network-wide objective. This produces Proof-of-Work (PoW), thus ensuring the correct answer. In other words, a potential solution must prove that it exhausts computational resources while solving the problem. In some types of permissionless blockchains, miners can be rewarded for correctly mining the value of the block (e.g., coins, etc.).

[0065] Here, the PoW process makes modifying blockchain 352 extremely difficult by linking blocks together, as an attacker would have to modify all subsequent blocks to accept a modification to one block. Furthermore, the difficulty of modifying a block increases with the mining of new blocks, and the number of subsequent blocks also increases. Using the allocation module 366, successfully verified blocks are allocated through the permissionless block chain 352, and all nodes 354 add the block to the majority chain of the auditable ledger of the permissionless block chain 352. Additionally, the value in the transaction committed by sender 356 is deposited into or otherwise transmitted to the digital wallet of recipient device 358.

[0066] Figure 4A This illustrates a blockchain system according to an example embodiment, where the execution of a new block is added to a distributed ledger 420. Figure 4B The contents of a new data block structure 430 for blockchain are shown according to an example embodiment. The new data block 430 may contain document link data.

[0067] refer to Figure 4A In process 400, a client (not shown) may submit a transaction to blockchain nodes 411, 412, and / or 413. The client can be an instruction received from any source to formulate an activity on blockchain 422. As an example, the client may be an application acting on behalf of a requester (such as a device, individual, or entity) to propose a transaction for blockchain 422. Multiple blockchain peers (e.g., blockchain nodes 411, 412, and 413) may maintain the state of the blockchain network and a copy of the distributed ledger 420. Different types of blockchain nodes / peers may exist in the blockchain network, including acknowledging peers and committing peers. Acknowledging peers simulate and acknowledge transactions proposed by clients, while committing peers verify acknowledgments, validate transactions, and commit transactions to the distributed ledger 420. In this example, each of blockchain nodes 411, 412, and 413 may act as a sign-off node, a commit node, or both.

[0068] Distributed ledger 420 comprises a blockchain storing immutable, ordered records in blocks (e.g., data blocks 423, 424, 425, 426, 427, 428, 429, and 430), and a state database 424 (current world state) maintaining the current state of blockchain 422. Each channel may exist in distributed ledger 420, and each peer maintains its own copy of distributed ledger 420 for each channel in which they are members. Blockchain 422 is a transaction log constructed as hash-linked blocks, where each block contains a sequence of N transactions. Blocks may include, for example, Figure 4B The various components shown. Links to blocks (e.g., data blocks 423-430). Figure 4A(As indicated by the arrow in the diagram) can be generated by adding the hash of the header of the previous block to the block header of the current block. In this way, all transactions on blockchain 422 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the links, the latest block in blockchain 422 (e.g., data block 430) represents every transaction that occurred before it. Blockchain 422 can be stored on a peer-to-peer file system (local or attached storage) that supports attached-only blockchain workloads.

[0069] The current state of blockchain 422 and distributed ledger 420 can be stored in state database 424. Here, the current state data represents the latest value of all keys that were ever included in the chain transaction log of blockchain 422. Chain calls execute transactions by referring to the current state in state database 424. To make these chain code interactions highly efficient, the latest values ​​of all keys are stored in state database 424. State database 424 can include an indexed view of the transaction log entering blockchain 422. Therefore, it can be regenerated from the chain at any time. State database 424 can be automatically restored (or generated if needed) upon peer startup before a transaction is accepted.

[0070] The accrediting nodes (411, 412, and / or 413) receive transactions from the client and accredit them based on the simulation results. The accrediting nodes hold the smart contract representing the simulated transaction proposal. When an accrediting node accredits a transaction, it creates a transaction accreditation, a signed response representing the accreditation of the simulated transaction from the accrediting node to the client application. The method of accrediting transactions depends on the accreditation policy that can be specified in the linker code. An example of an accreditation policy is "majority accrediting peers must accredit transactions." Different channels can have different accreditation policies. The client application forwards the verified transaction to the subscription service 410.

[0071] The ordering service 410 accepts signed transactions, orders them into blocks, and delivers these blocks to commit peers. For example, the ordering service 410 can initiate new blocks when a transaction threshold is reached, a timer times out, or another condition is met. Figure 4A In the example, blockchain node 412 is a committing peer that has received the new data block 430 to store on blockchain 422. The first block 423 in blockchain 422 can be called the producing block, which includes information about the blockchain, its members, the data stored in it, etc.

[0072] The ordering service 410 can consist of a cluster of orderers. The ordering service 410 does not handle transactions, smart contracts, or maintain a shared ledger. Instead, it accepts signed transactions and specifies the order in which those transactions are submitted to the distributed ledger 420. The architecture of the blockchain network can be designed so that the specific implementation of 'ordering' (e.g., Solo, Kafka, Byzantine fault tolerance, etc.) becomes a pluggable component.

[0073] Transactions are written to the distributed ledger 420 in a consistent order. This order is established to ensure that updates to the state database 424 are valid when they are committed to the network. Unlike cryptocurrency blockchain systems where ordering occurs through solving cryptographic puzzles or mining (e.g., Bitcoin), in this example, the parties to the distributed ledger 420 can choose the ordering mechanism best suited to the network.

[0074] When the ordering service 410 initializes a new data block 430, the new data block 430 can be broadcast to commit peers (e.g., blockchain nodes 411, 412, and 413). In response, each commit peer verifies the transactions within the new data block 430 by checking to ensure that the read set and write set still match the current world state in the state database 424. Specifically, the commit peers can determine whether the read data present when the signer simulates the transaction is the same as the current world state in the state database 424. When the commit peers verify the transaction, the transaction is written to blockchain 422 on the distributed ledger 420, and the state database 424 is updated with the write data from the read-write set. If the transaction fails, i.e., if the commit peers find that the read-write set does not match the current world state in the state database 424, the transaction ordered into the block can still be included in the block, but it can be marked as invalid, and the state database 424 may not be updated.

[0075] refer to Figure 4B A new data block 430 (also referred to as a data block) stored on blockchain 422 of the distributed ledger 420 may include multiple data segments, such as block header 440, block data 450, and block metadata 460. It should be understood that different descriptions of blocks and their contents, such as the new data block 430 and its contents, are possible. Figure 4B The examples shown are merely illustrative and do not imply limitation on the scope of the illustrated implementation. New data block 430 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within block data 450. New data block 430 may also include previous blocks (e.g., in the block header 440) that were previously included in the block header. Figure 4AThe link is on blockchain 422. Specifically, block header 440 may contain the hash of the header of the previous block. Block header 440 may also include a unique block number (e.g., data blocks 423-430), the hash of block data 450 of the new data block 430, etc. The block number of the new data block 430 may be unique and assigned in a different order, such as an incrementing / sequential order starting from zero.

[0076] Block data 450 can store transaction information for each transaction recorded within new data block 430. For example, transaction data may include the transaction type, version, timestamp, channel ID of the distributed ledger 420, one or more transaction IDs, period, payload visibility, linker path (deployment transaction), linker name, linker version, inputs (linker and functionality), client (creator) identifiers (such as public keys and certificates), client signature, approver identity, approver signature, suggestion hash, linker event, response status, namespace, read set (a list of keys and versions read by the transaction, etc.), write set (a list of keys and values, etc.), start key, end key, list of keys, Merkel tree query summary, etc. Transaction data can be stored for each of N transactions.

[0077] In some embodiments, block data 450 may also store new data 462 that adds additional information to the hash chain of blocks in blockchain 422. This additional information includes one or more of the steps, features, processes, and / or actions described or depicted herein. Thus, new data 462 may be stored in an immutable block log on the distributed ledger 420. Some benefits of storing such new data 462 are reflected in the various embodiments disclosed and depicted herein. Although in Figure 4B In the block data 450, new data 462 is depicted, but it can also be located in the block header 440 or the block metadata 460. New data 462 may include document combination keys used to link documents within the organization.

[0078] Block metadata 460 can store multiple fields of metadata (e.g., as a byte array). Metadata fields may include a signature about block creation, a reference to the last configured block, transaction filters identifying valid and invalid transactions within the block, the last offset remaining from the sorting service that sorts the blocks, etc. The signature, last configured block, and sorter metadata can be added by the sorting service 410. Meanwhile, the block submitter (such as blockchain node 412) can add valid / invalid information based on annotation strategies, verification of read / write sets, etc. Transaction filters may include a byte array of size equal to the number of transactions in block data 450 and a verification code identifying whether a transaction is valid / invalid.

[0079] Figure 4CA blockchain 470 for digital content is illustrated according to some embodiments described herein. Digital content may include one or more files and associated information. The files may contain media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of this blockchain act as safeguards to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where acceptability rules apply, or in other settings where evidence or the presentation and use of digital information is of other interest. In this context, the digital content may be referred to as digital evidence.

[0080] Blockchains can be formed in various ways. In some embodiments, digital content can be included within and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value (e.g., header, value, etc.) of reference information along with its associated digital content. The hash value and the associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing previous blocks. This can be illustrated as follows:

[0081] Block 1 Block 2 ... Block N

[0082] Hash value 1 Hash value 2 Hash value N

[0083] Digital content 1 Digital content 2 Digital content N

[0084] In some embodiments, digital content may not be included in the blockchain. For example, the blockchain may store the encrypted hash of the content of each block without any digital content. The digital content may be stored in a separate storage area or memory address associated with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area or even a separate relational database. By obtaining or querying the hash value of the block of interest, and then looking up the value stored in the storage area corresponding to that actual digital content, the digital content of each block can be referenced or accessed. This operation can be performed, for example, by a database gatekeeper. This can be illustrated as follows:

[0085] Blockchain storage area

[0086] Block 1 hash value Block 1 hash value... content ... ... ...

[0090] Block N hash value Block N hash value… content

[0091] exist Figure 4CIn an exemplary embodiment, blockchain 470 includes a plurality of blocks 4781, 4782, ..., 478 linked together in an ordered sequence cryptography. N Where N≥1. Used to link blocks 4781, 4782, ..., 478 N The encryption can be any function of multiple keyed or non-keyed hash functions. In some implementations, blocks 4781, 4782, ..., 478... N The input is subjected to a hash function that produces an n-bit alphanumeric output (where n is 256 or another number) based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, the Merkle-Damgard algorithm, the HAIFA algorithm, the Merkle-tree algorithm, random number-based algorithms, and collision-resistant pseudo-random functions (PRFs). In another embodiment, blocks 4781, 4782, ..., 478... N Links can be encrypted using functions other than hash functions. For illustrative purposes, the following description refers to hash functions (e.g., SHA-2).

[0092] Blocks 4781, 4782, ..., 478 in the blockchain N Each of these includes a header, a file version, and a value. Due to hashing in the blockchain, the header and value are different for each block. In some embodiments, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0093] The first block in the blockchain, 4781, is called the generating block and includes a header 4721, the original file 4741, and an initial value 4761. The hashing scheme used for the generating block, and indeed in all subsequent blocks, can vary. For example, all the information in the first block 4781 can be hashed together at once, or a portion of the information in the first block 4781 can be hashed separately, and then the hash of the separately hashed portions can be performed.

[0094] The second header 4721 may include one or more initial parameters, which may include, for example, a version number, timestamp, random number, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 4741 and / or the blockchain. The first header 4721 may be automatically generated (e.g., via blockchain network management software) or manually generated by blockchain participants. This is consistent with other segments 4782 to 478 in the blockchain. N Unlike the previous block, the header 4721 in the origin block 4781 does not reference the previous block, simply because the previous block does not exist.

[0095] The original file 4741 in the generating block can be, for example, data captured by a device, with or without processing, before being included in the blockchain. The original file 4741 is received from a device, media source, or node through a system interface. The original file 4741 is associated with metadata, which may be generated manually or automatically by a user, device, and / or system processor, for example. The metadata may be included in the first block 4781 associated with the original file 4741.

[0096] The value 4761 in the generation block is an initial value generated based on one or more unique attributes of the original file 4741. In some embodiments, the one or more unique attributes may include the hash value of the original file 4741, metadata of the original file 4741, and other information associated with the file. In one implementation, the initial value 4761 may be based on the following unique attributes:

[0097] 1) The hash value calculated using SHA-2 of the original file

[0098] 2) Generating device ID

[0099] 3) Start timestamp of the original file

[0100] 4) Initial storage location of the original file

[0101] 5) The blockchain network member ID that currently controls the original file and associated metadata.

[0102] Other blocks 4782 to 478 in the blockchain N It also has a header, filename, and value. However, unlike header 4721 in the first block, headers 4722 to 472 in the other blocks... N Each of the remaining blocks includes the hash of the block immediately preceding it. The hash of the previous block can be either the hash of the previous block's header or the hash of the entire previous block. By including the hash of the previous block in each of the remaining blocks, a block-by-block tracing back to the origin block (and associated original file) can be performed, as indicated by arrow 480, to establish an auditable and immutable chain of custody.

[0103] Headers 4722 to 472 in other blocks N Each of these may also include other information, such as version number, timestamp, random number, root information, difficulty level, consensus protocol and / or other parameters or information associated with the corresponding file and / or blockchain.

[0104] Files 4742 to 474 in other blocks NIt can be equal to the original file or a modified version of the original file in the generated block, depending on, for example, the type of processing performed. The type of processing performed can vary from block to block. The processing can involve, for example, any modification to the file in the previous block, such as editing information or otherwise changing the contents of the file, removing information from these files, or adding or appending information to these files.

[0105] Alternatively, processing may involve copying a file solely from a previous block, changing the storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing actions relative to the file and / or its associated metadata on the blockchain. Processes involving file analysis may include, for example, appending, including, or otherwise associating different analyses, statistics, or other information associated with the file.

[0106] Other blocks 4762 to 476 in other blocks N Each value in a block is unique and distinct as a result of any processing performed. For example, a value in any given block corresponds to an updated version of a value in a previous block. This update is reflected in the hash of the block to which the value was assigned. The block's value thus provides an indication of what processing was performed within the block and also allows for tracing back to the original file via the blockchain. This tracing confirms the file's supervisory chain throughout the blockchain.

[0107] For example, consider a scenario where a portion of a file in a previous block is edited, blocked, or pixelated to protect the identity of the person shown in the file. In this case, the block containing the edited file could include metadata associated with the edited file, such as how the edit was performed, who performed the edit, the timestamp of the edit, etc. The metadata can be hashed to form values. Because the metadata of a block differs from the information hashed to form values ​​in a previous block, these values ​​are distinct from each other and can be recovered during decryption.

[0108] In some embodiments, the value of a previous block can be updated (e.g., a newly calculated hash value) to form the value of the current block when any one or more of the following occur. In this exemplary embodiment, a new hash value can be calculated by hashing all or part of the information indicated below.

[0109] a) If the file has been processed in any way (e.g., if the file has been edited, copied, changed, accessed, or subjected to some other action), the hash value calculated by the new SHA-2 is...

[0110] b) New storage location of the file

[0111] c) New metadata identified and associated with the file

[0112] d) Transferring access to or control of the file from one blockchain participant to another.

[0113] Figure 4D Block 490 is shown, according to some embodiments, which can represent the structure of blocks in a blockchain (e.g., 470). Block (e.g., Block...) i (Including header 472) i Document 474 i Sum of 476 i .

[0114] The header 472i includes the previous block. i-1 The hash value and additional reference information, which can be, for example, any type of information discussed herein (e.g., header information including references, characteristics, parameters, etc.). All blocks reference the hash of the previous block, except for the block that produced it. The hash value of the previous block can be simply the hash of the header in the previous block or the hash of all or part of the information in the previous block (including files and metadata).

[0115] Document 474 i This includes multiple data sets, such as data 1, data 2, ..., data N in sequence. The data is tagged using metadata 1, metadata 2, ..., metadata N, which describes the content and / or characteristics associated with the data. For example, the metadata for each data set may include a timestamp indicating the data, keywords indicating the person or other content depicted in the data, and / or information that can help establish the validity and content of the document as a whole, and particularly other characteristics of its use of digital evidence, such as those described in conjunction with the embodiments discussed below. In addition to the metadata, each data set may be tagged with references to previous data (REF 1, REF 2, ..., REF N) to prevent tampering, gaps in the document, and sequential references through the document.

[0116] Once metadata is assigned to data (e.g., via a smart contract), it cannot be altered without a hash change, as this can be easily identified as invalid. Therefore, metadata creates data records containing information that can be accessed and used by participants in the blockchain.

[0117] Value 476 i It is a hash value or another value calculated based on any type of information discussed earlier. For example, for any given block, Block iThe value of this block can be updated to reflect the processing performed for that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other actions or information to be added. Although the value in each block is shown as separate from the metadata and header of the file's data, in another embodiment, the value may be based partly or entirely on that metadata.

[0118] Once block 490 is formed, at any point in time, the immutable custodian chain of the file can obtain the transaction history of values ​​across blocks by querying the blockchain. This query or tracing process can begin by decrypting the value of the most currently included block (e.g., the last (Nth) block) and then continue decrypting the values ​​of other blocks until the generating block is reached and the original file is recovered. Decryption may also include decrypting the header and file, along with associated metadata, in each block.

[0119] Decryption is performed based on the type of encryption that occurs within each block. This can involve using a private key, a public key, or a public-private key pair. For example, when using asymmetric encryption, blockchain participants or processors in the network can generate public and private key pairs using a pre-defined algorithm. The public and private keys are linked together through some mathematical relationship. The public key can be publicly distributed and used as an address to receive messages from other users, such as an IP address or home address. The private key is kept secret and used to digitally sign messages sent to other blockchain participants. The signature is included in the message, allowing the recipient to verify it using the sender's public key. In this way, the recipient can be confident that only the sender could have sent the message.

[0120] Generating key pairs is similar to creating an account on the blockchain, but it doesn't require actual registration anywhere. Furthermore, every transaction executed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and process documents on the blockchain (if within the permitted scope determined by smart contracts).

[0121] As discussed in more detail herein, it is anticipated that some or all of the operations of some embodiments of the methods described herein may be performed in an alternative order or may not be performed at all; furthermore, multiple operations may occur simultaneously or as part of a larger process.

[0122] Figure 5A high-level block diagram of an exemplary computer system 501, according to embodiments of the present disclosure, is shown that can be used to implement one or more of the methods, tools, and modules described herein and any associated functions (e.g., using one or more processor circuits of a computer or a computer processor). In some embodiments, the main components of the computer system 501 may include one or more CPUs 502, a memory subsystem 504, a terminal interface 512, a storage interface 516, an I / O (input / output) device interface 514, and a network interface 518, all of which may be directly or indirectly communicatively coupled for inter-component communication via a memory bus 503, an I / O bus 508, and an I / O bus interface unit 510.

[0123] Computer system 501 may include one or more general-purpose programmable central processing units (CPUs) 502A, 502B, 502C, and 502D, collectively referred to herein as CPU 502. In some embodiments, computer system 501 may include a typical multiple processors of a relatively large system; however, in other embodiments, computer system 501 may alternatively be a single CPU system. Each CPU 502 may execute instructions stored in memory subsystem 504 and may include one or more onboard caches.

[0124] System memory 504 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 522 or cache memory 524. Computer system 501 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 526 may be configured to read from and write to non-removable, non-volatile magnetic media (such as a "hard disk drive"). Although not shown, a disk drive may be provided for reading from or writing to a removable non-volatile disk (e.g., a "floppy disk"), or an optical disk drive may be provided for reading from or writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM, or other optical media). Furthermore, memory 504 may include flash memory, such as a flash stick drive or a flash drive. Memory devices may be connected to memory bus 503 via one or more data media interfaces. Memory 504 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of different embodiments.

[0125] One or more programs / utilities 528, each having at least one set of program modules 530, may be stored in memory 504. Programs / utilities 528 may include a hypervisor (also called a virtual machine monitor), one or more operating systems, one or more applications, other program modules, and program data. Each or some combination of the operating system, one or more applications, other program modules, and program data may include an implementation of a network environment. Programs 528 and / or program modules 530 generally perform the functions or methods of different embodiments.

[0126] Although the memory bus 503 is Figure 5 The diagram illustrates a single bus structure providing a direct communication path between CPU 502, memory subsystem 504, and I / O bus interface 510. However, in some embodiments, memory bus 503 may include multiple different buses or communication paths, which may be arranged in any of a variety of forms, such as point-to-point links in hierarchical, star, or network configurations, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Furthermore, although I / O bus interface 510 and I / O bus 508 are shown as a single corresponding unit, in some embodiments, computer system 501 may include multiple I / O bus interface units 510, multiple I / O buses 508, or both. Further, while multiple I / O interface units are shown separating I / O bus 508 from different communication paths running to different I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0127] In some embodiments, computer system 501 may be a multi-user mainframe computer system, a single-user system, a server computer, or a similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 501 may be implemented as a desktop computer, portable computer, laptop or notebook computer, tablet computer, pocket computer, telephone, smartphone, network switch or router, or any other suitable type of electronic device.

[0128] It is important to note that Figure 5 This description aims to depict representative major components of an exemplary computer system 501. However, in some embodiments, a single component may have more than Figure 5 The greater or lesser complexity represented therein can exist differently from... Figure 5 The components shown or excluding Figure 5 Components other than those shown, and the number, type, and configuration of such components can vary.

[0129] In a typical scenario, the transparency of a blockchain system requires that user actions be stored in a distributed ledger, and thus made available to anyone who can access that ledger. This can hinder the adoption of the technology for fear of revealing sensitive business information or failing to comply with existing regulations specifically designed to protect personal privacy.

[0130] Protecting user privacy focuses on two aspects: obscuring the content of transactions and concealing the identity of the user's origin. Obscuring content is achieved through verifiable encryption, while anonymity is achieved through a one-time key in the case of permissionless blockchains, and through anonymous certificates in the case of permissioned blockchains.

[0131] Traditional anonymous certificates assume a single issuer. While these solutions can hide the user's identity, they still reveal the issuer's identity. Authorizable certificate schemes support multiple issuers, as long as a root authority exists. A single root authority makes these solutions unsuitable for blockchain settings where issuers may not necessarily use the same root authority.

[0132] In some embodiments, this disclosure describes an anonymous certificate scheme that ensures user anonymity even in the absence of a single root authority.

[0133] Anonymous certificates allow users to prove claims about themselves without revealing their identity. Users first obtain a certificate (i.e., a signature) from an authorized publisher, containing the user's key and a set of attributes. To prove ownership of the attributes, the user uses zero-knowledge proofs to prove (i) knowledge of the certificate from the authorized publisher, (ii) knowledge of the corresponding key, and (iii) the certificate encoding the published attributes. Traditional techniques can hide the user's identity but still reveal the publisher's identity. A working environment is delegated certificates: these allow root authorities to delegate publishing capabilities by proving possession of a valid certificate, revealing only the root authority's identity and nothing else. However, in a blockchain setup, it is preferable to enable anonymity without relying on root permissions. In some embodiments, a user can be a node in the blockchain network or a user accessing the blockchain network through a node.

[0134] In some embodiments, secret signing schemes (such as Pointcheval-Sanders signatures) can be used to sign user certificates, allowing users to efficiently and privacy-preservingly prove claims about user certificates. These signatures are designed to accommodate zero-knowledge proofs of the signature and its corresponding message. Furthermore, to prevent users from disclosing the publisher's public key, multiple verification schemes are used to demonstrate that the user has obtained a valid signature relative to the submitted public key, and that the public key corresponds to one of the authorized publishers.

[0135] In some embodiments, Pointtcheval-Sanders or Groth signature schemes are used for zero-knowledge proofs. In some embodiments, Pointtcheval-Sanders or Groth signatures are randomizable signatures that (i) allow a signer to sign a message vector in a single attempt and (ii) enable a prover to prove zero-knowledge statements about the signature and its corresponding message.

[0136] In some embodiments, given a list of commitments (such as Pedersen commitments or Elgamal cryptography), multiple proofs allow a prover to demonstrate knowledge of the openness of one of these commitments in a privacy-preserving manner. In a commitment scheme such as Pedersen or Elgamal, the committer (or sender) decides (or is given) a secret message m obtained from some public message space having at least two elements. The same committer (or sender) then decides a random secret r and generates a commit c = C(m,r) from that m and r. The commitment is generated by making c public by applying some public method (commitment algorithm C) defined by the scheme, and subsequently revealing m and r. The verifier (or receiver) is given c, m, and r and can check whether C(m,r) = c.

[0137] In some embodiments, to join the blockchain as a certificate issuer, a party contacts the blockchain administrator with a public key of a signing scheme suitable for anonymous certificates (e.g., Pointcheval Sanders or Groth) and participates in an interactive zero-knowledge proof to demonstrate knowledge of the underlying key. If the administrator is convinced, they jointly submit the operation op = (join, pk, σ), where σ is a multi-signature of the administrator's own message (join, pk).

[0138] In some embodiments, the operation tx = (join, pk, σ) is verified by checking that there is no previous join operation with public key pk and that σ is a valid multi-signature relative to the administrator's public key.

[0139] In some embodiments, a user obtains a certificate of their attributes from a registered publisher. In some instances, the certificate consists of a signature. For example, the signature could be formed by the n attributes ā = (a1, ..., an) and the key sk (i.e., σ←sign(sk)). I The Groth signature σ on the vector ,sk,ā)) is composed of . I`sk` is the key of the registered publisher, and `sk` is the key of the user. In some embodiments, the user does not share their key with the publisher; instead, the publisher provides a signature (sk, a1, ..., a_n) without revealing the actual value of `sk`. Various signature schemes can be used (e.g., Pointcheval-Sanders, Groth), as long as the signature scheme allows the publisher to sign `sk` without learning its actual value and the user to sign transactions anonymously.

[0140] In some embodiments, a user action consists of a payload and a signature that do not disclose the user's identity. For example, to ensure that the action does not reveal any information about the user, it is sufficient to encrypt the payload using semantically secure encryption and to keep the signature anonymous. In some embodiments, the payload is data related to the action or data associated with the action.

[0141] To generate an anonymous signature for operating tx, the user proceeds as follows: computes a commitment to the public key of their publisher; proves using a one-to-one multiple proof that the commitment is a valid commitment to the public key of one of the authorized publishers; proves in zero-knowledge the knowledge of a valid signature under the submitted public key; and proves using a proof of knowledge of that value (such as a Schnorr proof). In some instances, the proof of knowledge is an interactive proof, where the prover proves knowledge of something to a certain extent, such that a verifier accepts it as proof that the prover indeed possesses that knowledge. In some instances, knowledge is proven by computation. For example, for a given input, the prover provides an output that the verifier accepts (i.e., previously received from a verified source) as the correct output. In some embodiments, the prover itself does not provide knowledge, but instead provides data that requires knowledge to generate.

[0142] In some embodiments, a proof (e.g., a Schnorr proof) serves as a knowledge signature by combining an operation, the zero-knowledge proofs generated to date, and a commitment to the public key. In some embodiments, coupling Groth signatures and one-to-many proofs allows for efficient implementation of multi-publisher anonymity certificates without a root authority. For example, a Groth signature can be replaced by any pairwise signature (e.g., a Pointtcheval-Sanders signature) that supports efficient zero-knowledge proofs of the statements involving the signature and the corresponding message.

[0143] Figure 6 A flowchart of an example method 600 for using multi-publisher anonymous certificates in a permissioned blockchain is shown.

[0144] Figure 6The process begins with step 602, which associates users with tuples. In some embodiments, a tuple is a finite, ordered list of elements. An n-tuple is a sequence of n elements, where n is a non-negative integer. For example, a tuple could be based on the formula user←(pk, a1, ..., a...). n ) are associated, where pk is the user's public key and a i It is the i-th attribute of the user.

[0145] Figure 6 Proceed to step 604, which associates the publisher with the PK public key. Each publisher may have a private / public key pair (PRK / PK), also known as a secret / public key pair. In the example, the first publisher has PRK1 / PK1, the second publisher has PRK2 / PK2, and the third publisher has PRK3 / PK3. In some embodiments, each publisher may use a formula PK. I ←X=Q x Associated with a public key, where X is calculated from the key sk = x.

[0146] In some embodiments, the association between a user and the Pk public key may include the user being registered by the publisher. In some embodiments, the publisher may use interactive zero-knowledge proofs to verify that the user knows the key sk and the underlying pk, and to check that the user holds attributes (a1, ..., a1). n ), and for (sk,a1,….,a n Issuing a certificate σ (i.e., signing). In some instances, attributes may include one or more identifiers of an entity or user. For example, attributes may be a user's citizenship, age, identification number, identification number of a node in the blockchain network accessible to the user, etc. In some embodiments, the attributes(s) are determined by the system and are not limited to the examples above.

[0147] For example, each certificate can be represented by a formula. To calculate, as in the Groth signature, where r is random and A is the following terms (a1,…,a…). n Bilinear accumulator:

[0148] Figure 6 Continuing to step 606: The user signs the operation using a certificate (e.g., a signature). In some embodiments, the user can compute a commitment to an operation on a public key. In some instances, the commitment scheme is a cryptographic tool. For example, a commitment can allow a user to hide a secret value while binding the user to that value, allowing the publisher to verify the secret value without revealing it. Thus, commitments can be used to hide the value of an operation while binding the owner to a secret attribute. In some embodiments, the user can generate a zero-knowledge proof that shows the user knows the tuple and the valid signature beneath it.

[0149] In some embodiments, a user may generate a plurality of proofs to demonstrate that the same public key was committed to one of the published commitments. For example, numerous proofs allow the prover to prove knowledge of the openness of one of these commitments in a privacy-preserving manner. That is, the prover does not reveal which commitment is known. In some embodiments, a user may sign a message (e.g., an action) by including the message in a challenge of a zero-knowledge proof (from step 604).

[0150] In some embodiments, the system may determine whether the certificate is presented during the correct period. This is illustrated in step 607. For example, some certificates may be valid only for a single period. In some embodiments, if the user's certificate is presented during the certificate's valid period, the signing is accepted in step 608. In some embodiments, if the user's certificate is not presented during the certificate's valid period, the signing is rejected in step 610.

[0151] Embodiments of this disclosure include a system comprising a memory and a processor communicating with the memory, the processor being configured to perform operations including anonymously signing and verifying user transactions. That is, without revealing the identity of the user generating the transaction or the identity of the issuer generating the user certificate.

[0152] Additional embodiments of this disclosure include a method comprising a signature scheme and a zero-knowledge proof, wherein the signature scheme allows a user to prove claims about themselves in a privacy-preserving manner, and the zero-knowledge proof enables the user to prove that an obfuscated public key (by encryption or submission) is a public key belonging to one of the authorized publishers. Examples of such signatures are Groth signatures or Pointcheval Sanders signatures, and examples of zero-knowledge proofs are proofs among many.

[0153] Further embodiments of this disclosure include a computer program product comprising a computer-readable storage medium having program instructions embodied therein, which are executable by a processor to cause the processor to perform a method comprising publisher registration, user registration, user signing of transactions, and the blockchain authenticating user transactions.

[0154] As discussed in more detail herein, it is anticipated that some or all of the operations of some embodiments of the methods described herein may be performed in an alternative order or may not be performed at all; furthermore, multiple operations may occur simultaneously or as part of a larger process.

[0155] This invention can be a system, method, and / or computer program product with any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0156] Computer-readable storage media can be tangible means for retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or protrusions in slots having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0157] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0158] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)) or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuitry in order to perform aspects of this invention.

[0159] The present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0160] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium storing the instructions includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0161] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, such that the instructions executed on the computer, other programmable apparatus, or other device perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0162] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the figures. For example, two blocks shown consecutively may actually be completed as a single step, executed simultaneously, substantially simultaneously, or with partial or complete temporal overlap, or the blocks may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0163] Various embodiments of this disclosure have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or technical improvements to technologies found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0164] While this disclosure has been described with reference to specific embodiments, variations and modifications thereof are expected to become apparent to those skilled in the art. Therefore, the following claims are intended to be construed as covering all such changes and modifications that fall within the true spirit and scope of this disclosure.

Claims

1. A blockchain certificate processing system, comprising: Memory; as well as A processor communicating with the memory, the processor being configured to perform processes including: A certificate for a user on the blockchain network is obtained from the publisher by a node on the blockchain network, the certificate being based on one or more attributes of the user. The publisher is selected from multiple authorized publishers used in the blockchain network, and The certificate includes a first signature and a key regarding one or more attributes, wherein the first signature is a Groth signature, the Groth signature being determined by the publisher's key, the user's key, and the one or more attributes, and the Groth signature scheme being used for zero-knowledge proofs of knowledge of valid certificates; The node generates an operation consisting of a payload and a second signature; The node calculates a commitment to the publisher's public key; The node uses one-to-many proofs to prove that the commitment is a valid commitment to the public key of one of the multiple authorized publishers; The node uses zero-knowledge proofs to prove the knowledge proof of the first signature and the certificate under the publisher's public key; and The proof is made by the node using proof of knowledge of the signed key and the values ​​of the one or more attributes.

2. The system according to claim 1, wherein, The payload is encrypted using semantic security encryption.

3. The system according to claim 1, wherein, The proof of knowledge of the value is a Schnorr proof.

4. The system according to claim 1, wherein, The user uses proof of knowledge of the value to demonstrate that the certificate is valid.

5. The system according to claim 1, wherein, The certificate is only valid during the specified period.

6. A blockchain certificate processing method, comprising: A certificate for a user on the blockchain network is obtained from the publisher by a node on the blockchain network, the certificate being based on one or more attributes of the user. The publisher is selected from multiple authorized publishers used in the blockchain network, and The certificate includes a first signature and a key regarding one or more attributes, wherein the first signature is a Groth signature, the Groth signature being determined by the publisher's key, the user's key, and the one or more attributes, and the Groth signature scheme being used for zero-knowledge proofs of knowledge of valid certificates; The node generates an operation consisting of a payload and a second signature; The node calculates a commitment to the publisher's public key; The node uses one-to-many proofs to prove that the commitment is a valid commitment to the public key of one of the multiple authorized publishers; The node uses zero-knowledge proofs to prove the knowledge proof of the first signature and the certificate under the publisher's public key; and The proof is made by the node using proof of knowledge of the signed key and the values ​​of the one or more attributes.

7. The method according to claim 6, wherein, The payload is encrypted using semantic security encryption.

8. The method according to claim 6, wherein, The proof of knowledge of the value is a Schnorr proof.

9. The method according to claim 6, wherein, The user uses proof of knowledge of the value to demonstrate that the certificate is valid.

10. The method according to claim 6, wherein, The certificate is only valid during the specified period.

11. A computer program product comprising program instructions executable by a processor to cause the processor to perform the method according to any one of claims 6 to 10.

Images