Abstract: Embodiments of the present disclosure relate to techniques for maintaining a state of a distributed system. In particular, certain embodiments relate to identifying a function. Some embodiments relate to, upon determining that the function comprises an annotation indicating that the function is capable of modifying the state of the distributed system, transforming the function to allow the function to generate updates to a state machine.

Abstract: Techniques for implementing linear view-change in a Byzantine Fault Tolerant (BFT) protocol running on a distributed system comprising n replicas are provided. According to one set of embodiments, at a time of performing a view-change from a current view number v to a new view number v+1, a replica in the n replicas corresponding to a new proposer for new view number v+1 can generate a PREPARE message comprising a single COMMIT certificate, where the single COMMIT certificate is the highest COMMIT certificate the new proposer is aware of. The new proposer can then transmit the PREPARE message with the single COMMIT certificate to all other replicas in the n replicas.

Abstract: Techniques for implementing linear view-change with optimistic responsiveness in a BFT protocol running on a distributed system comprising n replicas are provided. According to one set of embodiments, the replicas can execute, during a view v of the BFT protocol, a first voting round comprising communicating instances of a first type of COMMIT certificate among the replicas. Further, when 2f+1 instances of the first type of COMMIT certificate associated with view v have been received by the replicas, the replicas can execute a second voting round comprising communicating instances of a second type of COMMIT certificate among the replicas. If 2f+1 instances of the second type of COMMIT certificate associated with view v are not received by the replicas within a predetermined timeout period, a view change can be initiated from view v to a view v+1.

Abstract: The disclosure describes a failure-free execution agreement that includes n=3F+1 parties acting as replicas, and a number of parties acting as clients. One replica is designated as a primary. At most F replicas are presumed Byzantine faulty. The basic agreement protocol proceeds in three rounds: (1) client sends a request to the primary, who sends to all replicas; (2) each replica sends a threshold-part signature on hash to a first collector; (3) the collector combines the threshold-parts into a single signature and sends to all 3F+1 replicas which then commit and send to a second collector. The client proceeds when a signed block of requests arrives from the second collector.

Abstract: A shared log system can provide a key-index structure (main map) that allows clients (users) to access the state of objects stored in the shared log system. The client can define secondary indices on the main map to provide access to the data that are tailored to the client's data needs. Each client can generate their own customized set of secondary indices different from other clients.

Abstract: Techniques for implementing Byzantine fault tolerance with verifiable secret sharing at constant overhead are provided. In one set of embodiments, a client can determine a secret value s to be shared with N replicas in a distributed system, s being input data for a service operation provided by the N replicas. The client can further encode s into an f-degree polynomial P(x) where f corresponds to a maximum number of faulty replicas in the distributed system, evaluate P(x) at i for i=1 to N resulting in N evaluations P(i), generate at least one f-degree recovery polynomial R(x) based on a distributed pseudo-random function (DPRF) f?(x), and evaluate R(x) at i for i=1 to N resulting in at least N evaluations R(i). The client can then invoke the service operation, the invoking comprising transmitting a message including P(i) and R(i) to each respective replica i.

Abstract: A shared log in a distributed system provides for direct access to the most current data state of an object stored in the shared log. Directly accessing the data state of an object obviates the need for a client to replay all the transactions stored in the shared log made on the object.

Abstract: In accordance with disclosed embodiments, a shared log system includes a sequencer to verify transactions that comprise a source object and one or more members of the source object (source data objects), a target object and one or more members of the target object (target data objects), and a snapshot time reference. The sequencer verifies transaction using the snapshot time to determine whether the data states of the source data objects at the time of the snapshot time represent their most current data state in a shared log.

Abstract: Embodiments of the present disclosure relate to techniques for maintaining a state of a distributed system. In particular, certain embodiments relate to identifying a function. Some embodiments relate to, upon determining that the function comprises an annotation indicating that the function is capable of modifying the state of the distributed system, transforming the function to allow the function to generate updates to a state machine.

Abstract: Described herein are systems, methods, and software to enhance the management of data objects in a data storage system. In one implementation, a client in a data object environment is configured to identify a request for a data object in a first version from process on the client. Once the request is identified and the data object is provided or made available to the requesting process, the object storage system identifies a modification request for the data object to modify the data object from the first version to a second version. In response to the modification request, the object storage system generates an undo log entry to reflect the changes from the first version to the second version and updates the data object to the second version.

Abstract: The disclosure describes a failure-free execution agreement that includes n=3F+1 parties acting as replicas, and a number of parties acting as clients. One replica is designated as a primary. At most F replicas are presumed Byzantine faulty. The basic agreement protocol proceeds in three rounds: (1) client sends a request to the primary, who sends to all replicas; (2) each replica sends a threshold-part signature on hash to a first collector; (3) the collector combines the threshold-parts into a single signature and sends to all 3F+1 replicas which then commit and send to a second collector. The client proceeds when a signed block of requests arrives from the second collector.

