Computer-implemented method and system for controlling tasks implemented by cyclically ordered node sets participating in block chain network

Abstract

The invention discloses a method for controlling and coordinating processing steps in a distributed system. The method may be implemented by nodes in a cyclically ordered set of nodes participating in a blockchain network. The method includes receiving, from an immediately following node, a value corresponding to a combination of possible final results of processing steps associated with a node from the node to a node immediately preceding a supervising node. The value is based on a public key associated with the node and a public key of a supervising node corresponding to possible outputs. State values are generated based on the values and the public keys corresponding to the possible final results with respect to the processing steps of the node, and are shared with the supervising node and immediately preceding nodes. A blockchain transaction is prepared to transmit control of the resource from the node to the immediately following node after provisioning one of the set of unlock values corresponding to the received value.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201980027203.0 (PCT international application number PCT / IB2019 / 052946), application date April 10, 2019, and name “Computer-implemented method and system for controlling tasks performed by a set of circularly sorted nodes participating in a blockchain network”. Technical Field

[0002] The present application generally relates to decentralized computing systems. In particular, the present invention relates to the control and coordination of processing steps associated with nodes of a distributed computing system, including the use of a blockchain network to direct and control sequenced processing steps. The present invention also relates to resource allocation within a distributed computing system and network, and the use of cryptographic techniques and mechanisms to implement and enforce such resource control and allocation, and hierarchical organization and configuration of entities / nodes within the system. Background Art

[0003] Distributed systems have many advantages, including resistance to potential attacks, sharing of resources and results, etc. In a distributed computing system, various computing devices acting as nodes in the distributed system can communicate through a network. Such nodes can exchange messages. (For example) through message exchange, nodes can cooperate with each other to perform computing tasks. Such tasks may involve distributed processing across various nodes. Such distributed processing may require control and coordination of steps associated with various nodes. For example, a specific processing order may be implemented.

[0004] An example of a distributed system is a self-driving car. For example, a self-driving car may include various modules, each with its own sensor data. Each of these modules is responsible for performing a specific processing step. In addition, the self-driving car may negotiate with one or more internal nodes or external nodes to perform certain processing (e.g., related to vehicle control). For example, the external node may be based on a network or cloud.

[0005] In such distributed systems, it may be necessary or desirable to order the steps in a processing task. For example, a node may need to perform processing steps in order. These processing steps can then be combined into one of many possible outcomes of the task. Other technical challenges common to distributed systems include the difficulty of allocating resources within a network or system, and how to organize the actors (i.e., nodes) and the communications between them in an efficient and reliable manner. There are also challenges in the organization and hierarchical considerations of nodes within a distributed system. It is advantageous to use mathematical and cryptographic techniques to implement and determine the hierarchical configuration and control flow within a distributed system. This will provide benefits related to the security and automation of the program.

[0006] Typically, attempts to build protocols that provide online voting or decision making follow an "abuse-resistant, but dependent on a central authority" approach to verify and account for votes or feedback. The central authority can use various cryptographic primitives such as blind signatures and homomorphic encryption to add confidentiality and fitness for purpose verification in voting - see R. Riemann and S. Grumbach, "Distributed Protocols for Rescue Mode for Trusted Online Voting", available via arXiv preprint arXiv:1705.04480. For example, a centralized voting protocol is described by DL Chaum (1981), "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms", Communications of the ACM 24(2), pp. 84-90. In Chaum's protocol, participants send their votes to a centralized hybrid authority, which uses a hybrid network setup to reconfigure and encrypt the votes before broadcasting them, in order to disguise the vote-voter link.

