Managing reconfigurations of distributed computing systems

A computer manages reconfigurations of a Byzantine fault-tolerant, distributed computing system comprising a network of first nodes adhering to a given consensus protocol at a reconfiguration service. The computer services the network by receiving a request of change of status of a second node with respect to the network. The computer informs at least a subset of the first nodes of the received request. The computer obtains an approval of the request, whereby at least a subset of the first nodes collectively approve the change of status as a result of contributions processed according to the given consensus protocol. The computer updates a configuration log according to request approvals obtained by servicing the network. The computer addresses requests of clients about configurations of the network based on the updated configuration log.

The project leading to this application has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 780477.

BACKGROUND

The invention relates in general to the field of methods and computer program products for managing configurations of a distributed computing system such as a permissioned blockchain system. In particular, it is directed to methods relying on an external reconfiguration service, which is preferably run as a smart contract executing on a distributed system using a consensus protocol that differs from the consensus protocol used by the managed system.

Blockchain systems are conceived as long-lived systems, which are typically implemented by a set of nodes (also called miners or validators), which participate in a consensus on the system state. More lightweight client nodes (e.g., wallets) occasionally access the blockchain nodes, e.g., when a client wishes to submit an operation to the blockchain. In a long-lived system, this leads to security challenges.

SUMMARY

In an embodiment, a method of managing reconfigurations of a Byzantine fault-tolerant, distributed computing system comprising a network of first nodes adhering to a given consensus protocol at a reconfiguration service includes a computer managing reconfigurations of a Byzantine fault-tolerant, distributed computing system comprising a network of first nodes adhering to a given consensus protocol at a reconfiguration service. The computer services the network by receiving a request of change of status of a second node with respect to the network. The computer informs at least a subset of the first nodes of the received request. The computer obtains an approval of the request, whereby at least a subset of the first nodes collectively approve the change of status as a result of contributions processed according to the given consensus protocol. The computer updates a configuration log according to request approvals obtained by servicing the network. The computer addresses requests of clients about configurations of the network based on the updated configuration log. According to aspects of the invention, the reconfiguration service is implemented at one of the distributed computing system and a distinct distributed computing system and adheres to a further consensus protocol that is logically distinct from the given consensus protocol. According to aspects of the invention, the reconfiguration service is implemented as a smart contract executed according to the further consensus protocol. According to aspects of the invention, the reconfiguration service is implemented at a distinct distributed computing system. According to aspects of the invention, the further consensus protocol uses a proof of work mechanism. According to aspects of the invention, the consensus protocol given at servicing the network uses a proof of stake mechanism, and the approval is obtained by the reconfiguration service based on those contributions from a subset of the first nodes having stakes in respect of the request of change of status. According to aspects of the invention, the distributed system is configured as a permissioned blockchain. According to aspects of the invention, at servicing the network, the first nodes are informed by the reconfiguration service of the received request during a same epoch, so as to be able to make the contributions at an end of that same epoch; and the approval of the request is obtained by the reconfiguration service at the earliest at the end of that same epoch. According to aspects of the invention, at servicing the network, the approval of the request is obtained at the reconfiguration service by validating the request when a sufficient number of the contributions are available to the reconfiguration service. According to aspects of the invention, at each of the first nodes, the computer batches successive ones of their contributions in respect of successive requests of change of status as informed of by the reconfiguration service while servicing the network. According to aspects of the invention, servicing the network further includes informing the first nodes of a configurational change of the network reflecting the approved change of status. According to aspects of the invention, the method further includes, at the second node, obtaining a confirmation from the first nodes that they have been informed of the request of change of status; and confirming the request to the first nodes for the latter to start making the contributions based on the confirmed request. According to aspects of the invention, the method further includes obtaining the approval of the request at the second node, in addition to obtaining this approval at the reconfiguration service, for the second node to start acting with respect to the network according to the approved request. According to aspects of the invention, the method further includes, at the second node, sending the request of change of status to both the reconfiguration service and the first nodes, for the reconfiguration service to accordingly inform the first nodes and the first nodes to confirm they have been informed of the request and then start making the contributions. According to aspects of the invention, the method further includes, at the reconfiguration service, requesting the second node to provision credits for the reconfiguration service to compensate the first nodes according to a protocol run at the reconfiguration service. According to aspects of the invention, a configuration of the reconfiguration service is managed by a further configuration service. According to aspects of the invention, the received request is one of a request to join the network, a request to leave the network, and a request to evict one or more of the nodes of the network. According to aspects of the invention, the network comprises n nodes, n≥4, and the distributed computing system is configured to tolerate at most f Byzantine nodes, where f<n/3.

