Method, system and computer program (compliance mechanism in blockchain network)

Abstract

To solve the issues of reliability, time and trust by extending features of a database such as immutability, digital signatures, and being a single trustable information source, and provide a solution for compliance and accounting of transactions.SOLUTION: A node in a blockchain network may agree with an authority, accept a compliance module from the authority, and accept the compliance module. The node may also receive an operation, verify compliance of the operation based on the compliance module, and add the verified operation to a ledger on the blockchain network.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates generally to the field of digital asset transfer smart contracts, and more specifically to co-extended compliance in blockchain networks. [Background technology]

[0002] Blockchains provide immutability of data by replicating it across all nodes in the network. To be able to validate a blockchain, nodes must have access to the complete history of transactions, meaning any data on the chain is visible to all participants.

[0003] The transfer of digital or crypto assets between two parties or entities is governed by a smart contract, some type of business rules coded into the smart contract, or chaincode, or a combination thereof. These smart contracts act as the glue that ensures that all conditions are met when assets are transferred. Smart contracts also provide a governance layer to ensure that all conditions are met and that the system's obligations and liabilities are enforced, facilitating a digital transaction system. Summary of the Invention [Problem to be solved by the invention]

[0004] It solves the problems of reliability, time, and trust by extending database characteristics such as immutability, digital signatures, and being a single source of truth. It provides a solution for transaction compliance and accounting. [Means for solving the problem]

[0005] Embodiments of the present disclosure include methods, systems, and computer program products for compliance mechanisms in blockchain networks.

[0006] Some embodiments of the present disclosure may be illustrated by a method that includes: agreeing, by a node in a blockchain network, with an authority; receiving, by the node, a compliance module from the authority; and accepting, by the node, the compliance module.

[0007] Additionally, some embodiments of the present disclosure may be illustrated by a system including a memory; and a processor in communication with the memory, the processor configured to perform operations including agreeing on an authority for a blockchain network, receiving a compliance module from the authority, and accepting the compliance module.

[0008] Additionally, some embodiments of the present disclosure may be illustrated by a computer program product comprising a computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a processor to cause the processor to perform functions, the functions including agreeing with an authority for a blockchain network, receiving a compliance module from the authority, and accepting the compliance module.

[0009] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. [Brief explanation of the drawings]

[0010] The drawings included in this disclosure are incorporated in and constitute a part of the specification. They illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of particular embodiments and are not intended to limit the disclosure.

[0011] [Figure 1] FIG. 1 is a network diagram of a system including a database according to an exemplary embodiment.

[0012] [Figure 2A] FIG. 1 illustrates an example of a blockchain architecture configuration, according to an exemplary embodiment.

[0013] [Figure 2B] FIG. 1 illustrates a blockchain transaction flow, according to an exemplary embodiment.

[0014] [Figure 3A] FIG. 1 illustrates a permissioned network according to an exemplary embodiment.

[0015] [Figure 3B] FIG. 2 illustrates another permissioned network according to an exemplary embodiment.

[0016] [Figure 3C] FIG. 1 illustrates an unlicensed network according to an exemplary embodiment.

[0017] [Figure 4A] FIG. 1 illustrates a process for a new block being added to a distributed ledger, according to an exemplary embodiment.

[0018] [Figure 4B] FIG. 10 illustrates the contents of a new data block according to an exemplary embodiment.

[0019] [Figure 4C]FIG. 1 illustrates a block chain for digital content, according to an exemplary embodiment.

[0020] [Figure 4D] FIG. 1 illustrates a block diagram that may represent the structure of a block in a blockchain, according to an exemplary embodiment.

[0021] [Figure 5] FIG. 1 illustrates a high-level block diagram of an exemplary computer system that may be used to implement one or more of the methods, tools, and modules, and any associated functionality described herein, according to embodiments of the present disclosure.

[0022] [Figure 6] FIG. 10 is a flow diagram for accepting a compliance module in a blockchain network, according to an example embodiment.

[0023] [Figure 7] FIG. 10 is a flow diagram for applying compliance and audit modules to blockchain operations, according to an exemplary embodiment.

[0024] [Figure 8] FIG. 1 is a flow diagram showing module inception, selection, and processing.

[0025] The embodiments described herein are susceptible to various modifications and alternative forms, details of which are shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the particular embodiments described are not to be construed in a limiting sense. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0026] Aspects of the present disclosure relate generally to the field of due diligence for digital asset transfers across multiple jurisdictions, and more specifically to co-extended compliance in blockchain networks.

[0027] It will be readily understood that the components, as generally described and illustrated in the Figures herein, can be arranged and designed in a wide variety of different forms. Thus, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system, as illustrated in the accompanying Figures, is not intended to limit the scope of the claimed application but is merely representative of selected embodiments.

[0028] The features, structures, or characteristics described throughout this specification may be combined or eliminated in any suitable manner in one or more embodiments. For example, the use of the phrase "exemplary embodiment," "some embodiments," or other similar language throughout this specification indicates that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment. Thus, the appearances of the phrase "exemplary embodiment," "some embodiments," "other embodiments," or other similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or eliminated in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements can allow for one-way or two-way communication, or a combination thereof, even if the connection is shown with a one-way or two-way arrow. Also, any devices shown in the figures can be different devices. For example, even if a mobile device is shown as transmitting information, a wired device could also be used to transmit information.

[0029] Also, while the term "message" may be used in describing the embodiments, the present application may apply to many types of networks and data. Furthermore, although particular types of connections, messages, and signaling may be shown in the exemplary embodiments, the present application is not limited to the particular types of connections, messages, and signaling.

[0030] Described herein are methods, systems, and computer program products that utilize blockchain (e.g., Hyperledger Fabric) channels and smart contracts that implement logic based on non-interactive zero-knowledge proofs.

[0031] In some embodiments, a method, system, or computer program product, or combination thereof, utilizes a distributed database (such as a blockchain), which is a distributed storage system with multiple nodes communicating with each other. A distributed database comprises an append-only immutable data structure similar to a distributed ledger that allows records to be maintained among mutually untrusted parties. The 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 unless consensus is achieved among the distributed peers. For example, peers may execute a consensus protocol to verify the validity of blockchain storage transactions, group the storage transactions into blocks, and build a hash chain over the blocks. This process forms a ledger by ordering the storage transactions as necessary for consistency.

[0032] In various embodiments, a permissioned or permissionless blockchain, or a combination thereof, can be used. In a public or permissionless blockchain, anyone can participate without a specific identity (e.g., while maintaining anonymity). Public blockchains can involve native cryptocurrencies and use consensus based on various protocols, such as proof of work. Permissioned blockchain databases, on the other hand, provide secure interactions between entities that share a common purpose but do not fully trust each other, such as businesses exchanging funds, goods, information, and the like.

[0033] Additionally, in some embodiments, a method, system, or computer program product, or combination thereof, can utilize a blockchain, referred to as a "smart contract" or "chaincode," to operate arbitrary programmable logic tailored to a decentralized storage scheme. In some cases, a specialized chaincode, referred to as a system chaincode, may exist to manage functions and parameters. A method, system, or computer program product, or combination thereof, can further utilize smart contracts, which are trusted distributed applications that utilize the tamper-resistant properties of a blockchain database and an underlying agreement between nodes, referred to as an endorsement or endorsement policy. Blockchain transactions associated with this application can be "endorsed" before being committed to the blockchain, with unendorsed transactions being ignored.

[0034] An endorsement policy allows a chaincode to specify approvers for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transaction enters an ordering phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0035] In some embodiments, a method, system, or computer program product, or combination thereof, may utilize nodes, which are communicating entities in a blockchain system. A "node" may perform a logical function, in the sense that multiple nodes of different types may run on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes may include different types, such as client or submitting client nodes, which submit transaction calls to approvers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., ordering node).

[0036] Another type of node is a peer node, which can receive client-submitted transactions, commit transactions, and maintain a ledger state and copy of blockchain transactions. Peers can also have the role of approver, although this is not a requirement. An ordering service node or orderer is a node that performs communication services for all nodes and implements delivery guarantees, such as committing / confirming transactions and broadcasting to each of the peer nodes in the system when modifying the blockchain world state, also known as the initial blockchain transaction, which usually contains control and setup information.

[0037] In some embodiments, a method, system, or computer program product, or combination thereof, may utilize a ledger that is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (e.g., transactions) submitted by participants (e.g., client nodes, ordering nodes, validator nodes, peer nodes, etc.). Each participant (e.g., peer node) may maintain a copy of the ledger. As a result of a transaction, a set of asset key-value pairs may be committed to the ledger as one or more operands, such as create, update, delete, and the like. The ledger comprises a blockchain (also referred to as a chain) that is used to store immutable, sequenced records in blocks. The ledger also comprises a state database that maintains the current state of the blockchain.