[0007] Other early work dispensed with the need for a central trusted authority and relied instead on collaboration among participants, for example, AC Yao (November 1982), "Protocols for Secure Computation," in the 23rd Annual Symposium on Introduction to Computer Science (SFCS'08, 1982), pp. 160-164.

[0008] We describe a secure multi-party computation protocol that aims to enable a group of users to compute a joint private input function that they wish to keep secret without requiring a trusted third party. Secure multi-party computation allows the parties to jointly compute their average vote privately and securely, but in turn relies on collaboration between the parties.

[0009] Fundamentally, each of the aforementioned early works was intended for independent selection, not dependent selection, let alone for performing processing steps in a specified order to achieve a result.

[0010] In view of the above, one of the technical problems faced is how to provide a solution to allow and enforce the ordering of processing steps by nodes in a distributed system. Another technical problem may be how to provide a tamper-proof or tamper-resistant record of the results generated by this ordering process in the distributed system. Other technical problems may be how to use cryptographic techniques to enforce control and / or hierarchy and permissions (e.g., access permissions) within the distributed system.

[0011] Solutions to one or more of the aforementioned technical problems may involve the use of blockchain. As used herein, the term "blockchain" encompasses all forms of computer-based electronic distributed ledgers. Such ledgers include consensus-based blockchain and transaction chain technologies, permissioned and unpermitted ledgers, shared ledgers, and variations thereof. It should be noted that the subject matter of this application is not limited to the use of a particular blockchain, and alternative blockchain implementations and protocols are within the scope of this application.

[0012] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized computer-based system composed of blocks, which in turn consist of transactions. Each transaction is a digital structure that encodes the transfer of control of digital assets between addresses in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, which allows blocks to be linked together to create an immutable, permanent record of all transactions written to the blockchain from the beginning.

[0013] Blockchain can be used in a wide range of applications. For example, blockchain can be used to provide a ledger that reflects the ownership of one or more commodities. Some such commodities may represent underlying units, such as units of computing resources. Summary of the invention

[0014] According to the present application, there is provided a method and a system as described in the accompanying claims.

[0015] The present invention may provide a computer-implemented method for distributed control. The method may include receiving, by a particular node in a set of circularly ordered nodes participating in a blockchain network, values ​​corresponding to a combination of possible final results of processing steps from a node immediately following the particular node. These processing steps are associated with nodes located in the range of "the node immediately following to the node immediately preceding the supervisory node". These values ​​may be based on public keys associated with the nodes (each public key corresponding to a possible final result of the processing steps associated with the node) or on public keys of supervisory nodes. The method may include generating, by the particular node, a state value based on the received value and the public key corresponding to the possible final result of the processing step associated with the particular node. The method may include the particular node sharing the state value with the supervisory node and the node immediately preceding the particular node. The method may include preparing, by the particular node, a blockchain transaction using the state value, the blockchain transaction being configured to transfer control of a resource of a source address associated with the particular node to a receiving address of an immediately subsequent node, the subsequent node responding to satisfying an execution condition, including providing any one of a set (or multiple) of unlock values ​​corresponding to the received value.

[0016] The present invention may also provide a computer-implemented method for distributed control, comprising: receiving, through a specific node in a circularly sorted node set participating in a blockchain network, a plurality of values ​​corresponding to a plurality of combinations of possible final results of a plurality of processing steps associated with a plurality of nodes from a node immediately following the specific node, the plurality of nodes ranging from the node immediately following to a node immediately preceding a supervisory node, wherein the plurality of values ​​are based on a plurality of public keys associated with the plurality of nodes, each of the plurality of values ​​corresponding to a possible final result of a processing step associated with the node, and the plurality of values ​​are based on a public key of the supervisory node; generating, through the specific node, a plurality of status values ​​based on the received plurality of values ​​and a plurality of public keys corresponding to possible final results of the processing steps associated with the specific node; sharing the status values ​​with the supervisory node and with a node immediately preceding the specific node through the specific node; and transmitting control of resources between nodes in response to satisfying corresponding execution conditions and fallback conditions.

[0017] In some embodiments, control of a resource may be returned when return conditions are met.

[0018] In some embodiments, the fallback condition may require signatures from at least two nodes.

[0019] In some embodiments, the nodes may correspond to modules associated with a system, and the possible end results of the processing steps associated with a given node may correspond to relevant modules of the control system of the system.

[0020] In some embodiments, each received value may be determined by combining a public key associated with the supervisory node and a plurality of public keys corresponding to one of the respective combinations of possible end results of a processing step associated with a node in the range of "the node immediately following to the node immediately preceding the supervisory node".

[0021] In some embodiments, a given certain received value may be determined by summing a plurality of public keys associated with the supervisory node and a public key corresponding to a final result of one of the corresponding combinations of possible final results.

[0022] In some embodiments, the state value may be derived by combining the received value with a public key corresponding to a possible end result of a processing step associated with a particular node.

[0023] In some embodiments, the state value may be derived by summing one of the received values ​​and one of the public keys corresponding to the possible end results of the processing step associated with the particular node.

[0024] In some embodiments, another blockchain transaction may be configured to return control of the second resource to a specific node when the return condition is met. In some embodiments, the method may further include waiting for the blockchain transaction to execute, and obtaining a first unlock value from the transaction for unlocking the transaction, the first unlock value indicating the output of the processing step associated with the nodes in the range of "the node immediately following to the node immediately preceding the supervisory node", and based on the private keys corresponding to the plurality of public keys in the public keys associated with the nodes, and the private key corresponding to the output.

[0025] The method may include identifying one of the possible final results of the processing step associated with the particular node. The method may include determining, by the particular node, a second unlock value based on a private key corresponding to a public key corresponding to the identified final result and the unlock value. The second unlock value may correspond to one of the state values ​​and may indicate an output of the processing step associated with a node within a range from the particular node to a node immediately preceding the supervisory node. The method may include performing another blockchain transaction using the second unlock value.

[0026] In some embodiments, another blockchain transaction may be prepared by an immediately preceding node, the blockchain transaction being configured to transfer control of a second resource of a source address associated with the immediately preceding node to a receiving address of a specific node, the specific node responding to satisfying the execution condition, including providing any one of a second set (another set) of unlock values ​​corresponding to one of the state values. The blockchain transaction "being configured to transfer control of a resource of a source address associated with a specific node to a receiving address of an immediately succeeding node" may be prepared after preparing another blockchain transaction.

[0027] In some implementations, each unlock value in the second (another) set of unlock values ​​may correspond to a respective state value, and may be based on a private key corresponding to a public key on which the state value is based.

[0028] In some embodiments, the unlock value can be the sum of the following private keys: the private key corresponding to the output of the processing step associated with the node located in the range from the immediately next node to the immediately previous node of the supervisory node, and the private key corresponding to the public key associated with the supervisory node.

[0029] In some embodiments, the second unlock value can be the sum of the following private keys: the private key corresponding to the output of the processing step associated with the node located in the range of "from a specific node to the node immediately before the supervisory node" and the private key corresponding to the public key associated with the supervisory node.

[0030] In some embodiments, the resource and the second resource may be identical.

[0031] In some implementations, each public key and its corresponding private key may form an elliptic curve cryptography public-private key pair.

[0032] The present invention may also provide a computer-implemented system capable of implementing the above method.

[0033] The present invention may also provide a non-transitory computer-readable storage medium storing instructions for adapting a computer system to execute the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Any features described in relation to one aspect or embodiment of the invention may also be used in relation to one or more other aspects / embodiments. The above and other aspects of the invention will become apparent from the detailed description of the embodiments of the invention hereinafter. Embodiments of the invention are described in detail below by way of example only with reference to the accompanying drawings, in which:

[0035] Figure 1 Display transactions used in payment channels;

[0036] Figure 2 To illustrate how Figure 1 Flowchart for creating a payment channel;

[0037] Figure 3 A simplified schematic diagram for illustrating the operating environment of the present application example;

[0038] Figure 4 A simplified schematic diagram for illustrating another example operating environment of the present application;

[0039] Figure 5 For example, computing device;

[0040] Figure 6 A graph illustrating a circular sorted set of nodes;

[0041] Figure 7 The decision tree corresponding to the instance processing task is shown;

[0042] Figure 8 Explains the Figure 7 The private key associated with a specific edge of the decision tree;

[0043] Fig. 9 Description and Figure 8 The private key of Figure 7 The public key value associated with a specific edge of the decision tree;

[0044] Fig.10 To illustrate the Figure 6 A flowchart of the operations performed by a specific node in ;

[0045] Fig.11A diagram for illustrating an example payment channel of the present application;

[0046] Fig.12 To illustrate how to create Figure 1 Flowchart of the payment channel;

[0047] Fig.13 To illustrate the Figure 6 A flowchart of the operations performed by the nodes; and

[0048] Fig.14 To illustrate the Figure 6 A flowchart of the operations performed by a specific node.

[0049] Like reference numbers in the drawings are used to indicate like components and features. DETAILED DESCRIPTION

[0050] In the present application, “and / or” is intended to cover all possible combinations and sub-combinations of the listed elements, including only one of the listed elements alone, any sub-combination and all elements, and does not necessarily exclude other elements.

[0051] In the present application, the phrase "at least... or one of..." is intended to cover any one or more of the listed elements, including only one of the listed elements, any subcombination or all of the elements, and does not necessarily exclude any other elements, and does not necessarily require all elements.

[0052] A protocol embodying the present invention is described herein for a group of cooperating nodes to make decisions in an ordered fashion, each based on the concept of requiring nodes to commit units of computational resources that can only be recovered by those nodes using accumulated secret values ​​derived from the output of previous steps in a processing task.

[0053] The protocol described in this article is based on existing payment channels and in particular incorporates the use of refund transactions.

[0054] Payment Channels

[0055] As mentioned above, the following description involves payment channels, so for the convenience of readers' understanding, an overview of payment channels is provided.

[0056] Payment channel technology is designed to enable parties to trade multiple resources without submitting all transactions to the blockchain. In a typical payment channel implementation, an almost unlimited number of payments can be made, but only two transactions need to be added to the blockchain.

[0057] In addition to reducing the number of transactions added to the blockchain and the associated costs, payment channels also have the advantage of speed and, more importantly, allow parties to receive refund units if a transaction does not proceed as planned or if either party decides that the transaction should not exceed a certain payment set. An overview of payment channel implementation is provided below.

[0058] Consider a scenario where Alice needs to transfer blockchain resources to Bob. In this scenario, Alice may need to make multiple payments to Bob over a period of time. To facilitate this, a payment channel is established between Alice and Bob, and the following operations are performed:

[0059] First, Alice creates a 2 / 2 multi-signature payment to script hash (P2SH) transaction T c , the transaction is controlled by both Alice and Bob. At this point, the transaction will not be submitted to the network (this multi-signature address requires 2 people (Alice and Bob) to cryptographically sign any transaction spent at this address);

[0060] Next, Alice creates a separate refund transaction T r,0 , this refund transaction returns all units of multi-signature controlled funds to Alice. This transaction includes a nLockTime value of 100 blocks (nLockTime is a transaction parameter that allows transactions to be executed only after a specified time has passed). Bob signs the transaction. If there is a problem with the exchange between Alice and Bob, this refund transaction allows Alice to get a refund after nLockTime has passed.

[0061] Next, Alice sends the original transaction T c Sign.

[0062] At this point, Alice and Bob can continue to create new refund transactions to reflect the (off-blockchain) transfers made by Alice to Bob. These refund transactions will reflect the net amount of resources that Alice needs to transfer to Bob at that point in time. For each new refund transaction, if both parties agree on the details, the transaction is signed, but not necessarily submitted to the network.

[0063] It should be noted that each subsequent refund transaction is created with a smaller nLockTime than the previous refund transaction - that is, nLockTime(T r,i+1 ) <nLockTime(T r,i ).

[0064] If a participant refuses to r,i , then the victim can submit only Tr,i-1 In the worst case, Alice has r,0 Sign it and submit it to the network, thereby reclaiming all its units (after nLockTime expires).

[0065] The final refund transaction constructed represents the net sum of units transferred from Alice to Bob. This transaction is submitted to the network.

[0066] Figure 1 Shows transaction T used in payment channel c 100A and T r,n 100D. M represents the maximum amount that can be sent from Alice to Bob. x i is the current net sum of units that Alice needs to pay to Bob. stop is nLockTime with respect to the initial Refund transaction. n is the number of Refund transactions created by ongoing (out-of-block) transfers between Alice and Bob (this number excludes the initial Refund transaction). s is the time allotted to the parties (Alice and Bob) to agree to a Refund transaction before one of them risks the other submitting a previous Refund transaction, effectively closing the exchange between Alice and Bob.

[0067] Note: t+n*s stop , where t is the current time, and (S stop –n*s)≥s.

[0068] Figure 1 Transaction T in c 100A, T r,0 100B, T r,1 100C and T r,n 100D is a transaction that may appear on the blockchain.

[0069] Figure 2 The operations for establishing a payment channel between Alice and Bob are shown in flowchart 200 of . Operations 210 and onward are performed by one or more processors of one or more computing devices executing software including computer executable instructions that may be stored on a computer readable storage medium.

[0070] At operation 210, the processor of the computing device associated with Alice creates a 2 / 2 multi-signature pay-to-code-hash (P2SH) transaction T according to the method described above. c .

[0071] ​From operation 210, control proceeds to operation 212. At operation 212, the processor of the computing device associated with Alice creates an independent refund transaction T according to the manner described above. r,0 , in order to return all units of multi-sig controlled funds to the account associated with Alice.

[0072] From operation 212, control proceeds to operation 214. At operation 214, a processor of a computing device associated with Alice signs the refund transaction.

[0073] From operation 214, control proceeds to operation 216. During operation 214, the processor of the computing device associated with Bob may also sign the refund transaction. If the transaction is so signed, control proceeds to operation 218. If the transaction is not so signed, creation of the payment channel is aborted.

[0074] In performing operation 218, the processor of the computing device associated with Alice processes T c The signature is performed and submitted to the blockchain. Then, the control flow advances to operation 220.

[0075] At operation 220, the refund transaction is identified as a first refund transaction so that further transfer from Alice to Bob can be negotiated if time permits.

[0076] From operation 220, control proceeds to operation 222. At operation 222, it is determined whether the remaining time is sufficient to negotiate another transfer. If the remaining time is insufficient, control proceeds to operation 224, where the final refund transaction is submitted to the blockchain. If the remaining time is sufficient, control proceeds to operation 226.

[0077] At operation 226, further transmissions between Alice and Bob are negotiated. From operation 226, control proceeds to operation 228, where it is determined whether the negotiation was successful. If the negotiation failed, control proceeds to operation 224 as described above. If the negotiation was successful, control proceeds to operation 230.

[0078] When performing operation 230, a new refund transaction reflecting the successfully negotiated agreement is created according to the above-described method. Subsequently, the control flow advances to operation 240, at which time the new refund transaction is identified as the current refund transaction.

[0079] From operation 240, control proceeds to operation 242, where the processors of the computing devices associated with Alice and Bob may sign the current refund transaction. If the transaction is so signed, control returns to operation 222 as described above. If the transaction is not so signed, identification of the current refund transaction is restored to the previous refund transaction in operation 244. From operation 244, control returns to operation 222 as described above.

[0080] Figure 3 Shown is an example operating environment of the present application.

[0081] As shown, multiple nodes 300 communicate via a computer network 310. Each node 300 is a computing device that participates in a blockchain and has one or more associated addresses. In these addresses, the blockchain reflects the number of units, such as units of computing resources.

[0082] The various nodes 300 may perform processing steps in a distributed process, the outputs of which are combined to form a final result.

[0083] As further described below, the subject matter of the present application can be applied in a variety of situations. For example, Figure 4 A specific example operating environment of the present application is presented in the context of a system and, more particularly, an autonomous vehicle 400.

[0084] The autonomous vehicle 400 may rely on multiple modules for distributed processing. For example, the distributed processing may involve various nodes, such as a map module 410, a hospitality module 420, a weather module 430, and a traffic module 440. As shown, the modules 410 to 440 communicate via a network 450.

[0085] Some of these nodes may be integrated into the autonomous vehicle 400, and other of these nodes may be network or cloud based. For example, as shown, the map module 410 and the hospitality module 420 are integrated into the autonomous vehicle 400, while the weather module 430 and the traffic module 440 are remote from the autonomous vehicle 400.

[0086] The map module 410 may be a module for finding the shortest route. For example, the map module 410 may select the best route based on the distance.

[0087] The hospitality module 420 can select a route based on hospitality availability. For example, the hospitality module 420 can select the best route based on restaurant and hotel availability.

[0088] The weather module 430 can select a route based on the weather. For example, the weather module 430 can select an optimal route based on avoiding severe or inclement weather.

[0089] The traffic module 440 may select a route based on traffic conditions. For example, the traffic module 440 may select an optimal route based on avoiding traffic congestion.

[0090] Conveniently, the subject matter of the present application can be applied to allow modules 410 to 440 to collectively perform processing steps associated with a task associated with route selection for the autonomous vehicle 400, the outputs of which produce a particular result, namely a selected route. It is also worth noting that, as further described below, because the blockchain is used to record the outputs of the various processing steps and transmit such outputs between nodes, the outputs of modules 410 to 440 can be recorded in a manner that allows for future auditing and review (such as for fault determination after an incident involving the autonomous vehicle 400).

[0091] As described above, the subject matter of the present application may also be applied to other situations. For example, where the subject matter of the present application is applied to system control, the specific type of system being controlled need not be an autonomous vehicle. For example, the subject matter of the present application may be applied to allow modules such as those responsible for operating or controlling industrial equipment to jointly perform processing steps associated with the equipment. In a specific instance, such steps may correspond to decision or control points of an industrial procedure. In another example, the subject matter of the present application may be applied to the operation of a traffic control system, such as to allow modules of such a system to jointly perform processing steps associated with tasks such as controlling traffic signals.

[0092] return Figure 3 As mentioned above, each node in the node 300 is a computing device. Figure 5 500 is a high-level operational diagram of an example computing device. Example computing device 500 may be an example of one or more of the computer systems described herein, including, for example, one or more of nodes 300. Example computing device 500 includes software that makes it suitable for performing specific functions.

[0093] The example computing device 500 includes various modules. For example, as shown in the figure, the example computing device 500 may include a processor 510, a memory 520, and a network interface 530. As shown in the figure, the aforementioned components of the example computing device 500 communicate via a bus 540.

[0094] The processor 510 is a hardware processor. For example, the processor 510 may be one or more ARM, Intel x86, PowerPC processors, etc.

[0095] Memory 520 allows for storage and retrieval of data. For example, memory 520 may include random access memory, read-only memory, and permanent memory. For example, permanent memory may be flash memory, a solid-state drive, etc. Read-only memory and permanent memory are non-transitory computer-readable storage media. Computer-readable media may be organized using a file system, such as may be managed by an operating system that controls the overall operation of the example computing device 500.

[0096] The network interface 530 allows the example computing device 500 to communicate with other computing devices and / or other computing devices such as the computer network 310 ( Figure 3 ) to communicate through various communication networks.

[0097] The software including the instructions is executed by the processor 510 through the computer readable medium. For example, the software may be loaded into the random access memory from the permanent storage of the memory 520. Additionally or alternatively, the instructions may be executed by the processor 510 directly from the read-only memory of the memory 520.

[0098] As further described below, the software may adapt the example computing device 500 to function as one or more of the various computer systems mentioned herein, including, for example, one or more of the nodes 300 and / or one or more of the modules 410-440.

[0099] As further described below, in the protocol described herein, a node is responsible for executing the processing steps of the overall distributed computing task. Figure 6 In a particular example, the node 600 may be responsible for executing the processing tasks in sequence. One of the nodes acts as a supervisory node—for example, a node (node ​​U) in the node 600 0 ) can be the supervisory node—and the other nodes in the node are responsible for selecting options. The order of processing steps in the task can be used to implement a circular sorted set formed by the nodes. The circular sorted set can be viewed as a ring, where each node has two other nodes that are the immediately succeeding node (immediately successful node) and the immediately previous node (immediately previous node) of the node. For example, the circular sorted set of node 600 can be depicted as follows Figure 6 Guide ring 610 is shown.

