RU2775994C2 - Methods and device for effective implementation of a distributed database in a network - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: invention relates to computer technology. The device for implementing a distributed database contains: a memory and a processor adapted to: determine the first group of computing devices based on a deterministic pseudo-random function; receiving an event associated with the first set of events; identifying an order associated with the second set of events; identifying an order associated with a plurality of transactions; and storing in the distributed database instance an order associated with the plurality of transactions.

EFFECT: increasing the speed of convergence, while reducing the amount of data transferred between devices.

24 cl, 15 dwg

Description

Cross-reference to related applications

[1001] This application claims the priority and benefit of U.S. Provisional Application No. 62/531153, filed July 11, 2017, and entitled "Methods and Apparatus for Efficiently Implementing a Distributed Database within a Network", which is incorporated herein by reference in in all its fullness.

Background of the invention

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

[1003] Some well-known distributed database systems attempt to reach consensus for 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, it is important that the servers in the distributed database system eventually agree on which of the two users picked up the item first.

[1004] Such distributed consensus may be handled by methods and/or processes such as the Paxos algorithm or variants 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 other database system servers.

[1005] However, such known approaches use a server managed by a party (eg, a central control server) that is trusted by users of the database system (eg, game players). 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.

The essence of the invention

[1006] In some embodiments, a device includes a processor and memory operatively coupled to the processor and coupled to a distributed database instance on a first computing device adapted to be included in a group of computing devices that implement the distributed database via a network operatively coupled to the group of computing devices. devices. The processor is adapted to select an anonymous communication path associated with (a) a second computing device from a group of computing devices that implement a distributed database, and (b) a set of computing device identifiers. An anonymous communication path is defined by a sequence of masked public keys. Each masked public key in the sequence of masked public keys is associated with a computing device alias from a set of computing devices that implement an anonymous communication path. The processor is adapted to generate an encrypted message encrypted with the first masked public key included in the masked public key sequence. The first masked public key is associated with the second computing device. The processor is adapted to generate an encrypted data packet containing an encrypted message and a computing device identifier from a set of computing device identifiers. The computing device identifier is associated with the second computing device. The encrypted data packet is encrypted with the second masked public key from the sequence of masked public keys. The processor is adapted to send the encrypted data packet to a third computing device from a set of computing devices that implement an anonymous communication path.

Brief description of graphic materials

[1007] FIG. 1 is a high-level block diagram illustrating a distributed database system according to an embodiment.

[1008] FIG. 2 is a block diagram illustrating a computing device of a distributed database system according to an embodiment.

[1009] FIG. 3-6 illustrate examples of a hashgraph according to an embodiment.

[1010] In FIG. 7 is a block diagram illustrating the information flow between a first computing device and a second computing device according to an embodiment.

[1011] FIG. 8 shows an example of a hashgraph according to an embodiment.

[1012] FIG. 9 shows an example of a hashgraph according to an embodiment.

[1013] FIG. 10A-10B illustrate an exemplary consensus method for use with a hashgraph according to an embodiment.

[1014] FIG. 11A-11B illustrate an exemplary consensus method for use with a hashgraph according to another embodiment.

[1015] FIG. 12A-12B illustrate an exemplary consensus method for use with a hashgraph according to another embodiment.

Detailed description of the invention

[1016] In some embodiments, a device includes a processor and memory operably coupled to the processor and coupled to a distributed database instance on a first computing device adapted to be included in a group of computing devices that implement the distributed database via a network operatively coupled to the group of computing devices. devices. The processor is adapted to select an anonymous communication path associated with (a) a second computing device from a group of computing devices that implement a distributed database, and (b) a set of computing device identifiers. An anonymous communication path is defined by a sequence of masked public keys. Each masked public key in the sequence of masked public keys is associated with a computing device alias from a set of computing devices that implement an anonymous communication path. The processor is adapted to generate an encrypted message encrypted with the first masked public key included in the masked public key sequence. The first masked public key is associated with the second computing device. The processor is adapted to generate an encrypted data packet containing an encrypted message and a computing device identifier from a set of computing device identifiers. The computing device identifier is associated with the second computing device. The encrypted data packet is encrypted with the second masked public key from the sequence of masked public keys. The processor is adapted to send the encrypted data packet to a third computing device from a set of computing devices that implement an anonymous communication path.

[1017] In some embodiments, the first masked key is generated by selecting a first random value (R1) from a predefined set (G) of values that is an algebraic group such that R1 is a generator for G and selecting a second random value ( R2) from a predefined set (G) of values. The public key is defined as a pair (B, H) based on the first random value (R1) and the second random value (R2). A pair (B, H) is defined as (R1, R1^R2). The third random value (R3) is selected from a predetermined set (G) of values. The third random value (R3) is chosen so that B^R3 is the generator for G. The first masked key is defined as the pair (B', H') based on the public key and the third random value (R3). The pair (B', H') is defined as (B^R3, H^R3). In the context of this document, "^" means power and/or exponentiation (repeated uses of the * operator). So B^R3 means B to the power of R3 and/or applying the * operator R3-1 times to B.

[1018] In some embodiments, the nonvolatile processor-readable medium comprises code that, when executed by the processor, causes the processor to select, on a first computing device, a first random value (R1) from a predefined set (G) of values that is an algebraic group such that R1 was a generator for G, and choose a second random value (R2) from a predefined set of (G) values. The code further comprises code for causing the processor to determine the public key as a pair (B, H) based on a first random value (R1) and a second random value (R2). A pair (B, H) is defined as (R1, R1^R2). The code further comprises code for causing the processor to provide the public key (B, H) to the second computing device such that the second computing device securely provides the message (M) to the first computing device by: selecting a third random value (R3) from a predetermined set (G ) values; encrypting the message (M) using the public key (B, H) and a third random value (R3) to determine the encrypted ciphertext as (X, Y)=(B^R3, M * H^R3); and sending the encrypted ciphertext (X, Y) to the first computing device. The code further comprises code for causing the processor to receive the encrypted ciphertext (X, Y) from the second computing device and decrypt the encrypted ciphertext (X, Y) to identify the message (M) using the second random value (R2). In some cases, the public key (B, H) is a public key in disguise.

[1019] In some embodiments, the non-volatile processor-readable medium comprises code that, when executed by the processor, causes the processor to determine an anonymous communication path via a masked public key sequence for a set of computing devices from a group of computing devices that implement a distributed database. A set of computing devices defines an anonymous communication path. Each masked public key in the sequence of masked public keys is associated with an alias for a different computing device from a group of computing devices that implements a distributed database. The code further comprises code for causing the processor to generate a set of computing device identifiers comprising (1) an unencrypted computing device identifier identifying a computing device from a group of computing devices, and (2) a sequence of encrypted computing device identifiers. Each encrypted computing device identifier in the sequence of encrypted computing device identifiers is encrypted with a different masked public key from the sequence of masked public keys. The code further comprises code for causing the processor to provide a masked public key sequence and a set of computing device identifiers to at least one computing device from a group of computing devices such that the at least one computing device can determine a message for the processor to send over an anonymous communication path. The code further comprises code for causing the processor to receive, over an anonymous communication path, a message encrypted with the masked public key of the masked public key sequence and decrypt the message with the private key associated with the masked public key of the masked public key sequence.

[1020] In some embodiments, a device comprises memory associated with a distributed database instance on a first computing device adapted to be included in a plurality of computing devices that implements the distributed database via a network operatively coupled to the plurality of computing devices and a processor operatively coupled to memory. The processor is adapted to determine the first group of computing devices from the plurality of computing devices and the second group of computing devices from the plurality of computing devices based on a deterministic pseudo-random function. The processor is adapted to receive from a second computing device of the plurality of computing devices an event associated with a first set of events defined by the set of computing devices of the plurality of computing devices. The set of computing devices contains at least one computing device from the first group of computing devices and at least one computing device from the second group of computing devices. The processor is adapted to identify the order associated with the second set of events as a result of the consensus protocol (1) using the value for the event parameter from the first set of events that was determined by the computing device from the first group of computing devices, and (2) not using the value for the event parameter from the first set of events, which was determined by the computing device from the second group of computing devices. The processor is adapted to identify the order associated with the set of transactions specified in the distributed database instance based at least in part on the order associated with the second set of events and store in the distributed database instance the order associated with the set of transactions.

[1021] 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 operatively 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 adapted to determine at a first time a first event associated with the first set of events. The processor is adapted to receive, at a second time after the first time, and 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 adapted to identify the order associated with the third set of events based on at least one protocol result. 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 processor is adapted to maintain in the distributed database instance the order associated with the third set of events.

[1022] In some cases, each event from 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 matches a criterion (e.g., the number of events strongly identified by the topics 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 an indication 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.).

[1023] The value for the third attribute (eg, the accepted round number) of the attribute set may include a second numeric value based on the relationship between the event and the fifth event set 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.

[1024] In some embodiments, the device includes 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 holding an instance of the distributed database and adapted to receive a signal representing an event associated with the set of events. The processor is adapted to identify the order associated with the set of events based on at least the result of the protocol. The processor is adapted to maintain the order associated with a set of events in a distributed database instance.

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

[1026] In some embodiments, an instance of a distributed database on a first computing device may be adapted 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 connected to a distributed database instance. The database convergence module may be adapted to determine at a first time the 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 a set of transactions and (b) an order associated with a set of transactions. Each transaction in the set of transactions is a transaction in the set of transactions. The database convergence module may be adapted to receive at a second time after the first time and from a second computing device of the set of computing devices 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 adapted to define a third event associated with the first event and the second event. The database convergence module may be adapted to identify the 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 adapted 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 adapted to store in the distributed database instance the order associated with the plurality of transactions stored on the first computing device.

[1027] In some embodiments, an instance of a distributed database on a first computing device may be adapted 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 adapted to determine at a first time the 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 adapted to receive at a second time after the first time and from a second computing device of the set of computing devices 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 adapted to define a third event associated with the first event and the second event. The database convergence module may be adapted to identify the 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 adapted to preserve the order associated with the third set of events in the distributed database instance.

[1028] In some embodiments, data associated with a first transaction may be received on a first computing device of 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 contain at least a first transaction and a second transaction. A set of transaction ordinal values containing 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.

[1029] As used herein, a module may be, for example, any assembly and/or set of operatively connected electrical components associated with performing a particular function, and may include, for example, memory, processor, electrical communication channels, optical connectors, software (executable in hardware) and/or the like.

[1030] In the context of the present description, the singular form includes references defined by 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.

[1031] FIG. 1 is a high-level block diagram illustrating a distributed database system 100 according to an 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 containing computing 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 via an Internet Service Provider (ISP) and the Internet (e.g., 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.

[1032] 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 the figure). 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.

[1033] Each computing device 110, 120, 130, 140 may be any type of device adapted 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 drive, database, erasable programmable read only memory (EPROM), electrically erasable read only memory (EEPROM), read only memory (ROM), and/ or so on. 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) a record synchronization events, and/or records of previous synchronization events with other computing devices, and/or the order of synchronization events, and/or the order of transactions in events, parameters associated with identifying the order of synchronization events and/or transactions, and/or a value for the parameter ( for example, a database field that quantifies a transaction, a database field that quantifies the order in which events occur, and/or any other suitable field for which a value can be stored in the database).

[1034] The distributed database instance 114 may, for example, be adapted to perform operations on data, including storing, modifying, and/or deleting data. In some embodiments, distributed database instance 114 may be a set of arrays, a set of data structures, a relational database, an object database, a per-relational database, and/or any other suitable type of database or store. 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 associated with a vector of values. The value vector is used to determine the actual value for the parameter and/or field in that database instance 114 . In some cases, the distributed database instance 114 stores a sync event record, a record of previous sync events with other computing devices, the order of sync events, the order of transactions in events, parameters and/or values associated with identifying the order of sync events and/or transactions (e.g., used when calculating the order using the consensus method as described herein), a value for a parameter (e.g., a database field that quantifies the transaction, a database field that quantifies the order in which events occur, and/or any other suitable a field for which a value can be stored in the database).

