Systems, methods, and computer program products (multi-issuer anonymous credentials for permissioned blockchains)

Abstract

To provide a system anonymous credential scheme, system, method and program that ensures user anonymity even in the absence of a single root authority.SOLUTION: A user of a blockchain network may obtain credentials for the user from an issuer selected from one or more authorized issuers. The credentials are based on one or more attributes of the user, and include a signature on the one or more attributes and a secret key. Further, the user generates an operation composed of a payload and a second signature; computes a commitment to a public key of the issuer; uses a one-out-of-many proof to prove that the commitment is a valid commitment to a public key of one of the authorized issuers; uses a zero-knowledge proof to prove a proof of knowledge of the signature and the credentials under the public key of the issuer; and proves using a proof of knowledge of values of the signed secret key and attributes.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] This disclosure relates to the processing of operations on blockchain networks, and more specifically, to multi-issuer anonymous credentials for permissioned blockchains. [Background technology]

[0002] A blockchain is a list of cryptographically linked records called blocks. A blockchain network allows for the control of various types of operations by different parties. [Overview of the project] [Problems that the invention aims to solve]

[0003] This disclosure aims to provide an anonymous credentialing scheme that ensures user anonymity even when a single root authority does not exist. [Means for solving the problem]

[0004] Embodiments of this disclosure include systems, methods, and computer program products for multi-issuer anonymous credentials for permissioned blockchains in blockchain networks.

[0005] Embodiments of the present disclosure include a system including a memory and a processor that communicates with the memory. The processor is configured to perform a process which includes a user obtaining a user's credentials from an issuer based on one or more of the user's attributes, the issuer being selected from one or more authorized issuers, the credentials including a signature and a private key for the one or more attributes, the user generating an operation consisting of a payload and a second signature, the user calculating a commitment to the issuer's public key, the user proving, using a one-out-of-many proof, that the commitment is a valid commitment to the public key of one of the authorized issuers, the user proving a proof of knowledge regarding the signature and credentials based on the issuer's public key using a zero-knowledge proof, and the user performing a proof using a proof of knowledge regarding the signed private key and attribute values.

[0006] Further embodiments of the present disclosure include a method for a user to obtain credentials of the user from an issuer based on one or more of the user's attributes, the issuer being selected from one or more authorized issuers, the credentials comprising a signature and a private key for the one or more attributes, the user generating an operation comprising a payload and a second signature, the user calculating a commitment to the issuer's public key, the user proving by one-out-of-many proof that the commitment is a valid commitment to the public key of one of the authorized issuers, the user proving by zero-knowledge proof that the user has knowledge of the signature and credentials based on the issuer's public key, and the user performing proof by proof of knowledge of the signed private key and attribute values.

[0007] Further embodiments of the present disclosure include a computer program product comprising a computer-readable storage medium on which program instructions are implemented. The program instructions are executable by a processor and cause the processor to perform a method comprising: a user obtaining a user's credentials from an issuer based on one or more of the user's attributes, the issuer being selected from one or more authorized issuers, and the credentials comprising a signature and a private key for the one or more attributes; the user generating an operation comprising a payload and a second signature; the user calculating a commitment to the issuer's public key; the user proving, using a one-out-of-many proof, that the commitment is a valid commitment to the public key of one of the authorized issuers; the user proving, using a zero-knowledge proof, a proof of knowledge regarding the signature and credentials based on the issuer's public key; and the user performing a proof using a proof of knowledge regarding the signed private key and attribute values.

[0008] The above summary is not intended to describe each illustrated embodiment or all implementations in this disclosure. [Brief explanation of the drawing]

[0009] The drawings included in this disclosure are incorporated herein and constitute part of this specification. These drawings illustrate embodiments of this disclosure and, together with the specification, help to explain the principles of this disclosure. The drawings are illustrative of specific embodiments and do not limit this disclosure.

[0010] [Figure 1] Figure 1 is a network diagram of a system including a database, according to an exemplary embodiment. [Figure 2A] Figure 2A shows an exemplary blockchain architecture configuration according to an exemplary embodiment. [Figure 2B]A diagram showing the flow of blockchain transactions according to an exemplary embodiment. [Figure 3A] FIG. 3A is a diagram showing a permissioned network according to an exemplary embodiment. [Figure 3B] FIG. 3B is a diagram showing another permissioned network according to an exemplary embodiment. [Figure 3C] FIG. 3C is a diagram showing a permissionless network according to an exemplary embodiment. [Figure 4A] FIG. 4A is a diagram showing a process for adding a new block to a distributed ledger according to an exemplary embodiment. [Figure 4B] FIG. 4B is a diagram showing the content of a new data block according to an exemplary embodiment. [Figure 4C] FIG. 4C is a diagram showing a blockchain for digital content according to an exemplary embodiment. [Figure 4D] FIG. 4D is a diagram showing a block that can represent the structure of a block in a blockchain according to an exemplary embodiment. [Figure 5] FIG. 5 is a schematic block diagram of a computer system as an example that can be used when implementing one or more of the methods, tools, modules, and any related functions described herein according to an embodiment of the present disclosure. [Figure 6] FIG. 6 is a flowchart of an example of a method for multi-issuer anonymous credentials for a permissioned blockchain in a blockchain network according to an exemplary embodiment.

[0011] Each embodiment described herein is capable of various changes and alternative forms, and specific details of these embodiments are illustrated in the drawings and described in detail. However, the specific embodiments described herein should not be construed in a limiting sense. Rather, it is intended to encompass all modifications, equivalents, and alternative forms included within the spirit and scope of the present disclosure.

Mode for Carrying Out the Invention

[0012] Aspects of the present disclosure relate to the processing of operations on a blockchain network, and more specifically, to multi-issuer anonymous credentials for permissioned blockchains in a blockchain network.

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

[0014] Features, structures, or characteristics described throughout this specification may be combined or deleted in any suitable manner in one or more embodiments. For example, when terms such as "exemplary embodiments", "some embodiments", or other similar terms are used, it means that specific features, structures, or characteristics described in relation to the embodiments may be included in at least one embodiment throughout this specification. Thus, when terms such as "exemplary embodiments", "some embodiments", "other embodiments", or other similar terms appear, it does not necessarily refer to the same group of embodiments throughout this specification, and the features, structures, or characteristics described may be combined or deleted in any suitable manner in one or more embodiments. Further, in the drawings, any connection between elements can allow for one-way communication, two-way communication, or both, even if the illustrated connection is a one-way or two-way arrow. Also, any device shown in the drawings may be a different device. For example, if a mobile device for transmitting information is illustrated, a wired device may be used to transmit the information.

[0015] Furthermore, although the term “message” may be used in the description of each embodiment, this application is applicable to many types of networks and data. Additionally, while exemplary embodiments may depict certain types of connections, messages, and signaling, this application is not limited to any particular type of connection, message, and signaling.

[0016] In some embodiments, a method, system, or computer program product or combination thereof utilizes a decentralized database (such as a blockchain), which is a distributed storage system comprising multiple nodes communicating with each other. The decentralized database includes an append-only, immutable data structure similar to a distributed ledger, which can maintain records among parties who do not trust each other. These untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and a single peer cannot modify the database records unless an agreement is reached among the distributed peers. For example, peers may execute a consensus protocol to validate blockchain-stored transactions, group those stored transactions into blocks, and build a hash chain of multiple blocks. This process forms a ledger by ordering the stored transactions as needed for consistency.

[0017] In various embodiments, permissioned blockchains, permissionless blockchains, or both may be used. In public or permissionless blockchains, anyone can participate without possessing specific identification information (for example, while maintaining anonymity). Public blockchains can include native cryptocurrencies and can use consensus based on various protocols such as Proof of Work. On the other hand, permissioned blockchain databases enable secure interaction between groups of entities that have a common goal but do not fully trust each other, such as companies exchanging funds, goods, or information.

