Editable Blockchain

Abstract

In some embodiments, the processor may store a value and a hash of the value in a ledger associated with a blockchain network. The processor may construct a block hash from the hash of the value. The processor may validate a transaction by identifying that the hash of the value matches the hash of the value from a previous transaction. The processor may maintain the integrity of the block hash. In some embodiments, the processor may provide an edit transaction to a blockchain network. The processor may initialize the edit transaction. The edit transaction may be associated with a validated transaction. The processor may identify a hash value indicated in the edit transaction and associated with the validated transaction. The processor may edit a value associated with the hash value.

Description

[Technical Field]

[0001] The present disclosure relates generally to the field of information privacy, and more particularly to redacting information from blockchain networks.

[0002] Currently, under the General Data Protection Regulation (GDPR), any individual can contact a business and request that their personal information be deleted from all business systems within a specific timeframe. However, many businesses currently utilize some form of blockchain network within their systems, and by their nature, blockchain networks utilize immutable ledgers that permanently record information. Accordingly, challenges arise when an individual wants their personal information redacted / erased from a business's systems.

[0003] Furthermore, there is currently no suitable means for editing information from a blockchain network without corrupting the blocks in which the information is stored. Traditionally, each block in a blockchain network contains the hash of the preceding block, thus linking the blocks together to create a chain. As a result, if the content / information of a block is changed, the hash of the block changes, and therefore there is no way to prove the validity of the block in the chain. As such, it is not possible to directly delete data from the ledger associated with the blockchain network, as this would affect the ability to chain the blocks together. As a result, there is a pressing need for a means for editing information from a blockchain network without compromising the ability to continue linking the blocks together and the ability to maintain the validity of the blocks with the edited content / information. Summary of the Invention

[0004] Embodiments of the present disclosure include methods, systems, and computer program products for compiling information from a blockchain network. A processor may store a value and a hash of the value in a ledger associated with the blockchain network. The processor may construct a block hash from the hash of the value. The processor may verify the validity of a transaction by identifying that the hash of the value matches the hash of the value from a previous transaction. The processor may maintain the integrity of the block hash.

[0005] In some embodiments, the processor may edit the value, wherein the editing of the value may include setting a bit associated with the value to zero.

[0006] In some embodiments, compiling the value further includes maintaining the hash of the value and the block hash.

[0007] In some embodiments, editing the value may further include the processor replacing the user's data with the hash of the value. The processor may maintain a separate pre-image of the value.

[0008] In some embodiments, the hash of the value points to the separate pre-image.

[0009] In some embodiments, the processor may keep the validated transaction without the value.

[0010] In some embodiments, the processor may receive the value, the processor may identify that the value is associated with user data, and the processor may generate the hash of the value.

[0011] Further embodiments of the present disclosure include methods and systems for editing information from a blockchain network. A processor may provide an edit transaction to the blockchain network. The processor may initialize the edit transaction. The edit transaction may be associated with a validated transaction. The processor may identify a hash value indicated in the edit transaction and associated with the validated transaction. The processor may edit a value associated with the hash value.

[0012] In some embodiments, the processor may generate a transaction envelope, which may include the hash value, which includes a pointer to a pre-image.

[0013] In some embodiments, the transaction envelope may further include the pre-image, and the pre-image may include the value.

[0014] In some embodiments, editing the value may include setting bits associated with the value to zero. Setting the bits associated with the value to zero may allow the hash value to remain the same.

[0015] In some embodiments, the processor may retain the validated transaction based on identifying the hash value as being the same after the edit transaction.

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

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

[0018] [Figure 1A] 1 illustrates an exemplary blockchain architecture according to an embodiment of the present disclosure.

[0019] [Figure 1B] 1 illustrates a blockchain transaction flow according to an embodiment of the present disclosure.

[0020] [Figure 2] 1 illustrates a conventional blockchain transitioning to an editable blockchain according to an embodiment of the present disclosure.

[0021] [Figure 3A] 1 illustrates the initiation of a conventional transaction according to an embodiment of the present disclosure.

[0022] [Figure 3B] 1 illustrates an updated traditional transaction start according to an embodiment of the present disclosure.

[0023] [Figure 4] 1 illustrates a transaction structure for allowing editing of information according to an embodiment of the present disclosure.

[0024] [Figure 5] 1 illustrates validation of a transaction by a subordinate peer according to an embodiment of the present disclosure.

[0025] [Figure 6A] 1 illustrates a flowchart of an exemplary method for maintaining block hash integrity in a blockchain network, according to an embodiment of the present disclosure.

[0026] [Figure 6B]1 illustrates a flowchart of an exemplary method for compiling information from a blockchain network, according to an embodiment of the present disclosure.

[0027] [Figure 7A] 1 illustrates a cloud computing environment according to an embodiment of the present disclosure.

[0028] [Figure 7B] 1 illustrates an abstraction model layer according to an embodiment of the present disclosure.

[0029] [Figure 8] 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.

[0030] While the embodiments described herein are susceptible to various modifications and alternative forms, specific details thereof have been 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 intent is to cover all modifications, equivalents, and alternatives within the spirit and scope of the disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0031] Aspects of the present disclosure relate generally to the field of information privacy, and more specifically to redacting information (e.g., user information, personal data, etc.) from blockchain networks. Many individuals prefer to have control over their information (e.g., personal, private, or otherwise), and with the advent of GDPR, individuals now have the right to be forgotten. Such a right allows individuals to contact a business (e.g., a company, enterprise, etc.) and request that their information be deleted from the business's systems within a specific timeframe. However, many businesses currently utilize some form of blockchain network within their systems, which by their nature utilize an immutable ledger that permanently records information. Accordingly, challenges arise when individuals wish to have their personal information redacted / erased from a business's systems.

