COMPUTER-IMPLEMENTED METHOD AND SYSTEM FOR CONTROLLING TASKS PERFORMED BY A CYCLICLY ORDERED SET OF NODES PARTICIPATING IN A BLOCKCHAIN ​​NETWORK

Abstract

To provide a method of controlling and coordinating processing steps in a distributed system.SOLUTION: A method is implemented by a node in a cyclically-ordered set of nodes participating in a blockchain network. The method includes receiving, from an immediately subsequent node, values corresponding to combinations of possible outcomes of processing steps associated with nodes from that node through to a node immediately preceding a supervisor node. The values are based on public keys associated with nodes corresponding to possible outputs and the supervisor's public key. State values are generated based on the values and public keys corresponding to the possible outcomes further to a processing step of the node and are shared with the supervisor and an immediately previous node. A blockchain transaction is prepared to transmit control of a resource from the node to the immediately subsequent node upon supply of one of a set of unlocking values corresponding to the received values.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] This application relates generally to distributed computing systems and, more particularly, to the control and coordination of processing steps associated with nodes of a distributed computing system, including directing and controlling the sequence of processing steps using a blockchain network. The invention also relates to the allocation of resources within distributed computing systems and networks, and the use of cryptographic techniques and mechanisms for implementing and enforcing such resource control and allocation, and for the hierarchical organization and arrangement of entities / nodes within the system. [Background technology]

[0002] The advantages of distributed systems are many, including resilience against potential attacks, sharing of resources and effort, etc. In a distributed computing system, various computing devices acting as nodes in the distributed system may communicate via network messages that may be exchanged between these nodes. Through such exchange of messages, for example, the nodes may cooperate to perform computational tasks. Such tasks may include processing that is distributed across various nodes. Such distributed processing may require control and coordination of steps associated with various nodes. For example, a particular processing order may be enforced.

[0003] One example of a distributed system may occur in the context of a driverless car. For example, a driverless car may include various modules, each with its own sensor data. Each of these modules may be responsible for performing a particular processing step. Additionally, the driverless car may consult with one or more internal nodes and one or more external nodes to perform certain processing, which may be related to, for example, controlling the vehicle. The external nodes may be, for example, web or cloud based.

[0004] In such distributed systems, it may be necessary or desirable to be able to enforce ordering of steps in a processing task. For example, nodes may be required to execute processing steps in sequence. The processing steps may then be combined to produce one of multiple possible outcomes for the task. Other technical challenges often encountered with distributed systems include difficulties arising from the allocation of resources within the network or system, and how to organize the actors (i.e., nodes) and the communication between them in an efficient and robust manner. Node organization and hierarchical considerations also pose challenges in distributed systems. It would be advantageous to have a hierarchical arrangement and control flow in a distributed system that is implemented and determined via mathematical and cryptographic techniques. This would provide benefits related to security and process automation.

[0005] Attempts at providing online voting or decision-making protocols are generally constructed in ways that attempt to prevent abuse, but rely on a central authority to validate and take into account votes or feedback. The central authority may use different cryptographic primitives, such as blind signatures and homomorphic properties, to add secrecy and validation to the ballot vote - see for example "Distributed Protocols at the Rescue for Trustworthy Online Voting" by R. Riemann and S. Grumbach, available via the arXiv preprint arXiv:1705.04480. For example, a centralized voting protocol is described in "Untraceable electronic mail, return addresses, and digital pseudonyms" by DL Chaum, Communications of ACM, 24(2), 84-90 (1981). In Chaum's protocol, participants send their votes to a central mixing authority that uses Mix Nets set-up to disguise vote-voter links, and then reshuffles and encrypts the votes before broadcasting them.

[0006] Other previous work removes the dependency on a trusted central authority but relies on cooperation among participants. For example, Foundations of Computer Science, 1982, SFCS'08, 23 rd"Protocols for secure computations" by ACYao in the Annual Symposium (pp.160-164), November 1982, describes Secure Multi-Party Computations (MPC) protocols, the purpose of which is to allow users to compute functions of their joint private inputs that they wish to keep secret, without the need for a trusted third party. MPC allows parties to jointly compute their average vote privately and securely, but accordingly relies on cooperation between the parties.

[0007] More fundamentally, each of the above prior works is intended for independent and not non-independent selection, and of course performs processing steps in a prescribed order to arrive at a result.

[0008] In light of the above, one technical problem may be how to provide a solution that enables and enforces ordering of processing steps by nodes in a distributed system. Another technical problem may be how to provide tamperproof or tamper-resistant records of results resulting from such ordered processing in a distributed system. Another technical problem may be how to use cryptographic techniques to enforce control and / or hierarchy and authorization (e.g., access permissions) in a distributed system.

[0009] Providing a solution to one or more of the aforementioned technical problems may include the use of a blockchain. In this document, the term "blockchain" is used to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and un-permissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Bitcoin may be referenced herein for convenience and example purposes only, but it should be noted that the subject matter of this application is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of this application.

[0010] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based distributed system composed of blocks, which are in turn made up of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between addresses in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block it is chained together with, creating a permanent, immutable record of all transactions that have been written to the blockchain since its inception.

[0011] Blockchains can be used in a wide variety of applications. For example, a blockchain can be used to provide a ledger that reflects the ownership of one or more commodities. For example, in the Bitcoin blockchain, the ledger reflects the ownership of bitcoins and fractions thereof. Some of these commodities can represent underlying units, such as units of computational resources. Summary of the Invention

[0012] In accordance with the present application, there is provided a method and system as defined in the accompanying claims.

[0013] 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 cyclically ordered nodes participating in a blockchain network, from a node immediately following the particular node, values ​​corresponding to combinations of possible outcomes of processing steps associated with nodes from the immediately following node to a node immediately preceding a supervisor node. The values ​​may be based on public keys associated with the nodes, each corresponding to a possible outcome of a processing step associated with the node, and a public key of the supervisor node. The method may include generating, by the particular node, a state value based on the received values ​​and the public keys corresponding to the possible outcomes of processing steps associated with the particular node. The method may include sharing, by the particular node, the state value with the supervisor node and the node immediately preceding the particular node. The method may include preparing a blockchain transaction configured to transmit control of a resource from a source address associated with the particular node to a receiving address of the immediately following node in response to satisfaction of an execution condition, including provision by the particular node using the state value of any one of a plurality of unlocking values ​​corresponding to the received value.

[0014] In some implementations, the nodes correspond to modules associated with a system, and the possible outcomes of a processing step associated with a given node may correspond to the output of an associated module of a control system of the system.

[0015] In some implementations, each of the received values ​​may be determined by combining a public key associated with the supervisor node with values ​​of the public key that correspond to each combination of possible outcomes of processing steps associated with nodes from the immediately succeeding node through to the node immediately preceding the supervisor node.

