Distributed consensus system with rounds

Abstract

The invention relates to a distributed consensus system (400) for maintaining a replicated state. A leader device receives round confirmation messages for a preceding round and one or more respective transaction messages for a current round from a set of follower devices. The leader device distributes the confirmations and transactions on the replicated state to the follower devices. The follower devices send round confirmation message comprising a cryptographic signature for confirming the current round.

Description

[0001] DISTRIBUTED CONSENSUS SYSTEM WITH ROUNDS

[0002] FIELD OF THE INVENTION

[0003] The invention relates to a computer-implemented distributed consensus system; to a leader device, a follower device, and a submitter device for use in such a system; and to a cryptographic system comprising the distributed consensus system. The invention further relates to corresponding computer-implemented cryptographic methods; and to a corresponding computer-readable medium.

[0004] BACKGROUND OF THE INVENTION

[0005] In distributed systems, data may be replicated among multiple devices to increase resilience. Technical measures may be taken to ensure that the data remains consistent among the different copies of the data that these multiple devices hold. This consistency property can be guaranteed in the face of various types of faults, e.g., crashes, omissions, or Byzantine faults where one or more of the devices are corrupted devices that actively try to interfere. In particular, the respective devices may keep track of respective copies of a system state. Techniques for ensuring that this state remains consistent in the face of faults are referred to as state machine replication techniques. Desired properties of such a system include safety, which represents the consistency of the respective copies of the state; and liveness, which represents the guarantee that updates are eventually applied, e.g., even in case of failures.

[0006] Over the last years, in the context of distributed ledgers, many systems have been developed in which data is distributed among a large number of devices (for example, thousands or more). Specialized techniques, such as proof-of-stake or proof- of-work, are used to ensure that there is consensus on the contents of the ledger under certain assumptions on the set of corrupted devices. For example, consistency may hold under the assumption that the corrupted parties do not hold a majority of computational resources. Such distributed ledgers can also provide a degree of robustness against the case when one or more devices become unresponsive.

[0007] However, such existing distributed ledger systems may be less suitable for ensuring consistency when the number of devices is much smaller; for example, when there is a fixed set of only three, four, or five devices. Namely, such distributed ledger systems may incur a relatively large overhead, and security models in terms of proof-of-stake and proof-of-work may not provide appropriate guarantees if the number of parties is so small. Accordingly, it would be desirable to provide techniques for state machine replication that are more suitable for use with a smaller number of devices (say, 2, 3, or at most 50) in terms of security and / or efficiency.

[0008] SUMMARY OF THE INVENTION

[0009] In accordance with a first aspect of the invention, a computer- implemented distributed consensus system is provided, as defined by claim 1. In accordance with further aspects of the invention, a leader device, a follower device, and a submitter device for use in such a system are provided, as defined by claims 9, 10, and 11 , respectively. In accordance with still further aspects of the invention, cryptographic methods are provided corresponding to the above devices, as defined by claims 12, 13 and 14, respectively. In accordance with an aspect of the invention, a cryptographic system comprising a distributed consensus system is provided, as defined by claim 15. In accordance with an aspect of the invention, a computer- readable medium is provided, as defined by claim 16.

[0010] Various embodiments relate to a distributed consensus system for maintaining a replicated state, e.g., a distributed ledger system. In general, a state may be a data structure that may be operated upon by applying a transaction. A transaction may result in an updated state and / or an output value. A transaction may also be referred to as a command. A replicated state may also be referred to as a ledger. For example, the Bitcoin ledger is an example of a replicated state. In such an example, the ledger may comprise transactions from and to public keys. A transaction may represent the execution of a script, leading to an update to this mapping. Another example of a state can be a database. In this example, a transaction may be a database query or a database transaction. Such a transaction may result in an updated state of the database and / or a result of the database query or database transaction.

[0011] The distributed consensus system may use multiple rounds. A round may comprise zero or more transactions to be applied to the replicated state. In other words, the distributed consensus system may be a distributed ledger system for maintaining a ledger, wherein the ledger comprises multiple rounds, and wherein a round comprises zero or more transactions, e.g., entries of the ledger. Generally, a transaction can be any kind of data, e.g., non-technical data such as a financial transaction, to be appended to a log; or technical data, such as a database transaction or other type of operation to be applied to a stateful object. The consensus system may guarantee, under certain conditions, that all participants agree on the set of transactions; on the rounds that they are associated with; and optionally also on a well- defined ordering of transactions within a round.

[0012] The replicated state may be an append-only ledger, in the sense that the set of transactions that make up a round is fixed at some point in time and may not be changeable any more later on. It is noted that despite the ledger itself being append- only, a transaction comprised in it may represent an instruction to modify existing data external to the ledger, e.g., an instruction to remove one or more records from a database.

[0013] In some cases, the participants to the system may keep a history of all transactions that have been applied to the state, in other words, are part of the ledger, but this is not needed. For example, a participant may be configured not to keep old transactions, e.g., after a certain number of rounds, after a certain number of later transactions, and / or after a certain amount of time. Or, a participant may be configured to keep track of the state that results from applying the transactions, in which case keeping a history of the state, and / or keeping a history of the transactions themselves, may not be needed.

[0014] Interestingly, the inventors envisaged to use a distributed consensus system having as participants different devices with different roles. In particular, the distributed consensus system may comprise a leader device and one or more follower devices. A follower device may submit a transaction to the leader device. The leader device may turn zero or more received transactions into a round of the system. For security purposes, the follower devices may be operated by different entities. The leader device can be operated by the same entity as a follower device, or can be combined with a follower device into a single device. The leader device can optionally also provide zero or more transactions to be included into the round itself. Apart from the leader and follower devices, there can optionally be one or more submitter devices, as also discussed in more detail elsewhere.

[0015] The inventors realized that, when the number of devices involved in the distributed consensus system is relatively small, such a leader-follower set-up can provide advantageous security and efficiency properties, when combined with suitable use of cryptographic signatures. As is known per se in the art, a cryptographic signature, also sometimes referred to as a digital signature, is cryptographic technique by which the authenticity of a message can be verified with respect to the public key of its sender.

[0016] In particular, various embodiments may make use of round confirmation messages. In a current round, the leader device may send, to a follower device, the transactions of the current round and the round confirmation messages for a preceding round, at least from the other device other than the follower device itself. The follower device may respond by sending a round confirmation message to the leader device, wherein the round confirmation message comprises a cryptographic signature by the follower device for confirming the current round. For example, the cryptographic signature may be based on the transactions of the round, and on the round confirmation messages of the other follower devices, and also optionally its own round confirmation message of the preceding round.

[0017] Interesting, by using round confirmation messages, it may be achieved that the leader and follower devices obtain a consistent view of the replicated state, e.g., the ledger. By signing round confirmation messages, and by also basing the confirmation messages on verifying confirmation messages of the other devices, essentially, a common knowledge among the parties may be attained of which transactions are applied to the replicated state, in other words, comprised in the ledger.

[0018] In particular, the cryptographic signature of the round confirmation message may be based on the transaction(s) of the current round. By providing the round confirmation message, a follower device may indicate that it confirms the transactions of the current round, and that it confirms that the round confirmation messages of the other parties correspond to its view of the replicated state. The round confirmation messages of the other parties can be included in the payload of the cryptographic signature, although a consistency guarantee can also be obtained without this.

[0019] As the inventors realized, although a certain degree of divergence is possible, the techniques described herein allow to detect this divergence relatively quickly. Namely, in a given round, a follower device may receive round confirmation messages of the other follower devices relating to the preceding round. Since a follower device may be configured to only confirm a round a single time, this means that, if the follower device agrees with all other followers on the transactions of that preceding round, consistency at least of that preceding round may be guaranteed, and thereby, the preceding round may be fixed.

[0020] It may be noted that the follower device does not know at this point whether all other follower devices also know that the preceding round has been fixed; for example, another follower device may fail to receive the round confirmation messages from the leader device. It may also be noted that a follower device may fail to send a round confirmation message. Accordingly, at least without taking additional measures, leader and follower devices may be able to cause the distributed consensus system to stop working. Effectively, instead of offering complete robustness, the distributed consensus system may be secure with abort, as it is referred to in the cryptographic literature, see, e.g., J. Bartusek et al., "On the Communication Complexity of Secure Multi-Party Computation With Aborts" (incorporated herein by reference insofar as the definition of security with abort is concerned). Such a system may also be referred to as a system for Byzantine fault safe state machine replication, or as a system for providing abortable Byzantine fault tolerance. Regardless of robustness, however, interestingly, strong consistency guarantees may be obtained. Regardless of how many devices of the system may act maliciously, e.g., by failing to respond or sending different messages than expected, in a current round, a device may be sure that there can be only one valid view of the transactions up to the preceding round. On the other hand, the device may at this point not yet know if all other devices have the same view, or if they have aborted. However, the device may know that all parties have the same view up to the round before the preceding round. It may also be noted that the views of the devices on the current round may differ between devices, e.g., if the leader device selects different transactions for the current round for submission to different follower devices. Still, the security guarantee that there is only one valid view of the preceding round, is a strong security guarantee that interestingly can be provided with the current techniques regardless of the number of parties that actively try to interfere, and with a relatively small computational and communication complexity. In particular, by using transactions and round confirmations, effectively, consensus among the parties may be reached in two rounds, regardless of the number of parties, whereas, for example, using Dolev- Strong authenticated broadcast, it may take t+1 rounds to reach consensus, where t is the number of adversarially controlled parties. For example, with three parties and two corruptions, the number of rounds may be reduced from three to two. With a larger number of parties, the advantage can be even bigger, for example, with five parties and four corruptions, the number of rounds may be reduced from five to two.