[0032] Currently, there are no options for redacting information from a blockchain network. The closest alternatives are private data collection, encryption, and off-chain storage with on-chain hashing. However, each alternative does not actually redact information from the blockchain network, and each alternative has its own drawbacks. For example, private data collection relies on a time-based (e.g., block-deadline) block-to-live policy, incurs a performance penalty due to peers / nodes needing to extract private data upon commit, and must be designed upfront to avoid putting user data on-chain, since data cannot be removed once it is on the public chain. Furthermore, encryption alternatives require key management overhead, and forward secrecy is uncertain in the advent of quantum computing. Finally, off-chain storage with on-chain hashing poses challenges to data distribution, consistency, and availability when multiple administrative domains are involved. Overall, the key issue with each alternative is that they require add-ons that are not initially provided and therefore must be implemented each time a new blockchain is developed. However, what is disclosed herein is a unique embedded solution for a (permissioned) blockchain with an execution-command-validation architecture. Accordingly, there is a real need for the methods described herein of this disclosure that allow information (such as related to a particular user / individual) to be removed from the blockchain.

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

[0034] 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. Accordingly, the appearances of the phrases "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 depicted connection is represented by a one-way or two-way arrow. Also, any devices depicted in the figures may be different devices. For example, where a mobile device is shown transmitting information, a wired device may be used to transmit the information.

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

[0036] Detailed herein are methods, systems, and computer program products that utilize adapted transaction envelopes that allow for the compilation of information from a blockchain network.

[0037] In some embodiments, a method, system, or computer program product, or combination thereof, utilizes a distributed database (such as a blockchain), which is a decentralized storage system including multiple nodes communicating with each other. The decentralized database may include an append-only immutable data structure, similar to a distributed ledger, that can maintain records 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 a single peer cannot 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, if necessary, for consistency.

[0038] In various embodiments, permissioned or permissionless blockchains, or a combination thereof, can be used. In a public or permissionless blockchain, anyone can participate without a specific identity (e.g., 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 groups of entities that share a common purpose but do not fully trust each other, such as businesses exchanging funds, goods, (private) information, and the like.

[0039] Additionally, in some embodiments, a method, system, computer program product, or combination thereof may utilize a blockchain tailored to a decentralized storage scheme and running arbitrary programmable logic referred to as a "smart contract" or "chaincode." In some embodiments, a method, system, computer program product, or combination thereof may further utilize smart contracts, which are trusted, distributed applications that utilize the tamper-resistant properties of a blockchain database and underlying agreements between nodes referred to as authorizations or authorization policies. Blockchain transactions associated with the present application may be "endorsed" before being committed to the blockchain, with unendorsed transactions being ignored.

[0040] The endorsement policy allows the 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 verify the validity of the transaction. In some embodiments, the transaction is first simulated, e.g., endorsed to obtain agreement from peers to satisfy the endorsement policy. The transaction then enters an ordering phase, in which a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks. Furthermore, in some embodiments, after the transaction progresses to a block / blocks and reaches peers, the transaction is validated.

[0041] 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).

[0042] Another type of node is a peer node, which can receive client-submitted transactions, commit the transactions, and maintain a copy of the ledger state of the 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 modifications to the blockchain world state, also known as the initial blockchain transaction, which usually contains control and setup information.

[0043] In some embodiments, a method, system, or computer program product, or combination thereof, can utilize a ledger that is a sequenced, tamper-proof 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) can 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 includes a blockchain (also referred to as a chain) that is used to store immutable, sequenced records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0044] 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, with each block containing a sequence of N transactions, where N is equal to or greater than 1. A block header contains a hash of the block's transactions as well as the hash of the preceding block's header. In this way, all transactions on the ledger may be sequenced together and cryptographically linked. Accordingly, ledger data cannot be tampered with without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that came before it, thereby 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., locally, on attached storage, on the cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0045] 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.

[0046] Some advantages of the solutions described and depicted herein include methods, systems, and computer program products for redacting (personal) information from a blockchain network. Exemplary embodiments provide a solution for protecting information in a blockchain while maintaining the resilience of the chain (e.g., redacting information does not cause subsequent transactions to be invalidated).

[0047] It should be noted that a blockchain differs from a traditional database in that it does not have a central storage, but rather a decentralized, immutable, and secure storage, and nodes may share changes to records in the storage. Some properties inherent to blockchains 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 due to the accountability, security, privacy, permissioned decentralization, availability of smart contracts, authorization, and accessibility that are inherent and unique to blockchains.

[0048] In particular, blockchain ledger data is traditionally immutable, which provides an efficient way to identify inconsistencies within a blockchain network. The present disclosure provides methods, systems, and computer program products for mitigating inconsistencies that would result in the subsequent invalidation of transactions (e.g., data records). Additionally, the use of cryptography in blockchains provides security and builds trust. Smart contracts manage the state of assets and complete their lifecycles. An exemplary blockchain is permissioned and decentralized. As such, each end user may have their own copy of the ledger that they can access. Multiple organizations (and peers) may be onboarded onto the blockchain network. Key organizations may act as validating peers to verify the validity of smart contract execution results, read sets, and write sets.

