KR102258936B1 - System and method for serverless computing based on blockchain - Google Patents

Abstract

The present disclosure provides a serverless computing system based on a blockchain. The system includes a blockchain server that stores and manages a database including a plurality of block states updated according to one or more transactions received from a client, a state listener that monitors whether the state of a plurality of blocks is changed, and a plurality of a worker executing a function according to a change in the block state, wherein the state listener detects the change in the block state and notifies the worker to execute the function according to the change in the block state, and the worker executes the function according to the function execution notification do. In addition, a transaction representing the execution result of a function by a worker can be recorded in the blockchain network.

Description

SYSTEM AND METHOD FOR SERVERLESS COMPUTING BASED ON BLOCKCHAIN

The present invention relates to a blockchain-based serverless computing system and method, and more specifically, by setting or updating a block state value of a blockchain database, starting and executing a job by a worker having an off-chain state secure execution environment By configuring to do so, it relates to a system and method capable of parallel processing of one or more tasks.

In general, the blockchain technology is a technology for recording and storing the contents of a transaction made over a network communication in a reliable and secure way. A blockchain network is a system in a distributed environment that allows the exchange of digitized assets or transactions, and records the history of electronic transactions or work history generated in a peer-to-peer (P2P) network using a shared ledger. do. Since the blockchain network uses a decentralized or decentralized consensus mechanism, it is virtually impossible to forge or falsify a transaction by a third party, thereby guaranteeing the reliability and transparency of the transaction.

For example, when using Ethereum, which is a form of public blockchain, data security and reliability can be ensured by verifying the execution of code by participating nodes of the blockchain. However, at present, the speed of Ethereum's consensus process is only 15 TPS (transactions per second), which is not sufficient to handle the computation of applications deployed worldwide. In addition, since it structurally has the characteristics of statefulness, trustlessness, and serialized operation, the scalability of Ethereum can be significantly limited.

Recently, in order to increase the scalability of an application, a serverless computing technology having characteristics of stateless, permissioned, and parallel operation of operations has been used. Serverless computing refers to an event-based cloud computing technology that enables application development regardless of the consideration of computing resources required for application execution. In a serverless computing system, a cloud service provider or a distributed resource provider dynamically allocates machine resources, and a code provided by an application developer is executed through the allocated machine resources. In such a serverless computing environment, the cost of infrastructure operation and maintenance can be reduced, service users can easily access the service network, and data storage and various functions provided by the cloud service are used for code execution. You can manage the required time and money efficiently.

The conventional blockchain-based computing system supports only one programming language and one virtual machine running an application written in the programming language, and all nodes participating in the blockchain execute the same transaction. Due to this, the operating cost of the entire system increases, and since interaction occurs only with the internal state database, there is a problem in that it is impossible to call an external database and an application programming interface (API).

In order to solve the above problem, according to an embodiment of the present disclosure, a block capable of executing various programming languages on different types of runtime execution environments using a structure in which block chain-based communication, storage, and execution (or computation) are separated. It provides a chain-based serverless computing system.

In addition, according to an embodiment of the present disclosure, by setting a path value (or block state) of the blockchain database to start a job, and each resource provider for this job records the result in a specified path, one or more jobs It provides a blockchain-based serverless computing system capable of parallel processing of

In addition, according to an embodiment of the present disclosure, by configuring the block state of the block chain database in a tree structure, different consensus rules can be defined for each divided subtree, and a small block for each subtree It provides a blockchain-based serverless computing system that can maintain the chain.

The present disclosure provides a serverless computing system based on a blockchain. The system includes a blockchain server that stores and manages a database including a plurality of block states updated according to one or more transactions received from a client, a state listener that monitors whether the state of a plurality of blocks is changed, and a plurality of a worker executing a function according to a change in the block state, wherein the state listener detects the change in the block state and notifies the worker to execute the function according to the change in the block state, and the worker executes the function according to the function execution notification do.

According to one embodiment, the blockchain server sets the authority to change the block state of the database, and sets the function to be executed when the block state is changed.

