WO2020022531A1 - Procédé et système de connexion de chaîne basée sur un retard temporel dynamique dans une chaîne de blocs à base de pop - Google Patents

Procédé et système de connexion de chaîne basée sur un retard temporel dynamique dans une chaîne de blocs à base de pop Download PDF

Info

Publication number
WO2020022531A1
WO2020022531A1 PCT/KR2018/008400 KR2018008400W WO2020022531A1 WO 2020022531 A1 WO2020022531 A1 WO 2020022531A1 KR 2018008400 W KR2018008400 W KR 2018008400W WO 2020022531 A1 WO2020022531 A1 WO 2020022531A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
transaction
signed
merger
nodes
Prior art date
Application number
PCT/KR2018/008400
Other languages
English (en)
Korean (ko)
Inventor
양대헌
강전일
응웬다오딩
신동오
Original Assignee
주식회사 더볼터
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 더볼터 filed Critical 주식회사 더볼터
Publication of WO2020022531A1 publication Critical patent/WO2020022531A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1046—Joining mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information

Definitions

  • the following description provides a dynamic time delay based chain connection method and system in a PoP based blockchain.
  • the block chaining rules of the block are prevented from being merged by the merger to create the block within the dynamic delay time from the creation time of the previous block.
  • a method of chaining nodes participating in a blockchain network comprising: receiving a block generated by an amalgamator of the blockchain network; Calculating a dynamic delay time for the received block; And validating the received block by comparing the difference between the generation time of the previous block generated by the merger and the generation time of the received block and the dynamic delay time. to provide.
  • calculating the dynamic delay time the distance function between the IDs of the optimal signers for the next block calculated from the previous block and the IDs of the actual signers participating in the signature of the received block. And calculate the dynamic delay time to be proportional to the calculated distance exponentially, linearly, or stepwise.
  • the calculating of the dynamic delay time may include calculating a distance between an ID of an optimal merger for a next block calculated from the previous block and an ID of an actual merger participating in a signature of the received block through a distance function. And calculating the dynamic delay time to be proportional to the calculated distance exponentially, linearly, or stepwise.
  • the step of calculating the dynamic delay time, the dynamic to be exponentially, linearly or stepwise proportional to the product of the difficulty distance and the calculated distance determined based on the block generation frequency of the actual merger It may be characterized by calculating the delay time.
  • the calculating of the dynamic delay time may include calculating the dynamic delay time such that the dynamic delay time increases as a difficulty variable determined based on a difference between a generation time of a final block and a current time increases. It may be characterized by.
  • the validating step further includes validating a validity of a time sequence of the received block, a validity of a transaction included in the received block, and a signature included in the received block. It can be characterized.
  • the chain connection method may further include connecting the validated block to each of a plurality of different chains separated by soft forks.
  • the chain linking method may include: when the validated blocks are connected and there are chains in which m or more blocks (m is a natural number of 2 or more) are connected from a soft fork, the plurality of different chains may be different.
  • the method may further include deleting a chain having fewer than m blocks from the soft fork.
  • a computer program stored in a computer-readable recording medium for executing the chain linking method on a computer is provided.
  • a computer-readable recording medium having recorded thereon a program for executing the chain connection method on a computer.
  • a node participating in a blockchain network comprising: at least one processor implemented to execute computer readable instructions, wherein the at least one processor receives a block generated by an amalgamator of the blockchain network Calculates a dynamic delay time for the received block, compares the difference between the generation time of the previous block generated by the merger and the generation time of the received block, and the dynamic delay time. Provide a node to validate the block.
  • the block chaining rules of the block are prevented from being merged by the merger to create the block within the dynamic delay time from the creation time of the previous block. can do.
  • FIG. 1 is a diagram illustrating an example of a P2P ledger protocol according to an embodiment of the present invention.
  • FIG. 2 is a diagram for one example of information included in a new block added to a signed blockchain according to one embodiment of the present invention.
  • FIG. 3 is a diagram for one example of selecting signers for a new block based on a previous block according to one embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an example in which a p2p book is protected against forking a block according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating an example of an operating environment of a network system according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating an example of an internal configuration of a computer device according to one embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating an example of a signature method in an embodiment of the present invention.
  • FIG. 8 is a flowchart illustrating an example of a method for adding a transaction block according to an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating a soft fork and an example of a block in a block chain.
  • FIG. 10 is a flowchart illustrating an example of a block validation process according to an embodiment of the present invention.
  • FIG. 11 is a flowchart illustrating an example of a process of processing a validated block according to an embodiment of the present invention.
  • Embodiments of the present invention describe techniques for a p2p ledger that implements a universal financial platform for fiat currencies without issuing any cryptocurrencies.
  • embodiments of the present invention introduce a new concept of "Proof of Population" based on real name identity. It can be used as a p2p ledger for banks, as an influential tool for settlement, and can be used for any financial transactions. Furthermore, it distributes the costs held by third parties to peers that cannot be centralized. Since the energy requirements are very low, it is possible to run software according to embodiments of the present invention on a smartphone or personal computer.
  • a third trusted authority is assumed to be required to conduct records transactions in a trusted manner. In this model, participants need trust to believe that the records are not modified. Instead of providing trust, the third trust authority receives transaction costs from the participants. This is well done if the participants in the network generally agree on the cost of running a third party, such as a bank. However, if it is impossible to establish a third-party trust institution that technically, economically and politically protects the transaction, then a decentralized but not counterfeit online transaction record is needed. Furthermore, even if a third trust authority already exists, it is more preferable to use a distributed ledger if feasible, when the cost of maintaining the third trust authority is too large to create an unfair advantage, rather than technically or economically unavoidable. . Providing decentralized ledgers and eliminating third parties has a significant impact on markets run by trust institutions by providing another competitive technology that does not rely on third parties.
  • Bitcoin provided the concept of removing the centralized currency foundry and decentralizing the books of the online currency system.
  • coins are issued in a distributed way by peers managing a single global constant ledger.
  • Nakamoto has developed a new voting mechanism that resolves discrepancies in the books by voting by anonymous peers. Since nodes in the Internet cannot be accurately distinguished, a mechanism for realizing one vote per node is required. Because identities such as IP addresses can be easily captured, Bitcoin uses so-called proof-of-work (PoW) to effectively implement the abstract concept of one vote per CPU.
  • PoW proof-of-work
  • PoS proof-of-stake
  • Non-Transparency All transactions are processed under arbitrary addresses whose owner cannot be verified.
  • Non-decentralization Hashing of power or equity is dominated by small groups of people.
  • Cryptocurrencies efficiently realize online money systems so that they are not traceable as real currencies. Since the introduction of Bitcoin, much focus has been placed on cryptocurrencies, which has triggered a flood of cryptocurrency systems (about 1,300 cryptocurrencies). However, almost all cryptocurrencies using the block chain concept are untraceable. Just as cash in the real world is not easy to track even when used for crimes such as money laundering and tax avoidance, cryptocurrencies can't be tracked except when they are exchanged for real currency on an exchange. However, modern society is moving toward a more transparent economy due to credit cards, check cards and pay. The current cash model is gradually being eliminated by these alternatives. However, the cryptocurrencies represented by Bitcoin go in the opposite direction. An example of that opacity was in March 2017 that the US SEC decided not to list the Winklevoss Bitcoin Trust due to the opacity of the transaction.
  • decentralization means that the contributions and rewards for the network are distributed evenly to the participants.
  • Bolckchain.info the top seven mining groups occupy more than 70% of the world's hashing power. It is speculated that cryptocurrencies have not been as decentralized as expected when they were first proposed. Proof of ownership also allows high- stakeholders to control their books and reports that double spending is possible. To prevent centralization by small groups of people, one-on-one voting is the solution and other alternatives are just similar ones.
  • Embodiments of the present invention propose a p2p financial platform that can achieve both true decentralization and high levels of transparency while protecting book-level privacy. Instead of using inefficient PoW based voting, the system according to an embodiment of the present invention uses a much safer, faster, scalable and eco-friendly proof-of-population (PoP) based voting.
  • PoP proof-of-population
  • Closed ecosystems Bookkeeping technologies rely on closed ecosystems to maintain stable economic incentives for miners.
  • cryptocurrency is a reward and transactions are made only of cryptocurrencies.
  • the p2p financial platform can enable banks to sell financial products, and allow consumers to open accounts that do not operate on a central server.
  • BGP Byzantine Generals Problem
  • PoW Proof of Work
  • Blocks holding multiple transactions with PoW are linked to one public ledger organized by blockchain.
  • PoW is calculated by network participants called “miners” and miners are rewarded with transaction costs and coinbase in the form of cryptocurrencies.
  • miners network participants
  • miners are rewarded with transaction costs and coinbase in the form of cryptocurrencies.
  • the attackers To modify the book, attackers fork the chain by adding other transactions to the existing blockchain and adding PoWs that catch up and override the existing chain. To do this, the attacker must have more computing power to calculate the PoW for the blockchain.
  • the created blockchain reaches a point longer than the existing chain, the attacker opens the forged chain and asks to replace it with this new chain.
  • the attacker or group of attackers must have 51% or more computing power to succeed in the attack (51% attack).
  • private / consortium blockchains in which the identity of participating nodes are known to each other and the nodes are operated by organizations It can only be seen as a redundant distribution of databases for security purposes.
  • the entities in the private or consortium blockchain have real identity and can easily be identified with each other, and thus can easily agree without PoW / PoS when a mismatch occurs in the database.
  • Current experimental projects based on private or consortium blockchains focus on the efficiency of coherence between security and distributed database systems obtained by redundant database management by interested entities.
  • PBFTs Byzantine fault tolerance protocols
  • our blockchain has both the openness of the Public Block Chain and the high throughput of the Private Block Chain.
  • it appears to be a private blockchain because it is operated by anonymous, authenticated nodes rather than anonymous nodes.
  • it also appears to be a public chain, in that nodes can freely join and leave our network and blocks are signed by arbitrary nodes of no interest. This is not an anonymous network, but a network operated by real name authenticated peers, so all recorded transactions can be identified by government authorities if necessary.
  • the new ledger can serve as the ultimate P2P financial platform for dealing with any type of asset, including physical and cryptocurrencies.
  • the innovation of the public blockchain is to resolve book mismatches by enabling anonymous voting by PoW. Even if the identity of a node is unknown, if there is a way to distinguish between two votes coming from one node (duplicate votes) or two votes coming from other nodes (two valid votes), Can be counted. In the case of duplicate votes, one of the two votes may be ignored. In this case, votes can be counted without expensive PoW calculations.
  • the real name based identifier and its digital signature may serve for this purpose. Although real name identification is excessive for voting only, it aims to be a real name traceable platform for high-decentralized, high-transparent ledgers, thus perfectly meeting the purposes according to embodiments of the present invention.
  • a p2p ledger according to embodiments of the present invention using real name based pseudonyms and digital signatures may be seen as a variant of the private / consortium blockchain in which the block is identified by an explicit majority vote.
  • a book can be freely accessed and left by anyone once it is identified by its real name, and the book access is not controlled by anyone and the block can be signed by arbitrary peers.
  • It is a kind of public blockchain.
  • the operating environment of the public chain is different from the private chain. The number of signers is large, and excessive forking is frequently caused by large network delays. Therefore, we need a different strategy from the PBFT-based majority voting algorithm that is taken by private / consortium blockchains such as Hyperledger.
  • the problem here is how to implement signature-based majority voting in an efficient, secure and decentralized way in a distributed p2p network.
  • Our approach to the problem is to: 1) carefully balance the gains and losses of attackers by transaction volume, transaction cost, and completion time; and 2) to prevent attackers from counterfeiting their books through full traceability. Take advantage.
  • PoP makes decisions based on the cumulative number of people who support the block. Therefore, when forking occurs by an attack or asynchronous that generates several versions of the chain, a chain with a larger population or a chain supported by more voters is chosen as the chain that wins the game.
  • nodes in a PoP network There are two kinds of nodes in a PoP network.
  • One kind of node contributes to maintaining the open ledger by digitally signing the block, while the other kind of node gathers multiple transactions into one block, requests nodes to sign the block, and signs ) And contribute by linking it to an existing blockchain.
  • the former node is called the signer and the latter node is called the merger.
  • the signer receives a signature request for a transaction block, the signer displays a message to the user confirming that the PoP wallet should generate a signature. This can be done automatically by setting up informed consent for automatic signatures.
  • the signature module is executed on a terminal capable of installing an application such as a smartphone is considered.
  • the signer can make some money as a reward for signing the block.
  • the merger collects and verifies a certain number of transactions to construct a trading block.
  • the merger must collect a certain number of valid signatures for the block from the signers and insert them into the block.
  • the merger's software (module for collecting and inserting valid signatures) may also be run on the merger's terminal, such as a smartphone or desktop / server computer.
  • the aggregator node has to advertise or promote itself in order to get more signers to join their network and quickly collect as many signatures as needed. When the signer joins the network, it will register itself with the mergers and the mergers will ask the signer to sign the block.
  • FIG. 1 is a diagram illustrating an example of a P2P ledger protocol according to an embodiment of the present invention.
  • the first dashed line box 110 shows an example of a signed blockchain as a P2P ledger according to the present embodiment
  • FIG. 1 shows that the merger 120 has one transaction between the user and / or one between the user and the merchant.
  • An example of a case of adding a new block 111 of a signed block chain displayed in the first dotted line box 110 by merging into blocks is shown.
  • FIG. 1 illustrates transaction 1 131 and transaction 2 132, a plurality of transactions generated after the previous block 112 of the block 111 to be newly added are approved and delivered to the merger 120. May include transactions of.
  • the transaction record including the amount of money, the date / time, the purpose of the transaction and their IDs is signed using A's and B's private signature keys and A Sent to the mergers by either B or B;
  • the transaction 1 131 between the user and the user may include information on the amount of money, date / time, transaction purpose, and IDs of two users.
  • Transaction 1 131 may also be signed 133 by two users' private signature keys and sent to the mergers.
  • a transaction record may be substantially transmitted to each of the plurality of mergers.
  • Transaction 1 may include information about the amount of money, date / time, transaction purpose, and the user's ID and the merchant's ID.
  • Transaction 2 132 may also be signed 134 by the user's personal signature key and the merchant's personal signature key and sent to the mergers.
  • the transactions 131, 132 may be signed by the signers 141, 142, 143.
  • the signers 141, 142, 143 provide signatures 151, 152, 153 for the new block 111 at the request of the merger 120.
  • the signers to participate in the signature for the new block 111 may be selected according to the manner to be described later.
  • the merger 120 may sign 121 a new block 111 and broadcast it to all mergers, and the new block 111 approved by the mergers appears in the first dotted box 110. Can be added as the last block of the signed blockchain. The manner in which mergers approve a block is described in more detail later.
  • a transaction may be signed by an account holder and sent to a merger, and a block containing multiple transactions may be signed to signers and mergers.
  • FIG. 2 is a diagram for one example of information included in a new block added to a signed blockchain according to one embodiment of the present invention.
  • FIG. 2 includes transaction 1 131 with signature 141 and transaction 2 132 with signature 142 added to the end of the signed blockchain described with reference to FIG.
  • Block 111 is signed 151, 152, 153 by signers 141, 142, 143.
  • the merger 120 also indicates that a new block 111 has been signed 121.
  • PoP networks require how many people support the block, an individual must be authenticated in real name by a p2p bank before entering the network.
  • a user When a user is authenticated, he creates his own publickey / private key pair and pseudonym and gets the signature from the p2p bank. Therefore, the role of the p2p bank is to authenticate the user and issue public key certificates for aliases and public key pairs. The user stores all of this in the wallet, but the public key and alias pair signed by the p2p bank are registered on the blockchain, the p2p bank stores the real name, and the public key and alias are stored as tuples in the database. .
  • This database created by multiple p2p banks, must be shared to distinguish nodes or can be managed by a single trust authority.
  • the role of the authorities here is limited to the management of blind and pseudonym pairs, but not related to transaction processing.
  • the public key can be updated by adding new public key and alias pairs on the book if needed. Similarly, aliases can be updated by re-registering in the database, but change logs must also be maintained.
  • a user who has successfully registered an authentication on a book can serve as a signer, a consolidator and / or a consumer if desired.
  • the transaction record including the amount of money, date / time, transaction purpose and their IDs, is signed using A and B's private signature keys and A and B Sent to the mergers by either.
  • Mergers are selected by the sender according to the rank of the mergers profiled in the wallet.
  • the merger who receives the transaction record validates the record and merges some records to create a transaction block.
  • the merger collects a predetermined (but periodically adjusted) number of signatures as soon as possible to add the block to the chain. Signers and mergers can only create signatures for blocks created after they join the network.
  • the signers for a block are not arbitrarily chosen by the merger, but are chosen by a hash value that is the output of a function whose output is random because it is random and unpredictable but deterministic, depending on the input. Can be.
  • the hash value may be generated through a hash function preset in each of the mergers.
  • the signers may be selected according to the hash value as a result of the hash function having the information extracted from the transaction records of the previous block as a parameter. Therefore, to change the signature group for an attack, it is necessary to change the transactions of the previous block so that their hash value selects the attacker's signer group.
  • the transactions of the previous block must be changed.
  • changing the signature group of one block involves changing all signature groups of all preceding blocks and all subsequent blocks.
  • FIG. 3 is a diagram for one example of selecting signers for a new block based on a previous block according to one embodiment of the present invention.
  • 3 illustrates a new block 111 and a previous block 112 of the new block described with reference to FIG. 1.
  • the previous block 112 may include information about transaction a 310, transaction b 320 and transaction c 330, similar to those described with reference to FIG. It can include a signature.
  • the previous block 112 may include a previous hash value 340 generated based on the previous block of the previous block 112.
  • the merger (eg, the merger 120 described with reference to FIG. 1) has information about the transaction a 310, the transaction b 320 and the transaction c 330 included in the previous block 112 as parameters.
  • the hash function 350 may generate a hash value for the new block 111.
  • the newly generated hash value may be included in the new block 111 as in the previous hash value 360 shown in FIG. 3.
  • the merger may select the signers 370 based on the hash value generated through the hash function 350. For example, the signers 141, 142, 143 of FIG. 1 may be selected by the signer IDs that the merger 120 calculated based on the hash value.
  • the merger may send a new block 111 to the signers 370 to receive the signatures 151, 152, and 153 of the signers 370 and merge.
  • a block in a PoP network may be signed to signers and mergers, and a group of signers may be forced by a hash value for a transaction of the previous block.
  • the merger collects the transactions in the block, calculates the signer ID, finds the signers with the closest ID among the signers registered in the signer management list of the merger, and sends the block to the signers.
  • the merger waits until it gets some signatures on the block, and if successful, signs the block and broadcasts the multi-signed block to all mergers.
  • Mergers use the hash of the approved block as the previous hash to notify block approval by working to create the next block in the chain.
  • the signer must hold all block IDs signed. The signer checks the following and signs the block.
  • the time stamp in the block does not match the current time considering the time synchronization error on the distributed network, report it to the authority and ignore the block (e.g. in a Bitcoin network, the block has a time stamp of the last 11 blocks. If greater than the median, it is accepted as valid).
  • the signing request from the merger will be automatically rejected.
  • the signer ignores the request and notifies the merger. This notice has the effect of prompting the merger with the message "You are late. The transaction has already been added.”
  • the signer reports to the authorities and broadcasts the merger ID and sender ID to the network to drive the user who made the request out of the network. Now all requests from this attacker will be ignored.
  • Signers may be disqualified over time by the merger to ensure an even distribution of transaction costs.
  • block Is added to the chain and the next block Is added to the chain Receives one approval from the network. After a predetermined number of grants, the block is permanently added to the chain and after this permanent grant another forking request will not be granted. Therefore, the consolidator must choose one of the competing fork blockchains with the earliest time stamp for the latest permanent approval. This limits the forking discussion into the time frame after the latest permanent approval.
  • embodiments of the present invention may adopt GHOST (Greedy Heaviest-Observed Sub-Tree).
  • GHOST Hy Heaviest-Observed Sub-Tree
  • the idea is not to eliminate contending branches, but to leave branches to support the blocks from which the branches are forked. Now instead of choosing the longest chain, we choose the heaviest chain that the largest population supports.
  • the signer group for is selected by hashing the transaction content on the previous blocks and the list of signers in the signer group, excluding signatures and chain hashes.
  • the list is Can be calculated by Is the list of transactions and signers on the i th block, and t ( ⁇ 1) is the final threshold. This traceability of the signature group and the applied but unpredictable choice makes it more difficult to damage the books.
  • the signer ID selected by the hash value may not be valid because the signer has not yet joined or the signer with the ID may not be activated.
  • the closest ID in the hamming distance will be selected and the score for selecting the longest chain can be calculated as in Equation 1 below.
  • the number of my signers, 128 could be an example of the bit length of the ID, Is the hamming distance between the j th signer and the hash output.
  • New signers join the network through mergers, and they participate in the signature processing from the next block.
  • S is the number of signers to sign the block. Every 2 seconds is a reference point for collecting S signatures. This is calculated by measuring 1,800 block creation times, the number of which is recorded in blocks. If it is too slow to collect S signatures, only the minimum S (e.g. 5) is retained for security purposes.
  • the attacker has two choices. One is to forge signatures in the block, which is not feasible by the EUF-CMA security of the signature. Instead of breaking the cryptographic signature, one can buy the signature group of the block. This method replaces the signer group and puts the signatures of their own signer group.
  • 4 is a diagram illustrating an example in which a p2p book is protected against forking a block according to an embodiment of the present invention.
  • 4 shows a block Bi-1 411, a target block Bi 412 and a block Bi + 1 413 as part of a signed blockchain, in which the target block Bi 412 is the signer group a 421. Is signed, and the block Bi + 1 413 is signed by the signer group b 422.
  • the signer group a 421 is selected based on the hash value for the transaction of the block Bi-1 411, so that the forger uses a different signer group to obtain a signature for the counterfeit block Bi '431.
  • This requires the forger to sequentially forge all previous blocks of block Bi-1 411.
  • Forgers can also attempt to conspiracy against signers.
  • the counterfeiter has a burden of public advertising in order to collect conspirators, and the signers for signing the following counterfeit block Bi + 1 '432 are selected by the transaction contents of the counterfeit block Bi' 431.
  • the signer group selected for the forged block Bi + 1 '432 is different from the signer group b 422 of the normal block Bi + 1 413 as the signer group x 441 as shown in FIG. do.
  • not only the next counterfeit block Bi + 1 '432 but all the counterfeit blocks of the counterfeiter to be added afterwards must continually compete with the normal blocks attempted by multiple consolidators by duplicate signatures. The race must be repeated for the last block of the signed blockchain.
  • the first and most important device is a fully traceable blindness-based ledger.
  • the strongest motivation comes from the fact that all nodes have already been authenticated blind and that all transactions on the books are fully traceable. Therefore, nodes in the network know enough that the crime is perfectly traceable and likely to be discovered.
  • the second device is that private forks are impossible, so public advertising is inevitable for forking.
  • miners can secretly make forks for double payments by calculating PoW faster than other miners until they distribute a private fork to replace the actual chain.
  • creating a forking chain R group of signers approximately R ⁇ S two or more accurately approximately 200 signatories
  • the consolidator who forges the block will not be able to fork privately, since it must conspire.
  • at least one of the signers proposed by the counterfeit merger should know that the block has already been completed with a high probability (the block is completed after the time of the network distance). Therefore, any signer will report a double payment attempt to the authority.
  • the third device is that the incentives given to each competition signer are less than the transaction cost.
  • F % be the transaction cost and TA is the maximum limit per block.
  • M % of TA is the maximum limit per block.
  • R be the signer group size for the block and the number of blocks for confirmation, respectively.
  • Number of signers Is determined by the network speed, and R is determined by the network distance. For clarity, suppose S is the average number of signers for a block. At this point, the best scenario for an attacker is to forge a block that has just been established because only the minimum number of blocks needs to be re-signed. The attacker falsifies the block so that his trade in money consumption is eliminated.
  • the forged block loses M x TA transactions for the attacker's double payment, so M x F x TA must be compensated to the collusion signers of the forged block.
  • the signer group for the next block now changes to the new group, and they must sign the next block forged. Since the transactions do not change, subsequent blocks are signed by the same signer groups, and they do not get additional income from the new signature. Now, collusion signers for subsequent blocks are asked to sign the same block again, knowing that it is a duplicate signing action. At this time, contest signers must choose whether or not to participate in the contest. Competition signers consider two things. One is that network nodes are likely to be notified to the authorities for double signing.
  • the competition signers know that the signing of the competition can lead to the loss of the opportunity to obtain a transaction cost. This is because previous chains signed by competition signers have a greater chance of earning transaction costs than subsequent chains.
  • the stake that can be obtained by the competition signer can be calculated as ( M ⁇ TA - M ⁇ F ⁇ TA ) / ( R ⁇ S), and the transaction cost can be obtained as F ⁇ TA / S .
  • rewards and fines can be considered.
  • embodiments of the present invention may introduce a penalty to the notifier of the double payer and a penalty for the attacker.
  • the fines are greater than the benefits of counterfeiting, a potential attacker will rarely try to forge a book. Any signer is more likely to report a double payer because the reward is set higher than the equity that can be obtained when conspiring against illegal counterfeiting.
  • the rewards and fines should be set higher than ((1- F ) ⁇ M ⁇ TA ) / ( R ⁇ S ).
  • the incentive given by the attack may be limited by system policy that sets the maximum transaction value (eg, 10% of the total in the block). If the price of a transaction is high, the transaction must be broken up into many smaller transactions to prevent attacks. In doing so, the maximum profits of the conspirators are limited.
  • Every regional area has its own local blockchain. All transactions occurring within the area are processed as described above.
  • a transaction occurs between two local blockchains. For example, if A ('A @ Orlando') on a local chain in Orlando wants to send USD 5 to B ('B @ Fairfax') on a local chain in Fairfax. May be considered.
  • the transaction "A @ Orlando sends USD 5 to B @ Fairfax” can be verified for the first time by checking the balance and processed on the local chain at Fairfax. Therefore, the cost between transactions will be higher than the cost of processing transactions internally as it involves more mergers and signers.
  • B @ Fairfax wants to send some money to C ('C @ Boston') on a local chain in Boston, the balance of B @ Fairfax will be first validated on the local chain in Fairfax. Can be.
  • the system according to embodiments of the present invention can be extended in time.
  • a new chain is created, which can be advertised not to use the old chain, and all balances on the old chain can be transferred to the new chain.
  • the old chain may be kept in the repository of peers (full nodes). If all balances do not move to the new chain and later a transaction request on the old chain occurs, the archived chain can still be used to move to the new chain.
  • Multiple addresses can be used to separate transactions from privacy techniques for amounts to make tracking difficult.
  • the balance of each account as well as the transaction records can be stored in the book to make account balance verification faster.
  • T bank account
  • P p2p bank account
  • the blockchain according to embodiments of the present invention is executed and used by users (nodes) identified with real names, so that all transactions are traceable when given a pseudonym and real name mapping table. This will ease the development of books by resolving government concerns about tax avoidance and money laundering.
  • PoW PoW
  • PoS It is more democratic compared to PoW and PoS in that one user can cast one vote.
  • anonymous networks using PoW or PoS large computing power owners or high- stake owners can vote more than others. More democratic in this sense means a lot. For example, more democratic can mean better security, fairness and democratic control of the network.
  • PoW / PoS networks require decentralization but they are actually centralized by high hash capability groups, large cryptocurrency exchanges and developers.
  • PoP according to embodiments of the present invention can provide decentralization rather than cryptocurrency, PoW, PoS.
  • PoP can provide higher security with the possibility of retrograde or counterfeiting.
  • PoP is better than PoW. This is because PoP does not cause any huge calculations for transaction processing.
  • PoP networks are more scalable than PoW networks because of the order of magnitude of the faster processing speed.
  • the processing speed of Bitcoin network is only 7 Transactions Per Second (TPS).
  • any secure (EU-CMA secure) digital signature can be used simultaneously on platforms such as RSA-OAEP, ECDSA, DSA, pairing based signatures, and the like. If network bandwidth is not sufficient, an aggregate signature can be used to compress multiple signatures.
  • 5 is a diagram illustrating an example of an operating environment of a network system according to an embodiment of the present invention.
  • 5 illustrates a financial platform 510, a plurality of signer nodes 510 and a plurality of merger nodes 530.
  • the financial platform 510, each of the plurality of signer nodes 510, and each of the plurality of merger nodes 530 may be physical, for example, the computer device 600 described below with reference to FIG. 6. It may be implemented as a hardware device, or in some embodiments, two or more computer devices may be implemented in a combined form.
  • the financial platform 510 may correspond to the p2p bank described above, and may provide a user identifier on the network by authenticating the identity with a real name for each of the plurality of users who want to enter the network.
  • Each of the plurality of merger nodes 520 collects and merges information about a transaction between users to generate a transaction block, and understands the signers for the generated transaction block, the transaction that the generated transaction block includes. Regardless of the relationship, you can select based on the transaction of the last completed block of the signed blockchain, receive signatures on the created transaction blocks of the selected signers, and attempt to add the generated transaction blocks to the signed blockchain. have.
  • Each of the plurality of merger nodes 520 may correspond to the terminal of the merger described above.
  • Each of the plurality of signer nodes 530 verifies the validity of the transaction block generated in each of the plurality of merger nodes 520 according to a request from each of the plurality of merger nodes 520, The trading block can be signed.
  • Each of the plurality of signer nodes 530 may correspond to the terminal of the signer described above.
  • each of the plurality of signer nodes 510, and each of the plurality of merger nodes 520 may communicate with each other through the network 540 shown in FIG. 5.
  • the transaction record including the amount of money, date / time, transaction purpose and their IDs, is signed using A and B's private signature keys and is either A or B Sent by the sender to the mergers.
  • Mergers are selected by the sender according to the rank of the mergers profiled in the wallet.
  • the plurality of merger nodes 520 may correspond to terminals of the selected mergers, and the plurality of merger nodes 520 may correspond to transaction blocks signed from the plurality of signer nodes 530.
  • the validity of the signed transaction blocks can be verified and the addition of the validated signed transaction blocks to the signed blockchain can be approved.
  • the PoP network selects and realizes a new blockchain according to the cumulative number of people who support the block (signature number). At this time, since the number of accumulated people is the same for the blockchain determined before the new block, a new blockchain may be selected according to the number of transaction blocks newly added to the blockchain.
  • Each of the plurality of signer nodes 530 can validate the new trading blocks that are broadcast and approve adding the validated signed trading blocks to the blockchain, where the Transactions with the highest cumulative number of people (signatures) that support the addition of the trading block with the highest cumulative number of signatures (signatures) or new blockchains that have added validated trading blocks. You can select the blockchain to which the block is added.
  • each of the plurality of merger nodes 520 has as inputs information about a transaction included in a previous transaction block of a transaction block to be added to the signed blockchain, but is unpredictable (random) according to the input. Generate a hash value that is output through a function whose output is deterministic, select the signers for the transaction block you want to add based on the generated hash value, add them to the signer nodes corresponding to the selected signers, You can request a signature for your transaction block.
  • each of the plurality of signer nodes 530 manages a block identifier of a transaction block signed by it and issues a signature request for a transaction block generated before the last signed transaction block in the signed blockchain is completed. You can refuse.
  • each of the plurality of signer nodes 530 ignores the signing request for another transaction block that includes information about transactions on the transaction block that it has already signed, and sends information about the disregarding the signature request to another transaction block. The merger node corresponding to the message may be notified.
  • each of the plurality of signer nodes 530 reports a signing request to the financial platform 510 for a block that contains a transaction that does not match the signed one, and identifies the merger's identifier and the mismatched transaction according to the signature request.
  • the identifier of the sender of may be broadcast on the network.
  • each of the plurality of signer nodes 510, and each of the plurality of merger nodes 530 may be physical hardware devices, such as the computer device 600 of FIG. 6. In some implementations, two or more computer devices may be implemented in a combined form.
  • the computer device 600 may include a memory 610, a processor 620, a communication interface 630, and an input / output interface 640.
  • the memory 610 may be a computer-readable recording medium, and may include a permanent mass storage device such as random access memory (RAM), read only memory (ROM), and a disk drive.
  • RAM random access memory
  • ROM read only memory
  • the non-volatile mass storage device such as a ROM and a disk drive may be included in the computer device 600 as a separate permanent storage device separate from the memory 610.
  • the memory 610 may store an operating system and at least one program code. These software components may be loaded into the memory 610 from a computer-readable recording medium separate from the memory 610.
  • Such a separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, disk, tape, DVD / CD-ROM drive, memory card, and the like.
  • the software components may be loaded into the memory 610 via the communication interface 630 rather than a computer readable recording medium.
  • software components may be loaded into memory 610 of computer device 600 based on a computer program installed by files received via network 540.
  • the processor 620 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input / output operations.
  • the instructions may be provided to the processor 620 by the memory 610 or the communication interface 630.
  • the processor 620 may be configured to execute a command received according to a program code stored in a recording device such as the memory 610.
  • the communication interface 630 may provide a function for the computer device 600 to communicate with other devices (eg, storage devices described above) via the network 540. For example, a request, a command, data, a file, etc. generated by the processor 620 of the computer device 600 according to a program code stored in a recording device such as the memory 610 may be controlled according to the control of the communication interface 630. 540 may be passed to other devices. Conversely, signals, commands, data, files, and the like from other devices may be received by the computer device 600 via the network 540 via the communication interface 630 of the computer device 600. Signals, commands, data, and the like, received through the communication interface 630 may be transmitted to the processor 620 or the memory 610, and the files and the like may be further included in the storage medium (described above). Persistent storage).
  • the input / output interface 640 may be a means for interfacing with the input / output device 650.
  • the input device may include a device such as a microphone, a keyboard or a mouse
  • the output device may include a device such as a display or a speaker.
  • the input / output interface 640 may be a means for interfacing with a device in which functions for input and output are integrated into one, such as a touch screen.
  • the input / output device 650 may be configured as a computer device 600 and one device.
  • the computer device 600 may include fewer or more components than the components of FIG. 6. However, there is no need to clearly show most prior art components.
  • computer device 600 may be implemented to include at least some of the input and output devices 650 described above, or may further include other components, such as a transceiver, a database, and the like.
  • FIG. 7 is a flowchart illustrating an example of a signature method in an embodiment of the present invention.
  • the signature method according to the present embodiment may be performed by the computer device 600 implementing the terminal of the signer described above.
  • the processor 620 of the computer device 600 may be implemented to execute a control instruction according to a code of an operating system or a code of at least one program included in the memory 610.
  • the processor 620 may perform the steps 710 to 730 included in the method of FIG. 7 according to a control command provided by a code stored in the computer device 600. Can be controlled.
  • the computer device 600 receives a signature request for the transaction block generated by the merger node through the network from the merger node on the network whose identity is authenticated by the real name for the plurality of users to enter. can do.
  • the computer device 600 may correspond to a terminal of a user selected as a signer among a plurality of users, and the merger node may also correspond to a terminal of a user selected as a merger among a plurality of users.
  • the signature request may be sent by the merger node to the signer nodes on the network selected based on the hash value, where the hash value inputs information about transactions included in the last transaction block of the signed blockchain. Since it is arbitrary and unpredictable but deterministic, it can be output through a function whose output is determined according to the input.
  • the computer device 600 may verify the validity of the transaction block for which the signature is requested. Since the signer checks the validity of the transaction block several times, repeated descriptions are omitted.
  • the computer device 600 may sign a valid transaction block. At this time, the computer device 600 may transmit the signed transaction block to the merger node. Operation at the merger node will be described with reference to FIG. 8.
  • FIG. 8 is a flowchart illustrating an example of a method for adding a transaction block according to an embodiment of the present invention.
  • the transaction block adding method according to the present embodiment may be performed by the computer device 600 implementing the terminal of the merger described above.
  • the processor 620 of the computer device 600 may be implemented to execute a control instruction according to a code of an operating system or a code of at least one program included in the memory 610.
  • the processor 620 is a computer device 600 such that the computer device 600 performs the steps 810 to 850 included in the method of FIG. 8 according to a control command provided by a code stored in the computer device 600. Can be controlled.
  • the computer device 600 may collect information about a transaction between users through a network whose identity is authenticated using a real name for a plurality of users to enter. For example, when a transaction occurs from user A to user B, the transaction record, including the amount of money, the date / time, the purpose of the transaction, and their IDs (user A and user B), is the user's private signature key and user B It can be signed using the private signature key of and sent to the mergers by either the user A or the user B (the sender). In this embodiment, the computer device 600 may be a terminal of one of these mergers, and may collect information about transactions between users as in step 810.
  • the computer device 600 may generate a transaction block by merging the information about the collected transactions.
  • the transaction block may include information about the transaction (transaction record in the previous example) received from at least one sender.
  • step 830 the computer device 600 selects the signers for the generated transaction block based on the transaction of the last completed block of the signed blockchain, regardless of the interest in the transaction that the generated transaction block includes. Can be.
  • the new block 111 is obtained through a hash value calculated using a hash function having, as input parameters, transactions 310, 320, and 330 included in the previous block 112 of the new block 111.
  • signers 370 are selected for the above has been described.
  • the computer device 600 may request a signature for the generated transaction block of the selected signers.
  • each of the signers receives the signature request through the steps 710 to 730 described with reference to FIG. 7, confirms the validity of the transaction block, and signs the valid transaction block according to the embodiment of FIG. 8. 600 may be transmitted to the merger node.
  • the computer device 600 may send the signed transaction block to a plurality of aggregator nodes on the network to add the signed transaction block from the signers to the signed blockchain.
  • each of the plurality of merger nodes may confirm the validity of the signed transaction block and approve the addition of the validated signed transaction block to the signed block chain.
  • the cumulative number of people who support the trading block (the number of signatures) approves the addition of the largest trading block or supports the trading block among the new blockchains with the added valid trading blocks. You can choose a blockchain with the largest number of trading blocks (signature) added.
  • 5 to 8 may refer to the foregoing descriptions, and the effects of the network system, the signature method, and the transaction block generation method have been described in detail above.
  • a chain having the largest result of a score function for example, the function of Equation 1 described above
  • the score function has many parameters, such as the number of signers, the Hamming distance of the nearest signer, and the block creation time.
  • the number of signers who sign a block and how fast the chain connects is not important. Therefore, when a block with a very high score is added, even if it is slow, all the previously agreed blocks may be canceled, causing more soft forks, delaying the final agreement, and delaying the blockchain. There is a risk of impairing the stability.
  • a block can be forced to be created within a certain time, or a chain can be selected based on a score at a specific time rather than the order of the block.
  • an empty transaction should be allowed when there is no actual transaction occurring in the real world.
  • an attempt can be made to increase the score by simply connecting blocks without collecting transaction requests. If a newly generated coin is more expensive than a transaction processing fee every time a block is generated, there is a possibility of disturbing the blockchain, and a countermeasure for this is required.
  • embodiments are provided to mitigate these problems by providing a block generation delay time.
  • a block chain when a plurality of blocks that can be the next block of the previous block exist simultaneously and compete, that is, when a soft fork occurs, the chain in which the block is generated may be selected as soon as possible.
  • the propagation time between nodes participating in the blockchain can lead to a plurality of different chains.
  • 9 is a diagram illustrating a soft fork and an example of a block in a block chain.
  • the block of the chain to which the block is connected faster may be determined. For this reason, in blockchains such as Bitcoin, the contents recorded in the block in which the first soft fork occurred when 6 to 7 or more blocks are connected are confirmed.
  • the present embodiment provides a method for resolving a contention chain in a block chain based on a PoP (Proof of Population) by defining a chain connection rule of a block. All nodes (signers, mergers, general users) participating in the blockchain network according to the present embodiment can all be synchronized with a low error rate. Today's computing environment can synchronize in minutes, even seconds or late.
  • PoP Proof of Population
  • 10 is a flowchart illustrating an example of a block validation process according to an embodiment of the present invention. 10 illustrates an example of a block validation process when a node participating in a blockchain network receives a block containing transactions and signatures from an external consolidator. Such a node may be implemented with the computer device 600 of FIG. 6 described above.
  • the node may receive a block.
  • the node may receive the block generated by the merger of the blockchain network, and may verify the time order, validity, and signature for the received block as follows.
  • the node may verify the time order. Verification of the time sequence is described in more detail later.
  • the node may perform step 1040 if the time order is correct, and reject the received block if the time order is incorrect.
  • the node may validate the blocks received in all chains. In this case, the node may further verify the validity of the dynamic delay time as well as the validity of the transaction.
  • the dynamic delay time is calculated to limit the merger to generate another block within the dynamic delay time from the creation time of the previous block.
  • the node calculates the dynamic delay time for the received block so that the merger calculates the dynamic delay time. By determining whether or not the received block has been generated, the validity of the dynamic delay time of the received block can be verified.
  • the node may perform step 1060 if the chain is valid for the transaction, and may reject the received block if the chain is not valid.
  • the node may verify the signature of the received block.
  • the node may begin processing the received block if the signature is correct and may reject the received block if the signature is incorrect.
  • 11 is a flowchart illustrating an example of a process of processing a validated block according to an embodiment of the present invention. 11 illustrates an example of a process in which a node participating in a blockchain network connects a block validated to a chain. Such a node may also be implemented with the computer device 600 of FIG. 6 described above.
  • the node may perform operation 1120 when a new block exists and terminate the processing of the block when the new block does not exist.
  • the node may connect the block to the chain.
  • the node may perform operation 1140 when m or more blocks are connected to the chain from the soft fork, and terminate the processing of the blocks when the m or more blocks are not connected.
  • the node may delete the chain to which fewer than m blocks are connected from the soft fork.
  • a node may store and manage information on a plurality of different chains that exist separately by soft forks in a repository, and validate the received block to each of the plurality of different chains. Can connect In this case, if there are chains connected by m or more blocks from the soft fork, the chains may be deleted by deleting information on the remaining chains (chains connected by less than m blocks from the soft fork) from the storage. .
  • the node may connect a block validated in FIG. 10 to a chain known to the node in FIG. 11.
  • a plurality of chains may exist at the same time by the soft fork, and if a node has a chain of more than a certain length (chain connected with m or more blocks from the soft fork), the remaining chains (less than m blocks from the soft fork) And all blocks connected to the chains can be deleted.
  • a merger collects a transaction (and the corresponding user's signature), sends it to the signers, generates a merge signature after receiving a signature from the signers, in this embodiment, there is a delay to allow the merger to keep transactions and signatures. Can be.
  • the block generation delay time can be evaluated fairly by the participants of other blockchains, and blocks that do not keep the delay time can be rejected.
  • the merger may not generate the block within the dynamic delay time t i generated by Equation 2 below from the generation time of the previous block.
  • the determination of whether the merger has kept the dynamic delay time for the block may be processed at step 1040 described above with reference to FIG. 10.
  • the argument i can mean the order of the blocks, j can be the order of the signers, and k can be the order of the mergers.
  • t is the delay time
  • ⁇ is the fixed latency for network propagation and transaction collection
  • S is the number of signers involved in the signature
  • ⁇ is the signature of the current block from the optimal signer IDs computed from the previous block.
  • ⁇ may mean a distance from the best merger ID calculated from the previous block to the IDs of the mergers participating in the signature of the current block.
  • D may represent a difficulty variable considering a network situation
  • B may represent a difficulty variable considering a block merging situation
  • a function exp () may mean an exponential function having an arbitrary base.
  • the above-described PoP-based blockchain is designed such that the score increases as the number of signers participating in the generation of blocks increases, and only a minimum number of signers is defined, in the present embodiments, the number of signers S for generating one block can be fixed.
  • ⁇ and ⁇ are distance functions that measure the quality of the mergers and the signers participating in the generation of the block, and the smaller the smaller, the higher the quality of the mergers and the signers.
  • the quality of the signer is measured by using a hamming distance, but in the present embodiments, a distance function of two general vectors, such as Euclidean distance and Manhattan distance, may be used.
  • the delay time t can increase exponentially.
  • the delay time t increases exponentially with respect to the distance ⁇ .
  • a linear increase or a step increase function may be used instead.
  • a node that receives a block and validates the received block is a distance function of the distance between the IDs of the best signers for the next block calculated from the previous block and the IDs of the actual signers participating in the signature of the received block.
  • Calculate the dynamic delay time to be proportional to the calculated distance exponentially, linearly or stepwise.
  • the node calculates the distance between the ID of the best merger for the next block calculated from the previous block and the ID of the actual merger participating in the signature of the received block through the distance function, and calculates the calculated distance and the exponential, linear
  • the dynamic delay time can be calculated to be proportional to the product in steps or steps.
  • the node may calculate the dynamic delay time to be exponentially, linearly or stepwise proportional to the product of the difficulty variable and the calculated distance determined based on the block generation frequency of the actual merger.
  • Equation 2 described above is as if there is a constant delay per signer. As the number of signers increases, the latency increases, which is disadvantageous for the merger who wants to generate blocks quickly.
  • the merger selects the lowest latency signers (that is, the ones with the highest quality) from Equation 2 in its own signer cache pool, requests a signature, and merges them to create a block. can do. If signers with high enough quality are not in their signer cache pool, they can find a signer outside the cache pool and request a signature.
  • the merger may give up creating the block.
  • the distance ⁇ between the signer's identity from the original signer's ID for the selected block from the next previous block can be measured by means of the quality of the signer uses a different distance functions.
  • the quality of the actual signers depends on which distance function and ID to measure with which vector. For example, if the signer ID is interpreted as a binary vector (for example, ⁇ 0, 1 ⁇ 32 when the ID is 32 bits) and the Hamming distance is measured, the signer at the same distance as the reference signer ID It becomes innumerable. On the contrary, if the signer ID is interpreted as a hexadecimal vector (for example, ⁇ 0, 1, 2, ..., 15 ⁇ 8 when the ID is 32 bits), there are fewer signers at the same distance than the binary vector.
  • Difficulty variables D and B may be determined based on the state of the final number of blocks from the earliest block to m previous blocks based on finalization (eg 1000) and the difference between the last block generation time and the current time. . If the block generation delay time is relatively long, D is reduced and the block generation delay time is shortened to enable fast block generation. However, if the block generation delay time is too short, D may increase to increase the block generation delay time. This can increase the blockchain's security by allowing lower quality signers to sign the merger in a time-consuming problem between signers and mergers and in environments where signers are difficult to collect. For example, the node receiving the block and validating the received block may calculate the dynamic delay time so that the dynamic delay time increases as the difficulty variable D determined based on the difference between the creation time and the current time of the final block increases. have.
  • the corresponding B is increased to increase the block generation delay time, and conversely, B is decreased to reduce the block generation delay time.
  • the number of signers S can also be linked to the difficulty variable D. If the number of signers is not enough and no block is generated despite the relatively short block generation delay time, it is necessary to reduce the number of signers required. If D is gradually lowered from the last block generation time, and D is gradually lowered, and eventually the block is not generated even when the minimum value is reached, S can be gradually reduced to reduce the burden of signer recruitment. On the contrary, if the block generation delay time is not reduced even though D reaches the maximum value, it means that the signer is sufficient for the network, so that S may be gradually increased for higher security.
  • time order, delay time, and validity of a transaction may be checked.
  • Validation of transactions follows the method used in the existing blockchain.
  • the node receiving the block knows the current time. If a block of the signature generation time of the signer and the merge signature time of the merger arrives by ⁇ earlier than the current time, the block may be rejected. ⁇ can be defined as a few seconds as expected error of time synchronization. In addition, the signature generation time of the signer must be faster than the merge signature time of the merger. Otherwise, the block may be rejected.
  • the blocks must be validated. In addition to validating transactions as a method used in the existing blockchain, it is necessary to check whether the block has kept the block generation delay time (dynamic delay time described by Equation 2). If there is a problem with the validity of the transaction, or if the block creation delay time is faster than that obtained through the formula, the block may be rejected.
  • the variables that determine the time delay can be set differently in the contention chain where the softfork occurs. Some variables are determined by time and some variables are determined by chain sequence. The block created by the merger must always explicitly specify the previous block, so that nodes can check each delay through the determined chain and the current time.
  • the node can verify the signatures contained in the block. If the block contains the signature of the signer contained in the revocation list (RL) or if the signature itself is incorrect, the block may be rejected.
  • RL revocation list
  • the node can connect the block to its own chain and manage the soft fork of the chain. This process has been described above with reference to FIG. 2.
  • PoP Proof of Population
  • the system or apparatus described above may be implemented as a hardware component, a software component or a combination of hardware components and software components.
  • the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs). May be implemented using one or more general purpose or special purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions.
  • the processing device may execute an operating system (OS) and one or more software applications running on the operating system.
  • the processing device may also access, store, manipulate, process, and generate data in response to the execution of the software.
  • OS operating system
  • the processing device may also access, store, manipulate, process, and generate data in response to the execution of the software.
  • processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include.
  • the processing device may include a plurality of processors or one processor and one controller.
  • other processing configurations are possible, such as parallel processors.
  • the software may include a computer program, code, instructions, or a combination of one or more of the above, and may configure the processing device to operate as desired, or process independently or collectively. You can command the device.
  • Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. It can be embodied in.
  • the software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner.
  • Software and data may be stored on one or more computer readable media.
  • the method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium.
  • the computer readable medium may include program instructions, data files, data structures, and the like, alone or in combination.
  • Program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks such as floppy disks.
  • Such a recording medium may be various recording means or storage means in the form of a single or several hardware combined, and is not limited to a medium directly connected to any computer system, but may be distributed on a network.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne une technologie associée à un registre poste à poste (P2P) qui permet la mise en œuvre d'une plateforme financière universelle de monnaie fiduciaire sans émettre de cryptomonnaie. Un système de réseau selon certains modes de réalisation de la présente invention peut comprendre : une plateforme financière destinée à authentifier, à l'aide d'un nom réel, une identification pour chaque utilisateur parmi de multiples utilisateurs souhaitant entrer dans un réseau, et à fournir ainsi un identifiant d'utilisateur sur le réseau ; de multiples nœuds de dispositifs de fusion destinés à générer un bloc de transactions par une collecte et une fusion d'informations de transactions entre les utilisateurs, à sélectionner des signataires du bloc de transactions généré, à recevoir les signatures des signataires sélectionnées du bloc de transactions généré, et à tenter d'ajouter le bloc de transactions généré à une chaîne de blocs signée ; et de multiples nœuds de signataire destinés à vérifier la validité des blocs de transactions générés par les multiples nœuds de dispositifs de fusion respectifs, en réponse à des demandes provenant des multiples nœuds de dispositifs de fusion respectifs, et à signer les blocs de transactions dont la validité a été vérifiée.