[0038] In some embodiments, a method, system, or computer program product, or combination thereof, described herein may utilize a chain, which is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is 1 or greater. A block header contains a hash of the block's transactions as well as a hash of the header of the previous block. In this way, all transactions on the ledger may be sequenced together and cryptographically linked. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that came before it, ensuring that all peer nodes are in a consistent and trusted state. The chain may be stored on a peer node file system (e.g., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0039] The current state of the immutable ledger represents the most recent values ​​for all keys contained in the chain transaction log. The current state is sometimes referred to as the world state, as it represents the most recent key values ​​known to the channel. Chaincode invocations perform transactions against the ledger's current state data. To make these chaincode interactions efficient, the most recent values ​​for keys may be stored in a state database. The state database may simply be an indexed view into the chain's transaction log and therefore can be regenerated from the chain at any time. The state database may be automatically recovered (or generated if necessary) at peer node startup, before any transactions are accepted.

[0040] Some benefits of the solutions described and illustrated herein include methods, systems, and computer program products for compliance mechanisms within blockchain networks. Exemplary embodiments address issues of reliability, time, and trust by extending database features such as immutability, digital signatures, and single source of truth. Exemplary embodiments provide solutions for transaction compliance and accounting. Blockchain networks may be homogenous based on asset types and rules governing assets based on smart contracts.

[0041] Blockchains differ from traditional databases in that they are not centralized storage, but rather decentralized, immutable, and secure storage where nodes may share changes to records in storage. Some properties inherent to blockchains and that aid in their implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, authorization, accessibility, and the like, which are further described herein. According to various aspects, the systems described herein are implemented for immutable accountability, security, privacy, permissioned decentralization, availability of smart contracts, authorization, and accessibility inherent and unique to blockchains.

[0042] In particular, blockchain ledger data is immutable, providing an efficient method for compliance mechanisms within a blockchain network. Additionally, the use of cryptography in blockchains provides security and builds trust. Smart contracts manage the state of assets as they complete their lifecycles, and specialized nodes can ensure that blockchain operations comply with compliance requirements. An exemplary blockchain is permissioned and decentralized. Therefore, each end user may have their own copy of the ledger to which they have access. Multiple organizations (and peers) may be onboarded onto the blockchain network. Key organizations may act as validating peers to verify the results of smart contract execution, read sets, and write sets. In other words, the inherent characteristics of blockchains provide an efficient implementation of private transaction processing within a blockchain network.

[0043] One of the benefits of the exemplary embodiments is that they enhance the functionality of a computing system by implementing a method for processing private transactions within a blockchain network. Through the blockchain system described herein, a computing system (or a processor within a computing system) can perform private transaction processing functions using a blockchain network by providing access to capabilities such as distributed ledgers, peers, cryptography, MSPs, event handling, etc. Blockchain also enables the creation of business networks and the onboarding of any user or organization for participation. Thus, blockchain is more than just a database. Blockchain has the ability to create a network of users and onboard / offboard organizations that collaborate to perform service operations in the form of smart contracts.

[0044] Exemplary embodiments provide numerous benefits over traditional databases. For example, through blockchain, embodiments provide immutable accountability, security, privacy, permissioned decentralization, the availability of smart contracts, and authorization and accessibility inherent and unique to blockchain.

[0045] On the other hand, traditional databases may not be useful for implementing exemplary embodiments because they do not bring all parties on the network, they do not create trusted collaboration, and they do not provide an efficient method for data compliance. Traditional databases do not provide tamper-proof storage and do not provide due diligence and compliance retention. Thus, the exemplary embodiments provide a unique solution to problems in the area / field of compliance for transactions.

[0046] FIG. 1 illustrates a logic network diagram for smart data annotation in a blockchain network, according to an example embodiment.

[0047] Referring to FIG. 1 , an exemplary network 100 includes a node 102 connected to other blockchain (BC) nodes 105 representing document owner organizations. The node 102 may be connected to a blockchain 106 having a ledger 108 for storing data (110) to be shared among the nodes 105. While this example details only one node 102, multiple such nodes may be connected to the blockchain 106. It should be understood that the node 102 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of the node 102 disclosed herein. The node 102 may include a processor 104, which may be a computing device or server computer, or the like, and may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another hardware device, or a combination thereof. While a single processor 104 is shown, it should be understood that the node 102 may include multiple processors, multiple cores, or the like without departing from the scope of the node 102 system. Distributed file storage 150 may be accessible to the processor node 102 and other BC nodes 105. The distributed file storage may be used to store documents identified in the ledger (distributed file storage) 150.

[0048] The node 102 may also include a non-transitory computer-readable medium 112 that may store machine-readable instructions executable by the processor 104. Examples of machine-readable instructions are indicated at 114-120 and are described further below. Examples of the non-transitory computer-readable medium 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-transitory computer-readable medium 112 may be a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

[0049] The processor 104 may execute the machine-readable instructions 114 to agree with the authority. As described above, the blockchain ledger 108 may store data to be shared among the nodes 105. The blockchain 106 network may be configured with one or more smart contracts that manage transactions for multiple participating nodes. Documents linked to annotation information may be stored in distributed file storage 150. The processor 104 may execute the machine-readable instructions 116 to receive a compliance module from the authority. The processor 104 may execute the machine-readable instructions 118 to accept the compliance module.

[0050] FIG. 2A illustrates a blockchain architecture configuration 200 according to an example embodiment. Referring to FIG. 2A, the blockchain architecture 200 may include a group of specific blockchain elements, such as blockchain nodes 202. The blockchain nodes 202 may include one or more peer nodes 204-210 (these four nodes are shown merely by way of example). These nodes participate in multiple activities, such as the blockchain transaction addition and validation process (consensus). One or more of the blockchain nodes 204-210 may approve transactions based on an endorsement policy and provide an ordering service for all blockchain nodes in the architecture 200. The blockchain nodes may initiate blockchain validations and attempt writes to a blockchain immutable ledger stored in a blockchain layer 216, a copy of which may be stored on the underlying physical infrastructure 214. A blockchain configuration may include one or more applications 224 linked to an application programming interface (API) 222 for accessing and executing stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to customized configurations desired by participants, maintain their own state, control their own assets, and receive external information, which can be deployed and installed as transactions on all blockchain nodes 204-210 via appending to the distributed ledger.

[0051] The blockchain foundation or platform 212 may comprise various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 216 may present an interface that provides access to the virtual execution environment necessary to process program code and engage the physical infrastructure 214. The cryptographic trust services 218 may be used to verify transactions, such as asset exchange transactions, and keep information private.

[0052] The blockchain architecture configuration of FIG. 2A may process and execute program / application code 220 through one or more interfaces and services provided by the blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 may be executed by the nodes 204-210 in the form of smart contracts and associated chaincodes that can store and transfer data and have conditions or other code elements that are subject to execution. As a non-limiting example, smart contracts may be created to implement reminders, updates, or other notifications subject to changes, updates, etc., or a combination thereof. Smart contracts may be used to identify themselves, authorization and access requirements, and rules associated with the use of the ledger. For example, document attribute information 226 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. Results 228 may include multiple linked shared documents. The physical infrastructure 214 may be used to obtain any of the data or information described herein.

[0053] Smart contracts may be created via high-level application and programming languages ​​and then written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, or replicated with the blockchain (e.g., a decentralized network of blockchain peers), or a combination thereof. A transaction is the execution of smart contract code that can occur in response to conditions associated with the smart contract being met. Execution of a smart contract may trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger resulting from smart contract execution may be automatically replicated across the decentralized network of blockchain peers through one or more consensus protocols.

[0054] Smart contracts may write data to the blockchain in the format of key-value pairs. Additionally, 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 logic operations to the blockchain. The code may be used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain can be public, or it can be encrypted and kept private, or both. The temporary data used / generated by smart contracts is kept in memory by the provided execution environment and then deleted once the data needed for the blockchain has been identified.

[0055] Chaincode may include a code interpretation of a smart contract, with additional features. As described herein, chaincode may be program code deployed on a computing network that is executed and validated by a chain validator together during the consensus process. The chaincode receives hashes and retrieves hashes from the blockchain associated with data templates created by using pre-stored feature extractors. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chaincode transmits an authorization key for the requested service. The chaincode may be written to blockchain data associated with cryptographic details.