[0049] One advantage of the exemplary embodiments is that they enhance the capabilities of a computing system by implementing a method for editing (personal / private / etc.) information from a blockchain network (e.g., by editing information from a pre-image in a transaction envelope). Through the blockchain system described herein, a computing system (or a processor within a computing system) can perform functions for editing operations using the blockchain network by providing access to capabilities such as distributed ledgers, peers, cryptography, MSPs, event processing, etc. Blockchains also enable the creation of business networks and the onboarding of any user or organization for participation. As such, blockchains are more than just databases. Blockchains have the ability to create a network of users and onboard / offboard organizations that collaborate to execute service processes in the form of smart contracts (which may be associated with the editing process, the specific information to be edited, or both).

[0050] Exemplary embodiments provide numerous advantages over traditional databases. For example, through blockchain, embodiments provide accountability, security, privacy, permissioned decentralization, availability of smart contracts, authorization, and accessibility that are inherent and unique to blockchain.

[0051] On the other hand, traditional databases cannot be used to implement exemplary embodiments because they do not bring all parties into the network, do not create trusted federations, and do not provide efficient storage of digital assets. Traditional databases do not provide tamper-proof storage or retention of stored digital assets. As such, the proposed embodiments described herein utilizing blockchain networks cannot be implemented with traditional databases.

[0052] On the other hand, if a conventional database were used to implement the exemplary embodiments, the exemplary embodiments would suffer from unnecessary drawbacks such as poor search performance (e.g., due to attempting to identify inconsistencies in the compiled information), lack of security, and slow transaction speeds. Accordingly, the exemplary embodiments provide specific solutions to problems in the technology / field of information compilation in blockchains.

[0053] Referring now to FIG. 1A, a blockchain architecture 100 according to an embodiment of the present disclosure is illustrated. In some embodiments, the blockchain architecture 100 may include a particular blockchain element, such as a group of blockchain nodes 102. The blockchain nodes 102 may include one or more blockchain nodes, such as peers 104-110 (these four nodes are depicted for illustrative purposes only). These nodes participate in many activities, such as adding and validating blockchain transactions (consensus). One or more of the peers 104-110 may approve and / or recommend transactions based on approval policies and may provide an ordering service for all blockchain nodes 102 in the blockchain architecture 100. Blockchain nodes may initiate blockchain validations and attempt writes to the blockchain immutable ledger stored in the blockchain layer 116, a copy of which may also be stored on the underlying physical infrastructure 114. A blockchain configuration may include one or more applications 124 linked to an application programming interface (API) 122 for accessing and executing stored program / application code 120 (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 as transactions and installed on all blockchain nodes 104-110 via appends to the distributed ledger.

[0054] The blockchain base or platform 112 may include 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 116 may present an interface that provides access to the virtual execution environment necessary to process program code and interact with the physical infrastructure 114. The cryptographic trust services 118 may be used to verify transactions, such as asset exchange transactions, and keep information private.

[0055] The blockchain architecture 100 of FIG. 1A may process and execute program / application code 120 through one or more interfaces exposed and services provided by the blockchain platform 112. The application code 120 may control blockchain assets. For example, the application code 120 may store and transfer data and be executed by peers 104-110 in the form of smart contracts and associated chaincodes having conditions or other code elements that are subject to execution. As a non-limiting example, smart contracts may be created to perform resource transfers, resource creation, etc. Smart contracts may themselves be used to identify rules associated with authentication, access requirements (e.g., data stores, off-chain data stores, pre-image databases, etc.), ledger usage, or a combination thereof. For example, pre-image information 126 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. The results 128 may include multiple linked shared documents (e.g., each linked shared document recording the issuance of a smart contract for pre-image information 126 identified as either an accepted or rejected validity verification, etc.). In some embodiments, the physical infrastructure 114 may be utilized to obtain any of the data or information described herein.

[0056] Smart contracts may be created via high-level applications and programming languages ​​and then written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, replicated, or a combination thereof with the blockchain (e.g., a decentralized network of blockchain peers). A transaction is the execution of smart contract code that may be executed in response to a condition 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 caused by the execution of a smart contract may be automatically replicated across the decentralized network of blockchain peers through one or more consensus protocols.

[0057] 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.

[0058] Chaincode may include a code interpretation of a smart contract, with additional features. As described herein, chaincode may be program code deployed on a computation network that is executed and validated by chain validators 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 authentication key for the requested service. The chaincode may be written to the blockchain data associated with cryptographic details (e.g., to verify contributions, identify mismatches with contributions, etc.).

[0059] FIG. 1B illustrates an example of a blockchain transaction flow 150 between nodes of the blockchain, according to an example embodiment. Referring to FIG. 1B, the transaction flow may include a transaction proposal 191 sent by an application client node 160 to an endorsing peer node 181 (e.g., in some embodiments, the transaction proposal 191 may be a request including an identifier associated with an off-chain data store / database). The endorsing peer 181 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). A proposal response 192, if approved, is sent back to the client 160 along with the endorsing signature. The client 160 assembles the endorsing into a transaction payload 193 and broadcasts it to the ordering service node 184. The ordering service node 184 then distributes the ordered transactions as a block to all peers 181-183 on the channel. Before committing to the blockchain, each peer 181-183 may verify the validity of the transaction. For example, a peer may check an endorsement policy to ensure that the correct allocation of the specified peers has signed the result and authenticated the signature on the transaction payload 193 (e.g., all or a threshold number of peers may verify that the request includes a symmetric key, an identifier, or both, that allows locating a data store connection object, accessing an off-chain database, or both).

