Method and apparatus for distributed databases in a network

Abstract

In some embodiments, a method includes defining an address book for a distributed database. The address book includes an identifier for each computing device from a set of computing devices that implement the distributed database over a network. The method further includes receiving, from a computing device from the set of computing devices, an event including a transaction for updating the address book, and calculating a reception round of the event based on a consensus protocol for the distributed database that uses the address book. The method further includes updating the address book based on the transaction to define an updated address book after a predetermined number of rounds of at least one of reception rounds of events or updates to the address book.

Description

[Technical Field]

[0001] (Cross-reference of related applications) This application claims priority and interest in U.S. Provisional Patent Application No. 63 / 088,298, filed on 6 October 2020, entitled “Methods and Apparatus for a Distributed Database within a Network,” which is incorporated herein by reference in its entirety. [Background technology]

[0002] The embodiments described herein relate in general to database systems, and more particularly to methods and apparatus for implementing database systems across multiple devices in a network.

[0003] Some known distributed database systems attempt to achieve consensus on values ​​within the distributed database system (for example, regarding the order in which transactions occur). For example, an online multiplayer game may have many computer servers that users can access to play the game. If two users try to pick up a particular item in the game at the same time, it is important that the servers in the distributed database system eventually reach an agreement on which of the two users picked up the item first.

[0004] Such distributed consensus can be handled by methods and / or processes, such as the Paxos algorithm or a variation thereof. Under such methods and / or processes, one server in the database system is set up as the "leader," and the leader determines the order of events. Events (for example, in a multiplayer game) are forwarded to the leader, the leader selects an order for the events, and the leader broadcasts that order to the other servers in the database system.

[0005] However, such known approaches use servers operated by a party trusted by the database system's users (e.g., game players) (e.g., a central administration server). Therefore, there is a need for methods and apparatus for distributed database systems that do not require a leader or trusted third party to operate the database system. [Overview of the project]

[0006] In some embodiments, the method includes defining an address book for a distributed database. The address book includes identifiers for each computing device from a set of computing devices that implement the distributed database over a network. The method further includes receiving events from computing devices from the set of computing devices, which include transactions for updating the address book, and calculating the number of event reception rounds based on the consensus protocol of the distributed database that uses the address book. The method further includes updating the address book based on transactions to define an updated address book after a predetermined number of rounds, at least one of the event reception rounds or updates to the address book. [Brief explanation of the drawing]

[0007] [Figure 1] This is a high-level block diagram illustrating a distributed database system according to one embodiment. [Figure 2] This is a block diagram illustrating a computing device in a distributed database system according to one embodiment. [Figure 3] An example of a hash graph based on one embodiment will be illustrated. [Figure 4] An example of a hash graph based on one embodiment will be illustrated. [Figure 5] An example of a hash graph based on one embodiment will be illustrated. [Figure 6] An example of a hash graph based on one embodiment will be illustrated. [Figure 7]A flowchart illustrating a communication flow between a first computing device and a second computing device according to one embodiment. [Figure 8] An example of a hash graph according to one embodiment. [Figure 9] An example of a hash graph according to one embodiment. [Figure 10A] Illustrates an exemplary consensus scheme for use with a hash graph according to one embodiment. [Figure 10B] Illustrates an exemplary consensus scheme for use with a hash graph according to one embodiment. [Figure 11A] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 11B] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 12A] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 12B] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 13A] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 13B] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 13C] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 13D] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 13E] Illustrates an exemplary consensus scheme for use with a hash graph according to another embodiment. [Figure 14]An example of an address book associated with a distributed database system, according to one embodiment, is provided. [Figure 15] This flowchart illustrates a method for updating an address book according to one embodiment. [Figure 16] This flowchart illustrates a method by which a computing device connects to and / or joins a distributed database, according to one embodiment. [Modes for carrying out the invention]

[0008] In some embodiments, the method includes defining an address book for a distributed database. The address book includes identifiers for each computing device from a set of computing devices that implement the distributed database over a network. The method further includes receiving events from computing devices from the set of computing devices, which include transactions for updating the address book, and calculating the number of event reception rounds based on the consensus protocol of the distributed database that uses the address book. The method further includes updating the address book based on transactions to define an updated address book after a predetermined number of rounds, at least one of the event reception rounds or updates to the address book.

[0009] In some embodiments, the device includes a memory for a computing device associated with a distributed database implemented by a set of computing devices via a network operably coupled to the set of computing devices, and a processor operably coupled to the memory. The processor is configured to define an address book for the distributed database. The address book includes identifiers for each computing device from the set of computing devices implementing the distributed database. The processor is configured to receive events from computing devices from the set of computing devices, including transactions for updating the address book, and to calculate attributes (e.g., round number or created round) for each event from a group of events. An event is included in a group of events. The processor is configured to calculate the received round of an event based on the consensus protocol of the distributed database using the address book. The received round may be based on a threshold number of events from a set of events that are descendants of the event. The processor is further configured to update the address book based on transactions to define an updated address book after a predetermined number of rounds, at least one of the received rounds of an event or previous updates to the address book. The processor is configured to recalculate attributes for each event from the group of events using the updated address book when that event does not have descendant events from the set of events.

[0010] In some embodiments, a non-transient processor-readable medium stores code representing instructions to be executed by the processor. The code includes code to cause the processor to connect, over a network, to a set of computing devices implementing a distributed database, and as a node implementing the distributed database. The code further includes code to cause the processor to receive the state of the distributed database associated with a completed round of the consensus protocol from the computing devices of the set of computing devices. The state includes an index of the core set of events associated with the completed round, along with the round identifier of each event from the core set of events. The code further includes code to cause the processor to receive the set of events associated with the state from the set of computing devices, and to compute a set of attributes for each event from the set of events based on the core set of events and the round identifier of each event from the core set of events. The code includes code to cause the processor to construct a directed acyclic graph (DAG) based on the set of events and the set of attributes for the events, and to use the DAG to compute the order of events associated with the next round of the consensus protocol.

[0011] In some embodiments, the apparatus includes an instance of a distributed database in a first computing device, which is configured to be included in a set of computing devices implementing the distributed database via a network operably coupled to a set of computing devices. The apparatus also includes a processor operably coupled to memory that stores the instance of the distributed database. The processor is configured to define a first event linked to a first set of events at a first time. The processor is configured to receive, at a second time following the first time, a signal from a second computing device from the set of computing devices representing a second event that is (1) defined by the second computing device and (2) linked to a second set of events. The processor is configured to identify the sequence associated with a third set of events, at least based on the results of a protocol. Each event from the third set of events is from at least one of the first set of events or the second set of events. The processor is configured to store the sequence associated with the third set of events in the instance of the distributed database.

[0012] In some cases, each event from a third set of events is associated with a set of attributes (e.g., sequence number, generation number, round number, received round number, and / or timestamp). The protocol result may include values ​​for each attribute from the set of attributes for each event from the third set of events. The value for the first attribute from the set of attributes may include a first numeric value, and the value for the second attribute from the set of attributes may include a binary value associated with the first numeric value. The binary value for the second attribute for an event from the third set of events (e.g., round increment value) may be based on whether the relationship between that event and the fourth set of events linked to that event satisfies a criterion (e.g., the number of events strongly identified by that event). Each event from the fourth set of events is associated with a first common attribute (e.g., a common round number, an indicator of being the first event of round R) as (1) an ancestor of the events from the third set of events and (2) a remaining event from the fourth set of events. The first common attribute can indicate a first / initial instance in which an event defined by each computing device from a set of computing devices is associated with a first specific value (e.g., an indicator that it is the first event of round R).

[0013] A third attribute value from the set of attributes (e.g., number of received rounds) may include a second numerical value based on the relationship between the event and a fifth set of events linked to the event. Each event from the fifth set of events is a descendant of the event and, as the remaining events from the fifth set of events, is associated with a second common attribute (e.g., famous). The second common attribute may be associated with (1) a third common attribute indicating a first instance (e.g., the first event or witness of round R) in which a second event defined by each computing device from the set of computing devices is associated with a second specific value different from a first specific value, and (2) a result based on a set of metrics. Each metric from the set of metrics may be associated with an event from the sixth set of events. Each event from the sixth set of events may be associated with a fourth common attribute indicating a first / initial instance, and a third event defined by each computing device from the set of computing devices is associated with a third specific value different from the first and second specific values. In some cases, the first specific value is a first integer (e.g., the first round number R), the second specific value is a second integer greater than the first integer (e.g., the second round number R+n), and the third specific value is a third integer greater than the second integer (e.g., the third round number R+n+m).

[0014] As used herein, a module can be any assembly and / or set of operablely coupled electrical components associated with performing a particular function, and may include, for example, memory, a processor, electrical traces, optical connectors, software (running in hardware), and the like.

[0015] As used herein, the singular forms "a," "an," and "the" refer to multiple objects unless the context explicitly indicates otherwise. For example, the term "module" is intended to mean a single module or a combination of modules. Similarly, "network" is intended to mean a single network or a combination of networks.

[0016] Figure 1 is a high-level block diagram illustrating a distributed database system 100 according to one embodiment. While Figure 1 illustrates a distributed database 100 implemented across four computing devices (computer device 110, computer device 120, computer device 130, and computer device 140), it should be understood that the distributed database 100 can use any number of sets of computing devices, including those not shown in Figure 1. Network 105 can be any type of network (e.g., local area network (LAN), wide area network (WAN), virtual network, telecommunications network) implemented as a wired and / or wireless network and used to operably connect the computing devices 110, 120, 130, and 140. As will be described in more detail herein, in some embodiments, for example, the computing devices are personal computers connected to each other via an Internet Service Provider (ISP) and the Internet (e.g., network 105). In some embodiments, connections can be defined between any two of the computing devices 110, 120, 130, and 140 via the network 105. As shown in Figure 1, for example, a connection can be defined between computing device 110 and any one of computing devices 120, 130, or 140.

[0017] In some embodiments, computing devices 110, 120, 130, and 140 can communicate with each other (e.g., send data to each other and / or receive data from each other) and with the network via an intermediate network and / or alternative network (not shown in Figure 1). Such intermediate network and / or alternative network may be of the same type and / or a different type as network 105.

[0018] Each computing device 110, 120, 130, 140 can be any type of device configured to transmit data over the network 105 to send data to and / or receive data from one or more other computing devices. Figure 1 shows an example of a computing device. Computing device 110 includes memory 112, a processor 111, and an output device 113. Memory 112 may be, for example, random access memory (RAM), a memory buffer, a hard drive, a database, erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), or read-only memory (ROM). In some embodiments, the memory 112 of computing device 110 contains data associated with an instance of a distributed database (e.g., a distributed database instance 114). In some embodiments, memory 112 stores instructions causing the processor to execute modules, processes, and / or functions, and these modules, processes, and / or functions are associated with recording synchronization events, and / or recording previous synchronization events with other computing devices, and / or the order of synchronization events, and / or the order of transactions within the events, parameters associated with identifying the order of synchronization events and / or transactions, and / or the values ​​of the parameters (e.g., a database field that quantifies the transactions, a database field that quantifies the order in which the events occur, and / or any other suitable field whose values ​​may be stored in the database), to and / or from another instance of the distributed database (e.g., a distributed database instance 124 on computing device 120).

[0019] The distributed database instance 114 can be configured to manipulate data, for example, including storing, modifying, and / or deleting data. In some embodiments, the distributed database instance 114 may be a set of arrays, a set of data structures, a relational database, an object database, a post-relational database, and / or any other suitable type of database or storage. For example, the distributed database instance 114 may store data related to any particular function and / or industry. For example, the distributed database instance 114 may store financial transactions (e.g., of a user of computing device 110) including values ​​and / or vectors of values ​​related to the history of ownership of a particular financial instrument. Generally, a vector can be any set of parameter values, and a parameter can be any data object and / or database field that can take different values. Thus, the distributed database instance 114 may have several parameters and / or fields, each of which is associated with a vector of values. The vector of values ​​is used to determine the actual values ​​of the parameters and / or fields within the database instance 114. In some cases, the distributed database instance 114 stores records of synchronization events, records of previous synchronization events with other computing devices, the order of synchronization events, the order of transactions within an event, parameters and / or values ​​associated with identifying the order of synchronization events and / or transactions (e.g., used when calculating the order using the consensus scheme described herein), and parameter values ​​(e.g., a database field that quantifies a transaction, a database field that quantifies the order in which events occur, and / or any other suitable fields in which values ​​can be stored in the database).

[0020] In some cases, the distributed database instance 114 may also store database state variables and / or the current state. The current state may be a state, balance, condition and / or similar associated with the result of a transaction. Similarly, the state may include data structures and / or variables modified by the transaction. In other cases, the current state may be stored in a separate database and / or a portion of memory 112. In yet another case, the current state may be stored in the memory of a computing device different from computing device 110.

[0021] In some cases, the distributed database instance 114 can also be used to implement other data structures, such as sets of (key, value) pairs. Transactions recorded by the distributed database instance 114 may include, for example, adding, deleting, or modifying (key, value) pairs within a set of (key, value) pairs.

[0022] In some cases, queries can be made to the distributed database system 100 or to any of the distributed database instances 114, 124, 134, or 144. For example, a query may include a key, and the results returned from the distributed database system 100 or the distributed database instances 114, 124, 134, or 144 may be the value associated with the key. Also, in some cases, the distributed database system 100 or any of the distributed database instances 114, 124, 134, or 144 can be modified through a transaction. For example, a transaction that modifies a database may include a digital signature from the party authorizing the modification transaction.

[0023] The distributed database system 100 can be used for many purposes, such as storing attributes associated with various users in a distributed identity information system. For example, such a system can use user identity information and / or identifiers as "keys" and a list of attributes associated with the user as "values". In some cases, the identity information and / or identifiers may be cryptographic public keys with corresponding private keys known to that user. Each attribute may be digitally signed, for example, by an authority that has the right to assert that attribute. Each attribute may also be encrypted, for example, using a public key associated with an individual or group of individuals that has the right to read the attribute. Some keys or values ​​may also have a list of public keys of parties authorized to modify and / or delete the keys or values ​​attached to them.

[0024] In another example, a distributed database instance 114 can store data related to a massively multiplayer game (MMG), such as the current status and ownership of gameplay items. In some cases, the distributed database instance 114 can be implemented within a computing device 110, as shown in Figure 1. In other cases, the distributed database instance is accessible by the computing device (e.g., via a network) but is not implemented within the computing device (not shown in Figure 1).

[0025] The processor 111 of the computing device 110 may be any suitable processing device configured to run and / or execute the distributed database instance 114. For example, the processor 111 may be configured to update the distributed database instance 114 in response to receiving signals from the computing device 120 and / or to cause the computing device 120 to send signals, as will be described in more detail herein. More specifically, as will be described in more detail herein, the processor 111 may be configured to run modules, functions, and / or processes for updating the distributed database instance 114 in response to receiving synchronization events associated with transactions from another computing device, records associated with the sequence of synchronization events, and / or similar. In some embodiments, the processor 111 may be configured to run modules, functions, and / or processes for updating the distributed database instance 114 in response to receiving parameter values ​​stored in another instance of the distributed database (e.g., the distributed database instance 124 in computing device 120) and / or to cause the computing device 120 to send the parameter values ​​stored in the distributed database instance 114 in computing device 110. In some embodiments, the processor 111 may be a general-purpose processor, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), and the like.