[1035] In some cases, distributed database instance 114 may also store a database state variable and/or current state. The current state may be a state, balance, condition, and/or the like associated with the result of transactions. Similarly, the state may include a data structure and/or variables modified by transactions. In other cases, the current state may be stored in a separate database and/or portion of memory 112. In still other cases, the current state may be stored in a memory of a computing device other than computing device 110.

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

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

[1038] 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 signed with a digital signature by an authority having the authority to approve that attribute. Each attribute may also, for example, be encrypted with a public key associated with the individual or group of individuals who have 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.

[1039] In another example, distributed database instance 114 may store data related to massively multiplayer games (MMGs), such as the current status 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).

[1040] The processor 111 of the computing device 110 may be any suitable processing device adapted to start and/or execute the distributed database instance 114. For example, processor 111 may be adapted to update distributed database instance 114 in response to receiving a signal from computing device 120 and/or an instruct to send a signal to computing device 120, as described in more detail herein. More specifically, as described in more detail herein, processor 111 may be adapted 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, the processor 111 may be adapted to execute modules, functions, and/or processes to update the distributed database instance 114 in response to receiving a value for a parameter stored in another instance. distributed database instance (eg, distributed database instance 124 on computing device 120), and/or directing a value for a parameter stored in distributed database instance 114 on computing device 110 to be sent to computing device 120. In some embodiments, processor 111 may represent a a general purpose processor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a digital signal processor (DSP), and/or the like.

[1041] The display 113 may be any suitable display such as, for example, a liquid crystal display (LCD), a cathode ray tube display (CRT), or the like. In other embodiments, any of the computing devices 110, 120, 130 , 140 contains another output 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 an audio output device (e.g., a speaker), a tactile output device, and/or the like. In still other embodiments, any of the computing devices 110, 120, 130, 140 contains an input device instead of displays 113, 123, 133, 143 or in addition to them. For example, any of the computing devices 110, 120, 130, 140 may include a keyboard, mouse, and/or the like.

[1042] Although in FIG. 1 shows that everything resides in a single computing device, in some cases a processor adapted to execute modules, functions and/or processes for updating a distributed database may reside in a computing device separate from its associated distributed database. In such a case, for example, the processor may be operatively connected to the distributed database instance via a network. For example, the processor may execute a consensus method to identify the order of events and/or transactions (eg, as a result of synchronization with other distributed database instances) and may send a signal containing the order of events and/or transactions to an associated distributed database instance over the network. . The associated distributed database instance may then store the order of events, the order of transactions, and/or a state variable based on the order of transactions in the associated distributed database instance. As such, the functions and storage associated with a distributed database can be distributed. Moreover, a processor may query information from its associated distributed database instance, store state variables and/or current database states, and other suitable operations described herein in its distributed database instance, even when the database is implemented in a computing a device separate from a computing device having a processor that implements modules, functions, and/or processes (eg, a consensus method) associated with the distributed database system. In other instances, the functions and/or methods described herein may be executed on any number of computing devices (e.g., in a distributed computing environment and/or cluster) and the results and/or values of such functions and/or methods may be stored. in memory and/or storage on any suitable computing device.

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

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

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

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

[1047] 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 unit of computer code stored in memory and/or executed on a 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).

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

[1049] 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, 12, 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.

[1050] The absence of a leader in the distributed database system improves the security of the 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 increase the speed of convergence while reducing the amount of data transferred between devices, as described in more detail herein.

[1051] FIG. 2 illustrates a computing device 200 of a distributed database system (eg, distributed database system 100) according to an 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, via a network, such as network 105 shown in FIG. 1, or Internet (not shown). Similarly, communication module 210 may allow computing device 200 to send data to and/or receive data from another device.

[1052] 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 the order defined by the link scheme between events. Each event can be a record containing a cryptographic hash of the two earlier events (linking that event to the two earlier events and their parent events and vice versa), payload data (such as transactions to be recorded), other information such as as the current time, a timestamp (e.g. UTC date and time) approved by its creator representing the time at which the event was first defined, and/or the like. Each of the communicating computing devices is called "participants" or " hashgraph participants. 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 that distributed database).

[1053] In some embodiments, such a cryptographic hash of the two earlier events may be a hash value determined based on a cryptographic hash function using the event as input. In particular, in such embodiments, the implementation of the event contains a specific sequence or string of bytes (which represent the information of this event). An event hash can be a value returned by a hash function that uses 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 compute a 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.

[1054] In some cases, a set of events and their relationships may form a directed acyclic graph (DAG). In some cases, each event in the DAG refers to several (for example, two) earlier events (binding that event to earlier events and their parent events and vice versa) or does not refer to any of them, and each reference is strictly to more early events, so there are no cycles. In some embodiments, the DAG is based on cryptographic hashes, so that the data structure may be referred to as a hashgraph (also referred to herein as a "hash-based DAG"). The hashgraph directly encodes a partial order, denoting that an event X is known to occur before an event Y if Y contains a hash of X, or if Y contains a hash of an event that contains a 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.

[1055] An algorithm and/or consensus method may be used to determine the order of events in a hashgraph and/or the order of transactions stored in events. The order of the transactions, in turn, can determine the state of the database as a result of those transactions being executed according to the order. A particular database state can be stored as a database state variable. In some embodiments, a distributed database instance (e.g., distributed database instance 114) stores a hashgraph and/or transactions and/or order of transactions and/or events and/or order of events and/or state resulting from execution of transactions.

[1056] In some cases, the database convergence module may use the following function to calculate the total order from the partial order in the hashgraph. For each of the other computing devices (called "participants"), the database convergence module may examine the hashgraph to determine 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 participant in the hashgraph. 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 may 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.

[1057] FIG. 6 illustrates a hashgraph 640 of one example for determining the overall order. Hashgraph 640 illustrates two events (the bottommost circle with stripes and the bottommost circle with dots) and the first time each participant receives an indication of those 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 voices with stripes than with dots; therefore, the consensus votes for each of the participants are striped. In other words, the participants eventually agree that the stripe event happened before the dot event.

[1058] 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 event 644 (and/or an indication of that 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 hashgraph 640, Alice, Bob, and Carol each 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 event 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.

[1059] In other cases, the database convergence module may use another function to calculate the total order from the partial order in the hashgraph. 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.

[1060] In this embodiment, fast(x,y) gives the position of y in the overall order of events in the opinion of the creator(x) substantially immediately after the creation and/or determination 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.

[1061] In yet other cases, as described with respect to FIG. 8-12B, the database convergence module may use yet another function to calculate the total order from the partial order in the hashgraph. As shown in FIG. 8-9, each participant (Alice, Bob, Carol, Dave, and Ed) creates and/or defines events (1401-1413, as shown in Fig. 8; 1501-1506, shown in Fig. 9). When using the function and sub-functions described with respect to FIG. 8-12B, a general order for events can be computed by sorting the events by their received round, breaking equals by their received timestamp, and breaking those equals by their signatures, as described in more detail herein. In other cases, the overall order for events can be computed by sorting the events by their adopted round, collapsing the equals by their adopted generation (instead of their adopted timestamp), and collapsing those equals by their signatures. The following paragraphs detail the functions used to compute 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. 8–12B.

[1062] "Parent": Event X is the parent of event Y if Y contains a hash of X. For example, in FIG. 8, the parents of event 1412 include event 1406 and event 1408.

[1063] "Ancestor": The ancestors of event X are X, its parents, its parents' parents, and so on. For example, as shown in FIG. 8, the ancestors of event 1412 are events 1401, 1402, 1403, 1406, 1408, and 1412. An event's ancestors can be said to be attached to that event, and vice versa.

[1064] "Descendant": The descendants of event X are X, its children, its children's children, and so on. For example, as shown in FIG. 8, 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. An event's children can be said to be attached to that event and vice versa.

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

[1066] "M": the smallest integer that is greater than a certain percentage of N (eg, greater than 2/3 of N). For example, as shown in FIG. 8, 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.

[1067] 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. 8, event 1405's own parent is 1401.

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

[1069] "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. 8, event 1405's own parent is 1401. Since event 1401 sequence number is one, event 1405 sequence number is two (ie, one plus one).

[1070] "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. 8, 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).

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

[1072] "Round Number" ("Round Number" or "RN"): An integer attribute of the event. In some cases, it also refers to the round that is created or the round that was created. In some cases, the round number can be defined as the maximum value of the round numbers of the event's parents plus the event's round increment. For example, as shown in FIG. 8, 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. 8, 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.

[1073] "Forking": An event X together with an event Y are a fork if they are defined and/or created by one participant, and neither is the other's own ancestor. For example, as shown in FIG. 9, 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.

[1074] Branch "Identification": A branch can be "identified" by a third event created and/or determined after two events that together are branches, if both of those two events are ancestors of the third event. For example, as shown in FIG. 9, 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.

[1075] "Event Identification": An event X "identifies" or "sees" an ancestor event Y if X does not have an ancestor event Z that branches along with Y. For example, as shown in FIG. 8, event 1412 identifies (i.e. "sees") event 1403 because event 1403 is an ancestor of event 1412 and event 1412 does not have 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 events of that member 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.

[1076] "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 is 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 of which can identify Y, and which (6) are created and/or defined by at least M different contributors. For example, as shown in FIG. 8, 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.

[1077] "First event of round R" (also referred to herein as "witness" or "witness"): the event is the "first event of round R" (or "witness") if event (1) has a round number R and (2) has its own parent having a round number that is less than R, or does not have its own parent. For example, as shown in FIG. 8, 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 (i.e., less than two).

[1078] 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. 8, 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.

[1079] In some cases, the following method can be used to determine whether an event X can strongly identify an ancestor event Y. event number X, where that participant created and/or defined event X, and X can identify Y. For each event Z, an array A2 of integers, one per participant, is maintained that specifies the highest sequence number of event W created and/or defined by topic member 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. 8, participants 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.

[1080] Another implementation of a 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, the calculations may be performed using processor-specific instructions such as the Advanced Vector Extensions (AVX) instructions provided by Intel. and AMD, or equivalent in 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.

[1081] "Famous" event: event X of round R is "known" if (1) event X is the "first event of round R" (or "witness"), and (2) the decision is "YES" achieved by following the 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. 8, 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 hashgraph will grow upwards, and as a result, the other four participants will also have the first events of round 2 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. Those 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.

[1082] 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 G round, 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 those 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.

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

[1084] Similarly, if X is a witness of round R (or the first event of round R), then the voting results in rounds R+1, R+2, and so on can be computed, with the witnesses in each round voting on whether 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 voting 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.

[1085] As an example, in FIG. 8 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 vote 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). That vote will then be used in the next round, continuing until an agreement is reached.

[1086] 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, then 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 signature of event X.

[1087] Similarly, 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 another suitable number), then the election does not end on that 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 Y event signature bit (e.g., least significant bit, most significant bit, random bit), where 1=YES and 0=NO, or vice versa, according to the Y event timestamp, 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.

[1088] For example, as shown in FIG. 8, 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 ).

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

[1090] As described above, in some implementations, the hashgraph consensus method may involve deciding, for example, on the notoriety of witness X in the R round. As described above, the initial votes may be collected from the R+1 round by counting the YES or NO votes of each event according to whether it is a child of X. An alternative approach might involve collecting initial votes from "R+2" instead of "R+1" (or "R+3", "R+4", etc. instead of "R +1"). In that approach, an additional step can optionally be added. In particular, in such an implementation, each time the first event X of round R (or witness X of round R) is an ancestor of round R+1 witnesses created and/or defined by more than two-thirds of the population (i.e., more than 2N/3 participants), X is immediately declared known, and the election is immediately concluded, even before any votes for X have been counted. A second alternative approach could involve running an election for R with the initial votes collected from R+1, then if the number of participants who created and/or identified witnesses in the R round who were determined to be known is less than a given threshold T, rerun the election a second time with the original votes collected from R+2.

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

[1092] "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 round R events (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 round events R (or known witnesses) with round number R are descendants of X and/or can see X.

[1093] 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 that list.

[1094] 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, a modified mean (eg, by removing the earliest and latest timestamps from the calculation), and/or the like. In yet other cases, an extended median may be used.