PCT/KR2018/008400 2018-07-23 2018-07-25 Procédé et système de connexion de chaîne basée sur un retard temporel dynamique dans une chaîne de blocs à base de pop WO2020022531A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020180085539A KR102077397B1 (ko) 2018-07-23 2018-07-23 PoP 기반 블록체인에서의 동적 시간 지연 기반의 체인 연결 방법 및 시스템
KR10-2018-0085539 2018-07-23

Publications (1)

Publication Number Publication Date
WO2020022531A1 true WO2020022531A1 (fr) 2020-01-30

Family

ID=69181765

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/008400 WO2020022531A1 (fr) 2018-07-23 2018-07-25 Procédé et système de connexion de chaîne basée sur un retard temporel dynamique dans une chaîne de blocs à base de pop

Country Status (2)

Country Link
KR (1) KR102077397B1 (fr)
WO (1) WO2020022531A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111369367A (zh) * 2020-04-02 2020-07-03 中国工商银行股份有限公司 一种交易流程的组合方法及装置
CN112996080A (zh) * 2021-01-26 2021-06-18 杭州网银互联科技股份有限公司 一种sd-wan网络中pop点选择接入方法
CN113298508A (zh) * 2021-06-17 2021-08-24 中国人民银行数字货币研究所 一种数字货币交易方法和系统
CN113592652A (zh) * 2021-08-02 2021-11-02 杭州复杂美科技有限公司 延时交易方法、计算机设备和存储介质
CN114710425A (zh) * 2022-03-30 2022-07-05 蚂蚁区块链科技(上海)有限公司 一种区块链节点连接方法及装置
CN115099681A (zh) * 2022-07-18 2022-09-23 北京师范大学 一种基于区块链的图书馆管理系统及其方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210150174A (ko) * 2020-06-03 2021-12-10 삼성전자주식회사 블록체인을 이용하는 전자 장치 및 동작 방법
CN113807968B (zh) * 2021-09-22 2024-02-23 网易（杭州）网络有限公司 区块链用户请求处理方法、装置、委托服务器及存储介质
KR20230086501A (ko) * 2021-12-08 2023-06-15 고려대학교 산학협력단 블록체인 기반 공유자산 거래 시스템의 제어방법, 이를 수행하기 위한 기록매체 및 시스템

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101660627B1 (ko) * 2015-02-03 2016-09-28 한양대학교 에리카산학협력단 암호화 화폐의 거래를 보호하는 방법 및 장치
KR20170040079A (ko) * 2016-05-03 2017-04-12 안규태 블록 검증을 위한 복수의 일방향 함수를 지원하는 블록 체인
KR20180014534A (ko) * 2016-08-01 2018-02-09 서강대학교산학협력단 블록체인 기반 트랜잭션 검증 시스템 및 그 방법
KR101837167B1 (ko) * 2016-10-26 2018-03-09 주식회사 코인플러그 Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
KR20180079806A (ko) * 2017-01-02 2018-07-11 주식회사 코인플러그 블록체인 및 이와 연동되는 머클 트리 구조 기반의 모바일 아이디를 이용하여 사용자를 비대면 인증하는 방법, 단말 및 이를 이용한 서버

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101727525B1 (ko) * 2016-09-05 2017-04-17 주식회사 스케일체인 블록체인 기반 분산 저장 방법 및 이를 이용한 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101660627B1 (ko) * 2015-02-03 2016-09-28 한양대학교 에리카산학협력단 암호화 화폐의 거래를 보호하는 방법 및 장치
KR20170040079A (ko) * 2016-05-03 2017-04-12 안규태 블록 검증을 위한 복수의 일방향 함수를 지원하는 블록 체인
KR20180014534A (ko) * 2016-08-01 2018-02-09 서강대학교산학협력단 블록체인 기반 트랜잭션 검증 시스템 및 그 방법
KR101837167B1 (ko) * 2016-10-26 2018-03-09 주식회사 코인플러그 Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
KR20180079806A (ko) * 2017-01-02 2018-07-11 주식회사 코인플러그 블록체인 및 이와 연동되는 머클 트리 구조 기반의 모바일 아이디를 이용하여 사용자를 비대면 인증하는 방법, 단말 및 이를 이용한 서버

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111369367A (zh) * 2020-04-02 2020-07-03 中国工商银行股份有限公司 一种交易流程的组合方法及装置
CN112996080A (zh) * 2021-01-26 2021-06-18 杭州网银互联科技股份有限公司 一种sd-wan网络中pop点选择接入方法
CN113298508A (zh) * 2021-06-17 2021-08-24 中国人民银行数字货币研究所 一种数字货币交易方法和系统
CN113298508B (zh) * 2021-06-17 2024-03-22 中国人民银行数字货币研究所 一种数字货币交易方法和系统
CN113592652A (zh) * 2021-08-02 2021-11-02 杭州复杂美科技有限公司 延时交易方法、计算机设备和存储介质
CN113592652B (zh) * 2021-08-02 2023-05-30 杭州复杂美科技有限公司 延时交易方法、计算机设备和存储介质
CN114710425A (zh) * 2022-03-30 2022-07-05 蚂蚁区块链科技(上海)有限公司 一种区块链节点连接方法及装置
CN114710425B (zh) * 2022-03-30 2024-03-26 蚂蚁区块链科技(上海)有限公司 一种区块链节点连接方法、装置、介质及设备
CN115099681A (zh) * 2022-07-18 2022-09-23 北京师范大学 一种基于区块链的图书馆管理系统及其方法
CN115099681B (zh) * 2022-07-18 2023-01-31 北京师范大学 一种基于区块链的图书馆管理系统及其方法

