KR101827373B1 - Block window module having agreement algorithm for limiting mining, managing server and virtual money exchange system and method - Google Patents

Abstract

The present invention provides a block chain-based virtual currency trading system and method, and includes a consensus algorithm for mining restriction that gives certain constraints to a mining attempt after a specific job certification period for system mining nodes, general nodes and mining nodes And a block window module including a mining history management unit for recording the mining history information by linking the mining node's mining attempt result with the mining node; And a block window generation unit for setting a block window for invalidating the result of the mining attempt or inhibiting the mining attempt for at least a part of the mining nodes that have succeeded in mining. The block window module includes a block window size calculating unit for calculating a block window size based on the digesting history information and providing a block window and a transaction history managing unit for providing virtual currency transaction history information between general nodes during a current or recent period . The block window size (y) calculated from the block window size calculating unit is defined by y = [0.7 (N) x the cumulative number of blocks up to the present time] / (the cumulative number of blocks over 10 years) = (Total number of participating nodes), B = (total number of participating nodes) / (total number of mining nodes), C = (total number of mining nodes) / (number of participating mining nodes having mining success experience). Therefore, it is possible to effectively prevent the mining monopoly of a few mining nodes.

Description

Technical Field [0001] The present invention relates to a block window module and a management server including a consensus algorithm for mining restriction, a virtual money transaction system, and a virtual money transaction system.

The present invention relates to a virtual money trading system and method using a module or a server, and more particularly to a virtual money trading system in which a block monopoly or an oligopoly of a prime mining node is prevented, A consensus algorithm for mining restrictions that provides opportunities to equip mining opportunities and to limit mining opportunities to specific mining nodes that have been successfully mined to reduce waste of energy that is excessive use of resources and efforts required for mining. And more particularly, to a virtual money trading system and method using the module or the server.

The term "mining node" used herein is intended to emphasize functional aspects for the sake of convenience of description and means at least a node having a mining function. In the case of a mining node, a wallet function for virtual currency trading, Mining nodes can also have all kinds of node functions that apply to general virtual currency trading systems such as database functions. The term "general node " in the present specification is intended to emphasize a functional aspect for the sake of convenience of description, and at least represents a general node as a transaction function having a wallet function, a money transfer function and a collection function. However, Lt; / RTI > That is, in this specification, the node may include other functions in addition to the functions denoted by the name, regardless of the name of the node, and may include functions related to the operation of the virtual money system and functions And the like.

The block chain has the function of a transaction record book that continuously records transactions of virtual currency exchanged between nodes in a distributed virtual currency transaction system such as bit coin. The reason why the block chain functioning as a transaction record book is necessary in a distributed virtual currency trading system is that virtual money does not exist as a real physical currency but exists virtually only. In other words, the first 100 won virtual currency is always present in the system as a total concept over time, but its form can be divided into one hundred circles, and it can exist in 100 electronic wallets located in 100 nodes in the system For example, it may be included in a circle of 300 yen in a wallet of a specific node in combination with another virtual money 200 circle. Therefore, the data that can judge whether the virtual currency that is currently being traded is legitimate can be traced back from the time when the virtual currency was originally created until now to determine whether it is consistently valid I have no choice but to confirm. When a central server such as a bank manages a virtual currency as a whole, the central server collectively records these virtual currency transaction records. In the case of a block chain, however, the transactions are recorded by nodes in a distributed system of distributed nodes Each time a block chain is traded, the transaction is encrypted to generate a block, and the newly created block is combined into a block chain to update the transaction record. The strength of encryption in a block chain is that the recorded contents are cascaded into a hash value each time a transaction occurs from the past to the present. Therefore, it is not possible to manipulate the contents of the transaction as long as it can not decrypt the entire transaction in the transaction system, rather than one particular hash value. In addition, the contents that are re- , And since the transaction book is distributed in various nodes, it is impossible to decipher the block chain password or hack the block chain-based virtual currency trading system as a whole even though it takes hundreds of years with modern computers. That is, the virtual money based on the block chain can be verified through the transaction details described in the existing block chain, and can be said to have reliability in that the transaction details can not be manipulated realistically.

Therefore, in a virtual currency trading system using a block chain, a transaction that occurs every minute is propagated to all nodes, encrypted, and a new transaction record is generated as a block, and the generated new block is connected to a block chain.

As described above, when a new block is newly created for a predetermined period (for example, 1 minute, 3 minutes, 10 minutes, etc.) by bundling the newly formed transaction details and the block is connected to an existing block chain Called "proof of work".

Generally, the algorithm of the proof of agreement of the proof of work proceeds to the following process.

WS1: New transaction details are known to all nodes.

WS2: Each node collects new transaction details into a block.

WS3: Each node performs a process of finding a proof of work for the block.

WS4: When a node successfully performs a proof of operation, it sends the block to all nodes.

WS5: Nodes only acknowledge the block if all transactions are not previously used and valid.

WS6: Nodes indicate that the block has been approved through the process of generating the next block using the hash of the block it has approved as the previous hash. In this case, the nodes always consider the longest chain to be correct and perform the operation so that the chain continues to expand.

In a virtual currency system such as a bit coin, it is unique in that a new transaction through a plurality of nodes through such a process proves to be an integrity transaction that is consistently and temporally non-redundant from the first generation to the present.

In order to do this, it is necessary to give compensation motive to actively participate in nodes (hereinafter referred to as "mining nodes") participating in the proof of work, and this part is so-called "mining". That is, when a mining node that performs mining solves a hash value of a specific block, a transaction record is recorded in a block and a new block is created. In this case, a certain virtual money is paid as compensation.

However, due to the nature of these proofs, it is dependent on the performance of the mining nodes participating in mining, that is, the computer capabilities, so that the mining tendency is concentrated in a small number of individuals or groups concentrating their computer skills There is a problem in. When mining is concentrated on a small number of mining nodes with strong computer power, the remaining nodes lose motivation and lose their motivation for participation. As a result, the proof of work to be performed by a plurality of nodes is concentrated on a small number of nodes, This can pose a serious threat to the verification of the block chain. In other words, if a few nodes monopolize or block the block chain verification, if these monopoly mining nodes are unified to disable the verification system, the integrity of all virtual currency transactions can not be guaranteed, resulting in the collapse of the virtual monetary system There can be serious problems that can happen.

In addition, since the new money supply of the virtual money system is performed through the virtual money mined by the mining nodes, the virtual money is concentrated on a small number of oligopolistic mining nodes, .