According to an embodiment, a transaction includes a key-value pair of a target node path value for an operation (key) and a target value of a state update (value), and the block state reflects the key-value pair of the transaction It consists of a tree structure.

According to an embodiment, the blockchain server may configure a plurality of block states into a tree structure including a plurality of subtrees, and apply different consensus rules to each subtree of the plurality of block states.

According to an embodiment, a shard is applied to each subtree of a plurality of block states, and the shard processes each subtree in a blockchain instance.

According to an embodiment, a transaction includes a lead control, and the lead control indicates a suitable time for the transaction to be utilized, including executing a worker based on the transaction. For example, if the lead control is set to 0, it indicates that it is okay to refer to the data of the transaction even when block generation based on the transaction is not executed. If the lead control is set to 1, the block generation based on the transaction is at least 1 Indicates that the data can be referenced after it has been executed.

According to an embodiment, the blockchain server further includes a transaction pool that stores a transaction before the transaction is created as a block, and the system verifies the transaction before storing the transaction in the transaction pool and reflects it in the block state. 1 node; and a second node that generates a block including the transaction by executing validation of the transaction stored in the transaction pool.

According to an embodiment, the blockchain server removes the transaction from the transaction pool when validation and block generation for the transaction are completed by the second node.

According to another embodiment of the present disclosure, a blockchain-based serverless computing method is provided. The method includes, by a blockchain server, when one or more transactions are received from a client, updating a block state of a database according to the transactions; monitoring, by a state listener, whether a block state is changed; when a change in the block state is detected by the state listener, notifying the worker to execute a function according to the change in the state of the block chain; and transmitting, by the worker, a transaction representing a result of the worker executing the function to the blockchain network.

According to an embodiment, the block chain-based serverless computing method may further include setting the authority to change the block state of the database, and setting a function to be executed when the block state is changed.

According to one embodiment, when one or more transactions are received by the blockchain server from the client, updating the block state of the database according to the transaction includes: adding the transaction to the transaction pool before the transaction is created as a block; Before the transaction is stored in the transaction pool, by the first node, verifying the transaction and reflecting it in the block state; generating, by the second node, a block including the transaction by executing validation of the transaction stored in the transaction pool; and applying the block generated by the second node to the block state of the first node so that consistency of the blockchain network is maintained.

According to another embodiment, there is provided a computer-readable storage medium storing one or more programs configured to be executed by one or more processors of a computing device. The one or more programs include instructions for performing the above methods.

According to various embodiments of the present disclosure, by using a structure in which communication, storage, and execution are separated in a blockchain-based serverless computing system, various programming languages can be supported on different runtime execution environments, and system operating costs can be reduced. can

In addition, according to embodiments of the present disclosure, parallel processing of one or more tasks is possible by setting the block state of the blockchain database to start and execute tasks in a blockchain-based serverless computing system, thereby increasing system performance. have.

In addition, according to embodiments of the present disclosure, by configuring the block states of the block chain database in a tree structure, defining different consensus rules for each divided subtree, and maintaining a small block chain, execution in the system Consensus rules can be set to suit the various requirements of the application being used (eg, scalability, security, decentralization, etc.).

1 is a diagram illustrating the configuration of a block chain-based serverless computing system according to an embodiment of the present disclosure.
2 is a diagram illustrating a process in which a change in a block chain state acts as a trigger in a block chain-based serverless computing system according to an embodiment of the present disclosure to cause a chain reaction of transaction creation and job execution.
3 is a diagram illustrating a process of generating a transaction and a block in a blockchain-based serverless computing system according to an embodiment of the present disclosure.
4 is a diagram illustrating a state change of a block chain database according to a lead control line according to an embodiment of the present disclosure.
5 is a diagram illustrating a sharding process through a lower block chain in a block chain database according to an embodiment of the present disclosure.
6 is a flowchart illustrating a process of serverless computing based on a blockchain according to an embodiment of the present disclosure.
7 is a flowchart illustrating a transaction execution and block generation process according to an embodiment of the present disclosure.