[1095] In some cases, the overall order and/or consensus order for events is computed by sorting the events by their accepted round, collapsing the equalities by their adopted timestamp, and collapsing those equalities by their signatures. In other cases, the overall order for events can be computed by sorting the events by their accepted round, breaking down the equalities by their taken generation, and breaking down those equalities by their signatures. The above paragraphs detail the functions used to calculate and/or determine the received round, received timestamp, and/or received event generation.

[1096] 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. The result of XOR signatures of known witnesses in a given round is a pseudo-random number that is difficult to predict and/or difficult to manipulate by potential attackers and other actors. Thus, in some implementations, XOR signatures can be used as a source of unpredictable random numbers (i.e., "random flag"). Random numbers can be used in several hashgraph processes, including the execution of smart contracts, as discussed below.

[1097] In some implementations, the method of achieving consensus can be adapted so that the executable script or program ("smart contract") is executed by each participant in the hashgraph (for example, the processor of each participant or computing device). A smart contract can be a self-executing contract, a blockchain contract, or a digital contract converted into computer code, stored and duplicated in a hashgraph, and controlled by hashgraph participants. Smart contracts can be used, for example, to exchange money, property, shares, and other suitable transactions. Participants can record the results of an executed smart contract in a distributed database or distributed ledger. In some other implementations, the consensus algorithm can be adapted so that some of the participants (rather than each participant) run a smart contract based on non-deterministic code, the outcome of which is a computer time distribution function, or the results of communicating with another computer (for example, in addition to participants in a distributed Database). Accordingly, the set of participants selected to and/or eligible to execute a smart contract may be selected based on a deterministic pseudo-random random flag function (given, for example, based on the result of XOR signatures of known witnesses). Each of the selected participants can generate a transaction to record the output or results obtained as a result of running a smart contract. In some cases, if more than two-thirds of the selected participants receive matching results, then such results are considered as the official output of the contract, and the state of the distributed database or registry can be modified to reflect the consensus on the smart contract, respectively. In some other cases, where there is no single output or result that more than two-thirds of the selected participants agree or agree on, then the smart contract is considered to have failed and the state of the distributed database or ledger does not change. In other implementations, the threshold of two-thirds of the selected participants may be any other suitable threshold. For example, in some implementations, the threshold may be different for each smart contract launch.

[1098] In some cases, smart contracts may be non-deterministic due to the fact that they use purely random numbers received from a hardware device by accessing a network or an external computer such as a web server (“oracle”), and/or for a given time limit. In some cases, when a participant or computing device is executing a smart contract and the contract produces no output for a given number of milliseconds, then the computing device terminates or stops the smart contract and reports that it has no output. In some cases, the computing devices of the participants may start at different speeds, making the process non-deterministic. In addition, in some cases, the computing devices of the participants may be adapted to run at their full speed the compiled code, without running the interpreter and/or counting the number of indicators that have been executed so far by the computing device.

[1099] 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, with breaking 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.

[1100] 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. 8, the list of timestamps for event 1401 may include the timestamps for events 1402, 1403, 1403, and 1408. In some cases, the timestamp for event 1401 may also be included. the same received round) the average timestamps of the list of each event (or the predefined 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.

[1101] In still other cases, "truncated extended median" may be used instead of "extended 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.

[1102] 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 matches a certain deadline. or an earlier point in time. In that case, Bob will not be bound by the contract if Alice signs it after the deadline indicated by the "accepted median timestamp" as described above.

[1103] In some cases, the state of a distributed database may be determined after a 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 that 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), that 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.

[1104] In some implementations, a hashgraph may be used to implement a revocation service. The revocation service may record or store information about whether certain objects are still genuine. In some cases, the revocation service can be used to store authentic or unexpired hashes of authority-issued credentials that the authority can later revoke (e.g., DMV-issued driver's licenses that may be later revoked by DMV; government-issued passports, which may be later annulled by the state; membership information for the club; etc.). In some cases, a revocation service may use a transaction type to add a new entry to a distributed database or ledger of the form (H, T, L) where H is a cryptographic hash associated with an object or subject, T is a notation for "type » object or subject, L is a list of public keys, and the entry is signed with more than one private key associated with the public keys included in the list L, or not signed with any of them. An additional type of transaction that may be used by the revocation service may remove or remove a given hash H. Such a transaction may be adapted to be signed with a private key associated with one (or multiple) of the public keys in the list L associated with hash H to be removed or removed. Other types of special transactions that can be used by the revocation service include transactions to retrieve a record given its hash H, and transactions to retrieve, for example, all records from a certain time and date that have a given value T, and other suitable transactions. Although the above transactions have been discussed in relation to the revocation service, such transactions may be used by other suitable services in the hashgraph.

[1105] In some cases, M (as described above) may be based on the weights assigned to each participant, rather than just a fraction, percentage, and/or value of the number of all 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. We can say that each event defined by that participant has the weight value of its defining participant. Then M can be a part of the total share of all participants. The events described above as dependent on M will occur when a set of participants with a total number of shares of at least M comes to an agreement. 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. Votes regarding whether the events of round R are known will use the old stakes and list of participants, but votes regarding rounds after R will use the new stakes and list of participants. Additional details regarding the use of weights to determine consensus are described in U.S. Provisional Application No. 62/344,682, filed June 2, 2016, entitled "Methods And Apparatus For A Distributed Database With Consensus Determined Based On Weighted Stakes", which is incorporated herein. document by reference in its entirety.

[1106] In some cases, certain participants may be identified and/or designated as "lazy participants". In such cases, lazy participants can define and/or create events in the same way as normal participants or non-lazy participants. In addition, events defined and/or created by lazy participants can be included in the hashgraph, and the consensus order for such events can be computed and/or identified. However, the round increment for events defined by lazy participants is zero. Accordingly, the round number (or the round that is created) for the event defined by the lazy participant is equal to the maximum of the round numbers of the event's parents. Similarly, since the round increment for events defined by lazy participants is zero, the round number (or round that is created) for an event defined by a lazy participant cannot exceed the maximum round numbers of the event's parents.

[1107] Moreover, in some cases, events defined by lazy participants are not eligible to vote in elections, and events defined by lazy participants are not eligible to become the first events or witnesses of the R round and / or are not counted as intermediate events for the event, defined by a normal or non-lazy participant in order to strictly see another event. Accordingly, restrictions placed on lazy participants result in a reduction in the computations performed by the hashgraph while still maintaining the security and integrity of the consensus order. Members can be selected as lazy members based on any suitable criteria. For example, in some cases, participants may be assigned as lazy participants based on a deterministic pseudo-random selection performed in each round, predetermined at the start of the round, based on trust levels, based on share volume, based on the vote of other participants, and/or selection randomly. . In some cases, participants designated as lazy participants may be different for each round, while in some other cases, participants designated as lazy participants remain so throughout different rounds. In some other cases, events rather than participants may be designated as "lazy" events. In such a case, lazy events can be selected in each round instead of selecting participants.

[1108] Accordingly, in some cases, the processor of the first participant may determine the first group of participants (eg, computing devices) and the second group of participants (eg, computing devices) based on a deterministic pseudo-random function. The first group of participants may represent non-lazy participants, and the second group of participants may represent lazy participants. In some cases, the first group of participants is the absolute complement of the second group of participants with respect to the participants (eg, computing devices) of the distributed database. The first participant (or the processor of the first participant) may receive from the second participant (eg, from a computing device) an event associated with a first set of events defined by a set of participants (eg, a set of computing devices). The member set contains at least one member from the first member group and at least one member from the second member group. The processor can identify the order associated with the second set of events as a result of the consensus protocol (eg, as described herein) using a value for a parameter (eg, round number, round increment, vote, indication that someone is a witness, indicating that someone is a known witness, etc.) of an event from the first event set that was defined by a participant from the first group of participants, and does not use a value for the event parameter from the first event set that was defined by the participant from the second group of participants. The processor may identify the order associated with the transaction set specified in the distributed database instance based at least in part on the order associated with the second set of events and may store the order associated with the transaction set in the distributed database instance.

[1109] The foregoing terms, definitions, and algorithms are used to illustrate the embodiments and concepts described with respect to FIG. 8–10B. In FIG. 10A and FIG. 10B illustrates a first exemplary application of the consensus method and/or process, shown in mathematical form. In FIG. 11A and FIG. 11B illustrates a second exemplary application of the consensus method and/or process shown in mathematical form, and FIG. 12A and FIG. 12B illustrates a third exemplary application of the consensus method and/or process, shown in mathematical form.

[1110] 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 (eg ASIC, FPGA, etc.).

[1111] In some cases, a distributed database (eg, shown and described in relation to Fig. 1) may allow the processing of "intermediary transactions". In some cases, such intermediary transactions may be made by a distributed database participant on behalf of a person who is not a distributed database participant, a distributed database participant with less than full rights (for example, having read rights but not write rights, not having influence to consensus decisions, etc.), and/or the like. limited rights). Let's assume that Bob is a full member and has full rights in the distributed database. In this case, Alice can send a TR transaction to Bob, and Bob can send a TR to the network in order to influence the distributed database. In some cases, Alice may sign the TR with a digital signature. In some cases, the TR may contain, for example, a payment to Bob (eg, a fee for his service of submitting the TR to a distributed database). In some cases, Alice may send a TR to Bob via an anonymizing network, such as the TOR onion routing network, so that neither Bob nor other observers can determine that the TR came from Alice.

[1112] In some instances, a distributed database (eg, as shown and described in relation to FIG. 1) may be used to implement a cryptocurrency. In such a case, each distributed database instance 114, 124, 134, 144 may define one or more wallet data structures (also referred to herein as wallets) for storing cryptocurrency. In some cases, users who are not associated with the distributed database (for example, computing devices that are not members of the distributed database) may also create and/or define such wallets. The wallet data structure may contain a key pair (public key and private key). In some cases, a key pair for a wallet may be generated by the computing device on which the wallet is created. For example, if Alice defines a wallet (W, K), where W is the public key (which can also serve as an identifier for the wallet) and K is the private key, she can publish W (e.g. in an event) to the rest of the distributed database instances. , while keeping its identity anonymous so that other distributed database instances (or their users) cannot identify that purse W is associated with Alice. However, in some cases, cryptocurrency transfers are open. Thus, if her employer transfers money to W (for example, by using a transaction in an event), and then Alice makes a purchase by transferring money from W to a store (for example, using a different transaction in a different event), then the employer and the store can agree for the purpose of determining that W belongs to Alice and that the purchase was made by Alice. Thus, in order to avoid this, it may be useful for Alice to transfer money to a new anonymous wallet in order to keep her transactions anonymous.

[1113] The following example assumes that C crypto coins are transferred from wallet W to wallet R if the next transaction is published (for example, in an event), where _K at the end means that the transaction is digitally signed with a private key K. The following notation may be used:

TRANSFER(C, W, R)_K

[1114] In some cases, a new transaction type and/or a distributed database function may be defined to achieve anonymity in a cryptocurrency transfer. For example, the following transactions will transfer C1 coins from wallet W1 to wallet R1, as well as transfer C2 coins from wallet W2 to wallet R2. In some cases, for example, each of the wallets W1, R1, W2, R2 may be associated with a member (or computing device) of a distributed database, or with a user that is not associated with a distributed database (or a computing device associated with a distributed database). ). The four wallets may be associated with the same member or user, or may be associated with different members or users. In some cases, transactions may include an arbitrary identifier N (eg, a transformation identifier and/or a process identifier) that is intended to connect them.

TRANSFER_DOUBLE(N, C1, W1, R1, C2, W2, R2, T)_K1

TRANSFER_DOUBLE(N, C1, W1, R1, C2, W2, R2, T)_K2