[0100] For ease of reference, each unsupervised node of node 600 in pilot ring 610 is assigned a label U x , where x corresponds to the letters in the alphabetical order according to the expected order of steps in the processing task.

[0101] Estimated supervisory node U 0A node that is responsible for the execution of a given supervisory protocol. As described further below, a supervisory node acts as a protocol initiator and coordinator. In one example, a supervisory node is associated with a party that provides resources that will be allocated based on the results of a decision process.

[0102] Node 600 (supervisory and / or unsupervised) may be a node in node 300 and / or modules 410 to 440. In addition, a supervisory node U may be selected from node 300. 0 This selection may be performed in a variety of ways. For example, each of the nodes 300 may perform an operation or participate in a protocol that results in a particular node in the nodes being selected as a supervisory node. Alternatively, a node in the nodes 300 may be selected as a supervisory node by a central authority.

[0103] The protocol described herein facilitates the execution of distributed computing tasks by participating nodes 600, wherein the processing steps in the task correspond to the structure of a decision tree. An example of such a decision tree is shown in Figure 7 , which shows a decision tree 700. In decision tree 700, each level of the tree represents the result of processing performed by nodes participating in the protocol described herein, and in particular, one of nodes 300. In other words, each level of decision tree 700 corresponds to a "factor" in the final result of processing performed by the distributed system formed by nodes 600. Each node in nodes 600 at a given level of decision tree 700 corresponds to a combination of specific outputs of processing steps represented by higher levels of the tree (i.e., levels closer to the root). Each of the edges emerging from a node represents a possible result of processing associated with / performed by the node (a "choice") that a party may perform relative to the decision represented by the node.