In addition, excessive competition is wasting resources in order to improve computer power among participating mining nodes. In other words, if the computer power increases and the block generation speeds up, it is possible to increase the hash difficulty so that a certain mining cycle (ie, job certification cycle) condition (for example, 1 minute, 10 minutes, etc.) As a result of efforts to increase the number of participating entities or groups, the number of participating entities or groups is increased, and only the number of mining monopolies is increased, and resource waste is accelerating.
For example, as a conventional technique, non-patent document 1 (Lee, Hyuk-joon, 1, 'Reliable structure of bit coin and threat of double payment') Journal of the Korea Institute of Information Security and Cryptology (Apr. 2016, pp.25-30), <URL: http://www.dbpia.co.kr/Journal/ArticleDetail/NODE06669072>), as a method to prevent unfair double payment that damages the integrity of virtual money, (P29, "4.2.5 <50%") (based on the first method of non-patent document 1), a method of adjusting the number of approvals according to the importance of transactions (P29, "5.1" (P29, "5.2") (third method of non-patent document 1) (see Non-Patent Document 1, second method), and mining speed, ).
As another conventional technique, for example, Non-Patent Document 2 (Kim, Soh-hee et al., &Quot; Self-exploiting scheme analysis of bit coin block chain &quot;. Proceedings of KIIS Fall Conference, pp.423-424
<URL: http://www.dbpia.co.kr/Journal/ArticleDetail/NODE06564742>
(50%) of the number of approvals by making the minerals selectable by spreading the phenomenon to other miners when the block is branched, focusing on the problem of block branching, Half), resulting in loss of validity, or that the branching block is not given any mining compensation regardless of the reason, and the time stamp is used to inform the generation time of the block so that only the latest block is adopted.
However, both Non-Patent Documents 1 and 2 focus on prevention of integrity, but can not prevent the problem caused by mining monopoly. Moreover, because of such mining monopoly, many miners There is a fundamental problem in that it can not prevent loss of motivation.

delete

- Lee Hyuk Jun and 1 other. 'Bitcoin' s trust structure and threat of dual payments'. Journal of information security. Journal of the Korea Institute of Information Security and Cryptology (April 2016, 26, No. 2, pp.25-30), <URL: http://www.dbpia.co.kr/Journal/ArticleDetail/NODE06669072> - Kim Sookhee et al., 'Analysis of self-exploitation strategy of bit coin block chain'. Proceedings of the Korean Institute of Communication Sciences Conference. Korean Institute of Communication Sciences. November 2015, pp.423-424 <URL: http://www.dbpia.co.kr/Journal/ArticleDetail/NODE06564742>

SUMMARY OF THE INVENTION Accordingly, the present invention has been made keeping in mind the above problems occurring in the prior art, and it is an object of the present invention to provide a block window module and a block window management server capable of reducing a min- And to provide a virtual money transaction system and method using the same.

Another object of the present invention is to prevent a decrease in the number of mining nodes participating in a proof of work in a virtual money system and to give a motivation to participate in a plurality of mining nodes, A block window module and a block window management server including a consensus algorithm for mining restriction to prevent resource waste due to excessive input of computer power and equitable distribution of mined virtual money, and a virtual money trading system And a method thereof.

A first aspect for realizing an object according to an embodiment of the present invention is a block chain-based virtual currency trading system including at least a mining node participating in a proof of work and a general node for a virtual currency transaction, Includes a block window module including a consensus algorithm for mining restricting a mining attempt to a mining attempt after the specific work proof period for a mining node that has achieved a mining success in a specific work proof cycle, The module includes a mining history management unit for recording the mining history information by linking the mining node with a result of mining attempt, As a result of performing a mining attempt based on the mining history information, a block window is set for at least a part of the mining nodes that have succeeded in mining success, such that a result of mining attempt is invalidated or a mining attempt is prohibited for a predetermined period after the corresponding job proving period A block window generating unit for generating a block window; The mining history information includes information on the number of cumulative blocks connected to the block chain, information on the number of participating mining nodes, information on the number of mining nodes having a successful mining history, mining history information of individual mining nodes, And the block window module calculates a block window size to be set for a mining node that has successfully been mined based on the mining history information and calculates a block window size for providing a block window part And a transaction history management unit for providing the virtual currency transaction history information between the general nodes during a current or recent period, and the block window size (y) calculated from the block window size calculation unit is y = [0.7 N is the total number of nodes involved, and B is the total number of participating nodes / (total number of participating nodes) / (total number of participating nodes) / (Number of nodes), C = (total number of mining nodes) / (number of participating mining nodes having mining success experience).

delete

delete

Preferably, at least one of the variables A, B, and C may include a periodic transaction amount or a transaction amount change rate as an inverse factor from the transaction history information.
A second aspect for realizing an object according to an embodiment of the present invention is a block chain-based virtual currency trading system including at least a mining node participating in a proof of work and a general node for a virtual currency transaction, Includes a block window module including a consensus algorithm for mining restricting a mining attempt to a mining attempt after the specific work proof period for a mining node that has achieved a mining success in a specific work proof cycle, The module includes a mining history management unit for recording the mining history information by linking the mining node with a result of mining attempt, As a result of performing a mining attempt based on the mining history information, a block window is set for at least a part of the mining nodes that have succeeded in mining success, such that a result of mining attempt is invalidated or a mining attempt is prohibited for a predetermined period after the corresponding job proving period A block window generating unit for generating a block window; The mining history information includes information on the number of cumulative blocks connected to the block chain, information on the number of participating mining nodes, information on the number of mining nodes having a successful mining history, mining history information of individual mining nodes, And the block window module calculates a block window size to be set for a mining node that has successfully been mined based on the mining history information and calculates a block window size for providing a block window part And a transaction history management unit for providing the virtual currency transaction history information between the general nodes during the present or recent period. When defining the oligonucleotide ratio (R) of the mining node occupying the success rate of the upper certain rate as follows (Y) = y (y) = y (y) = y (y), where y is the number of blocks minus the total number of mining nodes ) N nP (where n is a natural number and P is a block generation period), and at least one of the variables A, B, and C may include a periodic transaction amount or a transaction amount change rate as an inverse factor from the transaction history information .

delete

Preferably, the block window size is set differently for the mining node in proportion to the mining success rate, or the block window is set indiscriminately, and the node factor N is a value obtained by subtracting a predetermined period trading amount from the transaction history information Include as an inverse factor.

Preferably, the block window module further includes a blackout monitoring unit for monitoring whether a blackout occurs in which no block is generated in the system during a specific job certification period, and when the blackout occurs in the system, Out monitoring unit sets a block window release mode for releasing the block window setting already set for the mining nodes in the task certification cycle after the specific task certification cycle, The block window release mode is immediately switched to the block window mode, and the block window generation unit generates the block window in cooperation with the block window size calculation unit according to the block window mode.

Preferably, the block window module further includes a blackout monitoring unit for monitoring whether a blackout occurs in which no block is generated in the system during a specific job certification period, and the blackout monitoring unit monitors at least one or more mining When the mining history management unit records that a mining attempt is made by the node to invalidate the mining operation and the blackout monitoring unit detects that blackout has occurred during the specific operation period, Wherein the blackout monitoring unit sets the unminifying dedicated mode to the block window mode immediately after detecting that the block is generated during the job certification period after the unminifying dedicated mode is set. In accordance with the block window mode, Generation unit may regenerate the block window in conjunction with the block diagram window size computing unit.

The virtual money transaction system further includes a block window management server for updating the block window module and providing the block window module as a framework to the nodes, wherein the block window management server is an independent entity, And the block window module is provided to the nodes from the block window management server each time it is updated or is propagated from the nodes to other nodes.