[1115] In some cases, these transactions have no effect until purse W1 contains at least C1 coins and purse W2 contains at least C2 coins. In some cases, these transactions have no effect until they are published and distributed to other distributed database instances, two identical copies (for example, in one or more events), one signed by K1 (using the private key associated with the public key of W1), and the other is signed by K2 (using the private key associated with W2's public key). In some cases, each transaction may also contain a secure timestamp, as described above. This secure timestamp can be the secure timestamp of the event to which the transaction is associated, or a separate secure timestamp of the transaction. If both transactions are posted with timestamps within T seconds of each other (eg secure timestamp of transactions within a predefined time period of each other), then both currency transfers will occur. Otherwise, none of the translations takes place. In some cases, a transaction may be created and/or defined with an expiration date and time T, and the transfer will not occur until both signed transactions have consensus timestamps prior to T.

[1116] In other cases, T is not used, and the currency transfer occurs only if both transactions occur before either party makes a transaction that reverses the transfer. For example, Alice may publish her signed transaction (eg, her TRANSFER_DOUBLE transaction), then publish another signed transaction containing a cancel message for that first transaction, then Bob publishes her signed transaction. The transfer will not occur if Bob's transaction was later than Alice's cancel message, but the transfer will occur if Bob's transaction was earlier than Alice's cancel message. In this way, the system can operate without T and without timestamps, using an ordered sequence of transaction consensus. In other cases, both T and cancel messages may be supported.

[1117] The following example illustrates how a transaction of type "TRANSFER_DOUBLE" and/or a distributed database function can be used to anonymously and securely initiate a transfer of data (such as currency). In the following example, Alice has purse W1, to which her employer has transferred money. She wishes to transfer C coins from W1 to an anonymous purse W2 she creates, which will later be used for purchases. But she wants to have secure anonymity so that no one viewing the transactions knows that W1 is linked to W2's anonymous wallet. It must be secure, even if her employer is partnering with the store to attack anonymity. In addition to this, for example, Bob desires the same secure anonymity when transferring coins from his W3 wallet to an anonymous W4 wallet he creates.

[1118] Alice and Bob can achieve a form of anonymity by executing the following protocol. It may include any form of communication with each other, such as direct email correspondence with each other, sending messages to each other through a text messaging site or online forum site, or through transactions published in a public distributed database or registry (for example, , in events). The following example assumes that the protocol is executed through a public registry. Suppose that Alice and Bob are strangers at first, but both have the ability to publish transactions on a public ledger and can read transactions that others post on a public ledger. Alice and Bob may publish the following transactions on the public ledger (for example, in one or more events):

Alice posts: Anonymize1(N, C, W1)_K1

Bob counts: B = encrypt(W4, W1)

Bob posts: Anonymize2(N, W3, B)_K3

Alice counts: A = encrypt(W2, W3)

Alice posts: Anonymize3(N, A)_K1

Both count: MIN = min(W2, W4)

Both count: MAX = max(W2, W4)

Bob posts: TRANSFER_DOUBLE(N, C, W1, MIN, C, W3, MAX, T)_K3

Alice publishes: TRANSFER_DOUBLE(N, C, W1, MIN, C, W3, MAX, T)_K1

[1119] In this example, Alice wants to transfer C coins from purse W1 to W2, and Bob wants to transfer C coins from purse W3 to W4. Alice and Bob each generate their own wallets by generating a key pair (public key, private key) for each wallet. Here, the public key for the wallet is also used as the name of the wallet (in other cases, a separate identifier can be used to identify the wallet). Alice and Bob want to make these transfers in such a way that observers can identify that the owner of wallet W1 is also the owner of either W2 or W4, but cannot identify which one. Similarly, Alice and Bob want to make these transfers in such a way that observers can identify that the owner of wallet W3 is also the owner of either W2 or W4, but cannot identify which one. The public key wallet W1 has the private key K1. Similarly, wallets W2, W3 and W4 have private keys K2, K3 and K4 respectively. Each transaction or instruction above is signed with the private key listed at the end. For example, the initial transaction or instruction is digitally signed using the private key K1.

[1120] The first transaction (Anonymize1(N, C, W1)_K1) is used to announce that Alice wants to transfer C coins from W1 to an anonymous wallet. This transaction contains an identifier number N, which may be the hash of the transaction, a random number contained in the transaction, and/or any other suitable identifier. This N (e.g., transformation ID and/or process ID) is used in subsequent transactions to refer back to the transaction that started the process, to avoid confusion (and to allow the process or transformation to be identified) if there are multiple similar processes and/or transformations. occurring at the same time. In some cases, N may contain a timeout deadline after which transactions involving N are ignored. This transaction is digitally signed by K1.

[1121] The function encrypt(W4, W1) encrypts W4 (the public key of the wallet owned by Bob and designated by him as his target anonymous wallet) using the public key of W1, resulting in B, which can only be decrypted with the corresponding private key K1 (held by Alice). This ensures that none of the other distributed database instances viewing the transaction can identify W4, except for the owner of W1 (Alice in this example).

[1122] The transaction Anonymize2(N, W3, B)_K3 indicates that, as part of a process or transformation N, Bob wishes to transfer C coins from W3 to an anonymous wallet identified by B. This transaction is digitally signed with using the K3 private key. Alice can then decrypt B using the private key K1 to identify Bob's target anonymous wallet as W4.

[1123] Alice can execute encrypt(W2, W3). This encrypts W2 (the public key of the wallet owned by Alice and designated by her as her target anonymous wallet) with the public key of W3 (Bob's original wallet). Alice can then post the transaction Anonymize3(N, A)_K1. Bob can identify W2 as Alice's target anonymous wallet by decrypting it with K3's private key.

[1124] The min(W2, W4) function returns which of the two public keys W3 and W4 is the first lexicographically (in alphabetical order). The max(W2, W4) function returns whichever of the two public keys W3 and W4 is the last one lexicographically (in alphabetical order). Thus, MIN can be either W2 or W4, and MAX can be either W2 or W4. The min and max functions allow ordering of wallets W2 and W4, both of which can be identified by Alice and Bob, but which do not indicate which wallet was created and/or defined by Alice and which was created and/or defined by Bob. In other cases, any other deterministic function can be used to identify, with respect to Alice and Bob, how to order the anonymous wallets W2 and W4, such as sorting by key hash, ranking, and/or the like.

[1125] TRANSFER_DOUBLE transactions can be published by both Bob and Alice and signed with their respective private keys K1 and K3. Due to the fact that both Bob and Alice transfer the same amount of coins C to each of their respective anonymous wallets, it does not matter which source wallet W1 or W3 transfers coins to which destination wallet W2 or W4. So in some cases Alice transfers C coins to her own anonymous wallet and Bob transfers C coins to his own anonymous wallet. In other cases, Alice transfers C coins to Bob's anonymous wallet, and Bob transfers C coins to Alice's anonymous wallet. This is determined by the MIN and MAX functions. This also ensures that observers can identify both W2 and W4, but will not be able to identify which wallet was identified by the owner of W1 and which wallet was identified by the owner of W3. After the transactions are published, the observer knows that the owners of wallets W1 and W3 are interacting to transfer C coins to each of the wallets W2 and W4, but the observer will not know which sender owns which receiving wallet, and thus wallets W2 and W4 will be slightly more anonymous than the W1 and W3 wallets.

[1126] In some cases, transactions may be "intermediary transactions", which means that a node in the network submits transactions on behalf of the other party. In the example above, Alice is the owner of wallets W1 and W2 and wants to publish multiple transactions. If Carol is a member of the distributed database with full rights, then Alice can send transactions to Carol to be submitted to the network on behalf of Alice. In some cases, an intermediary transaction may include permission to transfer a small fee from Carol's W1 wallet as payment for this service. In some cases, Alice may communicate with Carol over a network that anonymizes the communication, such as, for example, the TOR onion routing network. In some cases, Alice may also be a member but work through Carol for anonymity. In some cases, Alice is not a member.

[1127] In some cases, for example, Alice may then repeat the above anonymity protocol with Dave, and Bob may repeat the protocol with Ed. At that moment, other instances of the distributed database will be able to identify that Alice is the owner of one of the 4 wallets, but will not know which one. After 10 such runs, Alice is the owner of one wallet out of 210, which is 1024. After 20 runs, the set is over a million. After 30, it is over a billion. After 40, it is over a trillion. The protocol run should take a fraction of a second. But even if each protocol takes a full second to run, anyone who attempts to anonymize their wallet will randomly switch places with someone else in much less than a minute. The observers know that Alice is the owner of one of the resulting purses, but do not know which one.

[1128] This system may be less secure if only a few people attempt to anonymize their wallets. As an additional security measure, Alice can wait for a certain period of time (for example, a day, an hour, a week, etc.) and then further anonymize her final wallet when additional users participate. In this way, she may end up hiding among the crowd, which includes other users who have been trying to anonymize for a very long period of time. The more users using the system, the faster it can reach its goal. This system can be secure if there are a large number of users anonymizing their wallets, even if there are very few participants acting as intermediaries for them.

[1129] This system can potentially be compromised if an attacker can identify Alice's IP address when she communicates with a network implementing a distributed database (eg, the Internet). If an attacker identifies that Alice ran the protocol from a specific IP address and knows that she is the owner of either W2 or W4, and then immediately sees that someone has run the protocol on W2's wallet from the same address, he can come to the conclusion that Alice is the owner of the W2 wallet. The solution is to anonymize IP addresses. For example, an anonymous communication network (eg, the Tor network) can be used to achieve anonymous communication. The remaining distributed database instances can then identify that W2 started the protocol and signed transactions, but cannot identify whether W2 is using Alice's computer or Bob's computer.

[1130] In some cases, after Alice has transferred her cryptocurrency to a truly anonymized wallet, she can then spend the cryptocurrency on multiple transactions without the transactions being traced back to her. Additionally, Alice can split her cryptocurrency among many anonymized wallets and then buy multiple items, each using a different wallet, without showing that they were purchased by the same person and/or entity.

[1131] As described above, users can anonymize their IP address when communicating with a hashgraph participant that acts as an intermediary. In some implementations, they may achieve this through an existing anonymizing network, such as the TOR network. In other implementations, they may achieve this using the type of anonymizing network described below, which is based on the public key cipher described below.

[1132] The public key cipher is designed to do the following, where a "participant" is a computer that acts as part of an anonymizing network and/or is part of a hashgraph network and is willing to act as an intermediary for it:

the participant can create and/or define a pair of public-private keys;

a participant can take an existing public key (masked or not) and create and/or determine a masked version of the existing public key, i.e. a version of the public key with a different masking property (unbindability), by, for example, combining the public key with a masking factor (e.g., random masking factor). The masked public key is unbindable in the sense that the owner of the masked public key cannot identify the public key from the masked public key without a specific masking factor;

the participant can take an existing public key (masked or not) and a ciphertext encrypted with the existing public key and generate a masked version of that ciphertext;

the encrypted message can only be decrypted with the original private key, even if the public key was masked several times before encryption or never masked, and even if the ciphertext was masked several times after encryption or never masked;

without knowing the private key, it is impossible to determine whether two public keys have the same private key, or whether two ciphertexts have been encrypted with the same public key, or whether two ciphertexts have the same plaintext, or whether ciphertext is the specified plaintext.

[1133] An exemplary cipher to achieve the above conditions is discussed below. Participants (eg, computing devices and/or processors) may execute the steps to execute this cipher. First, members and/or members are aware of, store, generate, and/or define a mathematical group and/or set of G values, along with enough information to quickly recognize G generators. For example, members may be aware of a predefined a set of G values (eg, each member and/or participant can independently generate and/or receive a common set of G values). In some cases, the predefined set of G values may be any algebraic group (eg, numbers, elliptic curves, etc.). For example, in some cases, the set of values may be the set of numbers G={1,2,3,…,2P} multiplied modulo 2P+1, where both P and 2P+1 represent a prime element. In such cases, the group operator * can be defined as multiplication modulo 2P+1, and exponentiation can be defined as repeated multiplication modulo 2P+1. In such an example, an element D of G is a generator if and only if neither D^2 nor D^P is congruent to 1 modulo (2P+1). Of the 2P elements in G, phi(2P)=P-1 of them are generators, which is about half.

[1134] Members and/or participants know, store and/or can determine G and know enough information to recognize generators. So for the above example, the members know P and know G={1,2,3,…,2P} with multiplication and exponentiation modulo 2P+1. In some implementations, the cipher is defined as follows:

key generation: choose or choose random R1, R2 from G (for example, random values of R1 and R2). If R1 is not a generator for G, then a new random R1 is re-selected until a generator is found. Thus, R1 is a generator for G. The public key can be defined as a pair (B,H) which is based on the first random value of R1 and the second random value of R2, so that (B,H)=(R1, R1^R2 ), and the private key is S=R2;

message encryption: given a (possibly disguised) public key (B,H) and a plaintext message F (possibly with a deterministic transformation or padding, but not a non-deterministic random transformation or padding), choose or choose a random R3 (for example, a random value R3) from G. The plaintext message F can then be encrypted using the public key (B,H) and the random value R3 to determine the ciphertext as (X,Y)=(B^R3, F * H^R3) . In some cases, the encrypted ciphertext can be encrypted using a masked public key (B',H') or a public key (B,H) that has not been masked. Key masking is described below;

key masking: given a (possibly masked) public key (B,H), a random R4 (e.g., a random value of R4) is selected from G. The masked public key can be defined as a pair (B',H') that is based on the public key (B,H) and a random value R4, so (B',H')= (B^R4, H^R4). If B^R4 is not a generator for G, then a new random R4 is re-selected until B^R4 is a generator for G. Thus, B^R4 is a generator for G;

message masking: Given the ciphertext (X,Y) and the (possibly masked) public key (B,H) that was used to encrypt the ciphertext (X,Y), a masked encrypted message (X',Y') can be generated. For example, a random R5 (eg, a random value of R5) can be chosen and/or selected from G. The masked ciphertext and/or ciphertext can then be defined as (X',Y')=(X*(B^R5), Y*(H^R5)). In some cases, the ciphertext can be masked using a masked public key (B',H') or a public key (B,H) that has not been masked.

[1135] In some cases, the cipher described above may be used to encrypt and securely send a message (e.g., directly or by posting the message to a distributed database and/or distributed registry) from a first computing device (e.g., the first participant) to a second computing device (for example, to the second participant). For example, in some cases, the processor of the second computing device may select a first random value R1 from a predetermined set of values G, which is an algebraic group. The first random value R1 is selected as a generator for G. The processor may select a second random value R2 from a predetermined set of G values. The processor may then determine the public key as a pair (B, H) based on the first random value R1 and the second random value R2. The pair (B, H) representing the public key can be defined as (R1, R1^R2).

[1136] In some cases, the processor of the second computing device may provide a public key to the first computing device. The processor of the first computing device may choose a third random value R3 and encrypt the message M using the public key (B, H) and the third random value R3 to determine the encrypted ciphertext as (X, Y)=(B^R3, M * H^R3) . The processor of the first computing device may then send the encrypted ciphertext to the second computing device. The processor of the second computing device may receive the encrypted ciphertext and decrypt the encrypted ciphertext to identify the message M using the private key determined based on the second random value.

[1137] In other cases, the processor of the second computing device may mask the public key to determine a masked public key to provide to the first computing device (instead of a public key that has not been masked). The processor of the first computing device may then use the masked public key to encrypt the message to determine the encrypted ciphertext. In such cases, the processor of the second computing device may mask the public key by selecting a fourth random value R4 from a predetermined set of G values such that B^R4 is a generator for G. The processor may determine the masked public key as a pair (B', H') based on the public key (B, H) and a fourth random value R4, so (B', H')=(B^R4, H^R4).

[1138] In some cases, the processor of the first computing device may mask the encrypted ciphertext (X, Y) before sending the encrypted ciphertext to the second computing device. For example, the processor of the first computing device may select a fifth random value R5 from a predetermined set of G values. Based on the public key received from the second computing device (unmasked or masked) and the fifth random value R5, the processor of the first computing device may determine the masked encrypted message as (X',Y')=(X*(B^R5), Y* (H^R5)). The processor of the first computing device may then generate an encrypted data packet containing the masked encrypted message and send the encrypted ciphertext as a masked encrypted message to the second computing device.

[1139] The cipher described above can be used to create a new system for communication among participants, showing only aliases, without the need to disclose information such as IP addresses. For example, members {Alice, Bob, Carol, Dave, Ed} can publish their IP address along with their public name. Each participant can generate a key pair whose public key acts as its alias when making anonymized communication over the network. In some cases, Ed may allow other members to send messages to him without Ed having to identify or share his IP address. Ed can publish his alias (eg his public key) along with one or more paths. A "path" is a sequence of participants through which messages must be routed in order to reach it. For example, Ed can choose the sequence {Bob, Carol, Dave, Ed} as a path, which means that the second computing device can send a message to Bob, who will send it to Carol, who will send it to Dave, who will send it to Ed. Returned messages can follow the same path in reverse. Paths may be specified using aliases instead of other information that may indicate a user ID. As such, such a path may be an anonymous communication path. For example, Ed can create and publish the path {Bob, Carol, Dave, Ed} by performing the following steps. Ed can first mask each of the four public keys for those four participants (for example, by using the cipher mentioned above). Ed can then take the list of names {Carol, Dave, Ed} (which is the same list minus its first element, i.e. Bob) and encrypt each of those names using the masked public key Ed created for { Bob, Carol, Dave} respectively. The ed may then publish a "path" that contains (1) four masked keys (eg, a sequence of masked public keys) and (2) a set of participant computing device identifiers (eg, computing device). Such a set of computing device identifiers contains three encrypted names (a sequence of encrypted computing device identifiers that are uniquely associated with different participants) and the public name Bob without any encryption or obfuscation (an unencrypted computing device identifier). Such computing device identifiers may be aliases and are associated with a masked public key. In some implementations, Ed may skip the key masking step for the first name (Bob in this example) and only mask the rest of the keys.

[1140] If Alice (eg, the first computing device) wishes to send a message to the alias that Ed is using (eg, the second computing device), Alice may search for paths associated with Ed's alias and select one of those paths. For example, Alice may take or choose a path created from {Bob, Carol, Dave, Ed}. Accordingly, Alice may determine and/or generate an encrypted message by encrypting the message with a disguised public key for Ed created by Ed, specifically in this way. Alice can take the name (or alias) "Ed" (eg, the computing device identifier for the second computing device) and encrypt the name (or alias) "Ed" using Dave's disguised public key. This encrypted name may be masked and then appended to an encrypted message for Ed to generate and/or define an encrypted data packet. Alice can then repeat this to process the message in the reverse order of the chosen path. Accordingly, Alice can encrypt a packet (eg, an encrypted name attached to an encrypted message) using a masked public key for Dave. Alice can then attach a masked version of Dave's name, encrypted with Carol's key, to the packet. Alice then encrypts that entire packet using Carol's key. Then he attaches a disguised version of Carol's name encrypted with Bob's key. Bob is at the beginning of the path or list, so the encryption process for the selected path stops here.

[1141] At this point, Alice has created a large package. Bob's name is the only one that Ed included in plaintext, so Alice knows that the path starts with Bob. Therefore, Alice sends the entire final packet to Bob. He then decrypts the packet with his private key, then decrypts Carol's name with his private key, then removes her name and sends what's left to Carol. Carol does the same by sending Dave a smaller package. Dave does the same and sends to Eda. Finally, Ed decodes what he receives and is able to read the message.

[1142] Using the cipher described above, which provides obfuscated keys and obfuscated messages, for example, Ed can publish the path to be taken by other participants while maintaining his anonymity. Unlike the Tor hidden services, with the aforementioned anonymized IP communication protocol, Ed does not have to contact Bob in advance to negotiate this path, and Bob does not have to save anything while preparing the path. Instead, Ed publishes his paths, and when someone uses one of them, the message reaches him.

[1143] Similarly, using the method described above, other participants (eg, Alice) can publish an anonymous communication path and receive an encrypted data packet from other participants over the anonymous communication path. Ultimately, Alice can decrypt the received message with an Alice-specific private key and is paid with the public key used by Alice in this anonymous communication path. Accordingly, any number of participants (eg, computing devices) may define any number of anonymous communication paths. Additionally, such anonymous communication paths may be defined to include any number of intermediate participants (eg, computing devices). This can ensure that the IP address of the final recipient of the message remains undiscovered.

[1144] In some cases, the communication protocol can be optimized by adding chain numbers to the protocol. For example, when Alice provides Bob with the initial packet, Bob can respond with a random number that he chooses to uniquely identify the chain. When Bob sends a smaller packet to Carol, Carol replies to Bob with a random number for the chain. Other members do the same. When Alice wishes to send more messages to Ed in the near future, she can encrypt each message with all the public keys in the path (starting with Ed's key) and send each message to Bob along with the chain number he gave her. Bob can, for example, remember that this chain number is associated with Carol, so he will decrypt each message with his own private key and forward each message to Carol, along with the chain number that Carol gave him. Each participant can keep a list of chain numbers along with whoever immediately precedes and follows them in the path for that chain. In some cases, this information is kept for a limited period of time. If no messages have been sent by a given chain number for a period of time (eg, for a specified number of seconds or minutes), then that entry may be deleted. Alice can then recreate a new circuit the next time she wants to contact Ed.

[1145] In some cases, when Ed responds to Alice, his response can be encrypted using the public keys of {Alice, Bob, Carol, Dave} in that order. Ed can then send that response to Dave using the same chain number that Dave gave Ed the first time. Dave decrypts the answer, then sends the answer back to Carol, and this continues until it gets back to Alice. In such a case, Alice can include a disguised public key for herself in the original message, so that no one can read the message from Ed to Alice.

[1146] In some cases, Bob, Carol, and Dave may be compensated or rewarded for providing the above services to Alice and Ed. This can be done with a cryptocurrency, with Alice paying Bob as soon as she receives back a message from Ed. At that point, Alice can pay Bob enough to pay all of {Bob, Carol, Dave}. Bob can then pay Carol enough for {Carol, Dave} and then Carol can pay Dave. Such payments can be made when each new message is sent through the channel. In some cases, a single price can be set globally, for example, based on voting for such a price by participants in a community or a hashgraph. The price can be set for each participant along the way, with one price for establishing the chain, and a separate price for each message sent along the chain. In other cases, the price may be calculated per byte rather than per message.

[1147] In some cases, Bob may periodically pay Carol a lump sum, that is, either pay upfront for messages sent soon after, or pay for messages sent recently. Thus, micropayments can occur periodically (e.g., once a day or once a week), and therefore the record of payments reveals very little about how traffic flows through the network, preventing information about participant IDs from leaking or inferring information based on the time participants make payments. micropayments. Similarly, the messages themselves can be delayed for random amounts of time when there is little traffic to prevent eavesdropping devices from using timing analysis to track messages across the network.

[1148] In some cases, the above communication protocol provides one-way anonymity. For example, Alice can't figure out Ed's IP address unless she colludes with everyone in {Bob, Carol, Dave}. In some cases, Ed may choose or select Bob, Carol, and Dave at random, so it is unlikely that Alice will guess the path element that Ed chose. Conversely, Ed can find out Alice's IP address, for example, by selecting or electing {Bob, Carol, Dave} from among his own interaction objects, and together they can then collude or share information by revealing Alice's IP. However, in some cases, Alice may route her messages through several participants, whom she herself has chosen, before the messages reach Bob. This technique doubles the number of steps Alice goes through when creating the initial package, but it guarantees two-way anonymity. In still other cases, one-way anonymity can be applied in the opposite direction, for example, if Alice knows Bob's public name and wishes to send a message to him while hiding her own identifier, then she can design the initial packet so that it passes through several participants along the way. to Bob, and then the chain ended on Bob. Alice can then find out Bob's ID (or at least Bob's IP address), but Bob doesn't know who Alice is.

[1149] In some cases, if Alice creates and/or defines a new chain, Alice may create and/or define her original message containing a new symmetric key for each level of the encrypted message. Then, each node along the chain path can store that symmetric key along with two chain numbers (eg, chain numbers for nodes that immediately precede and follow that node in the path for that chain). Alice can then encrypt future messages with symmetric keys instead of using public keys. This can be faster in some cases, and also ensure that multiple layers of encryption don't cause future messages to become too large. Encryption with a symmetric key can be done in a manner that does not cause the message size to increase significantly when encrypted. Optionally, when using symmetric keys, Alice MAY include random padding in the innermost message. This removes the need to randomize each level of encryption, and the message does not necessarily increase in size at each level. When Alice sends a message across the chain, the message is decrypted at each node along the path, thus removing one layer of symmetric encryption. When the final recipient makes a response, the response can be encrypted at each level with the proper symmetric key, so that Alice receives the response encrypted with all symmetric keys.

[1150] Thus, the discussed communication protocol provides at least three modes of anonymity: a) one-way sender security, b) one-way receiver security, and c) two-way sender and receiver security. In some implementations, the communication protocol may be used to implement the cryptocurrency anonymizer described above. In some other implementations, the communication protocol may be used to anonymize the hashgraph consensus method protocol and/or other suitable processes performed within the hashgraph.

[1151] The following is a summary of yet another example of how the above cipher can be used to make anonymous communications. The private key is the y element of the random group. The corresponding public key is (a, b) = (g,g^y). The encrypted message is (c, d) = (g^x, m*g^{xy}), where x is randomly chosen by the sender and m is the original message. The encrypted message n = (e, f) is encrypted in a similar way with a distinct random x. One "tuple" is formed, which contains the public key and two encrypted messages m_1 and m_2. The tuple is (a, b, c, d, e, f) = (g, g^y, g^x_1, m_1*g^{x_1 y}, g^x_1, m_2*g^{x_1 y}) , where the sender chooses random x_1 and x_2. To mask an entry, select random r_1, r_2 and r_3 and define the masked entry as (a', b', c', d', e', f') = (a^r_1, b^r_1, c*a^r_2 , d*a^r_2, e*a^r_3, f*a^r_3).

[1152] A node (computing device) Alice in the network can publish a "path" that can be used to route messages to that node without revealing the address or identifier of that node. The path is a list of n entries (R_1, R_2, ..., R_n). Each R_i entry contains (a_i,b_i) which is the public key of a node on the network, where the last (a_n,b_n) is that node's public key. So, for example, a node (Dave) creates and/or defines a path to route messages through the following nodes: Alice, then Bob, then Carol, then Dave. In this example, (a_1,b_1) would be the public key for Alice, and (a_4,b_4) would be the public key for Dave (since n=4 in this example, since there are four nodes in the path). The first m_1 message in each entry is the ID of the next node in the path. So (c_1,d_1) is the ciphertext of a name (or identifier, or alias) for Bob, which can be used by a host to figure out Bob's IP address and public key. Similarly, (c_2,d_2) is Carol's ID, and (c_3,d_3) is Dave's ID. As for the last (c_n,d_n), which is (c_4,d_4) in this example, the message is simply the number 1 (or the identifier element for the group operator of the algebraic group if it is something other than the number 1). The second ciphertext in each (e_i,f_i) tuple is the encrypted 1 (or identifier element) for each entry in the path.

[1153] Once Dave has created and/or defined this path, they mask the path by masking each entry and then publish the path associated with the strictly anonymous name AnonymousDave. No person (or computing device on the network) will be able to know that anonymous Dave is actually Dave. Nor will it be able to find out the anonymous Dave's IP address. Others can use the path to send messages to Dave. The published path is also associated with the ID of the first node in the path. So in this example, the published path is associated with Alice, so it is clear to other nodes that the first node in the path will be Alice's node, and Alice's identity will not be hidden or anonymized.

[1154] Ed then sends a message to anonymous Dave in the following way. Retrieves and/or identifies the path that was posted to anonymous Dave (or one of the paths if more than one was posted). Masks entries in the path. Creates and/or defines a list of random masks (k_1, ... k_n). Changes each f_i to k_i*f_i. For each k_i computes the inverse of k'_i multiplication such that k_i * k'_i is 1 (or is the group ID element if it is not 1). Changes each d_i to d_i*(k'_1 * k'_2 * ... * k'_i). Ed encrypts his message with the public key (a_n,b_n) to determine the ciphertext, then sends both the ciphertext and the modified path to the first node on the path, i.e. Alice.

[1155] Alice then does the following. Decodes (e_1,f_1) to get k_1. Changes every d_i to d_i*k_1. Decodes (c_1,d_1) to find and/or identify the ID of the next node on the path, i.e. Bob. Removes the first tuple from the path, so now entry 2 will be called entry 1, entry 3 will be called 2, and so on. Masks an encrypted message. Sends a masked encrypted message and its modified path to Bob. If the encrypted message is encrypted using the standard hybrid approach (encrypting the message with a random key that is itself encrypted with an asymmetric cipher), then the message is "masked" by re-encrypting the message for the same public key. In this case, the public key will be transmitted along with the message, and the public key will be masked at each step.

[1156] Bob does the same, passing an even shorter modified path to Carol. Which does the same and hands it over to Dave. Dave then decrypts the message with his private key and is able to read the message. If Ed wishes to implement a response, he may use this same approach to create an anonymous path for himself, and may include an anonymous path in his message to Dave.

[1157] In the above example, anonymous communication can be performed more efficiently by using chain numbers in the following manner. For example, Ed sends his original modified path to Alice without including any ciphertext as a message. Alice generates a random "chain number" and returns it to Ed. When she passes the modified path to Bob, he generates a chain number and returns it to Alice. Alice stores those two numbers as a linked pair for a short period of time (eg minutes or hours). During that period Ed can send messages to Dave by encrypting them and sending them to Alice along with the chain number (and without sending the modified path). The message then follows the path, being masked again at each step until it reaches Dave. The first message should include Ed's public key. Dave can then reply with a message encrypted with that key, along with the chain number he received from Carol. The message is then sent back down the chain, masked at each step until Ed accepts the message.

[1158] In some jurisdictions, the government may wish to provide through legislation the ability to monitor currency flows to prevent crimes such as money laundering or tax evasion, while allowing citizens to remain anonymous from surveillance (e.g., by their neighbors, criminals, foreign governments). states, etc.). In some cases, the anonymity method and system described above may support such legislation. In such cases, the government may create or approve a specific certificate authority (CA) or multiple CAs for the purpose of creating and/or defining encrypted certificates that prove that the wallet is associated with a specific person. The encryption can be such that only the government can decrypt it (possible only by court order). If Alice creates and/or defines a wallet, she can optionally have such a certificate attached to the wallet, meaning that her neighbors cannot see that the wallet belongs to Alice, but the government can decrypt the certificate and identify Alice as the owner of the wallet. The government can insist that employers in their own country can only deposit money into wallets that have such a certificate, and that stores in that country accept payments from wallets with such a certificate. Alice can then execute the above protocol multiple times to create and/or define a chain of wallets and obtain the proper certificate for the first and last wallets in the chain.

[1159] Although it is described above that each wallet data structure has one public-private key pair, in other cases, the wallet data structure may contain two public-private key pairs: one for signing and one for encryption. In such a case, the methods described above can be modified to use a signing key for signing and an encryption key for encryption.

[1160] Although it is described above that a hashgraph is used and transactions are stored and exchanged in events, in other cases, any other suitable distributed database and / or distributed registry technology can be used to implement the above methods in order to provide secure and anonymous transactions. For example, in other cases, technologies such as blockchain, PAXOS, RAFT, Bitcoin, Ethereum, and/or the like can be used to implement such methods. In some cases, a secure timestamp can be added to these technologies (for example, built on them ) to implement the methods described above in order to provide secure and anonymous transactions. In other cases, as described above, no timestamp is used.

[1161] Although the implementation described above is between two different distributed database instances, in other cases, the anonymization method may be implemented by more than two distributed database instances. For example, in other cases, the transaction "TRANSFER_DOUBLE" may support additional numbers of transactions. For example, a TRANSFER_TRIPLE transaction could be defined to support transferring data between three different wallet data structures.

[1162] While it is described above that they implement a cryptocurrency, in other cases, transactions in any other type of distributed database can be anonymized. For example, a record of an exchange of goods, identification of an individual, permission to use a particular resource, and/or the like can be anonymized. In such cases, this can increase the security of a transaction in a distributed database.

[1163] FIG. 7 illustrates a signal flow diagram of two computing devices synchronizing events according to an 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, implementation, 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. 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 be able to select computing device 800 again. As explained above, distributed database instances 703 and 803 may be implemented in computing device 700 memory and computing device 800 memory, respectively.

[1164] In some implementations, computing device 700 may have multiple threads running concurrently, with each thread synchronizing with a different member. Accordingly, computing device 700 may synchronize with other computing devices (not shown in FIG. 7) in addition to computing device 800. In some cases, computing device 700 may establish connections for each thread initially or for the first time and then maintain each the connection is live or open by periodically sending a heartbeat message (for example, sending a heartbeat twice per second). Thus, in some cases, computing device 700 can prevent synchronization delays or delays otherwise caused by Transport Layer Security (TLS) protocols (e.g., write protocol and handshake protocol) each time the computing device establishes a connection with another participant or computing device. for synchronization.

[1165] In some implementations, computing device 700 may manage the establishment of streaming connections to other participants or computing devices as a connection pool and/or connections to a group of computing devices (eg, Transmission Control Protocol/Internet Protocol connections). In such a case, computing device 700 is adapted not to exceed the limit (upper limit threshold) of open connections with other participants or computing devices. In some cases, the connection limit may be adjusted based on the physical resources of the computing device 700, such as the RAM used for each connection or the performance of the CPU. For example, computing device 700 may be adapted to simultaneously maintain open connections with a constant number V of participants or computing devices such that its memory and processing resources are not utilized at their maximum performance and/or result in sub-optimal efficiency. In other words, computing device 700 must maintain open connections at a time not with every participant in the hashgraph, but instead with V participants or computing devices. Accordingly, in some cases, when choosing with whom to synchronize, computing device 700 selects from random participants or computing devices (or group of participants or computing devices) with which it has open connections established in its connection pool.

[1166] In some implementations, computing device 700 may be adapted to limit or limit the size of a connection pool according to a low limit threshold and a high limit threshold. In such a case, computing device 700 may randomly select a member or computing device to synchronize from among computing devices that have an open connection to computing device 700. When the connection pool is greater than an upper limit threshold and/or when the number of computing devices in a member group and /or the computing device reaches the upper limit threshold, after synchronization the computing device can close and/or terminate such a connection and remove the connection from the connection pool and/or group of participants or computing devices. Similarly, when the connection pool of computing device 700 is below the low limit threshold and/or when the number of computing devices in a group of members and/or computing devices reaches the low limit threshold, the computing device executes one or more threads to establish new connections with other members. or computing devices and adds these new connections to the connection pool and/or group of participants or computing devices. If the connection pool is less than the high limit threshold but greater than the low limit threshold, computing device 700 may maintain the current connection pool and/or group of members or computing devices. In some cases, a certain subset of calling threads may be forced to establish new connections only with participants or computing devices that have recently successfully established connections. The remaining calling threads may randomly call other participants from the set of all participants, even those with which the computing device 700 has not recently established a connection.

[1167] In some implementations, a single hashgraph may be used to reach a consensus order for a set of transactions. In the case of very large systems, sharding or horizontal partitioning of the hashgraph can be implemented. For example, in a very large multiplayer online game (MMO), each geographic region of the virtual world may become one segment. In such a case, each shard can have its own hashgraph that governs the ordering of transactions that occur in that shard. Each member computing device may then store multiple shards and store and participate in a hashgraph associated with each of the stored shards.

[1168] In some cases, synchronization between shards can be achieved by having participants in a shard reach a consensus on the order of transactions associated with that shard. Those transactions can trigger the creation of a message that updates the state of the shard, which can be signed by the members of the first shard. The signed message may be sent to the second segment to update the members of the second segment to the state of the first segment. For example, activities in the first segment (for example, for one region) can provoke the creation of a message for the second segment, which controls the cryptocurrency, instructing the second segment to transfer cryptocurrency between two specific wallets. In such a case, the message may be approved with signatures from more than a threshold number (eg, 2/3) of the first shard members (eg, in an address book with a list of first shard members). In addition, the message may contain the address book itself and may be approved with a signature from more than a threshold number (eg, 2/3) of participants in an earlier version of the address book. An earlier version of the address book can be validated using the signatures from the earlier version and so on back to the original address book for that hashgraph. Accordingly, an outgoing message from one segment to another may represent a consensus among the segment members that create the outgoing message.

[1169] FIG. 3-6 illustrate examples of a hashgraph according to an 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.

[1170] 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:

[1171] - Alice sends events stored in the distributed database 703 to Bob.

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

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

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

[1175] is Bob's digital signature of the above.

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

[1177] - Alice creates and/or defines a new event.

[1178] - Alice sends that event to Bob.

[1179] - Alice calculates the overall order for events as a hashgraph function.

[1180] - Bob calculates the overall order for events as a hashgraph function.

[1181] At any given time, a participant may store the currently 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 may 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 (the dot above) contains the hash of an earlier event (the dot below). An event can be said to be linked to another event if that event can refer to another event by means of that event's hash (either directly or through intermediate events).

[1182] For example, in FIG. 3 illustrates an example hashgraph 600. Event 602 is generated and/or determined 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 hashgraph using pointers to previous events. In some cases, event 602 can be said to be linked to other events in hashgraph 600 because event 602 can refer to each of the events in hashgraph 600 through earlier ancestor events. For example, event 602 is linked to event 608 via event 604. As another example, event 602 is linked to event 616 via events 606 and event 612.

[1183] Exemplary system 2: A system based on exemplary system 1, wherein the event also contains transaction payload data or other information to record. Such payload data 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 contain 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.

[1184] Exemplary System 3: A system based on Exemplary System 1, wherein the event also contains a 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.

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

[1186] For example, in FIG. 4 illustrates an exemplary hashgraph 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 hashgraph illustrating one particular event (solid circle) and the first point in time at which 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 may identify which events to send to Carol based on what Dave's hashgraph indicates 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 hashgraph based on 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 sending event 622 to Dave (not shown in FIG. 4) and identifying using event 622 (and references therein) by Dave to identify events that Carol already accepted.

[1187] 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 accepts and/or stores 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 sender's hashgraph (eg, a database state variable defined by the sender) and which events that hashgraph indicates 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 that event and its ancestors. Thus, Carol can send event 618 and event 616 to Bob first (i.e., the oldest events that Bob has yet to receive that Carol has received). Carol can then send event 612 and then event 606 to Bob. This allows Bob to easily link events together and rebuild Bob's hashgraph. Using Carol's hashgraph to identify which events Bob still needs to receive can improve synchronization efficiency and can reduce network traffic because Bob does not request events from Carol.

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

[1189] Exemplary System 6: A system based on Exemplary System 5 with the additional constraint that when a participant is able to select 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 that 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 that participant can send multiple events from each participant, instead of just send events defined and/or created by the attacker, and none (of several) events created and/or defined by other participants.

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

[1191] Alternatively, or additionally, in some implementations, a limit on the number of bytes per sync process and/or the number of events that are allowed to sync per sync process are implemented in a distributed database. For example, Alice may send events to Bob that Bob does not yet know about, then the database instance associated with Alice may stop and/or stop sending data packets and/or events when the next event exceeds a synchronization threshold based on either the allowed number of bytes (i.e. the amount of data to be synchronized) or the allowed number of events to be synchronized, and/or reaches it. Event dispatch in such cases can be done by dispatching the parent of the event before dispatching the event, if both events are synchronized.

[1192] In some cases, when Alice is synchronizing with Bob and she needs to send two events to him, for example an X event and a Y event, and Bob already has all the parents of both of those events, then Alice can choose which one to send first. In some implementations, Alice may calculate the total Bx of all bytes in X plus the bytes in all events created by the event creator of X that she has already sent during this synchronization. Likewise, it can calculate the total By for the bytes in Y and the events generated by the Y event creator that have been dispatched so far. She can then decide to send X before Y if Bx<By, and send Y before X if By<Bx, and send them in any order if Bx=By.

[1193] In some cases, synchronization between two participants may be limited by the maximum number of received events per synchronization (for example, to prevent denial of service attacks). If such a limit is reached before all events related to that synchronization have been received, then the synchronization ends earlier. In some other cases, each sync event may be limited to a maximum number of bytes received (instead of or in addition to being limited to the number of events received). Accordingly, limits, such as the maximum number of events received and the maximum number of bytes received, can be used to limit or regulate the number of events and/or bytes received and/or received by a recipient participant (for example, Bob) from another participant (for example, Alice). ) during synchronization. The above limits can prevent attacks in which a malicious participant creates a large event or floods the network with a huge number of small events. These limits also ensure gradual degradation of performance in cases where, for example, one participant has a low bandwidth connection to handle an average amount of data traffic, but not a spike in data traffic.