[0104] There are n=3 steps (and 3 nodes) involved in the process in decision tree 700, where each node associated with the process produces one of each of m=2 options.

[0105] Generally speaking, each node U of the decision tree 700 a,i represents a node, a processing step, and a previous output (i.e., a specific combination of processing outputs corresponding to a higher level of the tree), where a represents the processing step performed by a specific node and i represents the output of the previous processing step in the tree. In a specific example, U B,2 Indicates that on one side U A A node that performs processing step B after identifying a specific output of processing step A.

[0106] The leaf nodes of decision tree 700 represent a possible final result set produced by a specific combination of the outputs of various processing steps. In other words, the outputs of the tasks associated with each of the nodes form a path in the decision tree toward the distributed processing result. It is worth noting that in the current protocol, it is different from the decision or voting protocol that determines the winner by most votes. The combination of the outputs of various processing steps determines which result is selected. More specifically, the output of a specific processing step is not a vote on a specific result, but rather reduces the possible results of distributed processing to a possible result set (i.e., all results of the child nodes of the corresponding node of the decision tree 700 along the branch corresponding to the selected output). Therefore, each processing step in the predetermined step sequence reduces the possible result set until only one possible result remains-the output of the distributed processing.

[0107] In a particular example, in decision tree 700, possible outcome O can be reached via a particular path indicated by a thicker arrow. 212 First, as shown in the figure, if U A Choosing option 2 limits the set of possible results to {O 211 ,O 212 ,O 221 ,O 222}. Next, if U B Selecting option 1 limits the set of possible results to {O 211 ,O 212}. Next, if U C Choosing option 2 limits the set of possible results to {O 212}.

[0108] There are time order issues for processing by nodes, consistent with the dependencies between steps in the tasks performed by the protocol described herein. Specifically, each node performs its corresponding processing steps in a predetermined order. For example, in decision tree 700, the predetermined order reflected in the tree hierarchy corresponds to Figure 6 The order shown, where U A in U B Before executing its associated processing steps, U B Again in U C before executing its associated processing steps.

[0109] Of course, decision tree 700 is an example, and the decision tree associated with a given deployment of the protocol described herein may vary. For example, there is no requirement for a 1:1 correspondence between processing steps and nodes. In a particular example, a party U may be called ATo perform processing step B and processing step A. Additionally or alternatively, some or all of these steps may have more (i.e., more than 2) possible outputs. Additionally or alternatively, different steps may have different numbers of possible options. Additionally, there may be more or fewer steps or nodes.

[0110] In the protocol described herein, for each processing step associated with a particular node, the node will generate a set of private keys corresponding to each possible final result that the given node may have for that processing step. Specifically, a party is required to select private keys corresponding to each option that the node may select in the case of each possible output combination of the previous processing steps that have been performed.

[0111] Illustrating decision tree 700 Figure 8 This illustrated example case is augmented with various private keys associated with each edge of decision tree 700. As described, the private keys may be indicated by subscripts that encode the early processing step outputs and the output of the processing (i.e., the "current" processing step) at the level associated with the particular private key. For example, in Figure 8 by U B the processing performed has two possible outputs corresponding to four possible final results. In a particular instance, one option for U B is to select option 1 after U A selects option 2. This selection corresponds to the private key k 21 .

