Chain-type data storage technology for ensuring ownership and control right of personal data in very high security environment

Abstract

The present invention relates to a blockchain network that ensures personal data control rights. This transmitting node includes a processor configured to generate a transaction and a hash value on the basis of a transaction request, and a communicator configured to communicate with a receiving node and validation nodes. The processor adds a transaction to a block only when a normal validation signal is received from a receiving node and a predetermined number or more of validation nodes, and stores only a transaction that the processor is a sender. Each user owns an individual unique node and manages only his / her transaction, thereby protecting personal information and deleting data.

Description

Chain-based data storage technology that guarantees ownership and control of individual data in a highly secure environment.

[0001] The present invention relates to a chain-type data storage technology that guarantees ownership and control of an individual's data in a very high security environment, and more specifically, to a device and method that enable self-sovereign data control while maintaining high security reliability by proving that multiple nodes of a personal mainnet, where each individual operates and manages his or her own data, have not falsified or altered the individual's data.

[0002] Blockchain technology offers the advantage of providing a high level of security based on a decentralized distributed ledger and consensus-based architecture. Since the advent of Bitcoin, services utilizing blockchain have been utilized in various fields to enhance the transparency and security of financial transactions, automate smart contracts, and optimize supply chain management, providing efficient solutions across various industries.

[0003] However, existing blockchain technology makes it difficult to delete and manage one's own data because data from multiple participants is stored together on a single block and data deletion is impossible. In May 2016, the European Union (EU) enacted the General Data Protection Regulation (GDPR), which guarantees the free flow of personal information among EU member states in the digital single market while strengthening data subjects' rights to privacy. In particular, the GDPR's provision regarding the right to be forgotten conflicts with the existing blockchain architecture, which does not allow data deletion. These characteristics of blockchain architecture are hindering the activation of various services utilizing blockchain technology.

[0004] Therefore, to utilize blockchain technology, which offers a high level of security and reliability, in various service systems, a new blockchain architecture with high security while realizing self-control over personal data to protect personal information is needed.

[0005] The technical challenge of the present invention is to provide a chain-type data storage technology that guarantees ownership and control of an individual's data in a very high security environment.

[0006] Another technical challenge to be achieved by the present invention is to provide a device that applies chain-type data storage technology that guarantees ownership and control of an individual's data in a very high security environment.

[0007] Another technical problem to be achieved by the present invention is to provide a computer-readable recording medium or a computer-readable recording medium having recorded thereon a computer program for performing a method for chain-type data storage technology on a computer.

[0008] The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0009] In order to achieve the above technical problem, a transmitting node in a blockchain network according to the present invention may include a processor for generating a hash value of a transaction by applying a hash function to a transaction of a sender corresponding to the transmitting node and the transaction based on a received transaction request, and a communication unit for transmitting the transaction and the hash value of the transaction to a receiving node corresponding to a receiver of the transaction and one or more verification nodes that verify the transaction, respectively, and receiving a verification signal for the transaction from the receiving node and the one or more verification nodes, wherein the processor may add the generated transaction to a block of the transmitting node when a signal verifying that the transaction is normal is received from the receiving node and a signal verifying that a predetermined number or more of the transactions are normal is received from the one or more verification nodes, and may add to the block only transactions to which the sender is a party among a plurality of transactions in the blockchain network, and the transmitting node may be characterized in that it corresponds to an individual unique node of the sender.

[0010] When adding the generated transaction to the block of the transmitting node, the processor may generate a list of identifiers of a predetermined number of verification nodes that transmitted a signal verifying that the transaction is normal, and add the list to the block.

[0011] The processor may control not to add the generated transaction to the block of the transmitting node if it receives at least one signal from the receiving node or the one or more verification nodes verifying that the transaction is an error, or if it receives a signal from the one or more verification nodes verifying that less than the predetermined number of transactions are normal.

[0012] The processor may delete all blocks of a sending node that contain transactions to which the sender is a party based on a request for deletion of transactions to which the sender is a party.

[0013] The above communication unit receives information related to a service identifier for the generated transaction, and when the processor adds the generated transaction to a block of the transmitting node, it obtains a service identifier through the information related to the service identifier and adds the generated transaction to any one block of a blockchain configured by being distinguished by the acquired service identifier or any one block of a single configured blockchain.

[0014] The communication unit receives a transaction to which the sender is a party, information related to a service identifier for the transaction, and a deletion request for the transaction, and transmits a deletion approval request for the transaction, including the transaction, a hash value of the transaction, and an identifier of a block in which the transaction is stored, to a receiving node of the transaction and one or more verification nodes of the transaction, and receives a verification signal for the deletion approval request for the transaction from the receiving node and the one or more verification nodes, wherein the processor obtains a service identifier through information related to the service identifier when a signal verifying that the deletion approval request for the transaction is normal is received from the receiving node and a signal verifying that a predetermined number or more of the deletion approval requests for the transaction are normal is received from the one or more verification nodes, and can delete all blocks of a blockchain corresponding to the obtained service identifier among blockchains configured to be classified by service identifier.

[0015] The communication unit receives a request for approval of deletion of the transaction from a receiving node, the request including a transaction of the recipient corresponding to the receiving node, a hash value of the transaction, and an identifier of a block in which the transaction is stored, the processor obtains a transaction stored in a block of the transmitting node based on the received transaction, applies a hash function to the transaction obtained from the block of the transmitting node to generate a hash value, and determines that the request for approval of deletion of the transaction of the received recipient is normal when the hash value of the generated transaction matches the hash value of the received transaction, and the communication unit can transmit a signal verifying that the request for approval of deletion of the transaction of the received recipient is normal to the receiving node when it is determined that the request for approval of deletion of the transaction of the received recipient is normal.

[0016] In order to achieve the above technical problem, a receiving node in a blockchain network according to the present invention may include a communication unit that receives a transaction of a recipient corresponding to the receiving node and a hash value of the transaction from a transmitting node and receives a verification signal for the transaction from one or more verification nodes, and a processor that applies a hash function to the received transaction to generate a hash value of the transaction, and adds the received transaction to a block of the receiving node when the hash value of the generated transaction matches the hash value of the received transaction and a signal verifying that a predetermined number or more of the transactions are normal is received from the one or more verification nodes, and adds only transactions to which the recipient is a party among a plurality of transactions in the blockchain network to the block, and the communication unit may transmit a hash value of the generated transaction and a signal verifying that the transaction is normal to the transmitting node and the verification node when the hash value of the generated transaction matches the hash value of the received transaction and a signal verifying that the transaction is normal is received from the one or more verification nodes, and the receiving node may correspond to an individual unique node of the receiver. Can be.

[0017] When adding the received transaction to the block of the receiving node, the processor may generate a list of identifiers of a predetermined number of verification nodes that transmitted a signal verifying that the transaction is normal, and add the list to the block.

[0018] The processor controls not to add the received transaction to the block of the receiving node if the hash value of the generated transaction does not match the hash value of the received transaction, and the communication unit can transmit a signal verifying that the transaction is an error to the transmitting node and the verification node if the hash value of the generated transaction does not match the hash value of the received transaction.

[0019] The processor controls not to add the received transaction to the block of the receiving node when it receives at least one signal verifying that the transaction is an error from the one or more verification nodes, or receives a signal verifying that less than the predetermined number of transactions are normal from the one or more verification nodes, and the communication unit can transmit a signal verifying that the transaction is an error to the transmitting node and the verification node when it receives at least one signal verifying that the transaction is an error from the one or more verification nodes, or receives a signal verifying that less than the predetermined number of transactions are normal from the one or more verification nodes.

[0020] The processor may delete all blocks of a receiving node that contain transactions to which the recipient is a party based on a request for deletion of transactions to which the recipient is a party.

[0021] The above communication unit receives information related to a service identifier for the received transaction, and when the processor adds the received transaction to a block of the receiving node, it obtains a service identifier through the information related to the service identifier and adds the received transaction to any one block of a blockchain configured by being distinguished by the obtained service identifier or any one block of a single configured blockchain.

[0022] The communication unit receives a transaction to which the recipient is a party, information related to a service identifier for the transaction, and a deletion request for the transaction, and transmits a deletion approval request for the transaction, including the transaction, a hash value of the transaction, and an identifier of a block in which the transaction is stored, to a transmitting node of the transaction and one or more verification nodes of the transaction, and receives a verification signal for the deletion approval request for the transaction from the transmitting node and the one or more verification nodes, wherein the processor obtains a service identifier through information related to the service identifier when a signal verifying that the deletion approval request for the transaction is normal is received from the transmitting node and a signal verifying that a predetermined number or more of the deletion approval requests for the transaction are normal is received from the one or more verification nodes, and can delete all blocks of a blockchain corresponding to the obtained service identifier among blockchains configured to be classified by service identifier.

[0023] The communication unit receives a request for approval of deletion of the transaction from the transmitting node, the request including the transaction of the sender corresponding to the transmitting node, the hash value of the transaction, and the identifier of the block in which the transaction is stored, the processor obtains a transaction stored in the block of the receiving node based on the received transaction, applies a hash function to the transaction obtained from the block of the receiving node to generate a hash value, and if the hash value of the generated transaction matches the hash value of the received transaction, it is determined that the request for approval of deletion of the transaction of the received sender is normal, and if the communication unit determines that the request for approval of deletion of the transaction of the received sender is normal, it can transmit a signal verifying that the request for approval of deletion of the transaction of the received sender is normal to the transmitting node.In order to achieve the above technical problem, a verification node in a blockchain network according to the present invention may include a communication unit that receives a transaction and a hash value of the transaction from a transmitting node and receives a hash value of the transaction and a verification signal for the transaction from a receiving node, and a processor that applies a hash function to the received transaction to generate a hash value of the transaction when the received verification signal is a signal verifying that the transaction is normal, applies a reference function to the transaction to generate a reference value of the transaction when the generated hash value matches both the hash values ​​of the transactions received from the transmitting node and the receiving node, and adds the reference value of the generated transaction and the hash value of the generated transaction to a block of the verification node, and the communication unit may transmit a signal verifying that the transaction is normal to the transmitting node, the receiving node, and one or more other verification nodes when the reference value of the transaction and the hash value of the generated transaction are to be added to the block, and the verification node may be characterized in that it corresponds to an individual unique node of a verifier that is distinct from individual unique nodes of a sender and a receiver of the transaction.