A third aspect according to an embodiment of the present invention is a virtual money trading method in a block chain-based virtual money trading system including at least a mining node participating in a proof of work and a general node for a virtual currency transaction, The system includes a block window module that gives a certain restriction to a mining attempt after the specific job certification period for a mining node that has achieved mining success in a specific job proving cycle, and the mining history management unit of the block window module A mining history information recording step of recording the mining history information by linking the result of the mining attempt, which is one of the operation of the mining node's proof proving process, to the mining node; The block window generator of the block window module invalidates the result of the mining attempt for at least a part of the mining nodes that have achieved the mining success as a result of performing the mining attempt based on the mining history information, A block window setting step of setting a block window for prohibiting a mining attempt; Preferably, the mining history information includes a number of cumulative blocks connected to the block chain, information on the number of participating mining nodes, information on the number of mining nodes having a successful mining history, mining history information of individual mining nodes, mining of mining nodes Success rate, and mining monopoly rate of the upper mining nodes, and after the mining history information recording step, the transaction history management unit of the block window module provides the virtual currency transaction history information between the general nodes for the current or recent period ; Calculating a block window size to be set for a mining node in which the block window size calculating unit of the block window module succeeds in mining based on the mining history information to provide a block window; , The block window size (y) calculated from the block window size calculating unit is defined as y = [0.7 (N) x the cumulative number of blocks up to the present time)] / (the cumulative number of blocks over 10 years) N is the node factor, A = (total number of participating nodes), B = (total number of participating nodes) / (total number of mining nodes), C = (total number of mining nodes) ).

delete

delete

Preferably, at least one of the variables A, B, and C may include a periodic transaction amount or a transaction amount change rate as an inverse factor from the transaction history information.

A fourth aspect according to an embodiment of the present invention is a virtual currency trading method in a block chain-based virtual currency trading system including at least a mining node participating in a proof of work and a general node for a virtual currency transaction, The system includes a block window module that gives a certain restriction to a mining attempt after the specific job certification period for a mining node that has achieved mining success in a specific job proving cycle, and the mining history management unit of the block window module A mining history information recording step of recording the mining history information by linking the result of the mining attempt, which is one of the operation of the mining node's proof proving process, to the mining node; The block window generator of the block window module invalidates the result of the mining attempt for at least a part of the mining nodes that have achieved the mining success as a result of performing the mining attempt based on the mining history information, A block window setting step of setting a block window for prohibiting a mining attempt; Preferably, the mining history information includes a number of cumulative blocks connected to the block chain, information on the number of participating mining nodes, information on the number of mining nodes having a successful mining history, mining history information of individual mining nodes, mining of mining nodes Success rate, and mining monopoly rate of the upper mining nodes, and after the mining history information recording step, the transaction history management unit of the block window module provides the virtual currency transaction history information between the general nodes for the current or recent period ; Calculating a block window size to be set for a mining node in which the block window size calculating unit of the block window module succeeds in mining based on the mining history information to provide a block window; (R) of a mining node that occupies the highest success rate of mining success rate is defined as follows: R = [minus number of mining nodes of the upper certain ratio / number of all mining nodes (N is a natural number, and P is a block generation period), and the variables A, B, and C are defined by the following equation (1) B, and C may include, as inverse factors, a certain period of transaction amount or a change amount of transaction amount from the transaction history information.

Preferably, in the block window providing step, a block window size is set differently in proportion to a mining success rate of the mining node, or a block window is set indiscriminately, and the node argument (N) The amount of transactions from the information for a certain period is included as an inverse factor.

Preferably, the blackout monitoring unit of the block window module monitors whether a blackout occurs in which no block is generated in the system during a specific job certification period; A block window release mode setting step of setting a block window release mode in which the blackout monitoring unit releases the block window setting already set for the mining nodes in the task certification cycle after the specific task certification cycle when detecting that blackout has occurred ; When the blackout monitoring unit detects that a block has been generated during the task verification period after the block window release mode setting step, immediately switches the block window release mode to the block window mode, and in response to the block window mode, Regenerating the block window in cooperation with the window size calculating unit; .

Preferably, the blackout monitoring unit of the block window module monitors whether a blackout occurs in which no block is generated in the system during a specific job certification period; If the mining history management unit records that at least one mining node having a block window set by the mining node has been invalidated by mining attempt during the specific work period and that the blackout monitoring unit has generated blackout during the specific work period An unmining dedicated mode setting step of setting an unmining dedicated mode to switch the corresponding invalidation mining recorded in the mining history management unit to effective mining; Wherein when the blackout monitoring unit detects that a block has been generated during the operation proving period after the unminifying dedicated mode setting step, the blackout monitoring unit immediately switches the unminifying dedicated mode to the block window mode, Regenerating the block window in cooperation with the window size calculating unit; .

A fifth aspect according to an embodiment of the present invention provides a storage medium storing the block window module as a framework.

A sixth aspect according to an embodiment of the present invention provides a block window management server that can update the block window module and be provided to nodes, and is applicable to physically connect to a virtual currency trading system through a communication port.

According to the above configuration, the present invention can obtain the following effects.

According to the above configuration, the present invention can obtain the following effects.

First, since it is possible to set a block window for prohibiting additional mining at any time for mining nodes that have succeeded in mining, a few mining nodes having strong computer power or full mining nodes conspiring with few mining nodes are exclusively and exclusively The rate of successful mining can be reduced.

Second, it can prevent mining monopoly or oligopoly of mining node. As a result, mining nodes or general trading nodes alienated from mining can be given mining opportunity or motivation. Thereby preventing the work proof from being distorted.

Third, since the mining or proof-of-work process in virtual money plays the role of money issuance in real money, the block window technique of the present invention allows the virtual money to be widely distributed evenly to the public, Can be obtained.

Fourth, when applying the block window technique, even if the computer power is high, the period of prohibition of mining can be relatively long. Therefore, Method (e.g., concatenation of a pool mining node group, etc.) is substantially unnecessary. Therefore, it is possible to prevent the wasteful and wasted resources from being excessively wasted.

Fifth, a block window module may be integrally combined with a related system based on a virtual monetary system or other block chain, a form of a storage medium storing a framework type, a framework, a download form, a server combined with a framework and hardware It can be easily applied to an existing virtual money system or other block chain based system, thereby eliminating the waste of dismantling the existing system according to the new function.

FIG. 1 is a schematic block diagram of a virtual money system applying a block window function according to an embodiment of the present invention. Referring to FIG.
FIG. 2 is a schematic view showing a configuration and a relationship of a block window management server and a virtual currency function module management server that is responsible for system operation according to an embodiment of the present invention.
3 is an explanatory view showing an operation principle of a block window according to an embodiment of the present invention.
4 is a flowchart illustrating an operation process of a block window mode in a virtual money system according to an embodiment of the present invention.
5 is a graph illustrating predicted trends of future blocks and participating nodes for calculating a block window size according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings.