[0021] Optionally, a follower device may be configured to verify that the current round includes a transaction provided after confirming the preceding round or the round preceding the preceding round. Thereby, it may be guaranteed that the leader includes the transaction of the follower device in the replicated state, e.g., the ledger, at a point in time. A fixed time window in which the follower device can provide transactions to the leader device may not be needed. Namely, absent such a time window, it is possible that the leader device closes the current round while the follower device is sending the transaction. In this case, the leader device may include the transaction in the next round. To account for this possibility, the follower device may verify that a transaction is included either in a current round or the next round, but not later. This way, in addition to ensuring a consistent view, also the inclusion of transmitted transactions may be ensured to the extent possible.

[0022] If there is a fixed time window to submit transactions, the follower device may instead verify that a submitted transaction is included in the next round, thereby more quickly obtaining the guarantee that the transaction is included.

[0023] Optionally, a respective transaction message may further comprise a cryptographic signature by the respective follower device on the transaction. While not needed to achieve the consistency guarantee on the previous round described above, this signature may effectively provide a degree of assurance at an earlier point in time that the follower device did actually submit the transaction. This is particularly beneficial when the transaction represents an operation to be performed, in which the signature may effectively represent an authorization by the respective follower device to perform the operation, and / or to disclose its results, for example to a submitter device. By using a signature on the transaction, this authorization may be obtained before actually performing the operation, as opposed to obtaining this authorization later in the form of the confirmation message of that follower device for the next round.

[0024] Optionally, a transaction message that is signed by a follower device, and / or the cryptographic signature of a round confirmation message, may be based on a round identifier of the current round. Thereby, mixing of messages from different rounds may be prevented. Further, a global identifier of the replicated state may be included, to prevent mixing messages from different replicated states. Such messages may not be needed, for example, if there is only one replicated state in use at the same time and / or if other parts of the signed payload can be used to detect mixing of messages between rounds or states.

[0025] Optionally, a transaction of the distributed consensus system may be sent to a follower device by a submitter device. The submitter device can be part of the distributed consensus system, or can be external to it. As a response to sending the transaction, the submitter device may receive, for example from this follower device, the respective round confirmation messages of the one or more follower devices; and may verify the cryptographic signatures of the round confirmation messages using the transaction. Interestingly, in this way, the round confirmation messages from the distributed consensus system may provide guarantees about the consistency of the replicated state also to devices other than the leader and followers.

[0026] In particular, by receiving and verifying round confirmation messages from the follower devices for the round that includes the transaction, the submitter device may obtain the guarantee that replicated state either includes the transaction, or is in an aborted state. This guarantee may be sufficient in many cases, and can be obtained quickly after the current round. By receiving round confirmation messages for the round following the round that includes the transaction, the submitter device may obtain the stronger guarantee that there is agreement among the leader and follower devices that the transaction is actually included in the state, e.g., instead of an abort, at the expense of waiting for this next round.

[0027] Optionally, the submitter device may be configured to verify the respective round confirmation messages without using further transactions of the current round. For example, the signed payload of a round confirmation message can be based on hashes of the transactions of the round, for example in the form of a hash list or a hash tree. Thereby, to verify that one or more transactions are included in the round, knowledge of further transactions may not be needed. This is advantageous for performance reasons but especially also because of data privacy, since it allows data that is irrelevant to the submitter device, to remain hidden from it.

[0028] Optionally, a transaction may represent an operation to be applied to a stateful object. The stateful object can for example be a database, where the operation may comprise reading from and / or writing to the database. Or, the stateful object can be an accumulator, for example a Bloom filter or a cryptographic accumulator, for representing a set in such a way that it is possible to check set membership without inspecting individual items. The operation can be an update of the accumulator, for example, having the new accumulator state as result. Many other useful stateful objects and corresponding operations can be envisaged.

[0029] The replicated state may represent a stateful object, which may be held by the respective follower devices. The follower devices may be configured to apply the operation, for example, upon receiving the transactions of the current round from the leader device. When using the consensus system in combination with a stateful object, it may not be needed to keep a history of previous versions of the stateful object and / or to keep a history of the performed transactions; but it is also possible to keep such a history, e.g., in a time-limited or data-limited form, to allow roll-back of the state if needed.

[0030] Optionally, the payload of the cryptographic signature in the round confirmation message may be based on a result of applying the operation to the stateful object, for example, a hash of the result may be included in the payload. One advantage of basing the confirmation on the result, is that the submitter devices can thereby obtain an assurance that their views of the stateful object are consistent. This is particularly important if the stateful object and / or operations are relatively complex, e.g., queries such as SQL queries on a database, so that differences between different implementations could conceivably exist. Verifying the result can provide robustness in such cases. Another advantage is that also other devices than the leader and follower device, such as the submitter device that has submitted the transaction, can verify the result of the operation guarantees. The round confirmation messages may guarantee to such a party that at least all follower devices agree on the result.

[0031] Depending on the object, on the operations, and on the purpose of basing the conformation on the result, various information about the result may be included in the payload, for example, one or more of: a number of rows of a table affected by the operation; the affected rows; and the full table or a checksum over it. Optionally, applying the operation may comprise verifying whether the operation is authorized. For example, the authorization may be according to an authorization policy common to the follower devices, and / or according to respective authorization policies for the different follower devices. The authorization may be based on a cryptographic signature on the operation, e.g., by the submitter device and / or the follower device. Thereby, a robustly secure way of performing operations on the stateful object may be obtained, where, effectively, authorization decisions concerning operations may be distributed among the follower devices, and the operation represented by the transaction only finally becomes part of the state if all follower devices agree that it may be executed, for example, by the given submitter device. Here, different submitter devices can all enforce the same authorization policy, providing additional assurance that the policy is met even if one or more submitter devices misbehave; and / or the different submitter devices can enforce different authorization policies, allowing to obtain a distributed authorization system where the parties operating respective follower devices have strong guarantees that they have the power to block operations that they consider to be unauthorized.

[0032] In general, the system described herein can be configured with a leader device and one or more follower devices. The leader device can be combined with a follower device in a single device, and / or the leader device can include one or more transactions of its own into the current round without having received them from a follower device. If the leader device contributes one or more transactions, it may be noted that for the security of the system it may not be needed for the leader device to cryptographically sign the transactions and / or confirmations on them.

[0033] The number of transactions in a round can in general be zero, one, or more. For example, respective follower devices can contribute respective sets of zero, one, or more transactions. For example, the leader device can restrict the follower devices to include at most one transaction per round, allowing for a particularly efficient implementation with a small code base. It is also possible for a round to contain zero transactions. For example, the leader device may be configured to initiate a zerotransaction round after a given timeout, for example, following a round with one or more transactions. This way, it can be avoided that the follower devices, and / or the submitter device, have to wait for too long to obtain a confirmation of the transaction(s) of the round before.

[0034] Optionally, the round confirmation message may be based on a nonce for confirming freshness of a transaction to its submitter device. The nonce can for example be a value provided by the submitter device to the follower device. By using the nonce, it may be prevented that the follower device can replay an earlier identical query to the submitter. Instead of using a nonce that is provided by the submitter device, it is also possible to a nonce in the form of a timestamp, for example, generated by the follower device that receives the transaction from the submitter device.

[0035] Optionally, the distributed consensus system may be for use in a cryptographic system for performing a privacy-preserving computation on secret data. The cryptographic system may comprise multiple cryptographic devices. The multiple cryptographic devices may be configured to perform the computation as a cryptographic secure multi-party computation between the multiple cryptographic devices. The computation may comprise computing an object, such as a database table, as secret data of the multi-party computation. The replicated state may be used to store computation data relating to one or more performed privacy-preserving computations, which data may not need to be kept encrypted. For example, the computation data may include metadata of one or more computations, and / or of one or more objects computed by the cryptographic system. For example, the metadata may include the number of rows, the number of columns, column names, and / or column types, of a table, and the like. By storing such computation data using a replicated state, the data may be stored in a way that it can be accessed in a flexible and efficient way, e.g., by means of database queries; while still providing strong guarantees of correctness of the data, e.g., even if one of the cryptographic and / or follower devices acts in a malicious way. The computation data can also comprise, e.g., a log of performed privacy-preserving computations, and / or a list of authorizations for performing privacy-preserving computations, etc.