[0056] FIG. 2B illustrates an example of a blockchain transaction flow 250 between nodes of a blockchain, according to an exemplary embodiment. With reference to FIG. 2B, a general description of transaction flow 250 is provided, followed by a more specific example. The 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 a chaincode function to initiate the transaction. The output may include a chaincode result, a set of key / value versions read in the chaincode (the read set), and a set of key / values ​​written to the chaincode (the write set). If approved, a proposal response 292 is sent back to the client 260 along with the endorsing signature. The client 260 assembles the endorsing into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then distributes the ordered transaction as a block to all peers 281-283 on the channel. Before committing to the blockchain, each peer 281-283 may verify the validity of the transaction. For example, a peer may check an endorsement policy to ensure that the correct allocation of designated peers has signed the result and authenticated the signature on the transaction payload 293. In some embodiments, one or more of the peers may be manager nodes.

[0057] A more specific description of transaction flow 250 can be understood with a more specific example. Initially, a client node 260 initiates a transaction 291 by constructing and sending a request to a peer node 281, which is an approver. The client 260 may include an application that utilizes a supported software development kit (SDK) to generate a transaction proposal using available APIs. The proposal is a request that invokes chaincode functions to read or write data from the ledger (i.e., write a new key-value pair for an asset), or both. The SDK may package the transaction proposal into an appropriately designed format (e.g., protocol buffers for remote procedure calls (RPCs)) and act as a shim to obtain the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0058] In response, the endorsing peer node 281 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not already been submitted previously (replay attack protection), that the signature is valid, and (d) the submitter (in this example, client 260) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 281 may take the transaction proposal input as an argument to a chaincode function that is invoked. The chaincode is then executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set. However, no updates are made to the ledger at this point. At 292, the set of values, along with the endorsing peer node 281's signature, are returned as a proposal response 292 to the client 260's SDK, which parses the payload for the application to consume.

[0059] In response, the application on the client 260 inspects / verifies the endorsing peer signatures and compares the proposal responses to determine whether they are the same. If the chaincode simply queried the ledger, the application inspects the query response and typically does not submit the transaction to the ordering service node 284. If the client application intends to submit a transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied (i.e., whether all peer nodes required for the transaction have endorsed the transaction) before submitting. Here, the client may include only one of multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node may be required to endorse the transaction. The architecture is such that the endorsement policy can still be enforced by peers and maintained in the commit validation phase, even if the application chooses not to inspect the response or otherwise forwards an unendorsed transaction.

[0060] After successful validation, client 260 assembles the approvals into a transaction 293 and broadcasts the transaction proposal and response in a transaction message to ordering node 284. The transaction may include a read / write set, an approving peer signature, and a channel ID. Ordering node 284 does not need to validate the entire contents of a transaction to perform its operation. Instead, ordering node 284 may simply receive transactions from all channels in the network and order them chronologically by channel, creating a block of transactions per channel.

[0061] A block of transactions is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 in the block are validated to ensure that any endorsement policies are met and to ensure that there have been no changes to the ledger state with respect to the readset variable since transaction execution generated the readset. The transactions in the block are tagged as valid or invalid. Furthermore, in operation 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, the writeset is committed to the current state database. An event is emitted to notify the client application whether the transaction has been validated or invalidated, as well as to notify that the transaction (invocation) has been immutably appended to the chain.

[0062] FIG. 3A illustrates an example of a permissioned blockchain network 300 featuring a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 302 may initiate transactions against a permissioned blockchain 304. In this example, transactions may be deployed, invoked, or queried, and may be issued through a client-side application, such as directly through an API, or using an SDK. The network may provide access to regulators 306, such as auditors. A blockchain network operator 308 manages member permissions, such as enrolling regulators 306 as "auditors" and blockchain users 302 as "clients." Auditors may be limited to only querying the ledger, while clients may be authorized to deploy, invoke, and query specific types of chaincode.

[0063] A blockchain developer 310 can write chaincode and client-side applications. The blockchain developer 310 can deploy the chaincode directly to the network through an interface. To include certificates from traditional data sources 312 in the chaincode, the developer 310 may use an out-of-band connection to access the data. In this example, a blockchain user 302 connects to the permissioned blockchain 304 through one of the peer nodes 314 (see any one of nodes 314a-e). Before proceeding with any transaction, the peer node 314 (e.g., node 314a) obtains the user's enrollment and transaction certificate from a certificate authority 316 that manages user roles and permissions. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 304. However, a user attempting to use the chaincode may need to verify their certificate on the traditional data source 312. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 318.

[0064] 3B illustrates another example of a permissioned blockchain network 320 featuring a distributed, decentralized, peer-to-peer architecture. In this example, blockchain users 322 may submit transactions to a permissioned blockchain 324. In this example, transactions may be deployed, invoked, or queried, and may be issued through client-side applications, such as directly through an API, or using an SDK. The network may provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as enrolling regulators 326 as "auditors" and blockchain users 322 as "clients." Auditors may be limited to only querying the ledger, while clients may be authorized to deploy, invoke, and query specific types of chaincode.

[0065] A blockchain developer 330 may write chaincode and client-side applications. The blockchain developer 330 can deploy the chaincode directly to the network through an interface. To include certificates from traditional data sources 332 in the chaincode, the developer 330 may use an out-of-band connection to access the data. In this example, a blockchain user 322 connects to the network through a peer node 334. Before proceeding with any transaction, the peer node 334 obtains the user's enrollment and transaction certificate from a certificate authority 336. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 324. Alternatively, a user attempting to use the chaincode may need to verify their certificate on the traditional data source 332. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0066] In some embodiments of the present disclosure, the blockchain herein may be a permissionless blockchain. In contrast to a permissioned blockchain, which requires permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user may create a personal address and begin interacting with the network by submitting transactions and thus adding entries to the ledger. Furthermore, all parties have the option of running a node on the system and utilizing a mining protocol that helps validate transactions.

[0067] 3C illustrates a process 350 for a transaction processed by a permissionless blockchain 352 including multiple nodes 354. A sender 356 wishes to send a payment or some other form of value (e.g., an act, medical history, contract, good, service, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In some embodiments, the sender device 356 and the receiver device 358 may each have a digital wallet (associated with the blockchain 352) that provides user interface controls and a display of transaction parameters. In response, the transaction is broadcast throughout the blockchain 352 to the nodes 354.

[0068] Depending on the network parameters of the blockchain 352, the node validates 360 the transaction based on rules (which may be predefined or dynamically assigned) established by the permissionless blockchain 352 creator. For example, this may include verifying the identities of the parties involved, etc. The transaction may be validated immediately or may be queued with other transactions, and the node 354 determines whether the transaction is valid based on a set of network rules.

[0069] In construction 362, valid transactions are formed into blocks and sealed with a lock (hash). This process may be performed by mining nodes among nodes 354. Mining nodes may use additional software specifically for mining and generating blocks for the permissionless blockchain 352. Each block may be identified by a hash (e.g., a 256-bit number) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the header of the previous block in the chain, and a set of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure, independent chain of blocks.

[0070] Before a block can be added to the blockchain, the block must be validated. Validation in a permissionless blockchain 352 may involve Proof of Work (PoW), which is the solution to a puzzle derived from the block's header. Another process for validating a block, not shown in the example of FIG. 3C, is Proof of Stake. Unlike Proof of Work, where an algorithm rewards miners for solving a mathematical problem, in Proof of Stake, the creator of a new block is selected in a deterministic manner according to their wealth, also defined as "stake." A similar proof is then performed by the selected / elected nodes.

[0071] In mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution meets a network-wide target. This generates proof of work, which guarantees a correct answer. In other words, a potential solution must prove that computational resources have been exhausted to solve the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins) for successfully mining a block.

[0072] Here, the PoW process chains blocks together, making it extremely difficult for an attacker to modify the blockchain by requiring an attacker to modify all subsequent blocks in order for a modification to one block to be accepted. Furthermore, as new blocks are mined, the difficulty of modifying the block increases, and the number of subsequent blocks increases. In distribution 366, successfully validated blocks are distributed throughout the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the permissionless blockchain 352. Furthermore, the value of the transaction submitted by the sender 356 is deposited or otherwise transferred to a digital wallet on the receiving device 358.

[0073] Figure 4A illustrates a process 400 in which a new block is added to a distributed ledger 420, according to an example embodiment, and Figure 4B illustrates the contents of a new data block structure 430 for a blockchain, according to an example embodiment. The new data block 430 may include document linking data.

[0074] Referring to FIG. 4A , a client (not shown) may submit a transaction to blockchain node 411, 412, or 413, or a combination thereof. A client may be an instruction to perform an activity on blockchain 420 received from any source. In one example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, to propose a transaction to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 411, 412, and 413) may maintain a copy of the blockchain network state and distributed ledger 420. Different types of blockchain nodes / peers may exist within a blockchain network, including endorsing peers that simulate and approve transactions proposed by clients, and committing peers that verify the approvals, validate the transactions, and commit the transactions to distributed ledger 420. In this example, blockchain nodes 411, 412, and 413 may act as approver nodes, committer nodes, or both.