[0016] In some implementations, a given one of the received values ​​may be determined by summing the public key associated with the supervisor node and a value of one of the public keys corresponding to a respective one of a combination of possible outcomes.

[0017] In some implementations, the state value may be formed by combining the received value with the public key corresponding to a possible outcome of a processing step associated with the particular node.

[0018] In some implementations, the state value may be formed by summing one of the received values ​​and one of the public keys corresponding to a possible outcome of a processing step associated with the particular node.

[0019] In some implementations, another blockchain transaction may be configured to return control of a second resource to a particular node when a return condition is satisfied. In some implementations, the method may further include waiting for the blockchain transaction to execute and obtaining from the transaction a first unlocking value used to unlock the transaction, the first unlocking value being indicative of an output of a processing step associated with nodes from an immediately following node to a node immediately preceding the supervisor node and corresponding to the public keys associated with these nodes and based on a private key corresponding to the output. Such a method may include identifying one of the possible outcomes of the processing step associated with the particular node. Such a method may include determining, by the particular node, a second unlocking value based on the identified outcome and a private key corresponding to the public key corresponding to the unlocking value. The second unlocking value may correspond to one of the state values ​​and indicate an output of a processing step associated with a node from the particular node to a node immediately preceding the supervisor node. Such a method may include using the second unlocking value to execute another blockchain transaction.

[0020] In some implementations, the other blockchain transaction may be configured to transmit control of a second resource from a source address associated with the previous node to a receiving address of the particular node in response to satisfaction of a second execution condition including provision of any one of a second plurality of unlocking values ​​prepared by the previous node and corresponding to one of the state values, the blockchain transaction being configured to transmit control of the resource from the source address associated with the particular node to the receiving address of the immediately following node after preparation of the other blockchain transaction.

[0021] In some implementations, each unlocking value of the second plurality of unlocking values ​​may correspond to a respective one of the state values ​​and be based on a private key corresponding to the public key on which the state value is based.

[0022] In some implementations, the unlocking value may be the sum of the private key corresponding to the output of the processing step associated with the nodes from the immediately succeeding node to the node immediately preceding the supervisor node and the private key corresponding to the public key associated with the supervisor node.

[0023] In some implementations, the second unlocking value may be the sum of the private key corresponding to the output of a processing step associated with nodes from the particular node to the node immediately preceding the supervisor node and a private key corresponding to the public key associated with the supervisor node.

[0024] In some implementations, the resource and the second resource may be the same.

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

[0026] The present invention may also provide a computer-implemented system for carrying out a method according to the above.

[0027] The invention may also provide a non-transitory computer readable storage medium having stored thereon instructions for adapting a computer system to perform a method according to the above. [Brief description of the drawings]

[0028] Any feature described in relation to one aspect or embodiment of the invention may also be used in relation to one or more other aspects / embodiments. These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. Embodiments of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which: [Figure 1] Figure 1 shows the transactions used in a payment channel. [Diagram 2] FIG. 2 is a flow chart illustrating how a payment channel according to FIG. 1 can be created. [Diagram 3]FIG. 3 is a simplified schematic diagram illustrating one example of an operating environment for the present application. [Figure 4] FIG. 4 is a simplified schematic diagram illustrating another example of an operating environment of the present application. [Diagram 5] FIG. 5 illustrates an exemplary computing device. [Figure 6] FIG. 6 is a diagram showing a cyclically-ordered set of nodes. [Figure 7] FIG. 7 shows an example decision tree corresponding to the task processing. [Figure 8] FIG. 8 shows the private keys associated with particular edges of the decision tree of FIG. [Figure 9] FIG. 9 shows the public key values ​​associated with the private keys of FIG. 8 and associated with particular edges of the decision tree of FIG. [Figure 10] FIG. 10 is a flow chart describing operations performed by particular nodes of FIG. [Figure 11] FIG. 11 is a diagram illustrating an exemplary payment channel according to the present application. [Figure 12] FIG. 12 is a flow chart illustrating how a payment channel according to FIG. 1 can be created. [Figure 13] FIG. 13 is a flow chart describing operations performed by the nodes of FIG. [Figure 14] FIG. 14 is a flow chart illustrating operations performed by particular nodes of FIG.

[0029] In the drawings, like reference numbers are used to denote like elements and features. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] In this application, the term "and / or" refers to all possible combinations and subcombinations of the listed elements. B -combination), including any one of the listed elements alone, any subcombination, or all of the elements, and not necessarily excluding additional elements.

[0031] In this application, the phrase “at least one of…or…” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements, and does not necessarily require all elements.

[0032] A protocol embodying the invention is described herein for a group of nodes cooperating to each make decisions in an ordered manner. It is built on the concept of requiring a node to commit units of computational resources, which the node can only recover with the use of an accumulated secret value derived from the output of a previous step in the processing of the task.

[0033] The protocol described herein builds on an existing Bitcoin-related technology, Payment Channels (see, for example, “Introduction to Micropayment Channels” http: / / super3.org / introduction-to-micropayment-channels / ), which is a technology designed for off-block Bitcoin transactions between pairs of participants, and which specifically incorporates the use of refund transactions.

[0034] Payment channels As noted above, payment channels are referenced in the following description, and for the convenience of the reader, a summary of the payment channels follows.

[0035] Payment channels are a technology designed to conduct multiple cryptocurrency transactions on behalf of parties without committing all of the transactions to the blockchain. A typical implementation of a payment channel can make payments of nearly unlimited amount, but only requires adding two transactions to the blockchain.

[0036] In addition to reducing the number of transactions added to the blockchain and the associated cost savings, payment channels also offer the benefits of speed and, importantly, the ability for parties to have units refunded if things do not go as planned or if any participant decides not to proceed beyond a given set of payments. A payment channel implementation is outlined below.

[0037] Consider a scenario where Alice needs to transfer blockchain resources to Bob. This may require multiple payments from Alice to Bob over a period of time, depending on the circumstances. Alice hopes to transfer, say, 15 BTC (in total) to Bob in a possible set of exchanges. To facilitate this, a payment channel is established between Alice and Bob, and works as follows:

[0038] First, Alice creates a 2-of-2 multi-signature pay-to-script-hash (P2SH) transaction, T c , which is controlled by both Alice and Bob and commits 15 BTC originating from Alice. At this point, the transaction is not submitted to the Bitcoin network (such a multi-signature address requires that two individuals, Alice and Bob, cryptographically sign any transaction that spends money from this address).

[0039] Next, Alice issues a separate refund transaction, T, which returns all units of the multi-signature managed fund to Alice. c,0 , which contains an nLockTime value of 100 blocks (nLockTime is a Bitcoin transaction parameter that allows a Bitcoin transaction to become executable only after a specified amount of time has passed). Bob signs the transaction. The refund transaction allows Alice to be refunded after nLockTime has passed (transpired) if the exchange between Alice and Bob does not go through.

