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 build a block hash from the hash of the value. The processor may verify the 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 for the blockchain network. The processor may initialize the edit transaction. The edit transaction may be associated with a verified transaction. The processor may identify a hash value indicated in the edit transaction and associated with the verified transaction. The processor may edit a value associated with the hash value.

Description

Background Art

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

[0002] Currently, under the General Data Protection Regulation (GDPR), any individual can contact an entity to request that their personal information be deleted from all of the entity's systems within a specific time frame. However, many entities now utilize some form of blockchain network within their systems, and by nature, blockchain networks utilize an immutable ledger that permanently records information. Therefore, problems arise when an individual wishes to edit / delete their personal information from an entity's systems.

[0003] Furthermore, there are currently no adequate methods to edit information from a blockchain network without destroying the blocks in which the information is stored. Traditionally, each block in a blockchain network includes a hash of the previous block, thereby linking the blocks together to create a chain. Therefore, when the content / information of a block changes, the hash of the block also changes, and therefore the validity of the block cannot be proven within the chain. As such, it is not possible to directly delete data from a ledger associated with a blockchain network because it will affect the ability to link the blocks together. Therefore, there is an urgent need for a device for editing information from a blockchain network without destroying the ability to continue to link the blocks together and 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 editing 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 build a block hash from the hash of the value. The processor may verify 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. The editing of the value may include setting bits associated with the value to zero.

[0006] In some embodiments, editing the value further comprises 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 date with a hash of the value. The processor may maintain a decoupled previous image of the value.

[0008] In some embodiments, the hash of the value points to the decoupled previous image.

[0009] In some embodiments, the processor may maintain the verified transaction without this value.

[0010] In some embodiments, a processor may receive the value. The processor may identify that the value is associated with user data. The processor may generate a 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 a blockchain network. The processor may initialize an edit transaction. The edit transaction may be associated with a verified transaction. The processor may identify a hash value indicated in the edit transaction and associated with the verified transaction. The processor may edit a value associated with the hash value.

[0012] In some embodiments, the processor may generate a transaction envelope. The transaction envelope may include a hash value containing a pointer to the previous image.

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

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

[0015] In some embodiments, the processor may maintain the verified transaction based on identifying that the hash value is the same after editing the transaction.

[0016] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings included in the present disclosure are incorporated into the specification and form a part of the specification. They illustrate embodiments of the present disclosure and, together with the description, are used to explain the principles of the present disclosure. The accompanying drawings illustrate only certain embodiments and do not limit the present disclosure.

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

[0019] Figure 1B The blockchain transaction process according to an embodiment of the present disclosure is shown.

[0020] Figure 2 A conventional blockchain is shown being transformed into an editable blockchain according to an embodiment of the present disclosure.

[0021] Figure 3A A conventional transaction initiation according to an embodiment of the present disclosure is shown.

[0022] Figure 3BAn updated transaction initiation according to an embodiment of the present disclosure is shown.

[0023] Figure 4 A transaction structure for allowing editing of information according to an embodiment of the present disclosure is shown.

[0024] Figure 5 The verification of a transaction by a descendant peer according to an embodiment of the present invention is shown.

[0025] Fig. 6A A flowchart of an example method for maintaining block hash integrity in a blockchain network according to an embodiment of the present disclosure is shown.

[0026] Figure 6B A flow chart illustrating an exemplary method for editing information from a blockchain network according to an embodiment of the present disclosure.

[0027] Fig. 7A A cloud computing environment according to an embodiment of the present disclosure is shown.

[0028] Figure 7B An abstract model layer according to an embodiment of the present disclosure is shown.

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

[0030] Although the embodiments described herein may be subjected to various modifications and alternative forms, the details thereof have been illustrated in the drawings by way of example and will be described in detail. However, it should be understood that the specific embodiments described should not be considered restrictive. On the contrary, the present invention is intended to cover all modifications, equivalents and substitutes falling within the spirit and scope of the present disclosure. DETAILED DESCRIPTION

[0031] Aspects of the present disclosure relate generally to the field of information privacy, and more particularly to editing information (e.g., user information, personal data, etc.) from blockchain networks. Many individuals like to control what information is there (e.g., personal information, private information, or other information), and with the advent of GDPR, individuals now have the right to be forgotten. With such a right, an individual can contact an entity (e.g., a business, company, etc.) and request that their information be deleted from the entity's system within a specific time frame. However, many entities now utilize some form of blockchain network within their systems, and in essence, blockchain networks utilize an immutable ledger that permanently records information. Therefore, problems arise when an individual wishes to edit / delete their personal information from the entity's system.