[0075] The distributed ledger 420 comprises a blockchain, which stores immutable, sequenced records in blocks, and a state database 424 (current world state) that maintains the current state of the blockchain 422. There may be one distributed ledger 420 per channel, and each peer maintains its own copy of the distributed ledger 420 for each channel in which it is a member. The blockchain 422 is a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. A block may comprise various components, such as those shown in FIG. 4B. Block linking (shown by arrows in FIG. 4A) may be generated by adding a hash of the previous block's header into the block header of the current block. In this way, all transactions on the blockchain 422 are sequenced and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of these links, the latest block in the blockchain 422 represents all transactions that came before it. The blockchain 422 may be stored on a peer file system (local or attached storage) that supports append-only blockchain workloads.

[0076] The current state of the blockchain 422 and distributed ledger 420 may be stored in a state database 424, where current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 422. Chaincode invocations execute transactions against the current state in the state database 424. To make these chaincode interactions highly efficient, the latest values ​​of all keys may be stored in the state database 424. The state database 424 may contain an indexed view into the blockchain 422 transaction log and therefore can be regenerated off-chain at any time. The state database 424 may be automatically recovered (or generated if necessary) upon peer startup, before any transactions are accepted.

[0077] The endorsing node receives transactions from clients and approves the transactions based on the simulated results. The endorsing node holds smart contracts that simulate transaction proposals. When the endorsing node approves a transaction, it generates a transaction approval, which is a signed response from the endorsing node to the client application indicating approval of the simulated transaction. The manner in which a transaction is approved depends on an endorsement policy, which may be specified in the chaincode. An example of an endorsement policy is "a majority of the endorsing peers must approve the transaction." Different channels may have different endorsement policies. The approved transaction is forwarded by the client application to the ordering service 410.

[0078] The ordering service 410 accepts approved transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 410 may start a new block when a transaction threshold is reached, a timer times out, or another condition occurs. In the example of FIG. 4A, blockchain node 412 is a committing peer that receives a new data block 430 of new data to be stored in the blockchain 420. The first block in a blockchain may be referred to as a genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

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

[0080] Transactions are written to the distributed ledger 420 in a consistent order. The order of transactions is established to ensure that updates to the state database 424 are valid when they are committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering is achieved by solving cryptographic puzzles or by mining, in this example, the parties to the distributed ledger 420 may choose the ordering mechanism that best suits their network.

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

[0082] Referring to FIG. 4B , a new data block 430 (also referred to as a data block) stored on the blockchain 422 of the distributed ledger 420 may include multiple data segments, such as a block header 440, block data 450, and block metadata 460. It should be understood that the various illustrated blocks and their contents, such as the new data block 430 and its contents, are merely exemplary and are not intended to limit the scope of the illustrative embodiments. The new data block 430 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) in the block data 450. The new data block 430 may also include a link to a previous block (e.g., on the blockchain 422 of FIG. 4A ) in the block header 440. In particular, the block header 440 may include a hash of the header of the previous block. The block header 440 may also include a unique block number, a hash of the block data 450 of the new data block 430, and the like. The block numbers of the new data block 430 are unique and may be assigned in various orders, such as incremental / sequential order starting from 0.

[0083] The block data 450 may store transaction information for each transaction recorded in the new data block 430. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, distributed ledger 420 channel ID, transaction ID, epoch, payload visibility, chaincode path (deploy tx), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identity such as public key and certificate, signature of the approver's client identity, approver signature, proposal hash, chaincode event, response status, namespace, read set (e.g., list of keys and versions read by the transaction), write set (e.g., list of keys and values), start key, end key, list of keys, Merkle tree query summary, and the like. Transaction data may be stored for each of the N transactions.

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

[0085] Block metadata 460 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature attached to the block creation, a reference to the last constituent block, a transaction filter identifying valid and invalid transactions in the block, the last persisted offset of the ordering service that ordered the block, and the like. The signature, last constituent block, and orderer metadata may be added by the ordering service 410. Alternatively, the block committer (e.g., blockchain node 412) may add validity / invalidity information based on an endorsement policy, verification of the read / write set, and the like. The transaction filter may include a byte array of size equal to the number of transactions in block data 450 and a validation code identifying whether the transaction was valid / invalid.

[0086] Figure 4C illustrates an embodiment of a blockchain 470 for digital content, according to embodiments described herein. 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 append-only aspects of blockchain serve as safeguards 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 situations where evidence is considered or the presentation and use of digital information is otherwise of interest. In this case, the digital content may be referred to as digital evidence.

[0087] A blockchain may be formed in a variety of ways. In some embodiments, digital content may be contained in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of reference information (e.g., headers, values, etc.) along with the associated digital content. The hash value and the associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a basis for referencing previous blocks. This may be shown as follows:

[0088] Block 1 Block 2 ....... Block N

[0089] Hash value 1 Hash value 2 Hash value N

[0090] Digital Content 1 Digital Content 2 Digital Content N

[0091] In some embodiments, the digital content may not be included in the blockchain. For example, the blockchain may store an encrypted hash of each block's content without any of the digital content. The digital content may be stored in a separate 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 it 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 it is stored in correspondence with the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows: Blockchain Storage Area Block 1 hash value Block 1 hash value ... Contents Block N hash value Block N hash value ... Contents

[0092] In the exemplary embodiment of FIG. 4C , blockchain 470 includes multiple blocks 4781, 4782...478N cryptographically linked in an ordered sequence, where N is 1. The cryptography used to link blocks 4781, 4782...478N may be any of a number of keyed or unkeyed hash functions. In some embodiments, blocks 4781, 4782...478N are subject to a hash function that generates an n-bit alphanumeric output (where n is 256 or another number) from input based on information in the blocks. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Danguard algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and non-collision-resistant PRF algorithms. In other embodiments, blocks 4781, 4782...478N may be cryptographically linked by a function different from the hash function. For illustrative purposes, the following description is provided with respect to a hash function, e.g., SHA-2.

[0093] Each of the blocks 4781, 4782...478N in the blockchain includes a header, a file version, and a value. The header and value are different for each block as a result of hashing in the blockchain. In some embodiments, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0094] The first block 4781 in a blockchain is called the genesis block and includes a header 4721, an original file 4741, and an initial value 4761. The hashing scheme used for the genesis block, and indeed all subsequent blocks, may be different. For example, all of the information in the first block 4781 may be hashed together at once, or each or a portion of the information in the first block 4781 may be hashed separately, followed by a hash of the separately hashed portions.

[0095] The header 4721 may include one or more initial parameters, such as a version number, a timestamp, a nonce, root information, difficulty, a consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 4741 and / or the blockchain. The header 4721 may be generated automatically (e.g., by a blockchain network that manages the software) or manually by a blockchain participant. Unlike the headers in other blocks 4782-478N in the blockchain, the header 4721 in the genesis block does not reference a previous block, simply because there is no previous block.

[0096] The original file 4741 in the genesis block may be, for example, data captured by a device, with or without processing before inclusion in the blockchain. The original file 4741 may be received from a device, media source, or node through an interface of the system. The original file 4741 may be associated with metadata, which may be generated, for example, manually or automatically, by a user, device, or system processor, or a combination thereof. The metadata may be included in the first block 4781 in association with the original file 4741.

[0097] Value 4761 in the genesis block is an initial value that is generated based on one or more unique attributes of original file 4741. In some embodiments, the one or more unique attributes may include a hash value for original file 4741, metadata for original file 4741, and other information associated with the file. In one implementation, initial value 4761 may be based on the following unique attributes: 1) A SHA-2 calculated hash value for the original file, 2) Originating Device ID, 3) the start timestamp for the original file, 4) the initial storage location of the original file; 5) The blockchain network member ID for the software that currently controls the original file and associated metadata.

[0098] The other blocks 4782-478N in the blockchain also have headers, files, and values. However, unlike the header 4721 of the first block, each of the headers 4722-478N in the other blocks includes a hash value of the immediately preceding block. The hash value of the immediately preceding block may simply be a hash of the header of the preceding block, or it 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, a block-by-block trace can be performed, as indicated by arrow 480, from the Nth block back to the genesis block (and associated original file) to establish an auditable and immutable evidence chain.

[0099] Additionally, each of the headers 4722-472N in the other blocks may include other information, such as a version number, a timestamp, a nonce, root information, difficulty level, a consensus protocol, and / or other parameters or information associated with the corresponding file and / or blockchain in general.