[0036] It will be appreciated by those skilled in the art that two or more of the above-mentioned embodiments, implementations, and / or optional aspects of the invention may be combined in any way deemed useful. Modifications and variations of any method and / or any computer readable medium, which correspond to the described modifications and variations of a corresponding computer-implemented device or system, can be carried out by a person skilled in the art on the basis of the present description, and the other way round as well.

[0037] BRIEF DESCRIPTION OF THE DRAWINGS

[0038] These and other aspects of the invention will be apparent from and elucidated further with reference to the embodiments described by way of example in the following description and with reference to the accompanying drawings, in which:

[0039] Fig. 1 shows a leader device;

[0040] Fig. 2 shows a follower device;

[0041] Fig. 3 shows a submitter device;

[0042] Fig. 4 shows a distributed consensus system; Fig. 5 shows a distributed consensus system;

[0043] Fig. 6a shows a query message;

[0044] Fig. 6b shows a result of applying an operation to a stateful object;

[0045] Fig. 6c shows a transaction message;

[0046] Fig. 6d shows a round message;

[0047] Fig. 6e shows a round confirmation message;

[0048] Fig. 6f shows a response message;

[0049] Fig. 7 shows a leader method;

[0050] Fig. 8 shows a follower method;

[0051] Fig. 9 shows a submitter method;

[0052] Fig. 10 shows a computer-readable medium comprising data;

[0053] Fig. 11 shows a cryptographic system.

[0054] It should be noted that the figures are purely diagrammatic and not drawn to scale. In the figures, elements which correspond to elements already described may have the same reference numerals.

[0055] DETAILED DESCRIPTION OF EMBODIMENTS

[0056] Fig. 1 shows a leader device 100. Device 100 may be for use in a distributed consensus system as described herein, e.g., with respect to Fig. 4 or Fig. 5. Such a system may be referred to as a distributed ledger system. The distributed consensus system may be for maintaining a replicated state 040, e.g., a ledger. The distributed consensus system may use multiple rounds. A round may comprise zero or more transactions. The distributed consensus system may comprise one or more follower devices.

[0057] The device 100 may comprise a data interface 120 for accessing data 040 representing the replicated state. As shown in the figure, the data interface may further be for accessing additional data, such as transaction data 030 representing a transaction to be applied to the replicated state, e.g., included in the ledger. For example, as also illustrated in Fig. 1, the input interface may be constituted by a data storage interface 120 which may access 122 the data 030, 040 from a data storage 021. For example, the data storage interface 120 may be a memory interface or a persistent storage interface, e.g., a hard disk or an SSD interface, but also a personal, local or wide area network interface such as a Bluetooth, Zigbee or Wi-Fi interface or an ethernet or fibreoptic interface. The data storage 021 may be an internal data storage of the system 100, such as a hard drive or SSD, but also an external data storage, e.g., a network-accessible data storage. In some embodiments, the data 030, 040 may each be accessed from or distributed across different data storages, e.g., via a different subsystem of the data storage interface 120. Each subsystem may be of a type as is described above for data storage interface 120. The data interface 120 may internally communicate with processor subsystem 140 via data communication 121.

[0058] The device 100 may further comprise a communication interface 180. The communication interface may be configured for communication with at least the one or more follower devices. Communication interface 180 may internally communicate with processor subsystem 140 via data communication 125. Communication interface 180 may be arranged for direct communication with the other devices, e.g., using USB, IEEE 1394, or similar interfaces. As illustrated in the figure, communication interface 180 may also communicate 126 over a computer network 099, for example, a wireless personal area network, an internet, an intranet, a LAN, a WLAN, etc. For instance, communication interface 180 may comprise a connector, e.g., a wireless connector, an Ethernet connector, a Wi-Fi, 4G or 4G antenna, a ZigBee chip, etc., as appropriate for the computer network. Communication interface 180 may be an internal communication interface, e.g., a bus, an API, a storage interface, etc.

[0059] The device 100 may further comprise a processor subsystem 140. Processor subsystem 140 may be configured to receive, via the communication interface 180, respective round confirmation messages for a preceding round of the multiple rounds from the respective one or more follower devices. The processor subsystem 140 may be further configured to receive, via the communication interface 180, one or more respective transaction messages for a current round of the multiple rounds from one or more respective follower devices. A respective transaction message may comprise a respective transaction. The processor subsystem 140 may be further configured to send, via the communication interface, respective round messages to the respective one or more follower devices. A round message for a follower device may comprise at least the transactions and the round confirmation messages of the other follower devices.

[0060] Fig. 2 shows a follower device 200 for use in a distributed consensus system as described herein, e.g., with respect to Fig. 4 or Fig. 5, e.g., a distributed ledger system. The distributed consensus system may be for maintaining a replicated state, e.g., a ledger. The distributed consensus system may comprise multiple rounds. A round may comprise zero or more transactions to be applied to the replicated state. The distributed consensus system may comprise a leader device and optionally also one or more other follower device devices in addition to device 200.

[0061] In general, the follower device 200 may be as described for device 100 of Fig. 1. In particular, device 200 may comprise a data interface 220, a processor subsystem 240, and / or a communication interface 280, for which the same options are available as discussed for device 100 of Fig. 1. Also communication 221 , 222, 225 may be as described in Fig. 1. Device 100 and device 200 are in many cases distinct devices, although it is also possible to combine them into a single device. In particular, the follower device 200 may comprise a data interface 220. The data interface may be for accessing, e.g., from a data storage 022, transaction data 030 representing a transaction 030 to be applied to the replicated state, e.g., added to the ledger, and data 040 representing the replicated state, e.g., the ledger, itself.

[0062] As discussed, the follower device 200 may comprise a communication interface 280, e.g., based on communication interface 180 of Fig. 1. The communication interface 280 may be configured for communication with the leader device and / or with a submission device. For example, as illustrated in the figure, the communication interface 280 may be for communication 226 over a computer network 099 such as the internet or a local area network.

[0063] Processor subsystem 240 may be configured to receive, via the communication interface 280, a round message from the leader device. The round message may comprise one or more transactions for a current round of the multiple rounds from respective other follower devices; and round confirmation messages of the other follower devices for a preceding round of the multiple rounds. Processor subsystem 240 may be further configured to send, via the communication interface, a round confirmation message for the current round to the leader device. The round confirmation message may comprise a cryptographic signature by the follower device for confirming the current round.

[0064] Fig. 3 shows a submitter device 300. The device 300 may be for use in, or for use in combination with, a distributed consensus system as described herein, e.g., with respect to Fig. 4 or Fig. 5. The distributed consensus system may be for maintaining a replicated state. The distributed consensus system may use multiple rounds. A round may comprise zero or more transactions. The distributed consensus system may comprise a leader device and one or more follower devices.

[0065] In general, the device 300 may be as described for device 100 of Fig. 1. In particular, device 300 may comprise a data interface 320, a processor subsystem 340, and / or a communication interface 380, for which the same options are available as discussed for device 100 of Fig. 1. Also communication 321 , 322, 325 may be as described in Fig. 1. Device 300 is typically distinct from devices 100 and 200, although it is possible to combine them in a single device.

[0066] In particular, the authorization device 200 may comprise a data interface 220. The data interface may be for accessing, e.g., from a data storage 023, transaction data 030 representing a transaction to be applied to the replicated state, e.g., included in the ledger. As discussed, the device 300 may comprise a communication interface 380, e.g., based on communication interface 180 of Fig. 1. The communication interface 380 may be configured for communication with a follower device. For example, as illustrated in the figure, the communication interface 380 may be for communication 326 over a computer network 099 such as the internet or a local area network.

[0067] Processor subsystem 340 may be configured to send, via the communication interface 380, a transaction to the follower device. Processor subsystem 340 may be further configured to receive, via the communication interface 380, respective round confirmation messages for a current round of the multiple rounds of the one or more follower devices. A round confirmation message may comprise a cryptographic signature by a respective follower device for confirming the current round. Processor subsystem 340 may be further configured to verify the cryptographic signatures of the round confirmation messages using the transaction.

[0068] In general, each device described in this specification, including but not limited to devices 100, 200, 300 of Figs. 1-3, may be embodied as, or in, a single device or apparatus, such as a workstation or a server. The device may be an embedded device. The device or apparatus may comprise one or more microprocessors which execute appropriate software. For example, the processor subsystem of the respective system may be embodied by a single Central Processing Unit (CPU), but also by a combination or system of such CPUs and / or other types of processing units. The software may have been downloaded and / or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash. Alternatively, the processor subsystem of the respective system may be implemented in the device or apparatus in the form of programmable logic, e.g., as a Field-Programmable Gate Array (FPGA). In general, each functional unit of the respective system may be implemented in the form of a circuit. The respective system may also be implemented in a distributed manner, e.g., involving different devices or apparatuses, such as distributed local or cloud-based servers.