In another embodiment, a system of managing reconfigurations of a Byzantine fault-tolerant, distributed computing system comprising a network of first nodes adhering to a given consensus protocol at a reconfiguration service, includes a computer system comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a computer to cause the computer to: service the network by receiving a request of change of status of a second node with respect to the network, informing at least a subset of the first nodes of the received request, and obtaining an approval of the request, whereby at least a subset of the first nodes collectively approve the change of status as a result of contributions processed according to the given consensus protocol; updating a configuration log according to request approvals obtained by servicing the network; and addressing requests of clients about configurations of the network based on the updated configuration log.

In another embodiment, A computer program product for managing reconfigurations of a Byzantine fault-tolerant, distributed computing system comprising a network of first nodes adhering to a given consensus protocol, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by one or more processors, to cause the reconfiguration service to: service the network by receiving a request of change of status of a second node with respect to the network, informing at least a subset of the first nodes of the received request, and obtaining an approval of the request, whereby at least a subset of the first nodes collectively approve the change of status as a result of contributions processed according to the given consensus protocol; update a configuration log according to request approvals obtained by continually servicing the network; and address requests of clients about configurations of the network based on the updated configuration log.

According to a first aspect, the present invention is embodied as a method of managing reconfigurations of a Byzantine fault-tolerant (BFT), distributed computing system. The system includes a network of first nodes, which adhere to a given consensus protocol. The method includes a series of steps, which are performed at a reconfiguration service. Namely, the reconfiguration service continually services the network and accordingly update a configuration log. This way, the reconfiguration service may continually address requests of clients about configurations of the network, based on the updated configuration log. The reconfiguration service continually services the network by performing the following steps. Upon receiving a request of change of status of a second node with respect to the network, the reconfiguration service informs at least a subset of the first nodes of the received request. In turn, the reconfiguration service obtains an approval of the request, whereby at least a subset of the first nodes collectively approve the change of status as a result of contributions processed according to the given consensus protocol. Accordingly, the reconfiguration service can continually update the configuration log according to request approvals obtained by servicing the network. This way, the reconfiguration service can securely address client requests requiring accurate knowledge about recent configurations of the network.

The reconfiguration service is advantageously implemented at a distributed computing system (preferably distinct from the distributed computing system formed by the network of the first nodes) and adheres to a further consensus protocol that is logically distinct from the consensus protocol used by this network. The reconfiguration service may notably be implemented as a smart contract executed according to this further consensus protocol, e.g., relying on a proof of work mechanism. By contrast, the consensus protocol of the client network typically relies on a proof of stake mechanism. The client distributed computing system may notably be configured as a permissioned blockchain.

According to another aspect, the invention is embodied as a computer program product for managing reconfigurations of a BFT, distributed computing system comprising a network as described above. The computer program product comprises a computer readable storage medium having program instructions embodied therewith, where the program instructions are executable by one or more processors, to cause the reconfiguration service to perform steps according to the above method.

Aspects of the present invention recognize and address concerns regarding system state for a client rejoining a system after being disconnected.

Aspects of the invention, recognize and address issues that arise when the blockchain system initially includes (configuration C0) nodes A, B, C, and D, and then comes to gradually reconfigure to a configuration Ck, k>0, in which the system now includes nodes E, F, G, and H but does not include any of the initial nodes of C0in this example. Aspects of the present invention note that a client that only occasionally reconnects to the blockchain system may not have been updated about the changes in the system membership. Aspects of the present invention note that this client may reconnect to an initial configuration, e.g., C0, which might have been entirely corrupted by a malicious actor, it being noted that realistic blockchain systems limit assumptions on the power of adversaries only with respect to their current configuration. Aspects of the present invention note that may affects many blockchain systems, whether based on Proof-of-Work (PoW), Proof-of-Stake (PoS), or permissioned consensus protocols.