[0060] Referring again to FIG. 1B , a client node 160 initiates a transaction 191 by constructing and sending a request to a peer node 181 that is an approver. The client 160 may include an application using a supported software development kit (SDK) that utilizes available APIs to generate a transaction proposal 191. The proposal is a request that invokes chaincode functions to read and / or write data to the ledger (e.g., write a new key-value pair for an asset). The SDK may reduce the transaction proposal 191 package to a properly structured format (e.g., protocol buffers over remote procedure calls (RPCs)), obtain the client's cryptographic credentials, and generate a unique signature for the transaction proposal 191.

[0061] In response, the endorsing peer node 181 may verify that (a) the transaction proposal 191 is well-formed, (b) the transaction has not already been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example, client 160) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 181 may obtain the transaction proposal 191 input as an argument to a called chaincode function. The chaincode then runs against the current state database and generates 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 time. In some embodiments, the set of values, along with the endorsing peer node 181's signature, is returned as a proposal response 192 to the client 160's SDK, which parses the payload for the application to consume.

[0062] In response, the application on the client 160 inspects / verifies the endorsing peer signatures and compares the proposed responses to determine whether they are the same. If the chaincode only queries the ledger, the application inspects the query response and typically does not submit the transaction to the ordering service node 184. If the client application intends to submit a transaction to the ordering service node 184 to update the ledger, the application determines whether the specified endorsing policy is satisfied (e.g., has an accepted request) before submitting. Here, the client may include only one of multiple parties to a transaction. In this case, each client may have its own endorsing node, and each endorsing node will need to approve the transaction. The architecture ensures that even if the application chooses not to inspect the response or otherwise chooses to forward the unendorsed transaction, the endorsing policy is still enforced by the peers and is enforced during the validation phase of commit validity.

[0063] After successful validation, in the transaction payload stage 193, the client 160 assembles the authorizations into a transaction and broadcasts the transaction proposal 191 and the response in a transaction message to the ordering node 184. The transaction may include a read / write set, an approving peer signature, and a channel ID. The ordering node 184 does not need to validate the entire contents of the transaction to perform its operations; instead, the ordering node 184 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions per channel.

[0064] A block of transactions is distributed from the ordering node 184 to all peer nodes 181-183 on the channel. The transactions 194 in the block are validated to ensure that any endorsement policies are met and that no changes have been made 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 step 195, each peer node 181-183 appends the block to the channel's chain, and for each valid transaction, the writeset is committed to the current state database. Events are emitted to notify the client application that the transaction (invocation) has been immutably appended to the chain and whether the transaction was validated or invalidated (e.g., whether a request to access an off-chain data store was allowed or denied).

[0065] Referring now to FIG. 2, a traditional blockchain 202A is shown being transitioned to an editable blockchain 202B in accordance with an embodiment of the present disclosure. Note that like reference numbers are used to designate like parts in the accompanying drawings. As depicted, the traditional blockchain 202A includes a block hash 204, which is a hash of a block header and acts as a reference number for a block (not shown) in the traditional blockchain 202A. The block hash 204 is traditionally associated with (e.g., references, points to, etc.) a first value 206, a second value 208, or both. In some embodiments, the first value 206, the second value 208, or both may be values ​​associated with a transaction involving the information. In such instances, the information is immutably stored in the traditional blockchain 202A.

[0066] To allow editing of the first value 206, the second value 208, or both, the present disclosure provides that the traditional blockchain 202A is transitioned to an editable blockchain 202B by hashing the first value 206, the second value 208, or both. Hashing the first value 206, the second value 208, or both, respectively, generates a first hash 210, a second hash 212, or both, which are then associated with the block hash 204. In such instances, as described more fully below, in the traditional blockchain 204, the first hash 210, the second hash 212, or both, are essentially the first value 206 and the second value 208, and remain unchanged, so that the first value 206, the second value 208, or both, can be edited without invalidating the block hash 204 or the block referenced by the block hash 204. Note that the traditional blockchain 202A and the editable blockchain 202B are the same blockchain, but with structural modifications.

[0067] Referring now to FIG. 3A , a conventional transaction initiation 300A is shown, according to an embodiment of the present disclosure. As depicted, transaction 300A includes an envelope 302 that includes a payload 304 and a signature 314 that spans payload 304. Payload 304 includes a header 306 that includes destination information (e.g., identifying where the transaction assets should be sent). Payload 304 further includes a transaction 308 that includes actions 310. Transaction actions 310 include instructions depicted as transaction actions 312, although it should be noted that more than one instruction in transaction 308 may be included (e.g., retrieve information from database x and store information in database y). Transaction actions 312 may store information / data associated with a user, include a block hash 204 as depicted in FIG. 2, or both.

[0068] In some embodiments, signature 314 proves agreement with the outcome of execution of action 310 of transaction 308 (e.g., proving the retrieval of information from database X), allowing it to be committed to the blockchain. In some embodiments, if signature 314 is not received, transaction 308 is invalidated, rejected, or both. This may be the case if the information in transaction actions 312 does not match. For example, if a transaction is validated by the username in payload 304 and committed to the blockchain, each peer in the blockchain now has the username in their copy of the blockchain ledger. If the username is then removed from the transaction and a new peer joins the blockchain, peers that were in the blockchain before the username was removed will identify that the transaction no longer matches and the transaction will be rejected.