[1194] In some implementations, participants or computing devices do not initiate synchronization with another participant or computing device if all known events for which consensus has not yet been identified are null events containing no transactions. This ensures that participants do not waste bandwidth if there are long periods without new transactions.

[1195] In some cases, the lack of consensus may cause the memory of the participant or computing device to overflow. For example, a set of events for which consensus has not yet been identified may grow or increase beyond a given threshold when, for example, at least 1/3 of the population is offline, since consensus cannot be obtained when too few participants are offline. online mode. Thus, the participant's or computing device's memory may fill up with the cumulative number of events for which consensus cannot be reached. To prevent memory overflow due to accumulated events for which consensus cannot be reached, each of the participant and/or computing device can be adapted such that once a threshold of events for which consensus has not yet been reached is reached, that participant or that computing device the device may refuse to define and/or generate any new events until that participant or that computing device reaches a consensus on some of the events that the participant or computing device is aware of. In other words, in some cases, the lack of consensus can cause an overflow if consensus cannot be reached (for example, when too few participants are online to reach consensus). Thus, to prevent overflowing of events that cannot be entered into the consensus order (for example, because too few participants are online), a participant does not define any additional events until it can receive events from some of the participants in the offline to reach consensus on some of the older events.

[1196] Exemplary system 8: A system based on exemplary system 1, in which the following steps are added at the beginning of the synchronization process:

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