Aspects of the present invention note that in PoS blockchains, an adversary may mount a long-range attack fabricating a blockchain history, which the client cannot distinguish from the real history. Aspects of the present invention note that a similar attack is known in permissioned blockchains and Byzantine fault-tolerant (BFT) systems as the “I still work here” attack.

Aspects of the present invention note that situations may potentially affect PoW blockchains as well, these can rely on the longest chain selection rule. This, together with ever growing miner hashing power in established networks such as those used by cryptocurrencies, allows the nodes of the current configuration to (eventually) convince the client of their legitimacy, a security feature that is of advantage over PoS and permissioned blockchain systems.

Aspects of the present invention note that in PoS systems, long-range attacks are, typically, partially addressed by making validators bond their stakes for a very long time (stake unbonding or “thawing” time, which is often several weeks or more) with slashing mechanisms to discourage adversarial behavior. In other approaches, clients periodically synchronize with changes in the membership set. Permissioned blockchains typically reconfigure internally and are vulnerable to this type of attacks.

Aspects of the present invention recognize that approaches are needed to improve security on distributed computing systems such as permissioned blockchains and PoS systems.

The accompanying drawings show simplified representations of devices or parts thereof, as involved in embodiments. Similar or functionally similar elements in the figures have been allocated the same numeral references, unless otherwise indicated.

Computerized methods and computer program products embodying the present invention will now be described, by way of non-limiting examples.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The following description is structured as follows. First, general embodiments and high-level variants are described in section 1. Section 2 describes particularly preferred embodiments (it notably includes a detailed description ofFIGS.2and3), while Section 3 is directed to technical implementation details. Note, the present method and its variants are collectively referred to as the “present methods”. All references Sn refer to methods steps of the sequence diagrams ofFIGS.2and3, while numeral references pertain to physical parts or components of the systems shown inFIG.1and the computerized unit shown inFIG.4.

1. General Embodiments and High-Level Variants

In reference toFIGS.1-3, an aspect of the invention is first described, which concerns a method of managing reconfigurations of a distributed computing system1, which is a Byzantine fault-tolerant (BFT) system.

As illustrated inFIG.1, the distributed computing system1comprises a network of nodes11, hereafter referred to as “first nodes”. The first nodes11are assumed to adhere to a given consensus protocol21of the system1. The system1is enabled by physical machines11of the network, which runs a distributed computing method, as known by those of skill in this field. In the following, the same numeral reference (“1”) is used to designate both the system1and/or the underlying network. The network includes n nodes11. This number is not necessarily constant, since the configuration of the system can be dynamically changed. However, n is typically assumed to be equal to or larger than four, i.e., n≥4. In practice, the distributed system1is typically configured to tolerate at most f Byzantine nodes, where f<n/3. That is, at most f nodes in the network1can be Byzantine (i.e., fail in some way), such that n≥3f+1.

The method further involves a reconfiguration service2, which may be regarded as a server, while the managed system1may be regarded as a client of the service2. The reconfiguration service2continually services the network1, by repeatedly and frequently performing steps as described below. Servicing the network1causes the reconfiguration service to continually update a configuration log, in which current configurations of the network (or updates to such configurations) are stored. This way, the reconfiguration service may continually address S66requests made S64by external clients5(seeFIG.2), where such requests require correct knowledge of current configurations of the network1. These requests are typically addressed S66by providing data derived from the configuration log to such clients or by allowing such clients to access the configuration log, upon request S64of such clients5. Any of the client processes may potentially be Byzantine.