[0018] Furthermore, in some embodiments, the method, system, or computer program product or combination thereof may be designed for a decentralized storage scheme and may utilize a blockchain to run arbitrary programmable logic called “smart contracts” or “chaincode.” In some cases, there may be a dedicated chaincode for administrative functions and parameters, called system chaincode. The method, system, or computer program product or combination thereof may further utilize smart contracts, which are reliable decentralized applications that leverage the tamper-proof properties of the blockchain database and the underlying consensus between nodes (called endorsement or endorsement policy). Blockchain transactions associated with this application can be “endorsed” before being committed to the blockchain, and unendorsed transactions are ignored.

[0019] An endorsement policy allows the chaincode to specify a transaction endorser as a set of peer nodes required for endorsement. When a client submits a transaction to a peer specified in the endorsement policy, a transaction is executed to authenticate the transaction. After authentication, the transaction moves to the ordering phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0020] In some embodiments, a method, system, or computer program product or combination thereof may utilize nodes, which are communication entities in a blockchain system. A “node” can perform a logical function, meaning that multiple nodes of different types can run on the same physical server. Nodes are grouped within a trust domain and associated with logical entities that control these nodes in various ways. Nodes may include different types, such as client nodes or submit-client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes).

[0021] Another type of node is the peer node, which can receive transactions submitted by clients, commit those transactions, and maintain the state and copies of the blockchain transaction ledger. Peers can also act as endorsers, but this is not a requirement. An ordering service node, or orderer, is a node that performs communication services for all nodes. In some cases, an ordering service node implements a delivery guarantee, such as broadcasting to each peer node in the system when committing / confirming transactions and when changing the blockchain's world state. The world state is another name for the initial blockchain transaction, which usually contains control and configuration information.

[0022] In some embodiments, a method, system, or computer program product or combination thereof utilizes a ledger, which is a sequenced, tamper-proof record of all state transitions of the blockchain. State transitions may arise from chaincode calls (e.g., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party (e.g., peer nodes) may maintain a copy of the ledger. In some embodiments, participating parties are parties involved in an operation (e.g., an organization with nodes on the blockchain network). As a result of a transaction, a set of key-value pairs of assets may be committed to the ledger as one or more operands, such as create, update, or delete. The ledger includes a blockchain (also called a chain) used to store sequenced, immutable records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0023] In some embodiments, the methods, systems, or computer program products or combinations described herein may utilize a chain, which is a transaction log structured as hash-linked blocks. Each block contains a sequence of N transactions (where N is 1 or greater). The block header contains the hash of the block's transactions and the hash of the headers of preceding blocks. In this way, all transactions on the ledger are sequenced and cryptographically linked to one another. Thus, ledger data cannot be tampered with without breaking the hash links. The hash of the most recently added block in the blockchain represents all transactions on the chain that occurred before it, thereby ensuring that all peer nodes are consistent and trusted. The chain may be stored in a peer node file system (i.e., local, connected storage, cloud, etc.) that efficiently supports the nature of being dedicated to adding blockchain workloads.

[0024] The current state of an immutable ledger represents the most recent values ​​of all keys contained in the chain's transaction log. Because the current state represents the most recent key values ​​known to the channel, it is sometimes called the world state. Chaincode calls execute transactions against the data in the ledger's current state. To make these chaincode interactions more efficient, the most recent values ​​of keys may be stored in a state database. The state database may simply be an indexed view of the chain's transaction log and can therefore be replayed from the chain at any time. The state database may be automatically restored (or generated, if necessary) when a peer node is started and before any transactions are accepted.

[0025] What distinguishes blockchain from traditional databases is that it is not a centralized storage, but rather a decentralized, immutable, and secure storage, where nodes must share changes to records within the storage. Some characteristics unique to blockchain and useful for blockchain implementation include, but are not limited to, an immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility. These will be discussed further in this specification.

[0026] In particular, blockchain ledger data is immutable, which enables an efficient method of processing operations within the blockchain network. Furthermore, the use of encryption in the blockchain provides security and builds trust. Smart contracts manage the state of assets to complete their lifecycle. Therefore, dedicated nodes can ensure that blockchain operations with anonymity requirements can be securely submitted to the blockchain network. An exemplary blockchain is permission decentralized; therefore, each end-user may have their own ledger copy for access. Multiple organizations (and peers) may be onboarded to the blockchain network. The principal organization may act as endorsing peers to authenticate the execution results of smart contracts, read-sets, and write-sets. In other words, the inherent characteristics of blockchain enable the efficient implementation of private transaction processing within the blockchain network.

[0027] One of the advantages of the exemplary embodiment is that it can enhance the functionality of a computing system by implementing a method for processing private transactions on a blockchain network. Through the blockchain system described herein, a computing system (or a processor within a computing system) can perform the function of processing private transactions using a blockchain network by providing access to capabilities such as distributed ledger, peering, cryptographic technology, MSP, and event processing. Blockchain also enables the creation of business networks, allowing any user or organization to be onboarded and participate. Thus, blockchain is not merely a database. Blockchain forms a network for users and onboarded / offboarded organizations to collaborate and has the ability to execute service processes in the form of smart contracts.

[0028] On the other hand, conventional databases may not be useful for implementing the exemplary embodiment. This is because conventional databases do not involve all parties in the network, they do not generate reliable cooperation, and they do not provide a secure and efficient way to submit operations. Conventional databases do not provide tamper-proof storage or guaranteed valid transactions. Therefore, the exemplary embodiment provides a concrete solution to the problems in the field / domain of anonymous operation submission on a blockchain network.

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

[0030] Referring to Figure 1, the exemplary network 100 includes a node 102 connected to another blockchain (BC) node 105 representing a document owner organization. Node 102 may be connected to a blockchain 106 having a ledger 108 for storing data 110 shared among the nodes 105. In this example, only one node 102 is described in detail, but multiple such nodes may be connected to the blockchain 106. Note that node 102 may include additional components, and some of the components described herein may be removed, modified, or both, without deviating from the scope of node 102 disclosed herein. Node 102 may be a computing device or server computer, and may include a processor 104. The processor 104 may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another hardware device or a combination thereof. Note that a single processor 104 is illustrated, but node 102 may include multiple processors, multiple cores, etc., without deviating from the scope of the node 102 system. The distributed file storage 150 may be accessible to the processor node 102 and other BC nodes 105. Documents identified in the ledger 108 may be stored using the distributed file storage 150.

[0031] Node 102 may also include a non-temporary computer-readable medium 112 capable of storing machine-readable instructions executable by processor 104. Examples of machine-readable instructions are shown as reference numerals 114-118, which will be described in detail below. Examples of the non-temporary computer-readable medium 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-temporary computer-readable medium 112 may be RAM, electrically erasable programmable ROM (EEPROM), hard disk, optical disk, or other types of storage devices.

[0032] Processor 104 may execute a machine-readable instruction 114 to associate a user with a tuple. As described above, the blockchain ledger 108 may store data 110 shared among nodes 105. The blockchain network 106 may be configured to use one or more smart contracts to manage transactions of multiple participating nodes. Documents linked to annotation information may be stored in distributed file storage 150. Processor 104 may execute a machine-readable instruction 116 to associate an issuer with a PK public key. Processor 104 may execute a machine-readable instruction 118 to sign user operations.

[0033] Figure 2A shows a blockchain architecture configuration 200 according to an exemplary embodiment. Referring to Figure 2A, the blockchain architecture 200 may include certain blockchain elements (e.g., a group of blockchain nodes 202). The blockchain node 202 may include one or more peer nodes 204, 206, 208, and 210 (these four nodes are illustrative only). These nodes participate in several activities, such as adding blockchain transactions and the authentication process (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on an endorsement policy and may provide ordering services to all blockchain nodes 202 within the architecture 200. The blockchain nodes 204-210 may initiate blockchain authentication and request a write to the immutable ledger of the blockchain stored in the blockchain layer 216. A copy thereof may be stored in the underlying physical infrastructure 214. The blockchain configuration 200 may include one or more applications 224. Application 224 is created according to a customized configuration requested by the participant and is linked to an Application Programming Interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contract, etc.) that can maintain the participant's own state, control the participant's own assets, and receive external information. This can be installed on all blockchain nodes 204-210 by deploying it as a transaction and adding it to the distributed ledger.