[1198] - Alice identifies the participants that 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.

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

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

[1201] 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 that participant is a "scammer". If Alice determines that Dave is a fraud by receiving two different events created and/or defined by him using the same hash of his own, then she keeps the indicator indicating that he is a fraud and avoids synchronizing with him in the future. If she figures out that he is a scammer, but still syncs with him again and creates and/or defines a new event that records that fact, then Alice becomes a scammer 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 that sync completes, 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.

[1202] Exemplary System 10: A system based on Exemplary System 9 with the addition that Alice begins 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 identified, in addition to the scammers identified by Alice. They then continue as normal, but without counting cheaters while syncing with each other.

[1203] Exemplary system 11: A system based on exemplary system 1 with a process that constantly 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. Thus, for example, each computing device may maintain two versions of state (one updated as new events and transactions are received, and one updated only after consensus is reached). At a certain point in time (for example, after a period of time has elapsed, after a given number of events have been determined and/or accepted, etc.), the state version that is updated as new events and transactions are received may be deleted, and a new copy of the state, which is updated only after consensus is reached, can be executed as a new version of the state, which is updated as new events and transactions are received. This can keep both states in sync.

[1204] In some embodiments, the current state is a 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.

[1205] Exemplary system 12: A system based on exemplary system 11, accelerated by using a "fast clone" arrayList to maintain state (eg, bank 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, 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, that 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.

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

[1207] 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.). For example, a fast clone database can be used to provide two copies of the state, as discussed in relation to exemplary system 11. 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 attempts to execute a Structured Query Language (SQL) query against a database, that 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 clones of the database are created with IDs of 2 and 3 (for example, used to maintain two copies of the state). 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 rows that have values of 2 or 1 in that 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 that tree will be stored in an additional table that is inaccessible to clones, but which is fully used internally.