The reconfiguration service2services the network1as follows. In operation, the reconfiguration service2may continually receive requests of change of status of certain nodes12, hereafter referred to as “second nodes”. Such requests may be made by the second nodes12themselves or by other nodes (e.g., the first nodes11). However, these requests concern nodes12, which are nodes that may or may not belong to the network1. Such requests aim at changing statuses of the second nodes12with respect to the network1. A single request may possibly concern a change of status of one or more nodes12. For example, an external node12may request to join the network1, as assumed inFIGS.2and3. As another example, an internal node may request to leave the network1, while it is part of the network1. Such requests must be distinguished from requests of external clients5, which cause the first nodes11to perform some work for the requesting clients5.

Upon receiving S14a request of change of status of a node12, the reconfiguration service2informs S22at least a subset of the first nodes11of the received request. In turn, the reconfiguration service2may obtain S40an approval of the request from the nodes11. Different approval mechanisms can be contemplated. In all cases, an approval means that at least a subset of the first nodes11collectively approve S30the change of status, according to some pre-defined scheme. The approval results from contributions S34of the first nodes, where such contributions are processed according to the consensus protocol21used by the network1. That is, contributions S34of the nodes11are coordinated via this consensus protocol. That is, the first nodes11are informed about and approve requests in a coordinated manner, in order to apply new configurations in a consistent way.

It is noted that the scenario contemplated above, the request is approved at step S40. However, the request may also be rejected. The nodes' contributions can be compared to votes: a sufficient number of nodes' contributions leads to an approval, whereas an insufficient number of contributions leads to a rejection.

In this way, the reconfiguration service2is able to continually update S45the configuration log; this is performed according to request approvals as continually obtained S40throughout steps of servicing the network1. As a result, the reconfiguration service2is able to continually address S66requests S64of clients about configurations of the network, based on the updated configuration log.

According to aspects of the invention, the first nodes11can be informed S22of the request by way of a publication. In that case, the reconfiguration service2makes the request available to the nodes11, and the nodes access the published information. In that sense, “informing” means making some information available, without it being necessary to actively send such information to the first nodes11. Optionally, though, the reconfiguration service2may directly send this information to the first nodes. Note, the above remarks hold for other, similar steps of information. All nodes11of the network may potentially be informed at step S22. However, in variants, this information may be made available only to nodes11having stakes in such requests, as in embodiments discussed later in detail. In all cases, at least a subset of the nodes11are informed S22.

The present solution enables a dynamic reconfiguration of the distributed system membership set while preventing long-range attacks. Clients5can adequately solicit the reconfiguration service2and safely obtain updated configuration information directly from the reconfiguration service2, so as to mitigate or even prevent the risk of long-range attacks.

Embodiments of the invention will now be described in detail. The reconfiguration service2may advantageously be implemented as a distributed computing system2, as shown inFIG.1. The physical system2implementing the reconfiguration service2is preferably distinct from the client system1. In variants, the reconfiguration service2may be run on the same physical machines11that compose the distributed system1. In both cases, however, the reconfiguration service2adheres to a further consensus protocol22(e.g., based on a proof of work) that is logically distinct from the consensus protocol21used by the network1(e.g., based on a proof of stake). Thus, the reconfiguration service2may be implemented at the same distributed system1as the first nodes11or at a distinct distributed system2. In other variants, the reconfiguration service2uses on a centralized solution, involving, e.g., a public key infrastructure, as known by those skilled in this field. According to aspects of the invention, the reconfiguration service2acts as a trusted entity for the network1.

Moreover, additional trust may possibly be obtained by using several reconfiguration services2(not shown), interacting with clients5, the nodes12and the network1, for additional security. Analogously to the existence of multiple independent Domain Name System (DNS) services, the configuration of a single BFT system1can use multiple independent reconfiguration service instances. Upon reconfiguring, the BFT system1correspondingly updates S34each of the reconfiguration services involved. A client5may, depending on its trust in those reconfiguration services, use any/all/a quorum of such services to learn about the configuration of the BFT system1.