[0040] Next, Alice transfers the original transaction T c Sign.

[0041] At this point, Alice and Bob can proceed to generate new withdrawal transactions to reflect the (off-blockchain) transfers made from Alice to Bob. These withdrawal transactions reflect the net quantity of resources that Alice is now required to transfer to Bob. As an example, if Alice transfers 5 BTC to Bob, a new withdrawal transaction T r,i If Alice needs to transfer another 5 BTC to Bob, a new withdrawal transaction T is generated with outputs sending 5 BTC to Bob and 5 BTC to Alice. r,i+1 , is generated. For each new refund transaction, assuming they agree on the details, both parties sign the transaction but do not necessarily submit it to the network.

[0042] Note that each successive redemption transaction generated has a smaller nLockTime than the previous redemption transaction - i.e., nLockTime(T r,i+1 ) <nLockTime(T r,i ).

[0043] Participants can select any T r,i If an aggrieved participant refuses to sign the r,i-1 In the worst case scenario, Alice can submit T r,0 and submits it to the network (after nLockTime expires) reclaiming all of her units.

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

[0045] Figure 1 shows a transaction T used in a payment channel. c 100A and T r,n 100D. M represents the maximum amount that Alice can send to Bob. x i is the current net amount of units that Alice owes to Bob. S stop is the nLockTime for the first refund transaction. n is the number of refund transactions generated in the ongoing (out-of-block) transfer between Alice and Bob (this excludes the first refund transaction). s is the time allotted for both parties (Alice and Bob) to agree on a refund transaction before the parties incur the risk of the other party submitting a previous refund transaction, effectively terminating the exchange between Alice and Bob.

[0046] t+n*s stop Note that, where t is the current time and (S stop -n*s)≧s.

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

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

[0049] ​In operation 210, a processor of a computing device associated with Alice generates a two-of-two multi-signature pay-to-script hash (P2SH) transaction, T, in the manner described above. c Generate.

[0050] From operation 210, the flow of control passes to operation 212. In operation 212, a processor of a computing device associated with Alice generates a separate refund transaction T r,0 and returns all units of the multi-signature controlled fund to the account associated with Alice in the manner described above.

[0051] From operation 212, the control flow passes to operation 214. In operation 214, a processor of a computing device associated with Alice signs the above-mentioned refund transaction.

[0052] From operation 214, the flow of control passes to operation 216. In operation 214, the processor of the computing device associated with Bob may also sign the above-mentioned reimbursement transaction. If the transaction is so signed, the flow of control passes to operation 218. Alternatively, if the transaction is not signed, the creation of the payment channel is aborted.

[0053] In operation 218, a processor of a computing device associated with Alice c The control flow then proceeds to operation 220.

[0054] In operation 220, the above refund transaction is recognized as an initial refund transaction so that, if time permits, further transfers from Alice to Bob may be negotiated.

[0055] From operation 220, the control flow proceeds to operation 222. In operation 222, it is determined whether sufficient time remains to negotiate further transfers. If not, the control flow proceeds to operation 224, where a final refund transaction is submitted to the blockchain. Alternatively, if sufficient time remains, the control flow proceeds to operation 226.

[0056] In operation 226, further transfers between Alice and Bob are negotiated. From operation 226, the control flow passes to operation 228, where it is determined whether the negotiations were successful. If the negotiations were unsuccessful, control passes to operation 224, described above. Alternatively, if the negotiations were successful, which results in the control flow passing to operation 230.

[0057] In operation 230, a new refund transaction reflecting the agreement resulting from the successful negotiation is generated in the manner described above. Control then passes to operation 240, where the new refund transaction is recognized as the current refund transaction.

[0058] From operation 240, the control flow proceeds to operation 242, where processors of the computing devices associated with Alice and Bob may sign the current refund transaction. If so, the control flow returns to operation 222, described above. Alternatively, if the transaction is not so signed, recognition of the current refund transaction reverts to the previous refund transaction in operation 244. From operation 244, the control flow returns to operation 222, described above.

[0059] FIG. 3 illustrates one exemplary operating environment for the present application.

[0060] As shown, multiple nodes 300 communicate over a computer network 310. Each of the nodes 300 is a computing device and participates in the blockchain and has one or more associated addresses with which the blockchain reflects amounts of units, e.g., units of a computing resource.

[0061] Various ones of the nodes 300 may perform processing steps in a distributed process, the outputs of which are combined to form an outcome.

[0062] As will be further described below, the subject matter of the present application may be applied in a variety of contexts. For example, FIG. 4 illustrates a particular example operating environment of the present application in the context of a system, and more specifically, a self-driving vehicle 400.

[0063] Distributed processing by the autonomous vehicle 400 may rely on multiple modules. For example, distributed processing could include 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-440 communicate via a network 450.

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

[0065] 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 distance.

[0066] 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 the availability of restaurants and hotels.

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

[0068] The traffic module 440 can select a route based on traffic conditions. For example, the traffic module 440 can select a best route based on avoiding traffic congestion.

[0069] Advantageously, the subject matter of the present application may be applied such that modules 410-440 collectively perform processing steps related to the task of routing autonomous vehicle 400, the output of which results in a particular outcome, i.e., a selected route. Notably, as described further below, because blockchain is used to record the outputs of the various processing steps and transmit them between nodes, the outputs of modules 410-440 may also be recorded to enable future audit and review, such as for fault determination following an incident involving autonomous vehicle 400.

[0070] As mentioned above, the subject matter of the present application may also be applied in other contexts. For example, when the subject matter of the present application is applied to the control of a system, the particular type of system being controlled need not be an autonomous vehicle. For example, the subject matter of the present application may be applied to enable modules, such as those that may be responsible for the operation or control of an industrial plant, to collectively perform processing steps related to such a plant. In a particular example, such steps may correspond to decision or control points of an industrial process. In another example, the subject matter of the present application may be applied to the operation of a traffic control system, enabling modules of such a system to collectively perform processing steps related to a task, such as the control of a traffic light.

[0071] Returning to Figure 3, recall that each of the nodes 300 is a computing device. Figure 5 is a high-level operational diagram of a computing device. Exemplary computing device 500 may be representative of one or more of the computer systems described herein, including, for example, one or more of the nodes 300. Exemplary computing device 500 includes software that adapts it to perform certain functions.

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

[0073] Processor 510 is a hardware processor. Processor 510 may be, for example, one or more ARM, Intel x86, PowerPC processors, etc.

[0074] The memory 520 allows data to be stored and retrieved. The memory 520 may include, for example, random access memory, read-only memory, and persistent storage. The persistent storage may be, for example, flash memory, solid-state drives, etc. The read-only memory and persistent storage are non-transitory computer-readable storage media. The computer-readable media may be organized using a file system, such as may be managed by an operating system that governs the overall operation of the exemplary computing device 500.

