RU2768202C2 - Systems and methods for providing immutable records - Google Patents

Abstract

FIELD: computer engineering.

SUBSTANCE: technical result is achieved by creating a new block of the main row of blocks for storing new data records, wherein the new block is linked to the most recent block by including a cryptographic hash of the most recent block, wherein the new block becomes the new most recent block of the main row of blocks; creating a new cryptographic hash of the new block using the new random code; storing a new cryptographic hash and a new random code in a new block; and transmitting the new cryptographic hash and the new random code to the first neighboring computer system.

EFFECT: high accuracy, accessibility, safety and reliability of recording immutable records.

26 cl, 10 dwg

Description

RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 62/556,212 entitled "Systems and methods of distributed dynamically changing state machines with provable ordering of events", filed September 8, 2017, and U.S. Provisional Application No. 62/693,870 entitled "DETECTION OF ANOMALIES IN A COMPUTER SYSTEM" filed July 3, 2018, each of which is hereby incorporated by reference in its entirety.

FIELD OF TECHNOLOGY

[0002] The present disclosure relates generally to primary electronic consensus ledgers of records such as distributed ledgers enabled by blockchain, and in particular to systems and methods for providing immutable records.

BRIEF DESCRIPTION OF GRAPHICS

[0003] The present embodiments will become more apparent from the description below and the appended claims in conjunction with the accompanying drawings. It should be understood that the accompanying drawings depict exemplary embodiments only, and thus should not be construed as limiting the scope of the description, and the embodiments will be specifically and in detail described and explained with reference to the accompanying drawings.

[0004] FIG. 1 is a block diagram of a blockchain in a computing system according to an embodiment of the present disclosure.

[0005] FIG. 2 is a diagram of a cross-merklized blockchain network according to an embodiment of the present disclosure, comprising three participating blockchains, namely a main blockchain, a first participating neighbor blockchain, and a second participating neighbor blockchain.

[0006] FIG. 3A is a partial block diagram illustrating the cross-merclization of blocks from participating neighboring blockchains within the main blockchain shown in FIG. 1-2.

[0007] FIG. 3B is a partial block diagram illustrating block creation.

[0008] FIG. 4 is a graph illustrating the geometrically progressive degree of immutability that can be achieved in a blockchain network according to an embodiment of the present disclosure, such as the blockchain network shown in FIG. 1-3B.

[0009] FIG. 5 is a partial flowchart of operations performed on a computing system showing the underlying blockchain and event log, in accordance with an embodiment of the present disclosure.

[0010] FIG. 6 is a detailed partial block diagram of the operations of the computing system described in FIG. 5 in accordance with an embodiment of the present disclosure.

[0011] FIG. 7 is a block diagram of a blockchain network vector clock according to an embodiment of the present disclosure.

[0012] FIG. 8 is a detailed view of a portion of the vector clock shown in FIG. 7.

[0013] FIG. 9 is a diagram of a computing system providing immutable records, in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION

[0014] Transaction record logging is common in business and is of key importance, and it is necessary to ensure its accuracy, availability, security and reliability. With the latest technological advances, these requirements can be met. With the help of computer systems (hardware and software) it is possible, to a certain extent, to obtain accurate, accessible, secure and reliable recording of transaction records. With a number of aspects of computer-based transaction logging, there are both new advantages and disadvantages over older traditional written logging methods.

[0015] The present description relates to systems and methods for providing immutable records. Embodiments of the present disclosure may include distributed, dynamically changing state machines. The present description may include systems and methods for providing a provable order of events within (and between) such machines that are interconnected/capable of communicating with each other. A dynamically changing state machine (eg, a computer system) can, for example, be used to log transaction records. Recording a transaction itself requires validity and provable accuracy, including the order in which transactional and other events occurred and were recorded in a computing system. Failure of hardware or software, as well as the actions of intruders, can adversely affect the reliability and provability of recording records in a computer system. The present invention provides systems and methods for ensuring the reliability and provability of record registration for a plurality of computing systems exchanging specific transactional and timing information with each other.

[0016] The term "anomaly" refers to a change in state on a computer or computing system that is different from the expectations of the owner/operator of the computer, such as, without limitation, an actual or suspected mismatch in timing or a deviation in the registration of the order of events, as well as an actual violation of integrity data (violation of the integrity of the data does not necessarily involve the distortion of the data itself, but because of it there are doubts about the reliability and provability of the data).

[0017] The term "computer" refers to electronic devices capable of executing machine-readable instructions; which are suitable for storing and/or processing data; and which comprise at least a processor, a storage device, an input means, and an output means. A computer may be a complete computing system or a component of a computing system. The computer may be configured to perform one or more computer functions, namely receiving data, processing data, storing data, transmitting data, and outputting data.

[0018] The term "computing system" refers to a computer or a group of computers and similar devices that communicate with each other to perform one or more computer functions.

[0019] The term "network" refers to a system or method and associated equipment for interconnecting computing systems, regardless of topology, protocol, operating system, or geophysical location. In particular, the network in the context of this document includes a multiplex network that provides multi-directional synchronous and asynchronous communication between nodes, where one node represents one computing system or a specific group of computing systems, and where one node can be simultaneously communicating with many others. nodes, and moreover, a plurality of nodes can simultaneously communicate with a plurality of nodes.

[0020] The term "blockchain" refers to a system or method in which or in accordance with which data is contained in a logical block, different blocks of data are logically organized into a relative time-ordered sequence, and the data element of each block contains a marker that identifies and logically links block with immediately preceding block.

[0021] The term "blockchain network" refers to a group of at least two blockchains that exchange some specific data with each other, whereby each blockchain in the blockchain network provides some degree of proof of validity and proof of work for every other blockchain within blockchain networks. The specific data they exchange may contain blockchain blocks. The blockchain network can be implemented using cryptography using one-way functions, including cross-merklization, as described in this document.

[0022] The term "main blockchain" generally refers to a blockchain that functions as a key element; however, in the context of the present description, the core blockchain is the generic blockchain discussed herein as if said generic blockchain were functioning as a key element of the reader. In addition, for the purposes of this description, a typical core blockchain participates in a blockchain network.

[0023] The term "participating neighbor blockchain" refers to a blockchain that participates in a blockchain network and is not the main blockchain, but participates in the same blockchain network as the main blockchain. Each of the blockchains, whether it be the main blockchain or a participating neighbor blockchain, is a participating blockchain.

[0024] The term "block" refers to the elemental unit of the blockchain, and also refers to a group of data logically combined with each other, and may include various data of fixed types and sizes, as well as data of non-fixed types and sizes. In other words, a block may contain, for example, without limitation, (1) a version identifier, (2) a block identifier, (3) a random code, (4) a digest, (5) a parent digest, (6) a timestamp (TS), and (7) transaction data. Each of the elements (1)-(6) may refer to a specific data type and have a specific size, and the element (7) may contain a collection of data of different types and/or with different lengths. Each block may contain a marker (for example, a parent hash) that identifies the immediately preceding block in the blockchain of which the block is a member.

[0025] The term "set" refers to a partially ordered set or pc. set, as discussed in the scientific paper Deshpande, Jayant V. (1968) "On Continuity of a Partial Order" Proceedings of the American Mathematical Society , 19 (2): 383-386. Doi:10.1-9-/S0002-9939-1968-0236071-7, which is incorporated herein by reference in its entirety.

[0026] SHA is a secure hashing algorithm. SHA is a one-way cryptographic function or set of functions that takes as input a string that can be of variable length and produce a fixed length output. The task of SHA is to produce an output string from which no input string can be obtained. For the purposes of this description, references to SHA refer to an implementation of the SHA-2 family known as SHA256 that conforms to (or satisfies) the US National Security Agency standard published in Federal Information Processing Standards (FIPS) Publication 180-4 of the National Institute of Standards and Technology (NIST). ). SHA256 can accept a variable length input string up to 1,844e19 characters (over 2,000,000 terabytes) and produce a 256-bit (32-byte) output string. In at least some implementations of SHA256, it is possible to receive an input string (null) and generate an output string. The output string of SHA256 (or another SHA algorithm) is called a digest. The term "hash" can be used interchangeably with the term "digest". In some embodiments of the present disclosure, other suitable secure cryptographic hash algorithms may be used.

[0027] The digest is the result of a secure hashing algorithm. In SHA256, the digest is 256 bits long, or 32 bytes. A digest, also known as a hash, has a fixed length of 256 bits; thus, SHA256 can create up to ^2,256 individual digests (hashes). The digest representation may vary in length depending on the encoding method in the computing system. For example, a hexadecimal computing system might represent a digest as a 32-character string.

[0028] The term "double hash" or "double hash" refers to "hashing the hash" or creating a digest and then using that digest as an input string or part of the input string for another hash iteration to create a new digest. For the second iteration, the output digest of the first iteration can be combined with another digest, such as by concatenation, and the combination of the two digests forms the input value for the second hash iteration. If no other digest is available, the first output digest can be duplicated with the original, and the duplicated digests can be combined to form the input for the second hash iteration.

[0029] The term "merklization" (in some publications "merkelization") refers to the process in which each group of data rows is processed using the SHA algorithm and each resulting digest is paired with another similarly obtained digest, for example, by concatenation, and then processed again with SHA to create a new digest, and this procedure is repeated until only one digest remains. If there is an odd number of digests in any iteration (more than one (1)), one of the digests is duplicated, and the duplicate is concatenated with its original and then processed using SHA. The one remaining digest may be referred to as the root of the Merkle tree for a particular group of data rows. Similarly, the term "Merklized" refers to data that has been processed by merklization.

[0030] The term "cross-merklization" refers to merklization in which data from one blockchain (in the form of a digest) is merklized with data from another blockchain, also in the form of a digest. In a blockchain network, each participating blockchain contributes to a digest linking the last block of the blockchain to every other participating blockchain, and each participating blockchain merkles with each other all the digests accepted for the current block. Cross-merklization is also detailed below.

[0031] The term "system time" refers to the time of the timing subsystem of the computing system. It is common practice to configure the computer system's timing subsystem to periodically synchronize it with a remote timing system (eg, a time server maintained by the National Institute of Standards and Technology (NIST)).

[0032] The term "relative time" refers to the ordering of events based on the true time at which the event occurred, or which was assumed by a particular ordering mechanism or reported to it without respecting a strict time reference. For illustrative purposes, event A may occur on computer system CS-A at 20180601:0101:10.150 UTC, event B may occur on computer system CS-B 400 milliseconds after event A relative to UTC, and event C may occur on a CS-C computer system, 1300 milliseconds (1.3 seconds) after event A and 900 milliseconds after event B relative to UTC. CS-A and CS-B can report to CS-C when events A and B occur, including the system time of the event. Due to network topology, event B may arrive at CS-C 700 milliseconds after event B occurs and 200 milliseconds before event C occurs. Due to remoteness and network delays, event A may arrive at CS- C 2900 milliseconds (2.9 seconds) after event A occurred and 1600 milliseconds (1.6 seconds) after event C occurred. For CS-C, the relative time (order) of the specified events, based on whether when event C occurred in CS-C, and event messages A and B received in CS-C are: BCA, even if the absolute order according to UTC is expressed as AB C.

[0033] The term "collision" refers either to identical digests produced by SHA (digest collision) or to the simultaneous occurrence of two or more blocks (block collision). Digest collision, although unlikely, is theoretically possible due to different input strings. Collision of digests can arise due to the fact that many computing systems create identical digests at the same time or almost simultaneously with each other and, for example, participate in the blockchain network. A block collision can occur when two (or more) computing systems participating in a blockchain network create and/or deliver and/or receive blocks at the same time or with identical timestamps. Using the methods of blockchain systems, collisions of each of the specified types are minimized with the ability to prevent failure or blocking of the blockchain (s). For example, a computing system receiving a block from another blockchain that has a timestamp identical to the timestamp of the receiving computing system's last native block could simply ignore the input block's timestamp and treat the input block as coming immediately after the last native block. Similarly, a blockchain-participating computing system that receives a block from another blockchain at the same time that it creates its own block can be configured to treat an incoming block as having arrived after the creation of a new native block, regardless of the timestamp of the incoming block. A blockchain participating computing system receiving a block from each of the two (or more) participating computing systems can be configured to order a plurality of incoming blocks based on one of the timestamps of each block, the length (also called height) of each sending blockchain, assigning an ID blockchain, etc.

[0034] The term "collision resistance" refers to the low probability of digest collisions for different input rows (because block collision elimination depends only on the choice of block ordering method, block collision resistance is not a serious problem). Since the SHA256 algorithm is capable of producing up to ²²⁵⁶ separate digests, collision resistance can be considered quite high. In some computing applications, the collision resistance of SHA256 can theoretically be reduced by artificially imposing one or more restrictions on the allowable resulting digests. In other words, a particular application can apply a rule of x consecutive bits having a value of 0, thereby effectively reducing the number of individual digests that a particular application can take as output from the SHA256 algorithm. Since SHA is a one-way cryptographic function, such an output restriction rule cannot be used as an input parameter to SHA256, but only as a post-processing implementation that iteratively generates digests with different input strings until a digest is generated that satisfies the rule. In at least some blockchain implementations, changing the input string can be done by adding a random code to the beginning or end of the input string, and incrementing the random code, or randomly generating, or otherwise obtaining an arbitrary new random code with each SHA iteration, until no digest will be generated that matches the rule.