Hereinafter, specific contents for carrying out the present disclosure will be described in detail with reference to the accompanying drawings. However, in the following description, if there is a risk of unnecessarily obscuring the subject matter of the present disclosure, detailed descriptions of well-known functions or configurations will be omitted.

In the accompanying drawings, identical or corresponding components are assigned the same reference numerals. In addition, in the description of the embodiments below, overlapping description of the same or corresponding components may be omitted. However, even if descriptions regarding components are omitted, it is not intended that such components are not included in any embodiment.

In the present disclosure, the term "serverless computing" is used in conventional server-based computing, where users prepare a server to execute a specific task, and install an operating system and other necessary drivers and software. Unlike the prepared environment, it may refer to a computing environment or system in which a user does not need to manage a server or set its calculation and storage capacity. As will be described in detail with reference to various embodiments below, in a serverless computing system, back-end code may be automatically executed in response to an event. Here, the code is stored in a repository and can be executed in the managed environment of a worker (execution environment or resource provider). When a serverless computing system is implemented based on a blockchain, workers can provide an off-chain execution environment that is provided separately from the blockchain.

In this disclosure, the term "PoW (Proof-of-Work)" or "Proof of Work" is one of the consensus algorithms used for block generation in the blockchain network, for example, by calculating the nonce value of the block to validate the transaction. A consensus algorithm that proves On the other hand, the terms "PoS (Proof-of-Stake)" or "Proof of Stake" can refer to a consensus algorithm that gives decision-making authority in proportion to the stake of cryptocurrency or computing resource each node owns. For example, in a blockchain network that uses a PoS consensus algorithm, nodes holding assets such as cryptocurrency can contribute to the creation of the block by proving their stake in the block they agree on. In a PoW-based blockchain, the process of verifying block validity is called “mining”, whereas in a PoS-based blockchain, the process can be called “forging”.

The block chain-based serverless computing system according to an embodiment of the present disclosure, unlike the existing block chain system that includes all components of a smart contract in a block chain network, stores the system components, It operates by dividing it into communication processing network and computational components. The blockchain-based serverless computing system according to this embodiment serves to record the communication between components in the order of occurrence, and the computational task is performed off-chain in a secure runtime environment (SRE). chain) to be executed in the state. In this system, the storage can act as an adapter for aggregating different storages (eg, Amazon S3, Google Cloud Storage, IPFS, etc.).

According to an embodiment, the blockchain-based serverless computing system may manage uploaded programs, resource providers, and requests received from clients. In addition, in a blockchain-based serverless computing system, the smart contract operation is recorded as a state, and unlike the existing blockchain system (e.g. Ethereum), where the execution cannot be executed in parallel, the execution of the task It is stateless and asynchronous. That is, the system starts each operation or operation by setting the path value or block state of the blockchain database, and each worker executing this operation records the execution result in the specified path. do. All tasks can be processed in parallel as long as there is no attempt to duplicate and change the value of a specific path in the blockchain database.

In addition, according to an embodiment, the blockchain-based serverless computing system may store a database state in a tree structure. By dividing and configuring the database into multiple sub-trees in this way, each divided sub-tree defines its own consensus algorithm, except for the genesis rule (eg, PoS rule) of the blockchain network, A small-scale blockchain can be maintained for each subtree.

In one embodiment, the blockchain-based serverless computing system may function as a backend system for application execution. In this system, the application can be executed as follows. First, when a client (or dApp: decentralized application) sends a transaction to the blockchain, the block state of the blockchain node is changed by the data of the transaction (for example, path-value pairs). updated. On the other hand, the block state listener monitors the blockchain path, detects the state updated by the transaction, and sends an event to the worker. The worker receiving the event may execute a task or function associated with the transaction and create another transaction. If a worker creates another transaction, the block state of the blockchain node is updated by that transaction. In addition, the client can obtain the result through the modified blockchain state.