Trust can further be increased by using a hierarchical approach, in which the configuration of the reconfiguration service2is managed by a further configuration service3, e.g., implemented as a further distributed system3running its own protocol23, as shown inFIG.1. That is, the reconfiguration service2may be a distributed computing system2, the configuration of which can be managed by a further distributed computing system3, where the latter may implement a reconfiguration method as described herein. So, the reconfiguration service2may be a consensus-based distributed system2and the configuration of the reconfiguration service2may possibly be managed by an additional reconfiguration service3. According to aspects of the invention, a fixed-membership BFT system2can be used as a root service2. Even proof of stake and dynamic-membership BFT systems can be used, as long as they can be considered trusted (e.g., due to their own configuration being registered in another reconfiguration service). Such a hierarchy can have arbitrary many levels and be rooted in a reliably discoverable system, e.g., a proof of work blockchain or static-membership BFT system.

In the following, the reconfiguration service2is assumed to be implemented at a distributed computing system2(distinct from the managed system1), relying on a proof of work (PoW) consensus22, whereas the consensus protocol21of the client network1is assumed to rely on a proof of stake (PoS) mechanism. The client system1may notably be configured as a permissioned blockchain, e.g., a dynamic permissioned blockchain. Note, the present methods may possibly be applied to PoW-based client networks. However, other algorithms are available for such networks, which may be leveraged to achieve the same, as noted in the background section.

The reconfiguration service2may for instance be implemented as a smart contract that is executed according to said further consensus protocol22. A client5accessing the client system1is typically required to know its configuration (network addresses, keys, etc.). Now, it is advantageous to make the reconfiguration service2accessible without any prior knowledge about the identities of the nodes running it. Public PoW-based blockchain systems have this property. If the reconfiguration service2has the form of a smart contract (as in preferred embodiments), the identity of this smart contract can be considered the identity of the whole system2, as it is the only information needed to bootstrap interaction with it. Note, in some cryptocurrency blockchains, the identity of the smart contract is the address of the smart contract.

According to aspects of the invention, a client5connecting to the system1may first reliably obtain an up-to-date configuration of the system1from the reconfiguration service2. The client5may then submit its requests to the client system1.

The approval obtained at step S40(seeFIGS.2and3) by the reconfiguration service2may be based on a limited number of contributions, i.e., contributions made S34by a subset of the first nodes11that have stakes in respect of the request of change of status. So, the contributions made S34by the nodes11are processed by the reconfiguration service2according to such stakes.

The PoS blockchain systems reconfigure their validator sets through the process of “staking” and “destaking” funds in native cryptocurrency. To apply the reconfiguration service2to a PoS-based client1, the reconfiguration service2stores the amount of stake associated with each validator (i.e. member)11, in addition to or as part of the current configuration. Each validator's vote for a new configuration then has a weight proportional to the size of the corresponding stake.

The approval of a request may for instance be obtained S40by validating this request as soon as a sufficient number of contributions are made S34available to the reconfiguration service2. So, the reconfiguration service2does not necessarily need to obtain all the contributions of the nodes11. In addition, the reconfiguration service may impose a deadline and/or a quorum for the nodes11to vote.

As illustratedFIG.2, the contributions made S34by the nodes11are preferably obtained upon completion of the epoch during which the nodes11were informed S22of the request. That is, the first nodes11are informed S22by the reconfiguration service2of a request during a same epoch, such that the nodes may be able to contribute S34their votes at an end of that same epoch. The approval of the request is, at the earliest, obtained S40by the reconfiguration service2at the end of that same epoch for all nodes11involved. Doing so allows the nodes to vote based on same knowledge of the system.

Epochs can roughly be compared to time slices. However, they are not necessarily perfectly synchronous across the nodes11. In the present context, an epoch typically corresponds to a certain number of sequence numbers of operations performed by each node (e.g., according to a same log of operations as locally replicated at each node). Still, because no configurational change will be agreed before a current epoch completes (at least not in respect of a request received during that same epoch), an epoch may also be defined as the time period between two successive configurational changes. So, a transition from one configuration to the other corresponds to the end of an epoch and the beginning of another epoch.