[0035] The term "collision resolution" refers to a system(s) or method(s) for excluding all identical digests, with the ability to discard each excluded digest. When a digest is discarded, the block of which the discarded digest is a member may also be discarded.

[0036] The term "random code" refers to an arbitrary integer (eg, a 32-bit integer). The random code may be an element from a series of random codes. In some embodiments, the random code is randomly generated or pseudo-randomly generated for each use iteration. In other embodiments, the implementation of the random code may be increased to the next value for each subsequent iteration of use. The seed value of the random code (the random code for the first iteration of the block generation loop) may be chosen, eg without limitation, by an algorithm generating a 32-bit integer, or may be a protocol-defined seed. The next random code (a subsequent iteration in the same block generation cycle) may be determined by an algorithm that re-generates a 32-bit integer, or may be a protocol-defined increment of the previously used random code. In one embodiment, the random code may be re-generated for each iteration regardless of the previous value of the random code.

[0037] The term "proof of work" refers to a digest that satisfies an output restriction rule that sets the requirement for x consecutive bits to be 0. Since SHA does not accept an output parameter, the digest can be compared with the rule after generation. A digest that satisfies a rule is generated by iteratively generating digests until a digest that satisfies the rule is obtained. A digest that satisfies the rule can serve as evidence ("proof") that some amount of computer processing ("work") has been performed to create the digest. An output constraint rule might likewise require x consecutive bits that have a value of 1, or a specific substring of a specific length with a specific order of 0s and 1s. Requiring a better (longer) proof of work might result in lower collision resistance.

[0038] The term "target complexity" refers to an element that defines a specific constraint for generating a proof-of-work digest. For example, without limitation, the target complexity may indicate that a digest must have ten (10) consecutive 0-bits to be considered a proof-of-work digest.

[0039] The term "transaction" can generally refer to (a) an exchange, such as the exchange of goods/services for goods/services, goods/services for payment, exchange of debt obligations, exchange of obligations for delivery dates, exchange of monetary obligations, etc. d.; and (b) a computer function by which a transaction of type (a) is registered or otherwise processed; and to (c) a computer function by which a transaction of type (b) is registered. As an example, a transaction of type (a) could be the sale of a widget for cash; the associated transaction of type (b) may represent a reduction in the number of widgets in stock as a result of said sale; and an associated transaction of type (c) may be a computer log entry of information (e.g., user identity, login time, inventory software access, subtraction of a sold widget, etc.) about accessing, from - for which there was less goods in stock. Type (c) transactions may also include information about installing, modifying, or removing firmware or software, including image size, digital signature, license, certificate, and so on.

[0040] It should be understood that the placement and configuration of the components of the embodiments substantially described and shown in the figures herein may have a wide variety of different configurations. Thus, the following more detailed description of the various embodiments presented in the figures is not intended to limit the scope of the description as stated, but represents various embodiments. While various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

[0041] The grammatical means of expressing the singular can be described as "one", but not limited to one. For example, although the description may include the expression "group with digest", this description also assumes that there may be two or more digests in the specified group.

[0042] Unless otherwise noted, all ranges include both endpoints and all numbers between the endpoints.

[0043] As used herein, reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described with respect to a given embodiment is included in at least one embodiment. Thus, the expressions given herein, or variations thereof, do not necessarily refer to the same embodiment.

[0044] FIG. 1 is a diagram of a block 10 of a blockchain in a computing system 1 according to an embodiment of the present disclosure. Block 10 may include a header 11 (hdr) and payload 13. Block 10 may be created or otherwise implemented in computing system 1 by implementing a blockchain according to an embodiment of the present disclosure. Block 10 shown in FIG. 1 contains a block identifier (or block ID) 12 , a blockchain version (or blockchain version identifier) 14 , a blockchain identifier (or blockchain ID) 16 , a timestamp 18 , a proof of work (or POWR) area 20 (which can be considered as a set set theory), a block digest 30, a target difficulty 40, a block random code 50, and a group of auxiliary block digests 60. Block 10 may include one or more record digests 70, 72, 74 (e.g., roots of a Merkle tree), including the record digest 70 of the current block 10 and one or more block record digests 72, 74 of participating neighboring blockchains. Digests 70, 72, 74 records can be considered as a set in the framework of the theory of mathematical set. Block 10 may include more than one block header 80, 82 for blocks received from other blockchains (eg, participating neighboring blockchains).

[0045] Block 10 may include a record group 90 within payload 13. Said record group may contain transaction records. Transaction records may contain information relating to the transaction.

[0046] Header 11 of block 10 may contain block identifier 12, blockchain version 14, blockchain identifier 16, timestamp 18, POWR 20, block digest 30, target difficulty 40, block random code 50, auxiliary block digest group 60, and digest 70 ( Merkle tree root) transaction records of block 10. Payload 13 may contain a group of 90 records.

[0047] The block identifier 12 may be an ordinal identifier indicating the relative order of the block 10 in the blockchain to which the block 10 belongs. The blockchain version identifier 14 may indicate the specific version of the blockchain protocol on which the blockchain that created the block 10 operates. Time stamp 18 may be a system time indicator obtained from the timing subsystem of the computing system 1 hosting the blockchain in which the block 10 was created. Next, the POWR 20, the block digest 30, the target difficulty 40, and the auxiliary block digest group 60 will be described. The shape and order of the above elements in block 10 can be determined by the blockchain protocol on which the blockchain that created block 10 operates.

[0048] Computing system 1 may be any suitable computing system including one or more computing devices, each containing one or more processors, one or more computer-readable media, one or more electronic storage devices, one or more input/ output and/or one or more communication interfaces.

[0049] The order of elements 12-90 shown in FIG. 1 is provided for the convenience of the reader and is not binding on a particular embodiment of the present disclosure. One embodiment of the present description may include more or fewer elements than described herein.

[0050] FIG. 2 is a diagram of a cross-merklized blockchain network 100 having three participating blockchains, namely a main blockchain 200, a first participating neighbor 300, and a second participating neighbor 400, in accordance with an embodiment of the present disclosure. The main blockchain 200 contains a number of blocks in accordance with the embodiment of the present description, on the basis of which the block 230 is identified. The block 10 depicted in FIG. 1 is also shown in the context of blockchain network 100 and main blockchain 200. Although FIG. 2 shows three participating blockchains 200, 300, 400 of blockchain network 100, a blockchain network as described herein may include fewer (but at least two) or more participating blockchains. In addition, the blockchain network 100 may be a multiplex network.

[0051] The block 230 of the main blockchain 200 contains at least a unique block identifier 212, a blockchain version 214, a blockchain identifier 216, a timestamp 218, and a data area 226. The unique block identifier 212 may be the same as (and reasonably different from) the unique block identifier 12 for block 10. The blockchain version 214 may be the same as the blockchain version 14 for block 10. The blockchain identifier 216 may be the same as the blockchain identifier 16 for block 10. The time 218 may be similar to (and reasonably different from) the timestamp 18 for block 10. Data area 226 may include elements similar to other elements of block 10 shown in FIG. 1 and may include elements not shown in FIG. 1. Block 330 of the first participating neighbor blockchain 300 is identified, having elements 312, 314, 316, 318, 326, which may be generally similar to block 230 of the main blockchain 200. Block 430 of the second participating neighbor blockchain 400, having elements 412, 414, is identified. 416, 418, 426, which may be generally similar to block 230 of the main blockchain 200.

[0052] Blocks 230, 330, 430 are each represented below their respective blockchains 200, 300, 400, although they are shown in this manner solely for convenience of description. Each of blocks 230, 330, 430 can be obtained using a number of blocks of the corresponding blockchain 200, 300, 400 of each block 230, 330, 430. As an example, for block 230 of the main blockchain 200, the next block is block 10 _P , after followed by block 10, and block 10 is followed by block 10 _N . Each of the subsequent blocks 10 _P , 10, 10 _N , etc. of the main _blockchain 200 has a timestamp similar to the timestamp 218 of block 230 _. points in time. Within the main blockchain 200, the timestamps recorded in each of the subsequent blocks form at least a logical order of events within the main blockchain 200. In other words, the timestamp of each block within the main blockchain 200 is derived from the system time of the computing system in which blocks are generated.

[0053] Similarly, participating neighboring blockchains 300, 400 are represented, having next blocks 330 _P , 430 _P sequentially located at later times, and otherwise generally and functionally similar to the main blockchain 200. As well as subsequent block timestamps of the main blockchain 200 , subsequent block timestamps of each participating neighboring blockchain 300, 400 establish a reference sequential immutable order within the corresponding blockchain 300, 400.

[0054] The main blockchain 200 may be permanently present in the computing system 1 shown in FIG. 1, from which the blockchain 200 obtains the time value for each successive block timestamp. Each participating neighbor blockchain 300, 400 may likewise be permanently present in a respective distinct computing system similar to computing system 1 of the main blockchain 200. Each participating neighboring blockchain 300, 400 may determine the time value for each successive block timestamp of the respective blockchain 300, 400 based on system time of a computing system (similar to computing system 1 of blockchain 200) in which a corresponding participating neighboring blockchain 300, 400 is always present. As will be apparent to one skilled in the art, each of the computing systems (similar to computing system 1 of main blockchain 200) may various parameters and/or mechanisms for providing system time.

[0055] As each participating blockchain 200, 300, 400 completes each successive block, that block is transferred to at least one participating neighboring blockchain. For example, each block of the first participating neighbor 300 can be transferred 324 to at least the main blockchain 200 and each block of the second participating neighbor 400 can be transferred 422 to at least the main blockchain 200 as each block is generated. The main blockchain 200 may be independent of the relative block creation time within the participating neighbor blockchain 300, 400. when blockchain 200 "learns" the existence of a block in the participating neighboring blockchain 300, 400. More broadly, since each of the blockchains 200, 300, 400 creates a block, such as blocks 230, 330, 430 respectively, and passes them to the others in the same way blockchains 200, 300, 400 within the blockchain network 100, each of the blockchains 200, 300, 400 can record 112 the creation of each subsequent block and can order 114 these blocks in a progressive time series 110. In other words, each blockchain 200, 300, 400 may have information about the time order 114 of creation (or transfer upon creation) of each block of each blockchain 200, 300, 400 in the bl network okchain 100. See FIG. 5-6 below.

[0056] Referring to FIG. 1 and 2. In this example, the block 10 shown in FIG. 1 is an element of the main blockchain 200 shown in FIG. 2. Block ID 12 may be unique to block 10. In other words, each block in the blockchain can have a unique block ID 12. Blockchain version 14 may specify the specific implementation of the blockchain protocol used on the main blockchain 200 when block 10 is created. Blockchain ID 16 can identify the specific blockchain 200 of which block 10 is a member. Blockchain ID 16 is shown in 4-byte hexadecimal representation solely for convenience and is not necessary for the present description. The blockchain identifier 16 can be formed in various ways, provided that the blockchain identifier 16 is unique for each blockchain. The timestamp 18 may indicate the system time point at which the block 10 was created. The timestamp 18 may take the form of, for example, without limitation, a timestamp associated with a "Unix epoch" (Unix epoch), or any other form appropriate to the embodiment. blockchain protocol in accordance with the present description.

[0057] Auxiliary block digest group 60 includes the most recent block digests 66, 64, 62 from each blockchain 200, 300, 400 participating in the blockchain network 100. In the example shown in FIG. 1, block digest group 60 comprises a block digest 62 of the latest block from the first participating neighbor blockchain 300, a block digest 64 of the latest block from the second participating neighbor blockchain 400, and a block digest 66 of the latest block on the main blockchain 200 just before block 10.

[0058] Block digest 30 is obtained by merklization of block digest 62 and block digest 64. In other words, block digests 62, 64 (for blocks from participating neighboring blockchains) are concatenated to form a single 64-byte string, which is then processed using SHA. The output of merklization of block digests 62, 64 with SHA is a 32-byte string consisting entirely of block digest 30. Since each block digest 62, 64, 66 is formed by a different blockchain 200, 300, 400, the merclization of these block digests 62, 64, 66 is, in particular, cross-merclization. In a blockchain network including more than three participating blocks, block digest group 60 may contain a block digest from each participating blockchain and each such block digest may be cross-merklized, and a merkle tree root for block digests is created to generate block digest 30. Block 10 includes a block digest 66 that was created in the same manner as part of the most recent block 10 _P before and within the main blockchain 200. Block digest 66 may connect block 10 to the most recent previously created block 10 _P within main blockchain 200. Similarly, block 10 blockchain protocol 200 may ensure that block digest 30 is transmitted to the immediately following block 10 _N on main blockchain 200. Thus, block 10 _N following block 10 is linked to block 10, and block 10 is linked to the most recent block 10 _P preceding block 10. This interlocking of blocks is common to the entire main blockchain 200 and is configured to link each block to its immediate predecessor. and the blocks immediately following it. Similarly, a block digest 62 can be transferred from the participating neighbor 300 to the main blockchain 200, and a block digest 64 can be transferred from the participating neighbor 400 to the main blockchain 200. In this way, block 10 can be linked to the immediately preceding block 330 _P , 430 _P within each participating neighboring blockchain 300, 400 is similar to linking block 10 to the immediately preceding block 10 _P within main blockchain 200.