1 is a diagram illustrating the configuration of a block chain-based serverless computing system according to an embodiment of the present disclosure. The block chain-based serverless computing system 100 includes a block chain server 110 that stores and manages a database including a plurality of block states, a state listener 120 that monitors whether the block state is changed, and a block state of It includes a worker 130 that executes a function according to the change.

As shown, the blockchain server (or node) 110 may include a database 112 including a plurality of block states. In one embodiment, each block state stored in the database 112 may include a balance of each public key and a key-value database. The block state may be of one of two types: a master state and a rule state. The master state can store real data that is updated by all participating nodes in the blockchain network. Also, the rule state may include a rule for determining an access right for changing a data value corresponding to a key.

Also, the database 112 may be configured in a tree structure. The database 112 having a tree structure may maintain a subset (or subtree) of a tree as shards by applying a sharding technique. In the present disclosure, “sharding” may refer to an on-chain solution that divides the entire blockchain network, stores transactions by area, and processes them in parallel to provide scalability to the blockchain. . Since each subtree managed as a shard is processed in a separate small blockchain instance, it can have the effect of greatly increasing the total throughput of the blockchain. In one embodiment, a different PoS consensus algorithm may be set to be applied for each subtree of the database 112 .

The state listener 120 may monitor whether the state of the block chain block stored in the database 112 is changed. In one embodiment, the state listener 120 is a module created or executed by the worker 130 after the worker 130 is set to execute a new task, and is registered and installed in the worker 130 or installed in the blockchain server 110 . ) can be registered and installed.

The blockchain server 110 sets the authority to change the block state of the database 112, and sets the function to be executed when a transaction is received from one or more clients (or dApps) 140 and the block state is changed. can In addition, when receiving a transaction from one or more clients (or dApps) 140 , the blockchain server 110 may change the blockchain block state according to the transaction, and the state listener 120 is the blockchain server 110 . can be monitored to detect a change in the block state. When the state listener 120 detects a change in the block state, it may notify the worker 130 to execute a function according to the change in the block state. In an embodiment, the worker 130 may create another transaction as a result of executing a function according to a change in the block state. In this case, the worker 130 may transmit the newly created transaction to the block chain server 110 to update the block state. Such an update of the block state in the block chain server 110 may cause a chain reaction leading to the execution of an additional task. That is, when the transaction generated by the worker is transmitted to the block chain server 110 and the block state is updated, the state listener 120 detects the state update and notifies the worker 130 or another worker to execute the related task. can do.

In one embodiment, the above-described block chain server 110 and worker 130 may be included in one node of the block chain network. In this case, the blockchain server 110 and the worker 130 may immediately respond to the received transaction and execute the related work. In other embodiments, workers 130 are implemented to be detachable and may be hosted by other computing devices (or resource providers). In this case, a separate communication channel may be formed from the corresponding computing device to the block chain server 110 .

FIG. 2 is a diagram illustrating a process in which a change in a block state acts as a trigger in a block chain-based serverless computing system according to an embodiment of the present disclosure to cause a chain reaction of transaction creation and job execution.

As shown, the chained-reaction between creation of a transaction and execution of a task may be initiated by the client 210 creating a transaction through, for example, a dApp and transmitting it to the blockchain server 220 .

When the blockchain server 220 receives a transaction, the block state may be updated by the transaction. At this time, the state listener may monitor the block state change of the block chain server 220 and transmit an event according to the block state change to the worker 230 . The worker 230 may execute a task or function triggered by the block state change in this way, and may generate an additional transaction as a result of the function execution. The additional transaction generated by the worker 230 may be transmitted back to the blockchain server 220, and the corresponding block state may be updated accordingly. An updated state change here can trigger another worker's job. In addition, the client 210 can obtain a result value through the updated block state of the block chain.

3 is a diagram illustrating a process of generating a transaction and a block in a blockchain-based serverless computing system according to an embodiment of the present disclosure. The blockchain server 310 and the database 312 shown in FIG. 3 may include the blockchain server 110 and the database 112 shown in FIG. 1 , respectively.