[0034] The blockchain-based or platform 212 may include various layers of underlying physical computing infrastructure 214 that can be used to receive and store blockchain data, services (e.g., crypto-credit services, virtual execution environments, etc.), and new transactions, as well as to provide access to auditors seeking to access data entries. The blockchain layer 216 may expose an interface that provides access to the virtual execution environment necessary to process program code 220 and involve the physical infrastructure 214. The crypto-credit service 218 may be used to verify transactions, such as asset exchange transactions, and to keep information private.

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

[0036] Smart contracts may be created via high-level application and programming languages ​​and written to blocks in the blockchain. Smart contracts may contain executable code that is registered, stored, or replicated, or both, to the blockchain (e.g., a decentralized network of blockchain peers). A transaction is the execution of executable smart contract code when conditions related to the smart contract are met. The execution of a smart contract may trigger a trusted change to the state of the digital blockchain ledger. Changes to the blockchain ledger caused by the execution of a smart contract may be automatically replicated across the decentralized network of blockchain peers via one or more consensus protocols.

[0037] A smart contract may write data to the blockchain in the form of key-value pairs. Furthermore, the smart contract code can read values ​​stored on the blockchain and use them in the operation of the application. The smart contract code can write the output of various logical operations to the blockchain. The code may also be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain can be public, encrypted and kept private, or both. Temporary data used / generated by a smart contract is held in memory by the provided execution environment and then deleted when the data required for the blockchain is identified.

[0038] The chaincode may include smart contract code interpretation, along with additional functionality. As described herein, the chaincode may also be program code deployed on a computing network, which is executed and authenticated together by chain validators during the consensus process. The chaincode receives a hash and retrieves a hash 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 chaincode sends an authorization key to the requested service. The chaincode may write data related to cryptographic details to the blockchain.

[0039] Figure 2B shows an example of a blockchain transaction flow 250 between nodes of a blockchain (e.g., blockchain 106 shown in Figure 1) according to an exemplary embodiment. A general description of the transaction flow 250 will be given with reference to Figure 2B, followed by a more specific example. The transaction flow 250 may include a transaction proposal 291 sent by an application client node 260 to a first endosing peer node 281. The first endosing peer 281 may verify the client's signature, perform chaincode functions, and initiate the transaction. The output may include the chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values ​​written in the chaincode (written set). A proposal response 292, along with the endorsement signature if accepted, is sent back to the client 260. The client 260 puts the endorsement into a transaction payload 293 and broadcasts it to an ordering service (fourth peer) node 284. Next, the ordering service node 284 distributes the ordered transactions as blocks to all additional peers 281, 282, and 283 on the same channel. Before committing to the blockchain, each additional peer 281-283 may authenticate the transaction. For example, peers 281-283 may check an endorsement policy to ensure that the correct assignment of peers specified in the transaction proposal 291 has signed the result and authenticated the signature on the transaction payload 293. In some embodiments, one or more of the peers may be manager nodes.

[0040] A more detailed explanation of transaction flow 250 can be understood through a more concrete example. First, client node 260 initiates transaction proposal 291 by constructing a request and sending it to peer node 281, which is an endorser. Client 260 may include an application that utilizes a supported software development kit (SDK) to generate transaction proposals using available APIs. The proposal is a request to call a chaincode function so that data can be read from the ledger, or written to the ledger (i.e., a new key-value pair for an asset), or both. The SDK may act as a shim that packages the transaction proposal into a appropriately designed format (e.g., protocol buffer over remote procedure call (RPC)), and may receive the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0041] Accordingly, the Endosing Peer Node 281 may verify that (a) the transaction proposal is properly formed, (b) the transaction has not been submitted in the past (replay-attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) has the appropriate authority to perform the proposed operation on its channel. The Endosing Peer Node 281 may receive the input of the transaction proposal as an argument to a chaincode function that is called. The chaincode is then executed against the current state database to generate transaction results, including response values, read sets, and write sets. However, no updates are made to the ledger at this point. The set of transaction results, along with the Endosing Peer Node 281's signature, is returned to the client 260's SDK as a proposal response 292, which the SDK parses to prepare a payload for use by the application.

[0042] Accordingly, the application on client 260 inspects / verifies the signature of endosing peer 281 and compares it to the proposal response 292 to determine if the proposal response 292 is valid. If the chaincode simply queries the ledger, the application inspects the query response and typically does not submit the transaction to the ordering service node 284. If the client application intends to submit the transaction to the ordering service node 284 to update the ledger, the application determines before submitting whether the specified endorsement policy is met (i.e., whether all peer nodes required for the transaction have endorsed the transaction). Here, client 260 may be only one of several parties to the transaction. In this case, each client may include its own endorser node, and each endorser node must endorse the transaction. The architecture ensures that even if the application chooses not to inspect the response or otherwise forwards an unendorsed transaction, the endorsement policy is still enforced by the peers and maintained during the commit authentication phase.

[0043] After successful verification, client 260 consolidates the endorsements into transaction 293 and broadcasts the transaction proposals and responses in the transaction message to ordering node 284. Transaction 293 may include read / write sets, the endorsing peer's signature, and the channel ID. Ordering node 284 does not need to verify the entire contents of the transaction to perform its operation; instead, it may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions for each channel.

[0044] The block of transaction 293 is distributed from ordering node 284 to all other peer nodes 281-283 on the channel. Transaction 294 within the block is authenticated to ensure that all endorsement policies are met and that no changes have been made to the ledger state with respect to the variables in the read set since the read set was generated by the transaction execution. Transaction 294 within the block is tagged as valid or invalid. Furthermore, in operation 295, each peer node 281-283 adds the block to the channel chain and commits the write set to the current state database for each valid transaction. Events are issued to notify client applications that transaction (invocation) 293 has been added to the chain immutably and to notify them whether transaction 293 has been enabled or disabled.

[0045] Figure 3A shows an example permissioned blockchain network 300 according to an exemplary embodiment. The network 300 features a decentralized, decentralized peer-to-peer architecture. In this example, blockchain user 302 may initiate a transaction against the permissioned blockchain 304. In this example, a transaction may be a deployment, call, or query and may be issued in ways such as through a client-side application utilizing an SDK or directly through an API. The network 300 may provide access to a regulator 306, such as an auditor. The blockchain network operator 308 manages member permissions, such as registering the regulator 306 as an “auditor” and the blockchain user 302 as a “client”. The auditor may be restricted to ledger queries only, and the client may be granted permission to deploy, call, and query certain types of chaincode.

[0046] Blockchain developer 310 can write chaincode and client-side applications. Blockchain developer 310 can deploy chaincode directly to network 300 via an interface. To include credentials from traditional data source 312 in the chaincode, developer 310 may access the data using an out-of-band connection. In this example, blockchain user 302 connects to permissioned blockchain 304 via one of the peer nodes 314 (referring to any of nodes 314a-e). Before initiating any transaction, peer node 314 (e.g., node 314a) obtains registration and transaction certificates for user 302 from the certification authority 316 that manages the user's role and permissions. In some cases, blockchain users must possess these digital certificates in order to perform transactions on permissioned blockchain 304. On the other hand, users attempting to utilize the chaincode may be required to verify their credentials on traditional data source 312. To verify the authorization of user 302, the chaincode can use an out-of-band connection to this data via the conventional processing platform 318.

[0047] Figure 3B shows a permissioned blockchain network 320 as another example according to an exemplary embodiment. Network 320 features a decentralized, decentralized peer-to-peer architecture. In this example, blockchain user 322 may submit transactions to permissioned blockchain 324. In this example, transactions can be deployments, calls, or queries and may be issued in ways such as through a client-side application utilizing an SDK or directly through an API. The network may provide access to regulators 326, such as auditors. The blockchain network operator 328 manages member permissions, such as registering regulators 326 as “auditors” and blockchain users 322 as “clients”. Auditors may be restricted to ledger queries only, and clients may be granted permission to deploy, call, and query certain types of chaincode.

[0048] Blockchain developer 330 writes the chaincode and client-side applications. Blockchain developer 330 can deploy the chaincode directly to the network via an interface. To include credentials from a conventional data source 332 in the chaincode, developer 330 may access the data using an out-of-band connection. In this example, blockchain user 322 connects to the network via a peer node 334 (referring to one of nodes 334a-e). Peer node 334 (e.g., node 334a) obtains user registration and transaction certificates from the certification authority 336 before initiating any transaction. In some cases, blockchain users must possess these digital certificates in order to execute transactions on the permissioned blockchain 324. On the other hand, users attempting to utilize the chaincode may be required to verify their credentials on the conventional data source 332. To verify user authorization, the chaincode can use an out-of-band connection to this data via the conventional processing platform 338.

[0049] In some embodiments of this disclosure, the blockchain herein may be a permissionless blockchain. In contrast to permissioned blockchains (e.g., blockchains 304, 324) which require permission to participate, anyone can participate in a permissionless blockchain. For example, a user may initiate interaction with the network by creating a personal address and submitting a transaction, thereby adding an entry to the ledger, in order to participate in a permissionless blockchain. Furthermore, all parties may choose to run nodes on the system and employ a mining protocol to aid in transaction verification.

[0050] Figure 3C shows a network 350 in which transactions are processed by a permissionless blockchain 352 including a plurality of nodes 354, according to an exemplary embodiment. The sender 356 wishes to send a payment or other form of value (e.g., a certificate, medical record, contract, goods, service, or any other asset that can be encapsulated in a digital record) to the 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 user interface control and display of transaction parameters. Accordingly, the transaction is broadcast to the nodes 354 (referring to any of nodes 354a-e) throughout blockchain 352.

[0051] Depending on the network parameters of blockchain 352, a node uses a verification module 360 ​​to verify a transaction based on rules established by the creator of the permissionless blockchain 352 (which may be predefined or dynamically assigned). For example, this verification may include verifying the identification information of the parties involved. A transaction may be verified immediately or placed in a queue with other transactions. Then, node 354 determines whether the transaction is valid based on the set of network rules.

[0052] Within structure 362, valid transactions are formed into blocks and sealed using locks (hashes). This process may be performed by mining nodes within node 354. Mining nodes may utilize additional software, in particular, for mining and creating blocks in the permissionless blockchain 352. Each block can be identified by a hash (e.g., a 256-bit number) 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 preceding block in the chain, and a group of valid transactions. The reference to the hash of a preceding block is associated with the creation of a secure and independent chain for the block.

[0053] Before adding a block to blockchain 352, it must be authenticated. In the case of the permissionless blockchain 352, authentication may include proof-of-work (PoW), which is the solution to a puzzle derived from the block's header. Although not shown in the example in Figure 3C, another process for authenticating a block is proof-of-stake. Unlike proof-of-work, where an algorithm rewards miners who solve mathematical problems, proof-of-stake deterministically selects the creator of a new block based on assets (wealth) (also defined as "stake"). A similar proof is then performed by the selected node.

[0054] The mining module 364 allows nodes to attempt to solve a block by making incremental changes to a single variable until the solution satisfies a network-wide target. This generates Proof of Work (PoW), which guarantees the correct answer. In other words, possible solutions must prove that the computing resources consumed were used to solve the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins) for correctly mining a block.

[0055] Here, the PoW process, in parallel with the chaining of blocks, makes it extremely difficult to modify blockchain 352. This is because, in order for an attacker to accept a change to one block, they would have to modify all subsequent blocks. Furthermore, as new blocks are mined, modifying blocks becomes even more difficult, increasing the number of subsequent blocks. The distribution module 366 distributes successfully authenticated blocks through the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is the auditable ledger of the permissionless blockchain 352. In addition, the value in the transaction submitted by the sender 356 is deposited into the digital wallet of the receiving device 358 or transferred in other ways.

[0056] Figure 4A shows a blockchain system that performs a process 400 to add a new block to a distributed ledger 420, according to an exemplary embodiment. Figure 4B shows the contents of a new data block structure 430 for the blockchain, according to an exemplary embodiment. The new data block 430 may include document linking data.

[0057] Referring to Figure 4A, in process 400, a client (not shown) may submit a transaction to blockchain nodes 411, 412, or 413, or a combination thereof. The client may also be an instruction to perform an activity on blockchain 422, received from any source. For example, the client may be an application that acts on behalf of a requester, such as a device, person, or entity, to propose a transaction to blockchain 422. Multiple blockchain peers (e.g., blockchain nodes 411, 412, and 413) may maintain the state of the blockchain network and copies of the distributed ledger 420. Different types of blockchain nodes / peers may exist within the blockchain network. This may include, for example, endorsing peers that simulate and endorse transactions proposed by clients, and committing peers that verify endorsements, authenticate transactions, and commit transactions to the distributed ledger 420. In this example, each of blockchain nodes 411, 412, and 413 may act as an endorser node, a committer node, or both.

[0058] The distributed ledger 420 includes a blockchain that stores immutable sequenced records in blocks (e.g., data blocks 423, 424, 425, 426, 427, 428, 429, 430) and a state database 424 (current world state) that maintains the current state of blockchain 422. There may be one distributed ledger 420 for each channel, and each peer maintains its own copy of the distributed ledger 420 for each channel to which it is a member. Blockchain 422 is a transaction log constructed as hash-linked blocks, each containing a sequence of N transactions. Blocks may contain various components, such as those shown in Figure 4B. The linking of blocks (e.g., blocks 423-430) (indicated by arrows in Figure 4A) may be generated by adding the hash of the header of the preceding block to the block header of the current block. Thus, all transactions on blockchain 422 are sequenced and cryptographically linked to each other, preventing tampering with blockchain data without destroying the hash links. Furthermore, these links ensure that the most recent block in blockchain 422 (e.g., data block 430) represents all transactions preceding it. Blockchain 422 may be stored in a peer file system (local or connected storage) that supports dedicated blockchain workloads.

[0059] The current state of blockchain 422 and distributed ledger 420 may be stored in a state database 424. Here, the current state data represents the latest values ​​of all keys that have been included in the chain transaction log of blockchain 422 up to that point. Chaincode calls execute transactions against the current state in the state database 424. To make these chaincode interactions extremely efficient, the latest values ​​of all keys may be stored in the state database 424. The state database 424 may contain an indexed view of the transaction log of blockchain 422, so that it can be replayed from the chain at any time. The state database 424 may be automatically restored (or generated if necessary) when a peer is invoked and before a transaction is accepted.

[0060] Endosing nodes (411, 412, or 413, or a combination thereof) receive transactions from clients and endorse them based on simulation results. Endosing nodes hold smart contracts that simulate transaction proposals. When an endosing node endorses a transaction, it generates a transaction endorsement. A transaction endorsement is a signed response from the endosing node to the client application indicating endorsement of the simulated transaction. The method of endorsing a transaction is determined by the endorsement policy. The endorsement policy can be specified in the chaincode. An example of an endorsement policy is "the majority of endorsers must endorse the transaction." Endorsement policies may differ from channel to channel. Endorsed transactions are forwarded by the client application to the ordering service 410.

[0061] The ordering service 410 accepts endorsed transactions, orders them within a block, and sends the block to the committing peer. For example, the ordering service 410 may start a new block when a transaction threshold is reached, a timer times out, or another condition is met. In the example in Figure 4A, blockchain node 412 is a committing peer that has received a new data block 430 to be stored in blockchain 422. The first block 423 in blockchain 422 is sometimes referred to as the genesis block, which contains information about the blockchain, its members, and the data stored in the blockchain.

[0062] The ordering service 410 may consist of a cluster of orderers. The ordering service 410 does not process transactions or smart contracts, nor does it maintain a shared ledger. Rather, the ordering service 410 may accept endorsed transactions and specify the order in which these transactions are committed to the distributed ledger 420. The architecture of the blockchain network may be designed so that specific implementations of “ordering” (e.g., Solo, Kafka, Byzantine fault-tolerant, etc.) are pluggable components.

[0063] Transactions are written to the distributed ledger 420 in a consistent order. The order of transactions is established to ensure that updates to the state database 424 are valid when transactions are committed to the network. Unlike cryptocurrency blockchain systems (such as Bitcoin) where ordering occurs through solving a cryptographic puzzle, i.e., mining, in this example, the stakeholders of the distributed ledger 420 may choose the ordering mechanism that best suits the network.

[0064] When the ordering service 410 initializes a new data block 430, the new data block 430 may be broadcast to the committing peers (e.g., blockchain nodes 411, 412, and 413). In response, each committing peer verifies the transactions in the new data block 430 by checking and confirming that the read and write sets still match the current world state in the state database 424. Specifically, a committing peer can determine whether the read data that existed when the endorser simulated the transaction is identical to the current world state in the state database 424. When a committing peer verifies a transaction, the transaction is written to the blockchain 422 on the distributed ledger 420, and the state database 424 is updated with the write data from the read / write sets. If a transaction fails, i.e., if the committing peer determines that the read / write sets do not match the current world state in the state database 424, the ordered transactions in the block may still be included in that block, but the transaction may be marked as invalid and the state database 424 may not be updated.

[0065] Referring to Figure 4B, a new data block 430 (also called a data block) stored in the blockchain 422 of the distributed ledger 420 may contain multiple data segments, such as a block header 440, block data 450, and block metadata 460. Note that the various blocks and their contents shown, such as the new data block 430 and its contents in Figure 4B, are illustrative and not intended to limit the scope of the exemplary embodiments. The new data block 430 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 450. Furthermore, the new data block 430 may include a link to a preceding block (e.g., on the blockchain 422 in Figure 4A) within the block header 440. In particular, the block header 440 may include a hash of the header of the preceding block. The block header 440 may also include a unique block number (e.g., data blocks 423-430) or a hash of the block data 450 of the new data block 430. The block number of the new data block 430 is unique and may be assigned in various orders, such as an incremental / continuous order starting from 0.

[0066] Block data 450 may store transaction information for each transaction recorded in a new data block 430. For example, transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 420, transaction ID, epoch, payload visibility, chaincode path (transaction deployment), chaincode name, chaincode version, inputs (chaincode and functionality), client (author) identification information such as public key and certificate, client signature, endorser identification information, endorser signature, proposal hash, chaincode events, response status, namespace, read set (such as a list of keys and versions read by the transaction), write set (such as a list of keys and values), start key, end key, list of keys, Merkel tree query summary, etc. Transaction data may be stored for each of N transactions.

[0067] In some embodiments, the block data 450 may also store new data 462 that adds further information to the hash-linked chain of blocks in the blockchain 422. This new information includes one or more of the steps, features, processes, or actions or combinations thereof described or illustrated herein. Thus, the new data 462 can be stored in the immutable log of blocks on the distributed ledger 420. Some of the advantages of storing such new data 462 are reflected in the various embodiments disclosed and illustrated herein. Note that in Figure 4B, the new data 462 is shown within the block data 450, but the new data 462 may be located in the block header 440 or the block metadata 460. The new data 462 may include a document composite key used to link documents within an organization.

[0068] The block metadata 460 may store multiple metadata fields (for example, as a byte array). These metadata fields may include the signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions within the block, and the last surviving offset of the ordering service that ordered the blocks. The signature, last constituent block, and orderer metadata may be added by the ordering service 410. Meanwhile, the block committer (such as a blockchain node 412) may add valid / invalid information based on endorsement policies, read / write set verification, etc. The transaction filter may include a byte array equal in size to the number of transactions in the block data 450, and verification code that identifies whether a transaction was valid or invalid.

[0069] Figure 4C shows a blockchain 470 for digital content according to some embodiments described herein. The digital content may include one or more files and associated information. The files may include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutability and append-only nature of the blockchain acts as a safeguard to protect the integrity, validity, and authenticity of the digital content, making the use of the blockchain preferable in legal proceedings where admissibility rules apply, or in other situations where evidence is considered or where the presentation and use of digital information is of other interest. In this case, the digital content may be referred to as digital evidence.

[0070] Blockchains can be formed in various ways. In some embodiments, digital content may be contained within the blockchain itself and accessed from the blockchain. For example, each block in the blockchain may store the hash value of reference information (e.g., header, value, etc.) along with the associated digital content. The hash value and associated digital content may 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 preceding blocks. This can be illustrated as follows: Block 1 Block 2 ... Block N Hash value 1 Hash value 2 Hash value N Monthly Content 1 Monthly Content 2 Monthly Content N

[0071] In some embodiments, the digital content may not be included in the blockchain. For example, the blockchain may store encrypted hashes of the contents of each block without including the 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, a different storage area, or even a separate relational database. The digital content of each block may be referenced or accessed by retrieving or querying the hash value of the block in question and searching for that hash value stored in the storage area corresponding to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This can be shown as follows:

[0072] Blockchain storage area Hash value of block 1...Content · · · · · · Hash value of block N Hash value of block N... content

[0073] In an exemplary embodiment of Figure 4C, blockchain 470 consists of multiple blocks 4781, 4782, ... 478, which are cryptographically linked in an ordered sequence. N Includes (N is 1 or greater). Blocks 4781, 4782, ...478 N The encryption used to link them can be either multiple keyed hash functions or keyless hash functions. In some embodiments, blocks 4781, 4782, ... 478 N This is subject to a hash function that generates an n-bit alphanumeric output from an input based on the information within the block (where n is 256 or another number). Examples of such hash functions include, but are not limited to, SHA-type algorithms (SHA stands for Secure Hash Algorithm), Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, nonce-based algorithms, and non-collision-resistant pseudo-random functions (PRFs). In another embodiment, blocks 4781, 4782, ... 478 N These may be cryptographically linked by a function other than the hash function. As an example, the following explanation will refer to a hash function (e.g., SHA-2).

[0074] Blocks 4781, 4782, ..., 478 in the blockchain NEach of these includes a header, a file version, and a value. The header and value are different for each block as a result of hashing within the blockchain. In some embodiments, the value may be included in the header. As will be further detailed below, the file version may be the original file or a different version of the original file.

[0075] The first block in the blockchain, 4781, is called the genesis block and contains the header 4721, the original file 4741, and the initial value 4761. The hashing scheme used for the genesis block (and in fact for all subsequent blocks) may be different. For example, all the information in the first block 4781 may be hashed all at once, or parts of the information in the first block 4781 may be hashed individually, and then the hashing of the individually hashed parts may be performed.

[0076] The second header 4721 may contain one or more initial parameters, which may include, for example, a version number, timestamp, nonce, root information, difficulty, consensus protocol, duration, medium 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., by blockchain network management software) or manually generated by a blockchain participant. Other blocks in the blockchain 4782-478 N Unlike the headers within a block, header 4721 within genesis block 4781 does not reference a preceding block simply because the preceding block does not exist.

[0077] The original file 4741 in the genesis block can be, for example, data ingested by a device. The data may or may not be processed before being included in the blockchain. The original file 4741 is received from a device, medium source, or node via the system interface. The original file 4741 is associated with metadata. The metadata may be generated, for example, manually or automatically by a user, device, system processor, or a combination thereof. The metadata may be included in the first block 4781 in association with the original file 4741.

[0078] The value 4761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 4741. In some embodiments, one or more unique attributes may include the hash value of the original file 4741, the 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: 1) Hash value calculated for the original file using SHA-2 2) Outgoing device ID 3) Start timestamp of the original file 4) Initial storage location of the original file 5) Blockchain network member ID for the software to currently control the original file and associated metadata.

[0079] Other blocks in the blockchain: 4782-478 NIt also includes headers, files, and values. However, unlike the header 4721 of the first block, each of the headers 4722 to 4722N in the other blocks includes the hash value of the immediately preceding block. The hash value of the immediately preceding block may simply be the hash of the header of the previous block or the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, as indicated by the arrow 480, it is possible to perform a block-by-block trace back from the Nth block to the genesis block (and the associated original file), and establish an auditable and immutable chain-of-custody.

[0080] Also, each of the headers 4722 to 472 N in the other blocks may include other information. The other information is, for example, a version number, a timestamp, a nonce, root information, a difficulty level, a consensus protocol, and / or other parameters or information associated with the corresponding file and / or the blockchain in general.

[0081] The files 4722 to 472 N in the other blocks may be the same as the original file or a modified version of the original file in the genesis block, depending on, for example, the type of processing to be performed. The type of processing to be performed may vary from block to block. The processing may include any modification of the file in the previous block, such as editing the information or changing the content of the information in some other way, removing the information from the file, or adding information to the file.

[0082] In addition to or instead of the above, the process may include simply copying a file from a preceding block, changing the storage location of a file, analyzing a file from one or more preceding blocks, moving a file from one storage or memory location to another, or performing an action on a blockchain file or its associated metadata or both. Processes involving file analysis may include, for example, adding, including, or otherwise associating various analysis results, statistics, or other information associated with the file.

[0083] Other blocks in other blocks 4762-476 N Each value is unique and distinct, a result of the process performed. For example, a value in any one block corresponds to an updated version of a value in a preceding block. This update is reflected in the hash of the block to which the value was assigned. Therefore, the values ​​in a block indicate what process was performed in that block, and also allow the blockchain to be traced back to the original file. This tracing ensures the preservation of evidence for the file throughout the entire blockchain.

[0084] For example, consider a case where, in order to protect the identification information of a person indicated in the file, a portion of the file in the preceding block is edited, obscured, or pixelated. In this case, the block containing the edited file may include metadata associated with the edited file, such as how the edit was performed, who performed the edit, and the timestamp when the edit was made. This metadata may be hashed to form a value. Since the metadata of the block is different from the information hashed to form the value in the preceding block, these values ​​are different from each other and may be recovered upon decryption.

[0085] In some embodiments, the value of a preceding block may be updated to form the value of the current block if one or more of the following occur (for example, a new hash value may be calculated). In this exemplary embodiment, the new hash value may be calculated by hashing all or part of the information shown below. a) A new hash value calculated by SHA-2 when the file is processed in any way (for example, when the file is edited, copied, modified, accessed, or any other action is performed on the file) b) New storage location for the file c) New metadata identified and associated with the file d) Transfer of access to or control of a file from one blockchain participant to another blockchain participant.

[0086] Figure 4D shows a block 490 which can represent the structure of a block in a blockchain (e.g., 470) according to several embodiments. i ) is in Header 472 i , file 474 i , and value 476 i Includes.

[0087] Header 472 i is the preceding block (block) i-1 The hash value of the preceding block and additional reference information. The reference information may be any type of information described herein (e.g., header information including references, characteristics, parameters, etc.). All blocks (except the genesis block, of course) refer to the hash of the preceding block. The hash value of the preceding block may simply be the hash of the header in the preceding block, or it may be the hash of all or part of the information in the preceding block, including files and metadata.

[0088] File 474 iThis includes multiple data sets in sequence, such as Data 1, Data 2, ... Data N. The data are tagged with metadata 1, metadata 2, ... Metadata N, which describe the content, characteristics, or both associated with the data. For example, the metadata for each data set may include a timestamp of the data, the process of the data, keywords indicating a person or other content shown within the data, or other features, or a combination thereof, that may be useful in establishing the validity and content of the file as a whole, and in particular (as described in relation to the embodiments below, for example) in establishing the use of the file as digital evidence. In addition to metadata, each data set includes references to preceding data (REF1, REF2, ... REF) to prevent tampering, gaps within the file, and continuous referencing of the entire file. N It is also acceptable to tag it with ).

[0089] Once metadata is assigned to data (for example, via a smart contract), the metadata cannot be altered without changing the hash. Changes to the hash can be easily identified and invalidated. Therefore, the metadata generates a data log of information accessible for use by participants within the blockchain.

[0090] Value 476 i This is a hash value or other value calculated based on one of the types of information described above. For example, given a block (block i In the case of ), the value of the block may be updated to reflect the action performed on the block (e.g., a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other action or additional information). Although the values ​​within each block are shown to be separate from the metadata of the file and header data, in another embodiment, these values ​​may be based in part or in whole on this metadata.

[0091] At any point after the formation of blockchain 470, immutable evidence preservation of the file may be obtained by querying the blockchain for the transaction history of values ​​across the entire block. This query, or tracking procedure, may first decrypt the value of the last contained block (e.g., the last (Nth) block), and then continue decrypting the values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption may further include decrypting the header and file and associated metadata in each block.

[0092] Decryption is performed based on the type of encryption used for each block. This decryption may involve the use of a private key, a public key, or a public-private key pair. For example, if asymmetric encryption is used, a blockchain participant or a processor in the network may generate a public-private key pair using a predetermined algorithm. The public and private keys are related to each other by some mathematical relationship. The public key may be publicly distributed to function as an address (e.g., an IP address or home address) for receiving messages from other users. The private key is kept secret and used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can confirm that only the sender could have sent this message.

[0093] Generating a key pair is similar to creating an account on the blockchain, but in reality, there is no need to register anywhere. Also, all transactions performed on the blockchain are digitally signed by the sender using their private key. This signature ensures that only the account owner can track and process files on the blockchain (within the scope of permissions determined by the smart contract).

[0094] As will be described in more detail herein, some or all of the steps in some embodiments of the method herein may be performed in a different order or may not be performed at all. Furthermore, multiple steps may be performed simultaneously or as internal parts of a larger process.

[0095] Figure 5 is a schematic block diagram of a computer system 501 as an example of a computer system 501 that can be used to implement one or more of the methods, tools, modules, and any related functions described herein (for example, using one or more processor circuits or computer processors of a computer) according to embodiments of the present disclosure. 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. These can all be coupled together to communicate directly or indirectly for communication between components via a memory bus 503, an I / O bus 508, and an I / O bus interface unit 510.

[0096] The computer system 501 may include one or more general-purpose programmable central processing units (CPUs) 502A, 502B, 502C, and 502D (collectively referred to here as CPU 502). In some embodiments, the computer system 501 may include multiple processors, as is common in relatively large systems, but in other embodiments, the computer system 501 may instead be a system with a single CPU. Each CPU 502 can execute instructions stored in the memory subsystem 504. Each CPU 502 may also include one or more levels of onboard cache.

[0097] The system memory 504 may include computer system readable media as volatile memory, such as random access memory (RAM) 522 and cache memory 524. The computer system 501 may further include other removable / non-removable volatile / non-volatile computer system storage media. For illustrative purposes only, the storage system 526 may be provided for reading and writing to non-removable non-volatile magnetic media such as a “hard drive”. Although not shown in the figures, a magnetic disk drive for reading and writing to removable non-volatile magnetic disks (e.g., floppy disks) and an optical disk drive for reading and writing to removable non-volatile optical disks (such as CD-ROMs, DVD-ROMs, or other optical media) may be provided. Furthermore, the memory 504 may include flash memory (e.g., a flash memory stick drive or flash drive). The memory device may be connected to the memory bus 503 by one or more data medium interfaces. The memory 504 may include at least one program product having a set of program modules (e.g., at least one) configured to perform the functions of various embodiments.

[0098] One or more programs / utilities 528, each having at least one set of program modules 530, can be stored in memory 504. A program / utility 528 may include a hypervisor (also called a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of these, or any combination thereof, may include an implementation of a network environment. A program 528 or program module 530, or both, generally performs functions or methods of various embodiments.

[0099] In Figure 5, the memory bus 503 is illustrated as a single bus structure providing a direct communication path between the CPU 502, the memory subsystem 504, and the I / O bus interface 510. However, in some embodiments, the memory bus 503 may include multiple different buses or communication paths. These buses or communication paths can be arranged in any of various forms, such as point-to-point links in a hierarchical star or web configuration, multiple hierarchical buses, parallel and redundant paths, or any other appropriate type of configuration. Furthermore, although the I / O bus interface 510 and the I / O bus 508 are each illustrated as single units, the computer system 501 may, in some embodiments, include multiple I / O bus interface units 510, multiple I / O buses 508, or both. Additionally, while multiple I / O interface units are illustrated, they isolate the I / O bus 508 from various communication paths leading to various I / O devices. However, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

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

[0101] Figure 5 is intended to illustrate typical main components in a computer system 501 as an example. In some embodiments, individual components may be more complex or simpler than those shown in Figure 5. Furthermore, there may be components other than those shown in Figure 5, or additional components beyond those shown in Figure 5. The number, types, and configurations of such components may vary.

[0102] In general, the transparency of blockchain systems requires that user actions are stored on a distributed ledger and therefore available to anyone with access to that ledger. This can hinder the adoption of the technology due to concerns that sensitive business information may be revealed or that existing regulations specifically designed to protect individual privacy may not be complied with.

[0103] In protecting user privacy, two aspects are emphasized: obfuscation of transaction content and concealment of user origin identification information. Content obfuscation is achieved through verifiable encryption techniques. On the other hand, transaction anonymity is achieved through one-time keys in permissionless blockchains and through anonymous credentials in permissioned blockchains.

[0104] Traditional anonymous credentials assume a single issuer. While these solutions can hide the user's identity, the issuer's identity remains revealed. Delegable credential schemes support multiple issuers as long as a root authority exists. In the case of a single root authority, these solutions are unsuitable for blockchain environments where multiple issuers may not necessarily use the same root authority.

[0105] In some embodiments, this disclosure describes anonymous credential schemes that ensure user anonymity even when a single root authority does not exist.

[0106] Anonymous credentials allow a user to prove statements about themselves without disclosing their own identity. The user first obtains credentials (i.e., a signature) from an authorized issuer, including their private key and set of attributes. To prove ownership of the attributes, the user utilizes zero-knowledge proofs to demonstrate (i) knowledge of the credentials from the authorized issuer, (ii) knowledge of the corresponding private key, and (iii) that the credentials encode the disclosed attributes. Traditional techniques can conceal the user's identity but reveal the issuer's identity. One workaround is delegable credentials. These allow the root authority to delegate its issuing power in a way that, by proving ownership of valid credentials, only the root authority's identity is revealed, while nothing else is. However, in a blockchain environment, it is desirable to achieve anonymity without relying on the root authority. In some embodiments, the user may be a node in the blockchain network or a user accessing the blockchain network through a node.

[0107] In some embodiments, user credentials may be signed using a secret signature scheme, such as a Pointcheval-Sanders signature, to enable the user to prove a statement about user credentials in an efficient and privacy-protected manner. These signatures are designed to correspond to zero-knowledge proofs of the signature and its respective message. Furthermore, to prevent the user from exposing the issuer's public key, a one-out-of-many proof scheme is used to indicate that the user has obtained a valid signature on the committed public key and that the public key corresponds to one of the approved issuers.

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

[0109] In some embodiments, given a list of commitments (such as the Pedersen commitment or the ElGamal cryptography), a prover can prove knowledge of opening one of these commitments in a privacy-preserving manner through a one-out-of-many proof. In commitment schemes like Pedersen and ElGamal, the committer (or sender) determines (or is given) a secret message m taken from some public message space having at least two elements. The same committer (or sender) then determines a random secret r and generates a commitment c = C(m,r) from m and r. The commitment is generated by applying some disclosure method (commitment algorithm C) defined by the scheme, which then reveals c, m, and later m and r. A verifier (or receiver) is given c, m, and r and can verify whether C(m,r) = c is indeed true.

[0110] TIFF0007909360000001.tif45168

[0111] In some embodiments, the operation tx=(join,pk,σ) is authenticated by verifying that there has been no prior join operation using the public key pk, and that σ is a valid multi-signed signature for the administrator's public key.

[0112] TIFF0007909360000002.tif57168

[0113] In some embodiments, a user operation consists of a payload and a signature that does not disclose the user's identifying information. For example, to ensure that the operation does not leak any information about the user, it may suffice for the payload to be encrypted using semantically-secure encryption and the signature to be anonymous. In some embodiments, the payload is data for the operation or data related to the operation.

[0114] To generate an anonymous signature for an operation tx, the user proceeds as follows: (1) compute a commitment to the issuer's public key; (2) prove by a one-out-of-many proof that the commitment is a valid commitment to one of the acknowledged issuers' public keys; (3) prove, in zero knowledge, knowledge of a valid signature based on the committed public key; and (4) prove using a proof of knowledge of a value (such as a Schnorr proof). In some cases, a proof of knowledge is an interactive proof in which the prover demonstrates some knowledge to the extent that the verifier accepts it as proof that the prover possesses that knowledge. In some cases, knowledge is proven computationally. For example, for a given input, the prover provides an output that the verifier accepts as a correct output (i.e., one previously received from a verified source). In some embodiments, the prover does not provide the knowledge itself, but rather the data necessary for the generation of that knowledge.

[0115] To generate an anonymous signature for an operation tx, the user proceeds as follows: (1) compute a commitment to the issuer's public key; (2) prove by a one-out-of-many proof that the commitment is a valid commitment to one of the acknowledged issuers' public keys; (3) prove, in zero knowledge, knowledge of a valid signature based on the committed public key; and (4) prove using a proof of knowledge about a value (such as a Schnorr proof). In some cases, a proof of knowledge is an interactive proof in which the prover demonstrates some knowledge to the extent that the verifier accepts it as proof that the prover possesses that knowledge. In some cases, knowledge is proven computationally. For example, for a given input, the prover provides an output that the verifier accepts as a correct output (i.e., one previously received from a verified source). In some embodiments, the prover does not provide the knowledge itself, but rather the data necessary for the generation of that knowledge.

[0116] In some embodiments, a proof (e.g., a Schnorr proof) serves as a signature of knowledge by integrating the operation, previously generated zero-knowledge proofs, and commitments to the public key. In some embodiments, multi-issuer anonymous credentials can be efficiently implemented without root authority by combining a Groth signature with a one-out-of-many proof. For example, a Groth signature can be replaced with any pairing-based signature that supports efficient zero-knowledge proofs for statements containing the signature and the corresponding message (e.g., a Pointcheval-Sanders signature).

[0117] Figure 6 is a flowchart of Method 600 as an example of using multi-issuer anonymous credentials in a permissioned blockchain.

[0118] In Figure 6, first, in step 602, the user is associated with a tuple. In some embodiments, a tuple is a finitely ordered list of elements. An n-tuple is a sequence of n elements (where n is a non-negative integer). For example, a tuple is an expression user←(pk,a1,...,a n ) may be associated based on (where pk is the user's public key, a i (This is the i-th attribute of the user).

[0119] TIFF0007909360000003.tif39168

[0120] TIFF0007909360000004.tif57169

[0121] TIFF0007909360000005.tif27168

[0122] TIFF0007909360000006.tif57168

[0123] TIFF0007909360000007.tif44168

[0124] In some embodiments, the system may determine whether the credentials were presented in a correct epoch, as shown in step 607. For example, some credentials may only be valid during a single epoch. In some embodiments, if the user's credentials were presented during an epoch in which the credentials were valid, the signature is accepted in step 608. In some embodiments, if the user's credentials were not presented during an epoch in which the credentials were valid, the signature is rejected in step 610.

[0125] Embodiments of the present disclosure include a system comprising memory and a processor that communicates with the memory, the processor configured to perform operations including signing and verifying user transactions anonymously (i.e., without revealing the identity of the user generating the transaction or the identity of the issuer generating the user's credentials).

[0126] Further embodiments of this disclosure include a signature scheme that enables a user to prove a claim about themselves in a privacy-preserving manner, and a method that includes a zero-knowledge proof that enables a user to prove that an obfuscated public key (through encryption or commitment) is the public key of one of the approved issuers. Examples of such signatures are Groth signatures or Pointcheval Sanders signatures, and an example of a zero-knowledge proof is a one-out-of-many proof.

[0127] Further embodiments of the present disclosure include a computer program product comprising a computer-readable storage medium on which program instructions are implemented, wherein the program instructions are executable by a processor, and the processor is made executable by a processor to execute a method comprising issuer registration, user registration, user transaction signing, and a blockchain for authenticating user transactions.

[0128] As will be described in more detail herein, some or all of the steps in some embodiments of the method herein may be performed in a different order or may not be performed at all. Furthermore, multiple steps may be performed simultaneously or as internal parts of a larger process.

[0129] The present invention may be a system, method, or computer program product or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium storing computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0130] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. Examples of computer-readable storage media may include electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or appropriate combinations thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROM, DVD, memory stick, floppy disk, punch cards, or grooved raised structures, as well as mechanically encoded devices on which instructions are recorded, and appropriate combinations thereof. The computer-readable storage media used herein should not be interpreted 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 optical fiber cables), or electrical signals transmitted through wires.

[0131] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computer device / processor. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, LAN, WAN, or wireless network, or a combination thereof). The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers or edge servers, or a combination thereof. A network adapter card or network interface within each computer device / processor receives computer-readable program instructions from the network and transfers them for storage in a computer-readable storage medium in the respective computer device / processor.

[0132] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions can be executed as a standalone software package, either entirely on the user's computer or partially on the user's computer. Alternatively, they can be executed partially on the 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 LANs and WANs, or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), and programmable logic arrays (PLAs), can execute computer-readable program instructions by utilizing state information of computer-readable program instructions in order to customize the electronic circuits for the purpose of performing aspects of the present invention.

[0133] Embodiments of the present invention are described herein with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. Each block in a flowchart or block diagram, or both, and combinations of blocks in a flowchart or block diagram, or both, are executable by computer-readable program instructions.

[0134] The above computer-readable program instructions can be provided to a processor of a computer or other programmable data processing device to produce a machine. This creates a means for these instructions, executed via such computer or other programmable data processing device processor, to perform functions / operations identified in one or more blocks in a flowchart or block diagram, or both. The above computer-readable program instructions can further be stored in a computer-readable storage medium that can be instructed to function in a particular manner to a computer, programmable data processing device, or other device, or a combination thereof. Thus, the computer-readable storage medium on which the instructions are stored constitutes a product containing instructions for performing functions / operations identified in one or more blocks in a flowchart or block diagram, or both.

[0135] Alternatively, a computer execution process may be generated by loading computer-readable program instructions into a computer, another programmable device, or other device, and having a series of operational steps executed on that computer, other programmable device, or other device. This ensures that the instructions executed on the computer, other programmable device, or other device perform functions / operations identified in one or more blocks in a flowchart, block diagram, or both.

[0136] The flowcharts and block diagrams in the drawings of this disclosure illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, containing one or more executable instructions for performing a particular logical function. In some other implementations, the functions shown within a block may be executed in an order different from the order shown in each figure. For example, two consecutively shown blocks may actually be achieved as a single process, executed simultaneously or substantially simultaneously, executed in a partially or entirely overlapping manner in time, or, in some cases, executed in reverse order, depending on the functions involved. Each block in a block diagram or flowchart or both, and combinations of multiple blocks in a block diagram or flowchart or both, are executable by a dedicated hardware-based system that performs a particular function or operation, or executes a combination of dedicated hardware and computer instructions.

[0137] While various embodiments of this disclosure have been described as examples, they are not intended to be exhaustive or limit the scope to these embodiments. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope and spirit of each embodiment described. The terminology used herein has been selected to best describe the principles, practical applications, or technical improvements to the technologies found in the market of each embodiment, or to enable those skilled in the art to understand each embodiment disclosed herein.

[0138] While this disclosure has been described in terms of specific embodiments, it is conceivable that modifications and variations thereof would be obvious to those skilled in the art. Therefore, the following claims are intended to be construed as encompassing all such modifications and variations that fall within the true spirit and scope of this disclosure.

Claims

1. Memory and A system including a processor that communicates with the memory, The aforementioned processor, Obtaining user credentials from an issuer based on one or more attributes of the user, wherein the issuer is selected from one or more authorized issuers, and the credentials include a signature and private key for the one or more attributes. The operation involves generating a payload and a second signature, Calculating the issuer’s commitment to the public key, Using a one-out-of-many proof, prove that the commitment is a valid commitment to one of the public keys of the approved issuers, Using zero-knowledge proofs, prove knowledge of the signature and credentials based on the issuer's public key, Proof is made using proof of knowledge regarding the signed private key and attribute values, It is configured to run a process that includes system.

2. The aforementioned signature is a Groth signature. The system according to claim 1.

3. The payload is encrypted using highly confidential encryption. The system according to claim 1.

4. The proof of the aforementioned knowledge is a Schnorr proof. The system according to claim 1.

5. The Groth signature scheme facilitates zero-knowledge proofs of knowledge about valid credentials. The system according to claim 1.

6. The user shall prove that the credentials are valid using proof of knowledge. The system according to claim 1.

7. The aforementioned credentials are valid only for a certain epoch. The system according to claim 1.

8. A node on a blockchain network obtains user credentials from an issuer based on one or more attributes of the user of the blockchain network, wherein the issuer is selected from one or more approved issuers for the blockchain network, and the credentials include a signature and a private key for the one or more attributes. The node generates an operation consisting of a payload and a second signature, The node calculates the issuer's commitment to the public key, The node uses a one-out-of-many proof to prove that the commitment is a valid commitment to one of the public keys of the approved issuers, The node uses zero-knowledge proofs to prove knowledge of the signature and credentials based on the issuer's public key, The node performs proof using proof of knowledge regarding the signed private key and attribute values, Methods that include...

9. The aforementioned signature is a Groth signature. The method according to claim 8.

10. The payload is encrypted using highly confidential encryption. The method according to claim 8.

11. The proof of the aforementioned knowledge is a Schnorr proof. The method according to claim 8.

12. The Groth signature scheme facilitates zero-knowledge proofs of knowledge about valid credentials. The method according to claim 8.

13. The node uses proof of knowledge to prove that the credentials are valid. The method according to claim 8.

14. The aforementioned credentials are valid only for a certain epoch. The method according to claim 8.

15. A computer program that includes program instructions, wherein the program instructions are executable by a processor, and the processor, Obtaining user credentials from an issuer based on one or more attributes of the user, wherein the issuer is selected from one or more authorized issuers, and the credentials include a signature and private key for the one or more attributes. The operation involves generating a payload and a second signature, Calculating the issuer’s commitment to the public key, Using a one-out-of-many proof, prove that the commitment is a valid commitment to one of the public keys of the approved issuers, Using zero-knowledge proofs, prove knowledge of the signature and credentials based on the issuer's public key, Proof is made using proof of knowledge regarding the signed private key and attribute values, Perform a method that includes Computer program.

16. The aforementioned signature is a Groth signature. The computer program according to claim 15.

17. The payload is encrypted using highly confidential encryption. The computer program according to claim 15.

18. The proof of the aforementioned knowledge is a Schnorr proof. The computer program according to claim 15.

19. The Groth signature scheme facilitates zero-knowledge proofs of knowledge about valid credentials. The computer program according to claim 15.

20. The user shall prove that the credentials are valid using proof of knowledge. The computer program according to claim 15.

Images