[0059] The blockchain protocol 200 of block 10 may also provide for the transmission 222, 224 of a block digest 30 to each participating neighboring block 300, 400 with the ability to link the immediately following block 330 _N , 430 _N of each participating neighboring block 300, 400 to block 10 of the main blockchain 200. Thus, each of the participating blockchains 200, 300, 400 is connected to each other of the participating blockchains 200, 300, 400. In particular, the main blockchain 200 is directly connected to each participating neighboring blockchain 300, 400 by receiving directly from each participating neighboring blockchain 300, 400 previous digests 62, 64 blocks for blocks 330 _P , 430 _P ; and sending a block digest 30 to each of the participating neighboring blockchains 300, 400. The participating neighboring blockchains 300, 400 are indirectly connected to each other by sending each participating neighboring blockchain 300, 400 block digests (similar to digests 62, 64) to the main blockchain 200 and receiving from the main blockchain 200 block digests (similar to digests 64, 62) of another participating neighboring blockchain 400, 300. nearest next block of the participating blockchain. This cross-merklization process can rapidly propagate and occur throughout the blockchain network 100, whereby the participating blockchains 200, 300, 400 are interconnected in a cryptographic and independently verifiable manner. By sharing (i.e., sending a block digest 30) to other participating neighboring blockchains 300, 400 in the blockchain network 100, immutability (i.e., data included by the blockchain) is not related to the consistency (i.e., to add a block) of the participating blockchains 200, 300, 400.

[0060] FIG. 3A is a partial block diagram illustrating the cross-merclization of blocks 330 _P and 430 _P of participating neighboring blockchains 300, 400 with the main blockchain 200 shown in FIG. 1-2, in accordance with an embodiment of the present description. FIG. 3B is a partial block diagram illustrating the construction of block 10. As shown in FIG. 3A and 3B, on the main blockchain 200, block 10 may be immediately preceded by block 10 _P . Digest 66 of block 10 _P may be passed 701 directly to block 10. Block digest 66 may function as a reference to a previous block 10 _P , with the block immediately preceding block 10. The most recent preceding block 330 _P of the participating neighbor blockchain 300 may be passed (see ₃₂₄ in _FIG . 2) to the main blockchain 200, and the block digest 64 is retrieved and passed 703 directly to block 10.

[0061] The target complexity 40 may also be extracted 704 from the previous block 10 _P . In one embodiment, the target difficulty 40 can also be extracted from the block 330 _P , 430 _P of the participating neighbor blockchain 300, 400 for comparison with the target difficulty 40 of the previous block 10 _P as an additional validation before inclusion in the data block 10 from the participating neighbor blockchain 300 , 400.

[0062] Block digest 62 from block 330 _P and block digest 64 from block 430 _P may be concatenated 710, 711 with each other to form input string 29. The order in which the concatenation process takes place may be set as a requirement of a particular implementation of the network blockchain protocol. block 100. The input string 29 can then be passed 712 and processed using SHA 600 to generate 713 a block digest 30 for block 10. The block digest 30 can be passed 764 (via R4) to block 10. At a later stage, when the main blockchain 200 generates the next block 10 _N , the block digest 30 may be passed as an element of block 10 to block 10 _N and may function as a link from block 10 _N back to block 10, which includes the block digest 66 as a reference to the previous block 10 _P. This procedure of including the block digest of each previous block in the next block provides the formation of a chain of reference links between all blocks of the blockchain with the possibility of creating an immutable record of the order of blocks within the blockchain. This immutable order of blocks within a blockchain essentially provides an immutable record of the data included in each of the blocks of a particular blockchain, and therefore each participating blockchain in the blockchain network 100. In addition, immutability is not associated with any requirements regarding a separate blockchain for the consistency of the participating nodes regarding the addition of the block.

[0063] Each blockchain 200, 300, 400 may use a random code source 500, with each participating blockchain 200, 300, 400 having its own random code source 500. The random code source 500 may be a computational process that generates a random code for each iteration, or may be a computational process that generates an initial random code for the first iteration and then increments or otherwise changes the random code for each successive iteration. iterations. Random candidate code 510 may be received from a random code source 500 . The method for selecting the first random candidate code 510 may be defined in the blockchain protocol of the participating blockchain 200, 300, 400 and may be defined in the blockchain network protocol 100. The random candidate code 510 and the block digest 30 may be concatenated with each other 720, 721 s input string 520. Input string 520 can then be processed 730 with SHA 600 to produce 731 a proof-of-work (POW digest) candidate digest 32 based on the block digest 30 . Candidate POW digest 32 can then be compared 740 with a target complexity of 40 in step 550. In other words, POW digest 32 is obtained by "hash hashing" in which the hash to be hashed is the block digest 30, thus POW digest 32 is is a double hash.

[0064] Target difficulty 40 is represented in this example as a hexadecimal value; however, neither the explicit expression 0xFFFF0000 nor the hexadecimal format is required for the present description. Target complexity 40 can be expressed in a form that conveys a certain number of consecutive bits having a value of "off" (or bytes having a value of "0") occurring either at the higher or lower end of the resulting digest to qualify as POW, in each blockchain 200, 300, 400 of the blockchain network 100. In another embodiment, the target difficulty 40 may be structured to require a certain number of consecutive bits having a value of "on" (or bytes having a value of "1"). In another embodiment, the target complexity 40 may be determined by a certain sequence of "off" and "on" bits (bytes "0" and "1") present in a certain section of the digest candidate 32 POW.

[0065] If the POW digest candidate 32 does not match the target difficulty 40 552, the POW digest candidate 32 and the random code candidate 510 are discarded 590 and the blockchain returns R ₁ to the random code source 500 . A new random candidate code 510 is selected. The method for selecting a new random candidate code 510 can be defined in the blockchain protocol of the participating blockchain 200, 300, 400 and can be defined in the blockchain network protocol 100 as, for example, without limitation, a constant increase in the value of random code at each iteration or a constant decrease at each iteration. The new random candidate code 510 may be concatenated with the block digest 30, then processed using SHA 600, then compared 550 against a target complexity of 40. These steps may include iterating with the new random candidate code 510 at each iteration until a digest candidate 32 POW satisfying target complexity 40.

[0066] If the POW digest candidate 32 satisfies 550 the target complexity 40, the POW digest candidate 32 is sent 558 to perform a brief test 560 to determine if more POW digests are required to complete the POWR 20 of block 10. Since the current POW digest candidate 32 is derived from the current block 10, at least one additional POW digest is required. In this example, two additional POW digests are needed. Because of this, the "last digest" test 560 fails with an error 562. The current digest candidate 32 POW can be placed 760 in temporary storage 563 and the blockchain 200 returns R ₂ to the current random candidate code 510. The random candidate code 510 providing a successful digest candidate 32 POW, reuse 723 by concatenating random code candidate 510 with digest 62 (722) to obtain input string 530. Input string 530 can be passed 732 to SHA 600 to obtain 733 digest candidate 22 POW . The POW digest candidate 22 is then processed 741 to compare against the target complexity 40. If the current POW digest candidate 22 does not meet the target complexity 40 550, the current POW digest candidate 22 and the random candidate code 510 are discarded 552, 590. In addition, the previous digest candidate 32 POW is removed 750 from the temporary storage device 563 and discarded 590. The blockchain 200 then returns R ₁ to select a new random candidate code 510.

[0067] If the POW digest candidate 22 satisfies 550 the target complexity 40, the POW digest candidate 22 may be stored 760 in temporary storage 563 along with the previous POW digest candidate 32. The blockchain continues to iteratively traverse R ₁ , R _{2 of} the random code until a digest candidate of 32, 22, 24, etc. is generated. POW satisfying the target complexity of 40 for every last digest 66, 62, 64, etc block of the main blockchain 200 and participating neighboring blockchains 300, 400, etc. After a digest candidate 32, 22, 24, etc. POW is generated for each block digest 66, 62, 64, etc. , satisfying the target complexity of 40, each of the candidate digests 32, 22, 24, etc. POW can be retrieved 566 from temporary storage 563 to be placed 762 in POWR 20 of block 10. Main blockchain 200 can also store 766 successful random candidate code 510 as block random code 50 in block 10.

[0068] Once block 10 is created, main blockchain 200 may transmit block 10 to each of the participating neighboring blockchains 300, 400. Block 10 includes block digests 62 and 64 that blockchain 200 receives from the last preceding block 330 _P , 430 _P of each of the respective of the participating neighbor blockchains 300, 400. In other words, block element 10 is a digest 62 from the last preceding block 330 _P of the first participating neighbor blockchain 300. Accordingly, the block digest 62 comes from the participating neighbor blockchain 300 and then is sent back to it, whereby the participating neighbor blockchain 300 may verify or otherwise verify the integrity of its own stored data and/or transactions. Similarly, a block digest 64 has been received from and will be sent back to the second participating neighbor 400, whereby the second participating neighbor 400 can verify or otherwise verify the integrity of its own stored data and/or transactions. Thanks to the POWR 20 of block 10 in each of the participating neighboring blockchains 300, 400, the validity of block 10 is guaranteed, which means that the corresponding digests 62, 64 blocks are received for each of the participating neighboring blockchains 300, 400 as digests 62, 64 blocks are received in the main blockchain 200. Similarly, a block digest 30 from block 10 is transmitted to each of the participating neighbor chains 300, 400. Each of the participating neighbor blocks 300, 400 will return a block digest 30 to the main blockchain 200 using the next subsequent block from each participating neighbor blockchain 300 , 400. This allows the main blockchain 200 to verify the validity of the blockchain 200 itself, and hence the transaction records of each block of the blockchain 200. In addition, since the main blockchain 200 transmits to each of the participating neighboring blockchains 300, 400 a successful random candidate code 510, each of participating neighboring blockchains 300, 400 can process to each previous block digest 62, 64, 66 using SHA, using the described successful random candidate code 510 to ensure the generation of POWR in accordance with the blockchain protocol and the correctness of each block digest 62, 64, 66. Thus, in each participating neighboring blockchain, high certainty can be ensured with respect to data integrity, including the order of operations and digests, of each participating blockchain 200, 300, 400, even if each participating blockchain 200, 300, 400 does not have up-to-date data regarding each other participating blockchain 200, 300, 400. In this way, it is possible to create an immutable record for each blockchain 200, 300, 400 without the need for prior trust and without relying on negotiation, except to participate in the blockchain network 100. In other words, data immutability is not is related to the consistency of participating blockchains 200, 300, 400.

[0069] In addition, by allowing each participating blockchain 200, 300, 400 to independently verify that random candidate code 510 and previous block digests (similar to block digests 62, 64, 66 shown in FIG. 1, 3A) generate digests that meet the target complexity (similar to POW digests 22, 24, 32 shown in FIG. 3A), each of the participating blockchains 200, 300, 400 can recognize an anomaly associated with the data of one of the participating blockchains 200, 300, 400. In other words if the participating peer blockchain 300 performs block digest validation (similar to block digests 62, 64, 66) using the random candidate code 510 reported by main blockchain 200, and any of the resulting digests in the validation process fails to match the corresponding POW digest reported main blockchain 200, the participating neighbor blockchain 300 can identify the digest anomaly for each participating blockchain 200, 300, 400. Thus, it is possible to detect an anomaly in the data in the participating blockchain 200, 300, 400 of the blockchain network 100 at the time of the event that caused the anomaly and without describing the included actual data. In addition, the participating blockchain 200, 300, 400 that identified the anomaly may also combine previously known correct block data with the identified anomaly data and propagate evidence of abnormal operation to the other participating blockchain 200, 300, 400, including blockchain 200, 300, 400, in in which the anomaly is present. Through this cross-reporting of anomaly or evidence of abnormal functioning, each participating blockchain 200, 300, 400 is protected from possible input of incorrect data, and it is possible to prevent the occurrence of anomalous data (regardless of its source) for the audit log of each owner/operator of a computer system for a few minutes. For example, in the worst case, if the participating neighbor blockchain 400 detects anomalous data in a block from the participating neighbor blockchain 300, and the subject computing system(s) managing the participating neighbor blockchain 300 is so severely damaged (- s) that the owner/operator of the computing system(s) cannot detect the anomaly internally, data from any other participating blockchain 200, 400 will be able to reconstruct the anomaly event, as well as perform correction and reduce negative effects.

[0070] The above-described cross-merklization process can also be referred to as mutual cross-mining, since each participating blockchain 200, 300, 400 creates blocks simultaneously and independently of each of the other participating blockchains 200, 300, 400, and in doing so accepts any blocks that may be are represented by each of the participating blockchains 200, 300, 400.

[0071] FIG. 4 is a graph 150 illustrating the geometrically progressive degree of immutability that can be provided in a blockchain network, such as the blockchain network 100 depicted in FIG. 2-3B, in accordance with an embodiment of the present description, as well as for off-chain blockchain. In the present example, the degree of immutability depends on the location of the iteratively nested initial block digest within a given child block. In other words, the immutability of the initial block is 1 within the initial block, 2 after the second block, 4 after the third block, 8 after the fourth block, and so on. the initial block nested by cross-merklization in participating neighboring blockchains. For example, in a blockchain network with three participating blockchains, such as the main blockchain 200 shown in FIG. 2-3B, the initial block has a degree of immutability of 6 after the second block, 21 after the third block, 44 after the third block, and so on. Due to multiple nesting, in particular horizontal nesting, immutability is further improved.

[0072] The vertical scale 152 of graph 150 represents the degree of immutability that can be achieved in various embodiments of the present disclosure. The horizontal bar 154 of the graph 150 represents a plurality of blocks created in various implementations. It should be noted that the vertical scale 152 of plot 150 clearly demonstrates an increase in persistence of three orders of magnitude for each scale mark such that plot 150 spans the vertical range of values from 0 to ¹⁰⁹⁰ (1 and then 910). In particular, plot 150 reflects, without limitation, a general trend towards exponential immutability.