[0026] The display 113 may be any suitable display, such as a liquid crystal display (LCD) or a cathode ray tube display (CRT). In other embodiments, any of the computing devices 110, 120, 130, and 140 may include another output device instead of, or in addition to, the displays 113, 123, 133, and 143. For example, any one of the computing devices 110, 120, 130, and 140 may include an audio output device (e.g., a speaker), a haptic output device, and / or the like. In yet another embodiment, any of the computing devices 110, 120, 130, and 140 may include an input device instead of, or in addition to, the displays 113, 123, 133, and 143. For example, any one of the computing devices 110, 120, 130, and 140 may include a keyboard, a mouse, and / or the like.

[0027] Although Figure 1 shows them within a single computing device, in some cases, a processor configured to run modules, functions, and / or processes for updating a distributed database may reside in a computing device separate from its associated distributed database. In such cases, for example, the processor can be operablely coupled to a distributed database instance via a network. For example, the processor can run a consensus scheme to identify the order of events and / or transactions (e.g., as a result of synchronization with other distributed database instances) and can send signals containing the order of events and / or transactions to the associated distributed database instance via the network. The associated distributed database instance can then store the order of events, the order of transactions, and / or state variables based on the order of transactions. In this way, the functions and storage associated with a distributed database can be distributed. Furthermore, even if the database is implemented in a computing device separate from the computing device having a processor that implements modules, functions, and / or processes (e.g., consensus schemes) associated with the distributed database system, the processor can query its associated distributed database instance and store database state variables and / or current state, as well as other preferred operations described herein, within that distributed database instance. Otherwise, the functions and / or methods described herein can be executed across any number of computing devices (e.g., within a distributed computing environment and / or cluster), and the results and / or values ​​of such functions and / or methods can be stored in memory and / or storage on any preferred computing device.

[0028] The computing device 120 has a processor 121, memory 122, and display 123, which may be structurally and / or functionally similar to the processor 111, memory 112, and display 113, respectively. Similarly, the distributed database instance 124 may be structurally and / or functionally similar to the distributed database instance 114.

[0029] The computing device 130 has a processor 131, memory 132, and display 133, which may be structurally and / or functionally similar to the processor 111, memory 112, and display 113, respectively. Similarly, the distributed database instance 134 may be structurally and / or functionally similar to the distributed database instance 114.

[0030] The computing device 140 has a processor 141, memory 142, and display 143, which may be structurally and / or functionally similar to the processor 111, memory 112, and display 113, respectively. Similarly, the distributed database instance 144 may be structurally and / or functionally similar to the distributed database instance 114.

[0031] Although computing devices 110, 120, 130, and 140 are shown as being similar to one another, each computing device in the distributed database system 100 may be different from the others. Each computing device 110, 120, 130, and 140 in the distributed database system 100 may be, for example, one of the following: computing entities (e.g., personal computing devices such as desktop computers and laptop computers), mobile phones, or personal digital assistants (PDAs). For example, computing device 110 may be a desktop computer, computing device 120 may be a smartphone, and computing device 130 may be a server.

[0032] In some embodiments, one or more parts of the computing devices 110, 120, 130, and 140 may include hardware-based modules (e.g., digital signal processors (DSPs), field-programmable gate arrays (FPGAs)) and / or software-based modules (e.g., modules of computer code stored in memory and / or executed on the processors). In some embodiments, one or more functions associated with the computing devices 110, 120, 130, and 140 (e.g., functions associated with processors 111, 121, 131, and 141) may be contained in one or more modules (see, for example, Figure 2).

[0033] The properties of the distributed database system 100, including the properties of computing devices (e.g., computing devices 110, 120, 130, 140), the number of computing devices, and the network 105, can be selected in any number of ways. In some cases, the properties of the distributed database system 100 can be selected by the administrator of the distributed database system 100. In other cases, the properties of the distributed database system 100 can be selected collectively by the users of the distributed database system 100.

[0034] Because a distributed database system 100 is used, no leader is designated among the computing devices 110, 120, 130, and 140. Specifically, none of the computing devices 110, 120, 130, or 140 are identified and / or selected as a leader for resolving disputes among the values ​​stored in the distributed database instances 114, 124, 134, and 144 of the computing devices 110, 120, 130, and 140. Instead, the computing devices 110, 120, 130, and 140 can collectively converge to the parameter values ​​using an event synchronization process, a voting process, a consensus scheme and / or protocol, and / or other methods described herein.

[0035] By eliminating the leader in a distributed database system, the security of the distributed database system is increased. Specifically, in the presence of a leader, there is a single point of attack and / or failure. If malicious software infects the leader and / or if the parameter values ​​in the leader's distributed database instance are maliciously tampered with, the failure and / or inaccurate values ​​propagate throughout the other distributed database instances. However, in a leaderless system, there is no single point of attack and / or failure. Specifically, if a parameter in a distributed database instance of a leaderless system contains a value, that value changes after that distributed database instance exchanges values ​​with other distributed database instances in the system, as will be further described herein. Additionally, the leaderless distributed database system described herein increases the rate of convergence while reducing the amount of data transmitted between devices, as will be further described herein.

[0036] Figure 2 illustrates a computing device 200 of a distributed database system (e.g., distributed database system 100) according to one embodiment. In some embodiments, computing device 200 may be similar to computing devices 110, 120, 130, and 140 illustrated and described with respect to Figure 1. Computing device 200 includes a processor 210 and memory 220. The processor 210 and memory 220 are operably coupled to each other. In some embodiments, the processor 210 and memory 220 may be similar to the processor 111 and memory 112 described in detail with respect to Figure 1, respectively. As shown in Figure 2, the processor 210 includes a database convergence module 211 and a communication module 210, and the memory 220 includes a distributed database instance 221. The communication module 212 enables computing device 200 to communicate with other computing devices (e.g., to send data to and / or receive data from other computing devices). In some embodiments, a communication module 212 (not shown in Figure 1) enables computing device 110 to communicate with computing devices 120, 130, and 140. The communication module 210 may include, and / or enable, a network interface controller (NIC), wireless connectivity, wired ports, and / or similar. Thus, the communication module 210 can establish and / or maintain a communication session between computing device 200 and another device (for example, over a network such as network 105 in Figure 1 or the Internet (not shown)). Similarly, the communication module 210 may enable computing device 200 to send data to another device and / or receive data from another device.

[0037] In some cases, the database convergence module 211 exchanges events and / or transactions with other computing devices, stores the events and / or transactions it receives, and can calculate an ordering of events and / or transactions (e.g., consensus or total order) based on a partial order defined by a pattern of references between events. Each event may be a record containing identifiers (e.g., cryptographic hashes) of the two preceding events (linking that event to the two preceding events and their ancestor events, and vice versa), payload data (such as the transaction being recorded), the current time, a timestamp (e.g., date and UTC time) asserted by the event creator as the time the event was first defined, and / or similar information. Each of the communicating computing devices is called a “member” or “hash graph member”. In some cases, the first event defined by a member contains only the hash of a single event defined by another member. In such cases, the member does not yet have a previous self-hash (e.g., the hash of an event previously defined by that member). In some cases, the first event in a distributed database does not contain the hash of any previous event (because no previous event exists for that distributed database).

[0038] In some embodiments, such a cryptographic hash of the two events described above may be a hash value defined based on a cryptographic hash function that takes the events as input. Specifically, in such embodiments, the event includes a particular sequence or string of bytes (representing information about that event). The hash of the event may be the value returned by the hash function using the sequence of bytes for that event as input. In other embodiments, any other suitable data associated with the event (e.g., an identifier, serial number, bytes representing a particular part of the event) can be used as input to the hash function to compute the hash of that event. Any suitable hash function can be used to define the hash. In some embodiments, each member uses the same hash function so that the same hash is generated for each member for a given event. The event can then be digitally signed by the member that defines and / or creates the event. In some implementations, any other suitable identifier for the event may be used instead of the hash value.

[0039] In some cases, a set of events and their interconnections can form a directed acyclic graph (DAG). In some cases, each event in the DAG references zero or more (e.g., two) previous events (linking that event to previous events and their ancestor events, and vice versa), and since each reference is strictly to a previous event, no loops exist. In some embodiments, the DAG is based on cryptographic hashes, so the data structure can be called a hash graph (also referred to herein as a "hashDAG"). In other embodiments, the DAG can be based on any other suitable identifier for events. The hash graph or DAG directly encodes a partial order, meaning that if Y contains a hash of X, or if Y contains a hash of an event containing a hash of X, or for any such path of any length, it is known that event X comes before event Y. However, if there is no path from X to Y or from Y to X, the partial order does not define which event came first. Thus, a database convergence module can compute a total order or consensus order from the partial order. This can be done by any suitable deterministic function used by the computing device so that the computing device calculates the same order. In some embodiments, each member can recalculate this order after each synchronization, and eventually these orders may converge so that a consensus emerges.

[0040] Consensus algorithms and / or methods can be used to determine the hash graph, the entire order or consensus order of events in a DAG, and / or the order of transactions stored within events. The order of transactions can similarly define the state of the database as a result of performing those transactions in that order. The defined state of the database can be stored as a database state variable. In some embodiments, an instance of a distributed database (e.g., distributed database instance 114) stores the hash graph, and / or transactions, and / or the order of transactions, and / or events, and / or the order of events, and / or the state resulting from performing transactions.

[0041] In some cases, the database convergence module can derive the total order (also called the consensus order) from the partial order in the hash graph using the following function: For each of the other computing devices (called "members"), the database convergence module can examine the hash graph to discover the order in which events (and / or indices of those events) were received by that member. The database convergence module can then calculate as if that member had assigned a numerical "rank" to each event, where the rank is 1 for the first event received by that member, 2 for the second event received by that member, and so on. The database convergence module can do this for each member in the hash graph. For each event, the database convergence module can then calculate the median of the assigned ranks and sort the events by those medians. Sorting can break equilibrium in a deterministic way, such as sorting two events of the same rank by the numerical order of their hashes, or by some other method using the same method by each member's database convergence module. The result of this sort is the total order.

[0042] Figure 6 illustrates hash graph 640 as an example for determining a total order (or consensus order) from a partial order. Hash graph 640 illustrates two events (the bottommost striped circle and the bottommost dotted circle) and the time when each member first receives an index of those events (the other striped circle and the dotted circle). The names of each member at the top are colored according to which event came first in their partial order or later order. There are more initial votes for the striped circles than for the dotted circles, and therefore the consensus vote for each of these members is striped. In other words, the members eventually converge on the agreement that the striped events occurred before the dotted events.

[0043] In this example, the members (computation devices labeled Alice, Bob, Carol, Dave, and Ed) function to define a consensus on whether event 642 occurred first or event 644 occurred first. Each circle in the striped pattern indicates the event in which a member first received event 644 (and / or an index of event 644). Similarly, each circle in the dotted pattern indicates the event in which a member first received event 642 (and / or an index of event 642). As shown in hash graph 640, Alice, Bob, and Carol each received event 644 (and / or an index of event 644) before event 642. Both Dave and Ed received event 642 (and / or an index of event 642) before event 644 (and / or an index of event 644). Therefore, since more members received event 644 before event 642, each member can determine the total order for indicating that event 644 occurred before event 642.

[0044] In other cases, the database convergence module can use different functions to compute the total order and / or consensus order from the partial order in the hash graph. In such embodiments, for example, the database convergence module may use the following function to compute the total order, where a positive integer Q is a parameter shared by the members.

[0045]

number

[0046] In this embodiment, fast(x,y) gives the position of y in the total order of events in the opinion of creator(x) almost immediately after x is created and / or defined. When Q is infinite, the above calculates the same total order as in the embodiments described earlier. When Q is finite and all members are online, the above calculates the same total order as in the embodiments described earlier. When Q is finite and a small number of members are online at a given time, this function allows the online members to reach a consensus among themselves that remains unchanged even as new members slowly come online one by one. However, if partitions exist in the network, the members of each partition can reach a consensus of their own. Then, when the partitions are restored, the members of the smaller partitions adopt the consensus of the larger partition.

[0047] In other cases, as described with respect to Figures 8–13E, the database convergence module can calculate the total order from the partial order in the hash graph using different functions. As shown in Figures 8–9, each member (Alice, Bob, Carol, Dave, and Ed) creates and / or defines events (1401–1413 shown in Figure 8, and 1501–1506 shown in Figure 9). Using the functions and subfunctions described with respect to Figures 8–13E, the total order of events can be calculated by sorting the events by their reception round, breaking them by their reception timestamps, and breaking them by their signatures, as will be described in more detail herein. In other cases, the total order of events can be calculated by sorting the events by their reception round, breaking them by their reception generation (instead of their reception timestamps), and breaking them by their signatures. The following paragraphs describe in detail the functions used to calculate and / or define the reception round and reception generation of events in order to determine the order of events. The following terms are used and illustrated in relation to Figures 8 to 13E.

[0048] "Parent": If Y contains the hash of X, then event X is the parent of event Y. For example, in Figure 8, the parents of event 1412 include events 1406 and 1408.

[0049] "Ancestors": The ancestors of event X are X, X's parents, X's parents' parents, and so on. For example, in Figure 8, the ancestors of event 1412 are events 1401, 1402, 1403, 1406, 1408, and 1412. We can say that the ancestors of an event are linked to that event, and vice versa.

[0050] "Descendants": The descendants of event X are X, X's children, X's children's children, and so on. For example, in Figure 8, the descendants of event 1401 are all the events shown in the figure. In another example, the descendants of event 1403 are events 1403, 1404, 1406, 1407, 1409, 1410, 1411, 1412, and 1413. We can say that the descendants of an event are linked to that event, and vice versa.

[0051] "N": The total number of members in the population. For example, in Figure 8, the members are computing devices labeled Alice, Bob, Carol, Dave, and Ed, and N is equal to 5.

[0052] "M": The smallest integer greater than a certain proportion of N (for example, greater than 2 / 3 of N). For example, in Figure 8, if the proportion is defined as 2 / 3, then M is equal to 4. In other cases, M may be defined as, for example, different proportions of N (for example, 1 / 3, 1 / 2, etc.), a specific predefined number, and / or any other preferred form.

[0053] "Self-parent": The self-parent of event X is its parent event Y, which is created and / or defined by the same member. For example, in Figure 8, the self-parent of event 1405 is 1401.

[0054] "One's own ancestors": Event X's own ancestors are X, X's own parents, X's own parents' own parents, and so on.

[0055] "Sequence Number" (or "SN"): This is an integer attribute of an event, defined as the sequence number of its parent plus 1. For example, in Figure 8, the parent of event 1405 is 1401. Since the sequence number of event 1401 is 1, the sequence number of event 1405 is 2 (i.e., 1 plus 1).

[0056] "Generation Number" (or "GN"): An integer attribute of an event, defined as the maximum generation number of the event's parents plus 1. For example, in Figure 8, event 1412 has two parents, events 1406 and 1408, with generation numbers 4 and 2, respectively. Therefore, the generation number of event 1412 is 5 (i.e., 4 plus 1).

[0057] "Round Increment" (or "RI"): An attribute of the event, which can be either 0 or 1.