FIG. 1 is a schematic block diagram showing a virtual money system (hereinafter referred to as "virtual money system" or simply "system" used in combination) to which a block window is applied according to an embodiment of the present invention. Referring to the drawings, a virtual monetary system according to an embodiment of the present invention includes mining nodes MN1, MN2, MN3, and MN4 participating in mining, a virtual virtual money transaction using a P2P method, N5, N6, N7 and N8 (hereinafter referred to as "general node") that performs transactions through the network, functional software that allows nodes to perform desired functions, (Hereinafter referred to as "functional module ", a" module "used in the present invention is a unit capable of performing a specific function, and may be a functional software framework or a combination of a specific framework General software that can perform a specific function or a unit entity that can perform a specific function by combining such software and hardware) When the virtual money function module management server 200 and one of the mining nodes MN1, MN2, MN3, and MN4 have been mined according to the job certification process, A block window module (BMW) or a block window management server 100 that provides an environment for prohibiting mining, invalidating mining effects, and granting mining opportunities to other participating mining nodes.

Each component used in the system according to an embodiment of the present invention is presented for convenience of explanation and does not particularly limit the number of the components. Also, the mining nodes MN1, MN2, MN3, and MN4 and the general nodes N1, N2, N3, and N4 are also separated from each other for convenience of explanation. The general node can also have a mining function. Can be performed. Further, the node referred to in the present invention may represent each of the servers or may refer to a group of nodes, as needed. That is, if they function as independent unit entities, they can all be expressed as nodes. Thus, the transactional generic node may include anything that is capable of accessing the system as an entity, such as a smart phone, a mobile terminal, a personal PC, or a laptop computer.

For example, the communication network 70 may include a mobile communication network 71, an Internet 72, a Bluetooth BL (Personal Digital Assistant), and the like. The communication network 70 may be any of various types of communication networks, A dedicated line 73, a low power wide area network (LPWAN) 75, and the like. Specific examples of LPWAN (75), may be mentioned the US LoRaWAN ^TM, Sigfox ^TM in Europe and elsewhere as an open network Weightless ^TM, next generation networks, such as LTE. In addition, the connection between the communication network 70 and the nodes or servers can be performed in a wired manner as well as a wireless manner.

FIG. 2 is a schematic diagram showing a configuration of a block window server 100 and a virtual money function module management server 200 according to an embodiment of the present invention, and a relationship with other nodes.

First, the virtual currency function module management server 200 generally provides functional software to the nodes to maintain the virtual money system. That is, the nodes participating in the system may have some or all of the mining function module, the transaction function module (wallet), the block chain database function module, and the network routing function module. In order to provide or update such a function module, the virtual money function module management server 200 includes a mining function module management unit 210 for updating or providing a mining function module, an electronic purse (wallet) module for virtual currency transaction A block chain function module management unit that provides a function module capable of storing data of a block chain, and a network routing module that can perform a routing function of the network in and out of the system And a network routing module management unit 240. The nodes can directly download the function module from the virtual money function module management server 200 or download the function module from other nodes to perform a node operation of a desired function. The node cloud 500 may include all nodes capable of participating in the virtual money system according to one embodiment of the present invention, or nodes connectable to these nodes and various other algorithms. That is, the node cloud 500 includes mining nodes MN1, MN2 and MN3 MN4, trading general nodes N1, N2, N3 and N4, a pool mining node collectively combining mining nodes to increase computer power, Collectively pooled general nodes, various exchange servers participating in the virtual money system according to an embodiment of the present invention, and nodes of other functions directly or indirectly connected to these various nodes and servers.

Next, the concept of a block window that is uniquely proposed according to an embodiment of the present invention and a block window management server 100 to which the block window technique is applied will be described.

 The term "block window" is a term used for the first time in the present invention. The term " block window &quot; refers to a node that has achieved mining It is possible to define a function module for prohibiting the generation of blocks during a period of time and consequently stopping mining activities for a certain period of time or generating blocks through mining activities, Windows can prevent mining from being biased to certain mining nodes and provide mining opportunities for nodes with relatively low power.

The block window management server 100 according to an exemplary embodiment of the present invention may be configured separately from the virtual currency function module management server 200 to perform a block window mode operation when performing a virtual currency transaction function in a virtual currency transaction system Or may be integrally formed with the virtual money function module management server 200 to perform the same operation. If it is separately configured, it is also possible to configure the block window related operation to be carried out together with the virtual currency transaction by providing USB or a downloadable functional module to the general virtual currency trading system in the individual unit.

2, the block window management server 100 according to an embodiment of the present invention includes a mining history management unit 110 for tracking mining history of mining nodes MN1, MN2, MN3, MN4 and providing mining history information, And the transaction amount of the recent period (1 hour, 2 hours, 1 day, 1 week, etc.) and the transaction amount A transaction history management unit 120 for providing transaction history information such as a rate of change, a blackout management unit 120 for tracking the occurrence of a state in which a block can not be generated because the block is not generated, Based on the mining history information from the monitoring unit 130, the mining history management unit 110, the transaction history information from the transaction history management unit 120, and the blackout-related information from the blackout monitoring unit 130, Block window size to calculate size A block window generation unit 150 for generating a block window under the block window mode according to the block window size calculation unit 150 and providing the block window to the corresponding mining nodes MN1, MN2, MN3 and MN4, And a block window module update unit 160 that updates the function program or updates the block program module to each node of the system or system as a block window module as a function module.

In the block window management server 100, the mining history management unit 110, the transaction history management unit 120, the blackout monitoring unit 130, the block window size calculating unit 140, and the block window generating unit 150, Module (BWM) can be configured. In this case, the block window module (BWM) may be a software module or a combination of software and hardware initially combined together in the virtual currency trading system itself, or may be composed of a software framework, Based application system. Alternatively, the program may be a single object combined with hardware (for example, the block window management server 100 in this embodiment) and software, Lt; / RTI &gt; That is, in the present invention, there is no particular limitation on the existence of the block window module if it is possible to attenuate the phenomenon of mining monopoly of a monopoly mining node for that purpose.

Next, the concept and operation principle of a block window according to an embodiment of the present invention will be described with reference to FIG. 3 is an explanatory view showing an operation principle of a block window according to an embodiment of the present invention.

3, the mining operations (hereinafter referred to as "mining attempts") performed by the first mining node MN1 are M1-1, U1-2, M1-3, and U1-4, The identification number "1" of the corresponding mining node is recorded, and the order of the mining operation of the corresponding mining node is recorded in the minor number. In other words, 1-1 indicates that the first mining node MN1 has performed the first mining operation. Likewise, 1-2 indicates the second mining operation of the first mining node MN1, 1-3 indicates the third mining operation, 1- 4 represents the fourth mining operation, respectively. Also, this number "1" at W1-1 represents the first mining node MN1 and the minor number "1" represents the first block window allocated while the first mining node MN1 achieves mining success. Similarly, this number "1" at W1-2 represents the first mining node MN1 and the minor number "2" represents the second block window allocated while the first mining node MN1 achieves mining success.

Similarly, the second mining node MN2, the third mining node MN3, and the fourth mining node MN4 may interpret the semantics in the same manner as the first mining node MN.