[0069] Fig. 4 shows a distributed consensus system 400. As shown in the figure, the distributed consensus system 400 may comprise a leader device LD, 410. Typically, there is only a single leader device in system 400. Further, system 400 may comprise one or more follower devices. By way of illustration, the figure shows three follower devices FL1 , 421; FL2, 422; and FL3; 423. The number of follower devices can for example be at most or at least three; at most or at least five; or at most or at least ten. In principle, there is no limit to the number of follower devices in the system 400; but the system is particularly advantageous when there is a relatively small number of follower devices, say at most 50 or at most 100; in such cases, the system can provide an efficient distributed consensus while robustness against subsets of misbehaving parties may be less of an issue than in a large-scale consensus system with multiple thousands parties, say. The leader device LD can optionally be combined with a follower device FLi in a single device.

[0070] System 400 may be for maintaining a replicated state, such as a ledger. Respective follower devices FLi may maintain representation LG, 441 , 442, 443, of the replicated state. The distributed consensus system may use multiple rounds. A round may comprise zero or more transactions. A representation LG of the replicated state may comprise an ordered history of transactions; for example, the set of most recent, or all previous, transactions of the system. Instead or in addition, a representation LG of the replicated state may comprise data representing a stateful object, with transactions representing operations to be applied to the stateful object, and with one, more, or all of the follower devices FLi being configured to apply the operations to the stateful object.

[0071] By way of illustration, the figure shows a replicated state representing a database, in which case a transaction may represent one or more read and / or write operations to be applied to the database. By using system 400, the follower devices RLi may obtain assurance that their respective representations of the replicated state LG are based on the same set of transactions, divided into the same rounds, and typically also ordered within these rounds in the same way; and, as a consequence, that the state of the stateful object is consistent among the follower devices.

[0072] The system may proceed in a number of rounds. For example, the leader device LD may initiate a new round after a maximum time interval since the previous round, e.g., an interval of at most or at least a second, or at most or at least ten seconds, at least since a previous round with a non-zero number of transactions. Instead or in addition, the leader device LD may initiate a new round when receiving a certain number of transactions for the new round, e.g., when receiving at least one transaction; when receiving at least two transactions from the same follower device FLi, etc. The leader and follower devices may be configured to operate the distributed consensus system without a limit on the number of rounds, for example, the leader and follower devices may be configured to operate the distributed consensus system for at least 100 rounds, at least 1000 rounds etc.

[0073] In a current round, one or more of the follower devices FLi may send respective transaction messages for the round to the leader device LD. A transaction message may comprise a respective transaction to be applied to the replicated state. The leader device LD may send respective round messages to the respective follower devices FLi. A round message for a follower device may comprise the transactions to be included in the round. The round message may further include respective round confirmation messages of the respective follower devices FLi for confirming a preceding round of the multiple rounds. In the first round of the system, the round confirmation messages may be left out, or may be for confirming introduction messages of the respective follower devices FLi. Upon receiving the round message, a follower device FLi may construct a round confirmation message for the current round, and may send the message to the leader device LD. The round confirmation message may comprise a cryptographic signature by the follower device FLi for confirming the current round.

[0074] The figure further shows a submitter device SM, 430. The submitter device SM may be considered to be a part of the distributed consensus system 400, or may be considered to be an external party interacting with the distributed consensus system. In any case, the submitter device SM may be configured to send a transaction to a follower device. By way of illustration, the submitter device SM in the figure sends the transaction to follower device FL1. Typically, the submitter device SM can send the transaction to any of the follower devices FLi, or optionally even to the leader device LD. The submitter device may be further configured to receive, typically from the same follower device FL1 , respective round confirmation messages of the one or more follower devices. The round confirmation messages may be for the round in which the leader device LD has applied the transaction to the replicated state. The submitter device SM may be configured to verify the cryptographic signatures of the round confirmation messages using the transaction. Thereby, the submitted device can obtain insurance, and also a proof that can be shown to third parties, that the transaction has been applied to the replicated state.

[0075] In particular, the cryptographic signature of the round confirmation message may be on at least a result of applying the operation to the stateful object. This way, the submitter device SM may also obtain assurance about the result of applying the operation. Moreover, the cryptographic signature can allow the respective follower devices FLi to compare their results for consistency in a robust way.

[0076] Fig. 5 shows a detailed, yet non-limiting, example of a distributed consensus system 500. This example may be based on the example of Fig. 4. Similarly to Fig. 4, this example shows a leader device LD, 501; a submitter device SM, 503 that submits a transaction to a follower device FL1 , 502; and a further follower device FL2, 502'. The figure shows messages of three subsequent rounds of the consensus system: a preceding round R1 , 591; a current round R2, 592; and a next round R3; 593. Detailed examples of the messages shown in this figure, are provided with respect to Figs. 6a-6f. In the preceding round R1 , the follower device FLi may be configured to send round confirmation messages SC, 515, to the leader device LD for confirming the preceding round.

[0077] In the current round R2, the submitter device may be configured to send a query message Q, 521 , to a follower device, representing a transaction to be applied to the replicated state. Optionally, the submitter device may be configured to cryptographically sign the transaction Q using a key of the device or of a user of the device. In the example shown in the figure, the submitter device SM sends the message Q to follower device FL1.

[0078] The follower device FL1 may be configured to send a transaction message ST, 533, to the leader device LD, including the transaction. Optionally, the transaction message ST may comprise a cryptographic signature by the follower device FL1, and / or a cryptographic signature by the submitter device SM. Generally, a follower device FLi can contribute zero, one, or more transactions to a round R2. A follower device FLi can send multiple transaction messages in a single round; or the system may be configured to restrict a follower device to a single transaction message TM per round.

[0079] The leader device LD may be configured to initiate the current round. The leader device LD may select the transactions to be included in the current round: for example, all transactions received so far from follower devices FLi, directly from submitter devices SM, and / or from other sources. The leader device LD can initiate the current round for example upon receiving all the round confirmation messages for the preceding round and at least a given number of transactions; for example, upon receiving one transaction; two transactions; or a transaction from every follower device.

[0080] The leader device LD can also initiate the current round for example after a given time-out since the previous round, e.g., at least if the previous round has a non-zero number of transactions. For example, the time-out can be at most or at least one second, or at most or at least ten seconds. In such a case, it is possible that the round contains zero transactions. A zero-transaction round may be used to achieve timely receipt of round confirmation messages by the follower devices FLi and / or submitter devices SM; namely, such devices may only obtain assurance about a transaction in a current round by receiving its confirmation in the next round, so it is desirable to guarantee that the next round takes place not too long after the current round.

[0081] The leader device LD may be configured to send respective round messages NR, 544, to the respective follower devices FLi. The leader device LD can send the same round message comprising all transactions of the current round R2 and round confirmations for the preceding round R1 ; but it is also possible to send respective messages where the leader device does not echo the transactions and / or round confirmations of a follower device back to the follower device itself.

[0082] Upon receiving the round message NR, a follower device FLi may verify that the current round R2 includes a transaction that the follower device FLi provided to the leader device LD. For example, the follower device FLi may verify that the current round R2 includes the transaction of the query message Q. However, since it is possible that the leader device LD initiates the current round R2 when it has not yet processed this transaction, it is also possible that the transaction becomes included in the next round. Accordingly, the follower device FLi may verify that the current round R2 includes a transaction Q provided after confirming the preceding round R1 , or that the current round R2 includes a transaction provided after confirming the round preceding the preceding round. For transaction Q, the follower device may detect misbehaviour upon failing to verify that the message was included in the current round R2 or the next round R3. The follower device may also verify that the transaction was not included multiple times, e.g., both in round R2 and in round R3.

[0083] Following the verification, a follower device FLi may construct and send a round confirmation message SC', 555, for the current round to the leader device LD. The round confirmation message SC' of a follower device FLi may comprise a cryptographic signature by the follower device FLi for confirming the current round R2. In case a current round has no transactions, it is possible to skip the round confirmation message.

[0084] The next round R3 may proceed as described for the current round R2. In particular, the leader device LD may send respective round messages NR', 564 to the respective follower devices FLi, where the round message NR' sent to a follower device FL1 may comprise at least the round confirmations for the current round R2 of the other follower devices FL2. Upon receiving the round message NR' confirming the round R2, the follower device FL1 may provide, for example in the form of a response message RP, 576, the respective round confirmation messages SC' for the round R2 to the submitter device SM that provided the transaction Q that was included in the round, thereby providing assurance to the submitter device SM that the transaction Q was applied to the replicated state, e.g., included in the ledger.