[0112] At this stage, the nodes keep their respective private keys k secret.

[0113] The private keys k can be generated using techniques known to those of ordinary skill in the art. Additionally, various public key cryptosystems can be used. For example, elliptic curve cryptography (ECC) can be used. In a particular instance, elliptic curve cryptography can be used, and k and its corresponding public key P can be an elliptic curve cryptography public-private key pair such that P = kG, where G is a base point on the elliptic curve having order q: q×G = 0, where q is a large prime number and 0 < k < q. In a particular instance, the elliptic curve secp256k1 defined in the document "Standards for Efficient Cryptography 2 (SEC 2)" (Certicom Corp., January 27, 2010) can be used. In other words, each public key and its corresponding private key can form an elliptic curve cryptography public-private key pair.

[0114] After generating the private keys, values are generated based on the corresponding public keys.

[0115] First, the supervisory node generates a public / private key pair and shares the public key, which is indicated as Q s , with all nodes participating in the protocol described herein.

[0116] Next, each of the participating nodes generates a public key value corresponding to each of the private keys it previously generated. Fig. 9 , which shows a decision tree 900 corresponding to decision tree 700 but expanded to show the public key values ​​associated with a particular edge.

[0117] In particular, a public key value or state value is generated by combining the respective public keys corresponding to a plurality of previously generated private keys that are associated with an edge from the root of the tree to a given edge. In other words, each of the state values ​​is generated by combining the public key associated with a given one of the generated private keys (i.e., on an edge leading out of the node) with a public key value earlier in the tree (i.e., on an edge leading into the node). In the basic case (at the first level of the tree below the supervisory node), the state value can be generated by combining Q s The state value is generated with each of the public keys associated with the private key at that level.

[0118] In the case of elliptic curve cryptography, combinations can be generated by adding public keys. For example, a given public key can be added to a previously selected value. As mentioned above, in ECC, the public key P corresponding to the private key k is defined by P = k × G. Therefore, refer to Fig. 9 , when using ECC, it is possible that Q 2 =Q s +k 2 G. In another example, it is possible that Q 21 =Q 2 +k 21 G.

[0119] The supervisory node shares its public key Q with each of the other nodes participating in the protocol described in this article s Similarly, each node in the unsupervised node shares its state value with the node immediately preceding the node in the circular sorted set and the supervised node. In addition, each node in the unsupervised node shares the semantic meaning of the value (i.e., the corresponding final result) with the node immediately preceding the node in the circular sorted set and the supervised node.

[0120] It is worth noting that the final voter in the voting sequence (e.g. Figure 6 U C ) corresponds to the possible outcomes of the protocol described herein ( x ). The supervisory node can directly associate the new public key / address S with each result. x to other nodes participating in the protocol described in this article. This is equivalent to the set of pairs {(O x , S x )), where the set {O x} and set {S x} one-to-one correspondence. Public key S x The corresponding private keys may not belong to the supervisory node itself (i.e., the supervisory node may not know the corresponding private keys), but may be known to an independent entity whose task is to perform the work associated with a specific result. Conveniently, in this way, the corresponding public key S may be known to the supervisory node itself (i.e., the supervisory node may not know the corresponding private keys), but may be known to an independent entity whose task is to perform the work associated with a specific result. x The third party that holds the private key performs the subsequent steps.

[0121] Secret value sv x corresponds to each of the state values ​​(and therefore to each possible outcome).

[0122] Conveniently, in the case of using ECC, the secret value sv corresponding to a given selected value x The following is related to the selection value. First, as mentioned above, according to the homomorphic property of elliptic curve addition, E(m+n)=E(m)+E(n), where E is the function E(x)=xG. In addition, as mentioned above, when using ECC, the selection value Q is given. X By Q X =k s G+k A G+...+k x G is defined as s is the supervisory node corresponding to its public key Q s The private key (i.e., Q s =k s G). In other words, corresponding to the selected value Q x The private key sv x is the sum of the private keys k i +k i+1 +...+k x In the specific example associated with decision tree 700, sv 21 =k s +k 2 +k 21 And Q 21 =G×sv 21 .

[0123] The protocol described herein involves a payment channel circuit between participating nodes 600. In particular, as further described below, a payment channel is established between each node in the nodes 600 and its immediately preceding node to transfer computing resources from the node to its immediately preceding node. Figure 6 , a payment channel will be between each node in node 600 and its immediately preceding node, as indicated by the direction of the edge depicted between the nodes. The payment channel is configured to be unlockable by any of the secret values ​​corresponding to the state value of the immediately preceding node.

[0124] The use of a payment channel requires that a unit of computational resources be submitted to the channel. For example, in a payment channel loop, computational resources will be transferred from a node via each payment channel to the payment channel immediately following it.

[0125] Since the transfer of value is not critical to the protocol described herein, this amount may be a nominal amount. However, it is apparent that nodes are required to participate in selecting outcomes under the penalty of forfeiture of the value they submit to the payment channel. Therefore, nodes may also be required to submit a sufficient amount of computing resources to the payment channel to discourage frivolous participation and / or violation of the protocol described herein. The amount of computing resources submitted to the payment channel may be the same, or in other words, the resources submitted to the payment channel may be the same, where the resources are fungible resources.

[0126] Before constructing a payment channel for a circuit, nodes and especially supervisory nodes must comply with the following two values ​​in conjunction with other nodes participating in the protocol described in this article: a time point S and a time span s.

[0127] First, a time span s is selected, which represents the amount of time required for a node participating in the protocol described herein to complete certain operations described further below, namely, constructing a payment channel between the node and the immediately preceding node; retrieving a secret value that unlocks the previous payment channel in the loop; selecting one of the possible final results of the processing steps associated with the node; and submitting a payment transaction for another payment channel in favor of the node to the blockchain. If other users reach a consensus, any node can select the time s. In some embodiments, the supervisory node can select s that simplifies the protocol. The time s can be expressed in suitable units such as seconds or number of blocks.

[0128] Second, a value S is selected as the start time of the first transmission submitted to the node of the blockchain network. Any node can select S if other nodes reach a consensus. In some embodiments, the initiator selects S that simplifies the implementation of the protocol.

[0129] It is worth noting that S represents a time point, which can be specified, for example, in Unix time or block height, while s represents a time span.

[0130] Starting with the payment channel between the supervisory node and the new node immediately following it (i.e., the node responsible for making the final choice), the payment channel is constructed in a clockwise manner. Figure 6 , the first payment channel to be constructed is U 0 with U C The payment channel between them, and the final payment channel to be constructed is U A with U 0 payment channels between them.

[0131] This ordering sequence guarantees a node that there is a payment channel that benefits it before it commits resources to a payment channel that benefits the node immediately behind it. However, the supervisory node does not receive this guarantee because its private key k s is the component of all secret values ​​that can be unlocked for each of the various payment channels. However, since k s By keeping it secret at this stage, the supervisory node can safely create the first payment channel in the circuit without guaranteeing a payment channel in its favor. Specifically, if no payment channel in its favor has been created, the supervisory node can simply wait a sufficient period of time to submit a refund transaction for the payment channel it created.