[0069] Referring now to FIG. 3B, an updated traditional transaction initiation 300B is shown, according to an embodiment of the present disclosure. Note that the updated traditional transaction initiation 300B includes the same components included in the traditional transaction initiation 300A, but further includes a hash 316 that is associated with and points to (e.g., includes a pointer to) a pre-image 318 that is separate from the payload 304. The pre-image 318 is any information / value that is required to be used for the transaction 308. However, because the hash 316 is within the transaction action 312, the value of the hash 316 is used, and the pre-image 318 is never published to the blockchain (e.g., user data is never used in the validity verification logic). Furthermore, because the hash 316 replaces a value, and verification of the transaction's validity is not related to the content of the value associated with the hash 316, the pre-image 318 can be removed / edited from the envelope 302 and would not invalidate the transaction. It should be noted that what is described herein is functionally achievable since while verifying the validity of a transaction, the validity verification only has concern about the version of the key / keys (e.g., the key / keys associated with hash 316) and compliance with the authorization policy, thus allowing for the removal of pre-image 318.

[0070] Referring now to FIG. 4, a transaction structure 400 for allowing editing of information is shown, according to an embodiment of the present disclosure. In some embodiments, transaction structure 400 may be the structure used by action 310 of FIGS. 3A and 3B. In some embodiments, transaction structure 400 includes transaction action 452, which may be transaction action 312 of FIGS. 3A and 3B. As depicted, transaction action 452 includes a chaincode action payload 454, which includes a chaincode approval action 456. Chaincode approval action 456 includes approval 458. Approval 458 may be a signature / validation / authorization / etc. that indicates that the transaction associated with transaction action 452 can proceed, can be committed to the blockchain, or both.

[0071] As further depicted, the chaincode approval action 456 includes a proposal response payload 460. The proposal response payload 460 includes a proposal hash 462, which may be associated with information proposed to be added to the blockchain. The proposal response payload 460 may further include a chaincode action 464, which may detail how / where information about the transaction should be stored on the blockchain. In some embodiments, the chaincode action 464 includes a transaction (Tx) simulation result 466, which includes a transaction read / write set 468. The transaction read / write set 468 includes a next step (Ns) read / write (Rw) set 468, which points to a value 484, which may be information / data / content, and includes an associated value hash 472.

[0072] In some embodiments, chaincode action 464 further includes chaincode event 474. Chaincode event 474 points to and includes first payload hash 476 associated with first payload 482, which may include sensitive information. In some embodiments, chaincode action 464 further includes response 478, which points to and includes second payload hash 480 associated with second payload 486, which may be further information that a user may want to be editable. In some embodiments, value hash 472, first payload hash 476, and second payload hash 480 may all point to and be associated with the same information (e.g., value 484, first payload 482, or second payload 486).

[0073] Note that value 484, first payload 482, and second payload 486 are stored in separate areas of transaction structure 400 in pre-image 488. In pre-image 488, value 484, first payload 482, and second payload 486 are fully visible but not exposed to the blockchain during a transaction associated with transaction structure 400.

[0074] Referring now to FIG. 5, a verification 500 of transaction validity by a subordinate peer 518 is illustrated, according to an embodiment of the present disclosure. As depicted, a superior peer 502 includes a block 504 containing transactions (Tx) 506A-506C (e.g., validated transactions), where the block 504 is stored at the superior peer 502 via a blockchain that communicates with the superior peer 502 committing the transactions 506A-506C to the blockchain. In some embodiments, each of the transactions 506A-506C includes a payload 508A-508C and a signature 510A-510C, respectively. Here, transaction 1 506A includes a pre-image 512, transaction 2 506B includes a pre-image 514, and transaction 3 506C includes a pre-image 516. In some embodiments, each of the pre-images 512-516 may actually be a hash of the pre-image 512-516 or may be derived into the transactions 506A-506C via a hash that points to the pre-image 512-516, but for clarity, the hashes are not depicted.

[0075] In some embodiments, subordinate peer 518 may be onboarded to the blockchain or may receive a copy of the blockchain ledger, including block 504. Alternatively, in some embodiments, subordinate peer 518 may be superior peer 502, and block 504 may be updated after the fourth (subsequent) transaction. In either case, pre-image 514 is replaced with zero 520 (e.g., the value associated with pre-image 514 becomes zero via the edit transaction of pre-image 514), and thus appears as edited to / in block 504. The replacement of pre-image 514 with zero 520 allows transaction 2 506B to remain valid. That is, the reliance on the hash while computing the hash chain, and the independence of pre-image 514, allows verification of the continued validity of (edited) transaction 2 506B and the hash chain.

[0076] As provided in this disclosure and depicted in FIG. 5, information from the blockchain can be edited without invalidating transactions, maintaining block hash integrity (e.g., allowing continued chaining / linking of blocks). This continues to allow the blockchain to immutably verify the existence of transactions. Furthermore, note that a transaction with a mismatched hash / preimage marks all keys in its write set as corrupted, and any subsequent read (e.g., of the transaction) of the corrupted key during chaincode execution results in the immediate termination of the transaction. Typically, an orderer verifies the validity of the hash and rejects transactions with mismatched hash / preimages. This is required to prevent forks between a transaction with a mismatched hash / preimage (e.g., value) and the same transaction after an edit. As such, embodiments disclosed herein provide a method for edits that eliminate any key or cause of a fork in the same transaction.

[0077] 6A, a flowchart of an example method 600 for maintaining block hash integrity in a blockchain network is shown, according to an embodiment of the present disclosure. In some embodiments, method 600 may be performed by a processor (e.g., a peer / node in a system in a blockchain, etc.). In some embodiments, method 600 begins at operation 602, where a processor stores a value and a hash of the value in a ledger associated with the blockchain network.