[0085] Generally, upon detecting a failure, e.g., an incorrect cryptographic signature or a failure to apply a transaction to the replicated state in timely way, any device SM, FLi, LD of the system described herein may react by aborting, e.g., by failing to provide further input to the system. As a consequence, malicious behavior such as the sending of an incorrect signature, at least between the leader and follower devices, may result in no more rounds of the consensus system being confirmed. Thus, effectively, consistency may be guaranteed as long as all parties behave correctly.

[0086] In more detail, the security guarantees of distributed consensus systems described herein, may be formalized in terms of an ideal functionality as follows. As is known per se from the cryptographic literature on multi-party computation, an ideal functionality describes the functionality of the system in terms an equivalent system that operates in an idealized world and that explicitly formalizes the power that an attacker has to interfere with the systems' operation.

[0087] In terms of such an attacker model, a system may be provided that is resilient against n-1 maliciously corrupted parties. In this setting, security with abort may be achieved, where the correct operation of the system may be based on the cooperation of all parties. For example, in the particular case where a follower device can contribute at most one transaction per round, security may be provided against the following ideal-world adversary. Consider n parties P1, ..., Pn connected to the ideal functionality Fc. The adversary may be static and may, before the protocol starts, choose to corrupt any n-1 parties. T e adversary may arbitrarily delay the stream of messages, but arrived messages are assumed to be in order. The protocol proceeds in rounds:

[0088] 1. At every round / , each honest party (that is not expecting a postponed transaction, see step 4) sends zero or one transaction to Fc

[0089] 2. The adversary decides whether to abort. If not, the protocol continues.

[0090] 3. The adversary decides which transactions for the corrupted parties will be included in the round. Transactions will be presented in order, so P1, ..., Pn, and earlier transactions may invalidate transactions occurring later.

[0091] 4. The adversary decides for each honest party whether to include or postpone their transaction. Postponed transactions are guaranteed to be in round i+1 if the adversary does not abort.

[0092] 5. Fc sends the included transactions for P1, ..., Pn to each party, including the postponed transactions from the last round.

[0093] Fig. 6a shows a detailed, yet non-limiting, example of a query message Q, 610. The query message Q may be sent by a submitter device to provide a transaction to a follower device.

[0094] In this example, the transaction REQ, 613 represents an operation to be applied to a stateful object; in this case, a request to perform one or more read and / or write operations on a database. For example, the query Q can include a statement Stmt 614 representing a database query, e.g., a SQL query, that can contain zero or more placeholders. The query Q can further include a set Pars, 615, of parameters to be inserted at the locations of the placeholders in the query. The use of a statement Stmt and parameters Pars can be used to verify in a convenient and robust way whether the operation is authorized by performing a pattern matching on the statement Stmt. It is also possible to perform such authorization differently, or not to perform authorization, however.

[0095] Although not shown in the figure, optionally, the query Q may comprise a cryptographic signature on the transaction. For example, the cryptographic signature may be with a key of the submitter device, or a key of a user of the submitter device. The cryptographic signature may be used to determine whether the query Q is authorized for the specific submitter and / or user.

[0096] Interestingly, the transaction may optionally include a nonce N, 612, e.g., selected randomly or using a counter by the submitter device. The nonce may be part of the payload that gets confirmed by the follower devices, and can be used to avoid a malicious follower from replaying an earlier identical query. The nonce N can for example be a time-stamp. The submitter device can verify whether the exact nonce is confirmed, or verify that the time-stamp is recent enough, for example.

[0097] Fig. 6b shows a detailed, yet non-limiting, example of a result R, 620 of applying an operation to a stateful object. A transaction of the consensus system may represent an operation to be applied to the stateful object. As also explained elsewhere, one or more of the follower devices may be configured to apply the operation. For example, in the case of a database query, the result R may include a set Rows, 621 , of database rows resulting from the query, and / or a counter NumAffected, 622, of affected rows. Because of the consistency properties of the distributed consensus system, respective follower devices may obtain the same result from applying the operation.

[0098] It is noted that it is not needed per se for all of the follower devices to perform the operation. For example, one or more follower devices may apply the operation, and one or more further follower devices may keep the set of transactions without applying the corresponding operations on a stateful object themselves. It is also possible to use the techniques described herein without a stateful object apart from the list of transactions itself.

[0099] Fig. 6c shows a detailed, yet non-limiting, example of a transaction message ST, 630. This transaction message may be sent by a follower device to a leader device. The transaction message ST may comprise transaction data T, 631, and preferably also a signature Sig(T), 635, by follower device, on the transaction data T. The signature may be forwarded to further follower devices and may allow the further follower devices to obtain assurance about the origin of the transaction data from the follower device before the follower device confirms the round with a later round confirmation message.

[0100] The transaction data may comprise one or more transactions Q1 , ..., Qk, 632, to be applied to the replicated state. The transactions Qi may be represented as described with respect to Fig. 6a.

[0101] The transaction data T may further comprise a round identifier RID, 633, of the current round. The follower device may set the round identifier RID to the next round number that the follower device has not seen. The follower may verify that the transactions Qi are included in this round, or the one after, and may abort otherwise. Allowing the transactions to be in the next round may account for communication being asynchronous, making it possible that the leader has initiated the next round at the same time that the follower sends its transaction request ST.

[0102] The transaction data T may further include data that uniquely identifies the replicated state. This can be a unique identifier of the replicated state, or, as illustrated in this example, data H(Sig(C)i |...), 634, based on previous messages from the consensus system, e.g., based on previous round confirmation messages. This example shows a hash of the signatures Sig(C) on round confirmation messages of the previous round being used, see Fig. 6d. In the first round, for example, the data can be based on signatures of the initial "Hello" messages by the follower devices. By including data that is specific to the current replicated state, security of the system under parallel composition can be obtained, e.g., it may be avoided that the leader device mixes messages from two different instances. It is also possible for example to use a hash chain based on an identifier x_0 of the instance, for example: x_0, x_1 = H(x_0), x_2 = H(x_1) = H(H(x_0)), ...; where x_0 is for example a concatenation of random strings of respective follower devices from an initial Hello message, and a message in round r includes x_{r-1 }.

[0103] Fig. 6d shows a detailed, yet non-limiting, example of a round message NR, 640. The round message may be sent by a leader device to follower devices.

[0104] The round message NR may be used by the leader device to announce a new round. The round can contain zero or more transactions. A transaction may be included in the round message NR by including respective transaction message ST1 , ..., STm, 642 from respective follower device who have contributed one or more transactions to the round, e.g., as discussed with respect to Fig. 6c. It is not needed for all follower devices to contribute transactions. The transactions may be ordered per follower device, for example. The order of the transactions in the round message NR may define the order in which they are applied to the replicated state, for example, operations may be applied to a stateful object in the same order in which they appear in the round message. If a transaction is invalid due to an earlier transaction, then such a faulty transaction may be skipped.

[0105] The round message NR may further comprise round confirmation messages SC1, ..., SCk, 643, of the follower devices for the preceding round, for example, as discussed with respect to Fig. 6e. Typically, all follower devices contribute a round confirmation message.

[0106] The leader device may send the same round message to respective follower devices, or can for example send respective messages to respective follower devices in which data from the respective follower device itself is not echoed back to it.

[0107] The number of transactions STi of a round can be zero. This can be the case for several reasons. An initial round message NR may be used to set up the replicated state, in which the round message NR may comprise, as round confirmation messages SCi, hello messages from the respective follower devices. This initial round message may comprise zero transactions. It is also possible to have a round with zero transactions if there are no transaction shortly after a previous round, e.g., a round which does have transactions. In this case, a zero-transaction round may be used by the leader device to distribute the round confirmation messages of the previous round to the follower device before any new transactions have been submitted.

[0108] As shown in the figure, the round message NR may comprise a round identifier. For example, the round identifier may be increased in respective rounds. For example, the counter can start at 0 and be increased by 1 for a new round.

[0109] Fig. 6e shows a detailed, yet non-limiting, example of a round confirmation message SC, 650. The round confirmation message may be sent by a follower device to a leader device. By sending the round confirmation message, the follower device may confirm that the round was received correctly and the transactions were applied.

[0110] The round confirmation message may comprise a signature Sig(C), 655, by the follower device on confirmation data C, 651 , for confirming a current round. The round confirmation message may not need to comprise the confirmation data itself since the follower devices can construct the confirmation data C themselves and thereby verify the signature Sig(C).

[0111] The confirmation data C may comprise a round identifier RID, 653, as also discussed with respect to Figs. 6c and 6d. The confirmation data C may be based on the transactions included in the current round. For example, the confirmation data may include the transactions, and optionally also the results of the transactions, directly. See Figs. 6a and 6b for examples of representations of transactions and their results.

[0112] However, interestingly, it is also possible to include the transactions and / or transaction results in hashed form. This allows for the confirmation data to be verified by a submitter device that does not need to know all transactions and their results themselves. In particular, a submitter device may verify that a transaction occurred in the current round, and may optionally also verify the transaction result, without using further transactions of the round.

