KR102172751B1 - Method and system for exchanging cryptocurrency - Google Patents

Abstract

A virtual currency trading system and method are presented, and according to an embodiment, a system for virtual currency trading generates a trading pair by matching other orders to be concluded with the order for processing an order requesting a virtual currency transaction. A first matching server, and a coordination device in which the first matching server is added to the transaction system, wherein the coordination device registers a second matching server when the first matching server fails to process the order.

Description

Virtual currency trading method and system {METHOD AND SYSTEM FOR EXCHANGING CRYPTOCURRENCY}

The embodiments disclosed in this specification relate to a method and system for trading virtual currency, and more specifically, a virtual currency transaction that enables a secure transaction by flexibly responding to failures in virtual currency transactions that must be executed in sequence. It relates to a method and system.

In recent years, as cryptocurrencies such as Bitcoin and Ethereum have credibility and value as currency, the transaction has become active. For example, you can buy virtual currency with real money, and you can buy real money with virtual currency. Also, depending on the value of the virtual currency itself, it is also subject to exchange with other virtual currency.

As the cryptocurrency transaction becomes more active, the need for a system that can process cryptocurrency safely while transacting quickly is increasing. In addition, since the amount of cryptocurrency is flexible, a system that can flexibly respond to the increase in cryptocurrency transaction requests is required. However, today's systems that mediate cryptocurrency transactions only perform transactions, and when a transaction is concluded quickly or an error occurs in the system, countermeasures for the above-described failure are insufficient.

In relation to Korean Patent Publication No. 10-2018-0107037, a payment system in which a buyer can use it by converting it into cash according to the market price of virtual currency, and a seller can request a payment in the same way as a general payment and receive payment in cash or virtual currency. It only proposes for and does not satisfy the above-described needs.

Therefore, there is a need for a technology to meet the needs described above.

On the other hand, the above-described background technology is technical information that the inventor possessed for derivation of the present invention or acquired during the derivation process of the present invention, and is not necessarily known to be publicly known before filing the present invention. .

Embodiments disclosed herein are aimed at presenting a virtual currency trading system and method.

The embodiments disclosed in the present specification aim to provide a cryptocurrency trading system and method capable of efficiently processing orders by increasing the number of orders processed per second.

The embodiments disclosed in the present specification aim to provide a virtual currency trading system and method that can easily expand a virtual currency trading service.

The embodiments disclosed in the present specification aim to provide a virtual currency trading system and method capable of actively coping with a failure that may occur in a trading system.

The embodiments disclosed in this specification aim to provide a virtual currency trading system and method capable of minimizing the load on a database.

The embodiments disclosed in the present specification aim to provide a cryptocurrency trading system and method that can safely use user data.

As a technical means for achieving the above-described technical problem, according to an embodiment, as a system for virtual currency transaction, a transaction pair by matching other orders to be concluded with the order to process an order requesting a virtual currency transaction A first matching server for generating a, and a coordination device in which the first matching server is added to the transaction system, wherein the coordination device registers a second matching server when the first matching server fails to place the order. Process.

According to another embodiment, a cryptocurrency trading system including a first matching server for generating a trading pair by matching other orders to be concluded with the order for processing an order requesting a cryptocurrency transaction, transacts cryptocurrency As a method of doing so, it includes the step of registering a second matching server to process the order when the first matching server fails.

According to another embodiment, as a computer-readable recording medium in which a program for performing a virtual currency transaction method is recorded, the virtual currency transaction method includes registering a second matching server to process an order when the first matching server fails. Includes steps.

According to another embodiment, as a computer program performed by a virtual currency trading system and stored in a medium to perform a virtual currency trading method, the virtual currency trading method registers a second matching server when the first matching server fails. And processing the order.

According to any one of the above-described problem solving means, it is possible to propose a virtual currency trading system and method.

According to any one of the above-described problem solving means, it is possible to provide a virtual currency trading system and method capable of efficiently processing orders by increasing the number of orders processed per second.

