Conflict resolution in blockchain storage structures

Abstract

Example operations may include one or more of: receiving a content request to add content to a blockchain storage structure implemented on a blockchain database; based on when the content request was received, temporarily storing the requested content in a queue implemented via the blockchain database; receiving a request invoked by a chaincode to refresh the queue; and in response to the refresh request, removing the content from the queue and adding the content to the blockchain storage structure.

Description

Technical Field

[0001] The present application relates generally to processes for anonymously tracking behavior, and more specifically, to a blockchain that manages a storage structure for tracking data without knowing or revealing the identities of the participants whose data is being tracked. Background Art

[0002] A centralized database stores and maintains data in a single database at one location (e.g., a database server). This location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. The information stored in a centralized database can typically be accessed from multiple different points. Multiple users or client workstations can work on a centralized database simultaneously, for example, based on a client / server configuration. A centralized database is easy to manage, maintain, and control due to its single location (particularly for security purposes). In a centralized database, data redundancy is minimized because a single storage location for all data also means that a given data set has only one master record.

[0003] However, centralized databases are subject to significant disadvantages. For example, centralized databases have a single point of failure. In particular, if there is no fault tolerance consideration and a hardware failure (e.g., hardware, firmware, and / or software failure) occurs, all data within the database is lost and the work of all users is interrupted. In addition, centralized databases are highly dependent on network connectivity. Therefore, the slower the connection, the longer the amount of time required for each database access. Another disadvantage is the emergence of bottlenecks when the centralized database experiences high traffic due to a single location. In addition, centralized databases provide limited access to data because the database maintains only one copy of the data. Therefore, multiple devices cannot access the same piece of data at the same time without causing major problems or the risk of overwriting the stored data. In addition, because the database storage system has little to no data redundancy, accidentally lost data is difficult to retrieve from the backup storage device except through manual operation.

[0004] To address the deficiencies in security, immutability, and central authority, some organizations have begun turning to blockchain to store data. For example, supply chain data (e.g., between different untrusted participants in the supply chain, etc.) can be recorded in a trusted manner by using blockchain. However, information typically stored on a blockchain is visible / available to all participants of the blockchain. Therefore, a solution that can track information anonymously is needed. Summary of the invention

[0005] An example embodiment provides a system comprising one or more of a network interface and a processor, wherein the network interface is configured to receive a content request to add content to a blockchain storage structure implemented on a blockchain database, wherein the processor is configured to perform one or more of the following operations: based on when the content request is received, temporarily store the requested content in a queue implemented via the blockchain database; receive a request to flush the queue invoked by a chaincode; and in response to the flush request, remove the content from the queue and add the content to the blockchain storage structure.

[0006] Another example embodiment provides a method comprising one or more of: receiving a content request to add content to a blockchain storage structure implemented on a blockchain database; based on when the content request was received, temporarily storing the requested content in a queue implemented via the blockchain database; receiving a request to refresh the queue invoked by a chaincode; and in response to the refresh request, removing the content from the queue and adding the content to the blockchain storage structure.

[0007] Another example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of: receiving a content request to add content to a blockchain storage structure implemented on a blockchain database; based on when the content request was received, temporarily storing the requested content in a queue implemented via the blockchain database; receiving a request to refresh the queue invoked by a chaincode; and in response to the refresh request, removing the content from the queue and adding the content to the blockchain storage structure.

[0008] Another example embodiment provides a system comprising one or more of a storage device and a processor, wherein the storage device is configured as a tree structure, the tree structure comprising anonymous behavior data of multiple blockchain participants stored in multiple nodes in a hierarchical structure, wherein the processor is configured to perform one or more of the following operations: receiving a request to add new anonymous behavior data to the tree structure, the request comprising a zero-knowledge proof generated by a blockchain participant; based on the zero-knowledge proof, identifying an active leaf on the tree structure that stores previously recorded anonymous behavior data of the blockchain participant associated with the request; and generating a new active leaf for the blockchain participant based on the new anonymous behavior data and the previously recorded anonymous behavior, wherein the storage device is also configured to store the new active leaf as a leaf node on the tree structure.

[0009] Another example embodiment provides a method, the method comprising one or more of the following: storing, via a blockchain storage device, a tree structure including anonymous behavior data of multiple blockchain participants stored in multiple nodes in a hierarchical structure; receiving a request to add new anonymous behavior data to the tree structure, the request including a zero-knowledge proof generated by a blockchain participant; based on the zero-knowledge proof, identifying an active leaf on the tree structure that stores previously recorded anonymous behavior data of the blockchain participant associated with the request; generating a new active leaf for the blockchain participant based on the new anonymous behavior data and the previously recorded anonymous behavior; and storing the new active leaf as a leaf node on the tree structure in the blockchain storage device.

[0010] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following: storing, via a blockchain storage device, a tree structure including anonymous behavior data of multiple blockchain participants stored in multiple nodes in a hierarchical structure; receiving a request to add new anonymous behavior data to the tree structure, the request including a zero-knowledge proof generated by a blockchain participant; based on the zero-knowledge proof, identifying an active leaf on the tree structure that stores previously recorded anonymous behavior data of the blockchain participant associated with the request; generating a new active leaf for the blockchain participant based on the new anonymous behavior data and the previously recorded anonymous behavior; and storing the new active leaf as a leaf node on the tree structure in the blockchain storage device. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a diagram illustrating a blockchain network including storage of behavioral data of supply chain participants according to an example embodiment.

[0012] Figure 2A is a diagram illustrating an example blockchain architecture configuration according to an example embodiment.

[0013] Figure 2B is a diagram illustrating a blockchain transaction flow according to an example embodiment.

[0014] Figure 3A is a diagram illustrating a permission network according to an example embodiment.

[0015] Figure 3B is a diagram illustrating another permission network according to an example embodiment.

[0016] Figure 4A is a diagram illustrating a process of adding a new active leaf node to a blockchain structure according to an example embodiment.

[0017] Figure 4Bis a diagram illustrating a process of invoking a new active leaf node by a blockchain participant according to an example embodiment.

[0018] Figure 4C is a diagram illustrating queues implemented via a blockchain ledger to prevent storage conflicts according to an example embodiment.

[0019] Figure 5A is a flow chart illustrating a method of updating anonymity behavior on a blockchain structure according to an example embodiment.

[0020] Figure 5B is a flow chart illustrating a method of managing a queue via a blockchain ledger according to an example embodiment.

[0021] Fig. 6A is a diagram illustrating an example system configured to perform one or more operations described herein according to an example embodiment.

[0022] Figure 6B is a diagram illustrating another example system configured to perform one or more operations described herein according to an example embodiment.

[0023] Figure 6C is a diagram illustrating another example system configured to utilize smart contracts according to an example embodiment.

[0024] Fig.6D is a diagram illustrating yet another example system configured to utilize blockchain according to example embodiments.

[0025] Fig. 7A is a diagram illustrating a process of adding a new block to a distributed ledger according to an example embodiment.

[0026] Figure 7B is a diagram illustrating the content of a new data block according to an example embodiment.

[0027] Figure 7C is a diagram illustrating a blockchain of digital content according to an example embodiment.

[0028] Fig.7D is a diagram illustrating a block structure that may represent a block in a blockchain according to example embodiments.

[0029] Figure 8 is a diagram illustrating an example system that supports one or more example embodiments. DETAILED DESCRIPTION

[0030] It is readily understood that, as generally described and illustrated in the drawings herein, the components of the present invention may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of at least one of the methods, devices, non-transitory computer-readable media, and systems, as illustrated in the drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0031] In one or more embodiments, the present features, structures, or characteristics described throughout this specification may be combined or removed in any suitable manner. For example, throughout the specification, the use of the phrases "example embodiments," "some embodiments," or other similar language refers to the fact that a particular feature, structure, or characteristic described in conjunction with an embodiment may be included in at least one embodiment. Thus, throughout the specification, the appearance of the phrases "example embodiments," "in some embodiments," "in other embodiments," or other similar language does not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments.

[0032] In addition, although the term "message" may have been used in the description of the embodiment, the application can be applied to many types of networks and data. In addition, although specific types of connections, messages and signaling notifications can be described in the exemplary embodiments, the application is not limited to specific types of connections, messages and signaling notifications.

[0033] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide systems and methods for privacy-preserving abnormal behavior detection and tracking.