[0073] Data line 160 represents the approximate degree of non-chain blockchain immutability for the first 100 blocks created. Data line 162 represents the approximate degree of immutability for a blockchain participating in a blockchain network of three participating blockchains, similar to the main blockchain 200 shown in FIG. 2-3B. Data lines 164 and 166 represent the degree of blockchain immutability in a blockchain network with five and eight participating blockchains, respectively. Due to the display of the vertical scale 152 in order of magnitude, the data lines 160, 162, 164, 166 appear to represent only a linear deviation. As a reference, the degree of immutability of the data line 160 (representing the off-chain blockchain) after the creation of the 50th block is 2.815×10 ¹⁴ , and the degree of immutability of the data line 162 (which represents the blockchain network of three blockchains) is 1.994×10 ²³ , or in 7.084×10 ⁸ times more than for off-chain blockchain. After 100 blocks, the blockchain represented by data line 162 has a degree of immutability that is 4.517 x 10 ¹⁷ times the degree of immutability of the offline blockchain represented by data line 160. The blockchain on the eight blockchain network represented by data line 166 has a degree of immutability approximately 2.152×10 ⁵⁹ times greater than the off-chain blockchain after 100 blocks have been created.

[0074] FIG. 5 is a partial flow diagram of operations performed on a computing system such as that shown in FIG. 1-3B, a computing system 1 comprising a main blockchain 200 and an event log 280, in accordance with an embodiment of the present disclosure. The elements shown in FIG. 5 are generally similar to the corresponding elements shown in FIG. 2. Blocks 230, 330, 430, respectively, of the main blockchain 200 and the first and second participating neighboring blockchains 300, 400 are shown for reference. Time progression 110 is also shown for reference and is similar to time progression 110 shown in FIG. 2. The main blockchain 200 can be managed in or with the computing system 1. In addition to the main blockchain 200, the computing system 1 can generate an event log 280 on an ongoing basis. At least part of the communication shown in FIG. 5 may occur on the same network as shown in FIG. 2, which may be a multiplex network.

[0075] The event log 280 contains a group of event records shown in FIG. 5 next to the labels in the diagram of the event log 280. The event entry 284 is shown as an enlarged label and may be an event entry in the event log 280 recording the initial initialization of computer system 1. The event entry 284 may contain an initial sequence identifier 286 (sequence identifier), which in this case is shown as "0000" to represent the first and initial event entry in the event log 280. The event record 284 may also contain an identifier 288 representing the logical owner of the event. For event record 284, identifier 288 is shown as "0000" to represent, for example, without limitation, the host operating system of computer system 1. Each event record may also contain an implementable element, as described below.

[0076] Each event entry (represented by a series of labels in the event log 280) can be entered into the event log 280 as separate consecutive rows. Each event entry in the event log 280 may include a timestamp (not shown), and the presence of such a timestamp in the event entry may be preferred by a computer operator (not shown) manually checking the event log 280. The entries in the event log 280 and the event log 280 itself may be independent of time. The ID of each event record following the initial event record with sequence ID 286 "0000" may be incremented by 1. In other words, the event record immediately following the initial event record 284 may have sequence ID: "0001" .

[0077] As an example, block 230 is shown, similar to block 230 shown in FIG. 5, which was generated by the main blockchain 200 and which corresponds to the event record 211 in the event log 280. The event entry 211 has the sequence ID 213 "0004", which in the present example indicates that this is the fifth consecutive event entry in the event log 280. The event record 211 contains an event identifier 215 ("event ID") "A01" indicating that the event record 211 is logically related to the block 230 of the main blockchain 200. For convenience, the value "A01" of the event identifier 215 associates the event record 211 with the block 230 of the main blockchain 200 in FIG. 5 and similarly with the same block 230 shown in FIG. 2. As shown in the figure, in the next step, the main blockchain 200 generates the next block 240. When the block 240 is generated by the main blockchain 200, an event record 244 appears in the event log 280 242 . The event record 244 contains the sequence ID 246 "0009" and the event ID 248 "A02". Event ID 248 "A02" identifies the logical owner of event record 244 as block 240 of main blockchain 200. Sequence ID 246 "0009" indicates that event record 211 is the tenth event record in event log 280.

[0078] As shown in the figure, after block 240 is created on the main blockchain, block 340 is generated on the first participating neighbor blockchain 300. Participating blockchain 300 transmits 341 blocks 340 (or the cryptographic hash of block 340 (e.g. records) and any corresponding random code) to the main blockchain 200. The main blockchain 200 creates 342 an event record 344 in the event log 280. The event record 344 contains the sequence identifier 346 "000a" and the event identifier 348 "B02". The sequence identifier 346 "000a" indicates that the event entry 344 is the eleventh event entry in the event log. The event ID 348 "B02" indicates that the logical owner of the event record 344 is the block 340 of the first participating neighbor blockchain 300.

[0079] After blocks 240 and 340 are created, the second participating neighbor blockchain 400 can generate block 440. The second participating neighbor blockchain 400 transmits 441 blocks 440 (or the cryptographic hash of block 440 (e.g., POW hash, block hash, and/or record hash) and any corresponding random code) to the main blockchain 200. The main blockchain 200 creates 442 an event entry 444 in the event log 280 . The event record 444 contains the sequence ID 446 "000b" and the event ID 448 "C02". Sequence ID 446 "000b" indicates that event entry 444 is the twelfth event entry in the event log.

[0080] In one embodiment, a group of entries in the event log 280 from the creation of the first block may be merklized and included in the second block. In other words, when using the main blockchain 200 shown in FIG. 5, as an example, entries in the event log 280 starting with the creation of block 240 and having sequence ID 246 and other sequences with values from 0009 to 000b inclusive can be merklized with each other and included in the next block 250 of the main blockchain 200. Values used herein for sequence identifiers 246, 286, 346, 446 are merely examples to illustrate that each consecutive event record 244, 344, 444 corresponds to an ascending sequence identifier 246, 346, 446. The specific event log 280 may contain additional entries between specific entries 244, 344, 444 related to the creation of blocks on the main blockchain 200 and the receipt by the main blockchain 200 of blocks from the first and second participating neighboring blockchains 300, 400.

[0081] Although the present example presents an event log 280 containing only entries associated with blockchain blocks, in another embodiment, the event log may also include other entries. For example, the event log may include records of events corresponding to any of the various events recorded on blockchains, including realizable events that may lead to or otherwise trigger an action. Similarly, the values "A02", "B02", and "C02" of the event IDs 248, 348, 448 are configured to provide convenient references and do not necessarily reflect a particular event or event ID value in each respective event record 244, 344, 444. In other words, each block-associated event record 244, 344, 444 of an event may contain a plurality of data elements related to a specific corresponding block of the blockchain, for example, without limitation, a block identifier, a block digest, a block timestamp, a blockchain identifier, etc. .

[0082] FIG. 5 shows an event log 280 of the computing system 1 hosting the main blockchain 200. Each participating blockchain 200, 300, 400, etc. may similarly have an event log 280, each such event log being independent of every other event log.

[0083] In addition, due to network delays or similar problems, it is possible that in the present example, a block of the participating neighboring blockchain 300, 400 will arrive on the main blockchain 200 with a delay leading to a technical reordering of the event log, but in the absence of any or any other factor, the specified delay will be negligible. In addition, vector clocks (described below) can correct technical reordering. In other words, at a certain speed of the computer, a block can be created in the main blockchain 200, for example, at time (1), while a block in any of the participating neighboring blockchains 300, 400 could be created at time (0), and time (1) is, for example, 500 milliseconds later than time (0), but a block from a participating neighbor chain 300 or 400 can enter the main chain at time (2), while time (2) is 800 milliseconds later time (0) and 300 milliseconds later than time (1). Since the event log 280 is time independent and the entries are sequentially executed according to the order of receipt, an event entry for a block logically related to a block of the participating neighbor blockchain 300 or 400 can be sequentially placed after an event entry for the block of the main blockchain 200, even if the block of the main blockchain 200 was technically created before the block of the participating neighboring blockchain 300, 400. The time difference for two consecutive or almost consecutive entries in the event log is most likely irrelevant, given that the vector clock (described below) is executed with the ability to correct any error in the order of the event records.

[0084] FIG. 6 is a detailed partial block diagram of the operations of the computer system 1 described in FIG. 5 in accordance with an embodiment of the present disclosure. The detail zone in FIG. 6 corresponds to an area of the event log 280 related to blocks 240, 340, 440 described above and corresponding to performing a hard timed validation in accordance with an embodiment of the present disclosure. The main blockchain 200 is shown as a logical process in computing system 1. Computing system 1 contains all the logical processes for managing the main blockchain 200 (or, in other words, it implements the protocol of the main blockchain 200) and additionally contains an event log 280 and a process 900 for checking the chronological compliance. In addition, the first and second participating neighboring blockchains 300, 400 are shown.

[0085] The chronological matching process 900 occurs substantially independent of time, since the chronological matching process 900 is not constrained or controlled by the time subsystem of computing system 1. The chronological matching process 900 module sends and receives data and requests to provide and log the comparison timestamp groups, as further described below.

[0086] As shown in the figure, the main blockchain 200 generates a block 240 of the blockchain. Block 240 may include a block timestamp (not shown, but see, for example, 18 in FIG. 1) indicating the system time at which block 240 was created. Main blockchain 200 may exchange data 910 with process module 900 computing system 1. In particular, the main blockchain 200 can exchange 910 with a module of the chronological check process 900 a lot of data related to the newly created block 240, such as, for example, a block identifier, a block timestamp, a block digest, etc. e. The chronological matching process 900 can electronically communicate 922 with the first time server 920 by sending a signed message including at least some of the provided data related to the newly created block 240 to the specified time server and querying the first server 920 the time the response was sent with a signed time certificate (not showing ano). The method for requesting the current time from the first time server 920 may be any suitable and standardized method or protocol suitable for obtaining current time data from a common time server, such as an asymmetric key network time synchronization protocol. The first time server 920 may send a response 922 over the same communication medium, and send back a signed message, and include a signed current time certificate on the first time server 920.

[0087] The chronological check process 900, after receiving the signed message returned from the first time server 920 along with the signed time certificate, may repeat this process by sending 932 the signed message to the second time server 930 along with a request to receive the signed time certificate (not shown). The second time server 930 may return a signed message relating to the newly created block 240 along with a signed time certificate (not shown) indicating the current time on the second time server 930 via the same communication medium. The time reported by the first time server 920 and the second time server 930 can then be compared using the time-matching process 900 to determine if the time deviation is within the allowable limits set in the blockchain protocol. If this deviation exceeds the limit set in the blockchain protocol, the time matching process 900 can resubmit requests to one or both time servers 920, 930, or one or more additional time servers similar to time servers 920, 930 can be sent requests.

[0088] If the deviation between the times reported by the first and second time servers 920, 930 is within acceptable limits according to the blockchain protocol, the time matching process 900 may then compare the block timestamp 18 with signed time certificates received from the first and second servers 920, 930 time. If the difference between the block time stamp 18 and the signed time certificates from the first and second time servers 920, 930 is within the time deviation tolerance set in the blockchain protocol, the time matching process 900 sends a signed message to the main blockchain 900 containing data related to to the newly generated block 240, along with signed time certificates and a signal indicating successful time-based validation. In another embodiment, the chronological matching process 900 may directly trigger 242 the creation of an event record 244 in the event log 280 . In another embodiment, the chronological matching process 900 may initiate another process running on the computing system 1 to initiate 242 the creation of an event record 244 .

[0089] The event record 244 in the event log 280 related (or logically related) to the newly created block 240 may contain a sequence identifier 246, an event identifier 248 indicating the logical owner of the event record 244, a block timestamp 249 (similar to the block timestamp 18 the block time shown in FIG 1) and the times recorded in the signed time certificates received from the first and second time servers 920, 930.

[0090] As shown in the figure, the first participating neighbor blockchain 300 generated a block 340 at some point in time after the generation of block 240 by the main blockchain 200. The block 340 can be sent 341 to the main blockchain 200. The received block 340 is transmitted 910 to the module of the chronological verification process 900 compliance. The chronological matching process 900 may send 924, 934 requests to the first and second time servers 920, 930 as described above. If the difference between the block timestamp for block 340 (similar to the block timestamp 18 shown in FIG. 1) and the signed time certificates received from the time servers 920, 930 meets the deviation limit according to the blockchain protocol, 342 will be generated in the event log 280 event record 344 containing data associated with block 340. Event record 344 may include sequence identifier 346 for event record 344, event identifier 348 indicating the logical owner of event record 344 for block 340, block timestamp 349 for block 340 and time values 954, 964 received from time servers 920, 930 in response to the request associated with block 340.

[0091] As directed, the second participating neighbor blockchain 400 generated a block 440 at some point in time after the generation of block 240 by the main blockchain 200. The block 440 may be sent 440 to the main blockchain 200. The received block 440 is passed 910 to a module of the chronological matching process 900. The chronological matching process 900 may send 926, 936 requests to the first and second time servers 920, 930 as described above. If the difference between the block timestamp for block 440 (similar to the block timestamp 18 shown in FIG. 1) and the signed time certificates received from the time servers 920, 930 meets the deviation limit according to the blockchain protocol, 442 will be generated in the event log 280 event record 444 containing data associated with block 440. Event record 444 may include sequence identifier 446 for event record 444, event identifier 448 indicating the logical owner of event record 444 for block 340, block timestamp 449 for block 440 and time values 956, 966 received from time servers 920, 930 in response to the query associated with block 440.