[0078] In some embodiments, the method 600 proceeds to operation 604, where the processor constructs a block hash from the hashes of the values. In some embodiments, method 600 proceeds to operation 606. At operation 606, the processor verifies the validity of the transaction by identifying that the hash of the value matches the hash of the value from a previous transaction (or, in some embodiments, the onboarding of a new peer). In some embodiments, method 600 proceeds to operation 608, where the processor maintains the integrity of the block hashes (e.g., there are no forks between transactions with non-matching hashes of the same transaction at the edited time, and therefore the transactions are not invalidated, which allows for continued chaining / linking of blocks). In some embodiments, method 600 may end.

[0079] In some embodiments described below, one or more operations of method 600 are not depicted for the sake of brevity. Accordingly, in some embodiments, method 600 may further include a processor editing a value. In such embodiments, editing the transaction includes setting a bit associated with the value to zero. In some embodiments, method 600 may be performed after editing the value, editing information associated with the value (e.g., user data, personal information, etc.), or both.

[0080] In some embodiments, redacting the value may further include maintaining a hash of the value and a block hash. In some embodiments, redacting the value may further include the processor replacing the value with the hash of the value. The processor further maintains a separate pre-image of the value. In some embodiments, the hash of the value points to the separate pre-image.

[0081] In some embodiments, method 600 further comprises the processor maintaining the validated transaction without the value (e.g., even if the value is edited, the transaction remains valid, immutable, and unchanged due to the hash of the value being recorded in the ledger). In some embodiments, method 600 further comprises the processor receiving the value. The processor may identify that the value is associated with user data. The processor may then generate a hash of the value (e.g., the processor identifies that the value is associated with a particular type of data / information, and then a hash is generated for the value, described, and the proposed blockchain structure is created as depicted in this disclosure).

[0082] 6B, a flowchart of an example method 650 for editing information from a blockchain network is shown, according to an embodiment of the present disclosure. In some embodiments, method 650 may be performed by a processor (e.g., a peer / node in a blockchain in a system, etc.). In some embodiments, method 650 begins with operation 652, in which the processor provides the edit transaction to the blockchain network.

[0083] In some embodiments, the method 650 proceeds to operation 654, where the processor initializes an edit transaction. The edit transaction may be associated with the validated transaction. In some embodiments, method 650 proceeds to operation 656. At operation 656, the processor identifies a hash value indicated in the edit transaction and associated with the validated transaction. In some embodiments, method 650 proceeds to operation 658, where the processor edits a value associated with the hash value. In some embodiments, after operation 658, method 650 may end.

[0084] In some embodiments described below, one or more operations of method 650 are not depicted for the sake of brevity. Accordingly, in some embodiments, method 650 may further include a processor generating a transaction envelope. In some embodiments, the transaction envelope may include a hash value that includes a pointer to a pre-image. In some embodiments, the transaction envelope may further include a pre-image, and the pre-image may include a value.

[0085] In some embodiments, editing the value may include setting a bit associated with the value to zero. In such an instance, setting the bit associated with the value to zero allows the hash value to remain the same (e.g., unchanged, etc.). In some embodiments, method 650 may further include the processor maintaining the validated transaction based on identifying the hash value as the same after the edit transaction.

[0086] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present disclosure can be implemented in conjunction with any other type of computing environment now known or later developed.

[0087] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0088] The characteristics are as follows:

[0089] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without requiring human interaction with the service provider.

[0090] Wide network access: Capabilities are available over the network and are accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, and PDAs).

[0091] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge over the exact portion of the resources provided, but there is partial independence in that it may be possible to specify portions at a higher level of abstraction (e.g., country, state, or data center).

[0092] Rapid scalability: Different capacities can be rapidly and elastically provisioned, sometimes automatically, and scaled out quickly, or released quickly and scaled in quickly. To the consumer, this often feels like unlimited capacity available for provisioning, and can be purchased in any quantity at any time.

[0093] Measurable Services: Cloud systems automatically control and optimize resource usage by utilizing metering capabilities appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts) at some level of abstraction. Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services used.

[0094] The service model is as follows:

[0095] Software as a Service (SaaS): The consumer is offered the ability to use a provider's application running on a cloud infrastructure. The application is accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0096] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the application hosting environment configuration.

[0097] Infrastructure as a Service (IaaS): The capability offered to consumers is to provision processing, storage, network, and other basic computing resources, allowing the consumer to deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0098] The deployment model is as follows:

[0099] Private Cloud: The cloud infrastructure is operated exclusively for an organization. It can be managed by the organization or a third party and can exist on-premise or off-premise.

[0100] Community Cloud: Cloud infrastructure is shared among several organizations to support a specific community with common interests (e.g., mission, security requirements, policies, and regulatory compliance considerations). It can be managed by the organization or a third party and can reside on-premises or off-premises.

[0101] Public cloud: Cloud infrastructure is made available to the general public or a large industry organization and is owned by an organization that sells cloud services.

[0102] Hybrid cloud: A cloud infrastructure is a composite of two or more clouds (private, community, or public), where each cloud remains a unique entity but is tied together by standardized or proprietary technologies that allow for data and application portability (e.g., cloud bursting to load balance between clouds).

[0103] Cloud computing environments are service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0104] 7A illustrates a cloud computing environment 710. As shown, the cloud computing environment 710 includes one or more cloud computing nodes 700 with which local computing devices used by cloud consumers (e.g., a personal digital assistant (PDA) or cellular phone 700A, a desktop computer 700B, a laptop computer 700C, or an automobile computer system 700N, or combinations thereof) may communicate. The nodes 700 may communicate with each other. They may be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described above.