[0032] Currently, there is no option for editing information from a blockchain network. The closest alternative is private data collection, encryption, and off-chain storage with on-chain hashing. However, each alternative does not actually edit the information of the blockchain network, and each alternative has its own shortcomings. For example, private data collection: relies on a time-based block-to-live strategy (e.g., setting an expiration time on the block); has performance degradation due to the need for peers / nodes to pull private dates when submitting; and requires prior design, never putting user data on the chain, because once the data is on the public chain, it is impossible to get rid of it. In addition, encryption alternatives require key management overhead, and forward secrecy is unclear in the emerging quantum computing era. Finally, in the case of multiple management domains, off-chain storage hashed on the chain will lead to challenges in data distribution, consistency, and availability. That is, in general, the key problem of each alternative is that they require additional components that are not initially provided, and therefore must be implemented on a new blockchain each time, while what is disclosed herein is an inherent built-in solution for a (permitted) blockchain with an execution order verification architecture. Therefore, there does need to be a method of allowing information (because it relates to a specific user / individual) to be removed from the blockchain, which method is discussed in this disclosure.

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

[0034] In one or more embodiments, the instant features, structures, or characteristics as described throughout this specification may be combined or removed in any suitable manner. For example, the use of the phrases "exemplary embodiments", "some embodiments" or other similar language throughout this specification refers to the fact that the specific features, structures or characteristics described in conjunction with the embodiments may be included in at least one embodiment. Therefore, the phrases "exemplary embodiments", "in some embodiments", "in other embodiments" or other similar language appearing throughout this specification do not necessarily all refer to the same set of embodiments, and the described features, structures or characteristics may be combined or removed in any suitable manner in one or more embodiments. In addition, in the figure, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Moreover, any device depicted in the accompanying drawings may be a different device. For example, if a mobile device is shown as sending information, a wired device may also be used to send the information.

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

[0036] Methods, systems, and computer program products utilizing adapted transaction envelopes that allow editing of information from a blockchain network are described herein.

[0037] In some embodiments, the methods, systems, and / or computer program products utilize a decentralized database (such as a blockchain) as a distributed storage system that includes multiple nodes that communicate with each other. The decentralized database may include an append-only immutable data structure similar to a distributed ledger that can maintain records between mutually untrusted parties. Untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching a consensus between the distributed peers. For example, peers may execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain on the blocks. To maintain consistency, the process forms a ledger by sorting storage transactions as needed.

[0038] In various embodiments, permissioned and / or permissionless blockchains may be used. In a public or permissionless blockchain, anyone can participate without a specific identity (e.g., remaining anonymous). Public blockchains may involve local cryptography and use consensus based on different protocols (such as proof of work). On the other hand, a permissioned blockchain database provides secure interactions between a group of entities that share a common goal but do not fully trust each other, such as businesses that exchange funds, goods, (private) information, etc.

[0039] Further, in some embodiments, the methods, systems and / or computer program products may utilize a blockchain operating arbitrary, programmable logic that is customized for a decentralized storage solution and is referred to as a "smart contract" or "chaincode". In some embodiments, the methods, systems and / or computer program products may further utilize smart contracts, which are trusted distributed applications that utilize the tamper-proof properties of the blockchain database and an underlying protocol between nodes, referred to as endorsements or endorsement policies. Blockchain transactions associated with the application may be endorsed before being submitted to the blockchain, while unendorsed transactions are ignored.

[0040] The endorsement policy allows the chaincode to specify endorsers for a transaction in the form of a set of peer nodes that must endorse it. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to verify the transaction. In some embodiments, the transaction is first simulated, such as endorsed to get consent from peers to satisfy the endorsement policy. The transaction then enters the sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks. Further, in some embodiments, after the transaction enters the block / blocks and reaches the peers, the transaction is verified.

[0041] In some embodiments, the methods, systems and / or computer program products may utilize nodes as communication entities of 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 in trust domains and are associated with logical entities that control them in different ways. Nodes may include different types, such as client or submit-client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., an ordering node).

[0042] Another type of node is a peer node, which is able to receive transactions submitted by clients, submit transactions, and maintain the state and copy of the ledger of blockchain transactions. A peer may also have the role of an endorser, although it is not required. An ordering-service-node or orderer is a node that runs a communication service for all nodes, and it implements delivery guarantees, such as broadcasting to every peer node in the system when submitting / confirming transactions and modifying the world state of the blockchain, which is another name for the initial blockchain transaction, which typically includes control and setup information.

[0043] In some embodiments, the methods, systems, and / or computer program products may utilize a ledger, which is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions may be caused by chaincode invocations (e.g., transactions) submitted by parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each party (such as a peer node) may maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) for storing immutable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

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

[0045] The current state of an immutable ledger represents the latest values ​​of all keys included in the chain transaction log. Because the current state represents the latest key values ​​known to the channel, it is sometimes referred to as the world state. Chaincode invocations execute transactions against the current state data of the ledger. In order for these chaincode interactions to be efficient, the latest values ​​of the keys can be stored in a state database. The state database can simply be an indexed view into the chain's transaction log, and can therefore be regenerated from the chain at any time. The state database can be automatically restored (or generated if necessary) when a peer node starts and before accepting transactions.