[0034] In one embodiment, the system utilizes a decentralized database (such as a blockchain), which is a distributed storage system including multiple nodes that communicate with each other. The decentralized database includes an attached-only immutable data structure similar to a distributed ledger, which is capable of maintaining records between mutually untrusted parties. Untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching a consensus between the distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain on the blocks. For consistency, the process forms a ledger by sorting storage transactions (as needed). In various embodiments, permissioned blockchains and / or permissionless blockchains can be used. In a public blockchain or permissionless blockchain, anyone can participate without a specific identity. Public blockchains typically involve local cryptocurrencies and use consensus based on various protocols (such as Proof of Work (PoW). On the other hand, permissioned blockchain databases provide secure interactions between groups of entities that share common goals but do not fully trust each other, such as businesses that exchange funds, goods, information, etc.

[0035] The system may utilize a blockchain that operates arbitrary programmable logic that fits into a decentralized storage scheme and is referred to as a "smart contract" or "chaincode." In some cases, there may be specialized chaincodes for management functions and parameters, which are referred to as system chaincodes. The application may further utilize smart contracts, which are trusted distributed applications that utilize the tamper-proof properties of the blockchain database and the underlying agreement between nodes, which is referred to as endorsement or endorsement policy. Blockchain transactions associated with this application can be "endorsed" before being submitted to the blockchain, and unendorsed transactions will be ignored. The endorsement policy allows the chaincode to specify the endorsers of the transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to verify the transaction. After verification, the transaction enters the sorting phase, in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks.

[0036] The system can utilize nodes as communication entities of the blockchain system. In the sense that multiple nodes of different types can run on the same physical server, a "node" can perform a logical function. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as clients or client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive transactions submitted by clients, submit transactions, and maintain the state and copy of the ledger of blockchain transactions. Peers can also play the role of endorsers, although this is not required. Ordering service nodes or orderers are nodes that run communication services for all nodes, and they implement delivery guarantees, such as broadcasting to each of the peer nodes in the system when submitting transactions and modifying the world state of the blockchain, which is another name for the initial blockchain transaction, which typically includes control and setup information.

[0037] The system can utilize a ledger that is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions can result from chaincode invocations (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant (such as a peer node) can maintain a copy of the ledger. A transaction can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) that is used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0038] The system can utilize a chain that is a transaction log structured as hash-linked blocks, and each block contains a series of N transactions, where N is equal to or greater than 1. The block header includes a hash of the transactions of the block, as well as a hash of the block header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction that appeared before it on the chain, which makes it possible to ensure that all peer nodes are in a consensus and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage device, cloud, etc.), effectively supporting the attached-only nature of blockchain workloads.

[0039] The current state of the immutable ledger represents the latest values ​​of all keys contained in the chain's transaction log. Because the current state represents the latest key values ​​known to the channel, it is sometimes called the world state. Chaincode invocations execute transactions against the current state data of the ledger. In order for these chaincode interactions to be efficient, the latest values ​​of the keys may be stored in the state database. The state database may be only an indexed view of the chain's transaction log, so it may be regenerated from the chain at any time. The state database may be automatically restored (or generated if needed) at peer startup and before transactions are accepted.

[0040] Example embodiments provide a system that can anonymously track the behavior of entities (e.g., supply chain participants, patients, game users, etc.) on a blockchain (and detect abnormal behavior) based on storing and updating some relevant statistics related to the entity's input (e.g., ratings of suppliers, medical records, game information, etc.), while protecting the privacy of the entity. According to various aspects, the system can maintain Merkle trees for some entities (e.g., suppliers) participating in the blockchain. Each Merkle tree may include an "active leaf" for each user (e.g., buyer) of the entity (e.g., supplier).

[0041] The buyer's "active leaf" can store a standard cryptographic hash (e.g., sha256) value of the pre-image, which includes a concatenation of a secret (known only to the buyer) (which is a random bit string), the sum of its current ratings (encoded as a bit string), and the number of its current ratings (encoded as a bit string). Therefore, an accumulation of the buyer's anonymous activities / behaviors can be stored in the active leaf node based on the total number of reviews plus the sum of all ratings provided by the buyer. Therefore, the buyer's rating history can be maintained anonymously without disclosing the buyer's identity.

[0042] Some benefits of the instant solution described and depicted herein include the ability to accumulate behavioral information about participants of a blockchain while still protecting the privacy of the participants. Although the examples described herein involve the anonymous behavior of buyers providing reviews / ratings to sellers in a supply chain network, the example embodiments are not limited to this. As another example, anonymous bids on a blockchain can be tracked. In this example, bidders are anonymous and are allowed to update their bids up to a fixed number of times. An auctioneer can use the example embodiments to detect abnormal bidding sequences of bidders, where the bidder's active leaf stores a cryptographic hash of the number of bid updates made, and a zero-knowledge proof verifies that the number is below a threshold.

[0043] As another example, an embodiment can be used for anonymous patient health monitoring. In this example, the blockchain can maintain a system to detect anomalies in a sequence of patient health indicator data points. For each patient, some indicators of the patient's health can be measured regularly and sent to the system as anonymous input. In this example, data points outside a predetermined area (e.g., such as data points described by the mean and / or variance of the sequence, etc.) can be considered abnormal. This can be detected using the system described in the example embodiment, where the patient's active leaf stores the number of data points, the current sum, and the encrypted hash of the current sum of squares, which is sufficient to calculate and update the mean and variance. Zero-knowledge proofs can be used to ensure that new data points are within the area described by the current mean and variance.

[0044] Figure 1 A blockchain network 100 including storage of behavioral data of supply chain participants according to an example embodiment is shown. Figure 1 , blockchain network 100 includes blockchain 120, which stores supply chain data between suppliers 111 and 112 and buyers 131, 132, 133, and 134. For example, blockchain 120 can store work orders, invoices, signed documents, digital goods, etc. Figure 1 Not shown in the figure, blockchain 120 can be implemented by multiple peer nodes, which can include commit nodes, endorser nodes, sorter nodes, etc. In some cases, a node can fulfill multiple node roles.

[0045] According to various embodiments, the nodes implementing blockchain 120 may each maintain smart contracts (which are executable chain codes), ledgers distributed / replicated between nodes, and immutable blocks stored on the ledgers. The ledgers may be key-value stores (KVS) accessible to smart contracts, which are executed to programmatically maintain and update data on the ledgers. Suppliers 111 and 112 and buyers 131-134 may access blockchain 120 via one or more trusted nodes.

[0046] According to various embodiments, the behavior data of supply chain participants can be stored anonymously via blockchain 120. For example, in this example, the smart contract implemented by the node of blockchain 120 can store and manage a Merkle tree (or other data structure) as a key value in the ledger, which can be used to anonymously store the behavior information of buyers 131-134. The execution of the smart contract is a transaction that includes read and write sets of key values ​​accessed during execution. These sets are included in the transaction block of the block chain attached to blockchain 120. The ledger and block chain are updated identically on each peer in the blockchain network according to the consensus protocol.

[0047] In the examples herein, actions such as ratings and reviews of suppliers 111-112 performed by buyers 131-134 may be recorded on a Merkle tree in the key-value store of blockchain 120. In some embodiments, a node may maintain a separate Merkle tree for each supplier 111 and 112, and each buyer 131, 132, 133, and 134 may have a dedicated active leaf in the corresponding Merkle tree. To implement anonymous accumulation of data, such as ratings / reviews over time, a node may rely on non-interactive zero-knowledge proofs, where (i) the buyer (client) generates the proof, and (ii) the smart contract (chaincode) verifies the proof against the data of the ledger. Zero-knowledge proofs allow buyers to submit new review information and nullify old review information while protecting the buyer's identity. In other words, new active leaves are added (and used) anonymously. Smart contracts may include API enhancements to efficiently implement shared anonymous data updates.

[0048] When buyers 131-134 and suppliers 111-112 participate in supply chain activities, buyers can continuously upload comments about suppliers 111-112 in an anonymous manner to ensure that suppliers 111-112 are performing well and also to ensure that buyers 131-134 do not continuously give negative comments.

[0049] Figure 2A A blockchain architecture configuration 200 is shown according to an example embodiment. Figure 2A , the blockchain architecture 200 may include certain blockchain elements, such as a group of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are depicted by way of example only). These nodes participate in many activities, such as blockchain transaction addition and verification processes (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on endorsement policies and may provide sorting services for all blockchain nodes in the architecture 200. The blockchain node may initiate blockchain authentication and attempt to write to the blockchain immutable ledger stored in the blockchain layer 216, a copy of which may also be stored on the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224 that are linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chain code, smart contracts, etc.), which may be created based on the customized configuration sought by the participants and may maintain their own state, control their own assets, and receive external information. This may be deployed as a transaction and installed on all blockchain nodes 204-210 via attachment to a distributed ledger.

[0050] The blockchain base or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and an underlying physical computer infrastructure that may be used to receive and store new transactions and 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 and engage the physical infrastructure 214. Cryptographic trust services 218 may be used to verify transactions (such as asset exchange transactions) and keep information private.

