KR102390060B1 - Method and apparatus for providing lightweight blockchain for urgent data transmission - Google Patents

Abstract

A lightweight blockchain providing method for urgent data transmission and a device thereof are disclosed. A data transmission method performed by a first relay dust device (RDD) of a smart dust system comprises the following steps of: identifying whether delay of received sensing information is permitted when the sensing information is received from a smart dust device (SDD) due to generation of a transaction; and transmitting the sensing information to a server through different block chains according to the identified result about whether the delay of the sensing information is permitted.

Description

Method and device for providing a lightweight blockchain for urgent data transmission

The present invention relates to a method and apparatus for providing a lightweight block chain for urgent data transmission, and more specifically, a method for dividing a transaction into a transaction that allows some delay and a transaction that does not allow a delay, and transmits it through different block chains and devices.

Blockchain is a distributed computing technology-based data forgery prevention technology and P2P (Peer-to-Peer-based small-scale data chain) By storing managed data in a distributed data storage environment called a 'block', no one can arbitrarily modify it. It is a technology that makes the results of changes accessible to anyone.

Blockchain can effectively prevent data forgery, but as the number of nodes participating in validation increases, the processing speed decreases significantly due to the linear validation procedure. When urgent data transmission is required in an environment with a very large number of nodes, transactions on the blockchain have to wait a lot of time (e.g. 3 transactions in 1 hour for Bitcoin). This makes it difficult to verify the integrity of data requiring urgent transmission, and may cause serious problems. For example, if the oxygen saturation level of the personal health device cannot be verified in a timely manner, the patient's life can be seriously threatened.

Therefore, there is a need for a method that can process data that requires such urgent transmission in the block chain.

The present invention can provide a method and apparatus for facilitating urgent data transmission by constructing two different block chains capable of processing two types of transactions, storing and then integrating and transmitting transactions that allow some delay.

In the data transmission method performed by the first relay dust device (RDD) of the smart dust system according to an embodiment of the present invention, a transaction occurs and the data is transmitted from the smart dust device (SDD). when sensing information is received, identifying whether to allow delay of the received sensing information; and transmitting the sensing information to the server through different block chains according to whether delay of the identified sensing information is allowed.

In the transmitting step, when the sensing information received through the transaction is identified as allowing delay, the sensing information is stored in block units through a lightweight block chain, and when new blocks greater than a threshold are accumulated, sensing that satisfies a certain criterion New blocks including only information may be extracted and transmitted to the server.

In the transmitting step, when it is identified that the sensing information received through the transaction does not allow delay, the sensing information may be immediately transmitted to the server through a general block chain.

The transmitting may include: if the sensing information received through the transaction is identified as allowing delay, creating a new block through a lightweight blockchain and then recording the sensing information; requesting and recording a commit time from a time node to synchronize and manage the new block with other second RDDs; transmitting the new block to other second RDDs, writing the new block to the standby ledger, and simultaneously writing the new block to the commit ledger at the commit time along with other RDDs; and when new blocks greater than or equal to a threshold are accumulated in the commit ledger, extracting new blocks including only sensing information satisfying a predetermined criterion and transmitting the new blocks to the server.

The other second RDDs may write the new block received from the first RDD to the standby ledger, and then write the new block to the commit ledger at a commit time recorded in the new block.

The transmitting may include: immediately transmitting the received sensing information to the server when it is identified that the sensing information received through the transaction does not allow delay; recording sensing information after creating a new block through the general block chain; transmitting the new block in which the sensing information is recorded to a lower RDD; and writing the new block to a commit ledger.

In the step of immediately transmitting the received sensing information to the server, unique information for identifying a transaction corresponding to the received sensing information may be added.

The method may further include requesting ledger verification to second RDDs corresponding to lower nodes in order to transmit the sensing information collected in the SDD to the server.

In the ledger verification, when the sensing information received through the transaction is identified as allowing delay, verification of the first RDD and the second RDD may be performed in the form of a binary tree structure.