[0024] The processor may generate a reference value based on at least one piece of information from among the identifier of the transmitting node, the identifier of the receiving node, the identifier of the block in which the transaction of the transmitting node is stored, the identifier of the block in which the transaction of the receiving node is stored, the identifier of the transaction, and the identifier of the service in which the transaction occurred, using the reference function.

[0025] The processor controls not to add a reference value of the transaction to the block of the verification node and not to add the hash value of the transaction to the block of the verification node if any of the generated hash value, the hash value of the transaction received from the transmitting node, and the hash value of the transaction received from the receiving node do not match, and the communication unit can transmit a signal verifying that the transaction is an error to the transmitting node, the receiving node, and the one or more other verification nodes if any of the generated hash value, the hash value of the transaction received from the transmitting node, and the hash value of the transaction received from the receiving node do not match.

[0026] The communication unit receives a verification signal for the transaction from the one or more other verification nodes, and the processor controls not to add a reference value of the transaction to a block of the verification node and not to add a hash value of the transaction to the block of the verification node when receiving at least one signal verifying that the transaction is an error from the receiving node or the one or more other verification nodes, and the communication unit can transmit a signal verifying that the transaction is an error to a transmitting node, the receiving node, and the one or more other verification nodes when receiving at least one signal verifying that the transaction is an error from the receiving node or the one or more other verification nodes.

[0027] The above communication unit receives information related to a service identifier for the received transaction, and when the processor adds a reference value of the generated transaction and a hash value of the generated transaction to a block of the receiving node, the processor obtains a service identifier through the information related to the service identifier, and adds the reference value of the generated transaction and the hash value of the generated transaction to any one block of a blockchain configured separately for each of the obtained service identifiers or any one block of a single configured blockchain.

[0028] The communication unit receives a request for approval of deletion of a transaction from the transmitting node or the receiving node, the request including a transaction of a sender or a receiver corresponding to the transmitting node or the receiving node, a hash value of the transaction, and an identifier of a block in which the transaction is stored, and the processor applies a hash function to the received transaction to generate a hash value, and generates a reference value based on at least one piece of information from among the received transaction and the identifier of the block in which the received transaction is stored, and if the hash value of the generated transaction matches the hash value corresponding to the received transaction stored in the block of the verification node and the generated reference value matches the reference value corresponding to the received transaction stored in the block of the verification node, it is determined that the request for approval of deletion of the transaction of the received sender or receiver is normal, and if the communication unit determines that the request for approval of deletion of the transaction of the received sender or receiver is normal, it can transmit a signal verifying that the request for approval of deletion of the transaction of the received sender or receiver is normal to the transmitting node or the receiving node.

[0029] In order to achieve the above technical problem, the method for operating a transmitting node in a blockchain network according to the present invention may include a step in which a processor generates a transaction of a sender corresponding to the transmitting node and a hash value of the transaction by applying a hash function to the transaction based on a received transaction request, a step in which a communication unit transmits the transaction and the hash value of the transaction to a receiving node corresponding to a receiver of the transaction and one or more verification nodes that verify the transaction, respectively, and receives a verification signal for the transaction from the receiving node and the one or more verification nodes, a step in which the processor adds the generated transaction to a block of the transmitting node when a signal verifying that the transaction is normal is received from the receiving node and a signal verifying that a predetermined number or more of the transactions are normal is received from the one or more verification nodes, and a step in which the processor adds to the block only transactions to which the sender is a party among a plurality of transactions in the blockchain network, and the transmitting node may be characterized in that it corresponds to an individual unique node of the sender.

[0030] When the processor adds the generated transaction to the block of the transmitting node, the processor may include a step of generating a list of identifiers of a predetermined number of verification nodes that transmitted a signal verifying that the transaction is normal and adding the list to the block.

[0031] The processor may include a step of deleting all blocks of a sending node that contain transactions to which the sender is a party based on a request for deletion of transactions to which the sender is a party.

[0032] The step of the communication unit receiving information related to the service identifier for the generated transaction and, when the processor adds the generated transaction to the block of the transmitting node, obtaining a service identifier through the information related to the service identifier and adding the generated transaction to one block of a blockchain configured by being distinguished by the obtained service identifier or one block of a single configured blockchain may be included.

[0033] The above communication unit may include a step of receiving a request for deletion of a transaction to which the sender is a party and information related to a service identifier for the transaction to which the sender is a party, and a step of the processor obtaining a service identifier through the information related to the service identifier and deleting all blocks of a blockchain corresponding to the obtained service identifier among blockchains configured by being divided by service identifier according to the request for deletion of the received transaction.

[0034] In order to achieve the above technical problem, the method of operating a receiving node in a blockchain network according to the present invention may include the steps of: a communication unit receiving a transaction of a receiver corresponding to the receiving node and a hash value of the transaction from a transmitting node, and receiving a verification signal for the transaction from one or more verification nodes; a step of a processor applying a hash function to the received transaction to generate a hash value of the transaction, and adding the received transaction to a block of the receiving node when the hash value of the generated transaction matches the hash value of the received transaction and a signal verifying that a predetermined number or more of the transactions are normal is received from the one or more verification nodes; a step of the processor adding to the block only transactions to which the receiver is a party among a plurality of transactions in the blockchain network; and a step of transmitting to the transmitting node and the verification node the hash value of the generated transaction and a signal verifying that the transaction is normal when the hash value of the generated transaction matches the hash value of the received transaction and a signal verifying that the transaction is normal is received from the one or more verification nodes, and the receiving node may be configured to have an individual unique identifier of the receiver. It can be characterized by corresponding nodes.

[0035] When the processor adds the received transaction to the block of the receiving node, the processor may include a step of generating a list of identifiers of a predetermined number of verification nodes that transmitted a signal verifying that the transaction is normal and adding the list to the block.

[0036] The processor may include a step of deleting all blocks of a receiving node that contain transactions to which the recipient is a party based on a request for deletion of transactions to which the recipient is a party.

[0037] The step of the communication unit receiving information related to a service identifier for the received transaction, and the step of the processor obtaining a service identifier through the information related to the service identifier when adding the received transaction to a block of the receiving node, and adding the received transaction to one block of a blockchain configured by being distinguished by the obtained service identifier or one block of a single configured blockchain may be included.

[0038] The above communication unit may include a step of receiving a request for deletion of a transaction to which the recipient is a party and information related to a service identifier for the transaction to which the recipient is a party, and a step of the processor obtaining a service identifier through the information related to the service identifier and deleting all blocks of a blockchain corresponding to the obtained service identifier among blockchains configured by being classified by service identifier according to the request for deletion of the received transaction.

[0039] In order to achieve the above technical problem, the method for operating a verification node in a blockchain network according to the present invention may include the steps of: a communication unit receiving a transaction and a hash value of the transaction from a transmitting node, and receiving a hash value of the transaction and a verification signal for the transaction from a receiving node; a step of: applying a hash function to the received transaction to generate a hash value of the transaction when the received verification signal is a signal verifying that the transaction is normal; applying a reference function to the transaction to generate a reference value of the transaction when the generated hash value matches both the hash values ​​of the transactions received from the transmitting node and the receiving node; and a step of: transmitting a signal verifying that the transaction is normal to the transmitting node, the receiving node, and one or more other verification nodes when the reference value of the transaction and the hash value of the generated transaction are to be added to the block; and may be characterized in that the signal corresponds to an individual unique node of a verifier that is distinct from individual unique nodes of a sender and a receiver of the transaction.

[0040] The processor may include a step of generating a reference value based on at least one piece of information from among the identifier of the transmitting node, the identifier of the receiving node, the identifier of the block in which the transaction of the transmitting node is stored, the identifier of the block in which the transaction of the receiving node is stored, the identifier of the transaction, and the identifier of the service in which the transaction occurred, using the reference function.

[0041] The method may include a step of the communication unit receiving information related to a service identifier for the received transaction, and a step of obtaining a service identifier through the information related to the service identifier when the processor adds a reference value of the generated transaction and a hash value of the generated transaction to a block of the receiving node, and adding the reference value of the generated transaction and the hash value of the generated transaction to one block of a blockchain configured separately for each of the obtained service identifiers or one block of a single configured blockchain.

[0042] The effects of the chain-type data storage technology and method that guarantee ownership and control of an individual's data in a highly secure environment according to one embodiment of the present invention are as follows.

[0043] The chain-type data storage technology and method proposed in the present invention provides the advantage of limiting the storage of personal information and sensitive information of users that may be included in transactions to only specific nodes owned by the users, rather than storing them in all nodes of the blockchain network.

[0044] The chain-type data storage technology and method proposed in the present invention provides the advantage of easily deleting a user's personal information and sensitive information from a blockchain network.

[0045] The chain-type data storage technology and method proposed in the present invention provides the advantage of safely storing and deleting a user's personal information and sensitive information in a blockchain network without using a separate relational database, security device, or complex processing process.