[0051] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and the services provided by it. Code 220 can control blockchain assets. For example, code 220 can store and transmit data and can be executed by nodes 204-210 in the form of smart contracts and chain codes associated with conditions or other code elements affected by its execution. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications of changes, updates, etc. The smart contract itself can be used to identify rules associated with authentication and access requirements and the use of the ledger. For example, anonymous data 226 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The result 228 can include new active leaf data of the Merkle tree stored on the blockchain in association with the anonymous data 226. The physical infrastructure 214 can be used to retrieve any data or information described herein.

[0052] Smart contracts can be created via high-level applications and programming languages, and then written into blocks of a blockchain. A smart contract can include executable code that is registered, stored, and / or replicated to a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which can be executed in response to conditions associated with the smart contract being satisfied. The execution of a smart contract can trigger (multiple) trust modifications to the state of a digital blockchain ledger. (Multiple) modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.

[0053] Smart contracts can write data to the blockchain in the form of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by the smart contract is saved in memory by the supplied execution environment and then deleted once the data required for the blockchain is identified.

[0054] Chaincode may include a code interpretation of a smart contract, with additional functionality. As described herein, chaincode may be a program code deployed on a computing network where it is executed and verified by a chain verifier during a consensus process. The chaincode receives the hash and retrieves from the blockchain a hash associated with a data template created by using a previously stored feature extractor. If the hash of the hashed identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requesting service. The chaincode may write blockchain data associated with cryptographic details.

[0055] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. Figure 2B , a transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute the chaincode function to initiate the transaction. The output may include a chaincode result, a set of key / value versions read in the chaincode (read set), and the set of key / values ​​written in the chaincode (write set). If approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to the sorting service node 284. The sorting service node 284 then delivers the sorted transaction as a block to all peers 281-283 on the channel. Each peer 281-283 may verify the transaction before submitting it to the blockchain. For example, a peer may check the endorsement policy to ensure that the correct assignment of the specified peer has signed the result and authenticated the signature against the transaction payload 293.

[0056] Reference again Figure 2B, the client node 260 initiates a transaction 291 by constructing a request and sending it to the peer node 281 as an endorser. The client 260 may include an application utilizing a supported software development kit (SDK) that utilizes the available APIs to generate a transaction proposal. The proposal is a request to call a chaincode function so that data can be read and / or written to the ledger (i.e., write a new key-value pair for an asset). The SDK can be used as a small function library (shim) to package the transaction proposal into a format for the appropriate architecture (e.g., protocol buffers via remote procedure call (RPC)) and obtain the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0057] In response, the endorsing peer 281 can verify that (a) the transaction proposal is well-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 the example) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 can input the transaction proposal as an argument to the chaincode function invoked. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read set, and a write set. However, no updates are made to the ledger at this time. In 292, the set of values ​​is transmitted back to the SDK of the client 260 along with the signature of the endorsing peer 281 as a proposal response 292, which parses the payload for the application to consume.

[0058] In response, the client 260 application reviews / verifies the endorsed peer signatures and compares the proposed responses to determine if the proposed responses are identical. If the chaincode only queries the ledger, the application will review the query response and will typically not submit the transaction to the sorting node service 284. If the client application intends to submit the transaction to the sorting node service 284 to update the ledger, the application determines whether the specified endorsement policy has been met before submission (i.e., whether all peer nodes required for the transaction have endorsed the transaction). Here, the client may include only one of the multiple parties to the transaction. In this case, each client may have its own endorsement node, and each endorsement node is required to endorse the transaction. The architecture is such that even if the application chooses not to review the response or otherwise forward unendorsed transactions, the endorsement policy will still be enforced by the peers and supported during the submission verification phase.

[0059] After successful review, in step 293, client 260 assembles the endorsement into a transaction and broadcasts the transaction proposal and response in a transaction message to ordering node 284. The transaction may contain read / write sets, endorsing peer signatures, and channel IDs. Ordering node 284 does not need to review the entire contents of a transaction in order to perform its operations, but rather ordering node 284 can simply receive transactions from all channels in the network, sort them chronologically by channel, and create a block of transactions for each channel.

[0060] The transaction block is delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are verified to ensure that any endorsement policies are met and that the ledger state of the read set variables has not changed since the transaction execution generated the read set. The transactions in the block are marked as valid or invalid. In addition, in step 295, each peer node 281-283 attaches the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events are emitted to notify the client application that the transaction (call) has been immutably attached to the chain, and whether the transaction is verified or unverified.

[0061] Figure 3A An example of a permissioned blockchain network 300 is shown, featuring a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 302 can initiate a transaction to a permissioned blockchain 304. In this example, a transaction can be a deployment, call, or query, and can be issued through a client-side application utilizing an SDK, directly through an API, etc. The network can provide access to regulators 306 (such as auditors). The blockchain network operator 308 manages member permissions, such as registering regulators 306 as "auditors" and blockchain users 302 as "clients." Auditors are limited to querying the ledger, while clients can be authorized to deploy, call, and query certain types of chaincodes.

[0062] Blockchain developers 310 can write chaincodes and client-side applications. Blockchain developers 310 can deploy chaincodes directly to the network through an interface. In order to include credentials from traditional data sources 312 in the chaincode, developers 310 can use out-of-band connections to access the data. In this example, blockchain users 302 connect to the permissioned blockchain 304 through peer nodes 314. Before conducting any transactions, peer nodes 314 retrieve the user's registration and transaction certificates from the certificate authority 316 that manages user roles and permissions. In some cases, blockchain users must have these digital certificates in order to conduct transactions on the permissioned blockchain 304. At the same time, users trying to utilize chaincodes may need to verify their credentials on traditional data sources 312. To confirm the user's authorization, the chaincode can use an out-of-band connection to the data through a traditional processing platform 318.

[0063] Figure 3B Another example of a permissioned blockchain network 320 is shown, featuring a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 322 can submit transactions to a permissioned blockchain 324. In this example, a transaction can be a deployment, call, or query, and can be issued through a client-side application utilizing an SDK, directly through an API, etc. The network can 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 are limited to querying the ledger, while clients can be authorized to deploy, call, and query certain types of chaincodes.

[0064] Blockchain developers 330 write chaincodes and client-side applications. Blockchain developers 330 can deploy chaincodes directly to the network through an interface. To include credentials from traditional data sources 332 in chaincodes, developers 330 can use out-of-band connections to access data. In this example, blockchain users 322 connect to the network through peer nodes 334. Before conducting any transactions, peer nodes 334 retrieve the user's registration and transaction certificates from certificate authorities 336. In some cases, blockchain users must have these digital certificates in order to conduct transactions on the permissioned blockchain 324. At the same time, users attempting to utilize chaincodes may need to verify their credentials on traditional data sources 332. To confirm the user's authorization, the chaincode can use an out-of-band connection to the data through a traditional processing platform 338.

[0065] According to an example embodiment, Figure 4A shows a message to be sent to the storage device 401 ( Figure 4B Blockchain structure 410 (shown) Figure 4A ) adding a new active leaf node process 400, and Figure 4B The process 430 of calling a new active leaf node 411B by a blockchain participant 431 is shown according to an example embodiment. Figure 4A In the example of , the blockchain structure is a Merkle tree 410, which includes a first state 410A (also referred to as the current state) and a second state 410B (also referred to as the updated state), in which a new active leaf node 411B is added and the current active leaf node 411A is anonymously revoked. Figure 4A In the example of , three active leaf nodes 411, 412, and 413 are shown, which correspond to three anonymous buyers of the supplier.

[0066] As described herein, a Merkle tree is a binary tree that may include a depth of d, where the tree is a complete binary tree of depth d. In this case, each leaf node stores data that can be represented as a bit string of a fixed length. In this order, the value at each internal node in the tree can be a cryptographic hash (e.g., sha256, etc.) of the concatenation of the values ​​of the left and right child nodes. In the examples herein, an empty Merkle tree can be initialized with all of its leaf nodes set to some default value, such as an all-zero bit string. In order from left to right, any new active leaves are added to replace the next available unused (i.e., with a default value) leaf node, and the values ​​of the nodes on the path from the added leaf node to the root node are updated. For example, for Figure 1 For each buyer in the example, the first active leaf is added and set to a standard cryptographic hash of the initial preimage with a secret (known only to the corresponding buyer) random bit string, a zero rating sum (encoded as a bit string), and a number of ratings of zero (encoded as a bit string). The Merkle tree can be stored on the blockchain as part of the ledger corresponding to the smart contract. In an empty Merkle tree, all nodes at the same depth have the same value. Therefore, for memory efficiency, only the values ​​of those nodes that are different from the corresponding nodes in the empty Merkle tree are explicitly stored.