[1208] 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 fast clone relational database 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.

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

[1210] 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 in time. moment, 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.

[1211] 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, and the participants are 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 invites 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 a single member invites a huge number of "virtual" users to join, each of which is simply an alias under the control of the inviting member. 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.

[1212] Exemplary system 19: A system based on exemplary system 1 in which, instead of one 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 participants in that block, but not among participants outside 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.

[1213] Exemplary system 20: A system based on exemplary system 11 with the possibility of having an event that updates 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 as appropriate. 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, the code improvement notification may appear in an event so that the community may 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 remain running even during improvements without the need for a reboot or process restart.

[1214] In some implementations, the hashgraph consensus method may be implemented by a platform (i.e., a program implemented in software, executing on the processor of a computing device and/or system). In general, a hashgraph platform collects, distributes, sequences transactions, and performs other appropriate tasks related to consensus building processes. In addition to the platform, in some cases, a separate application maintains and modifies the shared hashgraph state by executing transactions in the consensus order defined by the platform. When a new version of such an application is released, a new version transaction can be created by providing, for example, the new version number, a hash of the new application code, and proof that the enhancement is genuine (for example, a digital signature of the application code signed by the company that created that application ). In some implementations, the new version transaction can be arranged such that the new version is not executed until a consensus order is identified for the new version transaction. Thus, transactions identified as earlier in the consensus order are processed by the old application version, and transactions identified as later in the consensus order are processed by the new application version. Accordingly, new version transactions ensure that participants upgrade to the new version of the application on the same instance and keep their state consistent.

[1215] In some implementations, platform enhancements may be performed in a manner similar to application enhancements. For example, a transaction for a new version of the platform may be executed at a time when a consensus is reached on such a transaction for the new version. Alternatively, when the platform finds out that a new version of the platform is available, it may display a prompt to each participant in the hashgraph asking them to indicate whether that participant wishes to implement an improvement. In such a case, the platform can be improved based on the response of the participant(s).

[1216] In some implementations, improvements to the application and/or platform may be subject to user voting. For example, the computing devices of the participants may display a pop-up window to the associated user prompting them to authorize the improvement by selecting or sending a yes or no vote recorded as a transaction (eg, in an event). Accordingly, automatic platform and/or application updates can be performed upon authorization from a population threshold (eg, more than 2/3 of the population).

[1217] Exemplary system 21: A system based on exemplary system 1, where the hashgraph participants or computing devices are adapted to remove unnecessary events from distributed database instances by determining the signed state of the distributed database. In some implementations, participants or computing devices may execute additional processes to prevent memory overflow and/or to conserve memory resources. For example, participants or computing devices may periodically delete old events based on a set of rules or criteria. The rule may, for example, indicate that transactions in an event should be ignored or deleted if a value equal to the difference between the round that is accepted and the round number (or round that is created) of the event exceeds a given threshold. In some cases, events contain hashes of their parents and a round created for each parent. Therefore, a given event may still be received during synchronization even if one or more parents are missing due to being ignored or deleted because they were created too many rounds ago. Accordingly, signed states may contain a hash of events that were defined and/or created in the rounds prior to the signed state, but not very long before the signed state, in which case they would be ignored or deleted. Removing or removing unnecessary events reduces the computational overhead caused by synchronizing redundant or irrelevant events within a set of computing devices that implement a distributed database (e.g., hashgraph participants) and reduces underutilization of local memory blocks of such a set of computing devices. Additional details regarding deleting and/or deleting events can be found in U.S. Provisional Application No. 62/436,066, filed December 19, 2016, entitled "Method and Apparatus for a Distributed Database that Enables Deletion of Events", which is incorporated herein. document by reference in its entirety.

[1218] It is contemplated that the systems described above create and/or provide an efficient convergence mechanism for distributed consensus with eventual consensus. Several theorems can be proved about this, as shown below.

[1219] Exemplary 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.

[1220] 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 learns about x before y), or it will be the case that synchronization provides that 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.

[1221] Exemplary Theorem 2: For any given hashgraph, if x precedes y in partial order, then x will precede y in the general order computed for that hashgraph.

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

[1223] for all i, rank(i,x) < rank(i,y),

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

[1225] For a 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:

[1226] rank(i1,x) < rank(i2,y).

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

[1228] Assume that 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. Hence 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. Hence 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.

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

[1230] after 1 transmission period: all participants accepted the events,

[1231] After 2 transmission periods: all participants agree on the order of those events

[1232] after 3 transmission periods: all participants know agreement has been reached,

[1233] After 4 transmission periods: All participants receive digital signatures from all other participants endorsing this consensus order.

[1234] Proof: Let's 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.

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

[1236] By time T2, a given member Alice will have received a record of each of the other members 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 those 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. Those S1 events may still vary where they fall in the sequence of S0 events. But the relative order of events in S0 will not change.

[1237] By time T3, Alice will know the general order on the union of S0 and S1, and the relative order of events in that 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. Therefore, 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.

