KR101962289B1 - Distributed Ledger Device for Supporting Sharing Economy - Google Patents

Abstract

The present invention relates to a distributed ledger apparatus which generates a key for a sharing economy based on a block chain, a distributed ledger method, a transaction information broadcast apparatus and a transaction information broadcast method. To this end, the present invention comprises: a storage request reception step of receiving a difficulty information storage request transaction including changed difficulty information on a specific user in a first account in the block chain; a storage step of storing the difficulty information based on the difficulty information storage request transaction; a difficulty information confirmation request step of receiving a difficulty information confirmation query which is a request for difficulty information confirmation in a second account in the block chain; and a difficulty information transmission step of transmitting the difficulty information to the second account.

Description

[0001] The present invention relates to a Distributed Ledger Device for Supporting Sharing Economy, which identifies a user using an asymmetric key method for a shared-

The present invention relates to a distributed branching apparatus and a distributed branching method for generating a key for a block-chain-based shared economy.

Shared economy is consumption trend and industrial trend that started with Airbnb, UBER, Zipcar, etc. as the economy of mutual consumption. In 2007, none of the companies with the highest enterprise value introduced a shared economy, but the shared economy was greatly revived with the public life approaching the public life for 10 years after the start of the Airbnb in 2008. UBER's corporate value was estimated at $ 48 billion, as it was settled during the acquisition of 15 percent of UBER's stake in Softbank, which was completed in early 2018. The market cap of Hyundai Motor, the second largest company in the KOSPI, is worth W40trn in early 2018, so we can see how high the corporate value of UBER is. The high enterprise value of the shared economy can be regarded as the value produced by the users of the shared economy and the suppliers of the shared economy that constitute the shared economic ecosystem.

However, there is a problem in the modern shared economy that it is not evenly distributed to the users and suppliers of the shared economy that have contributed a great deal to the value of the shared economy. All profits are taken by operators who run a shared economic platform. For example, former UBER CEO Travis Calneric sold 29% of his shares to Softbank during the acquisition of Softbank's UBER stake earlier this year, including $ 1.4 billion (about $ 1.5 trillion) ). On the other hand, the annual income of drivers who make up the UBER ecosystem is about $ 20,000 (40 hours a week, for example, about $ 8.77 per hour in the Detroit area) in 2016.

Korean Patent No. 10-1751025, a smart system for trading stock based blockchain based on block chain, Korean Patent Registration No. 10-1758870, Mining Management System and Mining Management Method Thereof (Mining Rig Monitoring System and Mining Rig Monitoring Method In Using Same) U.S. Published Patent Application No. US 2016/0342989 A1, Method and system for processing blockage-based transactions on existing payment networks, Mastercard International Incorporated U.S. Published Patent, US 2016/0292672 A1, Systems and methods of blockchain transaction recordation, Nasdaq, Inc. U.S. Published Patent, US 20170132615 A1, Block chain alias for person-to-person payments, Bank Of America Corporation

In order to solve the above problems of the existing shared economy, it is desirable to introduce a block chain into the shared economy. Block chaining is a technology that can run software in a secure and decentralized way without intermediaries. With a block chain, a shared economic platform does not need to run on a centralized server. If a shared economic platform based on block-chain technology can be implemented, the shared economy can be operated on an inter-personal network without being controlled by any one entity.

However, making the shared economy run on a block chain is technically difficult. When the shared economy is operated on a block chain, there may be an overlapping reservation problem, a listing problem, and an escrow problem because there is no operating entity for managing an ecosystem such as UBER. In particular, the token standard of the existing block chain is composed of replaceable tokens such as Etherium's ERC20. It is very difficult to manage various common goods of the shared economy in the block chain using these replaceable tokens It is difficult.

SUMMARY OF THE INVENTION Accordingly, it is an object of the present invention to provide a distribution chain for registering shared goods in a shared economy in a block chain, for a shared economy in which a shared economy can be established without an intermediary between a user and a supplier, Apparatus and a distributed ledger method.

Hereinafter, specific means for achieving the object of the present invention will be described.

An object of the present invention is a memory module for storing a block chain including a shared goods account and a plurality of smart contract accounts which are accounts for a specific shared goods; And a processing module operatively coupled to the memory module, the processing module executing computer readable program code of the shared good account, wherein the program code of the shared good account comprises: Receiving a conditional token remittance request for receiving a conditional token remittance request including a use condition information of a specific user and token remittance information in a user account which is one of accounts; Generating a conditional token transfer transaction including the use condition information and the token transfer information based on the conditional token transfer request, and storing the use condition information and the token transfer information in the shared goods account; And generating a key based on the ID of the conditional token transfer transaction or the Hash value of the conditional token transfer transaction and transmitting the key to the user account; Wherein the conditional token remittance transaction is a token remittance transaction that is information on token transfer from the user account to a provider account that is one of the plurality of smart contract accounts in the block chain, And a distributed general ledger apparatus for generating a key for a block-chain-based shared economy, which includes specific shared asset information which is information on the specific shared asset.

The generated key may be included in an identifier of a bar code, a QR code, a color code, an RFID, or an NFC, and may be used for identifying a user using the specific common goods.

Also, the key generating step generates a key by encrypting the conditional token transfer transaction to be decrypted with the supplier account, and transmits the generated key to the user account, and the generated key is a bar code, a QR code, a color code, And can be used for identification of a user who uses the specific shared goods.

It is another object of the present invention to provide a distributed ledger apparatus for storing a block chain including a shared goods account and a plurality of smart contract accounts which are accounts for specific shared goods, Receiving a conditional token remittance request for receiving a conditional token remittance request including a usage condition information of a specific user and token remittance information in an account; The distributed fund raising device generates a conditional token transfer transaction including the use condition information and the token transfer information based on the conditional token transfer request and stores the use condition information and the token transfer information in the shared goods account A transaction generation step; And generating a key based on the ID of the conditional token transfer transaction or the Hash value of the conditional token transfer transaction and transmitting the generated key to the user account, wherein the conditional token transfer transaction includes: The token transfer information and the specific shared goods information which are the information on the specific shared goods, which is information on the token transfer from the user account to the supplier account which is one of the plurality of smart contract accounts in the block chain, Based on shared block economy, which generates a key for a block chain-based shared economy.

Also, the generated key is used for mutual identification between a user who uses the specific shared goods and a supplier that supplies the specific shared goods, which is included in an identifier of Bar-code, QR Code, Color Code, RFID or NFC can do.

The key generation step may include generating a key by encrypting the conditional token transfer transaction to be decrypted by the supplier account, and transmitting the key to the user account, wherein the generated key is a bar code, a QR code, a color code, May be included in the identifier of the NFC and used for identifying the user using the specific shared goods.

The generating of the key may include encrypting the conditional token transfer transaction so as to be decrypted with the public key or the private key of the provider account to generate the key and transmit the generated key to the user account, May be included in the identifier of the user and used to identify the user using the specific shared goods.

Also, the generating of the key may include generating a request message for requesting transmission of a confirmation message from the user account to the provider account using the key, the generated key being included in an identifier of the identification code or the short- Wherein the confirmation message is configured to transmit the confirmation message from the account to the provider account, and is used for identifying a user who uses the specific shared goods, and the confirmation message is a query or a message transaction.

Another object of the present invention is a memory module for storing a block chain including a shared goods account and a plurality of smart contract accounts which are accounts for a specific shared goods; And a processing module operatively coupled to the memory module, the processing module executing computer readable program code of the shared good account, wherein the program code of the shared good account comprises: Receiving a conditional token remittance request for receiving a conditional token remittance request including a use condition information of a specific user and token remittance information in a user account which is one of accounts; Generating a conditional token transfer transaction including the use condition information and the token transfer information based on the conditional token transfer request, and storing the use condition information and the token transfer information in the shared goods account; And generating a key based on the ID of the conditional token transfer transaction and transmitting the generated key to the user account; Wherein the conditional token remittance transaction is a token remittance transaction that is information on token transfer from the user account to a provider account that is one of the plurality of smart contract accounts in the block chain, The user client, which is a client of the user account, encrypts the key with the private key of the user account and includes the identification code or the identifier of the local communication in the user account of the user account To the provider client, which is a client of the supplier account, for identification of a user using the specific shared goods, and the provider client decrypts the key using the public key of the user account to identify the user And It can be achieved by providing a balancing ledger system to identify the user's asymmetric key method for sharing the economic blocks based chain.

As described above, the present invention has the following effects.

First, according to an embodiment of the present invention, it is possible to construct a shared economy without an intermediary such as an operating entity.

Second, according to an embodiment of the present invention, there is no problem that the reservation is overlapped by a plurality of users without an intermediary such as an operating entity.

Third, according to an embodiment of the present invention, an escrow function can be performed without an intermediary such as an operating entity.

Fourth, according to one embodiment of the present invention, even if the ownership of the common good is changed, the entire system of the shared economy is not affected.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate preferred embodiments of the invention and together with the description, serve to explain the principles of the invention. .
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic diagram showing a dispersion laydown device according to an embodiment of the present invention;
FIG. 2 is a schematic diagram showing the form of various nodes,
3 is a schematic diagram illustrating a shared economic system using a block chain according to an embodiment of the present invention.
FIG. 4 is a flowchart showing a flow of data according to an embodiment of the present invention; FIG.
FIG. 5 is a schematic diagram of a shared goods account according to an embodiment of the present invention;
FIG. 6 is a schematic diagram illustrating a data structure of shared goods registration transaction information according to an embodiment of the present invention; FIG.
FIG. 7 is a flowchart showing a shared goods registration method according to an embodiment of the present invention;
FIG. 8 is a schematic diagram showing a data structure of conditional token transfer transaction information according to an embodiment of the present invention;
9 is a diagram illustrating a method of requesting the use of shared goods using conditional token remittance according to an embodiment of the present invention,
FIG. 10 is a flowchart illustrating a distributed ledger method for generating a key for a block-chain-based shared economy with specific conditions for use approval according to an exemplary embodiment of the present invention; FIG.
11 is a schematic diagram showing the HTTP communication between the transaction information transmitting apparatus 2 and the distributed branch machine 10 of the present invention.
FIG. 12 is a schematic diagram showing a case where a transaction information transmitting apparatus according to an embodiment of the present invention receives a request for using a specific shared material;
FIGS. 13 and 14 are flowcharts illustrating a process in which a legitimate user is identified by a distributed branching device that generates a key for a block-chain-based shared economy according to an embodiment of the present invention;
FIG. 15 is a flowchart illustrating a process in which a legitimate user is identified by a distributed branching device that generates a key for a block-chain-based shared economy according to another embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following detailed description of the operation principle of the preferred embodiment of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may unnecessarily obscure the subject matter of the present invention.

The same reference numerals are used for portions having similar functions and functions throughout the drawings. In the specification, when a specific portion is connected to another portion, it includes not only a direct connection but also a case where the other portion is indirectly connected with another element in between. In addition, the inclusion of a specific constituent element does not exclude other constituent elements unless specifically stated otherwise, but may include other constituent elements.

Distributed ledger generating key for shared chain-based economy

1 is a schematic diagram showing a distributed general ledger according to an embodiment of the present invention. 1, a distributed branching library apparatus 1 according to an embodiment of the present invention may mean one of nodes of a block-chain distributed network 100 and includes a communication module 10, a processing module 11 ), And a memory module 12.

The block chain distributed network 100 refers to a P2P distributed network composed of a plurality of nodes storing the distributed origin of a block chain. Since the block chain distributed network 100 is configured such that at least some of the nodes can perform the same processing, even if some of the nodes are shut down or modulated, the block chain distributed network 100 has no effect on the entire system. A node may refer to any computing device connected to the block-chain distributed network 100. These nodes may include digital wallets, block-chain copies, verification engines, mining engines, P2P network distribution functions (broadcasts), and may include clients that are made up of slightly more lightweight features. The block-chain distribution network 100 according to an exemplary embodiment of the present invention may include a hybrid P2P including a pure P2P and a super node. In particular, a node according to an embodiment of the present invention may be installed in a client together with the source code of a PC / mobile game application.

With regard to the node, FIG. 2 is a schematic diagram showing the form of various nodes. As shown in FIG. 2, the reference client includes a digital wallet management module for users, a mining module for block mining when the agreement algorithm is a proof of work (POW) A block chain database for storing all or at least a part of the entire block chain, a network routing module for broadcasting a transaction to a block chain distributed network, For example, a client of Bitcoin Core, or the like. A Full Node may refer to a node including a block chain database, a network routing module. The Solo Miner Node may refer to a node including a mining module, a block chain database, and a network routing module. A mining node may be a light node including a gateway router connected to a pool mining node, which means a node of a mining pool, and a mining module. A lightweight wallet node typically stores only the header information of a block chain, holds a digital wallet management module to store the user's digital wallet, and includes a network routing module, but does not include a block chain database To create a transaction or access a block-chain distributed network, it may refer to a light node that depends on a server owned by a third party. The distributed general ledger 1 according to an embodiment of the present invention may mean nodes including a block chain database and a network routing module among the above nodes. In addition, when the node according to an embodiment of the present invention includes a mining module, the user client can perform mining using a Proof of Work (POW) or POS (Proof of Stake) method.

The communication module 10 includes a network routing module that broadcasts a transaction to a block chain distributed network or a gateway router that is connected to a pool mining node It can mean.

The processing module 11 is a module for processing contents of a transaction stored in a block of a block chain which is a distributed ledger stored in the memory module 12. [ The processing module 11 according to an embodiment of the present invention may be configured as a virtual machine (VM) such as an Ethereum Virtual Machine. This virtual machine is a runtime for executing Byte Code that is generated by compiling code (Smart Contract, Smart Contract) created in a high level language such as Mutan, LLL, Serpent, Solidity and the like. In addition to OPCODE and Stack, It is also the subject of using Storage.

The memory module 12 is a module for storing a distributed ledger, and may mean a block chain database that stores all or a part of the entire block chain.

3 is a schematic diagram illustrating a shared economic system using a block chain according to an embodiment of the present invention. 3, a shared economic system using a block chain according to an exemplary embodiment of the present invention includes a user client 200, a supplier client 320, a Dapp 400, an IPFS 410, a server 420, A DB 430, and a block chain 30.

The user client 200 means a client, such as a smart phone, for using the Denter (Decenteralized Application) by the users of the shared goods in the shared economy.

Supplier client 320 refers to a client, such as a smartphone, for using a shared economic system, such as a shared goods supplier in a shared economy registering a shared item in Dapp and granting use of the shared item.

Dapp (400) means a web frontend such as Dapp in a shared economy system, and Dapp's web front end can be composed of a combination of HTML, CSS, and JavaScript (a large proportion of web3js). The user client 200 and the supplier client 320 interact with the block chain 30, the IPFS 410, and the nodeJS server 420 through this front end application.

The InterPlanetary File System (IPFS) 410 is a P2P distributed file system that attempts to connect all computing devices to the same file system. It can also be viewed as a single bit torrent swarm (a unique identifier for a file and a list of peers that own the file) that exchanges objects in the Git repository. In other words, IPFS provides a high throughput content addressed block storage model using content addressed hyperlinks that utilize Cotent's hash value as an address. It can take the form of a generalized Markle DAG, a data structure that can build a versioned file system, a block chain, or a persistent web page. IPFS is a combination of a distributed hash table, an incentive block exchange, and a self-signed namespace. With IPFS, unexpected termination or destruction of a particular node will not cause a single point of failure, and each node will not need to trust each other. According to one embodiment of the present invention, when a supplier uploads a product to the shared economy Dapp 400, the front-end Dapp 400 uploads the product image file and the description to the IPFS 410, Chain 30 and DB 430, respectively.

The server 420 is a back-end server of the Off Chain for communicating with the DB 430 by the front-end Dapp 400. The API is configured to allow the front end to query and receive shared material information from the database. In addition, the DB 430 performs a search and listing of shared goods registered under various conditions.

The DB 430 is an Off Chain database connected to the server 420 to store and index information on shared goods. For example, a database such as Mongolia DB. Displaying shared material on a Dapp (400), and querying the block chain every time you apply a variety of filters (such as viewing a specific category item, or viewing a deadline item, etc.) It is inefficient. Therefore, in an embodiment of the present invention, the DB 430 of the Off Chain is used instead of the block chain 30 to store and query the shared goods information.

The block chain 30 is composed of a plurality of blocks which are linked lists stored in the memory module 12 of the distributed general ledger device 1 for generating a key for a block economy based shared economy, Account, user account, supplier account. The block chain 30 according to an embodiment of the present invention will be described below.

4 is a flowchart illustrating a flow of data according to an embodiment of the present invention. As shown in FIG. 4, the block chain 30 may include a user account 20, a supplier account 32, and a shared goods account 31. The shared goods account 31 may be composed of a contract account (CA) including a Smart Contract and may be linked to the user account 20 and the supplier account 32 within the block chain 30, And an account that acts as a mediator in a shared economy within a block chain. The user account 20 can be composed of an EoA (External Owned Accouant) or a CA (Contract Account), and is connected to the client of the shared economic service user to request listing in the shared goods account 31, Request), conditional token remittance, user rating transmission, etc. The supplier account 32 may be comprised of an EoA (External Owned Accouant) or a CA (Contract Account), and may be connected to a client of the shared economic service provider to register a shared good in the shared good account 31 , An authorization request to approve the use of a shared item, an initiation confirmation to record the start of use by the user, an end-of-use confirmation to record the end-of-use of the user, a token reception, and a supplier rating transmission do.

FIG. 5 shows a schematic diagram of a shared goods account 31 according to an embodiment of the present invention. 5, the smart contract program code included in the shared goods account 31 includes a conditional token module 312 including a token receiving and conditional token transfer function, a usage approval module including a usage request reception and approval request function A key output module 314 including a key output function, a usage start confirmation module 315 including a usage start confirmation reception function, a usage end confirmation module 316 including a usage end confirmation reception function, a user rating and provider A rating receiving module 317 including a rating receiving function, and the like.

The conditional token module 312 is included in the shared goods account 31 and is used to send token transfer transactions of a particular condition from the user account 20 to the supplier account 32 via the user account 20 at the user client 200 (memorized) a transaction for token transfer based on the satisfaction of a specific condition in a shared commodity account 31 when a request for a conditional token transfer request (tx, Transaction) is generated (conditional token transfer request) To be shared by at least some of the nodes. Whether or not the specific condition is satisfied is judged by the shared goods account 31. [ If it is determined that certain conditions are met, then a certain number of tokens will be deleted from the user account 20 and a certain number of tokens will be assigned to the provider account 32. The token state changes when certain conditions are satisfied are shared among the block chain distributed networks. If it is determined that a certain condition is not satisfied, the token remittance request can not be created in the shared good account 31 and may be returned to the user account 20 (Reject). If certain conditions are not met, there is no token state change to be shared in the block-chain distributed network. According to the embodiment of the present invention, the use of the shared commodity can be requested only by the token remittance request, so that the shared economy can be driven without an operator performing the intermediary role.

The specific conditions according to an exemplary embodiment of the present invention may include conditions such as whether the user is legal, common goods availability, integrity of common goods DB information, approval of supplier use, and the like. Whether or not the user is legitimate means the condition for judging whether or not the user satisfies each condition when there is a black list, a white list or a separate condition for the user information for the user account address . The shared product availability means a condition for determining whether or not the shared goods are available based on the shared goods usage information stored together with the transaction registered in the shared goods account 31. [ Whether or not the use of the provider is approved may be determined by whether or not the transaction that the supplier client 320 approves use for the use request (for example, the token transfer transaction request or use request) of the corresponding user client 200 is created in the shared goods account 31 Quot; or " whether " In this regard, the use approval module 313 will be described in detail below.

The use approval module 313 is included in the shared goods account 31 and is used when the use condition of the supplier is included in the specific condition according to an embodiment of the present invention. The use approval module 313 receives a usage approval request (for example, a conditional token transfer request) from the user account 20 or the user client 200 to the provider account 32 or the provider client 320 And then receives a usage authorization from the supplier account 32. [ When the use approval module 313 receives the use approval from the supplier account 32, the shared goods account 31 transfers only the change of status of use approval except the transfer of the token among the transactions corresponding to the received token transfer request, Can be created and stored in memory and distributed. According to an embodiment of the present invention, when a transaction for use approval is distributed, an effect that an update that a usage is approved for a specific user for a specific period (shared use information) for the shared product is enabled in the Dapp 400 . This results in an effect of preventing overlapping reservation of the shared goods. According to the use approval module 313 according to an embodiment of the present invention, the user and supplier rating system can be implemented even in a block-chain shared economic ecosystem without an intermediary operator.

The key output module 314 is included in the shared goods account 31 and is used by the use approval module 313 after the conditional token module 312 determines that the specific condition is satisfied or is satisfied, And outputs the dynamically generated key to the user client 200 or the provider client 320 when receiving the use approval. The key according to an embodiment of the present invention may be generated based on the conditional token transfer request, the ID or Hash of the conditional token transfer transaction, the specific condition (or usage condition information), the user account address, or the Hash value of the provider account address And the user and the supplier can be used as an identifier in the implementation of the identification code such as Bar-code, QR Code, Color Code, and short-distance communication such as RFID, NFC, and BLE based on the key value. Also, the conditional token transfer transaction (ID or Hash value) is encrypted so as to be decrypted with the private key or the public key of the provider account to generate a key and transmit it to the user account. The provider decrypts the transaction with the private key or the public key of the provider account, can confirm. According to one embodiment of the present invention, when a user selects a specific commodity and remits the token and outputs the key, online / offline identification / authentication can be performed with the corresponding key. The provider can also identify and authenticate the user through the corresponding key. The effect that the shared economic system, which is completely dispersed by the key according to the embodiment of the present invention, becomes possible.

Also, according to an embodiment of the present invention, the user client 200 may be configured to output a user key and the supplier client 320 may output a supplier key. The supplier key and the user key can be configured as an asymmetric key system. The supplier key can be configured with a public key (a public key) and a user key with a private key. According to an embodiment of the present invention, when a user faces a provider for use of a shared item, and the provider client receives the user key, the conditional token transfer request and the hash value of the specific condition are transmitted as a provider key The user key can be verified by decrypting the encrypted value with a user key which is a private key (private key) and requesting a conditional token transfer and checking whether the hash value of the specific condition is correct.

Also, according to another embodiment of the present invention, the key generation can be configured to generate a confirmation message request as a key requesting to transmit a confirmation message signed with the provider account in the user account. According to this, the generated key is included in the identifier of the identification code or the short-range communication, and the command requesting to transmit the confirmation message from the user account to the provider account is configured to be executed in the block chain, An effect to be used for the identification of the user who uses it is generated. In particular, the confirmation message may comprise a query or message transaction. According to this, an effect that the identification of the user can be verified without additional encryption is generated.

According to another embodiment of the present invention, an account in the same block chain may also be assigned to the shared goods, so that the legitimate user can be identified in the shared goods account without communication with the supplier account.

According to one embodiment of the present invention, the actual use of the user ' s shared goods may be the specific condition for the token transfer. In this regard, the use start confirmation module 315 and the use end confirmation module 316 will be described below.

The use start confirmation module 315 is included in the shared goods account 31 and is a module for creating a transaction that records in the block chain that the user actually started the shared goods after the key is output. The use start confirmation module 315 according to an embodiment of the present invention may determine the time when the verification of the user key is completed in the supplier client 320 as the use start time. According to this, it becomes impossible for the supplier to record the commencement of the use of the commodities on the block chain, so that a more reliable block chain shared economy can be realized.

The use termination confirmation module 316 is a module that is included in the shared goods account 31 and generates a transaction that records in the block chain that the user has finished using the shared goods. The use termination confirmation module 316 according to an embodiment of the present invention receives a request to invoke the use termination confirmation module 316 from the supplier account 32 or the supplier client 320 to the shared commodity account 31 May be configured to generate a termination confirmation transaction. According to an embodiment of the present invention, when the token transfer proceeds on condition that the user starts using and terminating the use, the token is remitted after the user uses the common goods, so that at least a part The shared economic system in which tokens are returned can also be implemented. According to another embodiment of the present invention, in the conditional token transfer request, the token transfer may be performed only by receiving the use approval of the supplier, and the start and end of use may be stored as separate transactions.

The rating receiving module 317 is a module that receives a rating for at least one party of a user and a supplier and generates a transaction to record in a block chain. The rating receiving module 317 according to the embodiment of the present invention can implement the rating system in the block chain shared economy. The rating receiving module 317 according to an embodiment of the present invention can request / receive ratings from the user and the supplier on condition that the use end confirmation module 316 confirms the end of use.

For example, in the case of Ethereum, the code for this smart contract can be written in the languages Solidity, Serpent, LLL, and Mutan. Currently, Solidity is mainly used and the syntax is similar to JavaScript. Smart Contract is program code that is processed by processing module 11, including " variable ", " structure ", and " function ". These Smart Contract codes can be converted into Byte Code through the Compile process. Byte code can be compiled through the Solidity Realtime Compiler. The Byte code of Solidity is all hexadecimal code. In Solidity, if this Byte code is assigned to Payload (data:) without paying the receiving address and a transaction is distributed to Blockchain, Block is created by Miner. Transaction, and returns the contract address of the Contract created (distributed) in the contractAddress: field of the Transaction Receipt.

The Smart Contract development environment can include a range of development tools and compilers. For example, in the case of Solidity, when you create and compile a code, all compilers output [Byte Code], [Function Signature], and [ABI].

The Byte Code is the result of compiling Smart Contract Code as described above. In case of generating the Contract Creation Transaction in Blockchain and distributing Message Tx (Transaction abbreviation) to Contract, call / query to contract (1, EVM in the case of a dielectric) through the case where it occurs.

FunctionSignature is used as an interface in the contract function call, and is a 4-byte Hash value hash of the contract function name as a SHA3 cryptographic hash function.

ABI (Application Binary Interface) means Application Interface described in a way that is not dependent on a specific language or platform. The ABI definition is output by the compiler or the ABI Generator. The ABI defines the meta data for Smart Contract functions and parameters. With ABI, you can create an object when you create an application based on a JavaScript language, and you can easily call a Contract's function by calling the method of the object. Ethereum now supports creating and using ABI objects in JavaScript applications with web3.js. In go-ethereum since 1.4.0, it is possible to make Smart Contract easily bindable in Go native language based applications. ABIGen to generate the code.

Such a Smart Contract development environment can be connected to the Block Chain Engine to deliver Contract Creation / Deployment, Message Tx, and Call / Query. This Block Chain Engine means the distributed branching machine 1 according to an embodiment of the present invention, In the example of Leuim, it means Ethereum Node such as geth, parity, eth. As a result, a virtual machine such as EVM for transaction processing and contract execution related to all Smart Contracts is configured on the same node as Distributed Ledger (1).

In this Smart Contract development environment, ABI can be connected with Applications. Smart Contract has only Logic, and application is needed to interact with user or external system. Applications such as HTML + CSS + JavaScript, Application Server, and Wallet are configured to interact with Smart Contracts, for example, through an interface with Ethereum.

The Smart Contract Code can be classified into [Creation / Deployment] [Invoke by Message] [Call]. The code of the shared commodity account according to an embodiment of the present invention can also be classified into a shared commodity account creation, a shared commodity registration message transaction, and a listing request (Query).

FIG. 6 is a schematic diagram illustrating a data structure of shared goods account creation transaction information according to an embodiment of the present invention. 6, the memory module 12 according to an exemplary embodiment of the present invention may store all or part of a block chain. In each block header, a hash value (hash) of a previous block header, an answer value nonce), a hash value of a transaction group and other generated information such as a timestamp, Difficulty indicating difficulty of mining, and a block number indicating a number of a block. Each block body may include at least one transactional information (e.g., a shared good account creation transaction according to one embodiment of the present invention, a conditional token transfer transaction).

In the shared goods account creation transaction information for creation of the shared goods account 31, an address may not be included, and a code of a shared goods account (e.g., Byte), which is a type of smart contract according to an embodiment of the present invention code. Shared Goods Account Creation When transaction information is stored and executed in a block, the address of the shared goods account, which is a type of contract account for the smart contract, is created and stored in the block. At this time, the shared goods account includes a smart contract function for the conditional token transfer request and shared property information (for example, a hash address of the IPFS in which the shared goods are stored, a shared goods information hash value), supplier information (for example, Supplier account address). ≪ / RTI > If the created shared goods account is stored in a block, all the nodes in the distributed chain that are block-chained and distributed globally to the block-chain distributed network can share state changes due to the creation of the new shared goods account.

7 is a flowchart illustrating a method of generating a shared good account according to an embodiment of the present invention. As shown in FIG. 7, according to an embodiment of the present invention, a shared goods account can be created in the following steps.

(1) the supplier client 320 sends a request to the Dapp 400 to create a shared good account that contains shared good information (image, description, supplier information)

(2) the Dapp 400 requests the IPFS 410 to store images and descriptions of the shared good information

(3) The IPFS 410 returns the hash value (image hash value and hash value) of the shared good information to the Dapp 400

(4) requesting the server 430 to store the shared good information in the database at the Dapp 400

(5) The server 420 stores the shared goods information in the DB 430

(6) A message transaction is sent to the Dapp 400 to store the shared commodity account creation transaction including the hash value of the shared commodity information, supplier account information, shared commodity availability period information, price information,

With the above steps, various shared economic systems can be implemented on a block chain including shared goods accounts according to an embodiment of the present invention. According to this, even if the owner is changed for the specific common goods, the entire shared economy system can be maintained without registering the new common goods.

8 is a schematic diagram showing a data structure of conditional token remittance transaction information according to an embodiment of the present invention. 8, the memory module 12 according to an exemplary embodiment of the present invention may store all or part of a block chain. In each block header, a hash value (hash) of a previous block header, an answer value nonce), Timestamp (not shown), which is information about the hash value of the transaction group and other generated time, Difficulty (not shown) indicating the difficulty of the digestion, and Block Number (not shown) . Each block body may include at least one transaction information (in particular conditional token transfer transaction information according to an embodiment of the present invention).

The conditional token transfer transaction information is generated and stored (memorized) in the user account 20 when the conditional token transfer request is sent (message transaction) to the shared goods account 31 for use of the specific shared goods so that the shared goods account (31). As shown in FIG. 8, the conditional token transfer transaction information includes shared goods account address information, condition information on a specific condition (for example, information on a use condition such as a use request date that the user wants to use) (For example, a user account address), provider information (for example, a hash value of an IPFS in which a shared item is stored) that is one of parameters of an instruction, (E.g., provider account address), and token information (e.g., the number of tokens). When the shared goods account 31 generates the conditional token transfer transaction information, it stores it in the memory, and distributes the block chain to the distributed network globally, so that the conditional token transfer transaction information is recorded in all the nodes of the block chain distributed network. State changes can be shared.

FIG. 9 illustrates a method of requesting use of shared goods using conditional token remittance according to an embodiment of the present invention. As shown in FIG. 9, according to an embodiment of the present invention, the use of shared goods can be applied to the following steps.

(1) User client 200 requests Dapp (400) to use a specific shared item (requesting conditional token transfer from user account to shared goods account)

(2) The server 420 receives the shared product image information and the description information from the Dapp 400, and converts the shared product image information and the description information into a Hash value (shared product information hash value)

(3) Dapp (400) sends a conditional token remittance request (in the form of a message transaction) including the shared goods information hash value to the shared goods account (Smart Contract) of the block chain (30)

(4) Verifying whether the use of the supplier is approved in the common goods account (one embodiment of a specific condition)

(5) Retrieves an existing conditional token transfer transaction with the shared goods information hash value stored in the block chain (30) (in the case of the conditional token transfer transaction, the use of the shared goods is terminated, If the period is past, it can be excluded from the search. Also, the integrity of the specific common goods information is verified through retrieval of the hash value of the common goods information)

(6) Verifying that the shared good is a common good that is available based on the existing conditional token transfer transaction retrieved from the shared good account (one embodiment of a specific condition)

(7) If the validation of the supplier use approval, integrity and availability is satisfied, a token transfer transaction is created based on the conditional token transfer request, and then distributed to the block chain distributed network

When the off-chain servers and DBs are used for indexing when implementing the shared economic system as a block chain, the shared goods system can easily be modified. However, according to each of the above steps according to the embodiment of the present invention, the DB, the IPFS, and the block chain have mutual dependency, so that Dapp is not executed when the DB is modulated.

In addition, if the shared economic system is implemented as a block chain, a problem that an invalid shared resource use request is made occurs. According to each of the above steps according to the embodiment of the present invention, since the latestness of the shared goods can be always updated and verified by the block chain, the effect that the use request of the invalid shared goods is approved and not recorded in the block chain .

In addition, when a shared economic system is implemented in a block chain, if the provider who receives the user's token does not provide shared economic services, and if a refund is required under certain conditions, the amount of tokens held by the user is less than the price of the shared goods If the number is small, a problem such as a case where the user has sent an inappropriate token may occur. According to each of the above steps according to an embodiment of the present invention, an effect that an escrow function can be provided on the smart contract of the block chain is generated.

In addition, when a plurality of users make a use request for the same period of time for the same shared goods, the problem that the conditional token transfer request of each user is transmitted to each of the shared goods accounts stored in the plurality of nodes . However, according to each of the above steps according to the embodiment of the present invention, each node requests permission to use from the provider client and is distributed to all nodes as soon as the use approval is made. Therefore, a plurality of conditional token remittance requests An effect that a block chain (hard fork) having a separate path is not generated even if it is transmitted at the same time.

The verification of the availability of the common goods in steps (5) and (6) of the method of requesting the use of the common goods using the conditional token remittance can proceed to the following steps.

(1) judge whether or not the period for which the user wants to use the shared goods is a period set so as to enable the use of the shared goods in the available period information stored in the common goods account

(2) Determine whether another user has requested to use the period first and recorded in an existing conditional token transfer transaction

If it is determined by the above step that the shared goods availability in the shared goods use request using the conditional token remittance is determined, the condition of the conditional token remittance request is satisfied or not. If it is determined by the above step that there is no shared commodity availability in the shared commodity use request using the conditional token remittance, the shared commodity account returns the conditional token remittance request to the user account.

Also, when a plurality of users make usage requests for the same period of time for the same shared goods, the conditional token transfer request of each user is transmitted to each of the shared goods accounts stored in the plurality of nodes (distributed languor apparatus) A problem arises that it is possible to send usage approvals for conditional token remittance requests for the same period. This is because receipt of the supplier use authorization proceeds for each node that received the conditional token transfer request rather than proceeding to the entire node because of transaction costs. However, according to the above step (5) according to the embodiment of the present invention, since the conditional token transfer request is distributed to all the nodes after determining whether the use approval is duplicated for the same period, Even if a plurality of conditional token remittance requests are transmitted at the same time, a block chain (hard fork) having a separate path is not generated.

10 is a flowchart illustrating a distributed ledger method for generating a key for a block-chain-based shared economy with specific conditions for use approval according to an embodiment of the present invention. 10, a distributed ledger method for generating a key for a block-chain-based shared economy of the processing module 11 according to an embodiment of the present invention includes receiving a conditional token transfer request S10, The transaction information may be processed including the approval request step S11, the use approval step S12, the conditional token transfer transaction creation step S13, and the distribution step S14.

The conditional token transfer request receiving step S10 is a step in which the shared goods account 31 receives the conditional token transfer request from the user account 20. [ The conditional token remittance request is a request to cause the conditional token remitting function of the conditional token module 312 of the shared goods account 31 to be called. According to the step S10 of receiving the conditional token remittance request according to the embodiment of the present invention, since the token is remitted to the supplier account 32 after the satisfaction of the specific condition, the effect of escrowing becomes possible without the arbiter do.

The use approval request step (S11) and the use approval step (S12) illustrate one of the specific conditions of the conditional token remittance request.

The use authorization request step S11 is a step of requesting the supplier account 32 or the supplier client 320 to approve the use of the specific common goods in the common goods account 31. [

The use approval step (S12) is a step of transmitting, in the supplier account (32) or the supplier client (320), approval of use for the specific common goods to the common goods account (31). The specific condition of the conditional token transfer request in S10 is satisfied by the use approval step (S12).

The conditional token transfer transaction creation step S13 is a step of creating a transaction for the conditional token transfer request in the shared goods account 31 and storing the transaction in the storage or memory of the shared goods account 31. [ A contract account can contain a persistent store called Storage. In storage, a 32-byte key is mapped to a 32-byte value in a key-value map structure. Certain Smart Contracts may not be able to read or write storage of contracts other than themselves. Memory can be configured as a space for getting the latest instance whenever Smart Contract has a message call. In memory, it can be read and written at byte level, but it can be stored in 32 byte unit chunk. That is, if a value of 1 is stored in a memory, it can be stored in a space of 32 bytes (256 bits). For example, the EVM contains a stack that can hold a total of 1024 instruction sets (OPCODEs) and can have a word value of 256 bits.

The distributing step S14 distributes the conditional token transfer transaction information that is the state changed by the conditional token transfer transaction creating step S13 to all the nodes of the block chain distributed network 100 by the distributed general ledger 1, Casting.

According to the distributed ledger method for generating a key for a shared economy based on block chaining according to an embodiment of the present invention, a request for use of a shared good that is not illegal by a conditional token transfer request, The cost of creating a shared economic ecosystem without the cost of creating, storing, and distributing transactions.

Transaction information broadcast device

11 is a schematic diagram showing HTTP communication between the transaction information transmitting apparatus 2 and the distributed general ledger 10 of the present invention in connection with the transaction information broadcasting apparatus according to an embodiment of the present invention. As shown in FIG. 11, the transaction information broadcasting apparatus according to an embodiment of the present invention uses, for example, a JavaScript-based Web 3. Js API when it is coded with solidity, and internally uses a JSON-RPC You can use the API. Thus, the transaction information transmitting apparatus 2 can be configured with a browser, Node.JS, Mist, or the like. The subject of the transaction information transmitting apparatus 2 may be EOA or CA.

11, a conditional token transfer request is sent to the distributed general ledger 1 to store a conditional token transfer transaction in the shared goods account in the transaction information transmitting apparatus 2 according to the embodiment of the present invention, It can be requested using API. Upon receiving the conditional token transfer request (message transaction), the distributed general ledger 1 judges whether the specific condition is satisfied or not according to the distributed ledger method of generating a key for a block economy based shared economy according to an embodiment of the present invention If the condition is satisfied, the conditional token transfer transaction can be stored in the storage or memory of the shared commodity account as difficulty information, and then broadcast and propagated to the block chain distributed network 100.

FIG. 12 is a schematic diagram showing a case where a transaction information transmitting apparatus according to an embodiment of the present invention receives a conditional token transfer request including a use request for a specific shared item. As shown in FIG. 12, when the use of the specific shared goods by the user client is requested through the conditional token transfer, the transaction information transmitting device 2 transmits the conditional token transfer request to the block chain distributed network 100), and after the conditional token transfer request is generated as transaction information in the Core (transaction information generation step), transaction information signed with the secret key of the transaction information transmission apparatus is transmitted to the block chain distribution network 100 And is transmitted to a specific node (distributed resource device 1) (transaction information transmission step). At this time, the specific node may be a user client or a supplier client.

A specific node (Distributed Ldap, 1) will execute a smart contract of the request to store the conditional token transfer transaction in the block chain (smart contract execution phase) if certain conditions are met. The conditional token transfer transaction stored at a specific node is distributed to the block-chain distributed network 100.

The conditional token transfer transaction distributed to the block chain distributed network 100 at a specific node is stored in the memory of the shared commodity account, and when the specific node or another specific node mining a new block, Block.

Distributed ledger device and method for generating key for shared chain based economy

The distributed scheduling device according to an embodiment of the present invention may be configured to identify a legitimate user at a particular usage time of the shared item via a key generated by the key output module 314. [

13 and 14 are flowcharts illustrating a process in which a legitimate user is identified by a distributed branching device that generates a key for a block-chain-based shared economy according to an embodiment of the present invention. As shown in FIGS. 13 and 14, when the user accesses the shared goods or the supplier while holding the generated key in the client of the user, the client or client of the shared goods is notified of the key Lt; / RTI > The transmitted key can be decrypted based on the private key (private key or secret key) of the shared commodity account / supplier account on the shared commodity client / supplier client to output the proof transaction ID. The outputted validated transaction ID can be configured to determine whether or not the user is legitimate by comparing it with the generated reference transaction ID by requesting the use of the shared goods by the user's conditional token remittance transaction. For example, as shown in FIG. 13, when it is determined to be a legitimate user, unlock control can be performed so that the shared goods can be automatically used by the shared goods client. Or if it is determined that the user is an improper user as shown in FIG. 14, the lock control may be performed such that the shared commodity can not be automatically used by the shared commodity client. According to this, there is an effect that a shared economic system without centralization can be constructed without a resource managed centrally.

FIG. 15 is a flowchart illustrating a process in which a legitimate user is identified by a distributed branching device that generates a key for a block-chain-based shared economy according to another embodiment of the present invention. As shown in FIG. 15, when a user accesses a shared goods client or a supplier client while having a client of the user, the identification code or the local communication is used to confirm that the "Quot; send a message " When a request for a confirmation message is received from the client of the user, a confirmation message signed in the supplier account or the common good account is transmitted through the user's account, thereby identifying the legitimacy of the user. According to this, since the legitimacy of the user can be identified without any additional encryption, a simpler user identification function is enabled.

As described above, those skilled in the art will appreciate that the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. It is therefore to be understood that the above-described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the present invention is defined by the appended claims rather than the detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included in the scope of the present invention.

The features and advantages described herein are not all inclusive, and in particular, many additional features and advantages will be apparent to those skilled in the art in view of the drawings, specification, and claims. Moreover, it should be noted that the language used herein is primarily chosen for readability and for purposes of teaching, and may not be selected to delineate or limit the subject matter of the invention.

The foregoing description of embodiments of the invention has been presented for purposes of illustration; It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Those skilled in the art will appreciate that many modifications and variations are possible in light of the above teachings.

Some portions of this description describe embodiments of the present invention relating to symbolic representations of operations and algorithms. These algorithmic descriptions and representations are generally used by those skilled in the data processing arts to efficiently convey the essence of their work to the other skilled artisan. While such operations are described functionally, computationally, or logically, they are understood to be implemented by a computer or equivalent electrical circuitry, microcode, or the like. Furthermore, this is also conveniently demonstrated without loss of generality, sometimes to represent an arrangement of such operations as a module. The operations described above and their associated modules may be implemented in software, firmware, hardware, or any combination thereof.

Any of the steps, operations, or processes described herein may be performed or implemented in conjunction with one or more hardware or software modules, alone or in combination with other devices. In one embodiment, a software module is implemented with a computer program product comprised of a computer-readable medium comprising computer program code, and the computer program code is executable to perform any or all of the processes, steps, May be executed by a computer processor.

Furthermore, embodiments of the invention may relate to an apparatus for performing the operations herein. These devices may include a general-purpose computing device that may be specially constructed and / or selectively activated or reconfigured by a computer program stored within the computer for the required purpose. Such a computer program may be stored in any type of media suitable for storing computer readable storage media or type of instructions, and may be coupled to a computer system bus. Further, any computing system referred to herein may comprise a single processor, or it may be a structure employing a multiprocessor design for increased computing power.

Finally, the language used herein has been chosen primarily for readability and for purposes of teaching, and may not be selected to describe or limit the subject matter of the invention.

The scope of the invention is, therefore, not to be limited by the Detailed Description, but is to be defined by the claims of any application based thereon. Accordingly, the disclosure of embodiments of the invention is illustrative and not restrictive of the scope of the invention, which is set forth in the following claims.

1: Distributed Ledger
2: Transaction information transmitting apparatus
10: Communication module
11: Processing module
12: Memory module
20: User account
30: Block Chain
31: Shared Goods Account
32: Provider Account
100: Block Chain Distributed Network
200: User Client
310: shared goods registration module
311: List output module
312: Conditional Token Module
313: Use authorization module
314: Key Output Module
315: Start using confirmation module
316: Termination confirmation module
317: rating receiving module
320: Provider Client
400: Dapp
410: IPFS
420: server
430: DB

Claims (1)

A memory module for storing a block chain including a shared good account and a plurality of smart contract accounts which are accounts for a specific shared good; And
A processing module operably coupled to the memory module, the processing module executing computer readable program code of the shared goods account;
/ RTI >
Wherein the program code of the shared goods account comprises:
Receiving a conditional token remittance request for receiving a conditional token remittance request including a usage condition information of a specific user and token remittance information in a user account which is one of the plurality of smart contract accounts in the block chain;
Generating a conditional token transfer transaction including the use condition information and the token transfer information based on the conditional token transfer request, and storing the use condition information and the token transfer information in the shared goods account; And
Generating a key based on the ID of the conditional token transfer transaction and transmitting the key to the user account;
Readable program code for performing the steps of:
Wherein the conditional token transfer transaction is a transfer of the token transfer from the user account to the provider account that is one of the plurality of smart contract accounts in the block chain, the token transfer information and the specific shared goods information Lt; / RTI >
The user client that is the client of the user account encrypts the key with the private key of the user account and includes the identification code or the identifier of the local communication in order to identify the user using the specific shared goods Wherein the provider client decrypts the key using a public key of the user account to identify the user.
A distributed lagging device that identifies a user with an asymmetric key scheme for a shared economy based on block chaining.

Images