In one embodiment, the blockchain server 310 may include a database 312 containing the block state of the blockchain and a transaction pool 314 .

The client 340 may generate a transaction to update the block state stored and managed by the blockchain server 310 . Each transaction has a transaction identifier, address (eg, the public key of the transaction owner), data specifying the actual state update request (eg, the target node path for the operation (key), and the target value of the state update (value)) of key-value pairs).

Upon receiving the transaction sent from the client 340 , the blockchain server 310 may store the transaction in the transaction pool 314 . The transaction pool 314 may mean a repository of valid transactions that have not yet been added to a block but become part of a consensus blockchain.

In one embodiment, the node (or first node) including the blockchain server 310 may validate and execute the transaction before the transaction is stored in the transaction pool 314 . The first node may verify the transaction using a signature that guarantees that the transaction was sent by the appropriate client 340 and a rule that checks whether the transaction violates the permission authority. Also, the first node may complete execution (or application to the database) of the transaction by updating the transaction data (eg, path-value pairs) to the block state of the database 312 . As will be described in detail below, whether to update the transaction data in the block state may be determined by a value indicating the reliability of data included in the transaction. Once a transaction is added to the transaction pool 314 by the first node, the transaction can be propagated through the network until all other nodes on the blockchain network have added the transaction to the local transaction pool.

On the other hand, a forger node (or second node) of the blockchain network can execute validation (or forging) of a transaction added to the transaction pool. In addition, the second node can create a block including a transaction for which validation has been completed and connect it to the blockchain. Blocks connected to the blockchain are propagated to the first nodes constituting the blockchain network, and all nodes are updated to have the same blockchain state.

When verification of all transactions and block generation are completed and added to the blockchain, the transaction is removed from the transaction pool.

4 is a diagram illustrating a state change of a block chain database according to a lead control line according to an embodiment of the present disclosure. The database 400 shown in FIG. 4 is the database 112, 312 stored and managed by the blockchain servers 110, 220, 310 of the blockchain-based serverless computing system described with reference to FIGS. 1 to 3 ) can be shown in detail.

As shown, the database 400 may include blocks 410 and 420 including transactions and block states 430 corresponding thereto. For example, block 410 is created to include transactions “a/b:1” and “a/c:2”, corresponding to block state 430 with value “1” on path “a/b”. ", and updated to reflect the value "2" in path "a/c". Next, block 420 is created to contain transactions “a/d:3” and “a/c:3”, corresponding to block state 430 with the value “1” in path “a/b”. However, the value of path “a/c” is changed from “2” to “3” and updated to reflect the value “3” in path “a/d”.

Meanwhile, in the transaction pool of the blockchain server, transactions that have not yet been added as blocks to the blockchain (“a/e/f:4”, “a/e/g:5”) are stored. These transactions may further include a read_concern field in addition to the path (key)-value pair. Lead concern is a value that can be included when creating a transaction, and can indicate whether the data of the transaction is reliable enough to be reflected in the block state of the block chain.

In one embodiment, when the client creates a transaction, the transaction may include lead control information, and the value may be arbitrarily set by the client. The first node of the blockchain server may reflect the key-value pair of the corresponding transaction to the block state based on the lead-context value of each transaction. For example, if the lead concern value is 0, it is determined that the reliability is high enough to be used even before the block including the data of the transaction is created, and the data of the transaction can be directly reflected in the block state of the database. . In other words, the blockchain server can immediately execute the transaction when the lead-context value of the transaction is 0. On the other hand, when the lead control value is 1 or more, the execution of the corresponding transaction may be suspended until the block including the data of the corresponding transaction is generated once or more.

In the example of FIG. 4 , the value of the read control of the transaction “a/e/g:5” is given 1 and is recommended to be read after one block creation, so the corresponding data is not reflected in the block state 430 . execution can be suspended. On the other hand, since the lead control value of the transaction “a/e/f:4” is set to 0, the transaction may be executed immediately and reflected in the block state 430 .