The basic idea of the block window is that if the mining node succeeds in mining, the mining cycle starts from the submission of the mining cycle to the mining cycle (corresponding to the job certification cycle, hereinafter "work cycle" means "job certification cycle" (In the case of FIG. 3, up to three cycles), the success of mining of the corresponding mining node is inhibited.

Referring again to FIG. 3, the following will be described in detail.

If the first mining node MN1 succeeds in the mining attempt M1-1 at period t1, the block window module performs the mining attempt U1-2 of the first mining node MN1 during the period t2 to t4 (three periods) Is set as the first block window W1-1. The block window module BWM records the portion where the first mining node MN1 succeeds in mining, for example, "1-1" by using the function of the mining history management unit 110 Mining history part "M", see row t1). Then, even if the first mining node MN1 tries to mining at the cycle t3 or solves the block hash value, it is recorded as "1-2" in the "U" column of the unmining which means the mining failure The third mining node MN3 that has performed the mining attempt M3-1 at the same cycle t3 succeeds in mining and the t3 of the mining history management unit 110 Quot; 3-1 "in the period" M "column.

In the cycle t2, only the second mining node MN2 succeeds in the mining attempt M2-1 and is recorded as "2-1" in the M column, and the block window is set to the second mining node for the period t3 to t5. Therefore, at period t5, the mining attempt (U2-2) of the second mining node (MN2) is recorded as failure (see U column "2-2").

In the cycle t4, the block window is set in the third mining node MN3 for the period from t4 to t6. During this setting period, the mining attempt U3-2 is recorded as "3-2 & The mining attempt (M4-1) of the mining node MN4 succeeds and is recorded in the M column as "4-1 ".

In the t5 period and the t6 period, the mining attempt (U2-2) of the second mining node (MN2) and the mining attempt (U4-2) of the fourth mining node (M4) Quot; 2-2 "and" 4-2 "in the U column, and a cycle in which mining does not occur (hereinafter referred to as" blackout " The operation of the blackout period will be described later.

Even in the period from t7 to t13, the principle of operation is basically the same as the cycle t0 to t6 except for the occurrence of the blackout BO. Therefore, only the case where a blackout (BO) state in which mining does not occur will be described next.