According to any one of the above-described problem solving means, a virtual currency trading system and method capable of easily expanding a virtual currency trading service can be provided. That is, even if the order volume increases or the transaction volume according to order processing increases, the service can be expanded by scaling out the system.

According to any one of the above-described problem solving means, a virtual currency trading system and method capable of actively coping with a failure that may occur in a trading system can be provided. Therefore, when providing a virtual currency transaction service, it is possible to trade virtual currency without interruption of the service.

According to any one of the above-described problem solving means, a virtual currency trading system and method capable of minimizing the load on the database can be provided. By queuing the order to the matching server that processes the order by the admission server that obtains the order constituting the transaction system, the matching server does not have to pick up the order from the database, and as a result, the load on the database can be minimized.

According to any one of the above-described problem solving means, it is possible to propose a virtual currency trading system and method that can safely use user data. That is, by requesting a lease of user data, data contention that may occur when the admission server or the commit server uses the cache server can be prevented.

The effects that can be obtained in the disclosed embodiments are not limited to the above-mentioned effects, and other effects not mentioned are obvious to those of ordinary skill in the art to which the embodiments disclosed from the following description belong. Can be understood.

1 to 3 are configuration diagrams illustrating a virtual currency trading system according to an embodiment.
4 to 6 are flowcharts illustrating a method of trading virtual currency according to an embodiment.

Hereinafter, various embodiments will be described in detail with reference to the accompanying drawings. The embodiments described below may be modified and implemented in various different forms. In order to more clearly describe the features of the embodiments, detailed descriptions of matters widely known to those of ordinary skill in the art to which the following embodiments belong are omitted. In addition, parts not related to the description of the embodiments are omitted in the drawings, and similar reference numerals are attached to similar parts throughout the specification.

Throughout the specification, when a component is said to be "connected" with another component, this includes not only the case where it is'directly connected', but also the case where it is'connected with another element in the middle.' In addition, when a certain configuration "includes" a certain configuration, this means that other configurations may be further included rather than excluding other configurations, unless otherwise specified.

Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings.

1 to 3 are diagrams showing the configuration of a virtual currency trading system according to an embodiment.

In relation to this,'virtual currency' is a kind of electronic money that remains in the form of information on computers, etc., and is traded in the cyber world, and is sometimes called cryptocurrency.

The virtual currency transaction system (for convenience of explanation, hereinafter referred to as a transaction system) 100 recognizes the transaction as an order when a user requests a transaction for virtual currency (for example, selling virtual currency, buying virtual currency, etc.) And process the order to complete the transaction.

Referring to FIG. 1, a transaction system 100 according to an embodiment includes a matching server 120.

In addition, it may include an admission server 110, a commit server 130, a cache server 140, and a database 150 according to an embodiment.

The admission server 110 according to an embodiment communicates with an external system (not shown) of the transaction system 100 and receives a user's request to sell or purchase a virtual currency from an external system (not shown).

The admission server 110 may process the sell/buy request received from an external system as a'order'. For example, the admission server 110 may obtain an order requesting to buy one bitcoin at a price of 100 won. At this time, the order has an identifier that can be distinguished from other orders, and the identifier allows each order to be uniquely recognized.

At this time, the admission server 110 may distinguish the type of order. An order can be, for example, a'limit price transaction' that allows you to buy or sell only at a fixed amount, a'market price transaction' that allows you to buy or sell at the amount that the transaction is being concluded on the market at the time requested, and when certain conditions are satisfied, or There may be a'stop trading' that allows you to buy/sell only until certain conditions are satisfied. The admission server 110 may distinguish types of orders and allow at least some of the requested orders to be concluded.

The admission server 110 may distinguish the types of the acquired orders and, when it is determined that the order is a'limited price transaction' or a'market price transaction', may transmit the order to the matching server 120. In addition, when it is determined that the order is “stop transaction”, the order may be delivered to a stop order server 160 to be described later. In this case, the'stop transaction' may be reacquired as a'designated price transaction' or a'market price transaction' through the stop order server 160, and the reacquired order may be transmitted to the matching server 120.

When the admission server 110 obtains an order, the admission server 110 may request the cache server 140 to obtain user data.

In this case, the “user data” is information necessary for the transaction of virtual currency and includes all information about the user, and may include, for example, information about the user's balance. In addition, for example, the user data may include an order book that records a requested order or deletes an order upon completion of order processing.

For acquiring user data, according to an embodiment, the admission server 110 may request a lease from the cache server 140 for user data, but the method for acquiring user data is limited to the above-described example. Not, for example, the admission server 110 may request a lock on user data.

The admission server 110 that has obtained the user data may check whether the user requesting the order has a balance for processing the order by referring to the user data.

In addition, when it is determined that there is a balance, the admission server 110 may return the lease-requested data to the cache server 140 and transmit information about the order together. The cache server 140, which will be described in more detail below, may record the order in the user's order book stored in the database 150 while acquiring the order information. In addition, the admission server 110 may transmit order information to the cache server 140 and transmit its own identifier (for example, a server ID) as well, so that the server identifier is stored in the database 150.

In addition, the admission server 110 may transmit a result value of the order to an external system (not shown).

Also, the admission server 110 may queue the order to the matching server 120.

The above-described admission server 110 may be implemented as one or more instances and may be scaled out while increasing instances.

The matching server 120 according to an embodiment creates a transaction pair by matching the queued orders.

That is, the matching server 120 can obtain an order from the admission server 110, and when it is determined that a transaction can be concluded by matching the obtained orders with each other, the pair of orders that can be executed is transmitted to the commit server 130 as a transaction pair. I can. The commit server 130 to be described later may record information on a transaction pair in the database 150. Through this, the matching server 120 does not need to access the database 150 to process the transaction pair to be directly concluded, and this minimizes the I/O bottleneck that may occur in the matching server 120.

When the matching server 120 creates a transaction pair, the order included in the transaction pair may be deleted from the queue.

In addition, the matching server 120 may transmit execution information, which is information regarding a transaction pair, to the stop order server 160. In this case, the execution information may be received from the commit server 130, and the commit server 130 may transmit the execution information to the matching server 120 in response to the execution request transmitted from the matching server 120.

On the other hand, the matching server 120 can detect that there is a failure in the admission server 110, and if it is determined that there is a failure in the admission server 110, the order with the server identifier of the admission server 110 in the order book of the database 150 Among them, an order that is unknown to them may be queued in order to be processed as if the admission server 110 delivered it.

In addition, the matching server 120 can detect that there is a failure in the commit server 130, and if it is determined that there is a failure in the commit server 130, the database 150 for orders that have not received an ACK from the commit server 130 It is determined whether or not processing has been completed on the database 150 by referring to the order book and transaction history, and if not, a request for processing the order to another commit server may be performed.

The above-described matching server 120 may be implemented as one or more instances, and by selecting one of the one or more instances as a master, receiving orders from the admission server 110 and communicating with the commit server 120 You can have your order fulfilled.

In this case, if there are a plurality of instances, the plurality of instances may be installed for each physically separated server or on one physical server. Therefore, when an instance is selected as a master instance, a physical server corresponding to the instance operates as a matching server, and the physical server may be different from or the same as the server in which the failure occurred. Preferably, in order to flexibly respond to failure, it may be located on a different physical server for each instance.

Meanwhile, an instance other than the instance selected as the master may be set as a slave. In this case, if the master instance fails to operate as the matching server 120 due to a failure, one of the slave instances may become the master instance. Considering that transactions are executed sequentially due to the nature of cryptocurrency transactions, only one matching server should be operated, but only one of the plurality of instances is used as a matching server to cope with possible failures in the matching server. You can make it work.

At this time, a method of selecting a master instance among one or more instances may be various.

According to an embodiment, a slave instance randomly selected among slave instances may become the master instance.

According to another embodiment, a slave instance registered as the first matching server among slave instances may be the master instance.

Relatedly, as shown in FIG. 3, the transaction system 100 may further include a coordination device 170, and the coordination device 170 is among a distributed configuration service, a synchronization service, and a naming registry. At least one is provided, and information sharing between servers constituting a transaction system, status check of servers, or synchronization between servers may be performed. Accordingly, the server to be newly registered in the system can be detected by the coordination device 170, and the coordination device (not shown) can register the server. Such a coordination device (not shown) may be implemented with, for example, an Apache zookeeper, or may be implemented with an arbitrary solution that can be replaced with Apache Zookeeper.

Therefore, for example, an instance registered as a matching server in a coordination device (not shown) among the slave instances may become the master instance.

When the master instance is changed according to the above-described example, the matching server, which becomes the new master, receives a request for execution from the previous master instance from the commit server 130, but asks the commit server 130 to sign the transaction pair and respond if there is a transaction pair in a state that has not been concluded. Can be requested. According to the request, the commit server 130 may conclude an unsigned transaction pair and respond with a new master instance. Thereafter, the new master instance may recover an order that was not processed by the previous master instance by referring to the order recorded in the order book on the database 150. During restoration, the new master instance may receive a new order from the admission server 110, and the new order may be pending and queued as long as the order that has not been processed is not duplicated with the restored order after restoration is completed.

Meanwhile, the commit server 130 according to an embodiment performs execution processing on the transaction pair obtained from the matching server 120.

That is, the commut server 130 may receive and process the transaction pair from the matching server 120 and record the updated data in the database 150 through the cache server 140 according to the conclusion result.

The commut server 130 may obtain user data for signing a transaction pair by requesting a lease from the cache server 140. Using the acquired user data, the commit server 130 may check whether a user corresponding to an order included in the transaction pair has a balance for processing the order. By processing in this way, it is possible to check the balance of the user, which may have changed after the confirmation of the admission server 110.

And when it is determined that there is a balance, the commit server 130 returns the lease requested data to the cache server 140, and deletes the order information recorded in the user's order book stored in the database 150 through the cache server 140. You can change information about your balance.

The commit server 130 may transmit the execution information to the matching server 120 when the execution process is successful.

Through communication with the matching server 120, the commit server 130 may respond by receiving a request for execution of a transaction pair or acknowledging the success of the execution process, whereby the matching server 120 is a failure of the commit server 130 Can be detected. For example, if the matching server 120 transmits a request for execution of a transaction pair, but does not receive an acknowledgment for the request, it may be detected that a failure has occurred in the commit server 130. When it detects that a failure has occurred in the commit server 130, the matching server 120 checks whether processing has been completed on the database 150 by referring to the order book and transaction history in the database 150 for orders that have not received an ACK. If it is determined and not completed, it can request processing of the order to another commit server.

The commit server 130 may communicate with the matching server 120 in an asynchronous manner, and may also be implemented as one or more instances, and thus may be scaled out while increasing instances.

Meanwhile, the cache server 140 according to an embodiment is located between the admission server 110, the matching server 120, the commit server 130 or the stop order server 160, and the database 150. The admission server 110, the matching server 120, the commit server 130, or the stop order server 160 does not directly access the database 150.

When the user data is requested, the cache server 140 acquires the user data from the database 150 and caches the user data if the user data is not being cached.

When the admission server 110 or the commit server 130 requests to record/delete the order book, or update or request user data, the cache server 140 updates cached data or data in the database 150. Can be updated.

The cache server 140 can manage the data that has been reflected in the database 150 by adding it to the transaction history, and preferably manages the transaction history in a data update and atomic manner.

The cache server 140 may receive a lease request for data. For example, a lease request may be received from the admission server 110, the commit server 130, or the stop order server 160. However, the cache server 140 may receive a lock request for data.

The cache server 140 may manage lease-requested data. Therefore, when a failure occurs in the cache server 140, the admission server 110 checks whether data corresponding to the identifier of the order is in the order book, and the commit server 130 checks whether the order exists by referring to the transaction history. After confirmation, as the admission server 110 or the commit server 130 makes a lease request again, the cache server 140 from which the failure has been recovered may operate according to the request.

The cache server 140 may support sharding to eliminate a bottleneck caused by I/O.

In addition, the cache server 140 may operate in a write-through method to prevent loss of data to be updated.

The database 150 according to an embodiment stores data necessary for the operation of the transaction system 100.

For example, the database 150 may store user data. For example, the database 150 may store information on a user's balance, a user's order book, and the like.

Meanwhile, referring to FIG. 2, the transaction system 100 according to an exemplary embodiment may further include a stop order server 160.

The stop order server 160 according to an embodiment may operate when receiving an order for “stop transaction”.

When the order acquired by the admission server 110 is a “stop transaction”, the stop order server 160 may receive an order from the admission server 110.

The stop order server 160 may record the order in a database while storing the order.

In addition, the stop order server 160 may change the order to a'limited price transaction' order or a'market price transaction' order and transfer the order to the admission server 110 when a condition in which an order can be processed as a transaction is satisfied.

That is, when the stop order server 160 obtains an order, the user data of the user matching the order can be obtained by requesting a lease from the cache server 140, and the user corresponding to the order using the obtained user data You can check to see if you have the balance to deal with. If it is determined that there is a balance, the stop order server 160 may determine that the order can be processed, sends a response to the admission server 110, and returns the lease requested data to the cache server 140, while the database 150 Order information can be recorded in the user's order book stored in. In addition, the stop order server 160 may obtain the conclusion information from the matching server 120 to determine whether a specific condition is satisfied. If it is determined that a specific condition is satisfied, the stop order server 160 may change the order of the "stop transaction" to an order of "limited price transaction" or "market price transaction" and transmit it to the admission server 110.

The above-described stop order server 160 may be implemented as one or more instances, and one of the one or more instances may be selected as a master to receive and process an order from the admission server 110.

Therefore, an instance that has not been selected as a master is set as a slave, and if the master instance fails to operate as the stop order server 160 due to a failure, one of the slave instances may become the master instance.

At this time, there may be various methods of selecting a master instance among one or more instances, and a slave instance randomly selected among the slave instances may become the master instance, or the instance registered as the first stop order server among the slave instances may become the master instance. .

Each of the above-described admission server 110, matching server 120, commit server 130, cache server 140, and stop order server 160 is a control unit (not shown), communication unit (not shown), and memory (not shown). ) Can be included.

The controller (not shown) controls the overall operation of the device, and may include a processor such as a CPU. For example, the controller (not shown) may execute a program stored in a memory (not shown), read data stored in a memory (not shown), or store new data in the memory.

The communication unit (not shown) may perform wired or wireless communication with other devices or networks. To this end, the communication unit (not shown) may include a communication module that supports at least one of various wired and wireless communication methods. For example, the communication module may be implemented in the form of a chipset.

Wireless communication supported by the communication unit (not shown) may be, for example, Wireless Fidelity (Wi-Fi), Wi-Fi Direct, Bluetooth, Ultra Wide Band (UWB), or Near Field Communication (NFC). In addition, wired communication supported by the communication unit 130 may be, for example, USB or HDMI (High Definition Multimedia Interface).

The communication unit (not shown) may perform remote procedure call (RPC) communication through a wired or wireless communication method, and the RPC information may be stored in the coordination device 170. When registering a new server, the coordination device 170 acquires RPC information when registering a new server and creates an RPC channel so that other servers in the system can recognize the registration of the new server, and determine that the server has a failure as the RPC channel is disconnected. have.

Various types of data such as files, applications, and programs may be installed and stored in a memory (not shown). The controller (not shown) may access and use data stored in the memory (not shown), or may store new data in the memory (not shown). In addition, the control unit (not shown) may execute a program installed in the memory 140. For example, a program for performing a virtual currency transaction method may be installed in a memory (not shown).

Meanwhile, the transaction system 100 may further include a dashboard server (not shown) capable of additionally monitoring the operation of the transaction system 100.

In addition, the transaction system 100 may further include a management server (not shown) that additionally manages the transaction system 100. The management server (not shown) can process the management API, for example, stopping the operation of the exchange system, adding a new currency, deleting an existing currency, and adding an exchangeable currency (purchase of bitcoins). When you want to, you can control other servers when performing operations such as adding the type of currency that can purchase bitcoins). Each of the dashboard server or the management server can communicate with other servers constituting the system.

Meanwhile, FIGS. 4 to 6 are flowcharts illustrating a method of trading virtual currency according to an exemplary embodiment.

The transaction method according to the embodiment illustrated in FIGS. 4 to 6 includes steps processed in a time series in the transaction system 100 illustrated in FIGS. 1 to 3. Accordingly, even if the contents are omitted below, the contents described above with respect to the transaction system 100 illustrated in FIGS. 1 to 3 may also be applied to the transaction method according to the embodiment illustrated in FIGS. 4 to 6.

As shown in FIG. 4, the admission server 110 may obtain an order from an external system (not shown) and may classify the order type (S401). If the order type is classified, the admission server 110 may request to lease user data from the cache server 140 in order to check the level of the user's balance for the order if the order is'market price transaction' or'designated price transaction' ( S402). When it is confirmed that the user has a balance and that the order can be processed (S403), the admission server 110 may return the lease request data to the cache server 140 and deliver information about the order together (S404). The cache server 140 receiving the order information may record the order in the user's order book stored in the database 150 while updating the user data cached by itself (S405). Thereafter, the admission server 110 may transmit a result value of the order to an external system (not shown) (S406). Therefore, if a failure occurs in the admission server 110, the external system cannot obtain a result value related to the order, and thus the external system may detect the occurrence of the failure in the admission server 110 and request the order again.

Thereafter, the admission server 110 may queue the order to the matching server 120 (S407). If a failure of the admission server 110 occurs, the matching server 120 may detect the failure as an RPC, and may read order information stored in the database 150 so that the order is processed.

Meanwhile, the matching server 120 generates a transaction pair by matching the queued orders (S408), and transmits the transaction pair to the commit server 130 (S409). The commit server 130 may perform execution processing on the transaction pair obtained from the matching server 120 and may request a lease of user data from the cache server 140 for this (S410). When it is determined that there is a balance for processing a transaction pair (S411), the Kermot server 130 deletes the order information cached in the cache server 140 and returns information about the balance while returning the lease request data to the cache server 140. User data can be updated by changing (S412). In addition, the cache server 140 may also delete order information recorded in the user's order book stored in the database 150, update user data, and add information on transaction pair processing to the transaction history (S413).

On the other hand, when the admission server 110 obtains an order from an external system (not shown) in step S401 and the order is “stop transaction”, it may proceed to step S402 of FIG. 4 after performing each step in FIG. 5.

That is, the admission server 110 may transmit an order that is a stop transaction to the stop order server 160 (S501). The stop order server 160 receiving the order may request to lease user data from the cache server 140 in order to check the level of the user's balance for the order (S502). When it is confirmed that the user has a balance and that the order can be processed (S503), the stop order server 160 may record the order in the database 150 through the cache server 140 (S504) (S505). . In addition, the stop order server 160 may transmit a response to the order request to the admission server 110 (S506).

Thereafter, the stop order server 160 can receive the execution information from the matching server 120 in real time (S507), and when it is determined that a specific condition of the stop transaction is satisfied based on the execution information (S508), the stop transaction is designated. It may be converted into at least one of a transaction or a market price transaction and transmitted to the admission server 110 (S509). The converted order is transmitted to the admission server 110, and the transaction system 100 may perform each step of steps 402 to 413.

Meanwhile, the transaction system 100 further includes a coordination device 170, and when a failure of the matching server 120 is detected, the coordination device 170 causes the new matching server 120 to operate and Make it possible to accurately process currency transactions.

That is, as shown in FIG. 6, the transaction system 100 may open one or more slave instances. Accordingly, when the transaction system 100 detects a failure of the matching server (S610), one or more slave instances may be selected (S620). In this case, the selected instance may be an instance for which registration is requested first or may be a randomly selected instance. The transaction system 100 may use the selected instance as a master instance to operate as a new matching server, and the existing master server in which a failure has occurred may stop the operation (S630).

As described above, when a new matching server is registered in the transaction system 100, the newly registered matching server obtains a response to the execution request that was previously requested by the failure matching server in which a failure has occurred from the commit server 130. It can be confirmed that the processing of the execution request has been completed. Thereafter, the new matching server may recover from the database 150 an order that has not been processed even though the failure matching server has created a queuing or transaction pair. While receiving a response to the execution request from the commit server 130 or recovering the order from the database 150, the new matching server pending the order from the admission server 110 and places the order that was not processed by the failure matching server. Once you have finished recovering from the database, you can queue pending orders.

The term'~ unit' used in the above embodiments refers to software or hardware components such as field programmable gate array (FPGA) or ASIC, and the'~ unit' performs certain roles. However,'~ part' is not limited to software or hardware. The'~ unit' may be configured to be in an addressable storage medium, or may be configured to reproduce one or more processors. Thus, as an example,'~ unit' refers to components such as software components, object-oriented software components, class components and task components, processes, functions, properties, and procedures. , Subroutines, segments of program patent code, drivers, firmware, microcode, circuitry, data, database, data structures, tables, arrays, and variables.

The components and functions provided in the'~ units' may be combined into a smaller number of elements and'~ units' or separated from the additional elements and'~ units'.

In addition, components and'~ units' may be implemented to play one or more CPUs in a device or a security multimedia card.

The transaction method according to the embodiment described with reference to FIGS. 4 to 6 may also be implemented in the form of a computer-readable medium that stores instructions and data executable by a computer. In this case, the instructions and data may be stored in the form of a program code, and when executed by a processor, a predetermined program module may be generated to perform a predetermined operation. Further, the computer-readable medium may be any available medium that can be accessed by a computer, and includes both volatile and nonvolatile media, and removable and non-removable media. Further, the computer-readable medium may be a computer recording medium, which is volatile and non-volatile implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. It may include both volatile, removable and non-removable media. For example, computer recording media may include magnetic storage media such as HDDs and SSDs, optical recording media such as CDs, DVDs, and Blu-ray discs, or accessible through a network. It may be a memory included in the server.

In addition, the transaction method according to the embodiment described with reference to FIGS. 4 to 6 may be implemented as a computer program (or computer program product) including instructions executable by a computer. The computer program includes programmable machine instructions processed by a processor, and may be implemented in a high-level programming language, an object-oriented programming language, an assembly language, or a machine language. . Further, the computer program may be recorded on a tangible computer-readable recording medium (eg, memory, hard disk, magnetic/optical medium, solid-state drive (SSD), etc.).

Accordingly, the transaction method according to the embodiment described with reference to FIGS. 4 to 6 may be implemented by executing the above-described computer program by the computing device. The computing device may include at least some of a processor, a memory, a storage device, a high speed interface connected to the memory and a high speed expansion port, and a low speed interface connected to the low speed bus and the storage device. Each of these components is connected to each other using various buses and can be mounted on a common motherboard or in other suitable manner.

Here, the processor can process commands within the computing device. Such commands include, for example, to display graphic information for providing a GUI (Graphic User Interface) on an external input or output device, such as a display connected to a high-speed interface. Examples are instructions stored in memory or storage devices. As another embodiment, multiple processors and/or multiple buses may be utilized with multiple memories and memory types as appropriate. In addition, the processor may be implemented as a chipset formed by chips including a plurality of independent analog and/or digital processors.

The memory also stores information within the computing device. As an example, the memory may be composed of volatile memory units or a set of them. As another example, the memory may be composed of a nonvolatile memory unit or a set of them. Also, the memory may be another type of computer-readable medium such as a magnetic or optical disk.

In addition, the storage device may provide a large-capacity storage space to the computing device. The storage device may be a computer-readable medium or a configuration including such a medium, for example, devices in a storage area network (SAN) or other configurations, a floppy disk device, a hard disk device, an optical disk device, Or it may be a tape device, a flash memory, or another semiconductor memory device or device array similar thereto.

The above-described embodiments are for illustrative purposes only, and those of ordinary skill in the art to which the above-described embodiments belong can easily transform into other specific forms without changing the technical idea or essential features of the above-described embodiments. You can understand. Therefore, it should be understood that the above-described embodiments are illustrative and non-limiting in all respects. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as being distributed may also be implemented in a combined form.

The scope to be protected through the present specification is indicated by the claims to be described later rather than the detailed description, and should be interpreted as including all changes or modified forms derived from the meaning and scope of the claims and the concept of equivalents thereof. .

100: virtual currency trading system
110: admission server 120: matching server
130: commit server 140: cache server
150: database 160: stop order server
170: coordination device

Claims (16)

As a system for virtual currency trading,
A first matching server for generating a transaction pair by matching other orders to be concluded with the order for processing an order requesting a virtual currency transaction;
A coordination device in which the first matching server is added to the transaction system; And
And an admission server that obtains the order from a user and transmits the order to the first matching server,
The first matching server queues the order received from the admission server,
The coordination device,
When the first matching server fails, a second matching server is registered to process the order. The method of claim 1,
The coordination device,
A virtual currency trading system for selecting one of one or more slave instances as a master instance and registering a second matching server corresponding to the master instance. The method of claim 2,
The coordination device,
When the first matching server fails, the first instance of the one or more slave instances that succeeds in registration is determined as the master instance. delete The method of claim 1,
The second matching server,
A cryptocurrency trading system for queuing the pending orders when pending orders from the admission server and recovering the orders queued in the first matching server from a database. The method of claim 1,
If a condition corresponding to the stop transaction order is satisfied based on the execution information received from the first matching server, the stop order server converts the stop transaction order to at least one of a limit transaction order and a market price transaction order. and,
The admission server identifies the type of order acquired, and if the order type is a stop transaction, transfers the order to the stop order server, and requests at least one of a limit transaction and a market price transaction from the stop order server. A cryptocurrency trading system that takes orders. The method of claim 6,
The coordination device,
When the stop order server fails, one or more slave instances are selected as a master instance, and a stop order server corresponding to the master instance is registered as another stop order server. The method of claim 1
The cryptocurrency trading system further comprises a cache server that communicates with the database for recording the order and receives a request for a lease of data for processing the order. The method of claim 1,
A cryptocurrency trading system further comprising a commit server for receiving the execution request for the transaction pair from the first matching server and entering into the transaction pair. The method of claim 9,
The second matching server,
When a response to the execution request that was requested by the first matching server is obtained from the commit server, the order queued by the first matching server is recovered from a database. To process an order requesting a virtual currency transaction, an admission server that acquires the order from the user and delivers it to the first matching server, and queues the order received from the admission server and matches other orders to be concluded with the order. As a method of trading virtual currency, a virtual currency trading system including a first matching server that generates a trading pair
Comprising the step of processing the order by registering a second matching server when the first matching server fails. The method of claim 11,
The step of processing the order,
Comprising the step of selecting one of the one or more slave instances as a master instance and registering a second matching server corresponding to the master instance, virtual currency trading method. The method of claim 11,
The cryptocurrency transaction method,
The second matching server, further comprising the step of queuing the pending order when pending the order from the admission server and recovering the order queued in the first matching server from the database. The method of claim 11,
The cryptocurrency trading system further includes a commit server for receiving the execution request for the transaction pair from the first matching server and entering into the transaction pair,
If a response to the execution request that was requested by the first matching server is obtained from the commit server, the method further comprising recovering the order queued by the first matching server from the database. A computer-readable recording medium on which a program for performing the method according to claim 11 is recorded. A computer program performed by a virtual currency trading system and stored on a medium to perform the method described in claim 11.

Images