[0046] The effects that can be obtained from the invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0047] The accompanying drawings, which are included as part of the detailed description to aid in understanding the present invention, provide embodiments of the present invention and, together with the detailed description, explain the technical idea of ​​the present invention.

[0048] Figure 1 is a diagram illustrating an existing blockchain network (100).

[0049] FIG. 2 is a diagram illustrating an example of a blockchain network (200) according to the present invention.

[0050] Figure 3 is a diagram illustrating the status of transaction data of nodes in an existing blockchain network (100).

[0051] FIG. 4 is a diagram illustrating the status of transaction data of nodes in a blockchain network (200) according to the present invention.

[0052] FIG. 5 is a block diagram illustrating the function of a transmission node according to the present invention.

[0053] Figure 6 is a diagram schematically illustrating the operation of a transmitting node (500) and other nodes when a transaction occurs in a blockchain network (200).

[0054] FIG. 7 is a diagram illustrating a configuration in which the blockchain of each node's user is divided by service identifier in a blockchain network (200) according to the present invention.

[0055] FIG. 8 is a diagram illustrating an operation of processing an owner's transaction deletion request in a node configured by dividing the user's blockchain by service identifier according to the present invention.

[0056] FIG. 9 is a block diagram illustrating the function of a receiving node (900) according to the present invention.

[0057] Figure 10 is a drawing for explaining the operation process of a receiving node (900) and other nodes when a transaction occurs in a blockchain network (200).

[0058] FIG. 11 is another diagram illustrating a configuration in which the blockchain of each node's user is distinguished by service identifier in a blockchain network (200) according to the present invention.

[0059] FIG. 12 is another diagram illustrating an operation of processing an owner's transaction deletion request in a node configured by dividing the user's blockchain by service identifier according to the present invention.

[0060] FIG. 13 is a block diagram illustrating the function of a verification node according to the present invention.

[0061] Figure 14 is a diagram schematically illustrating the operation of a verification node (1300) and other nodes when a transaction occurs in a blockchain network (200).

[0062] FIG. 15 is a diagram illustrating a block state of a node according to one embodiment of a blockchain network (200) according to the present invention.

[0063] FIG. 16 is another diagram illustrating a block state of a node according to one embodiment of a blockchain network according to the present invention.

[0064] The present invention is susceptible to various modifications and embodiments. Specific embodiments are illustrated and described in detail in the drawings. However, this is not intended to limit the present invention to specific embodiments, but rather to encompass all modifications, equivalents, and alternatives falling within the spirit and technical scope of the present invention.

[0065] When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0066] Terms such as first, second, etc. may be used to describe various components, but these components should not be limited by these terms. These terms are used solely to distinguish one component from another.

[0067] The terminology used herein is merely used to describe specific embodiments and is not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this specification, it should be understood that the terms "comprises" or "has" indicate the presence of a feature, number, step, operation, component, part, or combination thereof described in the specification, but do not exclude in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0068] Additionally, terms such as “part,” “unit,” “module,” and “device” described in the specification mean a unit that processes at least one function or operation, which may be implemented by hardware, software, or a combination of hardware and software.

[0069] In some cases, to avoid ambiguity in the concepts of the present invention, well-known structures and devices may be omitted or illustrated in block diagram form focusing on the core functions of each structure and device. Furthermore, the same components are described using the same reference numerals throughout this specification.

[0070] In addition, it is to be understood that the components of the embodiments described with reference to each drawing are not limited to the specific embodiments, but may be implemented to be included in other embodiments within the scope in which the technical idea of ​​the present invention is maintained, and that multiple embodiments may be re-implemented as a single integrated embodiment even if a separate description is omitted.

[0071] Blockchain technology, emerging as a core technology of Web 3.0, offers the advantage of providing a high level of security based on a decentralized distributed ledger and consensus-based architecture. Since the advent of Bitcoin, blockchain-based services have been utilized in various fields to enhance the transparency and security of financial transactions, automate transactions through smart contracts, and optimize supply chain management. However, the adoption of blockchain-based services has been slow due to factors such as insufficient adoption by other companies, lack of knowledge, complexity, the gap between expectations and reality, scale issues, and technical barriers. For blockchain-based services to flourish, a method for protecting personal information using blockchain technology must be established. In particular, a level of personal information protection that complies with the European Union's General Data Protection Regulation (GDPR) must be established at the blockchain architecture level. Due to the conflicting nature of the right to be forgotten, which is mandated by various data protection laws, including the GDPR, and the inherent inability of existing blockchain architectures to delete data, the scope of services that can utilize blockchain technology is severely limited. Recently, with the cryptocurrency craze, various blockchain platforms such as Bitcoin, CORDA R3, IOTA, Hyperledger Fabric, and Ethereum have been developed. However, all of these have been hindered by the lack of personal information protection functions, scalability, and performance issues of existing blockchain technologies in the process of developing services that provide control over personal data using existing blockchain technologies.

[0072] Existing blockchain technology makes it difficult to delete and manage your own data because it doesn't allow data deletion and multiple participants' data is stored together on a single block. Recently, various technical solutions based on blockchain technology have been proposed to achieve GDPR compliance. These include two approaches: one that doesn't store personal information on the blockchain, and the other that uses technologies like Chameleon Hash, Linkable Digital Multi-Signature, and Reconstructable Ephemeral Key with Proof of Redaction to modify blocks. However, the first approach uses hashtags or stores only public keys on the blockchain. Strictly speaking, legal circles interpret public keys as personal information. Furthermore, even when using hashtags, tracking is possible if the hash table is exposed, making it difficult to consider personal information permanently deleted. Furthermore, the second approach requires separate security devices and processing processes to enable data modification and deletion on the blockchain, which requires more resources in terms of development and maintenance.

[0073] Table 1 below presents a look at the major blockchain platforms released so far from the perspectives of personal information control and architecture.

[0074] CategoryBitcoinEthereumHyperLedgerFabricR3 CordaIOTATypePublic BlockchainPublic BlockchainFrameworkFrameworkPublic DAGGeneration1st2nd2nd2nd3rdPermissionedⅩⅩOOOYear Founded20092015201520152017Consensus AlgorithmPoWPoWPBFT, KafkaNotariesPoWTransactions CostHighMedium000Smart Contract EnabledLimited(Scripts)Turing CompleteYES(Chaincode)YESNoHash AlgorithmSHA-256Ethash-Multiple*Keccak / SHA-3Performance~ 5 TPS~ 16 TPS~ 1,500 TPS*~ 1,500 TPS*~ 800 TPSBlock Time10 min16 sec5 sec*No Blocks-Settlement Time1 hour3 minImmediateImmediate3 minBlock Size1 MB224 TX*No Blocks-Data deletionⅩⅩⅩⅩⅩPrivate Data--O--* - Property can be changed or configured

[0075] Bitcoin is primarily used for cryptocurrency transactions and is known for its robust security. However, due to its design focused on financial transactions, it is not commonly used for supply chain management or personal data control. Ethereum is well-known for its smart contract functionality, which allows for complex, programmable transactions with a wide range of purposes. It is more suitable than Bitcoin for applications involving contracts or conditions. Ethereum's transparent architecture allows everyone on the network to view all transactions, which can compromise personal data privacy. Corda R3 is designed for business applications and specializes in facilitating private transactions between known parties, making it suitable for supply chain management, where privacy and efficiency are crucial in business-to-business transactions. Corda's architecture was heavily influenced by the needs of the financial industry, which prioritizes privacy and compliance. Hyperledger Fabric, part of the Linux Foundation's Hyperledger family of products, is designed for enterprises with a focus on modularity and scalability. It supports smart contracts and is ideal for supply chain management due to its flexibility, privacy, and performance. Fabric's architecture allows for the creation of customized blockchains to meet diverse needs. Besu is an enterprise-grade Ethereum client that supports both public and private permissioned networks. It leverages Ethereum's smart contract capabilities, but can be used in supply chains that require privacy and authorization for enterprise applications. IOTA utilizes a tangle architecture instead of a traditional blockchain, making it scalable and suitable for Internet of Things (IoT) applications. This can be useful in scenarios involving numerous IoT devices and sensors, allowing for greater control and integration of personal data in such environments.

[0076] None of the blockchain platforms compared in Table 1 offer a specific method for managing personal information, meaning they are GDPR-compliant. Some blockchain platforms even use a separate storage medium other than the blockchain to manage personal information. Because blockchain technology does not delete data, service providers would violate the law if they entered personal information into the blockchain (ledger) when providing services.

[0077] Research on technical solutions to avoid storing personal information on blocks to comply with GDPR is as follows:

[0078] Zero-Knowledge Proofs (ZKPs) allow one party to prove to another party that they know a value without revealing anything other than their knowledge of the value. This can be particularly useful for verifying transactions on blockchains without exposing underlying personal data. Homomorphic Encryption performs a computation on ciphertext to produce an encrypted result, which, upon decryption, produces an encrypted result that matches the result of the computation performed on plaintext. This can be used to perform private transactions on a public ledger. Secure Multi-Party Computation (SMPC) allows nodes on a network to jointly compute a function on inputs while keeping the inputs private. This can be useful in scenarios where data privacy is important. Private Transaction Protocols (e.g., Zcash's zk-SNARKs) encrypt transaction data using protocols like Zcash's zk-SNARKs, ensuring that only users with a view key can view the transaction contents. Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, self-sovereign digital identities. Personal information is not stored directly on the blockchain. Blockchain anonymization techniques, such as ring signatures, stealth addresses, and coin mixing, help anonymize blockchain transaction participants.

[0079] However, there is a problem that it is difficult to view personal information as permanently deleted, as the method of avoiding storing personal information in blocks is to use hashtags or to store only public keys in the blockchain, but strictly speaking, there is a legal interpretation that public keys can also be viewed as personal information, and even if hashtags are used, it is difficult to view personal information as permanently deleted, as tracking is possible if the hash table is exposed.

[0080] Research on technical solutions for modifying blockchain data in blockchain technology is as follows.

[0081] Chameleon Hash is a technique that can be used to modify data on a blockchain. It modifies the message within a block while maintaining the hash checksum. This allows data modification without altering the root of the Merkle tree, making it applicable to private, permissioned, and public blockchains. Chameleon Hash with Secret Sharing is based on Chameleon Hash, but grants more users the ability to modify the block and provides insight into the new content within the block. This system requires the approval of the block publisher, but this approval requirement can be lifted under certain conditions. For example, when a key holder leaves the network or other predefined triggers occur. Linkable Digital Multi-Signature focuses on specific blockchain implementations rather than hash functions. This method allows the sender of a transaction to request removal by revealing their identity or the contents of the transaction. This approach is particularly complex and can be challenging to implement in new networks. The Reconstructable Ephemeral Key with Proof of Redaction method aims to provide evidence of block modification while minimizing the impact on the block. This method utilizes two temporary trapdoors to enable block modification and proposes Proof of Redaction to track and verify block modifications.

[0082] However, the methods proposed so far for modifying blockchain data have the problem of requiring more resources in terms of development and maintenance, as they require separate security devices and processing processes to enable modification and deletion of data from the blockchain.

[0083] Each node in a conventional blockchain network stores a single blockchain, consisting of multiple linked blocks. Depending on the service provided, the blockchain may contain various pieces of information. When viewing a blockchain network from the perspective of providing transaction services between users, each node's blockchain contains all transaction information for the service, which can be referred to as a ledger.

[0084] To help understand the present invention, more precise meanings and definitions of various terms used in the present invention are explained.

[0085] A transaction is the smallest unit of a work process, consisting of one or more sequences of operations required to produce a result that complies with governing rules. A record refers to information created, received, and stored as evidence and assets (anything of value to stakeholders) by an organization in the course of fulfilling legal obligations or conducting business. Furthermore, a transaction record is a record that documents all types of transactions.

[0086] A ledger is an information repository that stores a record of transactions that is final, definitive, and immutable. A ledger record includes a record containing a transaction record, a hash value of a transaction record, or a reference to a transaction record recorded on the ledger.

[0087] A Distributed Ledger Technology Network (DLT Network) refers to a network of DLT nodes that constitute a DLT system. Here, a DLT system refers to a system implementing a distributed ledger, and a DLT node refers to a distributed ledger technology node device or process that participates in the network and stores full or partial copies of the ledger records. The blockchain network of the present invention refers to a DLT network.

[0088] Services on a blockchain network may include software components, functions, and programs that execute functions, and may be indicated in the diagram as SVC1, SVC2, etc. to distinguish between different services.

[0089] Figure 1 is a diagram illustrating an existing blockchain network (100).

[0090] As illustrated in FIG. 1, in an existing blockchain network (100), each node stores a ledger, and this ledger stores identical content in all nodes. That is, when a transaction occurs in which User A transfers money equivalent to 100 to User B, the blockchain network (100) converts this transaction into a data form called a transaction, including all information necessary for the transaction, such as the sender, receiver, transaction amount, transaction date, and transaction items, and stores it identically in the blockchain of each node. All nodes, including Node_1, Node_2, Node_3, and Node_4 illustrated in FIG. 1, store the same valid transaction corresponding to the above transaction.

[0091] In the example above, if User A wanted to delete all of the transactions in the above transaction that contained his personal information, there was no way to do so in the existing blockchain network.

[0092] FIG. 2 is a diagram illustrating an example of a blockchain network (200) according to the present invention.

[0093] As illustrated in FIG. 2, each node of the blockchain network (200) according to the present invention stores different transactions, unlike the nodes of the existing blockchain network (100). Node_1 illustrated in FIG. 2 is a unique node of user Alice (same as an individual mainnet), and the blockchain of this node stores only transactions to which Alice is a party in transactions occurring on the blockchain network (200).

[0094] Here, a transaction to which I am a party means a transaction in which I am the sender or recipient, and the transaction that expresses this transaction as data contains identifying information that can identify me.

[0095] For example, in a transaction where user Alice transfers $100 to user Bob, the transaction includes Alice's identity as the sender, so Alice is considered a party to the transaction. Similarly, Bob is considered a party to the transaction, so Bob is considered a party to the transaction. However, Claire's identity is not included in the transaction, so Claire is not considered a party to the transaction.

[0096] Each user of the blockchain network (200) according to the present invention has his / her own individual unique node, and only data generated from transactions to which he / she is a party among all transactions occurring and transmitted in the blockchain network (200) is stored in his / her individual unique node. This is one of the major differences from the existing blockchain network (100). In the existing blockchain network (100), there is no node corresponding to my individual unique node, and transactions to which I am a party are stored in all nodes of the network. However, in the blockchain network (200) according to the present invention, my individual unique node exists, and only transactions to which I am a party are stored in my individual unique node, and transaction information to which I am not a party cannot be stored in my individual unique node. When looking at this from the perspective of transactions to which I am a party, transactions to which I am a party are stored only in my individual unique node or in the individual unique node of the user who is a party to the transaction to which I am a party.

[0097] In the following description, in the blockchain network (200) according to the present invention, many individual unique nodes are owned nodes of each user, and here, the owned node may mean a node over which the user has actual control authority or a node over which the user has usage authority.

[0098] For example, Alice's individual unique node, Node_1, could be expressed as "Alice's node," "Alice's node," or "Alice's mainnet." The chain-type personal data that guarantees ownership and control of an individual's data in a highly secure environment according to the present invention can be referred to as "My Chain," etc.

[0099] Therefore, in the blockchain network (200) according to the present invention, if user Alice wishes to delete all transactions containing her personal information, the simplest solution is to simply delete the block information stored in Node_1 of FIG. 2. A more detailed explanation of the deletion of the user's transactions will be provided below.

[0100] The difference between the existing blockchain network and the blockchain network according to the present invention can be clearly understood by comparing FIGS. 3 and 4.

[0101] FIG. 3 is a diagram illustrating the state of transaction data of nodes in an existing blockchain network (100), and FIG. 4 is a diagram illustrating the state of transaction data of nodes in a blockchain network (200) according to the present invention.

[0102] In Fig. 3, all nodes in the existing blockchain network (100) store valid transaction data equally. However, in the blockchain network (200) according to the present invention, the transaction data of Node_1 owned by A and Node_2 transmitted by B are stored differently.

[0103] ViewpointExisting blockchain network (100)Blockchain network according to the present invention (200)Blockchain structure by nodeEach node has the same valid block number and structure.The number of blockchains and block numbers are different for each node.Number of blockchainsOne valid and independent blockchain.One or more valid and independent blockchains.Transaction by nodeEach node contains the same / valid transaction data.All nodes own different transaction data.Ledger by nodeSeveral users and different services are stored in one ledger.Different ledgers can be stored for each topic for one user.Data integrationDifferent data is stored for each blockchain network.Data integration is difficult if there is no compatibility between blockchain networks.Personal data can be stored in one blockchain network (individually identified node).

[0104] Table 2 shows the differences between the existing blockchain network (100) and the blockchain network (200) according to the present invention according to the perspective.

[0105] Nodes constituting the blockchain network (200) according to the present invention may function as transmitting nodes, receiving nodes, or verification nodes, depending on the transaction, or may not play any role in the transaction. The verification nodes of the present invention may be referred to as guarantor nodes or participating nodes that are not parties (transmitting nodes or verification nodes), and serve to guarantee or verify transactions between two parties. Hereinafter, they will be referred to as verification nodes.

[0106] That is, in the case of a transaction in which user Alice transfers money equivalent to 100 to user Bob in FIG. 2, from the perspective of this transaction, Alice's individual unique node, Node_1, becomes the sending node, Bob's individual unique node, Node_2, becomes the receiving node, Node_3 and Node_4, which perform the verification function for the above transaction, become verification nodes, and Node_N, which does not perform the verification function for the above transaction, plays no role. Whether a specific node provides a verification function for a transaction to which it is not a party can be set by the node owner or determined by the policy of the entire blockchain network or the service provided thereon.

[0107] The method of designating Node_1 as an individual unique node for user Alice can be implemented in various ways, such as when user Alice first creates account information in the blockchain network (200) according to the present invention, she prepares Node_1 herself and adds it to the blockchain network (200), or when she newly creates Node_1 on a virtual machine in the entire blockchain network and adds it to the blockchain network (200).

[0108] The architecture of the blockchain network (200) according to the present invention may have the following eight characteristics.

[0109] 1) One blockchain can be maintained per account or service.

[0110] 2) When requesting deletion, agreement from other nodes is required.

[0111] 3) A deletion unit is a single block with a unique number.

[0112] 4) The blockchain can be deleted in whole or in part (e.g. 2 or 3 blocks).

[0113] 5) Some of the data in the block cannot be modified.

[0114] 6) Transaction data is stored only in the blocks of the transaction parties.

[0115] 7) The validator does not store the sender and receiver data in its block, but only has the location information of the data.

[0116] 7) The transaction number has a unique value across the entire blockchain network. (The transaction number can be used to track service numbers, wallets, and users.)

[0117] FIG. 5 is a block diagram illustrating the function of a transmission node according to the present invention.

[0118] As illustrated in FIG. 5, a transmission node (500) according to the present invention may include a processor (510), a communication unit (520), and a storage unit (530).