When there is no blackout, basically, as described above, if a first mining occurs, a block window period for invalidating the result of the mining attempt for the next three cycles is set for the mining node (" Quot;), the block window mode is canceled or the result of the mining attempt that was invalidated during the block window period is validated if a blackout occurs due to the setting of all the block windows or due to the lack of participation of the node, The "unmining dedicated mode"

For example, in the periods t5 and t6, a block window is set for the second mining MN2, the third mining MN3, and the fourth mining MN4, and the block window is set for the second mining node MN2 The mining attempt U2-2 is registered as "2-2" in the U column of the mining history management unit 110 and the mining attempt U4-2 generated by the fourth mining MN4 at the time t6 is also U Quot; 2-2 "to cause blackout that blocks can not be generated.

In this case, the mining failure of the nullified mining attempts U2-2 and U4-2 is converted to mining success, and "2-2" in the U column and "4-2" Mining dedicated mode may be used to switch to a successful mining so that blocks are actually created.

As another embodiment of the operation mode of the blackout, if a blackout occurs in the cycle t8 and all the mining nodes do not attempt the mining, the block window release mode in which the block window mode is immediately released for a predetermined period from the next cycle t9 . Referring to FIG. 3, a block window release mode (W-RE) is set at a cycle t9 and a cycle t10. In this case, the mining attempt U1-4 of the first mining node MN1 and the mining attempt -3 is performed in the block window release mode, all of the mining attempts are recorded in the M column of the mining history management unit 110 with success of mining. In the block window release mode (W-RE), all the mining nodes do not perform the mining attempt. However, the mining node attempts mining attempt as in the mining-only mode, but the mining attempt is invalidated by setting the block window The block window release mode operation may be performed immediately in the next cycle without switching the invalidated mining attempt to validation.

In the block window release mode or the unminifying exclusive mode, when at least one of the participating nodes succeeds in mining, the blackout monitoring unit 130 automatically releases the block window mode and returns to the block window mode, The block window size calculator 140 generates block windows appropriately and assigns or sets the block windows to the corresponding mining nodes.

Next, in the cycle t11 when returning to the normal block window mode, the mining attempt M3-3 of the third mining node MN3 is registered as "3-3" in the column M indicating the mining success, The block window W3-2 is set in the cycle t12 to t14 of the third mining node MN3.

In the case of the fourth mining attempt (U2-4) of the second mining node MN2 at the cycle t12, since the mining attempt is the first mining attempt after the block window is released but failed, it is registered as "2-4" in the U column, The window is not set in the second mining node MN2. In the cycle t12, the third mining attempt (M4-3) of the fourth mining node MN4 is recognized as mining success and registered as "4-3" in the M column.

 At cycle t13, the fourth mining attempt (U3-4) of the third mining node MN3 is registered as 3-4 in the U column in the block window configuration, but can be dedicated and used as a mining success through the mining-only mode .

The concept of the block window of the present invention has been described above. However, the block window of the present invention is not limited to the block window mode (BW), the unmining dedicated mode (U-TR), and the block window release mode (W-RE). For example, it is possible to set block windows differently according to the mining success rate of the entire mining node, or to set the setting period of the block window differently.

Next, referring to FIG. 4, a description will be made of an operation process for a consensus algorithm of a virtual money transaction system to which a block window according to a preferred embodiment of the present invention is applied.

The four mining nodes MN1, MN2, MN3, and MN4 in the virtual monetary system (FIG. 1) according to an embodiment of the present invention will be described as an example. For the sake of simplicity, the names of four mining nodes are referred to as a first mining node MN1, a second mining node MN2, a third mining node MN3, and a fourth mining node MN4. It is assumed that at least some of each mining node has differentiation in computer power. In addition, the virtual currency trading system according to an embodiment of the present invention basically includes at least a part of environment and mining functions capable of trading virtual money through P2P through the virtual money function module management server 200, It is assumed that it is already equipped.

In addition, although the block window management server 100 of FIG. 2 is a concept of combining hardware and software, it may be configured as a block window module composed only of software. In this case, the block window module is a component of the block window management server 100. The block window module includes a mining node history management unit 110, a transaction history management unit 120, a blackout monitoring unit 130, a block window size calculation unit 140, The respective blocks 110, 120, 130, 140, and 150 of each block window management server 100 may be equally included in the software block window module 150. [ May be included, and this portion is as described above.

Hereinafter, an example in which the block window management server 100 performs the block window related operation will be described.

Step S1: The block window management server 100 provides the block window module to all participating nodes in the virtual money transaction system through the block window module update unit 160. [ The general node or the mining node may receive the block window module from other nodes that have already been downloaded to the P2P. The block window module update unit 160 may provide an updated version of the block window module and an updated latest block window module at any time.

As another embodiment, a block window agreement algorithm may be included together with a job proof module, a mining module or a general trading module (Wallet module) of a virtual money system. In this case, step S1 may perform a task of starting a virtual money system in which a block window module already exists.

Step S2: A transaction in which virtual money is exchanged between nodes in a virtual money transaction system is performed, and the transaction details (hereinafter referred to as " transaction " MN2, MN3, and MN4, and general nodes N1, N2, N3, and N4 during a period of 3 minutes, 10 minutes, and so on.

Step S3: One of the mining nodes, for example, the first mining node MN1 releases the block hash to write a transaction history in the job proofing period, that is, a transaction into a block to generate a new block, MN3, MN4, N1, N2, N3, N4).

Step S4: Other nodes approve the validity of the new block generated by the first mining node MN1.

Step S5: It is determined whether the approval number of the nodes exceeds a predetermined value (for example, 50% of the participating mining nodes) and the condition of the job certification cycle (for example, 1 minute, 10 minutes, (100) through the transaction history management unit (120).

Step S6: If the transaction history management unit 120 judges that the approval criteria and the job certification cycle are satisfied in step S5, the mining history management unit 110 recognizes that the mining has succeeded. If the mining history management unit 110 determines that the mining is successful, Register the success history (success count, time). Specifically, in FIG. 3, the mining node history management unit 110 determines that the mining attempt M1-1 of the first mining node MN1 is successful and informs the mining success register M of the mining success of the first mining node MN1 Register information. For example, the identifier ("1") of the first mining node and the mining success history (number of times "1") are registered Time, mining success rate, mining success share associated with the entire mining node, overall success and percentage of the upper percentage (eg, top 5%, 10%, 20%, 30%, 50% have.

Step S7: The transaction history management unit 120 also calculates and updates the number of blocks formed so far.

Step S8: The block window size calculating unit 140 calculates the current block window size based on the number (the number of blocks) of all the blocks connected to the block chain up to now and the mining history information about the mining node.

The block window size calculating unit 140 may calculate the block window size using, for example, the following equation.

y = (N * 0.7) / BLOCK_NUM_OF_MAX_BLOCKWINDOW * x

(if x > BLOCK_NUM_OF_MAX_BLOCKWINDOW then x = BLOCK_NUM_OF_MAX_BLOCKWINDOW)

y: Block window size

x: number of current blocks

BLOCK_NUM_OF_MAX_BLOCKWINDOW: Block number of block window maximum size (10 years; 1,752,000)

N can be defined as node arguments (A = number of participating nodes / mining node, or B = total number of mining nodes / number of mining nodes with experience of mining success, or C = number of oligonormal nodes / number of participating mining nodes)

The basic idea of calculating the block window size is based on the assumption that there are not many participating mining nodes or general nodes in the beginning, but it is expected to normalize over time and gradually expand the block window size. However, There is a limit to the practical limit, so you can not increase indefinitely. Therefore, it is possible to operate the virtual currency trading system while setting the maximum block window size or the maximum window size in advance and setting the size of the block window size appropriately.

In this basic concept, since the current block number x will increase over time, the current block number x is set as a direct-proportional variable, and the number of blocks (BLOCK_NUM_OF_MAX_BLOCKWINDOW) at the maximum window size Wm is set as an inverse variable , The block window size (y) can be calculated using the node argument (N = A or B or C) as the direct proportional variable.

Table 1 below shows the trends of block numbers per year, week, day, hour, and minute. NO in Table 1. (Min) / 3360 (number of blocks) = 3. Therefore, it takes 3 minutes for one block to be generated, so that in one embodiment (Ie, the job certification cycle) is 3 minutes in the virtual currency trading system according to the present invention, that is, an example of a virtual currency trading system in which one mining success occurs every 3 minutes is shown in Table 1 .

NO. year week Work city minute Number of blocks N Wm One One 365 8,760 525,600 175,200 100 7.000 2 5 1,825 43,800 2,628,000 876,000 100 35,000 3 10 3,650 87,600 5,256,000 1,752,000 100 70,000 4 20 7,300 175,200 10,512,000 3,504,000 100 70,000 5 30 10,950 262,800 15,768,000 5,256,000 100 70,000 6 ** ** ** ** ** ** ** ** 7 One 7 168 10,080 3,360 100 0.134 8 2 14 336 20,160 6,720 100 0.268 9 3 21 504 30,240 10,080 100 0.403 10 4 28 672 40,320 13,440 100 0.537 11 5 35 840 50,400 16,800 100 0.671 12 6 42 1,008 60,480 20,160 100 0.805 13 7 49 1,176 70,560 23,520 100 0.940 14 8 56 1,344 80,640 26,880 100 1.074 15 9 63 1,512 90,720 30,240 100 1.208 16 10 70 1,680 100,800 33,600 100 1.342

FIG. 5 is a graph of a maximum block window size (y) predicted according to an increase in the number of predicted blocks over 100 years. Referring to FIG. 5, when the number of blocks is equal to 1,752,000 (see Table 1) at the time of 10 years, and when the supply amount of virtual money and the block number (mined amount) It becomes a period that can be realized. Since the entire virtual money is monetary supplied by the amount of mining, from this point on, the timing or motivation for the mining node to mince the virtual money decreases. Therefore, it is also possible to set the time point at which the increase in the size of the block window is stopped to be 10 years. In addition, multiplying the node factor by 0.7 assumes that the block window size is limited based on the maximum of about 70% of the total number of participating nodes without assuming the block window size based on the total number of participating nodes. The node argument N is set to 100 for simplification but actually A = (total number of participating nodes), B = (total number of participating nodes) / (total number of mining nodes), C = (total number of mining nodes) / The number of participating mining nodes with success experience), etc., and any formula is possible if the block window size can be determined in such a way that the monopoly rate or the oligosity rate of the mining node becomes as small as possible. If the node argument N is at least one of A, B, and C, or is a formula including other variables, the transaction history management unit 120 may determine a predetermined period (for example, 1 hour, 3 hours, , 1 week, 1 month, etc.), it may include the transaction amount, the change amount of the transaction amount, and the change amount of the transaction amount in inverse proportion from the transaction history information showing the transaction amount related data such as the change amount of the transaction amount, In this case, when the transaction volume increases sharply in a short time, there is an advantage that the block window size can be reduced and the transaction volume can be temporarily processed quickly.

Specifically, as shown in Fig. The one-week block window size (y) of 7 can be calculated as follows.

y (1 week) = [0.7 (N) (1 week blocks)] / 1752000 (10 years blocks) = 0.134 (Wm)

Therefore, the block window size can be increased by 0.134 every 10 weeks for 10 years. However, since the block window size can vary according to the node argument N, the increase or decrease may occur continuously, and even after 10 years, the increase or decrease may occur depending on the change of the node argument.

In another embodiment, when defining the monopoly rate of a mining node (e.g., top 5%, 10%, top 20%, top 50%, etc.)

(The number of blocks) / total number of mining nodes (number of blocks) of participating mining nodes] (mining period is a recent period, for example, recent 1 month, recent 3 months, recent 6 months, the last one year, etc.)

The block window size y may be simply defined as y = (monopolar rating) x nP (n is a natural number, and P is a block generation period, for example, 1 minute, 3 minutes, 10 minutes, etc.).

In this case, since the block window size becomes larger as the monopoly rate of the monopoly mine node becomes larger, it is possible to prevent the exclusive and oligopolistic mining of the mining node in a realistic and direct manner.

In another embodiment, a monolithic mining node having a higher percentage (for example, from the upper 0% to the upper 50%, such as the upper 10%, upper 20%, upper 50%, etc.) You can also assign or set the window size. In this case, a block window may not be set for a mining node having a certain minus occupancy rate.

In another embodiment, the block window size may be differentiated in proportion to the mining occupancy, and a block window may be set by setting a difference in size among all the nodes.

As another embodiment, it is possible to set a block window or a block window size differently in proportion to a mining occupancy rate of a mining node in a recent short period. In this case, when the transaction volume suddenly surges, the block window size is decreased in the block window mode or the temporary block window release mode through the change of the transaction amount or the transaction amount, , The normal block window mode operation can be performed again when the transaction volume is restored to the normal operation amount, the daily average transaction amount, the round-robin average transaction amount, etc.).

Even in such a case, the phenomenon of concentration of mining only in a part of the mining nodes can be prevented, and thus the object of the present invention can be achieved.

When the size of the block window is calculated, in step S9, a block window mode for calculating an appropriate window size only for a mining node having a mining success rate equal to or higher than a predetermined ratio, for each mining node achieving mining according to the calculated block window size To operate the virtual currency trading system.

In step S10, when blackout occurs, the blackout monitoring unit 130 cancels the block window mode operation (block window release mode) in step S11. When the block window release mode is set in the system, it is preferably performed in a blackout period (for example, at cycle t8 in FIG. 3) when all the mining nodes are in a state of not attempting a mining operation Corresponds to the period t9 to t10 in Fig. 3).

As another embodiment, if another mining mode is selected for a mining attempt (e.g., a second mining attempt (U2-2) of the second mining node (MN2) of Figure 3 and a second mining attempt of the fourth mining node (Corresponding to the cycle t5 to t6 in FIG. 3), but is not recognized as effective mining (for example, in the case of the state 2 "and" 4-2 "of the mining history management unit 110 of the mining history management unit 110, the blackout monitoring unit 130 switches to the mining- "2-2 "," 4-2 ") can be dedicated to mining registration.

When the process of step S11 is finished, the process goes to step S12, the process up to now is updated, and the process is propagated to each node. Then, the process goes to step S2 and the process from the beginning is repeated.

If blackout does not occur in step S10, the process also proceeds to step S12, updates the process up to this point, propagates to each node, and then proceeds to step S2 to repeat the process from the beginning.

Although the preferred embodiments of the present invention have been described above, the scope of the present invention is not limited thereto. For example, the block window module may be integrally combined with a virtual money system or other related system based on a block chain, or a combination of a framework type, a storage medium storing a framework, a download form, a framework and hardware Server type, etc., it can be easily applied to an existing virtual money system or other block-chain-based system, thereby eliminating the waste of dismantling the existing system according to the new function. In addition, the present invention can be applied not only to a virtual currency system but also to all systems applying a block chain, depending on its application. Therefore, the present invention is susceptible to various modifications and variations by those skilled in the art without departing from the scope of the following claims.

70: communication network 71: mobile communication network
72: Internet 73: Bluetooth BL
74: Private line 75: LPWAN
100: Block window management server 110: Mining history management unit
120: transaction history management unit 130: blackout monitoring unit
140: block window size calculating unit 150: block window generating unit
160: Block window module update unit 200: Virtual currency function module management server
210: Mining function module management unit 220: Wallet function module management unit
230: Block Chain Function Module Management Unit 240: Network Routing Module Management Unit 300: Virtual Currency Exchange Server
MN1, MN2, MN3, MN4: First to fourth mining nodes
N5, N6, N7, N8: Normal node

Claims (22)

1. A block chain-based virtual currency trading system comprising at least a mining node participating in a proof of work and a general node for a virtual currency transaction,
The virtual currency transaction system includes a block window module including a consensus algorithm for mining restriction that gives a certain restriction to a mining attempt after the specific job proof period for a mining node that has succeeded in mining at a specific job proving period and,
The block window module comprises:
A mining history management unit that records the mining history information in association with the mining node with a result of the mining attempt, which is one of the operation of the mining node in the proof process;
As a result of performing a mining attempt based on the mining history information, a block window is set for at least a part of the mining nodes that have succeeded in mining success, such that a result of mining attempt is invalidated or a mining attempt is prohibited for a predetermined period after the corresponding job proving period A block window generating unit for generating a block window;
Including,
The mining history information includes information on the number of cumulative blocks connected to the block chain, the number of participating mining nodes, the number of mining nodes having a successful mining history, the mining history information of individual mining nodes, the mining success rate of mining nodes, A monopoly rate, and an oligosity rate,
The block window module includes a block window size calculator for calculating a block window size to be set for a mining node that has successfully mined based on the mining history information and providing a block window, And a transaction history management unit for providing history information,
Wherein the block window size (y) calculated from the block window size calculating unit
y = [0.7 (N) x cumulative number of blocks until now)] / (cumulative number of blocks in 10 years)
Lt; / RTI &gt;
N is a node argument
A = (total number of participating nodes), B = (total number of participating nodes) / (total number of mining nodes), C = (total number of mining nodes) / (number of participating mining nodes having mining success experience)
The virtual currency transaction system comprising: delete delete The method according to claim 1,
Wherein at least one of the variables A, B, and C can include a periodic transaction amount or a transaction amount change rate from the transaction history information as inverse factors. 1. A block chain-based virtual currency trading system comprising at least a mining node participating in a proof of work and a general node for a virtual currency transaction,
The virtual currency transaction system includes a block window module including a consensus algorithm for mining restriction that gives a certain restriction to a mining attempt after the specific job proof period for a mining node that has succeeded in mining at a specific job proving period and,
The block window module comprises:
A mining history management unit that records the mining history information in association with the mining node with a result of the mining attempt, which is one of the operation of the mining node in the proof process;
As a result of performing a mining attempt based on the mining history information, a block window is set for at least a part of the mining nodes that have succeeded in mining success, such that a result of mining attempt is invalidated or a mining attempt is prohibited for a predetermined period after the corresponding job proving period A block window generating unit for generating a block window;
Including,
The mining history information includes information on the number of cumulative blocks connected to the block chain, the number of participating mining nodes, the number of mining nodes having a successful mining history, the mining history information of individual mining nodes, the mining success rate of mining nodes, A monopoly rate, and an oligosity rate,
The block window module includes a block window size calculator for calculating a block window size to be set for a mining node that has successfully mined based on the mining history information and providing a block window, And a transaction history management unit for providing history information,
When the minutia ratio (R) of a mining node that occupies the highest success rate of mining success rate is defined as follows,
R = [number of blocks (number of blocks) / total number of mining nodes (number of blocks))
The block window size (y)
y = (degree of oligonormal) x nP (n is a natural number, and P is a block generation cycle)
Lt; / RTI &gt;
Wherein at least one of the variables A, B, and C can include a periodic transaction amount or a transaction amount change rate from the transaction history information as inverse factors. 6. The method of claim 5,
A block window size is discriminately set in proportion to a mining success rate of the mining node, a block window is set indiscriminately,
Wherein the node argument (N) includes a periodic transaction amount from the transaction history information as an inverse proportion argument. 7. The method according to any one of claims 4 to 6,
Wherein the block window module further includes a blackout monitoring unit for monitoring whether blackout occurs in which no block is generated in the system during a specific job certification period,
The blackout monitoring unit sets a block window release mode for releasing the block window setting already set for the mining nodes in the task certification cycle after the specific task certification cycle,
Wherein the blackout monitoring unit switches the block window release mode to the block window mode upon detecting that the block is generated during the task verification period after the block window release mode is set, And generates the block window in cooperation with the window size calculating unit. 7. The method according to any one of claims 4 to 6,
Wherein the block window module further includes a blackout monitoring unit for monitoring whether blackout occurs in which no block is generated in the system during a specific job certification period,
If the mining history management unit records that at least one mining node having a block window set by the mining node has been invalidated by mining attempt during the specific work period and that the blackout monitoring unit has generated blackout during the specific work period Mining dedicated mode to switch the corresponding invalidation mining recorded in the mining history management unit to effective mining,
Wherein the blackout monitoring unit immediately switches the unminifying dedicated mode to the block window mode upon detecting that the block has been generated during the task proof period after the unminifying dedicated mode is set, And generates the block window in cooperation with the window size calculating unit. 8. The method of claim 7,
The virtual currency transaction system further comprises a block window management server for updating the block window module and providing the block window module as a framework to the nodes,
The block window management server is an independent entity and can be coupled to a general virtual currency transaction system through a specific communication connector. The block window module is provided to the nodes from the block window management server each time the block window management server is updated, The virtual currency transaction system comprising: 9. The method of claim 8,
The virtual currency transaction system further comprises a block window management server for updating the block window module and providing the block window module as a framework to the nodes,
The block window management server is an independent entity and can be coupled to a general virtual currency transaction system through a specific communication connector. The block window module is provided to the nodes from the block window management server each time the block window management server is updated, The virtual currency transaction system comprising: A virtual currency trading method in a block chain-based virtual currency trading system including at least a mining node participating in a proof of work and a general node for a virtual currency transaction, the virtual currency trading system comprising: A block window module including a consensus algorithm for a mining restriction that gives a certain constraint on a mining attempt after the specific job certification period for a mining node,
A mining history information recording step of recording mining history information in association with a mining node with a mining history management unit of the block window module, the mining node having a result of a mining attempt,
The block window generator of the block window module invalidates the result of the mining attempt for at least a part of the mining nodes that have achieved the mining success as a result of performing the mining attempt based on the mining history information, A block window setting step of setting a block window for prohibiting a mining attempt;
Including,
The mining history information includes information on the number of cumulative blocks connected to the block chain, the number of participating mining nodes, the number of mining nodes having a successful mining history, the mining history information of individual mining nodes, the mining success rate of mining nodes, And a monopoly rate,
After the mining history information recording step,
The transaction history management unit of the block window module providing virtual currency transaction history information between common nodes for a current period or a recent period;
Calculating a block window size to be set for a mining node in which the block window size calculating unit of the block window module succeeds in mining based on the mining history information to provide a block window;
Further,
Wherein the block window size (y) calculated from the block window size calculating unit
y = [0.7 (N) x cumulative number of blocks until now)] / (cumulative number of blocks in 10 years)
Lt; / RTI &gt;
N is a node argument
A = (total number of participating nodes), B = (total number of participating nodes) / (total number of mining nodes), C = (total number of mining nodes) / (number of participating mining nodes having mining success experience)
The virtual currency transaction method comprising: delete delete 12. The method of claim 11,
Wherein at least one of the variables A, B, and C includes a periodic transaction amount or a transaction amount change rate as an inverse factor from the transaction history information. A virtual currency trading method in a block chain-based virtual currency trading system including at least a mining node participating in a proof of work and a general node for a virtual currency transaction, the virtual currency trading system comprising: A block window module including a consensus algorithm for a mining restriction that gives a certain constraint on a mining attempt after the specific job certification period for a mining node,
A mining history information recording step of recording mining history information in association with a mining node with a mining history management unit of the block window module, the mining node having a result of a mining attempt,
The block window generator of the block window module invalidates the result of the mining attempt for at least a part of the mining nodes that have achieved the mining success as a result of performing the mining attempt based on the mining history information, A block window setting step of setting a block window for prohibiting a mining attempt;
Including,
The mining history information includes information on the number of cumulative blocks connected to the block chain, the number of participating mining nodes, the number of mining nodes having a successful mining history, the mining history information of individual mining nodes, the mining success rate of mining nodes, And a monopoly rate,
After the mining history information recording step,
The transaction history management unit of the block window module providing virtual currency transaction history information between common nodes for a current period or a recent period;
Calculating a block window size to be set for a mining node in which the block window size calculating unit of the block window module succeeds in mining based on the mining history information to provide a block window;
Further,
When the minutia ratio (R) of a mining node that occupies the highest success rate of mining success rate is defined as follows,
R = [number of blocks (number of blocks) / total number of mining nodes (number of blocks))
The block window size (y)
y = (degree of oligonormal) x nP (n is a natural number, and P is a block generation cycle)
Lt; / RTI &gt;
Wherein at least one of the variables A, B, and C includes a periodic transaction amount or a transaction amount change rate as an inverse factor from the transaction history information. 16. The method of claim 15,
In the block window providing step,
A block window size is discriminately set in proportion to a mining success rate of the mining node, a block window is set indiscriminately,
Wherein the node argument (N) includes a periodic transaction amount from the transaction history information as an inverse proportion factor. 17. The method according to any one of claims 14 to 16,
A blackout monitoring step of monitoring a blackout monitoring unit of the block window module whether a blackout occurs in which no block is generated in the system during a specific job certification period;
A block window release mode setting step of setting a block window release mode in which the blackout monitoring unit releases the block window setting already set for the mining nodes in the task certification cycle after the specific task certification cycle when detecting that blackout has occurred ;
When the blackout monitoring unit detects that a block has been generated during the task verification period after the block window release mode setting step, immediately switches the block window release mode to the block window mode, and in response to the block window mode, Regenerating the block window in cooperation with the window size calculating unit;
Further comprising the steps of: 17. The method according to any one of claims 14 to 16,
A blackout monitoring step of monitoring a blackout monitoring unit of the block window module whether a blackout occurs in which no block is generated in the system during a specific job certification period;
If the mining history management unit records that at least one mining node having a block window set by the mining node has been invalidated by mining attempt during the specific work period and that the blackout monitoring unit has generated blackout during the specific work period An unmining dedicated mode setting step of setting an unmining dedicated mode to switch the corresponding invalidation mining recorded in the mining history management unit to effective mining;
Wherein when the blackout monitoring unit detects that a block has been generated during the operation proving period after the unminifying dedicated mode setting step, the blackout monitoring unit immediately switches the unminifying dedicated mode to the block window mode, Regenerating the block window in cooperation with the window size calculating unit;
Further comprising the steps of: 17. A storage medium storing a block window module according to claim 17 as a framework. 18. A storage medium storing a block window module according to claim 18 as a framework and applicable to a virtual currency trading system. 17. A block window management server capable of updating block window modules according to claim 17 and providing them to nodes and physically connecting to a virtual currency trading system through a communication port. 18. A block window management server capable of updating a block window module according to claim 18 and providing it to nodes and physically connecting to a virtual currency trading system through a communication port.

Images