[0092] FIG. 7 is a block diagram of a vector clock 800 of a blockchain network containing three participating blockchains (not shown), similar to blockchain network 100 and participating blockchains 200, 300, 400 shown in FIG. 2, with vector clock 800 containing event logs 801, 811, 821, in accordance with an embodiment of the present disclosure. The event logs 801, 811, 821 are provided by way of example only and not by way of limitation, and may additionally be the event logs of the participating blockchains 200, 300, 400 of the blockchain network 100 shown in FIG. 2. The event log 801 may be the event log 280 shown in FIG. 5-6, which may be similar to the main blockchain 200 event log shown in FIG. 2. Similarly, the event logs 811 and 821 may be similar to the event logs of the first and second participating neighboring blockchains 300, 400 depicted in FIG. 2, 5-6, respectively. At least part of the communication described in connection with FIG. 7 may occur on the same network as shown in FIG. 2, 5, which may be a multiplex network.

[0093] As an example, as shown in FIG. 7, the first blockchain associated with the event log 801 may be the first blockchain for triggering and creating a trigger event record 802 in the event log 801. The first block may be generated and an event record 803 may be created. For the present example, in this example, the second blockchain is similar to the first participating neighbor blockchain shown in FIG. 2 may be triggered after the specified blockchain according to the event log 801 and may be associated with the event log 811. The event log 811 may contain an event record 812 representing the initiation of the event log 811 (and its associated blockchain). An event record 812 of the event log 811 can be transmitted 827 and inserted into the event log 801 . The first blockchain block associated with the event log 811 may be generated and an event record 813 may be created. An event record 813 may be transmitted 828 and inserted into the event log 801 . The event records of the first event log 811, for example up to now, may include the trigger event record 802 for the first blockchain, the first block creation event record 803 for the first blockchain, the trigger event record (812) of the second blockchain, and the first block (813) of the second blockchain. Event records may be stored in the event log 801 in the order in which they occur and regardless of time.

[0094] The third blockchain for the purposes of this example is similar to the second participating neighbor blockchain depicted in FIG. 2 may trigger and generate a trigger event entry 821 in the event log 822 . A trigger event record 822 may be transmitted 834 and inserted into the event log 801 . The third blockchain may generate the first block and record 823 of the first block creation event. A record 823 of the first block creation event may be transmitted 836 and inserted into the event log 801 .

[0095] At the point described so far, the event log 811 of the second blockchain only contains an initiation event record 812 and a first block creation event record 813; and the event log 821 of the third blockchain contains only a trigger event record 822 and a first block creation event record 823. At some point after the event log 811 is triggered, the added point 830 in the event log 811 may be reached. The added point 830 may represent an event log 811 query sent to the event log 801 for all event entries in the event log 801 prior to the event log 801 receiving the entry 812 about the triggering event of the event log 811 . Any event records, such as the trigger event record 802 and the create event record of the first block of the event log 801, can be inserted 832 into the event log 811 to include the event records 802, 803 in the order in the event log 811 in which they occur. were entered in the event log 801, and taking into account all event records created before the added point 830. In other words, after the actions associated with the added point 830, the event log 811 may contain (in order) an entry 802 about the triggering event and an entry 803 about the creation event of the first block of the event log 801, as well as the entry 812 about the triggering event and the entry 813 about the creation event of the first block of the event log 811.

[0096] Similarly, the event log 821 may reach the added point 840. The event log 821 may request and receive all event records contained in the event log 801, and may insert 842 event records received from the event log 801 such that the log 821 events may contain a sequence of all event log entries starting with an initial event entry 802 from the event log 801, in the order in which the events represented by the event entries 802, 803, 804, 812, 813, 822, 823 occurred .

[0097] Since each blockchain in the blockchain network creates a new block, any subsequent block event record can be written to the event log of the associated blockchain and can be transferred to the event logs of other blockchains in the blockchain network. As a non-limiting example, any subsequent block event record 804 may be written to the event log 801 at the time the associated blockchain creates the first subsequent block. The event record 804 can then be passed 850 to the event log 811 . In the present example, the event record 804 may be submitted to the event log 821 at the time the event log 821 reaches the added point 840. The event log 821 may create a subsequent block event record 823 and pass the event record 823 836 to the event log 801. The event record 823 may also be passed 852 to the event log 811 .

[0098] As the blockchain associated with the event log 801 creates new subsequent blocks, new subsequent block event entries 805, 806, 807 (and so on ad infinitum) are created in the event log 801 in the order they were created. These event records 805, 806, 807 are passed 855, 861, 867 to the event log 811 and passed 856, 862, 868 to the event log 821 for inclusion in each event log 811, 821 in the order in which they occurred. Similarly, the event log 811 creates new subsequent block event entries 814, 815, 816 (and so on ad infinitum) and passes 853, 859, 865 each of these event entries 814, 815, 816 to the event log 801 for inclusion in the log. 801 events in the order in which the various events from both event logs 801, 811 occurred. Events 814, 815, 816 are also transmitted (shown herein as events 854, 860, 866 transmitted) from the event log 801 to the event log 821 for inclusion in the event log 821 in the order in which each of the various events from the logs 801 occurred. , 811, 821 events. Event log 821 also creates new subsequent block event records 824, 825, 826 corresponding to subsequent new blockchain blocks associated with event log 821, and passes 857, 863, 869 event records 824, 825, 826 to event log 801. Event records 824, 825, 826 are also transferred (shown in FIG. 7 as transferred 858, 864, 870 by the event log 801) to the event log 811. Each post-creation event record 805..., 815..., 824... is transmitted in such a way that each event log 801, 811, 821 can contain a comprehensive sequence of all block event records created by all blockchains in the blockchain network.

[0099] FIG. 8 is a detailed view of a portion of the vector clock 800 of FIG. 7. A portion of the event logs 801, 811, 821 is shown, corresponding to an event entry 806 (event log 801), an event entry 815 (event log 811), and an event entry 826 (event log 821). FIG. 7, for ease of illustration, the transfer of the event record 815 is shown as a transition from the event log 811 to the event log 801 and from the event log 801 to the event log 821. Similarly, the event record 825 of the event log 821 is shown as being transferred from the event log 821 to the event log 801 and from the event log 801 to the event log 811. In addition, multi-stage transmission occurs from one event log to the second event log and from the second event log to the third event log, with each event log 801, 811, 821 being able to transfer directly to each other event log 801, 811, 821. FIG. 8, the event record 815 from the event log 811 is transferred 859 from the event log 811 to the event log 801, is transferred 860 from the event log 801 to the event log 821, and is also transferred 880 from the event log 811 to the event log 821. Moreover, when the event log 821 has received (via 880) an event record 815 from the event log 811, the event log 821 may transfer 881 the event record 815 to the event log 801.

[00100] The event record 806 from the event log 801 is transferred 861 from the event log 801 to the event log 811, is transferred 862 from the event log 801 to the event log 821, is transferred 882 from the event log 811 to the event log 821, and is also transferred 883 from the log 821 events in the 811 event log. By passing every event record from every event log to every other event log, every event log will be able to log every event record for every event occurring on every blockchain participating in the blockchain network. Moreover, by passing any event entry from one event log to each other event log, each event entry can be allowed to be entered into each event log even if the network fails. For example, event log 821 may attempt to send 863 and 884 events 825, respectively, to event log 801 and event log 811. It is shown that the event record 825 was successfully transferred 884 to the event log 811; however, due to a network failure 886, an error occurred in sending 863 the event record 825 to the event log 801 . Since the event log 811 passes all event records from the event log 811 to the event log 801, the event record 825 from the event log 811 can be transferred 888 to the event log 801 despite a network failure 886 between the event log 821 and the event log 801.

[00101] Since every event record from every event log is passed to every other event log by every event log of every blockchain participating in the blockchain network, an immutable block creation record is created for all participating blockchains. As shown in the figure, the event record 825 reached every event log 801, 811, 821 even though the network 886 failed between the event logs 801, 811. Such multi-stage transfer (or multi-sourcing) of event records may also serve to prevent or detect mis-ordered event records. Each event log, in addition to receiving individual event records from each other event log, can compare the order of events independently or by periodically exchanging to partially or completely compare the list of events contained in the event log. In other words, the computer process creating each event log 801, 811, 821 may occasionally exchange a portion of the event log 801, 811, 821 created in connection with each particular blockchain in the blockchain network. Each computer process that creates an event log 801, 811, 821 can compare the received event log with the event log of a specific associated blockchain. If the computer process generating the event log 801, 811, 821 detects in the received event log an event entry entered in the received event log at an earlier position than currently reflected in the computer process's own event log, that computer process may modify own event log to account for the position of this event in the previous order.

[0100] As an example, network failure 886 of FIG. 8, instead of preventing the event record 825 from being sent 863 to the event log 801, it simply introduces a delay, i.e., the event record 825 is entered into the event log 801 after another block event record (e.g., a new subsequent block 816 of the event log 811 transmitted 865 to the event log 801 of FIG. 7). Thus, the event log 801 may reflect a partial order of events (as shown in FIG. 7) as 815 (block B03), 806 (block A04), 816 (block B04), and 825 (block C03). When the event log computer process 801 receives the event logs 811, 821, the event log computer process 801 may determine the order of those particular events in the event logs 811, 821 as 815, 806, 825, 816 and may modify the event log 801 to reflect itself. early position of event 825 in that order. Similarly, if in each event log 801, 811, 821 event 825 is in some different order position, by exchanging and comparing event logs 801, 811, 821, each event log 801, 811, 821 will be able to set event 825 to the earliest position in the order sequence. Thus, each event log 801, 811, 821 may reflect the earliest (in order of occurrence) point at which each block of each associated blockchain was first created. In other words, thanks to the vector clock 800, each event log 801, 811, 821 can keep a permanent record of the block creation order of each block in each blockchain participating in the blockchain network in the block creation order. The immutable order of the vector clock increases the degree of immutability of each block, achieved through mutually-merged mining in the process of cross-merklization.