[0100] The files 4742-474N in other blocks may be identical to the original file or may be modified versions of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. Processing may involve any modification of the file in the preceding block, such as, for example, editing or otherwise changing the content of information, removing information, or adding or appending information to the file.

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

[0102] The value in each of the other blocks 4762-476N is unique and different as a result of the operations performed on it. For example, the value in any one block corresponds to an updated version of the value in the preceding block. The update is reflected in the hash of the block to which the value is assigned. Thus, the value of a block provides an indication of what operations were performed on the block and also allows tracing back through the blockchain to the original file. This tracking ensures the integrity of the file throughout the blockchain.

[0103] For example, consider the case where a portion of a file in a previous block has been redacted, blocked out, or pixelated to protect the identity of a person depicted in the file. In this case, the block containing the edited file may include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp, where the edit occurred, etc. The metadata may be hashed to form a value. Because the metadata for the block is different from the information hashed to form the value in the previous block, these values ​​may be different from each other and may be recovered when decrypted.

[0104] In some embodiments, the value of a previous block may be updated (e.g., a new hash value calculated) to form the value of a current block when any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information shown below: a) If the file has been processed in any way (e.g., if the file has been edited, copied, modified, accessed, or any other action taken), a new SHA-2 calculated hash value; b) a new storage location for the file; c) identified new metadata associated with the file; d) Transfer of access or control of a file from one blockchain participant to another.

[0105] 4D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 490, according to one embodiment. A block, or Block i, includes a header 472 i, a file 474 i, and a value 476 i.

[0106] Header 472i includes a hash value of the predecessor block Block i-1 and further reference information, which may be, for example, any type of information described herein (e.g., header information including references, properties, parameters, etc.). All blocks, except of course for the genesis block, reference the hash value of the predecessor block. The hash value of the predecessor block may simply be a hash of the header in the predecessor block, or a hash of all or part of the information in the predecessor block, including files and metadata.

[0107] File 474i includes multiple data items, such as Data 1, Data 2, ..., Data N, in sequence. The data items are tagged with Metadata 1, Metadata 2, ..., Metadata N, which describe the content and / or characteristics associated with the data. For example, the metadata for each data item may include a timestamp for the data, keywords indicating the data's process, people or other content depicted in the data, and / or other characteristics that may be useful in establishing the validity and content of the file as a whole, and information indicating its use, particularly, e.g., digital evidence, as described in connection with the embodiments described below. In addition to the metadata, each data item may be tagged with a reference REF1, REF2, ..., REFN to the preceding data item to prevent tampering, gaps within the file, and sequential references throughout the file.

[0108] Once metadata is assigned to data (e.g., through a smart contract), it cannot be changed without an easily identifiable hash change that invalidates it. Thus, the metadata creates a data log of information that can be accessed for use by participants in the blockchain.

[0109] Value 476i is a hash value or other value calculated based on any of the types of information described above. For example, for any given block Blocki, the value for that block may be updated to reflect operations performed on that block, such as a new hash value, a new storage location, new metadata for an associated file, a transfer of control or access, an identifier, or other operations or information added. Although the values ​​in each block are shown as being separate from the metadata and headers for the file's data, in other embodiments, the values ​​may be based in part or in whole on this metadata.

[0110] Once the blockchain 470 is formed, at any point in time, an immutable evidence chain for a file may be obtained by querying the blockchain for a value's transaction history across blocks. This query, or tracking procedure, may begin by decrypting the value of the most recently included block (e.g., the last (Nth) block), and then continuing 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 headers in each block as well as the file and associated metadata.

[0111] Decryption is performed based on the type of encryption performed on each block. This may involve the use of a private key, a public key, or a public and private key pair. For example, if asymmetric encryption is used, blockchain participants or processors in the network may use a predetermined algorithm to generate a public and private key pair. The public and private keys are related to each other through some mathematical relationship. The public key may be publicly distributed to serve as an address for receiving messages from other users, such as an IP address or 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 the message.

[0112] Generating a key pair may be similar to creating an account on the blockchain, but without actually registering anywhere. Also, every transaction performed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and transact on files on the blockchain (within the scope of their permissions as determined by the smart contract).

[0113] As explained in more detail herein, it is contemplated that some or all of the operations of some of the method embodiments described herein may be performed in an alternate order or not at all, and further, that multiple operations may occur simultaneously or as internal divisions of a larger process.

[0114] The present disclosure may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail integration. The computer program product may include computer-readable storage medium(s) having computer-readable program instructions that cause a processor to perform aspects of the present disclosure.

[0115] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium is not, per se, to be construed as a transitory signal such as an electric wave or other propagable electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0116] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0117] Computer-readable program instructions for carrying out the operations of the present disclosure may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, or the like, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuit to perform aspects of the present disclosure.

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

[0119] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to produce a machine, such that the instructions, when executed by the computer processor or other programmable data processing apparatus, generate means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0120] The computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

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

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

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

[0124] One or more programs / utilities 528, each having at least one set of program modules 530, may be stored in memory 504. The programs / utilities 528 may include a hypervisor (also referred to as a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may comprise an implementation of a network environment. The programs 528 or program modules 530, or a combination thereof, typically perform the functions or methods of the various embodiments.

[0125] 5 as a single bus structure providing a direct communication path between CPU 502, memory subsystem 504, and I / O bus interface 510, memory bus 503, in some embodiments, may include multiple different buses or communication paths that may be arranged in any of a variety of forms, such as hierarchical, star, or web configurations, multiple hierarchical buses, parallel redundant paths, or point-to-point links in any other suitable type of configuration. Additionally, while I / O bus interface 510 and I / O bus 508 are shown as single respective units, computer system 501, in some embodiments, may include multiple I / O bus interface units 510, multiple I / O buses 508, or both. Additionally, while multiple I / O interface units are shown isolating I / O bus 508 from the various communication paths to the various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

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

[0127] It should be noted that Figure 5 is intended to illustrate representative major components of an exemplary computer system 501. However, in some embodiments, individual components may have greater or less complexity than depicted in Figure 5, components other than or in addition to those shown in Figure 5 may be present, and the number, type, and configuration of such components may vary.

[0128] As explained in more detail herein, it is contemplated that some or all of the operations of some of the method embodiments described herein may be performed in an alternate order or not at all, and further, that multiple operations may occur simultaneously or as internal divisions of a larger process.

[0129] The present disclosure may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail integration. The computer program product may include computer-readable storage medium(s) having computer-readable program instructions that cause a processor to perform aspects of the present disclosure.

[0130] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium is not, per se, to be construed as a transitory signal such as an electric wave or other propagable electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0131] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0132] Computer-readable program instructions for carrying out operations of the present disclosure may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuit to perform aspects of the present disclosure.

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

[0134] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to produce a machine, such that the instructions, when executed by the computer processor or other programmable data processing apparatus, generate means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0135] The computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0136] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions shown in the blocks may be performed out of the order shown in the figures. For example, two blocks shown in succession may actually be implemented as a single step, or may be executed simultaneously, substantially simultaneously, partially, or fully overlapping in time, or the blocks may even be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0137] The description of various embodiments of the present disclosure is provided for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements over commercially available technologies, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0138] While the present disclosure has been described with reference to specific embodiments, it is anticipated that variations and modifications thereof will become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted to cover all such variations and modifications as fall within the true spirit and scope of the present disclosure.

[0139] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions shown in the blocks may be performed out of the order shown in the figures. For example, two blocks shown in succession may actually be implemented as a single step, or may be executed simultaneously, substantially simultaneously, partially, or fully overlapping in time, or the blocks may even be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0140] The description of various embodiments of the present disclosure is provided for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements over commercially available technologies, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0141] While the present disclosure has been described with reference to specific embodiments, it is anticipated that variations and modifications thereof will become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted to cover all such variations and modifications as fall within the true spirit and scope of the present disclosure.