[0075] Network interface 530 enables exemplary computing device 500 to communicate with other computing devices and / or various communications networks, such as, for example, computer network 310 (FIG. 3).

[0076] Software containing instructions may be executed by processor 510 from a computer-readable medium. For example, the software may be loaded into the random access memory of memory 520 from a persistent storage. Additionally or alternatively, the instructions may be executed by processor 510 directly from a read-only memory of memory 520.

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

[0078] As will be further explained below, in the protocols described herein, the nodes are responsible for executing the processing steps of an overall distributed computing task. Referring to FIG. 6, in a particular embodiment, the nodes 600 may be responsible for executing the task processing in an ordered manner. One of the nodes acts as a supervisor node - for example, one of the nodes 600, node U0, may be the supervisor node - and the other nodes are responsible for selecting the options. The order of the step processing in the task may be used to realize a cyclically-ordered set formed of nodes. The cyclically-ordered set may be thought of as a ring, with each node having two other nodes as the immediate and immediate nodes relative to that node. For example, the cyclically-ordered set of nodes 600 may be depicted as a directed ring 610, as shown in FIG. 6.

[0079] Each non-supervisory node of node 600 in directed ring 610 is labeled U x where x corresponds to a letter in the alphabet according to the intended order of steps in the task process.

[0080] The supervisor node U0 is expected to be the node that is given the responsibility of overseeing the execution of the protocol. The supervisor node acts as the initiator and coordinator of the protocol, as described further below. In one example, it may be that the supervisor node is associated with a party that provides resources that are allocated based on the outcome of a decision-making process.

[0081] The nodes 600, supervisor nodes and / or non-supervisor nodes, may be of the nodes 300 and / or modules 410-440. Furthermore, the supervisor node U0 may be selected from among the nodes 300. Such selection may be made in various ways. For example, each of the nodes 300 may perform an operation or participate in a protocol, resulting in a particular one of the nodes being selected as the supervisor node. Alternatively, one of the nodes 300 may be selected as the supervisor by some central authority.

[0082] The protocol described herein facilitates the execution of a distributed computing task by participating nodes 600 with step processes in the task that correspond to the structure of a decision tree. One example of such a decision tree is found in FIG. 7, which shows a decision tree 700. In decision tree 700, each level of the tree represents the result of a process by a node participating in the protocol described herein, and in particular, by one of those nodes 300. In other words, each level of decision tree 700 corresponds to a "factor" in the final result of the process by the distributed system formed by the nodes 600. Each node 600 at a given level of decision tree 700 corresponds to a combination of specific outputs of the step processes represented by higher levels of the tree (i.e., levels closer to the root). Each edge emanating from a node represents a possible outcome ("choice") of the process associated with / performed by that node that a party may make with respect to the decision represented by that node.

[0083] In decision tree 700, there are n=3 steps (and 3 nodes) participating in the process, with each node involved in the process resulting in one of m=2 options.

[0084] In general, the U associated with the decision tree 700 A,i Each node in represents a particular combination of nodes, processing steps, and previous outputs (i.e., outputs of a process corresponding to a higher level in the tree), where a represents the processing step performed by a particular node, and i represents the output of the previous processing step in the tree. In a particular example, U B,2 The party U A represents a node that performs processing step B after identifying a specific output for processing step A.

[0085] The leaf nodes of the decision tree 700 represent a set of possible final outcomes resulting from a particular combination of outputs from the various processing steps. In other words, the outputs of the tasks associated with each node form a path in the decision tree towards the outcome of the distributed processing. Notably, unlike decision-making or voting protocols where a majority vote determines the winner, in this protocol it is the combination of the outputs of the various processing steps that determines which outcome is selected. More specifically, the output of a particular processing step is not a vote for a particular outcome, but rather narrows the possible outcomes of the distributed processing to a set of possible outcomes (i.e., all outcomes that are children of the corresponding node of the decision tree 700 along the branch corresponding to the selected output). Thus, as each processing step in the pre-determined sequence of steps is reduced, the set of possible outcomes - the output of the distributed processing - remains until there is only one possible outcome.

[0086] In a particular example, in decision tree 700, the possible outcomes O 212 can be reached via a particular path, indicated by the darker arrow. First, as shown, A If you choose option 2, this reduces the set of possible outcomes to {O 211 , O 212 , O221 , O 222}. Next, U B If chooses option 1, this results in a set of possible outcomes {O 211 , O 212}. Then, U C If you choose option 2, this reduces the set of possible outcomes to {O 212}.

[0087] The processing by the nodes has a chronological aspect that is consistent with dependencies between steps in the tasks performed by the protocols described herein. In particular, each node performs its respective processing steps in a pre-established sequence. For example, in decision tree 700, the pre-established sequence reflected in the levels of the tree corresponds to the order shown in FIG. A The relevant processing steps are B Run before U B The relevant processing steps are C Execute in sequence before .

[0088] Of course, decision tree 700 is one example, and the decision tree associated with a given deployment of the protocols described herein may vary. For example, there need not be a 1:1 correspondence between processing steps and nodes. In a particular example, party U A may be called to perform processing step B as well as processing step A. Additionally or alternatively, it may be that some or all of the steps have more (e.g., more than two) possible outputs. Additionally or alternatively, it may be that different steps have different numbers of possible options. Further, it may be that there are more or fewer steps or nodes.

[0089] In the protocol described herein, for each processing step associated with a particular node, that node generates a set of private keys corresponding to each possible outcome that a given node may have for that processing step. In particular, a party is required to select a private key corresponding to each option that may be selected in the context of each possible combination of the outputs of previous processing steps that have already taken place.

[0090] One example of this, shown in Figure 8, illustrates a decision tree 700 that has been augmented with various private keys associated with each edge of the decision tree 700. As shown, the private keys may be indicated using subscripts that encode the output of earlier processing steps, as well as the output of the processing at that level (i.e., the level of the "current" processing step) that is associated with a particular private key. For example, in Figure 8, U B The process by has two possible outputs, corresponding to four possible outcomes. In a specific example, one option is B About U A The choice is to choose option 1 after choosing option 2. The choice is made by 21 It supports.

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

[0092] The private key k can be generated using techniques known to those skilled in the art. Further, various public key cryptosystems can be employed. For example, Elliptic Curve Cryptography (ECC) may be used. In a specific example, ECC is employed, and k and the corresponding public key P may be a public key - private key pair of ECC such that P = kG. Here, G is a base point on an elliptic curve of order q: q×G = 0, where q is a large prime number and 0 < k < q. In a specific example, the elliptic curve secp256k1 - as defined in the document "Standards for Efficient Cryptography2 (SE2)", Certicom Corp, January 27, 2010 - may be used. In other words, each public key and its corresponding private key can form a public key - private key pair of ECC.