[0119] The communication unit (520) of the transmitting node (500) constituting the blockchain network (200) may include an external network interface and RPC (Remote Procedure Call) that can transmit and receive data with external nodes, a loop back network interface that can transmit and receive data between processes and threads within the node, and various IPC (Inter-Process Communication) including PIPE, Message Queue, and Shared Memory. The storage unit (530) of the transmitting node (500) may include volatile memories such as DRAM and cache, and non-volatile memories such as various flash memories, magnetic disks, and optical disks. When a transaction occurs in the blockchain network (200), the node owned by the sender of the transaction, i.e., the transmitting node, will be described.

[0120] In FIG. 5, the processor (510) of the transmitting node can control to generate a transaction in which the owner of the transmitting node is the sender based on the transaction information and to temporarily store the generated transaction in the storage unit (530). Here, the transaction may include the wallet address of the sender of the transaction, the wallet address of the recipient, information on the value of the money to be transferred, etc., and in the case of services such as proof of ownership and proof of real estate transaction, personal information that must be protected such as the individual's real name, resident registration number, address, and family relationships may be included. In this way, the transactions applied or used in the blockchain network (200) architecture of the present invention include various types of transactions such as monetary transactions and security token offerings (STOs). However, in the following description of the present invention, a simple example in which a sender sends money to a recipient will be explained to help understand the invention.

[0121] In order to prevent falsification of the wallet used for the transaction, the processor (510) of the transmitting node can check whether there is any falsification of previous transactions stored in all blockchains of the transmitting node or some blockchains related to the transaction before generating the transaction. The processor (510) of the transmitting node can control to apply the generated transaction to a predetermined hash function to generate a hash value of the transaction and to temporarily store the hash value of the generated transaction in the storage unit (530). The communication unit (520) of the transmitting node transmits the temporarily stored transaction and the hash value of the transaction to the node owned by the recipient of the transaction, i.e., the receiving node, and the nodes that provide the function of verifying the transaction, i.e., the verification nodes. The communication unit (520) can then receive a verification signal for the transmitted transaction from the receiving node and one or more verification nodes. The processor (510) of the transmitting node may store the transaction in the storage unit (530) where the block of the blockchain is stored when a signal verifying that the transaction is normal is received from the receiving node and a signal verifying that a predetermined number or more of transactions are normal is received from one or more verification nodes. Here, the number of signals verifying that a predetermined number or more of transactions are normal may be designated as a fixed value or may be set in various ways, such as 2 / 3 or more of all nodes of the blockchain network or 2 / 3 or more of verification nodes.

[0122] While a node acts as a transmitting node for a specific transaction, it can also act as a receiving node or verification node for other transactions. However, personal information stored in a node's block is limited to transactions in which the owner is a party to the transaction. Only transactions contain personal information, while other data that can be stored in a node include hash values, which are irreversible, and reference values ​​and verification node identifiers do not contain any personal information. The transmitting node (500) can generate a list of identifiers of a predetermined number of verification nodes that transmitted a signal verifying the normality of the transaction and add it to the transmitting node's (500) block. The transmitting node (500) can also store this list of verification nodes to track the verification nodes that participated in the verification of the transaction at any time. From the perspective of the transmitting node (500), the operation process between the receiving node (900), which is the counterparty of the transmitting node (500), and the verification nodes (1300) that perform the verification of the transaction will be described with reference to FIG. 6.

[0123] Figure 6 is a diagram schematically illustrating the operation of a transmitting node (500) and other nodes when a transaction occurs in a blockchain network (200).

[0124] In Fig. 6, Node_1 owned by User A operates as a transmitting node (500), Node_2 owned by User B operates as a receiving node (900), and Node_3 owned by User C and Node_N owned by User N operate as verification nodes.