Also Published As

Publication number Publication date
KR20200010905A (ko) 2020-01-31
KR102077397B1 (ko) 2020-02-13

Similar Documents

Publication Publication Date Title
WO2020022531A1 (fr) Procédé et système de connexion de chaîne basée sur un retard temporel dynamique dans une chaîne de blocs à base de pop
US11562333B1 (en) System, method and program product for generating and utilizing stable value digital assets
US20200272619A1 (en) Method and system for audit and payment clearing of electronic trading systems using blockchain database
Puthal et al. Everything you wanted to know about the blockchain: Its promise, components, processes, and problems
Xu et al. A taxonomy of blockchain-based systems for architecture design
TW202008207A (zh) 基於區塊鏈的資產發布方法及裝置、電子設備
WO2018124718A1 (fr) Procédé de fourniture de service de point intégré par gestion d'une base de données de solde pour chaque bloc d'une chaîne de blocs et serveur l'utilisant
CN113646765A (zh) 点对点分布式去中心化系统
US20240022631A1 (en) Malleability of transactions for inclusion in a blockchain
CN110728576A (zh) 一种基于零知识证明的去中心化匿名数据交易方法
WO2020107033A1 (fr) Procédés, systèmes et dispositifs pour transaction stable en chaîne en cryptomonnaies décentralisées
JP2019076350A (ja) アイテム取引システム及びアイテム取引プログラム
Zouina et al. Towards a distributed token based payment system using blockchain technology
KR20220102605A (ko) 블록체인 토큰 기반의 페이먼트를 수행하는 방법 및 이를 이용한 카드사 서버
JP2019079502A (ja) アイテム取引システム及びアイテム取引プログラム
WO2019172464A1 (fr) Livre p2p de monnaies fiduciaires qui n'utilise pas de cryptomonnaie
CN113994628A (zh) 通过侧信道流式传输部分数据
Muftic et al. Overview and analysis of the concept and applications of virtual currencies
CA3177280A1 (fr) Recompenses decentralisees preservant la confidentialite a l'aide d'accumulateurs de boites noires cryptographiques
CN115136542A (zh) 智能合约
Suliyanti et al. Evaluation of hash rate-based double-spending based on proof-of-work blockchain
JP2023510320A (ja) 分散型台帳ネットワークにおけるコンテンツのセキュアなピアツーピア送信のためのシステムおよび方法
Bhaskar et al. Verito: A Practical System for Transparency and Accountability in Virtual Economies.
Masseport et al. Proof of usage: User-centric consensus for data provision and exchange
JP2023106055A (ja) エビデンス管理方法、エビデンス管理システム及びノード

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18928109

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18928109

Country of ref document: EP

Kind code of ref document: A1