[0067] As described in the examples herein, each activity leaf may store or otherwise include participants (such as Figure 1 In the example in this article, the smart contract maintains a Merkle tree for each supplier, which contains an "active leaf" for each buyer of that supplier. The attributes maintained in the buyer's "active leaf" may include a standard cryptographic hash (sha256) value of the following preimage: (i) a secret (known only to the buyer) random bit string, (ii) the sum of its current ratings (encoded as a bit string), and (iii) the concatenation of its current number of ratings (encoded as a bit string). Figure 4B In the example of , the current active leaf node 411A includes these corresponding attributes.

[0068] When the buyer wants to add a new rating of a supplier, the buyer can call the smart contract of blockchain 401. Figure 4B In the example of Figure 1 One of the buyers 131-134 shown) can request an update to the supplier on the buyer's active leaf. Figure 4BIn the example of , anonymous system 431 is associated with leaf node 411A and uploads request 432 including new active leaf node 411B. When the buyer (anonymous system 431) calls the smart contract to provide a new rating (request 432), the buyer provides the new active leaf 411B, which contains the standard cryptographic hash value of the following new pre-image: (i) a new secret random bit string (known only to the buyer), (ii) the updated rating sum, and (iii) the updated number of ratings. In addition, the buyer provides a nullifier of the existing active leaf 411A, which is a different, unlinkable cryptographic hash of the pre-image of the existing active leaf 411A (e.g., sha256 with a non-standard initialization vector). In addition, the buyer provides a zero-knowledge proof (ZKP) and the rating he wishes to submit.

[0069] According to various embodiments, the ZKP can show that the provided annuler is indeed an annuler of an existing active leaf in the Merkle tree, the current average rating given by the ratio of the current rating sum and the current number of ratings is at least a given threshold (this check detects anomalous behavior), and the new active leaf value is a standard cryptographic hash of the new preimage given in 411B, such that the updated rating sum is the rating sum of the existing active leaves in (ii) plus the provided rating, and the updated rating number is the rating number of the existing active leaves in (iii) plus 1.

[0070] The smart contract can verify that the newly provided revoker is not used, thereby ensuring that the buyer must only revoke the current active leaf 411A, and further verify the zero-knowledge proof provided above. If the check and verification pass, the list of ratings is updated with the provided rating, the new active leaf 411B is added to the Merkle tree, and the provided revoker is stored and marked as used. Note that in the above process, since the verification is in a zero-knowledge state, it is not revealed which current active leaf is revoked. The only guarantee is that some active leaves in the Merkle tree are revoked. Since the supplier has multiple buyers, each of which has active leaves, the identity of the specific buyer who provided the rating is not revealed.

[0071] In the second state 410B, the existing active leaf 411A is deprecated and remains in its place, and a new active leaf 411B associated with the same anonymous user is added to replace the first default / empty leaf from left to right. In this case, the default leaf means that the leaf node currently has some default values ​​and has not been used to store any information. Therefore, in the second state 410B, the leaf L1 411A remains in place and is marked as deprecated. The new active leaf L1 411B is added to replace the default value.

[0072] The algorithm used for zero-knowledge proof creation can be an open source implementation of ZKSnarks. Using the included gadgets, the predicate of the zero-knowledge proof can be implemented in libsnark to generate the proving and verification executables and the corresponding proving and verification keys. The buyer has the proving executable and the keys. As described above, the buyer computes the new active leaf and the annuler of the current active leaf. To generate the proof, the buyer calls the smart contract to query the value of the sibling nodes on the path from the current active leaf to the root.

[0073] The buyer can then privately generate the desired zero-knowledge proof using the libsnark proof executable and a secret key (outside the blockchain / smart contract) with the following input values: an authentication path including the values ​​on the sibling nodes on the path from the current active leaf to the root, the components of the preimage of the current active leaf (e.g., a secret random bit string, the current rating sum, and the current number of ratings), the new rating to be provided, and a new secret random string of the preimage of the new active leaf. The output is a zero-knowledge proof that can be verified by a smart contract on the blockchain 401.

[0074] Likewise, when it is time to verify the ZKP, the smart contract receives the new rating, the annuler of the current active leaf, the new active leaf, and the zero-knowledge proof from the buyer. The smart contract can read the value of the Merkle tree root and run the libsnark verification executable along with the verification key with the following input values: the new rating, the annuler of the current active leaf and the new active leaf, the Merkle tree root value, and the zero-knowledge proof.

[0075] The output of the above executable is a true / false value indicating whether the zero-knowledge proof was verified to prove that the provided revoker is indeed the revoker of the existing active leaf in the Merkle tree, the current average rating given by the ratio of the sum of the current ratings to the current number of ratings is at least a given threshold (this check detects anomalous behavior), and the new active leaf value is a standard cryptographic hash of the new preimage. The smart contract can be executed by an endorsing peer of the blockchain 401 that has the libsnark verification executable and the verification key accessible to the smart contract. In these examples, the smart contract is unaware that the current active leaf is being revoked. Since the revoker is not linkable to the active leaf and the verification is in a zero-knowledge state, the smart contract does not obtain any information about the current active leaf being revoked, thereby protecting the privacy of the buyer.

[0076] For example, a smart contract can be executed on an endorsing peer to verify a zero-knowledge proof provided by a buyer who calls a smart contract to anonymously add a rating for a supplier. The endorsing peer has the libsnark verification executable as well as the verification key accessible to the smart contract. The zero-knowledge proof verification is done by the smart contract on behalf of the supplier, who guarantees that the buyer's anomalous (behavioral) rating will be detected while protecting the buyer's privacy.

[0077] If successful, the expected operations including Merkle tree updates, storage ratings, and revokers are performed by the smart contract, which involves updating multiple key values ​​in the ledger of blockchain 401. Corresponding endorsed transactions including read and write sets are created by peers and sent according to the blockchain protocol to be recorded in blocks on blockchain 401. The key values ​​in the ledgers of all blockchain peers are updated in the same way.

[0078] Figure 4C A process 440 for managing a queue 450 according to an example embodiment is shown, which is implemented via a blockchain ledger and can be used to prevent storage conflicts. In the Merkle tree (or other shared or joint storage structure) described herein, a single call transaction uses the current active leaf and adds a new active leaf for the buyer. This can be done anonymously using zero-knowledge proofs. However, when multiple buyers (or other users) add new leaves at the same index, problems may arise when the use / add-leaf transaction is called at the same time. Such simultaneous calls can cause read / write conflicts (reference Hyperledger Fabric v1), so at most one added leaf is possible in each block. When the add leaf operation is non-anonymous, the conflict can be resolved by collecting the new leaves and adding them to an aggregate transaction. However, this is not possible in anonymous data storage because privacy is protected. Although described for Merkle trees, storage conflicts naturally occur in other zero-knowledge proof paradigms when using any type of shared data structure that can be anonymously modified by multiple parties.

[0079] To address this situation, blockchain peer node 460 (smart contract) can implement queue 450 within the distributed blockchain ledger, where new active leaf nodes (e.g., nodes 411B, 413B, 417C, and 415B) can be temporarily stored and later added to Merkle tree 410 in response to a refresh operation. Once the ZK proof is verified, the revoker is stored, and the rating is added, no additional information is required to add a new active leaf other than its value. Peer node 460 can store the set of new active leaves in queue 450, and then can add them together separately in a single transaction.

[0080] The smart contract application programming interface (API) framework may support a special BufferKey operation that simulates a first-in-first-out (FIFO) queue 450 of string values. Various operations may be used to manipulate the queue 450 (or buffer), including a DefineBufferKey operation that defines a specific key string as a buffer key with an optional maximum buffer size (e.g., DefineBufferKey("Supplier1~MT1~LeafBuf", 50)). The API framework may also support a BufPush operation that attaches a value to the end of the queue 450. During the endorsement phase, a corresponding (BufferKey, value) write set pair is generated. During block submission on the ledger, the values ​​of the BufferKey will be attached in the order of transactions in the block, for example, BufPush("Supplier1~MT1~LeafBuf", "1234"). The API framework may also support a BufFlush operation that returns an iterator to the values ​​in the BufferKey and flushes the queue during the submission phase. A transaction cannot have both a BufPush and a BufFlush for the same key at the same time. The endorsement includes the BufferKey in a special flush set (eg BufFlush("Supplier1~MT1~LeafBuf")).