[0058] Round Number (or RN): An integer attribute of an event. In some cases, this is also called the round created or created round. In some cases, the round number can be defined as the maximum round number of the event's parents plus the event's round increment. For example, in Figure 8, event 1412 has two parents, events 1406 and 1408, both of which have round number 1. Event 1412 also has a round increment of 1. Therefore, the round number of event 1412 is 2 (i.e., 1 plus 1). In other cases, an event may have a round number R if R is the smallest integer such that the event can strongly see (as described herein) at least M events defined and / or created by different members, all of which have round number R-1. If no such integer exists, the event's round number may be a default value (e.g., 0, 1, etc.). In such cases, the event's round number can be calculated without using the round increment. For example, in Figure 8, if M is defined as the smallest integer greater than half of N, then M is 3. In this case, event 1412 strongly sees M events 1401, 1402, and 1408, each defined by a different member, and each having round number 1. Event 1412 cannot strongly see at least M events, each defined by a different member, that have round number 2. Therefore, the round number of event 1412 is 2. In some cases, the first event in a distributed database may contain round number 1. In other cases, the first event in a distributed database may contain round number 0 or any other suitable number.

[0059] "Forking": Event X is a fork of Event Y if Event X and Event Y are defined and / or created by the same member and neither is an ancestor of the other. For example, in Figure 9, member Dave forks by creating and / or defining Events 1503 and 1504, both of which have the same parent (i.e., Event 1501), so that Event 1503 is not an ancestor of Event 1504 and Event 1504 is not an ancestor of Event 1503.

[0060] Forking "Identification": Forking can be "identified" by a third event created and / or defined after two events that fork each other, if both of these events are ancestors of the third event. For example, in Figure 9, member Dave forks by creating events 1503 and 1504, neither of which are ancestors of the other. Since both events 1503 and 1504 are ancestors of event 1506, this fork can be identified by the later event 1506. In some cases, fork identification can indicate that a particular member (e.g., Dave) has done something wrong.

[0061] Event "Identification": If event X does not have an ancestor event Z that is a fork of event Y, then X "identifies" or "sees" the ancestor event Y. For example, in Figure 8, since event 1403 is an ancestor of event 1412, and event 1412 does not have an ancestor event that is a fork of event 1403, event 1412 identifies (also called "sees") event 1403. In some cases, event X can identify event Y if X does not identify any previous forking of event Y. In such cases, event X can see event Y even if event X identifies a forking by a member that defines event Y following event Y. Event X does not identify the event by that member that follows the forking. Furthermore, if a member defines two different events, both of which are the first events in that member's history, then event X can identify the forking but not the event by that member.

[0062] "Strong identification" of an event (also referred to herein as "strongly seeing"): If X identifies Y, then event X "strongly identifies" (or "strongly sees") an ancestor event Y created and / or defined by the same members as X. If there exists a set of events S that (1) includes both X and Y, (2) is an ancestor of event X, (3) is a descendant of ancestor event Y, (4) is identified by X, (5) each can identify Y, and (6) is created and / or defined by at least M different members, then event X "strongly identifies" an ancestor event Y that is not created and / or defined by the same members as X. For example, in Figure 8, if M is defined as the smallest integer greater than 2 / 3 of N (i.e., M = 1 + floor(2N / 3), which could be 4 in this example), then event 1412 strongly identifies ancestor event 1401. This is because the set of events 1401, 1402, 1406, and 1412 is a set of at least four events that are ancestors of event 1412 and descendants of event 1401, each created and / or defined by four members Dave, Carol, Bob, and Ed, and event 1412 identifies each of events 1401, 1402, 1406, and 1412, and each of events 1401, 1402, 1406, and 1412 identifies event 1401. Similarly, event X (e.g., event 1412) can "strongly see" event Y (e.g., event 1401) if X can see at least M events (e.g., events 1401, 1402, 1406, and 1412) created or defined by different members, each of which can see Y.

[0063] An event is a “first event of round R” (also known herein as a “witness”) if an event (1) has round number R and (2) has a parent with a round number smaller than R, or has no parent. For example, in Figure 8, event 1412 is a “first event of round 2” because it has round number 2 and its parent is event 1408, which has round number 1 (i.e., smaller than 2).

[0064] In some cases, the round increment of event X is defined as 1 only if X "strongly identifies" at least M "first events of round R," where R is the highest round number of its parent. For example, in Figure 8, M is 3 if M is defined as the smallest integer greater than half of N. Then event 1412 strongly identifies M events 1401, 1402, and 1408, all of which are first events of round 1. Both parents of 1412 have round number 1, and 1412 strongly identifies at least M first events of round 1, and therefore the round increment of 1412 is 1. Each event in the figure marked "RI=0" fails to strongly identify at least M first events of round 1, and therefore its round increment is 0.

[0065] In some cases, the following method can be used to determine whether an event X can strongly identify an ancestor event Y. For each first ancestor event Y in round R, maintain an array of integers A1, one for each member, and give the lowest sequence number of event X, then X can identify Y if that member created and / or defined event X. For each event Z, maintain an array of integers A2, one for each member, and give the highest sequence number of event W created and / or defined by that member, so that Z can identify W. To determine whether Z can strongly identify an ancestor event Y, count the number of element positions E such that A1[E] ≤ A2[E]. Event Z can strongly identify Y only if this count is greater than M. For example, in Figure 8, members Alice, Bob, Carol, Dave, and Ed can each identify event 1401, where the oldest events they can identify are their respective member events {1404, 1403, 1402, 1401, 1408}. These events have sequence number A1={1,1,1,1,1}. Similarly, the most recent event by each member, identified by event 1412, is events {none, 1406, 1402, 1401, 1412}, where Alice is listed as "none" because 1412 cannot identify an event by Alice. Each of these events has sequence number A2={0,2,1,1,2}, where all events have positive sequence numbers, so 0 means Alice has no events identified by 1412. Comparing list A1 to list A2, we get the result {1≦0,1≦2,1≦1,1≦1,1≦2}, which is equal to {false, true, true, true, true}, which has four true values. Thus there exists a set of four events S that are ancestors of 1412 and descendants of 1401. 4 is at least M, and therefore 1412 strongly identifies 1401.

[0066] Another variation of the method for determining whether event X can strongly identify ancestor event Y using A1 and A2 is as follows: If the number of integer elements in both arrays is less than 128, it is possible to store each element in one byte, pack eight such elements into one 64-bit word, and have A1 and A2 be arrays of such words. The most significant bit of each byte in A1 can be set to 0, and the most significant bit of each byte in A2 can be set to 1. Subtract the two corresponding words, then perform a bitwise AND using a mask that sets all bits except the most significant bit to 0, and then right-shift by 7 bits to obtain a value that can be expressed in the C programming language as ((A2[i]-A1[i])&0x8080808080808080)>>7). This can be added to an execution accumulator S initialized to 0. After performing this multiple times, the accumulator is converted to a count by shifting and adding bytes to obtain ((S&0xff)+((S>>8)&0xff)+((S>>16)&0xff)+((S>>24)&0xff)+((S>>32)&0xff)+((S>>40)&0xff)+((S>>48)&0xff)+((S>>56)&0xff)). In some cases, these calculations can be performed in C, Java, and / or similar programming languages. In other cases, the calculations can be performed using processor-specific instructions such as Advanced Vector Extensions (AVX) instructions provided by Intel and AMD, or their equivalents in a graphics processing unit (GPU) or general-purpose graphics processing unit (GPGPU). In some architectures, calculations can be performed more quickly by using words larger than 64 bits, such as 128, 256, 512, or more bits.

[0067] "Famous" Events: Round R event X is "famous" if (1) event X is the "first" event (or "witness") of Round R, and (2) a "yes" decision is reached through the execution of the Byzantine consensus protocol, which is described below. In some embodiments, the Byzantine consensus protocol can be executed by an instance of a distributed database (e.g., distributed database instance 114) and / or a database convergence module (e.g., database convergence module 211). For example, Figure 8 shows five first events of Round 1: 1401, 1402, 1403, 1404, and 1408. If M is defined as the smallest integer greater than half of N, and this is 3, then 1412 is the first event of Round 2. If the protocol is executed longer, the hash graph will grow upwards, and eventually the other four members will also have first events of Round 2 at the top of this figure. Each first event in Round 2 has a "vote" on whether each of the first events in Round 1 is "famous". Event 1412 will vote yes for 1401, 1402, and 1403 being famous because these are identifiable first events in Round 1. Event 1412 will vote no for 1404 being famous because 1412 cannot identify 1404. For a given first event in Round 1, such as 1402, the status of whether or not that event is "famous" is determined by calculating the votes of each first event in Round 2 on whether or not it is famous. These votes then propagate to the first events in Round 3, then to the first events in Round 4, and so on, until there is an agreement on whether or not 1402 was famous. The same process is repeated for the other first events.

[0068] The Byzantine Agreement Protocol can collect and use the votes and / or decisions of the first event of round R to identify a "famous event." For example, the first event Y of round R+1 votes "yes" if Y can "identify" event X, and "no" otherwise. Votes are calculated for each round G, G=R+2, R+3, R+4, etc., until a decision is reached by any member. Some of these rounds may be "majority" rounds, and some may be "coin" rounds. In some cases, for example, round R+2 is a majority round, and future rounds are designated (for example, according to a predefined schedule) as either majority rounds or coin rounds. In some cases, for example, whether a future round is a majority round or a coin round can be arbitrarily determined, given the condition that there cannot be two consecutive coin rounds. For example, it could be predefined that there are five majority voting rounds, followed by one coin round, then five more majority voting rounds, followed by one coin round, and so on, until an agreement is reached.

[0069] In some cases, if Round G is a majority vote round, the vote can be calculated as follows: If there are at least M Round G events that strongly identify the first of Round G-1 and vote for V (where V is either "yes" or "no"), the consensus decision is V and the Byzantine Agreement Protocol is terminated. Otherwise, each first event of Round G calculates a new vote, which is a majority vote of the first events of Round G-1 that each first event of Round G can strongly identify. If there is a tie and not a majority vote, the vote can be designated as "yes".

[0070] Similarly, if X is the witness of round R (or the first of round R), the results of the votes in rounds R+1, R+2, etc., can be calculated, where each witness in each round votes whether X is famous or not. In round R+1, all witnesses who can see X vote yes, and the other witnesses vote no. In round R+2, all witnesses vote according to the majority vote of the witnesses in round R+1 who can see X most strongly. Similarly, in round R+3, all witnesses vote according to the majority vote of the witnesses in round R+2 who can see X most strongly. This can continue across multiple rounds. In the case of a tie, the vote can be set to yes. Otherwise, ties can be set to no, or randomly. If any round has at least M witnesses who vote no, the election ends and X is not famous. If any round has at least M witnesses who vote yes, the election ends and X is famous. If neither the "yes" nor "no" option receives at least M votes, the election proceeds to the next round.

[0071] As an example, consider a first event X in the round shown below the diagram in Figure 8. In this case, each first event in Round 1 has a vote on whether X is famous or not. Event 1412 can strongly identify the first events 1401, 1402, and 1408 of Round 1. Therefore, the vote in event 1412 is based on the votes in those events. If this is a majority vote round, 1412 checks whether at least M of {1401, 1402, 1408} have yes votes. If so, the judgment is yes, and there is agreement. If at least M of them have voted no, the judgment is no, and there is agreement. If there are no votes of at least M in any direction, 1412 is given a vote that is a majority vote of the votes of 1401, 1402, and 1408 (breaking the tie by voting yes if there is a tie). That vote is then used in the next round and may continue until there is agreement.

[0072] In some cases, if round G is a coin round, the vote can be calculated as follows: If event X can strongly identify at least M firsts in round G-1 that vote for V (where V is either "yes" or "no"), then event X will change its vote to V. Otherwise, if round G is a coin round, each first event X in round G will change its vote to the result of a pseudo-random decision (in some cases similar to a coin flip) defined as the least significant bit of the signature of event X.

[0073] Similarly, in such a case, if the election reaches round R+K (coin round), where K is a specified coefficient (e.g., a multiple of a number such as 3, 6, 7, 8, 16, 32, or any other suitable number), the election does not end in that round. If the election reaches this round, it can continue for at least one more round. In such a round, if event Y is a round R+K witness, and Y can strongly see at least M witnesses from round R+K-1 voting for V, Y votes for V. Otherwise, Y votes according to a random value (e.g., one bit of the signature of event Y (e.g., the least significant bit, the most significant bit, a randomly selected bit), according to the timestamp of event Y, 1 = yes and 0 = no, or vice versa, using the cryptographic "shared coin" protocol and / or any other random determination). This random determination is unpredictable before Y is created and can therefore increase the security of the event and consensus protocol.

[0074] For example, in Figure 8, if Round 2 is a coin round and the vote is about whether some event prior to Round 1 was famous, then Event 1412 first checks whether at least M of {1401, 1402, 1408} voted yes, or whether at least M of them voted no. If so, 1412 votes accordingly. If there are no at least M votes in either direction, 1412 will have a random or pseudo-random vote (based on the least significant bit of the digital signature for Event 1412 generated when Ed signed Event 1412, or when Ed generated and / or defined Event 1412).

[0075] In some cases, the result of a pseudo-random decision may be the result of a crypto-shared coin protocol, which can be implemented, for example, as the least significant bit of a round number threshold signature.

[0076] As described above, in some implementations, the hash graph consensus scheme can include, for example, determining the fame of a witness X in round R. As described above, initial votes can be collected from round R+1 and each event can be counted to vote yes or no depending on whether each event is a descendant of X. An alternative approach may be to collect initial votes from "R+2" instead of "R+1" (or "R+3", "R+4", etc. instead of "R+1"). Additional steps can be optionally added in that approach. In detail, in such implementations, whenever the first event X of round R (or witness X of round R) is an ancestor of a witness in round R+1 created and / or defined by more than two-thirds of the population (i.e., more than 2N / 3 members), X is immediately declared famous and the election is immediately concluded, even before any votes for X are calculated. A second alternative approach is to conduct an election for R using the initial votes collected from R+1. In this case, if the number of members who created and / or defined witnesses in round R, which were determined to be famous, falls below a given threshold T (e.g., below 2N / 3 members), a second election is rerun using the initial votes collected from R+2. Similarly, if the number of famous witnesses for round R identified using votes from round R+1 is insufficient, the election can be completely rerun from the beginning using votes from round R+2 instead of round R+1 (i.e., the results of the election using votes from round R+1 are discarded, and the election is rerun using votes from round R+2).In some implementations, an alternative might be to conduct an election for R using initial votes collected from R+1, in which case a famous witness for round R (e.g., a judge) can be defined as a witness in round R that is an ancestor of a famous witness in round R+1, if the number of members that created and / or defined a witness in round R that was determined to be famous is below a given threshold T (e.g., below 2N / 3 members). (Some are removed to ensure that each member has only one famous witness in round R.)

[0077] The system can be constructed from any one of the methods for calculating the outcome of the pseudo-random decision described above. In some cases, the system cycles through various methods in some order. In other cases, the system can select from different methods according to a predefined pattern.