[0113] For example, as illustrated in the figure, the confirmation data C may comprise respective hashes H(Q1 |R1), ..., H(Qk|Rk), 652, of respective transactionresult pairs. It is also possible to hash the transactions and results separately. It is particularly advantageous to use a hash tree, for example of transaction-result pairs, to allow the submitter device to efficiently verify that one or more transactions and / or results were included in the round, with a complexity that scales linear only in the number of transactions to be verified and only sub-linearly in the total number of transactions in the round.

[0114] The confirmation data C may further comprise data H(Sig(C)i |...), 654 that uniquely identifies the replicated state, as discussed in more detail with respect to Fig. 6c.

[0115] An initial round confirmation message SC may be used to set up the distributed consensus system, as also discussed elsewhere. Such an initial round confirmation message may have confirmation data C based on hello messages of the respective follower devices. A hello message can for example comprise a peer identifier and / or a contribution to a unique identifier of the replicated state.

[0116] Fig. 6f shows a detailed, yet non-limiting, example of a response message RP, 660 representing a response to sending a transaction. The response message may be sent by a follower device to a submitter device.

[0117] As shown in the figure, the response message RP may contain a result Ri, 663, of the transaction, e.g., in the case where the transaction represents an operation on a stateful object that has a response. The response can for example be as described with respect to Fig. 6b.

[0118] The response message RP may further comprise the cryptographic signatures Sig(C)j, 664 of the round confirmation messages, by which the respective follower devices confirm the round in which the transaction is included. The response message RP may contain further data by which the submitter device can, in combination with its own transaction(s), verify the cryptographic signatures Sig(C)j. This can include the round identifier RID, 661, for example, as also discussed elsewhere. Further, this can include one or more hashes HS, 662, of other transactions and / or transaction responses of further transactions in the round. For example, in combination with the example of Fig. 6e, hashes H(Qk|Rk) of further transaction-result pairs may be included in the response message RP; or, when using a hash chain, hashes of further transaction-result pairs forming authentication path(s) for the transaction(s) of the submitter device that were included in the current round.

[0119] Fig. 11 shows a detailed, yet non-limiting, example of a cryptographic system 010 that incorporates a distributed consensus system as described herein. System 010 may be for performing a privacy-preserving computation on secret data. In this example, the cryptographic system is combined into a single system with a distributed consensus system as described herein, e.g., system 400 of Fig. 4. The distributed consensus may be used to keep track of and / or store data related to privacy-preserving computations that are performed by the cryptographic system.

[0120] The cryptographic system 010 may in general comprise multiple input devices, multiple different cryptographic devices, and at least one result device, where the sets of input, cryptographic, and result devices may overlap with each other. As illustrated, the devices typically communicate over a computer network 099, e.g., the internet or a local network. Generally, these devices may have a hardware configuration as described for the leader device of Fig. 1.

[0121] In particular, shown in the figure are three cryptographic devices CP1 , 721 ; CP2, 722; and CP3, 723. In particular, a respective cryptographic device CPi may be combined with a respective leader device and / or a respective follower device into a single device. Generally, the number of cryptographic devices that is used can vary depending on the particular technique used for the multi-party computation and the security properties which are desired. For example, the number of cryptographic devices CPi can be two, three, four, or more. The cryptographic devices of the cryptographic system are typically distinct devices, e.g., operated by different organizational entities.

[0122] The cryptographic devices CPi may be configured to perform a secure multi-party computation (also known per se as multi-party computation, secure computation, or MPC). Generally, a multi-party computation may be a distributed protocol between the cryptographic devices for performing a computation in a privacypreserving way. Depending on the specific technique used, MPC may ensure privacy and / or correctness of the computation against an attacker that eavesdrops or controls one or more (but typically not all) of the cryptographic devices. As known per se, any computation can be performed as a multi-party computation (in other words, “under the multi-party computation”), but concrete computational and communication efficiency can in general greatly depend on how exactly the computation is performed. The used MPC protocol can for example be actively secure, passively secure, or covertly secure.

[0123] In particular, the multi-party computation can be performed based on one of the following techniques:

[0124] - based on secret sharing, in particular arithmetic secret sharing such as Shamir secret sharing, replicated secret sharing, or additive secret sharing. For example, the multi-party computation can be based on the techniques described in Shamir, “How to Share a Secret”, Communications ACM, 1979; Ben-Or, Goldwasser, Wigderson, “Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed Computation (Extended Abstract)”, Proceedings of the 20th Annual ACM Symposium on Theory of Computing, 1988; Chaum, Crepeau, Damgaard, “Multiparty Unconditionally Secure Protocols (Extended Abstract)”, Proceedings of the 20th Annual ACM Symposium on Theory of Computing, 1988; Ito, Saito, Nishizeki, “Secret sharing scheme realizing general access structure”, Electronics and Communications in Japan (Part III: Fundamental Electronic Science), 1989; Damgaard, Pastro, Smart, Zakarias, “Multiparty Computation from Somewhat Homomorphic Encryption”, proceedings CRYPTO 2012;

[0125] - based on garbled circuits, e.g., see Yao, “Protocols for Secure Computations (Extended Abstract)”, 23rd Annual Symposium on Foundations of Computer Science, Chicago, 1982;

[0126] - based on oblivious transfer, e.g., see Goldreich, Micali, Wigderson, “How to Play any Mental Game or A Completeness Theorem for Protocols with Honest Majority”, Proceedings of the 19th Annual ACM Symposium on Theory of Computing, 1987;

[0127] - based on threshold homomorphic encryption, e.g., see Cramer, Damgaard, Nielsen, “Multiparty Computation from Threshold Homomorphic Encryption”, proceedings EUROCRYPT 2001;

[0128] - based on fully homomorphic encryption, e.g., see Nigel P. Smart, "Practical and Efficient FHE-based MPC", proceedings IMACC 2023;

[0129] - based on any combination of the above, e.g., see Demmler, Schneider, Zohner, “ABY - A Framework for Efficient Mixed-Protocol Secure Two-Party Computation”, proceedings NDSS 2015.

[0130] Also shown in the figure are a number of input devices INP1 , 711; INP2, 712; up to INPk, 713. The input devices may be configured to input respective input data for the computation. The input devices 711-713 may use the hardware configuration discussed in Fig. 1. The number of input devices can be two, at most or at least three, or at most or at least five, for example. In many cases, the sets of inputs devices INPi and cryptographic devices CPi may wholly or partially overlap. For example, the set of input devices may be a subset or a superset of the set of cryptographic devices, or may be exactly the same.

[0131] Further shown is a result device RES, 730. The result device RES may be configured to obtain a result of the MPC based on the performed privacy-preserving computation. It is also possible for multiple respective result devices to obtain multiple respective results of the multi-party computation. Although illustrated as a separate device in the figure, the result device(s) RES can be the same devices as an input device INPi and / or cryptographic device CPi. Generally, the result device may be implemented using the hardware configuration discussed with respect to Fig. 1.

[0132] Many known multi-party computation techniques are defined per se for the case where the input and result devices INPi and RES form a subset of the set of cryptographic devices CPi that perform the MPC. To use such techniques in a setting where an input and / or result device does not perform the MPC itself, an input device can for example determine a secret representation, e.g., a secret sharing, and distribute it among the computation devices. Similarly, a result device can for example receive a secret representation, e.g., respective secret shares, of an output from the computation devices and derive the output from the secret representation. It is also possible to use specific techniques for letting an external party provide inputs to and / or obtain outputs from a multi-party computation. For example, the techniques from the following reference can be used: T. P. Jakobsen, J. B. Nielsen, and C. Orlandi. “A framework for outsourcing of secure computation”, proceedings CCSW’14.

[0133] Also shown is a requestor device REQ, 740. The requestor device REQ may be configured to request the cryptographic devices CPi to perform a computation as a cryptographic secure multi-party computation between the multiple cryptographic devices CPi. The computation may comprise computing an output object as secret data of the multi-party computation. The object can for example be a database table, a tensor of numeric data, a fitted machine learning model, or the like. Metadata of the object, such as the number of rows, and the number and type of columns, may be known to the cryptographic devices CPi, but the actual data in the object, e.g., the values of the database cells, may be secret data. As another example, in a fitted machine learning model, the type of model may be known to the cryptographic devices; the values of the fitted parameters may be secret. In general, there can be any number of requestor devices REQ; and these devices can be considered to be part of, or external to, the system 010. The computation may have as input objects zero, one, or more such objects. For example, a computation may be a database join on two database tables, resulting in a joined table; a model fit on a dataset, resulting in a fitted model; or a model prediction of a fitted model on a dataset, resulting in a set of predictions. The computation may further have a set of parameters that are known to the cryptographic devices CPi. For example, the set of parameters can indicate the column or columns on which to perform the database join; the number of iterations used for the model fit, etcetera. The respective input objects can be input by respective input devices INPi and / or may be outputs of previous computations. Similarly, the output object can be used later computations, and / or output, e.g., to one or more result devices RES. For example, the requestor device REQ may itself acts as an input device and / or as a result device.