5 is a diagram illustrating a sharding process through a lower block chain in a block chain database according to an embodiment of the present disclosure. The database 500 shown in FIG. 5 is the database 112, 312 stored and managed by the blockchain servers 110, 220, 310 of the blockchain-based serverless computing system described with reference to FIGS. 1 to 3 ) can be shown in detail.

The database 500 may include a chain of blocks 510 , 520 , 530 , 542 , 544 , and 546 having a plurality of levels. In addition, the database 500 may further include block states 550 , 552 , and 554 reflecting path (key)-value pairs of the transactions included in the blocks 510 , 520 , and 530 .

As shown, the database 500 includes root blocks 510 , 520 , 530 using the highest level rule and lower level child blocks 542 , 544 , 546 generated by branching from these blocks. may include The path-value pairs of the transactions included in the root blocks 510 , 520 , and 530 are reflected and stored in the root state 552 , and the path-value pairs of the child blocks 542 , 544 , 546 are stored in the child state ( 554) and stored. Also, the root state 552 and the child state 554 may be combined and represented as the overall state 550 .

In an embodiment, the block states of the database 500 may be managed using a sharding method. The block states are configured in a tree structure as a whole, and some of the block states (ie, subtrees) of the tree structure can be maintained and managed by one shard. In the embodiment of FIG. 5 , a child state 554 among all states 550 may be managed as one shard. Accordingly, the blocks 542 , 544 , 546 of the lower level 540 corresponding to the child state 554 may also be managed as shards. A shard configured in this way can perform verification of blocks belonging to it. In general, the PoW (Proof of Work) consensus method may be difficult to apply to a blockchain managed by sharding because the amount of computation required to attack or hack each shard is significantly smaller than the amount of computation required to attack all blocks. Therefore, a PoS consensus method may be used for each shard in this embodiment.

In an embodiment, a top-level consensus rule (Genesis Rules) may be applied to the root blocks 510 , 520 , and 530 , and the top-level consensus rule is stored in a block 510 located at the forefront of a chain of root blocks. can be In addition, each of the blocks corresponding to the sub-tree of block states managed by shards can apply their own consensus rules. As such, the consensus rule applied to the subtree of block states may be stored in the first location block 542 in the chain of child blocks 542 , 544 , and 546 .

As described above, by setting different consensus rules for each subtree of block states (eg, child state 554), it is possible to solve the trilemma problem of scalability. That is, the blockchain-based serverless computing system of the present disclosure may set various consensus rules to satisfy the scalability and security requirements of various types of applications. For example, if the application requires scalability, a simple PoS consensus rule can be used to maximize throughput, and if the application requires strong security, permissionless PoS Rules can be used, and when an application requires more decentralization, a new consensus rule can be adopted and applied.

6 is a flowchart illustrating a process of serverless computing based on a blockchain according to an embodiment of the present disclosure. The process 600 may begin with a step S610 of receiving, by the blockchain server, a transaction from one or more clients.

A client (or dApp) creates a transaction, and the transaction can be sent to a blockchain server and stored in a database. In addition, the blockchain server can set the authority to change the block state of the database, and set the function to be executed when the block state is changed. When a transaction is received from one or more clients, the blockchain server changes the block state of the database according to the transaction (S620). Transaction data may include path (key)-value pairs, and the block state reflecting the transaction may be configured in a tree structure.

Next, the state listener detects a block state change (S630). The state listener monitors the blockchain server to determine if the block state changes. When the state listener detects a block state change, it notifies the worker of the function execution according to the block chain state change (S650). The state listener sends an event (or trigger) according to the block state change to the worker, and the worker executes a function according to the block state change according to the received event.

A transaction representing the result of executing the function of the worker may be transmitted to the block chain server (S660). A worker may also create additional transactions as a result of executing a function. Additional transactions generated by the worker can be updated back to the block state stored in the database of the blockchain server, and the client gets the result through the changed blockchain state.