[0125] Referring to FIG. 6, the communication unit (520) of the transmitting node (500) can transmit a transaction (e.g., TR#001: “A->B, 100”) and a hash value of the transaction (e.g., HASH(TR#001)) to the receiving node (900) and the verification node. Here, TR#001 is numbered to distinguish the transaction and means transaction number 001. Thereafter, the transmitting node (500) can receive a verification signal for this transaction from the receiving node (900) and one or more verification nodes (1300).

[0126] When the communication unit (520) of the transmitting node (500) receives a signal (TR#001 is OK) verifying that a transaction (e.g., TR#001: “A->B, 100”) is normal from the receiving node (900) and receives a signal (TR#001 is OK) verifying that a predetermined number or more of transactions (e.g., TR#001: “A->B, 100”) are normal from the verification nodes (1300), the processor (510) of the transmitting node (500) can determine that the transaction is normal and control the storage unit (530) to store the generated transaction in a block (590) of the blockchain.

[0127] In addition, if the transaction is determined to be normal, the processor (510) of the transmitting node (500) can control the storage unit (530) to store information about the identifier list (e.g., VAL_LIST (TR#001): “Node_3, …, Node_N) for the verification nodes that transmitted the signal verifying that the transaction is normal in the block (590) of the blockchain.

[0128] If the communication unit (520) of the transmitting node (500) receives a signal verifying that the transaction is an error from the receiving node (900) or one or more verification nodes (1300), the processor (510) of the transmitting node (500) may determine the transaction as abnormal and may not add information about the identifier list (e.g., VAL_LIST(TR#001): “Node_3, …, Node_N) for the generated transaction (e.g., TR#001: “A->B, 100”) and the verification nodes that transmitted the signal verifying that the transaction is normal to the block (590) of the transmitting node (500). In addition, if the communication unit (520) of the transmitting node (500) does not receive a predetermined number or more of signals verifying that the transaction is normal even though it receives signals verifying that the transaction is normal from one or more verification nodes, the processor (510) of the transmitting node (500) may determine the transaction as abnormal and may not add information about the identifier list (e.g., VAL_LIST(TR#001): “Node_3, …, Node_N) for the generated transaction (e.g., TR#001: “A->B, 100”) and the verification nodes that transmitted the signal verifying that the transaction is normal to the block (590) of the transmitting node (500). "A->B, 100") and information about the identifier list (e.g., VAL_LIST(TR#001): “Node_3, …, Node_N) for the verification nodes that transmitted the signal verifying that the transaction is normal may not be added to the block (590) of the transmitting node (500). Here, the number of signals verifying that a certain number or more of transactions are normal may be designated as a fixed value or may be set in various ways, such as 2 / 3 or more of all nodes of the blockchain network or 2 / 3 or more of the verification nodes.

[0129] As one embodiment of the present invention, the blockchain of each node may be configured to be distinguished by a service identifier. Here, the service identifier used by the transmitting node (500) to distinguish the blockchain may be included in the transaction or received through a separate data exchange without being included in the transaction.

[0130] FIG. 7 is a diagram illustrating a configuration in which the blockchain of each node's user is divided by service identifier in a blockchain network (200) according to the present invention.

[0131] Referring to Figure 7, User A owns a node called Node_1, and it can be confirmed that separate blockchains are configured for each service identifier (SVC1, SVC2, SVC3). User A conducted transactions with other users as the sender or receiver of each transaction using services SVC1, SVC2, and SVC3, respectively, and these transactions can be understood as being included in blocks of the blockchain identified by each service identifier.

[0132] The owner of a transmitting node can delete the blockchain containing the owner's transaction data stored on the owned node by distinguishing it by service identifier.

[0133] In one embodiment of the present invention, when the communication unit (520) of the transmitting node receives information related to a service identifier for a transaction and a deletion request for a transaction to which the sender is a party, the communication unit (520) of the transmitting node may transmit a deletion approval request for the transaction, including transaction data, a hash value of the transaction, and an identifier of a block in which the transaction is stored, to the receiving node of the transaction and one or more verification nodes of the transaction. Here, the transaction data transmitted to the receiving node and the verification node may include a transaction identifier, identifiers of the transaction parties (identifiers of the sender and the receiver), and all data related to the transaction.

[0134] The communication unit (520) of the transmitting node may receive a verification signal for the approval request from the receiving node of the transaction and one or more verification nodes of the transaction in response to the deletion approval request transmitted to the receiving node of the transaction and one or more verification nodes of the transaction. Here, the processor (510) of the transmitting node may determine that the deletion approval request of the corresponding transaction has been normally approved if a signal verifying that it is normal is received from the receiving node and a predetermined number or more of signals verifying that it is normal are received from one or more verification nodes. If it is determined that the deletion approval request has been normally approved, the processor (510) of the transmitting node may obtain a service identifier through information related to the service identifier of the previously received transaction, and control to delete all blocks of the blockchain corresponding to the obtained service identifier among the blockchains configured to be distinguished by service identifier. As another embodiment for deleting the owner's transaction data, if the processor (510) of the transmitting node in the above example determines that the deletion approval request has been normally approved, the communication unit (520) of the transmitting node may be implemented in a manner such that, for a transaction to which the sender is a party, the information related to the service identifier for the transaction is not received or the processor (510) of the transmitting node does not use it, and all blockchains of the nodes owned by the user are deleted.

[0135] FIG. 8 is a diagram illustrating an operation of processing an owner's transaction deletion request in a node configured by dividing the user's blockchain by service identifier according to the present invention.

[0136] In Figure 7, a request may be made from Node_1 to delete a transaction from Owner A for service identifier SVC1. At this time, Node_1 may delete all transactions for SVC1 in response to the transaction deletion request for service identifier SVC1. Figure 8 illustrates the blockchain state of Node_1 after the transaction deletion for SVC1 is completed.

[0137] FIG. 9 is a block diagram illustrating the function of a receiving node (900) according to the present invention.

[0138] As illustrated in FIG. 9, a receiving node (900) according to the present invention may include a processor (910), a communication unit (920), and a storage unit (930).

[0139] In the receiving node (900) constituting the blockchain network (200) according to the present invention, the communication unit (920) may include an external network interface and RPC (Remote Procedure Call) capable of transmitting and receiving data with external nodes, a loop back network interface capable of transmitting and receiving data between processes and threads within the node, and various IPC (Inter-Process Communication) including PIPE, Message Queue, and Shared Memory. The storage unit (930) of the receiving node (900) may include volatile memories such as DRAM and cache, and non-volatile memories such as various flash memories, magnetic disks, and optical disks. When a transaction occurs in the blockchain network, the node owned by the recipient of the transaction, i.e., the receiving node (900), will be described.

[0140] In FIG. 9, the communication unit (920) of the receiving node (900) can receive a transaction in which the owner of the receiving node (900) is the recipient and a hash value of the transaction from the transmitting node (500), and can receive a verification signal for the transaction from one or more verification nodes.

[0141] The processor (910) of the receiving node (900) can control the processor to apply a hash function to the received transaction to generate a hash value of the transaction and temporarily store the generated hash value of the transaction in the storage unit (930).

[0142] When the processor (910) of the receiving node (900) determines that the transaction is normal when the temporarily stored hash value matches the hash value of the transaction received from the transmitting node (500) and receives a signal verifying that a predetermined number or more of transactions are normal from one or more verification nodes, the processor (910) can control the transaction to be stored in the storage unit (930) where the block of the blockchain is stored. The number of signals verifying that a predetermined number or more of transactions are normal can be designated as a fixed value or can be set in various ways, such as 2 / 3 or more of all nodes of the blockchain network or 2 / 3 or more of verification nodes.

[0143] If the communication unit (920) of the receiving node (900) determines that the transaction is normal, it can transmit the hash value of the generated transaction and a signal verifying that the transaction is normal to the transmitting node (500) and one or more verification nodes (1300). Even while a node is performing the role of the receiving node (900), it can also perform the roles of the transmitting node (500) and the verification node (1300) for other transactions. However, personal information stored in the block of the node is only stored in transactions where the owner is a party to the transaction. Data that can be stored in one node includes personal information only in transactions, and data that can be stored in other nodes includes a hash value, which is irreversible, and the reference value and the identification value of the verification node do not include any personal information. The receiving node (900) can generate a list of identifiers of a predetermined number of verification nodes that have transmitted a signal verifying that the transaction is normal and add the list to the block of the receiving node. The receiving node (900) stores the list information of these verification nodes, enabling it to track the verification nodes that participated in the verification of the transaction at any time. From the perspective of the receiving node (900), the operation process of the transmitting node (500), the counterparty of the receiving node (900), and the verification nodes (1300) that perform the verification of the transaction will be described with reference to FIG. 10.

[0144] Figure 10 is a drawing for explaining the operation process of a receiving node (900) and other nodes when a transaction occurs in a blockchain network (200).

[0145] In Fig. 10, Node_2 owned by User B operates as a receiving node (900), Node_1 owned by User A operates as a transmitting node (500), and Node_3 owned by User C and Node_N owned by User N operate as verification nodes.

[0146] Referring to FIG. 10, the communication unit (920) of the receiving node (900) can receive a transaction (e.g., TR#001: “A->B, 100”) and a hash value of the transaction (e.g., HASH(TR#001)) from the transmitting node (500).

[0147] The processor (910) of the receiving node (900) can control the receiving node (900) to apply a hash function to the received transaction (e.g., TR#001: “A->B, 100”) to generate a hash value of the transaction itself, and to temporarily store the hash value of the generated transaction in the storage unit (930). If the processor (910) of the receiving node (900) determines that the temporarily stored hash value matches the hash value of the received transaction (HASH(TR#001)) and receives a predetermined number or more of signals verifying that the transaction is normal from one or more verification nodes, the processor (910) can determine that the transaction is normal and control the storage unit (930) to store the received transaction in a block (990) of the blockchain. If the transaction is determined to be normal, the communication unit (920) of the receiving node (900) can transmit a hash value of the transaction (e.g., HASH(TR#001)) and a verification signal for the transaction (e.g., TR#001 is OK) to the transmitting node (500) and one or more verification nodes (Node_3(1300), Node_N, etc.). In addition, if the transaction is determined to be normal, the processor (910) of the receiving node (900) can control the storage unit (930) to store information on the identifier list (e.g., VAL_LIST(TR#001): “Node_3, …, Node_N) for the verification nodes that transmitted the signal verifying that the transaction is normal in the block (990) of the blockchain. If the communication unit (920) of the receiving node (900) receives a signal verifying that the transaction is an error from one or more verification nodes, the processor (910) of the receiving node (900) determines the transaction to be abnormal and does not add the received transaction (e.g., TR#001: “A->B, 100”) and the information on the identifier list (e.g., VAL_LIST(TR#001): “Node_3, …, Node_N) for the verification nodes that transmitted the signal verifying that the transaction is normal in the block (990) of the receiving node (900). It may not be possible.

[0148] In addition, if the communication unit (920) of the receiving node (900) does not receive a predetermined number or more of signals verifying that a transaction is normal from one or more verification nodes even though the communication unit (920) of the receiving node (900) determines the transaction as abnormal and may not add information about the identifier list (e.g., VAL_LIST(TR#001): “Node_3, …, Node_N) for the verification nodes that transmitted the signals verifying that the transaction is normal to the block (990) of the receiving node (900). Here, the number of signals verifying that a predetermined number or more of transactions are normal may be designated as a fixed value or may be set in various ways, such as 2 / 3 or more of all nodes of the blockchain network or 2 / 3 or more of the verification nodes.

[0149] As one embodiment of the present invention, the blockchain of each node may be configured to be distinguished according to a service identifier, and the service identifier, wallet address, and other identification information used by the receiving node (900) to distinguish the blockchain may be included in the transaction or may be received through a separate data exchange without being included in the transaction.

[0150] FIG. 11 is another diagram illustrating a configuration in which the blockchain of each node's user is distinguished by service identifier in a blockchain network (200) according to the present invention.

[0151] Referring to Figure 11, it can be seen that User B owns a node called Node_2 and that separate blockchains are configured for each service identifier (SVC3, SVC4, SVC5, SVC6). User B used services SVC3, SVC4, SVC5, and SVC6 to conduct transactions with other users as the recipient or sender of each transaction, and it can be understood that these transactions are included in blocks of the blockchain identified by each service identifier.

[0152] The owner of the receiving node (900) can delete the blockchain containing the owner's transaction data stored in the owned node by distinguishing them by service identifier.

[0153] In one embodiment of the present invention, when the communication unit (920) of the receiving node (900) receives information related to a service identifier for a transaction and a deletion request for a transaction to which the receiver is a party, the communication unit (920) of the receiving node may transmit a deletion approval request for the transaction, including transaction data, a hash value of the transaction, and an identifier of a block in which the transaction is stored, to the sending node of the transaction and one or more verification nodes of the transaction. Here, the transaction data transmitted to the sending node and the verification nodes may include a transaction identifier, identifiers of the transaction parties (identifiers of the sender and the receiver), and all data related to the transaction. The communication unit (920) of the receiving node may receive a verification signal for the approval request from the sending node of the transaction and one or more verification nodes of the transaction in response to the deletion approval request transmitted to the receiving node of the transaction and the one or more verification nodes of the transaction. Here, the processor (910) of the receiving node can determine that the request for approval of deletion of the transaction has been approved normally if a signal verifying normality is received from the transmitting node and a predetermined number or more of signals verifying normality are received from one or more verification nodes.

[0154] If it is determined that the deletion approval request is normally approved, the processor (910) of the receiving node may obtain a service identifier through information related to the service identifier for the previously received transaction, and control to delete all blocks of the blockchain corresponding to the obtained service identifier among the blockchains configured by being classified by service identifier. As another embodiment for deleting the owner's transaction data, if the processor (910) of the receiving node in the above example determines that the deletion approval request is normally approved, the communication unit (920) of the receiving node may be implemented in a manner that, for a transaction to which the recipient is a party, the information related to the service identifier for the transaction is not received, or the processor (910) of the receiving node does not use it, and all blockchains of the node owned by the user are deleted.

[0155] FIG. 12 is another diagram illustrating an operation of processing an owner's transaction deletion request in a node configured by dividing the user's blockchain by service identifier according to the present invention.

[0156] In Figure 11, a request may be made from Node_2 to delete a transaction from Owner B for service identifier SVC3. At this time, Node_2 may delete all transactions for SVC3 in response to the transaction deletion request for service identifier SVC3. Figure 12 illustrates the blockchain state of Node_2 after the transaction deletion for SVC3 is completed.

[0157] FIG. 13 is a block diagram illustrating the function of a verification node (1300) according to the present invention.

[0158] As illustrated in FIG. 13, a verification node (1300) according to the present invention may include a processor (1310), a communication unit (1320), and a storage unit (1330).

[0159] In the verification node (1300) constituting the blockchain network (200) according to the present invention, the communication unit (1320) may include an external network interface and RPC (Remote Procedure Call) capable of transmitting and receiving data with external nodes, a loop back network interface capable of transmitting and receiving data between processes and threads within the node, and various IPC (Inter-Process Communication) including PIPE, Message Queue, and Shared Memory. The storage unit (1330) of the verification node (1300) may include volatile memories such as DRAM and cache, and non-volatile memories such as various flash memories, magnetic disks, and optical disks. When a transaction occurs in the blockchain network (200), a description will be given of a node owned by a user who is not a party to the transaction, i.e., a verification node.

[0160] In FIG. 13, the communication unit (1320) of the verification node (1300) can receive a transaction and a hash value of the transaction from the transmission node (500), and can receive a hash value of the transaction generated by the reception node (900) and a verification signal for the transaction from the reception node (900). The processor (1310) of the verification node (1300) can control the hash value of the transaction to be generated by applying a hash function to the received transaction, and the hash value of the generated transaction to be temporarily stored in the storage unit (1330).

[0161] The processor (1310) of the verification node (1300) may apply a reference function to the transaction to generate a reference value of the transaction if the verification signal for the transaction received from the receiving node (900) is a signal verifying that the transaction is normal and the temporarily stored hash value matches both the hash value of the transaction received from the transmitting node (500) and the hash value of the transaction received from the receiving node (900). The processor (1310) may control the storage unit (1330) to store the reference value of the generated transaction and the hash value of the temporarily stored transaction in a block of the blockchain. The processor (1310) may generate the reference value based on at least one of the following information: the identifier of the transmitting node (500), the identifier of the receiving node (900), the identifier of the block in which the transaction of the transmitting node (500) is stored, the identifier of the block in which the transaction of the receiving node (900) is stored, the identifier of the transaction, and the identifier of the service in which the transaction occurred.

[0162] While a node is acting as a verification node, it can also act as a transmitting node (500) or receiving node (900) for other transactions. However, personal information stored in the node's block is limited to transactions in which the owner is a party to the transaction. When acting as a verification node (1300), the data added to the block includes a hash value, but it is irreversible, and the reference value does not contain any personal information. The operation process for a transaction between a transmitting node (500) and a receiving node (900) from the perspective of a verification node (1300) is described with reference to FIG. 14.

[0163] FIG. 14 is a diagram for explaining the operation process of a verification node (1300) and other nodes when a transaction occurs in a blockchain network (200) according to the present invention.

[0164] In Fig. 14, Node_3 (1300) owned by User C and Node_N owned by User N are operating as verification nodes, Node_1 owned by User A is operating as a transmitting node (500), and Node_2 owned by User B is operating as a receiving node (900).

[0165] Referring to FIG. 14, the communication unit (1320) of the verification node (1300) can receive a transaction (e.g., TR#001: “A->B, 100”) and a hash value of the transaction (e.g., HASH(TR#001)) from the transmission node (500). In addition, the communication unit (1320) of the verification node (1300) can receive a hash value of the transaction generated by the reception node (900) (e.g., HASH(TR#001)) and a verification signal for the transaction from the reception node (900).

[0166] The processor (1310) of the verification node (1300) can control the processor to apply a hash function to a received transaction (e.g., TR#001: “A->B, 100”) to generate a hash value of the transaction, and to temporarily store the generated hash value of the transaction in the storage unit (1330).

[0167] The processor (1310) of the verification node (1300) can determine that the transaction is normal if the verification signal for the transaction received from the receiving node (900) is a signal verifying that the transaction is normal (e.g., TR#001 is OK) and the temporarily stored hash value matches both the hash value of the transaction received from the transmitting node (500) (e.g., HASH(TR#001)) and the hash value of the transaction received from the receiving node (900) (e.g., HASH(TR#001)).

[0168] If the transaction is determined to be normal, the processor (1310) of the verification node (1300) can apply a reference function to the transaction to generate a reference value (REF(TR#001)) of the transaction, and control the storage unit (1330) of the verification node (1300) to store the transaction together with the hash value (HASH(TR#001)) of the temporarily stored transaction in a block (1390) of the blockchain. If the transaction is determined to be normal, the communication unit (1320) of the verification node (1300) can transmit a verification signal (e.g., TR#001 is OK) for the transaction to the transmitting node (500), the receiving node (900), and one or more verification nodes (Node_3(1300), Node_N, etc.).

[0169] In another embodiment of the present invention, if the transaction is determined to be normal, a verification signal (e.g., TR#001 is OK) for the transaction may be transmitted only to the transmitting node (500) and the receiving node (900) to reduce network traffic. If the communication unit (1320) of the verification node (1300) receives a verification signal from the receiving node (900) indicating an error in the transaction, the processor (1310) of the verification node (1300) may determine the transaction to be abnormal.

[0170] In addition, if the temporarily stored hash value does not match even one of the hash values ​​of the transaction received from the transmitting node (500) (e.g., HASH(TR#001)) and the hash value of the transaction received from the receiving node (900) (e.g., HASH(TR#001)), the transaction may be judged as abnormal.

[0171] If the transaction is determined to be normal, the processor (1310) of the verification node (1300) can control not to add the reference value of the generated transaction and the hash value of the transaction to the block (1390) of the verification node (1300).

[0172] In the case of the verification node (1300), since it is not a party to the transaction but participated in the verification, the transaction (TR#001: "A->B, 100") is not stored in the block (1390). However, in order to prevent the verification node (1300) from being maliciously modified and storing transaction data containing personal information without permission, the transmission node (500) may preprocess and transmit the transaction (TR#001: "A->B, 100") to the verification node (1300).

[0173] In one embodiment of the present invention, the blockchain of each node may be configured to be distinguished by a service identifier. The service identifier used by the verification node (1300) to distinguish the blockchain may be included in the transaction or received through a separate data exchange without being included in the transaction. The verification node (1300) may receive a deletion approval request for a transaction that the verification node (1300) has verified as normal.

[0174] As one embodiment according to the present invention, the communication unit (1320) of the verification node (1300) may receive, from the transmitting node (500) or the receiving node (900), a request for approval of deletion of a transaction including the transaction of the sender or receiver, the hash value of the transaction, and the identifier of the block in which the transaction is stored, for a transaction that the verification node (1300) has verified to be normal.

[0175] The processor (1310) of the verification node (1300) can control the processor to apply a hash function to the received transaction to generate a hash value, and to generate a reference value based on at least one piece of information among the identifier of the received transaction and the block in which the received transaction is stored, and to temporarily store the reference value in the storage unit (1330) of the verification node (1300).

[0176] The processor (1310) of the verification node (1300) determines that the received request for approval of deletion of a transaction from a sender or receiver is normal if the temporarily stored hash value and reference value match the hash value and reference value already stored in the storage unit (1330) of the verification node (1300). If the request for approval of deletion of a transaction from a sender or receiver is determined to be normal, a signal is transmitted to the transmitting (500) node or the receiving node (900) verifying that the received request for approval of deletion of a transaction from a sender or receiver is normal.

[0177] Looking again at Figure 7, if Node_1 owned by User A participated in the verification of a transaction to which another user was a party for Service SVC1, it can be understood that the blockchain of Service SVC1 includes in its block not only the transaction to which User A was a sender or receiver, but also the reference value and the hash value of the transaction to which the other user was a party. Even in this case, if User A requests Node_1 owned by Node_1 to delete the transaction of Owner A for the service identifier SVC1, if there is a transaction to which Owner A was a party for Service SVC1, the request to delete the transaction of Owner A can be processed as shown in Figure 8.

[0178] FIG. 15 is a diagram illustrating the block status of each node according to one embodiment of a blockchain network (200) according to the present invention.

[0179] Figure 15 comprehensively illustrates a transmitting node (500), a receiving node (900), and a verification node (1300) based on the embodiments described so far. Users A, B, C, and D initially had no data stored in the blocks of their owning nodes, and the block states of each node after a transaction in which User A sent 100 to User B was issued are shown. Here, User A's owning node acted as a transmitting node, User B's owning node acted as a receiving node, and User C's and User D's owning nodes acted as verification nodes, respectively.

[0180] FIG. 16 is another diagram illustrating the block status of each node according to one embodiment of a blockchain network (200) according to the present invention.

[0181] Figure 16 illustrates the block state after an additional transaction occurs in the state of Figure 15. That is, it shows the block state of each node when User C remits 200 to A. Here, User C's own node acts as a sending node, User A's own node acts as a receiving node, and User B and User C's own nodes act as verification nodes.

[0182] The architecture of the blockchain network (200) according to the present invention, as described above, creates blocks for each individual, service, and wallet, and when deleting a block, deletes the entire block for each individual, enabling deletion without affecting other blockchains in a simple manner. Therefore, applications can be implemented without complexity, and because deletion creates free storage space, scalability issues can be easily resolved.

[0183] The embodiments described above are combinations of components and features of the present invention in a predetermined form. Each component or feature should be considered optional unless explicitly stated otherwise. Each component or feature may be implemented without being combined with other components or features. Furthermore, it is also possible to form an embodiment of the present invention by combining some components and / or features. The order of operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is self-evident that claims that do not have an explicit citation relationship in the patent claims may be combined to form an embodiment or may be incorporated as a new claim through a post-application amendment.

[0184] In the present invention, the processor (510, 910, 1310) may be implemented by hardware, firmware, software, or a combination thereof. When implementing an embodiment of the present invention using hardware, ASICs (Application Specific Integrated Circuits) or DSPs (Digital Signal Processors), DSPDs (Digital Signal Processing Devices), PLDs (Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays), etc. configured to perform the present invention may be provided in the processor (510, 910, 1310). The method for preventing user information leakage during user authentication according to the present invention may also be implemented as a computer-readable recording medium recording a program for executing the method on a computer.

[0185] It will be apparent to those skilled in the art that the present invention can be embodied in other specific forms without departing from the essential characteristics thereof. Therefore, the above detailed description should not be construed as limiting in any respect, but rather as illustrative. The scope of the present invention should be determined by a reasonable interpretation of the appended claims, and all modifications within the scope of equivalents of the present invention are intended to be included within the scope of the present invention.

[0186] Chain-based data storage technology, which guarantees ownership and control of personal data in a high-security environment, is industrially available through various blockchain-based services that provide high security while realizing self-control over personal data to protect personal information.

Claims

1. In a sending node in a blockchain network, a processor that generates a hash value of a transaction by applying a hash function to a transaction of a sender corresponding to the sending node and the transaction based on the received transaction request; and transmits the transaction and the hash value of the transaction to a receiving node corresponding to a receiver of the transaction and one or more verification nodes that verify the transaction, including a communication unit that receives a verification signal for the transaction from the receiving node and the one or more verification nodes, wherein the processor, when a signal verifying that the transaction is normal is received from the receiving node and signals verifying that the transaction is normal for a predetermined number or more of the transactions are received from the one or more verification nodes, adds the generated transaction to a block of the sending node, and adds only the transactions of which the sender is a party among a plurality of transactions in the blockchain network to the block, the sending node is characterized in that it corresponds to an individual unique node of the sender. Sending node.

2. According to claim 1, when adding the generated transaction to a block of the sending node, the processor generates a list of identifiers of a predetermined number of verification nodes that have transmitted a signal verifying that the transaction is normal and adds the list to the block. Sending node.

3. According to claim 1, the communication unit receives information related to a service identifier for the generated transaction, when adding the generated transaction to a block of the sending node, the processor obtains a service identifier through the information related to the service identifier and adds the generated transaction to any block of a blockchain configured to be separated by the obtained service identifier or any block of a single configured blockchain. Sending node. [[ID= The communication unit receives a transaction in which the sender is a party, information related to a service identifier for the transaction, and a deletion request for the transaction, and transmits a deletion approval request for the transaction, including the transaction, a hash value of the transaction, and an identifier of a block in which the transaction is stored, to a receiving node of the transaction and one or more verification nodes of the transaction. Upon receiving a verification signal for the deletion approval request for the transaction from the receiving node and the one or more verification nodes, the processor When a signal verifying that the deletion approval request for the transaction from the receiving node is normal is received and a signal verifying that the deletion approval requests for a predetermined number or more of the transactions from the one or more verification nodes are normal is received, the sender node obtains a service identifier through the information related to the service identifier and deletes all blocks of the blockchain corresponding to the obtained service identifier among the blockchains configured to be separated by service identifier.

5. In the case of a receiving node in a blockchain network A communication unit that receives a transaction of a receiver corresponding to the receiving node and a hash value of the transaction from a sender node and receives a verification signal for the transaction from one or more verification nodes; and A processor that applies a hash function to the received transaction to generate a hash value of the transaction, adds the received transaction to a block of the receiving node when the generated hash value of the transaction matches the received hash value of the transaction and a signal verifying that a predetermined number or more of the transactions from the one or more verification nodes are normal is received, and adds only the transactions in which the receiver is a party among a plurality of transactions in the blockchain network to the block. The communication unit When the hash value of the generated transaction matches the hash value of the received transaction and a signal verifying the normalcy of the transaction is received from at least a predetermined number of the one or more verification nodes, the transmitting node and the one or more verification nodes are transmitted with the hash value of the generated transaction and a signal verifying the normalcy of the transaction, The receiving node is characterized by corresponding to the individual unique node of the receiver, receiving node.

6. According to claim 5, When the processor adds the received transaction to the block of the receiving node, the receiving node generates a list of identifiers of a predetermined number of verification nodes that have transmitted a signal verifying the normalcy of the transaction and adds the list to the block.

7. According to claim 5, The communication unit receives information related to a service identifier for the received transaction, When the processor adds the received transaction to the block of the receiving node, the receiving node obtains a service identifier through the information related to the service identifier and adds the received transaction to any one block of a blockchain configured to be separated by the obtained service identifier or any one block of a single configured blockchain.

8. According to claim 5, The communication unit receives a transaction in which the receiver is a party, information related to a service identifier for the transaction, and a deletion request for the transaction, and transmits a deletion approval request for the transaction, including the transaction, the hash value of the transaction, and the identifier of the block in which the transaction is stored, to the transmitting node of the transaction and one or more verification nodes of the transaction, Receiving a verification signal for the deletion approval request of the transaction from the transmitting node and the one or more verification nodes, The processor, When a signal verifying the normalcy of a deletion approval request for the transaction is received from the transmitting node and signals verifying the normalcy of deletion approval requests for a predetermined number or more of the transactions are received from the one or more verification nodes, the receiving node obtains a service identifier through information related to the service identifier and deletes all blocks of the blockchain corresponding to the obtained service identifier among the blockchains configured separately for each service identifier.

9. A verification node in a blockchain network, a communication unit that receives a transaction and a hash value of the transaction from a transmitting node and receives the hash value of the transaction and a verification signal for the transaction from a receiving node; and a processor that, when the received verification signal is a signal verifying the normalcy of the transaction, applies a hash function to the received transaction to generate a hash value of the transaction, and when the generated hash value matches all of the hash values of the transaction received from the transmitting node and the receiving node, applies a reference function to the transaction to generate a reference value of the transaction, and adds the generated reference value and the generated hash value of the transaction to a block of the verification node, provided that the communication unit transmits a signal verifying the normalcy of the transaction to the transmitting node, the receiving node, and one or more other verification nodes when the reference value of the transaction and the generated hash value of the transaction need to be added to the block, and the verification node corresponds to an individual unique node of a verifier that is distinct from the individual unique nodes of the sender and the receiver of the transaction.

10. According to claim 9, The processor is a verification node that generates a reference value based on at least one piece of information among the identifier of the sending node, the identifier of the receiving node, the identifier of the block in which the transaction of the sending node is stored, the identifier of the block in which the transaction of the receiving node is stored, the identifier of the transaction, and the identifier of the service in which the transaction occurred, using the reference function.

11. According to claim 9, The communication unit receives information related to the service identifier for the received transaction, When adding the reference value of the generated transaction and the hash value of the generated transaction to the block of the verification node, the processor obtains the service identifier through the information related to the service identifier, and adds the reference value of the generated transaction and the hash value of the generated transaction to any block of the blockchain configured separately for each obtained service identifier or to any block of a single configured blockchain. The processor is a verification node.

12. According to claim 9, The communication unit receives a deletion approval request for the transaction of the sender or receiver corresponding to the sending node or the receiving node, including the transaction, the hash value of the transaction, and the identifier of the block in which the transaction is stored, from the sending node or the receiving node. The processor, applies a hash function to the received transaction to generate a hash value, generates a reference value based on at least one piece of information among the received transaction and the identifier of the block in which the received transaction is stored, and determines that the deletion approval request for the transaction of the received sender or receiver is normal when the generated hash value of the transaction matches the hash value corresponding to the received transaction stored in the block of the verification node and the generated reference value matches the reference value corresponding to the received transaction stored in the block of the verification node. When it is determined that the request for deletion approval of the transaction of the received sender or receiver is normal, the communication unit transmits a signal verifying that the request for deletion approval of the transaction of the received sender or receiver is normal to the sending node or the receiving node, which is a verification node.

13. In a method of operating a sending node in a blockchain network, a step of generating a hash value of a transaction by applying a hash function to a transaction of a sender corresponding to the sending node and the transaction based on the received transaction request by a processor; a step in which a communication unit transmits the transaction and the hash value of the transaction to a receiving node corresponding to a receiver of the transaction and one or more verification nodes for verifying the transaction, and receives a verification signal for the transaction from the receiving node and the one or more verification nodes; a step of adding the generated transaction to a block of the sending node when a signal verifying that the transaction is normal is received from the receiving node and signals verifying that the transaction is normal are received from at least a predetermined number of the one or more verification nodes; and a step of adding only transactions in which the sender is a party among a plurality of transactions in the blockchain network to the block by the processor, wherein the sending node corresponds to an individual unique node of the sender, the method of operating a sending node.

14. In a method of operating a receiving node in a blockchain network, a step in which a communication unit receives a transaction of a receiver corresponding to the receiving node and a hash value of the transaction from a sending node and receives a verification signal for the transaction from one or more verification nodes; The step of the processor applying a hash function to the received transaction to generate a hash value of the transaction, and adding the received transaction to the block of the receiving node when the generated hash value of the transaction matches the hash value of the received transaction and a signal verifying the normality of the transaction is received from at least a predetermined number of the one or more verification nodes; The step of the processor adding only the transactions of which the receiver is a party among the plurality of transactions in the blockchain network to the block; and The step of the communication unit transmitting the generated hash value of the transaction and a signal verifying the normality of the transaction to the transmitting node and the verification node when the generated hash value of the transaction matches the hash value of the received transaction and a signal verifying the normality of the transaction is received from at least a predetermined number of the one or more verification nodes, The method of operating a receiving node, characterized in that the receiving node corresponds to the individual unique node of the receiver.

15. In the method of operating a verification node in a blockchain network, The step of the communication unit receiving a transaction and the hash value of the transaction from a transmitting node and receiving the hash value of the transaction and a verification signal for the transaction from a receiving node; The step of the processor applying a hash function to the received transaction to generate a hash value of the transaction when the received verification signal is a signal verifying the normality of the transaction, generating a reference value of the transaction by applying a reference function to the transaction when the generated hash value matches both the hash values of the transaction received from the transmitting node and the receiving node, and adding the generated reference value and the generated hash value of the transaction to the block of the verification node; and When the communication unit needs to add the reference value of the transaction and the hash value of the generated transaction to the block, transmitting a signal verifying the normality of the transaction to the transmitting node, the receiving node, and one or more other verification nodes; The verification node corresponds to an individual unique node of a verifier that is distinct from the individual unique nodes of the transmitter and receiver of the transaction. A method of operating a verification node, characterized thereby.

Images