[0134] The cryptographic system 010 may be configured to perform respective computations upon request by respective requestor devices REQ. Interestingly, the techniques described herein may be used to keep track of computation data related to the performed computations in a secure way. Namely, while the use of multi-party computation may provide certain guarantees on the security of the computation carried out per se, apart from this, in system 010 there may also be a need to securely store such computation data. For example, there may be a need for the cryptographic devices CPi to make available such computation data to other devices in a secure way, and / or for other devices to make such computation data available to the cryptographic devices CPi. For example, a device other than the cryptographic devices CPi may be configured to provide functionality to a user to inspect metadata of objects that have been input to and / or computed by the cryptographic devices CPi. Interestingly, the task of keeping track of such computation data may be performed by using a distributed consensus system maintaining a replicated state. For example, a transaction may represent an object that has been computed and / or a computation that has been performed. By using the techniques described herein, security guarantees may be attained for the correctness of this information.

[0135] In particular, the replicated state may be the state of a database, as also described elsewhere in this specification. In such a case, computation data may be inserted into the database by means of a transaction that represents a query to insert the computation data into the database, where the computation data can e.g. represent an object or a computation. Computation data may be retrieved in the form of a transaction that represents a query to retrieve the computation data from the database. In such cases, as also described elsewhere, the distributed consensus system may provide security guarantees with regard to the state of the database, and thereby also with regard to the correctness of information retrieved from it. In this case, it may not be needed to keep a history of transactions to allow the computation data to be used.

[0136] It is also possible to use the distributed consensus system in the context of a cryptographic system by having the transactions themselves directly represent the computation data, such as a record of a performed computation or of a computed object. The replicated state may comprise a log of the transactions, where the transaction is applied by appending the transaction to the log, e.g., the transaction may in this case not represent a database insertion query. In such a case, the distributed consensus system may provide security guarantees with respect to the consistency of these transactions, and thereby the computation data represented by them, between the participants of the distributed consensus system.

[0137] For example, the computation data may include metadata of one or more objects computed by the cryptographic system. For example, the metadata may include the number of rows, the number of columns, the column names, and / or the column types, of a table. Such data may be made available by the cryptographic devices CPi, e.g., for use by the cryptographic devices themselves and / or by other devices. Instead or in addition, the computation data may comprise a log of one or more performed privacy-preserving computations. For example, upon computing an object, the cryptographic devices CPi may add an entry to the replicated state representing the computation, e.g., based on the command for performing the computation and / or metadata of the input and / or output objects. As another example, the replicated state may be used to keep track of a list of authorizations for performing privacy-preserving computations. A transaction may represent the addition, removal, and / or modification of an authorization, for example, by a device that is different from the cryptographic devices CPi. The cryptographic devices CPi may be configured to determine whether to perform a computation based on whether the computation is authorized according to the authorizations as represented by the replicated state.

[0138] In particular, the figure shows a leader device LD, 750; and respective follower devices FL1 , 751; FL2; 752; and FL3, 753. The leader device and the follower devices may be as described with respect to Fig. 4. The respective follower devices FLi may be configured to maintain respective instances LG, 761, 762, 763 of the replicated state, e.g., in the form of keeping track of a history of transactions, or in the form of maintaining a database to which the database operations represented by transactions are applied.

[0139] In this figure, there are respective follower devices FLi that correspond to the respective cryptographic devices CPi and that may for example be operated by the same parties that operate the respective cryptographic devices. This is not needed, however; e.g., in a system with three cryptographic devices CPi, it may suffice to operate two follower devices, e.g., in a setting where privacy and security is in any case only guaranteed by the used multi-party computation protocol if there is an honest majority. As also described with respect to Fig. 4, the leader device can be combined with a follower device in a single device; instead or in addition, it is possible to combine a cryptographic device CPi with a follower device FLi into a single device as desired.

[0140] Various devices of the system may act as the submitter device as referred to in Fig. 4. For example, as discussed, parties other than the cryptographic devices, such as the requester REQ, may store information in or retrieve information from the replicated state. In such a case, such a party may act as a submitter device.

[0141] In cases where the cryptographic devices CPi enter a transaction, such as a computation log or object metadata, into the replicated state, there are various ways in which it may be guaranteed that the cryptographic devices CPi all agree on this information. One possibility is for the respective cryptographic devices to respectively insert a transaction into the replicated state, e.g., using an identifier of the cryptographic device; consistency of the data may then be verified by verifying the existence of the respective transactions on the replicated state, or of respective database records that have been inserted as a result of the transactions. As another possibility, for example, one of the cryptographic devices CPi may submit the data to the replicated state, and the other respective cryptographic devices CPj may check that the inserted data is correct; for example, by providing the data to a respective follower device FLj and letting the follower device check the data, e.g., before the respective follower device FLj provides their round confirmation message for the round. In the latter way, a respective cryptographic device CPj and corresponding follower device FLj may together avoid the cryptographic device CPi from inserting incorrect data into the database.

[0142] Generally, by storing metadata relating to the computations by the cryptographic devices CPi data in a replicated state with consensus, this metadata data may be stored in a way that it can be accessed in a flexible and efficient way, while still providing strong guarantees of correctness of the data, e.g., even if one of the cryptographic devices CPi and / or follower devices FLi acts in a malicious way.

[0143] Fig. 7 shows a block-diagram of a leader method 1700. The leader method 1700 may be for use in distributed consensus system as described herein. The distributed consensus system may be for maintaining a replicated state. The distributed consensus system may use multiple rounds. A round may comprise zero or more transactions to be applied to the replicated state. The distributed consensus system may comprise one or more follower devices. The leader method 1700 may be computer-implemented, e.g., may be performed by a leader device such as device 100 of Fig. 1. However, this is not a limitation, in that the method 1700 may also be performed using another system, apparatus or device.

[0144] The method 1700 may comprise, in an operation titled "COMMUNICATE", communicating 1710 with the one or more follower devices.

[0145] The method 1700 may comprise, in an operation titled "RECEIVE CONFIRMATIONS", receiving 1720 respective round confirmation messages for a preceding round of the multiple rounds from the respective one or more follower devices.

[0146] The method 1700 may comprise, in an operation titled "RECEIVE TRANSACTIONS", receiving 1730 one or more respective transaction messages for a current round of the multiple rounds from one or more respective follower devices. A respective transaction message may comprise a respective transaction.

[0147] The method 1700 may comprise, in an operation titled "SEND TRANSATIONS + CONFIRMATIONS", sending 1740 to the respective one or more follower devices, at least the transactions and the round confirmation messages of the other follower devices.

[0148] Fig. 8 shows a block-diagram of a follower method 800. The follower method 800 may be for use in the distributed consensus system according as described herein. The distributed consensus system may be for maintaining a replicated state. The distributed consensus system may use multiple rounds. A round may comprise zero or more transactions. The distributed consensus system may comprise a leader device and one or more other follower devices. The follower method 800 may be computer-implemented, e.g., may be performed by a follower device such as device 200 of Fig. 2. However, this is not a limitation, in that the method 800 may also be performed using another system, apparatus or device.

[0149] The method 800 may comprise, in an operation titled "COMMUNICATE", communicating 810 with the leader device.

[0150] The method 800 may comprise, in an operation titled "RECEIVE TRANSACTIONS + CONFIRMATIONS", receiving 820, from the leader device, one or more transactions for a current round of the multiple rounds from respective other follower devices, and round confirmation messages of the other follower devices for a preceding round of the multiple rounds.

[0151] The method 800 may comprise, in an operation titled "SEND CONFIRMATION", sending 830 a respective round confirmation message for the current round to the leader device. The respective round confirmation message may comprise a cryptographic signature by the follower device for confirming the current round. Fig. 9 shows a block-diagram of a submitter method 900. The submitter method 900 may be for use in the distributed consensus system according as described herein. The distributed consensus system may be for maintaining a replicated state. The distributed consensus system may use multiple rounds. A round may comprise zero or more transactions. The distributed consensus system may comprise a leader device and one or more other follower devices. The submitter method 900 may be computer-implemented, e.g., may be performed by a submitter device such as device 300 of Fig. 3. However, this is not a limitation, in that the method 900 may also be performed using another system, apparatus or device.

[0152] The method 900 may comprise, in an operation titled "COMMUNICATE", communicating 910 with at least a follower device of the one or more follower devices.

[0153] The method 900 may comprise, in an operation titled "SEND TRANSACTION", sending 920 a transaction to the follower device.

[0154] The method 900 may comprise, in an operation titled "RECEIVE CONFIRMATIONS", receiving 930 respective round confirmation messages of the one or more follower devices. A respective round confirmation message may comprise a cryptographic signature by a respective follower device for confirming a current round of the multiple rounds.