[0046] Some benefits of the instant solution 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 on a blockchain while maintaining the resilience of the chain (e.g., redaction of information does not result in invalidation of subsequent transactions).

[0047] It is worth noting that blockchain is different from traditional databases because blockchain is not a central storage, but a decentralized, immutable and secure storage where nodes can share changes to records in the storage. Some properties inherent in blockchain and that contribute to the implementation of blockchain include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsements, accessibility, etc., further described herein. According to different aspects, the system described herein is achieved due to accountability, security, privacy, permissioned decentralization, availability of smart contracts, endorsements, and accessibility that are inherent and unique to blockchain.

[0048] In particular, blockchain ledger data is traditionally immutable, which provides an effective method for identifying discrepancies in blockchain networks; the present disclosure provides methods, systems, and computer program products for mitigating discrepancies that would result in subsequent invalidation of transactions (e.g., data records). In addition, the use of encryption in blockchains can provide security and establish trust. Smart contracts manage the state of assets to complete the life cycle. The example blockchain is decentralized. Therefore, each end user can access their own copy of the ledger. Multiple organizations (and peers) can join the blockchain network. Key organizations can act as endorsement peers to verify smart contract execution results, read-sets, and write-sets.

[0049] One of the benefits of the example embodiments is that it improves the functionality 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 in a computing system) can perform functions for utilizing a blockchain network for editing processes by providing access to functions such as distributed ledgers, peers, encryption, MSP, event processing, etc. In addition, blockchain enables the creation of business networks and enables any user or organization to participate. Therefore, the blockchain is more than just a database. The blockchain has the ability to create user networks and on-chain / off-chain organizations to collaborate and execute service processes (which can be associated with editing processes and / or specific information to be edited) in the form of smart contracts.

[0050] Example embodiments provide many benefits over traditional databases. For example, through blockchain, embodiments provide accountability, security, privacy, decentralization of permissions, availability of smart contracts, endorsement, and accessibility that are inherent and unique to blockchain.

[0051] At the same time, a traditional database cannot be used to implement the example embodiments because it does not bring all parties onto the network, it does not create trusted collaboration and does not provide efficient storage of digital assets. Traditional databases do not provide tamper-proof storage and do not provide preservation of stored digital assets. Thus, the proposed embodiments described herein that utilize a blockchain network cannot be implemented in a traditional database.

[0052] At the same time, if the example embodiments were implemented using a traditional database, the example embodiments would suffer from unnecessary disadvantages such as search capabilities, lack of security, and slow transactions (e.g., by attempting to identify edit information differences). Thus, the example embodiments provide a specific solution to problems in the field / domain of information editing in blockchain.

[0053] Now turn to Figure 1A, illustrates a blockchain architecture 100 according to an embodiment of the present disclosure. In some embodiments, the blockchain architecture 100 may include certain blockchain elements, for example, a set 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 by way of example only). These nodes participate in multiple activities, such as blockchain transaction addition and verification processes (consensus). One or more of the peers 104-110 may endorse and / or recommend transactions based on endorsement policies, and may provide sorting services for all blockchain nodes 102 in the blockchain architecture 100. The blockchain node may initiate a blockchain authentication and attempt to write to a blockchain immutable ledger stored in a blockchain layer 116, a copy of which may also be stored on the underlying physical infrastructure 114. The blockchain configuration may include one or more applications 124 that are linked to an application programming interface (API) 122 to access and execute stored program / application code 120 (e.g., chain code, smart contracts, etc.), which may be created according to the customized configuration sought by the participants and may maintain its own state, control its own assets, and receive external information. This may be deployed as a transaction and installed on all blockchain nodes 104-110 via appending to the distributed ledger.

[0054] The blockchain foundation or platform 112 may include different layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking to access data entries. The blockchain layer 116 may expose interfaces that provide access to the virtual execution environment necessary to process program code and participate in the physical infrastructure 114. Cryptographic trust services 118 may be used to verify transactions (such as asset exchange transactions) and keep information private.

[0055] Figure 1AThe blockchain architecture 100 can process and execute program / application code 120 through one or more interfaces exposed by the blockchain platform 112 and the services provided. The application code 120 can control blockchain assets. For example, the application code 120 can store and transmit data and can be executed by peers 104-110 in the form of smart contracts and associated chain codes, where conditions or other code elements are affected by its execution. As a non-limiting example, a smart contract can be created to perform the transfer of resources, the generation of resources, etc. The smart contract itself can be used to identify rules associated with authorization, access requirements (e.g., data repositories, off-chain data repositories, pre-image databases, etc.) and / or the use of ledgers. For example, the pre-image information 126 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. The results 128 can include multiple linked shared documents (e.g., each linked shared document records the issuance of a smart contract regarding the pre-image information 126, is identified as allowing or denying verification, etc.). In some embodiments, the physical infrastructure 114 can be used to retrieve any data or information described herein.

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

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