[0132] Now refer to Fig.10 , Fig.13 and Fig.14 The example operations performed by the nodes participating in the protocol described herein are discussed in the series of flowcharts shown in FIG. In these flowcharts and the following description thereof, the n nodes participating in the circular ordered set of the protocol are identified as U 0 …U n-1 , in the order in which the various payment channels are constructed (i.e., in the reverse order of the steps in the intended process) 0 For example, if the expected order of processing steps is described as follows: Figure 6 In the counterclockwise direction shown in Fig.10 , Fig.13 and Fig.14 The node U referenced in 0 …U n-1 Sort in clockwise direction. In a specific instance, according to this number, if Figure 6 Marked as U B The node identification is U i , then U A ( Figure 6 ) is U i+1 And U C ( Figure 6 ) is U i-1 In other words, Fig.10 , Fig.13 and Fig.14 For the purpose of the flowchart shown in Figure 6 Marked as U B The node is considered to be immediately adjacent to node U A The node before and will be marked as U B The node is considered to be immediately adjacent to node U C The node after that.

[0133] Discuss Now Fig.10 . Fig.10 1000, which illustrates operations associated with operations of a particular node participating in the protocol described herein in preparing to create, and subsequently creating, a payment channel from the node to its immediately preceding node. Various non-supervisory participating nodes may perform operations corresponding to the operations described in flowchart 1000 when creating the above-described payment channel loop. Operations 1010 and onwards are performed by one or more processors of a particular non-supervisory node among the participating nodes. Thus, operations 1010 and onwards are performed by one or more processors of a computing device, such as processor 510 (eg, processor 510 of an appropriately configured example of example computing device 500). Figure 5 ), the one or more processors executing software comprising computer executable instructions as may be stored on a computer readable storage medium such as memory 520.

[0134] At operation 1010, the particular node receives a state value associated with the immediately following node from the node immediately following the particular node in the circular ordered set. Thus, due to the definition of the state value and the ordering of the nodes in the circular ordered set, the particular node receives a value corresponding to a combination of possible final results of processing steps associated with the nodes in the circular ordered set (e.g., pilot loop 610) from the immediately following node to the node immediately preceding the supervisory node. As described above, the state value is based on a public key associated with the node and the possible outputs of the processing steps associated with the node. For example, in the case of using ECC, the received state value can be determined by summing a public key associated with the supervisory node and multiple public keys in the public key corresponding to the particular final result, as described above.

[0135] After operation 1010 , control flow proceeds to operation 1020 .

[0136] At operation 1020, the particular node generates a state value for the node. In other words, the particular node generates a state value corresponding to an output that can be selected by the particular node. The state value is based on receiving the state value and a public key associated with the node (which corresponds to a private key k associated with the node). x Thus, the state value is generated based on the received value and the public key corresponding to the possible final result of the processing step associated with the specific node.

[0137] After operation 1020 , control flow continues to operation 1030 .

[0138] At operation 1030, the state value is shared with the supervisory node and with the node immediately preceding the particular node in the round-robin ordered set, as described above.

[0139] From operation 1030 , control proceeds to operation 1040 .

[0140] At operation 1040, a particular node may wait for a payment channel to be created in its favor by an immediately preceding node. To create the aforementioned payment channel, a variety of transactions are prepared, as described above. For example, a transaction T is prepared using the locked value of the payment channel. pay The transaction is arranged to transfer a resource (e.g., x units of computing resources) from a source address associated with the immediately preceding node to a receiving address of a particular node. According to the transaction, control of the resource is transferred in response to satisfying an execution condition, the execution condition comprising supplying an unlock value (sv) corresponding to any lock value (i.e., any state value). x ). Specifically, the unlock value corresponds to the corresponding state value and is based on the private key corresponding to the public key on which the selected value is based. For example, in the case of using ECC, the unlock value can be these private keys and the public key Q corresponding to the supervisory node s The private key k s Thus, a particular node may be waiting to create a blockchain transaction that was prepared by an immediately preceding node and that is configured to transfer control of a resource from a source address associated with the immediately preceding node to a receiving address of the particular node.

[0141] Next, the particular node prepares a second payment channel using the state value, and the second payment channel is created by the particular node to benefit the immediately following node. For example, the particular node may prepare the second payment channel after creating the payment channel in favor of it. Preparing the payment channel is similar to the description of the first payment channel above, including preparing a blockchain transaction configured to transfer control of the second resource from a source address associated with the particular node to a receiving address of the immediately following node. The payment channel is used to transfer control of the resource in response to satisfying an execution condition, the execution condition comprising supplying any (second) plurality of unlock values ​​corresponding to the received value.

[0142] Fig.11 Provide a U such as corresponding to the first and second payment channels a →U b Display 1100 of the payment channel.

[0143] As shown in the figure, the channel includes T c , T pay and T r These three transactions. It should be noted that σ(U x ) indicates U x The encrypted signature.

[0144] The T c A transaction represents the commit component of a payment channel. Here, through this transaction, U b Send / submit a specified number of units to be controlled by the following signatures: 2 / 2 multi-signature (Ub , U a ) or learn multiple secret values ​​{sv} (a) Any one of U a The encrypted signature.

[0145] The T r The transaction represents the return of a specified number of units (from the submitted transaction) to U b to become applicable for refunds submitted to the blockchain after the specified time has expired. r Set to return control of resources to a specific node U after the return condition of time expiration is met b In order to successfully execute this transaction, it is necessary to a and U b The encrypted signature.

[0146] The T pay The transaction will come from U b Submit a specified number of units of funds to be transferred to U a To successfully execute this transaction, multiple secret values ​​{sv} are required (a) (state value associated with the factor / level corresponding to the decision tree) and U a The encrypted signature.

[0147] Fig.12 FIG. 1200 is a flowchart illustrating how the node U b Create a node from this node to another node U b The operations performed when the payment is made are as described above. Operation 1210 and the operations onwards are performed by node U b Thus, operations 1210 and onward are performed by one or more processors of a computing device, such as processor 510 (eg, processor 510 of an appropriately configured example of example computing device 500). Figure 5 ), the one or more processors execute software comprising computer executable instructions as may be stored on a computer readable storage medium such as memory 520.

[0148] At operation 1210, U b Create and submit transaction T C . Transaction T C As described above.

[0149] From operation 1210 , control flow continues to operation 1220 .

[0150] At operation 1220, a refund transaction T is created. r . Transaction T r As mentioned above. ris created with a specified expiration time S+(a+1)s, where for the first payment transaction in the circuit (e.g., 0 to U C )a is 0 and is incremented for each payment channel after a payment transaction in the loop (e.g., a=0, 1, 2, 3, ...).

[0151] From operation 1220 , control flow continues to operation 1230 .

[0152] At operation 1230, U b Sign the refund transaction.

[0153] From operation 1230 , control flow continues to operation 1240 .

[0154] As mentioned above, another participant U in the payment channel a Also for refund transactions T r At operation 1240, determine U a Whether to refund the transaction T r If it is not signed, the payment channel creation has failed and is aborted. a For refund transactions T r If signed, control flow continues to operation 1250 .

