Method and apparatus for distributed databases within 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 in a set of computing devices that implement the distributed database via a network. The method also includes receiving, from a computing device in the set of computing devices, an event that includes a transaction to update the address book, and computing a receiving round of the event based on a consensus protocol for the distributed database that uses the address book. The method also includes updating the address book based on the transaction to define an updated address book a predetermined number of rounds after at least one of the receiving round of the event or a previous update to the address book.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to U.S. Provisional Application No. 63 / 088,298, filed October 6, 2020, entitled “Methods and Apparatus for a Distributed Database within a Network,” which is incorporated herein by reference in its entirety. Technical Field

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

[0004] Some known distributed database systems attempt to reach consensus on values ​​within the system (e.g., the order in which transactions occur). For example, an online multiplayer game might have many computer servers that users can access to play the game. If two users attempt to pick up a specific item in the game simultaneously, it is important that the servers within the distributed database system eventually agree on which user should pick up the item first.

[0005] Such distributed consensus can be handled through methods and / or processes such as the Paxos algorithm or variations thereof. Under such methods and / or processes, one server in the database system is designated as the "leader," and the leader determines the order of events. Events (e.g., in a multiplayer game) are forwarded to the leader, the leader selects an order for the events, and the leader broadcasts this order to the other servers in the database system.

[0006] However, such known methods use servers operated by a party trusted by the users of the database system (e.g., game players) (e.g., a central management 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. Summary of the Invention

[0007] In some embodiments, a method includes defining an address book for a distributed database. The address book includes identifiers for each computing device in a set of computing devices that implement the distributed database via a network. The method also includes receiving events from the computing devices in the set of computing devices, the events including transactions updating the address book, and calculating a reception round for the events based on a consensus protocol of the distributed database using the address book. The method further includes updating the address book based on transactions to define the updated address book a predetermined number of rounds following at least one of the reception rounds of the events or a previous update to the address book. Attached Figure Description

[0008] Figure 1 This is a high-level block diagram illustrating a distributed database system according to an embodiment.

[0009] Figure 2 This is a block diagram illustrating a computing device for a distributed database system according to an embodiment.

[0010] Figure 3-6 The illustration shows an example of a hash diagram according to an embodiment.

[0011] Figure 7 This is a flowchart illustrating the communication process between a first computing device and a second computing device according to an embodiment.

[0012] Figure 8 This is an example of a hash diagram according to an embodiment.

[0013] Figure 9 This is an example of a hash diagram according to an embodiment.

[0014] Figures 10A-10B The illustration shows a method for hashing according to an embodiment. Figure 1 The example consensus method used.

[0015] Figure 11A-11B The illustration depicts a method for hashing according to another embodiment. Figure 1 The example consensus method used.

[0016] Figure 12A-12B The illustration depicts a method for hashing according to another embodiment. Figure 1 The example consensus method used.

[0017] Figures 13A-13E The illustration depicts a method for hashing according to another embodiment. Figure 1 The example consensus method used.

[0018] Figure 14 The illustration shows an address book associated with a distributed database system according to an embodiment.

[0019] Figure 15 This is a flowchart illustrating a method for updating an address book according to an embodiment.

[0020] Figure 16 This is a flowchart illustrating a method for connecting and / or joining a distributed database according to an embodiment. Detailed Implementation

[0021] In some embodiments, a method includes defining an address book for a distributed database. The address book includes identifiers for each computing device in a set of computing devices that implement the distributed database via a network. The method also includes receiving events from the computing devices in the set of computing devices, the events including transactions updating the address book, and calculating a reception round for the events based on a consensus protocol of the distributed database using the address book. The method further includes updating the address book based on transactions to define the updated address book a predetermined number of rounds following at least one of the reception rounds of the events or a previous update to the address book.

[0022] In some embodiments, an apparatus includes a memory of computing devices associated with a distributed database implemented by a set of computing devices via a network operatively coupled to the set of computing devices, and a processor operatively 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 in the set of computing devices that implement the distributed database. The processor is configured to receive events from the computing devices in the set of computing devices, the events including transactions updating the address book, and calculating attributes (e.g., round number or creation round) for each event in an event group. Events are included in the event group. The processor is configured to compute a reception round for an event based on a consensus protocol of the distributed database using the address book. The reception round may be based on a threshold number of events in the event set that are descendants of the event. The processor is also configured to update the address book based on transactions to define an updated address book a predetermined number of rounds following at least one of the reception round of an event or a previous update to the address book. The processor is configured to recalculate the attributes of each event in the event group using the updated address book when each event in the event group does not have descendant events from the event set.

[0023] In some embodiments, a non-transitory processor-readable medium stores code representing instructions to be executed by a processor. The code includes code that enables the processor to connect via a network to a set of computing devices implementing the distributed database and acting as nodes in the distributed database implementation. The code also includes code that enables the processor to receive from the computing devices in the set of computing devices a state of the distributed database associated with a completion round of a consensus protocol. This state includes an indication of a core set of events associated with the completion round and a round identifier for each event in the core set of events. The code further includes code that enables the processor to receive a set of events associated with the state from the set of computing devices and to compute a set of attributes for each event in the set of events based on the core set of events and the round identifier for each event in the core set of events. Finally, the code includes code that enables the processor to construct a directed acyclic graph (DAG) based on the event set and the attribute set of events, and to use the DAG to compute the order of events associated with the next round of the consensus protocol.

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

[0025] In some cases, each event in the third event set is associated with a set of attributes (e.g., sequence number, generation number, round number, receiving round number, and / or timestamp, etc.). The result of the protocol may include the value of each attribute in the attribute set for each event in the third event set. The value of the first attribute in the attribute set may include a first numerical value, and the value of the second attribute in the attribute set may include a binary value associated with the first numerical value. The binary value of the second attribute of an event in the third event set (e.g., round increment value) may be based on whether the relationship between the event and the fourth event set linked to the event meets a criterion (e.g., the number of events strongly identified by the event). Each event in the fourth event set is (1) an ancestor of the events in the third event set, and (2) as the remaining events in the fourth event set are associated with a first common attribute (e.g., common round number, indication as the first event of round R, etc.). The first common attribute may indicate the first / initial instance of an event defined by each computing device in the computing device set and associated with a first specific value (e.g., indication as the first event of round R, etc.).

[0026] The value of a third attribute (e.g., receiving round number) in the attribute set may include a second numerical value based on the relationship between the event and a fifth set of events linked to that event. Each event in the fifth set of events is a descendant of that event and is associated with a second common attribute (e.g., is known) as the remaining events in the fifth set of events. The second common attribute may be associated (1) with a third common attribute (e.g., is round R, first event, or witness) indicating that a second event defined by each computing device in the computing device set is associated with a first instance of a second specific value different from a first specific value, and (2) with a result based on the instruction set. Each instruction in the instruction set may be associated with an event in a sixth set of events. Each event in the sixth set of events may be associated with a fourth common attribute indicating that a third event defined by each computing device in the computing device set is associated with a first / initial instance of a third specific value different from a first specific value and a second specific value. 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).

[0027] As used herein, a module can be, for example, any collection of components and / or operatively coupled electrical parts associated with performing a particular function, and may include, for example, memory, processor, electrical traces, optical connectors, and / or software (executed in hardware), etc.

[0028] As used herein, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” include plural indicators. Thus, for example, the term “module” is intended to mean a single module or a combination of modules. For example, “network” is intended to mean a single network or a combination of networks.

[0029] Figure 1 This is a high-level block diagram illustrating a distributed database system 100 according to an embodiment. Figure 1 The illustration shows a distributed database 100 implemented across four computing devices (computing device 110, computing device 120, computing device 130, and computing device 140). However, it should be understood that the distributed database 100 can use any number of sets of computing devices, including... Figure 1 The computing devices are not shown in the diagram. 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 network and / or wireless network and used for operatively coupling computing devices 110, 120, 130, 140. As described further in detail herein, in some embodiments, for example, the computing devices are personal computers interconnected via an Internet Service Provider (ISP) and the Internet (e.g., network 105). In some embodiments, a connection can be defined between any two computing devices 110, 120, 130, 140 via network 105. For example, as... Figure 1 As shown, a connection can be defined between computing device 110 and any one of computing device 120, computing device 130 or computing device 140.

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

[0031] Each computing device 110, 120, 130, 140 can be any type of device configured to send data via network 105 and / or receive data from one or more other computing devices. Examples of computing devices are provided in... Figure 1As shown in the figure. Computing device 110 includes memory 112, processor 111, and output device 113. Memory 112 may be, for example, random access memory (RAM), memory buffer, hard disk drive, database, erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), and / or read-only memory (ROM), etc. In some embodiments, memory 112 of computing device 110 includes data associated with an instance of a distributed database (e.g., distributed database instance 114). In some embodiments, memory 112 stores instructions that cause a processor to execute modules, processes, and / or functions associated with sending and / or receiving records of synchronization events to and / or from another instance of the distributed database (e.g., distributed database instance 124 at computing device 120), and / or records of previous synchronization events with other computing devices, and / or the order of synchronization events, and / or the order of transactions within events, parameters associated with identifying the order of synchronization events and / or transactions, and / or the values ​​of parameters (e.g., database fields quantifying transactions, database fields quantifying the order in which events occur, and / or any other suitable fields in the database where values ​​can be stored).

[0032] Distributed database instance 114 can be configured, for example, to manipulate data, including storing, modifying, and / or deleting data. In some embodiments, distributed database instance 114 can be a collection of arrays, a collection of data structures, a relational database, an object database, a post-relational database, and / or any other suitable type of database or storage device. For example, distributed database instance 114 can store data related to any particular function and / or industry. For example, distributed database instance 114 can store (e.g., financial transactions of users of computing device 110), including values ​​and / or vectors of values ​​related to the ownership history of a particular financial instrument. Typically, a vector can be any set of parameter values, and a parameter can be any data object and / or database field capable of taking different values. Thus, distributed database instance 114 can have multiple parameters and / or fields, each parameter and / or field associated with a vector of values. The vector of values ​​is used to determine the actual value of the parameter and / or field within the database instance 114. In some cases, 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., for calculating the order using the consensus method described herein), and values ​​of parameters (e.g., database fields that quantify transactions, database fields that quantify the order in which events occur, and / or any other suitable fields in the database where values ​​can be stored).

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

[0034] In some cases, distributed database instance 114 can also be used to implement other data structures, such as collections of (key, value) pairs. Transactions recorded by distributed database instance 114 can, for example, add, delete, or modify (key, value) pairs in the collection of (key, value) pairs.

[0035] In some cases, it is possible to query distributed database system 100 or any distributed database instances 114, 124, 134, and 144. For example, the query may include a key, and the returned result from distributed database system 100 or distributed database instances 114, 124, 134, and 144 may be the value associated with that key. In some cases, distributed database system 100 or any distributed database instances 114, 124, 134, and 144 may also be modified through transactions. For example, a transaction that modifies the database may contain the digital signature of the party authorizing the modification transaction.

[0036] Distributed database system 100 can be used for a variety of purposes, such as storing attributes associated with various users in a distributed identity system. For example, such a system could use a user's identity and / or identifier as the "key" and a list of attributes associated with the user as the "value". In some cases, the identity and / or identifier can be a cryptographic public key with a corresponding private key known to the user. For example, each attribute can be digitally signed by an authorized authority authorized to claim the attribute. For example, each attribute can also be encrypted with a public key associated with an individual or group of individuals authorized to read the attribute. Some keys or values ​​may also have a list of public keys appended to them by parties authorized to modify and / or delete the keys or values.

[0037] In another example, distributed database instance 114 can store data related to large-scale multiplayer games (MMGs), such as the current state and ownership of gameplay items. In some cases, distributed database instance 114 can be implemented within computing device 110, such as... Figure 1 As shown. In other cases, instances of a distributed database may be accessed by a computing device (e.g., via a network), but are not implemented within the computing device. Figure 1 (Not shown in the image).

[0038] The processor 111 of computing device 110 can be any suitable processing device configured to run and / or execute distributed database instance 114. For example, processor 111 can be configured to update distributed database instance 114 in response to receiving a signal from computing device 120, and / or to send a signal to computing device 120, as further described herein. More specifically, as further described herein, processor 111 can be configured to execute modules, functions, and / or procedures to update distributed database instance 114 in response to receiving a synchronization event associated with a transaction from another computing device, and / or records associated with the order of the synchronization events. In some embodiments, processor 111 can be configured to execute modules, functions, and / or procedures to update distributed database instance 114 in response to receiving a value of a parameter stored in another instance of the distributed database (e.g., distributed database instance 124 at computing device 120), and / or to send the value of a parameter stored in distributed database instance 114 at computing device 110 to computing device 120. In some embodiments, processor 111 may be a general-purpose processor, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or a digital signal processor (DSP), etc.

[0039] Display 113 can be any suitable display, such as, for example, a liquid crystal display (LCD), a cathode ray tube display (CRT), etc. In other embodiments, instead of or as an addition to displays 113, 123, 133, 143, any of computing devices 110, 120, 130, 140 includes another output device. For example, any of computing devices 110, 120, 130, 140 may include an audio output device (e.g., a speaker), and / or a haptic output device, etc. In still other embodiments, instead of or as an addition to displays 113, 123, 133, 143, any of computing devices 110, 120, 130, 140 includes an input device. For example, any of computing devices 110, 120, 130, 140 may include a keyboard, and / or a mouse, etc.

[0040] Although Figure 1While the system is shown as residing within a single computing device, in some cases, a processor configured to execute modules, functions, and / or processes to update a distributed database may reside in a computing device separate from its associated distributed database. In this case, for example, the processor may be operatively coupled to the distributed database instance via a network. For instance, the processor may execute consensus methods to identify the order of events and / or transactions (e.g., as a result of synchronization with other distributed database instances) and may send signals including the order of events and / or transactions to the associated distributed database instance via the network. The associated distributed database instance may then store the order of events, the order of transactions, and / or state variables based on the order of transactions within the associated distributed database instance. Thus, functions and storage associated with the distributed database can be distributed. Furthermore, the processor can query its associated distributed database instance, store database state variables and / or the current state, and perform other suitable operations described herein, even when the database is implemented in a computing device separate from the computing device having a processor implementing modules, functions, and / or processes (e.g., consensus methods) associated with the distributed database system. In other cases, the functions and / or methods described herein can be executed across any number of computing devices (e.g., in a distributed computing environment and / or cluster), and the results and / or values ​​of these functions and / or methods can be stored in memory and / or storage devices at any suitable computing device.

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

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

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