The ledger verification may temporarily connect an overlay path to the root RDD to the lowest node of the binary tree structure of the first RDD that has requested the ledger verification.

A data transmission device corresponding to a first relay dust device (RDD) of a smart dust system according to an embodiment of the present invention includes a processor, wherein the processor generates a transaction to generate a smart dust device When sensing information is received from (Smart Dust Device, SDD), it is identified whether the received sensing information is delayed or not, and the sensing information is transmitted to the server through different blockchains according to whether the identified sensing information is delayed or not. can

When it is identified that the sensing information received through the transaction allows delay, the processor stores the sensing information in block units through the lightweight block chain, and when new blocks above a threshold are accumulated, only sensing information that meets a certain criterion The new blocks included may be extracted and transmitted to the server.

When it is identified that the sensing information received through the transaction does not allow delay, the processor may immediately transmit the sensing information to the server through a general block chain.

When it is identified that the sensing information received through the transaction allows delay, the processor creates a new block through the lightweight blockchain, records the sensing information, and synchronizes the new block with other second RDDs. In order to manage, the time node requests and records a commit time, and after transmitting the new block to other second RDDs, it is recorded in the standby ledger, and the new block is simultaneously written with other RDDs at the commit time. It is recorded in the commit ledger, and when new blocks greater than a threshold are accumulated in the commit ledger, new blocks including only sensing information satisfying a predetermined criterion may be extracted and transmitted to the server.

The other second RDDs may write the new block received from the first RDD to the standby ledger, and then write the new block to the commit ledger at a commit time recorded in the new block.

In the transmitting step, when it is identified that the sensing information received through the transaction does not allow delay, the received sensing information is immediately transmitted to the server, a new block is generated through the general block chain, and then sensing Information is recorded, the new block in which the sensing information is recorded may be transmitted to a lower RDD, and the new block may be recorded in the commit ledger.

The processor may immediately transmit the received sensing information to the server by adding unique information for identifying a transaction corresponding to the received sensing information.

The processor may request ledger verification from second RDDs corresponding to lower nodes in order to transmit the sensing information collected in the SDD to the server.

In the ledger verification, when the sensing information received through the transaction is identified as allowing delay, verification of the first RDD and the second RDD may be performed in the form of a binary tree structure.

The processor may temporarily connect an overlay path to the root RDD to the lowest node of the binary tree structure of the first RDD that has requested ledger verification.

The present invention can facilitate the transmission of urgent data by configuring two different blockchains that can process two types of transactions, and by storing and then integrating and transmitting transactions that allow some delay.

1 is a diagram showing the configuration of a physical device in a smart dust IoT environment using a lightweight block chain according to an embodiment of the present invention.
2 is a diagram illustrating a processing procedure of a lightweight block chain for processing general sensing data allowing delay according to an embodiment of the present invention.
3 is a diagram illustrating a block example of a lightweight block chain provided by a smart dust IoT system according to an embodiment of the present invention.
4 is a diagram illustrating a processing procedure of a general block chain for processing urgent sensing data that does not allow delay according to an embodiment of the present invention.
5 is a diagram illustrating a block example of a general block chain provided by the smart dust IoT system according to an embodiment of the present invention.
6 is a diagram illustrating a software module configuration of devices constituting a smart dust IoT system according to an embodiment of the present invention.

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

1 is a diagram showing the configuration of a physical device in a smart dust IoT environment using a lightweight block chain according to an embodiment of the present invention.

Referring to FIG. 1 , the smart dust IoT system 100 may be configured in a multi-layered form. The SDD of FIG. 1 refers to a smart dust device that is a sensing device for collecting data, and may have all the features of the smart dust device described above. RDD relays data collected through SDD and refers to a relay dust device that composes the block chain, and performs the role of integrating, transforming, compressing, or buffering data to remove bottlenecks, resulting in a large number of SDDs /RDDs can play a role in balancing the load. The Auth Node may refer to an authentication node that performs authentication, and the Time Node may refer to a time node that designates a commit time for synchronization of RDDs. In addition, the Processing Node of the Smart Dust IoT Server is a node that processes the collected data and can be mapped to Application Entities from a general IoT perspective, and the PC Node is a node that manages the Processing Node and is It is a node that efficiently decomposes the processing load to multiple Processing Nodes.