[0155] At operation 1250, U b Create payment transaction T pay . Transaction T pay As described above.

[0156] From operation 1250 , control proceeds to operation 1260 .

[0157] At operation 1260, U b For payment transactions T C Sign it and submit it to the blockchain.

[0158] After operation 1260, control terminates and the payment channel has been created.

[0159] After the payment circuit has been completed, the participating nodes can choose options. By way of overview, a node participating in the protocol described herein chooses options and then cashes out T in favor of the node based on its selection. pay trade.

[0160] Fig.13For flowchart 1300, which illustrates operations 1310 and onward as performed by nodes participating in the protocol described herein when selecting a result. Thus, both operations 1310 and onward are performed by one or more processors of a computing device, such as processor 510 of a suitably configured example computing device 500( Figure 5 ), which execute software comprising computer-executable instructions stored on a computer-readable storage medium such as memory 520.

[0161] As described above, flowchart 1300 and its description employ notation consistent with that of flowchart 1000. In other words, starting from the self-supervised node U 0 onward, the nodes are numbered in the order in which the payment channels are constructed.

[0162] At operation 1310, a check is made to ensure that the remaining time is sufficient to complete the necessary steps in the protocol described herein. Specifically, the current time may be compared with the start time S of the first transmission to ensure that there is sufficient time such that the loop can be completed without any payment channels timing out. Specifically, it is determined whether t < S + s, where t is the current time.

[0163] If the check at operation 1310 fails, the protocol described herein is aborted. Otherwise, the control flow proceeds to operation 1320, in which the supervising node submits a T pay blockchain transaction in its favor. This has the side effect of displaying the value k s on the blockchain, as it is the value corresponding to Q s used to lock that particular payment channel.

[0164] After operation 1320, a counter i is initialized to correspond to the node associated with the first processing step, U n-1 - i.e., the first voting node. The control flow then continues to operation 1330, in which a loop check determines whether the nodes participating in the protocol have completed their associated processing steps and have determined a result. If so, the control flow terminates. Alternatively, if all processing steps have not been completed (e.g., on the first pass through operation 1330), the control flow continues to operation 1340.

[0165] At operation 1340, the unlock value sv i is extracted from the blockchain, i.e., from the payment transactions of the payment channel from U (i+1)mod n to U previous , and this unlock value sv previous is used in the payment transaction of the payment channel that has been submitted to the blockchain at operation 1320 or will be submitted as described below at operation 1350). Conveniently, since sv previousThe processing steps are sorted to extract blockchain transactions that are submitted only after the output has been recognized by the immediately following node (i.e., the node related to the previous processing step).

[0166] Starting from operation 1340, the control flow advances to operation 1350.

[0167] At operation 1350, node U i identifies one of the possible final results regarding the processing step related to this node. The node then determines the corresponding unlocking value by combining the value sv previous with the private key (k ijk ) corresponding to the public key, where the public key corresponds to the recognized output. For example, in the case of using ECC, U i determines the secret value sv ijk = sv previous + k ijk to determine the secret value sv ijk . It is worth noting that the reason it works is the definition and homomorphic properties of the multiple state values that lock multiple T pay transactions.

[0168] Regarding the execution of the processing step, the step can be executed in multiple ways by node 300. For example, if node 300 corresponds to a module of an autonomous vehicle, the processing step can be selected in a planned manner based on the input data provided to the node. The input data can include data received from a user via one or more input devices.

[0169] Starting from operation 1350, the control flow advances to operation 1360. At operation 1360, it is determined whether there is enough remaining time to complete the transaction. Specifically, it is determined whether t < S+(n - i)s is satisfied, where t is the current time and i is the index of the current node counted from the supervising node, the supervising node is 0, the node immediately following the supervising node (i.e., the node related to the last processing step) has an index of 1, and so on until the node related to the first processing step has an index of (n - 1), as described above.

[0170] Starting from operation 1360, if it is determined that the remaining time is sufficient, the control flow advances to operation 1380. Alternatively, if it is determined that the remaining time is not enough, the control flow advances to operation 1370.

[0171] At operation 1370, the situation of insufficient remaining time is handled by causing U i-1 to trigger the abortion of the protocol described herein by means of a refund transaction. Specifically, U i-1Submit the refund transaction in favor of the node immediately following the round-robin sorting node set to the blockchain, thereby starting to make it to the node that intends to perform the final processing step (i.e., the node immediately following the supervisory node) U 1 The procedure by which nodes submit their refund transactions to the blockchain.

[0172] At operation 1380 (when sufficient time remains), node U i It will be beneficial to its T pay Blockchain transactions are submitted to the blockchain, thereby transferring sv current Displayed on the blockchain.

[0173] After operation 1380, counter i is decremented to correspond to selecting the next node in the sequence, and control flow then returns to operation 1330 (as described above), executing a loop to handle the selection by the next node of the sequence.

[0174] Flowchart 1300 describes processing steps performed across nodes participating as a whole in a distributed computing task. Fig.14 1400, which illustrates operations performed by a particular node participating in the protocol described herein when performing operations related to processing tasks. Various non-supervisory participating nodes may perform operations corresponding to the operations described in flowchart 1400 when creating the above-mentioned payment channel circuit. Operation 1410 and the operations onward are all performed by one or more processors of a particular non-supervisory node among the participating nodes. Thus, operation 1410 and the operations onward are all performed by one or more processors of a computing device, such as processor 510 ( Figure 5 ), the one or more processors executing software comprising computer executable instructions as may be stored on a computer readable storage medium such as memory 520.

[0175] As mentioned above, flowchart 1400 and its description utilize notation consistent with that of flowchart 1000. In other words, the self-supervising node U 0 Starting from , the nodes are numbered in the order in which the payment channel is constructed.

[0176] First, the particular node must ensure that it waits for the immediately following node to make its choice. Thus, at operation 1410, the particular node waits for a blockchain transaction T associated with a payment channel from the particular node to the immediately following node. pay Execute, that is, unlock the blockchain transaction and submit it to the blockchain. After submitting the transaction to the blockchain, the control flow proceeds to operation 1420.

[0177] At operation 1420, the specific node extracts the blockchain transaction T detected at operation 1410 from the blockchain.pay Unlock value sv to unlock previous As mentioned above, the value sv previous represents the processing step whose output is related to the node selected before a particular node. Thus, the value sv previous represents the processing steps associated with the output of the node from the node immediately following to the node immediately preceding the supervisory node in the circular sorted set. In addition, as described above, the value sv previous is based on a private key that corresponds to a plurality of public keys associated with the node and corresponds to the aforementioned selected option previously selected or chosen by the node. In other words, sv previous The selected value corresponding to the immediately following node. For example, as described above, in the case of using ECC, the unlocking value may be the sum of the following private keys: the private key corresponding to the output of the processing step associated with the nodes from the immediately following node to the node immediately before the supervisory node in the circular sorted set; and the public key (Q s )'s private key (k s ).

[0178] Next, at operation 1430, the particular node identifies one of the possible final results of the processing step associated with the node in the manner described above. As described above, a node can identify an output in a variety of ways, such as in a programmatic manner based on inputs and / or states associated with the node. For example, some inputs can be received via an input interface, such as from a user.