[0081] Therefore, when multiple buyers attempt to add leaf operations on the Merkle tree at the same time, the queue 450 and the supported push and flush operations can prevent potential collision problems. This is because a common data structure, such as a Merkle tree, can be modified anonymously by multiple parties (such as buyers). Operations such as BufferKey and DefineBufferKey, BufPush and BufFlush operations in the smart contract API can be used to simulate a FIFO queue implemented locally in the blockchain ledger.

[0082] Using this enhancement, in an add leaf operation, the smart contract can use a BufPush operation to push the new active leaf onto a predefined BufferKey. Periodically, a designated party calls a BufFlush operation that iterates through the active leaves to be added (e.g., a chaincode of a designated peer, etc.) and adds them to the Merkle tree 410. Thus, example embodiments may implement a smart contract method for storing anonymous data via a Merkle tree based on zero-knowledge proofs for privacy-preserving abnormal behavior detection on a blockchain, as well as enhancements that incorporate BufferKey into an API and a block chain ledger system for efficient implementation of a Merkle tree / zero-knowledge proof method to minimize conflicts. Note that the above conflict issues arise in a blockchain network where transactions are executed, ordered, and then committed, such as Hyperledger Fabric v1, and the enhancements described above are applicable to such a blockchain network.

[0083] Figure 5A A method 510 for updating anonymity behavior on a blockchain structure according to an example embodiment is shown. Figure 5A In 511, the method may include storing a tree structure via a blockchain storage device. For example, the tree structure may include a Merkle tree, a binary tree, a non-binary tree, etc. The anonymous behavior data may include anonymous behaviors of multiple blockchain participants stored in multiple nodes in a hierarchical structure. In some embodiments, the tree structure may include multiple active leaf nodes that store anonymous behavior data of multiple blockchain participants respectively, which do not reveal the identities of the multiple blockchain participants. The anonymous behavior may involve the identity of the content provider. For example, the anonymous behavior may not identify a public key, network address, name, device ID, email address, username, etc. associated with the behavior.

[0084] In 512, the method may include receiving a request to add new anonymous behavior data to the tree structure. For example, the request may include a zero-knowledge proof generated by a blockchain participant, a revoker of a previous active leaf of the blockchain participant, a new active leaf (anonymous data), etc. For example, the zero-knowledge proof may include a random string known only to the blockchain participant, which may be used to verify various properties of the new active leaf node and its contents without revealing the identity of the blockchain participant. In some embodiments, the method may also include verifying the validity of the new anonymous behavior based on the root value of the tree structure, the zero-knowledge proof, and the anonymity properties of the new anonymous behavior.

[0085] In 513, the method may include identifying an active leaf on a tree structure storing previously recorded anonymous behavior data of a blockchain participant associated with the request based on a zero-knowledge proof. In 514, the method may include generating a new active leaf for the blockchain participant based on the new anonymous behavior data and the previously recorded anonymous behavior. Here, the new active leaf may be used to replace the current active leaf. In some embodiments, the method may also include, in response to receiving the new anonymous behavior data, revoking the identified active leaf on the tree structure with the new active leaf. In 515, the method may include storing the new active leaf as a leaf node on the tree structure in the blockchain storage device.

[0086] In some embodiments, the tree structure may include a Merkle tree stored via a key-value store of a blockchain storage device, and the Merkle tree may include a corresponding active leaf node for each participant of the blockchain. In some embodiments, the anonymous behavioral data may include anonymous comments submitted by blockchain participants. In some embodiments, the method may also include endorsing the new active leaf based on a zero-knowledge proof before storing the new active leaf on the tree structure.

[0087] Figure 5B A method 520 of managing queues via a blockchain ledger according to an example embodiment is shown. Here, queues can be used to prevent conflicts when multiple participants attempt to add content to a blockchain storage structure at the same time. Figure 5B In 521, the method may include receiving a content request to add content to a blockchain storage structure implemented on a blockchain database. For example, the content request may include a request to store a new node (e.g., an active leaf node, etc.) on a shared blockchain storage structure (such as a binary tree, a Merkle tree, etc.). In some embodiments, the content request may include anonymous content that does not reveal the identity of the content creator. Here, the blockchain storage structure may store anonymous content of multiple content creators.

[0088] In 522, the method may include, based on when a request for content is received, temporarily storing the content of the request in a queue implemented via a blockchain database. The queue may be implemented via a distributed ledger and controlled by a smart contract executed on a peer node with the blockchain. In some embodiments, the queue may include a first-in-first-out (FIFO) queue implemented via a smart contract (chain code) executing the blockchain database. In 523, the method may include receiving a request to refresh the queue invoked by the chain code. In response to the refresh request, in 524, the method may include removing the content from the queue and adding the content to the blockchain storage structure. For example, the removal may include pushing the content from the end of the FIFO queue to a new node on a tree structure stored on the blockchain database.

[0089] In some embodiments, receiving may include receiving multiple content requests to add multiple pieces of content to a blockchain storage structure, and temporarily storing may include temporarily storing each piece of content as a corresponding entry in a queue. Here, the content may include a new leaf node to be added to the Merkle tree as an active leaf node. The nodes in the queue may be sorted based on when they were received to ensure the correct time order. In some embodiments, removing may include adding the content to an active leaf node on a Merkle tree storage structure implemented via a blockchain database. In some embodiments, the Merkle tree storage structure may be maintained within a key value store (KVS) of the blockchain database.

[0090] Fig. 6A An example system 600 is shown that includes a physical infrastructure 610 configured to perform various operations according to example embodiments. Fig. 6A , the physical infrastructure 610 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which may perform any operation steps 608 (in the module 612) included in any of the example embodiments. The steps / operations 608 may include one or more of the described or depicted embodiments, and may represent write or output information written to or read from one or more smart contracts 630 and / or blockchain 620. The physical infrastructure 610, the modules 612, and the modules 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, the modules 612 and the modules 614 may be the same module.

[0091] Figure 6B Another example system 640 is shown that is configured to perform various operations according to an example embodiment. Figure 6B , system 640 includes module 612 and module 614. Module 614 includes blockchain 620 and smart contract 630 (which may reside on blockchain 620), which smart contract can perform any operation step 608 (in module 612) included in any of the example embodiments. Step / operation 608 may include one or more of the described or depicted embodiments, and may represent write or output information written to or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, module 612 and module 614 may be the same module.

[0092] Figure 6CAn example system configured to utilize a smart contract configuration between contracting parties and an intermediary server configured to enforce the terms of the smart contract on a blockchain according to an example embodiment are shown. Figure 6C , configuration 650 may represent a communication session, an asset transfer session, or a process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the smart contract execution may be managed by a server 654. The contents of the smart contract 630 may need to be digitally signed by one or more of the entities 652 and 656 that are parties to the smart contract transaction. The results of the smart contract execution may be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0093] Fig.6D A system 660 including a blockchain is shown according to an example embodiment. Fig.6D In the example of , an application programming interface (API) gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincodes) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 662 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the server 654 is a blockchain network peer component that maintains a copy of the world state and the distributed ledger, thereby allowing clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, where, according to the smart contract 630 and the endorsement policy, the endorsing peer will run the smart contract 630.

[0094] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination thereof. The computer program may be implemented on a computer-readable medium, such as a storage medium. For example, the computer program may reside in a random access memory ("random access memory, RAM"), a flash memory, a read-only memory ("read-only memory, ROM"), an erasable programmable read-only memory ("erasable programmable read-only memory, EPROM"), an electrically erasable programmable read-only memory ("electrically erasable programmable read-only memory, EEPROM"), a register, a hard disk, a removable disk, a compact disk read-only memory ("compact disk read-only memory, CD-ROM"), or any other form of storage medium known in the art.

[0095] An exemplary storage medium may be coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and the storage medium may reside in an application specific integrated circuit ("application specific integrated circuit, ASIC"). In an alternative, the processor and the storage medium may reside as discrete components.

[0096] Fig. 7A 7 shows a process 700 in which a new block is added to a distributed ledger 720 according to an example embodiment, and Figure 7B The content of a new data block structure 730 for a blockchain according to an example embodiment is shown. Fig. 7A , a client (not shown) may submit a transaction to blockchain nodes 711, 712, and / or 713. A client may be an instruction received from any source to perform an activity on blockchain 720. For example, a client may be an application acting on behalf of a requester, such as a device, person, or entity proposing a transaction for a blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain the state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes / peers may exist in a blockchain network, including endorsement peers that simulate and endorse transactions proposed by clients, and submission peers that verify endorsements, verify transactions, and submit transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 may perform the roles of endorser nodes, submitter nodes, or both.