[0093] After the generation of the private key, a value is generated based on the corresponding public key.

[0094] First, the supervisor generates a public key / private key pair and shares the public key of the pair, Q, with all the nodes participating in the protocol described herein. S as shown.

[0095] Next, each participating node, in turn, generates the value of the public key corresponding to each of the previously generated private keys. This is explained, for example, in FIG. 9 showing decision tree 900, corresponding to decision tree 700, but enhanced to show the value of the public key associated with a particular edge.

[0096] In particular, a public key value, or state value, is generated by combining each of the public keys corresponding to previously generated private keys associated with edges from the root to a given edge of the tree. In other words, each state value 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 from earlier in the tree (i.e., on an edge leading into the node). In the base case (the first level of the tree below the supervisor), the state value is Q S with each of the public keys associated with the private key at that level.

[0097] This combination can be generated by appending public keys in the case of an elliptic curve cryptosystem. For example, a given public key can be appended to a preceding selected value. Recall that in ECC, the public key P corresponding to a private key k is defined by P=k×G. Thus, referring to FIG. 9, when ECC is used, Q2=Q S +k2G. In another example, Q 21 =Q2+k 21 It can be G.

[0098] The supervisor shares its public key Q with each of the other nodes participating in the protocol described herein. Similarly, each non-supervisor node shares its state values ​​with the previous node in the cyclically ordered set and with the supervisor node. In addition, each non-supervisor node shares the semantic meaning of those values ​​(i.e., the results they correspond to) with the previous node in the cyclically ordered set and with the supervisor node.

[0099] Notably, the state value of the final voter in the voting sequence—e.g., U in Figure 6— C- indicates possible outcomes of the protocols described herein (O x ) The supervisor node generates a new public key / address S that is directly associated with each result. x to other nodes participating in the protocol described herein. This is done by x , S x )}, where the set {O x} is the set {S x}. Public key S x The public key S does not belong to the supervisor node itself (i.e., the supervisor node need not know the corresponding private key), but instead the private key may be known to a separate entity tasked with carrying out duties associated with a particular outcome. Advantageously, in this way, a follow-up step is to x This may be performed by a third party who may possess the private key corresponding to .

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

[0101] Conveniently, when ECC is used, the secret value sv corresponding to a given selection value x is related to the selected value Q as follows: First, recall that E(m+n) = E(m) + E(n), where E is the function E(x) = xG, according to the homomorphic property of elliptic curve addition. Furthermore, if ECC is used, then for a given selected value Q x Q x =k S G+k A G+...+k x Recall that the function is defined by, where k S is its public key Q S (That is, Q S =k SG) is the secret key of the supervisor node that corresponds to the selection value Q x The private key sv corresponding to x is the sum of the private keys k i +k i+1 +...+k x In a specific example related to decision tree 700, sv 21 =k i +k i+1 +...+k x , and Q 21 = G × sv 21 It is.

[0102] The protocols described herein include the circuitry of payment channels between participating nodes 600. In particular, as described further below, a payment channel is established between each of the nodes 600 and its immediately preceding node to transfer computational resources from the node to its immediately preceding node. For example, in FIG. 6, a payment channel may be established between each of the nodes 600 and its immediately preceding node, as indicated by the direction of the edges shown between the nodes. The payment channel is configured to be unlockable by any one of the secret values ​​corresponding to the state values ​​of the immediately preceding node. The computational resources transferred by the payment channel may be, for example, Bitcoin or a portion thereof, in the case where the protocols described herein operate on the Bitcoin blockchain.

[0103] Use of a payment channel requires that units of computational resources be committed for the channel. For example, in a payment channel chain, computational resources are transferred by each payment channel from a node to the payment channel immediately following it.

[0104] Since the transfer of value is not central to the protocols described herein, this amount may be a nominal amount. As will become clear, however, each node is required to participate in the selection of the outcome, under the penalty of forfeiture of the value it commits to the payment channel. Thus, it may also be the case that nodes are required to contribute a sufficiently substantial amount of computational resources to the payment channels to discourage frivolous participation and / or violation of the protocols described herein. The amount of computational resources committed to each of the payment channels may be the same, or in other words, the resources committed to each of the payment channels may be the same if the resources are fungible.

[0105] Prior to the establishment of a payment channel for a line, the nodes, and in particular the supervisor node in combination with other nodes participating in the protocol described herein, must agree on two values: a time point S and a time span s.

[0106] First, a time span s is selected, which represents the amount of time each node participating in the protocol described herein needs to complete certain operations, which are described further below. The operations are: establishing a payment channel between the node and its immediate predecessor, retrieving a secret value used to unlock the previous payment channel in the chain, selecting one of the further possible outcomes for the processing step associated with the node, and submitting a payment transaction of another payment channel in favor of the node to the blockchain. Any one of the nodes can select the time s, taking into account the consensus of other users. In some implementations, a supervisor node can choose s that may simplify the protocol. The time s can be expressed in appropriate units, such as seconds or number of blocks.

[0107] A value S is then chosen as the start time for the first transfer for the node to submit to the blockchain network. Any node can choose S, taking into account the consensus of other nodes. In some implementations, the initiator can choose S, which may simplify the implementation of the protocol.

[0108] In particular, S represents a point, which may be specified, for example, in either unix time or block height, while s represents a time span.

[0109] Payment channels are constructed in a clockwise fashion, starting with a payment channel between the supervisor node and its immediate successor (i.e., the node responsible for making the final selection). For example, referring to Figure 6, the first payment channel to be constructed is between U0 and U C The final payment channel to be established is between A and U0.

[0110] This ordered sequence guarantees that a payment channel exists in favor of each node before it can commit resources to a payment channel in favor of the node immediately following it. However, the supervisor node does not receive this guarantee, because its private key k s is a component of all the secret values ​​that can be used to unlock each of the various payment channels. s Since,is kept secret by the supervisor node at this stage, the supervisor node can safely generate the first payment channel in the circuit without the guarantee of a payment channel in favor of it. In particular, if no payment channel is generated in favor of the supervisor node, it can wait long enough to submit a refund transaction for the payment channel it has generated.

[0111] Exemplary operations performed by nodes participating in the protocol described herein will now be described with reference to a series of flowcharts shown in Figures 10, 13 and 14. In these flowcharts and their following description, a cyclically ordered set of n nodes participating in the protocol is represented as U0...U n-1 , starting from the supervisor node U0 through the cyclically ordered set of nodes to the node that directly precedes the supervisor node (i.e., the immediately preceding node) in the order of construction of the various payment channels - that is, in the reverse order of the steps in the intended processing. For example, if the intended order of processing steps is depicted as being in a counterclockwise direction as shown in Figure 6, then the nodes U0...U n-1 The order of numbers follows a clockwise direction. In a specific example, according to such numbering, B The node labeled U i If identified as A(Figure 6) is U i+1 And U C (Figure 6) is U i-1 In other words, for the purposes of the flow charts shown in Figs. 10, 13, and 14, B The node labeled with is node U A is considered to be the node immediately before U B The node labeled with is node U C will be considered the node immediately following.