According to aspects of the invention, and as shown inFIG.2all participating nodes vote S34at the end of an epoch during which they were informed S22of the request. In variants, the nodes11may postpone their answers, such that the approval may be delayed. According to aspects of the invention, this occurs when the nodes11postpone their votes for batching purposes. In that case, the first nodes11may batch successive contributions in respect of successive requests of change of status, as informed S22by the reconfiguration service2while continually servicing the network1. That is, each participating node11may postpone one or more of its contributions and batch such contributions at a later stage. For example, the nodes11may send combined contributions to the server2, once the number of changes in the network exceeds a given threshold or after a given time has lapsed.

As further seen inFIG.2, the reconfiguration service2may, eventually, inform S47the first nodes11of a configurational change of the network reflecting the most recently approved S40change of status. That is, after the reconfiguration service2has obtained approval of a request, the reconfiguration service may inform S47the nodes, for their records, and in view of subsequent operations. By so doing, the nodes11and the reconfiguration service2are able to maintain consistent views of the system configuration. Again, the nodes need not be explicitly notified the configurational changes; they may be passively informed.

The reconfiguration service2may advantageously implement a compensation mechanism. As illustrated inFIG.2, the reconfiguration service2may notably request the second node12to provision S14“credits” for the reconfiguration service2to be able to compensate S47the first nodes11. This compensation can be performed according to any suitable protocol22running at the reconfiguration service2, i.e., a consensus protocol if the reconfiguration service2is a distributed computing system. The effective compensation of the participating nodes11may for instance occur as part of step S47, where the reconfiguration service2informs the nodes11of the obtained approval, in the interest of efficiency.

More sophisticated interactions between the nodes11,12and the reconfiguration service2can be contemplated, as now discussed in reference toFIG.3. As inFIG.2, the sequence shown inFIG.3involves a reconfiguration service2that informs S22a subset of nodes11of the network1upon receiving S14a request of change of status of some node12with respect to the network1. The request is again assumed to be a join request in this example. The reconfiguration service2then obtains S40an approval of the request, based on contributions made S34by the nodes11according to the consensus protocol21of the network1. Moreover, the reconfiguration service updates S45a configuration log according to request approvals obtained. This way, the reconfiguration service2can continually address client requests that require information about the configurations of the network1(not shown inFIG.3).

In addition, a number of optional steps are involved. First, the requesting node12accesses S12a latest configuration log of the reconfiguration service2, based on which the node12registers S14a request of change of status with the service2. This way, the reconfiguration service2may subsequently inform S22the nodes11of the request. In addition, the node12announces S16this request to the nodes11, such that the latter may subsequently perform verifications. The preliminary announce S16allows the nodes11to compare this announce with the request as subsequently received S22from the reconfiguration service2. This way, the nodes11may subsequently acknowledge S24(and thereby confirm) the request to the second node12if the announce S16of the second node matches the request received S22from the reconfiguration service. Note, in the specific example ofFIG.3, the confirmation S24may be necessary for the node12to make a valid join request.

As further seen inFIG.3, the second node12may, upon obtaining S24the acknowledgment from the nodes11, confirm S26the request to the nodes11for the latter to start making S34their contributions. The confirmation sent at step S24is a verification of the correctness of the join request; the request as informed S22by the reconfiguration service2can be (co-)related with the subsequent confirmation S26from the second node12. This makes it possible for the first nodes11to make sure that the second node12is acting as expected.

As also seen inFIG.3, the first nodes11may, in addition to sending S34contributions (or somehow make them available) to the reconfiguration service2, directly inform S32the second node12. That is, the node12may directly obtain S32the approval of the request. This way, the second node12may directly start acting S50with respect to the network according to the approved S32request. In the example ofFIG.3, this means that the joining node12may start acting S50as a node of the network1. The join operation may advantageously include a proof of the approval as received from the first nodes11, for better liveness guarantees. A checkpoint is created at step S36, which corresponds to the end of the epoch at which a sufficient number of contributions have been obtained S40to validate the approval. From this moment on, the nodes11,12may start using the new configuration Ck+1, as also updated at the reconfiguration service2at step S45.

Although the examples ofFIGS.2and3assumes a join request, the request as received at step S14may similarly be a request to leave the network. In that case, the request may be formulated by the leaving node itself. In other cases, the request may be a request to evict one or more of the nodes11of the network1, which is typically formulated by the remaining nodes. More generally, such requests may concern a change of status of any node (internal or external) with respect to the network1. This change of status normally concerns a change of a quality or a property of a node (e.g., becoming idle), having less available memory or fewer computational resources.