[0097] The distributed ledger 720 includes a blockchain that stores immutable, ordered records in blocks, and a state database 724 (current world state) that maintains the current state of the blockchain 722. There can be one distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for each channel they belong to. The blockchain 722 is a transaction log that is structured into hash-linked blocks, where each block contains a series of N transactions. A block can include various components, such as Figure 7B As shown. Block links ( Fig. 7A ) can be generated by adding the hash of the block header of the previous block to the block header of the current block. In this way, all transactions on the blockchain 722 are ordered and cryptographically linked together, thereby preventing tampering with the blockchain data without breaking the hash link. In addition, due to the link, the latest block in the blockchain 722 represents every transaction that has appeared before it. The blockchain 722 can be stored on a peer-to-peer file system (local or attached storage device) that supports only attached blockchain workloads.

[0098] The current state of the blockchain 722 and distributed ledger 722 may be stored in a state database 724. Here, the current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 722. Chaincode invocations execute transactions against the current state in the state database 724. In order to make these chaincode interactions very efficient, the latest values ​​of all keys are stored in the state database 724. The state database 724 may include an indexed view of the transaction log of the blockchain 722, so it can be regenerated from the chain at any time. The state database 724 may be automatically restored (or generated if necessary) at peer startup before a transaction is accepted.

[0099] The endorsing node receives the transaction from the client and endorses the transaction based on the results of the simulation. The endorsing node saves the smart contract proposed by the simulated transaction. When the endorsing node endorses the transaction, the endorsing node creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing the transaction depends on the endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction". Different channels can have different endorsement policies. The client application forwards the endorsed transaction to the sorting service 710.

[0100] The ordering service 710 accepts endorsed transactions, orders them into blocks, and delivers these blocks to committing peers. For example, the ordering service 710 may initiate a new block when a transaction threshold has been reached, a timer has expired, or other conditions have occurred. Fig. 7AIn the example of , blockchain node 712 is a committing peer that has received a new data block 730 for storage on blockchain 720. The first block in a blockchain may be referred to as a genesis block, which includes information about the blockchain, its members, data stored therein, and the like.

[0101] The sorting service 710 can be composed of a group of sorters. The sorting service 710 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the sorting service 710 can accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 720. The architecture of the blockchain network can be designed to make the implementation of "sorting" (e.g., Solo, Kafka, BFT, etc.) a pluggable component.

[0102] Transactions are written to the distributed ledger 720 in a consensus order. The order of transactions is established to ensure that updates to the state database 724 are valid when they are submitted to the network. In this example, the parties to the distributed ledger 720 can choose the ordering mechanism that best suits the network.

[0103] When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to the committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer verifies the transaction within the new data block 730 by checking to ensure that the read set and write set still match the current world state in the state database 724. Specifically, the committing peer may determine whether the read data that existed when the endorser simulated the transaction is the same as the current world state in the state database 724. When the committing peer verifies the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read write set. If the transaction fails, that is, if the committing peer finds that the read write set does not match the current world state in the state database 724, the transaction ordered into the block will still be included in the block, but it will be marked as invalid and the state database 724 will not be updated.

[0104] refer to Figure 7B , a new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be understood that Figure 7BThe various depicted blocks and their contents (such as new data block 730 and its contents) shown in the block data 750 are merely examples and are not meant to limit the scope of the example embodiments. New data block 730 may store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions within block data 750. New data block 730 may also include within block header 740 a link to a previous block (e.g., Fig. 7A In particular, the block header 740 may include a hash of the block header of the previous block. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, etc. The block number of the new data block 730 may be unique and assigned in various orders, such as an incremental / ordered order starting from zero.

[0105] The block data 750 may store transaction information for each transaction recorded within the new data block 730. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 720, transaction ID, period, payload visibility, chaincode path (deploy tx), chaincode name, chaincode version, input (chaincode and function), client (creator) identity (such as public key and certificate), client's signature, endorser's identity, endorser signature, proposal hash, chaincode event, response status, namespace, read set (list of keys and versions read by the transaction), write set (list of keys and values, etc.), start key, end key, key list, Merkel tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0106] In some embodiments, block data 750 may also store anonymous data 752, such as anonymous activities, behaviors, participation, etc. of users within a larger user group. In this way, block data 750 includes additional information that is added to the hash-linked chain of blocks in blockchain 722. For example, the additional information may include a Merkle tree (or other structure) containing anonymous data 752 from various sources. Anonymous data 752 may include secrets known only by the submission of data, accumulation of behaviors, multiple entries on a Merkle tree, etc. Therefore, anonymous data 752 can be stored in an immutable ledger via a key-value store included in the distributed ledger 720. Some of the benefits of storing such anonymous data 752 are reflected in the various embodiments disclosed and described herein. Although in Figure 7B The anonymous data 752 is depicted in the block data 750, but it may also be located in the block header 740 or the block metadata 760, or in other areas of the distributed ledger besides the blockchain, such as a key-value store, a world state database, etc.

[0107] The block metadata 760 may store a plurality of metadata fields (e.g., as a byte array, etc.). The metadata fields may include a signature when the block was created, a reference to the latest configuration block, a transaction filter that identifies valid and invalid transactions within the block, the latest offset of the sorting service that keeps the blocks sorted, etc. The signature, the latest configuration block, and the sorter metadata may be added by the sorting service 710. At the same time, the submitter of the block (such as a blockchain node 712) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 750 and a checksum that identifies whether the transaction is valid / invalid.

[0108] Figure 7C An embodiment of a blockchain 770 for digital content in accordance with embodiments described herein is shown. Digital content may include one or more files and associated information. Files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, attachment-only aspect of the blockchain serves as a security measure to protect the integrity, validity, and authenticity of digital content, making it suitable for use in legal proceedings where admissibility rules apply or in other environments where evidence is considered or where the presentation and use of digital information is otherwise of interest. In this case, the digital content may be referred to as digital evidence.

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

[0110] Block 1 Block 2 ....... Block N

[0111] Hash value 1 Hash value 2 Hash value N

[0112] Digital content 1 Digital content 2 Digital content N

[0113] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store a cryptographic hash of the content of each block without any digital content. The digital content may be stored in another storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or may be a different storage area, or even a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest, and then looking up the hash value in the storage area, where the hash value is stored corresponding to the actual digital content. This operation may be performed by, for example, a database gatekeeper. This may be illustrated as follows:

[0114]

[0115] exist Figure 7C In the example embodiment of the present invention, the blockchain 770 includes a plurality of blocks 7781, 7782, ..., 778 that are cryptographically linked in an ordered sequence. N , where N ≥ 1. Used to link blocks 7781, 7782, ..., 778 N The encryption may be any one of a plurality of keyed or non-keyed hash functions. In one embodiment, blocks 7781, 7782, ..., 778 N The block 7781 is subjected to a hash function that produces an n-bit alphanumeric output (where n is 256 or another number) based on an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle tree algorithms, random number-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778 N The link may be encrypted by a function other than a hash function.For purposes of illustration, the following description is made with reference to a hash function, such as SHA-2.

[0116] Blockchain 7781, 7782, ..., 778 N Each of the blocks includes a header, a version of the file, and a value. Because hashing is performed on the blockchain, the header and value are different for each data block. In one embodiment, the value can be included in the header. As described in more detail below, the version of the file can be the original file or a different version of the original file.

[0117] The first block 7781 in the blockchain is called a genesis block and includes a header 7721, a raw file 7741, and an initial value 7761. The hashing scheme used in the genesis block and in fact all subsequent blocks can vary. For example, all of the information in the first block 7781 can be hashed together and hashed at once, or each or a portion of the information in the first block 7781 can be hashed separately, and then hashing of the separately hashed portions can be performed.

[0118] The header 7721 may include one or more initial parameters, which may include, for example, a version number, a timestamp, a random number, root information, a difficulty level, a consensus protocol, a duration, a media format, a source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. The header 7721 may be automatically generated (e.g., by blockchain network management software) or manually generated by a blockchain participant. N Unlike the header in , header 7721 in the genesis block does not reference a previous block, simply because no previous block exists.

[0119] The original file 7741 in the genesis block may be data captured by a device, for example, with or without processing, before it is included in the blockchain. The original file 7741 is received from a device, a media source, or a node through a system interface. The original file 7741 is associated with metadata, which may be generated manually or automatically by a user, a device, and / or a system processor, for example. The metadata may be included in the first block 7781 in association with the original file 7741.

[0120] The value 7761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes may include a hash value of the original file 7741, metadata of the original file 7741, and other information associated with the file. In one implementation, the initial value 7761 may be based on the following unique attributes:

[0121] 1) SHA-2 calculated hash value for the original file

[0122] 2) Originating device ID

[0123] 3) The start timestamp of the original file

[0124] 4) The original storage location of the original file

[0125] 5) The blockchain network member ID for the software that currently controls the original file and associated metadata