Transmission of authentication information and sensing data in the smart dust IoT system 100 may be processed as a transaction. The smart dust IoT system 100 may apply a ledger-based data transmission method to reduce a vast amount of data generated in a smart dust IoT environment. That is, instead of transmitting all the sensing data collected from each RDD to the smart dust IoT server, only a selected specific RDD can parse all the ledger information propagated from all RDDs to transmit the smart dust IoT server.

When processing the ledger by applying the blockchain to the smart dust IoT system 100, a slight delay may occur while processing urgent sensing data that does not allow delay in the ledger. In order to solve this problem, the smart dust IoT system 100 may create two types of ledgers for managing two types of data (emergency sensing data and general sensing data) and process them separately. That is, the smart dust IoT system 100 may use two block chains, that is, a lightweight block chain for processing general sensing data and a general block chain for processing emergency sensing data.

2 is a diagram illustrating a processing procedure of a lightweight block chain for processing general sensing data allowing delay according to an embodiment of the present invention.

Normal sensing data does not need to be transmitted urgently, so immediate transmission may not be necessary if network bandwidth is not sufficient. Therefore, RDD collects general sensing data and, when a transaction occurs, records it in the general data ledger, then integrates and transmits it.

Transactions in the existing blockchain can be uniquely identified by information such as the hash of the transaction, mempool, etc. regardless of the order in which the transactions occur. However, maintaining the existing blockchain in smart dust IoT devices can be very difficult as the computing power and resources of the devices are very limited. Since the proposed lightweight block chain for the smart dust IoT system 100 cannot uniquely identify a transaction, the transaction order can be used as a unique identification tool of the transaction. Accordingly, the smart dust IoT system 100 may provide the concepts of a standby ledger, a commit time, and a time node to ensure a transaction order through a lightweight blockchain.

The standby ledger may be a temporary ledger that records new blocks not registered in the commit ledger, which is a synchronized general data ledger of all RDDs. As such, new blocks recorded in the temporary ledger may be merged into the commit ledger at commit time. The time node may perform scheduling using a scheduling table to determine the commit time. The scheduling table is a very simple table divided by enough time intervals to merge the standby ledger into the commit ledger.

First, RDD A constituting the smart dust IoT system 100 receives general sensing data from SDD in step 202, and generates a new block and transaction based on the received general sensing data in step 204 can do.

Thereafter, in step 206 , the RDD A may start inputting information into the generated new block. More specifically, RDD A records the device information of RDD A in the 'to' field of the new block as shown in FIG. 3, records the device information of the SDD from which data is collected in the 'from' field of the new block, and receives information can be recorded in the 'data' field of the new block. In addition, RDD A may record device information of the SDD in the 'Device's Information' field of the new block, and record the hash of the previous block in the 'Hash of previous block'.

Then, in step 208, RDD A requests a commit time from the time node, and in step 210, the time node selects the earliest time in the scheduling table as a commit time based on the request of RDD A and adds it to the scheduling table. can be recorded

In step 212, the RDD A receives the commit time from the time node, records it in the 'Sync Time' field of the new block in step 214, and applies a hash algorithm to the current new block to ' By writing in the 'Hash' field, you can complete the input of information in a new block.

In step 216, when RDD A propagates a new block for which information input has been completed to other RDDs, other RDDs that have received it will not write the new block to their commit ledger, but write the new block to the standby ledger. can In this case, the standby ledger may mean a ledger in which new blocks are recorded, although authentication has been performed but before synchronization of authentication is made, and the commit ledger may mean a ledger in which blocks synchronized to all RDDs are recorded. In addition, RDD A, which has propagated the new block, may also record the new block in its standby ledger.

Thereafter, when the commit time T is reached, in step 218, the Time Node notifies all RDDs of the smart dust IoT system 100 that the commit time T is reached, and the RDDs that have been received are recorded in the standby ledger in step 220 You can update the commit ledger by writing new blocks to your commit ledger.