[0058] The chaincode may include a code interpretation of a smart contract with additional features. As described herein, a chaincode may be a program code deployed on a computing network, wherein the chaincode is executed and validated by a chain validator together during a consensus process. The chaincode receives the hash and retrieves from the blockchain a hash associated with a data template created by using a previously stored feature extractor. If the hash of the hashed identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode may write data associated with cryptographic details to the blockchain (e.g., thereby confirming the contribution, the difference between the identity and the contribution, etc.).

[0059] Figure 1B An example of a blockchain transaction flow 150 between nodes of a blockchain is shown according to an exemplary embodiment. Figure 1B , the transaction flow may include a transaction proposal 191 sent by the application client node 160 to the endorsing peer node 181 (for example, 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 the chaincode function to initiate the transaction. The output may include the chaincode result, the set of key / value versions read in the chaincode (read set), and the set of key / values ​​written in the chaincode (write set). If approved, the proposal response 192 is sent back to the client 160 along with the endorsement signature. The client 160 assembles the endorsement into a transaction payload 193 and broadcasts it to the ordering service node 184. The ordering service node 184 then delivers the ordered transaction as a block to all peers 181-183 on the channel. Each peer 181-183 may validate the transaction before committing to the blockchain. For example, a peer may check the endorsement policy to ensure that the correct assignment of specified peers has signed the transaction payload 193 and authenticated the signature (e.g., all or a threshold number of peers verify that the request includes an identifier and / or symmetric key that allows discovery of the data store connection object and / or access to an off-chain database).

[0060] Reference again Figure 1B , the client node 160 initiates a transaction 191 by constructing a request and sending it to the peer node 181 as an endorser. The client 160 may include an application that utilizes a supported software development kit (SDK) that utilizes an available API to generate a transaction proposal 191. A proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger (e.g., write a new key-value pair for an asset). The SDK can reduce the package of the transaction proposal 191 to a format of an appropriate architecture (e.g., protocol buffers over a remote procedure call (RPC)) and use the client's cryptographic certificate to 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 formatted correctly, (b) the transaction has not been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in the example, client 160) is properly authorized to perform the proposed operation on the channel. The endorsing peer node 181 may input the transaction proposal 191 as a parameter to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read set, and a write set. However, no updates are made to the ledger at this time. In some embodiments, the value set is passed back to the SDK of the client 160 along with the signature of the endorsing peer node 181 as a proposal response 192, and the SDK parses the payload for consumption by the application.

[0062] In response, the client 160 application checks / verifies the endorsed peer signature and compares the proposed responses to determine if the proposed responses are the same. If the chaincode only queries the ledger, the application will check the query response and will generally not submit the transaction to the ordering node service 184. If the client application intends to submit the transaction to the ordering node service 184 to update the ledger, the application determines whether the specified endorsement policy has been satisfied (e.g., whether the request has been accepted) before submission. Here, the client may only include one of the multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node is required to endorse the transaction. The architecture is such that even if the application chooses not to check the response or otherwise forward unendorsed transactions, the endorsement policy will still be enforced by the peer and maintained during the submission verification phase.

[0063] After successful checks, in the transaction payload step 193, the client 160 assembles the endorsements into a transaction and broadcasts the transaction proposal 191 and the response within the transaction message to the ordering node 184. The transaction may contain a read / write set, an endorsing peer signature, and a channel ID. The ordering node 184 does not need to examine the entire contents of the transaction in order to perform its operations, instead, the ordering node 184 can simply receive transactions from all channels in the network, sort them chronologically by channel, and create a transaction block for each channel.

[0064] The block of transactions is delivered from the ordering node 184 to all peer nodes 181-183 on the channel. The transactions 194 within the block are validated to ensure that any endorsement policies are satisfied and that the state of the ledger for the read set variables has not changed since the transaction execution generated the read set. The transactions in the block are marked as valid or invalid. In addition, in step 195, each peer node 181-183 appends the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. An event is emitted to notify the client application that the transaction (call) has been immutably attached to the chain, as well as to notify whether the transaction is validated or invalid (e.g., whether the request is allowed or denied, access to an off-chain data store).

[0065] Now refer to Figure 2 , showing that a traditional blockchain 202A according to an embodiment of the present disclosure is transformed into an editable blockchain 202B. It should be noted that the same reference numerals are used to refer to the same components in the accompanying drawings. As shown, the traditional blockchain 202A includes a block hash 204, which is a hash of the block header and serves as a reference number for the block (not depicted) in the traditional blockchain 202A. The block hash 204 is traditionally associated with (e.g., referenced, pointed to, etc.) a first value 206 and / or a second value 208. In some embodiments, the first value 206 and / or the second value 208 can be a value associated with a transaction involving information. In this case, the information is immutably stored on the traditional blockchain 202A.

[0066] To allow editing of the first value 206 and / or the second value 208, the present disclosure provides for transforming the traditional blockchain 202A into an editable blockchain 202B by hashing the first value 206 and / or the second value 208. The hashing of the first value 206 and / or the second value 208 generates a corresponding first hash 210 and / or second hash 212, which are now associated with the block 204. In this case, and as will be discussed more fully below, the first value 206 and / or the second value 208 can now be edited without invalidating the block hash 204 or the block referenced by the block hash 204, because the first hash 210 and / or the second hash 212 are effectively the first value 206 and the second value 208 in the traditional blockchain 204 and will not change. It should be noted that the traditional blockchain 202A and the editable blockchain 202B are the same blockchain, but with structural changes.

[0067] See now Figure 3A, shown is a traditional transaction initiation 300A according to an embodiment of the present disclosure. As shown, the traditional transaction 300A includes an envelope 302 containing a payload 304 and a signature 314 on the payload 304. The payload 304 includes a header 306, which includes destination information (e.g., identifying where the assets of the transaction should be sent, etc.). The payload 304 further includes a transaction 308, which includes an action 310. The transaction action 310 includes instructions depicted as transaction action 312, but it should be noted that more than one instruction may be included in the transaction 308 (e.g., pull information from database x and store the information in database y, etc.). As shown Figure 2 As shown, the transaction action 312 may store information / data associated with the user and / or include the block hash 204 .

[0068] In some embodiments, signature 314 proves agreement on the results of execution of action 310 of transaction 308 (e.g., proves pulling information from database X, etc.), and it allows for commitment to the blockchain. In some embodiments, if signature 314 is not received, transaction 308 is invalid and / or rejected, which may be the case when the information in transaction action 312 does not match. For example, if a transaction is verified with a username in payload 304 and submitted to the blockchain, each peer in the blockchain now has the username on their copy of the blockchain ledger. Then, if the username is removed from the transaction, and a new peer joins the blockchain, the peers in the blockchain before the username was removed will identify that the transaction no longer meets the conditions, and the transaction is rejected.

[0069] See now Figure 3B , shown is an updated transaction initiation 300B according to an embodiment of the present disclosure. Note that the updated transaction initiation 300B includes the same components included in the traditional transaction initiation 300A, but further includes a hash 316 associated with the pre-image 318 and pointing to (e.g., including a pointer) the pre-image 318 separated from the payload 304. The pre-image 318 is any information / value that needs to be used for the transaction 308, but because the hash 316 is in the transaction action 312, the value of the hash 316 is used, and the pre-image 318 is never exposed to the blockchain (e.g., the user data is never used in the verification logic). Further, the pre-image 318 can be deleted / edited from the envelope 302 and will not invalidate the transaction because the hash 316 replaces the value and the transaction verification is independent of the content of the value associated with the hash 316. It should be noted that what is described herein is functionally achievable because during verification of a transaction, verification is only concerned with the version of one / multiple keys (e.g., one / multiple keys associated with hash 316) and compliance with the endorsement policy, thereby allowing the original image 318 to be deleted.

[0070] Reference now Figure 4 , which shows a transaction structure 400 that allows editing information according to an embodiment of the present disclosure. In some embodiments, the transaction structure 400 may be composed of Figure 3A and 3B In some embodiments, transaction structure 400 includes transaction action 452, which may be Figure 3A and 3B Transaction action 312. As depicted, transaction action 452 includes chaincode action payload 454, which includes chaincode endorsement action 456. Chaincode endorsement action 456 includes endorsement 458, which can be a signature / verification / permission, etc. indicating that the transaction associated with transaction action 452 can be conducted and / or submitted to the blockchain.

[0071] As further depicted, the chaincode endorsement action 456 includes a proposal response payload 460 that includes a proposal hash 462 that may be associated with the information proposed to be added to the blockchain. The proposal response payload 460 may also include a chaincode action 464 that 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 that includes a transaction read / write set 468. The transaction read / write set 468 includes a next step (Ns) read / write (Rw) set 468 that includes a hash of (a) value 472 that points to and is associated with a value 484, which may be information / data / content.

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

[0073] Note that value 484 , first payload 482 , and second payload 486 are stored in a decoupled area of ​​transaction structure 400 in front image 488 , where value 484 , first payload 482 , and second payload 486 are viewable in their entirety but are not exposed to the blockchain during transactions associated with transaction structure 400 .

[0074] See now Figure 5 , illustrating verification 500 of a transaction by a descendant peer 518 in accordance with an embodiment of the present disclosure. As depicted, an ancestor peer 502 includes a block 504, which includes transactions (Tx) 506A-C (e.g., verified transactions), wherein the block 504 is stored on the ancestor peer 502 via a blockchain in communication with the ancestor peer 502, submitting the transactions 506A-C to the blockchain. In some embodiments, each of the transactions 506A-C includes a payload 508A-C and a signature 510A-C, respectively, wherein transaction one 506A includes a pre-image 512, transaction two 506B includes a pre-image 514, and transaction three 506C includes a pre-image 516. In some embodiments, each pre-image 512-516 can actually be a hash of the pre-image 512-516, or pulled into the transaction 506A-C by pointing to the hash of the pre-image 512-516, but for clarity, the hashes are not depicted.

[0075] In some embodiments, descendant peer 518 may join the blockchain and receive a copy of the blockchain ledger, including block 504, or in some embodiments, descendant peer 518 may be ancestor peer 502, and block 504 may be updated after the fourth (subsequent) transaction. In either case, pre-image 514 is replaced by zero 520 (e.g., the value associated with pre-image 514 becomes zero via the edit transaction of pre-image 514), thereby making an edit to / in block 504. Replacing pre-image 514 with zero 520 allows transaction two 506B to remain valid. That is, relying on the hash instead of pre-image 514 in calculating the hash chain allows continued verification of transaction two 506B and the hash chain (after the edit).

[0076] As provided in this disclosure and Figure 5As depicted in , information can be edited from the blockchain without invalidating the transaction and maintaining block hash integrity (e.g., allowing continued chaining / linking of blocks), which continues to allow the blockchain to confirm the existence of the transaction unchanged. Additionally, it is worth noting that a transaction with a mismatching hash / pre-image marks all keys in its write set as revoked, and subsequent (e.g., transaction) reads of the revoked keys during chaincode execution result in immediate termination of the transaction. Typically, the sequencer verifies the hash and rejects transactions with mismatching hashes / pre-images, which is necessary to prevent forks between a transaction (e.g., value) with a mismatching hash / pre-image and the same transaction after the edit. Therefore, embodiments disclosed herein provide a way to edit in the same transaction by destroying any keys or causing a fork.

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

[0078] In some embodiments, the method 600 proceeds to operation 604, where the processor builds a block hash from the hash of the value. In some embodiments, the method 600 proceeds to operation 606. At operation 606, the processor verifies the transaction by identifying that the hash of the value matches the hash of the value from a previous transaction (or, in some embodiments, a new peer's login). In some embodiments, the method 600 proceeds to operation 608, where the processor maintains the integrity of the block hash (e.g., there are no forks between transactions with non-matching hashes of the same transaction after editing, so the transaction is not invalidated, and it allows continued chaining of blocks / chaining of blocks). In some embodiments, the method 600 may end.

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

[0080] In some embodiments, the deleting of the value may further include maintaining the block hash and the hash of the value. In some embodiments, editing the value may further include the processor replacing the value with the hash of the value. The processor may further maintain a decoupled previous image of the value. In some embodiments, the hash of the value may point to a decoupled previous image.

[0081] In some embodiments, method 600 may further include the processor maintaining the verified transaction without the value (e.g., the transaction remains valid even if the value is edited because the value is recorded to the ledger and the hash remains immutable and unchanged). In some embodiments, method 600 may further include the processor receiving the value. The processor may identify that the value is associated with user data. The processor may then generate the hash of the value (e.g., the processor identifies that the value is associated with a specific type of data / information, and then generates a hash of the value and generates the proposed blockchain structure as discussed and depicted throughout the present invention).

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

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

[0084] In some embodiments discussed below, one or more operations of method 650 are not depicted for the sake of brevity. Thus, in some embodiments, method 650 may further include the processor generating a transaction envelope. In some embodiments, the transaction envelope may include a hash value including a pointer to the previous image. In some embodiments, the transaction envelope may further include the previous image, and the previous image may include the value.

[0085] In some embodiments, editing the value may include setting bits associated with the value to zero. In this case, setting bits associated with the value to zero may allow the hash value to remain the same (e.g., not change, etc.). In some embodiments, method 650 may also include the processor maintaining the verified transaction based on identifying that the hash value is the same after editing the transaction.

[0086] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings cited herein is not limited to cloud computing environments. Instead, the 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 quickly provisioned and released with minimal management effort or interaction with the provider of the service. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0088] Features are as follows:

[0089] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed, without requiring manual interaction with the service provider.

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

[0091] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of partial independence, as consumers typically do not have control or knowledge of the exact portions of resources provided, but may be able to specify portions at a higher level of abstraction (e.g., country, state, or data center).

[0092] Rapid elasticity: The ability to quickly and elastically provision capacity, in some cases automatically scaling down quickly and releasing quickly to scale up quickly. To the consumer, the capacity available for provisioning generally appears unlimited and can be purchased in any quantity at any time.

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

[0094] The service model is as follows:

[0095] Software as a Service (SaaS): The capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications can be accessed from different 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 capabilities, with the possible exception of limited user-specific application configuration settings.

[0096] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired by consumers using programming languages ​​and tools supported by the provider onto the cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure including networks, servers, operating systems or storage, but have control over the deployed applications and possible configuration of the application hosting environment.

[0097] Infrastructure as a Service (IaaS): The capabilities provided to consumers are the provision of processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but 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: Cloud infrastructure is operated only for the organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

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

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

[0102] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

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

[0104] Fig. 7A A cloud computing environment 710 is shown. 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., personal digital assistants (PDAs) or cell phones 700A, desktop computers 700B, laptop computers 700C, and / or automotive computer systems 700N) can communicate. The nodes 700 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above.