[0112] FIG. 10 will now be described. FIG. 10 shows a flowchart 1000 illustrating operations associated with a particular node participating in the protocol described herein, performing operations in preparing for creation and generating a payment channel from the node to its immediate predecessor. Various non-supervisory participating nodes may each perform operations corresponding to the operations shown in flowchart 1000 in creating a payment channel circuit as described above. Operations 1010 et seq. are performed by one or more processors associated with one of the particular non-supervisory nodes of the participating nodes. Thus, operations 1010 et seq. are performed by one or more processors of a computing device, such as processor 510 (FIG. 5) of a suitably configured instance of exemplary computing device 500 executing software including computer-executable instructions that may be stored in a computer-readable storage medium, such as the storage of memory 520.

[0113] In operation 1010, a particular node receives state values ​​associated with the node immediately following the particular node in the cyclically ordered set from the node immediately following the particular node. Thus, due to the definition of the state values ​​and the ordering of the nodes in the cyclically ordered set, the particular node receives values ​​corresponding to combinations of possible outcomes of the processing steps associated with the nodes in the cyclically ordered set (e.g., oriented ring 610) from the immediately following node to the node immediately preceding the supervisor node. As described above, the state values ​​are based on the public keys associated with the nodes, and each of these public keys corresponds to a possible output of the processing step associated with that node. For example, if ECC is used, each received state value may be determined by summing the public key associated with the supervisor node and each public key corresponding to a particular outcome, as described above.

[0114] Following operation 1010 , the control flow proceeds to operation 1020 .

[0115] In operation 1020, the particular node generates a state value for the node. In other words, the particular node generates a state value that corresponds to an output selectable by the particular node. The state value is generated based on the received state value and the public key associated with the node (as described above, the private key k associated with the node). x Thus, a state value is generated based on the received value and a public key corresponding to a possible outcome of a processing step associated with a particular node.

[0116] Following operation 1020 , the control flow proceeds to operation 1030 .

[0117] In operation 1030, the state value is shared with the supervisor node and the node immediately preceding the particular node in the cyclically ordered set, as described above.

[0118] From operation 1030 , the control flow proceeds to operation 1040 .

[0119] In operation 1040, a particular node may wait for the creation of a payment channel in favor of it by a previous node. To create each of the above payment routes, various transactions are prepared as described above. For example, transaction T pay is prepared using a lock value for that payment channel. The transaction is configured to send a resource - for example, x units of computational resources, or x BTC - from a source address associated with the previous node to a receiving address of a particular node. According to the transaction, control of the resource is transferred to an unlocking value (sv x ) in response to the satisfaction of execution conditions. In particular, each unlocking value corresponds to a respective state value and is based on a private key corresponding to the public key on which the selected value is based. For example, if ECC is used, each unlocking value is based on their private key and the supervisor node's public key Q S The private key k corresponding to S Thus, a particular node may wait for the generation of a blockchain transaction prepared by a previous node and configured to transmit control of a resource from a source address associated with the previous node to a receiving address of the particular node.

[0120] The particular node is then prepared using the state value, and a second payment channel is generated by the particular node in favor of the immediately following node. For example, the particular node may prepare such a second payment channel after a payment channel in favor of it is generated. Preparing such a payment channel is similar to the description of the first payment channel above, and includes preparing a blockchain transaction configured to transmit control of a second resource from a source address associated with the particular node to a receiving address of the immediately following node. The payment channel is configured to transmit control of the resource responsive to satisfaction of the execution condition, and includes a supply of any one of a (second) plurality of unlocking values ​​corresponding to the received value.

[0121] FIG. 11 illustrates a U a →U b A representation 1100 of a payment channel is provided.

[0122] As shown, the channel is divided into three transactions T c , T pay , and T r It includes σ(U x ) is U x Note that this represents a cryptographic signature of

[0123] T c A transaction represents the commitment component of a payment channel. b is a 2 of 2 multi-signature (U b , U a ), or multiple secret values ​​{sv} (a) and U a Send / commit a specified number of units, governed by the knowledge of any one of the cryptographic signatures of

[0124] T rA transaction acquires a specified number of units (from a commitment transaction) that become eligible for submission to the blockchain after a specified time has elapsed. b Thus, T r If the time-out return condition is satisfied, a particular node, U b For this transaction to be successful, the cryptographic signature U a and signature U b is required.

[0125] T pay The transaction is b of committed funds to U a For this transaction to be successful, multiple secret values ​​{sv} (a) (corresponding to the state value associated with that element / level of the decision tree), and U a requires a cryptographic signature of the

[0126] If the blockchain is the Bitcoin blockchain, T c , T r , and T pay Each may be a Bitcoin transaction.

[0127] FIG. 12 shows the flow of a node U b In generating payments to node U, b 12 shows a flowchart 1200 illustrating operations that may be performed by a node U. bThus, operations 1210 et seq. are performed by one or more processors of a computing device, such as processor 510 (FIG. 5) of a suitably configured instance of exemplary computing device 500 executing software including computer-executable instructions, which may be stored in a computer-readable storage medium, such as the storage of memory 520.

[0128] In operation 1210, U b is a commitment transaction, T c Generate a transaction T c is as described above.

[0129] From operation 1210 , the control flow proceeds to operation 1220 .

[0130] In operation 1220, a refund transaction, T r A transaction T is generated. r is as described above. r is generated with the time specified for the expiry of S+(a+1)s, where a is the first payment transaction in the line (e.g., U0 to U c ), and is incremented by 1 for each succeeding payment channel in the line (eg, a=0, 1, 2, 3, ...).

[0131] From operation 1220 , the control flow proceeds to operation 1230 .

[0132] In operation 1230, U b Signs the refund transaction.

[0133] From operation 1230 , the control flow proceeds to operation 1240 .

[0134] As mentioned above, other participants in the payment channel, U a , and also, the refund transaction T r In operation 1240, U a is a refund transaction T r If not, the creation of the payment channel fails and is aborted. Alternatively, a is a refund transaction T r If so, then the control flow proceeds to operation 1250 .

[0135] In operation 1250, U b is a payment transaction T pay Generate a transaction T pay is as described above.

[0136] From operation 1250 , the control flow proceeds to operation 1260 .

[0137] In operation 1260, U b is a payment transaction T c Sign the token and submit it to the blockchain.

[0138] Following operation 1260, the control flow ends and the payment channel has been created.

[0139] After the payment circuit is completed, each participating node can take turns choosing an option. In summary, each node participating in the protocol described herein takes turns choosing an option and then, based on its choice, selects a T in favor of that node. pay Redeem the transaction.