[0105] This enables the cloud computing environment 710 to provide infrastructure, platform, and / or software as a service without requiring the cloud consumer to maintain resources on a local computing device. It will be understood that the types of computing devices 700A-700N shown in Figure 7A are intended to be illustrative only, and that the computing nodes 700 and the cloud computing environment 710 can communicate with any type of computerized device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0106] Figure 7B illustrates a set of functional abstraction layers provided by the cloud computing environment 710 (Figure 7A). It should be understood in advance that the components, layers, and functions illustrated in Figure 7B are intended to be illustrative only, and embodiments of the present disclosure are not limited thereto. As depicted below, the following layers and corresponding functions are provided:

[0107] Hardware and software layer 715 includes hardware and software components. Examples of hardware components include mainframe 702, RISC (reduced instruction set computer) architecture-based server 704, server 706, blade server 708, storage device 711, and network and networking components 712. In some embodiments, software components include network application server software 714 and database software 716.

[0108] The virtualization layer 720 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 722, virtual storage 724, virtual networks including virtual private networks 726, virtual applications and operating systems 728, and virtual clients 730.

[0109] In one example, management layer 740 may provide the functions described below. Resource provisioning 742 provides dynamic procurement of computing and other resources used to execute tasks within the cloud computing environment. Metering and pricing 744 provides cost tracking as resources are utilized within the cloud computing environment and charges or bills for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 746 provides access to the cloud computing environment to consumers and system administrators. Service level management 748 provides allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment 750 provides pre-configuration and procurement of cloud computing resources for anticipated future requirements according to SLAs.

[0110] The workload layer 760 provides example functions for which a cloud computing environment can be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation 762, software development and lifecycle management 764, virtual classroom instruction delivery 766, data analytics processing 768, transaction processing 770, and editorial transaction processing 772.

[0111] 8, there is shown a high-level block diagram of an exemplary computer system 801 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 801 may include one or more CPUs 802, a memory subsystem 804, a terminal interface 812, a storage interface 816, an I / O (input / output) device interface 814, and a network interface 818, all of which may be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 803, an I / O bus 808, and an I / O bus interface unit 810.

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

[0113] The system memory 804 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 822 or cache memory 824. The computer system 801 may further include other removable / non-removable volatile / non-volatile computer system storage media. By way of example only, a storage system 826 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium, such as a “hard drive.” Although not shown, a magnetic disk drive may be provided for reading from or writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), or an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. Additionally, the memory 804 may include flash memory, such as a flash memory stick drive or flash drive. Memory devices may be connected to the memory bus 803 by one or more data medium interfaces. The memory 804 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.

[0114] One or more programs / utilities 828, each having at least one set of program modules 830, may be stored in memory 804. The programs / utilities 828 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 networking environment. The programs 828 and / or program modules 830 generally perform the functions or methodologies of various embodiments.

[0115] 8 as a single bus structure providing a direct communication path between CPU 802, memory subsystem 804, and I / O bus interface 810, memory bus 803, in some embodiments, may include multiple different buses or communication paths that may be configured in any of a variety of forms, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Furthermore, while I / O bus interface 810 and I / O bus 808 are shown as single respective units, in some embodiments computer system 801 may include multiple I / O bus interface units 810, multiple I / O buses 808, or both. Furthermore, while multiple I / O interface units are shown separating I / O bus 808 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.

[0116] In some embodiments, computer system 801 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 801 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.

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

[0118] As described 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 alternative order or not at all, and further, multiple operations may occur simultaneously or as part of a larger process.

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

[0120] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is 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, punch cards, or mechanically encoded devices such as ridge structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium itself is not to be construed as a transitory signal such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0121] The computer-readable program instructions described herein may be downloaded to each computing / processing device from a computer-readable storage medium, or may be downloaded 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 comprise copper transmission cables, optical transmission fiber, wireless transmission, 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 forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0122] The computer-readable program instructions for carrying out the operations of the present disclosure may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, 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 run entirely on the user's computer, as a standalone software package, partially on the user's computer, 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 via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the present disclosure.

[0123] 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.

[0124] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to create a machine, such that the instructions, when executed by the computer processor or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or a combination thereof. These computer-readable program instructions may also be stored on a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, or other device, or a combination thereof, to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or both.

[0125] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to execute a series of operational steps to generate 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.

[0126] 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, that implement a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be realized as a single step, executed concurrently, substantially concurrently, partially, or fully in a time-overlapping manner, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of a block diagram or flowchart diagram, or combination thereof, and combinations of blocks in block diagrams or flowchart diagrams, or combinations thereof, 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.