[0078] "Received Round": Event X has a "received round" of R if R is the smallest integer such that at least half of the famous first events (or famous witnesses) of round R having round number R are descendants of X and / or can be seen. Otherwise, any other suitable proportion can be used. For example, in another case, event X has a "received round" of R if R is the smallest integer such that at least a predefined proportion (e.g., 40%, 60%, 80%, etc.) of the famous first events (or famous witnesses) of round R having round number R are descendants of X and / or can be seen.

[0079] In some cases, the "received generation" of event X can be calculated as follows: Determine which member created and / or defined the first event in each round R that can identify event X. Then determine the generation number of the oldest event by that member that can identify X. Then define the "received generation" of X as the median of that list.

[0080] In some cases, the "received timestamp" T of event X may be the median of timestamps within the event that are the first event identified and / or seen by each member for X. For example, the received timestamp of event 1401 may be the median of the timestamp values ​​of events 1402, 1403, 1403, and 1408. In some cases, the timestamp of event 1401 may be included in the median calculation. In other cases, the received timestamp of X may be any other value or combination of timestamp values ​​within the event that are the first event identified and / or seen by each member for X. For example, the received timestamp of X may be based on the mean of the timestamps, the standard deviation of the timestamps, the modified mean (by removing the oldest and newest timestamps from the calculation, for example), and / or similar. In yet other cases, an extended median may be used.

[0081] In some cases, the total order and / or consensus order of events is calculated by sorting the events by their reception round, breaking the equilibrium by their reception timestamp, and breaking the equilibrium by their signature. In other cases, the total order of events can be calculated by sorting the events by their reception round, breaking the equilibrium by their reception generation, and breaking the equilibrium by their signature. The preceding paragraph specifies the functions used to calculate and / or define the reception round, reception timestamp, and / or reception generation of events.

[0082] In other cases, instead of using the signature of each event, the signature of that event can be used by XORing it with the signature of a well-known event or well-known witness that has the same receiving round and / or the same receiving generation in that round. In other cases, any other suitable combination of event signatures can be used to break the equilibrium and define the consensus order of events. The result of XORing the signatures of well-known witnesses in a given round represents pseudorandom numbers that are difficult for potential attackers and other entities to predict and / or manipulate. Thus, in some implementation forms, the XORed signatures can be used as a source of unpredictable random numbers (i.e., "random beacons"). Random numbers can be used in various hash graph processes.

[0083] In yet another case, instead of defining the "received generation" as the median of the list, we can define the "received generation" as the list itself. Then, when sorting by the received generation, two received generations can be compared by the middle element of their lists, breaking the balance with the element immediately preceding the middle, breaking their balance with the element immediately following the middle, and so on, alternating between the elements before and after the elements used until a balance is broken.

[0084] In some cases, the timestamp median can be replaced with an "extended median." In such cases, the list of timestamps may be defined for each event, rather than a single received timestamp. The list of timestamps for event X may include the first event by each member that identifies and / or sees X. For example, in Figure 8, the list of timestamps for event 1401 may include the timestamps for events 1402, 1403, 1403, and 1408. In some cases, the timestamp for event 1401 may also be included. When the balance with the list of timestamps is broken (i.e., two events have the same received round), the intermediate timestamps of each event's list (or, if the length is even, the first or second given timestamp of two intermediate timestamps) may be compared. If these timestamps are the same, the timestamp immediately following the intermediate timestamp can be compared. If these timestamps are the same, the timestamp immediately preceding the intermediate timestamp can be compared. If these timestamps are also the same, the timestamp after the three timestamps already compared is compared. This can continue alternately until the balance is broken. As in the above consideration, if the two lists are identical, the balance can be broken by the signatures of the two elements.

[0085] In other cases, the "shortened extended median" can be used instead of the "extended median." In such cases, the entire list of timestamps is not stored for each event. Instead, only a few values ​​near the middle of the list are stored and used for comparison.

[0086] The median received timestamp can potentially be used for purposes other than calculating the overall order of events. For example, Bob might sign a contract indicating that he agrees to be bound by it, but this only happens if there is an event X containing a transaction in which Alice signs this same contract, and the received timestamp of X is at or before a certain deadline. In that case, as indicated by the “median received timestamp” as described above, if Alice signs the contract after the deadline, Bob will not be bound by the contract.

[0087] In some implementations, Alice creates two events X and Y that are forks (having the same parent), and if Bob receives X, then subsequent events defined by Bob can see X. Later, if Bob receives Y, then Bob's future events can no longer see X or Y (because Bob has identified the fork). In some implementations, this can be changed so that Bob's future events continue to see X and not Y. Similarly, if a member can see an event, that see is "sticky," and the member's future events continue to see that event but do not see forks of that event. Using this, consensus schemes and / or algorithms no longer need to detect or react to forks. The definition changes from a predicate (can x see y?) to a function (which witness can x see?).

[0088] In some implementations, the defined see, stronglySee, and fork functions can be omitted, and the consensus scheme and / or algorithm can use the terms lastSee, firstSee, stronglySeeP, stronglySeeS1, seeThruP, firstSelfWitnessS, and firstWitnessS (see, for example, the functions shown in Figures 13A to 13E). Each of these functions is given an event x and a member m, and returns a unique event created by member m that is (in some way) seen by event x. Some of the names ending in S, S1, or P indicate that the returned event is (each) x's own round (the round in which x was created), its own round minus 1, or its parent round. For each function, if there is no such visible event, or

[0089]

number

[0090]

number

[0091] In the function builder notation used in Figures 13A to 13E, if multiple lines contain a satisfying "if" statement, the first (top) line is used. Also, since logical OR(V) is assumed to be short-circuited, pVq is defined as true when p is true and q is undefined (for example, when the definition of q can involve infinite recursion).

[0092] The exemplary definitions in Figures 13A to 13E can be directly implemented in an efficient form. Since the formulas in Figures 13A and 13B contain few existential or universal quantifiers, their calculation is straightforward. An efficient implementation involves memoizing the functions lastSee, stronglySeeP, round, firstSelfWitnessS, and firstWitnessS. Other functions in Figure 13B, parentRound, seeThru, stronglySeeS1, and firstSee, may not be memoized. Each is an event and a member function. Therefore, the functions can be memoized by memoizing an array for each event, each containing one element of an array of members. The exemplary definitions in Figures 13A to 13E are listed in an order such that they recursively depend on each other and, when any given function is called on a given event x, that function applies to x and does not depend on the functions listed below it, but only on the ancestors of x.

[0093] In some cases, the state of a distributed database can be defined after consensus has been achieved. For example, if S(R) is a set of events that can be seen by a well-known witness in round R, then eventually all events in S(R) will have a known receiving round and receiving timestamp. At that point, the consensus order of events in S(R) is known and does not change. Once this point is reached, members can compute and / or define representations of events and their order. For example, a member can compute the hash values ​​of events in S(R) in the consensus order of those events. The member can then digitally sign the hash values ​​(using their private key) and include the hash values ​​in the next event defined by that member. This can be used to inform other members that the member has decided that the events in S(R) have a given, unchanging order. After at least M members (or any other preferred number or proportion of members) have signed a hash value for S(R) (and thus agreed on the order represented by the hash value), the consensus list of events, together with the list of member signatures, can form a single file (or other data structure) which can be used to prove that the consensus order was as asserted for events in S(R). In some cases, if an event involves a transaction that updates the state of a distributed database system (as described herein), the hash value may be that of the state of the distributed database system after applying the transaction of the event in S(R) in the consensus order.

[0094] In some cases, M (as described above) can be based on a weight value assigned to each member, rather than simply a fraction, percentage, and / or value of the total number of members. In such cases, each member has a stake associated with its interest and / or influence in the distributed database system. Such a stake can be a weight value. It can be said that each event defined by that member has a weight value of that defining member. In this case, M can be a fraction of the total stake of all members. Events described above as dependent on M occur when a set of members having a stake total of at least M agree. Thus, based on those stakes, certain members can have a greater influence on how the system and consensus order are derived. In some cases, a transaction in an event can change the stake of one or more members, add new members, and / or remove members. If such a transaction has an incoming round of R, then after the incoming round is calculated, events after the witness of round R will recalculate those round numbers and other information using the modified stakes and modified list of members. Voting on whether an event in Round R is famous uses the old stake and member list, while voting on rounds after R uses the new stake and member list. Further details regarding the use of weight values ​​to determine consensus are described in U.S. Patent Application No. 15 / 387,048, filed on 21 December 2016, entitled “Methods And Apparatus For A Distributed Database Within A Network,” U.S. Patent No. 9,646,029, which is incorporated herein by reference in its entirety.

[0095] In some cases, certain members can be identified and / or designated as "lazy members." In such cases, lazy members can define and / or create events just like normal members or non-lazy members. In addition, events defined and / or created by lazy members can be included in the hash graph, and the consensus order of such events can be calculated and / or identified. However, the round increment for events defined by lazy members is 0. Therefore, the round number (or created round) of an event defined by a lazy member is equal to the maximum round number of the event's parent. Similarly, since the round increment for events defined by lazy members is 0, the round number (or created round) of an event defined by a lazy member cannot be greater than the maximum round number of the event's parent.

[0096] Furthermore, in some cases, events defined by lazy members are ineligible to vote in an election, ineligible to be the first event or witness of round R, and / or not considered an intermediate event between a regular member or an event defined by a lazy member in order to strongly favor another event. Thus, the restrictions imposed on lazy members result in a reduction of the computations performed by the hash graph while still maintaining security and the integrity of the consensus order. Members may be selected as lazy members based on any preferred criteria. For example, in some cases, members may be designated as lazy members based on a deterministic pseudo-random selection performed in each round, predefined at the start of a round, based on confidence level, based on stake amount, based on votes from other members, and / or randomly selected. In some cases, members designated as lazy members may differ from round to round, and in some other cases, members designated as lazy members remain the same across different rounds. In some other cases, events, rather than members, can be designated as "lazy" events. In such cases, a lazy event may be selected in each round instead of a member.

[0097] Therefore, in some cases, a processor of a first member can define a first group of members (e.g., computing devices) and a second group of members (e.g., computing devices) based on a deterministic pseudorandom function. The first group of members may be non-lazy members, and the second group of members may be lazy members. In some cases, the first group of members is the absolute complement of the second group of members with respect to the members of the distributed database (e.g., computing devices). The first member (or a processor of the first member) can receive events from the second member (e.g., computing devices) that are linked to a first set of events defined by a set of members (e.g., a set of computing devices). The set of members includes at least one member from the first group of members and at least one member from the second group of members. The processor can identify the order associated with a second set of events as a result of a consensus protocol (e.g., as described herein) that uses the values ​​of event parameters (e.g., round number, round increment, vote, witness indicator, famous witness indicator, etc.) from a first set of events defined by members from a first group of members, but does not use the values ​​of event parameters from a first set of events defined by members from a second group of members. Based at least partially on the order associated with the second set of events, the processor can identify the order associated with a set of transactions shown in an instance of the distributed database, and can store the order associated with a set of transactions in the instance of the distributed database.

[0098] The terms, definitions, and algorithms described above are used to illustrate the embodiments and concepts described in Figures 8 to 13E. Figures 10A and 10B illustrate a first exemplary application of the consensus scheme and / or process as shown in mathematical form. Figures 11A and 11B illustrate a second exemplary application of the consensus scheme and / or process as shown in mathematical form, Figures 12A and 12B illustrate a third exemplary application of the consensus scheme and / or process as shown in mathematical form, and Figures 13A to 13E illustrate a fourth exemplary application of the consensus scheme and / or process as shown in mathematical form.

[0099] In Figure 2, the database convergence module 211 and the communication module 212 are shown as being implemented within the processor 210. In some embodiments, the database convergence module 211 and / or the communication module 212 can be implemented within the memory 220. In some embodiments, the database convergence module 211 and / or the communication module 212 may be hardware-based (e.g., ASIC, FPGA, etc.).

[0100] Just as a transaction can change the data and / or state within a distributed database (for example, as described herein with respect to Figure 1), a transaction can also modify the membership of a distributed database (e.g., a set of computing devices that implement a distributed database) by adding, removing, and / or modifying members of the distributed database. In some implementations, the members of a distributed database can change over time by adding one or more computing devices to and / or removing one or more computing devices from the set of computing devices that implement the distributed database (e.g., computing devices 110, 120, 130, 140 in Figure 1). Similarly, the set of computing devices 110, 120, 130, 140 that implement a distributed database can change over time as computing devices are removed from and / or added to the set of computing devices 110, 120, 130, 140. In some cases, removed computing devices can be reconnected to the distributed database system later.