[0140] Figure 13 shows a flowchart 1300 for explaining operation 1310 and subsequent operations, which can be executed by nodes participating in the protocol described herein in the selection of results. Thus, operation 1310 and subsequent operations are executed by one or more processors of various computing devices. For example, it pertains to a properly configured instance of an exemplary computing device 500 that executes software including computer-executable instructions that can be stored in a computer-readable storage medium such as the storage of memory 520, such as a processor 510 (FIG. 5).

[0141] As described above, flowchart 1300 and its description use a notation consistent with the notation of flowchart 1000. In other words, the nodes start from the supervisor node U0 and are numbered in the order of constructing the payment channel.

[0142] In operation 1310, a check is performed to ensure that there is sufficient time remaining to complete the necessary steps in the protocol described herein. In particular, the current time may be compared with the start time, S, of the first transfer, and it can be ensured that there is sufficient time so that none of the payment channels time out and can complete the line. In particular, it is determined whether t < S + s. Here, t is the current time.

[0143] If the check in operation 1310 fails, the protocol described herein is aborted. Otherwise, the control flow proceeds to operation 1320, where the supervisor node submits a pay blockchain transaction. This has the side effect of revealing the value k on the blockchain as the value Q S corresponding to locking that particular payment channel. S ​

[0144] Following operation 1320, the node associated with the first processing step, U n-1 , i.e., the first node to vote. Control flow then proceeds to operation 1330, where a loop check determines whether each node participating in the protocol has completed its associated processing step, and an outcome is determined. If so, the control flow ends. Alternatively, if all processing steps have not yet been completed (e.g., on the first pass through operation 1330), control flow proceeds to operation 1340.

[0145] In operation 1340, an unlocking value, sv, to be used in the payment transaction of the payment channel (which may have been submitted to the blockchain in operation 1320 or, as described below, in operation 1350) is previous , is extracted from the blockchain. - i.e., U i From U (i+1)mode n Conveniently, sv previous is extracted from the blockchain transaction that is submitted only after the immediately succeeding node (i.e., the node associated with the previous processing step) has identified the output, thus enforcing ordering of the processing steps.

[0146] From operation 1340 , the control flow proceeds to operation 1350 .

[0147] In operation 1350, node U i further identifies one of the possible outcomes for the processing step associated with that node. The node is then assigned a value sv previous , the private key (k ijk ) to determine the corresponding unlocking value. For example, if ECC is used, Ui is sv ijk = sv previous + k ijk The secret value sv is determined by calculating ijk In particular, this is done according to each of the various state values used to lock various T pay transactions and operates according to isomorphic properties.

[0148] Regarding the execution of the processing steps, each of the nodes 30 can execute the steps in various ways. For example, if the node 300 corresponds to a module of an autonomous vehicle, the processing step can select an output according to a program. For example, it can be based on the input data provided to the node, such as data received from one or more input devices, such as from a user.

[0149] From operation 1350, the control flow proceeds to operation 1360. In operation 1360, it is determined whether there is enough time left to complete the transaction. In particular, it is determined whether t < S+(n - i)s. Here, t is the current time, and i is the index of the current node counted from the supervisor node. The supervisor node is 0, the node immediately following the supervisor node (i.e., the node associated with the last processing step) has index 1, and it continues in the same way until the node associated with the first processing step having index (n - i) as described above.

[0150] From operation 1360, if it is determined that there is enough time left, the control flow proceeds to operation 1380. Alternatively, if it is determined that there is not enough time left, the control flow proceeds to operation 1370.

[0151] In operation 1370, the lack of sufficient remaining time may result in an abort of the protocol described herein as a refund transaction. n-1 In particular, U n-1 is the next node in the set of cyclically ordered nodes for the blockchain, U i , thereby starting the process and causing nodes up to the node intended to perform the final processing step (i.e., the node immediately after the supervisor node), U1, to submit their respective refund transactions to the blockchain.

[0152] In operation 1380 (when enough time remains), node U i But I agree with that. pay Submit a blockchain transaction to the blockchain, thereby creating a sv current It reveals:

[0153] Following operation 1380, counter i is decremented by one to correspond to the next node in the selection sequence, and control flow then returns to operation 1330 (as described above), thereby looping to process the selection by the next node in the sequence.

[0154] Flowchart 1300 illustrates the execution of processing steps across the nodes participating in the distributed computing task as a whole. FIG. 14 shows a flowchart 1400 illustrating operations performed by a particular node participating in the protocol described herein in performing operations involved in processing the task. Various non-supervisory participating nodes may each perform operations corresponding to the operations described in flowchart 1400 in generating the payment channel lines described above. Operation 1410 and beyond is performed by one or more processors associated with a particular, non-supervisory one of the participating nodes. Thus, operation 1410 and beyond is performed by one or more processors of a computing device, such as processor 510 (FIG. 5), associated with a suitably configured instance of an exemplary computing device 500 executing software including computer-executable instructions, which may be stored in a computer-readable storage medium, such as the storage of memory 520.

[0155] As noted above, flowchart 1400 and its description use notation consistent with that of flowchart 1000. In other words, the nodes are numbered in the order of construction of the payment channel, starting with supervisor node U0.

[0156] First, the particular node must ensure that it waits for the next node to make a selection. Thus, in operation 1410, the particular node transfers the blockchain transaction T associated with the payment channel from the particular node to the next node. pay The transaction waits to be executed, i.e. unlocked and submitted to the blockchain. Following the transaction being submitted to the blockchain, the control flow proceeds to operation 1420.

[0157] In operation 1420, the particular node receives from the blockchain the blockchain transaction T detected in operation 1410. pay The unlocking value, sv, used to unlock previous , as described above. previous indicates the output of the processing step associated with the node selected before the particular node. Thus, the value sv previous denotes the output of the processing step associated with the node in the cyclically ordered set from the immediately succeeding node to the node immediately preceding the supervisor node. Furthermore, as mentioned above, the value sv previous is based on a private key that corresponds to a public key associated with the nodes and corresponds to the selected option previously chosen or selected by the nodes. In other words, the value sv previous corresponds to the selection value of the immediately succeeding node. For example, as mentioned above, if ECC is used, the unlocking value may be the combination of a private key corresponding to the output of a processing step associated with a node in the cyclically ordered set from the immediately succeeding node to the node immediately preceding the supervisor node, and a public key (Q s ) corresponding to the private key (k s )

[0158] Then, in operation 1430, the particular node further identifies one of the possible outcomes for the processing step associated with that node in the manner described above. As described above, a node may programmatically identify an output in a variety of ways depending, for example, on the inputs and / or conditions associated with that node. For example, some of the inputs may be received via an input interface, such as from a user.

[0159] From operation 1430 , the control flow proceeds to operation 1440 .