7 is a flowchart illustrating a transaction execution and block generation process according to an embodiment of the present disclosure. The process 700 of executing a transaction and generating a block begins with the block chain server receiving the transaction generated by the client ( S710 ).

A blockchain server may include a database containing block states and a transaction pool for storing transactions. When the blockchain server receives the transaction, the first node verifies and executes the transaction (S720).

The first node may verify and execute the transaction before the transaction is added to the transaction pool. To this end, the first node may verify the transaction by using a signature that guarantees that the transaction has been transmitted by the client and a rule that checks whether the transaction violates the permission authority. Also, the first node may complete the execution of the transaction by updating the transaction data (eg, path-value pair) to the block state. Whether to update the transaction data in the block state may be determined by a value indicating the reliability of data included in the transaction.

When transaction verification and execution are completed, the corresponding transaction is added to the transaction pool (S730). Thereafter, the second node creates a block for the transaction in the transaction pool and connects to the block chain (S740). The second node executes the validation of the transaction taken from the transaction pool, creates a block containing the transaction, and connects the block to the blockchain. The second node propagates the generated block to the first nodes in the blockchain network (S750). Based on the propagated block, the first node compares the current state with the state it has, and if there is a state that does not match, it modifies the block based on the corresponding block.

The components and methods of the above-described apparatus or system may be implemented as computer-readable codes on a computer-readable recording medium. The computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, and optical data storage device. Further, the computer-readable recording medium is distributed over a computer system connected through a network, so that computer-readable codes can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the above embodiments can be easily inferred by programmers in the technical field to which the present invention pertains.

The techniques described herein may be implemented by various means. For example, these techniques may be implemented in hardware, firmware, software, or a combination thereof. Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

In a hardware implementation, the processing units used to perform the techniques include one or more ASICs, DSPs, digital signal processing devices (DSPDs), programmable logic devices (PLDs). ), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein; It may be implemented in a computer, or a combination thereof.

Accordingly, the various illustrative logic blocks, modules, and circuits described in connection with the present disclosure are suitable for general purpose processors, DSPs, ASICs, FPGAs or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or It may be implemented or performed in any combination of those designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, eg, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

For firmware and/or software implementations, the techniques include random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), PROM ( on computer-readable media such as programmable read-only memory), erasable programmable read-only memory (EPROM), electrically erasable PROM (EEPROM), flash memory, compact disc (CD), magnetic or optical data storage devices, etc. It may be implemented as stored instructions. The instructions may be executable by one or more processors and may cause the processor(s) to perform certain aspects of the functionality described herein.

If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. Storage media may be any available media that can be accessed by a computer. By way of non-limiting example, such computer-readable medium may contain RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or desired program code in the form of instructions or data structures. may include any other medium that can be used for transport or storage to a computer and can be accessed by a computer. Also, any connection is properly termed a computer-readable medium.

For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, wireless, and microwave, the coaxial cable , fiber optic cable, twisted pair, digital subscriber line, or wireless technologies such as infrared, radio, and microwave are included within the definition of a medium. As used herein, disk and disk include CD, laser disk, optical disk, digital versatile disc (DVD), floppy disk, and Blu-ray disk, where disks are usually magnetic Data is reproduced optically, while discs reproduce data optically using a laser. Combinations of the above should also be included within the scope of computer-readable media.

A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor such that the processor can read information from, or write information to, the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and storage medium may reside within the ASIC. The ASIC may exist in the user terminal. Alternatively, the processor and the storage medium may exist as separate components in the user terminal.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to various modifications without departing from the spirit or scope of the disclosure. Accordingly, this disclosure is not intended to be limited to the examples set forth herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Although example implementations may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more standalone computer systems, the subject matter is not so limited, but rather in connection with any computing environment, such as a network or distributed computing environment. may be implemented. Still further, aspects of the presently disclosed subject matter may be implemented in or across a plurality of processing chips or devices, and storage may be similarly affected across the plurality of devices. Such devices may include PCs, network servers, and handheld devices.

Although subject matter has been described in language specific to structural features and/or methodological acts, it will be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts set forth above. Rather, the specific features and acts described above are set forth as example forms of implementing the claims.

Although the method mentioned in this specification has been described through specific embodiments, it may be implemented as computer-readable code on a computer-readable recording medium. The computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, and optical data storage device. Further, the computer-readable recording medium is distributed over a computer system connected through a network, so that computer-readable codes can be stored and executed in a distributed manner. And, functional programs, codes, and code segments for implementing the embodiments can be easily inferred by programmers in the art to which the present invention pertains.

Although the present disclosure has been described with reference to some embodiments herein, it should be understood that various modifications and changes may be made without departing from the scope of the present disclosure as understood by those skilled in the art to which the present invention pertains. something to do. Further, such modifications and variations are intended to fall within the scope of the claims appended hereto.

110: blockchain server 112: database
120: status listener 130: walker
140: client

Claims (11)

In a blockchain-based serverless computing system,
a blockchain server for storing and managing a database including a plurality of block states updated according to one or more transactions related to functions received from a client;
a state listener for monitoring whether the state of the plurality of blocks is changed; and
a worker executing a function according to a change in the state of the plurality of blocks;
Including,
The state listener detects a change in the block state and notifies the worker of the function execution according to the change in the plurality of block states, the worker executes the function according to the function execution notification,
The transaction includes one or more key-value pairs of a target node path value for an operation (key) and a target value of a state update (value),
The block state consists of a tree structure reflecting one or more key-value pairs of the transaction,
A serverless computing system based on blockchain.
The method of claim 1,
The block chain server sets the authority to change the block state of the database, and sets a function to be executed when the block state is changed,
A serverless computing system based on blockchain.
delete The method of claim 1,
The blockchain server is
The plurality of block states are configured in a tree structure including a plurality of subtrees,
A different consensus rule can be applied to each of the subtrees of the plurality of block states,
A serverless computing system based on blockchain.
The method of claim 4,
Applying a shard to each subtree of the plurality of block states,
The shard processes each of the subtrees in a blockchain instance,
A serverless computing system based on blockchain.
The method of claim 1,
The transaction includes a lead control,
The lead control indicates a suitable time for the transaction to be utilized, including executing the worker based on the transaction.
A serverless computing system based on blockchain.
The method of claim 1,
The blockchain server further includes a transaction pool that stores the transaction before the transaction is created as a block,
The system,
a first node that verifies the transaction before storing the transaction in the transaction pool and reflects it in the block state; and
a second node generating a block including the transaction by executing validation of the transaction stored in the transaction pool;
Further comprising,
A serverless computing system based on blockchain.
In the blockchain-based serverless computing method,
updating, by the blockchain server, when one or more transactions associated with a function are received from the client, the block state of the database according to the transactions;
monitoring whether the block state is changed by a state listener;
when the state listener detects a change in the block state, notifying a worker to execute a function according to the change in the state of the block chain; and
sending, by the worker, a transaction representing the result of the worker executing the function to the blockchain network;
Including,
The transaction includes one or more key-value pairs of a target node path value for an operation (key) and a target value of a state update (value),
The block state consists of a tree structure reflecting one or more key-value pairs of the transaction,
Way.
The method of claim 8,
The method further comprising, by the blockchain server, setting the authority to change the block state of the database, and setting a function to be executed when the block state is changed.
The method of claim 8,
When, by the blockchain server, one or more transactions are received from the client, updating the block state of the database according to the transaction comprises:
adding the transaction to a transaction pool before the transaction is created as a block;
before the transaction is stored in the transaction pool, by the first node, verifying the transaction and reflecting it in the block state;
generating, by a second node, a block including the transaction by executing validation of the transaction stored in the transaction pool; and
applying the block generated by the second node to the block state of the first node so that consistency of the blockchain network is maintained
Including, the method.
A computer-readable storage medium storing one or more programs configured to be executed by one or more processors of a computing device, comprising:
The one or more programs, a computer-readable storage medium comprising instructions for performing the method of any one of claims 8 to 10.

Images