[1238] By time T4, Alice will accept similar signatures from other participants. At that point, it can simply store that list of signatures along with the state they are evidence of, and it can delete the events it has stored prior to the first S1 event. Q.E.D.

[1239] The systems described herein describe a distributed database that reaches 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 current 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.

[1240] Another example is a distributed game that acts like a massively multiplayer online game (MMO) played on a server, but achieves that without the use of a central server. Consensus can be reached without any central server exercising control.

[1241] 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 strict anti-spam policies 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 networks.

[1242] Other applications may include more complex cryptographic functions, 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.

[1243] Another example is an open 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. These funds can then be automatically distributed to the participants who store that data, and to the participants who are constantly in sync to work towards consensus. Participants can automatically receive a small amount of cryptocurrency every time they sync.

[1244] Another example is a secure messaging system that is not amenable to traffic analysis. In this example, the distributed database may contain and/or store encrypted messages between participants. Each participant has access to every message, but the messages are encrypted in such a way that only the intended recipients can decrypt them. For example, Alice can send a message to Bob without the knowledge of the other participants in the hashgraph by encrypting the message with Bob's public key and then serving the encrypted message as a transaction. Such a transaction may be propagated or dispersed, as discussed above, to the rest of the hashgraph participants. The community will know when a member sends a message, but will not know who the message was sent to. Each participant can attempt to decrypt each message, and recognize those sent to him, based on the fact that the decrypted message is genuine and has the correct checksum.

[1245] Alternatively, the computational requirements in such a system can be reduced, for example, as follows. Each pair of participants may first negotiate two shared secret keys (one for each participant in the pair) that they use to distribute two different cryptographically secure random number generators (CSPRNGs) (one for each participant in the pair). If Alice has created such a key with Bob, then she uses her CSPRNG to generate a new pseudo-random number each time she adds a message meant for Bob to the database, and she appends that number to the encrypted message. Bob can then quickly check the number attached to each message in the database to see if any of those numbers indicate messages meant for him. Since Bob knows the shared key, he therefore knows the sequence of numbers that Alice will generate, and hence he knows what numbers to look for when browsing messages for messages addressed to him by Alice. When he finds messages with such numbers attached, he knows that they are messages sent to him by Alice, and he can decrypt them. Only Bob can decrypt such messages because they were encrypted with his public key, and only Bob has the corresponding private key.

[1246] In some cases, extraneous messages, such as those from Carol to Dave, may have different numbers attached, and Bob can delete them without attempting to decrypt the messages. Moreover, Alice can send Bob the Kth message with the unencrypted Kth random number from her CSPRNG attached. Alice and Bob can keep track of how many messages Alice has sent to Bob (for example, by storing the messages in a hash table). Thus, at any given time, Bob can determine the next number to expect from each of the other participants in the hashgraph. On receiving each message, Bob can determine via a hash table whether the attached number matches any expected number. If not, then Bob should not waste time and resources trying to decipher the received message.

[1247] In some cases, Alice and Bob may periodically renegotiate their shared keys and erase their old keys. This provides advanced security in such a way that in the future it will be difficult for a third party to identify the messages exchanged between Alice and Bob, even if their later keys are eventually broken. Thus, efficient transmission and reception of private messages can be provided in a hashgraph or distributed database.

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

[1249] Although it is described above that an event contains a hash of two previous events (one own hash and one foreign hash), in other embodiments, a participant can synchronize with two other participants to create and / or determine an event containing the hashes of the three previous events ( one own hash and two others' 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 contain different numbers of hashes of previous events. For example, the first event may contain two event hashes, and the second event may contain three event hashes.

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

[1251] In other embodiments, events may contain complete cryptographic hashes, but only portions of those 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.

[1252] While 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.

[1253] Although various embodiments have been described above, it should be understood that they have been presented solely as an example 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.

[1254] 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 adapted for storing and executing program code, such as application specific integrated circuits (ASICs), programmable logic integrated circuits (PLDs), read-only memories (ROMs), and random access memories (RAMs). Other embodiments described herein relate to a computer program product, which may include, for example, the instructions and/or computer code discussed herein.

[1255] 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 (eg C, Fortran, etc.), functional programming languages (Haskell, Erlang, etc.), logical programming languages (eg, Prolog), object-based oriented programming languages (eg 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.

[1256] Although 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 can 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 (63)

1. A device for implementing a distributed database, containing: a memory associated with a distributed database instance on a first computing device adapted to be included in a plurality of computing devices that implement the distributed database via a network operatively coupled to the plurality of computing devices; and a processor operatively connected to memory and adapted to: determining a first group of computing devices from a plurality of computing devices and a second group of computing devices from a plurality of computing devices based on a deterministic pseudo-random function; receiving from a second computing device from a plurality of computing devices an event associated with a first set of events defined by a set of computing devices from a plurality of computing devices, wherein the set of computing devices comprises at least one computing device from the first group of computing devices and at least one computing device from the second group of computing devices; identification of the order associated with the second set of events, as a result of the consensus protocol (1) using the value for the event parameter from the first set of events, which was determined by the computing device from the first group of computing devices, and (2) not using the value for the event parameter from a first set of events that has been determined by a computing device from a second group of computing devices; identifying an order associated with the plurality of transactions specified in the distributed database instance based at least in part on the order associated with the second set of events; and storing in a distributed database instance an order associated with a set of transactions. 2. The apparatus of claim 1, wherein the processor is adapted to identify the order associated with the second set of events by executing a Byzantine error-resistant consensus protocol based on the value of the event parameter determined by the first group of computing devices, rather than the value of the event parameter, defined by the second group of computing devices. 3. The device according to claim 1, characterized in that the first group of computing devices is the absolute complement of the second group of computing devices in relation to the plurality of computing devices that implement a distributed database. 4. The device according to claim 1, characterized in that the processor is additionally adapted for: determining a third group of computing devices from a plurality of computing devices that implement a distributed database, the third group of computing devices being associated with an upper limit threshold and a lower limit threshold; establishing a communication session to synchronize events with each computing device from the third group of computing devices; and after synchronization with a computing device from the third group of computing devices: terminating a communication session with a computing device from the third group of computing devices when the number of computing devices in the third group of computing devices reaches a threshold value of the upper limit; maintaining a communication session with a computing device from the third computing device group when the number of computing devices in the third computing device group is below the upper limit threshold and above the lower limit threshold; and establishing a communication session to synchronize events with a third computing device from a plurality of computing devices, when the number of computing devices in the third group of computing devices is below the threshold value of the lower limit, and the third computing device is not included in the third group of computing devices. 5. The device according to claim 1, characterized in that the processor is additionally adapted for: executing an event synchronization process with the second computing device to receive the event; and terminating the event synchronization process when a synchronization threshold is reached, wherein the synchronization threshold is related to the amount of data to be synchronized. 6. The device according to claim 1, characterized in that the processor is additionally adapted for: executing an event synchronization process with the second computing device to receive the event; and terminating the event synchronization process when a synchronization threshold is reached, wherein the synchronization threshold is related to the number of synchronized events. 7. The device according to claim 1, characterized in that the processor is additionally adapted for: receiving an event from the second computing device based on event synchronization with the second computing device from the plurality of computing devices, the second computing device being randomly selected from the plurality of computing devices. 8. A non-volatile, processor-readable medium storing code representing instructions to be executed by the processor, the code containing code for instructing the processor to: to assign, on a computing device from a plurality of computing devices that implements a distributed database, a first group of computing devices from a plurality of computing devices as lazy computing devices, wherein the second group of computing devices from a plurality of computing devices is non-lazy computing devices, wherein the second group of computing devices is the absolute complement of the first group of computing devices in relation to the plurality of computing devices; receive a first set of events from a set of computing devices of the plurality of computing devices, each event of the first set of events being determined by a computing device of the plurality of computing devices; identify the order associated with the second set of events as a result of the consensus protocol (1) using the parameter of the first event from the first set of events based on the fact that the first event was determined by a computing device from the second group of computing devices, and (2) not using a second event parameter from the first set of events based on the fact that the second event was determined by the computing device from the first group of computing devices; and keep the order associated with the second set of events. 9. Non-volatile, processor-readable media according to claim 8, characterized in that it additionally contains code for prescribing to the processor: compute the state of the distributed database based on the order associated with the second set of events. 10. The nonvolatile, processor-readable medium of claim 8, wherein the code for causing the processor to make the assignment comprises code for causing the processor to select a first group of computing devices from a plurality of computing devices using a deterministic pseudo-random function. 11. A non-volatile, processor-readable medium according to claim 8, characterized in that each event from the first set of events is associated with a common round. 12. The nonvolatile, processor-readable medium of claim 8, wherein the code for causing the processor to make an assignment comprises code for causing the processor to make an assignment for the first round of the consensus protocol, the code further comprising code for causing the processor to: to assign a third group of computing devices from the plurality of computing devices as lazy computing devices for the second round of the consensus protocol, wherein the first group of computing devices is different from the third group of computing devices. 13. The non-volatile, processor-readable medium of claim 8, wherein the code for causing the processor to make the assignment comprises code for causing the processor to select a first group of computing devices from a plurality of computing devices based on the size of the share associated with each computing device of the plurality of computing devices. . 14. A non-volatile, processor-readable medium according to claim 8, characterized in that the parameter of the first event from the first set of events is determined using the first method and the parameter of the second event from the first set of events is determined using a second method different from the first method. 15. The non-volatile, processor-readable medium of claim 8, wherein the computing device of the plurality of computing devices is the first computing device of the plurality of computing devices, the code further comprising code for instructing the processor: execute an event synchronization process with a second computing device of the plurality of computing devices to receive at least one event from the first set of events; and stop the event synchronization process when the synchronization threshold is reached, wherein the synchronization threshold is related to the number of synchronized events. 16. A non-volatile, processor-readable medium according to claim 8, characterized in that the first event from the second set of events was determined by a computing device from the first group of computing devices and the second event from the second set of events was determined by a computing device from the second group of computing devices. 17. A method for implementing a distributed database, including: identifying on a computing device from a plurality of computing devices that implements a distributed database, a first group of computing devices from a plurality of computing devices and a second group of computing devices from a plurality of computing devices, wherein the second group of computing devices is the absolute complement of the first group of computing devices with respect to the plurality of computing devices ; receiving from a set of computing devices of a plurality of computing devices a first set of events, each event from the first set of events being determined by a computing device of the plurality of computing devices; identifying, using the first process, a round number for each event from the first set of events that has been determined by the computing device from the first group of computing devices; identifying, using a second process different from the first process, a round number for each event from the first set of events that has been determined by a computing device from the second group of computing devices; determining a subset of events from the first set of events based on a round number for each event from the first set of events, each event from the subset of events being determined by a computing device from the second group of computing devices; calculating an order associated with the second set of events as a result of the consensus protocol using a subset of events; and preserving the order associated with the second set of events. 18. The method according to p. 17, characterized in that it additionally includes: calculating the state of the distributed database based on the order associated with the second set of events. 19. The method of claim 17, wherein the first process includes identifying the round number for each event in the first set of events as equal to the round number of at least one parent event for that event in the first set of events. 20. The method of claim 17, wherein the round number for each event in the subset of events is the initial instance in which the computing device that determines that event determined the round number event. 21. The method of claim 17, wherein identifying the first group of computing devices includes identifying the first group of computing devices from the plurality of computing devices using a deterministic pseudo-random function. 22. The method of claim 17, wherein identifying the first group of computing devices includes identifying the first group of computing devices for the first round of the consensus protocol, the method further comprising: identifying a third group of computing devices from the plurality of computing devices for the second round of the consensus protocol, wherein the first group of computing devices is different from the third group of computing devices. 23. The method according to p. 17, characterized in that it additionally includes: executing an event synchronization process with a computing device from the set of computing devices to receive at least one event from the first set of events; and terminating the event synchronization process when a synchronization threshold is reached, wherein the synchronization threshold is related to the amount of data to be synchronized. 24. The method according to p. 17, characterized in that it additionally includes: executing an event synchronization process with a computing device from the set of computing devices to receive at least one event from the first set of events; and terminating the event synchronization process when a synchronization threshold is reached, wherein the synchronization threshold is related to the number of synchronized events.

Images