[0126] Other blocks in the blockchain 7782 to 778 NIt also has a header, a file, and a value. However, unlike the first block 7721, the headers 7722 to 772 N Each of the remaining blocks includes a hash value of the immediately preceding block. The hash value of the immediately preceding block may be a hash value of only the header of the preceding block, or may be a hash value of the entire preceding block. By including the hash value of the preceding block in each of the remaining blocks, tracking can be performed block by block from the Nth block backward to the genesis block (and associated original file) (as shown by arrow 780) to establish an auditable and immutable chain of custody.

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

[0128] Files 7742 to 774 in other blocks N The original file may be the same as the original file, or may be a modified version of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed may differ between blocks. The processing may include, for example, any modifications to the file in a previous block, such as editing information or otherwise changing the contents of the file, taking information away from the file, or adding or appending information to the file.

[0129] Additionally or alternatively, the processing may involve simply copying a file from a previous block, changing a storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage device or memory location to another storage device or memory location, or performing an action related to the file of the blockchain and / or its associated metadata. Processing involving analyzing a file may include, for example, attaching, including, or otherwise associating various analytics, statistics, or other information associated with the file.

[0130] Other blocks 7762 to 776 in other blocks N The values ​​in each of the blocks are unique values ​​and are all different due to the processing performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value was assigned. The value of the block therefore provides an indication of what processing was performed in the block and also allows tracking backwards through the blockchain to the original file. This tracking confirms the chain of custody of the file across the blockchain.

[0131] For example, consider a situation where portions of a file in a previous block are edited, masked, or pixelated in order to protect the identity of the person shown in the file. In this case, the block that includes the edited file will include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp when the edit(s) occurred, etc. The metadata can be hashed to form a value. Because the metadata of the block is different from the information that was hashed to form the value in the previous block, the values ​​are different from each other and can be recovered upon decryption.

[0132] In one embodiment, when any one or more of the following occurs, the value of the previous block can be updated (e.g., a new hash value is calculated) to form the value of the current block. In this example embodiment, a new hash value can be calculated by hashing all or part of the information mentioned below.

[0133] a) If the file has been manipulated in any way (for example, if the file has been edited, copied, changed, accessed, or some other action has been taken) the new SHA-2 computed hash value

[0134] b) New storage location for the file

[0135] c) New metadata identified as being associated with the file

[0136] d) Transferring access to or control of a file from one blockchain participant to another

[0137] Fig.7D An embodiment of a block that can represent the structure of a block in blockchain 790 is shown, according to one embodiment. i Including header 772 i 、File 774 i The sum is 776 i .

[0138] Head 772 i Include the previous block Block i-1 The hash value of the previous block and additional reference information, which can be any type of information discussed in this article (e.g., header information including references, properties, parameters, etc.). All blocks reference the hash of the previous block, except for the genesis block. The hash value of the previous block can be just the hash of the header in the previous block, or the hash of all or part of the information in the previous block (including files and metadata).

[0139] File 774 iIn turn, a plurality of data are included, such as Data 1, Data 2, ..., Data N. The data are tagged with metadata Metadata 1, Metadata 2, ..., Metadata N describing the content and / or characteristics associated with the data. For example, the metadata of each data may include a timestamp indicating the data, information on processing the data, keywords indicating the person or other content depicted in the data, and / or other characteristics that may contribute to establishing the validity and content of the file as a whole, and in particular its use digital evidence, for example, as described in conjunction with the embodiments discussed below. In addition to the metadata, each data may be tagged with a reference REF1, REF2, ..., REF N to a previous data. N to mark to prevent tampering, gaps in the file, and sequential reference through the file.

[0140] Once metadata is assigned to data (e.g., by a smart contract), the metadata cannot be changed without the hash changing, which can be easily identified as invalid. Thus, metadata creates a data log of information that can be accessed for use by participants in the blockchain.

[0141] Value 776 i is a hash value or other value calculated based on any of the types of information discussed previously. For example, for any given block i , the value of the block can be updated to reflect the processing performed on the block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other actions or information to be added. Although the value in each block is shown as separate from the metadata of the file and header data, in another embodiment, the value can be based in part or in whole on the metadata.

[0142] Once the blockchain 770 is formed, then at any point in time, an immutable chain of custody for a file can be obtained by querying the blockchain for the transaction history of values ​​on a block basis. The query or tracking procedure can begin by decrypting the value of the most recently included block (e.g., the latest (Nth) block), and then continue to decrypt the values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption may also involve decrypting the header and file and associated metadata at each block.

[0143] Decryption is performed based on the type of encryption that occurred in each block. This may involve the use of a private key, a public key, or a public-private key pair. For example, when asymmetric encryption is used, a blockchain participant or a processor in the network can generate a public and private key pair using a predetermined algorithm. The public and private keys are related to each other through some mathematical relationship. The public key can be distributed publicly to be used as an address to receive messages from other users, for example, an IP address or a home address. The private key is kept secret and is 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 be sure that only the sender could have sent this message.

[0144] Generating a key pair may be similar to creating an account on the blockchain, but you don’t actually have to register it anywhere. Moreover, every transaction performed on the blockchain is digitally signed by the sender using his private key. This signature ensures that only the owner of the account can track and process (if within the scope of permission determined by the smart contract) the files on the blockchain.

[0145] Figure 8 An example system 800 is shown that supports one or more of the example embodiments described and / or depicted herein. System 800 includes a computer system / server 802 that can operate with many other general or special computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 802 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

[0146] Computer system / server 802 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Generally speaking, program modules can include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 802 can be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located in local and remote computer system storage media including memory storage devices.

[0147] like Figure 8As shown, the computer system / server 802 in the cloud computing node 800 is shown in the form of a general-purpose computing device. The components of the computer system / server 802 may include, but are not limited to, one or more processors or processing units 804, a system memory 806, and a bus that couples various system components including the system memory 806 to the processor 804.

[0148] The term "bus" refers to one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus using any of a variety of bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0149] The computer system / server 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computer system / server 12, including volatile and non-volatile media, removable and non-removable media. In one embodiment, the system memory 906 implements the flowcharts of the other figures. The system memory 806 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 810 and / or cache memory 812. The computer system / server 802 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 814 can be used to read and write non-removable, non-volatile magnetic media (not shown in the figure, commonly referred to as a "hard drive"). Although Figure 1 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical medium) may be provided. In these cases, each drive may be connected to the bus via one or more data medium interfaces. The memory 80 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of the various embodiments of the present application.

[0150] A program / utility 816 having a set (at least one) of program modules 818 may be stored, for example, in memory 806, including, by way of example but not limitation, an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. Program modules 818 generally perform the functions and / or methods of the embodiments described herein.

[0151] As will be appreciated by those skilled in the art, various aspects of the present application may be implemented as a system, method or computer program product. Therefore, various aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.) or an embodiment in combination with software and hardware, which may all be collectively referred to as "circuit", "module" or "system" in this article. In addition, various aspects of the present application may take the form of a computer program product implemented in one or more computer-readable media containing a computer-readable program code thereon.

[0152] The computer system / server 802 may also communicate with one or more external devices 820 (e.g., keyboards, pointing devices, displays 822, etc.), may communicate with one or more devices that enable a user to interact with the computer system / server 802, and / or may communicate with any device that enables the computer system / server 802 to communicate with one or more other computing devices (e.g., network cards, modems, etc.). Such communication may be performed via an input / output (I / O) interface 824. In addition, the computer system / server 802 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 826. As shown, the network adapter 826 communicates with other modules of the computer system / server 802 via a bus. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the computer system / server 802, including, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0153] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media have been shown in the drawings and described in the foregoing detailed description, it should be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions as set forth and defined by the appended claims. For example, the capabilities of the systems of the various drawings may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include pairs of transmitters, receivers, or both transmitters and receivers. For example, all or part of the functions performed by the various modules may be performed by one or more of these modules. Further, the functions described herein may be performed at different times and in relation to different events inside or outside the modules or components. Moreover, the information sent between the various modules may be sent between the modules via a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or via at least one of a plurality of protocols. Moreover, the messages sent or received by any module may be sent or received directly and / or via one or more of the other modules.

[0154] Those skilled in the art will appreciate that a "system" may be implemented as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smart phone, or any other suitable computing device, or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide an example of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

[0155] It should be noted that some of the system features described in this specification have been presented as modules in order to more specifically emphasize their implementation independence. For example, a module can be implemented as a hardware circuit comprising a custom very large-scale integration (VLSI) circuit or gate array, an off-the-shelf semiconductor (such as a logic chip, transistor, or other discrete component). A module can also be implemented in a programmable hardware device, such as a field programmable gate array, programmable array logic, a programmable logic device, a graphics processing unit, etc.