[0160] As described above, the public key of a particular node corresponds to each possible outcome of the task processing associated with that node. In operation 1440, the unlocking value is calculated by multiplying the unlocking value sv extracted in operation 1420 by the public key sv . previous and a private key corresponding to the public key corresponding to the identified result. For example, if ECC is used, the values ​​may be combined by adding in the manner described above.

[0161] From operation 1440 , the control flow proceeds to operation 1450 .

[0162] In operation 1450, the unlocking value determined in operation 1440 is used to execute a transaction associated with the payment channel between the previous node and the particular node. In particular, the particular node uses the unlocking value determined in operation 1440 to unlock the corresponding T pay The transaction may be unlocked and then sent to the blockchain. pay A transaction may be unlocked by submitting the unlocking value into the transaction's unlocking script. In particular, as described above, unlocking a transaction with the unlocking value determined in operation 1440 and submitting it to the blockchain has the side effect of revealing the unlocking value on the blockchain.

[0163] Following operation 1450, selection by particular node is complete.

[0164] The protocols described herein may be applied to a wide variety of applications, such as in relation to autonomous vehicles, such as autonomous vehicle 400. In some such implementations, it may be that a possible outcome of a processing step associated with a given node participating in the protocols described herein may correspond to an output of an associated module of a control system of the vehicle. For example, the output may be an output of modules 410-440.

[0165] In implementing the protocols described herein on a given blockchain, various implementation details need to be taken into account. For example, in the Bitcoin blockchain, it is possible that a transaction's associated transaction ID may change while the transaction remains valid. This may be referred to as the transaction malleability problem. This is a problem that occurs when a refund transaction (T r ) and payment transactions (T pay This could pose a problem in the implementation of protocols such as those described herein that rely on payment channels where a transaction can be executed in a manner that references identifiers of previous transactions. Additional information on transaction malleability in Bitcoin can be found, for example, in “The Who, What, Why and How of the Ongoing Transaction Malleability Attack” by Aaron van Wirdum, published in Bitcoin Magazine on October 7, 2015. Transaction malleability can be eliminated by Bitcoin's Seg Wit fork - see, for example, “Segregated Witness Benefits”, available at https: / / bitcoincore.org / en / 2016 / 01 / 26 / segwit-benefits / (updated October 19, 2016).

[0166] It should be noted that the above-described embodiments are illustrative rather than limiting the subject matter of the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The terms "comprising" and "comprises", etc., do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes or consists of" and "comprising" means "including or consisting of". The singular reference of an element does not exclude the plural reference of such element and vice versa. The subject matter of the present invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. 1. A computer-implemented method for distributed control, comprising: receiving, by a particular node in the set of cyclically ordered nodes participating in the blockchain network, from a node immediately following said particular node, values ​​corresponding to combinations of possible outcomes of processing steps associated with nodes from said immediately following node to a node immediately preceding the supervisor node; the values ​​being based on public keys associated with the nodes, each corresponding to a possible outcome of a processing step associated with the node, and a public key of the supervisor node; Steps and generating, by said particular node, a state value based on said received value and a public key corresponding to a possible outcome of a processing step associated with said particular node; sharing, by the particular node, the state value with the supervisor node and with a node immediately preceding the particular node; transmitting control of resources between nodes in response to satisfaction of each of the execution and return conditions; A method comprising:

2. control of the resource is returned upon satisfaction of a return condition; The method of claim 1.

3. The return condition requires the signature of at least two nodes. The method of claim 2.

4. The nodes correspond to modules associated with the system; and the possible outcomes of a processing step associated with a given node correspond to an output of an associated module of a control system of the system; The method of claim 1.

5. each of the received values ​​is determined by combining a public key associated with the supervisor node with values ​​of the public key corresponding to each combination of possible outcomes of processing steps associated with nodes from the immediately succeeding node through to the node immediately preceding the supervisor node; 5. The method according to any one of claims 1 to 4.

6. a given one of the received values ​​is determined by summing the public key associated with the supervisor node and a value of one of the public keys corresponding to a respective one of a combination of possible outcomes; The method according to claim 5.

7. the state value is formed by combining the received value with the public key corresponding to a possible outcome of a processing step associated with the particular node.

7. The method according to any one of claims 1 to 6.

8. each said state value being formed by summing one of said received values ​​with one of said public keys corresponding to a possible outcome of a processing step associated with said particular node; The method of claim 7.

9. The method further comprises: preparing a blockchain transaction configured to transmit control of a resource from a source address associated with the particular node to a receiving address of the immediately following node in response to satisfaction of an execution condition including provision by the particular node of any one of a plurality of unlocking values ​​corresponding to the received value using the state value; waiting for the blockchain transaction to be executed; and obtaining from the blockchain transaction a first unlocking value used to unlock the blockchain transaction; the first unlocking value being indicative of an output of a processing step associated with nodes from the immediately succeeding node to the node immediately preceding the supervisor node, and corresponding to the public keys associated with these nodes, and being based on a private key corresponding to the output; Steps and identifying one of the possible outcomes of the processing step associated with the particular node; determining, by the particular node, a second unlocking value based on the identified result and a private key corresponding to the public key corresponding to the unlocking value; the second unlocking value corresponds to one of the state values ​​and is indicative of an output of a processing step associated with a node from the particular node to a node immediately preceding the supervisor node; Steps and using the second unlocking value to execute another blockchain transaction; and The method of any one of claims 1 to 8, comprising:

10. The other blockchain transaction is configured to transmit control of a second resource from a source address associated with the previous node to a receiving address of the particular node in response to satisfaction of a second execution condition prepared by the previous node and including provision of any one of a second plurality of unlocking values ​​corresponding to one of the state values; and After the preparation of the other blockchain transaction, a blockchain transaction is prepared that is configured to transmit control of the resource from the source address associated with the particular node to the receiving address of the immediately subsequent node.

10. The method of claim 9.

11. each unlocking value of the second plurality of unlocking values ​​corresponds to a respective one of the state values ​​and is based on a private key corresponding to the public key on which the state value is based; The method of claim 10.

12. the unlocking value being the sum of the private keys corresponding to the outputs of processing steps associated with the nodes from the immediately succeeding node to the node immediately preceding the supervisor node and the private key corresponding to the public key associated with the supervisor node; 12. The method according to any one of claims 9 to 11.

13. the second unlocking value being the sum of the private key corresponding to the output of the processing step associated with the nodes from the particular node to the node immediately preceding the supervisor node and the private key corresponding to the public key associated with the supervisor node; 12. The method according to any one of claims 9 to 11.

14. the resource and the second resource are identical; 12. The method according to claim 10 or 11.

15. Each public key and the corresponding private key form an elliptic curve cryptography public-private key pair.

15. The method according to any one of claims 1 to 14.

16. A computer implemented system for carrying out the method of any one of claims 1 to 15.

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

Images