[0105] This allows the cloud computing environment 710 to provide infrastructure, platform and / or software as a service for which cloud consumers do not need to maintain resources on local computing devices. Fig. 7A The types of computing devices 700A-N shown in are intended to be illustrative only, and computing node 700 and cloud computing environment 710 may communicate with any type of computerized device over any type of network and / or network addressable connection (eg, using a web browser).

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

[0107] The hardware and software layer 715 includes hardware and software components. Examples of hardware components include: mainframe 702; server 704 based on RISC (Reduced Instruction Set Computer) architecture; 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] Virtualization layer 720 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 722 ; virtual storage 724 ; virtual networks 726 , including virtual private networks; virtual applications and operating systems 728 ; and virtual clients 730 .

[0109] In one example, the management layer 740 may provide the functionality described below. Resource provisioning 742 provides dynamic procurement of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing 744 provides cost tracking when resources are utilized within a cloud computing environment, and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 746 provides access to the cloud computing environment for consumers and system administrators. Service level management 748 provides cloud computing resource allocation and management so that the required service levels are met. Service level agreement (SLA) planning and fulfillment 750 provides pre-scheduling and procurement of cloud computing resources in anticipation of future demand according to the SLA.

[0110] Workload layer 760 provides examples of functionality that can take advantage of a cloud computing environment. Examples of workloads and functionality that can be provided from the layer include: mapping and navigation 762; software development and lifecycle management 764; virtual classroom education delivery 766; data analysis processing 768; transaction processing 770; and editorial transaction processing 772.