[0156] Modules may also be implemented at least in part in software so that they are executed by various types of processors. The identified unit of executable code may, for example, include one or more physical or logical blocks of computer instructions, which may, for example, be organized as objects, programs, or functions. However, the executable program of the identified module does not need to be physically located together, but may include different instructions stored in different locations, which include the module and realize the stated purpose of the module when these instructions are logically combined together. Further, a module may be stored on a computer-readable medium, which may be, for example, a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape, or any other such medium for storing data.

[0157] In fact, a module of executable code can be a single instruction or many instructions, and can even be distributed on several different code segments, between different programs, and distributed on several memory devices. Similarly, operating data can be identified and shown in the module herein, and can be implemented in any suitable form, and organized in any suitable type of data structure. Operating data can be collected as a single data set, or can be distributed in different locations, including on different storage devices, and can exist at least partially only as electronic signals on a system or network.

[0158] It is easy to understand that the components of the present application can be arranged and designed in a variety of different configurations as generally described and shown in the drawings herein. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but only represents an embodiment of the selected application.

[0159] Those skilled in the art will readily appreciate that the above content may be practiced with steps in different orders and / or for hardware elements in configurations different from those disclosed. Therefore, although the present application has been described based on these preferred embodiments, some modifications, variations, and alternative structures will be apparent to those skilled in the art.

[0160] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and that the scope of the present application is limited solely by the appended claims when considering the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.) of the appended claims.

Claims

1. A computing system comprising: a network interface configured to receive a plurality of content requests to add content to a blockchain storage structure implemented on a blockchain database, to add a plurality of pieces of content to the blockchain storage structure; and a processor configured to: temporarily store each of the plurality of pieces of content of the plurality of content requests in a queue implemented via the blockchain database based on when the plurality of content requests are received; Receive a request to refresh the queue invoked by the chaincode; and in response to a refresh request, removing the content from the queue and adding the content to the blockchain storage structure, wherein the plurality of content requests include anonymous content that does not reveal the identity of a content creator and a zero-knowledge proof provided by the content creator, The processor is further configured to add the anonymous content to an active leaf node on a Merkle tree storage structure implemented via the blockchain database, comprising: identifying, based on the zero-knowledge proof, an active leaf on the Merkle tree storage structure storing previously recorded anonymized content of a blockchain participant associated with the content request; and A new active leaf of the blockchain participant is generated based on the anonymous content and the previously recorded anonymous content.

2. The computing system of claim 1, wherein: The queue comprises a first-in-first-out (FIFO) queue implemented via a chaincode of the blockchain database.

3. The computing system of claim 2, wherein: The processor is configured to push the content from an end of the FIFO queue into a new node on a tree structure stored on the blockchain database.

4. The computing system of claim 1, wherein: The processor maintains the Merkle tree storage structure within a key value store (KVS) of the blockchain database.

5. The computing system of claim 1, wherein: The blockchain storage structure stores anonymous content from multiple content creators.

6. A method applied to a computing system, comprising: receiving a plurality of content requests to add content to a blockchain storage structure implemented on a blockchain database to add a plurality of pieces of content to the blockchain storage structure; temporarily storing each of the plurality of pieces of content of the plurality of content requests in a queue implemented via the blockchain database based on when the plurality of content requests are received; Receive a request to refresh the queue invoked by the chaincode; as well as In response to the refresh request, removing the content from the queue and adding the content to the blockchain storage structure, wherein the plurality of content requests include anonymous content that does not reveal the identity of a content creator and a zero-knowledge proof provided by the content creator, The method further includes adding the anonymous content to an active leaf node on a Merkle tree storage structure implemented via the blockchain database, comprising: identifying, based on the zero-knowledge proof, an active leaf on the Merkle tree storage structure storing previously recorded anonymized content of a blockchain participant associated with the content request; and A new active leaf of the blockchain participant is generated based on the anonymous content and the previously recorded anonymous content.

7. The method according to claim 6, wherein: The queue comprises a first-in-first-out (FIFO) queue implemented via a chaincode of the blockchain database.

8. The method according to claim 7, wherein: The removal includes pushing the content from the end of the FIFO queue to a new node on a tree structure stored on the blockchain database.

9. The method according to claim 6, wherein: The removing includes adding the content to an active leaf node on a Merkle tree storage structure implemented via the blockchain database.

10. The method according to claim 9, wherein: The Merkle tree storage structure is maintained in the key value storage (KVS) of the blockchain database.

11. The method according to claim 6, wherein: The blockchain storage structure stores anonymous content from multiple content creators.

12. A computing system comprising: A storage device configured as a tree structure, the tree structure including anonymous behavior data of multiple blockchain participants stored in multiple nodes in a hierarchical structure; as well as a processor configured to: receive a request to add new anonymous behavior data to the tree structure, the request comprising a zero-knowledge proof generated by a blockchain participant; identify, based on the zero-knowledge proof, an active leaf on the tree structure storing previously recorded anonymous behavior data of the blockchain participant associated with the request; and generate a new active leaf for the blockchain participant based on the new anonymous behavior data and the previously recorded anonymous behavior data, Wherein, the storage device is further configured to store the new active leaf as a leaf node on the tree structure.

13. The computing system of claim 12, wherein: The tree structure includes multiple active leaf nodes, and the multiple active leaf nodes respectively store anonymous behavior data of multiple blockchain participants, and the anonymous behavior data does not reveal the identities of the multiple blockchain participants.

14. The computing system of claim 12, wherein: The processor is further configured to, in response to receiving the new anonymous behavioral data, deprecate the identified active leaf on the tree structure with the new active leaf.

15. The computing system of claim 12, wherein: The zero-knowledge proof includes a random string known only to the blockchain participants.

16. The computing system of claim 12, wherein: The processor is further configured to verify the validity of the new anonymous behavior based on the root value of the tree structure, the zero-knowledge proof, and an anonymous property of the new anonymous behavior.

17. The computing system of claim 12, wherein: The tree structure includes a Merkle tree stored via a key-value store of the storage device, and the Merkle tree includes a corresponding active leaf node for each participant of the blockchain.

18. The computing system of claim 12, wherein: The anonymous behavioral data includes anonymous comments submitted by the blockchain participants.

19. The computing system of claim 12, wherein: The processor is further configured to endorse the new active leaf based on the zero-knowledge proof before storing the new active leaf on the tree structure.

20. A method applied to a computing system, comprising: storing, via a blockchain storage device, a tree structure comprising anonymous behavioral data of a plurality of blockchain participants stored in a plurality of nodes in a hierarchical structure; receiving a request to add new anonymous behavior data to the tree structure, the request comprising a zero-knowledge proof generated by a blockchain participant; identifying, based on the zero-knowledge proof, an active leaf on the tree structure storing previously recorded anonymized behavioral data of a blockchain participant associated with the request; generating a new active leaf of the blockchain participant based on the new anonymous behavior data and the previously recorded anonymous behavior data; as well as The new active leaf is stored as a leaf node on the tree structure in the blockchain storage device.

21. The method according to claim 20, wherein: The tree structure in the blockchain storage device includes multiple active leaf nodes, and the multiple active leaf nodes respectively store anonymous behavior data of multiple blockchain participants, and the anonymous behavior data does not reveal the identities of the multiple blockchain participants.

22. The method of claim 20, further comprising, in response to receiving the new anonymous behavioral data, deprecating the identified active leaf on the tree structure with the new active leaf.

23. The method according to claim 20, wherein: The zero-knowledge proof includes a random string known only to the blockchain participants.

24. The method according to claim 20, further comprising verifying the validity of the new anonymous behavior based on the root value of the tree structure, the zero-knowledge proof, and the anonymous attribute of the new anonymous behavior.

25. The method according to claim 20, wherein: The tree structure comprises a Merkle tree stored via a key-value store of the blockchain storage device, and the Merkle tree comprises a corresponding active leaf node for each participant of the blockchain.

26. The method of claim 20, wherein: The anonymous behavioral data includes anonymous comments submitted by the blockchain participants.

27. The method of claim 20, further comprising endorsing the new active leaf based on the zero-knowledge proof before storing the new active leaf on the tree structure.

28. A non-transitory computer readable medium comprising instructions which, when read by a processor, cause the processor to perform the method according to any one of claims 6-11 and 20-27.

29. A computer system comprising: one or more processors; A computer-readable storage medium coupled to the one or more processors, the computer-readable storage medium comprising instructions that, when executed by the one or more processors, perform the method of any one of claims 6-11 and 20-27.

30. A computing system comprising modules for respectively performing the steps of the method according to any one of claims 6-11 and 20-27.

Images