[0101] Each event record may further contain a usable element. The usable element may be an actual physical action to be performed, or a computer-executable logical function, or both. In other words, a specific event record may refer to a related block of one of the blockchains in the blockchain network and may contain data, the acceptance of which by one of the computing systems using any blockchain from the blockchain network, may indicate the possibility of performing a physical process or action in the subject , by or under the control of an entity of the receiving computing system and/or application to perform a logical process or function on the receiving computing system (or component of the receiving computing system). As a non-limiting example, and in accordance with FIG. 7-8, a computer system employing the event log 801 may create, in addition to block A04 (shown in event entry 806), an event entry 806 . The event record 806 may contain, in addition to a reference to block A04 of the blockchain associated with the event log 801 (such as the main blockchain 200 of FIG. a command executed by an entity using the event log computer system 821 to transfer payment to an entity using the event log computer system 811 after receiving an event record (e.g., event record 816 of FIG. 7) from the event log computer system 811 confirming, that the shipment has been shipped.

[00102] FIG. 9 is a diagram of a computing system 1000 providing immutable records in accordance with one embodiment of the present disclosure. The computing system 1000 may include one or more processors 1002, a storage device 1004, a network interface 1006, a blockchain 1010, a vector clock vector 1020, an event log 1022, and a chronological matching process 1030. Computing system 1000 may be similar to computing system 1 shown in FIG. 1 and 6 and described above.

[00103] Vector 1020 may provide event logging in event log 1022 and may provide functionality to receive other event logs from other computing systems implementing different blockchains and then compare event log 1022 with other event logs.

[0102] It should be understood that other configurations of computing devices are possible, including distributed computing systems containing a plurality of processors and/or storage devices distributed and interconnected via a data communication network.

[0103] Implementation examples

[0104] The following are some examples of implementation within the scope of the description. To avoid difficulties in providing a description, not all of the examples listed below are described separately and expressly as being contemplated herein and as being combinable with all of the other examples listed below and other embodiments described above herein. Unless it is clear to one skilled in the art that the examples listed below (and the embodiments described above) cannot be combined, it is intended within the scope of the description that such examples and embodiments can be combined.

[0105] Example 1. The main computing system providing the registration of immutable records (and / or the order of events, and / or the provable order of events), containing: one or more machine-readable storage media for storing the main blockchain for storing record data in the main set of blocks that related to each other chronologically, the most recent block from the main series of blocks, including a cryptographic hash (for example, the block digest of the block of the latest block, a random code for the cryptographic hash of the most recent block, a cryptographic hash of the previous block in order, a random code for the cryptographic hash of the previous in block order, the target complexity for the cryptographic hash, the timestamp and data portion of the records; one or more processors in electrical communication with one or more machine-readable storage media and configured to create the main blockchain or other implementation of the main blockchain protocol, one or more processors for: creating a new block of the main row of blocks for storing new record data, the new block being associated with the most recent block by including a cryptographic hash (eg, block digest) of the most recent block; and optionally a random code for the cryptographic hash of the latest block, a target difficulty for the cryptographic hash of the latest block, and a timestamp, the new block becomes the new most recent block of the main block row; generating a new cryptographic hash (eg, a new block digest) of a new block from the main row of blocks with the new random code and negotiating a difficulty target for the new block's cryptographic hash; saving a new cryptographic hash and a new random code in a new block; and transmitting to the first neighboring computing system over the data network through the network interface a new cryptographic hash of the new block and a new random code for the cryptographic hash of the new block for cross-merclization of the main blockchain with the first participating neighboring blockchain on the first neighboring computing system.

[0106] Example 2. The system of example 1, in which the cryptographic hash of each block of the main blockchain is created using a one-way secure hashing algorithm.

[0107] Example 3. The system of Example 1, in which the cryptographic hash contains a binary hash tree, in which the cryptographic hash is obtained by concatenation with a random code to form an input string for a one-way cryptographic function whose output corresponds to the target complexity that contains the rule A that specifies a compatible cryptographic hash.

[0108] Example 4. The system of example 3, in which the rule points to a specific set of one or more binary values at given positions of a compatible cryptographic hash.

[0109] Example 5. The system of Example 1, wherein one or more processors are further configured to receive a cryptographic hash, a corresponding random code, and a set of cryptographic hashes of the most recent block from the first adjacent row of blocks from the first neighboring computing system.

[0110] Example 6. The system of example 5, in which the cryptographic hash of each block from the first participating neighbor blockchain is created using a one-way secure hashing algorithm.

[0111] Example 7. The system of Example 5, wherein the set of cryptographic hashes contains at least one cryptographic hash from the most recent block of the main blockchain.

[0112] Example 8. The system of Example 5, wherein the set of cryptographic hashes contains at least one cryptographic hash from the most recent block from the second participating neighbor blockchain.

[0113] Example 9. The system of Example 5, in which one or more processors additionally serve to create the next block of the main series of blocks, and the next block is associated with the new most recent block by including a new cryptographic hash (new most recent block) and a new random code (for the cryptographic hash of the new most recent block), the next block also includes the cryptographic hash (and the corresponding random code) of the most recent block from the first neighboring row of blocks (the first participating neighboring blockchain implemented on the first neighboring computing system).

[0114] Example 10. The system of Example 5, wherein one or more processors further stores a main event log including an ordered list of event records, each corresponding to a transaction record from the record data stored in the main row of blocks main blockchain.

[0115] Example 11. The system of example 10, in which one or more processors are further configured to: register in the main event log an event entry indicating the creation of a new block; and registering in the main event log an event entry corresponding to the most recent block of the first neighboring block row of the first participating neighboring blockchain after receiving the cryptographic hash and the corresponding random code of the latest block from the first neighboring block row of the first participating neighboring blockchain.

[0116] Example 12. The system of example 10, in which one or more processors are additionally configured to: identify a transaction record from these records as corresponding to an event; and registering in the main event log an entry about an event corresponding to this event.

[0117] Example 13. The system of example 1, in which one or more computer-readable storage media additionally stores the main event log, including an ordered list of event records, each of which corresponds to any transaction record included in the data records of the main blockchain, and one or more processors are additionally configured to register in the main event log an event record indicating the creation of a new block.

[0118] Example 14. The system of example 13, in which one or more processors are further configured to: receive (for example, from the first neighboring computing system over a data network via a network interface) at least a portion of the first neighboring event log; comparing the main event log with the first adjacent event log; and ensuring that the earliest occurrence of each block is reflected in the main event log based on the comparison.

[0119] Example 15. The system of example 14, in which one or more processors are further configured to: reorder event entries in the main event log based on a comparison and/or based on an earlier entry in one of the main event log and adjacent log events for each event entry.

[0120] Example 16. The system of Example 1, in which the first neighboring computing system is in electronic communication with the system and implements the first participating neighboring blockchain containing the first neighboring row of blocks that are connected to each other chronologically, the most recent block from the first neighboring row blocks includes a cryptographic hash (e.g., a block digest) of the most recent block, a random code for the cryptographic hash of the most recent block and a cryptographic hash of the previous block in order, a random code for the cryptographic hash of the block preceding in order from the first neighboring row of blocks (and optionally code for the cryptographic hash of the previous block in order from the first adjacent row of blocks).

[0121] Example 17. The system of Example 16, wherein the latest block from the first adjacent block row further includes a cryptographic hash of the latest block from the first main block row and a random code for the cryptographic hash of the latest block from the first main block row for cross-merklization of the main blockchain with the first participating neighboring blockchain.

[0122] Example 18. The system of example 1, in which one or more processors are additionally configured to transmit to a second neighboring computing system (for example, over a data network via a network interface) a new cryptographic hash (new block) and a new random code ( for the cryptographic hash of the new block) to cross-merklize the main blockchain with the second participating neighboring blockchain on the second neighboring computing system.

[0123] Example 19. The system of Example 18, in which one or more processors are further configured to receive from the second neighboring computing system a cryptographic hash, a corresponding random code, and a set of cryptographic hashes of the most recent block from the second neighboring row of blocks of the second participating neighboring blockchain, implemented on the second neighboring computing system.

[0124] Example 20. The system of example 1, in which the record data contains a plurality of transaction records.

[0125] Example 21. A distributed electronic record system providing immutable record logging (which can provide an immutable record of the order of events and/or can provide a provable order of events), comprising: a main computing system on which the main blockchain is implemented, for storage data records in the main row of blocks that are related to each other chronologically, and the most recent block from the main row of blocks includes a cryptographic hash (for example, a block digest) of the most recent block from the main row of blocks, a random code for the cryptographic hash of the most recent block from the main a block row, a cryptographic hash of the previous block in order of the main block row, a random code for the cryptographic hash of the previous block in order of the main block row (and optionally a random code for the cryptographic hash of the previous block in order of the main block row), and a part of the record data; a first neighboring computing system in electronic communication with the main computing system over a data network, wherein the first neighboring computing system implements a first participating neighboring blockchain containing a first neighboring row of blocks that are chronologically related to each other, the most recent block from the first neighboring row blocks includes the cryptographic hash of the most recent block from the first adjacent row of blocks, the random code for the cryptographic hash of the most recent block from the first adjacent row of blocks, the cryptographic hash of the previous block in order from the first adjacent row of blocks (and optionally the random code for the cryptographic hash of the previous block row) block order from the first adjacent row of blocks), wherein the main computing system is configured to: create a new block of the main row of blocks for storing new record data, and the new block is associated with the most recent block of the main row of blocks by including a cryptographic hash (e.g., a block digest) of the most recent block in the main block row (and optionally a random code for the cryptographic hash of the most recent block in the main block row), the new block becomes the new most recent block of the main block row; generating a new cryptographic hash (e.g., a new proof-of-work digest) of a new block from the main row of blocks using a new random code (and negotiating a difficulty target for the new block's cryptographic hash), a new cryptographic hash, and a new random code stored in the new block; and transmitting to the first neighboring computing system (for example, over a data network via a network interface) a new cryptographic hash of the new block and a new random code for the cryptographic hash of the new block to cross merklize the main blockchain with the first participating neighboring blockchain.

[0126] Example 22 The system of Example 21, wherein the cryptographic hash of each block of the main blockchain is generated using a one-way secure hash algorithm, and wherein the cryptographic hash of each block from the first participating neighbor blockchain is generated using a one-way secure hash algorithm.

[0127] Example 23 The system of Example 21, wherein the latest block from the first adjacent block row further includes a cryptographic hash of the latest block from the main block row and a random code for the cryptographic hash of the latest block from the first main block row.

[0128] Example 24 The system of Example 21, wherein the latest block in the main block row further includes a cryptographic hash of the latest block in the first neighboring block row and a random code for the cryptographic hash of the latest block in the first neighboring block row.

[0129] Example 25. The system of Example 21, wherein the first neighbor computing system is further configured to transmit to the main computing system a cryptographic hash and the corresponding random code of the most recent block from the first neighboring row of blocks from the first participating neighboring blockchain implemented on the first neighboring computing system.

[0130] Example 26. The system of Example 21, wherein the main computing system is further configured to receive from the first neighbor computing system a cryptographic hash and the corresponding random code of the most recent block from the first neighboring row of blocks from the first participating neighbor blockchain implemented on the first neighboring computing system.

[0131] Example 27. The system of Example 21, wherein the first neighbor computing system is configured to: create a new neighbor block from a first neighbor row of blocks, wherein the new neighbor block is associated with the most recent block of the first neighbor row of blocks by including a cryptographic hash of the most recent a block from the first adjacent row of blocks (and a random code for the cryptographic hash of the most recent block from the first adjacent row of blocks), with the new block becoming the new most recent block of the main row of blocks; creating a new cryptographic hash of the new block from the first adjacent row of blocks with the new random code and negotiating a target complexity for the cryptographic hash of the new block, the new cryptographic hash, and the new random code stored in the new adjacent block; and transmitting to the main computing system (eg, over a data network via a network interface) the new cryptographic hash of the new neighbor block and the new random code for the cryptographic hash of the new neighbor block to cross merklize the first participating neighbor blockchain with the main blockchain. The first neighboring computing system can additionally store in the new neighboring block a new cryptographic hash of the new block of the main row of blocks and a new random code for the cryptographic hash of the new block of the main row of blocks for cross-merclization of the main blockchain with the first participating neighboring blockchain on the first neighboring computing system.

[0132] Example 28. The system of Example 21, further comprising: a second neighbor computing system in electronic communication with the main computing system and/or the first neighbor computing system over a data network, the second neighbor computing system implementing the second participating neighbor blockchain, containing a second adjacent row of blocks that are chronologically related to each other, while the most recent block of the second adjacent row of blocks includes a cryptographic hash of the latest block from the second adjacent row of blocks, a random code for the cryptographic hash of the latest block from the second adjacent row of blocks, a cryptographic hash of the previous block in order from the second adjacent row of blocks (and optionally a random code for the cryptographic hash of the previous block in order from the second adjacent row of blocks), and the main computing system is additionally configured to be transmitted to the second neighboring computing a separate system (for example, over a data network via a network interface) of a new cryptographic hash of the new block and a new random code for the cryptographic hash of the new block for cross-merclization of the main blockchain with the second participating neighboring blockchain.

[0133] Example 29. The system of Example 28, in which the first neighboring computing system is further configured to transmit to the second neighboring computing system a cryptographic hash and the corresponding random code of the most recent block from the first neighboring row of blocks from the first participating neighboring blockchain implemented on the first neighboring computer system.

[0134] Example 30. The system of Example 28, wherein the main computing system is further configured to receive from the second neighboring computing system a cryptographic hash and the corresponding random code of the most recent block from the second neighboring row of blocks from the second participating neighboring blockchain implemented on the second neighboring computing system.

[0135] Example 31. The system of Example 28, wherein the second neighbor computing system is further configured to receive from the host computing system a cryptographic hash and the corresponding random code of the most recent block from the main row of blocks from the first participating neighbor blockchain implemented on the host computing system , and in which the second neighboring computing system is further configured to receive from the first neighboring computing system a cryptographic hash and a corresponding random code of the most recent block from the first neighboring row of blocks from the first participating neighboring blockchain implemented on the first neighboring computing system.

[0136] Example 32. A method for providing immutable records (e.g., transaction records) (and/or an immutable order of events and/or provable order of events) record, including: creating or otherwise implementing a main blockchain on a main computing system , and the main blockchain is configured to store transaction records in the main series of blocks that are stored on one or more machine-readable storage media of the main computing system and which are linked to each other chronologically, and the most recent block from the main series of blocks includes a cryptographic hash ( for example, a proof-of-work (POW) digest of the most recent block, a random code for the cryptographic hash of the most recent block, a cryptographic hash of the previous block in sequence, and a portion of the transaction records; creation of a new block of the main block row to hold new transaction records, the new block being associated with the most recent block by including a cryptographic hash (e.g., a block digest) of the most recent block (and optionally a random code for the cryptographic hash of the most recent block), wherein the new the block becomes the new most recent block of the main row of blocks; generating a new cryptographic hash (eg, a new POW digest) of a new block from the main row of blocks with a new random code (and negotiating a difficulty target for the new block's cryptographic hash); saving a new cryptographic hash and a new random code in a new block; and transmitting to the first neighboring computing system (e.g., over a data network via a network interface) a new cryptographic hash of the new block and a new random code for the cryptographic hash of the new block to cross merklize the main blockchain with the first participating neighboring blockchain on the first neighboring computing system.

[0137] Example 33. A system (e.g., a host computer system) that maintains immutable records (e.g., a transaction and/or order of events record) or otherwise maintains a provable order of events, comprising: one or more machine-readable storage media the main blockchain to store transaction records in the main series of blocks that are related to each other chronologically, with the most recent block of the main series of blocks including a proof-of-work (POW) digest (which is a cryptographically hashed block digest of the most recent block ), with a random code to achieve (match) the target complexity, the block digest of the previous block in order, and a part of the transaction records; one or more processors in electrical communication with one or more machine-readable storage media and configured to implement the main blockchain protocol, wherein one or more processors are configured to: create a new block of the main row of blocks to store new transaction records, and the new the block is linked to the most recent block by including a cryptographic hash (eg, a block digest) of the most recent block, with the new block becoming the new most recent block of the main row of blocks; creating a digest of records (eg, the root of a Merkle tree) from the new transaction records by cryptographically hashing the new transaction records; generating a block digest of the new block by cryptographically hashing the entry digest with the new random code; generating a new POW digest of the new block by cryptographically hashing the new block's block digest with the new random code to achieve (or otherwise match) the target difficulty; storing the new POW digest, the new random code, and the new block record digest in the new block; and transmitting to the first neighboring computing system (for example, over a data network via a network interface) a header of the new block, the header including the new POW digest of the new block, the new random code, and the record digest for cross-merklization of the main blockchain with the first participating neighbor blockchain on the first neighboring computing system.

[0138] Example 34. The system of Example 33, wherein the one or more processors are further configured to receive from a first neighbor computing system (e.g., over a data network via a network interface) a header of the most recent first neighbor block from a first participating neighbor blockchain in the first neighbor computing system, wherein the header contains a POW digest of the latest first neighbor block from the first participating neighbor blockchain in the first neighbor computing system, a random code of the most recent first neighbor block, and a digest of the records of the latest first neighbor block for cross merklization of the first participating neighbor blockchain with the main blockchain.

[0139] Example 35. The system of Example 34, wherein one or more processors are further configured to create the next block of the main block row, with the next block associated with the new most recent block by including a new POW digest of the new block, a new random code, and a digest records, the POW digest of the latest first neighbor block, the random code of the latest first neighbor block, and the record digest of the latest first neighbor block.

[0140] Example 36. The system of Example 33, wherein one or more processors are configured to maintain (e.g., on a computer-readable storage medium) a master event log including an ordered list of event records, each corresponding to a transaction record from transaction records stored in the main row of blocks of the main blockchain.

[0141] Example 37. The system of Example 36, wherein one or more processors are further configured to log an event entry in the main event log indicating the creation of a new block.

[0142] Example 38. The system of example 36, in which one or more processors are further configured to: receive from the first neighboring computing system (eg, over a data network via a network interface) at least a portion of the first neighboring event log; comparing the main event log with the first adjacent event log; and ensuring that the earliest occurrence of each event entry (eg, a new block creation event entry) is reflected in the main event log based on the comparison.

[0143] Example 39. The system of Example 38, wherein one or more processors are further configured to: reorder event entries in the main event log based on a comparison and/or based on an earlier entry in one of the main event log and adjacent log events for each event entry.

[0144] Example 40. A method for ensuring the registration of immutable records (for example, a record of a transaction and / or an order of events) or otherwise providing a provable order of events, including: creating or otherwise implementing (protocol) the main blockchain on the main computing system, moreover, the main blockchain is configured to store transaction records in the main series of blocks that are stored on one or more machine-readable storage media of the main computing system and which are related to each other chronologically, and the most recent block from the main series of blocks includes a digest with proof of execution work (POW) (which is a cryptographically hashed block digest of the most recent block), with a random code to achieve (or otherwise match) the target complexity, the block digest of the block of the previous block in order, and part of the transaction records; creating a new block of the main block row to store new transaction records, the new block being associated with the most recent block by including a cryptographic hash (e.g., a block digest) of the most recent block, the new block becoming the new most recent block of the main block series; creating a new record digest (Merkle tree root) from the new transaction records by cryptographic hashing of the new transaction records; generating a new block digest of the new block by cryptographically hashing the new record digest with the new random code; generating a new POW digest of the new block by cryptographically hashing the new block's block digest with the new random code to achieve (or otherwise match) the target difficulty; saving a new POW digest, a new random code, and a new record digest in a new block; and transmitting to the first neighbor computing system (e.g., over a data network via a network interface) a header of the new block, the header including the new POW digest of the new block, the new random code, and the new record digest to cross-merklize the main blockchain with the first participating neighbor blockchain. on the first neighboring computing system.

[0145] Example 41. A distributed electronic record system providing immutable record logging and comprising: a main blockchain for storing record data in a main set of blocks that are chronologically related to each other, the most recent block of the main set of blocks including a cryptographic hash of itself the last block, a random code for the cryptographic hash of the most recent block, the cryptographic hash of the previous block in order, and a part of the record data; the first participating neighboring blockchain containing the first neighboring row of blocks that are chronologically related to each other, and the most recent block from the first neighboring row of blocks includes the cryptographic hash of the most recent block from the first neighboring row of blocks, a random code for the cryptographic hash of the most recent block from of the first neighboring row of blocks and a cryptographic hash of the previous block in order from the first neighboring row of blocks, while the main blockchain is configured to: create a new block of the main row of blocks to store new record data, and the new block is associated with the most recent block of the main row of blocks by including a cryptographic hash of the latest block from the main block row, whereby the new block becomes the new most recent block of the main block row; creating a new cryptographic hash of the new block of the main series of blocks using the new random code, the new cryptographic hash, and the new random code stored in the new block; and transmitting to the first participating neighboring blockchain a new cryptographic hash and a new random code.

[0146] Example 42. A system providing immutable record logging, comprising: a main blockchain for storing transaction records in a main set of blocks that are related to each other chronologically, and the most recent block of the main set of blocks includes a digest confirming the completion of work (POW), block digest of the previous block in order and part of the transaction records; the first participating neighbor chain containing the first neighboring row of blocks that are chronologically related to each other, with the most recent block from the first neighboring row of blocks including a proof-of-work (POW) digest, the most recent block from the first neighboring row of blocks, and a block digest the block preceding in order from the first adjacent row of blocks; wherein the main blockchain is configured to: create a new block of the main block series to store new transaction records, the new block being associated with the most recent block by including a block digest of the latest block, the new block becoming the new most recent block of the main block series; creating a digest of records (the root of the Merkle tree) from new transaction records; generating a new POW digest of the new block by cryptographically hashing the block digest of the new block with the new random code; storing the new POW digest, the new random code, and the new block record digest in the new block; and transmitting the new POW digest, the new random code, and the record digest to the first participating neighbor blockchain.

[0147] Example 43. The system of Example 41, wherein the main blockchain is further configured to receive from the first participating neighbor blockchain a POW digest of the most recent first neighbor block from the first participating neighbor blockchain, a random code of the latest first neighbor block, and a digest of the records of the most recent first adjacent block.

[0148] Example 44. The system of Example 43, in which the main blockchain is further configured to create the next block of the main series of blocks, and the next block is associated with the new most recent block by including the block digest of the new block, the new random code of the new block, and the digest of records of the new block, wherein the new block includes the POW digest of the latest first neighbor block and the record digest of the latest first neighbor block.

[0149] Example 45. The system of Example 41, further comprising a vector clock comprising: a main event log including an ordered list of event records, each corresponding to a transaction record from transaction records stored in the main row of blocks of the main blockchain; and a first participating neighbor event log including an ordered list of event records, each corresponding to a transaction record from the transaction records stored in the first neighbor row of blocks of the first participating neighbor blockchain, the vector clock comparing the main event log with the first adjacent event log and ensure that the main event log reflects the earliest occurrence of each event entry.

[0150] Example 46. The system of Example 45, wherein the vector clock is configured to reorder event entries in the main event log based on comparison.

[0151] Example 47. The system of Example 45, wherein one or more processors are further configured to log (eg, in the main event log) an event entry indicating the creation of a new block.

[0152] Example 48. A system that provides immutable record keeping to ensure a provable order of events, comprising: a main blockchain (in the main computing system) for storing transaction records in a main set of blocks that are related to each other chronologically, with the most recent block of the main row of blocks includes a proof-of-work (POW) digest, a block digest of the previous block in order, and a portion of the transaction records; a main event log (in the main computing system) including an ordered list of event records, each corresponding to a transaction record from the transaction records stored in the main row of blocks of the main blockchain; the first participating neighbor blockchain (on the first participating neighbor computing system) containing the first neighboring row of blocks that are related to each other chronologically, where the most recent block from the first neighboring row of blocks includes a proof-of-work (POW) digest of the most recent block from the first adjacent row of blocks and the block digest of the previous block in order from the first adjacent row of blocks; a first participating neighbor event log (on the first participating neighbor computing system) including an ordered list of event records, each corresponding to a transaction record from the transaction records stored in the first neighbor row of blocks of the first participating neighbor blockchain; and a vector clock, which is configured to compare the main event log with the first adjacent event log and ensure that the main event log reflects the earliest occurrence of each event record, while the main blockchain is configured to: create a new block of the main row of blocks to store new records about a transaction, wherein the new block is linked to the most recent block by including a block digest of the most recent block, the new block becoming the new most recent block of the main block row; creating a digest of records (the root of the Merkle tree) from new transaction records; generating a new POW digest of the new block by cryptographically hashing the block digest of the new block with the new random code; storing the new POW digest, the new random code, and the new block record digest in the new block; registration in the main event log of an event record corresponding to the creation of a new block; and transmitting the new POW digest, the new random code, and the record digest to the first participating neighbor blockchain.

[0153] Example 49. The main computing system, providing immutable record keeping to ensure a provable order of events, containing: one or more machine-readable storage media for storage: the main blockchain for storing transaction records in the main series of blocks that are related to each other chronologically, wherein the most recent block of the main series of blocks includes a proof-of-work (POW) digest (which is a cryptographically hashed block digest of the most recent block), with a random code to achieve (match) the target complexity, a digest of the block of the previous one in order block and part of transaction records; and a main event log containing an ordered list of event records, each corresponding to a transaction record from the transaction records stored in the main row of blocks of the main blockchain; and one or more processors in electrical communication with one or more computer-readable storage media and configured to implement the main blockchain protocol, wherein one or more processors are configured to: receive from the first neighboring computing system a POW digest of the latest block from the first neighboring row blocks of a first participating neighbor blockchain implemented in a first neighbor computing system, a corresponding random POW digest code of the most recent block from the first neighbor row of blocks, and a digest of the records of the latest block from the first neighbor row of blocks; creating a new block of the main block row to store new transaction records, including the POW digest of the most recent block from the first adjacent row of blocks, the corresponding random code of the POW digest of the most recent block from the first adjacent row of blocks, and the digest of the records of the latest block from the first adjacent row blocks, wherein the new block is linked to the most recent block by including a cryptographic hash (eg, block digest) of the most recent block, and the new block becomes the new most recent block of the main block row; creating a record digest (e.g. the root of a Merkle tree) from new transaction records by cryptographically hashing the new transaction records including the POW digest of the most recent block from the first neighboring block row, the corresponding random code of the POW digest of the most recent block from the first neighboring block row and a digest of the records of the most recent block from the first adjacent row of blocks; creating a block digest of a new block by cryptographic hashing…. digest records using a new random code; generating a new POW digest of the new block by cryptographically hashing the block digest of the new block with the new random code to achieve (match) the target complexity; storing the new POW digest, the new random code, and the new block record digest in the new block; registration in the main event log of an event record corresponding to the creation of a new block; comparing the main event log with the first adjacent event log and ensuring that the main event log reflects the earliest occurrence of each event entry, where the first adjacent event log includes an ordered list of event entries, each corresponding to a transaction entry from transaction records stored in a first neighbor row of blocks from a first participating neighbor blockchain implemented on a first neighbor computing system; and transmitting to the first neighbor computing system (e.g., over a data network via a network interface) the new POW digest of the new block, the new random code, and the record digest to cross-merklize the main blockchain with the first participating neighbor blockchain on the first neighbor computing system. The described features, operations, or characteristics may be arranged and designed in a wide range of different configurations and/or may be combined in any suitable manner in one or more embodiments. Thus, the detailed description of the various embodiments of systems and methods is not intended to limit the claimed scope of the description, and only serves to introduce possible embodiments of the description. In addition, it should be understood that the order of steps or actions in the methods described in connection with the described embodiments may be changed, as is obvious to experts in this field. Thus, any sequence in the drawings or in the detailed description is for illustrative purposes only and does not imply the required order unless otherwise indicated.

[0154] Embodiments may include various steps that may be included in computer-executable instructions for execution by a general-purpose or special-purpose computer (or other electronic device). In an alternative embodiment, these steps may be performed by hardware components that include specific logic to perform these steps, or by any combination of hardware, software, and/or firmware.

[0155] Embodiments may also be provided as a computer program product containing a computer-readable storage medium having instructions stored thereon that can be used to program a computer (or other electronic device) to perform the methods described herein. A computer-readable storage medium may include, without limitation: hard disks, floppy disks, optical disks, CD-ROMs, DVD-ROMs, ROMs, RAM, EPROMs, EEPROMs, magnetic or optical cards, mass storage devices, or other types of media/machine-readable media suitable for storing electronic commands.

[0156] As used herein, a program module or component may include any type of computer program or computer executable code located on a storage device and/or computer-readable storage medium. A software module may, for example, contain one or more physical or logical blocks of computer instructions, which may be organized as a subroutine, program, object, component, data structure, or the like, that perform one or more tasks or implement certain abstract types. data.

[0157] In certain embodiments, a particular software module may contain heterogeneous instructions stored in different areas of the storage device that collectively implement the described functionality of the module. In reality, a module may contain a single instruction or multiple instructions and may be distributed across several different code segments, between different programs, and across multiple storage devices. Some embodiments may be implemented in a distributed computing environment in which tasks are performed by a remote processing device that is linked through a data network. In a distributed computing environment, program modules may be located in local and/or remote storage devices for data storage. In addition, data linked to or concatenated with each other in a database entry may reside on the same storage device or on multiple storage devices and may be linked to each other over a network in the fields of the database entry.

[0158] The foregoing description has been made with reference to various embodiments, including the best embodiment. However, those skilled in the art will appreciate that various modifications and changes are possible without departing from the scope of the present description and the principles underlying the invention. Accordingly, the present description is to be considered illustrative and not restrictive, and all such modifications are intended to be included within its scope. In addition, the benefits, other advantages, and solutions to problems with bringing various embodiments are described above. However, benefits, benefits, solutions to problems, and any element(s) that may provide any benefits, advantages, or solutions or gain greater prominence should not be construed as a critical, mandatory, or essential feature or element.

[0159] In this document, the terms "comprises", "comprising", or any other variations thereof, presented herein, are used to denote a non-exclusive inclusion, i.e. a process, method, product or device, including a list of elements, consists not only of these elements, but may contain other elements not explicitly specified or inherent in such a process, method, product or device. In addition, as used herein, the terms "coupled", "coupling", or any other variation thereof provided herein, encompasses a physical connection, an electrical connection, a magnetic connection, an optical connection, a communication connection, a functional connection, and/or any other connection.

[0160] The inclusion in the claims of the term "first" in relation to any feature or element does not necessarily imply the presence of a second or additional such feature or element. The principles of the present disclosure may be reflected in a computer program product stored on a tangible computer-readable storage medium having computer-readable program code means stored on the storage medium. Any suitable computer-readable storage medium may be used, including magnetic storage devices (hard disks, floppy disks, etc.), optical storage devices (CD-ROMs, DVDs, Blu-Rays, etc.), flash memory, and/ or the like. These computer program instructions can be downloaded to a general purpose computer, special purpose computer, or other programmable data processing device to create a machine, such that the means for implementing the specified functions. These computer program instructions may also be stored on a computer-readable storage device, which may indicate to a computer or other programmable data processing device to perform certain actions, so that the instructions stored on the computer-readable storage device produce a finished product, including instructions for implementing the specified function. Computer program instructions may also be downloaded to a computer or other programmable processing device to cause a series of operating steps to be performed on the computer or other programmable device to create a computer-implemented process by which the steps are provided by the instructions executed on the computer or other programmable device. to implement these functions.

[0161] The principles of the present disclosure may be reflected in a computer program implemented as one or more program modules or components. As used herein, a software module or component (eg, handler, engine, system, subsystem) may include any type of computer program or computer executable code located on a storage device and/or computer-readable storage medium. A software module may, for example, contain one or more physical or logical blocks of computer instructions, which may be organized as a subroutine, program, object, component, data structure, or the like, that perform one or more tasks or implement certain types of data. .

[0162] In certain embodiments, a particular software module may contain heterogeneous instructions stored in different areas of the storage device that collectively implement the described functionality of the module. In reality, a module may contain a single instruction or multiple instructions and may be distributed across several different code segments, between different programs, and across multiple storage devices. Some embodiments may be implemented in a distributed computing environment in which tasks are performed by a remote processing device that is linked through a data network. In a distributed computing environment, program modules may be located in local and/or remote storage devices for data storage. In addition, data linked to or concatenated with each other in a database entry may reside on the same storage device or on multiple storage devices and may be linked to each other over a network in the fields of the database entry.

[0163] Suitable software to facilitate the implementation of the invention is readily provided by those skilled in the relevant art(s) using the ideas presented herein and programming languages and tools such as Java, Pascal, C++, C, database languages, API, SDK, host, firmware, microcode, and/or other languages and tools.

[0164] The embodiments described herein may be fully or partially implemented on a digital computer. The digital computer includes a processor that performs the necessary calculations. The computer further includes a storage device that is in electronic communication with the processor for storing the operating system of the computer. Computer operating systems may include, without limitation, MS-DOS, Windows, Linux, Unix, AIX, CLIX, QNX, OS/2, and Apple. In addition, future embodiments will presumably be adapted to run on other future operating systems.

[0165] In some instances, well-known features, structures, or operations are not shown or described in detail. Moreover, the described features, structures, or operations can be combined in any suitable manner in one or more embodiments. It should also be understood that the placement and construction of the components of the embodiments substantially described and shown in the drawings herein may have many different configurations.

[0166] Various operational steps, as well as components for performing operational steps, may be implemented in alternative ways, depending on the particular application or taking into account any number of cost functions associated with the operation of the system, for example, one or more stages can be removed, changed or combined with others. stages.

[0167] Although the principles of the present disclosure are shown in various embodiments, many modifications to the structure, structures, proportions, elements, materials, and components used in practice, which are specifically adapted to specific conditions and operating requirements, can be used, without departing from the principles and the scope of this description. The scope of the present description is intended to include all such modifications and variations.

[0168] Thus, the scope of the present invention should be determined only by the following claims.

Claims (65)

1. A system that provides registration of immutable records, containing: one or more machine-readable storage media for storing the main blockchain for storing data records in the main block row that are related to each other chronologically, and the most recent block of the main block row includes the cryptographic hash of the most recent block, a random code for the cryptographic hash of the most recent block, the cryptographic hash of the previous block in order and part of the record data; one or more processors in electrical communication with one or more computer-readable storage media and configured to implement the main blockchain, wherein one or more processors are configured to: creating a new block of the main block-row for storing new record data, the new block being associated with the most recent block by including a cryptographic hash of the latest block, the new block becoming the new most recent block of the main block-row; creating a new cryptographic hash of a new block using a new random code; saving a new cryptographic hash and a new random code in a new block; and transferring a new cryptographic hash and a new random code to the first neighboring computing system. 2. The system of claim 1, wherein the one or more processors are further configured to receive a cryptographic hash, a corresponding random code, and a set of cryptographic hashes of the most recent block from the first neighboring row of blocks from the first neighboring computing system. 3. The system of claim. 2, in which one or more processors are further configured to create the next block of the main series of blocks, and the next block is associated with the new most recent block by including a new cryptographic hash and a new random code, while the next block also includes into itself the cryptographic hash of the most recent block from the first adjacent row of blocks. 4. The system of claim 2, wherein the one or more processors are further configured to store a main event log including an ordered list of event records, each corresponding to a transaction record from the record data stored in the main row of main blocks. blockchain. 5. The system of claim 1, wherein the one or more computer-readable storage media is further configured to store a main event log including an ordered list of event records, each corresponding to a transaction record included in the main blockchain record data, wherein one or more processors are further configured to log an event entry in the main event log indicating the creation of a new block. 6. The system of claim 5, wherein the one or more processors are further configured to: receiving at least a portion of the first neighbor event log from the first neighbor computing system; comparing the main event log with the first adjacent event log; and ensuring that the earliest occurrence of each event entry in the main event log is reflected based on comparison. 7. The system of claim. 1, in which the first neighboring computing system is in electronic communication with the system and implements the first participating neighboring blockchain containing the first neighboring row of blocks that are related to each other chronologically, and the most recent block of the first neighboring row of blocks includes cryptographic hash of the most recent block, a random code for the cryptographic hash of the most recent block, and a cryptographic hash of the previous block in order from the first adjacent row of blocks. 8. The system of claim 1, wherein the one or more processors are further configured to transmit the new cryptographic hash and the new random code to the second adjacent computing system. 9. The system of claim 8, wherein the one or more processors are further configured to receive a cryptographic hash, a corresponding random code, and a set of cryptographic hashes of the most recent block from the second neighboring row of blocks of the second participating neighboring blockchain implemented on the second neighboring computing system, from the second neighboring computing system. 10. The system of claim 1, wherein the record data contains a plurality of transaction records. 11. A distributed electronic records system that ensures the registration of immutable records and contains: the main computing system on which the main blockchain is implemented, for storing record data in the main series of blocks that are related to each other chronologically, and the most recent block of the main series of blocks includes the cryptographic hash of the most recent block, a random code for the cryptographic hash of the most recent block, the cryptographic hash of the previous block in order and part of the record data; a first neighboring computing system that is in electronic communication with the main computing system over a data network, wherein the first neighboring computing system implements a first participating neighboring blockchain containing a first neighboring row of blocks that are chronologically related to each other, with the most recent block from the first adjacent row of blocks includes a cryptographic hash of the latest block from the first adjacent row of blocks, a random code for the cryptographic hash of the most recent block from the first adjacent row of blocks, and a cryptographic hash of the previous block in order from the first adjacent row of blocks, wherein the main computing system is configured to: creating a new block of the main block-row for storing new record data, the new block being associated with the most recent block of the main block-row by including a cryptographic hash of the latest block of the main block-row, the new block becoming the new most recent block of the main block-row; creating a new cryptographic hash of the new block of the main series of blocks using the new random code, the new cryptographic hash, and the new random code stored in the new block; and transferring a new cryptographic hash and a new random code to the first neighboring computing system. 12. The system of claim 11, wherein the most recent block of the first adjacent block row further includes a cryptographic hash of the most recent block of the main block row and a random code for the cryptographic hash of the most recent block of the first main block row. 13. The system of claim 11, wherein the most recent block of the main block row further includes a cryptographic hash of the most recent block of the first adjacent block row and a random code for the cryptographic hash of the most recent block of the first adjacent block row. 14. The system of claim 11, wherein the first neighbor computing system is further configured to transmit the cryptographic hash and the corresponding random code of the most recent block from the first neighboring row of blocks from the first participating neighbor blockchain implemented on the first neighboring computing system to the host computing system. . 15. The system according to claim 11, in which the first neighboring computing system is configured to: creating a new neighbor block from the first neighbor row of blocks, the new neighbor block being associated with the most recent block of the first neighbor row of blocks by including a cryptographic hash of the latest block from the first neighbor row of blocks, the new block becoming the new most recent block of the main row of blocks; generating a new cryptographic hash of the new block from the first adjacent row of blocks using the new random code, the new cryptographic hash, and the new random code stored in the new adjacent block; and transferring a new cryptographic hash and a new random code to the main computing system. 16. The system according to claim 11, further comprising: a second neighboring computing system that is in electronic communication with the main computing system and the first neighboring computing system over a data communication network, wherein the second neighboring computing system implements a second participating neighboring blockchain containing a second neighboring row of blocks that are chronologically related to each other, the most the last block from the second adjacent row of blocks includes the cryptographic hash of the most recent block from the second adjacent row of blocks, a random code for the cryptographic hash of the latest block from the second adjacent row of blocks, and the cryptographic hash of the previous block from the second adjacent row of blocks, wherein the main computing system is additionally configured to transmit the new cryptographic hash and the new random code to the second adjacent computing system. 17. A method for ensuring the registration of immutable records, including: implementation of the main blockchain on the main computing system, wherein the main blockchain is configured to store transaction records in the main row of blocks that are chronologically related to each other, and the most recent block from the main row of blocks includes a cryptographic hash of the most recent block, a random code for the cryptographic hash of the most recent block, the cryptographic hash of the previous block in order, and part of the transaction records; creating a new block of the main block row to store new transaction records, the new block being associated with the most recent block by including a cryptographic hash of the latest block, the new block becoming the new most recent block of the main block series; creating a new cryptographic hash of a new block using a new random code; saving a new cryptographic hash and a new random code in a new block; and transmission of a new cryptographic hash and a new random code to the first neighboring computing system. 18. The method of claim 17, further comprising: receiving a cryptographic hash, a corresponding random code, and a set of cryptographic hashes of the latest block from the first neighboring row of blocks from the first neighboring computing system. 19. The method of claim 18, further comprising: creating the next block of the main row of blocks, and the next block is associated with the new most recent block by including a new cryptographic hash and a new random code, while the next block also includes the cryptographic hash of the latest block from the first adjacent row of blocks. 20. The method of claim 17, further comprising: registering an event record indicating the creation of a new block in the main event log, the main event log including an ordered list of event records, each corresponding to a transaction record in the main blockchain. 21. A system that provides registration of immutable records, containing: one or more machine-readable storage media for storing the main blockchain for storing transaction records in the main series of blocks that are related to each other chronologically, and the most recent block of the main series of blocks includes a proof-of-work (POW) digest, a block digest of the previous in block order and part of transaction records; one or more processors in electrical communication with one or more computer-readable storage media and configured to implement the main blockchain, wherein one or more processors are configured to: creating a new block of the main block row to store new transaction records, the new block being associated with the most recent block by including a cryptographic hash of the latest block, the new block becoming the new most recent block of the main block series; creating a digest of records (the root of the Merkle tree) from new transaction records; generating a new POW digest of the new block by cryptographically hashing the block digest of the new block with the new random code; storing the new POW digest, the new random code, and the new block record digest in the new block; and transmitting the new POW digest, the new random code, and the record digest to the first neighboring computing system. 22. The system of claim 21, wherein the one or more processors are further configured to receive a POW digest of the latest first neighbor block from a first participating neighbor blockchain implemented in the first neighbor computing system, a random code of the latest first neighbor block, and a digest of records of the the last first neighboring block from the first neighboring computing system. 23. The system of claim 22, wherein the one or more processors are further configured to create the next block of the main row of blocks, the next block being associated with the new most recent block by including a new POW digest, a new random code and a record digest, the POW digest itself the last first neighbor block, the random code of the latest first neighbor block, and the digest of the entries of the latest first neighbor block. 24. The system of claim 21, wherein the one or more processors are further configured to maintain a main event log including an ordered list of event records, each corresponding to a transaction record from the transaction records stored in the main row of blocks of the main blockchain. 25. The system of claim 24, wherein the one or more processors are further configured to log an event entry in the main event log indicating the creation of a new block. 26. The system of claim 24, wherein the one or more processors are further configured to: receiving at least a portion of the first neighbor event log from the first neighbor computing system; comparing the main event log with the first adjacent event log; and reordering the event entries in the main event log based on comparison.

Images