Thereafter, one RDD selected from among the plurality of RDDs, for example RDD B, may increase the transmission efficiency of the smart dust IoT system 100 by using a two-step data reduction method in step 222 . More specifically, RDD B extracts general sensing data that exceeds the threshold compared to previous general sensing data by parsing the commit ledger (step 1), and overlapping information (e.g. SDD of the general sensing data) ID, header of communication protocol, etc.) can be integrated (step 2).

In this way, RDD B can increase the transmission efficiency of the smart dust IoT system 100 by transmitting the general sensing data, which is reduced in size through the extraction and integration process, to the server as in step 224 .

4 is a diagram illustrating a processing procedure of a general block chain for processing urgent sensing data that does not allow delay according to an embodiment of the present invention.

Delayed transmission of general sensing data that allows delay is possible, but urgent sensing data that does not tolerate delay does not. Therefore, a general blockchain for transmitting urgent sensing data has a standby ledger, commit time, time node, and two-step data reduction method. Not applicable. Therefore, it is possible to manage a general blockchain for transmitting urgent sensing data through the emergency data ledger.

RDD A constituting the smart dust IoT system 100 may first receive emergency sensing data from the SDD in step 402 . In this case, the RDD A may identify whether the data urgently needs to be transmitted by checking the header of the urgent sensing data received from the SDD.

Since the urgent sensing data is not allowed to delay, in step 404, the RDD A immediately transmits the received urgent sensing data to the smart dust IoT server, and then in step 406, based on the transmitted urgent sensing data, a new block and You can create a transaction.

In step 408, the RDD A may input information on the generated new block, and a process of inputting such information may be similar to a process of generating a new block of general sensing data. However, the only difference is that after RDD records all transactions in the 'Transaction' field of the new block, the hash value derived by applying the hash algorithm to the transaction recorded in the 'Transaction' field as shown in FIG. 5 is stored in the 'Hash of previous transaction' field that it is recorded in As such, the smart dust IoT system 100 can distinguish each transaction through the hash value recorded in the 'Hash of previous transaction' field even in a mixed state regardless of the order of the transactions for the urgent sensing data.

In step 410, the RDD may propagate the new block for which information input has been completed to the lower RDDs, and in step 412, the lower RDDs, when receiving the propagated new block, respond to urgent sensing data for data integrity You can update new blocks to your own commit ledger sequentially.

6 is a diagram illustrating a software module configuration of devices constituting a smart dust IoT system according to an embodiment of the present invention.

The smart dust IoT system 100 provided by the present invention can be largely divided into four physical devices such as SDD, RDD, Time Node, and Server Node. Among the software of these four physical devices, the modules commonly loaded are Init Module, Session Module, Sending Module, and Receiving Module. First, the Init Module is a module that performs initialization suitable for the role of each device, the Session Module is a module that maintains and manages the connection to the device connected to itself, and the Sending Module sends data generated or processed from the device to another device. The sending module is the receiving module, and the receiving module is the module receiving data from other devices.

In addition to this, the SDD may further include a Sensing Module, wherein the Sensing Module is a module that detects and collects data from the outside.

In addition, the RDD may further include a BlockMng Module, a TransMng Module, and a Broadcast Module, where the BlockMng Module is a module that creates and manages blocks, and the TransMng Module is a module that records transactions such as authentication and data collection in blocks. , the Broadcast Module is a module that propagates a block to other RDDs.

Finally, the Time Node may further include a TaskRegister Module, a TimeCheck Module, and a Notification Module, where the TaskRegister Module is a module that registers a task in a schedule, the TimeCheck Module is a module that determines the task time for synchronization, and the Notification Module is a module that notifies synchronization when the working time is reached.

Meanwhile, the method according to the present invention is written as a program that can be executed on a computer and can be implemented in various recording media such as magnetic storage media, optical reading media, and digital storage media.

Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or combinations thereof. Implementations may be implemented for processing by, or controlling the operation of, a data processing device, eg, a programmable processor, computer, or number of computers, a computer program product, ie an information carrier, eg, a machine readable storage It may be embodied as a computer program tangibly embodied in an apparatus (computer readable medium) or a radio signal. A computer program, such as the computer program(s) described above, may be written in any form of programming language, including compiled or interpreted languages, as a standalone program or in a module, component, subroutine, or computing environment. It can be deployed in any form, including as other units suitable for use in A computer program may be deployed to be processed on one computer or multiple computers at one site or distributed across multiple sites and interconnected by a communications network.

Processors suitable for processing a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. In general, a processor will receive instructions and data from either read-only memory or random access memory or both. Elements of a computer may include at least one processor that executes instructions and one or more memory devices that store instructions and data. In general, a computer may include, receive data from, transmit data to, or both, one or more mass storage devices for storing data, for example magnetic, magneto-optical disks, or optical disks. may be combined to become Information carriers suitable for embodying computer program instructions and data are, for example, semiconductor memory devices, for example, magnetic media such as hard disks, floppy disks and magnetic tapes, Compact Disk Read Only Memory (CD-ROM). ), optical recording media such as DVD (Digital Video Disk), magneto-optical media such as optical disk, ROM (Read Only Memory), RAM (RAM) , Random Access Memory), flash memory, EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), and the like. Processors and memories may be supplemented by, or included in, special purpose logic circuitry.

In addition, the computer-readable medium may be any available medium that can be accessed by a computer, and may include both computer storage media and transmission media.

While this specification contains numerous specific implementation details, they should not be construed as limitations on the scope of any invention or claim, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. should be understood Certain features that are described herein in the context of separate embodiments may be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments, either individually or in any suitable subcombination. Further, although features operate in a particular combination and may be initially depicted as claimed as such, one or more features from a claimed combination may in some cases be excluded from the combination, the claimed combination being a sub-combination. or a variant of a sub-combination.

Likewise, although acts are depicted in the drawings in a particular order, it should not be construed that all acts shown must be performed or that such acts must be performed in the specific order or sequential order shown to obtain desirable results. In certain cases, multitasking and parallel processing may be advantageous. Further, the separation of the various device components of the above-described embodiments should not be construed as requiring such separation in all embodiments, and the program components and devices described may generally be integrated together into a single software product or packaged into multiple software products. You have to understand that you can.

On the other hand, the embodiments of the present invention disclosed in the present specification and drawings are merely presented as specific examples to aid understanding, and are not intended to limit the scope of the present invention. It will be apparent to those of ordinary skill in the art to which the present invention pertains that other modifications based on the technical spirit of the present invention can be implemented in addition to the embodiments disclosed herein.

100: Smart Dust IoT System

Claims (20)

In a data transmission method performed by a first relay dust device (RDD) of a smart dust system,
When sensing information is received from a smart dust device (SDD) due to a transaction occurring, identifying whether to allow delay of the received sensing information; and
Transmitting sensing information to a server through different block chains according to whether delay of the identified sensing information is permitted
A data transmission method comprising a. According to claim 1,
The transmitting step is
When the sensing information received through the transaction is identified as allowing delay, the sensing information is stored in block units through the lightweight block chain, and when new blocks greater than a threshold are accumulated, only sensing information that satisfies a certain criterion is included. A data transmission method for extracting blocks and transmitting them to the server. According to claim 1,
The transmitting step is
When it is identified that the sensing information received through the transaction does not allow delay, the data transmission method for immediately transmitting the sensing information to the server through a general block chain. According to claim 1,
The transmitting step is
When the sensing information received through the transaction is identified as allowing delay, creating a new block through a lightweight blockchain and then recording the sensing information;
requesting and recording a commit time from a time node to synchronize and manage the new block with other second RDDs;
transmitting the new block to other second RDDs, writing the new block to the standby ledger, and simultaneously writing the new block to the commit ledger at the commit time along with other RDDs; and
When new blocks greater than a threshold are accumulated in the commit ledger, extracting new blocks including only sensing information satisfying a predetermined criterion and transmitting the new blocks to the server
A data transmission method comprising a. 5. The method of claim 4,
The other second RDDs are
A data transmission method of writing the new block received from the first RDD to a standby ledger and writing the new block to the commit ledger at a commit time recorded in the new block. According to claim 1,
The transmitting step is
immediately transmitting the received sensing information to the server when it is identified that the sensing information received through the transaction does not allow delay;
Recording sensing information after creating a new block through a general block chain;
transmitting the new block in which the sensing information is recorded to a lower RDD; and
writing the new block to the commit ledger
A data transmission method comprising a. 7. The method of claim 6,
The step of immediately transmitting the received sensing information to the server,
A data transmission method for adding unique information for identifying a transaction corresponding to the received sensing information. According to claim 1,
requesting ledger verification to second RDDs corresponding to lower nodes in order to transmit the sensing information collected in the SDD to the server
A data transmission method further comprising a. 9. The method of claim 8,
The ledger verification is
When the sensing information received through the transaction is identified as allowing delay, the first RDD and the second RDD are verified in the form of a binary tree structure. 10. The method of claim 9,
The ledger verification is
A data transmission method of temporarily connecting an overlay path to the root RDD to the lowest node of the binary tree structure of the first RDD that has requested ledger verification. A data transmission device corresponding to a first relay dust device (RDD) of a smart dust system, the data transmission device comprising:
including a processor;
The processor is
When a transaction occurs and sensing information is received from a smart dust device (SDD), it is identified whether delay of the received sensing information is allowed, and different block chains are created according to whether the delay of the identified sensing information is allowed. A data transmission device that transmits sensing information to a server through 12. The method of claim 11,
The processor is
When the sensing information received through the transaction is identified as allowing delay, the sensing information is stored in block units through the lightweight block chain, and when new blocks greater than a threshold are accumulated, only sensing information that satisfies a certain criterion is included. A data transmission device for extracting blocks and transmitting them to the server. 12. The method of claim 11,
The processor is
When it is identified that the sensing information received through the transaction does not allow delay, the data transmission device immediately transmits the sensing information to the server through a general block chain. 12. The method of claim 11,
The processor is
When it is identified that the sensing information received through the transaction allows delay, a new block is created through the lightweight blockchain, the sensing information is recorded, and the new block is synchronized with other second RDDs to manage it The time node requests and records a commit time, and after transmitting the new block to other second RDDs, it is recorded in the standby ledger. At the commit time, the new block is simultaneously written to the commit ledger with other RDDs. A data transmission apparatus for recording, and for extracting new blocks including only sensing information satisfying a predetermined criterion when new blocks greater than a threshold are accumulated in the commit ledger and transmitting the new blocks to the server. 15. The method of claim 14,
The other second RDDs are
A data transmission apparatus for writing the new block received from the first RDD in a standby ledger and writing the new block to the commit ledger at a commit time recorded in the new block. 12. The method of claim 11,
The transmitting step is
If it is identified that the sensing information received through the transaction does not allow delay, the received sensing information is immediately transmitted to the server, a new block is created through a general block chain, and then the sensing information is recorded, and the A data transmission device that transmits a new block in which sensing information is recorded to a lower RDD, and records the new block in a commit ledger. 17. The method of claim 16,
The processor is
A data transmission apparatus for immediately transmitting the received sensing information to the server by adding unique information for identifying a transaction corresponding to the received sensing information. 12. The method of claim 11,
The processor is
A data transmission device for requesting ledger verification to second RDDs corresponding to lower nodes in order to transmit the sensing information collected in the SDD to the server. 19. The method of claim 18,
The ledger verification is
When the sensing information received through the transaction is identified as allowing delay, the first RDD and the second RDD are verified in the form of a binary tree structure. 20. The method of claim 19,
The processor is
A data transmission device that temporarily connects an overlay path to the root RDD to the lowest node in the binary tree structure of the first RDD that has requested ledger verification.

Images