[0044] Although computing devices 110, 120, 130, and 140 are shown to be similar to each other, each computing device in the distributed database system 100 can be different from the others. Each computing device 110, 120, 130, and 140 of the distributed database system 100 can be any of, for example, a computing entity (e.g., a personal computing device, such as a desktop computer, laptop computer, etc.), a mobile phone, a personal digital assistant (PDA), etc. For example, computing device 110 can be a desktop computer, computing device 120 can be a smartphone, and computing device 130 can be a server.

[0045] In some embodiments, one or more portions of computing devices 110, 120, 130, 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 at a processor). In some embodiments, one or more functions associated with computing devices 110, 120, 130, 140 (e.g., functions associated with processors 111, 121, 131, 141) may be included in one or more modules (see, for example...). Figure 2 ).

[0046] The attributes of the distributed database system 100 (including the attributes 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 attributes of the distributed database system 100 can be selected by the administrator of the distributed database system 100. In other cases, the attributes of the distributed database system 100 can be selected jointly by the users of the distributed database system 100.

[0047] Because a distributed database system 100 is used, no leader is designated among computing devices 110, 120, 130, and 140. Specifically, no leader is identified and / or selected for computing devices 110, 120, 130, or 140 as a leader to resolve disputes between values ​​stored in distributed database instances 114, 124, 134, and 144 of computing devices 110, 120, 130, and 140. Instead, computing devices 110, 120, 130, and 140 may collectively aggregate the value of the parameter using the event synchronization process, voting process, consensus method, and / or protocol and / or other methods described herein.

[0048] The absence of a leader in a distributed database system increases its security. Specifically, in a leader-based system, there is a single point of attack and / or point of failure. If malware infects the leader and / or the value of a parameter at the leader's distributed database instance is maliciously altered, the faulty and / or incorrect value propagates throughout other distributed database instances. However, in a leaderless system, there is no single point of attack and / or point of failure. Specifically, if a parameter in a distributed database instance in a leaderless system contains a value, that value will change after the distributed database instance exchanges values ​​with other distributed database instances in the system, as described further in this document. Furthermore, the leaderless distributed database system described herein increases the speed of aggregation while reducing the amount of data sent between devices, as described further in this document.

[0049] Figure 2 The illustration shows a computing device 200 of a distributed database system (e.g., distributed database system 100) according to an embodiment. In some embodiments, the computing device 200 may be similar to that described above. Figure 1 Computing devices 110, 120, 130, and 140 are shown and described. Computing device 200 includes a processor 210 and a memory 220. The processor 210 and the memory 220 are operatively coupled to each other. In some embodiments, the processor 210 and the memory 220 may be respectively analogous to those described above. Figure 1 The processor 111 and memory 112 are described in detail. For example... Figure 2 As shown, processor 210 includes a database aggregation module 211 and a communication module 212, and memory 220 includes a distributed database instance 221. Communication module 212 enables computing device 200 to communicate with other computing devices (e.g., send data to them and / or receive data from them). In some embodiments, communication module 212 ( Figure 1 (Not shown in the image) enables computing device 110 to communicate with computing devices 120, 130, and 140. Communication module 210 may include and / or enable features such as a network interface controller (NIC), wireless connectivity, and / or a wired port. Thus, communication module 210 can establish and / or maintain communication between computing device 200 and another device (e.g., via a device such as...). Figure 1 The communication module 210 enables the computing device 200 to send data to and / or receive data from another device.

[0050] In some cases, the database aggregation module 211 can exchange events and / or transactions with other computing devices, store events and / or transactions received by the database aggregation module 211, and calculate the order of events and / or transactions based on a partial order defined by a referencing pattern between events (e.g., consensus or overall order). Each event can be a record containing: identifiers of two earlier events (e.g., a cryptographic hash) (linking the event to two earlier events and their ancestor events, and vice versa), payload data (such as the transaction to be recorded), other information such as the current time, and / or a timestamp (e.g., date and UTC time) declared by its creator as the time when the event was first defined. Each of the communicating computing devices is referred to as 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 this case, the member does not yet have any previous self-hashes (e.g., hashes of events previously defined by that member). In some cases, the first event in the distributed database does not contain the hashes of any previous events (because there are no previous events for that distributed database).

[0051] In some embodiments, such a cryptographic hash of two earlier events can be a hash value defined based on a cryptographic hash function that uses the events as input. Specifically, in such embodiments, an event comprises a specific sequence or string of bytes (which represents information about the event). The hash of the event can be the value returned from a hash function that uses the sequence of bytes of the event as input. In other embodiments, any other suitable data associated with the event (e.g., an identifier, a sequence number, bytes representing a specific part of the event, etc.) can be used as input to a hash function to compute the hash of the event. Any suitable hash function can be used to define the hash. In some embodiments, each member uses the same hash function, such that the same hash is generated at each member for a given event. The event can then be digitally signed by the member who defines and / or creates the event. In some embodiments, any other suitable event identifier can be used instead of the hash value.

[0052] In some cases, the 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) earlier events (linking that event to the earlier event and its ancestor events, and vice versa), and each reference is strictly limited to the earlier event, such that no cycles 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 “hashDAG”). In other embodiments, the DAG can be based on any other suitable identifier for the events. A hash graph or DAG directly encodes partial ordering, meaning that if Y contains a hash of X, or if Y contains a hash of an event that includes the hash of X, or for any length of these paths, event X is known to have arrived before event Y. However, if there is no path from X to Y or from Y to X, partial ordering does not define which event arrived first. Therefore, a database aggregation module can compute a total order or consensus order from partial ordering. This can be done by any suitable deterministic function used by the computing device, such that the computing device computes the same order. In some embodiments, each member can recalculate the order after each synchronization, and eventually these orders can be aggregated to achieve consensus.

[0053] Consensus algorithms and / or methods can be used to determine the overall order or consensus order of events in a hash graph, a DAG, and / or the order of transactions stored in the events. As a result of executing those transactions in order, the order of transactions can further define the state of the database. The defined state of the database can be stored as database state variables. In some embodiments, an instance of the distributed database (e.g., distributed database instance 114) stores hash graphs, and / or transactions, and / or the order of transactions, and / or events, and / or the order of events, and / or the state resulting from executing transactions.

[0054] In some cases, the database aggregation module can use the following functions to compute the overall order (also known as the consensus order) from the partial order in a hash graph. For each of the other computing devices (called "members"), the database aggregation module can examine the hash graph to discover the order in which events (and / or indications of those events) were received by that member. The database aggregation module can then perform a computation as if that member had assigned a numerical "rank" to each event, where the first event received by the member is ranked 1, the second event received by the member is ranked 2, and so on. The database aggregation module can do this for each member in the hash graph. Then, for each event, the database aggregation module can compute the median of the assigned ranks and sort the events by their median. This sorting can break ties in a deterministic way, such as by the numerical order of their hashes or by sorting two tied events using some other method, where the database aggregation module for each member uses the same method. The result of this sorting is the overall order.

[0055] Figure 6 Hash graph 640 illustrates an example of using partial order to determine overall order (or consensus order). Hash graph 640 illustrates two events (the lowest striped circle and the lowest dashed circle), and the first time each member receives an indication of these events (the other striped and dashed circles). The name of each member at the top is colored according to which event was first in their partial or slow order. The initial votes for the striped events are greater than those for the dashed events, so each member's consensus vote is striped. In other words, the members eventually agree that the striped events occurred before the dashed events.

[0056] In this example, the members (the computing devices labeled Alice, Bob, Carol, Dave, and Ed) will work to define a consensus on whether event 642 or event 644 occurred first. Each striped circle indicates the event on which a member first received event 644 (and / or an indication of event 644). Similarly, each dashed circle indicates the event on which a member first received event 642 (and / or an indication of event 642). As shown in hash graph 640, Alice, Bob, and Carol each received event 644 (and / or an indication of event 644) before event 642. Dave and Ed both received event 642 (and / or an indication of event 642) before event 644 (and / or an indication of event 644). Therefore, since a larger number of members received event 644 before event 642, the overall order can be determined by each member to indicate that event 644 occurred before event 642.

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

[0058] creator(x) = Creates the member of event x

[0059] anc(x) = the set of events that are ancestors of x, including x itself.

[0060] other(x) = The event created by the member that was synchronized just before x was created.

[0061] The last event with the same creator before self(x) = x.

[0062] self(x, 0) = self(x)

[0063] self(x,n)=self(self(x),n-1)

[0064] order(x, y) = k, where y is the k-th event that creator(x) learns from the following:

[0065]

[0066]

[0067] fast(x, y) = the position of y in the sorted list, element z ∈ anc(x) is sorted by the median slow(w, z) and ties are broken by the hash of each event w ∈ last(x).

[0068] In this embodiment, essentially immediately after x is created and / or defined, fast(x,y) gives the position of y in the overall order of events from the creator(x)'s perspective. If Q is infinite, the same overall order is calculated as in the previous embodiment. If Q is finite and all members are online, the same overall order is calculated as in the previous embodiment. If Q is finite and a minority of members are online at a given time, this function allows online members to reach a consensus among themselves, which remains constant as new members slowly come online one by one. However, if the network is partitioned, then members of each partition can reach their own consensus. Then, when the partitions heal, members of the smaller partition will adopt the consensus of the larger partition.

[0069] In other cases, such as regarding Figure 8-13EAs described, the database aggregation module can use different functions to calculate the overall order from the partial order in the hash graph. For example... Figure 8-9 As shown, each member (Alice, Bob, Carol, Dave, and Ed) creates and / or defines events (such as...). Figure 8 As shown in 1401-1413; Figure 9 (As shown in 1501-1506). Use about Figure 8-13E The functions and subfunctions described herein allow the overall order of events to be calculated by sorting events according to their receiving rounds, breaking ties by their receiving timestamps, and breaking those ties by their signatures, as further described in detail herein. In other cases, the overall order of events can be calculated by sorting events according to their receiving rounds, breaking ties by their receiving generations (rather than their receiving timestamps), and breaking those ties by their signatures. The following paragraphs specify the functions used to calculate and / or define the receiving rounds and receiving generations of events to determine the order of events. The following terms are combined... Figure 8-13E Usage and illustrations.

[0070] "Father": If Y contains a hash of X, then event X is the father of event Y. For example, in Figure 8 In this context, the father of Event 1412 includes Events 1406 and 1408.

[0071] "Ancestor": The ancestors of event X are X, its father, its father's father, and so on. For example, in Figure 8 In the example, the ancestors of event 1412 are events 1401, 1402, 1403, 1406, 1408, and 1412. An ancestor of an event can be called an event linked to that event, and vice versa.

[0072] "Descendants": The descendants of event X are X, its children, its children's children, and so on. For example, in Figure 8 In the diagram, the descendants of event 1401 are every event shown. Similarly, the descendants of event 1403 are events 1403, 1404, 1406, 1407, 1409, 1410, 1411, 1412, and 1413. The descendants of an event can be referred to as being linked to that event, and vice versa.

[0073] “N”: The total number of members in the population. For example, in Figure 8 In this context, the members are computing devices labeled Alice, Bob, Carol, Dave, and Ed, and N equals five.

[0074] “M”: The smallest integer greater than a certain percentage of N (e.g., greater than 2 / 3 of N). For example, in Figure 8In this context, if the percentage is defined as 2 / 3, then M equals four. In other cases, for example, M can be defined as a different percentage of N (e.g., 1 / 3, 1 / 2, etc.), a specific predefined quantity, and / or defined in any other suitable manner.

[0075] "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 In the story, the father of event 1405 is 1401.

[0076] "Self-ancestor": The self-ancestor of event X is X, its self-father, its self-father's self-father, etc.

[0077] "Serial Number" (or "SN"): An integer property of the event, defined as the event's parent serial number plus 1. For example, in Figure 8 In the sequence, 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).

[0078] "Generation Number" (or "GN"): An integer attribute of the event, defined as the maximum value of the generation number of the event's parent plus 1. For example, in Figure 8 In this context, event 1412 has two parents: events 1406 and 1408, which have generation numbers four and two, respectively. Therefore, the generation number of event 1412 is five (i.e., four plus one).

[0079] "Round Increment" (or "RI"): An attribute of an event that can be zero or one.

[0080] "Round Number" (or "RN"): An integer property of the event. In some cases, this is also referred to as the creation round or the creation round. In some cases, the round number can be defined as the maximum value of the round number of the event's parent plus the round increment of the event. For example, in... Figure 8 In the example, event 1412 has two parents: events 1406 and 1408, both with a round number of one. Event 1412 also has a round increment of one. Therefore, the round number of event 1412 is two (i.e., one plus one). In other cases, if R is the smallest integer, an event can have a round number R such that the event can strongly see (as described in this paper) at least M events defined and / or created by different members, all of which have a round number R-1. If no such integer exists, the round number of the event can be a default value (e.g., 0, 1, etc.). In this case, the round increment can be omitted when calculating the round number of the event. For example, in Figure 8In this context, if M is defined as the smallest integer greater than 1 / 2 of N, then M is three. Event 1412 strongly sees M events 1401, 1402, and 1408, where each event is defined by a different member and has a round number of 1. Event 1412 does not strongly see at least M events defined by different members and have a round number of 2. Therefore, the round number of event 1412 is 2. In some cases, the first event in a distributed database includes a round number of 1. In other cases, the first event in a distributed database may include a round number of 0 or any other suitable number.

[0081] "Bifurcation": 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 a self-ancestor of the other. For example, in Figure 9 In the process, member Dave forks by creating and / or defining events 1503 and 1504 that have the same self-parent (i.e., event 1501), such that event 1503 is not a self-ancestor of event 1504, and event 1504 is not a self-ancestor of event 1503.

[0082] "Identification" of a fork: A fork can be "identified" by a third event created and / or defined after two events that fork from each other, if both events are ancestors of the third event. For example, in Figure 9 In the example, member Dave forks by creating events 1503 and 1504, neither of which is a self-ancestor of the other. Since both events 1503 and 1504 are ancestors of event 1506, the fork can be identified by the later event 1506. In some cases, the identification of the fork can indicate that a specific member (e.g., Dave) has cheated.

[0083] Event “Identification”: If X does not have an ancestor event Z that branches off from Y, then event X “identifies” or “sees” its ancestor event Y. For example, in Figure 8 In this context, event 1412 recognizes (also "sees") event 1403 because event 1403 is an ancestor of event 1412, and event 1412 has no ancestor event that branches off from event 1403. In some cases, if X does not recognize a branch before event Y, then event X can recognize event Y. In this case, even if event X recognizes a branch by defining a member of event Y after event Y, event X can see event Y. Event X will not recognize events of that member after the branch. Furthermore, if a member defines two distinct events, both of which are the first events in that member's history, then event X can recognize the branch but will not recognize any events of that member.

[0084] "Strong identification" (also referred to herein as "strongly seen") of an event: 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 S of events (1) including both X and Y and (2) being an ancestor of event X and (3) being a descendant of ancestor event Y and (4) being identified by X and (5) each capable of identifying Y and (6) being created and / or defined by at least M distinct members, then event X "strongly identifies" not an ancestor event Y created and / or defined by the same members as X. For example, in Figure 8 In the given condition, if M is defined as the smallest integer greater than 2 / 3 of N (i.e., M = 1 + floor(2N / 3), which would be four in this example), then event 1412 strongly identifies its ancestor event 1401 because the event sets 1401, 1402, 1406, and 1412 are sets of at least four events that are ancestors of event 1412 and descendants of event 1401, and they are created and / or defined by the four members Dave, Carol, Bob, and Ed respectively, 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, if X can see at least M events created or defined by different members (e.g., events 1401, 1402, 1406, and 1412) (each of which can see Y), then event X (e.g., event 1412) can "strongly see" event Y (e.g., event 1401).

[0085] "R-first" event (also referred to as "witness" in this text): An event is "R-first" event (or "witness") if (1) has a round number R and (2) has a self-parent with a round number less than R or has no self-parent. For example, in Figure 8 In the event, event 1412 is the "round 2 first" event because it has a round number of two, and its parent event is event 1408, which has a round number of one (i.e., less than two).

[0086] In some cases, the round increment of event X is defined as 1 if and only if X “strongly identifies” at least M “round R first” events, where R is the largest round number of its parent. For example, in Figure 8In the diagram, if M is defined as the smallest integer greater than 1 / 2 of N, then M is three. Event 1412 strongly identifies M events 1401, 1402, and 1408, all of which are round 1 first events. Both parents of 1412 have round number 1, and 1412 strongly identifies at least M round 1 first events; therefore, the round increment for 1412 is one. Events marked "RI=0" in the diagram do not strongly identify at least M round 1 first events, therefore their round increments are 0.

[0087] In some cases, the following method can be used to determine whether an event X strongly recognizes its ancestor event Y. For each round R, the first ancestor event Y is maintained as an array A1 of integers, one for each member, giving the lowest sequence number of event X, where the member created and / or defined event X, and X can recognize Y. For each event Z, an array A2 of integers is maintained, one for each member, giving the highest sequence number of event W created and / or defined by that member, such that Z can recognize W. To determine whether Z strongly recognizes its ancestor event Y, the number E of element positions is counted such that A1[E] <= A2[E]. Event Z strongly recognizes Y if and only if this count is greater than M. For example, in Figure 8 In this context, members Alice, Bob, Carol, Dave, and Ed can each identify event 1401, with the earliest events that can do so being their events {1404, 1403, 1402, 1401, 1408}. These events have sequence numbers A1 = {1, 1, 1, 1, 1}. Similarly, the most recent event identified by event 1412 for each of them is event {NONE, 1406, 1402, 1401, 1412}, where Alice is listed as "NONE" because 1412 cannot identify any event for Alice. These events have sequence numbers A2 = {0, 2, 1, 1, 2}, where all events have positive sequence numbers, so 0 means Alice has no event identified by 1412. Comparing list A1 with list A2 yields the result {1<=0, 1<=2, 1<=1, 1<=1, 1<=2}, which is equivalent to {false, true, true, true, true} with four truth values. Therefore, there exists a set S of four events that are ancestors of 1412 and descendants of 1401. Since at least M is present, 1412 strongly identifies 1401.

[0088] Another variation of the method for determining whether event X strongly identifies its ancestor event Y using A1 and A2 is as follows. If the integer elements in both arrays are less than 128, it is possible to store each element in a single byte, pack 8 such elements into a single 64-bit word, and let 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. The two corresponding words are subtracted, and then a bitwise AND is performed with a mask to clear all bits except the most significant bit, and then right-shifted by 7 bits to obtain a value expressed in C as: ((A2[i]-A1[i])&0x8080808080808080)>>7). This can be added to a running accumulator S initialized to zero. After doing this multiple times, the accumulator is converted into a count by shifting and adding bytes, resulting in: ((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 using programming languages ​​such as C and / or Java. In others, they can be performed using processor-specific instructions, such as Advanced Vector Extensions (AVX) instructions provided by Intel and AMD, or equivalent instructions in a graphics processing unit (GPU) or general-purpose graphics processing unit (GPGPU). In some architectures, calculations can be performed faster by using words larger than 64 bits (such as 128, 256, 512, or more bits).

[0089] "Notable" event: Event X in round R is "notable" if (1) event X is the "first" event in round R (or "witness") and (2) a "yes" decision is reached via the execution of the Byzantine consensus protocol as described below. In some embodiments, the Byzantine consensus protocol may be executed by an instance of a distributed database (e.g., distributed database instance 114) and / or a database aggregation module (e.g., database aggregation module 211). For example, in Figure 8The diagram shows five Round 1 First Events: 1401, 1402, 1403, 1404, and 1408. If M is defined as the smallest integer greater than half a multiple of N (which is 3), then 1412 is a Round 2 First Event. If the protocol runs longer, the hash graph will grow upwards, and eventually the other four members will also have Round 2 First Events above the top of the graph. Each Round 2 First Event will have a "vote" regarding whether it is "famous" among each of the Round 1 First Events. Event 1412 will have a "yes" vote for being famous among 1401, 1402, and 1403, because these are Round 1 First Events it can recognize. Event 1412 will have a "no" vote for being famous among 1404, because 1412 cannot recognize 1404. For a given Round 1 First Event, such as 1402, its "famous" status will be determined by calculating the votes for its fame among each Round 2 First Event. These votes will then propagate to Round 3, Round 4, and so on, until a consensus is reached on whether 1402 is famous. The same process is repeated for the other Round 1 events.

[0090] The Byzantine consensus protocol can collect and use votes and / or decisions for the "round R first" event to identify "prominent" events. For example, if Y can "identify" event X, then event Y will vote "yes" for "round R+1 first"; otherwise, it will vote "no." Then, for each round G, votes are calculated for G = R+2, R+3, R+4, etc., until a decision is made by any member. Votes are calculated for each round G before a decision is made. Some of these rounds can be "majority" rounds, while others can be "coin" rounds. In some cases, such as round R+2, it is a majority round, and future rounds are designated as either majority rounds or coin rounds (e.g., according to a predefined schedule). For example, in some cases, whether a future round is a majority round or a coin round can be arbitrarily determined, provided there are no two consecutive coin rounds. For example, it might be predefined that there will be five majority rounds, then a coin toss, then five majority rounds, then a coin toss, and so on, until consensus is reached.

[0091] In some cases, if round G is the majority round, the vote can be calculated as follows. If there are at least M round G-1 first events that strongly identify vote V (where V is "yes" or "no"), then the consensus is V, and the Byzantine consensus protocol ends. Otherwise, for each round G first event, a new vote is calculated that represents the majority of round G-1 first events that can be strongly identified by each round G first event. In the case of a tie rather than a majority, the vote can be designated as "yes".

[0092] Similarly, if X is a witness in round R (or first in round R), then the voting results in rounds R+1, R+2, etc., can be calculated, where witnesses in each round vote on whether X is famous. In round R+1, every witness who can see X votes "yes," and the other witnesses vote "no." In round R+2, each witness votes based on the majority vote of the witnesses in round R+1 that they can strongly see. Similarly, in round R+3, each witness votes based on the majority vote of the witnesses in round R+2 that they can strongly see. This can continue for multiple rounds. In the case of a tie, the vote can be set to "yes." In other cases, a tie can be set to "no" or can be randomly assigned. If any round has at least M witnesses voting "no," the election ends, and X is not famous. If any round has at least M witnesses voting "yes," the election ends, and X is famous. If neither "yes" nor "no" has at least M votes, the election continues to the next round.

[0093] As an example, in Figure 8 Consider some round 1 events X below the diagram shown. Then, in each round 1 event 1, a vote is taken on whether X is significant. Event 1412 can strongly identify round 1 events 1401, 1402, and 1408. Therefore, the vote for event 1412 will be based on their votes. If this is a majority round, 1412 will check if at least M of {1401, 1402, 1408} have "yes" votes. If they do, it is decided to be "yes," and consensus is achieved. If at least M of them vote "no," it is decided to be "no," and consensus is achieved. If no more than M votes are cast in either direction, 1412 is given a majority vote as the votes of 1401, 1402, and 1408 (if a tie exists, it will be broken by voting "yes"). This vote will then be used in the next round, continuing until consensus is reached.

[0094] In some cases, if round G is a coin toss, the vote can be calculated as follows. If event X can identify at least M first events of round G-1 that vote V (where V is "yes" or "no"), then event X will change its vote to V. Otherwise, if round G is a coin toss, then each first event X of round G changes its vote to a pseudo-randomly determined result (similar to a coin flip in some cases), which is defined as the least significant bit of event X's signature.

[0095] Similarly, in this scenario, if the election reaches round R+K (coin rounds), where K is a specified factor (e.g., a multiple of a number such as 3, 6, 7, 8, 16, 32, or any other suitable number), the election will not end at 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 witness in round R+K, then Y will vote for V if it can strongly see at least M witnesses voting for V in round R+K-1. Otherwise, Y will vote based on random values ​​(e.g., based on the bits of event Y's signature (e.g., least significant bit, most significant bit, randomly selected bit), where 1 = "yes" and 0 = "no", or vice versa, based on event Y's timestamp, using a cryptographic "shared coin" protocol and / or any other random determination). This random determination is unpredictable before Y is created and therefore enhances the security of events and the consensus protocol.

[0096] For example, in Figure 8 In the event 1412, if round 2 is a coin toss and the voting is about whether an event prior to round 1 is well-known, then event 1412 will first check if at least M votes in {1401, 1402, 1408} are "yes", or if at least M votes in them are "no". If this is the case, then 1412 will vote in the same manner. If there are no at least M votes in either direction, then 1412 will have random or pseudo-random voting (e.g., based on the least significant bit of the digital signature created by Ed for event 1412 when ED created and / or defined event 1412).

[0097] In some cases, the result of pseudo-random determination can be the result of a cryptographically shared coin protocol, for example, it can be implemented as the least significant bit of a threshold signature of a round number.

[0098] As described above, in some implementations, the hash graph consensus method may include, for example, determining the reputation of witness X in round R. As described above, initial votes can be collected from round R+1, counting yes or no for each event based on whether it is a descendant of X. Alternative methods may include collecting initial votes from "R+2" instead of "R+1" (or "R+3", "R+4", etc. instead of "R+1"). In that method, additional steps may optionally be added. Specifically, in this implementation, whenever the first event X in round R (or witness X in round R) is an ancestor of witnesses in round R+1 created and / or defined by more than two-thirds of the total (i.e., more than 2N / 3 members), X is immediately declared famous, and the election ends immediately, even before any votes are counted for X. A second alternative approach could involve running an election for R, where initial votes are collected from R+1. Then, if the number of members identified as prominent witnesses in round R is less than a given threshold T (e.g., less than 2N / 3 members), a second election is run, where initial votes are collected from R+2. Similarly, if the number of prominent witnesses identified in round R using votes from round R+1 is insufficient, the election can be rerun from scratch using votes from round R+2 instead of round R+1 (i.e., the election results using votes from round R+1 are discarded, and the election is rerun using votes from round R+2). In some implementations, another alternative may include running an election for R, where initial votes are collected from R+1, then if the number of members created and / or defined as prominent witnesses in round R is less than a given threshold T (e.g., less than 2N / 3 members), then a prominent witness in round R (e.g., a judge) may be defined as a witness in round R who is an ancestor of a prominent witness in round R+1 (removing some to ensure that each member has only one prominent witness in round R).

[0099] The system can be constructed from any of the methods used to compute the pseudo-randomly determined results described above. In some cases, the system uses different methods cyclically in a certain order. In other cases, the system can select between different methods based on a predefined pattern.

[0100] "Receiving Round": If R is the smallest integer, then event X has a "receiving round" of R such that at least half of the first events (or prominent witnesses) in the prominent round R with round number R are descendants of X and / or can see X. In other cases, any other suitable percentage may be used. For example, in another case, if R is the smallest integer, then event X has a "receiving round" of R such that at least a predetermined percentage (e.g., 40%, 60%, 80%, etc.) of the first events (or prominent witnesses) in the prominent round R with round number R are descendants of X and / or can see X.

[0101] In some cases, the "receiving generation" of event X can be calculated as follows: Identify which member created and / or defined the first event in each round R that can identify event X. Then determine the generation number of that member's earliest event that can identify X. Then define the "receiving generation" of X as the median of this list.

[0102] In some cases, the “receive timestamp” T of event X can be the median of timestamps in the events that include the first event in which each member of X is identified and / or seen. For example, the receive timestamp of event 1401 can be the median of the timestamp values ​​of events 1402, 1403, 1404, and 1408. In some cases, the timestamp of event 1401 can be included in the median calculation. In other cases, the receive timestamp of X can be any other value or combination of timestamp values ​​in the events that include the first event in which each member of X is identified or seen. For example, the receive timestamp of X can be based on the average of the timestamps, the standard deviation of the timestamps, and / or a modified average (e.g., by removing the oldest and most recent timestamps from the calculation), and so on. In still other cases, an extended median can be used.

[0103] In some cases, the overall order and / or consensus order of events is calculated by sorting events by their reception rounds, breaking ties by their reception timestamps, and breaking those ties by their signatures. In other cases, the overall order of events can be calculated by sorting events by their reception rounds, breaking ties by their reception generations, and breaking those ties by their signatures. The above paragraphs specify functions for calculating and / or defining the reception rounds, reception timestamps, and / or reception generations of events.

[0104] In other cases, instead of using the signature of each event, an XOR operation can be performed using the signature of that event and the signatures of prominent events or prominent witnesses with the same receiving round and / or receiving generation in that round. In other cases, any other suitable combination of event signatures can be used to break ties to define the consensus order of events. The result of the XOR signature of prominent witnesses in a given round represents a pseudo-random number that is difficult for potential attackers and other entities to predict and / or manipulate. Therefore, in some implementations, the XOR signature can be used as a source of unpredictable random numbers (i.e., a "random beacon"). Random numbers can be used in various hash graph processes.

[0105] In other cases, instead of defining the "receiving generation" as the midpoint of the list, the "receiving generation" can be defined as the list itself. Then, when sorting by receiving generation, two receiving generations can be compared by the midpoint of their lists, breaking ties by the element immediately before the midpoint, breaking those ties by the element immediately after the midpoint, and continuing by alternating between elements before and after the element used so far, until a tie is broken.

[0106] In some cases, the median timestamp can be replaced with an "extended median." In this case, a list of timestamps can be defined for each event, instead of a single received timestamp. The list of timestamps for event X could include the first event that identifies and / or sees each member of X. For example, in... Figure 8 In the context of the event 1401, the timestamp list can include timestamps for events 1402, 1403, 1404, and 1408. In some cases, it may also include the timestamp for event 1401. When breaking a tie using timestamp lists (i.e., two events having the same reception round), the middle timestamps of each event's list (or the predetermined first or second of two middle timestamps, if any, a longer middle timestamp) can be compared. If these timestamps are the same, then the timestamps immediately following the middle timestamp can be compared. If these timestamps are the same, then the timestamps immediately preceding the middle timestamp can be compared. If these timestamps are also the same, then the timestamps following the three compared timestamps are compared. This can continue alternating until the tie is broken. Similar to the discussion above, if two lists are completely identical, a tie can be broken by the signatures of the two elements.

[0107] In other cases, "truncated extended median" can be used instead of "extended median". In this case, the entire list of timestamps for each event is not stored. Instead, only a few values ​​closest to the middle of the list are stored and used for comparison.

[0108] Besides calculating the overall order of events, the received median timestamp can potentially be used for other purposes. For example, Bob might sign a contract stating that he agrees to be bound by the contract if and only if there exists an event X involving Alice signing the same contract, where the received timestamp of X is on or before a certain deadline. In this case, as mentioned above, if Alice signs the contract after the deadline indicated by the "received median timestamp," Bob will not be bound by the contract.

[0109] In some implementations, if Alice creates two events X and Y that are forked (having the same parent), and Bob receives X, then subsequent events defined by Bob can see X. Later, when Bob receives Y, his subsequent future events will no longer see X or Y because Bob recognized the fork. In some implementations, this can be modified so that Bob's future events will continue to see X but not Y. Similarly, once a member can see an event, that seeing is "sticky," and their future events will continue to see that event but not any forks of that event. Using this, consensus methods and / or algorithms no longer need to detect forks or react to forks. The definition changes from an assertion (Can x see y?) to a function (Which witness can x see?).

[0110] In some implementations, the definitions of the see, stronglySee, and fork functions can be removed, and consensus methods and / or algorithms can use the terms lastSee, firstSee, stronglySeeP, stronglySeeS1, seeThruP, firstSelfWitnessS, and firstWitnessS (see example...). Figures 13A-13E (The functions shown). Each of these functions is assigned an event x and a member m, and returns the unique event created by member m and seen by event x (in some way). Several of the names ending in S, S1, or P indicate the returned event (respectively) in x's own cycle (x's creation cycle), its own cycle minus one, or its parent cycle. For each function, if there is no such visible event, or if (Indicating no event), then it returns

[0111] exist Figures 13A-13E In the function builder notation used, if multiple lines have a satisfying "if", then the first one (the one above) is used. Furthermore, assuming logical OR (∨) is short-circuited, p∨q is defined as true if p is true and q is undefined (e.g., if the definition of q would have infinite recursion).

[0112] Figures 13A-13E The example definitions in [the document] can be implemented directly in an efficient manner. Figure 13A and 13B The equations contain almost no quantifiers or universal quantifiers, making these calculations simple. An efficient implementation would involve the memory functions lastSee, stronglySeeP, round, firstSelfWitnessS, and firstWitnessS. Figure 13BOther functions in the array can be omitted from memory: parentRound, seeThru, stronglySeeS1, and firstSee. Each is a function that is both an event and a member. Therefore, functions can be memorized by storing an array for each event, with one element of the array for each member. Figures 13A-13E The examples in the table define recursive dependencies on each other and are listed in order, such that when any given function is called for a given event x, that function will not depend on the functions applied to x listed below, but only on the ancestors of x.

[0113] In some cases, the state of a distributed database can be defined after consensus is reached. For example, if S(R) is the set of events that a well-known witness in round R can see, then eventually all events in S(R) will have a known receiving round and a receiving timestamp. At this point, the consensus order of events in S(R) is known and will not change. Once this is achieved, members can compute and / or define representations of the events and their order. For example, a member can compute the hash values ​​of the events in S(R) according to their consensus order. The member can then digitally sign the hash values ​​(using that member's private key) and include the hash values ​​in the next event defined by the member. This can be used to notify other members that the member has determined that the events in S(R) have a given order that will not change. After at least M members (or any other suitable number or percentage of members) have signed the hash value of S(R) (and therefore agree on the order represented by the hash value), this consensus list of events, along with the list of members' signatures, can form a single file (or other data structure) that can be used to prove the consensus order as stated for the events in S(R). In some cases, if the event contains a transaction that updates the state of the distributed database system (as described herein), the hash value can be the hash value of the state of the distributed database system after the transaction that applies the events in S(R) in the consensus order.

[0114] In some cases, M (as described above) can be based on the weight value assigned to each member, rather than simply a fraction, percentage, and / or value of the total number of members. In this case, each member has an interest associated with their benefit and / or influence in the distributed database system. Such interest can be a weight value. Each event defined by the member can be considered to have a weight value for the member who defined it. Thus, M can be a portion of the total interest of all members. The above description of events dependent on M occurs when the set of members with at least M's total interest agrees. Therefore, based on their interests, some members can have a greater influence on the system and how the consensus order is derived. In some cases, transactions in an event can change the interests of one or more members, add new members, and / or delete members. If such a transaction has a receiving round of R, then after the receiving round has been calculated, events following round R will have their round numbers and other information recalculated using the modified interests and the modified member list. Votes about whether an event in round R is famous will use the old interests and member list, but votes about rounds following R will use the new interests and member list. Additional details regarding the use of weight values ​​to determine consensus are described in U.S. Patent No. 9,646,029, filed December 21, 2016 as U.S. Patent Application No. 15 / 387,048, entitled “Methods And Apparatus For A Distributed Database Within A Network,” which is incorporated herein by reference in its entirety.

[0115] In some cases, certain members can be identified and / or designated as "lazy members." In this case, lazy members can define and / or create events similar to regular or non-lazy members. Furthermore, events defined and / or created by lazy members can be included in the hash graph, and the consensus order used for such events can be computed and / or identified. However, the round increment of events defined by lazy members is zero. Therefore, the round number (or creation round) of an event defined by a lazy member is equal to the maximum value of the round number of the event's parent. Similarly, since the round increment of events defined by lazy members is zero, the round number (or creation round) of an event defined by a lazy member cannot be greater than the maximum value of the round number of the event's parent.

[0116] Furthermore, in some cases, events defined by lazy members are ineligible to vote in an election, and events defined by lazy members are ineligible to be the first event or witness in round R, and / or are not counted as intermediate events where events defined by ordinary or non-lazy members strongly see another event. Therefore, the restrictions imposed on lazy members result in a reduction in computation performed by the hash graph while still maintaining the integrity and security of the consensus order. Members can be selected as lazy members based on any suitable criteria. For example, in some cases, members can be designated as lazy members based on deterministic pseudo-random selection performed in each round, predefined at the start of the round, based on trust level, based on the amount of stake, based on the votes of other members, and / or random selection. In some cases, the members designated as lazy members can differ for each round, while in others, the members designated as lazy members remain the same across different rounds. In still others, events rather than members can be designated as "lazy" events. In this case, lazy events can be selected instead of members in each round.

[0117] Therefore, in some cases, the processor of the first member can define a first set of members (e.g., computing devices) and a second set of members (e.g., computing devices) based on a deterministic pseudo-random function. The first set of members can be non-lazy members, while the second set of members can be lazy members. In some cases, the first set of members is the absolute complement of the second set of members relative to the members (e.g., computing devices) of the distributed database. The first member (or the processor of the first member) can receive events from the second member (e.g., computing devices) linked to a first set of events defined by the set of members (e.g., the set of computing devices). The set of members includes at least one member from the first set of members and at least one member from the second set of members. The processor can use the values ​​of parameters (e.g., round number, round increment, vote, indication as a witness, indication as a prominent witness, etc.) of events in the first set of events defined by members of the first set of members, and not the values ​​of parameters of events in the first set of events defined by members of the second set of members, as a result of a consensus protocol (e.g., as described herein) to identify the order associated with the second set of events. The processor can identify, at least in part, the order associated with the set of transactions indicated in the instance of the distributed database based on the order associated with the second set of events, and can store the order associated with the set of transactions in the instance of the distributed database.

[0118] The preceding terms, definitions, and algorithms are used for illustration. Figure 8-13E The embodiments and concepts described herein. Figure 10A and Figure 10B The illustration shows a first example application of consensus methods and / or processes, presented in mathematical form. Figure 11A and Figure 11B The illustration shows a second example application of consensus methods and / or processes, presented in mathematical form. Figure 12A and 12B A third example application of the consensus method and / or process, illustrated in mathematical form, is shown. Figures 13A-13E The illustration shows a fourth example application of the consensus method and / or process, presented in mathematical form.

[0119] exist Figure 2 In the middle, the database aggregation module 211 and the communication module 212 are Figure 2 The diagram shows implementation in processor 210. In some embodiments, database aggregation module 211 and / or communication module 212 may be implemented in memory 220. In some embodiments, database aggregation module 211 and / or communication module 212 may be hardware-based (e.g., ASIC, FPGA, etc.).

[0120] Just as transactions can change data and / or state in a distributed database (as described in this article, for example, regarding...), Figure 1 Similarly, transactions can modify the membership of a distributed database (e.g., a collection of computing devices implementing the distributed database) by adding, removing, and / or modifying members. In some implementations, members of a distributed database can be modified from a collection of computing devices implementing the distributed database (e.g., Figure 1 One or more computing devices (110, 120, 130, 140) can be added and / or removed over time to change the set of computing devices implementing the distributed database. Similarly, the set of computing devices 110, 120, 130, 140 can change over time because computing devices from the set of computing devices 110, 120, 130, 140 are removed from the set of computing devices 110, 120, 130, 140 and / or other computing devices are added to the set of computing devices implementing the distributed database. In some cases, removed computing devices can be reconnected to the distributed database system later.

[0121] Address books can be used to keep track of members of a distributed database (i.e., the computing devices that implement the distributed database) at any given time. Figure 14 The illustration shows an address book 1400 associated with a distributed database system according to an embodiment. The address book 1400 includes components for... Figure 1 The entries in each of the computing devices 110, 120, 130, and 140 in the distributed database system 100. Specifically, the address book 1400 is defined as including entries in the computing devices implementing the distributed database (such as those related to...). Figure 1The address book 1400 is a set of public keys (A, B, C, and D) for the set of computing devices 110, 120, 130, 140 shown and described. In embodiments that use stake to determine consensus (e.g., a device's stake indicates the amount of influence that device has on the consensus process), the address book 1400 may also include the amount of stake associated with each computing device.

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

[0123] In some implementations, each round of the consensus protocol may have a new address book (e.g., each computing device implementing the distributed database may update its address book for each round of the consensus protocol). Specifically, when information in the address book changes (e.g., via transactions that add, remove, and / or modify the information in the computing device implementing the distributed database), each computing device may update its address book to reflect the transactions that changed the address book. After a receiving round is assigned via the consensus protocol for events including such changes, these changes may be reflected in the address book used for that round. Specifically, the address book A used for round r... r This can reflect transactions in events with a reception round less than r (i.e., transactions in events with a reception round of r-1 or less). Similarly, once an event with a reception round of r is identified, a new address book A can be defined for round r+1. r+1 This allows for the reception of transactions in rounds less than r+1. Therefore, in such implementations, the address book can be updated for each round. This ensures that transactions quickly impact the address book.

[0124] In some implementations, the address book A used for round r r Instead of updating for each round, updates are performed a predetermined number of rounds p after an event with receiving round r has been identified (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 Defined as A r-p A copy is then modified by a valid transaction in the receiving round rp or smaller. Therefore, if p = 2, then the address book A used for round r is... r This includes updates to the address book from transactions affecting the consensus mechanism (e.g., adding, removing, and / or modifying transactions in a distributed database implementation) that have received rounds r-2 or less. In some implementations, any other suitable value of p can be used (e.g., 3, 4, 5, etc.). This provides the computing mechanism with a duration of p-1 rounds (e.g., using a background thread) to process consensus transactions before using the new address book in the consensus protocol. This additional time can help avoid pauses and / or delays in the consensus protocol.

[0125] In some implementations, instead of the address book A for round r, r A predetermined number of rounds p following a previous update of the address book is updated (e.g., each computing device implementing the distributed database can update its address book accordingly). For example, in such an implementation, the address book A for round r... r A can be defined for any round that is not a multiple of p. r-1 A copy. Otherwise, address book A r This reflects transactions that have received events in rounds r-1 or smaller. Similarly, the address book can be updated every p rounds. For example, if p = 10, then for any round r that is not a multiple of 10, A r It can be defined as A r-1 An unmodified copy. Otherwise, if r is a multiple of 10, then A r It is A r-10 A copy of the address book is provided, modified by valid transactions in events receiving rounds r-10 through r-1. In some implementations, the multiplier p can be any suitable number (e.g., 2, 5, 10, 20, etc.). This allows for fewer recalculations of the round number (or creation round) of events when defining a new address book (as described further in detail herein). Specifically, batching multiple round changes to the address book before updating it ensures that the same address book is used to calculate and recalculate the round numbers for multiple rounds. Using the same address book for multiple rounds reduces the need to recalculate the round number (or creation round) of events after address book changes.

[0126] In some implementations, the consensus protocol can either wait for a predetermined number of rounds p after a previous address book update, or wait for a predetermined number of rounds k after reaching consensus before updating the address book. For example, in such implementations, the address book A used for round r... r A can be defined for any round that is not a multiple of p. r-1 A copy. Otherwise, if the round is a multiple of p, then address book A r This can reflect transactions in events with a receiving round number of rk or less. As an example, if p = 10 and k = 2, then for any r that is not a multiple of 10, A... r It can be defined as A r-1 An unmodified copy. Otherwise, if r is a multiple of 10, then A r It is A r-11 A copy of the address book is generated, which is modified by valid transactions in the receiving rounds r-11 through r-2. This can provide the advantage of batching changes from multiple rounds before they are applied to the address book, and the advantage of providing additional time (e.g., using background threads) for each computing device to process consensus transactions before the new address book is used in the consensus protocol.

[0127] After reaching a consensus on the prominent witnesses in round r, the event receiving round r can be identified, and a new address book A can be calculated. r+1 (As described above). In some implementations, each event can use a new address book A. r+1 The creation round is recalculated. This is done to identify prominent witnesses in round r+1. Therefore, for each address book and the round associated with that address book, the event can have a different creation round.

[0128] In some implementations, to reduce the number of recalculations of creation rounds for events, some events can be identified as frozen. Frozen events are not recalculated in their creation rounds when a new address book is defined. Specifically, if an event is an ancestor of any notable witness in round r or earlier, then it can be considered frozen and its creation round will not be recalculated in subsequent rounds or using a subsequent address book. However, if an event is not an ancestor of any notable witness in round r or earlier, then the address book A used for round r+1 is used. r+1In round r+1, its creation round is recalculated (if the address book used for round r+1 has changed from the address book used for round r). Similarly, moving forward, after identifying prominent witnesses in round r+1 and identifying the events that received round r+1, if the additional event is an ancestor of a prominent witness in round r+1 or earlier, the additional event can become frozen. Such frozen events will not have their creation round recalculated in round r+2. This can similarly continue for future rounds of the consensus protocol.

[0129] In some implementations, the recalculation of the two rounds can be modified so that when the parent round is r+2, a majority (rather than a strong one) is seen, while when the parent round is r+1, only one (rather than the vast majority) is seen. This controls the trade-off between latency and computational complexity: it increases computational cost but reduces latency in reaching consensus. In some implementations, latency can also be reduced by having each computing device implementing the distributed database synchronize substantially simultaneously with many other computing devices, such as allowing each event to have multiple other parent events.

[0130] Figure 15 This is a flowchart illustrating a method 1500 for updating an address book according to an embodiment. Method 1500 can be executed by a processor of a computing device in a set of computing devices implementing a distributed database. Method 1500 includes defining an address book for the distributed database at 1502. In some embodiments, the address book includes an identifier (e.g., a public key) and / or other information (e.g., a stake value) for each computing device in the set of computing devices implementing the distributed database via a network.

[0131] At 1504, an event is received that includes a transaction updating the address book. For example, the event may include transactions such as adding a computing device to the set of computing devices implementing a distributed database, removing a computing device from the set of computing devices implementing a distributed database, and / or updating the equity value associated with a computing device in the set of computing devices implementing a distributed database.

[0132] At point 1506, a consensus protocol based on a distributed database using an address book is used to compute the reception round of an event. For example, any suitable consensus protocol, such as the one disclosed herein, can be used to compute the reception round of an event (or a property associated with order).

[0133] At point 1508, the address book is updated based on a transaction, defined as a predetermined number of rounds following at least one of the event reception round or a previous update to the address book. As discussed above, in some implementations, the address book may be updated based on a predetermined number of rounds following the event reception round. In some implementations, the address book may be updated after a predetermined number of rounds following a previous update to the address book (e.g., when the update to the address book occurs when the round is a multiple of p).

[0134] In some implementations, the consensus protocol is configured to identify a set of events (e.g., notable witnesses) for each round of the consensus protocol. The consensus protocol can use the event set for each round to determine the receiving round for each event in the set. Furthermore, an address book can be used to compute attributes (e.g., creation round) for each event in the set. When an event is not an ancestor of at least one event in the event set defining the round of the updated address book, the attribute can be recomputed for each event in the set using the updated address book. Similarly, when an event from a set is an ancestor of at least one event in the event set defining the round of the updated address book, the attribute is not recomputed for each event in the set using the updated address book.

[0135] In some implementations, events are stored indefinitely in the distributed database and / or as part of a Directed Acyclic Graph (DAG). In some implementations, events can be discarded as they become old. For example, if an event is old enough, it can be classified as ancient. In some implementations, the computing device can optionally delete ancient events from its distributed database instance. If an event is even older, it can be classified as expired, and the computing device discards it from its distributed database instance. If the distributed database has not reached consensus on an event by the time it becomes old (e.g., the distributed database has not identified the reception round for the event), then the event can be classified as obsolete. In such implementations, events classified as obsolete are not assigned a reception 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. Moreover, when an event becomes expired, it is no longer sent during synchronization with other members (the computing devices implementing the distributed database). However, in some implementations, members can continue to exchange ancient events during synchronization so that members that may be lagging behind in time can still consider these events (e.g., such lagging members may still not consider such events as ancient).

[0136] In some cases, if all the fathers of an event already exist in the DAG or hash graph, then the event is added only to the DAG or hash graph. In other embodiments, if the father does not exist in the DAG or hash graph but the father may be ancient or expired, then the event can still be added to the DAG or hash graph.

[0137] In some embodiments, the thresholds for expired and / or ancient events can be defined by the number of rounds from when the event was created until it becomes ancient or expired. As an example, the thresholds can be defined as expiredDuration > ancientDuration > 0. The values of ancientDuration and expiredDuration can be any suitable values. For example, in some embodiments, ancientDuration = 4 and expiredDuration = 8. In other embodiments, any other values can be used for ancientDuration and / or expiredDuration.

[0138] In some embodiments, each event can include an indication of the declared generation number (or generation) of each father event of the event. In such embodiments, the generation number of an event can be one more than the maximum of the declared generation numbers of the event's fathers. An event with no fathers can have a generation number of one.

[0139] When the distributed database (or the (one or more) computing devices implementing the distributed database), the DAG, or the hash graph reaches a consensus on an event with a specific receive round (e.g., receive round r, where the distributed database did not previously reach a consensus on receive round r), the generation number for round r can be the minimum generation number of the events that are well-known witnesses in round r. In some embodiments, if the generation number of event x is less than the generation number of the round equal to the most recent round, then event x can be considered ancient to achieve consensus for reducing ancientDuration. Similarly, if gen(x) < gen(r – ancientDuration), then event x can be considered ancient, where gen(x) is the generation number of event x and gen(r - ancientDuration) is the generation number of the round obtained by subtracting ancientDuration from the most recent round r for which consensus was reached. Similarly, in some embodiments, if the generation number of event x is less than the generation number of the round equal to the most recent round, then event x can be considered expired to achieve consensus for reducing expiredDuration (or gen(x) < gen(r – expiredDuration)).

[0140] In some embodiments, a core set S of events for round r can be definedr The core set of events in round r can be defined as the non-ancient, non-expired events that are frozen immediately after consensus is reached in round r. Similarly, the core set S of events in round r... r The core set of events can be the set of witnesses frozen in round r, along with their ancestors in round r and previous rounds, whose generations are close enough that the events are not old or outdated. The core set of events can be useful for demonstrating that the distributed database system described in this paper continues to possess the asynchronous Byzantine Fault Tolerance (ABFT) property. For example, consensus can be guaranteed for the basic case of round 1 because no events have been discarded and the address book has not been changed. Then, if consensus in round r is true, and all honest members have the same core set S of events for round r+1... r If all members have the same address book, then all members will reach the same consensus in round r+1, thus for the same core set S of events in r+1. r+1 Consensus is reached with the consensus event and the address book of r+2. Therefore, consensus can be proven inductively.

[0141] In some implementations, if a new member (computing device) joins the distributed database and / or if 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 another member (computing device), such as the most recent round r that reached consensus. In some implementations, the latest information can be the state of the distributed database digitally signed by a predetermined number and / or percentage of the current members and / or stake (e.g., 1 / 3 of the members and / or 1 / 3 of the total stake in the distributed database). In addition to the signed state of round r (which reflects the results of consensus transactions up to round r), the new member or reconnected member can obtain other information about the hash graph, DAG, and / or the distributed database. For example, the new member or reconnected member can receive the core set S of round r from another member. r The core set S of events and rounds r in the event set. r The hash value of the events in the graph and / or the minimum generation of the unique, well-known witness in each non-ancient round, such as when r is the latest round with consensus. With this information, new or reconnected members can join or rejoin the hash graph, DAG, and / or distributed database.

[0142] In some implementations, where possible, reconnecting members may write their events and / or the state of their hash graph, DAG, and / or distributed database instance to memory before rebooting or leaving the hash graph, DAG, and / or distributed database. Reconnecting members can then read the events and / or state after rebooting and / or reconnecting to the hash graph, DAG, and / or distributed database. This can save synchronization bandwidth after rebooting and / or when members reconnect and / or rejoin the hash graph, DAG, and / or distributed database, but it is not required.

[0143] As an example, the member computing device Alice (using the processor at Alice's computing device) can use the DAG and / or hash graph at Alice's distributed database instance to determine and / or identify prominent witnesses in the distributed database for rounds up to and including round r. Alice can then compute a consensus order for receiving events with rounds r or less. Using the consensus order, Alice can process transactions in the events according to the consensus order to determine the state of the distributed database. Alice can compute a hash value of the state of the distributed database and define and send new events with transactions that include the hash value of the state. Alice can digitally sign this event and / or transaction using Alice's private key. Alice can then collect digital signatures from other members of the distributed database who agree on the state, such that the state of the distributed database is digitally signed by a predetermined number and / or percentage of the current members and / or stake in the distributed database (e.g., at least 1 / 3 of the members and / or 1 / 3 of the total stake in the distributed database).

[0144] In this example, if computing device Bob joins (or reconnects to) the network (e.g., by being added to the address book via a transaction in an event), Alice can send him the signed state of round r (e.g., the state of round r digitally signed by a predetermined number and / or percentage of current members and / or interests in the distributed database). Bob can then begin synchronizing with the other members of the distributed database. Specifically, he can receive events by synchronizing with other members. Bob can first accept events that are not old but whose parents are old (according to the definition of old as of the end of round r). Bob can then accept events whose parents are either old or among the older events Bob has received. Using these events, Bob can begin constructing and / or defining a DAG. This can continue until Bob receives events up to the present, at which point Bob catches up and can be a full participating member.

[0145] As a participating member, Bob can calculate the reception rounds for subsequent events received by Bob. Because different address books are used for different rounds (as discussed in this article), Bob cannot use address book A. r+1 Simply calculate the reception round for each event. Therefore, in some implementations, the signature status may include and / or be sent to Bob (from Alice), having S r Each event in, along with S r The creation round of each event in S. Then Bob will know S r Bob determines the consensus creation round for each event in the round. Using this information, Bob can then compute the consensus creation round for events in round r-1 and subsequent rounds. For events with creation rounds prior to r-1, Bob will not know the creation round, but this is irrelevant because these events will not be used to compute the consensus creation round for prominent witnesses in round r+1 and beyond.

[0146] Although described above as sending S to Bob r Each event in the sequence, but in some implementations, only those events whose creation round is greater than the creation round of their parent event. r Only those events in the sequence are sent along with the signed state to the joined (or reconnected) member (e.g., Bob). This provides enough information for other events so that Bob can recalculate the creation rounds of the other events by copying the creation round from the creation round of its parent event, which has the highest creation round.

[0147] In some implementations, the S discussed above, which is sent along with the signature status, is... r The hash value of each event is sent along with the signed state, rather than the event itself. Therefore, in this implementation, the state comprises a list of three hash values ​​and / or is sent along with a list of three hash values: the creation round greater than its parent, and the creation rounds in rounds r, r-1, and r-2. rThe hash value of the event in the state. In this implementation, upon reconnection or new connection, Bob can synchronize with other members until Bob receives an event whose hash value is stored in the signed state and / or sent with the signed state. Specifically, Bob can identify such events during synchronization by calculating a hash value for each event Bob receives and comparing that hash value with the hash value Bob received with the state. Bob can then assign an appropriate creation round to any event that is both an ancestor of an event whose hash value is in the state and / or sent with the state, and a descendant of another event whose hash value is in the state and / or sent with the state. Bob can also assign a predetermined creation round value (e.g., -∞) to any other event for which it has no parent event. Based on this information, Bob can define a DAG, and Bob can use address book A r+1 Calculate the value for creating a round for the other events Bob receives as described above. As more rounds reach consensus and as Bob receives more events in sync with other members, he can continue from there as a regular participating member.

[0148] Figure 16 This is a flowchart illustrating method 1600 for connecting and / or joining a distributed database. Method 1600 can be executed by the processor of the computing device. Method 1600 includes, at 1602, a collection of computing devices connected via a network to and acting as nodes of the distributed database. For example, a computing device can join the distributed database as a member and / or node by being added to the address book of the distributed database. This can be accomplished using transactions within events ordered using a consensus protocol of the distributed database (as described herein).

[0149] At 1604, the state of the distributed database associated with the completed round of the consensus protocol is received from a computing device in the set of computing devices. In some implementations, the state may be digitally signed by a predetermined number and / or percentage of the current members and / or stakes of the distributed database (e.g., at least 1 / 3 of the members and / or 1 / 3 of the total stake in the distributed database). The state may be the state of the distributed database as given in round r (e.g., transactions included in receiving round r or earlier have been executed and / or processed). In some implementations, the state includes an indication of the core set of events associated with the completed round (e.g., hash values ​​of each event from the core set of events) and a round identifier of each event from the core set of events, or is sent together with the indication of the core set of events associated with the completed round (e.g., hash values ​​of each event from the core set of events) and a round identifier of each event from the core set of events. In some implementations, the core set of events does not include events with a predetermined number of rounds prior to the completed round (e.g., expired and / or ancient).

[0150] At position 1606, a set of events associated with the state is received from the set of computing devices. This set of events can be received based on synchronization with other computing devices from the set of computing devices.

[0151] At point 1608, based on the core set of events and the round identifier of each event from the core set of events, a set of attributes for each event from the event set is computed. For example, attributes described in this paper regarding the consensus protocol (e.g., creation round, notable witnesses for each round, etc.) can be computed for each event in the event set.

[0152] At point 1610, a directed acyclic graph (DAG) is constructed based on the event set and the attribute set of the event set, and at point 1612, the DAG is used to compute the order of events associated with the next round of the consensus protocol. Computing devices connected to and / or joined to the distributed database can continue to operate as fully functional and up-to-date members.

[0153] In some cases, distributed databases (e.g., regarding...) Figure 1(As shown and described) can be used to implement cryptocurrencies. In this case, each distributed database instance 114, 124, 134, 144 can define one or more wallet data structures (also referred to herein as wallets) to store cryptocurrencies. In some cases, users not associated with the distributed database (e.g., computing devices that are not members of the distributed database) can also create and / or define such wallets. The wallet data structure can include a key pair (public key and private key). In some cases, the key pair used for the wallet can be generated by the computing device from which the wallet originates. For example, if Alice defines a wallet (W, K), where W is the public key (which can also act as the identifier of the wallet) and K is the private key, then she can publish W (e.g., in an event) to the remaining instances of the distributed database, but keep her identity anonymous, so that other instances of the distributed database (or their users) cannot recognize that wallet W is associated with Alice.

[0154] Figure 7 The diagram illustrates a signal flow diagram of synchronization events between two computing devices according to an embodiment. Specifically, in some embodiments, distributed database instances 703 and 803 can exchange events to achieve aggregation. Computing device 700 can randomly select to synchronize with computing device 800 based on its relationship with computing device 700, its proximity to computing device 700, and / or an ordered list associated with computing device 700. In some embodiments, since computing device 800 can be selected by computing device 700 from a set of computing devices belonging to the distributed database system, computing device 700 can select computing device 800 multiple times consecutively or can refrain from selecting computing device 800 for a period of time. In other embodiments, an indication of a previously selected computing device can be stored at computing device 700. In such embodiments, computing device 700 can wait for a predetermined number of selections before being able to select computing device 800 again. As described above, distributed database instances 703 and 803 can be implemented in the memory of computing device 700 and the memory of computing device 800, respectively.

[0155] In some implementations, computing device 700 can run multiple threads simultaneously, each thread synchronized with another member. Therefore, in addition to computing device 800, computing device 700 can also interact with other computing devices (…). Figure 7(Not shown in the image) Synchronization. In some cases, computing device 700 may establish a connection for each thread initially or immediately, and then maintain each connection activity or open by periodically sending heartbeat messages (e.g., twice per second). Thus, in some cases, computing device 700 can prevent synchronization delays or latency otherwise caused by Transport Layer Security (TLS) protocols (e.g., record protocols and handshake protocols) each time a computing device establishes a connection with another member or computing device for synchronization. Further details regarding establishing and maintaining connections with other members or computing devices (including as a pool of connections) can be found in U.S. Patent No. 10,375,037, filed July 11, 2018, as U.S. Patent Application No. 16 / 032,652, entitled “Methods and Apparatus for Efficiently Implementing a Distributed Database within a Network,” which is incorporated herein by reference in its entirety.

[0156] Figure 3-6 An example hash diagram according to an embodiment is illustrated. There are five members, each represented by a black vertical line. Each circle represents an event. Two downward lines from an event represent the hash of two previous events. In this example, each event has two downward lines (one black line to the same member and one light line to another member) in addition to the first event for each member. Time progresses upwards. Figure 3-6 In this context, the computing devices for the distributed database are designated as Alice, Bob, Carol, Dave, and Ed. It should be understood that such designation refers to devices that are structurally and functionally similar to those described above. Figure 1 Computing devices 110, 120, 130, and 140 are shown and described. The following paragraphs include example systems for implementing distributed databases. It should be understood that any example can be combined with other examples, devices, methods, and / or systems listed below or otherwise described herein.

[0157] Example System 1: If computing device 700 is called Alice and computing device 800 is called Bob, then synchronization between them can be as follows: Figure 7 As shown, synchronization between Alice and Bob can be achieved, for example, as follows:

[0158] Alice sends events stored in distributed database 703 to Bob.

[0159] - Bob creates and / or defines a new event that contains:

[0160] --Hash of the last event created and / or defined by Bob

[0161] --Hash of the last event created and / or defined by Alice

[0162] --The above is Bob's digital signature

[0163] Bob sends events stored in distributed database 803 to Alice.

[0164] Alice creates and / or defines new events.

[0165] Alice sends that event to Bob.

[0166] Alice calculates the overall order of events based on the hash diagram.

[0167] Bob calculates the overall order of events based on the hash diagram.

[0168] At any given time, a member can store the events received so far, along with an identifier associated with the computing device and / or distributed database instance that created and / or defined each event. Each event contains the hashes of two earlier events, except for the initial event (which has no parent hash) and the first event for each new member (which has a single parent event hash representing the event of the existing member that invited them to join). A graph representing this set of events can be drawn. It can display a vertical line for each member and a point or circle on that line for each event created and / or defined by that member. Whenever an event (the higher point) includes the hash of an earlier event (the lower point), a diagonal line is drawn between the two points. An event can be said to be linked to other events if it can be referenced by the hash of other events (directly or through intermediate events).

[0169] For example, Figure 3An example of hash graph 600 is illustrated. Bob creates and / or defines event 602 as a result of synchronizing with Carol and after synchronizing 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 included within event 602 includes pointers to its direct ancestor events, namely events 608 and 610. Therefore, Bob can use event 602 to reference events 608 and 610 and use the pointers to previous events to reconstruct the hash graph. In some cases, event 602 may be referred to as being linked to other events in hash graph 600 because event 602 can reference every event in hash graph 600 via earlier ancestor events. For example, event 602 is linked to event 608 via event 604. As another example, event 602 is linked to event 616 via events 606 and 612.

[0170] Example System 2: A system derived from Example System 1 (or any other example system disclosed herein), wherein the event also includes a "payload" of transactions or other information to be logged. Such a payload can be used to update the event using any transactions and / or information that have occurred and / or been defined since a directly prior event of the computing device. For example, event 602 may include any transactions performed by Bob since event 604 was created and / or defined. Therefore, Bob can share this information when event 602 is synchronized with other computing devices. Accordingly, transactions performed by Bob can be associated with the event and shared with other members using the event. In some implementations, Example System 2 may also be applied to other example systems disclosed herein that may not specifically refer to Example System 2.

[0171] Example System 3: A system derived from Example System 1 (or any other example system disclosed herein), wherein the events also include the current time and / or date for debugging, diagnostics, and / or other purposes. The time and / or date may be the local time and / or date when the computing device (e.g., Bob) creates and / or defines the event. In such an embodiment, this local time and / or date is not synchronized with the remaining devices. In other embodiments, the time and / or date may be synchronized across devices (e.g., when events are exchanged). In still other embodiments, a global timer may be used to determine the time and / or date.

[0172] Example System 4: A system derived from Example System 1 (or any other example system disclosed herein), wherein Alice neither sends to Bob events created and / or defined by Bob, nor sends ancestor events of such events. Event x is an ancestor of event y if y contains a hash of x, or if y contains a hash of an event that is a descendant of x. Similarly, in such an embodiment, Bob sends to Alice events that have not yet been stored by Alice, and does not send events that have already been stored by Alice.

[0173] For example, Figure 4 The example hash graph 620 illustrates the ancestor events (dashed circles) and descendant events (striped circles) of event 622 (black circle). The lines establish a partial order of events, where ancestors appear before black events and descendants appear after them. This partial order does not indicate whether white events precede or follow black events; therefore, the overall order or consensus order is used to determine their sequence. For example, Figure 5 The illustration shows an example hash graph that represents a specific event (solid circle) and the first moment each member receives an indication of that event (striped circle). When Carol synchronizes with Dave to create and / or define event 624, Dave does not send Carol 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 stored in Carol's distributed database instance. In some embodiments, Dave may identify events to send to Carol based on what Dave's hash graph reveals about which events Carol has previously received. Event 622 is an ancestor of event 626. Therefore, at event 626, Dave has already received event 622. Figure 4 The diagram illustrates Dave receiving event 622 from Ed, Ed receiving event 622 from Bob, and Bob receiving event 622 from Carol. Furthermore, at event 624, event 622 is the last event Dave received created and / or defined by Carol. Therefore, Dave can send Carol events that Dave has stored, excluding event 622 and its ancestors. Additionally, after receiving event 626 from Dave, Carol can reconstruct the hash graph based on pointers to events stored in Carol's distributed database instance. In other embodiments, based on Carol sending event 622 to Dave... Figure 4(Not shown in the image) and Dave uses event 622 (and references therein) to identify the events Carol has received, allowing Dave to determine which events to send to Carol. By reconstructing the hash graph, Carol can determine how Dave will vote in the consensus protocol described above without actually receiving Dave's votes for each round of the consensus protocol. Similarly, based on Carol's hash graph, Carol can determine how each remaining member of the distributed database will vote without specifically receiving their votes. This reduces network traffic because votes for each round of the consensus protocol are not exchanged among the members of the distributed database.

[0174] Example System 5: A system derived from Example System 1 (or any other example system disclosed herein) in which two members send events to another member in a specific order, such that an event is not sent until the receiver has received and / or stored the event's ancestor. Therefore, the sender sends events from oldest to newest, allowing the receiver to examine the two hashes for each event upon receiving it by comparing them to the two ancestor events already received. The sender can identify which events to send 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 the receiver has already received. References Figure 3 For example, when Bob is synchronizing with Carol to define event 602, Carol can identify that event 619 is the last event Carol received that Bob created and / or defined. Therefore, Carol can determine that Bob knows about that event and its ancestors. Thus, Carol can first send Bob events 618 and 616 (i.e., the oldest events Carol received that Bob hasn't yet received). Carol can then send Bob event 612 and then event 606. This allows Bob to easily chain the events and reconstruct his hash graph. Using Carol's hash graph to identify which events Bob hasn't yet received improves synchronization efficiency and reduces network traffic because Bob doesn't request events from Carol.

[0175] In other embodiments, the most recent event may be sent first. If the receiver determines (based on the hash of the two previous events in the most recent event and / or the pointers to previous events in the most recent event) that they have not yet received one of the two previous events, the receiver may request the sender to send such an event. This can occur until the receiver has received and / or stored the ancestor of the most recent event. (See also...) Figure 3In such an embodiment, for example, when Bob receives event 606 from Carol, Bob can identify the hashes of events 612 and 614 within event 606. Bob can determine that event 614 was previously received from Alice when event 604 was created and / or defined. 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. Bob can then determine, based on the hash within event 612, that he has not yet received events 616 or 618, and can request these events from Carol accordingly. Based on events 616 and 618, Bob will then be able to determine the ancestors of the events he has received, such as event 606.

[0176] Example System 6: A system derived from Example System 5 (or any other example system disclosed herein) with the additional constraint that, when a member chooses among several events to be sent next, the event that minimizes the total number of bytes created and / or defined by that member so far is selected. For example, if Alice has only two remaining events to send to Bob, one 100 bytes created and / or defined by Carol, and the other 10 bytes created and / or defined by Dave, and Alice has so far sent 200 bytes of Carol's event and 210 bytes of Dave's event in this synchronization, then Alice should send Dave's event first, followed by Carol's event, because 210 + 10 < 100 + 200. This can be used to address attacks where a single member sends a single large event or a large number of small events. In cases where the traffic exceeds the byte limit of most members (as discussed with regard to Example System 7), the method of Example System 6 ensures that attacker events are ignored instead of legitimate user events. Similarly, attacks can be mitigated by sending smaller events before larger ones (to defend against a massive event bundled together). Furthermore, if a member cannot send every event in a single synchronization (e.g., due to network limitations, member byte limits, etc.), then that member can send several events from each member, rather than simply sending events defined and / or created by the attacker while (or almost never sending) events created and / or defined by other members.

[0177] Example System 7: The system from Example System 1 (or any other example system disclosed herein), which has an additional first step where Bob sends a number to Alice indicating the maximum number of bytes he is willing to receive during that synchronization, and Alice replies with her limit. When the next event will exceed this limit, then Alice stops sending. Bob does the same. In such an embodiment, this limits the number of bytes transferred. This may increase the aggregation time but will reduce the amount of network traffic per synchronization.

[0178] Alternatively or additionally, in some embodiments, a byte count limit for each synchronization process and / or the number of events allowed to be synchronized per synchronization process is implemented in a distributed database. For example, Alice may send events to Bob that Bob does not yet know, then when the next event exceeds and / or reaches a synchronization threshold, the database instance associated with Alice may stop and / or terminate sending data packets and / or events, the synchronization threshold being based on the allowed number of bytes (i.e., the amount of synchronized data) or the allowed amount of events to be synchronized. If an event and the father of the event are being synchronized, then the transmission of the event in such a case can be performed by sending the father of the event before sending the event.

[0179] In some cases, when Alice is synchronizing with Bob and she needs to send him two events (e.g., event X and event Y), and Bob already has all the fathers of these two events, then Alice can choose which one to send first. In some embodiments, Alice can calculate the total number of bytes (Bx) in all the bytes in X plus all the bytes in all the events of the creator of X that she has already sent during this synchronization. Similarly, she can calculate the number of bytes in Y and the total number of bytes in the events sent so far by the creator of Y (By). Then, if Bx < By, then she can choose to send X before Y, if By < Bx, then send Y before X, and if Bx = By, then send them in either order.

[0180] In some cases, synchronization between two members can be limited to a maximum number of events received per synchronization (e.g., to prevent denial-of-service attacks). If such a limit is reached before all events associated with the synchronization are received, the synchronization ends prematurely. In other cases, each synchronization event can be limited to a maximum number of bytes received (instead of being limited to the number of events received, or as a supplement to it). Thus, limits such as the maximum number of events received and the maximum number of bytes received can be used to constrain or regulate the number of events and / or bytes received and / or accepted by the receiving member (e.g., Bob) from another member (e.g., Alice) during synchronization. The limits mentioned above can prevent attacks in which malicious members create large events or overwhelm the network with a large number of small events. These limits also ensure graceful degradation in some situations, such as when a member has a low-bandwidth connection used to handle an average amount of data traffic rather than a surge in data traffic.

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

[0182] In some cases, a lack of consensus can cause memory overflow for members or computing devices. For example, when at least one-third of the total is offline, the set of events for which consensus has not yet been reached can grow or increase beyond a given threshold because consensus may not be possible when too few members are online. Therefore, the memory of a member or computing device may overflow due to the accumulated number of events for which consensus cannot be reached. To prevent memory overflow due to the accumulation of events for which consensus cannot be reached, each member and / or computing device can be configured such that once the threshold of events for which consensus has not yet been reached is reached, that member or computing device can refuse to define and / or create any new events until that member or computing device reaches consensus on some events that it is aware of. In other words, in some cases, a lack of consensus can lead to overflow if consensus cannot be reached (e.g., when too few members are online and consensus cannot be reached). Therefore, to prevent the overflow of events that cannot be placed in the consensus order (e.g., because too few members are online), a member does not define any additional events until it can receive events from some offline members to reach consensus on some older events.

[0183] Example System 8: A system from Example System 1 (or any other example system disclosed herein), wherein the following steps are added at the start of the synchronization process:

[0184] Alice identifies S, that is, the set of events she has received and / or stored, skipping events created and / or defined by Bob or those that are ancestors of events created and / or defined by Bob.

[0185] Alice identifies the members who create and / or define each event in S and sends a list of member ID numbers to Bob. Alice also sends multiple events created and / or defined by each member that she has received and / or stored.

[0186] Bob responds using a list of how many events he has received that were created and / or defined by other members.

[0187] Alice then sends Bob only the events he hasn't yet received. For example, if Alice indicates to 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.

[0188] Example System 9: A system derived from Example System 1 (or any other example system disclosed herein) with additional mechanisms for identifying and / or handling cheaters. Each event contains two hashes, one from the last event created and / or defined by that member (“self-hash”), and one from the last event created and / or defined by another member (“external hash”). If a member creates and / or defines two different events with the same self-hash, then that member is a “cheater.” If Alice discovers that Dave is a cheater by receiving two different events created and / or defined by Dave with the same self-hash, she stores an indicator that he is a cheater and avoids synchronizing with him in the future. If she discovers that he is a cheater but still synchronizes with him again and creates and / or defines a new event recording that fact, then Alice also becomes a cheater, and other members who know that Alice is still synchronizing with Dave stop synchronizing with Alice. In some embodiments, this only affects synchronization unilaterally. For example, when Alice sends a list of identifiers and the number of events she received from each member, she doesn't send the cheater's ID or count, so Bob won't reply with any corresponding numbers. Alice then sends Bob the events she received, and those of other cheaters for whom Bob hasn't received any indication that he has. After this synchronization is complete, Bob will also be able to determine that Dave is a cheater (if he hasn't already identified Dave as a cheater), and Bob will refuse to synchronize with the cheater.

[0189] Example System 10: The system in Example System 9 (or any other example system disclosed herein), where Alice begins the synchronization process by sending Bob a list of cheaters she has identified and who still stores their events, and Bob replies with any cheaters he has identified in addition to those identified by Alice. They then continue as usual, but without considering cheaters when synchronizing with each other.

[0190] Example System 11: The system in Example System 1 (or any other example system disclosed herein) has a process that repeatedly updates the current state (e.g., captured by database state variables defined by members of the system) based on transactions within any new events received during synchronization. This may also include a second process that repeatedly rebuilds the state (e.g., the order of events) whenever the sequence of events changes, by returning to a copy of the earlier state and by processing the events in a new order to recalculate the current state. 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 reached (based on total or consensus order)). At some point (e.g., after a period of time, after defining and / or receiving a given number of events, etc.), the version of the state updated with the receipt of new events and transactions may be discarded, and a new copy of the state updated only after consensus is reached may be used as the new version of the state updated when new events and transactions are received. This ensures synchronization of the two states.

[0191] In some embodiments, the current state is a state, balance, and / or conditions associated with the outcome of a transaction. Similarly, the state can include data structures and / or variables modified by the transaction. For example, if the transaction is a remittance between bank accounts, the current state could be the current balance of the accounts. As another example, if the transaction is associated with a multiplayer game, the current state could be a location associated with the game, the number of lives, acquired items, and / or the state of the game, etc.

[0192] Example System 12: The system in Example System 11 (or any other example system disclosed herein) makes maintaining state (e.g., bank account balance, game state, etc.) faster by using "fast clones" of arrayLists. A fast clone of an arrayList is a data structure that works like an array with an additional feature: it supports "cloning" operations, which appear to create and / or define new objects as copies of the original. Cloning is as if it were a real copy because changes to the clone do not affect the original. However, cloning is faster than creating a real copy because creating a clone does not actually involve copying and / or updating the entire contents of one arrayList to another. Instead of two clones and / or copies of the original list, two small objects, each with a hash table and a pointer to the original list, can be used. When a write is made to a clone, the hash table remembers which element was modified and the new value. When a read is performed on a location, the hash table is checked first, and if the element has been modified, the new value in the hash table is returned. Otherwise, the element in the original arrayList is returned. In this way, the two "clones" are initially just pointers to the original arrayList. However, because each one is repeatedly modified, it grows into a large hash table storing the differences between itself and the original list. Cloning itself can be done, causing the data structure to expand into a tree of objects, each with its own hash table and a pointer to its parent. Therefore, a read results in walking up 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 real copy of its parent, changes in the hash table can be applied to the copy, and the hash table is discarded. Furthermore, if a clone is no longer needed, it can be removed from the tree during garbage collection, and the tree can be shrunk.

[0193] Example System 13: The system in Example System 11 (or any other example system disclosed herein) makes it faster to maintain state (e.g., bank account balance, game state, etc.) by using a “fast clone” hash table. It is identical to System 12 except that the root of the tree is a hash table instead of an arrayList.

[0194] Example System 14: The system in Example System 11 (or any other example system disclosed herein) enables faster maintenance of state (e.g., bank account balances, game state, etc.) by using a “fast clone” relational database. For example, a fast clone database can be used to maintain two copies of the state, as discussed with regard to Example 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 with an ID number and a pointer to the object containing the database. When user code attempts to execute a Structured Query Language (SQL) query on the database, the query is first modified and then sent to the real database. The real database is the same as the database seen by the client code, except that each table has an 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 are created with IDs 2 and 3 (e.g., two copies for maintaining state). Each row in each table will have 1, 2, or 3 in the clone ID field. When a query comes from user code to clone 2, the query is modified so that the query will only read rows with an ID of 2 or 1 in that field. Similarly, a read of 3 looks for rows with an ID of 3 or 1. If a Structured Query Language (SQL) command goes to clone 2 and says to delete a row, and that row has an ID of 1, then the command should only change 1 to 3. This will mark the row as no longer shared by clones 2 and 3, and it will now only be visible to clone 3. If several clones exist in the operation, then several copies of the row can be inserted, and each copy can be changed to a different clone's ID, making the new row visible to all clones except the one that just "deleted" the row. Similarly, if a row is added to clone 2, the row is added to the table with ID 2. Modifying a row is equivalent to deleting and then inserting. As before, if several clones are garbage collected, then the tree can be simplified. The structure of this tree will be stored in an additional table that the clones cannot access, and is purely for internal use.

[0195] Example System 15: The system in Example System 11 (or any other example system disclosed herein) achieves faster state maintenance by using a "fast clone" file system. This is an object that acts as a wrapper for the 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 either stores a large number of files in a single directory or partitions them by filename (to keep directories small). The directory tree can be stored in a database instead of being 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 the clone now exists. If 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 using a copy of the existing hard drive. Changes to one copy may have no effect on the others. In reality, there is only one copy of each file or directory, and copying occurs when a file is modified via a clone.

[0196] Example System 16: The system in Example System 15 (or any other example system disclosed herein), in which a separate file is created and / or defined on the host operating system for each N-byte portion of a file in a fast-cloning filesystem. N can be some suitable size, such as, for example, 4096 or 1024. In this way, if a byte is changed in a large file, then only one block of the large file is copied and modified. This also improves efficiency when storing many files that differ by only a few bytes on a drive.

[0197] Example System 17: A system similar to Example System 11 (or any other example system disclosed herein), in which each member includes in some and / or all of the events they create and / or define a hash of a state at a previous time, and the number of events that occurred up to that point, to indicate to the member that a consensus now exists regarding the order of the events. After members have collected signed events containing such hashes from a majority of users for a given state, members can then store it as proof of the consensus state at that point and remove events and transactions prior to that point from memory.

[0198] Example System 18: A system from Example System 1 (or any other example system disclosed herein) where the calculation of the median or majority is replaced by a weighted median or weighted majority, where members are weighted by their “stakes.” Stake is a number indicating how many votes a member has counted. Stake can be a share of cryptocurrency or simply an arbitrary number allocated when a member is first invited to join and then divided among new members invited by that member. Older events can be discarded when enough members agree on a consensus state such that their total stake is a majority of the existing stake. If the total order is calculated using the median of the rankings contributed by the members, the result is a number where half of the members have higher rankings and half have lower rankings. On the other hand, if the total order is calculated using a weighted median, the result is a number where approximately half of the total stake is associated with a ranking below that median and approximately half of the total stake is associated with a ranking above that median. Weighted voting and medians can be useful in preventing Sybil attacks, in which a member invites a large number of “alias” users, each of whom is simply a pseudonym controlled by the inviting member. If inviting members are forced to share their stake with invitees, then pseudonyms will be useless against attackers attempting to control the consensus outcome. Therefore, proof-of-stake can be useful in some situations.

[0199] Example System 19: A system from Example System 1 (or any other example system disclosed herein) in which multiple databases exist in a hierarchical structure instead of a single distributed database. For example, there might be a single database where users are its members, and thus several smaller databases or "blocks," each with a subset of members. When events occur within a block, they are synchronized among members of that block, not among members outside that block. Then, from time to time, after a consensus order has been determined within a block, the resulting state (or events with their overall consensus order) can be shared with all members of the larger database.

[0200] Example System 20: A system in Example System 11 (or any other example system disclosed herein) that has the capability to have events that update software used to update the state (e.g., captured by database state variables defined by the system's members). For example, events X and Y may contain transactions that modify the state, and then update the state appropriately, depending on the software code that reads the transactions in these events. Event Z may then contain notification that a new version of the software is now available. If the overall order tells that 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 processing the transactions in Y with the new software. However, if the consensus order is X, Y, Z, then both X and Y can be updated with the old software, which may give different final states. Therefore, in such an embodiment, notification of code upgrades can occur within an event, allowing the community to reach a consensus on when to switch from the old version to the new version. In some embodiments, the code can switch from the old version to the new version in a round following the round in which event Z (including notification of code upgrades) is received. Therefore, if event Z is determined to have a receiving round r, then any event with a receiving round r or earlier will be sorted using the old version. Similarly, any event that has not yet had a receiving round up to round r will be sorted using the new version. This ensures that members remain in a synchronized state. It also ensures that the system remains operational even during upgrades without requiring a reboot or restart of the process.

[0201] Example System 21: A system from Example System 1 (or any other example system disclosed herein) in which members or computing devices of a hash graph are configured to remove unwanted events from an instance of a distributed database by defining a signed state for the distributed database. In some implementations, members or computing devices may perform additional processes to prevent memory overflow and / or conserve memory resources. For example, members or computing devices may periodically discard old events based on a set of rules or criteria. For example, if the number of receiving rounds minus the round number (or creation round) of an event exceeds a given threshold, or if the generation of an event is less than a threshold (e.g., based on expiredDuration or ancientDuration), then a rule may state to ignore or discard transactions in the event. In some cases, an event contains the hash of its parent and the creation round of each parent. Thus, a given event can still be accepted during synchronization, even if one or more parents are lost due to being ignored or discarded because they were created too many rounds ago (e.g., ancient or expired, as described herein). Consequently, the signed state may include hashes of events defined and / or created in rounds prior to the signed state, but which will be ignored or discarded shortly before the signed state. Removing or discarding unnecessary events reduces the overhead of synchronizing redundant or irrelevant events between collections of computing devices implementing a distributed database (e.g., members of a hash graph) and reduces underutilization of the local memory of such collections of computing devices. Additional details regarding the removal and / or discarding of events can be found in U.S. Patent Application Publication 2018 / 0173747, filed December 19, 2017, as U.S. Patent Application No. 15 / 846,402, entitled “Methods and Apparatus for a Distributed Database that Enables Deletion of Events,” which is incorporated herein by reference in its entirety.

[0202] Furthermore, in some implementations, during synchronization with another member, the computing device may reject received events that are grammatically incorrect (e.g., unparsed) or have invalid digital signatures. Also, in some implementations, expired events may be rejected during synchronization. Additionally, in some implementations, during synchronization, events received that have a non-ancient, non-expired parent event that was lost at the computing device (e.g., not in the computing device's memory or DAG or in an instance of the distributed database) may be rejected until a non-ancient, non-expired parent event is received.

[0203] The system described above is expected to create and / or implement an efficient aggregation mechanism for distributed consensus, and to achieve eventual consensus. Several theorems can prove this, as shown below.

[0204] Example Theorem 1: If event x precedes event y in a partial order, then at a given time, given members’ knowledge of the other members, each of the other members will either receive an indication that x precedes y, or will not have received an indication that y has not yet been received.

[0205] Proof: If event x precedes event y in a partial order, then x is an ancestor of y. When a member first receives an indication of y, that member either has already received an indication of x earlier (in which case they hear x before y), or it will be the case that synchronization provides that member with both x and y (in which case they will hear x before y during that synchronization, because events received during a single synchronization are considered to have been received in the order consistent with ancestor relationships as described with respect to Example System 5). QED

[0206] Example Theorem 2: For any given hash graph, if x precedes y in a partial order, then x will precede y in the overall order calculated for that hash graph.

[0207] Proof: If x precedes y in a partial order, then by Theorem 1:

[0208] For all i, rank(i,x) <rank(i,y)

[0209] Here, rank(i,x) is the rank assigned to event x by member i. If x is the first event received by member i, it is 1; if it is the second event, it is 2, and so on. Let med(x) be the median of rank(i,x) over all i, and the same applies to med(y).

[0210] For a given k, choose i1 and i2 such that rank(i1,x) is the rank of the kth smallest x, and rank(i2,y) is the rank of the kth smallest y. Then:

[0211] rank(i1,x) <rank(i2,y)

[0212] This is because rank(i2,y) is greater than or equal to the k rank(i), each of which is strictly greater than the corresponding rank(i). Therefore, rank(i2,y) is strictly greater than at least the k rank(i), and thus strictly greater than the kth smallest rank(i). This argument applies to any k.

[0213] Let n be the number of members (which is the number of i values). Then n must be either odd or even. If n is odd, let k = (n + 1) / 2, and the k-th smallest rank will be the median. Thus med(x) < med(y). If n is even, then when k = n / 2, the k-th smallest x rank will be strictly less than the k-th smallest y rank, and the (k + 1)-th smallest x rank will be strictly less than the (k + 1)-th smallest y rank. Thus the average of these two x ranks will be less than the average of these two y ranks. Thus, med(x) < med(y). Therefore, in both cases, the median of the x ranks is strictly less than the median of the y ranks. Thus, if the total order is defined by a sorting action by median rank, then x will be before y in the total order. QED

[0214] Example Theorem 3: If the "gossip period" is the amount of time for an existing event to spread synchronously to all members, then:

[0215] After 1 gossip period: All members have received the event

[0216] After 2 gossip periods: All members agree on the order of the events

[0217] After 3 gossip periods: All members know that consensus has been reached

[0218] After 4 gossip periods: All members obtain digital signatures from all other members to approve this consensus order.

[0219] Proof: Let S0 be the set of events created and / or defined up to a given time T0. If each member will eventually synchronize with each other member infinitely often, then with probability 1 there will eventually be a time T1 where the events in S0 have spread to every member such that every member knows all the events. This is the end of the first gossip period. Let S1 be the set of events that exist at time T1 and did not exist at T0. Then with probability 1 there will eventually be a time T2 where each member has received every event in the set S1, which are those events that existed at time T1. This is the end of the second gossip period. Similarly, T3 is the time when all events in S2 (i.e., those events that existed up to T2 but did not exist before T1) have spread to all members. Note that each gossip period ends with probability 1 eventually. On average, if there are n members, each gossip period will last the time it takes to perform log2(n) synchronizations.

[0220] By time T1, each member will have received every event in S0.

[0221] By time T2, a given member Alice will have received records of every other member receiving each event in S0. Therefore, Alice can calculate the rank of each action in S0 for each member (the order in which that member received the action) and then sort the events according to the median of the rank. The overall order of the events in S0 will not change. This is because the resulting order is a function of the order in which each member first received the indications for each of these events, and it does not change. It is possible that the order Alice calculates will have some events from S1 interspersed among the S0 events. These S1 events may still change, where they fall within the sequence of S0 events. However, the relative order of the events in S0 will not change.

[0222] By time T3, Alice will have learned the overall order of the union of S0 and S1, and the relative order of events within that union will not change. Furthermore, she can find the earliest event from S1 in this sequence and conclude that the sequence of events prior to S1 will not change, even if new events are inserted outside of 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. She can digitally sign the hash of the state generated by these events occurring in this order (e.g., captured by database state variables defined by Alice) and issue the signature as part of the next event she creates and / or defines.

[0223] By time T4, Alice will have received similar signatures from the other members. At that point, she can simply retain the list of signatures along with the state they confirm, and she can discard the events she stored prior to the first S1 event. QED

[0224] The system described in this paper describes a distributed database that achieves consensus quickly and securely. This could 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 if the state is simply a statement of the current amount in each wallet, then the system would constitute a cryptocurrency system that avoids the expensive proof-of-work required in existing systems. Automated rule enforcement allows it to add features not common in current cryptocurrencies. For example, lost coins can be recovered to avoid deflation by enforcing the rule that if a wallet neither sends nor receives cryptocurrency within a certain period, then the wallet is deleted, and its value is distributed to other existing wallets proportional to the amount they currently contain. In this way, even if a wallet's private key is lost, the money supply will not increase or decrease.

[0225] Another example is distributed gaming, which is similar to a massively multiplayer online game (MMO) played on a server, but implemented without using a central server. Consensus can be reached without the control of any central server.

[0226] Another example is a system for social media built on such a database. Because transactions are digitally signed and members receive information about other members, this offers advantages in security and convenience compared to current systems. For example, since email return addresses cannot be forged, an email system with strong anti-spam policies can be implemented. Such a system could also become a unified social system, combining the functionality currently performed via email, tweets, text, forums, wikis, and / or other social media within a single distributed database.

[0227] Other applications could include more sophisticated cryptographic features, such as group digital signatures, where the entire group collaborates to sign a contract or document. This, and other forms of multi-party computation, can be usefully implemented using such distributed consensus systems.

[0228] Another example is a public ledger system. Anyone can pay to store some information in the system, paying a small amount of cryptocurrency (or real-world currency) per byte per year. These funds can then be automatically distributed to the members who store the data, as well as to members who repeatedly synchronize to work and reach consensus. It can automatically transfer a small amount of cryptocurrency to members each time they synchronize.

[0229] These examples demonstrate the usefulness of distributed consensus databases as components in many applications. Because databases do not use expensive proof-of-work, but may use cheaper proof-of-stake, they can run alongside full nodes on smaller computers or even mobile and embedded devices.

[0230] While the above description refers to an event comprising a hash of two preceding events (one self-hash and one external hash), in other embodiments, a member may synchronize with two other members to create and / or define an event comprising a hash of three preceding events (one self-hash and two external hashes). In still other embodiments, any number of event hashes from any number of members' preceding events may be included in an event. In some embodiments, different events may include hashes of different numbers of preceding events. For example, a first event may include two event hashes, and a second event may include three event hashes.

[0231] While the above description of events as including hashes (or cryptographic hashes) of previous events is valid, in other embodiments, events may be created and / or defined to include pointers, identifiers, and / or any other suitable references to previous events. For example, events may be created and / or defined to include sequence numbers associated with and used to identify previous events, thereby linking events. In some embodiments, such sequence numbers may include, for example, an identifier associated with the member who created and / or defined the event (e.g., a Media Access Control (MAC) address, Internet Protocol (IP) address, and / or an assigned address, etc.) and the order of events defined by that member. For example, a member with an identifier of 10, and whose event is the 15th event created and / or defined by that member, may assign an identifier of 1015 to that event. In other embodiments, any other suitable format may be used to assign identifiers to events.

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

[0233] While the example systems shown and described above are referenced to other systems, in other embodiments, any combination of the example systems and their associated functionality can be implemented to create and / or define a distributed database. For example, example systems 1, 2, and 3 can be combined to create and / or define a distributed database. As another example, in some embodiments, example system 10 can be implemented using example system 1 without example system 9. As yet another example, example system 7 can be combined and implemented with example system 6. In still other embodiments, any other suitable combination of example systems can be implemented.

[0234] While various embodiments have been described above, it should be understood that they are given by way of example only and not as limitations. Where the methods described above instruct certain events to occur in a certain order, the ordering of some events can be modified. Furthermore, if possible, some events in the process can be executed concurrently in parallel processes, as well as sequentially as described above.

[0235] Some embodiments described herein relate to computer storage products having a non-transitory computer-readable medium (also referred to as a non-transitory processor-readable medium) having instructions or computer code thereon for performing operations of various computer implementations. A computer-readable medium (or processor-readable medium) is non-transitory in the sense that it does not itself include transient propagation signals (e.g., propagating electromagnetic waves carrying information over a transmission medium such as space or cable). The medium and computer code (also referred to as code) can be those codes designed and constructed for a particular purpose or one or more. Examples of non-transitory 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 discs / digital video discs (CD / DVD), compact disc read-only memories (CD-ROMs), 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 memories (ROMs), and random access memory (RAM) devices. Other embodiments described herein relate to computer program products that may include, for example, the instructions and / or computer code discussed herein.

[0236] Examples of computer code include, but are not limited to, microcode or microinstructions, such as machine instructions generated by a compiler, code for generating web services, and files containing higher-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 ​​(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. Additional examples of computer code include, but are not limited to, control signals, encryption code, and compression code.

[0237] While various embodiments have been described above, it should be understood that they are given by way of example only and not as limitations, and various changes in form and detail may be made. Any part of the apparatus and / or methods described herein may be combined in any combination other than mutually exclusive combinations. The embodiments described herein may include various combinations and / or sub-combinations of the functions, components, and / or features of the different embodiments described.

Claims

1. A method comprising: Define the address book of the distributed database, which includes the identifier of each computing device among the multiple computing devices that implement the distributed database via a network; Receive events from the computing devices among the plurality of computing devices, including transactions that update the address book; Calculate the attributes of each of a plurality of events, which are included in the plurality of events; Based on a consensus protocol using a distributed database with an address book, the reception round of an event is calculated, the reception round being based on a threshold number of events in the event set that are descendants of the event. The address book is updated based on transactions, with the updated address book defined as a predetermined number of rounds following at least one of the event reception round or a previous update to the address book, said predetermined number of rounds being greater than one. In response to the first event among the plurality of events not having descendant events in the event set, the attributes of the first event are recalculated using the updated address book; as well as In response to a second event among the plurality of events having descendant events in the event set, the attribute of recalculating the second event using the updated address book is excluded.

2. The method of claim 1, wherein the transaction of 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 of claim 1, wherein the address book includes the equity value of each of the plurality of computing devices implementing the distributed database, and the transaction of updating the address book includes modifying the equity value of at least one of the plurality of computing devices.

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

5. The method of claim 1, wherein the update includes defining the updated address book a predetermined number of rounds following a previous update of the address book, the updated address book including updating the address book within an event of receiving a round number between the round in which the previous update of the address book occurred and the round in which the updated address book is defined.

6. The method of claim 1, wherein the identifier of each of the plurality of computing devices is the public key of that computing device among the plurality of computing devices.

7. The method of claim 1, wherein the computing device is a first computing device, and the method further comprises: The state of the distributed database is defined based on multiple receiving rounds of the events. as well as The state of the distributed database is sent to a second computing device among the plurality of computing devices, the state being: (1) associated with a completion round of the consensus protocol; and (2) including an indication of a core set of events, the core set of events being (a) associated with the completion round and (b) including fewer events than the set of events. (3) is used to generate a directed acyclic graph (DAG) at a second computing device.

8. An apparatus comprising: A memory of computing devices associated with a distributed database implemented via a network of multiple computing devices, the network being operatively coupled to the multiple computing devices; as well as A processor, operatively coupled to the memory, is configured to: Define an address book for the distributed database, the address book including an identifier for each of the plurality of computing devices implementing the distributed database; Receive events from the computing devices among the plurality of computing devices, including transactions that update the address book; Calculate the attributes of each of a plurality of events, which are included in the plurality of events; Based on a consensus protocol using a distributed database with an address book, the reception round of an event is calculated, the reception round being based on a threshold number of events in the event set that are descendants of the event. The address book is updated based on transactions, with the updated address book defined as a predetermined number of rounds following at least one of the event reception round or a previous update to the address book, said predetermined number of rounds being greater than one. In response to the first event among the plurality of events not having descendant events in the event set, the attributes of the first event are recalculated using the updated address book; as well as In response to a second event among the plurality of events having descendant events in the event set, the attribute of recalculating the second event using the updated address book is excluded.

9. The apparatus of claim 8, wherein the processor is configured to update the address book on a transaction basis to define the updated address book a predetermined number of rounds following the reception round of an event.

10. The apparatus of claim 8, wherein the processor is configured to update the address book on a transaction basis to define the updated address book a predetermined number of rounds following a previous update of the address book, the updated address book including the update of the address book within an event of receiving a round number between the round in which the previous update of the address book occurred and the round in which the updated address book is defined.

11. The apparatus of claim 8, wherein the transaction of 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.

12. The apparatus of claim 8, wherein the computing device is a first computing device, and the processor is further configured to: The state of the distributed database is defined based on multiple receiving rounds of the events. as well as The state of the distributed database is sent to a second computing device among the plurality of computing devices, the state being: (1) associated with a completion round of the consensus protocol; and (2) including an indication of a core set of events, the core set of events being (a) associated with the completion round and (b) including fewer events than the set of events. (3) is used to generate a directed acyclic graph (DAG) at a second computing device.

Images