Methods and apparatus for distributed databases within a network

Abstract

This application relates to methods and apparatus for a distributed database within a network. 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 implementing the distributed database. The apparatus also includes a processor configured to define a first event linked to a first event set. The processor is configured to receive from a second computing device in the set of computing devices a signal 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. The processor is configured to store the order associated with the third event set in the instance of the distributed database.

Description

[0001] This application is a continuation-in-part of the application entitled "Methods and Apparatus for a Distributed Database within a Network" and having application number 201910908046.6, filed on August 26, 2016.

[0002] The original application of this application is the application entitled "Methods and Apparatus for a Distributed Database within a Network" and having application number 201680061456.6, filed on August 26, 2016.

[0003] Cross Reference to Related Applications

[0004] This application is a continuation-in-part of U.S. Patent Application No. 15 / 205,688, filed on July 8, 2016, entitled "Methods and Apparatus for a Distributed Database within a Network," which is a continuation of U.S. Patent Application No. 14 / 988,873, filed on January 6, 2016, entitled "Methods and Apparatus for a Distributed Database within a Network," which claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 211,411, filed on August 28, 2015, entitled "Methods and Apparatus for a Distributed Database within a Network," each of which is incorporated herein by reference in its entirety.

[0005] This application is also a continuation-in-part of U.S. Patent Application No. 15 / 153,011, filed May 12, 2016, entitled “Methods and Apparatus for a Distributed Database within a Network,” which is a continuation-in-part of U.S. Patent Application No. 14 / 988,873, filed January 6, 2016, entitled “Methods and Apparatus for a Distributed Database within a Network,” which claims priority and benefit to U.S. Provisional Patent Application No. 62 / 211,411, filed August 28, 2015, entitled “Methods and Apparatus for a Distributed Database within a Network.” Each of these applications is incorporated herein by reference in its entirety.

[0006] This application also claims priority and benefit to U.S. Provisional Patent Application No. 62 / 211,411, filed August 28, 2015, entitled “Methods and Apparatus for a Distributed Database within a Network,” which is incorporated herein by reference in its entirety.

[0007] This application also claims priority and benefit to U.S. Provisional Patent Application No. 62 / 344,682, filed June 2, 2016, entitled “Methods and Apparatus for a Distributed Database with Consensus Determined Based on Weighted Stakes,” which is incorporated herein by reference in its entirety. Background Technology

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

[0009] Some known distributed database systems attempt to reach consensus on values ​​within the system (e.g., regarding 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 for the servers within the distributed database system to eventually agree on which user should pick up the item first.

[0010] This distributed consensus can be handled through methods and / or processes such as the Paxos algorithm or its variants. According to such methods and / or processes, one server in the database system is designated as the "leader," and the leader determines the order of events. (For example, in a multiplayer game) Events are forwarded to the leader, the leader selects the order of events, and the leader broadcasts this order to the other servers in the database system.

[0011] 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 a trusted third party to operate the database system.

[0012] Other distributed databases are designed to be leaderless, but are inefficient. For example, one such distributed database is based on a "blockchain" data structure that allows consensus to be reached. However, such systems can be limited to a small number of transactions per second for all participants combined (e.g., 7 transactions per second), which is insufficient for large-scale games or many traditional database applications. Therefore, there is a need for a distributed database system that achieves consensus without a leader and is highly efficient. Summary of the Invention

[0013] 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 implementing the distributed database. The apparatus also includes a processor configured to define a first event linked to a first set of events. The processor is configured to receive from a second computing device in the set of computing devices a signal representing (1) a second event defined by the second computing device and (2) linked to a second set of events. The processor is configured to identify an order associated with a third set of events, at least based on the results of a protocol. The processor is configured to store the order associated with the third set of events in the instance of the distributed database. Attached Figure Description

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

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

[0016] Figures 3-6 An example of a hashDAG according to an embodiment is shown.

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

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

[0019] Figures 9a-9c This is a vector graph that shows an example of a vector with values.

[0020] Figures 10a-10d This is a vector graph showing an example of a vector whose values ​​have been updated to include the new values.

[0021] Figure 11 This is a flowchart illustrating the operation of a distributed database system according to an embodiment.

[0022] Figure 12 This is a flowchart illustrating the operation of a distributed database system according to an embodiment.

[0023] Figure 13 This is a flowchart illustrating the operation of a distributed database system according to an embodiment.

[0024] Figure 14 This is an example of a hashDAG according to an embodiment.

[0025] Figure 15 This is an example of a hashDAG according to an embodiment.

[0026] Figures 16a-16b An example consensus method for use with hashDAG is shown according to an embodiment.

[0027] Figures 17a-17b An example consensus method for use with hashDAG is shown according to another embodiment. Detailed Implementation

[0028] 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.

[0029] 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, reception 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 (1) is an ancestor of the events in the third event set, and (2) is associated with a first common attribute (e.g., common round number, indication as the first event of round R, etc.) of the remaining events in the fourth event set. The first common attribute may indicate a first instance where an event defined by each computing device in the computing device set is associated with a first specific value (e.g., indication as the first event of round R, etc.).

[0030] 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 it. Each event in the fifth set of events is a descendant of the event and is associated with a second common attribute (e.g., being well-known) as a remaining event in the fifth set of events. The second common attribute may be associated (1) with a third common attribute (e.g., being the first event of round R or a witness), where the third common attribute indicates a first instance of a second event defined by each computing device in the computing device set associated with a second specific value different from a first specific value, and (2) with a result based on an indication set. Each indication in the indication 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, which indicates a first instance of a third event defined by each computing device in the computing device set associated with 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).

[0031] In some embodiments, an apparatus includes a memory and a processor. The memory includes an instance of a distributed database at a first computing device configured to be included within a set of computing devices implementing the distributed database via a network operatively coupled to the set of computing devices. The processor is operatively coupled to the memory storing the instance of the distributed database and is configured to receive signals representing events linked to a set of events. The processor is configured to identify an order associated with the set of events, at least based on the results of a protocol. The processor is configured to store the order associated with the set of events in the instance of the distributed database.

[0032] In some embodiments, a non-transitory processor-readable medium stores code representing instructions to be executed by a processor to receive signals representing events linked to a set of events, and to identify an order associated with the set of events based on the rounds associated with each event in the set and an indication of when to increment the rounds associated with each event. The code also includes code that causes the processor to store the order associated with the set of events in an instance of a distributed database at a first computing device configured to be included within a set of computing devices implementing the distributed database via a network operatively coupled to the processor.

[0033] In some embodiments, an instance of a distributed database at a first computing device may be 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 first computing device stores multiple transactions in the instance of the distributed database. A database convergence module may be implemented in the memory or processor of the first computing device. The database convergence module may be operatively coupled to the instance of the distributed database. The database convergence module may be configured to define a first event linked to a first event set at a first time. Each event in the first event set is a sequence of bytes and (1) is associated with a set of transactions in a plurality of transaction sets, and (b) is associated with the order associated with that transaction set. Each transaction in the transaction set originates from the plurality of transactions. The database convergence module may be configured to receive (1) a second event defined by the second computing device and (2) linked to a second event set from a second computing device in the set of computing devices at a second time after the first time. The database convergence module may be configured to define a third event linked to the first and second events. The database convergence module may be configured to identify the order associated with the third event set based at least on the first and second event sets. Each event in the third event set originates from at least one of the first or second event sets. The database convergence module can be configured to identify the order associated with multiple transactions based at least on (1) the order associated with the third event set and (2) the order associated with each of the multiple transaction sets. The database convergence module can be configured to store the order associated with the multiple transactions stored in the first computing device within an instance of the distributed database.

[0034] In some embodiments, an instance of a distributed database at a first computing device can be 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. A database convergence module can be implemented in the memory or processor of the first computing device. The database convergence module can be configured to define a first event linked to a first event set at a first time. Each event in the first event set is a sequence of bytes. The database convergence module can be configured to receive (1) a second event defined by the second computing device and (2) linked to a second event set from a second computing device in the set of computing devices at a second time after the first time. Each event in the second event set is a sequence of bytes. The database convergence module can be configured to define a third event linked to the first and second events. The database convergence module can be configured to identify the order associated with the third event set based at least on the first and second event sets. Each event in the third event set comes from at least one of the first or second event sets. The database convergence module can be configured to store the order associated with the third event set in an instance of the distributed database.

[0035] In some embodiments, data associated with a first transaction may be received at a first computing device in a set of computing devices, wherein the set of computing devices implements a distributed database via a network operatively coupled to the set of computing devices. Each computing device in the set of computing devices has a separate instance of the distributed database. A first transaction order value associated with the first transaction may be defined at a first time. Data associated with a second transaction may be received from a second computing device in the set of computing devices. A transaction set may be stored in the instance of the distributed database at the first computing device. The transaction set may include at least the first transaction and the second transaction. A set of transaction order values, including at least the first transaction order value and the second transaction order value, may be selected at a second time after the first time. The second transaction order value may be associated with the second transaction. Database state variables may be defined at least based on the transaction set and the transaction order value set.

[0036] In some embodiments, a method includes receiving a first event from an instance of a distributed database at a first computing device in a set of computing devices, the set of computing devices implementing the distributed database via a network operatively coupled to the set of computing devices. The method also includes defining a third event based on the first and second events. The third event is linked to a set of events. A sequence value may be defined for a fourth event based at least in part on a collective equity value associated with the set of events that satisfies an equity value criterion. The sequence value may be stored in an instance of the distributed database at a second computing device in the set of computing devices. In some embodiments, the method also includes calculating a collective equity value based on the sum of a set of equity values. Each equity value in the set of equity values ​​is associated with an instance of the distributed database that defines the events in the set of events.

[0037] In some embodiments, a method includes receiving a first event from an instance of a distributed database at a first computing device in a set of computing devices, the set of computing devices implementing the distributed database via a network operatively coupled to the set of computing devices. The method also includes defining a third event based on the first event and a second event, and determining a first event set at least in part based on the third event. Each event in the first event set a) is identified by a second event set and b) is associated with a first round number. Collective stake values ​​associated with the second event set satisfy a first stake value criterion, and each event in the second event set (1) is defined by a different instance of the distributed database and (2) is identified by the third event. The round number of the third event can be calculated based on determining that the sum of stake values ​​associated with each event in the first event set satisfies the second stake value criterion. The round number of the first event corresponds to a second round number greater than the first round number. The method also includes determining a third event set based on the third event. Each event in the third event set a) is identified by a fourth event set including the third event and b) originates from the first event set. Each event in the fourth event set is defined by a different instance of the distributed database, and the collective stake value associated with the fourth event set satisfies the third stake value criterion. Then, an order value is defined for the fourth event based on the collective stake value associated with the third event set that satisfies the fourth stake value criterion, and this order value can be stored in an instance of the distributed database at the second computing device.

[0038] In some embodiments, the equity value set includes (1) equity values ​​associated with each instance of the distributed database that defines the events in the second event set and (2) equity values ​​proportional to the amount of cryptocurrency associated with that instance of the distributed database. The collective equity value associated with the second event set is based on the sum of the equity values ​​in the equity value set.

[0039] In some embodiments, at least one of a first equity value standard, a second equity value standard, a third equity value standard, or a fourth equity value standard is defined based on the collective equity value of the distributed database. Furthermore, in some embodiments, the set of computing devices of the distributed database is associated with a set of trusted entities at a first time, and at a second time after the first time, the set of computing devices of the distributed database is associated with a set of entities including entities not from the set of trusted entities.

[0040] 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 can include, for example, memory, processor, electrical traces, optical connectors, software (executed in hardware), and so on.

[0041] 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.

[0042] Figure 1 This is a high-level block diagram illustrating a distributed database system 100 according to an embodiment. Figure 1 A distributed database 100 implemented across four computing devices (computing device 110, computing device 120, computing device 130, and computing device 140) is shown; however, it should be understood that the distributed database 100 can use devices including... Figure 1 A collection of any number of computing devices not shown. 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. Figure 1 As shown, for example, a connection can be defined between computing device 110 and any one of computing device 120, computing device 130 or computing device 140.

[0043] 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 networks and / or alternative networks can be networks of the same type and / or different type from network 105.

[0044] 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 1 As shown in the diagram. 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), 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 for causing the processor to perform 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), records of previous synchronization events with other computing devices, the order of synchronization events, and values ​​of parameters (e.g., database fields quantifying transactions, database fields quantifying the order in which events occur, and / or values ​​that may be for any other suitable fields stored in the database).

[0045] 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 relational database, object database, post-relational database, and / or any other suitable type of database. 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) that include 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 of which is associated with a vector of values. The vector of values ​​is used to determine the actual values ​​of the parameters and / or fields within the database instance 114.

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

[0047] In some cases, it is possible to query any of the distributed database systems 100 or distributed database instances 114, 124, 134, and 144. For example, the query may include a key, and the result returned from the distributed database system 100 or distributed database instances 114, 124, 134, and 144 may be the value associated with that key. In some cases, any of the distributed database systems 100 or 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.

[0048] 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 as a "key" and a list of attributes associated with the user as "values." In some cases, the identity can be a cryptographic public key, and the corresponding private key is known to the user. Each attribute can be digitally signed, for example, by an authorized party authorized to assert that attribute. Each attribute can also be encrypted, for example, 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 or delete the keys or values.

[0049] 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 game 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 that computing device. Figure 1 (Not shown in the image).

[0050] 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 for updating distributed database instance 114 in response to receiving a synchronization event associated with a transaction from another computing device, a record associated with the order of the synchronization event, etc. In other embodiments, processor 111 can be configured to execute modules, functions, and / or procedures to update distributed database instance 114 in response to receiving values ​​of parameters stored in another instance of the distributed database (e.g., distributed database instance 124 at computing device 120), and / or to send values ​​of parameters 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), a digital signal processor (DSP), and so on.

[0051] 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, as an alternative to or in addition to displays 113, 123, 133, 143, any of computing devices 110, 120, 130, 140 may include another output device. For example, any of computing devices 110, 120, 130, 140 may include an audio output device (e.g., a speaker), a haptic output device, etc. In still other embodiments, as an alternative to or in addition to displays 113, 123, 133, 143, any of computing devices 110, 120, 130, 140 may include an input device. For example, any of computing devices 110, 120, 130, 140 may include a keyboard, a mouse, etc.

[0052] 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.

[0053] 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, memory 112, and display 113, respectively. Furthermore, the distributed database instance 134 may be structurally and / or functionally similar to the distributed database instance 114.

[0054] 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, memory 112, and display 113, respectively. Furthermore, the distributed database instance 144 may be structurally and / or functionally similar to the distributed database instance 114.

[0055] 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 may 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 may be a desktop computer, computing device 120 may be a smartphone, and computing device 130 may be a server.

[0056] 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 ).

[0057] 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 collectively by the users of the distributed database system 100.

[0058] Because a distributed database system 100 is used, no leader is designated among computing devices 110, 120, 130, and 140. Specifically, none of the computing devices 110, 120, 130, or 140 is identified and / or selected as the leader to resolve disputes between values ​​stored in the distributed database instances 111, 12, 131, and 141 of the computing devices 110, 120, 130, and 140. Alternatively, the computing devices 110, 120, 130, and 140 can converge collectively on the values ​​of the parameters by using the event synchronization process, voting process, and / or methods described herein.

[0059] 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 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 to other distributed database instances. However, in a leaderless system, there is no single point of attack and / or failure. Specifically, if a parameter in a distributed database instance 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 convergence speed while reducing the amount of data sent between devices, as described further in this document.

[0060] Figure 2 A computing device 200 is shown as 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 similar 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 convergence 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 and / or receive data from other computing devices). 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, wired ports, etc. Thus, communication module 210 can establish and / or maintain communication between computing device 200 and another device (e.g., via a network interface controller (NIC), wireless connectivity, wired ports, etc.). Figure 1 The communication module 210 enables the computing device 200 to send data to and / or receive data from another device. This communication session can be conducted via a network such as Network 105 or the Internet (not shown).

[0061] In some cases, the database convergence module 211 can exchange events and / or transactions with other computing devices, store the events and / or transactions received by the database convergence module 211, and calculate the order of events and / or transactions based on a partial order defined by a reference pattern between events. Each event can be a record containing cryptographic hashes of two earlier events (linking the event to those 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, a timestamp (e.g., date and UTC time) declaring that the event was first defined by its creator, etc. 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 a previous self-hash (e.g., the hash of an event previously defined by that member). In some cases, the first event in the distributed database does not contain the hash of any previous events (because there are no previous events in the distributed database).

[0062] 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., bytes representing a specific part of the event, identifiers, sequence numbers, 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 for each member for a given event. The event can then be digitally signed by the member who defined and / or created the event.

[0063] In some cases, sets of events and their interconnections can form a directed acyclic graph (DAG). In some cases, each event in the DAG references two earlier events (linking the event to those two earlier events and their ancestor events, and vice versa), and each reference is strictly limited to the earlier event, such that there are no cycles. In some embodiments, since the DAG is based on cryptographic hashes, the data structure can be called a hashDAG. A hashDAG directly encodes the partial order, meaning that if Y contains the hash of X, or if Y contains the hash of an event that includes the hash of X, or for any path of such length, it is known that event X arrived before event Y. However, if there is no path from X to Y or from Y to X, the partial order does not define which event arrived first. Therefore, the database convergence module can compute the overall order based on the partial order. 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 recompile the order after each synchronization, and eventually these orders can converge to achieve consensus.

[0064] Consensus algorithms can be used to determine the order of events in a hashDAG and / or the order of transactions stored within events. As a result of executing these transactions in that order, the transaction order itself can define the state of the database. This defined database state can then be stored as database state variables.

[0065] In some cases, the database convergence module can use the following function to calculate the overall order based on the partial order in the hashDAG. For each of the other computing devices (called "members"), the database convergence module can examine the hashDAG to find the order of events (and / or indications of those events) received by that member. The database convergence module can then perform a calculation as if the member had assigned a numerical "rank" to each event, where the rank for the first event received by the member is 1, the rank for the second event received by the member is 2, and so on. The database convergence module can perform this operation for each member in the hashDAG. Then, for each event, the database convergence module can calculate 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 some other method for sorting two tied events, where the database convergence module for each member uses the same method. The result of this sorting is the overall order.

[0066] Figure 6A hashDAG 640 is shown as an example used to determine the overall order. HashDAG 640 shows two events (the lowest striped circle and the lowest dashed circle), and the first time each member receives indications of these events (the other striped and dashed circles). The names of each member at the top are colored according to which event occurred first in their slow order. The initial votes for the striped events are more numerous than those for the dashed events, so each member's consensus vote is striped. In other words, these members eventually converge to a protocol where the striped events occur before the dashed events.

[0067] In this example, the members (computing devices labeled Alice, Bob, Carol, Dave, and Ed) will work to reach a consensus on whether event 642 or event 644 occurred first. Each striped circle indicates the event in which a member first received event 644 (and / or an indication of event 644). Similarly, each dashed circle indicates the event in which a member first received event 642 (and / or an indication of event 642). As shown in hashDAG 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.

[0068] In other instances, the database convergence module can use different functions to calculate the overall order based on the partial order in the hashDAG. In such an embodiment, for example, the database convergence module can use the following function to calculate the overall order, where the positive integer Q is a parameter shared by the members.

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

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

[0071] other(x) = Events created by members synchronized just before x was created.

[0072] self(x) = the last event before x that has the same creator.

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

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

[0075] order(x,y) = k, where y is the k-th event known to creator(x).

[0076] last(x) =

[0077]

[0078] fast(x,y) = the position of element y in the sorted list. pass The events are sorted and ties are broken by the hash of each event.

[0079] In this embodiment, essentially immediately following the creation and / or definition of x, 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 above calculates the same overall order as in the previous embodiment. If Q is finite and all members are online, the above calculates the same overall order 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 that remains unchanged as new members slowly come online one by one. However, if there are partitions in the network, then members of each partition can reach their own consensus. Then, when the partitions are restored, members of the smaller partition will adopt the consensus of the larger partition.

[0080] In other instances, such as regarding Figures 14-17b As described, the database convergence module can use different functions to calculate the overall order based on the partial order in the hashDAG. For example... Figures 14-15 As shown, each member (Alice, Bob, Carol, Dave, and Ed) creates and / or defines events (such as...). Figure 14 As shown in 1401-1413; Figure 15 (As shown in 1501-1506). By using about Figures 14-17bThe functions and subfunctions described herein allow the overall order of events to be calculated by sorting the events according to their receiving rounds (also referred to herein as order values), breaking ties by their receiving timestamps, and breaking those ties by their signatures, as described further in detail herein. In other cases, the overall order of events can be calculated by sorting the 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... Figures 14-17b Used and shown.

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

[0082] "Ancestor": The ancestors of event X are X, X's father, X's father's father, and so on. For example, in Figure 14 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.

[0083] "Descendants": The descendants of event X are X, X's children, X's children's children, and so on. For example, in Figure 14 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.

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

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

[0086] "Self-parent": The self-parent of event X is the parent event Y of X, which is created and / or defined by the same member. For example, inFigure 14 In the story, the father of event 1405 is 1401.

[0087] "Self-ancestor": The self-ancestor of event X is X, the self-father of X, the self-father of X's self-father, and so on.

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

[0089] "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 14 In this context, event 1412 has two parents: events 1406 and 1408, which have generation numbers 4 and 2 respectively. Therefore, the generation number of event 1412 is 5 (i.e., 4 plus 1).

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

[0091] "Round Number" (or "RN"): An integer property of the event. In some cases, the round number can be defined as the maximum round number of the event's parent plus the round increment of the event. For example, in... Figure 14 In the example, event 1412 has two parents: events 1406 and 1408, both of which have round number 1. Event 1412 also has a round increment of 1. Therefore, the round number of event 1412 is 2 (i.e., 1 plus 1). In other instances, if R is the smallest integer, an event can have a round number R such that the event strongly sees (as described in this paper) at least M events defined and / or created by different members, all of which have round numbers 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 14 In this context, if M is defined as the smallest integer greater than half a multiple of N, then M is three. Event 1412 strongly sees M events 1401, 1402, and 1408, each defined by a different member and having round number 1. Event 1412 does not strongly see at least M events defined by different members and having round number 2. Therefore, the round number of event 1412 is 2. In some cases, the first event in a distributed database includes round number 1. In other cases, the first event in a distributed database may include round number 0 or any other suitable number.

[0092] "Forking": If event X and event Y are defined and / or created by the same member, and neither event X nor event Y is a self-ancestor of the other, then event X is a fork of event Y. For example, in Figure 15 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.

[0093] "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 15 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.

[0094] Event “Identification”: If X has no ancestor event Z that branches off from Y, then event X “identifies” or “sees” its ancestor event Y. For example, in Figure 14 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 made after event Y by the member that defines event Y, event X can see event Y. Event X does not recognize events after that member's 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 does not recognize any events of that member.

[0095] "Strongly identified" (also referred to as "strongly seen" in this text) 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 an event set S that (1) includes both X and Y and (2) is an ancestor of event X and (3) is a descendant of ancestor event Y and (4) is identified by X and (5) can each identify Y and (6) is created and / or defined by at least M different 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 14In 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), where each of the at least M events can see Y, then event X (e.g., event 1412) can "strongly see" event Y (e.g., event 1401).

[0096] "R-round first" event (also referred to as "witness" in this text): An event is "R-round 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 14 In the event, event 1412 is the "second round first" event because it has a round number of 2, and its parent is event 1408, which has a round number of 1 (i.e., less than two).

[0097] In some cases, the round increment of event X is defined as 1 if and only if X “strongly identifies” at least M “R-round first” events, where R is the largest round number of its parent. For example, in Figure 14 In 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 are round-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 increment is 0.

[0098] In some cases, the following method can be used to determine whether an event X strongly recognizes its ancestor event Y. For each R round of the first ancestor event Y, maintain an integer array A1, where each member is an integer, giving the lowest sequence number where that member creates and / or defines event X and X can recognize Y. For each event Z, maintain an integer array A2, where each member is an integer, 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, count the number of element positions E 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 14 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, 1}. Similarly, the most recent events identified by event 1412 for each of them are events {NONE, 1406, 1402, 1401, 1412}, where Alice is listed as "NONE" because 1412 cannot identify any events 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 events 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}, which has four values ​​of true. Therefore, there exists a set S of four events that are ancestors of 1412 and descendants of 1401. 4 is at least M, therefore 1412 strongly identifies 1401.

[0099] 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 and pack 8 such elements into a single 64-bit word, making A1 and A2 arrays of these 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, Java, etc. In other cases, the calculations can be performed using processor-specific instructions, such as Advanced Vector Extensions (AVX) instructions provided by Intel and AMD, or 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 bits, 256 bits, 512 bits, or more).

[0100] "Notable" event: Event X is "notable" if (1) it is the "R-round first" event (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 convergence module (e.g., database convergence module 211). For example, in Figure 14The 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. If the protocol runs longer, the hashDAG will grow upwards, and eventually the other four members will also have round 2 firsts at the top of the graph. Each round 2 first will have a "vote" regarding whether each of the round 1 firsts is "famous". Event 1412 will have a "yes" vote for 1401, 1402, and 1403 being famous, because these are round 1 firsts it can recognize. Event 1412 will have a "no" vote for 1404 being famous, because 1412 cannot recognize 1404. For a given round 1 first, such as 1402, its state of being "famous" will be determined by calculating the votes for whether it is "famous" in each round 2 first. These votes will then propagate to the 3rd round first, then to the 4th round first, and so on, until a final consensus is reached on whether 1402 is famous. The same process is repeated for the other firsts.

[0101] The Byzantine consensus protocol can collect and use votes and / or decisions from the "R-round first" event to identify "notable" events. For example, if "R+1-round first" Y can "identify" event X, then Y will vote "yes"; 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. Some of these rounds can be "majority" rounds, while others can be "coin" rounds. In some cases, for example, round R+2 is a majority round, and future rounds (e.g., according to a predefined schedule) are designated as either majority rounds or coin rounds. For example, in some cases, whether a future round is a majority round or a coin round can be arbitrarily determined, provided that there cannot be two consecutive coin rounds. For example, it might be predefined that there will be five majority rounds, then one coin round, then five majority rounds, then one coin round, and this process repeats until consensus is reached.

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

[0103] Similarly, if X is a witness in round R (or the 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 of votes they can strongly see from the witnesses in round R+1. Similarly, in round R+3, each witness votes based on the majority of votes they can strongly see from the witnesses in round R+2. 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 at least M witnesses vote "no" in any round, the election ends, and X is not famous. If at least M witnesses vote "yes" in any round, the election ends, and X is famous. If neither "yes" nor "no" has at least M votes, the election continues to the next round.

[0104] As an example, in Figure 14 Consider event X in a round 1 as shown in the diagram below. Then, each round 1 first event will vote on whether X is significant. Event 1412 can be strongly identified as round 1 first 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 as "yes," and consensus has been achieved. If at least M of them vote "no," it is decided as "no," and consensus has been achieved. If no more than M votes are cast in either direction, 1412 is given a vote as a majority of the votes for 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.

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

[0106] Similarly, in this scenario, if the election reaches round R+K (the coin round), 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 does not end in that round. If the election reaches this round, it can continue for at least one more round. In this 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 in round R+K-1 voting for V. 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.

[0107] For example, in Figure 14 In the process, if wheel 2 is a coin wheel and the voting is about whether an event prior to wheel 1 is well-known, then event 1412 will first check whether at least M votes in {1401, 1402, 1408} are "yes" or whether 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 a random vote or a pseudo-random vote (e.g., based on the least significant bit of the digital signature created by Ed for event 1412 when Ed created and / or defined the event 1412).

[0108] In some cases, the result of pseudo-random determination can be the result of a cryptographic sharing coin protocol, which can be implemented, for example, as the least significant bit of a threshold signature of a round number.

[0109] The system can be constructed using any of the methods described above for calculating pseudo-randomly determined results. 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.

[0110] "Receive Round": Event X has a "Receive Round" R if R is the smallest integer such that at least half of the well-known R-round first events (or well-known witnesses) 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 instance, event X has a "Receive Round" R if R is the smallest integer such that at least a predetermined percentage (e.g., 40%, 60%, 80%, etc.) of the well-known R-round first events (or well-known witnesses) with round number R are descendants of X and / or can see X.

[0111] In some cases, the "receiving generation" of event X can be calculated as follows: Identify which member created and / or defined the first event of every R rounds 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.

[0112] In some cases, the "receive timestamp" T of event X can be the median of timestamps in the events that include each member's identification and / or the first event in which X is 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 timestamps in the events that include each member's identification or the first event in which X is seen. For example, the receive timestamp of X can be based on the average of timestamps, the standard deviation of timestamps, a modified average (e.g., by removing the oldest and most recent timestamps from the calculation), and so on. In other cases, an extended median can be used.

[0113] In some cases, the overall order and / or consensus order of events is calculated by sorting events by their reception rounds (also referred to herein as order values), 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 paragraphs above specify the functions used to calculate and / or define the reception rounds, reception timestamps, and / or reception generations of events.

[0114] In other cases, as an alternative to using the signature of each event, the signature of the event can be XORed with the signatures of prominent events or prominent witnesses in that round who have the same receiving round and / or receiving generation. In still other cases, any other suitable combination of event signatures can be used to break a tie to define the consensus order of events.

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

[0116] 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 each member's identification and / or the first event to see X. For example, in... Figure 14 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 a predetermined first or second of two middle timestamps, if they have an even length) 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.

[0117] In other cases, a "truncated extended median" can be used instead of an "extended median". In this case, a complete list of timestamps for each event is not stored. Instead, only some values ​​from the middle of the list are stored and used for comparison.

[0118] 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 in which Alice signs the same contract, where the received timestamp of X is on or before a certain deadline. In this case, as described above, if Alice signs the contract after the deadline, as indicated by the "received median timestamp," Bob will not be bound by the contract.

[0119] 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 visible to a known witness in R rounds, then eventually all events in S(R) will have a known receiving round and 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, members can compute hash values ​​of the events in S(R) according to their consensus order. Members can then digitally sign the hash values ​​and include them 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 thus agree on the order represented by the hash value), this consensus list of events and the list of members' signatures can form a single file (or other data structure) that can be used to prove that the consensus order is as declared in the events in S(R). In other cases, if the event contains a transaction that updates the state of the distributed database system (as described in this paper), the hash value may have the state of the distributed database system after the transaction in which the events in S(R) are applied in consensus order.

[0120] In some cases, M (as described above) can be based on the weight value assigned to each member (also referred to as the stake value in this paper), rather than simply a portion, percentage, and / or value of the total number of members. In this case, each member has a stake associated with its interests and / or influence in the distributed database system. Such a stake can be a weight value and / or a stake value. Each event defined by the member can be referred to as the weight value of the member who defined it. M can then be a portion of the total stake of all members and can be referred to as a stake value criterion and / or threshold. The events described above as dependent on M will occur when the set of members with a total stake of at least M agrees (i.e., the stake value criterion is met). Therefore, based on their stakes, 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 stakes of one or more members, add new members, and / or delete members. If such a transaction has a receiving round 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 stakes and the modified member list. In some cases, the old equity and member list can be used for voting on whether a round R event is famous, but the new equity and member list can be used for voting on rounds after R.

[0121] In some cases, a predetermined weight or stake value can be assigned to each member of the distributed database system. Therefore, consensus reached via a Byzantine consensus protocol can be implemented with associated security levels to protect member groups or communities from potential Sybil attacks. In some cases, this security level can be mathematically guaranteed. For example, an attacker might want to influence the outcome of one or more events by reordering a portion of the events registered in a hashDAG. An attack can be carried out by reordering one or more portions of a hashDAG before consensus and / or eventual agreement is reached among the members of the distributed database. In some cases, the timing of multiple competing events may be disputed. As discussed above, the outcome associated with an event can depend on the value of M. Therefore, in some cases, when the number of votes or the total stake of the consensus voting members is greater than or equal to the value of M, it can be determined whether Alice or Bob should take action first on the event (and / or the transactions within the event).

[0122] Some types of event reordering attacks require the attacker to control at least a portion or percentage of N (e.g., 1 / 10, 1 / 4, 1 / 3, etc.), depending on the value of M. In some cases, the value of M can be configured to, for example, 2 / 3 of a group or population N. In this case, as long as more than 2 / 3 of the members of the group or population are not participants in the attack, consensus can be reached by members who are not part of the attack, and the distributed database will continue to reach consensus and operate as expected. Furthermore, in this case, the attacker will have to control at least N minus M (NM) members of the group or population during the attack period (1 / 3 of the members in this example) to prevent database convergence, thereby causing the distributed database to converge in a way that favors the attacker (e.g., causing the database to converge in an unfair order), converge to two distinct states (e.g., causing members to formally agree on two contradictory states), or fabricate a cryptocurrency (when the distributed database system operates with a cryptocurrency).

[0123] In some implementations, weights or stakes can be assigned to each member of a group or cluster, and N will be the sum of all their weights or stakes. Therefore, higher weight or stake values ​​can be assigned to subsets of the group or cluster based on trust or reliability. For example, higher weight or stake values ​​can be assigned to members who are less likely to engage in attacks or who have indicators showing they are not inclined to engage in dishonest behavior.

[0124] In some cases, the security level of a distributed database system can be increased by choosing M as a larger fraction of N. For example, when M corresponds to the smallest integer greater than 2 / 3 of the number of members N in a group or community, and all members have equal voting power, an attacker would need to control or influence at least 1 / 3 of N to prevent consensus among non-attacker members and thus prevent the distributed database from reaching consensus. Similarly, in this case, an attacker would need to control or influence at least 1 / 3 of more than N to make the distributed database system converge and / or reach consensus in a manner favorable to the attacker (e.g., causing the database to converge in an unfair order), converge to two distinct states (e.g., causing members to formally agree on two contradictory states), or fabricate cryptocurrencies (when the distributed database system operates with cryptocurrencies).

[0125] In some cases, such as when dishonest members vote in two different ways, the distributed database may converge to two different states. For example, if N = 300 and 100 members are dishonest, there are 200 honest members, of whom, for example, 100 vote "yes" for a transaction and 100 vote "no". If the 100 dishonest members send a message (or event) to the 100 honest "yes" voters that they voted "yes", the 100 honest "yes" voters will consider the final consensus to be "yes" because they will believe that 2 / 3 of the members voted "yes". Similarly, if the 100 dishonest members send a message (or event) to the 100 honest "no" voters that they voted "no", the 100 honest "no" voters will consider the final consensus to be "no" because they will believe that 2 / 3 of the members voted "no". Therefore, in this scenario, some honest members will agree on "yes," while others will agree on "no," causing the distributed database to converge to two distinct states. However, if the number of dishonest members is less than 100, then the honest members will eventually converge to a single value ("yes" or "no"), because dishonest members will not be able to push both "yes" and "no" votes to exceed 200 (i.e., 2 / 3 of N). Other suitable values ​​for M can be used depending on the specifications and / or specific requirements of the distributed database system application.

[0126] In some other cases, when members have unequal voting power—for example, when the most reliable or trusted voter has one unit of voting power (e.g., a weight value or stake value), while the remaining members have a fraction of a unit of voting power—a consensus can be reached when the total stake or weight reaches a value M. Therefore, in some cases, consensus can sometimes be reached even if a majority of members disagree with the final decision, but a majority of reliable or trusted members agree. In other words, the voting power of untrusted members can be reduced to prevent or mitigate potential attacks. Thus, in some cases, a level of security can be increased by requiring consensus from members with a total stake of M, rather than simply a count of M members. A higher value of M means that a larger portion of the stake (e.g., more members in an unweighted system) must agree for the distributed database system to converge.

[0127] In some cases, distributed database systems can support multiple participation security protocols, including but not limited to the protocols shown in Table 1 and any combinations thereof. The protocols shown in Table 1 describe various techniques for assigning interests or weights to members of a group or community. The protocols in Table 1 can be implemented using cryptocurrencies, such as derivatives of native cryptocurrencies, cryptocurrencies defined within the distributed database system, or any other suitable type of cryptocurrency. While cryptocurrencies are described, in other cases, the protocols shown in Table 1 can be used in any other suitable distributed database system, and in conjunction with any other methods for assigning interests.

[0128] Table 1

[0129]

[0130] The choice between engagement-based security protocols can depend on the specific application. For example, hybrid protocols can be suitable for temporary, low-value transactions, business collaboration applications, computer games, and other similar applications where a trade-off between security and minimal computational cost leans towards the latter. Hybrid protocols can effectively prevent a single disgruntled member from interfering with or attacking a group of members.

[0131] For another example, permissioned protocols might be desirable when security requirements are of the highest priority and group members are not complete strangers or unknowns. Permissioned protocols can be used to implement applications involving, for example, banks and similar financial entities or entities bound in a consortium. In this case, banks in the consortium can be members of the group, and each bank can be restricted to participating as a single member. Therefore, M can be set as the smallest integer exceeding two-thirds of the group. As individual entities, banks may not trust each other, but can rely on a security level provided by a distributed database system that, in this example, limits the number of dishonest members to no more than one-third of the banks in the group.

[0132] In another example, when the group includes a large number of strangers or unknown members, a burn proof protocol can be implemented. In this case, an attacker might be able to gain control over a portion of the total equity exceeding the value given to M. However, the entry fee can be set high enough that the cost of the attack outweighs any expected gains or profits.

[0133] For another example, proof-of-stake protocols can be applicable to larger groups. When there is a large group of members who own a significant amount of cryptocurrency in roughly equal shares, and it is unforeseen or possible that a disruptive member will acquire a larger amount of cryptocurrency than is collectively owned by that large group, a proof-of-stake protocol may be the optimal or ideal solution.

[0134] In other cases, further or more complex protocols can be derived from the protocols or combinations of protocols shown in Table 1. For example, a distributed database system can be configured to implement a hybrid protocol that follows a permissioned agreement for a predetermined period of time and ultimately allows members to sell voting rights to each other. As another example, a distributed database system can be configured to implement a proof-of-stake protocol and ultimately transition to a proof-of-stake protocol once the value of an event or the transaction involved reaches a threshold or a predetermined cryptocurrency value.

[0135] The preceding terms, definitions, and algorithms are used to illustrate Figure 14-17b The embodiments and concepts described herein. Figure 16a and Figure 16b This section presents a first example application of consensus methods and / or processes, illustrated in mathematical form. Figure 17a and Figure 17b A second example application of consensus methods and / or processes, presented in mathematical form, is shown.

[0136] In other cases, and as further described in detail herein, the database convergence module 211 may initially define a vector of parameter values ​​and may update the vector of values ​​as it receives additional values ​​for the parameters from other computing devices. For example, the database convergence module 211 may receive additional values ​​for the parameters from other computing devices via the communication module 212. In some cases, the database convergence module may select parameter values ​​based on the defined and / or updated vector of values ​​for the parameters, as further described in detail herein. In some embodiments, the database convergence module 211 may also transmit parameter values ​​to other computing devices via the communication module 212, as further described in detail herein.

[0137] In some embodiments, the database convergence module 211 may send a signal to the memory 220 to store in the memory 220 a vector of (1) the defined and / or updated values ​​of the parameters, and / or (2) the values ​​of the parameters selected based on the vector of the defined and / or updated values ​​of the parameters. For example, the vector of (1) the defined and / or updated values ​​of the parameters and / or (2) the values ​​of the parameters selected based on the vector of the defined and / or updated values ​​of the parameters may be stored in a distributed database instance 221 implemented in the memory 220. In some embodiments, the distributed database instance 221 may be similar to Figure 1 The distributed database instances 114, 124, 134, and 144 of the distributed database system 100 shown are illustrated.

[0138] exist Figure 2 In the middle, the database convergence module 211 and the communication module 212 are in Figure 2 The database convergence module 211 and / or communication module 212 are shown to be implemented in processor 210. In other embodiments, the database convergence module 211 and / or communication module 212 may be implemented in memory 220. In still other embodiments, the database convergence module 211 and / or communication module 212 may be hardware-based (e.g., ASIC, FPGA, etc.).

[0139] Figure 7A signal flow diagram of two computing device synchronization events according to an embodiment is shown. Specifically, in some embodiments, distributed database instances 703 and 803 may exchange events to achieve convergence. Computing device 700 may randomly select to synchronize with computing device 800 based on its relationship with computing device 700, its proximity to computing device 700, or an ordered list associated with computing device 700. In some embodiments, since computing device 800 may be selected by computing device 700 from a set of computing devices belonging to the distributed database system, computing device 700 may select computing device 800 multiple times consecutively or may not select computing device 800 for a period of time. In other embodiments, an indication of a previously selected computing device may be stored at computing device 700. In such embodiments, computing device 700 may 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 may be implemented in the memory of computing device 700 and the memory of computing device 800, respectively.

[0140] Figures 3-6 An example of a hashDAG according to an embodiment is shown. 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 (a thick line to the same member and a thin line to another member) in addition to the first event of each member. Time progresses upwards. Figures 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 The computing devices 110, 120, 130 and 140 shown and described.

[0141] 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 in the image, synchronization between Alice and Bob can be achieved as follows:

[0142] Alice sends an event stored in distributed database 703 to Bob.

[0143] - Bob creates and / or defines a new event that includes:

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

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

[0146] -- Bob's digital signature on the above content

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

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

[0149] Alice sends the event to Bob.

[0150] Alice calculates the total order of events based on the hashDAG.

[0151] Bob calculates the total order of events based on the hashDAG.

[0152] 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 show a vertical line for each member and points on that line for each event created and / or defined by that member. Whenever an event (the higher point) contains the hash of an earlier event (the lower point), a diagonal line is drawn between the two points. If an event can reference another event via its hash (directly or through an intermediary event), then that event can be said to be linked to that other event.

[0153] For example, Figure 3An example of hashDAG 600 is shown. Event 602 is created and / or defined by Bob as a result of and after Bob's synchronization with Carol. Event 602 includes the hash of event 604 (a previous event created and / or defined by Bob) and the hash of event 606 (a previous event created and / or defined by Carol). In some embodiments, for example, the hash of event 604 included within event 602 includes pointers to its direct ancestor events, namely events 608 and 610. Thus, Bob can use event 602 to reference events 608 and 610, and use the pointers to previous events to reconstruct the hashDAG. In some instances, event 602 may be referred to as being linked to other events in hashDAG 600, because event 602 can reference each event in hashDAG 600 via earlier ancestor events. For example, event 602 is linked to event 608 via event 604. For example, event 602 is linked to event 616 via events 606 and 612.

[0154] Example System 2: A system derived from Example System 1, where events also include a "payload" or other information about the transactions to be recorded. 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 previous event on the computing device. For example, event 602 could include any transactions executed by Bob since event 604 was created and / or defined. Therefore, Bob could share this information when synchronizing event 602 with other computing devices. Accordingly, transactions executed by Bob could be associated with the event and shared with other members using the event.

[0155] Example System 3: A system derived from Example System 1, wherein the events also include the current time and / or date useful 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 exchanging events). In still other embodiments, a global timer may be used to determine the time and / or date.

[0156] Example System 4: A system from Example System 1, where Alice neither sends Bob events created and / or defined by Bob, nor 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 an ancestor of x. Similarly, in such an embodiment, Bob sends Alice events that have not yet been stored by Alice, and does not send events that have already been stored by Alice.

[0157] For example, Figure 4 Example hashDAG 620 is shown, illustrating the ancestor events (dashed circles) and descendant events (striped circles) of event 622 (black circle). The line segments establish a partial order of events, where ancestors appear before black events and descendants appear after black events. This partial order does not indicate whether white events precede or follow black events; therefore, the overall order is used to determine their sequence. For another example, Figure 5 Example hashDAG is shown, illustrating a specific event (solid circle) and the first moment each member receives the 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 stored in Carol's distributed database instance. In some embodiments, Dave may identify events to send to Carol based on what Dave's hashDAG 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 that was 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 hashDAG 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 events that Carol has received, and Dave can identify events to send to Carol.

[0158] Example System 5: A system derived from Example System 1, where 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 its ancestor. Therefore, the sender sends events from oldest to newest, allowing the receiver to examine the two hashes of each event upon receipt by comparing them to the two ancestor events already received. The sender can identify the events to send to the receiver based on the current state of the sender's hashDAG (e.g., a database state variable defined by the sender) and what that hashDAG indicates the receiver has already received. Reference 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 the event and its ancestors. Thus, Carol can first send events 618 and 616 to Bob (i.e., the oldest events Carol received that Bob hasn't yet received). Carol can then send event 612 to Bob and then event 606. This allows Bob to easily chain the events and reconstruct his hashDAG. Using Carol's hashDAG to identify events Bob hasn't yet received improves synchronization efficiency and reduces network traffic because Bob doesn't request events from Carol.

[0159] In other embodiments, the most recent event may be sent first. If the receiver (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) determines that it has not yet received one of the two previous events, the receiver may request the sender to send such an event. This can continue until the receiver has received and / or stored the ancestor of the most recent event. (See also...) Figure 3 In 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. When Bob creates and / or defines event 604, he can determine that event 614 was previously received from Alice. Therefore, Bob does not need to request event 614 from Carol. Bob can also determine that event 612 has not yet been received. Bob can then request event 612 from Carol. 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.

[0160] Example System 6: A system derived from Example System 5 with an additional constraint: when a member has the option to choose among several events to send next, they must select the event that minimizes the total number of bytes sent so far by that member, which they have created and / or defined. For example, if Alice has only two events left 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 already 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 huge event or a large number of small events. In cases where traffic exceeds the byte limits of most members (as discussed with regard to Example System 7), the approach of Example System 6 ensures that attacker events are ignored, rather than legitimate user events. Similarly, attacks can be mitigated by sending smaller events before larger ones (to prevent a single huge event from consuming the connection). 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, instead of only sending events defined and / or created by the attacker and not sending (a few) events created and / or defined by other members.

[0161] Example System 7: A system derived from Example System 1, with an additional first step in which Bob sends Alice a number indicating the maximum number of bytes he is willing to receive during the synchronization, and Alice replies with her limit. When the next event will exceed this limit, Alice then stops sending. Bob does the same. In such an embodiment, this limits the number of bytes transmitted. This may increase convergence time, but will reduce the amount of network traffic per synchronization.

[0162] Example System 8: A system from Example System 1, where the following steps are added at the start of the synchronization process:

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

[0164] Alice identifies the members who create and / or define each event in S and sends Bob a list of member IDs. Alice also sends several events that she has received and / or stored, created and / or defined by each member.

[0165] Bob responded with a list of the number of events he had received, created and / or defined by other members.

[0166] Alice then only sends Bob events that 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.

[0167] Example System 9: A system from Example System 1 with additional mechanisms for identifying and / or handling cheaters. Each event contains two hashes: one hash from the last event created and / or defined by the member (“self-hash”), and the other hash 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 he is a cheater but still synchronizes with him again and creates and / or defines a new event to record that fact, then Alice also becomes a cheater, and other members who know Alice is still synchronizing with Dave stop synchronizing with Alice. In some embodiments, this only affects synchronization to a certain extent. For example, when Alice sends the number of events she received for each member along with a list of identifiers, she does not send the cheater's ID or count, so Bob will not respond with any corresponding numbers. Alice then sends Bob the event she received, and she did not receive an indication that Bob had received such an event, indicating that the cheater was involved. After synchronization is complete, Bob will also be able to determine that Dave is the cheater (if he has not already identified Dave as a cheater), and Bob will refuse to synchronize with the cheater.

[0168] Example System 10: The system in Example System 9, where Alice begins the synchronization process by sending Bob a list of cheaters she has identified and who still stores their events, and Bob responds with any cheaters he has identified besides those identified by Alice. They then continue as usual, but without considering cheaters when synchronizing with each other.

[0169] Example System 11: The system in Example System 1, which has a process for repeatedly updating (e.g., captured by database state variables defined by members of the system) the current state 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 previous state and recalculating the current state by processing the events in the new order. In some embodiments, the current state is a state, balance, condition, etc., associated with the outcome of a transaction. Similarly, the state may include data structures and / or variables modified by a transaction. For example, if the transaction is a remittance between bank accounts, then 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 position associated with the game, the number of lives, acquired items, the state of the game, etc.

[0170] Example System 12: The system in Example System 11 is made faster by using "fast cloning" of an arrayList to maintain state (e.g., bank account balance, game state, etc.). A fast cloning arrayList is a data structure that works like an array but with an additional feature: it supports "cloning" operations, which appear to create and / or define a new object as a copy of the original. The clone behaves as if it were a true copy because changes to the clone do not affect the original. However, cloning is faster than creating a true 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" initially are simply pointers to the original ArrayList. However, as each is repeatedly modified, it grows into a large hash table storing the differences between itself and the original list. The clones themselves can be cloned, causing the data structure to expand into a tree of objects, where each object has 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.

[0171] Example System 13: The system in Example System 11 is made faster by using a "fast clone" hash table to maintain state (e.g., bank account balance, game state, etc.). It is identical to System 12 except that the root of the tree is a hash table instead of an arrayList.

[0172] Example System 14: The system in Example System 11 is made faster by using a “fast clone” relational database to maintain state (e.g., bank account balance, game state, etc.). This is an object that acts as a wrapper for 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 identical to 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 made with IDs 2 and 3. Each row in each table will have 1, 2, or 3 in the clone ID field. When a query from user code targets clone 2, the query is modified so that the query will only read from rows that have 2 or 1 in that field. Similarly, a read for 3 looks for rows with ID 3 or 1. If a Structured Query Language (SQL) command is passed to clone 2 and claims to delete a row with the ID 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 now only visible to clone 3. If several clones exist in the operation, 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, the tree can be simplified. The structure of this tree will be stored in an additional table that the clones cannot access, but is purely for internal use.

[0173] Example System 15: The system in Example System 11 is made faster by using a "Quick Clone" file system to maintain state. 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 Quick Clone relational database to manage different versions of the file system. The underlying file system 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 the database and is not provided to the host file system. When a file or directory is cloned, the "clone" is simply an object with an ID number, and the database is modified to reflect that the clone now exists. If the Quick 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, only one copy of each file or directory exists, and copying occurs when a file is modified through a clone.

[0174] Example System 16: The system in Example System 15, where 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 a suitable size, such as, for example, 4096 or 1024. In this way, if a byte is changed in a large file, only one block of that large file is copied and modified. This also improves efficiency when storing many files that differ by only a few bytes on the drive.

[0175] Example System 17: The system in Example System 11, where each member includes in some or all of the events they create and / or define a hash of the state at a previous time, and the number of events that occurred up to that point, thereby instructing the member to recognize and / or identify a consensus that exists regarding the order of events. After a member collects signed events containing such hashes of a given state from a majority of users, the member can then store it as a consensus state proof at that point and remove events and transactions prior to that point from memory.

[0176] Example System 18: The system in Example System 1, where the calculation of the median or majority vote is replaced by a weighted median or weighted majority vote, where members are weighted by their “stakes.” Stake is a number indicating how many votes a member has counted. Stake can be a stake held in the form of cryptocurrency, or simply an arbitrary number assigned when a member is first invited to join and then divided among new members invited by that member. When enough members have agreed on the consensus state, older stakes can be discarded, such that their total stake is a majority of the existing stake. If the total order is calculated using the median of the rankings of member contributions, 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 rankings below that weighted median and approximately half of the total stake is associated with rankings above that weighted median. Weighted voting and medians can be useful in preventing Sybil attacks, in which a member invites a large number of “alt accounts,” each of which 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 to attackers attempting to control the consensus outcome. Therefore, proof-of-stake can be useful in some situations.

[0177] Example System 19: The system in Example System 1, where 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, followed by several smaller databases or "blocks," each with a subset of members. When events occur within a block, they are synchronized among the members of that block, but 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.

[0178] Example System 20: A system like the one in Example System 11, capable of having events that update software used to update (e.g., captured by database state variables defined by the system's members) a state. For example, events X and Y could contain transactions that modify the state, and then update the state appropriately, depending on the software code that reads the transactions within these events. Event Z could then contain notification that a new version of the software is now available. If the overall sequence claims 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 could give different final states. Therefore, in such an embodiment, notification of upgrade code can occur within an event, allowing the community to reach a consensus on when to switch from the old version to the new version. This ensures that members will maintain a synchronized state. It also ensures that the system remains operational even during upgrades without requiring a reboot or restart of the process.

[0179] Example System 21: A system derived from Example System 1, where a proof-of-stake protocol is implemented to reach consensus and each member's voting power is proportional to the amount of cryptocurrency they own. The cryptocurrency in this example will be referred to as StakeCoin below. Membership in the group or community is open, not permissioned; therefore, there may be no trust between members.

[0180] Compared to other protocols (e.g., proof-of-work protocols), proof-of-stake protocols can be computationally cheaper. In this example, M (as described above) can be 2 / 3 of the amount of StakeCoin collectively owned by the members. Therefore, if an attacker cannot obtain 1 / 3 of the total StakeCoin owned by the participating members together, the distributed database system can be secure (and can converge as expected). As long as more than 2 / 3 of the StakeCoin is owned by honest, active members, the distributed database system can continue to operate at a mathematically guaranteed level of security. This allows the database to converge correctly.

[0181] An attacker can gain control of a distributed database system by individually negotiating with StakeCoin owners within the system to purchase their StakeCoin. For example, Alice could acquire a majority of StakeCoin by purchasing the StakeCoin owned by Bob, Carol, and Dave, thus putting Ed at a disadvantage. This is similar to monopolizing a market for a commodity or attempting to buy enough shares in a company for a hostile takeover. The described scenario represents not only an attack on the distributed database system using StakeCoin but also an attack on StakeCoin itself. If a member gains a near-monopoly over cryptocurrency, that member can manipulate the cryptocurrency's market value and repeatedly buy low and sell high. This might be profitable in the short term but ultimately undermines trust in the cryptocurrency and could lead to its widespread abandonment. The market value of a currency can be independent of the technology used to convey that currency. For example, if an individual or entity acquired ownership of the majority of US dollars in the world or the majority of corn futures in the world, such an individual or entity could potentially disrupt the market for profit.

[0182] If cryptocurrency is both valuable and widespread, then an attack by acquiring a near-monopoly of the cryptocurrency would be difficult. If cryptocurrency is valuable, then purchasing most of the StakeCoin supply would be extremely expensive. If cryptocurrency is widespread and many different people own StakeCoin, then attempts to monopolize the StakeCoin market would be seen early on, which would naturally drive up the price of StakeCoin, making it even more difficult to acquire the remaining supply.

[0183] A second type of attack can be carried out by acquiring a small amount of StakeCoin compared to the collective amount of StakeCoin across multiple distributed database systems, but larger than the amount of StakeCoin held by members participating in a specific distributed database system. This type of attack can be avoided when cryptocurrency is specifically defined for use in applications involving distributed database systems. In other words, the implementations of StakeCoin and distributed database systems can be defined simultaneously as being linked to each other, with each contributing to the value of the other. Similarly, there is no additional implementation of a distributed database that trades StakeCoins.

[0184] It might be desirable to have a valuable cryptocurrency from the outset when the implementation of the distributed database system is redefined. While a cryptocurrency can increase its value over time, a valuable cryptocurrency may be beneficial in the early stages of the system. In some cases, a consortium of participating entities can launch a cryptocurrency and its associated distributed database system. For example, ten well-known large companies or organizations as founders could be given a large amount of StakeCoin to launch the StakeCoin cryptocurrency and distributed database system. The system can be configured such that the supply of the cryptocurrency will not grow rapidly and will have some eventual size limit. Each founding entity can have an incentive to participate as a member in the implementation of the distributed database system and StakeCoin (e.g., implemented as a distributed database system that can be constructed as a hashDAG using a consensus algorithm). Since there is no proof-of-work, becoming a participating member running a node may not be expensive. The founding entities can be reliable enough that it is impossible for any majority of them to collude to destroy the system, especially since this would destroy the value of the StakeCoin they own and the implemented distributed database system.

[0185] In some implementations, other members can join the distributed database system, and other individuals or entities can purchase StakeCoin directly from the founding entity or on an exchange. The distributed database system can be configured to incentivize participation by paying a small amount of StakeCoin for participation. Over time, the system can become more distributed, and stake eventually diffuses, making it difficult for any individual or entity, even if the founding entity conspires to attack, to monopolize the market. At that point, the cryptocurrency can achieve independent value; the distributed database system can have an independent level of security; and the system can be open and permissionless (e.g., not requiring an invitation from founding members to join). This saves the recurring computational costs required by systems implemented with alternative protocols (e.g., systems implemented with proof-of-work protocols).

[0186] While the above description concerns the use of a hashDAG distributed database, example system 21 can be implemented using any other suitable distributed database protocol. For example, although the specific example numbers and stakes may change, example system 21 can be used to enhance the security of any suitable distributed database system.

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

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

[0189] 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 beforehand (in which case they know x precedes y), or it will be the case that synchronization provides that member with both x and y (in which case they will know x precedes 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

[0190] Example Theorem 2: For any given hashDAG, if x precedes y in a partial order, then x will precede y in the overall order computed for that hashDAG.

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

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

[0193] Here, rank(i,x) is the rank assigned to event x by member i. If x is the first event received by member i, then rank(i,x) is 1; if x is the second event, then rank(i,x) 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).

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

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

[0196] 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.

[0197] 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 ranking will be the median. Thus med(x) < med(y). If n is even, then when k = n / 2, the k-th smallest x ranking will be strictly less than the k-th smallest y ranking, and the (k + 1)-th smallest x ranking will be strictly less than the (k + 1)-th smallest y ranking. Thus the average of the two x rankings will be less than the average of the two y rankings. Thus, med(x) < med(y). Thus in both cases, the median of the x rankings is strictly less than the median of the y rankings. Thus, if the total order is defined by sorting actions by median ranking, then x will be before y in the total order. QED

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

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

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

[0201] After 3 gossip periods: All members know that an agreement has been reached

[0202] After 4 gossip periods: All members obtain digital signatures from all other members, thereby endorsing this consensus order.

[0203] Proof: Let S0 be the set of events created and / or defined at 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 at which the events in S0 have propagated to each member, such that each 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 at which each member has received each event in the set S1, which are the events that existed at time T1. This is the end of the second gossip period. Similarly, T3 is the time at which all events in S2, i.e., the events that existed by T2 but did not exist before T1, have propagated 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.

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

[0205] By time T2, a given member Alice will have received records of every event in S0 received by every other member. Therefore, Alice can calculate a rank for each action in S0 for each member (the order in which the member received the action) and then sort the events according to the median of the rank. The overall order of events in S0 will not change. This is because the resulting order is based on the order in which each member first received the indications for each of these events, and this order remains unchanged. It is possible that the order calculated by Alice will intersperse some events from S1 among the events in S0. These S1 events may still change their position within the sequence of S0 events. However, the relative order of events in S0 will not change.

[0206] By time T3, Alice will know 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 within this sequence and deduce that the sequence of events prior to S1 will not change, even if a new event is 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.

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

[0208] 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 for the addition of features not commonly found in current cryptocurrencies. For example, lost coins can be recovered to avoid deflation by enforcing rules: if a wallet has neither sent nor received cryptocurrency within a certain period, then the wallet is deleted, and its value is allocated to other existing wallets in proportion 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.

[0209] Another example is distributed gaming, which is like a massively multiplayer online game (MMO) played on a server, but implemented without using a central server. Consensus can be reached without any central server controlling it.

[0210] 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 emails cannot have fictitious return addresses, 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.

[0211] Other applications could include more sophisticated cryptographic features, such as group digital signatures, where a group collaborates as a whole to sign contracts or documents. This form, as well as other forms of multi-party computation, can be efficiently implemented using such distributed consensus systems.

[0212] 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.

[0213] 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 as full nodes on smaller computers or even mobile and embedded devices.

[0214] Although described above as an event containing hashes of two previous 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 containing hashes of three previous events (one self-hash and two external hashes). In still other embodiments, any number of event hashes from any number of members' previous events may be included in the event. In some embodiments, different events may include different numbers of hashes of previous events. For example, a first event may include two event hashes, and a second event may include three event hashes.

[0215] While the events described above are comprised of hashes (or cryptographic hashes) of previous events, 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, an event may be created and / or defined to include a sequence number associated with and used to identify previous events, thereby linking the events. In some embodiments, such a sequence number 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, assigned address, etc.) and the order of events defined by that member. For example, a member having identifier 10 and whose event is the 15th event created and / or defined by them may assign identifier 1015 to that event. In other embodiments, any other suitable format may be used to assign identifiers to events.

[0216] In other embodiments, the event may contain the complete cryptographic hash, but only a portion of that hash is 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 reply to Alice to request the complete H. In this way, the hash can be compressed during transmission.

[0217] 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 instead of example system 9. As yet another example, example system 7 can be combined with and implemented using example system 6. In still other embodiments, any other suitable combination of the example systems can be implemented.

[0218] Although described above as exchanging events to achieve convergence, in other embodiments, distributed database instances may exchange values ​​and / or vectors of values ​​to achieve convergence, as shown above. Figures 8-13 The convergence described. Specifically, for example, Figure 8 The diagram illustrates a communication flow between a first computing device 400 from a distributed database system (e.g., distributed database system 100) and a second computing device 500 from the same distributed database system (e.g., distributed database system 100) according to an embodiment. In some embodiments, the computing devices 400 and 500 may be structurally and / or functionally similar to...Figure 2 The computing device 200 is shown. In some embodiments, computing devices 400 and 500 are configured to communicate with respect to... Figure 1 The computing devices 110, 120, 130, and 140 shown and described communicate with each other in a similar manner within the distributed database system 100.

[0219] Similar to about Figure 2 The computing devices 200, 400, and 500 described can each initially define a vector of parameter values, update a vector of values, select parameter values ​​based on the vector of defined and / or updated parameter values, and store (1) the vector of defined and / or updated parameter values, and / or (2) the parameter values ​​selected based on the vector of defined and / or updated parameter values. Each of the computing devices 400 and 500 can initially define the vector of parameter values ​​in any number of ways. For example, each of the computing devices 400 and 500 can initially define the vector of parameter values ​​by setting each value in the vector of values ​​to be equal to the value initially stored in the distributed database instances 403 and 503. As another example, each of the computing devices 400 and 500 can initially define the vector of parameter values ​​by setting each value in the vector of values ​​to be equal to a random value. The vector of parameter values ​​that is initially defined can be selected, for example, by the administrator of the distributed database system to which computing devices 400 and 500 belong, or individually or collectively by the users of the computing devices (e.g., computing devices 400 and 500) of the distributed database system.

[0220] Computing devices 400 and 500 can also each store vectors of parameter values ​​and / or selected values ​​of parameters in distributed database instances 403 and 503, respectively. Each of the distributed database instances 403 and 503 can store vectors of parameter values ​​and / or selected values ​​of parameters in a manner similar to... Figure 2 The memory of the memory 220 shown ( Figure 8 Implemented in (not shown in the image).

[0221] In step 1, computing device 400 requests from computing device 500 the value of a parameter stored in the distributed database instance 503 of computing device 500 (e.g., a value stored in a specific field of distributed database instance 503). In some embodiments, computing device 500 may be selected by computing device 400 from a set of computing devices belonging to the distributed database system. Computing device 500 may be selected randomly, based on its relationship with computing device 400, based on its proximity to computing device 400, based on an ordered list associated with computing device 400, and so on. In some embodiments, since computing device 500 may be selected by computing device 400 from a set of computing devices belonging to the distributed database system, computing device 400 may select computing device 500 multiple times consecutively or may not select computing device 500 for a period of time. In other embodiments, an indication of a previously selected computing device may be stored at computing device 400. In such embodiments, computing device 400 may wait for a predetermined number of selections before being able to select computing device 500 again. As described above, distributed database instance 503 may be implemented in the memory of computing device 500.

[0222] In some embodiments, a request from computing device 400 may be made by the communication module of computing device 400. Figure 8 The signal is transmitted by a network (such as network 105, not shown in the diagram). Figure 1 (As shown in the diagram) is carried and received by the communication module of computing device 500. In some embodiments, each of the communication modules of computing devices 400 and 500 may be implemented within a processor or memory. For example, the communication modules of computing devices 400 and 500 may be similar to Figure 2 The communication module 212 shown.

[0223] After receiving a request from computing device 400 for the value of a parameter stored in distributed database instance 503, computing device 500 sends the value of the parameter stored in distributed database instance 503 to computing device 400 in step 2. In some embodiments, computing device 500 may retrieve the value of the parameter from memory and via the communication module of computing device 500. Figure 8 (Not shown in the diagram) This value is sent as a signal. In some cases, if the distributed database instance 503 has not yet included a parameter value (e.g., a transaction has not yet been defined in the distributed database instance 503), the distributed database instance 503 can request the parameter value from the computing device 403 (if the parameter value has not been provided in step 1) and store the parameter value in the distributed database instance 503. In some embodiments, the computing device 400 then uses this value as the parameter value in the distributed database instance 503.

[0224] In step 3, computing device 400 sends the value of the parameter stored in distributed database instance 403 to computing device 500. In other embodiments, the value of the parameter stored in distributed database instance 403 (step 1) and the request for the value of the same parameter stored in distributed database instance 503 (step 3) can be sent as a single signal. In other embodiments, the value of the parameter stored in distributed database instance 403 can be sent in a different signal than the signal used to request the value of the parameter stored in distributed database instance 503. In embodiments where the value of the parameter stored in distributed database instance 403 is sent in a different signal than the signal used to request the value of the parameter stored in distributed database instance 503, the two signals can be sent in any order. In other words, either signal can be sent before the other.

[0225] After computing device 400 receives the value of a parameter sent from computing device 500 and / or computing device 500 receives the value of a parameter sent from computing device 400, in some embodiments, computing device 400 and / or computing device 500 may respectively update the vector of values ​​stored in distributed database instance 403 and / or the vector of values ​​stored in distributed database instance 503. For example, computing devices 400 and 500 may update the vector of values ​​stored in distributed database instances 403 and 503 to respectively include the value of the parameter received by computing devices 400 and 500. Computing devices 400 and 500 may also update the value of the parameter stored in distributed database instance 403 and / or the value of the parameter stored in distributed database instance 503 based on the updated vector of values ​​stored in distributed database instance 403 and / or the updated vector of values ​​stored in distributed database instance 503, respectively.

[0226] Although these steps are Figure 8 The steps 1, 2, and 3, as discussed above, are labeled 1, 2, and 3. However, it should be understood that steps 1, 2, and 3 can be performed in any order. For example, step 3 can be performed before steps 1 and 2. Furthermore, as described in detail herein, communication between computing devices 400 and 500 is not limited to... Figure 3 Steps 1, 2, and 3 are shown. Furthermore, after steps 1, 2, and 3 are completed, computing device 400 can select another computing device from the set of computing devices within the distributed database system to exchange values ​​(similar to steps 1, 2, and 3).

[0227] In some embodiments, the data transmitted between computing devices 400 and 500 may include compressed data, encrypted data, digital signatures, cryptographic checksums, etc. Furthermore, each of computing devices 400 and 500 may send data to another computing device to acknowledge receipt of data previously sent by that other device. Each of computing devices 400 and 500 may also ignore data that has been repeatedly sent by another device.

[0228] Each of the computing devices 400 and 500 can initially define a vector of parameter values, and store the vector of parameter values ​​in distributed database instances 403 and 503 respectively. Figures 9a-9c An example of a vector representing the values ​​of a parameter is shown. A vector can be any collection of parameter values ​​(e.g., a one-dimensional array of parameter values, an array of values ​​each having multiple parts, etc.). For illustrative purposes, in Figures 9a-9c The document provides three examples of vectors. As shown in the figure, each of vectors 410, 420, and 430 has five values ​​with a specific parameter. However, it should be understood that a vector of values ​​can have any number of values. In some cases, the number of values ​​included in a vector of values ​​can be set by the user, set according to the situation, set randomly, and so on.

[0229] Parameters can be any data object capable of taking different values. For example, a parameter could be a binary vote, where the vote value can be "yes" or "no" (or binary "1" or "0"). Figure 9a As shown, the vector of values ​​410 is a vector with five binary votes, where values ​​411, 412, 413, 414, and 415 represent "yes", "no", "no", "yes", and "yes", respectively. For example, the parameter can be a set of data elements. Figure 9b An example is shown where the parameter is a set of letters. As shown, the vector of values ​​420 has five sets of four letters, where the values ​​421, 422, 423, 424, and 425 are {A, B, C, D}, {A, B, C, E}, {A, B, C, F}, {A, B, F, G}, and {A, B, G, H}, respectively. Also, for example, the parameter can be a ranked and / or ordered set of data elements. Figure 9c An example is shown where the parameter is a set of rankings of people. As shown in the figure, the vector of values ​​430 has five sets of rankings of six people, where values ​​431, 432, 433, 434, and 435 are respectively:

[0230] (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank),

[0231] (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Ed, 6. Frank),

[0232] (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Frank, 6. Ed),

[0233] (1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank) and

[0234] (1. Alice, 2. Bob, 3. Ed, 4. Carol, 5. Dave, 6. Frank).

[0235] After defining a vector of parameter values, each of the computing devices 400 and 500 can select a parameter value based on the vector of parameter values. This selection can be performed according to any method and / or process (e.g., a rule or set of rules). For example, the selection can be performed according to a "majority rule," where the parameter value is selected as the value that appears in more than 50% of the values ​​included in the vector. For example, ( Figure 9a The vector of values ​​410 shown includes three "yes" values ​​and two "no" values. Under the "majority rule", the value selected for the parameter based on the vector of values ​​will be "yes" because "yes" appears in more than 50% of the values ​​411, 412, 413, 414, and 415 of the vector of values ​​410.

[0236] For example, a selection can be performed based on "majority occurrence," where the parameter value is selected as a set of data elements, where each data element appears in more than 50% of the values ​​included in the vector. Using... Figure 9b For example, data elements “A”, “B”, and “C” appear in more than 50% of the values ​​421, 422, 423, 424, and 425 of the value vector 420. Under the “majority occurrence” rule, the value chosen for the parameter based on the value vector would be {A, B, C}, because only these data elements (i.e., “A”, “B”, and “C”) appear in three out of the five values ​​of the value vector 420.

[0237] For example, a selection can be performed based on "ranked by median," where the value of the parameter is selected as the set of rank values ​​for the data elements (e.g., the distinct data values ​​within the vector of values), and the rank of each data element is equal to the median rank of all values ​​included across the vector for that data element. For instance, Figure 9c The median rank of each data element in the dataset is calculated as follows:

[0238] Alice: (1, 2, 2, 1, 1); Median rank = 1;

[0239] Bob: (2, 1, 1, 2, 2); median rank = 2;

[0240] Carol: (3, 3, 3, 3, 4); Median rank = 3;

[0241] Dave: (4, 4, 4, 5, 5); Median rank = 4;

[0242] Ed: (5, 5, 6, 4, 3); Median rank = 5;

[0243] Frank: (6, 6, 5, 6, 6); median rank = 6.

[0244] Therefore, under the "rank by median" rule, the values ​​of the rank set of data elements calculated based on the value vector 430 will be (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank). In some embodiments, if two or more data elements have the same median (e.g., a tie), the order can be determined by any suitable method (e.g., randomly, according to the first indicator of the rank, the last indicator of the rank, alphabetically and / or numerically, etc.).

[0245] For an additional example, a selection can be performed based on the "Kemeny Young vote," where the parameter value is chosen as a set of rankings of the data elements, calculated to minimize the cost. For example, for three out of a vector of five values, Alice ranks ahead of Bob in the vectors of values ​​431, 434, and 435. For two out of a vector of five values, Bob ranks ahead of Alice in the vectors of values ​​432 and 433. The cost of ranking Alice ahead of Bob is 2 / 5, and the cost of ranking Bob ahead of Alice is 3 / 5. Therefore, the cost of Alice being ahead of Bob is lower, and according to the "Kemeny Young vote," Alice will be ranked ahead of Bob.

[0246] It should be understood that “majority rule,” “majority occurrence,” “ranking by median,” and “Kemeny Young vote” are discussed as examples of methods and / or procedures that can be used to select the value of a parameter based on a vector of parameter values. Any other methods and / or procedures may also be used. For example, the value of a parameter may be selected as the value that appears in more than x% of the values ​​included in the vector, where x% can be any percentage (i.e., not limited to the 50% used in the “majority rule”). The percentage (i.e., x%) may also vary due to selections performed at different times, for example, relative to confidence values ​​(discussed in detail herein).

[0247] In some embodiments, because a computing device can randomly select other computing devices with which it exchanges values, the vector of values ​​for a computing device can include multiple values ​​from another single computing device at any given time. For example, if the vector size is five, the computing device may randomly select another computing device twice in the last five value exchange iterations. Therefore, the values ​​stored in the distributed database instance of the other computing device will be included twice in the vector of five values ​​used to request the computing device.

[0248] As an example, Figures 10a-10d This illustrates how a vector of values ​​can be updated when one computing device communicates with another. For example, computing device 400 can initially define a vector of values ​​510. In some embodiments, the vector of values ​​510 can be defined based on the values ​​of parameters stored in a distributed database instance 403 at computing device 400. For example, when the vector of values ​​510 is first defined, each value in the vector of values ​​510 (i.e., each of values ​​511, 512, 513, 514, 515) can be set to be equal to the value of the parameter stored in the distributed database instance 403. For instance, if the value of the parameter stored in the distributed database instance 403 is "yes" when the vector of values ​​510 is defined, then each value from the vector of values ​​510 (i.e., each of values ​​511, 512, 513, 514, 515) will be set to "yes," as shown below. Figure 10a As shown. When computing device 400 receives the value of a parameter stored in an instance of a distributed database on another computing device (e.g., distributed database instance 504 of computing device 500), computing device 400 can update the value vector 510 to include the value of the parameter stored in distributed database instance 504. In some cases, the value vector 510 can be updated according to a first-in, first-out (FIFO) order. For example, if computing device 400 receives the value 516 ("Yes"), computing device 400 can add the value 516 to the value vector 510 and remove the value 511 from the value vector 510 to define the value vector 520, as... Figure 10bAs shown. For example, if the computing device receives values ​​517 and 518 at later times, the computing device 400 can add values ​​517 and 518 to the value vector 510 and delete values ​​512 and 513 from the value vector 510 to define value vectors 530 and 540 respectively. In other cases, the value vector 510 can be updated according to a scheme other than first-in-first-out (FIFO) (such as last-in-first-out (LIFO)).

[0249] After the computing device 400 updates the value vector 510 to define value vectors 520, 530, and / or 540, the computing device 400 can select parameter values ​​based on the value vectors 520, 530, and / or 540. This selection can be based on the values ​​described above. Figures 9a-9c Any methods and / or processes (e.g., rules or sets of rules) discussed for execution.

[0250] In some cases, computing devices 400 and 500 may belong to a distributed database system that stores information related to transactions involving financial instruments. For example, each of computing devices 400 and 500 may store binary votes (examples of "values") regarding whether a particular stock is available for purchase (an example of a "parameter"). For example, distributed database instance 403 of computing device 400 may store the value "yes," indicating that the particular stock is indeed available for purchase. On the other hand, distributed database instance 503 of computing device 500 may store the value "no," indicating that the particular stock is not available for purchase. In some cases, computing device 400 may initially define a vector of binary votes based on the binary votes stored in distributed database instance 403. For example, computing device 400 may set each binary vote within the vector of binary votes to be equal to the binary vote stored in distributed database instance 403. In this case, computing device 400 may define a vector of binary votes similar to a vector of values ​​510. At a later time, computing device 400 may communicate with computing device 500 to request computing device 500 to send its binary vote regarding whether a particular stock is available for purchase. Once computing device 400 receives a binary vote from computing device 500 (in this example, "No," indicating that a particular stock is not available for purchase), computing device 400 can update its vector of binary votes. For example, the updated vector of binary votes could resemble a vector of values ​​520. This can occur indefinitely until the confidence value meets predetermined criteria (described in further detail herein), periodically, and so on.

[0251] Figure 11A flowchart 10 illustrates steps performed by a computing device 110 within a distributed database system 100 according to an embodiment. In step 11, the computing device 110 defines a vector of parameter values ​​based on the values ​​of parameters stored in a distributed database instance 113. In some embodiments, the computing device 110 may define the vector of parameter values ​​based on the values ​​of parameters stored in the distributed database instance 113. In step 12, the computing device 110 selects another computing device within the distributed database system 110 and requests the values ​​of parameters stored in the distributed database instance of the selected computing device from the selected computing device. For example, the computing device 110 may randomly select computing device 120 from computing devices 120, 130, and 140, and request the values ​​of parameters stored in the distributed database instance 123 from computing device 120. In step 13, computing device 110 (1) receives the values ​​of parameters stored in a distributed database instance (e.g., distributed database instance 123) of the selected computing device (e.g., computing device 120), and (2) sends the values ​​of parameters stored in distributed database instance 113 to the selected computing device (e.g., computing device 120). In step 14, computing device 110 stores the values ​​of parameters received from the selected computing device (e.g., computing device 120) in a vector of parameter values. In step 15, computing device 110 selects the value of the parameter based on the vector of parameter values. As stated above regarding... Figures 9a-9c The selection discussed can be performed according to any method and / or process (e.g., rules or sets of rules). In some embodiments, the computing device 110 can repeatedly select the value of the parameter at different times. The computing device 110 can also repeatedly cycle steps 12 to 14 between each selection of the parameter value.

[0252] In some cases, distributed database system 100 can store information related to transactions within a massively multiplayer game (MMG). For example, each computing device belonging to distributed database system 100 can store a set of player rankings (examples of "values") in the order in which a particular item is owned (examples of "parameters"). For example, distributed database instance 114 of computing device 110 can store a set of player rankings similar to value 431 (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank), indicating that ownership of a particular item begins with Alice, then passes to Bob, then to Carol, then to Dave, then to Ed, and finally to Frank. The distributed database instance 124 of computing device 120 can store the values ​​of the ranking set of players similar to value 432: (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Ed, 6. Frank); the distributed database instance 134 of computing device 130 can store the values ​​of the ranking set of players similar to value 433: (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Frank, 6. Ed); the distributed database instance 144 of computing device 140 can store the values ​​of the ranking set of players similar to value 434: (1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank); the fifth computing device ( Figure 1 A distributed database instance (not shown) can store the values ​​of a ranking set of players similar to the value 435: (1. Alice, 2. Bob, 3. Ed, 4. Carol, 5. Dave, 6. Frank).

[0253] After defining a vector of player ranking sets in computing device 110, the computing device can receive player ranking set values ​​from other computing devices in the distributed database system 100. For example, computing device 110 can receive (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Ed, 6. Frank) from computing device 120; (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Frank, 6. Ed) from computing device 130; (1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank) from computing device 140; and from a fifth computing device (…). Figure 1(Not shown in the original text) Receives (1. Alice, 2. Bob, 3. Ed, 4. Collar, 5. Dave, 6. Frank). When computing device 110 receives the values ​​of the player's ranking set from other computing devices, computing device 110 can update its vector of player ranking sets to include the values ​​of the player's ranking sets received from other computing devices. For example, after receiving the values ​​of the ranking sets listed above, the vector of player ranking sets stored in the distributed database instance 114 of computing device 110 can be updated to resemble the vector of values ​​430. After the vector of player ranking sets has been updated to resemble the vector of values ​​430, computing device 110 can select the player's ranking set based on the vector of player ranking sets. For example, as mentioned above regarding... Figures 9a-9c The selection discussed can be performed based on "ranking by median". Based on "ranking by median", the computing device 110 will select based on a vector of the ranking set of players (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank) similar to the value vector 430.

[0254] In some cases, computing device 110 does not receive the entire value from another computing device. In some cases, computing device 110 may receive an identifier (such as a cryptographic hash value) associated with a portion of the entire value (also called a composite value), rather than the portion itself. For example, in some cases, computing device 110 does not receive (1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank), i.e., the entire value 434, from computing device 140, but only (4. Ed, 5. Dave, 6. Frank). In other words, computing device 110 does not receive (1. Alice, 2. Bob, 3. Carol), i.e., certain portions of the value 434, from computing device 140. Alternatively, computing device 110 may receive from computing device 140 the cryptographic hash value associated with these portions of the value 434 (i.e., (1. Alice, 2. Bob, 3. Carol)).

[0255] A cryptographic hash value uniquely represents a portion of the value it is associated with. For example, a cryptographic hash representing (1. Alice, 2. Bob, 3. Carol) will be different from a cryptographic hash representing the following:

[0256] (1. Alice);

[0257] (2. Bob);

[0258] (3. Carol);

[0259] (1. Alice, 2. Bob);

[0260] (2. Bob, 3. Carol);

[0261] (1. Bob, 2. Alice, 3. Carol);

[0262] (1. Carol, 2. Bob, 3. Alice);

[0263] etc.

[0264] After computing device 110 receives a cryptographic hash value associated with a portion of value 434 from computing device 140, computing device 110 may (1) generate a cryptographic hash value using the same portion of value 431 stored in distributed database instance 113, and (2) compare the generated cryptographic hash value with the received cryptographic hash value.

[0265] For example, computing device 110 can receive from computing device 140 a cryptographic hash value associated with certain portions of a value 434 as indicated in italics below: (1. Alice, 2. Bob, 3. Colol, 4. Ed, 5. Dave, 6. Frank). The computing device can then generate a cryptographic hash value using the same portions of a value 431 (stored in distributed database instance 113) as indicated in italics below: (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank). Since the italicized portions of value 434 and value 431 are identical, the received cryptographic hash value (associated with the italicized portion of value 434) will also be the same as the generated cryptographic hash value (associated with the italicized portion of value 431).

[0266] By comparing the generated cryptographic hash value with the received cryptographic hash value, computing device 110 can determine whether to request the actual portion associated with the received cryptographic hash value from computing device 140. If the generated cryptographic hash value is the same as the received cryptographic hash value, computing device 110 can determine that a copy identical to the actual portion associated with the received cryptographic hash value is already stored in distributed database instance 113, and therefore the actual portion associated with the received cryptographic hash value from computing device 140 is not needed. On the other hand, if the generated cryptographic hash value is different from the received cryptographic hash value, computing device 110 can request the actual portion associated with the received cryptographic hash value from computing device 140.

[0267] While the cryptographic hash values ​​discussed above are associated with portions of a single value, it should be understood that cryptographic hash values ​​can be associated with an entire single value and / or multiple values. For example, in some embodiments, a computing device (e.g., computing device 140) may store a set of values ​​in its distributed database instance (e.g., distributed database instance 144). In such embodiments, after a predetermined period of time since the value has been updated in the database instance, the confidence value of the value (regarding...) is... Figure 13 (Discussion) After a predetermined criterion (e.g., reaching a predetermined threshold), after a specified amount of time since the transaction was initiated, and / or based on any other suitable factor, this value can be included in the cryptographic hash value along with other values ​​when requesting data from or sending data to another database instance. This reduces the number of specific values ​​that are sent between database instances.

[0268] In some cases, for example, the set of values ​​in the database may include: a first set of values ​​including transactions between 2000 and 2010; a second set of values ​​including transactions between 2010 and 2013; a third set of values ​​including transactions between 2013 and 2014; and a fourth set of values ​​including transactions between 2014 and the present. Using this example, if computing device 110 requests data stored in a distributed database instance 144 of computing device 140 from computing device 140, in some embodiments, computing device 140 may send to computing device 110 (1) a first cryptographic hash value associated with the first set of values, (2) a second cryptographic hash value associated with the second set of values, (3) a third cryptographic hash value associated with the third set of values, and (4) each value from the fourth set of values. Criteria regarding when to add values ​​to the cryptographic hash can be set by an administrator, individual users, based on the many values ​​already existing in the database instance, etc. Sending cryptographic hash values ​​instead of each individual value reduces the number of individual values ​​provided when exchanging values ​​between database instances.

[0269] When receiving a computing device (e.g., Figure 8 When the computing device 400 in step 2 receives a cryptographic hash value (e.g., generated by computing device 500 based on values ​​in distributed database instance 503), it uses the same method and / or process, along with the values ​​of parameters (e.g., transactions during a specified time period) in its database instance (e.g., distributed database instance 403) used to generate the received cryptographic hash value, to generate the cryptographic hash value. The receiving computing device can then compare the received cryptographic hash value with the generated cryptographic hash value. If the values ​​do not match, the receiving computing device can retrieve the hash value from the sending computing device (e.g., Figure 8The computing device 500 in the middle requests the generation of the values ​​of the received cryptographic hash and compares the values ​​from the sending database instance (e.g., distributed database instance 503) with the values ​​of those transactions in the receiving database instance (e.g., distributed database instance 403).

[0270] For example, if the receiving computing device receives a cryptographic hash value associated with a transaction between 2000 and 2010, it can use the value of the transaction between 2000 and 2010 stored in its database instance to generate the cryptographic hash. If the received cryptographic hash value matches a locally generated cryptographic hash value, the receiving computing device can assume that the value used for the transaction between 2000 and 2010 is the same in both databases and does not request additional information. However, if the received cryptographic hash value does not match a locally generated cryptographic hash value, the receiving computing device can request a separate value from the sending computing device used to generate the received cryptographic hash value. The receiving computing device can then identify the difference and update the vector of values ​​used for that separate value.

[0271] Cryptographic hash values ​​can rely on any suitable process and / or hash function to combine multiple values ​​and / or parts of values ​​into a single identifier. For example, any suitable number of values ​​(e.g., transactions within a time period) can be used as input to a hash function, and hash values ​​can be generated based on the hash function.

[0272] While the above discussion uses cryptographic hash values ​​as identifiers associated with values ​​and / or parts of values, it should be understood that other identifiers can be used to represent multiple values ​​and / or parts of values. Examples of other identifiers include digital fingerprints, checksums, regular hash values, etc.

[0273] Figure 12 A flowchart (flowchart 20) illustrating steps performed by a computing device 110 within a distributed database system 100, according to an embodiment, is shown. Figure 12 In the illustrated embodiment, the vector of values ​​is reset based on a predefined probability. Similarly, each value in the vector of values ​​can be reset to a certain value from time to time and based on a probability. In step 21, the computing device 110 selects a value for the parameter based on the vector of parameter values, similar to... Figure 11 The steps shown and discussed above are steps 15. In step 22, computing device 110 receives parameter values ​​from other computing devices (e.g., computing devices 120, 130, 140) and sends the parameter values ​​stored in the distributed database instance 113 to the other computing devices (e.g., computing devices 120, 130, 140). For example, step 22 may include execution for each of the other computing devices. Figure 11The steps 12 and 13 shown and discussed above. In step 23, computing device 110 stores the values ​​of parameters received from other computing devices (e.g., computing devices 120, 130, 140) in a vector of parameter values, similar to... Figure 11 This relates to step 14 shown and discussed above. In step 24, computing device 110 determines whether to reset the vector of values ​​based on a predefined probability of the vector of reset values. In some cases, for example, after each update of the vector of parameter values ​​stored in distributed database instance 114, computing device 110 has a 10% probability of resetting the vector of parameter values. In this case, in step 24, computing device 110 will determine whether to reset based on a 10% probability. In some cases, this determination may be performed by processor 111 of computing device 110.

[0274] If computing device 110 determines a vector of reset values ​​based on a predefined probability, then computing device 110 resets the vector of values ​​at step 25. In some embodiments, computing device 110 may reset each value in the vector of parameter values ​​to be equal to the value of the parameter stored in distributed database instance 113 at the time of reset. For example, if just before the reset, the vector of values ​​is vector 430, and the value of the parameter stored in distributed database instance 113 is (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank) (e.g., based on “ranked by median”), then each value in the vector of values ​​will be reset to be equal to (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank). In other words, each of the values ​​431, 432, 433, 434, 435 in the vector of values ​​430 will be reset to be equal to the value 431. Resetting each value in the vector of parameter values ​​from time to time and based on probability to be equal to the value of the parameter stored in the distributed database instance at the time of reset helps the distributed database system (to which the computing device belongs) reach consensus. Similarly, resetting facilitates consensus on parameter values ​​among computing devices in a distributed database system.

[0275] For example, the distributed database instance 114 of computing device 110 can store a ranking set of players similar to value 431 (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank), which indicates that ownership of a particular item starts with Alice, then passes to Bob, then to Carol, then to Dave, then to Ed, and finally to Frank.

[0276] Figure 13A flowchart (flowchart 30) illustrating steps performed by a computing device 110 within a distributed database system 100 according to an embodiment is shown. Figure 13 In the illustrated embodiment, parameter value selection occurs based on a vector of parameter values ​​when the confidence value associated with an instance of the distributed database is zero. The confidence value can indicate the level of “consensus” or consistency between the value of a parameter stored in computing device 110 and the values ​​of parameters stored in other computing devices (e.g., computing devices 120, 130, 140) of the distributed database system 100. In some embodiments, as described in detail herein, the confidence value is incremented (e.g., increased by 1) whenever a parameter value received by computing device 110 from another computing device is equal to the value of the parameter stored in computing device 110, and decremented (i.e., decreased by 1) whenever a parameter value received by computing device 110 from another computing device is not equal to the value of the parameter stored in computing device 110, if the confidence value is above zero.

[0277] In step 31, computing device 110 receives the value of a parameter from another computing device (e.g., computing device 120) and sends the value of the parameter stored in the distributed database instance 113 to that other computing device (e.g., computing device 120). For example, step 31 may include execution Figure 11 Steps 12 and 13 are shown and discussed above. In step 32, computing device 110 stores the values ​​of the parameters received from the other computing device (e.g., computing device 120) in a vector of parameter values, similar to... Figure 11 The process is illustrated in step 14 as discussed above. In step 33, computing device 110 determines whether the value of the parameter received from the other computing device (e.g., computing device 120) is equal to the value of the parameter stored in distributed database instance 113. If the value of the parameter received from the other computing device (e.g., computing device 120) is equal to the value of the parameter stored in distributed database instance 113, computing device 110 increments the confidence value associated with distributed database instance 113 by 1 at step 34, and the process shown in flowchart 30 loops back to step 31. If the value of the parameter received from the other computing device (e.g., computing device 120) is not equal to the value of the parameter stored in distributed database instance 113, then if the confidence value is greater than zero, computing device 110 decrements the confidence value associated with distributed database instance 113 by 1 at step 35.

[0278] At step 36, computing device 110 determines whether the confidence value associated with distributed database instance 113 is equal to zero. If the confidence value is equal to zero, the computing device selects a parameter value based on a vector of parameter values ​​at step 37. As discussed above, this selection can be performed according to any method and / or process (e.g., a rule or a set of rules). If the confidence value is not equal to zero, the process shown in flowchart 30 loops back to step 31.

[0279] As discussed above, the confidence value is associated with the distributed database instance. However, it should be understood that, as an alternative to, or in addition to, as associated with the distributed database instance, the confidence value may also be associated with the value of a vector stored in the distributed database instance and / or (e.g., within its distributed database instance) in a computing device that stores the values ​​of the vector.

[0280] about Figure 13 The values ​​associated with the confidence level (e.g., threshold, increment, and decrement) used are for illustrative purposes only. It should be understood that other values ​​associated with the confidence level (e.g., threshold, increment, and decrement) may be used. For example, the increases and / or decreases in the confidence level used in steps 34 and 35, respectively, can be any value. As another example, the confidence threshold of zero used in steps 35 and 36 can also be any value. Furthermore, the values ​​associated with the confidence level (e.g., threshold, increment, and decrement) may change during the operation, i.e., cyclically, as shown in flowchart 30.

[0281] In some embodiments, the confidence value can influence the communication flow between a first computing device and a second computing device in a distributed database system, as described above. Figure 8 As described. For example, if a first computing device (e.g., computing device 110) has a high confidence value associated with its distributed database instance (e.g., distributed database instance 114), the first computing device can request a portion of the value of a parameter (and a cryptographic hash value associated with the larger portion of the parameter value) from a second computing device that the first computing device would otherwise request from the second computing device (e.g., if the first computing device has a low confidence value associated with its distributed database instance). The high confidence value can indicate that the value of the parameter stored in the first computing device may be consistent with the value of the parameter stored in other computing devices in the distributed database system, and therefore, the cryptographic hash value is used to verify consistency.

[0282] In some cases, the confidence value of the first computing device can be increased to reach a threshold at which the first computing device determines that it should no longer request a specific value, a specific portion of a value, and / or the cryptographic hash value associated with the specific value and / or the specific portion of the value from other computing devices in the distributed database system. For example, if the confidence value of a value meets a certain criterion (e.g., reaches a threshold), the first computing device can determine that the value has converged and does not further request to exchange the value with other devices. As another example, a value can be added to a cryptographic hash value based on its confidence value meeting a criterion. In this case, as discussed in detail above, the cryptographic hash value of the set of values ​​can be sent after the confidence value meets the criterion, rather than the individual values. Exchanging fewer values ​​and / or smaller actual portions of values ​​using cryptographic hash values ​​associated with the remaining portions can facilitate efficient communication between computing devices in a distributed database system.

[0283] In some cases, as the confidence value of a specific value of a parameter of a distributed database instance increases, the computing device associated with that distributed database instance may request to exchange that parameter value with other computing devices less frequently. Similarly, in other cases, as the confidence value of a specific value of a parameter of a distributed database instance decreases, the computing device associated with that distributed database instance may request to exchange that parameter value with other computing devices more frequently. Therefore, confidence values ​​can be used to reduce the number of values ​​exchanged between computing devices.

[0284] 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 certain events can be modified. Furthermore, if possible, some events in the process can be executed simultaneously in parallel processes, as well as sequentially as described above.

[0285] 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 contain transient propagation signals (e.g., propagating electromagnetic waves carrying information over a transmission medium such as space or cables). The medium and computer code (also referred to as code) can be media and computer code 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 memories (RAMs). Other embodiments described herein relate to computer program products that may include, for example, instructions and / or computer code discussed herein.

[0286] 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.

[0287] 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 method described herein can 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: receiving a first event from an instance of a distributed database at a first computing device of a plurality of computing devices, the plurality of computing devices implementing the distributed database via a network operatively coupled to the plurality of computing devices; defining a third event comprising a reference to the first event and a reference to a second event, the second event defined by a second computing device; determining a first set of events based at least in part on the third event, each event in the first set of events: a) identified by a second set of events, a collective stake value associated with the second set of events satisfying a first stake value criterion, each event in the second set of events (1) defined by a different instance of the distributed database, and (2) identified by the third event, and b) having a first round number; computing a round number for the third event based on determining that a collective stake value associated with the first set of events satisfies a second stake value criterion, the round number for the third event greater than the first round number; determining a third set of events based on the third event, each event in the third set of events: a) identified by a fourth set of events comprising the third event, each event in the fourth set of events defined by a different instance of the distributed database, a collective stake value associated with the fourth set of events satisfying a third stake value criterion, and b) from the first set of events; defining an order value for a fourth event based on a collective stake value associated with the third set of events satisfying a fourth stake value criterion, the fourth event an ancestor of the third set of events; and storing the order value in an instance of the distributed database at a second computing device of the plurality of computing devices, the collective stake value associated with a respective set of events based on a sum of stake values associated with each instance of the distributed database that defines an event in the respective set of events.

2. The method of claim 1, wherein the order value is stored and influences a hash value that uniquely identifies a consensus state of the distributed database.

3. The method of claim 1, wherein: each event in the first set of events is an earliest event among events defined by different instances of the distributed database that have the first round number.

4. The method of claim 1, wherein at least one of the first stake value criterion, the second stake value criterion, the third stake value criterion, or the fourth stake value criterion is defined based on a collective stake value of the distributed database.

5. The method of claim 1, wherein the plurality of computing devices implementing the distributed database are a plurality of computing devices implementing the distributed database at a first time and associated with a set of trusted entities, a plurality of computing devices implementing the distributed database at a second time after the first time associated with a set of entities that includes entities that are not from the set of trusted entities.

6. A non-transitory processor-readable medium storing code representing instructions to be executed by a processor, the code comprising code to cause the processor to perform operations comprising: ​ receiving a first event from an instance of a distributed database at a first computing device of a plurality of computing devices, the plurality of computing devices implementing the distributed database via a network operatively coupled to the plurality of computing devices; defining a third event that includes a reference to the first event and a reference to a second event, the second event defined by a second computing device; determining a first set of events based at least in part on the third event, each event in the first set of events: identified by a second set of events, a collective stake value associated with the second set of events satisfies a first stake value criterion, each event in the second set of events (1) defined by a different instance of the distributed database and (2) identified by the third event, and having a first round number; computing a round number for the third event based on determining that a collective stake value associated with the first set of events satisfies a second stake value criterion, the round number for the third event greater than the first round number; determining a third set of events based on the third event, each event in the third set of events: identified by a fourth set of events that includes the third event, each event in the fourth set of events defined by a different instance of the distributed database, a collective stake value associated with the fourth set of events satisfies a third stake value criterion, and from the first set of events; defining an order value for the fourth event based at least in part on a collective stake value associated with the third set of events satisfying a fourth stake value criterion, wherein the fourth event is an ancestor of the third set of events; and storing the order value in an instance of the distributed database at a second computing device of the plurality of computing devices, wherein the collective stake value associated with a respective set of events is based on a sum of stake values associated with each instance of the distributed database that defines an event in the respective set of events.

7. The non-transitory processor-readable medium of claim 6, wherein the second stake value criterion is based on a predefined proportion associated with a collective stake value of the distributed database, the code further comprising code that causes the processor to perform operations of: associating the round number for the third event as a received round number for the fourth event based on the third set of events satisfying the fourth stake value criterion.

8. The non-transitory processor-readable medium of claim 6, further comprising code that causes the processor to perform operations of: determining a value for the third event based on a value of each event in the fourth set of events, based on the fourth set of events satisfying the third stake value criterion, the value for the third event being a value associated with a majority of events in the fourth set of events, the fourth set of events satisfying the third stake value criterion when a collective stake value of each event in the fourth set of events having the value associated with the majority of events is greater than a first threshold value and less than a second threshold value, the first threshold value and the second threshold value based on the collective stake value of the fourth set of events.

9. The non-transitory processor-readable medium of claim 6, further comprising code that causes the processor to perform operations of: determining a value for the third event based on a value of each event in the fourth set of events, based on the fourth set of events satisfying the fourth stake value criterion, the value for the third event being pseudo-random, The fourth event set satisfies a fourth equity value criterion when a collective equity value of each event in the fourth event set having a value associated with a majority of events in the fourth event set is greater than a first threshold value and less than a second threshold value, the first threshold value and the second threshold value based on the collective equity value associated with the fourth event set.

10. The non-transitory processor-readable medium of claim 6, wherein the fourth event set is a subset of events from a fifth event set, the code further comprising code that causes the processor to perform operations of: identifying the subset of events based on a value associated with each event in the subset of events being equal to a value associated with a remaining event in the subset of events, the value associated with each event in the subset of events (1) being associated with a fourth event and (2) being based on a value of each event in a sixth event set identifiable by that event in the subset of events, the fifth event set having an ordinal number greater than an ordinal number of the sixth event set, the subset of events satisfying a fifth equity value criterion when a collective equity value of the subset of events is greater than a first threshold value and less than a second threshold value, the first threshold value and the second threshold value based on the collective equity value of the fifth event set; and identifying, based on the subset of events satisfying the fifth equity value criterion, a seventh event set having a collective equity value for determining an order value of the fourth event, the seventh event set having an ordinal number greater than an ordinal number of the fifth event set, a value of each event in the seventh event set based on a value associated with each event in the fifth event set.

11. The non-transitory processor-readable medium of claim 6, wherein each event in the third event set (1) is defined by a different instance of the distributed database and (2) is identified by the third event, the order value of the fourth event further based on a pseudo-random determination associated with a digital signature of the third event.

12. The non-transitory processor-readable medium of claim 6, wherein the fourth equity value criterion is satisfied when a collective equity value associated with the third event set is greater than a predetermined threshold value, the predetermined threshold value based at least in part on a collective equity value of the distributed database.

Images