[0155] The method 900 may comprise, in an operation titled "VERIFY", verifying 940 the cryptographic signatures of the round confirmation messages using the transaction.

[0156] It will be appreciated that, in general, the operations of method 1700 of Fig. 7, method 800 of Fig. 8, and method 900 of Fig. 9. may be performed in any suitable order, e.g., consecutively, simultaneously, or a combination thereof, subject to, where applicable, a particular order being necessitated, e.g., by input / output relations. Methods 1700 and 800 can also be combined into an overall distributed consensus method. For example, one instance of method 1700 may be combined with one or more instances of method 800, wherein one instance of method 800 may optionally be performed by the same device as method 1700. Optionally, the distributed consensus method can also include method 900.

[0157] The method(s) may be implemented on a computer as a computer implemented method, as dedicated hardware, or as a combination of both. As also illustrated in Fig. 10, instructions for the computer, e.g., executable code, may be stored on a computer readable medium 1100, e.g., in the form of a series 1110 of machine-readable physical marks and / or as a series of elements having different electrical, e.g., magnetic, or optical properties or values. The medium 1100 may be transitory or non-transitory. Examples of computer readable mediums include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Fig. 10 shows an optical disc 1100.

[0158] Instead of, or in addition to, comprising instructions to perform a method described herein, the data 1010 may represent a digital signature on operation approval data for use in a cryptographic system as described herein.

[0159] Examples, embodiments or optional features, whether indicated as nonlimiting or not, are not to be understood as limiting the invention as claimed.

[0160] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or stages other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of” when preceding a list or group of elements represent a selection of all or of any subset of elements from the list or group. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may 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

32CLAIMS1. A computer-implemented distributed consensus system (400), wherein the distributed consensus system is for maintaining a replicated state; wherein the distributed consensus system uses multiple rounds; wherein a round comprises zero or more transactions to be applied to the replicated state; wherein the distributed consensus system comprises a leader device (410) and one or more follower devices (421-423), wherein: the leader device (410) is configured to: receive, from the respective one or more follower devices, respective round confirmation messages for a preceding round of the multiple rounds; receive, from one or more respective follower devices, one or more respective transaction messages for a current round of the multiple rounds, wherein a respective transaction message comprises a respective transaction; send, to the respective one or more follower devices, at least the transactions and the round confirmation messages of the other follower devices; a follower device (421) of the one or more follower devices is configured to: receive, from the leader device, the transactions for the current round and the round confirmation messages of the other follower devices for the preceding round; send, to the leader device, a round confirmation message for the current round, wherein the round confirmation message comprises a cryptographic signature by the follower device for confirming the current round.

2. The system (400) of claim 1 , wherein the follower device is configured to verify that the current round includes a transaction provided after confirming the preceding round or the round preceding the preceding round.

3. The system (400) of any preceding claim, wherein the respective transaction message further comprises a cryptographic signature by the respective follower device on the transaction.

4. The system (400) of any preceding claim, wherein the system further comprises a submitter device (430), wherein: the submitter device is configured to send the respective transaction for the current round to the respective follower device; and33 the submitter device is configured to receive round confirmation messages for the current round of the one or more follower devices; and to verify the cryptographic signatures of the round confirmation messages using the transaction.

5. The system (400) of claim 4, wherein the submitter device is configured to verify the round confirmation messages without using further transactions of the current round.

6. The system (400) of any preceding claim, wherein the transaction represents an operation to be applied to a stateful object, and wherein the follower devices are configured to apply the operation.

7. The system (400) of claim 6, wherein the cryptographic signature of the round confirmation message is based on a result of applying the operation to the stateful object.

8. The system (400) of claim 6 or 7, wherein applying the operation comprises verifying whether the operation is authorized.

9. A leader device (100) for use in the distributed consensus system according to any one of the preceding claims, wherein the distributed consensus system is for maintaining a replicated state; wherein the distributed consensus system uses multiple rounds; wherein a round comprises zero or more transactions to be applied to the replicated state; wherein the distributed consensus system comprises one or more follower devices; wherein the leader device (100) comprises: a communication interface (180) configured for communication with the one or more follower devices; a processor subsystem (140) configured to: receive, via the communication interface, respective round confirmation messages for a preceding round of the multiple rounds from the respective one or more follower devices; receive, via the communication interface, one or more respective transaction messages for a current round of the multiple rounds from one or more respective follower devices, wherein a respective transaction message comprises a respective transaction; send, via the communication interface to the respective one or more follower devices, at least the transactions and the round confirmation messages of the other follower devices.

10. A follower device (200) for use in the distributed consensus system according to any one of claims 1-8, wherein the distributed consensus system is for maintaining a replicated state; wherein the distributed consensus system uses multiple rounds; wherein a round comprises zero or more transactions to be applied to the replicated state; wherein the distributed consensus system comprises a leader device and one or more other follower devices; wherein the follower device (200) comprises: a communication interface (280) configured for communication with the leader device; a processor subsystem (240) configured to: receive from the leader device, via the communication interface, one or more transactions for a current round of the multiple rounds and round confirmation messages of the other follower devices for a preceding round of the multiple rounds; send to the leader device, via the communication interface, a round confirmation message for the current round, wherein the round confirmation message comprises a cryptographic signature by the follower device for confirming the current round.

11. A submitter device (300) for use in the distributed consensus system according to any one of claims 1-8, wherein the distributed consensus system is for maintaining a replicated state; wherein the distributed consensus system uses multiple rounds; wherein a round comprises zero or more transactions to be applied to the replicated state; wherein the distributed consensus system comprises a leader device and one or more follower devices; wherein the submitter device comprises: a communication interface (380) configured for communication with at least a follower device of the one or more follower devices; a processor subsystem (340) configured to: send, via the communication interface, a transaction to the follower device; and receive, via the communication interface, respective round confirmation messages of the one or more follower devices, wherein a respective round confirmation message comprises a cryptographic signature of the respective follower device for confirming a current round of the multiple rounds; verify the cryptographic signatures of the round confirmation messages using the transaction.

12. A computer-implemented leader method (1700) for use in the distributed consensus system according to any one of claims 1-8, wherein the distributedconsensus system is for maintaining a replicated state; wherein the distributed consensus system uses multiple rounds; wherein a round comprises zero or more transactions to be applied to the replicated state; wherein the distributed consensus system comprises one or more follower devices; wherein the leader method comprises: communicating (1710) with the one or more follower devices; receiving (1720) respective round confirmation messages for a preceding round of the multiple rounds from the respective one or more follower devices; receiving (1730) one or more respective transaction messages for a current round of the multiple rounds from one or more respective follower devices, wherein a respective transaction message comprises a respective transaction; sending (1740) to the respective one or more follower devices, at least the transactions and the round confirmation messages of the other follower devices.

13. A computer-implemented follower method (800) for use in the distributed consensus system according to any one of claims 1-8, wherein the distributed consensus system is for maintaining a replicated state; wherein the distributed consensus system uses multiple rounds; wherein a round comprises zero or more transactions to be applied to the replicated state; wherein the distributed consensus system comprises a leader device and one or more other follower devices; wherein the follower method (800) comprises: communicating (810) with the leader device; receiving (820), from the leader device, one or more transactions for a current round of the multiple rounds and round confirmation messages of the other follower devices for a preceding round of the multiple rounds; sending (830), to the leader device, a round confirmation message for the current round, wherein the respective round confirmation message comprises a cryptographic signature by the follower device for confirming the current round.

14. A computer-implemented submitter method (900) for use in the distributed consensus system according to any one of claims 1-8, wherein the distributed consensus system is for maintaining a replicated state; wherein the distributed consensus system uses multiple rounds; wherein a round comprises zero or more transactions to be applied to the replicated state; wherein the distributed consensus system comprises a leader device and one or more follower devices; wherein the submitter method (900) comprises: communicating (910) with at least a follower device of the one or more follower devices;36 sending (920) a transaction to the follower device; and receiving (930) respective round confirmation messages of the one or more follower devices, wherein a respective round confirmation message comprises a cryptographic signature of the respective follower device for confirming a current round of the multiple rounds; verifying (940) the cryptographic signatures of the round confirmation messages using the transaction.

15. A cryptographic system (010) for performing a privacy-preserving computation on secret data, wherein the cryptographic system comprises multiple cryptographic devices, wherein the multiple cryptographic devices are configured to perform the computation as a cryptographic secure multi-party computation between the multiple cryptographic devices, wherein the cryptographic system comprises a distributed consensus system for maintaining a replicated state according to any one of claims 1-8, wherein the replicated state stores metadata of the privacy-preserving computation.

16. A transitory or non-transitory computer-readable medium (1100) comprising data (1110) representing instructions which, when executed by a processor system, cause the processor system to perform any one of: the leader method of claim 12; the follower method of claim 13; the submitter method of claim 14.

Images