According to another aspect, the invention can be embodied as a computer program product for managing reconfigurations of a distributed computing system1as described above. In such cases, a computer program product includes a computer readable storage medium having program instructions embodied therewith. Such program instructions are executable by processing means105, such as processors of a computerized unit101shown inFIG.4, to cause a reconfiguration service to implement steps as described above in reference to the present methods. Aspects of such computer program products are described in detail in section 3.2

The above embodiments have been succinctly described in reference to the accompanying drawings and may accommodate a number of variants. Several combinations of the above features may be contemplated. Examples are given in the next section.

2.1 Particularly Preferred Embodiments

The following proposes a general decentralized solution for secure and dynamic reconfiguration for blockchain and BFT distributed systems. First, a reconfiguration service2is relied on, i.e., a Blockchain/BFT Membership Service for permissioned blockchains and BFT systems, which is designed to prevent attacks, such as “I still work here” attacks, by leveraging a (root) reconfiguration service implemented as a smart-contract on a public permissionless PoW blockchain. Members (or potential members) of the BFT distributed system1push membership updates to the reconfiguration service2; the new membership is accepted and published by the reconfiguration service once a qualified number of nodes of the reconfigured system approve (vote for) the change. The reconfiguration service allows the new permissioned blockchain nodes to pay fees for joining and leaving the system. These fees are distributed among voting nodes to cover the cost of pushing membership updates to the reconfiguration service and create incentives for protocol participation.

The reconfiguration service can, for instance, be implemented as a smart-contract and be used with the Mir-BFT protocol known by those of skill in this filed. Such a reconfiguration service can be extended from permissioned to permissionless PoS blockchains to prevent long-range attacks; the reconfiguration service can considerably reduce the stake unbonding (“thawing”) time.

2.2 Detailed Description of FIG.2

InFIG.2, an external node12sends S14a join request to the reconfiguration service2, which accordingly stores S20the request. The reconfiguration service may for instance temporarily update a configuration log, in accordance with the join request. The requesting node12may altogether provision S14credits, e.g., in view of compensating the nodes11of the client network1. The reconfiguration service2accordingly informs S22nodes11of the network1, which start agreeing S30on the join request (or not). The nodes11subsequently send S34contributions, at the end of the epoch during which they were informed S22. A checkpoint is created at the end of the epoch during which the nodes agreed to the join request. From this moment on, the nodes11start using the configuration of the network1. The reconfiguration service obtains S40the approval by collecting the contributions S34and validating them. If the join request is approved, the reconfiguration service updates S45its configuration log and informs S47the nodes11of the validated configuration. The reconfiguration service may, at the same time, take steps S47to compensate the participating nodes, according to a protocol executed at the reconfiguration service.

The reconfiguration service concurrently manages requests received from external clients5. Assume that a given client5loses connection at step S62. This client may later reconnect by soliciting S64the reconfiguration service and thereby obtain S66data as to the latest validated configuration of the network1.

2.3 Detailed Description of FIG.3

The sequences shown inFIG.3are essentially similar to those shown inFIG.2, although it includes a number of intermediate steps, for additional security. In this example, interactions with external clients are not shown, for conciseness.

InFIG.3, an external node12first reads S12a current configuration of the network1(as previously stored S10by the reconfiguration service) and subsequently registers S14with the reconfiguration service2, which accordingly stores S20the request. The requesting node12may again provision S14credits, in view of compensating the nodes11. In addition to registering S14with the reconfiguration service, the joining node12announces S16itself to the nodes11. The reconfiguration service informs S22nodes11of the network1of the join request. In turn, the nodes11proceed S24to a verification with the requesting node12, which confirms the join request at step S26. At this point, the nodes11start to agree S30on the join request (or not). The nodes11subsequently send S32, S34their contributions to the requesting node12and the reconfiguration service2; a checkpoint is created at step S36. From this moment on, the nodes11start using the new configuration of the network1and the requesting node12may start S50participating in the network1.