[0101] An address book can be used to track members of a distributed database (i.e., computing devices that implement the distributed database) at any given time. Figure 14 illustrates an address book 1400 associated with a distributed database system according to one embodiment. The address book 1400 contains entries for each of the computing devices 110, 120, 130, and 140 in the distributed database system 100 in Figure 1. Specifically, the address book 1400 is defined to contain a set of public keys (A, B, C, and D) for the set of computing devices that implement the distributed database (computing devices 110, 120, 130, and 140 illustrated and described with respect to Figure 1). In an implementation where stakes are used to determine consensus (e.g., a device's stake indicates the amount of influence a device has on the consensus process), the address book 1400 may also include the amount of stake associated with each computing device.

[0102] When a transaction adds, removes, and / or modifies compute devices from the set of compute devices that implement a distributed database, the transaction can modify and / or update the address book. For example, if a transaction to remove compute device 140 from the distributed database is entered into the distributed database and ordered (e.g., within the consensus order of the distributed database), the transaction can be executed and compute device 140 can be removed from the distributed database. In response to this transaction, a new address book can be defined that does not contain an entry for compute device 140. In another example, if a transaction to add a new compute device to the distributed database is entered into the distributed database and ordered (e.g., within the consensus order of the distributed database), a new address book with entries (e.g., including the public key and / or stake amount) can be defined for the new compute device. In yet another example, if a transaction to change the stake amount associated with one or more compute devices is entered into the distributed database and ordered, a new address book reflecting the stake change can be defined. For example, if the stake reflects the amount of cryptocurrency coins held by each computing device, a transaction could reflect computing device 140 sending 5 coins to computing device 130. After the transactions are ordered and executed, a new address book can be defined reflecting that computing device 140 now has 70 coins and computing device 130 has 35 coins.

[0103] In some implementations, each round of the consensus protocol may have a new address book (for example, each computing device implementing the distributed database may update its address book for each round of the consensus protocol). Specifically, if information in the address book changes (for example, through transactions that add, remove, and / or modify computing devices implementing the distributed database), each computing device may update its address book to reflect the transaction that made the change to the address book. Such changes may be reflected in the round's address book after the event containing such changes has been assigned to the receiving round via the consensus protocol. Specifically, address book A of round r r This can reflect transactions in events with fewer than r receiving rounds (i.e., transactions in events with r-1 or less receiving rounds). Similarly, once an event with r receiving rounds is identified, transactions with fewer than r+1 receiving rounds can be implemented to create a new address book A for round r+1. r+1 This can be defined. Therefore, in such an implementation, the address book can be updated round by round. This ensures that transactions have a rapid impact on the address book.

[0104] In some implementations, round r is the address book A r The address book is not updated every round, but instead is updated after a predetermined number of rounds p in which an event with round r is identified (for example, each computing device implementing a distributed database can update its address book accordingly). For example, in such an implementation, the address book A for round r r is, A r-p It is defined as a copy of and then modified by a valid transaction in an event that has an incoming round less than or equal to rp. Therefore, if p=2, then Address Book A of round r. rincludes updates from transactions that affect the address book within an event having a reception round of r - 2 or less (e.g., adding, deleting, and / or modifying a computing device implementing a distributed database). In some implementations, any other suitable value for p may be used (e.g., 3, 4, 5, etc.). This provides a duration of p - 1 rounds for a computing device to process consensus transactions (e.g., using a background thread) before the new address book is used within the consensus protocol. This additional time can help avoid pauses and / or delays in the consensus protocol.

[0105] In some implementations, the address book A for round r r is instead updated a predetermined number p of rounds after a previous update to the address book (e.g., each computing device implementing a distributed database can update its address book accordingly). For example, in such an implementation, the address book A for round r r can be defined as a copy of A for any round that is not a multiple of p r-1 Otherwise, the address book A r reflects the transactions in an event having a reception round of r - 1 or less. Similarly stated, the address book can be updated every p rounds. As an example, when p = 10, A r can be defined as an unmodified copy of A for any round r that is not a multiple of 10 r-1 Otherwise, when r is a multiple of 10, A r is modified by valid transactions within an event having a reception round from r - 10 to r - 1 of A r-10This is a copy of the original. In some implementations, the multiple p can be any suitable number (e.g., 2, 5, 10, 20, etc.). This allows for less recalculation of the event round number (or created round) when a new address book is defined (as will be described in more detail herein). Specifically, batching multiple rounds of changes to the address book before updating the address book ensures that the same address book is used to calculate and recalculate the round number for multiple rounds. Using the same address book for multiple rounds reduces the need to recalculate the event round number (or created round) after the address book has changed.

[0106] In some implementations, the consensus protocol can both wait for a predetermined number of rounds p after a previous update to the address book, and wait for a predetermined number of rounds k after consensus is achieved before updating the address book. For example, in such an implementation, address book A in round r r A is any round that is not a multiple of p. r-1 It can be defined as a copy of Address Book A. Otherwise, if the round is a multiple of p, then Address Book A r This can reflect transactions in events with receiving rounds less than or equal to rk. For example, if p=10 and k=2, A r This is the A for any r that is not a multiple of 10. r-1 It can be defined as an unmodified copy of . Otherwise, if r is a multiple of 10, A r A is corrected by a valid transaction in an event that has an incoming round from r-11 to r-2. r-11This is a copy of the previous version. This can offer the advantage of batching multiple rounds of changes before applying them to the address book, along with the advantage of providing each computing device with additional time (e.g., using background threads) to process the consensus transaction before the new address book is used within the consensus protocol.

[0107] After reaching a consensus on a well-known witness in round r, it is possible to identify events that have received round r, and a new address book A r+1 This can be calculated (as discussed above). In some implementations, each event is a new address book A r+1 It is possible to have a created round, which is recalculated using the method. This is done in round r+1 to identify a famous witness. Thus, for each address book and for the round associated with that address book, the event may have a different created round.

[0108] In some implementations, certain events can be identified as frozen to reduce the number of rounds recalculated and created for an event. Frozen events do not have a created round, which is recalculated when a new address book is defined. Specifically, if an event is an ancestor of any famous witness in round r or earlier, it can be considered frozen, and the created round of that event is not recalculated in subsequent rounds or is not recalculated using subsequent address books. On the other hand, if an event is not an ancestor of any famous witness in round r or earlier, the created round of that event is (if the address book in round r+1 has been modified from the address book in round r) the address book A of round r+1. r+1It is recalculated in round r+1 using the same method. Similarly, going forward, once a famous witness in round r+1 is identified and events with received round r+1 are identified, any additional events may be frozen if they are ancestors of famous witnesses in round r+1 or earlier. Such frozen events do not have their created round, which is recalculated in round r+2. This can be continued similarly for future rounds of the consensus protocol.

[0109] In some implementations, recalculation can be modified for two rounds: looking at (or identifying) the majority vote (rather than looking strongly) when the parent round is r+2, and looking at just one (rather than absolute majority) when the parent round is r+1. This allows for control over the trade-off between latency and computational complexity, increasing computational cost but reducing latency to reach consensus. In some implementations, latency can also be reduced by synchronizing each computing device implementing the distributed database with many other computing devices substantially simultaneously, allowing each event to have multiple other parent events.

[0110] Figure 15 is a flowchart illustrating a method 1500 for updating an address book according to one embodiment. Method 1500 can be executed by the processor of a computing device from a set of computing devices implementing a distributed database. Method 1500 includes defining an address book for the distributed database in 1502. In some implementations, the address book includes identifiers (e.g., public keys) and / or other information (e.g., stake values) for each computing device from a set of computing devices implementing a distributed database over a network.

[0111] At 1504, an event is received that includes a transaction to update the address book. For example, the event may include transactions to add a compute device to a set of compute devices implementing a distributed database, remove a compute device from a set of compute devices implementing a distributed database, update the stake value associated with a compute device from a set of compute devices implementing a distributed database, and / or similar actions.

[0112] In 1506, the reception round of an event is calculated based on the consensus protocol of a distributed database using an address book. For example, any suitable consensus protocol, such as those disclosed herein, can be used to calculate the reception round of an event (or attributes associated with the order).

[0113] In 1508, the address book is updated based on a transaction to define the updated address book after a predetermined number of rounds, which is either an event receiving round or a previous update to the address book. As considered above, in some implementations, the address book can be updated based on a transaction after a predetermined number of rounds of event receiving rounds. In some implementations, the address book can be updated only by a predetermined number of rounds of previous updates to the address book (for example, updates to the address book that occur when the round is a multiple of p).

[0114] In some implementations, the consensus protocol is configured to identify a set of events (e.g., famous witnesses) for each round of the consensus protocol. The set of events for each round may be used by the consensus protocol to determine the receiving round for each event from the group of events. Furthermore, an address book may be used to compute attributes (e.g., the round in which it was created) for each event from the group of events. The attributes may be recalculated using the updated address book if each event from the group of events is not an ancestor of at least one event from the set of events for the round in which the updated address book is defined. Similarly, the attributes are not recalculated for each event from the group of events using the updated address book if each event from the group of events is an ancestor of at least one event from the set of events for the round in which the updated address book is defined.

[0115] In some implementations, events are retained indefinitely within the distributed database and / or as part of the DAG. In some implementations, events can be discarded when they become old. For example, if an event is old enough, it can be classified as ancient. In some implementations, a compute device can optionally remove ancient events from its instance in the distributed database. If an event is even older, it can be classified as expired, and the compute device discards it from its instance in the distributed database. If the distributed database has not reached a consensus on an event by the time the event is ancient (for example, if the distributed database has not identified the receiving round for that event), it can be classified as stale. In such implementations, events classified as stale are not assigned a receiving round or consensus timestamp, are not part of the consensus order, and transactions within the event are not processed. Therefore, transactions within the event do not affect the shared state or address book. Furthermore, once an event expires, it is no longer sent during synchronization with other members (computational devices implementing the distributed database). However, in some implementations, members can continue to exchange ancient events during synchronization to ensure that potentially lagging members (for example, such lagging members might still not consider such events as ancient) still consider them.

[0116] In some cases, an event is added to a DAG or hash graph only if all of its parents already exist in the DAG or hash graph. In other implementations, an event can still be added to a DAG or hash graph if its parents do not exist in the DAG or hash graph, but those parents are either ancient or expired.

[0117] In some implementations, the threshold for expired and / or ancient events can be defined by the number of rounds from when the event was created until it became ancient or expired. For example, the threshold can be defined as expiredDuration > ancientDuration > 0. The values ​​of ancientDuration and expiredDuration can be any suitable values. For example, in some implementations, ancientDuration = 4 and expiredDuration = 8. In other implementations, any other values ​​may be used for ancientDuration and / or expiredDuration.

[0118] In some implementations, each event may include an index of the generation number (or generation) claimed for each of its parent events. In such implementations, the generation number of an event may be the maximum of the claimed generation numbers of its parents plus 1. An event with no parents may have a generation number of 1.

[0119] When a distributed database (or a computing device implementing a distributed database), a DAG, or a hash graph reaches consensus on an event having a particular receive round (e.g., a receive round r for which the distributed database did not previously have consensus for receive round r), the generation number of round r can be the minimum generation number of events that are witnesses famous in round r. In some implementations, an event x can be considered ancient if event x has a generation number less than the generation number of the round equal to the most recent round in order to achieve consensus less than ancientDuration. Similarly stated, event x can be considered ancient if gen(x) < gen(r - ancientDuration), where gen(x) is the generation number of event x and gen(r - ancientDuration) is the generation number of the round resulting from the most recent round r to achieve consensus - ancientDuration. Similarly, in some implementations, an event x can be considered expired if event x has a generation number less than the generation number of the round equal to the most recent round in order to achieve consensus (or gen(x) < gen(r - expiredDuration)) less than expiredDuration.

[0120] In some implementations, a core set S of events for round r r can be defined. The core set of events for round r can be defined as the frozen, non - ancient, non - expired events immediately after reaching consensus in round r. Similarly stated, the core set S of events for round r rThis may be a set of frozen witnesses in round r, which includes ancestors of those witnesses in round r and previous rounds, and whose generations are recent enough that the events are neither ancient nor expired. The core set of events may be useful in demonstrating that the distributed database system described herein continues to possess asynchronous byzantine fault tolerance (ABFT) properties. For example, consensus can be guaranteed for the base case of round 1, since the events have not yet been discarded and the address book has not yet been modified. Then, the core set S of events for round r+1 is determined to be true for round r, and all honest members have the same core set of events for round r+1. r And if they have the same address book, all reach the same consensus in round r+1, and the core set S of the same event in r+1 r+1 And the consensus event, as well as the address book of r+2, are agreed upon. Therefore, the consensus can be proven by induction.

[0121] In some implementations, when a new member (computing device) joins a distributed database, and / or when a member reconnects to the distributed database after being disconnected, that member can receive the latest information and events associated with the distributed database from other members (computing devices) at the time of the most recent round r in which consensus was achieved. In some implementations, the latest information may be the state of the distributed database, digitally signed by a predetermined number and / or percentage (e.g., 1 / 3 of the members in the distributed database and / or 1 / 3 of the total stake) of the current members and / or stake. In addition to the signed state at the time of round r, which reflects the results of consensus transactions up to round r, the new or reconnecting member can receive additional information about the hash graph, DAG, and / or the distributed database. For example, the new or reconnecting member can receive from another member the core set S of round r at the time r is the most recent round in which consensus was achieved. r Events within the round, core set S r It is possible to receive the hash values ​​of events within the system, and / or the minimum generation of unique, well-known witnesses in each non-ancient round. Given this information, new or reconnecting members can join or rejoin the hash graph, DAG, and / or distributed database.

[0122] In some implementations, if possible, a reconnecting member can write those events and / or the state of their hash graph, DAG, and / or distributed database instances to memory before rebooting or leaving the hash graph, DAG, and / or distributed database. The reconnecting member can then read the events and / or state after the reboot and / or when reconnecting to the hash graph, DAG, and / or distributed database. This can save bandwidth for synchronization after the reboot and / or when members reconnect to and / or rejoin the hash graph, DAG, and / or distributed database, although this is not mandatory.

[0123] As an example, member computing device Alice (using the processor in computing device Alice) can use the DAG and / or hash graph in the instance of Alice of the distributed database to determine and / or identify the well-known witnesses of the distributed database for rounds up to round r and rounds including round r. Next, Alice can calculate the consensus order of events that have received rounds up to r. Using the consensus order, Alice can process the transactions in the events in the consensus order to determine the state of the distributed database. Alice can calculate the hash value of the state of the distributed database and define and send a new event that has a transaction containing the hash value of the state. Alice can digitally sign this event and / or transaction using Alice's private key. Next, Alice can collect digital signatures from other members of the distributed database that match this state so that the state of the distributed database is digitally signed by a predetermined number and / or percentage (e.g., at least 1 / 3 of the members in the distributed database and / or 1 / 3 of the total stake) of the current members and / or stake of the distributed database.

[0124] In this example, when the compute device Bob joins (or reconnects) to the network (for example, by being added to the address book via a transaction in an event), Alice can send Bob the signed state of round r (for example, the state of round r digitally signed by a given number and / or percentage of current members and / or stakes of the distributed database). Bob can then begin synchronizing with other members of the distributed database. Specifically, he can receive events through synchronization with other members. Bob can first accept events that are not ancient but whose parent is ancient (by definition of ancient at the end of round r). Bob can then accept events whose parent is ancient or is among older events that Bob has received. Using these events, Bob can begin building and / or defining the DAG. This can continue until Bob has received events up to the present, at which point Bob can catch up and become a full participating member.

[0125] As a participating member, Bob can calculate the incoming round of events he will receive in the future. Since different address books are used for different rounds (as discussed herein), Bob can use address book A. r+1 It is not possible to simply calculate each receiving round of an event using this. Therefore, in some implementation forms, the signed state is S r S r Each event within can include Bob and / or be sent to Bob (from Alice). Then Bob will rWe know the consensus round created for each event within the round. Then, using this information, Bob can calculate the consensus round created for events in round r-1 and subsequent rounds. For events that have events created before r-1, Bob does not know the round in which they were created, but this is not a problem because these events are not used in calculating famous witnesses from round r+1 onwards.

[0126] S r As described above, each event within is sent to Bob, but in some implementations, only events within Sr that have a greater created round than the created rounds of both parent events are sent to the joining (or reconnecting) member (such as Bob), along with their signed state. This provides enough information for Bob to recalculate the created rounds of other events by copying the created rounds from the parent event with the highest created rounds.

[0127] In some implementations, S, as considered above, is sent along with the signed state. r The hash value of each event within is sent along with the signed state, not the event itself. Thus, in such an implementation, the state is a list of three hash values, namely the parent and S which was created in both rounds r, r-1, and r-2, and which has a created round greater than the created round. rThe hash value of the event within the state is included and / or transmitted together. In such an implementation, upon reconnection or new connection, Bob can synchronize with other members until Bob receives an event whose hash value is stored and / or transmitted together with the signed state. Specifically, Bob can identify such an event during synchronization by calculating a hash value for each event he receives and comparing that hash value to the hash value he received with the state. Bob can then assign a suitable created round to any event that is both an ancestor of one event with a hash value in and / or transmitted together with the state, and a descendant of another event with a hash value in and / or transmitted together with the state. Bob can also assign a predetermined value (e.g., -∞) of the created round to any other event for which Bob does not have a parent event. Based on this information, Bob can define a DAG, and Bob can define an Address Book A r+1 Using this, we can calculate the rounds created for other events Bob receives as described above. Bob can then continue from there as a regular participating member once further rounds reach consensus and Bob receives further events through synchronization with other members.

[0128] Figure 16 is a flowchart illustrating a method 1600 in which a computing device connects to and / or joins a distributed database. Method 1600 can be performed by the processor of the computing device. Method 1600 includes, in 1602, connecting over a network to a set of computing devices implementing a distributed database, and as a node implementing the distributed database. For example, a computing device can join a distributed database as a member and / or node by being added to the address book of the distributed database. This can be done using transactions in events ordered using the consensus protocol of the distributed database (as described herein).

[0129] In 1604, the state of the distributed database associated with a completed round of the consensus protocol is received from computing devices from a set of computing devices. In some implementations, the state may be digitally signed by a predetermined number and / or percentage (e.g., at least one-third of the members in the distributed database and / or one-third of the total stake) of the current members and / or stake of the distributed database. The state may be the state of the distributed database at a given round r (e.g., having transactions contained in events that have received rounds or previously executed and / or processed rounds). In some implementations, the state may include, or be transmitted with, an index of the core set of events associated with the completed round (e.g., the hash value of each event from the core set of events), along with the round identifier of each event from the core set of events. In some implementations, the core set of events may not include events that have a generation (e.g., expired and / or ancient) which is a predetermined number of previous rounds of the completed round.

[0130] In 1606, a set of events associated with a state is received from a set of computing devices. This set of events may be received based on synchronization with other computing devices from the set of computing devices.

[0131] In 1608, a set of attributes for each event from the set of events is calculated based on the core set of events and the round identifier for each event from the core set of events. For example, the attributes described herein with respect to the consensus protocol (e.g., the round created, the notable witnesses for each round, etc.) can be calculated for each event from the set of events.

[0132] In step 1610, a directed acyclic graph (DAG) is constructed based on a set of events and a set of attributes about the events, and in step 1612, the DAG is used to calculate the order of events associated with the next round of the consensus protocol. Computing devices connecting to and / or joining the distributed database can continue to function as fully functional, modern members.

[0133] In some cases, a distributed database (e.g., illustrated and described with respect to Figure 1) can be used to implement cryptocurrency. In such cases, each distributed database instance 114, 124, 134, 144 may define one or more wallet data structures (also referred to herein as wallets) to store cryptocurrency. In some cases, a user not associated with a distributed database (e.g., a computing device that is not a member of the distributed database) may also create and / or define such a wallet. A wallet data structure may include a key pair (public key and private key). In some cases, the key pair of a wallet may be generated by the computing device that produces that wallet. For example, if Alice defines a wallet (W, K) where W is the public key (which may behave like a wallet identifier) ​​and K is the private key, Alice may expose W to the remaining instances of the distributed database (e.g., in an event), but keep Alice's identity anonymous so that other instances of the distributed database (or their users) cannot identify that wallet W is associated with Alice.

[0134] Figure 7 illustrates a signal flow diagram of two computing devices synchronizing events according to one embodiment. Specifically, in some embodiments, distributed database instances 703 and 803 can exchange events to achieve convergence. Computing device 700 can randomly choose to synchronize with computing device 800 based on its relationship with computing device 800, based on its proximity to computing device 700, based on an ordered list associated with computing device 700, and / or similar. In some embodiments, computing device 800 can be selected by computing device 700 from a set of computing devices belonging to a distributed database system, so that computing device 700 can be selected multiple times in succession, or it may not be selected for a while. In other embodiments, the index of a previously selected computing device can be stored in computing device 700. In such embodiments, computing device 700 can wait for a predetermined number of selections before it can be selected again. As explained above, distributed database instances 703 and 803 can be implemented in the memory of computing device 700 and computing device 800, respectively.

[0135] In some implementations, the computing device 700 may have multiple threads running simultaneously, each thread synchronizing with another member. Thus, the computing device 700 can synchronize with other computing devices (not shown in Figure 7) in addition to the computing device 800. In some cases, the computing device 700 can maintain each connection alive or open by establishing a connection for each thread initially and then periodically sending heartbeat messages (e.g., sending two heartbeats per second). Thus, in some cases, the computing device 700 can prevent synchronization latency or delays that would otherwise be caused by the Transfer Layer Security (TLS) protocol (e.g., the recording protocol and the handshake protocol) each time the computing device establishes a connection with another member or computing device for synchronization. Further details regarding establishing and maintaining connections (including as a pool of connections) with other members or computing devices can be found in U.S. Patent Application No. 16 / 032,652 filed on 11 July 2018, entitled “Methods and Apparatus for Efficiently Implementing a Distributed Database within a Network,” which is incorporated herein by reference in its entirety.

[0136] Figures 3-6 illustrate an example of a hash graph according to one embodiment. There are five members, each represented by a thick vertical line. Each circle represents an event. Two lines extending downward from an event represent the hash of the two previous events. In this example, all events, except for the first event of each member, have two lines extending downward (one thick line to the same member and one thin line to another member). Time progresses upward. In Figures 3-6, the computing devices of the distributed database are shown as Alice, Bob, Carol, Dave, and Ed. It should be understood that such indicators refer to computing devices structurally and functionally similar to computing devices 110, 120, 130, and 140 illustrated and described with respect to Figure 1. The following paragraphs include exemplary systems for implementing a distributed database. It should be understood that any of the embodiments can be combined with other embodiments, devices, methods, and / or systems listed below or otherwise described herein.

[0137] In exemplary system 1, if computing device 700 is called Alice and computing device 800 is called Bob, the synchronization between them can be illustrated in Figure 7. The synchronization between Alice and Bob is, for example, as follows: -Alice sends events stored in the distributed database 703 to Bob. -Bob creates and / or defines a new event that includes the following: --The hash of the last event created and / or defined by Bob --The hash of the last event created and / or defined by Alice --The above digital signature by Bob -Bob sends events stored in the distributed database 803 to Alice. -Alice creates and / or defines a new event. -Alice sends that event to Bob. -Alice calculates the total order of events as a function of the hash graph. -Bob calculates the total order of events as a function of the hash graph.

[0138] At any given time, a member can store all events received so far, along with identifiers associated with the computing device and / or distributed database instance that created and / or defined each event. Each event contains hashes of the two preceding events, with the initial event (which has no parent hash) and the first event for each new member (which has a single parent event hash and represents the events of existing members that joined them). A diagram can be drawn representing this set of events. It can show vertical lines for each member and dots or circles on those lines for each event created and / or defined by that member. Whenever an event (higher dot) contains the hash of a preceding event (lower dot), a diagonal line is drawn between the two dots. An event can be said to be linked to another event if that event can reference other events through its hash (directly or through intermediate events).

[0139] For example, Figure 3 illustrates an example of a hash graph 600. Event 602 is created and / or defined by Bob as a result of synchronization with Carol. Event 602 includes the hash of Event 604 (a previous event created and / or defined by Bob) and the hash of Event 606 (a previous event created and / or defined by Carol). In some embodiments, for example, the hash of Event 604 contained within Event 602 includes pointers to its immediate ancestor events, Events 608 and 610. Thus, Bob can use Event 602 to refer to Events 608 and 610 and use the pointers to previous events to reconstruct the hash graph. In some cases, it can be said that Event 602 is linked to other events in the hash graph 600 because Event 602 can refer to each of the events in the hash graph 600 via its previous ancestor events. For example, Event 602 is linked to Event 608 via Event 604. In another example, event 602 is linked to event 616 via events 606 and 612.

[0140] Exemplary System 2: A system from Exemplary System 1 (or any other exemplary system disclosed herein) where an event also includes a “payload” of transactional or other information for recording. Using such a payload, the event can be updated with any transactional and / or defined transactional and / or information that has occurred since the immediately preceding event on the computing device. For example, event 602 may include any transactional and / or defined transactional and / or performed by Bob since event 604 was created and / or defined. Thus, when synchronizing event 602 with other computing devices, Bob can share this information. Transactional and / or defined transactional and

[0141] Exemplary System 3: A system from Exemplary System 1 (or any other exemplary system disclosed herein) wherein the event also includes the current time and / or date, which is useful for debugging, diagnostics, and / or other purposes. The time and / or date may be a local time and / or date at which a computing device (e.g., Bob) creates and / or defines the event. In such embodiments, such local time and / or date is not synchronized with the rest of the devices. In other embodiments, the time and / or date may be synchronized across devices (e.g., when exchanging events). In yet another embodiment, a global timer may be used to determine the time and / or date.

[0142] Exemplary System 4: A system from Exemplary System 1 (or any other exemplary system disclosed herein) in which Alice does not send to Bob any events created and / or defined by Bob, nor any ancestor events of such events. If y contains a hash of x, or if y contains a hash of an event that is a descendant of x, then event x is an ancestor of event y. Similarly, in such embodiments, Bob sends to Alice any events that have not yet been stored by Alice, and does not send any events that have already been stored by Alice.

[0143] For example, Figure 4 illustrates an exemplary hash graph 620 illustrating the ancestor events (dotted circles) and descendant events (striped circles) of event 622 (black circles). The lines establish a partial order of events, where ancestors come before black events and descendants come after black events. Since the partial order does not indicate whether white events come before or after black events, a total order or consensus order is used to determine their sequence. As another example, Figure 5 illustrates an exemplary hash graph illustrating one particular event (filled circle) and when each member first received an indicator of that event (striped circles). When Carol synchronizes with Dave to create and / or define event 624, Dave does not send Carol the ancestor events of event 622 because Carol already knows and has received such events. Instead, Dave sends Carol events that Carol has not yet received and / or that are not stored in Carol's distributed database instance. In some embodiments, Dave can identify events to send to Carol based on what Dave's hash graph reveals about events previously received by Carol. Event 622 is an ancestor of event 626. Therefore, at the time of event 626, Dave has already received event 622. Figure 4 shows that Dave has received event 622 from Bob, who received event 622 from Carol, and from Ed, who received event 622 from Carol. Furthermore, at the time of event 624, event 622 is the last event created and / or defined by Carol that Dave has received. Therefore, Dave can send Carol any events stored by Dave other than event 622 and its ancestors. Additionally, upon receiving event 626 from Dave, Carol can reconstruct its hash graph based on pointers in events stored in Carol's distributed database instance.In another embodiment, Dave can determine which events to send to Carol based on the fact that Carol sends event 622 to Dave (not shown in Figure 4), and Dave uses event 622 (and the references within it) to identify events that Carol has already received. By reconstructing the hash graph, Carol can determine how Dave will vote in the consensus protocol described above without actually receiving votes from Dave for each round of the consensus protocol. Similarly, based on Carol's hash graph, Carol can determine how each of the remaining members of the distributed database will vote without specifically receiving votes from them. This reduces network traffic because votes for each round of the consensus protocol are not exchanged among the members of the distributed database.

[0144] Exemplary System 5: A system from Exemplary System 1 (or any other exemplary system disclosed herein) in which both members transmit events to the other in an order such that an event is not transmitted until the receiver has received and / or remembers the ancestors of the event. Thus, the sender transmits events from oldest to newest, and as a result, the receiver can check two hashes on each event when an event is received by comparing the two hashes with two ancestor events that have already been received. The sender can identify which events to transmit to the receiver based on the current state of the sender's hash graph (e.g., a database state variable defined by the sender) and what the hash graph indicates that the receiver has already received. Referring to Figure 3, for example, when Bob is synchronizing with Carol to define event 602, Carol can identify that event 619 is the last event created and / or defined by Bob that Carol has received. Thus, Carol can determine that Bob knows that event and its ancestors. This allows Carol to first send events 618 and 616 (i.e., the oldest events Carol has received that Bob has not yet received) to Bob. Then Carol can send event 612 to Bob, followed by event 606. This allows Bob to easily link the events and reconstruct his hash graph. Since Bob does not request events from Carol, he can increase the efficiency of synchronization and reduce network traffic by using Carol's hash graph to identify events he has not yet received.

[0145] In other embodiments, the most recent event may be sent first. If the receiver determines that it has not yet received one of the two previous events (based on the hashes of two previous events in the most recent event and / or a pointer to the previous event in the most recent event), the receiver may request the sender to send such an event. This can continue until the receiver receives and / or remembers the ancestors of the most recent event. Referring to Figure 3, in such embodiments, for example, when Bob receives event 606 from Carol, Bob can identify the hashes of events 612 and 614 within event 606. When Bob creates and / or defines event 604, he can determine that event 614 has been previously received from Alice. Therefore, Bob does not need to request event 614 from Carol. Bob can also determine that event 612 has not yet been received. Bob can then request event 612 from Carol. Next, Bob can determine, based on the hash in event 612, that he has not received events 616 or 618, and therefore can request these events from Carol. Based on events 616 and 618, Bob can determine that he has received the ancestor of event 606.

[0146] Exemplary System 6: A system from Exemplary System 5 (or any other exemplary system disclosed herein) with the additional constraint that, when a member has a choice between several events to send next, the events are selected in such a way as to minimize the total number of bytes previously sent by that member that have been created and / or defined. For example, if Alice has only two events left to send to Bob, one of 100 bytes and created and / or defined by Carol, and the other of 10 bytes and created and / or defined by Dave, and in this synchronization Alice has already sent a 200-byte event by Carol and a 210-byte event by Dave, then Alice should send the Dave event first, followed by the Carol event, because 210 + 10 < 100 + 200. This can be used to address attacks in which a single member either sends one huge event or a large number of small events. (As considered with respect to exemplary system 7,) if traffic exceeds the byte limits of most members, the method of exemplary system 6 can ensure that attacker events are ignored rather than legitimate user events. Similarly, attacks can be mitigated by sending smaller events before larger ones (to defend against one massive event that binds the connection). Furthermore, if a member cannot send each of the events in a single synchronous (e.g., due to network limits, member byte limits, etc.), that member can send a small number of events from each member rather than simply sending events defined and / or created by the attacker and not sending any of the (small number) events created and / or defined by other members.

[0147] Exemplary System 7: A system from Exemplary System 1 (or any other exemplary system disclosed herein) comprising an additional first step in which Bob sends to Alice a number indicating the maximum number of bytes he is willing to receive during this synchronization, and Alice replies with Alice's limit. Alice then stops sending when the next event is about to exceed this limit. Bob does the same. In such embodiments, this limits the number of bytes transferred. This may increase the time to convergence but reduces the amount of network traffic per synchronization.

[0148] Alternatively or additionally, in some implementations, a limit on the number of bytes per synchronization process and / or a limit on the number of events allowed to be synchronized per synchronization process are implemented within the distributed database. For example, Alice can send an event to Bob that Bob does not yet know about, and then the database instance associated with Alice can stop and / or terminate the transmission of data packets and / or events when the next event exceeds and / or reaches a synchronization threshold based on either the acceptable number of bytes (i.e., the amount of synchronized data) or the acceptable number of events to be synchronized. In such cases, the transmission of events can be carried out by sending the parent of the event before sending the event, provided that both events are synchronized.

[0149] In some cases, where Alice is in sync with Bob and needs to send Bob two events, for example event X and event Y, and Bob already has all the parents of both those events, Alice can choose which one to send first. In some implementations, Alice can calculate a total byte count (Bx) for all the bytes in X by adding the bytes in all events by the creator of X that Alice has already sent during this sync. Similarly, a total byte count (By) for the bytes in Y and for events by the creator of Y that have been sent so far can be calculated. Next, Alice can choose to send X before Y if Bx < By, send Y before X if By < Bx, or choose to send in either order if Bx = By.

[0150] In some cases, the synchronization between two members can be limited to a maximum number of received events per synchronization (for example, to prevent a service disruption attack). If such a limit is reached before all events related to that synchronization are received, the synchronization ends early. In some other cases, each synchronization event can be limited to a maximum number of received bytes (instead of or in addition to being limited to the number of received events). Thus, limits such as the maximum number of received events and the maximum number of received bytes can be used to constrain or adjust the number of events and / or bytes received and / or accepted by a receiving member (e.g., Bob) from another member (e.g., Alice) during synchronization. The aforementioned limits can prevent an attack where a malicious member creates large events or floods the network with a huge number of small events. Also, these limits can guarantee graceful degradation when, for example, one member has a low bandwidth connection that handles an average amount of data traffic but not sudden spikes in data traffic.

[0151] In some implementations, if all known events for which consensus has not yet been identified are empty events that do not contain transactions, a member or computing device will not initiate synchronization with another member or computing device. This ensures that members do not waste bandwidth when there are no new transactions for a long period of time.

[0152] In some cases, a lack of consensus can cause a memory overflow in a member or computing device. For example, a set of events for which consensus has not yet been identified may grow or increase beyond a given threshold, for instance, if at least one-third of the population is offline. This is because consensus may not be derived when there are too few members online. Thus, the memory of a member or computing device may overflow due to the cumulative number of events for which consensus cannot be reached. To prevent memory overflow due to accumulated events for which consensus cannot be achieved, each member and / or computing device may be configured to refuse to define and / or create any new events until a consensus is reached on some of the events that the member or computing device is aware of, once a threshold for events for which consensus has not yet been reached is reached. In other words, in some cases, a lack of consensus can cause an overflow if consensus cannot be achieved (for example, if there are too few members online who can derive consensus). Therefore, to prevent an overflow of events that cannot be included in the consensus order (for example, because there are too few online members), members do not define additional events until they can receive events from some offline members and reach a consensus on some of the older events.

[0153] Exemplary System 8: A system from Exemplary System 1 (or any other exemplary system disclosed herein) that, at the start of the synchronization process, has the following additional steps: -Alice identifies S, which is a set of events that Alice has received and / or stored, skipping events created and / or defined by Bob, or events that are ancestors of events created and / or defined by Bob. -Alice identifies the member that created and / or defined each event in S and sends Bob a list of the member's ID numbers. Alice also sends the number of events created and / or defined by each member that Alice has already received and / or remembered. -Bob returns a list of the number of events that Bob has received, created and / or defined by other members. -Alice will only send Bob events that he has not yet received. For example, if Alice tells Bob that she has received 100 events created and / or defined by Carol, and Bob replies that he has received 95 events created and / or defined by Carol, Alice will only send the 5 most recent events created and / or defined by Carol.

[0154] Exemplary System 9: A system derived from Exemplary System 1 (or any other exemplary system disclosed herein) with additional mechanisms for identifying and / or dealing with a rogue. Each event includes two hashes, one from the last event created and / or defined by its member ("self-hash") and one from the last event created and / or defined by another member ("external-hash"). A member is a "rogue" if it creates and / or defines two different events that have the same self-hash. If Alice discovers that Dave is a rogue by receiving two different events created and / or defined by Dave using the same self-hash, Alice remembers an indicator that Dave is a rogue and refrains from synchronizing with her in the future. If Alice discovers that Dave is a rogue and still synchronizes with Dave again and creates and / or defines a new event to record that fact, Alice also becomes a rogue, and other members who learn that Alice is further synchronizing with Dave stop synchronizing with Alice. In some embodiments, this affects only one-way synchronization. For example, if Alice sends a list of identifiers and the number of events she received for each member, and does not send the ID or count of the culprits, Bob will not reply with any corresponding number. Alice then sends Bob culprit events that Alice has not received, indicating that Bob has received such events. After the synchronization is complete, Bob can also determine that Dave is the culprit (if Bob has not yet identified Dave as the culprit), and Bob can also refuse to synchronize with that culprit.

[0155] Exemplary System 10: A system in Exemplary System 9 (or any other exemplary system disclosed herein) in which Alice initiates a synchronization process by sending Bob a list of fraudsters identified by Alice and a list of events involving those fraudsters that Alice still remembers, with the addition that Bob replies with any fraudsters identified by Bob in addition to those identified by Alice. Alice and Bob then continue as usual, but without giving each other a count of fraudsters when synchronizing.

[0156] Exemplary System 11: A system in Exemplary System 1 (or any other exemplary system disclosed herein) with a process for iteratively updating the current state (such as captured by a database state variable defined by a member of the system) based on internal transactions of any new events received during synchronization. This may also include a second process, which iteratively reconstructs the state (e.g., the order of events) whenever the sequence of events changes, by returning to a copy of the previous state and recalculating the current state by processing the events in the new order. Thus, for example, each computing device may maintain two versions of the state (one updated when new events and transactions are received (based on partial order), and one updated only after consensus is achieved (based on total order or consensus order). At some point (e.g., after a certain period of time, after a given number of events have been defined and / or received), the version of the state that is updated when new events and transactions are received can be discarded, and a new copy of the state that is updated only after consensus is achieved can be made as the new version of the state that is updated when new events and transactions are received. This can guarantee synchronization of both states.

[0157] In some embodiments, the current state is a state, balance, condition, and / or similar associated with the outcome of a transaction. Similarly, the state may include data structures and / or variables modified by the transaction. For example, if the transaction is a transfer between bank accounts, the current state may be the current balance of the account. In another example, if the transaction is associated with a multiplayer game, the current state may be the position, the number of lives, the items acquired, the game state, and / or similar associated with the game.

[0158] Exemplary System 12: A system in Exemplary System 11 (or any other exemplary system disclosed herein) that is made faster by using a “fast clone” arrayList to maintain state (e.g., bank account balance, game state, etc.). A fast clone arrayList is a data structure that behaves like an array with one additional feature that supports “cloning” behavior, which appears to create and / or define a new object that is a copy of the original. Since changes to the clone do not affect the original, the clone behaves as if it were a true copy. However, since creating a clone does not actually involve copying and / or updating the entire contents of one arrayList to another, the cloning behavior is faster than creating a true copy. Instead of having two clones and / or copies of the original list, one can use two smaller objects, each having a hash table and a pointer to the original list. When a write is made to a clone, the hash table stores which elements were modified and their new values. When a read is made at a certain location, the hash table is checked first, and if that element has been modified, the new value from the hash table is returned. Otherwise, the elements from the original arrayList are returned. In this way, the two "clones" are initially just pointers to the original arrayList. However, as each is repeatedly modified, the arrayList grows to have a large hash table that stores the differences between itself and the original list. Clones can be cloned themselves, extending the data structure into a tree of objects, where each object has its own hash table and a pointer to its parent. Thus, reads cause a walk-up of the tree until a vertex with the requested data is found or the root is reached. If a vertex becomes too large or complex, it can be replaced with a true copy of its parent, changes in the hash table can be made to the copy, and the hash table can be discarded.Additionally, if a clone is no longer needed, it can be removed from the tree during garbage collection, allowing the tree to be collapsed.

[0159] Exemplary System 13: A system in Exemplary System 11 (or any other exemplary system disclosed herein) that is made faster by using a “fast clone” hash table to maintain state (e.g., bank account balance, game state, etc.). This is the same as System 12, except that the root of the tree is a hash table instead of an arrayList.

[0160] Exemplary System 14: A system in Exemplary System 11 (or any other exemplary system disclosed herein) that is made faster by the use of a “fast clone” relational database for maintaining state (e.g., bank account balance, game state, etc.). For example, the fast clone database can be used to maintain two copies of state, as considered with respect to Exemplary System 11. This is an object that acts as a wrapper around an existing relational database management system (RDBMS). Each apparent “clone” is actually an object having an ID number and a pointer to an object containing the database. When user code attempts to execute a Structure Query Language (SQL) query on the database, the query is first modified and then sent to the actual database. The actual database is identical to the database seen by the client code, except that each table has one additional field for the clone ID. For example, suppose there is an original database with clone ID 1, and then two clones of the database (e.g., used to maintain two copies of state) are created with IDs 2 and 3. Each row in each table has a clone ID field that is 1, 2, or 3. When a query is from user code to clone 2, the query is modified to read only from rows that have a field that is 2 or 1. Similarly, a read up to 3 will look for rows that have an ID of 3 or 1. If a Structured Query Language (SQL) command goes to clone 2 and tells it to delete a row that has 1, the command should only change 1 to 3, thereby marking the row as no longer shared by clones 2 and 3 and visible only to 3.If several clones are active, several copies of a row can be inserted, each with a different clone's ID, so that the new row is visible to all clones except the one that just "deleted" it. Similarly, if a row is added to clone 2, that row is added to the table with ID 2. Modifying a row is equivalent to deleting and then inserting it. As mentioned earlier, if some clones are garbage collected, the tree can be simplified. The structure of that tree is stored in an additional table that is not accessible to the clones but is used purely internally.

[0161] Exemplary System 15: A system in Exemplary System 11 (or any other exemplary system disclosed herein) that is made faster by the use of a “fast clone” file system for maintaining state. This is an object that behaves as a wrapper for a file system. The file system is built on top of an existing file system, using a fast clone relational database to manage different versions of the file system. The underlying file system stores a large number of files either in one directory or divided according to file names (to keep directories small). The directory tree can be stored in the database and is not provided to the host file system. When a file or directory is cloned, the “clone” is simply an object with an ID number, and the database is modified to reflect that this clone now exists. When a fast clone file system is cloned, it appears to the user as if an entire new hard drive has been created and / or defined and initialized with a copy of the existing hard drive. Changes to one copy may not affect other copies. In reality, there is only one copy of each file or directory, and a copy is made when a file is modified via one clone.

[0162] Exemplary System 16: A system in Exemplary System 15 (or any other exemplary system disclosed herein) in which, for each N-byte portion of a file in a fast clone file system, a separate file is created and / or defined on the host operating system. N can be any preferred size, such as 4096 or 1024. In this way, if one byte is changed in a large file, only one chunk of the large file is copied and modified. This also increases efficiency when storing many files that differ by only a few bytes on a drive.

[0163] Exemplary System 17: A system in Exemplary System 11 (or any other exemplary system disclosed herein) wherein each member includes in some or all of the events created and / or defined by each member a hash of the state at a previous time, along with the number of events that have occurred up to that point, indicating that the member recognizes and / or identifies that a consensus currently exists regarding the order of events. After a member has collected signed events containing such hashes from a majority of users for a given state, that member can then store them as proof of the consensus state at that point and remove any events and transactions prior to that point from memory.

[0164] Exemplary System 18: A system in Exemplary System 1 (or any other exemplary system disclosed herein) in which the operation for calculating the median or majority vote is replaced by a weighted median or weighted majority vote, and members are weighted by their “stakes.” Stake is a number that indicates how important a member’s vote is. Stake may be a holding in cryptocurrency, or it may simply be any number that a member is initially assigned when invited to join and that is subsequently divided among any new members that the member invites to join. Old events can be discarded when enough members agree to a consensus state, thereby their total stake becomes a majority vote of the existing stakes. If the total order is calculated using the median of ranks contributed by members, the result is a number in which half of the members have a higher rank and the other half have a lower rank. On the other hand, if the total order is calculated using a weighted median, the result is a number in which about half of the total stake is associated with a lower rank and the other half with a higher rank. Weighted voting and medians can be useful in preventing Sybil attacks, in which one member invites a large number of "sock puppet" users to join, each of which is merely a pseudonym controlled by the inviting member. If the inviting member is forced to split the stake with the invited members, sock puppets are not useful to an attacker attempting to control the consensus outcome. Therefore, proof of stake can be useful in some situations.

[0165] Exemplary System 19: A system in Exemplary System 1 (or any other exemplary system disclosed herein) in which, instead of a single distributed database, multiple databases exist in a hierarchy. For example, there may be a single database of which the user is a member, and then several smaller databases, or “chunks,” each having a subset of members. When events occur within a chunk, those events are synchronized among the members of that chunk, but not among members outside that chunk. Then, occasionally, after a consensus order has been determined within a chunk, the resulting state (or events with a consensus total order) can be shared with the entire membership of the larger database.

[0166] Exemplary System 20: A system in Exemplary System 11 (or any other exemplary system disclosed herein) having the ability to have events that update software for updating state (such as being captured by database state variables defined by members of the system). For example, events X and Y may include transactions that read the transactions within those events and then correct the state according to software code that appropriately updates the state. Then, event Z may include a notification that a new version of the software is now available. If the overall order indicates that the events occur in the order X, Z, Y, then the state can be updated by processing the transactions in X with the old software and then the transactions in Y with the new software. However, if the consensus order was X, Y, Z, then both X and Y can be updated with the old software, which may result in a different final state. Thus, in such embodiments, a notification to upgrade the code can be made within an event, and as a result, the community can reach a consensus on when to switch from the old version to the new version. In some embodiments, the code may switch from the old version to the new version in a round after the round in which event Z (including the notification to upgrade the code) is received. Therefore, if event Z is determined to have a receive round r, any events that have a receive round r or earlier will be ordered using the older version. Similarly, any events that do not yet have a receive round at the time of round r will be ordered using the newer version. This ensures that members maintain synchronization and that the system can remain running even during an upgrade without requiring a reboot or restart of the process.

[0167] Exemplary System 21: A system in Exemplary System 1 (or any other exemplary system disclosed herein) in which a member or compute device of a hash graph is configured to remove unwanted events from an instance of a distributed database by defining the signed state of the distributed database. In some implementations, the member or compute device may perform additional processes to prevent memory overflow and / or conserve memory resources. For example, the member or compute device may periodically discard old events based on a set of rules or criteria. The rules may state, for example, that a transaction in an event is ignored or discarded if the received round of the event minus the round number (or the round in which it was created) exceeds a given threshold, or if the generation of the event is less than a threshold (e.g., based on expiredDuration or ancientDuration). In some cases, an event includes the hashes of its parents and the rounds created for each parent. Thus, a given event can still be accepted during synchronization even if one or more parents are missing (e.g., ancient or expired, as described herein) because they were ignored or discarded because they were created too many rounds ago. Therefore, the signed state may include hashes of events defined and / or created in a round prior to the signed state, but not so early as to be ignored or discarded. Removing or discarding unnecessary events reduces the overhead caused by synchronizing redundant or irrelevant events across sets of computing devices implementing a distributed database (e.g., members of a hash graph), and reduces underuse of local memory on such sets of computing devices.Further details relating to the removal and / or destruction of events can be found in U.S. Patent Application No. 15 / 846,402, “Methods and Apparatus for a Distributed Database that Enables Deletion of Events,” filed on 19 December 2017, and published in its entirety herein by reference.

[0168] Furthermore, in some implementations, during synchronization with another member, a computing device may reject incoming events that are syntactically incorrect (e.g., not parsed) or have invalid digital signatures. Furthermore, in some implementations, expired incoming events may be rejected during synchronization. Furthermore, in some implementations, during synchronization, an incoming event with a non-ancient, non-expired parent event that is missing in the computing device (e.g., not in the memory or DAG of that computing device or instance of the distributed database) may be rejected until the non-ancient, non-expired parent event is received.

[0169] The system described above is expected to create and / or achieve an efficient convergence mechanism for distributed consensus, which has a final consensus. Several theorems can be proven about this, as shown below.

[0170] Exemplary Theorem 1: If event x partially precedes event y, then, in a given time, in the knowledge of the other members of a given group, each of the other members either receives the index of x before y, or has not yet received the index of y.

[0171] Proof: If event x precedes event y in partial order, then x is an ancestor of y. This occurs when a member first receives an index of y, either because that member has already received an index of x (in this case, x was heard before y), or because synchronization provides the member with both x and y (in this case, events received during a single synchronization are considered to have been received in an order consistent with the ancestor relations described for the exemplary system 5, so x was heard before y during that synchronization). End of proof.

[0172] Exemplary Theorem 2: For any given hash graph, if x precedes y in a partial order, then x precedes y in the total order that can be computed for that hash graph.

[0173] Proof: If x is partially ordered and precedes y, then by Theorem 1, For all i, rank(i,x) <rank(i,y)であり、 In the formula, rank(i,x) is the rank assigned to event x by member i, where it is 1 if x is the first event received by member i, 2 if it is the second event, and so on. Let med(x) be the median of rank(i,x) over all i, and similarly for med(y).

[0174] Given k, we select i1 and i2 such that rank(i1,x) is the k-th smallest x-rank and rank(i2,y) is the k-th smallest y-rank. Therefore, rank(i1,x) <rank(i2,y)である。

[0175] This is because rank(i2,y) is at least k of the y ranks, and each of the y ranks is strictly greater than its corresponding x rank. Therefore, rank(i2,y) is strictly greater than at least k of the x ranks, and thus strictly greater than the k-th smallest x rank. This argument holds for any k.

[0176] Let n be the number of members (the number of i values). Therefore, n must be either odd or even. If n is odd, let k = (n + 1) / 2, and the k-th smallest rank is the median. Therefore, med(x) < med(y). If n is even, when k = n / 2, the k-th smallest x rank is strictly smaller than the k-th smallest y rank, and the (k + 1)-th smallest x rank is also strictly smaller than the (k + 1)-th smallest y rank. Therefore, the average of the two x ranks is smaller than the average of the two y ranks. Therefore, med(x) < med(y). Therefore, in both cases, the median rank of the x ranks is strictly smaller than the median rank of the y ranks. Therefore, if a total order is defined by sorting the behavior according to the median rank, x precedes y in the total order. End of proof.

[0177] Exemplary Theorem 3: When the "gossip period" is the amount of time for existing events to propagate to all members through synchronization, After 1 gossip period: All members have received the event After 2 gossip periods: All members agree on the order of their events After 3 gossip periods: All members know that they have reached an agreement After 4 gossip periods: All members obtain digital signatures from all other members and endorse this consensus order.

[0178] Proof: Let S0 be the set of events created and / or defined up to a given time T0. If all members eventually synchronize with all other members infinitely frequently, there is a probability of 1 that there is a time T1 when all events in S0 have spread to all members, so that all members are aware of all events. This is the end of the first gossip period. Let S1 be the set of events that existed at time T1 but not yet existed at T0. Then, there is a probability of 1 that there is a time T2 when all members have received all events in set S1, which were present at time T1. This is the end of the second gossip period. Similarly, T3 is when all events in S2 that existed up to T2 but not before T1 have spread to all members. Note that each gossip period ends with a probability of 1. On average, if there are n members, each lasts as long as it takes to perform log2(n) synchronizations.

[0179] By time T1, all members will have received all events within S0.

[0180] By time T2, a given member Alice will have received records of each of the other members who have received all the events in S0. Therefore, Alice can calculate the rank of all behaviors for all members in S0 (the order in which each member received that behavior), and then sort the events by the median rank. The resulting overall order does not change for the events in S0. This is because the resulting order is a function of the order in which each member first received each metric of those events, and that order does not change. The order calculated by Alice may have some events from S1 scattered among the S0 events. Those S1 events can still change if they are within the sequence of S0 events. However, the relative order of the events in S0 does not change.

[0181] By time T3, Alice has learned the total order of the union of S0 and S1, and the relative order of events in that union remains unchanged. Furthermore, Alice can find the oldest event from S1 within this sequence and conclude that the sequence of events prior to S1 does not change, even with the insertion of new events other than S0. Therefore, by time T3, Alice can determine that a consensus has been reached regarding the order of events in the history prior to the first S1 event. Alice digitally signs the hash of the state resulting from these events occurring in this order (e.g., captured by a database state variable defined by Alice) and can send this signature as part of the next event that Alice generates and / or defines.

[0182] By time T4, Alice will have received similar signatures from the other members. At that point, Alice only needs to keep that list of signatures along with the state that the signatures prove, and she can discard the events she stored before the first S1 event. Proof complete.

[0183] The system described herein describes a distributed database that achieves consensus quickly and securely. This can be a useful building block for many applications. For example, if a transaction describes the transfer of cryptocurrency from one cryptocurrency wallet to another, and the state is simply a statement of the amount of currency in each wallet, this system constitutes a cryptocurrency system that avoids the costly proof-of-work in existing systems. Automated rule enforcement makes it possible to add features that are not common in current cryptocurrencies. For example, by enforcing a rule that if a wallet neither sends nor receives cryptocurrency for a certain period of time, that wallet is deleted and its value is distributed to other existing wallets in proportion to the amount they currently hold, lost coins can be recovered and deflation can be avoided. In this way, even if the private key for a wallet is lost, the money supply will not increase or decrease.

[0184] Another example is a distributed game that behaves like a massively multiplayer online (MMO) game played on a server, but achieves this without using a central server. Consensus can be achieved without any central server control.

[0185] Another example is a system for social media built on top of such a database. Since transactions are digitally signed and members receive information about other members, this offers superior security and convenience advantages compared to current systems. For example, email systems with strong anti-spam policies can be implemented, as reply addresses cannot be forged. Such systems could also combine the functions currently performed by email, tweets, text, forums, wikis, and / or other social media into a single distributed database to become an integrated social system.

[0186] Other applications may include more advanced cryptographic functions such as group digital signatures, where a group collaborates as a whole to sign a contract or document. This and other forms of multi-party computing can be usefully implemented using such distributed consensus systems.

[0187] Another example is a public ledger system. Anyone can pay a fee to store some information in the system, paying a small amount of cryptocurrency (or real-world currency) per byte per year for storing information in the system. These funds can then be automatically distributed to members who store the data and members who repeatedly synchronize and operate to achieve consensus. This allows a small amount of cryptocurrency to be automatically sent to members each time they synchronize.

[0188] These examples demonstrate that distributed consensus databases are useful as components for many applications. Because databases do not use costly proof-of-work and in some cases use the less expensive proof-of-stake instead, they can run as full nodes on smaller computers or even on mobile and embedded devices.

[0189] While described above as an event containing the hash of the two previous events (one self-hash and one external hash), in other embodiments, a member can synchronize with two other members to create and / or define an event containing the hash of the three previous events (one self-hash and two external hashes). In yet another embodiment, any number of event hashes of previous events from any number of members can be included within an event. In some embodiments, different events can contain a different number of hashes of previous events. For example, a first event may contain two event hashes, and a second event may contain three event hashes.

[0190] While events have been described above as including a hash (or cryptographic hash value) of a previous event, in other embodiments, events may be created and / or defined to include pointers, identifiers, and / or any other preferred reference to a previous event. For example, an event may include a serial number associated with and used to identify a previous event, and thus be created and / or defined to link events. In some embodiments, such a serial number may include, for example, an identifier associated with the member that created and / or defined the event (e.g., a media access control (MAC) address, an Internet Protocol (IP) address, an assigned address, and / or similar) and the order of events defined by that member. For example, a member having the identifier 10, where the event is the 15th event created and / or defined by that member, may assign the identifier 1015 to that event. In other embodiments, any other preferred format may be used to assign an identifier to an event.

[0191] In other embodiments, an event may contain a complete cryptographic hash, but only a portion of those hashes is transmitted during synchronization. For example, if Alice sends Bob an event containing hash H, and J is the first three bytes of H, and Alice determines that H is the only hash among the events and hashes she has stored that starts with J, then Alice can send J instead of H during synchronization. If Bob then determines that he has another hash that starts with J, he can reply to Alice requesting the complete H. In this way, hashes can be compressed during transmission.

[0192] The exemplary systems illustrated and described above are described with reference to other systems, but in other embodiments, any combination of exemplary systems and their associated functions can be implemented to create and / or define a distributed database. For example, exemplary system 1, exemplary system 2, and exemplary system 3 can be combined to create and / or define a distributed database. In another example, in some embodiments, exemplary system 10 can be implemented with exemplary system 1 but without exemplary system 9. In yet another example, exemplary system 7 can be implemented together with exemplary system 6 in combination with exemplary system 6. In yet another embodiment, any other suitable combination of exemplary systems can be implemented.

[0193] While various embodiments have been described above, it should be understood that these are presented only as examples and not as limitations. Where the methods described above indicate specific events occurring in a particular order, the order of those events may be modified. Additionally, specific events may be performed in parallel processes if possible, or sequentially as described above.

[0194] Some embodiments described herein relate to computer storage products that include a non-temporary computer-readable medium (which may also be referred to as a non-temporary processor-readable medium) having instructions or computer code for performing various computer implementation operations. The computer-readable medium (or processor-readable medium) is non-temporary in the sense that it does not itself contain a temporary propagating signal (e.g., a propagating electromagnetic wave that carries information on a transmission medium such as space or a cable). The medium and the computer code (which may also be referred to as code) may be designed and constructed for a particular purpose. Examples of non-temporary computer-readable media include, but are not limited to, magnetic storage media such as hard disks, floppy disks, and magnetic tapes; optical storage media such as Compact Disc / Digital Video Disc (CD / DVD), Compact Disc-Read Only Memory (CD-ROM), and holographic devices; magneto-optical storage media such as optical discs; carrier signal processing modules; and hardware devices specifically configured to store and execute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), read-only memory (ROM), and random access memory (RAM) devices. Other embodiments described herein relate, for example, to computer program products that may include the instructions and / or computer code considered herein.

[0195] Examples of computer code include, but are not limited to, microcode or microinstructions, machine instructions such as those generated by a compiler, code used to generate web services, and files containing high-level instructions executed by a computer using an interpreter. For example, embodiments may be implemented using imperative programming languages ​​(e.g., C, Fortran, etc.), functional programming languages ​​(e.g., Haskell, Erlang, etc.), logic programming languages ​​(e.g., Prolog), object-oriented programming languages ​​(e.g., Java, C++, etc.), or other suitable programming languages ​​and / or development tools. Further examples of computer code include, but are not limited to, control signals, encryption code, and compression code.

[0196] While various embodiments have been described above, it should be understood that they are presented only as examples and not limiting, and that various modifications in form and detail are possible. Any part of the apparatus and / or method described herein can be combined in any combination, except for mutually exclusive combinations. The embodiments described herein may include various combinations and / or partial combinations of the functions, components, and / or features of the different embodiments described.

Claims

1. It is a method, In a first computing device among a plurality of computing devices implementing a distributed database via a network, an address book for the distributed database is defined, wherein the address book includes identifiers for each computing device from the plurality of computing devices implementing the distributed database via the network. The first computing device receives a first event, including a first transaction for updating the address book, from a second computing device among the plurality of computing devices. The first computing device calculates the reception round of the first event based on the consensus protocol of the distributed database using the address book, wherein the reception round of the first event is not a predetermined reception round. The first computing device receives a second event from a third computing device among the plurality of computing devices, which includes a second transaction for updating the address book. Based on the consensus protocol, the first computing device calculates the reception round of the second event, wherein the reception round of the second event is greater than the reception round of the first event, and the reception round of the second event is a predetermined reception round. (1) Based on the first transaction, (2) the second transaction, and (3) the receiving round of the second event which is a predetermined receiving round, the first computing device updates the address book and defines the updated address book. Methods that include...

2. The method according to claim 1, wherein the first transaction for updating the address book includes at least one of adding a computing device to the plurality of computing devices implementing the distributed database, or removing a computing device from the plurality of computing devices implementing the distributed database.

3. The method according to claim 1, wherein the address book includes stake values ​​for each computing device from the plurality of computing devices that implement the distributed database, and the first transaction for updating the address book includes modifying the stake values ​​for at least one computing device from the plurality of computing devices.

4. The method according to claim 1, wherein the receiving round of each event from a plurality of events associated with the distributed database is based on a set of descendant events for that event, the set of descendant events is calculated using the address book before the update of the address book, and the set of descendant events is recalculated using the updated address book after the update of the address book.

5. The consensus protocol is configured to identify a set of events for each round of the consensus protocol, and the set of events for each round is used by the consensus protocol to determine the receiving round for each event from a plurality of events. Using the address book, attributes for each event from the multiple events are calculated. The method according to claim 1, wherein when each event from the plurality of events is not an ancestor of at least one event from the set of events in the round in which the updated address book is defined, the attributes for that event are recalculated using the updated address book.

6. The consensus protocol is configured to identify a set of events for each round of the consensus protocol, and the set of events for each round is used by the consensus protocol to determine the receiving round for each event from a plurality of events. Using the address book, attributes for each event from the multiple events are calculated. The method according to claim 1, wherein the updated address book is not used to recalculate the attributes for each event from the plurality of events when each event from the plurality of events is an ancestor of at least one event from the set of events in the round in which the updated address book is defined.

7. The method according to claim 1, wherein the updating includes defining the updated address book after a predetermined number of previous updates to the address book, and the updated address book includes updates to the address book in events having a number of received rounds between the round in which the previous updates to the address book occurred and the round in which the updated address book is defined.

8. The method according to claim 1, wherein the address book is updated after a predetermined number of rounds of the receiving round of the second event, and the predetermined number of rounds is greater than 1.

9. The method according to claim 1, wherein the identifier of each computing device from the plurality of computing devices is the public key to that computing device from the plurality of computing devices.

10. It is a device, The memory of the first computing device among multiple computing devices that implement a distributed database over a network, The system comprises a processor operably coupled to the memory, and the processor Defining an address book for the distributed database, wherein the address book includes identifiers for each computing device from the plurality of computing devices that implement the distributed database; Receiving an event from a second computing device among the aforementioned plurality of computing devices, which includes a transaction for updating the address book, Calculating attributes for each event from multiple events, wherein the event is included in the multiple events, and calculating the attributes of each event from multiple events. Calculating the reception round of the event based on the consensus protocol of the distributed database using the address book, wherein the reception round is calculated based on a threshold number of events from the set of events that are descendants of the event. (1) updating the address book based on the transaction that defines the updated address book and (2) a predetermined number of rounds after the round in which the event is received, A device configured to recalculate the attributes for an event using the updated address book when each event from the aforementioned group of events does not have descendant events from the set of events.

11. The apparatus according to claim 10, wherein the predetermined number of rounds is greater than 1.

12. The apparatus according to claim 10, wherein the updated address book includes updates to the address book in events having a number of received rounds between the round in which a previous update to the address book occurred and the round in which the updated address book is defined.

13. The apparatus according to claim 10, wherein the transaction for updating the address book includes at least one of adding a computing device to the plurality of computing devices implementing the distributed database, or removing a computing device from the plurality of computing devices implementing the distributed database.

14. The apparatus according to claim 10, wherein when each event from the plurality of events does not have descendant events from the set of events, the processor is configured not to recalculate the attributes for that event using the updated address book.

Images