[0111] Figure 8 A high-level block diagram of an exemplary computer system 801 that can be used to implement one or more of the methods, tools, and modules described herein and any related functionality (e.g., using one or more processor circuits of a computer or a computer processor) according to an embodiment of the present disclosure is shown. In some embodiments, the main components of the 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 directly or indirectly communicatively coupled 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 typical of relatively large systems; however, in other embodiments, computer system 801 may instead be a single CPU system. Each CPU 802 may execute instructions stored in a memory subsystem 804 and may include one or more levels of onboard 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, the storage system 826 may be configured to read from and write to a non-removable, non-volatile magnetic medium (such as a "hard drive"). Although not shown, a disk drive for reading from or writing to a removable non-volatile disk (e.g., a "floppy disk"), or an optical drive for reading from or writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media) may be provided. In addition, the memory 804 may include flash memory, such as a flash memory stick drive or a flash drive. The memory device may be connected to the memory bus 803 via one or more data media interfaces. The memory 804 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of different embodiments.

[0114] One or more programs / utilities 828, each having at least one set of program modules 830, may be stored in memory 804. 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 or some combination of each operating system, one or more application programs, other program modules, and program data may include an implementation of a network environment. Programs 828 and / or program modules 830 typically perform the functions or methods of different embodiments.