Meanwhile, the reconfiguration service obtains S40the approval and updates S45its configuration log, so as to be able to serve external client processes (not shown). That is, the configuration Ck(as initially stored at step S10) transitions to configuration Ck+1(as updated at step S45), which corresponds to configuration Ckaugmented by the joining node12. In this example, the transfers of funds within the reconfiguration service2happen on processing S20the “Register” transaction S14(from the joining node's account to the reconfiguration service smart contract) and on updating S45the stored configuration (from the smart contract to the accounts of nodes which have voted).

The example depicted inFIG.3assumes that all nodes have access to the state of the reconfiguration service2. In some implementations of the reconfiguration service, each node may be assumed to run its own client (or use a proxy). All messages and requests may be authenticated using an appropriate authentication mechanism, e.g., public-key cryptography.

3. Technical Implementation Details

3.1 Computerized Units and Systems

Computerized systems and devices can be suitably designed for implementing embodiments of the present invention as described herein. In that respect, it can be appreciated that the methods described herein are largely non-interactive and automated. In exemplary embodiments, the methods described herein can be implemented either in an interactive, a partly interactive, or a non-interactive system. The methods described herein can be implemented in software, hardware, or a combination thereof. In exemplary embodiments, the methods proposed herein are implemented in software, as an executable program, the latter executed by suitable digital processing devices. More generally, embodiments of the present invention can be implemented wherein virtual machines and/or general-purpose digital computers, such as personal computers, workstations, etc., are used.

For instance,FIG.4schematically represents a computerized unit101(e.g., a general- or specific-purpose computer), which may possibly interact with other, similar units101, to be able to perform steps according to the present methods.

In exemplary embodiments, in terms of hardware architecture, as shown inFIG.4, each unit101includes at least one processor105, and memory110coupled to a memory controller115. Several processors (CPUs, and/or GPUs) may possibly be involved in each unit101. To that aim, each CPU/GPU may be assigned a respective memory controller, as known by those of skill in this field.

One or more input and/or output (I/O) devices145,150,155(or peripherals) are communicatively coupled via a local input/output controller135. The input/output controller135can be coupled to or include one or more buses and a system bus140, as known in the art. The input/output controller135may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processors105are hardware devices for executing software instructions. The processors105can be any custom made or commercially available processor(s). In general, they may involve any type of semiconductor-based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions.

The memory110typically includes volatile memory elements (e.g., random-access memory), and may further include nonvolatile memory elements. Moreover, the memory110may incorporate electronic, magnetic, optical, and/or other types of storage media. External (i.e. secondary or auxiliary) storage120is normally available, which is not directly accessible by the processing means105, as usual.

Software in memory110may include one or more separate programs, each of which includes executable instructions for implementing logical functions. In the example ofFIG.4, instructions loaded in the memory110may include instructions arising from the execution of the computerized methods described herein in accordance with exemplary embodiments. The memory110may further load a suitable operating system (OS). The OS essentially controls the execution of other computer programs or instructions and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

Possibly, a conventional keyboard and mouse can be coupled to the input/output controller135. Other I/O devices145,150,155may be included. The computerized unit101can further include a display controller125coupled to a display130. Any computerized unit101will typically include a network interface or transceiver160for coupling to a network, to enable, in turn, data communication to/from other, external components, e.g., other units101.

The network transmits and receives data between a given unit101and other devices101. The network may possibly be implemented in a wireless fashion, e.g., using wireless protocols and technologies, such as Wi-Fi, WiMAX, etc. The network may notably be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN), a personal area network (PAN), a virtual private network (VPN), an intranet or other suitable network system and includes equipment for receiving and transmitting signals. Preferably though, this network should allow very fast message passing between the units.

The network can also be an IP-based network for communication between any given unit101and any external unit, via a broadband connection. In exemplary embodiments, network can be a managed IP network administered by a service provider. Besides, the network can be a packet-switched network such as a LAN, WAN, Internet network, an Internet of things network, etc.

3.2 Computer Program Products

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows: