RU2778013C2 - Methods and device for a distributed database on the network - Google Patents

Abstract

FIELD: information systems.

SUBSTANCE: invention relates to information systems, namely distributed databases. A device for implementing a distributed database contains: memory containing an instance of a distributed database on the first computing device, made with the possibility of inclusion in a plurality of computing devices, which implements a distributed database via a network functionally connected to a plurality of computing devices, as well as a processor functionally connected to an instance of a distributed database, while the processor made with the possibility of determining the first event at the first moment of time, in this case, the processor is designed with the possibility of receiving at the second moment of time after the first moment of time and from the second computing device from a plurality of computing devices.

EFFECT: expansion of the range of solutions for databases.

99 cl, 24 dwg, 1 tbl

Description

Cross-references to related applications

This application is a continuation in part of U.S. Patent Application No. 15/205688, filed 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/988873, filed January 6, 2016, entitled "Methods and Apparatus for a Distributed Database within a Network", which claims the priority and benefit of Provisional Application No. U.S. Patent No. 62/211411, filed August 28, 2015, titled "Methods and Apparatus for a Distributed Database within a Network", each of which is incorporated herein by reference in in all its fullness.

This application is also a continuation in part of U.S. Patent Application No. 15/153011, filed May 12, 2016, entitled "Methods and Apparatus for a Distributed Database within a Network", which is a partial continuation of U.S. Patent Application No. 14/988873, filed January 6, 2016, titled "Methods and Apparatus for a Distributed Database within a Network", which claims the priority and benefit of prior U.S. Patent Application No. 62/211411, filed Aug. 28, 2015, entitled "Methods and Apparatus for a Distributed Database within a Network", each of which is incorporated herein by links in their entirety.

This application also claims the priority and benefit of U.S. Provisional Application No. 62/211411, filed Aug. 28, 2015, titled "Methods and Apparatus for a Distributed Database within a Network" which has been incorporated herein by reference in its entirety.

This application also claims the priority and benefit of U.S. Provisional Application No. 62/344682, filed June 2, 2016, entitled "Methods and Apparatus for a Distributed Database with Consensus Determined Based on Weighted Stakes." consensus determined on the basis of weighted proportions)”, which is incorporated herein by reference in its entirety.

Background of the invention

The embodiments described herein relate generally to a database system, and more specifically to methods and apparatus for implementing a database system on a plurality of devices on a network.

Some well-known distributed database systems attempt to reach consensus on values in distributed database systems (eg, regarding the order in which transactions occur). For example, an online multiplayer game may have a plurality of computer servers that users may access to play the game. If two users simultaneously attempt to pick up a particular item in the game, then it is important that the servers in the distributed database system eventually agree on which of the two users picked up the item first.

Such distributed consensus may be handled by methods and/or processes such as the Paxos algorithm or variations thereof. Using such methods and/or processes, one database system server is established as the "leader" and the leader makes decisions about the order of events. Events (eg, in multiplayer games) are passed to the leader, the leader selects an ordered sequence for the events, and the leader passes this ordered sequence to the other database system servers.

However, such known approaches use a server managed by some party (eg, a central control server) that is trusted by the users of the database system (eg, the players in the game). Accordingly, there is a need for methods and apparatus for a distributed database system that do not require a leader or trusted third party to control the database system.

Other distributed databases are designed without a leader but are inefficient. For example, one such distributed database is based on a "chain of blocks" data structure that can reach consensus. However, such a system may be limited to a small number of transactions per second for all participants combined (eg, 7 transactions per second), which is not enough for a large-scale game or for many traditional database applications. Accordingly, there is a need for a distributed database system that achieves consensus without a leader and that is efficient.

The essence of the invention

In some embodiments, the device comprises an instance of the distributed database on a first computing device adapted to be included in a set of computing devices that implement the distributed database. The device also includes a processor configured to determine the first event associated with the first set of events. The processor is configured to receive from a second computing device of the set of computing devices a signal representing a second event (1) determined by the second computing device and (2) associated with the second set of events. The processor is configured to identify the order associated with the third set of events based on at least one protocol result. The processor is configured to store in the distributed database instance the order associated with the third set of events.

Brief description of graphic materials

In FIG. 1 is a high-level block diagram illustrating a distributed database system according to one embodiment.

In FIG. 2 is a block diagram illustrating a computing device of a distributed database system according to one embodiment.

In FIG. 3-6 illustrate examples of hash-based DAGs according to one embodiment.

In FIG. 7 is a block diagram illustrating information flow between a first computing device and a second computing device according to one embodiment.

In FIG. 8 is a block diagram illustrating information flow between a first computing device and a second computing device according to one embodiment.

In FIG. 9a-9c show vector tables illustrating examples of value vectors.

In FIG. 10a-10d show vector tables illustrating examples of value vectors updated to include new values.

In FIG. 11 is a block diagram illustrating the operation of a distributed database system according to one embodiment.

In FIG. 12 is a block diagram illustrating the operation of a distributed database system according to one embodiment.

In FIG. 13 is a block diagram illustrating the operation of a distributed database system according to one embodiment.

In FIG. 14 shows an example of a hash-based DAG according to one embodiment.

In FIG. 15 shows an example of a hash-based DAG according to one embodiment.

In FIG. 16a-16b illustrate an example of a consensus method for use with a hash-based DAG according to one embodiment.

In FIG. 17a-17b illustrate an example of a consensus method for use with a hash-based DAG according to another embodiment.

Detailed description of the invention

In some embodiments, the device comprises an instance of the distributed database on a first computing device adapted to be included in a set of computing devices that implement the distributed database via a network operably coupled to the set of computing devices. The apparatus also includes a processor operatively coupled to a memory storing an instance of the distributed database. The processor is configured to determine at a first time the first event associated with the first set of events. The processor is configured to receive at a second time point, after the first time point, and from a second computing device from the set of computing devices, a signal representing a second event (1) determined by the second computing device and (2) associated with the second set of events. The processor is configured to identify the order associated with the third set of events based on at least one protocol result. Each event from the third event set is an event from at least one of the first event set or the second event set. The processor is configured to store in the distributed database instance the order associated with the third set of events.

In some cases, each event in the third set of events is associated with a set of attributes (eg, sequence number, generation number, round number, received number and/or timestamp, etc.). The protocol result may contain a value for each attribute in the attribute set for each event in the third event set. The value for the first attribute from the attribute set may include a first numeric value, and the value for the second attribute from the attribute set may include a binary value associated with the first numeric value. A binary value for a second attribute (e.g., round increment value) for an event from a third set of events may be based on whether the relationship between that event and the fourth set of events associated with that event meets some criterion (e.g., the number of events strongly identified this event). Each event in the fourth event set (1) is an ancestor of the event in the third event set, and (2) is associated with the first common attribute, as are the rest of the events in the fourth event set (e.g., a general round number, an indication of what constitutes the first event round R, etc.). The first general attribute may be indicative of the first instance in which an event identified by each computing device in the set of computing devices is associated with a first specific value (eg, an indication of what constitutes the first event of round R, etc.).

The value for the third attribute (eg, received round number) from the attribute set may include a second numeric value based on the relationship between the event and the fifth set of events associated with the event. Each event in the fifth event set is a child of an event and is associated with a second common attribute (eg, known), like the rest of the events in the fifth event set. The second common attribute may be associated with (1) a third common attribute (e.g., an indication of what constitutes the first event of an R round or witness), which is an indication of the first occurrence in which the second event specified by each computing device in the set of computing devices, is associated with a second specific value other than the first specific value, and (2) a result based on a set of indications. Each indication from the set of indications may be associated with an event from the sixth set of events. Each event in the sixth event set may be associated with a fourth common attribute, which is an indication of the first occurrence in which the third event identified by each computing device in the computing device set is associated with a third specific value other than the first specific value and the second specific value. . In some cases, the first specific value is the first integer (for example, the first round number R), the second specific value is the second integer (for example, the second round number, R+n) greater than the first integer, and the third specific value is the third integer. number (for example, the third round number, R+n+m) greater than the second integer.

In some embodiments, the implementation of the device contains a memory and a processor. The memory contains an instance of the distributed database on a first computing device adapted to be included in a set of computing devices that implements the distributed database via a network operatively connected to the set of computing devices. The processor is operatively coupled to a memory storing an instance of the distributed database and configured to receive a signal representing an event associated with the set of events. The processor is configured to identify the order associated with the set of events based on at least the result of the protocol. The processor is configured to store in the distributed database instance the order associated with the set of events.

In some embodiments, a non-volatile processor-readable medium stores code representing instructions to be executed by the processor to receive a signal representing an event associated with a set of events and identify the order associated with the set of events based on the round associated with each event in the set. events, and an indication indicating when to increment the round associated with each event. The code further comprises code for causing the processor in the distributed database instance on a first computing device adapted to be included in a set of computing devices that implements the distributed database via a network operably connected to the set of computing devices to store the order associated with the set of events. The distributed database instance is operatively coupled to the processor.

In some embodiments, an instance of the distributed database on a first computing device may be configured to be included in a set of computing devices that implements the distributed database via a network operatively coupled to the set of computing devices. The first computing device stores a plurality of transactions in a distributed database instance. The database convergence module may be implemented in the memory or processor of the first computing device. The database convergence module may be operatively associated with a distributed database instance. The database convergence module may be configured to determine at a first time a first event associated with the first set of events. Each event from the first set of events is a sequence of bytes and is associated with (1) a set of transactions from the set of transactions and (2) an order associated with the set of transactions. Each transaction in the set of transactions is a transaction in the set of transactions. The database convergence module may be configured to receive, at a second time after the first time and from a second computing device of the computing device set, a second event (1) determined by the second computing device and (2) associated with the second set of events. The database convergence module may be configured to determine a third event associated with the first event and the second event. The database convergence module may be configured to identify an order associated with the third set of events based on at least the first set of events and the second set of events. Each event from the third set of events is an event from at least one of the first set of events or the second set of events. The database convergence module may be configured to identify an order associated with a plurality of transactions based on at least (1) an order associated with a third set of events and (2) an order associated with each transaction set of the plurality of transaction sets. The database convergence module may be configured to store in the distributed database instance an order associated with a plurality of transactions stored on the first computing device.

In some embodiments, an instance of the distributed database on a first computing device may be configured to be included in a set of computing devices that implements the distributed database via a network operatively coupled to the set of computing devices. The database convergence module may be implemented in the memory or processor of the first computing device. The database convergence module may be configured to determine at a first time a first event associated with the first set of events. Each event from the first set of events is a sequence of bytes. The database convergence module may be configured to receive, at a second time after the first time and from a second computing device of the computing device set, a second event (1) determined by the second computing device and (2) associated with the second set of events. Each event from the second set of events is a sequence of bytes. The database convergence module may be configured to determine a third event associated with the first event and the second event. The database convergence module may be configured to identify an order associated with the third set of events based on at least the first set of events and the second set of events. Each event from the third set of events is an event from at least one of the first set of events or the second set of events. The database convergence module may be configured to store in the distributed database instance the order associated with the third set of events.

In some embodiments, data associated with a first transaction may be received on a first computing device from a set of computing devices that implement 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 distributed database instance. The ordinal value of the first transaction associated with the first transaction can be determined at the first time. The data associated with the second transaction may be received from a second computing device of the set of computing devices. The set of transactions may be stored in a distributed database instance on the first computing device. The set of transactions may include at least a first transaction and a second transaction. A set of transaction ordinal values, including at least a first transaction ordinal value and a second transaction ordinal value, may be selected at a second time point after the first time point. The ordinal value of the second transaction may be associated with the second transaction. The database state variable may be determined based on at least a set of transactions and a set of transaction ordinal values.

In some embodiments, the method includes receiving a first event from a distributed database instance on a first computing device of a set of computing devices that implement the distributed database via a network operably coupled to the set of computing devices. The method further includes determining a third event based on the first event and the second event. The third event is associated with a set of events. The ordinal value may be determined for the fourth event based at least in part on the total stake value associated with the set of events corresponding to the stake size criterion. The ordinal value may be stored in a distributed database instance on a second computing device of the set of computing devices. In some embodiments, the method further includes calculating the total share value based on the sum of the set of share values. Each share value in the share value set is associated with a distributed database instance that determined the event in the event set.

In some embodiments, the method includes receiving a first event from a distributed database instance on a first computing device of a set of computing devices that implement the distributed database via a network operably coupled to the set of computing devices. The method further includes determining a third event based on the first event and the second event, and determining the first set of events based at least in part on the third event. Each event from the first set of events is a) identified by the second set of events and b) associated with the first round number. The total share value associated with the second set of events satisfies the first share value criterion, and each event in the second set of events is (1) identified by a different distributed database instance and (2) identified by a third event. The round number for the third event may be calculated based on determining that the sum of the stake values associated with each event from the first set of events satisfies the second stake size criterion. The round number for the first event corresponds to the second round number greater than the first round number. The method further includes determining a third set of events based on the third event. Each event from the third event set is a) identified by a fourth event set including the third event, and b) is an event from the first event set. Each event in the fourth event set is determined by a different distributed database instance, and the total stake value associated with the fourth event set satisfies the third stake size criterion. An ordinal value is then determined for the fourth event based on the total stakes associated with the third set of events satisfying the fourth stakes criterion, and the ordinal value can be stored in the distributed database instance on the second computing device.

In some embodiments, the set of stake values includes a stake value (1) associated with each distributed database instance that determines an event from the second set of events, and (2) proportional to the amount of cryptocurrency associated with that distributed database instance. The total stake value associated with the second set of events is based on the sum of the stake values from the stake value set.

In some embodiments, at least one of the first share value criterion, the second share value criterion, the third share value criterion, or the fourth share value criterion is determined based on the total share value of the distributed database. Moreover, in some embodiments, a set of computing devices that implement a distributed database is associated with a set of trusted entities at a first time, and a set of computing devices that implement a distributed database is associated with a set of entities at a second time after the first time. A that includes subjects not in the set of trusted subjects.

In the context of this document, a module may be, for example, any node and/or set of functionally related electrical components associated with the performance of a specific function, and may contain, for example, memory, processor, electrical communication channels, optical connectors, software (executable in hardware) and/or the like.

In the context of the present description, the singular form includes the reference of the designated objects in the plural, unless the context clearly indicates otherwise. Thus, for example, the term "module" is intended to mean one module or a combination of modules. For example, "network" is intended to mean one network or combination of networks.

In FIG. 1 is a high-level block diagram illustrating a distributed database system 100 according to one embodiment. In FIG. 1 illustrates a distributed database 100 implemented on four computing devices (computing device 110, computing device 120, computing device 130, and computing device 140), but it should be understood that distributed database 100 may use a set of any number of computing devices, including computing devices. devices not shown in Fig. 1. Network 105 may be any type of network (eg, local area network (LAN), wide area network (WAN), virtual network, telecommunications network) implemented as a wired network and/or wireless network and used to functionally interconnect computing devices 110, 120, 130, 140. As described in more detail herein, in some embodiments, for example, the computing devices are personal computers connected to each other through an Internet Service Provider (ISP) and the Internet (for example, , networks 105). In some embodiments, a connection may be established via network 105 between any two computing devices 110, 120, 130, 140. As shown in FIG. 1, for example, a connection may be established between computing device 110 and any of computing device 120, computing device 130, or computing device 140.

In some embodiments, computing devices 110, 120, 130, 140 may communicate with each other (eg, send data to and/or receive data from) and with the network via intermediate networks and/or alternate networks (not shown in FIG. 1 ). Such intermediate networks and/or alternative networks may be of the same type and/or a different type of network compared to network 105.

Each computing device 110, 120, 130, 140 may be any type of device configured to send data over network 105 to send and/or receive data from one or more other computing devices. Examples of computing devices are shown in FIG. 1. Computing device 110 includes a memory 112, a processor 111, and an output device 113. The memory 112 may be, for example, random access memory (RAM), memory buffer, hard disk, database, erasable programmable read only memory (EPROM), electrically erasable program read only memory (EEPROM), read only memory (ROM), and /or etc. In some embodiments, memory 112 of computing device 110 contains data associated with a distributed database instance (eg, distributed database instance 114). In some embodiments, memory 112 stores instructions that cause the processor to execute modules, processes, and/or functions associated with sending to and/or receiving from another distributed database instance (e.g., distributed database instance 124 on computing device 120) records of a sync event, records of previous sync events with other computing devices, order of sync events, value for a parameter (e.g., a database field that quantifies a transaction, a database field that quantifies the order in which events occur, and/or any other appropriate field for which a value can be stored in the database).

The distributed database instance 114 may, for example, be configured to perform data operations, including storing, modifying, and/or deleting data. In some embodiments, distributed database instance 114 may be a relational database, an object database, a post-relational database, and/or any other suitable type of database. For example, distributed database instance 114 may store data related to any particular function and/or area. For example, distributed database instance 114 may store financial transactions (eg, of a user of computing device 110), including a value and/or vector of values related to the ownership history of a particular financial instrument. In general, a vector can be any set of values for a parameter, and a parameter can be any data object and/or database field that can take on different values. Thus, distributed database instance 114 may have a number of parameters and/or fields, each of which is associated with a vector of values. The value vector is used to determine the actual value for the parameter and/or field in this instance 114 of the database.

In some cases, distributed database instance 114 may also be used to implement other data structures, such as a set of (key, value) pairs. The transaction recorded by the distributed database instance 114 may be, for example, adding, deleting, or modifying a (key, value) pair in a set of (key, value) pairs.

In some cases, a query may be sent to the distributed database system 100 or to any of the distributed database instances 114, 124, 134, 144. For example, a query may consist of a key, and the result returned by the distributed database system 100 or distributed database instances 114, 124, 134, 144 may be a value associated with the key. In some cases, the distributed database system 100 or any of the distributed database instances 114, 124, 134, 144 may also be modified by a transaction. For example, a transaction for modifying a database may contain a digital signature performed by the party authorizing the modification transaction.

The distributed database system 100 can be used for many purposes, such as storing attributes associated with different users in a distributed identity system, for example. For example, such a system might use a user ID as a "key" and a list of attributes associated with users as a "value". In some cases, the identifier may be a cryptographic public key with a corresponding private key known to that user. Each attribute may, for example, be digitally signed by an authority that has the authority to approve that attribute. Each attribute may also, for example, be encrypted using a public key associated with a person or group of people who has the right to read the attribute. Some keys or values may also have a list of public keys of parties that are authorized to modify or delete the keys or values attached to them.

In another example, distributed database instance 114 may store data related to Massively Multiplayer Games (MMG), such as the current state and ownership of game items. In some cases, distributed database instance 114 may be implemented on computing device 110, as shown in FIG. 1. In other cases, the computing device may have access to a distributed database instance (eg, over a network), but it is not implemented in the computing device (not shown in FIG. 1).

Processor 111 of computing device 110 may be any suitable processing device capable of starting and/or executing distributed database instance 114. For example, processor 111 may be configured to update distributed database instance 114 in response to receiving a signal from computing device 120 and/or causing a signal to be sent to computing device 120, as described in more detail herein. More specifically, as described in more detail herein, processor 111 may be configured to execute modules, functions, and/or processes to update distributed database instance 114 in response to receiving a transaction-related synchronization event from another computing device, write associated with the order of synchronization events, and/or the like. In other embodiments, processor 111 may be configured to execute modules, functions, and/or processes to update distributed database instance 114 in response to receiving a value for a parameter stored in another distributed database instance (e.g., distributed database instance 124 on computing device 120), and/or causing a value for a parameter stored in a distributed database instance 114 on computing device 110 to be sent to computing device 120. In some embodiments, processor 111 may be a general purpose processor, field programmable gate array (FPGA) ), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), and/or the like.

The display 113 may be any suitable display such as, for example, a liquid crystal display (LCD), a cathode ray tube (CRT) display, or the like. In other embodiments, any of the computing devices 110, 120, 130, 140 comprise another output device in addition to or instead of the displays 113, 123, 133, 143. For example, any of the computing devices 110, 120, 130, 140 may include an audio output device (eg, a speaker), a tactile output device, and/or the like. In still other embodiments, any of the computing devices 110, 120, 130, 140 includes an input device instead of or in addition to the displays 113, 123, 133, 143. For example, any of the computing devices 110, 120, 130, 140 may include a keyboard, mouse, and/or the like.

Computing device 120 has a processor 121, memory 122, and display 123, which may be structurally and/or functionally similar to processor 111, memory 112, and display 113, respectively. Also, distributed database instance 124 may be structurally and/or functionally similar to distributed database instance 114.

Computing device 130 has a processor 131, memory 132, and display 133, which may be structurally and/or functionally similar to processor 111, memory 112, and display 113, respectively. Also, distributed database instance 134 may be structurally and/or functionally similar to distributed database instance 114.

Computing device 140 has a processor 141, memory 142, and display 143, which may be structurally and/or functionally similar to processor 111, memory 112, and display 113, respectively. Also, distributed database instance 144 may be structurally and/or functionally similar to distributed database instance 114.

Although the computing devices 110, 120, 130, 140 are shown as similar to each other, each computing device of the distributed database system 100 may be different from other computing devices. Each computing device 110, 120, 130, 140 of the distributed database system 100 may be any of, for example, a computing element (e.g., a personal computing device such as a desktop computer, laptop computer, etc.), a mobile phone, a handheld personal computer (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.

In some embodiments, one or more portions of computing devices 110, 120, 130, 140 may include a hardware module (e.g., a digital signal processor (DSP), a field programmable gate array (FPGA)) and/or a software module (e.g., a computer computer module). code stored in memory and/or executed by the processor). In some embodiments, one or more functions associated with computing devices 110, 120, 130, 140 (eg, functions associated with processors 111, 121, 131, 141) may be included in one or more modules (see, for example, , Fig. 2).

Properties of distributed database system 100, including properties of computing devices (eg, computing devices 110, 120, 130, 140), number of computing devices, and network 105 may be selected in any manner. In some cases, the properties of the distributed database system 100 may be selected by an administrator of the distributed database system 100. In other cases, the properties of the distributed database system 100 may be jointly selected by the users of the distributed database system 100.

Because the distributed database system 100 is used, no leader is assigned among the computing devices 110, 120, 130, and 140. In particular, none of the computing devices 110, 120, 130, or 140 is identified and/or chosen as the leader to resolve conflicts between values stored in the distributed database instances 111, 121, 131, 141 of the computing devices 110, 120, 130, 140. Instead, using the event timing processes, voting processes, and/or methods described herein, computing devices 110, 120, 130, 140 may collaboratively negotiate a value for a parameter.

The absence of a leader in a distributed database system enhances the security of a distributed database system. In particular, in the presence of a leader, there is a single point of attack and/or failure. If malware infects the leader and/or the value for a parameter on the leader's distributed database instance is maliciously modified, the erroneous and/or incorrect value is propagated to other distributed database instances. However, in a leaderless system, there is no single point of attack and/or failure. In particular, if a parameter in a distributed database instance of a leaderless system contains a value, the value will change after that distributed database instance exchanges values with other distributed database instances in the system, as described in more detail herein. Additionally, the leaderless distributed database systems described herein improve convergence speed while reducing the amount of data transferred between devices, as described in more detail herein.

In FIG. 2 illustrates a computing device 200 of a distributed database system (eg, distributed database system 100) according to one embodiment. In some embodiments, computing device 200 may be similar to computing devices 110, 120, 130, 140 shown and described with respect to FIG. 1. Computing device 200 includes a processor 210 and a memory 220. The processor 210 and memory 220 are operatively coupled to each other. In some embodiments, processor 210 and memory 220 may be similar to processor 111 and memory 112, respectively, as detailed with respect to FIG. 1. As shown in FIG. 2, processor 210 includes a database convergence module 211 and communication module 210, and memory 220 includes a distributed database instance 221. Communications module 212 allows computing device 200 to communicate with (eg, send data to and/or receive data from) other computing devices. In some embodiments, communication module 212 (not shown in FIG. 1) allows computing device 110 to communicate with computing devices 120, 130, 140. Communication module 210 may include and/or provide, for example, a network interface controller (NIC), wireless connection, wired port, and/or the like. As such, communication module 210 may establish and/or maintain a communication session between computing device 200 and another device (eg, over a network, such as network 105 shown in FIG. 1, or the Internet (not shown)). Similarly, communication module 210 may allow computing device 200 to send data to and/or receive data from another device.

In some cases, the database convergence module 211 may exchange events and/or transactions with other computing devices, store the events and/or transactions that the database convergence module 211 receives, and calculate an ordered sequence of events and/or transactions based on a partial order determined by linking scheme between events. Each event can be a record containing a cryptographic hash of the two earlier events (associating that event with the two earlier events and their parent events, and vice versa), payload data (such as transactions to be recorded), other information, such as the current time, a timestamp (eg, UTC date and time) that its creator has approved representing the time at which the event was first defined, and/or the like. In some cases, the first event defined by a participant contains a hash of only one event defined by another participant. In such cases, the participant does not yet have a previous hash of its own (eg, an event hash previously determined by that participant). In some cases, the first event in a distributed database does not contain the hash of any previous event (because there is no previous event for this distributed database).

In some embodiments, such a cryptographic hash of the two earlier events may be a hash value determined from a cryptographic hash function using the event as input. Namely, in such embodiments, the implementation of the event contains a specific sequence or string of bytes (which represent information about this event). An event hash can be a value returned by a hash function that takes the byte sequence for that event as input. In other embodiments, any other suitable data associated with the event (e.g., ID, serial number, bytes representing a particular part of the event, etc.) can be used as input to a hash function to calculate the hash of that event. . Any suitable hash function can be used to determine the hash. In some embodiments, each participant uses the same hash function so that the same hash is generated for each participant for a given event. The event may then be digitally signed by the participant defining and/or creating the event.

In some cases, a set of events and their relationships can form a Directed Acyclic Graph (DAG). In some cases, each event in the DAG references two earlier events (associating that event with the two earlier events and their parent events, and vice versa), and each reference is strictly to the earlier events, so there are no cycles. In some embodiments, the implementation of the DAG is based on cryptographic hashes, so that the data structure can be called a DAG based on hashes. A hash-based DAG directly encodes a partial order, denoting that event X is known to occur before event Y if Y contains the hash of X, or if Y contains the hash of an event that contains the hash of X, or for such paths of arbitrary length. However, if there is no path from X to Y or from Y to X, then the partial order does not determine which event happened first. Therefore, the database convergence module can calculate the total order from the partial order. This can be done with any suitable deterministic function that is used by the computing devices such that the computing devices compute the same order. In some embodiments, each participant may recalculate this order after each synchronization, and eventually these orders may converge such that a consensus occurs.

The consensus algorithm can be used to determine the order of events in the DAG based on the hashes and/or the order of the transactions stored in the events. The order of transactions, in turn, can determine the state of the database as a result of the execution of these transactions in accordance with the order. A particular database state can be stored as a database state variable.

In some cases, the database convergence module may use the following function to calculate a total order from a partial order in a DAG based on hashes. For each of the other computing devices (called "participants"), the database convergence module may look at the hash-based DAG to find the order in which events (and/or indications of those events) were received by that participant. The database convergence module can then perform calculations as if that participant had assigned a numerical "rank" to each event, with the rank being 1 for the first event that the participant accepted, 2 for the second event that the participant accepted, and so on. The database convergence module can do this for each member in a hash-based DAG. Then, for each event, the database convergence module may calculate the median of the assigned ranks and may sort the events by their medians. Sorting can break the equalities in a deterministic way, for example by sorting two equal events by the numerical order of their hashes, or in some other way in which each participant's database convergence module uses the same way. The result of this sort is the overall order.

In FIG. 6 illustrates DAG 640 based on hashes of one example to determine the overall order. The hash-based DAG 640 illustrates two events (the bottommost circle with stripes and the bottommost circle with dots) and the first time each participant receives indications of these events (the remaining circles with stripes and dots). Each member's name at the top is colored according to which event is first in their slow order. There are more initial votes with stripes than with dots, so the consensus votes for each participant are striped. In other words, the participants eventually agree that the stripe event happened before the dot event.

In this example, the participants (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 circle with stripes indicates an event when the participant first received an event 644 (and/or an indication of this event 644). Similarly, each dotted circle indicates the event when the participant first received event 642 (and/or an indication of that event 642). As shown in the hash-based DAG 640, Alice, Bob, and Carol all received event 644 (and/or an indication of event 644) before event 642. Both Dave and Ed received event 642 (and/or an indication of event 642) before events 644 (and/or indications of event 644). Thus, since more participants received event 644 prior to event 642, a general order may be specified by each participant to indicate that event 644 occurred prior to event 642.

In other cases, the database convergence module may use another function to calculate the total order from the partial order in the DAG based on hashes. In such embodiments, for example, the database convergence module may use the following functions to calculate the overall order, with the positive integer Q being a parameter shared by the participants.

creator(x) = participant who created event x, (creator)

anc(x) = set of events that are ancestors of x, including x itself

other(x) = event created by the member who synced just before x was created

self(x) = last event before x with same creator

self(x, 0) = self(x)

self(x, n) = self(self(x), n-1)

order(x, y) = k, where y is the kth event that creator(x) learned about

slow(w, z), и с разрушением равенств посредством хеша каждого событияfast(x, y) = position of y in the sorted list, with element z ∈ anc(x), sorted by

slow(w, z), and with the destruction of equalities through the hash of each event

In this embodiment, fast(x, y) gives the position of y in the overall order of events in the opinion of the creator(x) essentially immediately after the creation and/or definition of x. If Q is equal to infinity, then the above calculates the same overall order as obtained in the previously described embodiment. If Q is a finite number and all participants are online, then the above calculates the same general order as obtained in the previously described embodiment. If Q is a finite number and a minority of participants are online at a given point in time, then this function allows online participants to reach a consensus among themselves, which will remain unchanged as new participants gradually, one by one, come online. However, if it is a section of the network, then the participants in each section can come to their own consensus. Then, when the section is full, the members of the smaller section will accept the consensus of the larger section.

In yet other cases, as described with respect to FIG. 14-17b, the database convergence module may use yet another function to calculate the total order from the partial order in a DAG based on hashes. As shown in FIG. 14-15, each participant (Alice, Bob, Carol, Dave, and Ed) creates and/or defines events (1401-1413, as shown in Fig. 14; 1501-1506, shown in Fig. 15). When using the function and sub-functions described with respect to FIG. 14-17b, the overall order for events can be computed by sorting the events by their accepted round (also referred to herein as ordinal value), collapsing equalities by their adopted timestamp, and collapsing those equalities by their signatures, as described in more detail herein. document. In other cases, the overall order for events can be computed by sorting the events by their adopted round, collapsing the equalities by their adopted generation (instead of their adopted timestamp), and collapsing those equalities by their signatures. The following paragraphs define functions used to calculate and/or determine the received round and received event generation to determine the order for the events. The following terms are used and illustrated in connection with FIG. 14–17b.

Parent: Event X is the parent of event Y if Y contains the hash of X. For example, as shown in FIG. 14, the parents of event 1412 include event 1406 and event 1408.

"Ancestor": The ancestors of event X are X, its parents, its parents' parents, and so on. For example, as shown in FIG. 14, the ancestors of event 1412 are events 1401, 1402, 1403, 1406, 1408, and 1412. An event's ancestors can be said to be associated with this event, and vice versa.

"Descendant": The descendants of event X are X, its children, its children's children, and so on. For example, as shown in FIG. 14, a child of event 1401 is each event shown in the figure. As another example, the children of event 1403 are events 1403, 1404, 1406, 1407, 1409, 1410, 1411, 1412, and 1413. Children of an event can be said to be associated with this event and vice versa.

"N": total number of participants in the population. For example, as shown in FIG. 14, the participants are computing devices designated as Alice, Bob, Carol, Dave, and Ed, and N is five.

"M": The smallest integer that is greater than a certain percentage of N (for example, greater than 2/3 of N). For example, as shown in FIG. 14, if the percentage is defined as 2/3, then M is four. In other cases, M may be defined, for example, as another percentage of N (eg, 1/3, 1/2, etc.), a specific predetermined number, and/or any other suitable method.

"Self-parent": Event X's own parent is its parent event Y, created and/or defined by the same participant. For example, as shown in FIG. 14, event 1405's own parent is 1401.

"Self-ancestor": Event X's own ancestors are X, its own parent, its own parent's own parent, and so on.

"Sequence Number" or "SN": An integer attribute of the event, defined as the sequence number of the event's own parent plus one. For example, as shown in FIG. 14, event 1405's own parent is 1401. Since event 1401's sequence number is one, event 1405's sequence number is two (ie, one plus one).

"Generation Number" or "GN": An integer attribute of the event, defined as the maximum value of the generation numbers of the event's parents plus one. For example, as shown in FIG. 14, event 1412 has two parents, events 1406 and 1408, having generation numbers four and two, respectively. Thus, the generation number of event 1412 is five (that is, four plus one).

"Round Increment" or "RI": An event attribute that can be either zero or one.

"Round Number" or "RN": An integer attribute of the event. In some cases, the round number can be defined as the maximum value of the round numbers of the event's parents plus the round increment. For example, as shown in FIG. 14, event 1412 has two parents, events 1406 and 1408, both of which have a round number of one. Event 1412 also has a round increment of one. Thus, the round number of event 1412 is two (i.e., one plus one). In other cases, an event may have a round number R if R is the minimum integer such that the event can strictly see (as described herein) at least M events defined and/or created by different participants, all of which have a round number R -one. If there is no such integer, the round number for the event can be a default value (for example, 0, 1, etc.). In such cases, the round number for the event can be calculated without using the round increment. For example, as shown in FIG. 14, if M is defined as the smallest integer greater than 1/2 times N, then M is three. Then event 1412 strictly sees M events 1401, 1402, and 1408, each of which was determined by a different participant and has a round number of 1. Event 1412 cannot strictly see at least M events with a round number of 2, which were determined to be different. participants. Therefore, the round number for event 1412 is 2. In some cases, the first event in the distributed database has a round number of 1. In other cases, the first event in the distributed database may have a round number of 0, or any other suitable number.

"Forking": An event X together with an event Y are forks if they are defined and/or created by one participant and neither is the other's own ancestor. For example, as shown in FIG. 15, participant Dave creates a branch by creating and/or defining events 1503 and 1504, both of which have the same parent of their own (i.e., event 1501), so that event 1503 is not its own ancestor of event 1504, and event 1504 is not its own. ancestor of event 1503.

Branch "Identification": A branch can be "identified" by a third event created and/or defined after two events that together are branches, if both of these two events are ancestors of the third event. For example, as shown in FIG. 15, participant Dave creates a fork by creating events 1503 and 1504, neither of which is the other's own parent. This branch can be identified by a later event 1506, since both events 1503 and 1504 are ancestors of event 1506. In some cases, the identification of a branch may indicate that a particular participant (eg, Dave) is cheating.

Event "Identification": Event X "identifies" or "sees" an ancestor event of Y if X does not have an ancestor event of Z that branches along with Y. For example, as shown in FIG. 14, event 1412 identifies (i.e. "sees") event 1403 because event 1403 is an ancestor of event 1412 and event 1412 has no parent events that branch off event 1403. In some cases, event X may identify event Y, if X does not identify a branch prior to event Y. In such cases, even if event X identifies a branch created by the member that defines event Y after event Y, event X may see event Y. Event X does not identify that member's events after the branch. Moreover, if a participant identifies two different events that are both that participant's first events in history, the X event may identify a branch and not identify any of that participant's events.

"Strong identification" (also referred to herein as "strongly seeing" or "strict vision") of an event: event X "strongly identifies" (or "strongly sees") an ancestor event Y created and/or defined by the same participant as X if X identifies Y. An event X "strongly identifies" an ancestor event of Y that was not created and/or defined by the same participant as X if there exists a set S of events that (1 ) include both X and Y, and (2) are ancestors of event X, and (3) are children of event ancestor Y, and (4) are identified by X, and (5) each can identify Y, and (6) are created and/or defined by at least M different contributors. For example, as shown in FIG. 14, if M is defined as the smallest integer that is 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 an ancestor event 1401, since the set of events 1401, 1402, 1406, and 1412 is a set of at least four events that are ancestors of event 1412 and children of event 1401, and they are created and/or defined by the four participants 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, event X (e.g., event 1412) may "strongly see" event Y (e.g. , event 1401) if X can see at least M events (for example, events 1401, 1402, 1406, and 1412) created or defined by different participants, each of which can see Y.

"First event of R round" (also referred to herein as "witness" or "witness"): an event is an "first event of R round" (or "witness") if event (1) has an R round number and (2 ) has its own parent that has a round number less than R, or does not have its own parent. For example, as shown in FIG. 14, event 1412 is the "first event of round 2" because it has a round number of two and its own parent is event 1408, which has a round number of one (ie, less than two).

In some cases, the round increment for an event X is defined as 1 if and only if X "strongly identifies" at least M "first round events R", where R is the maximum round number of its parents. For example, as shown in FIG. 14, if M is defined as the smallest integer greater than 1/2 times N, then M is three. Then event 1412 strongly identifies M events 1401, 1402, and 1408, which are all first events of round 1. Both parents of event 1412 belong to round 1, and 1412 strongly identifies at least M first events of round 1, hence the round increment for 1412 is alone. Each of the events in the diagram labeled "RI=0" cannot strictly identify at least M first events of round 1, hence their round increments are 0.

In some cases, the following method can be used to determine whether event X can strongly identify ancestor event Y. For each first ancestor event Y of round R, an array A1 of integers, one per participant, is maintained that specifies the lowest sequence number of event X , where this participant created and/or defined event X, and X can identify Y. For each event Z, an array A2 of integers is maintained, one per participant, that specifies the highest sequence number of event W created and/or defined by this participant, so that Z can identify W. To determine whether Z can strongly identify an ancestor event of Y, the number of element positions E such that A1[E] <= A2[E] is counted. An event Z can strongly identify Y if and only if this count is greater than M. For example, as shown in FIG. 14, Alice, Bob, Carol, Dave, and Ed can each identify event 1401, with the earliest event that can do so being their event {1404, 1403, 1402, 1401, 1408}, respectively. These events have serial numbers A1={1,1,1,1,1}. Similarly, the latest event of each of them, which is identified by event 1412, is the event {NONE, 1406, 1402, 1401, 1412}, where Alice has "NONE" because 1412 cannot identify any of Alice's events. These events have sequence numbers A2={0,2,1,1,2} respectively, with all events having positive sequence numbers, so 0 means that Alice has no events that are identified by event 1412. When comparing list A1 with list A2 get the results {1<=0, 1<=2, 1<=1, 1<=1, 1<=2}, which is equivalent to {false, true, true, true, true}, where there are four values, which are true. Therefore, there is a set S of four events that are ancestors of event 1412 and descendants of event 1401. Four matches at least M, so 1412 strongly identifies 1401.

Yet another implementation of the method for determining, using A1 and A2, whether an event X can strongly identify an ancestor event Y is as follows. If the integer elements in both arrays are less than 128, then you can store each element in one byte and pack 8 such elements into one 64-bit word, and assume that A1 and A2 are arrays of such words. The most significant bit of each byte in A1 may be set to 0, and the most significant bit of each byte in A2 may be set to 1. The two corresponding words are subtracted, then a bitwise AND operation is performed using a mask to set all but the most significant bits to zero, then perform a right shift by 7 bit positions to obtain a value that is expressed in the C programming language as: ((A2[i] - A1[i]) & 0x8080808080808080) >> 7). This can be added to a register stack S that has been initialized to zero. After performing this action, convert the register to a counter many times by shifting and adding bytes to obtain ((S & 0xff) + ((S >> 8) & 0xff) + ((S >> 16) & 0xff) + ((S > > 24) & 0xff) + ((S >> 32) & 0xff) + ((S >> 40) & 0xff) + ((S >> 48) & 0xff) + ((S >> 56) & 0xff) ). In some cases, these calculations may be performed in programming languages such as C, Java, and/or the like. In other cases, calculations may be performed using processor-specific instructions such as the Advanced Vector Extensions (AVX) instructions provided by Intel and AMD, or the equivalent in a graphics processing unit (GPU) or general purpose graphics processing unit (GPGPU). On some architectures, calculations can be performed faster using words that are longer than 64 bits, such as 128, 256, 512 or more bits.

"Famous" event: Event X of round R is "known" if (1) event X is the "first event of round R" (or "witness"), and (2) a "YES" decision is reached by executing protocol of the Byzantine agreement described below. In some embodiments, the byzantine agreement protocol may be executed by a distributed database instance (eg, distributed database instance 114) and/or a database convergence module (eg, database convergence module 211). For example, as shown in FIG. 14, the first five events of round 1 are shown: 1401, 1402, 1403, 1404, and 1408. If M is defined as the smallest integer greater than 1/2 times N, which is three, then 1412 is the first event of round 2. If the protocol continues further, then the hash-based DAG will grow upwards, and as a result, the other four participants will also have the first round 2 events above the top of this figure. Each first round 2 event will have a "vote" as to whether each of the first round 1 events is "known". Event 1412 will vote YES for 1401, 1402 and 1403 being known as they are the first round 1 events it can identify. Event 1412 will vote NO against 1404 being known because 1412 cannot identify 1404. For a given first round 1 event such as 1402, the decision as to whether its status is known or not will be made based on the count votes for each first round 2 event as to whether it is known or not. These votes will then be propagated to the first events of Round 3, then to the first events of Round 4, and so on, until there is eventually agreement as to whether 1402 is known. A similar process is repeated for other first events.

The Protocol of the Byzantine Agreement may collect and use the votes and/or decisions of the "first round R events" to identify "known" events. For example, "first event Y of round R+1" will vote "YES" if Y can "identify" event X, otherwise it will vote "NO". The votes are then counted for each round G, for G = R+2, R+3, R+4, etc. until a decision is made by either participant. The votes are counted for each round of G until a decision is made. Some of these rounds may be "majority" rounds, while some of the other rounds may be "coin toss" rounds. In some cases, for example, the R+2 round is a majority round and future rounds are defined as either a majority round or a coin toss round (eg, according to a predetermined pattern). For example, in some cases it may be arbitrarily determined whether a future round is a majority round or a coin toss, provided that there cannot be two consecutive coin tosses. For example, it may be predetermined that there will be five majority rounds, then one coin toss, then five majority rounds, then one coin toss, repeating until agreement is reached.

In some cases, if round G is a majoritarian round, the votes may be counted as follows. If there is a G round event that strongly identifies at least M first G-1 round events voting V (where V is either "YES" or "NO"), then the consensus decision is V, and the Byzantine agreement protocol ends. Otherwise, each first event of round G computes a new vote, which is the solution of the majority of first events of round G-1 that each first event of round G can strongly identify. In cases of equality of votes and lack of a majority, the decision may be marked as "YES".

Similarly, if X is a witness of round R (or the first event of round R), then the results of voting in rounds R+1, R+2, and so on can be computed, with the witnesses in each round voting on whether X is known. . In the R+1 round, each witness who can see X votes YES and the other witnesses vote NO. In the R+2 round, each witness votes according to the majority of the votes of the R+1 round witnesses that he can strictly see. Similarly, in the R+3 round, each witness votes according to the majority vote of the R+2 witness that he can strictly see. This may go on for several rounds. In the event of a tie vote, the vote may be set to YES. In other cases, a tie vote may be set to NO or may be set at random. If any round has at least M witnesses voting NO, then the election ends and X is not known. If any round has at least M witnesses, a tie vote is YES, then the election ends and X is known. If neither YES nor NO has at least M votes, the election proceeds to the next round.

As an example, in FIG. 14 assumes the first event X of some round, which is below the figure shown. Then every first event of round 1 will have a vote as to whether X is known. Event 1412 can strictly identify the first events 1401, 1402 and 1408 of round 1. Thus, his vote will be based on their votes. If it is a majority round, then 1412 will check if at least M events {1401, 1402, 1408} have a YES vote. If they do, then the decision is YES and agreement has been reached. If at least M of them voted NO, then the decision is NO and agreement has been reached. If the number of votes is not at least M to either side, then 1412 receives a vote that represents a majority of the votes of events 1401, 1402, and 1408 (and breaks the tie with a YES vote if there was a tie). This vote will then be used in the next round, continuing until an agreement is reached.

In some cases, if round G is a coin toss, the votes may be counted as follows. If event X can identify at least M first round G-1 events voting V (where V is either "YES" or "NO"), then event X will change its vote to V. Otherwise, if round G is a round with a coin toss, every first event X of round G changes its vote to the result of a pseudo-random determination (similar to a coin toss in some cases), which is determined as the least significant bit of the X event signature.

Likewise, in such cases, if the election reaches an R+K (coin toss) round, where K is a certain coefficient (e.g., a multiple of a number such as 3, 6, 7, 8, 16, 32, or any other suitable number ), then the election does not end in this round. If the election reaches this round, it may continue for at least one more round. In such a round, if event Y is a witness to the R+K round, then if it can strictly see at least M witnesses from the R+K-1 round who vote V, Y will vote V. Otherwise, Y will vote according to a random value (e.g. , according to the signature bit of the Y event (e.g., the least significant bit, the most significant bit, a randomly selected bit), where 1=YES and 0=NO, or vice versa, according to the timestamp of the Y event, using a shared coin cryptographic protocol and/or any other random definition). This random definition is unpredictable until Y is created, and thus the security of the events and the consensus protocol can be improved.

For example, as shown in FIG. 14, if round 2 is a coin toss and there is a vote as to whether some event prior to round 1 was known, then event 1412 will first check if at least M events {1401, 1402, 1408} voted YES, or at least M of them voted NO. If so, then 1412 will vote the same. If at least M votes to either side are missing, then 1412 will have a random or pseudo-random vote (e.g. based on the least significant bit of the digital signature that Ed created for event 1412 when he signed it at the time of its creation and/or definition ).

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

The system may be based on any of the methods for calculating the result of the pseudo-random determination described above. In some cases, the system loops through different ways in some order. In other cases, the system may select among different methods according to a predetermined pattern.

"Received round": An event X has a "received round" R if R is the minimum integer such that at least half of the known first events of round R (or 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 case, event X has an "accepted round" R if R is the minimum integer such that at least a predetermined percentage (e.g., 40%, 60%, 80%, etc.) of known first events round R (or known witnesses) with round number R are descendants of X and/or can see X.

In some cases, the "accepted generation" of event X can be calculated as follows. Find which participant created and/or determined each first round event R that can identify event X. Then determine the generation number for that participant's earliest event that can identify X. Then determine the "accepted generation" X as the median of this list.

In some cases, the "received timestamp" T of event X may be the median of the timestamps in events that include the first event of each participant that identifies and/or sees X. For example, the received timestamp of event 1401 may be the median of the timestamp value for events 1402 , 1403, 1403, and 1408. In some cases, the timestamp for event 1401 may be included in the median calculation. In other cases, the received timestamp for X may be any other value, or a combination of the timestamp values in the events that are the first events of each participant to identify or see X. For example, the received timestamp for X may be based on the average of the timestamps, rms timestamp deviation, modified average (eg, by removing the earliest and latest timestamps from the calculation), and/or the like. In still other cases, the extended median may be used.

In some cases, the overall order and/or consensus order for events is computed by sorting the events by their accepted round (also referred to herein as ordinal value), collapsing equalities by their adopted timestamp, and collapsing those equalities by their signatures. In other cases, the overall order for the events can be computed by sorting the events by their adopted round, breaking down the equalities by their adopted generation, and breaking down those equalities by their signatures. The above paragraphs define functions used to calculate and/or determine the received round, received timestamp, and/or received event generation.

In other cases, instead of using the signature of each event, the signature of that event XORed with signatures of known events or known witnesses with the same received round and/or received generation in that round may be used. In other cases, any other suitable combination of event signatures can be used to break the equalities to determine the event consensus order.

In still other cases, instead of defining "accepted generation" as the median of the list, "accepted generation" may be defined as the list itself. Then, when sorted by the accepted generation, the two accepted generations can be compared by the middle elements of their lists, breaking down the equalities by the element just before the middle, breaking those equalities by the element just after the middle, and continuing to alternate between the element before the one used before and the element after, until equality is destroyed.

In some cases, the median timestamp may be replaced by "extended median". In such cases, a list of timestamps may be defined for each event, instead of a single received timestamp. The list of timestamps for event X may include the first event of each participant that identifies and/or sees X. For example, as shown in FIG. 14, the timestamp list for event 1401 may include the timestamps for events 1402, 1403, 1403, and 1408. In some cases, the timestamp for event 1401 may also be included. the same received round) the average timestamps of the list of each event (or the predetermined first or second of the two average timestamps if the length is even) can be compared. If these timestamps are the same, the timestamps directly after the middle timestamps can be compared. If these timestamps are the same, the timestamps just before the average timestamps can be compared. If these timestamps are also the same, the timestamps after the three timestamps already compared are compared. This alternation can continue until the equality is destroyed. Similar to the above discussion, if two lists are identical, the equality can be broken by the signatures of the two elements.

In still other cases, "truncated extended median" may be used in place of "expanded median". In such a case, the entire list of timestamps is not stored for each event. Instead, only a few values near the center of the list are stored and used for comparison.

The received median timestamp can potentially be used for other purposes in addition to calculating the overall order of events. For example, Bob could sign a contract stating that he is committed to the contract if and only if there is an event X containing a transaction in which Alice signs the same contract, and the received timestamp for X corresponds to a certain deadline. or an earlier point in time. In this case, Bob will not commit to the contract if Alice signs it after the deadline indicated by the "accepted median timestamp" as described above.

In some cases, the state of a distributed database can be determined after consensus has been reached. For example, if S(R) is a set of events that known bystanders in round R can see, the result is that all events in S(R) will have a known received round and received timestamp. At this stage, the consensus order for events in S(R) is known and will not change. When this stage is reached, the participant can calculate and/or determine the representation of events and their order. For example, a participant can compute the hash value of the events in S(R) in their consensus order. The participant can then digitally sign the hash value and include the hash value in the next event that the participant specifies. This can be used to alert other participants that this participant has determined that the events in S(R) are in a given order that will not change. After at least M participants (or any other suitable number or percentage of participants) have signed the hash value for S(R) (and thus agree on the order represented by the hash value), this event consensus list, along with the list of signatures participants can form a single file (or other data structure) that can be used to prove that the consensus order was as claimed for the events in S(R). In other cases, if the events contain transactions that update the state of the distributed database system (as described herein), then the hash value may represent the state of the distributed database system after applying the event transactions in S(R) in consensus order.

In some cases, M (as described above) may be based on weight values (also referred to herein as share values) assigned to each participant, rather than simply a fractional number, percentage, and/or total number of participants. In such a case, each participant has a share associated with his interest and/or influence in the distributed database system. Such a proportion may be a weight value and/or a fraction value. We can say that each event defined by this participant can have the weight value of its defining participant. Then M may be a fraction of the total share of all participants and may be referred to as a criterion and/or a threshold for the size of the share. The events described above as dependent on M will occur when a set of participants with a sum of shares of at least M comes to an agreement (i.e., satisfies the share size criterion). Thus, based on their stake, certain participants can have more influence over the system and how the consensus order is obtained. In some cases, a transaction in an event may change the stake of one or more participants, add new participants, and/or remove participants. If such a transaction has an accepted round R, then after calculating the accepted round, the events after round witnesses R will recalculate their round numbers and other information using the modified shares and the modified participant list. In some cases, votes on whether round R events are known may use the old stakes and list of participants, but votes on rounds after R may use the new stakes and list of participants.

In some additional cases, predetermined weights or stakes may be assigned to each member of the distributed database system. Accordingly, the consensus achieved through the Byzantine Agreement protocol can be implemented using an associated security layer to protect a group of participants or a population from potential Sibyl attacks. In some cases, this level of security can be mathematically guaranteed. For example, attackers may want to influence the outcome of one or more events by rearranging the partial order of events registered in the DAG based on hashes. The attack can be carried out by reorganizing one or more partial DAG orders based on hashes until a consensus and/or final agreement is reached among the participants in the distributed database. In some cases, there may be disagreement about the time at which several competing events occurred. As discussed above, the outcome associated with an event may depend on the value of M. As such, in some cases, determining which Alice or Bob performed the action first on an event (and/or a transaction within an event) can be made when the number of votes or the sum of the shares of voting members in the agreement is greater than or equal to M.

Some types of reordering attacks require the attacker to control at least a fraction or percentage (for example, 1/10, 1/4, 1/3, etc.) of N depending on the value of M. In some cases, the value of M can be adjusted to be, for example, 2/3 of the group or population N. In such a case, as long as more than 2/3 of the members of the group or population are not participants in the attack, agreement can be reached by participants who are not participating in the attack. attack, and the distributed database will continue to reach consensus and work as expected. Moreover, in such a case, the attacker must control at least N minus M (N-M) members of the group or population (1/3 of the members in this example) during the attack period in order to stop database convergence in order to cause distributed database convergence in favor of the attacker (for example, to cause a database to converge in an unfair order), to bring two different states together (for example, so that participants formally agree on both of two conflicting states), or to falsify a currency (when a distributed database system works with a cryptocurrency).

In some implementations, weights or shares may be assigned to each member of a group or population, and N will be the total sum of all their weights or shares. Accordingly, a higher weight or proportion may be assigned to a subset of a group of participants or a population based on a measure of confidence or reliability. For example, a higher weight or share value may be assigned to participants who are less likely to engage in an attack or who have some indicator that they are less likely to engage in dishonest activity.

In some cases, the security level of a distributed database system can be improved by choosing M to be a larger fraction of N. For example, when M is the smallest integer that is greater than 2/3 of the number of members of a group or population, N, and all participants have the same voting power, an attacker would need to have control or influence over at least 1/3 of N to prevent consensus among participants not taking part in the attack and to ensure that the distributed database cannot reach consensus . Similarly, in such a case, the attacker would need to have control or influence over at least 1/3 of N to cause distributed database convergence and/or reach an agreement in favor of the attacker (e.g., to cause database convergence in an unfair order), so that two different states converge (for example, so that participants formally agree on both of the two conflicting states) or to falsify a currency (when a distributed database system works with a cryptocurrency).

In some cases, for example, a dishonest participant may vote in two different ways to cause a distributed database to converge into two different states. If, for example, N=300 and 100 participants are dishonest, there are 200 honest participants, of which, for example, 100 voted "yes" and 100 voted "no" regarding the transaction. If 100 dishonest participants send a message (or event) to 100 honest participants who voted "yes" that 100 dishonest participants voted "yes", 100 honest participants who voted "yes" will assume that the final consensus is "yes" because they will assume that 2/3 of the participants voted "yes". Similarly, if 100 dishonest participants send a message (or event) to 100 honest participants who voted "no" that 100 dishonest participants voted "no", 100 honest participants who voted "no" will assume that the final consensus is "no" because they will assume that 2/3 of the participants voted "no". Thus, in this situation, some honest participants will believe that the consensus is "yes", while other honest participants will believe that the consensus is "no", which will cause the distributed database to converge to two different states. However, if the number of dishonest participants is less than 100, honest participants will eventually converge on one value (either yes or no), since dishonest participants will not be able to push the number of both yes and no votes over 200 ( i.e. 2/3 of N). Other suitable values of M may be used according to the characteristics and/or specific application requirements of the distributed database system.

In some additional cases where participants have unequal voting power, such as when the most trusted or trusted voters have a voting power (e.g., weight or share value) of one, and the remaining participants have a fraction of one, agreement can be reached, when the sum of the shares or weights reaches the value M. Thus, in some cases, agreement can sometimes be reached even when the majority of participants do not agree with the final decision, but the majority of reliable or trusted participants agree. In other words, the power of untrusted participants' votes can be weakened to prevent or mitigate possible attacks. Accordingly, in some cases, the level of security can be increased by requiring consensus among participants with a total share M, and not just the number M of participants. A higher value for M means that more of the share (for example, more participants in an unweighted system) must agree in order to cause distributed database convergence.

In some cases, a distributed database system may support a variety of participation security protocols, including but not limited to those shown in Table 1 and any combination thereof. The protocols shown in Table 1 describe a variety of methods for assigning a proportion or weight to members of a group or population. The protocols in Table 1 may be implemented using cryptocurrencies such as, for example, Bitcoin derived from the original cryptocurrency, a cryptocurrency defined in a distributed database system, or any other suitable type of cryptocurrency. Despite the description in relation to cryptocurrencies, in other cases, the protocols shown in Table 1 can be used in any other suitable distributed database system and with any other method of assigning shares.

TABLE 1

Example Security Participation Protocols Protocol name Description Proof of ownership Each participant can associate himself with one or more cryptocurrency wallets he owns, and his voting share is set to a value related to the total balance of those one or more cryptocurrency wallets. Burn Proof Similar to proof of stake, but participants prove that they destroyed or spent the cryptocurrency in question. In other words, a fee is paid to join the voting population, and the share of votes is proportional to the amount paid. Proof of Work Participants can earn shares of votes by completing computational tasks or solving puzzles. Unlike traditional cryptocurrencies, computational costs may entail earning a share of votes rather than mining blocks.
In this protocol, members of the population may be required to continue performing computational tasks or solving puzzles in order to keep up with the needs of the system and not lose their ability to maintain the security of the system. This protocol can also be configured to decrease vote shares over time to encourage continued participation by participants. By permission Each participant receives a share of votes exactly equal to one. Members may only be allowed to become a member if they have permission.
Permission to join a population may be based on a vote by existing members, proof of membership in some existing organization, or any other suitable condition. Hybrid Founders of a population can start with the same share of votes. Founders can invite other members to join the population, so the membership can explode. Each participant will share their own share of the votes with those they invite. So if a member invited 1000 virtual members, then all 1001 of them together would still have the same total vote share that that member originally had. So virtual users will not help in launching the Sibyl attack. Simple Each participant is provided with a share of votes corresponding to one unit. Any member can invite new members to join the population. New participants are provided with a share of votes corresponding to one unit.

The choice of one of the participation security protocols may depend on specific applications. For example, a hybrid protocol may be suitable for general low-value transactions, commercial collaboration applications, computer game applications, and other similar types of applications where the trade-off between security and minimal computational overhead leans towards the latter. A hybrid protocol can be effective in preventing a disruption or attack on a group of participants or a population by a single disgruntled participant.

As another example, a resolution protocol may be desirable when security requirements are of the highest priority and the members of the population are not completely unfamiliar or unknown to each other. The authorization protocol can be used to implement applications intended, for example, for banks and entities of this type of financial relationship, or entities that are members of a consortium. In such a case, the banks in the consortium may become members of the population, and each bank may have the restriction that it participates as one member. Accordingly, M can be set to the smallest integer that is greater than two-thirds of the population. Banks cannot mutually trust each other as separate entities, but can rely on the level of security provided by the distributed database system, which in this example limits the number of dishonest participants to no more than one-third of the banks in the population.

As another example, a burn proof protocol can be implemented when the population contains a large number of unfamiliar members or unknown members. In such a case, the attacker may gain control of a portion of the total share that exceeds the value specified for M. However, the entry fee may be set high enough that the cost of the attack exceeds any expected benefits or revenues.

As another example, a proof-of-stake protocol may be suitable for larger groups. A proof-of-stake protocol may be an optimal or desirable solution when there is a large group of participants who hold substantial amounts of cryptocurrencies in approximately equal amounts, and it is not foreseen or expected that the disrupting participant will collect a larger amount of cryptocurrencies than the amount that together owned by a large group of participants.

In other cases, other additional or more complex protocols may be derived from the protocol or combination of protocols shown in Table 1. For example, a distributed database system may be configured to implement a hybrid protocol that follows the resolution protocol for a predetermined period of time and ultimately allows participants to sell shares of votes to each other. As another example, a distributed database system may be configured to implement a proof-of-burn protocol and eventually transition to a proof-of-stake protocol when the value of the events or transactions involved reaches a threshold or predetermined value in the cryptocurrency.

The foregoing terms, definitions, and algorithms are used to illustrate the embodiments and concepts described with respect to FIG. 14–17b. In FIG. 16a and FIG. 16b illustrates a first exemplary application of the consensus method and/or process, shown in mathematical form. In FIG. 17a and fig. 17b illustrates a second exemplary application of the consensus method and/or process, shown in mathematical form.

In other cases, and as described in more detail herein, database convergence module 211 may initially determine a value vector for a parameter, and may update the value vector as additional values for the parameter are received from other computing devices. For example, database convergence module 211 can receive additional values for a parameter from other computing devices via communication module 212 . In some cases, the database convergence module may select a value for a parameter based on a determined and/or updated vector of values for the parameter, as described in more detail herein. In some embodiments, database convergence module 211 may also send a value for a parameter to other computing devices via communication module 212, as described in more detail herein.

In some embodiments, database convergence module 211 may send a signal to memory 220 to cause memory 220 to store (1) a determined and/or updated vector of values for a parameter and/or (2) a selected value for a parameter based on the determined and/or updated a vector of values for the parameter. For example, (1) a determined and/or updated value vector for a parameter and/or (2) a selected value for a parameter based on the determined and/or updated value vector for a parameter may be stored in a distributed database instance 221 implemented in memory 220. In some embodiments, distributed database instance 221 may be similar to distributed database instances 114, 124, 134, 144 of distributed database system 100 shown in FIG. one.

As shown in FIG. 2, the database convergence module 211 and the communication module 212 are shown in FIG. 2 as implemented in processor 210. In other embodiments, database convergence module 211 and/or communication module 212 may be implemented in memory 220. In still other embodiments, database convergence module 211 and/or communication module 212 may be hardware-based. software (e.g. ASIC, FPGA, etc.).

In FIG. 7 illustrates a signal flow diagram of two event timing computing devices, according to one embodiment. In particular, in some embodiments, distributed database instances 703 and 803 may exchange events to achieve convergence. Computing device 700 may choose to synchronize with computing device 800 randomly, based on relationship with computing device 700, based on proximity to computing device 700, based on an ordered list associated with computing device 700, and/or the like. In some embodiments, since computing device 800 may be selected by computing device 700 from a set of computing devices associated with a distributed database system, computing device 700 may select computing device 800 multiple times in a row or may not select computing device 800 for a while. In others embodiments, an indication of previously selected computing devices may be stored on computing device 700. In such embodiments, computing device 700 may wait until a predetermined number of selections have been made before being able to select computing device 800 again. As discussed above, distributed database instances 703 and 803 may be implemented in computing device memory 700 and computing device memory 800, respectively.

In FIG. 3-6 illustrate examples of hash-based DAGs according to one embodiment. There are five participants, each represented by a dark vertical line. Each circle represents an event. The two descending lines from the event represent the hashes of the previous two events. Each event in this example has two descending lines (one dark line to the same participant and one light line to the other participant), except for the first event of each participant. Time flows upward. In FIG. 3-6, the distributed database computing devices are labeled Alice, Bob, Carol, Dave, and Ed. It should be understood that such designations refer to computing devices that are structurally and functionally similar to computing devices 110, 120, 130, and 140 shown and described with respect to FIG. one.

Exemplary System 1: If computing device 700 is named Alice and computing device 800 is named Bob, then synchronization between them can be performed as illustrated in FIG. 7. Synchronization between Alice and Bob can be done as follows:

- Alice sends Bob the events stored in the distributed database 703 data.

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

-- hash of the last event created and/or defined by Bob;

-- hash of the last event created and/or defined by Alice;

-- Bob's digital signature of the above.

- Bob sends the events stored in the distributed database 803 to Alice.

- Alice creates and/or defines a new event.

- Alice sends this event to Bob.

- Alice calculates the overall order for events as a DAG function based on hashes.

- Bob calculates the overall order for the events as a function of the DAG based on the hashes.

At any given point in time, a participant may store the so far received events 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 the two earlier events, except for the original event (which has no parent hashes) and the first event for each new member (which has one parent event hash representing the event of the existing member who invited them to join). A diagram can be drawn to represent this set of events. It can show a vertical line for each participant, and a dot on that line for each event created and/or defined by that participant. A diagonal line is drawn between two dots whenever an event (higher dot) contains a hash of an earlier event (lower dot). An event can be said to be related to another event if that event can refer to another event via the hash of that event (either directly or through intermediate events).

For example, in FIG. 3 illustrates an example of a DAG 600 based on hashes. Event 602 is generated and/or defined by Bob as a result of synchronization with and after Carol. Event 602 contains a hash of event 604 (the previous event created and/or defined by Bob) and a hash of event 606 (the previous event created and/or defined by Carol). In some embodiments, for example, the hash of event 604 included in event 602 contains a pointer to its immediate parent events, events 608 and 610. As such, Bob can use event 602 to refer to events 608 and 610 and rebuild the DAG based on hashes using pointers to previous events. In some cases, event 602 can be said to be related to other events in the hash-based DAG 600 because event 602 can refer to each of the events in the hash-based DAG 600 through earlier ancestor events. For example, event 602 is associated with event 608 through event 604. As another example, event 602 is associated with event 616 through event 606 and event 612.

Exemplary System 2: A system based on Exemplary System 1, wherein the event also contains transaction payloads or other information to record. Such payload may be used to update events with any transactions and/or information that have occurred and/or have been determined since the immediate previous event of the computing device. For example, event 602 may include any transactions performed by Bob since event 604 was created and/or defined. Thus, while event 602 is synchronizing with other computing devices, Bob may share this information. Accordingly, transactions performed by Bob can be associated with an event and provided to other participants using events.

Exemplary System 3: A system based on Exemplary System 1, wherein the event also includes the current time and/or date, useful for debugging, diagnostics, and/or other purposes. The time and/or date may be a local time and/or date indicating when the computing device (eg, Bob) creates and/or determines the event. In such embodiments, such local time and/or date is not synchronized with other devices. In other embodiments, the implementation of the time and/or date can be synchronized on all devices (for example, when exchanging events). In yet other embodiments, a global timer may be used to determine the time and/or date.

Exemplary System 4: A system based on Exemplary System 1 in which Alice does not send Bob any events created and/or defined by Bob, nor any parent events of such an event. An event x is an ancestor of an event y if y contains the hash of x or y contains the hash of an event that is an ancestor of x. Similarly, in such embodiments, Bob sends events to Alice not yet stored by Alice, and does not send events already stored by Alice.

For example, in FIG. 4 illustrates an exemplary hash-based DAG 620 illustrating ancestor events (dotted circles) and descendant events (circles with stripes) of event 622 (black circle). The lines establish a partial order of events in which ancestors come before the black circle event and descendants come after the black circle event. The partial order does not indicate whether the white circle events come before or after the black circle event, so the overall order is used to determine their sequence. As another example, in FIG. 5 illustrates an exemplary hash-based DAG illustrating one particular event (solid circle) and the first time each participant receives an indication of that event (barred circles). When Carol synchronizes with Dave to create and/or define an event 624, Dave does not send event 622 ancestors to Carol, as Carol is already aware of and accepted such events. Instead, Dave sends events to Carol, which Carol still needs to receive and/or store in Carol's distributed database instance. In some embodiments, Dave can identify which events to send to Carol based on what the DAG based on Dave's hashes shows about which events Carol has previously received. Event 622 is an ancestor of event 626. Therefore, at the time of event 626, Dave has already received event 622. In FIG. Figure 4 shows that Dave received event 622 from Ed, who received event 622 from Bob, who received event 622 from Carol. Also, at the time of event 624, event 622 is the last event received by Dave that was created and/or defined by Carol. Therefore, Dave can send Carol events that Dave saved that are different from event 622 and its ancestors. Additionally, after receiving event 626 from Dave, Carol can rebuild the DAG based on hashes using pointers in events stored in Carol's distributed database instance. In other embodiments, Dave can identify which events to send to Carol based on Carol's sending event 622 to Dave (not shown in FIG. 4) and identifying by event 622 (and references therein) by Dave to identify events that Carol already accepted.

Exemplary System 5: A system based on Exemplary System 1 in which both participants send events to each other in such an order that the event is sent only after the receiver has accepted and/or stored the ancestors of that event. Accordingly, the sender sends events from oldest to newest, so that the receiver can check the two hashes in each event when receiving the event by comparing the two hashes with the two ancestor events that have already been received. The sender can identify which events to send to the recipient based on the current state of the DAG based on the sender's hashes (eg, a database state variable defined by the sender) and which hash-based DAGs indicate which the recipient has already received. Referring to FIG. 3, for example, when Bob synchronizes with Carol to determine event 602, Carol may identify that event 619 is the last event created and/or determined by Bob that Carol received. Therefore, Carol can determine what Bob knows about this event and its ancestors. Thus, Carol can send event 618 and event 616 to Bob first (ie, the oldest events that Bob still needs to receive from Carol's received). Carol can then send event 612 and then event 606 to Bob. This allows Bob to easily chain events and rebuild the DAG based on Bob's hashes. Using a DAG based on Carol's hashes to identify which events Bob still needs to receive can improve synchronization efficiency and can reduce network traffic because Bob doesn't request events from Carol.

In other embodiments, the most recent event may be sent first. If the receiver determines (based on the hash of the two previous events in the most recent event and/or pointers to previous events in the most recent event) that it has not yet received one of the two previous events, the receiver may request the sender to send such events. This may continue until the receiver accepts and/or stores the ancestors of the most recent event. Referring to FIG. 3, in such embodiments, for example, when Bob receives event 606 from Carol, Bob can identify the hash of event 612 and event 614 in event 606. Bob can determine that event 614 was previously received from Alice when creating and/or defining event 604 Therefore, Bob does not need to request event 614 from Carol. Bob may 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 hashes in event 612, that Bob did not receive events 616 or 618, and can request those events from Carol accordingly. Based on events 616 and 618, Bob will then be able to determine that he has adopted the ancestors of event 606.

Exemplary System 6: A system based on Exemplary System 5 with the additional constraint that when a participant has a choice between multiple events to send next, the event is selected to minimize the total number of bytes sent so far, created and/or defined by this member. For example, if Alice only has two events left to send Bob, and one of them is 100 bytes long and was created and/or defined by Carol, and the other is 10 bytes long and was created and/or defined by Dave, and is currently in the process of Since Alice has already sent 200 bytes of events to Carol and 210 to Dave, Alice should first send an event to Dave and then send an event to Carol. Because 210 + 10 < 100 + 200. This can be used to prevent attacks where a single participant emits either one huge event or a stream of small events. In the event that the traffic exceeds the majority byte limit (as discussed with respect to exemplary system 7), the method of exemplary system 6 can ensure that malicious events are ignored rather than legitimate user events. Similarly, attacks can be mitigated by sending smaller events before larger events (to protect against one huge event clogging the communication channel). Moreover, if a participant cannot send each of the events in one sync (for example, due to network restrictions, participant byte limits, etc.), then this participant can send multiple events from each participant, instead of a simple send events defined and/or created by the attacker, and none (of several) events created and/or defined by other participants.

Exemplary System 7: A system based on Exemplary System 1 with an additional first step in which Bob sends Alice a number indicating the maximum number of bytes he wishes to receive during this synchronization, and Alice responds with a message with her limit. Alice then stops sending if the next event would exceed this limit. Bob does the same. In such an embodiment, this limits the number of bytes transmitted. This may increase the convergence time, but will reduce the amount of network traffic to sync.

Exemplary System 8: A system based on Exemplary System 1 in which the following steps are added at the beginning of the synchronization process:

- Alice identifies S, the set of events she received and/or stored, skipping events that were created and/or defined by Bob or that are ancestors of events created and/or defined by Bob.

- Alice identifies the participants who created and/or defined each event in S and sends Bob a list of participant ID numbers. Alice also sends the number of events that have been created and/or defined by each participant that she has already accepted and/or saved.

- Bob responds with a list of how many events he received, those created and/or defined by other participants.

- Alice then sends Bob only the events that he has yet to accept. For example, if Alice indicates to Bob that she has received 100 events created and/or defined by Carol, and Bob responds that he has received 95 events created and/or defined by Carol, then Alice will send only the 5 most recent events created and/or defined by Carol. certain Carol.

Exemplary System 9: A system based on Exemplary System 1 with an additional mechanism for identifying and/or eliminating fraudsters. Each event contains two hashes, one from the last event created and/or defined by that participant ("own hash"), and one from the last event created and/or defined by another participant ("foreign hash"). If a participant creates and/or defines two different events with the same own hash, then this participant is a "scammer". If Alice determines that Dave is a cheater by receiving two different events created and/or defined by him using the same hash of his own, then Alice keeps the indicator that Dave is a cheater and avoids synchronizing with him in the future. If she establishes that he is a cheater, but still syncs with him again and creates and/or defines a new event that records this fact, then Alice becomes a cheater too, and other participants who learn that Alice subsequently synced with Dave stop synchronize with Alice. In some embodiments, this affects only one-way timing. For example, when Alice sends a list of IDs and the number of events she received for each participant, she does not send an ID or count for the cheater, so Bob will not respond with any corresponding number. Alice then sends Bob the rogue events that she accepted and for which she did not accept an indication that Bob accepted such events. After this sync is complete, Bob will also be able to determine that Dave is a scammer (if he hasn't already identified Dave as a scammer), and Bob will also opt out of syncing with the scammer.

Exemplary System 10: A system based on Exemplary System 9 with the addition that Alice initiates the synchronization process by sending Bob a list of fraudsters that she has identified and whose events she still holds, and Bob responds with a message indicating any fraudsters that he has identified in addition to the scammers identified by Alice. They then continue as normal, but without counting cheaters while syncing with each other.

Exemplary System 11: A system based on Exemplary System 1 with a process that continually updates the current state (eg, captured by a database state variable defined by a system member) based on transactions in any new events that are received during synchronization. It may also include a second process that continually rebuilds that state (eg, the order of events) each time the sequence of events changes by reverting to a copy of the earlier state and recomputing the present state by processing the events in the new order. In some embodiments, the current state is the state, balance, condition, and/or the like associated with the outcome of transactions. Similarly, the state may include a data structure and/or variables modified by transactions. For example, if the transactions are money transfers between bank accounts, then the current state could be the current balance of the accounts. As another example, if the transactions are related to a multiplayer game, the current state may be the location, number of lives, items received, game state, and/or the like associated with the game.

Exemplary System 12: A system based on Exemplary System 11, accelerated by using a "fast clone" arrayList to maintain state (eg, bank account balance, game state, etc.). A cloneable ArrayList is a data structure that acts like an array with one additional feature: it supports the "clone" operation, which is the creation and/or definition of a new object that is a copy of the original. The clone acts as if it were an exact copy, since the changes the clone undergoes do not affect the original. However, the clone operation is faster than making an exact copy, because creating a clone does not actually involve copying and/or updating the entire contents of one arrayList into another. Instead of having two clones and/or copies of the original list, two small objects can be used, each with a hash table and a pointer to the original list. When a clone is written to, the hash table remembers which element was modified and the new value. When reading from a position, the hash table is checked first, and if that element has been modified, the new value from the hash table is returned. Otherwise, this element is returned from the original arrayList. Thus, the two "clones" are initially just pointers to the original arrayList. But since each of them is constantly being modified, they expand so much that they have a large hash table that stores the differences between them and the original list. Clones themselves can be cloned, which causes the data structure to expand into a tree of objects, each with its own hash table and pointer to its parent. Therefore, the read causes a climb up the tree until either the vertex that has the requested data is set or the root is reached. If a node becomes too large or complex, then it can be replaced with an exact copy of the parent, changes to the hash table can be translated into the copy, and the hash table removed. Also, if the clone is no longer needed, it can be removed from the tree during garbage collection and the tree can be collapsed.

Exemplary System 13: A system based on Exemplary System 11 accelerated by using a "fast clone" hash table to maintain state (eg, bank account balance, game state, etc.). It is similar to system 12, except that the root of the tree is a hash table rather than an arrayList.

Exemplary System 14: A system based on Exemplary System 11 accelerated by using a "fast clone" relational database to maintain state (eg, bank account balance, game state, etc.). It is an object that acts as a wrapper around an existing relational database management system (RDBMS). Each explicit "clone" is actually an object with an ID number and a pointer to the object containing the database. When user code tries to send a Structured Query Language (SQL) query to a database, then the query is first modified and then sent to the actual database. The real database is identical to the database in terms of client code, except that each table has one additional field for the clone ID. For example, suppose there is an original database with a clone ID of 1, and then two database clones are created with IDs of 2 and 3. Each row in each table will have the value 1, 2, or 3 in the clone ID field. When a request comes from user code on clone 2, the request is modified so that the request will only read from lines that have a value of 2 or 1 in this field. Similarly, queries against clone 3 read rows with an ID of 3 or 1. If a Structured Query Language (SQL) command goes to clone 2 and says to delete a row, and that row has a 1, then the command should simply change 1 to 3, which marks the row as no longer shared between clones 2 and 3, and is now only visible to clone 3. If there are multiple working clones, then multiple copies of the row can be inserted, and each one can be set to a different clone ID, so that new rows are visible to all clones except for the clone that just "deleted" the row. Similarly, if a row is added to clone 2, then the row is added to the table with an ID of 2. Modifying the row is equivalent to deleting followed by an insert. As before, if multiple clones are removed during garbage collection, then the tree can be simplified. The structure of this tree will be stored in an additional table that is inaccessible to clones, but which is fully used internally.

Exemplary System 15: A system based on Exemplary System 11 accelerated by using a "fast clone" file system for state maintenance. It is an object that acts as a wrapper around the file system. The file system is built on top of the existing file system, using a relational database with fast cloning to manage different versions of the file system. The underlying file system stores a large number of files, either in a single directory or separated by file name (to keep directories small). The directory tree may be stored in the database and not provided to the underlying file system. When a file or directory is cloned, the "clone" is just an object with an ID number, and the database is modified to reflect that the clone now exists. If a quick clone file system is cloned, it appears to the user as if a whole new hard drive had been created and/or defined, initialized using a copy of the existing hard drive. Changes to one copy may not affect other copies. There is really only one copy of each file or directory, and copying occurs when a file is modified by a single clone.

Exemplary System 16: A system based on Exemplary System 15 in which a separate file is created and/or defined in the base operating system for each N-byte file portion in the fast clone file system. N may be some suitable size, such as 4096 or 1024, for example. Thus, if one byte is changed in a large file, only one block of the large file is copied and modified. It also improves efficiency when storing many files on disk that differ by only a few bytes.

Exemplary System 17: A system based on Exemplary System 11, where each participant includes in some or all of the events it creates and/or defines a hash of the state at some previous point in time along with the number of events that have occurred up to that point, indicating that the participant recognizes and/or identifies that a consensus has now been reached on the order of events. Once a participant has collected signed events containing such a hash from a majority of users for a given state, the participant can then store this as proof of the consensus state at that point and delete events and transactions up to that point from memory.

Exemplary System 18: A system based on Exemplary System 1 where the operations that calculate the median or majority are replaced by a weighted median or a weighted majority, with participants weighted according to their "share". Share is a number that indicates how much a member's vote means. The stake can be cryptocurrency assets or just an arbitrary number that is assigned when a member is first invited to join and then split among the new members that the member invited to join. Old events can be deleted when enough participants agree to the consensus state so that their total share is the majority of the share available. If the overall order is computed using the median of the ranks contributed by the participants, then the result is the number where half of the participants are higher ranked and half are lower ranked. On the other hand, if the overall order is computed using a weighted median, then the result is a number where approximately half of the total share is associated with ranks below that and half above. Weighted voting and medians can be useful in preventing a Sybil attack, where one participant invites a huge number of "virtual" users to join, each of which is just an alias under the control of the inviting participant. If the inviter is forced to share their share with the invitees, then the virtual users will be useless for the attacker to try to control the outcome of the consensus. Accordingly, proof of ownership may be useful in some circumstances.

Exemplary System 19: A system based on Exemplary System 1 in which, instead of a single distributed database, there are multiple databases in a hierarchy. For example, there may be one database whose users are members, as well as several smaller databases or "blocks", each with a subset of members. When events occur in a block, they are synchronized among members of that block, but not among members outside of that block. Then, periodically after deciding on the consensus order in the block, the resulting state (or events with their overall consensus order) can be shared by the entire membership of the large database.

Exemplary system 20: A system based on exemplary system 11 with the possibility of having an event that updates the software to update a state (eg, a fixed database state variable defined by a system member). For example, events X and Y may contain transactions that modify the state according to code that reads the transactions in those events and then updates the state accordingly. The Z event may then contain a notification that a new version of the software is now available. If the general order says that events occur in X, Z, Y order, then the state can be updated by processing transactions in X using the old software, and then transactions in Y using the new software. But if the consensus order was X, Y, Z, then both X and Y could be updated using old software that could give a different end state. Therefore, in such embodiments, a code update notification can appear in an event so that the community can reach a consensus on when to migrate from the old version to the new version. This ensures that participants maintain synchronized states. It also ensures that the system can stay running even during updates without having to reboot or restart the process.

Exemplary System 21: A system based on Exemplary System 1 where a proof-of-stake protocol is implemented to achieve consensus, and the power of each participant's vote is proportional to the amount of cryptocurrency the participant owns. The cryptocurrency of this example will be referred to hereinafter as the StakeCoin currency. Participation in a group or population is open, meaning it does not require permission, so there may be a lack of trust among participants.

The proof of stake protocol may be less computationally expensive than other protocols, such as the proof of work protocol. In this example, M (as described above) could be 2/3 of the StakeCoin currency jointly owned by the participants. Thus, a distributed database system can be secure (and can converge properly) if an attacker cannot obtain 1/3 of the total amount of StakeCoin currency that the participants involved together own. The distributed database system can continue to operate with a mathematically secure level as long as more than 2/3 of the amount of the StakeCoin currency is owned by honest active participants. This ensures proper database convergence.

A way for an attacker to gain control of the distributed database system can be achieved by negotiating individually with StakeCoin currency holders in the distributed database system to purchase their StakeCoin currency. For example, Alice can get most of the StakeCoin by purchasing the StakeCoin currency owned by Bob, Carol, and Dave, which puts Ed in a vulnerable position. This is similar to speculative buying of goods in the market or trying to buy enough shares of a company for an aggressive takeover. The described scenario represents not only an attack on a distributed database system that uses the StakeCoin currency, but also an attack on the StakeCoin currency itself. If a participant obtains a near-monopoly on the cryptocurrency, such a participant can control the price of the cryptocurrency and arrange itself in such a way as to constantly sell high and buy low. This may be beneficial in the short term, but it could ultimately undermine the credibility of cryptocurrencies and possibly lead everyone to abandon it. The market value of a currency may not depend on the technology used to transfer the currency. For example, if a person or entity were to acquire ownership of most of the world's US dollars or most of the world's grain futures, that person or entity could profitably disrupt the market.

An attack carried out by obtaining a near monopoly on a cryptocurrency is more difficult if the cryptocurrency is both valuable and widespread. If the cryptocurrency is valuable, then buying a large part of the stock of StakeCoin currency will be very expensive. If a cryptocurrency is widespread, with many different people owning the StakeCoin currency, attempts to monopolize the StakeCoin market will become apparent early on, which will naturally drive up the price of StakeCoin, making it even more difficult to obtain the rest of the currency supply.

The second type of attack can be performed by obtaining an amount in StakeCoin currency, which can be small compared to the total amount of StakeCoin currency on multiple distributed database systems, but large compared to the amount of StakeCoin currency held by participants involved in a particular system. distributed database. This type of attack can be prevented if the cryptocurrency is specifically defined for use in a distributed database system application. In other words, the StakeCoin currency and the implementation of the distributed database system can be simultaneously defined as related to each other, and each contributes to the value of the other. Likewise, there are no additional distributed database implementations that trade the StakeCoin currency.

It may be desirable to have an expensive cryptocurrency from the very beginning, when the implementation of the distributed database system has just been defined. Even though the value of a cryptocurrency can increase over time, an expensive cryptocurrency can be profitable in the early stages of the system. In some cases, a consortium of involved entities may initiate a cryptocurrency and an associated distributed database system. For example, ten large, respected corporations or organizations that are founders can be given a significant amount of StakeCoin currency to launch the StakeCoin cryptocurrency and distributed database system. The system can be designed in such a way that the supply of cryptocurrency does not grow quickly and has some finite volume limit. Each founding entity may be motivated to participate as a participant in a distributed database system and implementation of the StakeCoin currency (for example, implemented as a distributed database system that can be structured as a hash-based DAG with a consensus algorithm). Because there is no proof-of-work, it can be inexpensive to be a contributor who operates a node. The founding entities can be trustworthy enough that it is unlikely that any large part of them will collude to undermine the system, in particular as this could destroy the value of the StakeCoin they hold and the implemented distributed database system.

In some implementations, other participants may join the distributed database system, and other people or entities may purchase the StakeCoin either directly from the founding entities or on an exchange. The distributed database system can be configured to motivate participants to participate by paying small amounts of StakeCoin for participation. Over time, the system can become much more distributed, with stake eventually dispersed such that it becomes difficult for any person or entity to monopolize the market, even if the founding entities collude to carry out an attack. At this stage, the cryptocurrency can gain independent value; a distributed database system may have an independent security layer; and the system can be open without permission restrictions (for example, without the need to obtain an invitation from the founder to join). Thus, there is a saving in the regular computational overhead required by systems implemented using alternative protocols, such as systems implemented using proof-of-work protocols.

While the description above relates to using a distributed database using a hash-based DAG, any other suitable distributed database protocol may be used to implement the exemplary system 21. For example, while the specific exemplary numbers and proportion may vary, the exemplary system 21 may be used to enhancing the security of any suitable distributed database system.

The systems described above are expected to create and/or provide an efficient convergence mechanism for distributed consensus with eventual consensus. Several theorems can be proved about this, as shown below.

Sample Theorem 1: If event x precedes event y in partial order, then in a given participant's knowledge of the other participants at a given point in time, each of the other participants has either accepted an indication of x before y or has not yet accepted an indication of y.

Proof: If event x precedes event y in partial order, then x is an ancestor of y. When a participant receives an indication of y for the first time, that participant has either already received an indication of x previously (in which case it knows about x before y) or it will be the case that synchronization provides this participant with both x and y (in which case what it learns about x before y during that synchronization, since events received during one synchronization are considered to be received in order consistent with progeny relationships as described with respect to exemplary system 5). Q.E.D.

Sample Theorem 2: For any given hash-based DAG, if x precedes y in partial order, then x will precede y in the overall order computed for that hash-based DAG.

Proof: If x precedes y in partial order, then according to Theorem 1:

for all i, rank(i,x) < rank(i,y),

where rank(i,x) is the rank assigned by participant i to event x, which is 1 if x is the first event received by participant i, 2 if the second, and so on. Assume that med(x) is the median of rank(i,x) for all i, and similarly for med(y).

Given k, choose i1 and i2 such that rank(i1,x) is the k-th smallest rank of x and rank(i2,y) is the k-th smallest rank of y. Then:

rank(i1,x) < rank(i2,y).

This is because rank(i2,y) is greater than or equal to k ranks of y, each strictly greater than the corresponding rank of x. Therefore, rank(i2,y) strictly exceeds at least k ranks of x, and hence strictly exceeds the k-th smallest rank of x. This argument is valid for any k.

Let's say n is the number of participants (which is the number of i values). Then n must be either odd or even. If n is odd, then let's say that k=(n+1)/2, and the k-th smallest rank will be the median. Therefore, med(x) < med(y). If n is even, then when k=n/2, the k-th smallest rank of x will be strictly less than the k-th smallest rank of y, and also the (k+1)-th smallest rank of x will be strictly less than (k +1)-th smallest rank of y. Therefore, the average of the two x ranks will be less than the average of the two y ranks. Therefore, med(x) < med(y). Therefore, in both cases, the median of x-ranks is strictly less than the median of y-ranks. Therefore, if the overall order is determined by sorting the activities by median rank, then the x event will precede the y event in the overall order. Q.E.D.

Sample Theorem 3: If "transmission period" is the amount of time required for existing events to propagate through synchronization to all participants, then:

after 1 transfer period: all participants accepted the events,

after 2 transmission periods: all participants agree on the order of these events,

after 3 transmission periods: all participants know that agreement has been reached,

after 4 transmission periods: all participants receive digital signatures from all other participants endorsing this consensus order.

Proof: Assume that S0 is a set of events that have been created and/or defined up to a given time T0. If each participant ends up synchronizing with each of the other participants an infinite number of times, then with probability equal to 1, there will eventually be a point in time T1 by which the events in S0 will propagate to each participant, so that each participant will be aware of all events. This is the end of the first transmission period. Assume that S1 is a set of events that exist at time T1 and that did not yet exist at time T0. Then, with probability equal to 1, there will eventually be a time T2 at which each participant will accept each of the events in the set S1 that is in existence at time T1. This is the end of the second transmission period. Similarly, T3 represents the point in time when all events in S2 that exist up to time T2 but not before time T1 have propagated to all participants. Note that each transmission period eventually ends with a probability of 1. On average, each period will last as long as it takes to complete log2(n) synchronizations if there are n participants.

By time T1, each participant will have received every event in S0.

By time T2, the given participant Alice will have received the record of each of the other participants receiving each event in S0. Therefore, Alice can calculate the rank for each action in S0 for each participant (which is the order in which that participant took that action), and then sort the events by the median of the ranks. The resulting overall order does not change for events in S0. This is because the resulting order is a function of the order in which each participant first received an indication of each of these events, which does not change. It is possible that the order computed by Alice will have several events from S1 scattered among the events of S0. These S1 events may still vary where they fall in the sequence S0 of events. But the relative order of events in S0 will not change.

By time T3, Alice knows the general order on the union S0 and S1, and the relative order of events in this union will not change. In addition, it can find the earliest event from S1 in this sequence and can conclude that the sequence of events before S1 will not change, even by inserting new events not from S0. Hence, by time T3, Alice can determine that a consensus has been reached for the order of events in history prior to the first event S1. She can digitally sign the hash of the state (eg, captured by a database state variable defined by Alice) resulting from these events occurring in that order, and send the signature as part of the next event she creates and/or defines.

By time T4, Alice will have accepted similar signatures from other participants. At this point, she can simply store this list of signatures, along with the state they are evidence of, and she can delete the events she has stored prior to the first S1 event. Q.E.D.

The systems described in this document describe a distributed database that achieves consensus quickly and securely. It can be a useful building block for many applications. For example, if transactions describe the transfer of cryptocurrency from one cryptocurrency wallet to another, and if the state is a simple measure of the current amount in each wallet, then this system would be a cryptocurrency system that avoids the expensive proof of work used in existing systems. Automatic compliance with the rules allows you to add signs that are not common in existing cryptocurrencies. For example, lost coins can be recovered to avoid deflation by enforcing a rule stating that if a wallet neither sends nor receives cryptocurrency within a certain period of time, then that wallet is deleted and its contents are distributed to other existing wallets in proportion to the amount they currently contain. Thus, the supply of money will not grow or shrink even if the private key for the wallet is lost.

Another example is a distributed game that acts like a Massively Multiplayer Online (MMO) game played on a server but achieves this without the use of a central server. Consensus can be reached without any central server exercising control.

Another example is a social networking system that is built on top of such a database. Because transactions are digitally signed and participants accept information about other participants, this provides security and convenience advantages over current systems. For example, an email system with a strict anti-spam policy can be implemented because emails cannot have fake return addresses. Such a system could also become a unified social system, combining in one distributed database the functions currently performed by email, tweets, text messages, forums, wikis, and/or other social resources.

Other applications may include more complex cryptographic features, such as group digital signatures, in which the group acts as a unit to sign a contract or document. These and other forms of multiparty computation can be efficiently implemented using such a distributed consensus system.

Another example is the public registry system. Anyone can pay to keep some information in the system, while paying a small amount of cryptocurrency (or real currency) per byte per year to store information in the system. This cash can then be automatically distributed to the participants who store this data and to the participants who are constantly in sync to work towards consensus. Participants can automatically receive a small amount of cryptocurrency each time they sync.

These examples show that a distributed database with consensus is useful as a component of many applications. Because the database does not use expensive proof-of-work, instead using less expensive proof-of-stake when possible, the database can run with a full node running on less powerful computers or even mobile and embedded devices.

Although described above as an event containing a hash of two previous events (one own hash and one foreign hash), in other embodiments, a participant may synchronize with two other participants to create and/or define an event containing the hashes of the three previous events (one own hash and two foreign hashes). In still other embodiments, any number of event hashes of previous events from any number of participants can be included in an event. In some embodiments, different events may include different numbers of hashes of previous events. For example, the first event may include two event hashes, and the second event may include three event hashes.

While events are described above as including hashes (or cryptographic hash values) of previous events, in other embodiments, an event may be constructed and/or defined to include a pointer, identifier, and/or any other suitable reference to previous events. For example, an event may be created and/or defined to include a serial number associated with a previous event and used to identify it, thus linking the events. In some embodiments, such a serial number may include, for example, an identifier (e.g., a media access control (MAC) address, an Internet protocol (IP) address, an assigned address, and/or the like) associated with the participant that created the and/or defined an event, and the order of the event defined by that participant. For example, if a member has an ID of 10 and the event is the 15th event created and/or defined by that member, then the member may assign an ID of 1015 to that event. In other embodiments, any other suitable format may be used to assign event identifiers.

In other embodiments, the events may contain complete cryptographic hashes, but only parts of these hashes are transmitted during synchronization. For example, if Alice sends Bob an event containing hash H, and J is the first 3 bytes of H, and Alice determines that out of all the events and hashes she has stored, H is the only hash that starts with J, then she can send J instead H during synchronization. If Bob then determines that he has another hash starting with J, then he can send a response message to Alice requesting the full H. This way the hashes can be compressed during transmission.

Although the exemplary systems shown and described above have been described with reference to other systems, in other embodiments, any combination of exemplary systems and associated functionality may be implemented to create and/or define a distributed database. For example, exemplary system 1, exemplary system 2, and exemplary system 3 may be combined to create and/or define a distributed database. As another example, in some embodiments, exemplary system 10 may be implemented with exemplary system 1 but without exemplary system 9. As yet another example, exemplary system 7 may be combined and implemented with exemplary system 6. In still others embodiments, any other suitable combinations of exemplary systems may be implemented.

Although described above as performing event exchange to achieve convergence, in other embodiments, distributed database instances may exchange values and/or value vectors to achieve convergence, as described with respect to FIG. 8–13. In particular, for example, in FIG. 8 illustrates information flow between a first computing device 400 from a distributed database system (eg, distributed database system 100) and a second computing device 500 from a distributed database system (eg, distributed database system 100) according to one embodiment. In some embodiments, computing devices 400, 500 may be structurally and/or functionally similar to computing device 200 shown in FIG. 2. In some embodiments, computing device 400 and computing device 500 communicate with each other in a manner similar to how computing devices 110, 120, 130, 140 communicate with each other in distributed database system 100 shown and described with respect to FIG. one.

Like computing device 200 described with respect to FIG. 2, each of the computing devices 400, 500 may initially determine a value vector for the parameter, update the value vector, select a value for the parameter based on the determined and/or updated value vector for the parameter, and store (1) the determined and/or updated value vector for the parameter. and/or (2) a selected value for the parameter based on the determined and/or updated vector of values for the parameter. Each of computing devices 400, 500 may initially determine a vector of values for a parameter in any number of ways. For example, each of the computing devices 400, 500 may initially determine a value vector for a parameter by setting each value from the value vector to a value originally stored in distributed database instances 403, 503, respectively. As another example, each of the computing devices 400, 500 may initially determine a value vector for a parameter by setting each value from the value vector to a random value. The method of initially determining the value vector for a parameter may be chosen, for example, by an administrator of the distributed database system to which computing devices 400, 500 belong, or individually or collectively by computing device users (e.g., computing devices 400, 500) of the distributed database system.

Each of the computing devices 400, 500 may also store a vector of values for a parameter and/or a selected value for a parameter in distributed database instances 403, 503, respectively. Each of the distributed database instances 403, 503 may be implemented in a memory (not shown in FIG. 8) similar to memory 220 shown in FIG. 2.

In step 1, computing device 400 queries computing device 500 for a value for a parameter stored in distributed database instance 503 of computing device 500 (eg, a value stored in a particular 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 associated with a distributed database system. Computing device 500 may be randomly selected, selected based on relationship with computing device 400, based on proximity to computing device 400, selected based on an ordered list associated with computing device 400, and/or the like. In some embodiments, since computing device 500 may be selected by computing device 400 from a set of computing devices associated with a distributed database system, computing device 400 may select computing device 500 multiple times in a row or may not select computing device 500 for a while. In others embodiments, an indication of previously selected computing devices may be stored on computing device 400. In such embodiments, computing device 400 may wait until a predetermined number of selections have been made before being able to select computing device 500 again. As explained above, distributed database instance 503 may be implemented in memory of computing device 500.

In some embodiments, the request from computing device 400 may be a signal sent by a communication module of computing device 400 (not shown in FIG. 8). This signal may be transmitted over a network, such as network 105 (shown in FIG. 1), and received by the communication module of computing device 500. In some embodiments, each of the communication modules of computing devices 400, 500 may be implemented in a processor or memory. For example, communication modules of computing devices 400, 500 may be similar to communication module 212 shown in FIG. 2.

Upon receiving from computing device 400 a request for a parameter value stored in distributed database instance 503, computing device 500 sends the parameter value stored in distributed database instance 503 to computing device 400 in step 2. In some embodiments, computing device 500 may retrieve parameter value from memory and send the value as a signal via the communication module of the computing device 500 (not shown in FIG. 8). In some cases, if the distributed database instance 503 does not yet contain a value for a parameter (for example, a transaction has not yet been defined in the distributed database instance 503), the distributed database instance 503 may request a value for the parameter from the computing device 403 (if it has not yet been not provided in step 1) and store that value for the parameter in the distributed database instance 503 . In some embodiments, the computing device 400 will then use this value as the value for the parameter in the distributed database instance 503.

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

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

Although the steps are labeled 1, 2 and 3 in FIG. 8 and in the discussion above, it should be understood that steps 1, 2, and 3 may be performed in any order. For example, step 3 may be performed before steps 1 and 2. In addition, communication between computing devices 400 and 500 is not limited to steps 1, 2, and 3 shown in FIG. 3 as detailed herein. Moreover, upon completion of steps 1, 2, and 3, computing device 400 may select another computing device from the set of computing devices in the distributed database system to exchange values with (similar to steps 1, 2, and 3).

In some embodiments, data transferred between computing devices 400, 500 may include compressed data, encrypted data, digital signatures, cryptographic checksums, and/or the like. In addition, each of the computing devices 400, 500 may send data to the other computing device to acknowledge receipt of data previously sent by the other device. Each of the computing devices 400, 500 may also ignore data that has been repeatedly sent by the other device.

Each of the computing devices 400, 500 may initially determine a value vector for a parameter and store that value vector for the parameter in distributed database instances 403, 503, respectively. In FIG. 9a–9c illustrate examples of value vectors for a parameter. A vector can be any set of values for a parameter (for example, a one-dimensional array of values for a parameter, an array of values each with multiple parts, etc.). Three examples of vectors are shown in Fig. 9a-9c for illustration purposes. As shown, each of the vectors 410, 420, 430 has five values for a particular parameter. However, it should be understood that the value vector may have any number of values. In some cases, the number of values included in the value vector can be set by the user, situationally, randomly, etc.

The parameter can be any data object that can take on different values. For example, the parameter may be a binary voice, in which the value of the vote may be either "YES" or "NO" (or binary "1" or "0"). As shown in FIG. 9a, the value vector 410 is a vector having five binary votes, where the values 411, 412, 413, 414, 415 correspond to "YES", "NO", "NO", "YES", and "YES", respectively. As another example, a parameter may be a set of data items. In FIG. 9b shows an example where the parameter is a set of alphabetic characters. As shown, the value vector 420 has five sets of four alphabetic characters, with the values 421, 422, 423, 424, 425 corresponding to {A, B, C, D}, {A, B, C, E}, {A, B, C, F}, {A, B, F, G} and {A, B, G, H}, respectively. As another example, a parameter may be a ranked and/or ordered set of data items. In FIG. 9c shows an example where the parameter is a ranked set of people. As shown, the value vector 430 has five ranked sets of six people, with the values 431, 432, 433, 434, 435 corresponding to

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

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

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

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

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

respectively.

After determining a value vector for a parameter, each of the computing devices 400, 500 may select a value for the parameter based on the value vector for the parameter. This selection may be made according to any method and/or process (eg, a rule or a set of rules). For example, the selection can be made according to "majority rules" in which the value for a parameter is chosen to be equal to the value that appears in more than 50% of the values included in the vector. For illustration, the value vector 410 (shown in FIG. 9a) contains three "YES" values and two "NO" values. According to the "majority rules", the value chosen for the parameter based on the value vector will be "YES" because "YES" appears in more than 50% of the values 411, 412, 413, 414, 415 (value vector 410).

As another example, the selection can be made according to "occurrence in the majority", in which the value for a parameter is chosen to be equal to a set of data elements, where each data element appears in more than 50% of the values included in the vector. For illustration, with the help of FIG. 9b, data elements "A", "B", and "C" appear in more than 50% of the values 421, 422, 423, 424, 425 of the value vector 420. According to "occurrence in the majority", the value chosen for the parameter based on the value vector will be {A, B, C}, since only these data elements (i.e. "A", "B" and "C") appear in three of the five values of the vector 420 values.

As yet another example, the selection may be made according to "rank by median", in which the value for a parameter is chosen to be equal to a ranked set of data items (e.g., different data values within the value of a vector of values), where the rank of each data item is equal to the median rank of that data element among all values included in the vector. To illustrate, the median rank of each data item in FIG. 9c is calculated as follows:

Alice: (1, 2, 2, 1, 1); median rank = 1;

Bob: (2, 1, 1, 2, 2); median rank = 2;

Carol: (3, 3, 3, 3, 4); median rank = 3;

Dave: (4, 4, 4, 5, 5); median rank = 4;

Ed: (5, 5, 6, 4, 3); median rank = 5;

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

Thus, according to "rank by median", the value for the ranked set of data items calculated from a vector of 430 values would be (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank). In some embodiments, if two or more data items share the same median (e.g., equality), the order may be determined in any suitable manner (e.g., randomly, first rank indication, last rank indication, alphabetical and/or numerical order, etc.). d.).

As a further example, the selection may be made according to "Kemeny-Young voting" in which a value for a parameter is chosen to be equal to a ranked set of data items, with the rank calculated to minimize the amount of cost. For example, Alice has a rank higher than Bob's in the value vectors 431, 434, 435, which is three of the five value vectors in total. Bob has a rank higher than Alice's in the value vectors 432 and 433, totaling two of the five value vectors. The cost to rank Alice above Bob is 2/5 and the cost to rank Bob above Alice is 3/5. Thus, the cost to rank Alice above Bob is less, and Alice will be ranked above Bob according to "Kemeny-Young voting".

It should be understood that "majority rules", "appearance in the majority", "rank by median" and "Kemeny-Young voting" are discussed as examples of methods and/or processes that can be used to select a value for a parameter based on a vector of values for the parameter. Any other method and/or process may also be used. For example, a value for a parameter could be chosen to be equal to a value that appears in more than x% of the values included in the vector, where x% can be any percentage value (i.e. not limited to 50% as in the case of "majority rules" ). The percentage (i.e. x%) can also vary between selections made at different points in time, for example in terms of confidence (discussed in detail in this paper).

In some embodiments, since a computing device may randomly select other computing devices to exchange values with them, the computing device's value vector may at any time include a plurality of values from another individual computing device. For example, if the size of the vector is five, the computing device may randomly select another computing device twice in the last five iterations of the exchange of values. Accordingly, a value stored in a distributed database instance of another computing device will be included twice in the vector of five values for the requesting computing device.

In FIG. 10a-10d together illustrate by way of example how a value vector can be updated when one computing device communicates with another computing device. For example, computing device 400 may initially define a vector 510 of values. In some embodiments, value vector 510 may be determined based on a value for a parameter stored in distributed database instance 403 on computing device 400. For example, when value vector 510 is first determined, each value from value vector 510 (i.e., each of values 511, 512, 513, 514, 515) can be set to a value for a parameter stored in the distributed database instance 403. To illustrate, if the value for a parameter stored in the distributed database instance 403 at the point in time when the value vector 510 is determined is "YES", then each value from the value vector 510 (i.e., each of the values 511, 512, 513, 514, 515) will be set to "YES" as shown in FIG. 10a. When computing device 400 receives a value for a parameter stored in another computing device's distributed database instance (eg, distributed database instance 504 of computing device 500), computing device 400 may update value vector 510 to include the value for the parameter stored in instance 504 distributed database. In some cases, the value vector 510 may be updated according to a first-in-first-out (FIFO) basis. For example, if computing device 400 receives value 516 ("NO"), computing device 400 may add value 516 to value vector 510 and remove value 511 from value vector 510 to determine value vector 520 as shown in FIG. 10b. For example, if at a later time the computing device receives the values 517, 518, the computing device 400 may add the values 517, 518 to the value vector 510 and remove the values 512, 513, respectively, from the value vector 510 to determine the value vectors 530, 540, respectively. In other cases, the value vector 510 may be updated according to schemes other than first in, first out, such as last in, first out (LIFO).

After computing device 400 updates value vector 510 to determine value vectors 520, 530, and/or 540, computing device 400 may select a value for the parameter based on value vector 520, 530, and/or 540. This selection may be made according to any method and/or process (eg, a rule or set of rules) as discussed above with respect to FIG. 9a–9c.

In some cases, computing devices 400, 500 may refer to a distributed database system that stores information related to transactions involving financial instruments. For example, each of the computing devices 400, 500 may store a binary vote (example "value") as to whether a particular item is available for purchase (example "parameter"). For example, distributed database instance 403 of computing device 400 may store a value of "YES" indicating that a particular item is indeed available for purchase. The distributed database instance 503 of the computing device 500, on the other hand, may store the value "NO" indicating that the particular item is not available for purchase. In some cases, computing device 400 may initially determine a vector of binary votes based on a binary vote stored in distributed database instance 403. For example, computing device 400 may set each binary vote in the vector of binary votes to a binary vote stored in distributed database instance 403. In this case, computing device 400 may determine a vector of binary votes similar to value vector 510. At some later point in time, computing device 400 may communicate with computing device 500, requesting computing device 500 to send its binary vote regarding whether a particular product. After computing device 400 receives the binary vote of computing device 500 (in this example, "NO" indicating that the particular item is not available for purchase), computing device 400 may update its vector of binary votes. For example, the updated vector of binary votes may be similar to the value vector 520. This may occur indefinitely, until the confidence level meets a predetermined criterion (described in more detail herein), periodically, and/or the like.

In FIG. 11 is a flowchart 10 illustrating steps performed by a computing device 110 in a distributed database system 100, according to one embodiment. At step 11, the computing device 110 determines a vector of values for the parameter based on the value of the parameter stored in the instance 113 of the distributed database. In some embodiments, computing device 110 may determine a vector of values for a parameter based on a value for a parameter stored in distributed database instance 113. In step 12, computing device 110 selects another computing device in distributed database system 100 and queries the selected computing device for a value for a parameter stored in the distributed database instance of the selected computing device. For example, computing device 110 may randomly select computing device 120 from among computing devices 120, 130, 140 and query computing device 120 for a value for a parameter stored in distributed database instance 123. In step 13, computing device 110 (1) receives from a selected computing device (eg, computing device 120) a value for a parameter stored in a distributed database instance of the selected computing device (eg, distributed database instance 123) and (2) sends to the selected computing device (eg, computing device 120) the value for the parameter stored in the instance 113 of the distributed database. In step 14, computing device 110 stores the value for the parameter received from the selected computing device (eg, computing device 120) in a value vector for the parameter. In step 15, computing device 110 selects a value for the parameter based on a vector of values for the parameter. This selection may be made according to any method and/or process (eg, a rule or set of rules) as discussed above with respect to FIG. 9a–9c. In some embodiments, computing device 110 may repeat selecting a value for a parameter at other times. Computing device 110 may also repeatedly loop steps 12-14 between each selection of a value for a parameter.

In some cases, the distributed database system 100 may store information related to transactions in a massively multiplayer game (MMG). For example, each computing device associated with distributed database system 100 may store a ranked set of players (example "value") in the order in which they owned a particular item (example "parameter"). For example, distributed database instance 114 of computing device 110 may store a ranked set of players (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank) like the value 431, indicating that first a particular item was owned by Alice, then it passed to Bob, then it passed to Carol, then it passed to Dave, then it passed to Ed, and finally it passed to Frank. Distributed database instance 124 of computing device 120 may store a ranked player set value similar to 432: (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Ed, 6. Frank); distributed database instance 134 of computing device 130 may store a ranked player set value similar to 433: (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Frank, 6. Ed); distributed database instance 144 of computing device 140 may store a ranked player set value similar to 434: (1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank); a distributed database instance of a fifth computing device (not shown in FIG. 1) can store a ranked player set value like 435: (1. Alice, 2. Bob, 3. Ed, 4. Carol, 5. Dave, 6. Frank ).

After the computing device 110 determines the ranked player set vector, the computing device may receive ranked player set values from other computing devices of the distributed database system 100. For example, computing device 110 may 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 (1. Alice, 2. Bob, 3. Ed, 4. Carol, 5. Dave, 6. Frank) from a fifth computing device (not shown in FIG. 1). As computing device 110 receives ranked player set values from other computing devices, computing device 110 may update its player ranked set vector to include player ranked set values received from other computing devices. For example, the player ranked set vector stored in distributed database instance 114 of computing device 110, upon receiving the ranked set values listed above, may be updated to be similar to the value vector 430. After the player ranked set vector has been updated to to be similar to value vector 430, computing device 110 may select a ranked set of players based on a vector of ranked player sets. For example, the selection may be made according to "rank by median", as discussed above with respect to FIG. 9a–9c. According to "rank by median", computing device 110 will select (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank) based on a vector of ranked player sets similar to the value vector 430.

In some cases, computing device 110 does not receive the full value from another computing device. In some cases, computing device 110 may receive an identifier associated with portions of a complete value (also referred to as a composite value), such as a cryptographic hash value, instead of the portions themselves. To illustrate, computing device 110 in some cases does not receive (1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank), that is, the full value 434, from computing device 140, but receives only (4. Ed, 5. Dave, 6. Frank) from computing device 140. In other words, computing device 110 does not receive (1. Alice, 2. Bob, 3. Carol) from computing device 140, that is, certain parts of the value 434. Instead, computing device 110 may receive from computing device 140 a cryptographic hash value associated with these portions of value 434, i. (1. Alice, 2. Bob, 3. Carol).

A cryptographic hash value uniquely represents the parts of the value with which it is associated. For example, a cryptographic hash representing (1. Alice, 2. Bob, 3. Carol) will be different from cryptographic hashes representing:

(1. Alice);

(2. Bob);

(3. Carol);

(1. Alice, 2. Bob);

(2. Bob, 3. Carol);

(1. Bob, 2. Alice, 3. Carol);

(1. Carol, 2. Bob, 3. Alice);

etc.

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

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

By comparing the generated cryptographic hash value with the received cryptographic hash value, computing device 110 can determine whether computing device 140 should be asked for the actual portions associated with the received cryptographic hash value. If the generated cryptographic hash value is identical to the received cryptographic hash value, computing device 110 may determine that a copy identical to the actual parts associated with the received cryptographic hash value is already stored in the distributed database instance 113, and therefore the actual parts associated with the received cryptographic hash value hash from computing device 140 are not necessary. On the other hand, if the generated cryptographic hash value is not identical to the received cryptographic hash value, computing device 110 may request the actual portions associated with the received cryptographic hash value from computing device 140.

While the cryptographic hash values discussed above are associated with portions of single values, it should be understood that a cryptographic hash value may be associated with the entire single value and/or multiple values. For example, in some embodiments, the computing device (eg, computing device 140) may store a set of values in its distributed database instance (eg, distributed database instance 144). In such embodiments, after a predetermined period of time has elapsed since a value has been updated in a database instance, after a confidence level (discussed in relation to FIG. time after the transaction occurred and/or based on any other pertinent factors, this value may be included in the cryptographic hash value with other values when data is queried from and sent to another database instance. This reduces the number of specific values that are passed between database instances.

In some cases, for example, a set of values in a database may include a first set of values including transactions between the year 2000 and 2010; a second set of values including transactions between 2010 and 2013; the third set of values, including transactions between 2013 and 2014; and a fourth set of values including transactions between 2014 and now. Using this example, if computing device 110 queries computing device 140 for data stored in distributed database instance 144 of 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 a 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 as to when a value is added to a cryptographic hash may be set by the administrator, by individual users, based on the number of values already contained in the database instance, and/or the like. Sending cryptographic hash values instead of each individual value reduces the number of individual values provided when exchanging values between database instances.

When a receiving computing device (eg, computing device 400 in step 2 of FIG. 8) receives a cryptographic hash value (eg, generated by computing device 500 based on values in distributed database instance 503), that computing device generates a cryptographic hash value with using the same method and/or process and values in its database instance (eg, distributed database instance 403) for parameters (eg, transactions during a specified time period) that are used to generate the received cryptographic hash value. The receiving computing device may then compare the received cryptographic hash value with the generated cryptographic hash value. If the values do not match, the receiving computing device may query the individual values used to generate the received cryptographic hash from the transmitting computing device (e.g., computing device 500 in FIG. 8) and compare the individual values from the transmitting database instance (e.g., distributed database instance 503). database) with distinct values for those transactions in the receiving database instance (eg, distributed database instance 403).

For example, if a receiving computing device receives a cryptographic hash value associated with transactions between 2000 and 2010, the receiving computing device can generate a cryptographic hash using the values for transactions between 2000 and 2010 stored in its database instance. . If the received cryptographic hash value matches the locally generated cryptographic hash value, the receiving computing device may assume that the values for transactions between the year 2000 and 2010 are the same in both databases and no further information is requested. However, if the received cryptographic hash value does not match the locally generated cryptographic hash value, the receiving computing device may request from the transmitting computing device separate values used to generate the received cryptographic hash value. The receiving computing device may then identify the discrepancy and update the value vector for that individual value.

Cryptographic hash values may be based on any suitable process and/or hash function for combining multiple values and/or value parts into a single identifier. For example, any suitable number of values (eg, transactions over a period of time) may be used as input to a hash function, and a hash value may be generated based on the hash function.

Although the above discussion uses cryptographic hash values as an identifier 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 fingerprints, checksums, regular hash values, and/or the like.

In FIG. 12 is a flowchart (flowchart 20) illustrating the steps performed by the computing device 110 in the distributed database system 100, according to one embodiment. In the embodiment illustrated in FIG. 12, the value vector is reset based on a predetermined probability. Likewise, each value in the value vector may be reset to a value from time to time and based on probability. In step 21, computing device 110 selects a value for the parameter based on a vector of values for the parameter, similar to step 15 illustrated in FIG. 11 and discussed above. At step 22, computing device 110 receives values for the parameter from other computing devices (e.g., computing devices 120, 130, 140) and sends the value for the parameter stored in distributed database instance 113 to other computing devices (e.g., computing devices 120, 130, 140). For example, step 22 may include performing steps 12 and 13 illustrated in FIG. 11 and discussed above for each of the other computing devices. In step 23, computing device 110 stores parameter values received from other computing devices (eg, computing devices 120, 130, 140) into a parameter value vector, similar to step 14 illustrated in FIG. 11 and discussed above. In step 24, computing device 110 determines whether to reset the value vector based on a predetermined probability of resetting the value vector. In some cases, for example, there is a 10% chance that computing device 110 will reset the value vector for a parameter after each update by computing device 110 of the value vector for a parameter stored in distributed database instance 114. In such a scenario, computing device 110 will determine in step 24 whether a reinstall should be performed or not based on a 10% chance. In some cases, the determination may be performed by the processor 111 of the computing device 110.

If computing device 110 determines that the value vector should be reset based on a predetermined probability, computing device 110 resets the value vector in step 25. In some embodiments, the computing device 110 may reset each value in the value vector for a parameter to equal the value for the parameter stored in the distributed database instance 113 at the time of the reset. For example, if just before the reset the value vector is a value vector 430 and the value for the parameter stored in the distributed database instance 113 is (1.Alice, 2.Bob, 3.Carol, 4.Dave, 5.Ed, 6 . Frank) (e.g. according to "rank by median"), then each value in the value vector will be reset to equal (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank ). In other words, each of the values 431, 432, 433, 434, 435 of the value vector 430 will be reset to equal the value 431. Resetting each value in the value vector for a parameter to equal the value for the parameter stored in the distributed database instance helps the distributed database system (to which the computing device belongs) reach consensus at the time of reset, from time to time, and on a probability basis. Likewise, a reset promotes agreement on a value for a parameter among the computing devices of a distributed database system.

For example, distributed database instance 114 of computing device 110 may store a ranked set of players (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank) like the value 431, indicating that first a particular item was owned by Alice, then it passed to Bob, then it passed to Carol, then it passed to Dave, then it passed to Ed, and finally it passed to Frank.

In FIG. 13 is a flowchart (flowchart 30) illustrating the steps performed by the computing device 110 in the distributed database system 100, according to one embodiment. In the embodiment illustrated in FIG. 13, selection of a parameter value based on a vector of values for the parameter occurs when the confidence level associated with the distributed database instance is zero. Confidence may indicate a level of "consensus", or agreement, between a parameter value stored on computing device 110 and parameter values stored on other computing devices (e.g., computing devices 120, 130, 140) of distributed database system 100. In some embodiments, as detailed herein, the confidence level is incremented (e.g., incremented by one) each time the value for a parameter received from another computing device by computing device 110 equals the value for a parameter stored in computing device 110, and the confidence level is reduced (ie, reduced by one) each time the value for the parameter received from another computing device by the computing device 110 does not equal the value for the parameter stored in the computing device 110 if the confidence level is greater than zero.

In step 31, computing device 110 receives a value for a parameter from another computing device (eg, computing device 120) and sends the value for a parameter stored in distributed database instance 113 to the other computing device (eg, computing device 120). For example, step 31 may include performing steps 12 and 13 illustrated in FIG. 11 and discussed above. In step 32, computing device 110 stores a value for a parameter received from another computing device (eg, computing device 120) in a vector of values for the parameter, similar to step 14 illustrated in FIG. 11 and discussed above. In step 33, the computing device 110 determines whether the value for the parameter received from another computing device (eg, computing device 120) is equal to the value for the parameter stored in the distributed database instance 113. If the value for a parameter received from another computing device (for example, computing device 120) is equal to the value for a parameter stored in distributed database instance 113, then computing device 110 increments the confidence associated with distributed database instance 113 in step 34, by one, and the process illustrated by flowchart 30 returns to step 31. If the value for the parameter received from another computing device (eg, computing device 120) does not equal the value for the parameter stored in the distributed database instance 113, then the computing device 110 at step 35 reduces the confidence level associated with the distributed database instance 113 by one if the confidence level is greater than zero.

At step 36, the computing device 110 determines whether the confidence level associated with the distributed database instance 113 is zero. If the confidence level is zero, then the computing device in step 37 selects a value for the parameter based on the vector of values for the parameter. This selection may be made according to any method and/or process (eg, a rule or set of rules) as discussed above. If the confidence level is not zero, then the process illustrated by flowchart 30 returns to step 31.

As discussed above, degrees of confidence are associated with distributed database instances. However, it should be understood that confidence may also be related to the vector value stored in the distributed database instance and/or the computing device storing the vector value (e.g., in its distributed database instance), instead of or in addition to the distributed database instance. to him.

Values related to degrees of confidence (eg, threshold values, increment values, and reduction values) used in relation to FIG. 13 are presented for illustrative purposes only. It should be understood that other values related to degrees of confidence (eg, threshold values, increment values, and reduction values) may be used. For example, any value may be used for the confidence increments and/or decrements performed in steps 34 and 35, respectively. As another example, the confidence level threshold of zero used in steps 35 and 36 may also be any value. In addition, values related to degrees of certainty (eg, threshold values, incremental values, and reduction values) may change during operation, ie. as the cycles of the process illustrated in flowchart 30 are performed.

In some embodiments, the degree of certainty may affect the information flow between the first computing device from the distributed database system and the second computing device from the distributed database system, described above with respect to FIG. 8. For example, if the first computing device (eg, computing device 110) has a high degree of certainty associated with its distributed database instance (eg, distributed database instance 114), then the first computing device may ask the second computing device for a smaller portion of the value for the parameter (and the cryptographic hash value associated with most of the value for the parameter) than the first computing device would otherwise request from the second computing device (e.g., if the first computing device has low confidence associated with its distributed database instance) . High confidence may indicate that the value for the parameter stored in the first computing device is likely consistent with the values for the parameter stored in other computing devices from the distributed database system, and thus the cryptographic hash value is used to verify consistency.

In some cases, the degree of certainty of the first computing device may increase to reach a threshold at which the first computing device determines that it should no longer request specific values, specific parts of values, and/or cryptographic hash values associated with specific values and/or specific parts. values from other computing devices from a distributed database system. For example, if the confidence level of a value satisfies a particular criterion (eg, reaches a threshold value), the first computing device may determine that the value has converged and not further request that the value be exchanged with other devices. As another example, a value may be added to a cryptographic hash value based on its confidence level that satisfies a criterion. In such cases, a cryptographic hash value for a set of values may be sent instead of a single value after the confidence level satisfies the criteria, as discussed in detail above. Exchange of fewer values and/or smaller actual parts (values) with cryptographic hash values associated with the remaining parts (values) can facilitate efficient communication between computing devices of a distributed database system.

In some cases, as confidence increases for a particular value of a parameter of a distributed database instance, the computing device associated with that distributed database instance may request to exchange values for that parameter with other computing devices less frequently. Similarly, in some cases, as the confidence level for a particular parameter value of a distributed database instance decreases, the computing device associated with that distributed database instance may request to exchange values for that parameter with other computing devices more frequently. Thus, the degree of confidence can be used to reduce the number of values exchanged between computing devices.

While various embodiments have been described above, it should be understood that they have been presented by way of example only and not limitation. In case the methods described above indicate that certain events occur in a certain order, the ordered sequence of certain events can be changed. Additionally, some of the events may be executed simultaneously in a parallel process, when possible, as well as performed sequentially, as described above.

Some embodiments described herein relate to a non-volatile computer-readable medium (which may also be referred to as non-volatile, processor-readable medium) storage product that stores instructions or computer code for performing various computer-implemented operations. A computer-readable medium (or a processor-readable medium) is non-volatile in the sense that it essentially does not contain temporally propagating signals (eg, a propagating electromagnetic wave carrying information over a transmission medium such as space or a cable). The media and computer code (which may also be referred to as code) may be executed and created for a particular purpose or purposes. Examples of non-volatile computer-readable media include, but are not limited to: magnetic storage devices such as hard disks, floppy disks, and magnetic tape; optical storage devices such as compact disc/digital video discs (CD/DVD), compact disc read only memory (CD-ROM), and holographic devices; magneto-optical storage devices such as optical discs; carrier frequency signal processing modules; and hardware devices that are specifically configured to store and execute program code, such as application specific integrated circuits (ASICs), programmable logic integrated circuits (PLDs), read only memory (ROM) and random access memory (RAM). Other embodiments described herein relate to a computer program product that may include, for example, the instructions and/or computer code discussed herein.

Examples of computer code include, but are not limited to, microcode or microinstructions, machine instructions such as those generated by a compiler, code used to create a web service, and files containing higher level instructions that are executed by a computer using an interpreter. For example, embodiments may be implemented using imperative programming languages (e.g., C, Fortran, etc.), functional programming languages (e.g., Haskell, Erlang, etc.), logical programming languages (e.g., Prolog), object-based 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, encrypted code, and compressed code.

While various embodiments have been described above, it should be understood that they have been presented by way of example only and not limitation, and various changes may be made in terms of form and detail. Any part of the apparatus and/or methods described herein may be combined in any combination, except for mutually exclusive combinations. The embodiments described herein may include various combinations and/or subcombinations of functions, components, and/or features of the various embodiments described.

Claims (256)

1. A non-volatile processor-readable medium that stores code representing instructions to be executed by the processor, the code containing code that causes the processor to execute: receiving a first event from a distributed database instance on a first computing device of a plurality of computing devices that implement the distributed database via a network operatively connected to the plurality of computing devices; determining a third event based on the first event and the second event; determining a first set of events based at least in part on a third event, wherein each event from the first set of events: is identified by a second set of events, wherein the total stake value associated with the second set of events satisfies the first share size criterion, where each event from the second set of events is (1) determined by a different instance of the distributed database and (2) is identified by a third event, and associated with the first number of the round; calculating a round number for the third event based on determining that the sum of the proportion values associated with each event of the first set of events satisfies the second proportion value criterion, wherein the round number for the third event corresponds to a second round number greater than the first round number; determining a third event set based on the third event, wherein each event from the third event set: identified by a fourth event set containing a third event, each event from the fourth event set: is determined by a different instance of the distributed database, wherein the total stake value associated with the fourth set of events satisfies the third stake criterion, and represents an event from the first set of events; determining an ordinal value for the fourth event based at least in part on the total share value associated with the third set of events satisfying the fourth share value criterion; and storing an ordinal value in a distributed database instance on a second computing device of the plurality of computing devices. 2. The non-volatile processor-readable medium of claim 1, further comprising code that causes the processor to execute: calculating an overall stake value associated with the third set of events based on the sum of the set of stake values, wherein each stake value of the set of stake values is associated with the distributed database instance that determined the event from the third event set. 3. The non-volatile processor-readable medium of claim. 1, wherein the code that causes the processor to determine the ordinal value for the fourth event comprises code that causes the processor to execute the determination of the received round number associated with the fourth event based on the identification of the fourth event. a third set of events whose total shares satisfy the fourth share criterion. 4. The non-volatile processor-readable medium of claim 1, further comprising code that causes the processor to execute: determining a third event set based on the equality of the value associated with each event in the third event set with the value associated with the remaining events in the third event set, wherein the value associated with each event in the third event set is (1) associated with the fourth event and (2) based on a value for each event in the fourth event set that such event in the third event set can identify, wherein the fourth share value criterion is satisfied by the third event set when the total share value associated with the third event set exceeds a threshold value based on the total share value associated with the fourth event set. 5. The non-volatile processor-readable medium of claim 1, wherein the second share value criterion is based on a predetermined ratio associated with the total distributed database share value, wherein the code further comprises code that causes the processor to execute: linking the round number of the third event as the received round number for the fourth event based on the satisfaction of the fourth share value criterion by the third set of events. 6. Non-volatile processor-readable media according to claim 1, characterized in that it additionally contains code that causes the processor to execute: determining a value for a third event based on a value for each event from the fourth set of events, wherein the value for the third event is the value associated with the majority of the events from the fourth set of events based on the satisfaction of the third share size criterion by the fourth set of events, wherein the fourth set of events satisfies the third criterion of the share value, when the total value of the shares of each event from the fourth set of events has a value associated with the majority of events that exceeds the first threshold value and does not exceed the second threshold value, while the first threshold value and the second threshold value are based on the total value of the shares of the fourth set of events. 7. The non-volatile processor-readable medium of claim 1, further comprising code that causes the processor to execute: determining a value for a third event based on a value for each event from the fourth set of events, wherein the value for the third event is pseudo-random, based on the satisfaction of the fourth criterion of the share value by the fourth set of events, the fourth set of events satisfies the fourth criterion for the size of the share, when the total value of the shares of each event from the fourth set of events has a value associated with the majority of the events from the fourth set of events that exceeds the first threshold value and does not exceed the second threshold value, while the first threshold value and the second threshold is based on the total stakes associated with the fourth set of events. 8. The non-volatile processor-readable medium of claim. 1, wherein the fourth set of events is a subset of events from the fifth set of events, wherein the code further comprises code that causes the processor to execute: identifying a subset of events based on the equality of the value associated with each event in the event subset with the value associated with the remaining events in the event subset, wherein the value associated with each event in the event subset is (1) associated with the fourth event, and (2) based on the value for each event in the sixth event set that such an event in the event subset can identify, wherein the round number of the fifth set of events exceeds the number of the round of the sixth set of events, wherein the fifth proportion criterion is satisfied by the event subset when the total proportion of the event subset exceeds the first threshold and does not exceed the second threshold, the first threshold and the second threshold being based on the total proportion of the fifth event set; and identification, based on the satisfaction of the fifth criterion of the proportion of a subset of events, the seventh set of events, the total value of the shares of which is used to determine the ordinal value for the fourth event, while the seventh set of events has a round number greater than the round number of the fifth set of events, while the value for of each event in the seventh event set is based on the value associated with each event in the fifth event set. 9. Non-volatile processor-readable media according to claim 1, characterized in that each event from the third set of events (1) is determined by a different distributed database instance and (2) is identified by a third event, wherein the ordinal value for the fourth event is further based on the pseudo-random determination associated with the digital signature of the third event. 10. The non-volatile processor-readable medium of claim 1, wherein the fourth stake size criterion is based at least in part on the sum of a set of stake values associated with a cryptocurrency, with In this case, each share value from the set of share values associated with the amount of cryptocurrency is stored by a different instance of the distributed database. 11. The non-volatile processor-readable medium of claim 1, wherein the fourth share value criterion is met when the total share value associated with the third set of events exceeds a predetermined threshold, wherein the predetermined threshold is based at least in part on the total share of the distributed database. 12. A device for implementing a distributed database, comprising: a memory containing an instance of the distributed database on a first computing device capable of being included in a plurality of computing devices that implements the distributed database via a network operatively connected to the plurality of computing devices; and a processor operatively connected to a distributed database instance, wherein the processor is configured to determine at the first moment of time the first event associated with the first set of events, wherein each event from the first set of events is a sequence of bytes, wherein the processor is configured to receive, at a second time point after the first time point and from the second computing device of the plurality of computing devices, a signal representing a second event (1) determined by the second computing device and (2) associated with the second set of events, wherein each event from the second set of events is a sequence of bytes, wherein the processor is configured to identify the order associated with the third set of events based on at least the value of the share associated with each computing device from the plurality of computing devices, wherein each event from the third set of events is an event from at least one of the first set of events or the second set of events, wherein each event from the third set of events is associated with a value for each attribute from the set of attributes, wherein the value for the first attribute from the set of attributes for each event from the third set of events contains the first value based on whether the relationship between such an event and the first set of events associated with this event satisfies the criterion, wherein each event from the first set of events (1) is an ancestor of such an event from the third set of events and (2) is associated with the same first common attribute as the rest of the events from the first set of events, while the first common attribute is an indicator of the initial instance, in which the event defined by each computing device from a plurality of computing devices is associated with a specific value, wherein the value for the second attribute from the set of attributes contains a numeric value based on the relationship between such an event from the third set of events and the second set of events associated with such an event from the third set of events, wherein each event from the second set of events is a descendant of such an event from the third set of events and is associated with the second common attribute, like the rest of the events from the second set of events, wherein the processor is configured to store in the distributed database instance the order associated with the third set of events. 13. The device according to claim 12, characterized in that the value of the share associated with each computing device from a plurality of computing devices is proportional to the amount of cryptocurrency associated with a distributed database instance on such a computing device from a plurality of computing devices. 14. The device according to claim 12, characterized in that: the criterion is based on comparing (1) a combination of proportion values associated with the first set of events and (2) a threshold value determined based on the proportion value associated with each computing device of the plurality of computing devices. 15. A device for implementing a distributed database, comprising: a memory associated with a distributed database instance on a first computing device configured to be included in a plurality of computing devices that implements the distributed database via a network operatively connected to the plurality of computing devices, and processor operatively coupled to memory wherein the processor is configured to identify at the first time the first event of the distributed database, (1) determined by the first computing device and (2) associated with the first set of events of the distributed database, wherein the processor is configured to receive, at a second time point after the first time point, a signal representing a second distributed database event (1) determined by a second computing device of the plurality of computing devices and (2) associated with a second set of distributed database events, wherein the processor is configured to identify the order of distributed database events within the third distributed database event set based at least in part on a first attribute value for each distributed database event of the third distributed database event set, wherein the first attribute value for each event distributed database event from the third set of distributed database events is based on the relationship between such a distributed database event and a set of distributed database events containing descendants of such a distributed database event, with each distributed database event from the set of distributed database events associated with the second an attribute common to the remaining distributed database events from the distributed database event set, wherein each distributed database event from the third distributed database event set is taken from at least at least one of the first distributed database event set or the second distributed database event set, wherein the third distributed database event set is mutually exclusive with the distributed database event set, wherein the processor is configured to store in memory the order associated with the third set of events of the distributed database. 16. The apparatus of claim. 15, characterized in that the value of the first attribute for each distributed database event from the third set of distributed database events is based on the number of descendants of such an event contained in the distributed database event set, compared to the number of non-descendants such an event contained in the distributed database event set. 17. The apparatus of claim. 15, characterized in that each distributed database event from a set of distributed database events is determined by a unique computing device from a plurality of computing devices. 18. The device according to claim 15, characterized in that each distributed database event from a set of distributed database events is determined by a unique computing device from a plurality of computing devices, wherein the processor is configured to identify each distributed database event from the set of distributed database events based on the fact that each distributed database event from the set of distributed database events represents an initial instance of the computing device from the plurality of computing devices that determined that the event distributed database event has defined a distributed database event having a specific value for the third attribute, wherein each distributed database event in the set of distributed database events has a specific value for the third attribute. 19. The device according to claim 15, characterized in that the set of distributed database events is the first set of distributed database events, wherein each distributed database event from the first set of distributed database events is determined by a unique computing device from a plurality of computing devices, wherein the processor is configured to identify each distributed database event from the first set of distributed database events based on (1) that each distributed database event from the first set of distributed database events represents an initial instance of a computing device from a plurality of computing devices, which determined that a distributed database event determined a distributed database event, having a specific value for the third attribute, and (2) an agreement protocol outcome in which the second set of distributed database events indicates that such a distributed database event from the first set of distributed database events should be within the third set of distributed database events, when wherein the first distributed database event set is a subset of the third distributed database event set, wherein each distributed database event of the first distributed database event set has a specific value for the third attribute. 20. The apparatus of claim 15, wherein each distributed database event of the first distributed database event set and each distributed database event of the second distributed database event set is a sequence of bytes. 21. The apparatus of claim. 15, characterized in that the distributed database event set is a first distributed database event set, wherein the processor is configured to identify each distributed database event from the first distributed database event set based on the outcome of the agreement protocol , in which the second distributed database event set indicates that such a distributed database event from the first distributed database event set should be within the third distributed database event set, and the second distributed database event set satisfies a predefined criterion, while the first set of distributed database events is a subset of the third set of distributed database events. 22. The apparatus of claim. 15, characterized in that the distributed database event set is a first distributed database event set, wherein the processor is configured to identify each distributed database event from the first distributed database event set based on the outcome of the agreement protocol , in which the second distributed database event set indicates that such a distributed database event from the first distributed database event set should be within the third distributed database event set, wherein the first distributed database event set is a subset of the third distributed database event set Database, wherein the processor is configured to identify each distributed database event from the second distributed database event set based on (1) that the distributed database event from the second distributed database event set is a descendant of the fourth distributed database event set, and (2) the number of distributed database events in the fourth set of distributed database events that meet the criterion. 23. The apparatus of claim. 15, characterized in that the distributed database event set is a first distributed database event set, wherein the processor is configured to identify each distributed database event from the first distributed database event set based on the outcome of the agreement protocol , in which the second distributed database event set indicates that such a distributed database event from the first distributed database event set should be within the third distributed database event set, wherein the first distributed database event set is a subset of the third distributed database event set Database, wherein the processor is configured to identify each distributed database event from the second distributed database event set based on (1) that the distributed database event from the second distributed database event set is a descendant of the fourth distributed database event set, and (2) the number of distributed database events in the fourth set of distributed database events that satisfy the first criterion, wherein each distributed database event from the fourth distributed database event set is an ancestor of the fifth distributed database event set, wherein each distributed database event from the second distributed database event set is a descendant of the fifth distributed database event set, wherein the processor is configured to identify each distributed database event from the fourth set of distributed database events based on the number of distributed database events in the fifth set of distributed database events that meet the second criterion. 24. The apparatus of claim 15, wherein the processor is configured to identify an order associated with the third distributed database event set based at least in part on a first attribute value for each distributed database event of the third distributed database event set, and a timestamp associated with each distributed database event of the third distributed database event set. 25. The apparatus of claim 15, wherein the processor is configured to identify an order associated with the third distributed database event set based at least in part on a first attribute value for each distributed database event of the third distributed database event set, and a signature for each distributed database event from the third distributed database event set. 26. The device according to claim. 15, characterized in that the set of events of the distributed database is the first set of events of the distributed database, wherein the processor is configured to identify each distributed database event from the first set of distributed database events based on the outcome of the agreement protocol, in which the second set of events of the distributed database indicates that such a distributed database event from the first set of distributed database events should be located within the third set of distributed database events, wherein each distributed database event from the second distributed database event set indicates that such distributed database event from the first distributed database event set should be within the third distributed database event set based on the value (1) associated with such a distributed database event from the first set of distributed database events and (2) identified by the set of ancestors of such a distributed database event from the second set of distributed database events. 27. A non-volatile processor-readable medium that stores code representing instructions to be executed by the processor, the code containing code that causes the processor to execute: receiving a signal representing a plurality of distributed database events containing transactions associated with the distributed database; calculation for each distributed database event from the set of distributed database events, the accepted round for such a distributed database event from the set of distributed database events based on the relationship between such a distributed database event and the set of distributed database events containing descendants of such an event, when whereby each distributed database event in the distributed database event set is classified as known; identifying an order associated with the distributed database event set based on the received round associated with each distributed database event of the distributed database event set; and maintaining order in memory associated with the distributed database instance on a first computing device capable of being included in a plurality of computing devices that implements the distributed database via a network operatively coupled to the plurality of computing devices. 28. The non-volatile processor-readable medium of claim 27, wherein the code that causes the processor to perform a calculation comprises code that causes the processor to perform a calculation, for each distributed database event from a set of distributed database events, the accepted round for such an event distributed database based on the number of children of such an event contained in the distributed database event set compared to the number of non-children of such event contained in the distributed database event set. 29. The non-volatile processor-readable medium of claim 27, wherein the set of distributed database events is the first set of distributed database events, wherein each distributed database event from the first set of distributed database events is determined by a unique computing device from a plurality of computing devices. devices, while the code additionally contains code that causes the processor to execute: classifying each distributed database event from the first set of distributed database events as known, based on (1) that each distributed database event from the first set of distributed database events represents an initial instance of a computing device from a set of computing devices that has determined, that a distributed database event identified a distributed database event having a particular value for the attribute, and (2) an agreement protocol outcome in which the second set of distributed database events indicates that such a distributed database event from the first set of distributed database events should be located within a third distributed database event set, wherein the first distributed database event set is a subset of the third distributed database event set, wherein each distributed database event from the first distributed database event set The database field has a specific value for the attribute. 30. The non-volatile processor-readable medium of claim 27, wherein each distributed database event from a set of distributed database events is determined by a unique computing device of the plurality of computing devices. 31. The non-volatile processor-readable medium of claim 27, wherein the distributed database event set is the first distributed database event set, wherein the code further comprises code that causes the processor to execute: classifying each distributed database event from the first distributed database event set as known, based on an agreement protocol outcome in which the second distributed database event set indicates that such a distributed database event from the first distributed database event set should be within the third a set of distributed database events, wherein each distributed database event from the second distributed database event set indicates that such distributed database event from the first distributed database event set should be within the third distributed database event set based on the value (1) associated with such a distributed database event from the first set of distributed database events and (2) identified by the set of ancestors of such a distributed database event from the second set of distributed database events. 32. The non-volatile processor-readable medium of claim 27, wherein the code that causes the processor to execute an order identification comprises code that causes the processor to execute an order identification associated with a set of distributed database events at least in part based on the received round, associated with each distributed database event of the set of distributed database events and at least one of the timestamp or signature of each distributed database event of the set of distributed database events. 33. A method for implementing a distributed database, including: identifying at a first time a first distributed database event (1) determined by a first computing device capable of being included in a plurality of computing devices that implements the distributed database via a network operably connected to the plurality of computing devices, and (2) associated with the first a plurality of distributed database events; receiving, at a second time after the first time, a signal representing a second distributed database event (1) determined by a second computing device of the plurality of computing devices and (2) associated with a second plurality of distributed database events; calculating, using a processor associated with the distributed database instance, the order associated with the third distributed database event set based at least in part on the value of the first attribute for each distributed database event of the third distributed database event set, wherein the value of the first attribute for each distributed database event from the third set of distributed database events is based on the relationship between such a distributed database event and a set of distributed database events containing descendants of such a distributed database event, with each distributed database event from the distributed database event set database is associated with a second attribute common to the remaining distributed database events from the distributed database event set, where each distributed database event from the third distributed database event set is taken from at least one of the first distributed database event set or the second distributed database event set; and storing in memory associated with the distributed database instance an order associated with the third distributed database event set. 34. The method of claim 33, wherein each distributed database event from the set of distributed database events is determined by a unique computing device from the plurality of computing devices, wherein the method further comprises: identifying each distributed database event in the distributed database event set based on the fact that each distributed database event in the distributed database event set is the first computing device instance of the plurality of computing devices that determined that the distributed database event determined the distributed database event. a database that has a specific value for the third attribute, wherein each distributed database event in the set of distributed database events has a specific value for the third attribute. 35. The method of claim 33, wherein the distributed database event set is the first distributed database event set, the method comprising: identifying each distributed database event from the first distributed database event set, based on the outcome of the agreement protocol, in which the second distributed database event set indicates that such a distributed database event from the first distributed database event set should be within the third event set distributed database, wherein each distributed database event from the second distributed database event set indicates that such distributed database event from the first distributed database event set should be within the third distributed database event set based on the value (1) associated with such a distributed database event from the first set of distributed database events and (2) identified by the set of ancestors of such a distributed database event from the second set of distributed database events. 36. The method according to p. 33, characterized in that it further includes: calculating an order associated with a third distributed database event set based at least in part on the value of a first attribute for each distributed database event from the third distributed database event set and at least one of the timestamp and signature of each distributed database event from the third set of events of a distributed database. 37. The method of claim 33, wherein the value of the first attribute for each distributed database event from the third distributed database event set is based on the number of descendants of that event contained in the distributed database event set compared to the number of non-children. such an event contained in the distributed database event set. 38. A device for implementing a distributed database, containing: a memory storing an instance of a distributed directed acyclic graph (DAG) on a first computing device configured to be included in a plurality of computing devices that implements a distributed DAG via a network operatively connected to the plurality of computing devices, wherein the first computing device is configured to be stored in event set memory using a distributed DAG instance; and the processor of the first computing device operatively connected to the memory, wherein the processor is configured to determine at the first moment of time the first event associated with the first set of events, wherein the processor is configured to receive, at a second time point after the first time point and from the second computing device of the plurality of computing devices, the second event (1) determined by the second computing device and (2) associated with the second set of events, wherein the processor is configured to determine a third event containing a cryptographic hash of the first event and a cryptographic hash of the second event, and wherein the processor is configured to identify, by means of a consensus algorithm, the order of each event from the third set of events with respect to the remaining events from the third set of events based on at least the first set of events and the second set of events, wherein each event from the third set of events is an event from at least one of the first set of events or the second set of events, wherein the processor is configured to store in memory and using the distributed DAG instance, the third event as part of the event set, and the order associated with the third event set. 39. The apparatus of claim 38, wherein the consensus algorithm does not require a proof-of-work protocol. 40. The device according to claim 38, characterized in that the distributed DAG does not contain a leader entity. 41. The apparatus of claim 38, wherein the processor receives the second event from the second computing device as part of a synchronization event. 42. The apparatus of claim 38, wherein each event of the third event set contains payload data ordered with respect to the payload data for each remaining event of the third event set based on the order associated with the third event set. 43. The device according to claim 38, characterized in that the third event is digitally signed by the first computing device. 44. The apparatus of claim 38, wherein the processor is further configured to send the first event to the second computing device in response to receiving the second event from the second computing device, such that the computing device determines a fourth event containing a cryptographic hash of the first event . 45. The apparatus of claim 38, wherein the order associated with the third event set is based at least in part on a set of values, wherein each value from the set of values assigned to an event from a subset of events from the third event set is based on at least one of a measure of confidence or reliability associated with such an event from a subset of events. 46. The apparatus of claim 38, wherein the processor is configured to receive a second event in response to the second computing device randomly selecting a first computing device from among the plurality of computing devices. 47. The apparatus of claim 38, wherein the order associated with the third set of events is based at least in part on a set of values, where each value in the set of values is assigned a reputation associated with an event in the subset of events. 48. The device according to claim 38, characterized in that the first event is associated with the first set of events by including in the first event an identifier of at least two events from the first set of events. 49. A device for implementing a distributed database, containing: a first computing device configured to be included in a plurality of computing devices that implements a distributed DAG via a network operably coupled to the plurality of computing devices, wherein the first computing device comprises a processor and a memory operatively coupled to the processor, wherein (1 ) an instance of the distributed DAG, and (2) instructions that cause the processor to execute: determining at the first moment of time the first event associated with the first set of events using the identifier of at least one event from the first set of events contained in the first event, receiving at a second point in time after the first point in time from a second computing device from a plurality of computing devices, a second event (1) determined by the second computing device and (2) linked to the second set of events using an identifier of at least one event from the second set of events, contained in the second event, determining the third event containing the cryptographic hash of the first event and the cryptographic hash of the second event, identifying, using a consensus algorithm, the order of each event from the third event set relative to the remaining events from the third event set based on at least the first event set and the second event set, wherein each event from the third event set is an event from at least one of a first set of events or a second set of events, and storing in memory as part of the distributed DAG the third event and the order associated with the third set of events. 50. The apparatus of claim 49, wherein the consensus algorithm does not require a proof-of-work protocol. 51. The device according to claim 49, characterized in that the distributed DAG does not contain a leader entity. 52. The apparatus of claim 49, wherein the reception of the second event from the second computing device is part of the synchronization event. 53. The apparatus of claim 49, wherein each event of the third event set contains payload data ordered with respect to the payload data for each remaining event of the third event set based on the order associated with the third event set. 54. The apparatus of claim 49, wherein the instructions that cause the processor to execute a receive include instructions that cause the processor to execute a receive of a second event in response to the second computing device randomly selecting the first computing device. 55. The device according to claim 49, characterized in that the third event is digitally signed by the first computing device. 56. The device according to claim 49, characterized in that the memory additionally stores instructions that cause the processor to send the first event to the second computing device in response to receiving the second event from the second computing device, so that the computing device determines the fourth event, containing the cryptographic hash of the first event. 57. A device for implementing a distributed database, containing: memory; and a processor operably associated with the memory, wherein the processor is configured to receive a first event from a first computing device implementing a distributed database, wherein the first event contains (1) an identifier of the first ancestor event and (2) an identifier of the second ancestor event, wherein the processor is configured to receive the second event from the second computing device implementing the distributed database, wherein the second event contains (1) the identifier of the third ancestor event and (2) the identifier of the fourth ancestor event, wherein the processor is configured to construct a directed acyclic graph (DAG) based on the first event and the second event, wherein the processor is configured to identify a consensus order of the first event and the second event based on the DAG. 58. The apparatus of claim 57, wherein the processor is configured to identify a consensus order using a DAG to identify how the first computing device and the second computing device would vote on the consensus protocol without the processor receiving votes from the first computing device and the second computing device. devices. 59. The apparatus of claim 57, wherein the processor is configured to determine a third event comprising (1) a second event identifier and (2) a fifth parent event identifier, wherein the fifth parent event is determined by the processor. 60. The device according to claim 57, characterized in that the processor is configured to receive the first event at the first time, while the processor is configured to receive the second event at the second time after the first time, wherein the processor is configured to determine the third event, containing (1) the identifier of the first event and (2) the identifier of the fifth ancestor event, while the fifth ancestor event is determined by the processor, wherein the processor is configured to determine a fourth event comprising (1) a third event identifier and (2) a second event identifier. 61. The apparatus of claim 57, wherein the identifier of the first parent event is a cryptographic hash of the first parent event. 62. The apparatus of claim 57, wherein the processor is configured to identify the consensus order of the first event, second event, first parent event, second parent event, third parent event, and fourth parent event based on the DAG. 63. The apparatus of claim 57, wherein the processor is configured to determine the state of the distributed database based on the consensus order. 64. The apparatus of claim. 57, wherein the first event contains a first set of transactions and the second event contains a second set of transactions, wherein the consensus order determines the order of the first set of transactions relative to the second set of transactions. 65. A non-volatile processor-readable medium that stores code representing instructions to be executed by the processor, the code containing code that causes the processor to execute: receiving an event from a computing device implementing a distributed database, the event comprising (1) a first parent event identifier and (2) a second parent event identifier; constructing a directed acyclic graph (DAG) based on the event, the first parent event, and the second parent event; and identifying, based on the DAG, a consensus order of a plurality of events containing an event, a first parent event, and a second parent event. 66. The non-volatile processor-readable medium of claim 65, wherein the first parent event identifier is a cryptographic hash of the first parent event. 67. A non-volatile processor-readable medium according to claim 65, characterized in that the computing device is selected from a plurality of computing devices that implement a distributed database, wherein the code that causes the identification processor to execute the identification comprises code that causes the identification processor to execute a consensus order using the DAG to identify how the plurality of computing devices would vote in the consensus protocol without the processor receiving votes from the plurality of computing devices. 68. The non-volatile processor-readable medium of claim 65, further comprising code that causes the processor to execute: calculating the state of a distributed database based on the consensus order. 69. The non-volatile processor-readable medium of claim 65, wherein the first parent event contains a first set of transactions and the second parent event contains a second set of transactions, the code further comprising code that causes the processor to execute: identifying the order of the first set of transactions relative to the second set of transactions based on the order of the consensus. 70. The non-volatile processor-readable medium of claim 65, wherein the event is the first event and the computing device is the first computing device, wherein the code further comprises code that causes the processor to execute: receiving a second event from a second computing device implementing a distributed database, wherein the second event contains (1) the identifier of the third ancestor event and (2) the identifier of the fourth ancestor event, wherein the code that causes the processor to execute the construction comprises code that causes the processor to execute the construction of the DAG based on the first event, the second event, the first ancestor event, the second ancestor event, the third ancestor event, and the fourth ancestor event. 71. A method for implementing a distributed database, including: receiving on the first computing device that implements the distributed database and from the second computing device that implements the distributed database, the first event that contains (1) the identifier of the second event and (2) the identifier of the third event, while the third event is determined by the third computing device that implements distributed database; determining, on the first computing device, a fourth event, the fourth event comprising (1) a first event identifier and (2) a fifth event identifier; and calculating a consensus order of the first event, second event, third event, fourth event, and fifth event based on identifying, without receiving votes from the second computing device and third computing device, how the second computing device and third computing device would vote in the consensus protocol. 72. The method according to p. 71, characterized in that it further includes: receiving a fifth event from a fourth computing device implementing a distributed database. 73. The method of claim 71, wherein the first event identifier is a cryptographic hash of the first event. 74. The method according to p. 71, characterized in that it further includes: constructing a directed acyclic graph (DAG) based on the first event, second event, third event, fourth event, and fifth event, calculating the consensus order based on the DAG. 75. The method of claim 71, wherein the second event comprises a first set of transactions and the third event comprises a second set of transactions, the method further comprising: identifying the order of the first set of transactions relative to the second set of transactions based on the order of the consensus. 76. The method according to p. 71, characterized in that it further includes: determining the state of a distributed database based on the consensus order. 77. A method for implementing a distributed database, including: receiving on a first computing device of the plurality of computing devices data associated with the first transaction, each computing device of the plurality of computing devices having a separate instance of a distributed database operably interconnected via a network of multiple computing devices; receiving from a second computing device of a plurality of computing devices data associated with the second transaction; determining a first database clone object associated with a state associated with the distributed database, wherein the first database clone object contains an identifier and a pointer to a database in memory storing an initial value of the state; defining a second database clone object associated with the state, wherein the second database clone object contains a second identifier different from the first identifier and a pointer to a database in memory storing the initial value of the state; receiving an indication of the order of the initial transaction based on an event associated with the first transaction and an event associated with the second transaction; determining at a first time a first updated state value based on the initial state value and the initial order of the transaction; storing the first updated state value in the database and as associated with the first database clone object such that a request to read the state through the first database clone object and at a second time point after the first time point returns the first updated state value; receiving, after the first time, an indication of a transaction consensus order based on an event associated with the first transaction and an event associated with the second transaction; determining, at a third time after the first time, a second updated state value based on the initial state value and the transaction consensus order; and storing the second updated state value in the database and as associated with the second database clone object such that a request to read the state through the second database clone object and at a fourth time point after the third time point returns the second updated state value. 78. The method according to p. 77, characterized in that it further includes: retrieving a first updated state value in response to a request to the first database clone object at a fifth time point after the first time point; and retrieving a second updated state value in response to a request to a second database clone object at a sixth time point after the third time point. 79. The method of claim 77, wherein the first updated state value and the second updated state value are associated with the state of the first computing device, wherein the state of the first computing device is associated with at least one of the amount of cryptocurrency stored by the first computing device, indicating on the owner of the item or the state of the multiplayer game. 80. The method according to p. 77, characterized in that it further includes: returning an initial state value in response to a request to read the state associated with the distributed database by the second database clone object at the fifth time after the first time and before the third time; and returning a second updated state value in response to a request to read the state associated with the distributed database by the second database clone object at a sixth time point after the third time point. 81. The method according to p. 77, characterized in that it further includes: returning an initial state value in response to a request to read the state associated with the distributed database by the first database clone object at the fifth time point before the first time point; and returning a first updated state value in response to a request to read the state associated with the distributed database by the first database clone object at a sixth time point after the first time point. 82. The method of claim 77, wherein the event associated with the first transaction is the first event and the event associated with the second transaction is the second event, the first event contains the identifier of the third event and the identifier of the fourth event, wherein the second event contains a fifth event identifier and a sixth event identifier. 83. A device for implementing a distributed database, comprising: memory associated with a distributed database instance on a first computing device capable of being included in a plurality of computing devices that implements a distributed database via a network operably connected to the plurality of computing devices, wherein the memory contains an initial state value associated with the distributed database ; and processor operatively coupled to memory wherein the processor is configured to determine a first database clone object associated with the state and a second database clone object associated with the state, wherein the first database clone object contains a first identifier and a pointer to a database in memory storing the initial value of the state associated with the distributed database, while the second database clone object contains a second identifier different from the first identifier, and a pointer to the database in memory storing the initial value of the state associated with the distributed database, wherein the processor is configured to update at a first time the state value associated with the first database clone object by determining the first copy of the initial state value associated with the distributed database as associated with the first identifier, and updating the value of the first copy of the initial value the state associated with the distributed database, based on a set of events associated with the distributed database, to determine the first updated state value associated with the distributed database, wherein the processor is configured to update, at a second time point after the first time point, a state value associated with the second database clone object by determining a second copy of the initial state value associated with the distributed database as associated with the second identifier and updating the value a second copy of the initial state value associated with the distributed database based on the set of events to determine a second updated state value associated with the distributed database. 84. The device according to claim 83, characterized in that: the processor is configured to read, from a first position in the database, an initial state value in response to receiving, by means of the first database clone object and at a point in time preceding the first point in time, a request to read the state associated with the distributed database, and wherein the processor is configured to read from the second position in the database the first updated state value in response to receiving by the first database clone object and at a time point following the first time point, a request to read the state associated with the distributed database. 85. The device according to claim 83, characterized in that: the processor is configured to read, from a position in the database, an initial state value in response to receiving, by means of the first database clone object and at a third time point preceding the first time point, a request to read the state associated with the distributed database, and wherein the processor is configured to read, from a position in the database, an initial state value in response to receiving, by means of the second database clone object, and at a fourth time point preceding the first time point, a request to read the state associated with the distributed database. 86. The device according to claim 83, characterized in that: the processor is configured to read from a first position in the database a first updated state value in response to receiving, by means of the first database clone object, and at a third time point following the first time point and preceding the second time point, a request to read the state associated with distributed database, and wherein the processor is configured to read from the second position in the database the initial value of the state in response to receiving by means of the second database clone object and at the fourth time point following the first time point and preceding the second time point, a request to read the state associated with a distributed database. 87. The device according to claim 83, characterized in that: the processor is configured to read from the first position in the database the initial value of the state in response to receiving by the first database clone object and at the third time point preceding the first time point, a request to read the state associated with the distributed database, wherein the processor is configured to read from the first position in the database the initial value of the state in response to receiving by means of the second database clone object and at the fourth time point preceding the second time point, a request to read the state associated with the distributed database, wherein the processor is configured to read from the second position in the database the first updated state value in response to receiving by the first database clone object and at the fifth time point following the first time point, a request to read the state associated with the distributed database , and wherein the processor is configured to read, from a third position in the database, a second updated state value in response to receiving by means of the second database clone object and, at a sixth time point following the second time point, a request to read the state associated with the distributed database . 88. The apparatus of claim 83, wherein the distributed database is different from an in-memory database that stores state associated with the distributed database. 89. The apparatus of claim 83, wherein the updated value is the current value of the state associated with the distributed database at a third time after the second time. 90. The apparatus of claim 83, wherein the processor is configured to update the state value associated with the second database clone object by updating the value of the second copy of the initial state value associated with the distributed database based on the event set consensus order to determine a second updated state value associated with the distributed database. 91. The device according to clause 83, characterized in that: the initial state value is stored in the in-memory database as associated with a third identifier different from the first identifier and the second identifier, wherein the first updated state value is stored in the in-memory database as associated with the first identifier, and wherein the second updated state value is stored in the in-memory database as associated with the second identifier. 92. The device according to claim 83, characterized in that: in response to a request to the first database clone object, the processor is configured to read from the position in the database associated with the first identifier, or the position in the database associated with the third identifier associated with the initial state value, wherein the processor is configured to ignore the position in the database associated with the second identifier in response to a request to the first database clone object. 93. The device according to claim 83, characterized in that the state associated with the distributed database is associated with the state of the first computing device, while the state of the first computing device is associated with at least one of the amount of cryptocurrency stored by the first computing device, indicating the owner of the item or the state of the multiplayer game. 94. The device according to claim 83, characterized in that each event from the set of events contains an identifier of at least two other events. 95. A non-volatile processor-readable medium that stores code representing instructions to be executed by the processor, the code containing code that causes the processor to execute: defining a first database clone object associated with a state associated with a distributed database interconnected via a network operably connected to a plurality of computing devices that implements a distributed database, wherein the first database clone object contains a first identifier and a pointer to the database data in memory storing an initial state value associated with the distributed database; defining a second database clone object associated with the state, the second database clone object comprising a second identifier different from the first identifier and a pointer to a database in memory storing an initial value of the state associated with the distributed database; receiving at a first point in time an indication of the initial order of the set of events associated with the distributed database; updating, in response to receiving an indication of the initial order of the set of events, the state value associated with the first clone object of the database, by determining the first copy of the initial state value associated with the distributed database as associated with the first identifier, and updating the value of the first copy an initial state value associated with the distributed database, based on a set of events to determine the first updated state value associated with the distributed database; receiving, at a second time point after the first time point, an indication of the consensus order of a set of events associated with the distributed database; and updating, in response to receiving an indication of the event set consensus order, the state value associated with the second database clone object by identifying a copy of the initial value of the state associated with the distributed database as associated with the second identifier, and updating the second copy of the initial value the distributed database associated state based on the event set consensus order to determine a second updated distributed database associated state value, the second updated value being the distributed database associated state value corresponding to the consensus order. 96. The non-volatile processor-readable medium of claim 95, further comprising code that causes the processor to execute: reading from a first position in the database an initial state value in response to receiving, by the first database clone object, and at a third time point preceding the first time point, a state read request associated with the distributed database; reading from a first position in the database an initial state value in response to receiving, by the second database clone object, and at a fourth time point preceding the second time point, a state read request associated with the distributed database; reading from a second position in the database a first updated state value in response to receiving by the first database clone object, and at a fifth time point following the first time point, a request to read the state associated with the distributed database; and reading from the third position in the database a second updated state value in response to receiving by the second database clone object, and at a sixth time point following the second time point, a request to read the state associated with the distributed database. 97. A non-volatile processor-readable medium according to claim 95, characterized in that: the initial state value is stored in the in-memory database as associated with a third identifier different from the first identifier and the second identifier, wherein the first updated state value is stored in the in-memory database as associated with the first identifier, and wherein the second updated state value is stored in the in-memory database as associated with the second identifier. 98. The non-volatile processor-readable medium of claim 95, wherein the distributed database is different from an in-memory database storing state associated with the distributed database. 99. The non-volatile processor-readable medium of claim 95, wherein each event in the set of events contains an identifier for at least two other events.

Images