[0115] Although the memory bus 803 is Figure 8803 may include multiple different buses or communication paths, which may be arranged in any of a variety of forms, such as point-to-point links in a hierarchical, star or network configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. In addition, although the I / O bus interface 810 and the I / O bus 808 are shown as a single corresponding unit, in some embodiments, the computer system 801 may include multiple I / O bus interface units 810, multiple I / O buses 808, or both. Further, although multiple I / O interface units are shown to separate the I / O bus 808 from different communication paths running to different I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0116] In some embodiments, the computer system 801 may be a multi-user mainframe computer system, a single-user system or a server computer or a similar device having little or no direct user interface but receiving requests from other computer systems (clients). Further, in some embodiments, the 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 phone, a smart phone, a network switch or router, or any other suitable type of electronic device.

[0117] It should be noted that Figure 8 The main components of the exemplary computer system 801 are intended to be described. However, in some embodiments, the various components may have more Figure 8 The greater or lesser complexity represented in , may exist different from Figure 8 Components other than those shown in Figure 8 Components other than those shown in the drawings may be included, and the number, type, and configuration of such components may vary.

[0118] As discussed in greater detail herein, it is contemplated that some or all of the operations of some embodiments of the methods described herein may be performed in an alternate order or may not be performed at all; furthermore, multiple operations may occur concurrently or as internal parts of a larger process.

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

[0120] Computer readable storage medium can be a tangible device that can retain and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, 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 stick, floppy disk, mechanical encoding device such as punch card or a protruding structure in a groove with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself, such as radio waves or other free propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses passing through fiber optic cables) or electrical signals emitted by wires.

[0121] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The 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 to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0122] The computer-readable program instructions for performing the operation of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and process programming languages ​​(such as "C" programming languages ​​or similar programming languages). The computer-readable program instructions may be executed completely on a user's computer, partially on a user's computer, executed as an independent software package, partially on a user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., using an Internet service provider via the Internet). 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 be personalized to execute computer-readable program instructions by utilizing the state information of the computer-readable program instructions to perform various aspects of the present disclosure.