[0142] Data compliance is a critical task in many industries, enabling the verification and enforcement of regulatory, contractual, business and other types of rules. For example, the transfer of digital or crypto assets between two parties (e.g., entities) may be governed by a smart contract, business rules coded within the smart contract, or chaincode, or a combination thereof. Blockchain processes (such as those handling smart contracts) may be used to ensure that all conditions are met when assets are transferred. Blockchain processes may also provide a governance layer to ensure that all compliance requirements are met and system obligations are fulfilled. However, data compliance can be a difficult task because developers responsible for creating systems may not have the knowledge base to define all of the rules associated with compliance. While the network itself is a digital network and transaction system, non-digital factors (such as business location, entity registration, and legal entity identifiers) play a crucial role in determining the rules and principles that may need to be met. It is a cumbersome task for each organization to ensure that it meets the due diligence requirements for each participant in the asset transfer and each financial regulator (e.g., governing entity). For example, for a trade of dairy futures between Company A and Company B, the Chicago Mercantile Exchange (CME) may be the transfer enforcement entity, and the Commodity Futures Trading Commission (CFTC, created by the Commodity Futures Trading Commission Act of 1974) may be the regulatory authority. In this example, the parties may be Company A and Company B, and both the CME and the CFTC may be financial regulators. In another example, with respect to a service level agreement (SLA) regarding smart contracts and performance metrics between cloud data service centers, one regulator may be a technical services expert, and the auditor may be a service technical services manager. Actual use cases may have various details that may be determined and configured by participants as described herein, in response to requests by participants, asset contracts, regulatory entities, or other sources.

[0143] Due diligence requirements may depend on existing legal principles and how legal, political, and commercial entities decide to treat technology. In some examples, a regulatory entity is a government or oversight entity with the authority to regulate, tax, or control certain activities, or a combination thereof.

[0144] In some examples, blockchain processes enable the execution of trusted transactions that are traceable and irreversible. For example, if transferring cryptocurrency from the United States to Germany through a Swiss bank requires payment of a fee to the Swiss government, a smart contract may be created that may not complete the final transfer until the fee is paid. In some embodiments, the execution of many types of real-world actions or transactions may involve the creation and completion of one or more blockchain processes. Further information on blockchain processes (e.g., smart contracts) can be found in FIG. 2A.

[0145] In some examples, compliance validation is an analytical method of examining and interrogating data to determine whether the data conforms to a specified set of conditions, referred to herein as rules. In some examples, compliance validation focuses on analyzing transactions rather than the state of the object. For example, with respect to the transfer of money, compliance validation may focus on how the money was transferred rather than where the money is after the transfer (e.g., focusing on the transaction that moves money into or out of an account rather than on the account balance itself).

[0146] In the context of blockchain, existing compliance verification methods focus on post-record analysis of data. For example, existing methods rely on retrospective verification of transactions recorded in the ledger with the aim of detecting non-compliant records. This is done as a reactive action to detect defects (e.g., when evidence of wrongdoing such as fraud is required).

[0147] The present disclosure provides a mechanism for compliance verification and enforcement prior to recording an operation (e.g., a transaction, a transaction proposal, a smart contract, or a process executed on or using a blockchain network, or a combination thereof) on the ledger. In some embodiments, the system may also provide a method for recording due diligence steps taken to comply with regulatory authority requirements involving transactions on an immutable blockchain ledger. Unlike existing compliance methods, compliance verification and enforcement prior to recording a transaction on the ledger allows for proactive data compliance enforcement and removal of non-compliant data, as opposed to retroactive compliance verification. By using a compliance module with a ledger-wide set of rules that are applied to all transactions, regardless of how many or what smart contracts are deployed on the ledger, the mechanism can be external to the smart contracts and therefore updated independently of the contracts while still recording compliance evidence on the ledger.

[0148] In some embodiments, the compliance mechanism may be distinguished from smart contract functionality (which may also validate data as part of the smart contract) in that the compliance mechanism uses a regulatory module and a set of dynamically configurable rules defined by an internal or external authority, or a combination thereof (e.g., a financial authority), to conform to compliance rules and regulations.

[0149] In some embodiments, the audit mechanism may be distinct from the functionality of a smart contract in that the audit mechanism (e.g., accounting mechanism) uses a set of audit modules and dynamically configurable rules defined by a designated auditor. In some embodiments, the designated auditor may be one or more peer nodes, an organization, or an external company, or a combination thereof. For example, an auditor may be a node within an organization (e.g., regulator 326) managed by the audit department. In some embodiments, an auditor may be typically limited to querying the network but may be authorized to modify audit modules. In some embodiments, an auditor may be given access to a regulator module, and a financial authority may be given access to an audit module. For example, the regulator module and the audit module may need to work interconnected, require similar information, or use similar processes, or both. Thus, an audit module may access a regulator module, which may access an audit module during execution (e.g., when used by a smart contract process).

[0150] In some embodiments, methods and systems are provided for storing compliance data or audit data, or a combination thereof, on a blockchain network. In some embodiments, methods and systems are provided for verifying that data stored in a ledger conforms to a set of compliance rules defined by an external authority, an internal authority, or a combination thereof. In some embodiments, the audit may be of the financial and operational structure of a business or transaction, and may include bank statement records, bank account records including bank statement records, copies of deposit slips, debit / credit memos, and bank reconciliations, investment and all other asset records including fixed asset inventories, receipt records including copies of receipts, income books, and individual membership records (member ledger cards), expense records, canceled checks, check stubs, expense books, payroll books, vouchers, expense receipts, invoices, credit card statements, and other supporting documentation, an audit report for the audit period, if any, prepared by the association auditor or an accountant employed by the association, minutes of executive committee and membership meetings, copies of the current constitution and bylaws and any financial policy documents, and other business data.

[0151] In some embodiments, a system (e.g., computer system 501) may provide compliance validation and enforcement of regulatory, contractual, business, and other types of rules and laws. In some embodiments, one or more network peers (e.g., peers 281-283) may host a compliance validation or audit validation component, or a combination thereof, that examines transactions and runs modules (e.g., program module 530) to validate rules after the transaction is generated but before it is accepted / approved.

[0152] In some embodiments, if the system determines that all of the rules are met, the transaction is allowed. In some embodiments, if the system determines that all of the rules are not met, the transaction may be rejected or marked as non-compliant, and further notification (e.g., an event, etc.) may be sent to the client.

[0153] In some embodiments, the method uses a set of pluggable modules (e.g., program modules 530) to define compliance and audit policies for a given transaction. In some embodiments, modules can be dynamically added or removed and configured. For example, the modules may be organized in an Open Services Gateway Initiative (OSGI style).

[0154] In some embodiments, each module implements a set of rules, where the rules may evolve and update with the network, regulations, business agreements, etc. As an example, cryptocurrency asset transfers within the United States may have specific rules and regulations set forth by the U.S. Securities and Exchange Commission (SEC). At the federal level, the SEC typically has regulatory authority over the issuance or resale of any tokens or other digital assets that constitute a security. Thus, the SEC may create a compliance module with rules for trading cryptocurrencies.

[0155] In some embodiments, a module or rule may apply to a particular asset type (or multiple asset types), commodity, service, or other subject of a blockchain transaction. In some embodiments, multiple authorized authorities can add and modify compliance module configurations and rules. Continuing the example from above, a trade exchanging dairy futures for cryptocurrency may involve modules from the SEC, CME, and CFTC. A single operation (e.g., transaction) may require multiple regulator modules or multiple auditor modules, or a combination thereof.

[0156] In some embodiments, network members (e.g., peers or organizations) agree on a set of authorities that define acceptance-specific rules (e.g., in the form of access controls) from authorized authorities that accept policies (or portions of policies). For example, members may agree on which authorities can define which types of rules and which rules are applicable to which types of transactions. The blockchain network may determine which regulator (e.g., the SEC) defines a set of requirements (e.g., a compliance module) for financial transactions (e.g., a 10k threshold for tax approval) and which auditor defines a set of rules (e.g., an audit module for tax compliance). In some embodiments, an external authority may provide modules that can be accepted by the blockchain network. In some embodiments, the network may receive a set of rules and form the rules into modules. For example, the network may receive a list of rules from an authority and execute the rules through a rule-module process. In some embodiments, the network may modify the received modules to function on the blockchain network. For example, a received module may require conversion from one programming language to another to work with all smart contracts. In some embodiments, nodes in the network may store the module to perform operations. For example, the module may be stored in distributed file storage 150 or on one or more nodes (e.g., nodes 102 and 105). Other storage methods may be used.

[0157] In some embodiments, the modules may include validation logic and rules that define which actions (e.g., financial compliance and audit actions) need to be performed and how to verify that the actions have been performed. In some embodiments, one or more blockchain nodes may verify that the appropriate compliance and audit modules have been invoked. As described herein, a smart contract is a digital contract that may have one or more specific requirements for completion of the smart contract. In some examples, a smart contract may be a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or execution of a contract. While smart contracts are used for illustrative purposes, other types of blockchain processes may also be used.

[0158] In some embodiments, a compliance policy defines a set of modules and rules used to evaluate data and transactions for compliance. In some embodiments, after a compliance policy is enforced, the verified results may be recorded in a ledger.

[0159] 6, a flowchart of an example method 600 for accepting a compliance module into a blockchain network is shown, according to an embodiment of the present disclosure. In some embodiments, method 600 may be performed by a processor on or in communication with the blockchain network (e.g., processor 502 connected to the various components of FIG. 5).