Abstract: A technique is disclosed for building agreement among a plurality of servers who receive a transaction from clients. The technique includes each server broadcasting its received transaction to all other servers. Each server uses the set of transactions that it received from all servers (including its own transaction) to produce an echo that represents the set of transactions, and broadcasts the echo. Each will commit its transaction to a log if its echo matches each echo received from the other servers. The present disclosure can detect byzantine failures and punishes deviating participating servers by reconfiguring the plurality of servers that participate in the protocol.

Abstract: In accordance with disclosed embodiments, a shared log system includes a sequencer that receives a source object and a snapshot time reference, where the source object is used to generate data for a destination object. The sequencer uses the snapshot time to determine whether the data state of the source object is current with respect to the snapshot time, to assess correctness of the generated data relative to the snapshot time.

Abstract: Methods and systems to sample event messages are described. As event messages are generated by one or more sources, the event messages are stored in a storage queue. An event message policy that represents conditions for storing event messages in a sample log file are input. For each event message output from the storage queue, the event message may be stored in a sample log file when one or more of the conditions of the event message policy are satisfied. The event messages of the sample log file may be displayed in a graphical user interface that enables a user to change the event message policy.

Abstract: A method of managing a transaction in a control plane executing on a computing system that manages a plurality of services includes: receiving, at the control plane from a client, a plurality of first requests for at least one target service of the plurality of services, each of the plurality of first requests including a transaction indicator identifying the transaction; executing at least one handler of the at least one target service to process the plurality of first requests; receiving, at the control plane from the client, a commit request for the transaction coordinator service, the commit request including an instruction to commit the transaction; and executing a handler of the transaction coordinator service to process the commit request and notify the at least one target service of a status of the commit request.

Abstract: Maintaining ring consistency when a node leaves a ring includes a first adjacent node to a leaving node receiving an indication, from the leaving node, indicating its intent to leave the ring. The first adjacent node sends a first indication to a second adjacent node indicating i) acceptance of the leaving node's intent to leave id-space ownership for a portion of the id-space between the leaving node and the first adjacent node, and ii) establishment of a one-way monitoring relationship between the first adjacent node and the second adjacent node. The first adjacent node receives a second indication, from the second adjacent node, indicating i) acceptance of the first adjacent node's intent to assume id-space ownership for the portion of the id-space between the leaving node and the first adjacent node, and ii) establishment of the one-way monitoring relationship between the second adjacent node and the first adjacent node.

Abstract: The present invention extends to methods, systems, and computer program products for a joining node to join a ring of nodes within a rendezvous federation. Embodiments of the invention include establishing a neighborhood of multiple nodes on the ring of nodes. The joining node indicates its intent to take id-space ownership for a portion of the id-space between the joining node and a selected immediately adjacent node. The joining node initiates a one-way monitoring relationship with the selected immediately adjacent node. The joining node receiving an indication from the selected immediately adjacent node that indicates acceptance of the joining node's intent to take id-space ownership for a portion of the id-space between the joining node and the selected node and indicates establishment of a one-way monitoring relationship between the selected node and the joining node. The joining node agrees to participate in a one-way monitoring relationship with the selected node.

Abstract: A “Stochastic Clustering-Based Network Generator” enables rapid formation of an interconnected hierarchical network structure from an arbitrary number of agents via an iterative turn-based coalescence process. Given N agents wishing to coalesce into one hierarchical network, a turn-based process allows each agent (or the head of each hierarchical cluster of agents), to randomly decide whether to issue or listen for merge requests in each round. Issuing a request amounts to contacting a randomly chosen agent with a merge request. Given multiple received requests, a cluster head will randomly accept one request for a merge received by any agent in that cluster. The requesting cluster then merges as a hierarchical child of the accepting cluster. In a related embodiment, given multiple merge requests, the request from the smallest cluster is accepted. In further embodiments, ties of the smallest cluster size are broken based on various options.

Abstract: A remote procedure call chain is provided that replaces multiple consecutive remote procedure calls to multiple servers from a client by allowing a client to specify multiple functions to be performed consecutively at multiple servers in a single remote procedure call chain. The remote procedure call chain is executed by a sequence of multiple servers. Each server executes a service function and a chaining function of the remote procedure call chain. The chaining function uses the state of the remote procedure call chain in the sequence of servers to determine the next server to receive the remote procedure call chain, and the service function to be executed by that server. After the last service function is performed, the last server in the sequence of servers sends the results of the executed service functions to the client that originated the remote procedure call chain.

Abstract: During an initialization phase, some nodes of a network form clusters. The nodes in a cluster share information with a leader node, which knows all of the nodes that each of the nodes in the cluster is aware of. During a growth phase, clusters are randomly activated or deactivated. The nodes of the activated clusters message randomly selected known nodes, asking the nodes to merge with the cluster. The nodes of deactivated clusters determine which activated cluster to join based on received messages. After the growth phase ends, the remaining clusters may merge to form a single cluster, and the list of nodes known to the leader of the single cluster may be shared as the list of all nodes on the network.