[0123] Various aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0124] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium in which the instructions are stored includes a manufactured product containing instructions for implementing aspects of the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

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

[0126] The flowcharts and block diagrams in the accompanying drawings show the architecture, functions and operations of possible implementations of the system, method and computer program product according to different embodiments of the present disclosure. To this end, each box in the flowchart or block diagram may represent a module, segment or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions marked in the box may not occur in the order marked in the figure. For example, the two boxes shown in succession can actually be completed as a step, and are executed simultaneously, substantially simultaneously, in a partially or completely overlapping manner in time, or the boxes can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0127] The description of different 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 of ordinary skill 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 to technologies found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

[0128] Although the present disclosure has been described in terms of specific embodiments, it is contemplated that changes and modifications will become apparent to those skilled in the art. Therefore, the following claims are intended to be interpreted as covering all such changes and modifications that fall within the true spirit and scope of the present disclosure.

Claims

1. A computer-implemented method, the method comprising: storing a plurality of values ​​and a plurality of corresponding hashes of the plurality of values ​​in a ledger associated with a blockchain network, wherein the plurality of values ​​and the plurality of corresponding hashes are stored within a same blockchain block; constructing a block hash from the plurality of corresponding hashes of the plurality of values, wherein the block hash is a hash of a block header and serves as a reference number for referencing a block; verifying the transaction by matching a corresponding hash of the identification value with said corresponding hash of said value from a previous transaction; maintaining the integrity of the block hash; as well as At least one value stored within a block corresponding to the block hash is edited, wherein editing the at least one value includes setting bits associated with the at least one value to zero and maintaining the corresponding hash of the value of the block and the block hash.

2. The method according to claim 1, wherein: Editing the value further comprises: replacing the value with the corresponding hash of the value; and A decoupled previous image of the value is maintained.

3. The method according to claim 2, wherein: The corresponding hash of the value points to the decoupled previous image.

4. The method according to claim 1, further comprising: The value is not required to maintain a verified transaction.

5. The method according to claim 1, further comprising: receiving the value; identifying that the value is associated with user data; as well as The corresponding hash of the value is generated.

6. The method of claim 2, wherein maintaining the decoupled front image further comprises: A transaction envelope is generated, wherein the transaction envelope includes the corresponding hash of the value including a pointer to the decoupled pre-image and the decoupled pre-image includes the value.

7. The method according to claim 1, further comprising: Based on identifying that the corresponding hash of the value is the same after the editing, maintaining the verified transaction in a single block entry, the single block entry corresponding to the block hash.

8. The method of claim 1 , wherein editing the value further comprises: Initializing an edit transaction, wherein the edit transaction is associated with a previously validated transaction; identifying the corresponding hash and the value associated with the corresponding hash; as well as A value associated with the hash value of the block corresponding to the block hash is edited.

9. The method of claim 1, wherein the value is compiled using the block corresponding to the block hash, wherein the transaction is verified against the block.

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

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

12. A system, comprising: Memory; as well as a processor in communication with the memory, the processor being configured to perform operations comprising: storing a plurality of values ​​and a plurality of corresponding hashes of the plurality of values ​​in a ledger associated with a blockchain network, wherein the plurality of values ​​and the plurality of corresponding hashes are stored within a same blockchain block; constructing a block hash from the plurality of corresponding hashes of the plurality of values, wherein the block hash is a hash of a block header and serves as a reference number for referencing a block; verifying the transaction by matching a corresponding hash of the identification value with a corresponding hash of said value from a previous transaction; maintaining the integrity of the block hash; as well as The value stored within the block corresponding to the block hash is edited, wherein editing the value includes setting bits associated with the value to zero and maintaining the corresponding hash of the value of the block and the block hash.

13. The system according to claim 12, wherein: Editing the value further comprises: replacing the value with the corresponding hash of the value; and A decoupled previous image of the value is maintained.

14. The system according to claim 13, wherein: The corresponding hash of the value points to the decoupled previous image.

15. A computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor to cause the processor to perform functions, the functions comprising: storing a plurality of values ​​and a plurality of corresponding hashes of the plurality of values ​​in a ledger associated with a blockchain network, wherein the plurality of values ​​and the plurality of corresponding hashes are stored within a same blockchain block; constructing a block hash from the plurality of corresponding hashes of the plurality of values, wherein the block hash is a hash of a block header and serves as a reference number for referencing a block; verifying the transaction by matching a corresponding hash of the identification value with a corresponding hash of said value from a previous transaction; maintaining the integrity of the block hash; as well as The value stored within the block corresponding to the block hash is edited, wherein editing the value includes setting bits associated with the value to zero and maintaining the corresponding hash of the value of the block and the block hash.

16. The computer program product of claim 15, wherein: Editing the transaction further comprises: replacing the value with the corresponding hash of the value, wherein the corresponding hash of the value points to a decoupled previous image; and A previous image of the decoupling of the values ​​is maintained.

Images