[0160] In some embodiments, method 600 begins with operation 602 of agreeing on an authority for which components of the network will be used. In some embodiments, the authority may be a controlling or regulatory body, a node responsible for compliance, or another entity that provides or modifies compliance modules (e.g., modules containing compliance rules). The authority may be defined by an authorization mechanism. One authorization mechanism may be an access control list, although those skilled in the art will recognize that other authorization mechanisms are possible. Similarly, in some embodiments, the network may agree on an auditor that has authorization to provide or modify one or more audit modules (e.g., modules containing audit rules). In some embodiments, authorization may be granted in conjunction with an authorization mechanism, as described above. In some embodiments, authorization may be specific to the system, a designated node, or a regulator (e.g., regulator 326).

[0161] In some embodiments, agreements to one or more authorities may be recorded as an access control list. In some embodiments, the access control list may be recorded on a blockchain ledger. In some embodiments, a threshold authority agreement metric may be used to define the access control list. For example, some networks may require that 100% of nodes or organizations agree to an authority, a majority of nodes agree to an authority, or one or more control nodes must agree to an authority. In some embodiments, each node or organization may maintain an access control list. For example, a node must agree to an authority before it can accept a compliance module from the authority. Other methods of generating and maintaining control lists will be apparent to those skilled in the art.

[0162] In some embodiments, the network operator, e.g., a node or organization, may decide to change authorities and / or which authorities may have revoked their privileges. For example, if an organization operates in a new country, the network may grant authorities in the new country and revoke authorities in the old country.

[0163] In some embodiments, method 600 continues with operation 604, in which the financial regulator defines a compliance module. In some embodiments, the compliance module may be a single module, multiple modules, or multiple interconnected modules. For example, each law may have a separate module, and multiple modules may be required to comply with the agency's requirements. In another example, each agency may have a single module that contains all compliance requirements necessary for the agency. Other module configurations are possible.

[0164] In some embodiments, method 600 continues with operation 606, in which an auditor defines an audit module. In some embodiments, a single auditor may define a single audit module or modules, or multiple auditors may define a single module or modules. For example, an external auditing firm may provide a tax module, and an internal audit department may provide a general bookkeeping module.

[0165] In some embodiments, method 600 continues with operation 608, in which the network accepts the modules. In some embodiments, the network may accept or reject each module independently. In some embodiments, a scheme for accepting modules may exist. For example, a certain percentage of nodes may be required to agree on a module before it can be accepted.

[0166] In some embodiments, participants in the network may be given the opportunity to accept or reject each module that may be submitted. For example, participants may decide whether they want to apply a particular compliance or accounting module. Some examples may have multiple compliance requirements or accounting options available. For example, there may be an accounting module for cryptocurrency taxes and a module for stock trading taxes.

[0167] 7, a flowchart of an example method 700 for applying compliance and audit modules to blockchain operations is shown, according to an embodiment of the present disclosure. In some embodiments, method 700 is performed by a processor on or in communication with a blockchain network.

[0168] In some embodiments, method 700 begins with operation 708, where an operation is initiated. In some embodiments, the initiation of an operation may be the initiation of a smart contract, the initiation or submission of a transaction, the generation or submission of a transaction proposal, etc. In some embodiments, the initiation includes a client invoking a smart contract and a peer generating an operation proposal (e.g., a transaction proposal). For example, the operation proposal may identify which actions or changes the smart contract may perform. In some embodiments, rules or modules within a module may be matched to blockchain operations (e.g., transactions) and data based on specific conditions, such as the type of asset, the type of transaction, and the submitter of the transaction. In some embodiments, the system may identify the type of asset and select one or more modules for the selected asset type. For example, the system may utilize a schema or type identification pattern, such as a regular expression (regex). In some embodiments, the system may identify the type of transaction and match it to a particular module. The type of transaction may be identified in transaction metadata / attributes (function, chaincode, etc.). For example, a dairy trade may require invoking modules for the Chicago Mercantile Exchange and the Commodity Futures Trading Commission. Also, in some embodiments, modules / rules may be selectively applied based on the identity of the transaction submitter. For example, a client dealing in cryptocurrency trades may require invoking a module from the U.S. Securities and Exchange Commission.

[0169] In some embodiments, initiation may come from one or more parties participating in the request, or may come from a third party (e.g., a mediator in a settlement agreement or a broker in a real estate transaction). For example, Company A may be using Mediator M to handle asset transfer agreements / particulars, and Mediator M may generate the operation.

[0170] In some embodiments, the initiation may include information about the operation, such as a list of terms in the agreement regarding the asset transfer, a list of agents (e.g., banks, brokers, companies, mediation organizations, representatives, etc.) who may represent either party to the transfer, a list of organizations or agents (e.g., banks, brokers, companies, mediation organizations, representatives, etc.) who may facilitate the transfer of digital assets, the location or jurisdiction of the agents, the type of assets to be transferred, and other information regarding the transfer. For example, a digital asset transfer request may include information such as the location of Company A, the location of Company B, the location of mediator M, and business details such as Company A may transfer, for example, 100 Exempt Gratiados (a fictitious cryptocurrency) to Company B through a bank. In some embodiments, the request may include the data or the location of the data in distributed file storage. In some embodiments, some or all of the data may be included in digital constructs (e.g., digital contracts) on various blockchain networks. For example, in a simple two-party agreement, each party may create a digital contract, where each contract includes agreed-upon terms that are important to the drafting party. Other possible ways of initiating the operation are contemplated. Once the operation has been initiated, the method may continue with operation 710.

[0171] In some embodiments, method 700 continues with operation 710, in which the peer verifies compliance of the operation based on one or more modules. In some embodiments, when evaluating the operation, the validation component may determine whether the module / rule is the correct module / rule for the operation, determine whether the correct rules are included in the module, or validate that the module works with all nodes for the operation (e.g., transaction or smart contract), or a combination thereof. For example, for a financial transaction, both state and federal modules may need to be selected. If only the federal module is selected, the peer may either reject the operation or obtain the appropriate state module. In some embodiments, validation may include determining whether all nodes are capable of executing the smart contract using those modules. In some embodiments, the smart contract may have a validation component, or the network may have a validation component to comply with the system. In some embodiments, validation may be performed based on the contents of the module. For example, the module may include one or more validation steps / rules.

[0172] In some embodiments, a peer may verify that the appropriate module is selected for each operation. For example, nodes with different requirements or qualifications may be required to validate that the appropriate module / rules are invoked. In some embodiments, a peer may verify that modules work properly with each other and with the smart contract. For example, if a compliance module requires that taxes be prepared prior to a transaction, but the audit module does not, the modules may be incompatible. In another example, if a compliance module requires that both state and federal taxes be deducted from a financial transaction, but only the audit module has rules for the federal module, the peer may reject the transaction and send a notification to the client.

[0173] In some embodiments, a peer may generate a compliance statement or attestation based on the validation of the operation. The compliance statement may reference each module that was validated against the operation, or against each rule in the operation proposal, or a combination thereof. For example, if the operation proposal was validated with a module from the SEC, the compliance statement or attestation may reference the SEC module. In some embodiments, the compliance statement may also include a statement about how the requirements of each rule were met. For example, if the operation proposal was validated with a module from the SEC, the compliance statement or attestation may list how each rule in the SEC module was met. In some embodiments, these compliance statements or attestations may be available for review by authorities on a ledger, as described in operation 712.

[0174] In some embodiments, method 700 continues with operation 712, in which the verified operation may be processed in accordance with the procedures of the blockchain network, or a formal proof of compliance may be recorded on the ledger, or a combination thereof.

[0175] In some embodiments, a transaction may require a formal compliance statement or proof of compliance. In some examples, the proof may be constructed as a statement by an approver (e.g., an expression of a set of verified rules), where the statement includes validation of one or more types of data in the context of the transaction. For example, the data may include the transaction's output data (e.g., a write set), the values ​​of any of the arguments used to invoke the transaction creation, or data that may not be explicitly intended to be recorded in the transaction but may be required to establish content validity or compliance with a rule or law, or a combination thereof. For example, a transaction may include a hash of a document. To confirm the validity of a document, compliance requires a reviewer to "see" the document and calculate the hash to verify the validity of the hash and therefore the validity of the document.

[0176] In some embodiments, the proof may include documentation that the validation component (e.g., the system chaincode) was invoked along with all available data relevant to the validation (e.g., how each rule was met).

[0177] In some embodiments, a validation component may be invoked in each or each compliance module, and attestation may be provided for each or each individual module. In some embodiments, a or each module may act as a validation component, executing a set of pre-configured rules in the context of the transaction being processed.