[0127] The description of various embodiments of the present disclosure has been presented for illustrative purposes, but 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 terminology used herein has been selected to best explain the principles of the embodiments, practical applications of, or technical improvements to, the technology found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0128] 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. According to this specification, the following items are also disclosed. [Item 1] 1. A computer-implemented method comprising: storing the value and a hash of the value in a ledger associated with a blockchain network; constructing a block hash from the hashes of the values; verifying the validity of the transaction by identifying that the hash of the value matches the hash of the value from a previous transaction; maintaining the integrity of the block hashes; A method comprising: [Item 2] further comprising editing the value, wherein editing the value comprises setting bits associated with the value to zero. The method according to item 1. [Item 3] compiling the value further comprises maintaining the hash of the value and the block hash. The method described in item 2. [Item 4] The step of editing the value includes: replacing the value with the hash of the value; and maintaining a separate pre-image of said value. The method according to item 3. [Item 5] the hash of the value points to the separate pre-image; The method according to item 4. [Item 6] 6. The method of any one of items 1 to 5, further comprising maintaining the validated transaction without the value. [Item 7] receiving the value; identifying that the value is associated with user data; generating the hash of the value; 7. The method of any one of items 1 to 6, further comprising: [Item 8] Memory and a processor in communication with the memory; Equipped with The processor: storing the value and a hash of said value in a ledger associated with a blockchain network; constructing a block hash from the hash of the value; verifying the validity of the transaction by identifying that the hash of the value matches the hash of the value from a previous transaction; maintaining the integrity of the block hashes. system. [Item 9] The actions further include editing the value; editing the value includes setting a bit associated with the value to zero; Item 9. The system according to item 8. [Item 10] Compiling the value further includes maintaining the hash of the value and the block hash. Item 9. The system according to item 9. [Item 11] Editing the value further includes replacing the value with the hash of the value; and maintaining a separate pre-image of said value. [Item 12] Item 12. The system of item 11, wherein the hash of the value points to the separate pre-image. [Item 13] A computer program comprising program instructions that, when executed by a processor, are executable by the processor to cause the processor to perform a function, the function comprising: storing the value and a hash of said value in a ledger associated with a blockchain network; constructing a block hash from the hash of the value; verifying the validity of the transaction by identifying that the hash of the value matches the hash of the value from a previous transaction; maintaining the integrity of the block hashes. [Item 14] Item 14. The computer program product of item 13, wherein the function further comprises editing the value, and editing the value includes setting a bit associated with the value to zero. [Item 15] Item 15. The computer program of item 14, wherein compiling the value further comprises maintaining the hash of the value and the block hash. [Item 16] Compiling the transaction further comprises: replacing the value with the hash of the value, where the hash of the value points to a separate preimage; maintaining separate pre-images of said values; Item 16. The computer program according to item 15, comprising: [Item 17] 1. A method for compiling information from a blockchain network, comprising: providing the edit transaction to the blockchain network; initializing the edit transaction, the edit transaction being associated with a validated transaction; identifying a hash value indicated in the edit transaction and associated with the validated transaction; and compiling a value associated with the hash value. [Item 18] 20. The method of claim 17, further comprising generating a transaction envelope, the transaction envelope including the hash value including a pointer to a pre-image. [Item 19] 20. The method of claim 18, wherein the transaction envelope further includes the pre-image, the pre-image including the value. [Item 20] 20. The method of claim 17, wherein editing the value includes setting bits associated with the value to zero, wherein setting the bits associated with the value to zero allows the hash value to remain the same. [Item 21] 21. The method of claim 20, further comprising: maintaining the validated transaction based on identifying that the hash value is the same value after the edit transaction. [Item 22] 1. A system for compiling information from a blockchain network, the system comprising: Memory and a processor in communication with the memory; The processor: providing an edit transaction to the blockchain network; initializing the edit transaction, the edit transaction being associated with a validated transaction; Identifying a hash value indicated in the edit transaction and associated with the validated transaction; compiling a value associated with the hash value; A system configured to perform operations including: [Item 23] The operation may further include: generating a transaction envelope, the transaction envelope including the hash value including a pointer to a pre-image, the transaction envelope further including the pre-image, the pre-image including the value; Item 23. The system according to item 22. [Item 24] editing the value includes setting a bit associated with the value to zero, wherein setting the bit associated with the value to zero allows the hash value to remain the same. 24. The system according to item 22 or 23. [Item 25] and further comprising: after the edit transaction, maintaining the validated transaction based on identifying that the hash values ​​are the same. Item 25. The system according to item 24.

Claims

1. 1. A computer-implemented method comprising: storing the value and a hash of said value in a ledger associated with a blockchain network; constructing a block hash from the hashes of the values; verifying the validity of the transaction associated with the value by identifying that the hash of the value matches the hash of the value from a previous transaction; editing the value, the step including setting bits associated with the value to zero, and maintaining the hash of the value and the block hash; A method comprising:

2. 2. The method of claim 1, wherein the value is compiled using a block corresponding to the block hash, the block being the block against which the transaction is validated.

3. 3. The method of claim 1, wherein the at least one value edited is a first value or a second value, the first value corresponding to a first hash and the second value corresponding to a second hash, and the first hash and the second hash are associated with a block corresponding to the block hash.

4. 3. The method of claim 1, wherein the at least one value edited is a first value and a second value, the first value corresponding to a first hash and the second value corresponding to a second hash, and the first hash and the second hash are associated with a block corresponding to the block hash.

5. Memory and a processor in communication with the memory; Equipped with The processor: storing the value and a hash of said value in a ledger associated with a blockchain network; constructing a block hash from the hash of the value; verifying the validity of the transaction associated with the value by identifying that the hash of the value matches the hash of the value from a previous transaction; editing the value, the editing including setting a bit associated with the value to zero and maintaining the hash of the value and the block hash; configured to perform operations comprising: system.

6. A computer program comprising program instructions that, when executed by a processor, are executable by the processor to cause the processor to perform a function, the function comprising: storing the value and a hash of said value in a ledger associated with a blockchain network; constructing a block hash from the hash of the value; verifying the validity of the transaction associated with the value by identifying that the hash of the value matches the hash of the value from a previous transaction; editing the value, the editing including setting a bit associated with the value to zero and maintaining the hash of the value and the block hash; A computer program comprising:

Images