[0179] From operation 1430 , control flows to operation 1440 .

[0180] As described above, the public key of a particular node corresponds to all possible final results of the processing tasks associated with the node. previous The unlock value is determined by the private key corresponding to the public key corresponding to the identified final result. For example, in the case of using ECC, the value can be combined by adding in the manner described above.

[0181] From operation 1440 , control proceeds to operation 1450 .

[0182] At operation 1450, the unlock value determined at operation 1440 is used to perform a transaction associated with the payment channel between the immediately preceding node and the specific node. Specifically, the specific node may use the unlock value determined at operation 1440 to convert the corresponding T pay The transaction is unlocked and the unlocked transaction is submitted to the blockchain. For example, T can be unlocked by submitting the unlock value to the unlock script of the transaction. payThe transaction is unlocked. Notably, as described above, unlocking the transaction for the unlock value determined at operation 1440 and submitting it to the blockchain has the side effect of displaying the unlock value on the blockchain.

[0183] After operation 1450, the selection by the particular node is complete.

[0184] The protocols described herein may be used in a wide variety of applications. For example, they may be used in autonomous vehicles, such as autonomous vehicle 400. In some such embodiments, the possible end results of the processing steps associated with a given node participating in the protocols described herein may correspond to the outputs of the relevant modules of the vehicle control system. For example, the outputs may be the outputs of modules 410 to 440.

[0185] When implementing the protocols described herein on a given blockchain, various implementation details may need to be considered. For example, it is possible that the ID associated with a transaction may change while the transaction remains valid. This may be referred to as the transaction malleability problem. This may present a problem in the implementation of protocols such as the protocols described herein that rely on payment channels, where refunds (T r ) and payment (T pay ) transactions can be implemented by referencing the identifier of a previous transaction. For more information on transaction malleability, see, for example, "The Who, What, Why and How of the Ongoing Transaction Malleability Attack" by Aaron van Wirdum (October 7, 2015). Transaction malleability can be eliminated by the SegWit fork, see, for example, "Segregated Witness Benefits" (updated on October 19, 2016).

[0186] It should be noted that the embodiments mentioned above illustrate rather than limit the subject matter of the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference numerals placed in brackets shall not be construed as limiting the scope of the claims. "Comprising" and "comprises" and the like do not exclude the presence of other elements or steps not listed in any claim or in the overall specification. "Comprises" as used in this specification means "comprising or consisting of...". A singular reference to an element does not exclude a plural reference to such elements, and vice versa. The subject matter of the invention may be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim enumerating several components, several of these components may be embodied by the same hardware item. The mere fact that certain measures are described in mutually different dependent claims does not indicate that a combination of these methods cannot be used to advantage.

Claims

1. A computer-implemented method for distributed control, comprising: Receiving, through a specific node in a set of circularly ordered nodes participating in a blockchain network, a plurality of values ​​corresponding to a plurality of combinations of possible final results of a plurality of processing steps associated with a plurality of nodes from a node immediately following the specific node to a node immediately preceding a supervisory node, wherein the plurality of values ​​are based on a plurality of public keys associated with the plurality of nodes, each value in the plurality of values ​​corresponding to a possible final result of a processing step associated with the node, and the plurality of values ​​are based on a public key of the supervisory node; generating, by the specific node, a plurality of state values ​​based on the received plurality of values ​​and a plurality of public keys corresponding to possible final results of the processing steps associated with the specific node; sharing the state value with the supervisory node and with a node immediately before the specific node through the specific node; and Control of resources is transferred between nodes in response to corresponding execution conditions and fallback conditions being satisfied.

2. The method according to claim 1, wherein: Return control of the resource when the return conditions are met.

3. The method according to claim 1, wherein: The return condition requires signatures from at least two nodes.

4. The method according to claim 1, wherein: The nodes correspond to modules associated with a system, and the possible end results of the processing steps associated with a given node correspond to outputs of the associated modules of the control system of the system.

5. A method according to any one of the preceding claims, wherein: Each of the received multiple values ​​is determined by combining a public key associated with the supervisory node and multiple public keys of the multiple public keys corresponding to a corresponding combination of the multiple combinations of possible final results of multiple processing steps, wherein the multiple processing steps are associated with multiple nodes from the immediately subsequent node to the node immediately before the supervisory node.

6. The method according to claim 5, wherein: A given value of the received plurality of values ​​is determined by summing the public key associated with the supervisory node and the plurality of public keys corresponding to the final result of a corresponding one of the plurality of combinations of possible final results.

7. A method according to any one of the preceding claims, wherein: The state value is formed by combining the received plurality of values ​​and the public key corresponding to a possible final result of a processing step associated with the particular node.

8. The method according to claim 7, wherein: The state value is formed by summing a value among the received plurality of values ​​and a public key among the plurality of public keys corresponding to a possible final result of a processing step associated with the particular node.

9. The method according to any one of the preceding claims, further comprising: Waiting for the blockchain transaction to be executed, and obtaining a first unlock value for unlocking the transaction from the transaction, wherein the first unlock value indicates that outputs of the plurality of processing steps are related to a plurality of nodes from the immediately succeeding node to the node immediately before the supervisory node, and are based on private keys corresponding to a plurality of public keys among the plurality of public keys related to the plurality of nodes and corresponding to the outputs; identifying one of a plurality of possible end results of a processing step associated with the particular node; determining, by the specific node, a second unlock value based on a private key corresponding to the public key and the unlock value, the public key corresponding to the identified final result, the second unlock value corresponding to one of the state values ​​and indicating outputs of a plurality of processing steps associated with a plurality of nodes from the specific node to the node immediately before the supervisory node; as well as Using the second unlock value, another blockchain transaction is performed.

10. The method according to claim 9, wherein: The other blockchain transaction is prepared by an immediately preceding node and is used to transfer control of a second resource from a source address associated with the immediately preceding node to a receiving address of the specific node in response to satisfying a second execution condition, the second execution condition comprising supplying any value of a second set of unlock values ​​corresponding to the state value, and wherein after preparing the other blockchain transaction, the blockchain transaction is prepared to transfer control of the resource from the source address associated with the specific node to the receiving address of the immediately succeeding node.

11. The method according to claim 10, wherein: Each unlock value of the second set of unlock values ​​corresponds to one of the state values ​​and is based on a private key corresponding to the public key on which the state value is based.

12. The method according to any one of claims 9 to 11, wherein: The unlock value is the sum of the private key corresponding to the output of the processing steps associated with the nodes from the immediately subsequent node to the node immediately before the supervisory node and the private key corresponding to the public key associated with the supervisory node.

13. The method according to any one of claims 9 to 12, wherein: The second unlock value is the sum of the private key corresponding to the output of the processing steps associated with the nodes from the specific node to the node immediately before the supervisory node and the private key corresponding to the public key associated with the supervisory node.

14. The method according to any one of claims 9 to 13, wherein: The resource is the same as the second resource.

15. A method according to any one of the preceding claims, wherein: The public key and its corresponding private key form an elliptic curve cryptography public-private key pair.

16. A computer-implemented system for performing the method according to any one of claims 1 to 15.

17. A non-transitory computer-readable storage medium storing instructions for adapting a computer system to perform the method according to any one of claims 1 to 15.

Images