[0178] In some embodiments, the statement may be included in the transaction header as proof of validation. In some embodiments, the statement may be used to provide proof that a compliance policy was applied / evaluated. Also, in some embodiments, the proof may demonstrate that all peers recognized the proof, since proofs between various peers must agree before the proof can be applied to the blockchain network. The proof may then be used by an auditor to check whether and which rules were applied.

[0179] 8, a flowchart of an example method 800 illustrating module inception, selection, and processing is shown, according to an embodiment of the present disclosure. In some embodiments, method 800 is performed by a processor on or in communication with a blockchain network.

[0180] In some embodiments, method 800 begins with operation 812, where it is determined that a module is required. In some embodiments, the operation may include an indication that a regulatory or audit requirement exists. For example, the transaction may indicate that a particular module or code may need to be referenced. In some embodiments, the validation process (e.g., operation 710) may include one or more checks for a module (e.g., a regulatory module or an audit module). For example, the system may perform a check each time a financial transaction occurs to determine whether a module exists or should exist. In some embodiments, the validation may determine jurisdictional requirements for all operations. For example, the system may attempt to determine whether a code exists for each location where part of the operation occurs. In some embodiments, the system may require that a module be applied for all transactions. For example, a blockchain network that processes cryptocurrency transactions for U.S.-based companies may always require that a module from the U.S. Securities and Exchange Commission be invoked.

[0181] In some embodiments, method 800 continues with operation 814, where a module is selected. In some embodiments, the operation or system instructions may include a direct indication of which module to use. For example, a cryptographic operation may include an instruction to invoke U.S. Securities and Exchange Commission module 405B (a fictitious example). In some embodiments, the system may use an identification process to determine the appropriate module. For example, the system may search all jurisdictions for the transaction and pull in modules for any jurisdictions.

[0182] In some embodiments, method 800 continues with operation 814, where a model is applied. In some embodiments, the application is similar to operations 710 and 712. In some embodiments, a particular module may be applied to a particular portion of an operation. For example, a compliance module may be applied to a method of a financial transaction, and an audit module may be applied to a tax section of a financial transaction. In another example, a U.S. compliance module may be applied to the U.S. portion of a transaction, and a Swedish compliance module may be applied to the Swedish portion of the transaction. According to this specification, the following items are also disclosed. [Item 1] agreeing on the authority by the nodes in the blockchain network; receiving, by said node, a compliance module from said authority; accepting, by the node, the compliance module; storing, by the node, the compliance module for performing operations; A method comprising: [Item 2] receiving the operation; verifying compliance of the operation based on the compliance module; adding the verified operation to a ledger on the blockchain network; The method of claim 1 further comprising: [Item 3] determining compliance information based on said verification; recording compliance information on said ledger; The method of claim 2 further comprising: [Item 4] receiving, by said node, an audit module from an auditor; receiving, by the node, the audit module; The method of any one of claims 1 to 3, further comprising: [Item 5] receiving the operation; verifying compliance of the operation based on the compliance module and the audit module; submitting the verified operation to be added to a ledger on the blockchain network; The method of claim 4 further comprising: [Item 6] determining audit information based on said verification; submitting audit information to be recorded on said ledger; The method of claim 5 further comprising: [Item 7] determining the capability of all nodes in the blockchain network to process the operation using the compliance module and the audit module; The method of claim 6 further comprising: [Item 8] Memory and a processor in communication with the memory, The process of agreeing on authorities for the blockchain network; receiving a compliance module from the authority; a process for accepting the compliance module; a process for storing said compliance module for execution of an operation; a processor configured to execute a process including: A system comprising: [Item 9] The process comprises: a process for receiving the operation; a process for verifying compliance of the operation based on the compliance module; adding the verified operation to a ledger on the blockchain network; The system of claim 8 further comprising: [Item 10] The process comprises: determining compliance information based on said verification; a process for recording compliance information on said ledger; The system of claim 9 further comprising: [Item 11] The process comprises: a process for receiving an audit module from an auditor; A process for accepting audit modules; 11. The system of claim 8, further comprising: [Item 12] The process comprises: a process for receiving the operation; a process for verifying compliance of the operation based on the compliance module and the audit module; a process for submitting the validated operation to be added to a ledger; The system of claim 11 further comprising: [Item 13] The process comprises: determining audit information based on said verification; a process of submitting the audit information to be recorded on the ledger on the blockchain network; The system of claim 12 further comprising: [Item 14] The process comprises: a process of determining the capability of all nodes in the blockchain network to process the operation using the compliance module and the audit module; The system of claim 13 further comprising: [Item 15] The processor A procedure for agreeing on authorities for the blockchain network; receiving a compliance module from the authority; receiving the compliance module; storing the compliance module for execution of an operation; A computer program for executing [Item 16] the processor, receiving the operation; verifying compliance of the operation based on the compliance module; adding the verified operation to a ledger on the blockchain network; 16. The computer program of claim 15, further comprising: [Item 17] the processor, determining compliance information based on said verification; recording compliance information on said ledger; 17. The computer program of claim 16, further comprising: [Item 18] the processor, receiving an audit module from an auditor; accepting the audit module; 18. The computer program of claim 15, further comprising: [Item 19] the processor, receiving the operation; verifying compliance of the operation based on the compliance module and the audit module; submitting the validated operation to be added to a ledger on the blockchain network; 20. The computer program of claim 18, further comprising: [Item 20] the processor, determining audit information based on said verification; submitting said audit information to be recorded on said ledger; 20. The computer program of claim 19, further comprising:

Claims

1. Agreeing to accept the compliance module with the authorities by the nodes in the blockchain network; receiving, by the node, the compliance module from the authority; accepting, by the node, the compliance module; receiving, by said node, an audit module from an auditor; receiving, by the node, the audit module; receiving, by the node, an operation; storing, by the node, the compliance module for performing the operation; verifying, by the node, compliance of the operation based on the compliance module and the audit module; adding, by the node, the verified operation to a ledger on the blockchain network; A method comprising:

2. verifying, by the node, the compliance of the operation with the compliance module by computing a second hash of the document; comparing, by the node, the second hash of the document to a first hash of the document stored on the blockchain network; The method of claim 1 further comprising:

3. determining, by the node, compliance information based on the validation; recording, by the node, compliance information on the ledger; The method of claim 1 or 2, further comprising:

4. determining, by the node, audit information based on the verification; submitting audit information by the node to be recorded on the ledger; The method of claim 1 , further comprising:

5. determining, by the node, whether all nodes in the blockchain network are capable of performing the operation using the compliance module and the audit module to process the operation using the compliance module and the audit module; The method of claim 4 further comprising:

6. Memory and a processor in communication with the memory, The process of agreeing to accept compliance modules with authorities for blockchain networks; receiving the compliance module from the authority; a process for accepting the compliance module; a process for receiving an audit module from an auditor; a process for receiving the audit module; a process for receiving an operation; a process for storing the compliance module for execution of the operation; a process for verifying compliance of the operation based on the compliance module and the audit module; adding the verified operation to a ledger on the blockchain network; a processor configured to execute a process including: A system comprising:

7. verifying the compliance of the operation with the compliance module by computing a second hash of the document; comparing the second hash of the document to a first hash of the document stored on the blockchain network; The system of claim 6 further comprising:

8. The process comprises: determining compliance information based on said verification; a process for recording compliance information on said ledger; The system of claim 6 or 7, further comprising:

9. The process comprises: determining audit information based on said verification; a process of submitting the audit information to be recorded on the ledger on the blockchain network; The system of claim 6 , further comprising:

10. The process comprises: a process for determining whether all nodes in the blockchain network are capable of performing the operation using the compliance module and the audit module to process the operation using the compliance module and the audit module; The system of claim 9 further comprising:

11. The processor A procedure for agreeing to accept the compliance module with the authorities for the blockchain network; receiving the compliance module from the authority; receiving the compliance module; receiving an audit module from an auditor; accepting the audit module; receiving an operation; storing the compliance module for execution of the operation; verifying compliance of the operation based on the compliance module and the audit module; adding the verified operation to a ledger on the blockchain network; A computer program for executing

12. verifying the compliance of the operation with the compliance module by computing a second hash of the document; comparing the second hash of the document to a first hash of the document stored on the blockchain network; The computer program of claim 11 , further comprising:

13. the processor, determining compliance information based on said verification; recording compliance information on said ledger; 13. The computer program according to claim 11 or 12, further comprising:

14. the processor, determining audit information based on said verification; submitting said audit information to be recorded on said ledger; 14. The computer program of claim 11, further comprising:

Images