SYSTEM AND METHOD THAT USES A BLOCKCHAIN ​​SUITABILITY GRADIENT CONSENSUS AND PROVIDES ADVANCED DISTRIBUTED LEDGER CAPABILITIES THROUGH SPECIALIZED DATA RECORDS

Abstract

An enhanced electronic system that implements and applies different types of gradient-fitness consensus methodologies, including hash distance and locker-based consensus variations, within a digital blockchain. This system calculates the highest fitness value among competing blocks or blockchain segments to resolve conflicts and allocate rewards associated with building new blocks. The enhanced consensus system applies conflict resolution formulas to incentivize each block-building node in a blockchain network to share each block it generates as soon as it completes construction, thereby improving the chances of receiving a reward and resulting in increased blockchain speed and security.Hash distance consensus uses a scalar hash distance value as part of its suitability metric, while locker consensus allocates tokens to lockers and calculates an aggregate value of the allocated tokens as part of the consensus. A trust-but-verify variant increases transactional throughput and reduces linearity and other computational constraints. The system also uses new record types, such as token genesis, transfer, transaction, trade order, settlement, proposal, determination, and pattern-linking records, to facilitate the automation of financial processes.

Description

SYSTEM AND METHOD THAT USES A BLOCKCHAIN ​​SUITABILITY GRADIENT CONSENSUS AND PROVIDES ADVANCED LEDGER CAPABILITIES DISTRIBUTED THROUGH SPECIALIZED DATA REGISTERS FIELD OF THE INVENTION The present invention generally relates to a field of blockchain technology, which is also known as a distributed electronic ledger for storing data that can be accessed, modified, updated, maintained and verified by multiple parties. More specifically, the present invention relates to a consensus chain selection method (the Fitness Gradient consensus method) that simplifies or eliminates a wasteful and resource-intensive proof-of-work step to determine which chain or block must be selected from competing chains and blocks to continue using the blockchain construction. Additionally, the present invention relates to certain complex distributed data records that interoperate to provide the distributed electronic ledger with certain specialized capabilities. BACKGROUND Individual parties may have or maintain distributed electronic ledgers or blockchains, or they may contain entries for different parties and may be replicated and distributed among multiple participants in a network. Distributed electronic ledgers are used by various applications, including exchanging and recording cryptocurrency transactions, such as, for example, transactions involving Bitcoin, Etherium, Ripple (XPR), and other cryptocurrencies. Additionally, blockchains can also be used to record and confirm the identity or existence of a person, object, or event. Data records confirming such identity or existence may then be used for such application as confirmation of the identity of an account holder, or to confirm the relationship between two account holders, or to confirm the occurrence of a real-world event. , and to then use that information to direct contractual behavior. Blockchains can also be used as a solution to record, track and mediate ownership of an asset or multiple assets, the latter encoded as a token (or multiple tokens) on a blockchain, which can be transferred or otherwise manipulated through elements of the distributed electronic ledger, such as smart contracts and on-chain data records. I CCCI n / l 7Π7 / Ε / Υ Additionally, blockchains can also be used to facilitate currency trading and money remittance by serving as a record of transactions represented on-chain by currency-backed asset tokens. For example, currency-backed asset tokens may be created by a trusted institution (e.g., a bank) that issues such tokens and trade or contracts with another institution (e.g., a different bank) through the use of smart contracts in a blockchain, to effect the transfer of asset tokens (and underlying assets) from one third party entity to another. Such transfer may be conditioned upon verification that any requirements that may be established in the associated smart contract for that asset token have been met. DESCRIPTION OF THE INVENTION In view of the above, it is an object and feature of the present invention to provide a computer system and method for the implementation of a distributed electronic ledger or blockchain that uses a Gradient of Suitability consensus method to determine which of the Competing nodes are selected to receive a reward for a particular block or chain that has been added to the blockchain. Another object and feature of the present invention is to implement a Fitness Gradient consensus to determine which node is allowed to build the next block in the distributed electronic ledger or blockchain, or which block or chain is used as a basis upon which continue to build the distributed electronic ledger or blockchain, and how to resolve a conflict between any block or chain in the event of a conflict between competing alternative blocks or chains. Another object and feature of the present invention is the implementation of a Hash Distance consensus variant and / or a Locker consensus variant of the Suitability Gradient consensus method to determine which of the competing nodes is selected to receive a reward for a block or chain that is added to the blockchain. These and other variants of the Gradient of Suitability consensus method of the present invention reduce or eliminate the less efficient Proof of Work consensus method by reconceptualizing the role of conflict resolution and the consensus process as a generic evaluation problem. of Suitability between competing blocks or chains. According to at least one embodiment, the Hash Distance consensus variant may use a scalar hash distance value as part of its Fitness metric when comparing chains for conflict resolution. The Locker consensus variant may incorporate the act of “freezing” tokens as a complementary method of generating a Fitness metric for use in chain comparison. Another object and feature of the present invention is the implementation of a Gradient of Suitability consensus or a variant incorporating the “trust but verify” methodology to determine which of the competing blocks or chains is added to the blockchain. or to the distributed ledger, and which of the competing nodes is selected to receive a reward for the block or chain that is added to the blockchain or distributed ledger. This strategy significantly increases the transactional throughput of currently known systems by reducing linearity constraints (and other computational constraints that delay overall system processing) and allows system processing throughput to approach the theoretical maximum throughput for blockchains. and distributed electronic ledger systems in general. Another object and feature of the present invention is the use and implementation of Bloom filters to represent all accounts affected during the execution of a block. It also allows you to build the new block without having to execute the previous block to determine which accounts may have been updated in the course of executing that block. A further object and feature of the present invention is the use and implementation of Penalty records, and the use of Bloom filters to optimize parallel processing within the blockchain or distributed electronic ledger network. Yet another object and feature of the present invention is the implementation of a method for stabilizing the supply and price of blockchain tokens by using information regarding native token charges specified in data records. added to new blocks. Additionally, the present invention provides increased native token price and supply stability by using on-chain data related to transactions between native and user-defined token pairs as indicators of inflation or deflation. Yet another object of the present invention is to implement a system and method for implementing and maintaining a network-connected distributed ledger computing system including (1) an interconnected network of a plurality of computers, each including a processor that executes computer instructions stored in an electronic memory of each computer to implement and maintain a distributed electronic ledger system implemented as a backward-linked blockchain I CCCI n / l 7Π7 / Β / ΥΙΛΙ of multiple interconnected blockchain blocks; (2) a first node in such computer network, wherein the processor of the first node executes peer-to-peer software to create a first competing block or segment of the blockchain to be added to the blockchain; (3) a second node on such computer network, wherein the processor of the second node executes peer-to-peer software to create a second competing block or segment of the blockchain to be added to the blockchain; (4) the network of computers (nodes) that execute computer instructions that apply a Fitness Gradient consensus to calculate and apply a calculation of the highest fitness value between the first and second blocks or segments of the blockchain that compete; (5) the nodes executing the computer software in accordance with at least one embodiment to determine which of the first or second nodes is permitted to add a next block or block chain segment to the blockchain and which of the nodes first or second is allowed to share a reward for the added block or segment of the blockchain; and (6) adding the next block or blockchain segment to the blockchain after determination. Another object and feature of the present invention is the use of different types of records, including token genesis records, transfer records, trade order records, settlement records, proposal records, determination records and pattern linkage records. These different registries, and the Fitness Gradient consensus methodology and its variants are useful in (1) the implementation of real-world event-oriented smart contract execution systems using blockchains and blockchain-based systems; (2) identity confirmation processing through the use of blockchains and blockchain-based systems; (3) the tracking and title of assets of blockchains and blockchain-based systems; (4) coin-based asset tokens, currency and remittance trading processes using blockchains and blockchain-based systems; and (5) the implementation of an automated system for the issuance, sale, transfer and trading of tokens that may be characterized as securities, and that are regulated as securities in accordance with multiple securities regulations, rules and restrictions governing securities transactions . Yet another object and feature of the present invention is the use of different types of records, including, without limitation, token genesis records, transfer records, trade order records, settlement records, proposal records, determination records and / or pattern binding records to implement derivative and base tokens, and control the supply and value of tokens, as well as the transfer and trading of tokens. Another object and feature of the present invention is the use of different types of records, including, without limitation, token genesis records, transfer records, trade order records, settlement records, proposal, determination records and / or pattern binding records to facilitate the exchange of the different types of tokens (e.g. native tokens and different user tokens) and also the implementation of other trading orders (e.g. , market orders, limit orders and stop loss orders). These and other objects, advantages, aspects and features of the present invention are as described below and / or appreciated and well understood by those skilled in the art. BRIEF DESCRIPTION OF THE DRAWINGS The above and other features and aspects of the present invention will become more apparent upon reading the following detailed description together with the accompanying drawings, in which: Figure 1 illustrates the general structure and organization of various components of a blockchain in a distributed network according to at least one embodiment of the present invention. Figure 2 illustrates the general structure and organization of a blockchain according to at least one embodiment of the present invention. Figure 3 illustrates the process flow for the implementation of the Pigeonhole consensus of a Fitness Gradient consensus system and method in accordance with at least one embodiment of the present invention. Figures 4A and 4B illustrate the structure, organization and information of the Locker consensus stored in a locker implementation of a Gradient Suitability consensus system and method according to at least one embodiment of the present invention. Figure 5 illustrates a Suitability Gradient consensus determination between two competing blockchains A and B for block N, according to at least one embodiment of the Suitability Gradient consensus system and method of the present invention. Figure 6 illustrates the organization and data stored in a block according to at least one embodiment of the present invention. I CCCI n / l 7Π7 / Β / ΥΙΛΙ Figure 7 illustrates a flowchart and trading algorithm between pairs of native and user-defined tokens according to at least one modality that increases and / or guarantees the price of the native token and the stability of supply. Figure 8 illustrates the proposal determination procedure according to at least one modality. Figure 9 illustrates the process of distributing proposal rewards to successful voting accounts according to at least one modality. Figure 10 illustrates the processing of linkage records in a blockchain according to at least one embodiment. Figure 11 illustrates the processing of business records on a blockchain according to at least one embodiment. Figure 12A-D illustrates a simplified block propagation processing process by using the “trust but verify” variation of the Gradient of Suitability consensus by using Bloom filters according to at least one embodiment. Figure 13A illustrates a “Suitability” rating of blocks with Bloom filters for a simplified process by using the “trust but verify” variation of the Suitability Gradient consensus according to at least one modality. Figure 13B illustrates the difference between a linear blockchain and a directed acyclic graph implementation of the “trust but verify” variation of the Gradient of Suitability consensus according to at least one modality. The present invention is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements. In the following description, the following terms are useful in understanding the use and operation of a system or a component of a system that includes at least one embodiment of the present invention. Structure and Organization of the Blockchain A blockchain data structure is an immutable, attachment-only data structure, comprising an ordered set of individual “Blocks,” with each block representing an ordered set of individual data records. A “Distributed Electronic Ledger” is a database, duplicated across multiple devices, whose state at any point in time is determined by applying discrete data transformations in a given, well-defined order. By design, a blockchain data structure is typically used to host a distributed electronic ledger, so that individual data transformations of the distributed electronic ledger I CCCI n / l 7Π7 / Β / ΥΙΛΙ correspond to the data records referenced by the blocks of the blockchain data structure. Within the context of this application, the term “Blockchain” is used inclusively to refer to various types of data structures upon which a distributed electronic ledger may be implemented (including linear blockchain data structures, n-dimensional mesh data structures, and directed acyclic graphs) as well as the distributed electronic ledger itself that is implemented on top of such a data structure. A 'Blockchain System' is a system of computing devices connected to each other through a distributed data exchange network, within which, in combination with any associated software, a blockchain and ledger may be implemented. distributed. Figure 1 illustrates the general structure of a blockchain system used in a distributed data exchange network. A blockchain system 100 typically includes a blockchain processing device 110, a wallet device 120, a blockchain data browsing device 130, and a provider device 140, all of which are connect to the Internet 190 (or a distributed network). The blockchain system may include multiple blockchain processing devices 110, multiple wallet devices 120, multiple blockchain data browsing devices 130, and multiple provider devices 140, all of which are connected to the Internet 190 (or a distributed network). In addition to the separate blockchain processing devices 110, the separate wallet devices 120, the separate blockchain data browsing devices 130, and the separate provider devices 140, a blockchain system may contain combination devices 150 (not shown) that combine features and functionality of all or some portion of these devices, or that simultaneously perform the function of all or some portion of these devices, and that also connect to the Internet 190 (or a distributed network). The blockchain processing device 110 may be a computer such as a mobile phone, smartphone, tablet, laptop, desktop computer, server computer, specifically designed computing device, or other type of computing device, with one or further computer processors 112, computer memory 114 for storing computer instructions, a database 116 for processing blockchain information (including records and / or transactions), and a communication module 118 for connecting to the Internet 190 and / or the distributed network. The blockchain processing device may also optionally include a display 155 (not shown), and may consist of multiple computers or a network of computers (either directly connected or distributed), all of the same type or of different types. . The wallet device 120, the blockchain data browsing device 130, the provider device 140, and the merging device 150 typically have the same components as the blockchain processing device 110. The blockchain processing device 110 functions as a 'Block Construction Node', which is also called a 'miner' in proof-of-work blockchains. Block Construction Nodes are responsible for assembling new blocks that reflect the inclusion of new records or transactions in the blockchain, and for linking those blocks to the blockchain. Block Construction Nodes are also responsible for algorithmically confirming whether blocks that have been linked to the blockchain are valid, and whether records or transactions are validly included in the blockchain. Block Building Nodes are also responsible for propagating blocks and data records within the network. In at least one embodiment of the present invention, each Block Building Node is associated with an account or address on the blockchain, to which block mining rewards in accounts or addresses may be assigned. Such an account or address may also be used by a Block Building Node to securely identify itself and its activities within the network and on-chain through the use of cryptographic signatures. The wallet device 120 functions as a “Wallet” that acts to securely store cryptographic keys, which keys are used to cryptographically sign new data records that are proposed for inclusion in the blockchain. Cryptographic signatures ensure that Block Building Nodes only include data records that are properly authorized. In addition to storing cryptographic keys and other secure data, Wallets may generate and cryptographically sign new data records and transmit them to one or more Block Construction Nodes, typically over the Internet 190 or other network. The blockchain data navigation device 130 functions to provide users with a means to read, view, or otherwise access data associated with the read-only blockchain. I CCCI n / l 7Π7 / Ε / ΥΙΛΙ Provider device 140 may include one or more computers or other computer processing devices that facilitate the activity of the Blockchain Providers. The term “Blockchain Provider”, in the context of this application, refers to any person or entity that offers, issues, sells or distributes any token to one or more users, or that provides services that are in any way verify, confirm, provide or transmit via a blockchain, for example, identity verification services. A provider device runs software that allows Blockchain Providers to provide such services. The term “Node” in this application refers to a computer such as a mobile phone, smartphone, tablet, laptop, desktop computer, server computer, a specifically designed computing device, or another computing device that runs the software of the peer-to-peer blockchain and communicates with other similar computers operating on a connected distributed data exchange network such as the Internet. The term “Node Network” refers to a collection of computers running the same peer-to-peer blockchain software, working to build a single shared blockchain, and connecting to each other through a sharing network. distributed data network connected like the Internet. Data records accepted for inclusion in a blockchain are stored or referenced in the blocks of a distributed ledger or Blockchain. Individual blocks can contain record and / or transaction data. Alternatively, blocks may reference such data through a cryptographic hash or digest that summarizes the data, which hash or digest may be generated by a separate data structure containing the records and transactions, e.g., a data tree. Merkle. For cryptocurrency blockchains, ownership of cryptocurrency is linked to the unique addresses or account numbers included as data within these records and transactions. In such cryptocurrency blockchains, the cryptocurrency balance associated with a particular address or account number may be derived from the entire history of records and transactions preserved by the distributed ledger or Blockchain, from its origin. The general structure of a linear blockchain data structure 200 is illustrated with reference to Figure 2. The blockchain data structure 200 is an immutable attachment-only data structure, comprising one or more individual blocks 210A-C, shown in Figure 2 as Blocks 10, 11 and 12. Each block 210A-C represents a unique set of data records 220A-C. These data records of a particular block may not be contained in that block, but rather may be represented in the block by one or more cryptographic hash values, either the root(s) of one or more 225A-D Merkle trees (shown in Figure 2 for the TxRoot hash for block 21OB, or the hash of an aggregate data structure (such as, the hash of some key-value map). Each cryptographic hash 230 is unique to the data from which it is derived , and by design will change radically even if the smallest aspect of its underlying data is altered. Each block 210A-C in the blockchain data structure 200 may be described by, or in terms of, the cryptographic hash of its contents 220A-C. The 'Block Hash', in the context of this application, is this cryptographic hash of the contents of a particular block. Each block refers to its preceding block on chain 200 by the block hash of that preceding block 240A-C, and includes that reference among its own data (i.e., the data used to derive its own block hash). . In other words, block 210B stores as its own data the block hash 240B of the preceding block 210A. Each block may also store timestamp 250 (shown for block 210B in Figure 2), which could indicate the time of the block's formation or acceptance into the blockchain. This organization ensures the immutability of the blockchain data structure 200. Given the existence of any block in a well-formed blockchain data structure (e.g., the last block in the chain), the entire The preceding chain, which includes both blocks and all the records they represent, are immutable. Any change to any record or any block would have a cascading effect on the cryptographic hashes that make up the chain, and would invalidate each and every downstream block in its original form. Therefore, any change to any record of the last block 210N on chain 200 would invalidate all downstream (linked) blocks. A new node entering the Node Network must validate the chain, to ensure that each block accurately represents the records attributed to it, and that all blocks in the blockchain are linked correctly. This reset validation is performed in sequence, from the first block 210A and its first record to the last block 210N and its last record. Additionally, each new block generated by any Block Building Node(s) in the Node Network must be validated by other Block Building Nodes, or it will not be added to the Blockchain. Additionally, because the validation process and the new block creation process can be done in parallel by many different Block Building Nodes on the same network, each Node must also decide which instance of the blockchain should be used when it exists. more than one valid instance of the ledger or blockchain on the network. This is a decision process that is often referred to as “Conflict Resolution.” The term “Consensus Algorithm” refers to the determined procedure followed by the Block Building Nodes of the network to unequivocally decide which valid version of the blockchain is “canonical” and can continue to be used. Each Block Building Node independently decides which version of the blockchain is canonical, and proceeds to generate new blocks with reference to that version. Since all Nodes in the network by design run the same software, share all the same data, and use the same Consensus Algorithm, these independent decisions result in all Nodes accepting a single distributed ledger or Blockchain. The “Token”, in the context of this application, refers to a unit of value that is tracked within the blockchain. Tokens belong to particular accounts or addresses, and can be transferred from one account or address to another through the inclusion of a transfer record on the blockchain. Tokens may be created through the operation of the Consensus Algorithm implemented within a particular blockchain system - for example, as a reward that incentivizes Block Building Nodes to contribute computing resources to the operation of the blockchain. the network - or tokens can be generated through certain types of records, specifically “Genesis Records”. Each Block Building Node maintains a duplicate copy of the token values ​​associated with each account or address within the blockchain. At any point in time, the current state of the tokens, accounts, or addresses is encoded within the blockchain as the entire series of records that have been added to the blockchain before that point in time. Therefore, to reliably determine the current token balance for any given account or address, a node will run and validate the entire history of the distributed ledger or blockchain, creating and transferring tokens between accounts and addresses up to the current state is reached. Once the entire chain is validated, updates are applied when accepting and validating, or generating, new blocks. The Account”, in the context of this application, is an address with which certain data is associated on the blockchain. Tokens, smart contracts, or other data may be associated with an account. The account number relates to one or more public keys that are used in combination with one or more private keys to cryptographically sign records that are created on behalf of an account, and which may alter certain data associated with the account. Only a record that is cryptographically signed with its corresponding account key will be considered valid and included in the blockchain. In some embodiments, the account number may be a hash or other transformation of a single public key. “Transfer” or “Token Transfer”, in the context of this application, is a particular type of record that reassigns a certain token value from the signing account to some destination account. “Token Fees”, in the context of this application, refers to the requirement that a record include a fee, which is a common feature of blockchains. In at least one embodiment, the present invention addresses increased complexity with respect to charges, due to certain records being re-executed for a number of blocks in succession. The Smart Contract”, in the context of this application, is a small executable program that can be added as a record to the blockchain. There are a variety of smart contract runtimes, and a variety of higher-level languages ​​compile to such executable contract runtimes. The “Blog Chain Segment”, in the context of this application, is a discrete and contiguous subsection of a blockchain. A blockchain segment may be a portion of the canonical blockchain currently accepted as such by nodes within the blockchain system, or it may represent a portion of a conflicting blockchain that differs from the blockchain. of canonical blocks. Each block within a segment of the blockchain can be described as having a “Height” relative to the first block within the blockchain as a whole, calculated by counting the distance, in terms of number of blocks, between the origin of blockchains, and the block in question. When blockchain segments are compared for conflict resolution, typically both would originate at the same block height. Overview of Blockchain Consensus Algorithms A feature that is common to most blockchains and blockchain systems is the use of a consensus algorithm to resolve conflicts between competing chains. A blockchain system will implement a consensus algorithm as a way for different untrusted nodes to come to an agreement as to the current state of the blockchain in question. I CCCI n / l 7Π7 / Β / ΥΙΛΙ The present invention, in at least one embodiment, uses and implements Fitness Gradient Consensus, and in other embodiments uses and implements certain variations of Fitness Gradient Consensus, including Hash Distance consensus and Pigeonhole consensus. These consensus methods and systems replace known consensus methodologies, including Nakamoto's original “proof-of-work” consensus methodology, and known “proof-of-stake” consensus methodologies, within an on-chain system. blocks. A typical blockchain comprises an ordered set of “blocks”, where the order of these blocks is incorporated in a chain of references from each block to its preceding block (or multiple previous blocks). Each subsequent reference is a cryptographically generated unique hash or digest of the contents of the preceding block. Such post-reference data is accumulated to the other data encapsulated in the block, which together is passed through a cryptographic hash function or hash function to determine the unique reference that the subsequent block will contain. Blocks within blockchains that use non-linear arrangements of blocks will contain multiple back references. The creation, sequencing and linking of new blocks, and the content of each new block, are determined by computers linked to the network (Block Building Nodes) that have been given the right to make decisions on behalf of the entire network, according to a consensus algorithm. In a blockchain system, multiple block building nodes may work simultaneously to create new blocks and add them to the blockchain, thereby augmenting the blockchain and adding new data records to it. she. Each Block Building Node attempts to add blocks that point to the version of the blockchain that the consensus algorithm determines to be canonical, choosing between the different versions it has learned from other nodes in the network. Block building nodes typically abandon new blocks they attempt to build after confirming that the version of the blockchain they are built on is replaced by a new version of the blockchain. The nodes will then proceed to generate new blocks that reference (i.e., are based on) the new version of the blockchain. For example, in one embodiment, if block construction nodes within a blockchain system work to construct a new block at height N, when one of those nodes successfully generates a valid new block at height N and links to the canonical blockchain, this new expanded blockchain can replace the previous version. I CCCI n / l 7Π7 / Β / ΥΙΛΙ At that point, nodes that learn of the new version can go to work to build the subsequent block at height N plus 1, which will reference the block at height N. However, competing nodes can propose simultaneously alternative blocks and alternative chains. When two or more competing versions of the same blockchain compete for supremacy within a single blockchain system, this event is known as a “fork.” Conflicts between different versions or segments of the blockchain caused by a fork can be resolved deterministically within a blockchain system, as long as nodes within the network are fully informed about the nature of each fork. Given the same set of options, all nodes within a blockchain system will use the same consensus algorithm to choose the same fork. For this reason, a blockchain system will remain cohesive as long as all participating nodes implement the same consensus algorithm. Each node will use the consensus algorithm to determine which alternative chain ends with a block at height N to reference when constructing a block at height N plus 1. Within each block, data is represented as a set of records or transactions. The records and transactions included in the blocks encode transformations to the global state maintained by the blockchain system. Such records are executed in a well-defined and predictable sequence as new blocks are generated, evaluated, validated and added to the blockchain by each Block building node. By agreeing which blocks and records are included in the blockchain and which are not – which agreement is enabled by the system consensus algorithm – block building nodes can ensure that the entire system maintains the same global state. Some portion of the records or transactions within the blocks typically commemorate the creation or transfer of the tokens. Token values ​​are remapped from certain specified source addresses to certain specified destination addresses via individual data records, each of which is cryptographically signed to demonstrate that each transfer is authorized. Alternatively, tokens are added to accounts or addresses based on the consensus algorithm when a block is created. In cryptocurrency blockchains, a block building node that successfully adds a new block to the blockchain will typically receive a reward in the form of a token. To incentivize nodes to compete in producing new blocks and validate future updates to the blockchain, each new block contains a record that assigns a token reward to an address specified by the node creating the block. Include such incentive acts to increase participation in the block construction and block validation process, thereby increasing the overall security of the system. Different consensus algorithms differ in how this reward is determined and assigned. In a blockchain system that uses a proof-of-work algorithm, for example, miners receive token rewards for solving certain computing problems. These block building nodes have the right to add new blocks to the blockchain after solving a computing problem before any other node has done so. Fitness Gradient Consensus Compared to Known Consensus Strategies The Fitness Gradient consensus algorithm and the Locker and Hash Distance consensus variations of the present invention, used with one or more modalities, are distinct in a number of important ways from the proof-of-concept consensus strategies and known proof-of-stake that is used for several existing blockchains. An important difference between the Gradient of Suitability consensus method of the present invention, compared to existing and known consensus methodologies (including proof-of-work and proof-of-stake consensus methodologies) is that in the system and Gradient Suitability method, no block or node is privileged. Instead, all active nodes can build blocks simultaneously and broadcast the blocks that are built. Each node is incentivized (but not required) to share each block it generates, as soon as it completes construction, to improve the node's chances of receiving a reward for the new block. If that block has the highest Suitability among the competing blocks, then the use of that block will spread throughout the network; a lower Suitability block will be discarded. By contrast, in the well-known blockchain consensus approaches used today, a node will transmit a block only after the node has achieved some privileged state - which is different from the methodology used in blockchain consensus. Gradient of Suitability of at least one embodiment of the present invention. Among the consensus approaches currently used, different consensus approaches will assign a Block Building Node its privileged status through different means. Another difference between Gradient Fitness consensus and consensus methodologies I CCCI n / l 7Π7 / Β / ΥΙΛΙ existing approaches are that existing approaches rely entirely on computing power or cryptographic power to secure blockchain systems. In contrast, the Hash Distance consensus and the Locker consensus implementations of the Suitability Gradient consensus, implemented according to at least one modality, calculate Suitability through a process that combines both computing power and cryptographic power (i.e. control over the tokens on the chain). By using a ratio of tokens sent within the blockchain by hash distance as a Fitness metric, Fitness Gradient consensus methods decrease or eliminate the possibility of computationally powerful nodes exerting concentrated influence over block production. . Any node attempting to exert concentrated influence would have to control a disproportionate amount of both participating computing power and tokens held on-chain. In a widely distributed network, with many participating nodes, such a possibility would be difficult, if not impossible, for a single actor to achieve, both technologically and economically. Another difference between the Suitability Gradient consensus of the present invention and the known proof-of-work consensus and proof-of-stake types of consensus is the way nodes choose which block to consult when assembling new blocks (i.e., which block or block chain segment to build), and by implication which node is given the right to include data records in the block and assign the token reward of that block. The Fitness Gradient and Hash Distance / Locker consensus methods of the present invention do not use separate algorithms or metrics when deciding which block to build on one hand, and which chain to choose when resolving conflicts on another. Instead, each potential new block transmitted to the network is evaluated as a competing chain with the same algorithm used to evaluate and compare potential forks. This simplification makes the application of Gradient Fitness consensus much more efficient for blockchain applications where processing time is a key issue. Furthermore, it reduces the cost of transactions involving blockchains, the time required to create and verify a new block, and also promotes the participation of more nodes in the consensus / conflict resolution process. In at least one embodiment of the present invention, new unique blocks are evaluated as a fork or segment of the blockchain of height one, but are evaluated in a manner I CCCI n / l 7Π7 / Β / ΥΙΛΙ against blockchain forks / segments of arbitrary height if all forks branch from the same initial state. In comparison, well-known proof-of-work and proof-of-stake algorithms are concerned with determining which node can afford to broadcast the next block, based on the block. In the event that two nodes satisfy the criteria to allow both to generate the next block in the chain - or if two separate chains are generated as a result of a network partition or fork - a separate algorithm is used for conflict resolution. to decide which string should be discarded and which string should be used to continue building. The Fitness Gradient consensus in general, as well as the Hash Distance (which is a subtype of Fitness Gradient consensus in at least one embodiment of the present invention) and the Locker consensus (which is a subtype of Distance consensus hash in at least one embodiment of the present invention) in particular, all use formulas to calculate a well-defined scalar value (i.e., Suitability) in each segment of the blockchain, to compare the blocks, or the segments of the block chain. These formulas determine whether one block or segment of the blockchain is selected over another in a non-binary manner (not strictly a yes / no validity choice). A large number of blocks and chains may be valid, but only the chain with the highest Suitability is chosen by the participating nodes. Nodes continually grow the chain, adding blocks and transmitting the Fitness value of their chains across the network. When a node learns of the existence of a chain of higher Suitability, it requests and receives a chain update from the node in possession of that chain, and then performs block construction activities from that chain. In at least one embodiment, a node may engage in new block generation activity for one or a number of different chains simultaneously, but will discard chains (or segments) of lower Suitability in favor of building on top of the chain. higher Suitability once you can confirm that the higher Suitability string is actually valid. In known proof-of-work consensus systems, the determination of whether or not a particular block is valid and qualified is a binary determination. Each of the multiple “mining” nodes will compete to solve the mathematical problem that will make their block valid. The first node to generate a valid block transmits that block, and thus claims the right to specify the next block accepted by the network (and to claim the I CCCI n / l 7Π7 / Β / ΥΙΛΙ reward for the solved cryptographic problem and the creation / validation of the new block). Forks are minimized because the difficulty of the math problem is calibrated to ensure that it is solved approximately once per block by a single node. When the mathematical problem is solved more than once and by more than one node, it is treated as an exception, which exception is handled by a separate algorithm or set of rules. Similarly, in well-known proof-of-stake systems, some algorithm is used to assign a particular node the right to generate a block, and that block, when transmitted to the network, is accepted or rejected based on that determination. The choice of the assigned node will depend on the “stake” that unique node has (for example, a certain amount of ownership of the cryptocurrency, or the age, seniority, or some other quantifiable stake or property that is tied to the node), possibly in combination with some random factor. In contrast, in Suitability gradient consensus, implemented in accordance with at least one embodiment of the present invention, most nodes construct, publish, and transmit blocks, and the blocks compete head-to-head based on Suitability. All blocks that are eventually incorporated into the final canonical blockchain will have been selected by winning a tournament so that blocks generated by nodes in the network will be compared against each other to determine the block with the highest Suitability. Therefore, all or most nodes in a Fitness Gradient consensus network broadcast their blocks, as opposed to nodes using consensus methodologies that only broadcast individual blocks that satisfy narrow criteria. Variations of the Fitness Gradient consensus will compare the fitness of the entire chain, or the fitness of segments of the blockchain that contain multiple blocks, rather than just comparing individual blocks. In such variations, evaluation of blocks is done by evaluating chains, forks, or segments of the blockchain. In a Hash Distance consensus, which is a particular variant or species of the Fitness Gradient consensus, as used in at least one embodiment of the present invention, the Fitness of a block or segment of the blockchain is a function of the numerical distance between the hash of each block, and the “target hash” of each block. In one variation, Suitability may be determined based on minimizing the hash distance, or in another variation, by maximizing a certain ratio of “aggregate tokens used” per hash distance. This numerical distance is determined algorithmically based on the specific implementation of the consensus. Variations of Hash Distance consensus, including Locker consensus, can have different forms and methodologies for deciding on the target hash and hash distance. In at least one embodiment of the Hash Distance consensus, the output of the Suitability function may vary depending on some aggregation of token values ​​assigned within records that have been included in blocks or segments of the blockchain. that are compared. In other embodiments, related consensus systems may incorporate other inputs when calculating Suitability. For example, a variation of the Locker consensus of the present invention (described herein) combines the hash distance with the aggregate token value that is assigned to the “lockers” that are used to determine the target hash. In any case, these token values ​​may be referred to as “used aggregate tokens” for a given block or blockchain segment. In Locker consensus, which is a particular variant or species of Hash Distance consensus, implemented according to at least one embodiment, the target hash is determined by users sending tokens to lockers. Pigeonhole consensus divides the potential range of the hash output into a continuous set of pigeonholes, such that the output of the relevant hash algorithm falls into only one pigeonhole. Each box is a numerical range, and each record that assigns tokens to a box will specify the box to which the tokens contribute. Tokens that are sent to lockers in a block can be used to determine the target hash for a future block - that is, for a block that has not yet been generated a fixed number of blocks greater than the block. Comparison to Nakamoto Proof-of-Work Consensus Within the Nakamoto Proof-of-Work methodology and consensus system, all nodes work to create blocks, but a node will only transmit a block if it wins a race to solve a brute force proof-of-work computing problem. . Due to the low probability of solving such a problem, a very small number of nodes reach the privileged status required to create, validate and publish a block and add that block to the blockchain. The Fitness Gradient consensus of the present invention in at least one embodiment will bypass the proof-of-work computing problem. A block is valid as long as it is correctly constructed in terms of format, and as long as its internal records have integrity (i.e., the same token value is not transferred twice; account values ​​do not become negative; and all the other data found within the block is valid). I CCCI n / l 7Π7 / Β / ΥΙΛΙ When more than one block is published at the same time, or when more than one subchain emerges within the network, with Proof-of-Work consensus, the longest chain is accepted by each and every node. While chain length could theoretically be used as a Suitability criterion in the Suitability Gradient consensus, it would be insufficient on its own to differentiate between two competing blocks or blockchain segments that compete for inclusion in the blockchain. . Due to the absence of a proof-of-work problem within the Fitness Gradient consensus, a malicious node trying to maximize the length of the chain could quickly build block upon block without restrictions, without spending time and computing resources on the necessary work. of executing, processing and validating smart contracts, records and transactions for inclusion in the blocks. As a result, the cooperative nodes would be at a disadvantage because they would be penalized for actually attempting to evaluate Suitability, while the malicious node would be rewarded for limiting its computing resources for its own use. In Nakamoto Proof-of-Work consensus implementations, the possibility of competing chains is relatively rare, and nodes begin building on the first new valid block they find without evaluating suitability at all, only validity. Most of the time, there are no competing chains to compare. In contrast, with Suitability Gradient consensus, before the block building operation begins, a node will inquire from surrounding nodes regarding the Suitability metric of other chains and download the highest Suitability chain from among those who are present. Next, it will then start building on top of that string. This mechanism encourages each note to actively search for a large number of competing blockchains, rank them by suitability, choose the one with the highest Suitability, and then download and build on top of that blockchain. One of the key benefits of the present invention is that because chain length and chain difficulty are replaced by more energy-efficient Fitness metrics, the energy expenditure and computing resources required to verify and set the chain length and difficulty, and the performance of the blockchain is significantly increased. In contrast, the Proof of Work consensus methodology includes the proof of work algorithm as an additional stage necessary to enable the use of chain length as a metric that can be used when attempting to resolve conflicts between chains. I CCCI n / l 7Π7 / Β / ΥΙΛΙ that compete. This additional stage is computationally inefficient and energy inefficient, and unnecessarily increases the processing time required to grow the blockchain. The Gradient Fitness consensus variations of the present invention are simplified algorithms that eliminate this unnecessary and wasteful step. The Hash distance consensus in at least one embodiment determines a scalar value that can place a block within a gradient of Suitability values. More significantly, Hash Distance consensus uses the scalar hash distance value as part of the Fitness metric when comparing chains, while proof-of-work entirely ignores block hash comparisons when comparing chains across the chain. block length, or use only the target hash value when comparing the aggregate difficulty of two chains, ignoring the block hash. Comparison to Proof-of-Stake Consensus There are a variety of Proof-of-Stake implementations (such as Casper), but most share some basics. Proof of Stake depends on cryptographic power, unlike Proof of Work which depends on computing power. Essentially, in Proof of Stake consensus, the right to generate or propose blocks is given to nodes that stake the tokens, or that can claim a set of tokens on the chain that lend that authority to the node. In some implementations, there is some inherent quality of the referenced tokens that are used to establish which node has block generation authority. In others, such as Casper, the block generating nodes vote in real time (not on chain, but as part of the network protocol) which block to accept. In other words, the block generating node has some specific real-world authority to accept or issue a decision on the new block. Proof of Stake is an approach to determining which node or nodes are allowed to work on creating new blocks. In contrast, in Fitness Gradient consensus, any node can create new blocks, and all nodes are encouraged to work on creating new blocks. Additionally, block building nodes in the Suitability Gradient consensus have no requirement or incentive to hold, freeze, or not allocate tokens at all, unlike block building nodes that operate within many Proof systems. of Participation. When considering tokens in the Suitability Gradient consensus, it is evaluating the token's activity on the chain generally for the purposes of determining Suitability, rather than establishing whether a node on I CCCI n / l 7Π7 / Β / ΥΙΛΙ individual is allowed or not allowed to publish a block or vote in a block. Locker consensus of at least one modality requires that some tokens be “locked” on the chain for a period, and accounts that lock these tokens may receive a reward for doing so. However, there is no link between the participation of these accounts and the determination of which node generates the block that is accepted (which is effectively random). In at least some embodiments, upon acceptance of a block, separate rewards may be granted to both the Block Building Node and the accounts that freeze the tokens. At least one modality Suitability Gradient consensus does not have a nomination protocol / voting type in which authorized nodes participate, as used in certain Proof-of-Stake consensus systems. Convergence is achieved on the Suitability Gradient because all nodes agree on the criteria used to evaluate Suitability. Suitability Gradient consensus generally and Hash Distance consensus in particular do not necessarily require in all embodiments that tokens be involved as part of the consensus algorithm; for example, the Hash Distance value can only be used to determine Suitability. When Hash Distance uses tokens, as you stated above, it can use only the history of the on-chain tokens, not the tokens identified or associated in any way with the block building node. Locker consensus, as well as other variations of Hash Distance consensus of at least one modality, are based on a combination of computing power (hash-distance component) and cryptographic power (token value component), unlike of only cryptographic power for consensus. Definitions Related to Consensus and Suitability Gradient Variations The term “Suitability”, in the context of this application, refers to a numerical score that is derived from the state of a particular blockchain instance, or from the state of a particular blockchain segment. The present invention uses and implements one or more versions of the “Suitability Gradient Consensus” algorithm to determine a Suitability score. Under the Suitability Gradient Consensus, according to at least one embodiment of the present invention, the segment of the blockchain that has the highest Suitability value will be selected as the basis on which to continue building the blockchain. block chain. In other words, it will be selected by the nodes (or Block Building Nodes) in the Node Network as the correct blockchain segment in case of a conflict between different segments present in the network. The different algorithms i ccci η / ι znz / E / YiAi > 23k c Gradient Consensus Framework and its distinctive approaches to resolving conflicts between different blockchains and competing blockchain segments, are described in more detail below. The “Target Hash”, in the context of this application, is a numerical value belonging to a block at a particular height, whose numerical value is known before the creation of those blocks and is derived from some pre-existing state. The target hash can be compared to the block hash of the block in question to calculate the hash distance of those blocks. The “Hash Distance”, in the context of this request, is the absolute value of the difference between the block hash of those blocks and their target hash. Hash distance is a key component of the fitness calculation within the Hash Distance Consensus. In at least one embodiment of the present invention, a variation of the Fitness Gradient consensus, called “Hash Distance Consensus,” would calculate Fitness as some function of the Hash Distance. For example, one version would calculate the Suitability as follows: N Σε . , . unique yvtokens C~----;----------------k + J ' Hash distance i-G where V is the aggregate value of certain qualified tokens within a block, D is the hash distance for that block and c, k, j and y are constants, for all blocks with heights G to N within the segment. “Unique Tokens”, in the context of this application, refer to token values ​​that have not been transferred, reused or reassigned within a particular blockchain segment; tokens that have not been recycled between different accounts and are therefore not measured twice when used for the aggregated token values ​​to calculate the Eligibility of a particular chain. Measuring unique tokens requires tracing the origin of tokens from account to account back to the first block of a blockchain segment being evaluated. In at least one embodiment of Hash Distance Consensus called “Locker Consensus,” Suitability would be calculated in the same manner as Hash Distance Consensus, but where V includes the tokens assigned to lockers through the allocation records. boxes, and the hash distance D is determined by using a specified value with a given box as the target hash. For example, in a variation of the consensus of Locker,The target hash is the midpoint of the locker to which the largest has been assigned through the locker allocation records for the block in question. “Box”, in the context of this application, refers to a numerical range; one of a set of contiguous numerical intervals that overlaps the output interval of a cryptographic hash function. For example, for any input, the SHA-256 hash output will be a number between zero and 2256; the lowest box will have zero as its lower limit, and the highest box will have 2256 as its upper limit. “Locker Assignment Record,” in the context of this application, refers to a particular type of record on the blockchain that links a certain token value to a particular conceptual locker and a particular block height. The originating account that signs the locker allocation record with its cryptographic key can put this token value at risk of total or partial loss in exchange for an opportunity to earn a greater token reward in the future, some number of blocks that follows the block at the specified height. All locker allocation records can compete for a limited number of slots, and would gain inclusion in the blockchain (and therefore earn an opportunity to stake tokens) based on the size of the charge they include. In at least one embodiment, bids for the slots are made in a type of Dutch auction. Since the lowest offsetting bid price is accepted for all bids, a surplus of unused charges accumulates for the highest bidders. In one embodiment, the excess charges may be returned, but in another embodiment, they are reapplied in future blocks to persist the record beyond its initial holding. Additionally, long-lived records may be re-executed for some blocks after the block where they are first included. The charge, according to at least one embodiment, is set for the overlay of this precise and consistent set of blocks, after which the record would need to be added again. Process v Suitability Gradient Consensus Method The Gradient Suitability blockchain consensus method of the present invention may implement the following steps, elements and features (although not all steps, elements and features are necessary in each embodiment). (1) Fitness Gradient consensus is implemented within a blockchain system and a network consisting of Block Building Nodes. When a new I CCCI n / l 7Π7 / Ε / ΥΙΛΙ Block Building Node goes online, it connects to the network by pairing with other Block Building Nodes already connected to the network. (2) A newly connected Block Building Node downloads the blockchain blocks, block headers, smart contracts, data records and transactions from peer nodes within the node network. Downloads all blocks, block headers, smart contracts, records and transactions that have been added to the blockchain up to the current blockchain height N minus 1 (N -1), and then executes smart contracts and validates and processes records and transactions in sequence, building its own internal representation of the global state. (3) The Block Building Node begins to receive new smart contracts, registrations and transactions from peer nodes, as well as from wallets and other network participants. The Block Building Node adds them to a locker of unprocessed smart contracts, records or transactions. (4) The Block Construction Node begins to receive information regarding newly constructed blocks that have height N generated by other Block Construction Nodes, and which are shared within the network through a gossip protocol. (5) The Block Construction Node evaluates the suitability of newly constructed blocks at height N of which it is aware, to identify which blocks have the highest Suitability value according to the criteria of any suitability formula or algorithm that is in place. in use by the blockchain system as a whole. (6) The Block Construction Node chooses the highest suitability block(s) to build on and begins building a new block at height N plus 1, assembling smart contracts, records and locker transactions. The global state is updated by executing smart contracts and validating and processing the records and transactions contained in the new blocks. (7) Other nodes in the network continue to transmit the blocks and block headers as they create them. Blocks and block headers are shared as fast as they are built, with little delay. Some of these blocks will be at height N, and some will be at height N plus 1, and some of these could be at even higher heights. In at least one embodiment, the Block Construction Node will receive these blocks and begin parsing them in a separate thread, system process, or coroutine, separate from the thread, system process, or coroutine that constructs the new block. I CCCI n / l 7Π7 / Β / ΥΙΛΙ (8) If the Block Construction Node is aware of a block at height N that is of higher suitability than the block on which it is currently built, it may discard the work it has done so far and start building on that block, depending on the size of the discrepancy. (9) After building a new block at height N plus 1, the Block Construction Node will calculate the suitability of that new block and compare it with the suitability of other candidate blocks at the same height that are transmitted through the grid. If the Block Building Node determines that the new block it produced has a higher suitability than the other blocks it has become aware of, or if the new block has at least a suitability that exceeds a certain threshold, then the node will broadcast that block to the network. (10) The Block Construction Node returns to the previous stage (3) to start the process again. In effect, the node receives new records and new blocks, choosing the most suitable block of which it is aware at height N plus 1 (N + 1), and begins building a new block at height N plus 2 (N + 2). Alternatively, in at least one embodiment, if there is knowledge of a block already constructed at a higher height, for example at block height N plus 2, or N plus 3, - and if the block chain segment at that belongs to has a higher aggregate Suitability than the other nodes, then the Block Construction Node can skip ahead and start building a new block at a higher height, - for example, at block height N plus 3, or N plus 4. In at least one embodiment of the present invention, when the suitability of a given block is evaluated, it may be evaluated individually, or it may be evaluated for the segment of the blockchain or the entire blockchain to which the block belongs. When comparing the fitness of two blocks, either the fitness of the entire blockchain to which the blocks belong, or the fitness of two segments of the blockchain that incorporate the most recent ancestor block that both blocks share. In at least one embodiment, the calculated fitness for a particular block may be added to the header of the block that is shared among network nodes, along with the aggregate fitness of certain segments of the blockchain of predetermined length to which the block belongs. , so that an indication of block suitability can be known to nodes before a complete block is downloaded, to speed up suitability evaluation by Block Building Nodes. Hash Distance Consensus Variant of the Fitness Gradient Consensus i ccci η / ι ζηζ / Ε / γ A variation of at least one embodiment of the Fitness Gradient consensus algorithm and method of the present invention is the Hash Distance Consensus algorithm and method. The Hash Distance consensus variant of the Fitness Gradient consensus decides the Fitness value of a blockchain segment according to a function of the Hash Distance of each block within the blockchain segment under consideration. The Suitability of an individual block within a Hash Distance Consensus system can be determined by calculating the suitability of a blockchain segment of size one that contains that single block. The Hash Distance Suitability formula, according to at least one embodiment, may be described as follows: n Σ’ Viy C----A-77¿ k+j Ή, i=g H: Hash distance values ​​for all blocks in the segment being evaluated H;: hash distance value for block i V: “Use of Aggregate Token” for all blocks in the segment being evaluated V,: “Aggregation Token Usage” for block i, for unique tokens within the blockchain segment being evaluated. g: the height of the first block within the blockchain segment being evaluated n: the height of the last block within the blockchain segment being evaluated c, k, y: tunable constants j: tunable constant, probably the ratio 1 over the maximum possible block hash value Alternative forms of Hash Distance consensus may vary the way inputs are generated for this function, or may modify this function with another function that accepts hash distance values ​​as input criteria. Hash Distance Consensus Locker Consensus Variant I CCCI n / l 7Π7 / Β / ΥΙΛΙ The Locker consensus implementation of a Hash Distance consensus system and method according to at least one embodiment of the present invention is shown with reference to Figures 3, 4A-B and 5. Such actions described by these figures are performed by a Block Building Node or miner that executes a modality of the consensus algorithm Locker. Referring to Figure 3, at 310, within the block numbered N (the current block), the reward output of the block numbered N minus 1 (i.e., N - 1) is assigned to winning addresses among the associated locker records with the block numbered N minus G (where G is a predefined constant integer value), as well as to the Block Construction Node or miner that generated the block numbered N minus 1. At 320, within the numbered block, the transactions are assembled N and the records assigned to that block and smart contracts are executed within that block. Then, at 330, various nodes, other than the Block Construction Node, transmit the locker assignment records to the network. These registers send the tokens to the locker addresses for the block numbered N. At 335, some portion of these locker assignment registers are incorporated into the block numbered N, where the number of locker assignment registers incorporated into the block is less than or equal to a predefined upper limit count X. At 340, the token reward for the block numbered N is calculated by the block construction node. The nature of this reward depends on the nature or variation or modality; for example, it may incorporate some portion of tokens previously sent to lockers, or transaction or registration fees, or new tokens generated as part of an inflationary token supply algorithm. The reward value in token form is stored in a temporary holding address for the block, to be assigned to the block building node and locker contributor(s) later in the process. Then, at 345, block N is finalized, and the reference to the previous block (cryptographic hash of the previous block) is stored within block N. The hash is also computed for block N, and the block is propagated to the network. blockchain for suitability assessment. At 350, other block building nodes within the node network evaluate the new block and compare it to competing blocks based on Suitability criteria. Since the nodes implement the same consensus algorithm, if all nodes share access to the information and content of the different competing blocks, they will all independently choose and agree on the same block, whichever has an optimal suitability. At 355, the evaluation nodes determine whether the proposed block or blockchain segment maximizes Suitability and whether the new block numbered N (or the blockchain segment containing this block) has the highest Suitability value. high among competing blocks (or segments of the blockchain). If so, the evaluation nodes accept a new block for the blockchain and I CCCI n / l 7Π7 / Β / ΥΙΛΙ begin building the new blocks for the newly accepted block at 360. Otherwise, at step 370, it is determined that the new block is not the winning block (based on the Suitability evaluation) and is discarded in place of a competing block with a higher Suitability value. Therefore, instead of building on top of the new block, at 380, the evaluation tickets begin to be built on top of an alternative competing block that has a higher Suitability value. Then, the process of building and evaluating the block is repeated for the next block with the number N plus 1 (N + 1), starting at 310. According to at least one embodiment, the block building nodes conventionally incorporate the highest value locker token assignments they encounter. By convention, only the number However, different block building nodes within the same network may prioritize allocation records differently, as long as no more than X locker allocation records are included in any block. Higher stake values ​​improve the chance that the proposed block will be widely adopted and eventually accepted. Evaluating the Suitability of competing blocks or blockchain segments – and selecting the “winning” block or blockchain segment – ​​may be implemented in at least one embodiment according to the following criteria and method. In step (1), the aggregate locker value for the entire block or segment of the blockchain is calculated by incorporating the values ​​of all lockers within all blocks in the segment (this is the “aggregate tokens used” for that segment of the blockchain). In step (2), the “aggregate hash distance” for the entire block or segment of the blockchain is calculated by adding the individual hash distance values ​​for each block within the segment (i.e., the distance between the hash of block, and the winning square for each block, all together). In step (3), the “aggregate tokens used” are divided by the “aggregate hash distance” to generate the Segment Suitability value. Higher Suitability values ​​are preferred. Alternatively, evaluating the Suitability of blocks or block segments may also be implemented in at least one embodiment as follows. In step (1), an aggregate locker value is calculated for each individual block (in other words, the value of “aggregate tokens used” would first be calculated separately for each block in the segment). In step (2), an individual Fitness value is calculated for each block by dividing the blocks' aggregate locker value by the hash distance of that individual block. In step (3), the Suitability values ​​of the individual blocks are summed into a single Suitability value I CCCI n / l 7Π7 / Β / ΥΙΛΙ for the blockchain segment. In other words, for each winning box, divide the box value by the hash distance, then add all the resulting quotients. As in the previous approach, larger fitness values ​​will be favored. Either of the two preceding variations can complement the calculation of the value of “aggregate tokens used” by incorporating the value of the use of eligible tokens within the blockchain segment. For example, transfers and token fees paid within the segment would be incorporated in addition to the value of tokens assigned to lockers, so blockchain segments that contain records that move more tokens have a higher Eligibility. Cyclic token transfers or expenditures were completely unknown: within the blockchain segment, any considered token utilization cannot be included in the total if they are transmitted again after a first utilization; If the expense is sent to an address, any expense from that address is subsequently reduced by the amount received, and any discounted amount received is not counted toward the recipient's address. Figures 4A-B illustrate the Locker consensus structure, organization and information stored in a Locker implementation of a Fitness Gradient consensus system and method according to at least one embodiment of the present invention. Each box represents a range of values ​​potentially conforming to the block hash value, which has not yet been determined for a future block numbered N. In other words, each box contains a potential target hash for the block numbered N. Such a target hash for A box can be determined in several ways depending on the modality: it can be the midpoint of the range of values ​​represented by the box, it can be the minimum or maximum value represented by the box, or by some other function that is implemented consistently. on all nodes. An assignment of tokens to a particular locker is a vote in favor of that target hash. Referring to Figures 4A-B, competing users (i.e., token holders) stake the target hash of future blocks by sending tokens to individual lockers. Tokens sent to the locker in the block numbered N minus G (block N - G) that is closest to the block hash value, end of block number N earn a token reward calculated for block number N. Users submit tokens to lockers by generating locker allocation records (specifying locker index, block number, token value, etc.), which records are signed with the private key of the account or address they contributes to the value of the token. I CCCI n / l 7Π7 / Β / ΥΙΛΙ Those records are broadcast block building nodes, so these records can be included in a block that is accepted into the blockchain. The block building nodes will disseminate certain proposed locker assignment records and include them in the new blocks, at least in one embodiment, by sorting the proposed records and selecting the X number of records that assign the highest token value to the lockers. for a particular block. Nodes will discard proposed block allocation records that were not successfully incorporated into previous blocks, and will only attempt to incorporate block allocation record transactions for the current block. Referring to Figures 4A-B, Assignment A 410, which is recorded as part of block N - G (block numbered N minus G), “earns” (or is assigned) a token reward for the block numbered N over Allocation B 420 because it has been committed to the locker with the value closest to the final hash of the block numbered N. Such a token reward may include tokens allocated to other lockers that are not “winners” (i.e. , which are not the N - G block lockers that are closest to the N block hash). In at least one embodiment, lockers may be represented as addresses, such that token assignments may be made by transferring tokens (or by pointing) to such addresses. Lockers can be represented as 440 addresses, so token assignments can be made by transferring tokens to such addresses. In the case shown, a blockchain uses eight-byte block hashes, but may have hashes that are longer or shorted in accordance with other embodiments. In the case of this mode, the first four bytes can be used as a value to describe each slot, thereby limiting the number of slots available, so that there are fewer slots than there are hash values ​​available. In alternative embodiments, either more or less than half the length of the hash may be used to define lockers, up to the size of the entire block hash. In the example shown in Figures 4A-4B, more than two billion boxes may be defined, but in alternative embodiments, more or fewer boxes may be defined. With so many boxes, the closest box with any value may not be the box immediately closest to a hash; The locker chosen will be the storage value of the closest locker. In at least one embodiment, the blockchain may use eight-byte words to represent addresses to or from which tokens may be sent. The addresses within I CCCI n / l 7Α7 / Β / ΥΙΛΙ these blockchains can be distinguished from each other according to their use. Lockers are represented by addresses that are distinguished from contract or user account addresses. Referring to Figure 4A, one way to distinguish such addresses from each other is to use a prefix. For example, the first 462 byte of an address can be used to encode the “locker assignment” address type. If the last four bytes 468 of the address are used to encode the locker (e.g. locker index), then the remaining three bytes 465 can be used to encode the block number to which the stake belongs. In such a configuration, six bytes could be used to represent the number of the block being addressed by the locker allocation record, allowing any of the -16.8 million block generations to be referenced. In other embodiments, the address length may be longer, allowing more block numbers to be accounted for and used. Alternatively, as illustrated in Figure 4B, a fixed locker assignment address 470 may be designated as the destination of any locker assignment transaction, with the block number 480 and locker index 490 as separate fields within the locker record. locker allocation, along with the token amount and the token source account or token source address. In other embodiments, other data may also be included as separate fields of the record. For example, the address type and block number may be included as separate fields within a locker assignment record, such that the locker address itself comprises only the locker index. An example of determining the Fitness Gradient consensus between two competing blockchains A and B for building block N, according to at least one pre-established embodiment of the invention is shown in Figure 5. The decision between competing chains can be handled by a variety of algorithms that take into account the tokens assigned to the lockers, as well as the winning hash distances, in accordance with the present invention. In one example, a system consisting of Block Building Nodes determines which segment of the blockchain has the highest Suitability value, calculated to be £W / ΣΔ, where “W” represents the value of the aggregate tokens used for a given block (i.e., the sum of all locker allocation values ​​and other eligible token usage within the block), and “Δ” represents the hash distance for a given block. As illustrated in Figure 5, a build node of Block numbered N must decide between building on Version A 510 or Version B 520 of block numbered N minus one (Block I CCCI n / l 7Π7 / Β / ΥΙΛΙ Ν-1), whose blocks are at the terminal ends of the Version A and Version B blockchain segments. In other words, these two versions of the block with number N minus one compete with each other on the network, but only one will be included in the blockchain containing block N. To determine the correct block to build on, the node must calculate a Fitness value for each segment of the blockchain other than the one being evaluated. In the example shown in Figure 5, the Version A blockchain segment 510 has weight = (5,000 + 2,000 + 5,000 + 1,200) / (100+100+200+100)=^13,300! 470 = 28.29. The 520 Version B chain has a weight = (5,000 + 2,000 + 8,000 + 1,000) / (100+100+100+50)= 16,000 / 350 = 45.71. Therefore, the Version B string has a higher Fitness Gradient value. Once a block builder node is informed regarding both chains, it will build block N on chain 520 of version B due to its higher Suitability value. Version B of the block numbered N -1 is referenced by the new block numbered N that is constructed, thus growing the chain. For each block in Figure 5, Δ is determined by comparing the block hash, of each block with the locker allocation records of the block located at G number of blocks before evaluating the block. Since the value of Δ depends on having knowledge of the block hash, it is not computed by the block construction node that constructs the block it describes, but is instead computed by the node that constructs the next block. The Δ value of the block numbered N will be incorporated into the block numbered N plus 1, so the Δ value of Block N in Figure 5 is unknown. Figure 6 illustrates the information that can be stored in a block according to at least one embodiment of the present invention. The block may contain such information as a Pointer to the Parent Block or to a Parent Block Hash 610, which connects the block to its preceding (i.e., parent) block. It may also include a Parent Block Stake Reward Allocation 620, i.e., an allocation of rewards in token form to accounts that made locker allocations that were used to determine the eligibility of the previous block (i.e. , father). It may contain a Preserved Calculation Δ for the Parent Block 630, which is the hash distance value calculated for the preceding (i.e., parent) block. Standard transactions and contracts 640 can be placed in a block or indirectly included as a pointer or hash to the current data. The block may also include Locker Assignment Transactions 650, that is, locker assignment records that are used to calculate the eligibility of a future block. It can also include a I CCCI n / l 7Π7 / Β / ΥΙΛΙ Reward Transaction for a Construction Node 660, which assigns the portion of the reward to the block construction node that generated the block, and a Winner Reward Placeholder 670, which would temporarily store the reward to be assigned in the next block to the box contributors who helped determine the Eligibility of this block. Finally, it may contain a Block Hash Value. 680, which is a cryptographic hash of all the other elements in the block. The blocks are built to form an internal structure that is verifiable. Data within a block must be ordered deterministically, so that two blocks containing the same data must always be identical. Within a block, standard transactions and 640 contracts can be recorded independently of the data relevant to the Consensus Algorithm information. This means that this consensus algorithm should be able to support various application functionality that can be implemented on top of it. Depending on the specific implementation of the blockchain, each block building node may be allowed to assign some portion of the aggregate block reward to its own address 660. The reward to be assigned to the winners of this block must be assigned to a placeholder address 670, due to the fact that the receiver is unaware until the hash value for the entire block has been calculated. The subsequent child block will distribute this reward. Alternative Box Consensus Method Another version of the Locker Consensus algorithm and method according to at least one embodiment of the present invention is a variant such that there is no single winner to whom locker rewards are assigned. Rather, all accounts that allocate tokens to lockers can potentially receive rewards. In this variation, the target hash is determined by the locker that has received the highest allocation of tokens among all lockers. As in the preceding version of the Locker Consensus described above, each block allows up to X number of locker allocation records, each record having a token allocation value w. In this scenario, however, the locker that has the highest aggregate token allocation £w is designated as the target locker, representing a target hash value T. In at least one embodiment, the locker allocation records for the block at height N minus G (block N - G) are used when the block at height N is formed to determine what the target hash value is for that block. . For example, the midpoint of the locker with the highest token allocation value in the block at height N minus G would become the hash I CCCI n / l 7Π7 / Β / ΥΙΛΙ target for the block at height N. Among all the potential new blocks generated by the block building nodes, the block that has the closest hash value to that target hash T is most likely that the nodes in the network use it to build the next block at height N plus one. In at least one embodiment, the reward is distributed proportionally to all accounts that contributed tokens to lockers in that block. The new block created at height N plus one will contain a record or records that proportionally distribute token rewards for the previous block at height N to those accounts that originated the locker assignment records included with the block at height N minus G. Each account will receive a proportional allocation of the reward depending on the size of the allocation it made to the lockers in that block. Some portion of the token reward may also be allocated to an account designated by the network node that assembled / built the accepted block N. In at least one embodiment, the reward would consist of the same rewards that would be included in any block within an implementation of the Suitability Consensus, including token fees included in various records and transactions, fees used to pay for execution of the smart contract. , and any new tokens generated as part of an inflationary token supply algorithm. However, the tokens that contributed to the lockers would not be included in the reward, but will be returned to the accounts that originally contributed. Unlike the previous version of the Locker Consensus described above, users in this scenario are not incentivized to allocate tokens to lockers in pursuit of a large reward, at the risk of losing all allocated tokens. Instead, users are incentivized to lock tokens in lockers for the G number of blocks due to the guarantee that they will receive a portion of the block reward after the locking period has ended. By locking these tokens, the blockchain is protected, because any parallel competing chain or chain created in a double-spending attack will need to have access to a greater number of unique tokens than those that contributed to the blocks generated within the locking period. . Hash Distance Consensus Without Lockers In another variation of the Hash distance consensus according to the present invention, users do not assign tokens to lockers. Instead, users lock their tokens for a period of time in exchange for a portion of the reward. i ccci η / ι znz / E / YiAi Unlike the Locker consensus variation of hash distance consensus described above, locked tokens do not influence the target hash at all. But, similar to the Locker consensus method, the aggregate value of the tokens locked in this modality contributes to the calculation of the Eligibility value of a block or subchain. Suitability is established by comparing the hash of individual blocks on a proposed chain to an appropriate target hash for each block, and combining that hash distance value via some function with the total tokens allocated within the chain. The target hash in each case would come from an on-chain source; for example, the target hash could be a transformation of the block hash already computed for the block that occurs in some number G of blocks before the current block. To illustrate: let the total token allocation, S, within a segment of the blockchain equal Σδ, the sum of all native tokens allocated within each block of that segment. Let the total hash distance, D, within the blockchain segment be equal to Σd, the sum of the individual distances between each block's hash and the target hash for all blocks in that segment. Then, the blockchain segment chosen to build can be determined by choosing the chain with the largest S / D value (i.e., the largest Σθ / Σά value), which would be considered the Suitability value for that segment. In another embodiment, the chosen block can be determined by choosing the chain with the largest value Σ(δ / ό). In other alternative embodiments, the chosen block may be determined by choosing the string with the largest value (Σθ / Σ^+ο)0) / where the values ​​a, b, c and j are constant or known in some other deterministic way at each iteration based on the state of the chain, in a manner agreed upon by the network. In another variation, the suitability of a blockchain segment is determined by a function f(si, S2, S3, S4,... Sy, Sz, di, da, da, d4,... dz, dz ), for blocks 1 through Z within that segment. The hash distance d,in this variation, as in other variations, is the absolute value of the difference between the block hash,i,being evaluated and the target hash. The target hash is determined by some fixed algorithm capable of determining the target before consensus evaluation is performed. In at least one embodiment, the target hash for the block numbered N would be the cryptographic hash of the block hash already computed for the block numbered N minus G. In at least another embodiment, the target hash of the block numbered N, tN, would be the actual hash of the block numbered N minus G above, plus some predeterminable offset c, according to the formula: I CCCI n / l 7Π7 / Β / ΥΙΛΙ dN= |hN— hNG| +c Fitness Gradient Consensus Using Space and Time In another variation of the Suitability gradient consensus according to at least one embodiment of the present invention, users do not assign tokens to lockers, and the use of a hash distance value is optional. Instead, the fitness calculated for each block depends mainly on the number of computing steps performed by the processing registers within the block (time), the amount of data or the number of registers in the block (space), and / or the value of the unique tokens within the block. The modality by using the Suitability Gradient Consensus method by using size and time, which is based on the general Suitability Gradient consensus process of the present invention, can implement the following steps, elements and characteristics ( although not all stages, elements and characteristics are required in each modality). First, certain median metrics are collected with respect to each block: (1) A certain value of the “unique token” V, is calculated for each block in the subchain, whose value is equal to a certain number of unique tokens allocated within that block, for example (a) the tokens assigned to the lockers within that block; (b) tokens included as charges for records added to that block; (c) tokens otherwise allocated within the block. Here, as elsewhere in this description, “unique tokens” refers to the “used aggregate tokens” of tokens that have not been transferred more than once, reused or reassigned within a particular blockchain segment. , that is, tokens that have not been recycled between different accounts, and therefore are not measured twice when the aggregated token values ​​are used to calculate the suitability of a particular chain. (2) Some value of size S is computed for each block of the substring, whose value may be equal to the number of records that have been added to the block (i.e., that are encapsulated within its Merkle tree or other data structure ), or it can be equal to the amount of memory occupied by the block, including all the registers it represents. (3) Some execution time value T is determined for each block of the subchain, the value of which represents the number of computational stages required to complete the validation and evaluation of the block, which includes the execution of all smart contracts invoked by the blocks. records within the block. This value would be determined by the actual validation of the substring, in the process of executing all the invoked smart contracts and monitoring all the computational stages. I CCCI n / l 7Π7 / Β / ΥΙΛΙ (4) Part of the hash distance value D is calculated for each block in the subchain, as described elsewhere in the present description. Second, a particular function is defined that accepts these values ​​as parameters—F(V, S, T, H), where V, S, T, and D are ordered lists of the aggregated unique token value, size, execution time and the hash distance values ​​for each of the blocks in the subchain—which function represents the Suitability metric used to determine Suitability for use in the Suitability Gradient consensus process described herein: (1) In a variation of this function, some constant scalar parameters are decided—s, t, d—each of which represents the relative weight given to each of the above dynamic values ​​of the block when added to determine the value of the Suitability metric for the substring, according to the following formula: Í=G If any value is to be discounted completely, then its accompanying constant would be set to zero. For example, if only the unique token quantity and size are used to calculate eligibility, then the values ​​assigned to d and t would be zero. (2) A number of variations of this function could also be used; Some examples of specific formulas that combine all of the above would be as follows (where, in addition to the variables and constants described above, G is the index of the first block in the substring, N is the index of the last block in the substring, and c and k constants arbitrary variables selected to optimize the performance of the Gradient Suitability algorithm): (i) (ii) (iii) f(v,s,t,h)=£ f -- í J k-V¡ c+d-D^s-St+t-T, (iv) (v) C y, Ϊ í j — ____ ’ ’ ’ JL l·. v F(V S T H) = V-----— r ( V > o μ , π / Z-· . „ Xcγ i-n C+S't'b^l i—O I Discounting the Use of Duplicate Tokens; Unique Token Identification In at least one embodiment of the Fitness Gradient consensus or the Hash Distance consensus, the use of counted tokens to determine the “Aggregated Token Utilization” of the blocks and segments of the blockchain, or the activity of assigning Tokens used in any other way as an input to a eligibility calculation, must not include tokens reassigned or reused within the period being evaluated, but must include only “Unique Tokens.” Two blockchain segments or forks that are compared in the context of the Fitness Gradient consensus ultimately trace their origin to a shared branch point somewhere within their history. The evaluation period for the comparison should only include blocks included after that branch point (or a fixed number of blocks preceding that branch point) up to the most recent block being evaluated. The term “evaluation period” is used herein to describe the set of blocks within each of the two segments being compared, which blocks are linked back through subsequent recursive references to the shared branch point, in combination with the blockchain segment of size P that precedes and includes the block at the shared branch point (where P >= 0). Once a token value is assigned to a new address or account within the evaluation period, then at that time that value is included in the “Aggregated Token Usage” value that is calculated. However, no token value can be counted twice within the same evaluation period for a particular chain. When evaluating whether a source address or account contains sufficient token value to allow allocation of its tokens to another address or account, any token value previously allocated to that address or account within the evaluation period will be completely discarded from the contribution. from that token assignment to the “Aggregated Token Usage” value. Additionally, any assignment originating from such address or account will be similarly limited in subsequent assignments for purposes of determining “Aggregated Token Usage” within the evaluation period. Without this limitation, a block building node can build a block with an Eligibility value that is artificially inflated by the same tokens being sent back and forth, or spent and re-spent in fees, by accounts controlled by the block building node. block construction. Rewards Given to Participants in the Fitness Gradient Consensus In at least one embodiment of the Fitness Gradient consensus of the present invention, for each block that is added to the blockchain, a reward in the form of a token is determined according to some function of the record generation activity within the block (token assignments, contract execution, and any other activity recorded within the block). This reward is assigned to one or more accounts chosen by the block building node that created the block, as well as to one or more accounts that may be recipients of mandatory rewards according to the Consensus Algorithm implemented within the modality. specific. The block reward may have a variety of different sources, which may include one or all of the following, depending on the specific implementation or modality: • Brand new tokens that increase the total aggregate token value available on-chain at a given rate per block, which tokens are generated as part of an inflationary token supply algorithm. • The total of individual charges and awards attached to the data records included in the block; Token fees and rewards attached to data records incentivize the inclusion of those particular data records in the block (records without sufficient rewards may not be included). • The termination or revocation of tokens that were originally awarded N minus the number R of blocks before the current block (where R <= N), incentivizing active use of the tokens. • In at least one embodiment of the Locker Consensus, the token values ​​assigned to the locker allocation addresses of the current block N; or alternatively, the token values ​​mapped to the N-G block locker mapping addresses that are used to calculate the hash distance for the N block. Depending on the specific implementation or modality of the Gradient consensus I CCCI n / l 7Π7 / Β / ΥΙΛΙ Suitably, this reward may be assigned in whole or in part to an account associated with the block construction node that built the block, and / or may be assigned in whole or in part to other accounts participating in the consensus process. In at least one embodiment of the Consensus Locker, a portion of the reward is allocated to those accounts that contribute tokens to lockers that help determine the eligibility of the new block, as described elsewhere in this description. “Trust but Verify” Variation of the Suitability Gradient Consensus Another variation of the Fitness Gradient Consensus system according to at least one embodiment of the invention addresses the transactional performance limitations of currently known systems and improves the transactional performance of the blockchain system. One of the recognized obstacles hindering the wide-scale adoption of blockchain technology across a variety of sectors is the “transactional performance” of such systems. The Visa credit card network reports that it handles approximately 1,700 transactions per second on average, with an ability to scale to 24,000 transactions per second. The MasterCard credit card system has recorded similar numbers. The Bitcoin blockchain, on the other hand, cannot exceed 10 transactions per second, and Ethereum can typically process up to only 20 transactions per second. These well-known limitations of proof-of-work systems hinder the broader adoption of these blockchains in financial and other sectors and applications. A major limitation of known proof-of-work blockchain systems (and many proof-of-stake systems) is their linearity. Because the output of each transaction can act as the possible input of each subsequent transaction, all operations must be executed sequentially and all records must be ordered deterministically. Furthermore, the blockchain is organized as a linked chain – a linear sequence of nodes. Therefore, a new block can only be created once the preceding blocks are known. Under the linearity constraint, the maximum throughput of any blockchain can be theoretically projected as the number of operations and records that can be processed in sequence by a program running in a single thread on a computer. Depending on the hardware and software used, this can be hundreds of thousands or millions of operations per second - which can translate into many thousands of transactions per second, depending on the computational complexity of the individual transactions. I CCCI n / l 7Π7 / Β / ΥΙΛΙ Furthermore, in reality, the actual observed performance varies significantly from this theoretical maximum. A number of different reasons explain this difference and explain why known blockchain implementations cannot achieve this theoretical maximum performance. In known proof-of-work consensus systems, most of the computing resources are dedicated to solving the proof-of-work problem. Calculating proof of work creates a delay, but this delay is treated by these systems as a feature rather than a defect. The proof-of-work difficulty targets a specific time delay between blocks, and the difficulty adjusts to sync with that time delay. Well-known proof-of-stake consensus systems, as well as voting and approval-based consensus systems, take the time to coordinate between nodes to decide which node is authorized to create a new block. In practice, these approaches allow for much faster block creation time and higher transaction throughput than proof-of-work systems, but typically at the expense of requiring some form of centralization. Still, even in these systems, the amount of time needed to establish consensus is non-trivial, as it requires the nodes to synchronize their state. Additionally, most of these systems generate some delay between blocks (during consensus and creation), to provide enough time to allow data to propagate. The delay between blocks allows data records and discovered blocks to propagate across the network, typically through a gossip protocol. Among these two categories of data, transactions will constitute the largest proportion. When a new block is created and distributed, nodes within the network will validate the block by executing the transactions it contains. A “trust but verify” variation of the Suitability Gradient consensus according to at least one embodiment is intended to eliminate or reduce several of the known restrictions of known blockchain implementations, and allow system processing of the practical blockchain approaches the theoretical maximum performance (discussed above). An example of the propagation of the propagation block using the “trust but verify” variation of the Suitability Gradient consensus in accordance with at least one embodiment of the invention is described below with reference to Figures 12A-D and 13A-B. In at least one embodiment, the present invention will continue to execute blockchain operations linearly, but will use and leverage computer systems I CCCI n / l 7Π7 / Β / ΥΙΛΙ multiprocessor / multicore / multipu (or clusters) when performing validation processing in a parallel and multithreaded (or multithreaded) software implementation. In at least one embodiment of the present invention, each of the following activities can occur simultaneously and largely independently of the other activities: (a) the main block construction thread, process or coroutine builds on the block with the highest Suitability known to the node among the blocks already disseminated to the network; (b) a thread, process or coroutine continues based on the node's own best previous block that was produced by itself (with inherent validation and confirmation) in case the “winning” thread, process or coroutine cannot be validated (i.e. that is, it is fraudulent); (c) one or more parallel threads / processes rely on the child block, or a late-discovery block, as another backup of the higher-Suitability block; (d) one or more parallel threads / processes acquire from peer nodes all transactions of externally acquired blocks, and then proceed to validate those blocks. By using this Gradient Suitability consensus methodology of the present invention, a node faces a high risk of wasted block construction efforts in the event that a fraudulent block is adopted and not verified as the basis on which it is based. which to start building the next block. Such a fraudulent block must be discarded, along with any work done to build on it. However, as long as the incidence of fraud is low, then the performance of the implementation according to at least one embodiment of the present invention would correspond to the speed of the threads / processes working to construct the next block. Even being within one or two orders of magnitude of the theoretical maximum performance would make the Fitness Gradient consensus variation of the present invention, using the “trust but verify” data propagation method, more efficient and better performing (with respect to throughput) than existing blockchain implementations. Trust but Verify Block Propagation Method using Bloom Filters In at least one embodiment, “trust but verify” data propagation operates as follows. (1) Data records (such as transfer records or trade order records) are not widely propagated across the network prior to block creation. Before block creation, data records are only shared with direct peers, or with peers of peers a specific small number of hops away from the data record generating node. I CCCI n / l 7Π7 / Β / ΥΙΛΙ Each block building node only creates new blocks by using the data records that originate from its close neighborhood. Nearby neighbors push transactions to each other immediately upon acquisition, but at a certain level of removal, the propagation stops. A node would know how many hops a particular data record has taken, because the propagated record would include that information. A node would decide whether or not to forward the data record based on that knowledge, and if the data is forwarded, the receiving node would be provided with an updated number reflecting the extra hop. (2) Newly created blocks are propagated through the network via the gossip protocol, but only certain essential kernel fields are included with such block data. It is a common feature among blockchain implementations that the representation of a block in memory and as a transmittable message (elsewhere called a “block header”) excludes most of the data belonging to the block itself. . In any case, sufficient information is included with each block to evaluate its Suitability and otherwise perform the algorithm, including the block's “Account Bloom Filter” and the calculated Suitability value. (3) As nodes become aware of newly created blocks, low Suitability blocks are discarded, while high Suitability blocks are retained and forwarded forward. Most nodes will converge to the same set of high Suitability blocks. Due to the fact that blocks at this stage are not validated (except by the original creator), there is a possibility that some of these blocks are fraudulent. In the context of the present invention, a “Fraudulent Block” is a block that has been transmitted, shared or disseminated by a block construction node despite being invalid according to the standards and software of the blockchain system. blocks. To mitigate the risk of building on the most fraudulent blocks, block building nodes can retain and build on more than one block for redundancy. (4) Immediately after the block distribution has reasonably stabilized - meaning that the speed of sending high-suitability blocks over the wire has decreased below a certain threshold, measured from the perspective of an individual node - the node will start building the next block on top of the high suitability blocks it has retained. It will create the block by using data records that have been generated locally, or that have been generated in its immediate neighborhood (as described above). i ccci η / ι znz / E / YiAi When a node creates this new block, the node will create a Bloom Filter, which represents all accounts affected during the execution of the block (the “Account Bloom Filter”). Alternatively, two or more Bloom filters can be created, representing the source accounts and the target accounts separately. In at least one embodiment, one or more additional Bloom filters may also be created that represent other data affected by the block that is not associated with any account. The Bloom filter(s) will be included with the block and distributed as part of the sent “block header” message. Accounts included in Account Bloom Filters are those for which some data has been changed within the block with which the Bloom filters are associated. If an account is found within the Account Bloom Filter(s), then it is possible or likely that its state would be modified if the node were to validate and execute the block. However, if an account is not found in the Bloom filter, then it is ensured that the state of that account would not change by block validation and therefore its current state would already be known to the node, even if the node has not yet validated or executed the block. The Bloom filter, according to at least one embodiment of the invention, allows a new block to be constructed without having to validate and execute the previous block to update the account values. Membership of accounts in Bloom Filters can be verified as a smart contract is executed or when a data record is added to the block. Affected accounts are checked to ensure that each account is not contained within the Bloom filter of the previous block. If so, the execution of the contract or inclusion of the record is stopped and discarded from the block. (5) The Bloom filters used can afford a relatively high false positive rate, allowing them to be smaller and faster than in most use cases. Transactions that are discarded from a block can in most cases be included in a subsequent block. Because addresses are generated via cryptographic hashing, their distribution is already randomly distributed over the range of possible hash values. A simple modulo operation has been shown to be sufficient in such cases to achieve a low false positive ratio, without additional hashing, as shown by Jianyuan Lu, et al., in their 2015 paper, “One-Hashing Bloom Filter,” published in conjunction with the 23rd IEEE International Symposium on Quality of Service. Alternatively, or in combination, a compressed Bloom filter can be used to reduce the filter size for transmission. Compression can be done in numerous known ways, including that described by Harvard's Michael Mitzenmacher in his 2002 paper, “Compressed Bloom Filters.” I CCCI n / l 7Π7 / Β / ΥΙΛΙ (6) Simultaneously with the creation of new blocks, in separate parallel threads, coroutines or system processes, the nodes will begin to collect and transmit data records belonging to the blocks of high suitability on which they are built. Data logs can be learned in several ways: (a) If a block originated from a node's direct peer node, then the node will already have those data records. These records would need to be ordered and assembled, and smart contracts would be executed, but the data would not need to be relayed. Once a node has all the records corresponding to a High Suitability block, it will then begin to distribute those records through the gossip protocol. Other nodes that receive these records will retain and broadcast them (or, alternatively, discard them) depending on whether those nodes have also retained the same block. (b) If a node is still missing a transaction, it can then query for that transaction by directly communicating with a node (whether a direct peer or not) that claims to have validated the associated block. (7) As soon as the set of data records corresponding to a block is downloaded, the block validation process can begin. In at least one embodiment, this would occur simultaneously with the creation of new blocks. If a block cannot be validated for any reason (for example, if the Merkle root cannot be reproduced by using the set of data records, or if the block hash is specified incorrectly, or if the data records violate some rule or are otherwise invalid), it is then discarded along with the new block that is built on top of it. (8) To increase the chance of creating the highest Suitability block, a node can work to build the alternative blocks in parallel in one or more separate threads, coroutines, system processes, or computer clusters. A node will broadcast its highest Suitability blocks as they are created, discarding the lowest Suitability blocks. The approach described above could have the following expected impacts in practice: (a) Pop-up localization – certain hub nodes collect activity from certain accounts and other hub nodes collect activity from other accounts; Responsibility for processing records relating to different sets of accounts is loosely and informally compartmentalized across the emerging network topology. (b) Emergent diversification – nodes will exclude accounts from a block if they appeared in the previous block; The implication is that, combined with localization, blocks on the blockchain will alternate as to which part of the network they originate from. I CCCI n / l 7Π7 / Β / ΥΙΛΙ (c) Disseminate records as necessary - records are only propagated throughout the network if there is a high possibility that they will be preserved with the blockchain permanently. The process of propagating blocks using the “trust but verify” block propagation methodology in accordance with at least one embodiment of the present invention is described with reference to Figures 12A-D. In Step 1, as illustrated in Figure 12A, different transfer records are generated or sent by the wallets to various nodes 1201-1206 (1-6) within a network. Each transfer record transfers tokens from one account to another 1221-1226 (accounts represented by letters). For example, node 1201 (1) has a transfer record 1221 that transfers from account A to account C, node 1204 (4) has a transfer record 1224 that transfers from accounts B to A and from account B to C, node 1205 (5) has a transfer record 1225 that transfers from account L to account M and node 1206 (6) has a transfer record 1226 that transfers from account Y to Z. Nodes 1201 (1) and 1203 (3) do not have their own transfer logs. The nodes of the pair relationship are shown by interconnected lines. In stage 2, illustrated in Figure 12B, nodes 1201-1206 (1-6) of the network share records only with their immediate peers. The records 1231-1236 that each node has after sharing with immediate peers are shown as 1231-1236 in Figure 12B. For example, node 1201 (1) shares records with nodes 1202 (2) and 1204 (4). Therefore, it contains within a combined set of transfer records 1231 its own transfer record information 1221 (shown in Figure 12A), for the transfer from account A to C and the transfer record information from neighbor node 1204 (4), for the transfer from account B to A and from B to C. Similarly, the combined set of transfer records 1232 for node 1202 (2) contains information from the transfer record transfers from neighboring nodes 1201 (1) and 1206 (6). Therefore, node 1232 contains the transfer log information for transfers from account A to C, X to Y, and Y to Z. Node 1205 (5) contains the log information of transfers of the neighboring nodes 1204 (4) and 1206 (6), in this way, contains within your computer the information of the memory transfer registers for the transfers from accounts L to M (the original data of the register of transfers 1225 for node 1205 (5) and the transfer log data for transfers from accounts B to A and from B to C (from the original transfer log data 1224 I CCCI n / l 7Π7 / Β / ΥΙΛΙ of neighbor node 1204 (4)) and the transfer log data for transfers from accounts transfers 1226 from neighbor node 1206 (6)). The same methodology is applied to determine the transfer log data 1231,1232,1234, 1235 and 1236 maintained within the computer memory by nodes 1201-1206 (1-6). Node 1203 (3) does not have its own original transfer log data and its only neighbor node 1202 (3) also does not have any original transfer log data. Therefore, there is no combined transfer log data maintained at node 1203, as illustrated in Figure 12B. In stage 3, illustrated in Figure 12C, nodes 1201-1206 (1-6) construct blocks containing the records they know. Each block has a Bloom filter that identifies the accounts contained in block 1241-1246, here shown as a list of accounts (letters) affected by the accounts that are part of the block transfer records shown in Figure 12B. For example, transfer log data from node 1201 (1) affects transfers between accounts A, B, and C, forming a block with Bloom filter ABC (1241), while node 1202 (2) has transfer log data that affects transfers between accounts A, B, C, X, Y, and Z, which forms a block with Bloom filter ACXYZ. Similarly, node 1206 (6) forms a bloom filter block LMXYZ, node 1205 (5) forms a bloom filter block ABCLMXYZ, and block 1204 (4) forms a bloom filter block ABCLM, as is illustrated in Figure 12C. Simultaneously, node 1203 (3) generates or is sent a new transfer record, which will be included in the next block; specifically, a transfer from the Q account to the R account. The use of letters to represent beads and blocks is for illustrative purposes only. In current and other embodiments, the Bloom filter is not a list of letters, or a list of counts, but a standard data structure. In step 4, which is illustrated in Figure 12D, the blocks (formed in Figure 12C) are shared by all node pairs 1201-1206 (1-6) in the entire network. In the simplified illustration of the network in Figure 12D, all blocks are shared with all nodes. Therefore, all nodes in this network include the shared collection of blocks 1251 ABCLMXYZ, ABCLM, ACXYZ, LMXYZ, and ABC. In other embodiments of the present invention, nodes can only share blocks (with account transfer data) if they exceed a certain Suitability value threshold. Also in stage 4, node 1203 (3) shares its new transfer log with its only peer, node 1202 (2). I CCCI n / l 7Π7 / Β / ΥΙΛΙ In stage 5, illustrated in Figure 13A, nodes in the network sort blocks by Suitability, to decide which block to start building from. In this illustration, a simplified Suitability metric representing a “number of records” is used for illustrative purposes. In other embodiments, other metrics may be used for the Suitability metric. In the illustrative example in Figure 13A, each block with a Bloom filter is evaluated based on a Fitness metric that involves the amount of records or accounts included. For example, the block with a Bloom filter ABCLMXYZ is evaluated based on the transfer records included for transfers from accounts L to M, X to Y, Y to Z, B to A. Based on the Suitability evaluation criteria “number of records”, it receives a Suitability score of 5. Similarly, the block with a Bloom filter ABCLM is evaluated based on the transfer records included for transfers from the accounts B to A, B to C, A to C, and L to M, which receives a Suitability score of 4. Blocks with Bloom filters ACXYZ, LMXYZ, and ABC, respectively, are They are evaluated similarly and each receives a score of Appropriateness 3. If node 1202 (2) or node 1203 (3) were to build a new block, they would create a block containing the shown transfer log, transferring the tokens from account Q to account R. If such a block is built in a system by using a linear blockchain data structure 1381 shown in Figure 13B, then the block with the Bloom filter ABCLMXYZ would be used, because it has the highest Suitability value of 5. However, the Bloom filters ABC and LMXYZ do not overlap at all, and when combined, blocks with these Bloom filters have a suitability value / score greater than 6. Therefore, if the new block is built in a system using the using a directed acyclic graph data structure 1382 shown in Figure 13B, then these two blocks would be used. Reducing Denial of Service Attacks Propagated by Fraudulent Blocks As described above, a risk faced by block construction nodes that implement the “trust but verify” block propagation method is that they may begin building a new block on top of a fraudulent block, which needs to discard the work afterwards. when the fraudulent block is discovered. This risk to individual nodes can escalate beyond being a localized risk and can become a system-wide risk if malicious nodes begin transmitting fraudulent blocks en masse. Therefore, an attacker wishing to slow down or disable the network (i.e. use the known denial of service attack) could attempt to send a flood of fraudulent blocks, I CCCI n / l 7Π7 / Β / ΥΙΛΙ in the hopes of overwhelming other nodes with wasted work and slowing down or disabling the operation of the blockchain system. While it is unlikely that such an attack would subvert blockchain data or result in token theft (because all blocks are eventually validated), if too many fraudulent blocks are introduced, network performance could degrade significantly due to to the wasted efforts of nodes built on fraudulent blocks. According to at least one embodiment, the present invention may use various approaches to prevent or at a minimum discourage this type of attack and reduce the risk and effectiveness of such an attack. First, nodes can assign a risk rating to other nodes and can choose to only build on a block without validation if the block has originated from a trusted node. High Suitability blocks created by untrusted nodes would still be built, but only after the data records are downloaded and verification is performed. (1) In at least one embodiment, trust is established when recent blocks produced by the node in question have already been successfully validated. Trust would be lost immediately if a block created by the node is deemed fraudulent, but would be regained if the node in question produces a sufficient (potentially high) number of valid blocks following the detection of a fraudulent block. A variation of this strategy would be a form of “tit-for-tat” strategy similar to that described by Axelrod and Hamilton in their 1981 article “The Evolution of Cooperation.” In at least one embodiment of this strategy, a node that has lost trust in another node would allow that second node to reestablish its trustworthiness through the simple act of creating a valid block. Conversely, after trust has been gained, it would be lost if the node in question publishes a single fraudulent block. Determining the trust status of a node would depend only on recent history, not the node's entire history. Even within the same blockchain network, different nodes may employ alternative strategies to determine trust. It would not be necessary for all nodes to employ the same strategy, whether “tit-for-tat” or some other strategy, since the node's internal decision behavior regarding trust would not need to be part of the global protocol shared by all nodes to achieve consensus. (2) New nodes would automatically be in an untrusted state, so they would have to build reputation to be trusted. At the very least, they would have to do enough I CCCI n / l 7Π7 / Β / ΥΙΛΙ work to generate one or more blocks with a suitability high enough that other nodes are at risk of being built on top of them, depending on the risk threshold configured within those other nodes. Since a new block will be built sooner on top of a block generated by a trusted node (and will therefore be more likely to be permanently incorporated into the blockchain), nodes have an incentive to be trusted (in other words, to satisfy the risk threshold of other block building nodes). (3) In at least one embodiment, each block building node would be identified by a blockchain account address included with any block or blockchain segment that is transmitted. This account address would be the node's reward account address. Each node would cryptographically sign each block it produces using the private key associated with that reward account, preventing unauthorized nodes from damaging the reputation of other nodes. (4) In at least one embodiment, nodes randomly sample untrusted blocks, choosing to spend a relatively small fraction of their computing effort building on such blocks to build trust in new nodes joining the network. This sampling process would ignore the Suitability of the blocks being sampled, in order to more quickly establish whether a new node can be trusted. (5) In at least one embodiment, nodes would share information from trusted nodes with peer nodes. In other words, when a block building node makes a determination that another node is trustworthy, it would share that determination with peer nodes. In one version, the block building node would generate and cryptographically sign a dedicated message declaring that a particular node is trusted, and share that message with its peer nodes. In another version, the node would generate and cryptographically sign envelopes encapsulating non-validated third-party blocks that it shares with its peers, but only in the case that those non-validated blocks originate with (i.e., are cryptographically signed by) the nodes. trustworthy. Peer nodes would extract information about the trusted node from these envelopes, before handling non-validated blocks. Construction Charge In at least one embodiment, the proposed blocks may contain some native token allocation made by the block construction node proposing the block, an incentive for other nodes to go through the trouble of downloading the block records and performing the block. I CCCI n / l 7Π7 / Β / ΥΙΛΙ validation. Such block containing such incentive is hereinafter referred to as “Incentive Block”, and the incentive itself is referred to as “Construction Charge”. In this modality, each incentivized block would contain a construction fee that would be automatically transferred to the block construction node's reward account upon validation of the subsequent block. The source account for that charge would be the account address provided by the node that generated the incentivized block. All of these block headers could then be included as records within the blockchain; If a block is not chosen to build upon, the construction fees for that incentivized block would nevertheless be transferred to the block reward that incorporates the block header records for these discarded low-Eligibility blocks. In accordance with the present invention, the block headers of the incentivized blocks that are not chosen to be built upon could be located or placed in two mutually exclusive locations on the blockchain: (1) embedded in the blockchain itself as “uncle” blocks, similarly referenced to other blocks within the blockchain, but without contributing data records, transactions, or any state modifications to the blockchain, or (2) included among the data records associated with individual blocks, such that the block is known and referenced by the blockchain, but without any of the data in that block being otherwise incorporated into the state of the blockchain. Referencing these incentivized blocks to a new node in this way would effect the transfer of the build charge to the block build node. The size or amount of the construction charge would not be set in advance, but would be chosen by the node transmitting the proposed block. It may turn out that the average construction fee is similar in size to the average data record fee, because otherwise you would not pay enough to include the block header as a reward record within a new block being built. Two counterincentives would act in opposition to each other in practice, discouraging spam and reducing or eliminating malicious denial-of-service attacks on a blockchain. On the one hand, the cost of block diffusion would incentivize waiting to see which competing high Suitability nodes might be spawned by other block building nodes. If a competing node generates a block of higher Suitability, then it does not make sense to discard the token fee to transmit a block of lower Suitability. On the other hand, a node that has built a block with a recognizably high Fitness (as determined by some pre-established threshold) may be incentivized to include a large build quota, to better ensure the propagation of that block. In at least one embodiment, a construction fee would accrue to the reward account of a block construction node only in the event that the incentivized block is evaluated as valid, to ensure that the block construction node validates the block. block before referencing it from the blockchain. If the block contributing to the build fee is invalid, then the segment of the blockchain referencing that block would be invalid; This would mean that the work done by the block building node would need to be thrown away, and that the block building node could incur a penalty through a penalty log (described below), and at a minimum would lose any reward it it would have been won any other way. Since the build charge is part of the block that is used to determine the block hash and therefore Suitability, a decision regarding the size of the charge should be made before Suitability is known (at least in the case where Hash Distance Suitability consensus is used). The existence of this charge, if high enough, can discourage spam, but a malicious attacker can only be deterred by a charge that is much higher than what cooperative nodes are willing or able to include as a charge. . Still, this approach would incentivize nodes to only broadcast their highest Suitability blocks in cases where they can produce multiple blocks simultaneously. Therefore, even if build charges are too low to mitigate the risk of fraudulent spam, they can act to moderate network traffic and reduce the effectiveness of a malicious attack (and therefore its possibility). Penalty Records In another embodiment, the proposed blocks can be accompanied by a token allocation which, unlike the above, would be refunded as long as the block is verifiable. Block building nodes would incorporate this amount at risk as a way of collateral to compensate other Block Building Nodes that use processor time to validate a “Guaranteed Block”, in the event that such block is invalid. This amount at risk would not be a fixed amount; Larger amounts would incentivize the adoption of more risks by block construction nodes that decide to build or not on the guaranteed block. In at least one embodiment, this amount at risk would be incorporated into a penalty register, which the penalty register would include all or some portion of the following: the amount at risk, the I CCCI n / l 7Π7 / Β / ΥΙΛΙ source address contributing to the tokens (the node's own token account address), the block hash, guaranteed, and other block identification information linking the penalty record to the proposed block, the network ID (e.g. an IP address) of the publishing node (plus level -1 peer nodes that may also have the transactions), and would be signed with the private key of the source address. The amount at risk would be “refunded” (i.e., considered unallocated) should the Guaranteed Block be validated and adopted. If the Guaranteed Block cannot be validated, then the amount at risk in the penalty record will be assigned to the block construction node that successfully adds the penalty record to the blockchain (i.e., the block construction node that successfully establishes that the Guaranteed Block is not, in fact, valid). The existence of a penalty record will send the amount at risk to the reward of the new blocks. In at least one embodiment, in the event that the Guaranteed Block is determined to be invalid, the mechanism by which the amount at risk is assigned to a block construction node is as follows: First, the block construction node performs a validation of the Guaranteed Block, discovering that the block is invalid and establishing that the penalty record can be used. Second, the block building node adds the penalty record to a new block, causing the reward available for that block to increase by the amount at risk of the penalty record. Third, in the event that the new block is accepted by other block building nodes and incorporated into the canonical blockchain, the reward would be assigned, at least in part, to the account of the block building node that generated the block. new block, and the balance of the account that contributed the tokens to the penalty record would be reduced by an equal amount. However, to confirm that the block containing the penalty record is valid itself, other block construction nodes will attempt to refute the penalty by successfully assembling, validating, and executing the data records that contribute to the formation of the Guaranteed Block by which is referenced in the penalty record. A penalty record that references a Guaranteed Block that is not invalid would not be valid in itself and its inclusion would invalidate the block containing it. If the block containing the penalty record itself is secured by a separate penalty record, a finding that the first penalty record is invalid would make the second penalty record valid, making its amount at risk available for inclusion in a block reward. If no block building node finds that the Guaranteed Block associated with a particular penalty record is invalid, then that penalty record would simply be discarded. In an alternative embodiment, a node requesting block details from a second node could include its own account address in that request, causing the second node to generate and sign a block header that explicitly transfers a “directed charge” to that address. . If a node does not trust the block created by another node, in the standard case it will download the constituent data records of the untrusted block and validate the block before attempting to build on it (as described above). If the node sees that the other node's block has a very high Suitability level, and yet wants to start building on the block without performing validation first, it can request that the node issue a “directed charge” via a registry. special that points to the block. Such a directed charge record would function as a type of penalty record, sending tokens to the receiving node's account only in case the newly proposed block (a Guaranteed Block in this case) is invalid. Otherwise, the directed charge will be dismissed. Non-Linear Block Arrays Enabled by Trust But Verify Block Propagation When operating within the confines of a linear blockchain, Suitability Gradient consensus and variation or the “trust but verify” approach to data propagation can significantly increase the performance of a blockchain system or network. block chain. In addition to these improvements, further performance increases can be achieved by optimizing the blockchain data structure. In at least one embodiment, linearity limitations can be overcome by allowing multiple subchains or segments of the blockchain to be included with the main blockchain data structure in parallel, transforming it into a directed acyclic graph (DAG). It should also be noted that not all currently known distributed ledger systems use linear blockchains as such. Some well-known blockchain implementations use network or mesh data structures, and others use directed acyclic graphs (DAGs). The “trust but verify” block propagation methodology and variation of the Suitability Gradient consensus according to at least one modality further improve the feasibility i ccci η / ι znz / E / YiAi and usefulness of a data structure DAG to organize the blocks, compared to what has been known and used in the past. (a) Because all nodes are continually building and potentially transmitting alternative blocks and subchains, the number of already existing subchains or blockchain segments eligible for inclusion in the blockchain / DAG increases. The Fitness Gradient consensus methodology in at least one modality provides a context by which these candidates can be ranked, such that the best fit among them can be included with the main chain as part of the DAG (assuming a certain upper bound on as to how many substrings can be included). (b) At least one modality of the “trust but verify” block propagation methodology has an effect of records being processed massively in parallel across the network. Because different nodes in the network are working on records associated with distinct and mutually exclusive sets of accounts (as enabled by “trust but verify” through the use of Bloom filters), the occurrence of unique calculations is not duplicates increases substantially. The more shared blocks that originate from different places on the network, the greater the chance that unique combinations of records will be included as parallel subchains in the blockchain. (c) Because “trust but verify” block propagation requires that each block contain a Bloom filter that represents the set of accounts with which it operates (i.e., that are affected by its inclusion in the chain of blocks), two blocks or subchains can be quickly compared to determine whether they are both traded on either of the same accounts. Comparing Bloom filters can provide certainty that the two chains do not work on any of the same transactions. (d) Since transactions are not propagated immediately, but are dumped after a block is accepted, different regions of the node network are likely to know about different transactions, making it easier to combine two blocks when they are generated in different regions of the network, as they are less likely to share the same transactions (addressing a specific problem discussed by Lewenberg et al.). The Suitability Gradient consensus method when combined with the “trust but verify” data propagation variation described above, can implement the following stages, elements, and features (although not all stages, elements, and features are necessary in each modality). I CCCI n / l 7Π7 / Β / ΥΙΛΙ (1) Under the “trust but verify” data propagation described above, Block Building Nodes add the records and transactions they generate to their own blocks and share those records and transactions with immediate peers. Transactions may also be shared with peers of peers, and peers of peers of peers, etc., to a point, depending on the specific implementation or embodiment of the present invention. A node will build blocks containing primarily “local” records that were built by that node or its peers. (2) Block building nodes with these “local” records and transactions, updating Bloom filters to reflect the send and receive accounts referenced by these records and transactions. Nodes with sufficient computing resources can build multiple blocks simultaneously, in at least one modality with mutually exclusive sets of accounts being affected, using Bloom filters to ensure this separation. In at least one alternative “Trust but Verify” block propagation mode, Block Building Nodes, Wallets, and other network participants that generate new records and transactions can share those records and transactions with any Block Building Node. Blocks. However, accounts and addresses are identified as being associated with certain Block Building Nodes, which are considered your “local” nodes. Records and transactions are preferably shared with the “local” nodes of the accounts referenced within those records and transactions, thereby concentrating the occurrence of records and transactions referencing those accounts in the blocks. generated by “local” nodes and their peers. This leads to less overlap between blocks with respect to the accounts they affect, and a lower chance of any two blocks conflicting with each other. (3) Nodes broadcast block header details (but not individual records or transactions contained in the block) throughout the network. In at least one embodiment, nodes may optionally include some block charge amount or token amount at stake to incentivize other nodes to begin building on the block. (4) Nodes evaluate all blocks that were disseminated without (in most cases) downloading and validating detailed records. Bloom filter comparisons allow nodes to choose a number of new blocks that operate on sets of mutually exclusive accounts. More technical implementation-specific details for comparing Bloom filters can be found in the I CCCI n / l 7Π7 / Β / ΥΙΛΙ CISE 2004 technical report by Agarwal and Trachtenberg, “Estimation of the number of differences between remote sets.” Nodes choose the combination of the mutually exclusive blocks with the highest Combined Suitability, up to a certain limit of parallel chains (i.e., maximum DAG width). The nodes begin to build the new blocks on these subchains by executing the records that operate on the accounts not found among the selected subchains, as determined by comparison with the Bloom filter. With the implementation of the present invention, there is a relatively high probability that if a record is rejected after being compared with the Bloom filter, then that record is already in the chain but has not been removed from the record set because validation is still has not continued. (5) Nodes may construct alternative blocks in parallel on different blocks or combinations of blocks, consistent with the “trust but verify” block propagation methodology described elsewhere in this disclosure. In other words, nodes can create new blocks in parallel, and new blocks can have subsequent references to one or more subchains. Building a variety of block combinations helps mitigate the risk of a fraudulent block being introduced, because if the main worker thread needs to be disposed of, another worker thread might be able to collect the task and continue processing the blocks. construction. This node build includes building against the previous generation's own node block. In at least one embodiment, each node would always have at least one thread, process, or coroutine construct in the highest fitness chain that the node has fully validated. (6) In parallel with the construction of the new block, all transactions for the block(s) with the highest Suitability are downloaded and the various blocks are validated. The included records are removed from the record set. If at any time it is discovered that a block is invalid, or that the records cannot be obtained, then the effort to build on that block is terminated - which includes efforts to build blocks on top of that fraudulent block in combination with other blocks. The main build effort becomes the effort that is built on the combination of blocks and segments / subchains of the blockchain with the next highest suitability. I CCCI n / l 7Π7 / Β / ΥΙΛΙ Once all fraudulent blocks (if any) have been discovered and discarded and all remaining blocks have been validated, the optimal combination of blockchain segments / subchains can then be used to construct a maximally optimized block (if any). this has not yet occurred due to the parallel efforts made to build the new block). (7) The new block that is eventually constructed and broadcast to the node network will point to all contributing blockchain segments / subchains through multiple previous references embedded in the block header. Among the contributing substrings, the particular substring that has the highest Suitability will be considered the parent string. In at least one embodiment that combines this DAG-enhanced “Trust But Verify” block propagation methodology with hash distance consensus, when hash distance calculations are performed to determine Suitability, the target hash will be found by counting the blocks backward along the main chain until the source of the target hash for that block is identified. Reducing Denial of Service Attacks Targeting Non-Linear Block Arrays Trusting but verifying consensus variations of the present invention that employ non-linear block arrangements may be susceptible to a particular “denial of service” type attack that would significantly reduce the performance of a blockchain implementing such consensus strategies. Specifically, an attacker can create a series of records that originate from (are signed by and assign tokens from) or end with (assign tokens to) a single account, but are distributed to a large number of nodes operating on the network. . If the charges included with those records are high enough, they can then be included in a large number of new blocks or subchains simultaneously. Trust, but verify consensus variations of the present invention that employ non-linear block arrangements take advantage of the fact that if two blocks or segments of the blockchain produced simultaneously do not contain records operating in the same accounts - in other In other words, if the accounts referenced in both the blocks and the blockchain segments are mutually exclusive - then either the blocks or the blockchain segments can be used by a new block to build the block. simultaneous in the expansion of the blockchain. However, if almost all nodes attempt to produce blocks that reference the same account, then the number of contemporaneous blocks or blockchain segments that can be added to the chain I CCCI n / l 7Π7 / Β / ΥΙΛΙ blocks will be severely limited. Among the blocks and segments of the blockchain that refer to that account, only one - the most suitable - will be included, giving an advantage to blocks that would otherwise be less suitable and do not reference that account. (for example, blocks created by an attacker attempting to exploit this feature). There are a variety of strategies that could be employed to mitigate this risk, or at least to create strong incentives against this type of behavior, increasing the cost of such an attack. To that end, the Gradient of Suitability consensus, according to at least one embodiment of the present invention, may implement the following steps, elements and characteristics (although not all steps, elements and characteristics are necessary in each embodiment). (1) Accounts can optionally specify in their on-chain profile data or configure a short, prioritized list of preferred block building nodes. Additionally, statistics can be maintained regarding the frequency of records referencing each account (e.g., a total reference count or a reference count within the last 100 blocks, etc.). In at least one embodiment, for high-volume accounts (e.g., merchant accounts and business accounts), any records referencing those accounts may be required to be sent directly to or forwarded to the preferred nodes, if those nodes are online. . Only the preferred nodes of these accounts would incorporate such records into their blocks, because other nodes would want to avoid the risk of their blocks not being added to the chain. (2) In at least one embodiment, if a particular record references two high-volume accounts, and if both accounts designate different preferred nodes, then the record may be forwarded to the preferred node of the account that records among its usage statistics a increased volume of on-chain activity (measured by the number of registrations or total charges added). Alternatively, the record can be sent to all preferred nodes listed by these accounts, whose nodes can compete with each other for the block they produce to be accepted on the blockchain. As long as the nodes attempting to include such records are limited to a small fraction of the number of active block building nodes in the network, overall performance should not decrease as a result of too many conflicts arising from new blocks containing the same record. (3) A block building node may require explicit registration for accounts, so that if an account does not register with that node, the node will not accept registrations that reference that account. Such registration may, in at least one embodiment, require some real-world identity confirmation through offline channels. It can also match that node which is listed among the preferred nodes for the account in question. In at least one such embodiment, an account would register with a limited number of nodes, and if the account signs transactions that have been included in different blocks issued by too many nodes, then the account may lose its registration. (4) In at least one embodiment, a block building node may maintain a blacklist of accounts that it will not allow records to reference; Any record referencing such accounts would be discarded and not included in any block that is built by that node. Accounts that end up on that blacklist may, in some implementations, be accounts referenced by a competing block and thus result in a block or segment of the blockchain constructed by the node in question being lost. to another block. Alternatively, accounts that end up on the blacklist may be those accounts that repeatedly (with a frequency that exceeds a certain threshold, or with such frequency that it cannot be counted at random) send tokens to an account that also sends or receives tokens. in contemporary blocks built by other nodes in the network. (5) Some implementations of block building nodes may reject a record that has been signed by an account if recent records signed by that account have been disseminated and incorporated into blocks by other nodes. A block-building node will benefit if an account is loyal, because if records referencing that account occasionally appear in competing blocks, conflicts between blocks will be more frequent, and it will be more difficult for that node than its blocks or segments of the blockchain are satisfactorily accepted by the rest of the network. In an extreme example, if a particular account only sends its records to a block building node, then that account itself will never be the cause of any conflicts that could result in blocks built by that node being rejected. However, this arrangement may not be beneficial for accounts as it may reduce the likelihood of their records being added to the blockchain by not appearing in enough proposed blocks. (6) In at least one embodiment of the present invention, a record may include a reference to a recent block in the chain to which it claims to belong, and an expiration block height beyond which the record would no longer be viable. . A system-wide maximum expiration window can also be specified so that a record cannot be added long after its reference block has been created (regardless of the expiration height specified within the record itself). This approach would force a record to belong to a segment of the blockchain that contains the reference block, whereby the risk of the same record existing in more than one segment of the blockchain would be limited so that it would only belong to segments of the blockchain that fork from the reference block before the expiration window has passed. In at least one embodiment, it may be necessary that records signed by a given account have to point to blocks within the same segment of the blockchain that contains other records signed by the same account - meaning that all signed records by an account would exist within the direct ancestor blocks of any block containing other records signed by the same account, and not within a parallel blockchain segment within the DAG. For some of the above strategies to work, they would have to be employed by every block building node on the network and implemented in the blockchain software used by each block building node. For example, strategies that require modifications to data representation, or that require information or configuration to be attached to on-chain data objects such as accounts (preferred node storage, record counts) and records (block reference storage , expiration height), would have to be provided by each node within a modality. However, for other strategies to work, they do not all have to be employed by each block building node in the same way. Certain block building nodes may employ some strategies, while others do not, and different nodes employing the same strategies may have different tolerance levels or configurations related to those strategies. For example, some nodes may use aggressive blacklisting, while others do not; some nodes may refuse to handle logs not associated with registered accounts, while others do not; and some nodes can only handle accounts that list them as preferred nodes, while others can process any logs they receive. Hash Distance Consensus Optimization through Participating Nodes An important property and characteristic of the Fitness Gradient consensus and the “trust but verify” block propagation variant described herein is that the specialized hardware most capable of accelerating the process beyond the current performance limits will be the hardware that is best able to accelerate the entire spinning code that resides within the smart contracts, and the code you used to validate the new blocks. Devices similar to Bitcoin ASIO chips - “Application Integrated Circuits Specific” that specialize in performing proof-of-work calculations quickly – improve the performance of only one aspect of the block construction process in current systems – specifically, the cryptographic hashing process used to discover proof-of-work solutions – and they may not provide sufficient competitive advantage to justify their cost and use for other purposes. The Gradient of Suitability consensus of the present invention in at least one embodiment provides the incentive to develop and improve specialized hardware for other calculations, including generic calculations. Advances and improvements in such hardware would be widely beneficial in a wide range of contexts, aside from blockchain consensus algorithms. When implementing Hash Distance consensus, an improvement in a node's hashing rate will increase the chance that it will build high Suitability blocks, by increasing the rate and number of valid blocks the node can build. However, as the hash distance approaches zero, there are diminishing returns to scale for such an effort. Repeated iterations of hash distance calculation can reduce the block hash distance through random search. At each iteration, the contents of the block only need to be modified in small ways - for example, by modifying the metadata of some trivial data records - so that very different hash distance values ​​are calculated. However, the probability that each subsequent attempt will discover a particular variation of the block's content that produces a hash distance better than any previously discovered decreases as more attempts are made. On the other hand, during the time it takes to perform such calculations, network participants continue to use more tokens by spending and transferring more tokens, distributing more charges, and allocating the tokens to lockers (in the case of a consensus implementation Locker). Any iterative attempt to improve the hash distance as described above regardless of whether or not hardware optimization is used - would be overridden by the generation of these registers, and would have to be reconfigured to incorporate these new registers. Therefore, trying to get closer to zero distance by optimizing the hashing operation becomes less valuable as the number of new registrations and broadcast transactions across the network increases, and as more tokens are used. The tipping point might be closer to zero for hardware-accelerated iterative searches, but it's still there. The tipping point at which an iterative search for lower hash distances is no longer worth the effort may be closer to zero when using hardware acceleration of hash operations, but in any case there is a limit beyond I CCCI n / l 7Π7 / Β / ΥΙΛΙ than it makes more sense to move to the next block instead of trying to optimize the current block. Basic randomization across the entire network, with all block building nodes operating in parallel, can result in hash distances very close to zero for the highest Suitability blocks, and while hardware optimizations can drive this number down , such an effort would likely not have the same benefit as optimizing the execution time of smart contracts and other essential block construction operations. To optimize suitability within the hash distance consensus, an accelerated random search across the space of possible data records and block / subchain combinations - performed by creating new block and data record combinations as these elements are become known by block building nodes - not only will it optimize hash distance (randomly creating new blocks with hash distance values ​​closer to zero), but it will also optimize unique native token values. It is the combination of these two values ​​that contributes to the Hash Distance Suitability formula and the efficiency and speed of the method. Therefore, hardware acceleration of hash operations is handicapped by massively parallel ordinary computing resources capable of computing Turing complete contracts. This trend allows Suitability Gradient-driven blockchains implemented in accordance with at least one embodiment of the present invention to provide additional monetary incentives to improve overall computing speed. Investing in accelerating Turing-complete smart contracts is not an optimization with is the only application that is blockchain performance, as Bitcoin and Ethereum specialized hash accelerators (ASICs) are, but would be widely valuable for improving computing speed in all applications. Fitness Gradient Consensus with Time Delays In another variation of the Gradient Fitness consensus of the present invention, it incorporates specific time delays into the block generation process. Each proposed block (including blocks added subsequently) would meet a specific time segment. Such a time segment can be defined in different ways: • The time segment can be defined in terms of clock time - described as an offset against a particular point in time, or called some standard way in relation to timing standards (UTC, etc.) I CCCI n / l 7Π7 / Β / ΥΙΛΙ • The time segment can be defined in terms of a number of essential computing units or stages required to be executed in sequence • The time segment can be defined in terms of a proof-of-work assignment with a certain level of difficulty, which will take a certain expected amount of time to execute on average. The number of records accepted in a block (i.e., block size) would be limited relative to the length of the time segment. Each block would be allowed to include records corresponding to a particular execution time. Only a number of records will be accepted in the block that represents an execution time that matches exactly or approximately some fraction Q of the total duration of the time segment. Alternatively, each block would be allowed to include records corresponding to a particular expected total transmission time across the network (being both a function of network latency and data size). Only a number of records that can reasonably be expected to be transmitted over the node network within a fraction Q of the total time segment duration will be accepted in the block. In another embodiment, both the expected execution time and the transmission time would be taken into account when determining the maximum block size. Only so many records will be accepted in the block that can be expected to be transmitted across the network of nodes and then subsequently executed within some fraction Q of the total segment time duration. The fraction Q of the total segment time duration, which fraction is used to determine the block size, would be set to allow nodes to validate competing blocks and chains by interpreting the records they contain. Sufficient downtime must be available within the block construction process to allow a node to traverse a long history of older blocks and catch up with the current block within a reasonable time frame. In at least one embodiment of the present invention, each node will build the new blocks on top of whichever chain has been found to have the highest fitness value. The process of finding the string with the highest Suitability value will be as follows. (1) Nodes will pass to each other the Suitability value (and other identifying information) of the chain each is currently building (i.e., the highest Suitability chain that each node has fully validated). Additionally, nodes can also share I CCCI n / l 7Π7 / Β / ΥΙΛΙ information about the highest Suitability chain that they know, but have not yet been able to validate, along with the address of the node that advertises that chain. (2) In the event that a node is aware of a chain that is of higher Fitness than its current chain, it may request that chain be downloaded from the node advertising that chain (or the portion of that chain or segment of the chain). block chain that deviates from the already validated chain of the requesting node). (3) Upon receiving data from the new chain (which includes all records), the requesting node would interpret all records in sequence until it can confirm that all blocks (and contained records) are valid, and that the suitability of that string is actually larger than any other string you have validated (especially your current active string). (4) Due to the fact that this validation process may result in the new competing chain being rejected - because it is invalid, or because the advertised fitness value was incorrect, or for some other reason - a requesting node (validator ) could simultaneously continue building its already validated higher suitability chain. Each new block that is constructed will begin to be constructed only after the required time delay (i.e., time slice) for the previous block has passed. (5) The current chain of a node would only be replaced at the time when the validation of the competing chain has been reached with the same block number as the current chain, so that the new chain can be used without problems for build a block and the appropriate time segment. In at least one embodiment, the required time delay between blocks may be enforced by requiring a minimum time gap between blocks, or requiring a maximum number of blocks to be included in the blockchain within a certain amount of time. In this modality, each block would identify the date and time of its creation and inclusion in the blockchain (i.e., its timestamp), from the first block to the last. A segment of the blockchain or blockchain would be considered invalid (1) if the separation between the blocks fell below a certain threshold, or if the number of blocks in the chain exceeded the number of blocks expected for the timestamps included with the blocks; or (2) if the most recent blocks at the end of the blockchain did not align with the current time, as the block building node understands it. Similarly, new blocks that are evaluated by the block construction nodes would only be valid (1) if the timestamp of each block is within some threshold of the current time as understood by the block construction node, and (2) if the brand I CCCI n / l 7Π7 / Β / ΥΙΛΙ block time is not too close to the timestamp of the preceding block in the blockchain. Any invalid blockchain, blockchain segment, or block will be discarded in lieu of an alternative, valid blockchain, blockchain segment, or block. In at least one other embodiment, the time delay may be applied by requiring that the blocks include a proof of work that is of a level of computational difficulty that would be executable on an amortized basis within the amount of time represented by the time segment. A block would be valid only if (a) the difficulty represented by this proof of work corresponds on an amortized basis to the duration of the time segment, and if (b) the block has satisfactorily completed the proof of work, as demonstrated by the nonce and the block hash. In at least one embodiment, the mandatory time segment duration imposed by the methods described above may change depending on the computing and network performance of the blockchain system. If more or less time is required for block construction and block validation calculations to be performed, or for data to be shared across the network, then the length of the time segment can be increased or decreased. Such changes to the length of the time segment would cause a change to the minimum time gap between blocks, the maximum number of blocks that can be included in a blockchain segment for a given amount of time, or the level of difficulty. of a proof-of-work problem used to separate the blocks. The fraction Q of the total time slice duration used to determine the block size must be carefully chosen so that it is computationally possible for a node to construct new blocks in real time according to the slice time schedule, while the node simultaneously validates a competing string of some length L that can replace its current active string. The validation process must continue at a faster pace than the block construction process; any other way, it will never reach the current block. For example, if the fraction Q is 1 / 3, then it may be possible for a node to validate a subchain of length L=6 blocks within approximately the same time it would take to construct two new blocks and add them to the node's current chain, assuming the parallel execution of both processes. Similar timing issues would also affect the startup of a new node joining the network (i.e., a node that does not have any blockchain or registry data). A new I CCCI n / l 7Π7 / Ε / ΥΙΛΙ node that logs into the network must obtain all blocks and records from the blockchain that have been accepted by its peer nodes in the network. Although there may be some variation between peer nodes regarding the most recent blocks in their individual chains, the set of largest and most overwhelming blocks returning to the origin of the chain must be identical. This can be done by retrieving block data and register data over the peer node network, or it can be done by installing a data wrapper that encapsulates the data in the block in an out-of-band manner (e.g. by copying such a data packet from a USB drive or other physical media, or by downloading the packet from some server over the network). In any case, a node must validate that all such data is correct and execute the smart contracts and process the data to create a local runtime instance of the global state of the system. This is likely done by running all log history and smart contracts on-chain in sequence. Until this has been completed, the data should be considered potentially invalid or even malicious. However, once completed, the node can treat this third-party blockchain and registry data as valid and verified. After the initial download of the new node's reset block and related data, the rest of the network will add the blocks at a constant rate. As a result, even after the new node has completed verification and validation of the reset data, that new node will have to download and verify the new blocks, logs, and other data generated since that initial download. The value of Q will determine how far along the rest of the network will have been running by the time the new node has completed its verification of the blockchain and related data, as a function of the length of the blockchain at the time. time of initial download. The value of Q will also determine how long it will take for the new node to fully reach the current network state after verifying the initial data. The order in which different types of records may be evaluated for incorporation into a block may be limited by the requirements of this variation. If there are some operations that must be executed before finalizing the block - and which may directly involve the creation of additional records and additional stages of execution - then these elements should not be left at the end of the block creation / execution process, and should be processed at the beginning of the process. I CCCI n / l 7Π7 / Β / ΥΙΛΙ Other records that may be optional and could be included / interpreted / evaluated at the end of the process, so that they can be skipped or cut in case the maximum block size is reached. For example, locker records are a mandatory part of the Locker consensus algorithm, so they must be incorporated first or at least near the beginning of the block creation process. For example, in at least one embodiment, trade settlement and matching records (described elsewhere herein) may be considered mandatory parts of any block when trading is implemented. The implication of performing trade reconciliation and settlement at the beginning of the block creation process, before new trade order records are added to the block, is that in such circumstances trade order reconciliation and settlement should only be made for trading orders added to the blockchain in previous blocks. However, evaluating records that invoke Turing-complete smart contracts, such as those that can be implemented with the Solidity language, may require variable and unpredictable durations. Although each smart contract must be deterministic in its execution at the point it is included in the blockchain (so that each validating node sees the same result), due to the “stopping problem” (classic computer science proposition proven by Alan Turing), the amount of time required to execute such a contract is not known without actually executing the contract. The execution time of these contracts may be limited by the requirement that individual computing stages be paid for through the use of a per-token fee known as “gas,” so even a smart shrink implementing non-terminal logic will terminate. when your computational steps exceed what has been paid in advance. However, because this cap represents only an upper limit, the actual amount of time these smart contracts take will vary, even if they have a cap. At a certain point in the process of executing such contracts, the node will exceed the point at which the execution time is available for the block. The last record incorporated / interpreted / evaluated in a new block by a node will be the record whose interpretation first exceeds the time threshold, or the record immediately preceding the record that causes the time threshold to be exceeded. All other proposed records are classified, discarded, or delayed for inclusion in a future block. I CCCI n / l 7Π7 / Β / ΥΙΛΙ Other records, such as balance transfers, new trade orders, or proposal-related records, are potentially more predictable in their performance and can be incorporated mid-process. The different types of records are described below in more detail. If these records are linked to smart contracts via pattern binding records, they may need to be treated as if they directly invoked Turing-complete smart contracts and classified in the same way. To prevent the evaluation of Turing-complete contracts from being mandatory, pattern linking records may be required to be non-mandatory executable (so there is no guarantee that they will be executed). Or, alternatively, it may be necessary to have only a limited number of calculation cycles available for linked contracts in each block, and force pattern linking records to bid for inclusion through the use of charges. Such a limit could be conservatively enforced by assuming that each smart contract will consume its entire gas allocation, regardless of the final outcome. Token Supply Algorithms Among the various blockchain implementations, there is a wide variety of strategies regarding how native tokens (often referred to as “coins” in currency blockchains) are created, distributed, managed, and destroyed. At least one embodiment refers to the “supply” of such tokens. Not all blockchain implementations use native tokens. For example, blockchain software that uses authoritative vote-based consensus, such as IBM's Fabric Hyperledger, does not require the existence of any native coin or token to incentivize participation in the consensus process. Fabric Hyperledger is used by companies that operate in a “partial trust” environment, so nodes that join the network are explicitly authorized to do so by the other nodes, and are incentivized to participate due to the ancillary business benefits it provides. their operators receive as a result of the network's existence, such as document timestamps and document preservation. The computing contribution made by nodes in such a network is essentially a gift, given to benefit a closed or semi-closed group of participants without receiving direct consideration in return. In contrast, blockchain networks that use native tokens are typically open to participation by any anonymous node capable of connecting to the network over the Internet. These implementations (e.g. Bitcoin and Ethereum) primarily use the native i ccci η / ι znz / E / YiAi tokens to incentivize participation from nodes that otherwise would not have an incentive to participate in building the chain. blocks and, in this way, help secure the network against attack by untrustworthy parties. Within proof-of-work blockchain networks, the market value of tokens, the number of tokens issued and outstanding at any given time, the way in which tokens are distributed, and the rate and manner in which The way new tokens are created has a direct impact on the computing power that is applied to solve proof-of-work problems. Proof-of-work miners spend real-world money (“decree” currency in industry terms) to pay for mining equipment and electricity to perform proof-of-work calculations; They recover their costs by selling the native tokens generated in exchange for the currency “by decree.” Historically, trends in the value of the token market have had a direct impact on the total computing power contributed to support the resolution of proof-of-work problems, which has a direct impact on the overall security of the system. (more computing power means greater security). A sudden, drastic drop in the value of a native token can result in a rapid drop in network participants, even while physical capacity remains intact. For example, if a double-spend attack were ever to take place on the Bitcoin network, a likely way it would happen would be for a large miner to waste their mining capacity after a market breakout, and use that capacity to mine. a chain duplicated in parallel and secretly. To stage an attack, such an actor would (1) purchase a large amount of Bitcoin; then (2) I would use his ability to start mining a secret chain; then (3) sell his Bitcoin, finalize the deal on the public chain; (4) he would release the longest secret chain of his, which would replace the main chain, removing the record of the sale; and finally (5) would sell his Bitcoin for the second time. In other words, token price volatility can decrease the security of proof-of-work networks. In proof-of-stake blockchain networks, the higher the value of native tokens in a given node's designated account, the more that node can stake in a given round. A higher “stake” increases the odds that the chosen node will build the next block and receive the block reward. Nodes that can stake a greater number of tokens / coins will therefore accumulate more tokens through block rewards, and will have a disproportionate influence on consensus determinations. I CCCI n / l 7Π7 / Β / ΥΙΛΙ Without built-in countermeasures, accounts that are already the largest holders of native tokens will continue to accumulate them at the expense of ordinary users who pay fees to add the records to the blockchain. This trend is accelerated if the algorithm used to distribute the native tokens at the beginning also results in concentration. Concentration carries specific risks and implications for a proof-of-stake system: if all but a few nodes face a low probability of building a new block (and benefiting from the rewards), then nodes tend to exit the concentration. network and refuse to participate. Fewer participating nodes increase the possibility of collusion among (or common control over) a majority of nodes, which substantially impacts security and increases the network's exposure to a potential double-spending attack. Variation between Supply Algorithms The types of algorithms used to determine how tokens are distributed and how many tokens will be distributed are varied. For example, the first block of the blockchain, the “genesis block,” may itself contain a token assignment. This initial supply is sometimes called a “premine” or an “instamine,” although the term “initial supply” is more accurate. Depending on how tokens subsequent to this event are generated and distributed, it can lead to a high degree of centralization of token ownership. As part of each block, new tokens can be generated. The total number of tokens that will be generated over time may be limited, or may be potentially infinite. Bitcoin generates additional tokens each block based on the block height of the chain: the same number of new Bitcoins are added each block, except that every 210,000 blocks that number is halved. New Bitcoins will continue to be generated until the total supply equals 21 million. In 2019, 12.5 Bitcoins were created in each block. Ethereum currently emits 3 constant ethers per block, and there is no built-in limit; Unless a change is made to the Ethereum software and adopted by a critical mass of nodes, 3 ethers will be generated per block for as long as Ethereum exists, and a potentially infinite supply of Ether tokens can be generated. In some blockchain networks or cryptocurrencies, such as Ripple, the tokens generated at the beginning comprise the maximum supply of tokens that will be generated; In such cases, there is no protocol to issue more tokens. Some blockchain implementations destroy tokens. In the case of Ripple, the tokens used as charges are removed I CCCI n / l 7Π7 / Β / ΥΙΛΙ permanently from circulation, causing the total supply of tokens to gradually decrease over time. Issuance and supply algorithms implemented in blockchain software substantially affect user adoption, ongoing participation levels, and price volatility of native tokens. The total amount of outstanding tokens influences pricing through supply and demand, and the rate and mechanism of token issuance influences user behavior through incentives. Despite this, many or most blockchain and cryptocurrency implementations have chosen their issuance and supply algorithms without having clear, long-term goals regarding the user. In contrast, the present invention aims to reduce volatility and improve predictability regarding the price of native tokens over time, by using on-chain information that is accessible to each block building node to deterministically decide the number of native tokens to be issued or destroyed in a given block. Price Stability Algorithms Native tokens within a blockchain system serve to incentivize the block building activities of the block building nodes, but also serve the essential purpose of monetizing the services provided by the blockchain. Native tokens are a means for blockchain users to compensate the network for providing services. Typically, these services include on-chain data preservation and the computer processing associated with the creation of a new block. It is reasonable to expect that the price of a native token relative to external real-world assets and currencies will vary according to the perceived usefulness of those services. However, it is not necessarily the case that the number of native tokens allocated as fees to participate in those services should be volatile. Essentially, two different approaches can be taken to stabilize the off-chain price or value of tokens, each of which can be implemented in accordance with at least one embodiment of the present invention. Under the first approach, a blockchain system can designate a value peg to anchor the price of the token in terms of a real-world asset or currency (e.g., USD, SDR). To stabilize the price of that token, some human or algorithmic intervention must take place - for example, buying tokens in exchange for the fixed asset, or selling tokens in exchange for the fixed asset, or creating or destroying tokens, or locking or I CCCI n / l 7Π7 / Β / ΥΙΛΙ unlocking tokens. Although there are some systems that have attempted to use at least some of the methodologies mentioned above (for example, Tether tokens), the present invention offers a number of improvements over known systems. According to the second approach, a blockchain system can identify some value metric internal to the blockchain itself and perform an algorithmic intervention to stabilize that metric, independent of external market price information. An example of this value metric would be native token fees paid by users who want to add data to the blockchain, or who want nodes to perform some computing work (i.e. “service charge” prices expressed in terms of the token used for that purpose). This second approach is unique to the present invention, and is not among known blockchain systems. Two new processes and methods, each according to at least one embodiment of the present invention, are described below. The first process and method described is an implementation of the second “internal metrics” approach introduced above, along with severe variations. The second process and method described is an application of the first value peg approach introduced above. Token Supply via Internal Metric Guidance According to at least one embodiment of the present invention, the supply of native tokens can be managed such that the native token fees paid by users who wish to add data to the blockchain, or who wish to have nodes that perform some computer work, will generally be consistent (although not necessarily fixed) over time. To that end, a target can be set for what the average token fee should be for adding records or performing work on the blockchain (i.e., blockchain “service fee”). This target can be set for the entire period of time that the blockchain network operates, but would be better defined as a function of the height of the current block, so that the target average service charge can vary over time. In at least one embodiment, if the current average service charge for new registrations on the blockchain falls below the target, then a certain number of new native tokens would be created and added to the block reward. This number of tokens would be determined deterministically at the time a block is created. Specifically, in at least one embodiment, the number of new native tokens would be determined by examining the number n of blocks immediately preceding the block in question, and determining some average I CCCI n / l 7Π7 / Β / ΥΙΛΙ weighted discrepancy between the actual average service charge of each block, and the target service charge in that number of the block. In other words, a weighted moving average would be used, but only a weighted average of blocks immediately preceding the block where the new native tokens would be assigned. All being equal, increasing the block reward would thus increase the total number of tokens in circulation on the blockchain and increase the global supply of available tokens. This, in turn, can be expected to gradually reduce the price that users must pay to acquire the tokens and have users assign higher charge values ​​when proposing new records to be added to the blockchain. On the other hand, if the current average service charge for new registrations on the blockchain rises above the target, then the block reward would decrease by a certain number of native tokens. As in the previous case, this amount would be determined deterministically at the time a block is created. Specifically, in at least one embodiment, the number of tokens by which the reward is reduced would be determined by examining the number n of blocks immediately preceding the block in question, and determining some weighted average of the discrepancy between the actual average service charge of each block, and the target service charge on that block number. As in the previous case, a weighted moving average would be used, but only for the blocks immediately preceding the block where the new native tokens would be assigned. All else being equal, decreasing the block reward in this case would decrease the total number of tokens in circulation on the blockchain and decrease the overall supply of available tokens. This, in turn, can be expected to gradually increase the price that users must pay to acquire the tokens and cause users to assign lower charge values ​​when proposing new records to be added to the blockchain. In any case, the size of the block reward would be at least slightly decoupled from the size of the fees specified in the records added to the blockchain. Although a block that has the highest total fees will produce a higher reward than a block that has the lowest total fees, the actual final reward for the block would be a percentage of those fees (either 150% of the fees, or 50% of the charges, or 0%), which percentage value would depend on a function of the charges assigned in the preceding blocks. The final reward may depend on the weighted average service charge for preceding blocks, as described above, and in at least one embodiment may depend on the rate of change in charges recorded for those blocks. I CCCI n / l 7Π7 / Β / ΥΙΛΙ The block reward cannot fall below zero, so the maximum impact of reducing the block rewards would be proportionally smaller than the maximum impact of increasing the block reward by creating the new tokens to increase the total supply. The block reward would not be reducible to zero, but rather to a predefined minimum level. That said, however, terminating tokens already in circulation provides a way to effect a reduction in the number of native tokens in circulation beyond this limit. In the case of Locker consensus similar algorithms, in at least one embodiment, if the average service charge increases too much above the target (i.e., beyond some expressly defined high threshold), then some portion of the locked tokens or tokens at risk may be reduced as well to further reduce tokens in circulation. Withdrawing locked tokens in this way would have the effect of decreasing the total number of tokens in circulation at the expense of decreasing the incentive for participants to lock or stake the tokens (by effectively imposing a negative interest rate on those tokens), which would would negatively affect safety. The following section below describes possible alternative token termination strategies that do not create this perverse incentive. Reducing block rewards and terminating tokens can destroy the tokens in question, just as an increase in block rewards can create new tokens that did not exist before. Which means that there is likely a discrepancy between the charges made by the records included in the block and the block reward issued for that block. Indeed, when a token supply algorithm such as the one described here is employed, the total number of native tokens residing within the blockchain system before a block is processed may be greater or less than the number of native tokens. residents within the system after it is processed. In this way, the global supply of native tokens is influenced by the price of blockchain services – that is, the level of charges included in new records added to the blockchain, on average. Token Termination v Metric Selection In at least one embodiment of the “internal metric” token supply method described above, if the current average service charge were to fall below the target metric by a certain threshold, then some portion of the tokens in general circulation would be voided. Depending on the implementation and modality, a percentage of tokens that have not been allocated or moved at all within the blockchain for some time would be voided; or a certain percentage of tokens that have been held for a certain amount would be redeemed I CCCI n / l 7Π7 / Β / ΥΙΛΙ period of time without having been used as positions; or in the case of Casillero consensus (and similar algorithms) a percentage of tokens that had not been locked or staked for a period of time would be voided; or some combination of these. This “accumulation fee”, “non-payment penalty” or “inactivity penalty” would incentivize dormant tokens to be actively used, which would put upward pressure on service charge pricing as the number increases. of tokens in active circulation. In at least one embodiment, the voided tokens themselves may be reintroduced into active circulation by being added, in whole or in part, to block rewards available for distribution; Alternatively, voided tokens may be destroyed, in whole or in part. In addition to incentivizing an immediate increase in overall token circulation, this approach would eventually return to circulation the native tokens that had been effectively lost due to the cryptographic credentials (i.e. private key) of the account that held those tokens. lost. This would also help reduce the risk of a massive surge of tokens re-entering mass circulation, which would have a large impact on both the external price paid for such tokens, as well as service charge pricing. that real users experience. Unlike the increased stability provided by at least one embodiment of the present invention, in the case of the Bitcoin blockchain, there are billions of dollars worth of Bitcoin that are widely assumed to be permanently locked and therefore therefore, lost. However, it is not certain that those Bitcoins will be permanently lost, and there is some risk that those dormant tokens will re-enter circulation at some point, affecting the price of Bitcoin in the market. In the case of Locker consensus (or related Hash Distance and Suitability consensus approaches where locked or staked tokens contribute to the Suitability value) according to at least one modality, assigning tokens to lockers and locking them would exempt them of the penalty for inactivity. As a result, in addition to stabilizing the value of native tokens, there would be an incentive for larger amounts of tokens to be locked or parked at any given time, which would increase the security of the Consensus Algorithm. To determine which account balances would be subject to this termination, block building nodes would trace back through the blockchain to the block in which the tokens were distributed as part of a block reward, or to the block in the one in which the tokens were released after being locked or staked. The number of blocks between the current block and that specific block would be considered the “age” of the token. I CCCI n / l 7Π7 / Β / ΥΙΛΙ In at least one embodiment, if an account mixes tokens of different ages, each transfer from that account will be deemed to have transferred tokens of those different ages in proportion to the ages of the tokens originally held by the account. When charges are assigned or tokens are allocated to a locker (or tokens are locked or staked), then the “older” tokens are considered to have been allocated first, before the younger tokens have been allocated. For optimization purposes, in at least one embodiment, the age of the various token balances held by an account at any given time may be tracked as part of the account data residing in the block, such that the age does not matter. have to be recalculated after initial validation. In at least one embodiment, the percentage of tokens voided as part of the "inactivity penalty" may be determined by a function that considers factors such as the age of the token in combination with the discrepancy between the target service charge and the service charge. actual service experienced during the most recent n blocks. In another embodiment of the present invention, fully latent tokens - tokens that have not been included in any data records written to the blockchain after a certain well-defined block height - would be voided at a certain rate. In each block, some percentage of inactive tokens would be voided; however, the size of this percentage may or may not depend on the current discrepancy between the target average service charge and the current average service charge. In at least one embodiment, the occurrence of this latent token termination would depend solely on the age of the token, and would be assessed independently of the “inactivity penalty” described above and the “retention allowance” described below. Retention Allocations and Metric Selection In at least one embodiment of the “internal metric” token supply method described above, if the current average service charge exceeds the target by a certain threshold, then a certain amount of native tokens would be distributed to the accounts holding the native tokens. This “hold allocation” could be implemented by assigning to these accounts some portion of the reward that would otherwise be distributed to consensus participants; or by issuing a new token value not previously accounted for on-chain (in other words, through the issuance of new native tokens created through inflation); or through a combination of these. I CCCI n / l 7Π7 / Β / ΥΙΛΙ This “hold allocation” would inflate the size of all native token balances simultaneously across the network by a percentage that is determined, at least in one embodiment, by how large the discrepancy is between the service charge metric. target average and the metric of the current average service charges among the n most recent blocks added to the blockchain. The larger the discrepancy, the higher the percentage. This retention allocation, however, would only apply to accounts with an “age” above a certain threshold, or it would be applied proportionally to accounts based on the age of the tokens containing it. In this way, the hold allocation would also incentivize holders of the native token to continue holding on to them and not using them (and not selling them to use them), potentially decreasing the number of tokens in active circulation. Configuring v Tuning Token Supply Based on Internal Metrics The above approaches according to at least one embodiment of the "internal metric" token supply method of the present invention, may incorporate a number of constants and functions that depending on the details chosen at the time of implementation would have a material effect in the behavior of the software and the incentives that motivate its users. These may include: • The target average service charge function • The block reward increase and decrease function(s) • The hold allocation and inactivity penalty function(s) • The termination percentage function inactive token Each of these functions can be implemented in a way that is integrated directly into the block building node software, or they can be implemented in whole or in part as smart contracts that can be modified at run time by privileged users. If a function is integrated into the block building node's software, all nodes in the blockchain network must share the same version of that function's implementation. For block validation to work correctly, it is required that all nodes accept the result of this function. An implication of this requirement is that a substantial percentage of all nodes - rather than a majority - must update their software and agree to the same version of that software for that adjustment to take effect. The programming of such systems can be implemented in different programming languages ​​and / or for different operating systems by a person skilled in the art following the description of the characteristics and I CCCI n / l 7Π7 / Β / ΥΙΛΙ system limitations that are described in this description and that are appropriately reflected, applied and implemented in the specific coding implementation. Alternatively, any of these functions that are implemented as a smart contract on the blockchain can be replaced by another smart contract added to the blockchain without requiring any new version of the software to be implemented. To replace such a smart contract with another smart contract, one or more authorized accounts would sign the record of the new smart contract with instructions to replace the record of the old smart contract. Alternatively, a single smart contract could be programmed to delegate responsibility to a subordinate contract, which subordinate contract could be modified by a majority of authorized voting accounts. Blocks before this replacement act would be valid only if the old version of the function was used, while blocks after this replacement act would be valid only if the new version of the function was used. There are some special considerations to be made regarding the average service charge function. The nature of this feature can have a significant impact on potential users' incentives to participate in the network by running the nodes and adding the records to the blockchain. For example, if the function is linear, then the level of service charges will grow at a constant rate over time. This may provide stability, or may discourage adoption early on if block rewards decrease to reduce rapid fee increases as the network begins to provide public services to users - or may discourage adoption if tokens are nullified. to incentivize token velocity before the network has reached the uncritical mass of participating nodes. In another order, for example, a function that resembles a sigmoid function (shifting so that y=0 to x=0) could address these problems by providing a smooth transition from a period of zero or low charges, to a stabilized existence. , with higher charges, in the long term. To align such a transition with the network reaching a critical mass of nodes, such a feature could also take into account the current performance of the network, or how dramatic and consistent price spikes may be; further upward price pressure could trigger the transition to the higher stable level. Alternatively or additionally, more nuanced features could be implemented taking into account network behavior after deployment. Replacing these provisioning functions could be done if the majority of block building nodes accept the modification and update their software. A function that is implemented as a smart contract could be, but if a consensus is built among node operators that a particular smart contract implementation is optimal and should be preserved, the logic of that function can be implemented itself in the block building node software, giving it a semi-permanent state that cannot be replaced by anything more than a broad consensus of the network's block building nodes. Token Supply via Value Peg Guidance A further example of at least one system and method of the present invention that improves native token price and supply stability is discussed with reference to Figure 7. Blockchain implementations typically keep the added value of native tokens within the blockchain system constant, or increase it at a predetermined rate (either at a constant rate or with a gradual decay). This typically results in cryptocurrencies being deflationary, with token values ​​increasing compared to real-world assets as usage increases. At least one embodiment of the present invention attempts to use on-chain data related to operations between pairs of native tokens and user tokens as indicators of inflation or deflation. The creation or destruction of native tokens is triggered according to these flags. Referring to Figure 7, at the beginning, at step 710, a certain number of native tokens are issued. Block rewards can be denominated in these native tokens. In 715, records intended for listing on the blockchain must include fees to incentivize listing. These fees must be in the form of native tokens within that blockchain. At 720, a record is transmitted to the network of nodes for inclusion in the blockchain. At 725, nodes first check whether the charges allocated with the registry are denominated in native tokens. If so, in 728, the record is included in the blockchain and the fees are added to the block reward. Otherwise, if the native tokens are not denominated, at 730, the block construction node attempts to match these charge user tokens with a trade order record that would convert the charge denomination (to user tokens) in native tokens. At 735, it is determined whether a matching reciprocal business record (or sequence of records) is found. If such a reciprocal trade or sequence of trades is found, then at step 740, the block building node settles a trade, and converts charges denominated in user-defined tokens (or currency) into native tokens. I CCCI n / l 7Π7 / Β / ΥΙΛΙ At 745, the block building node compares the trade with operations within the N number of blocks, and calculates a deviation percentage P. It then determines a 750 if the deviation percentage P is above the upper or lower threshold limit. If so, at 755, some function of the deviation percentage and fees R, which can be described as R(P, fees), is used to calculate the registry's contribution to the block reward. In at least one embodiment, this feature would be implemented to increase the reward if the price of native tokens is too low relative to historical precedent, in order to disproportionately increase the overall supply of tokens. If the tradable price for native tokens is too high relative to historical precedent, then this feature would reduce or eliminate the reward, to suppress the overall supply of tokens. In any case, once the reward is calculated, at step 790, the record is added to the block with a reward that is greater or less than the charge of the record, depending on the output of the R function. Otherwise, if the deviation P does not exceed the threshold at step 750, the charges converted into native tokens are added to the block reward at 758, and the original record is added to the blockchain. If at step 735, it is determined that a matching reciprocal trade record (or sequence of trades) is not found, then at 770, the transaction history is scanned and analyzed to determine whether the trade volume sales charge tokens V for native tokens they have been settled within X number of blocks. As part of this process, at 775, it is determined whether the trading volume V is greater than some minimum allowed threshold. Otherwise, then the trading volume is not high enough and the original record is considered invalid at 778. As a result, it is not included or added to the blockchain. If the volume V is above the minimum threshold, then at 780, the block building node generates the new native tokens and exchanges them for the charge tokens. At 785, the original user-type fee tokens are committed to a trading order offering to exchange for the native tokens, with the proceeds going to the block reward account. After that, at 790, the original record is included in the blockchain, contributing a certain amount to the block reward that is somewhat greater or possibly less than the value of the charge, but within the allowed level of fluctuation. Therefore, the system maintains price stability and supply of the native token type. Improved Cryptographic Key Management and Security I CCCI Π / I 7Π7 / Β / ΥΙΛΙ The security of ownership of tokens, cryptocurrencies, or other assets held or tracked on a blockchain typically depends on that person's ability to keep secret the private cryptographic key that is used to sign records, transactions, or smart contracts that originate from that account. Such records, transactions or smart contracts, when signed, are capable of effecting the allocation of those tokens, assets or units of cryptocurrency to the accounts of other persons. If a private cryptographic key becomes known to a person other than the owner of the account secured by that key, then that other person typically shares equal control over the contents of the account, even if they do not have ownership of it. This de facto control extends to the point of being able to transfer those assets out of the original account and into an account outside the reach of their legal owner. One or more features and methods of the present invention solve this problem by reducing the risk of surreptitious access of keys by malicious actors. These features and methods also resolve certain regulatory hurdles caused by uncertainty regarding the custody of cryptographic keys. In some jurisdictions, stockbrokers may be prohibited from trading and managing assets over which they cannot maintain exclusive control. The following is a means by which such entities can substantiate a claim that they maintain full control over the tokens in their custody. In at least one embodiment of the present invention, each account may be assigned multiple pairs of cryptographic keys, each managed separately, and each may authorize records that originate from - and modify the state of - the account. These key pairs would consist of a public component and a private component. These public and private components would function to enable the creation and verification of digital signatures using a standard digital signature algorithm such as ECDSA. In at least one embodiment, each account key pair will have separate settings relating to the activities it can authorize and the records it can sign. If a record is signed by a key pair that is not authorized to generate that record, then the record is invalid, even if the account itself can validly originate that record. One or more designated master key pairs could modify settings attached to the other key pairs that are associated with an account. Different key pairs can correspond to different devices acting as wallets, giving the user(s) the ability to control what activities can take place and what logs can be generated on each device. This will allow the I CCCI n / l 7Π7 / Β / ΥΙΛΙ more secure devices perform more activities - and have access to higher token values ​​- than less secure devices. In at least one embodiment, for example, the wallet installed on a smartphone may use a key that has been configured to generate only transfer records, and only move 100 tokens per day. A home or office computer, on the other hand, can use a key with a limit of 1,000 tokens per day and is authorized to sign most types of records. On the other hand, an air gapped computer would use a key that has unrestricted authorization. However, all of these keys would be accessing the same account. To reduce the possibility of private keys being stolen undetected, and to ensure that each key pair is associated with a device at most, in at least one embodiment, each key would be used only once, replaced after each use. When a key pair is used, the registry shares the public portion of the replacement on the blockchain, and the private key is retained by the wallet device. All settings from the original key pair are transferred to the replacement key pair. Alternatively, a configuration can control how the key pair is replaced frequently. In at least one embodiment, the key pairs of individual accounts would be associated with the subaccounts, the purpose of which is to keep track of the configuration that adheres to the specific key pair, and to link the key pairs to the devices, and the devices to accounts. When a record is generated and signed, the subaccount number is included in that record to correctly identify which key pair should be used to sign it. Should an old and now replaced key pair sign a record, in at least one embodiment this will cause the particular device / subaccount, or the entire account, to become locked and unusable. Each chain activity and record corresponding to that account or that device / subaccount would be considered invalid. Whether the entire account is locked, or only the device / subaccount is locked, would depend on the settings of the account and the deviceZ / subaccount. Similarly, the duration of the lock would depend on the configuration. The lock could be for a limited period of time, or it could be indefinite, until certain stages are met to unlock it. Reactivating the account or device would require a process to regenerate the key for the inactive device, similar to how new devices and key pairs are added in the first place: I CCCI n / l 7Π7 / Β / ΥΙΛΙ (a) An authorized and still active device generates a new key pair for the disabled device, updates the public portion in the blockchain via a reactivation message, and packages the pair of keys in a message to share with the idle device or wallet. (b) The new key message is shared with the disabled device via a QR Code, or via a URL sent via text message / email, via a network plug connection, via a webcast. radio, through manual entry or through other means. (c) The newly reactivated device installs the key pair and immediately generates a blockchain message to replace the shared key pair with a new key pair. In high security environments, reactivation may require all or most of the affiliated devices / accounts to be used to generate the new key — including offline keys. In this case, in at least one embodiment, the above reactivation procedure would be repeated for multiple active devices, with the inactive device remaining inactive until a sufficient number of reactivation messages have been added to the blockchain. One implication of the key rotation and account locking method described above is that new registrations proposed by an account would have to specify its order or block height. If key rotation is frequent, then the order in which records are added to the blockchain matters, because records out of order can trigger a crash. This account lockout feature, in combination with the key rotation feature described above, would force one of two outcomes in the event of a key theft: either the key thief is quickly blocked from using the account, or if the key thief is successful and the account owner would be alerted by being blocked from using the account as soon as unauthorized use of the account occurs. Limits on the size of token transfers, and on the types of activities that an account key pair can authorize, mean that if a private key is stolen, the economic impact is limited. To enable this functionality, and readjust key distribution to different devices, the following method and process would be implemented in accordance with at least one embodiment of the present invention. I CCCI n / l 7Π7 / Β / ΥΙΛΙ (1) A wallet device generates a new account on the blockchain and produces a new key pair that is associated with a master subaccount for that new account. Since this wallet device contains and controls this master key pair, it should be considered the master wallet. (2) This master wallet generates a new secondary key pair associated with a secondary subaccount of the account. (3) The master wallet adds the public portion of the key pair to the public blockchain, while the master wallet retains the private portion. The master wallet configures that secondary key pair based on the user's needs and adds this configuration to the blockchain. (4) The master wallet packages the secondary key pair into a message to share with a secondary wallet device. The message is encoded in binary format, such as a 2-dimensional barcode or QR code, as base64 data within a URL or other format. (5) The secondary wallet, through a network plug connection, through a radio transmission, through a scan of a QR code, through manual entry, or by other means, receives from the master wallet the key replacement message. (6) Finally, the secondary wallet device installs the key pair and immediately generates a blockchain message to replace the shared key pair with a new key pair, giving the device exclusive control over the key pair. keys. In the event that a higher level of security is required, in at least one embodiment, an offline mode would allow offline secret keys to be configured as a security measure, and then held in “storage.” “cold” until needed. This would be a way to add additional keys to an account, to provide some override capability in case an account is hijacked by having its keys stolen online. Alternatively, keys with full permissions regarding an account can be kept offline in cold storage, while hot wallet devices work by using keys that only have partial permissions. [00 01] The off-line key generation method of the present invention may implement the following steps, elements and features (although not all steps, elements and features are necessary in each embodiment). (1) A wallet device that has the master key pair for an account is taken offline and isolated in a secure environment, to reduce the possibility of hacking during this process. This i ccci η / ι znz / E / YiAi Air Gapped wallet device would act as the master wallet for the purposes of this process. (2) The master wallet generates a new secondary key pair associated with a new subaccount outside the account line. (3) The master wallet generates and signs a record by adding the public portion of the key pair to the public blockchain, while retaining the private portion. The master wallet configures that key pair offline based on the user's needs, and further generates and signs a record by adding this configuration to the blockchain. If the offline key pair is intended as a means to lock down full control of the account, then this setup stage can give the key pair the same permissions as the wallet's master key pair. (4) Because the master wallet is not connected to the blockchain through any network, these records are not automatically added to the blockchain. Instead, they are visually encoded using a QR code or some other visual means of data storage, and printed on paper using a printer connected directly to the wallet. (5) The master wallet then packages the offline key pair into a message, visually encoded through the use of a QR code or some other visual means of data storage. This visual encoding is printed by using a printer connected to the wallet, or displayed on a computer monitor or other visual display connected to the wallet. (6) A compatible wallet device, placed in a less secure area, scans the QR code of the two records by using a connected camera and then transmits those records to the blockchain, thereby updating the blockchain to reflect the public portion of the new offline key pair and its configuration. (7) The physical message printed offline (i.e., QR code) containing the key pair is kept in a secure facility until needed. For example, it can be kept in a safe, safe deposit box, or bank vault. (8) Going forward, the master wallet can reconnect to the network, but for maximum security it will remain disconnected, turned off, or even destroyed. However, before it is taken out of service, the master wallet of this process can follow this same procedure offline to create one or more key pairs again, in this case with reduced permissions. These key pairs would be uploaded to connected wallet devices, which I CCCI n / l 7Π7 / Β / ΥΙΛΙ would manage the day-to-day management of the account, with reduced permissions to reduce the impact of a possible hack. Note that this process depends on a feature of the present invention where, in at least one embodiment, a wallet device may receive an encrypted record directly from another wallet device before that record has been added to the blockchain. . The receiving wallet device can then add that record to the blockchain on behalf of the sending wallet device, uploading the record to the blockchain network. In the case described above, the means of transferring such a record is by visually scanned QR code, but in other embodiments the message may be encoded in binary format, such as base 64 data within a URL, or another format in addition to a barcode. 2-dimensional or a QR code. Such data may be shared with the receiving wallet device through a network plug connection, through a radio transmission, through a scan of a QR code, through manual entry, or through other means. , in addition to through visual scanning means of a QR code or similar. Payment Risk Mitigation A common challenge that blockchain users face when using tokens to make real-time payments, especially retail payments, is that it takes some time to finalize or confirm a tokenized payment or transfer on the blockchain. First, a payment or transfer record or transaction must be accepted for a block that is added to the blockchain. Second, the risk of that block being voided (i.e., being part of a fork that is disposed of through a conflict resolution process) should be reduced. The risk of a block being voided decreases as more blocks are built on top of it, because each additional block increases the fitness of the entire chain. Without quick confirmation or completion, it is difficult for commercial transactions, especially retail transactions, to use blockchain tokens as a means of payment. Both customers and merchants typically do not want to wait for payment to clear before products and services are transmitted from seller to buyer. The present invention assists in the process of finalizing or confirming payments or transfers in at least one embodiment by decreasing the delay between blocks and increasing the rate at which new blocks are added to the blockchain, through the processes and methods described. in this description. In at least one embodiment of the present invention, the following process further improves the I CCCI n / l 7Π7 / Β / ΥΙΛΙ ability of the recipient of a payment or transfer to reduce the risk that that payment or transfer will be reversed, thereby increasing that recipient's confidence that they will be assigned control over those tokens in a lasting way. (1) A party, the “Receiver”, generates a payment request that specifies that a certain amount of tokens be transferred to a certain account. The payment request is encoded as a message containing the token of the requested amount and the destination account or address to which the message will be sent, as well as other information including, in at least one embodiment, detailed details of the services or products for which payment is requested (such as on an invoice); details about the identity of the applicant (e.g. name, address, telephone number, photograph), and the type of token requested in the event that there is more than one token hosted within the blockchain system. In at least one embodiment, the payment request will further incorporate a cryptographically signed "transaction header" record, which record is required to be included for the processing of multi-signature atomic transactions in accordance with the transaction protocol described elsewhere in the present description. (2) This request message is then transmitted electronically through various possible means to the second party from whom payment is requested. This second party, the "Issuer", may, in at least one embodiment, receive this message through a mobile text message or SMS, or through an email message, which message will contain a visual encoding of the request ( for example, as a QR code or two-dimensional barcode) in a graphic attachment, or a URI that encodes the message in base 64 or another encoding format. The sender may also receive the payment request through a message sent over a packet-switched computer network via TCP / IP, UDP, or another protocol. In at least one embodiment, the recipient generates the payment request through the use of a computing device such as a mobile phone, smartphone, tablet, laptop computer, desktop computer, server computer, point-of-sale device, or display device. specifically designed computing (the Receiver device). This Receiver device would connect to a monitor or other type of computer screen; When the request message is generated, it is encoded as a QR code, 2-dimensional barcode, or other visual encoding, and displayed on the monitor. The Sender would then use a camera connected to a computing device of the Sender to capture an image of the visually encoded message and decode the message by analyzing the captured visual image. In at least one embodiment, the receiver transmits the request message through an antenna I CCCI n / l 7Π7 / Β / ΥΙΛΙ radio frequency linked to the Receiver device, whose message is received through a radio frequency antenna on the Transmitter device. The information may be transmitted via near field communication or another protocol. (3) The Issuer receives the payment request message through a computing device that is also a Wallet device, which stores cryptographic private key information related to the Issuer's blockchain account or address. This Wallet device presents payment request information to the Issuer through a monitor, graphical display, text-based terminal or other output device (for example, by reading the details through the use of a speech synthesizer) , requesting that the Issuer authorize a payment to be made using tokens assigned to the Issuer's blockchain account or address. The issuer may provide this authorization by pressing a button, providing verbal approval accepted by voice recognition, typing a specific command through the use of a command line interface, or by other means. (4) Once the Authorization is provided by the Issuer, the Wallet device generates a token transfer record that maps the indicated tokens from the Issuer's account or address to the account or address indicated in the request message. This token transfer record would be signed by using the private key signature held within the Issuer's wallet device. In at least one embodiment, the signed token transfer record would be accompanied by additional metadata that includes relevant identity information such as (depending on the embodiment) name, zip code, address, telephone number, government ID number, and / or other relevant information. If the request message is accompanied by a signed transaction header record, then the token transfer record will include a reference to the transaction header record in accordance with the transaction protocol described elsewhere in this description. (5) Upon signing the transfer record, the Sending device would transmit the signed transfer record, along with any metadata, to the Receiving device. This signed transfer record may be sent via mobile text message or SMS, or via email message, which message will include a visual encoding of the signed transfer record (for example, as a QR code or a security code). 2-dimensional bars) in a graphical attachment, or a URI that encodes the message in base 64 or another encoding format. The Receiver may further receive the signed transfer record via a message sent over a packet-switched computer network via I CCCI n / l 7Π7 / Β / ΥΙΛΙ TCP / IP, UDP or other protocol. In at least one embodiment, the Emitter device would be connected to a monitor or other type of computer display; When the signed transfer record is generated, it is encoded as a QR code, 2-dimensional barcode, or other visual encoding, and displayed on the screen. The Receiver would then use a camera connected to the Receiver device to capture an image of the visually encoded message and decode the transfer record by analyzing the captured visual image. In at least one embodiment, the Sender transmits the request message through a radio frequency antenna attached to the Sender device, which message is received through a radio frequency antenna on the Receiver device. The information may be transmitted via near field communication or another protocol. (6) The Receiving device, upon receipt of the signed transfer record, will share the signed transfer data and any included metadata with a separate processing server, which is itself a specialized block building node, or which is connected to a controlling block building node. This processing server maintains a computerized risk weighting model that is capable of assigning a risk weighting score to the signed transfer record that it has received. This risk weight score is based on the nature and history of the issuing account that has been shared. In at least one embodiment, the risk weighting model would be implemented through the use of machine learning techniques, which shape the model by analyzing a body of data involving similar transactions, or otherwise, by analyzing of blockchain data. For this purpose, machine learning techniques such as neural networks, multilayer perceivers, random forests, support vector machines, decision trees, logistic regression, XGBoost, Inverse Bolzman Machines, Isolation Forests, Variation Autoencoders, Probability of Local Outliers, Local Outliers Factor, DBSCAN or other machine learning algorithms. (7) Depending on the assigned risk score, the processing server will provide an immediate indication via the Receiver device to the Receiver whether the payment has been accepted immediately or if the payment requires additional processing. The Receiver device will transmit this information to the Receiver through its user interface. If the processing server indicates that the payment has been accepted, this tells the Receiver I CCCI n / l 7Π7 / Β / ΥΙΛΙ that it is safe to deliver products or merchandise or provide services to the Issuer, because there is a high possibility that the payment will be completed on the blockchain. If the processing server indicates that additional processing is required, then the Receiver may decide not to deliver products or services to the Sender until processing has been completed. (8) The processing server will share the record with the blockchain network and then begin constructing a block containing the record (along with any other similar records it has received). This can happen simultaneously with the determination of the risk weight score, or after the determination of this score. According to at least one embodiment, if the transfer record points to a transaction header record, then the processing server will construct a transaction record around the transfer record according to the transaction processing protocol described elsewhere in the present description. The processing server will then share that record (which will encapsulate the transfer record) with the network and construct a new block containing that record, rather than the transfer record. In the event that the risk weight model causes the processing server to decide that the payment is not accepted immediately (i.e. the risk weight score is too low), then the processing server will continue analyzing the consensus of the blockchain. When the processing server detects that the transfer record or transaction has been included in a block, and that the block has been constructed with a sufficient number of additional new blocks so that it has a high enough chance of not being revoked or voided, the server will notify the receiving device that the payment is finally accepted. (9) In at least one embodiment, the processing server may be controlled and managed by a separate person or entity, the “Processor.” The Processor maintains an account or address on the blockchain (the Processor Account) that is independent of the blockchain address or account maintained by the Receiver (the Receiver Account). Under such an arrangement, the payment request message will indicate that the tokens should be transferred to the Processor's account, rather than the Receiver's account. In at least one embodiment, if the payment is accepted immediately, it means that the processor has guaranteed the payment. The processor will transfer the tokens from the Processor Account to the Receiver Account, in an amount equal to the payment amount less a processing fee, at the I CCCI n / l 7Π7 / Β / ΥΙΛΙ generate a transfer record for this purpose. Separately and independently, the processor will transmit the transfer record received from the sender (or the transaction that encapsulates it). If the first of these two transfers (from the processor account to the recipient) expires and is not ultimately accepted, the Processor will regenerate the transfer until it is accepted, regardless of the result of the second transfer (from the sending account to processor account). In at least one embodiment, if payment is not accepted immediately, it means that the Processor has not guaranteed payment. The processor in this case will also generate a transfer record from the processor's account, assigning the payment amount less a charge to the recipient's account. The processing server will transmit this record to the blockchain along with the transfer record and then start building a new block with these records. However, in this case, if the first of these two transfers (from processor to receiver) fails or expires, it will only be retransmitted if the sender's original transfer is confirmed and finalized on the blockchain. In at least one embodiment, if transaction logs are implemented as part of the embodiment, these two logs will be combined into a single transaction log. This transaction record will be transmitted and included in the next block that the processing server constructs, so that both transfers are included in the blockchain, or neither. Token and Registry Type Definitions Different types of records can be used by a blockchain system and method according to the present invention. These records interact and manipulate two types of token: native tokens and user tokens. “Native Token”, in the context of this application, refers to a type of token that is inherent to the operation of a blockchain implementation, and can only be created or destroyed as part of the required operation of the blockchain implementation. blockchain itself. Fees and rewards are preferably denominated in the native token according to at least one modality. “User Token”, in the context of this application, is a type of token that has been named and assigned some aggregate value through a record created by the user on the blockchain. “Derived Token Type”, in the context of this application, is a user token type that is somehow dependent on another user token type, a base token type. This I COCI n / l 7Π7 / Β / ΥΙΛΙ allows the delegation of the creation of a new type of token and the creation of a new token in a controlled manner. “Business Order Registration”, in the context of this application, is a particular type of registration. A trade order offers to exchange one type of token (either native token or user token) for another type of token. The offer is valid for a particular period of time, after which it expires if not matched. The “Settlement Record”, in the context of this application, is a record that matches two trade orders. An account statement record allocates margin to an account specified by the Block Construction Node. “Pattern Linking Record”, in the context of this application, refers to a particular type of record that can be added to the blockchain. A pattern binding record links a pattern to a particular smart contract - if the pattern matches some event that occurs within the processing of a block, some record that appears within a block, or some state that is achieved as a block is processed, the linked smart contract will be executed as part of the block construction process. The term “Proposal”, in the context of this application, refers to a statement of real-world fact that conforms to some formal structure and is quadritable and recoverable within a smart contract. For example, a statement regarding the outside temperature measured at a particular time and location, or the level of rainfall experienced at a location during a particular period, or the number of named hurricanes over the course of a calendar year. A proposal can also be a structured statement of fact that refers to a specific object within the blockchain, for example, referring to an account or address, or to a type of token. A proposal would have a truth state that is decided through processes implemented in the blockchain software: undecided, true, and false. “Proposal Registry”, in the context of this application, refers to a registry that introduces a proposal to the blockchain and initiates the process of deciding the truth status of that proposal. A proposal record is created with a token reward that is distributed to the accounts that have voted the most when the proposal is decided, which decision is made at a time defined by the proposal record. “Decision Record”, in the context of this application, refers to a record that puts a certain number of tokens at risk to vote for or against a proposal associated with a proposal record. Following the proposal decision, the tokens at risk for I CCCI n / l 7Π7 / Β / ΥΙΛΙ the voting records in the minority are distributed to the addresses specified by the voting records in the majority. Native and User Specified Token Types Two broad categories of token types can be defined for a blockchain: native token types and user-specified token types. Instances of these two types of tokens, called native tokens and user tokens, exist as values ​​associated with accounts or addresses within the global state of a blockchain system. Almost all blockchain implementations have a single type of native token, which is used to pay fees and generate rewards that incentivize user participation. Furthermore, within at least one embodiment of the present invention, any number of user-specified token types may also be declared and defined. Depending on the specific modality, blockchain accounts and addresses may store value for a single token type, or may store value for multiple token types. Blockchains constructed in accordance with at least one embodiment of the present invention may be capable of containing multiple token types. Native tokens may be accumulated in an account (1) through a transfer from a separate account that has a native token value exceeding the transfer amount; (2) through the assignment of an automatic reward; or (3) through the opening of account balances established in the first block of the chain when the blockchain network is first launched. After the first block establishes initial native token balances, the total aggregate native token balance on the blockchain can only be increased through the blockchain's reward mechanism. User tokens work under different restrictions. In at least one embodiment of the present invention, a new type of user token is declared and defined through a “genesis” record. This genesis record may further assign a certain amount of these tokens to an account or address, or establish rules for the operation and use of the token within the blockchain system. Future use of that particular token type is restricted according to the configuration data specified as part of the genesis record. In at least one embodiment, a “genesis” record may be a unique record format and class – separate and apart from other record classes. In other embodiments, it may be the first accepted transfer record on the blockchain that references that type of token. I CCCI n / l 7Π7 / Β / ΥΙΛΙ A type of user token is identified by its tag, which is a number or string of characters. No two token types can share the same tag. Any record that references a particular token type tag is only valid if it meets the restrictions set according to the blockchain history preceding the genesis record of that token type. In other words, the use of token type tags is applied within the block construction process. Genesis Records A Genesis record is a type of record resident within a blockchain system. Within the present invention, genesis records are added to the blockchain to declare and define new user token types. Genesis records may contain all or a portion of the following data (not all elements and characteristics are required in each modality): • Label – the unique string that distinguishes one token from another and that identifies different token balances within an account. • Value – the value of the aggregate token created as a result of the inclusion of the genesis record; can be 0 in the case of a genesis record that is used to increase the stake associated with an already declared token type, in the case of a record that somehow modifies the configuration of an existing token type, or in the in case the local account has authority to generate an unlimited amount of derived tokens. • Base token type – optional. In at least one embodiment, a derived type will explicitly reference its base token type. • Derived token tag - optional. In at least one embodiment, the labels of the derived tokens will be restricted according to the field of the derived token label. This field will specify a pattern that the tag must satisfy for the derived type to be valid, which pattern can be implemented as a regular expression or in a similar language. • Local account – the account that receives the newly generated user tokens and can therefore distribute these tokens. • Issuing account – the account that cryptographically signs the genesis record; in the case of an “open” token issuance scheme, this is the local account for the original stake; In the case of an “authorized” token issuance scheme, this is the account that has the authority to issue new tokens with the indicated tag. This is the originating account that cryptographically signs the genesis record with its private key. I CCCI n / l 7Π7 / Β / ΥΙΛΙ • Staking - in the case of an “open” token issuance scheme, the native token value staked (i.e. locked) in support of this user token; field not present under the “authorized” emission scheme (see below). • Fee – the amount that will be included among the block rewards to incentivize the inclusion of the record on the blockchain. • Fractional – setting that controls whether an account is allowed to have fractional or decimal values, or if only integer values ​​can be passed for the token type. The options are “fractional” and “total”; The default is “fractional”. An alternative to the “unit fraction” field is below. • Unit Fraction – setting that controls how many fractional tokens make up a single unit of the token. In an embodiment that implements the Unit Fraction field instead of the Fractional field, each token represents the smallest possible fraction of the asset represented by the token. Each token represents a fraction equal to 1 / “unit fraction” of one unit of the asset. The number of “unit fraction” tokens is equivalent to one unit of the asset. • Supply – in the case of a “permitted” token issuance scheme, it is controlled whether the local account or issuing account can arbitrarily increase the aggregate value available for a particular token, or whether the value is permanently fixed at the time of issuance. the initial broadcast. The options are “fixed”, “unlimited” and “original issuer”; By default it is “fixed”. • New issuance – in the case of a “permitted” token issuance scheme, it controls whether the local account or the original issuing account can issue subordinated derivative tokens – or whether an account that is the bearer of a token can transform a token into new types of derived tokens. The options are “original issuer”, “local” and “bearer”; By default it is “original issuer”. • Authorization subroutine - optional. A smart contract subroutine that will be executed whenever tokens of this type are included in any record. In at least one embodiment, this subroutine, when invoked, would receive as input all data records subject to authorization as arguments, along with the token type that was originally bound to the authorization subroutine. The subroutine would return False in the case that the proposed record is not authorized, and True in the case that the record is authorized. • Authorization filters - optional. A list of filters that can be used to exclude accounts from confirming holding, sending, or receiving tokens of the given type, or that can be used to require accounts holding, sending, or receiving tokens of the given type to fit a given profile. The filters would consist of a pattern that the records or accounts would need I CCCI n / l 7Π7 / Β / ΥΙΛΙ comply, and would refer to the details of a given account, including details that are attached to an account through the use of a proposal record. In at least one embodiment, each authorization filter may further specify which specific third-party accounts would need to have created, confirmed, or decided upon any proposal record used or referenced by the authorization filter. • Authorization cascade - optional. The boolean value that indicates whether or not the authorization subroutine should be invoked, and / or whether authorization filters should be invoked for instances of token types derived from the token in question. The options are “True” or “False”, depending on whether or not the authorization subroutine and / or authorization filters for this particular user token type should be applied in the case of derived tokens, as well as this token type itself. As noted above, two strategies can be followed to define and declare user-specified token types: a process for “authorized” tokens and a process for “open” tokens. The user token types that can be declared and defined under an “open” scheme would be limited in quantity, and each new token type declaration would require a bet (with supplementary bets also possible in at least one modality). The specific number C of token types allowed to be declared and activated at any time would be constant for the blockchain implementation. An account that declares and defines an “open” token type would stake (i.e. lock) a certain number of native tokens, which native tokens would remain locked as long as the associated user tokens remain active. Only a new token type will be accepted with a stake greater than the smallest among the global set of C-number token types, although any positive value stake would be sufficient if fewer C-token types are defined. Furthermore, in at least In one embodiment, a stake may potentially be subject to termination based on age, decreasing the stake over time, and allowing latent or abandoned token types to be removed from the system when the stake falls below the required threshold. Occasionally, additional native tokens may be pinned to the token's “local” account to keep up with the staking values ​​of other open token statements; In any other way, a token type is responsible for being removed from circulation when it is displaced by a sufficient number of new genesis records. In at least one embodiment, a token type that has been declared and defined under the “open” process described above can avoid the limitations of this process — which includes the I CCCI n / l 7Π7 / Β / ΥΙΛΙ cap on the number of open tokens and staking requirement — upon becoming an “authorized” token type. Such a conversion would occur if a well-formed authorization or genesis record is issued and cryptographically signed by an account authorized to initiate such conversion, and is, at least in one embodiment, also countersigned by the account that signed the genesis record that originally declared and defined the type of token in question. Alternatively, a new type of token that is defined and declared under the “authorized” process described below would never be subject to these limitations. Issuance Process for Authorized Tokens Unlike “open” token types, the number of “authorized” token types is unlimited. While the number of possible “authorized” token types is unlimited, however, any new “authorized” token generation must proceed through an account authorization path through a genesis record chain originating with the account that ultimately has the authority to issue any new type of token with any label: the “root” account, which would be the “local account” specified in the first genesis record within the blockchain. In at least one embodiment, this "root" account would be designated through the issuance of a genesis record by using the empty string as a tag, which the genesis record would convey to the root account final authority over the issuance. of all other accounts. Authorized token types would be generated through the following “issuance” process involving genesis records. According to this process, in at least one embodiment, new tokens can only be issued, and new token types can only be declared and defined, if these tokens and token types are issued and declared and defined by individual accounts that are explicitly authorized to do it. According to the process described below, given two token types, one can be considered a “derived” token type and the other a “base” token type if the existence and configuration of the “derived” token type somehow depends on of the existence and configuration of the “base” token type. A new token type is considered to be derived from a base token type if the genesis record of the derived type somehow references a base token type. Except for token types declared and defined by the “root” account, all authorized token types are derived from some base token type, including base token types within this reference chain. I CCCI n / l 7Π7 / Β / ΥΙΛΙ 100 The issuing account indicated in a genesis record must be authorized to issue derivative tokens based on the base token's “reissue” setting. Additionally, this issuing account must cryptographically sign the genesis record of the derived token type. In at least one embodiment, the label of the first token type (the "derived" type) is constructed into the label of the second token type (the "base" type). In such an embodiment, a new token type is considered to be derived from a base token type only if the base type label consists of the same characters that form the initial portion of the derived type label. In another embodiment, one token type may be considered the “base” of another “derived” token type if the local account of the base token type is counted as the issuing account used to issue the derived token type, and if the registry genesis of the derived token type refers to the base token type. This alternative system can be useful in the case where no specific restrictions are placed on the labels that the derived tokens will use. The “reissue” setting for a base token determines which account is authorized to issue a new type of token derived from that base token. The issuing account of a derivative token is the account that is authorized to issue new derivative tokens based on the “reissue” setting of its base token. Configuring New Issuance of Authorized Tokens In at least one embodiment of the present invention, if "new issue" is set to "original issuer" or a comparable indicator, then only the issuing account specified in the genesis record of the base token type can declare new derived types that derive of a particular type of base. For example, if 'tok' is a base token type with the new issuance setting 'original issuer', and 'tok.derived' is a token type derived from 'tok', then the genesis record that originally issues ' tok.derived' is only valid if your “issuing account” is the same “issuing account” that signed the genesis account “tok'. If “new issuance” is set to “local” or a comparable indicator, then the local account of a base token can issue new derived tokens directly; the local account of the base token would be the issuing account of the new type of derived token. For example, if 'tok' is a base token type with the new issuance setting 'local', then the genesis record issuing a new derived token type 'tok.derived' would specify an issuing account that is the local account associated with “tok'.

[0002] If “new issue” is set to “bearer” or a comparable indicator, then any account may transform some portion of the user tokens it holds into a new derived type; this action would be destructive of the original base tokens. In this case, i ccci η / ι znz / E / YiAi 101 an account with tokens of type “tok” could issue new derived tokens of type “tok.deríved”, as long as the new issuance configuration of “tok” is “bearer”. Authorized Token Supply Configuration In at least one embodiment of the present invention, the "supply" configuration specified in a genesis record controls whether or not the total aggregate value available for a given token type can be increased, and if so, which account is authorized to increase that supply. If a new token type is defined with “supply” set to “unlimited” or a comparable indicator, then the local account for that token type can arbitrarily increase the aggregate value of that token within the blockchain; records that use that token's local account as a source account (and signed by the local account) will be valid even when they exceed the token value stored in the local account. If a new token type is defined with “supply” set to “fixed” or a comparable flag, then only the token value specified in the genesis record will be created. If a new token type is defined with “supply” set to “original issuer” or a comparable indicator, then the total aggregate value of issued tokens of that type can only be increased by the issuing account of that genesis transfer record . In at least one embodiment, records (such as transfer records or trade order records) that use such issuing account as a source account will be valid even when they exceed the token value stored in that issuing account, as long as the authority of that issuing account is not itself restricted by a more restrictive genesis record with reference to its base token type. Whenever a derived token type is declared and defined, unless the base token type has its supply set to “unlimited”, the value specified in the genesis record of the derived token type will extract the total supply available to the base token type (that is, the aggregated total value of all authorized tokens of the base token type). In this way, the total aggregate value of all tokens of a given base token type and all of its derived types cannot exceed the authorized supply for that base token type. The following scenario descriptions illustrate the interaction of the “new issue” and “supply” configurations: (A) The token type TokenA is declared in a new genesis record with the “new issue” field set to “local”, the “supply” field set to “unlimited”, and the local account set to Account_A. I CCCI n / l 7Α7 / Β / ΥΙΛΙ 102 In this case, Account_A can, at any time, increase the total aggregate value of TokenA tokens on the blockchain. Account_A may also issue new types of derived tokens that reference Token A as a base token at any time. (B) Account_A declares a new token with label “Token A.Child T in a new genesis record with base token “Token A”, field “new issue” set to “local”, field “supply” set to “original issuer” and the local account set to Account_B. The token value in the genesis record is 10,000. In this case, Account_B can declare a new derived token with the base token 'Token_A.Child_T, which has the label 'Token_A.Child_1.Grandchild'. Without any intervention from Account_A, Account_B can only declare the full 10,000 token value of Token_A.Child_1 .Grandchild, which further depletes the token balance of Token_A.Child_1. Account A, however, can issue new tokens of Token A.Child 1 at will through additional genesis records, replenishing the balance of Account_B of Token_A.Child_1, and allowing Account_B to increase the total aggregate value of tokens of TokenA . Child_ LGandild. (C) Account_A declares a new token with the label 'Token_A.Child_2' in a new genesis record that has 'Token_A' as its base token type, with the 'new issue' field set to 'local', the “supply” set to “fixed” and the local account set to Account_C. The token value in the genesis record is 10,000. In this case, Account_C can issue a new genesis record that declares a new token type with the label “Token_A.Child_2.Grandchild\ that has a base token type “Token_A.Chile_2”. The maximum total value of Token_A.Child_2.Grandchild tokens that Account_C can declare is 10,000, which further depletes the balance of Token_A.Child_2. Since the supply of 'Token_A.Child_2' is fixed, more than 10,000 additional tokens will never be declared for Token_A.Child_2 and all its derived token types in total. In at least one embodiment, “new issue” is set to “original issuer” and “supply” is set to “fixed” by default if the settings are omitted from the genesis record. In the case of a new derived token type, in at least one embodiment, “new issue” can only be set to “local” if the genesis record of the original base token type also sets the “new issue” setting to "local". A derived token type cannot have a more liberal issuance policy than its base token type. i ccci η / ι znz / E / YiAi 103 Additionally, in the case of a new derived token type, in at least one embodiment, “supply” can only be set to “fixed” if the base token type has a “supply” setting of “fixed” or “original issuer.” ”. However, if the base token type has a “supply” setting of “unlimited”, then the new derived token type can be set to any of “fixed”, “original issuer”, or “unlimited”. This means that an account issuing a new derived token can only specify a “supply” setting that is at least as restrictive as the “supply” policy it is subject to itself. “Authorized” and “open” tokens can also be issued for smart contracts (where the address of the smart contract is the local account in the genesis registry). These smart contracts, implemented as Turing-complete code, can transfer and issue tokens and perform any other actions permitted by a non-contractual account. Smart contracts can limit or automate how tokens are issued or distributed. Authorization Contracts, Authorization Filters v Authorization Cascade Token issuers and creators of new Token Types may, from time to time, wish to restrict the use and ownership of tokens to certain qualified entities and persons. Or, they may want to enforce certain rules for the transfer and acquisition of tokens - for example, purchasing by limiting the total number of accounts that can hold a particular token, or specifying a minimum holding time for tokens, or whatever. another arbitrary limitation that can be placed through the use of computer logic. The use cases specified elsewhere in this description list a variety of restrictions that may be desirable for token issuers. To specify and enforce these limitations through the block validation process of the blockchain, in at least one embodiment of the present invention, genesis records may specify Authorization Contracts and Authorization Filters that are used to control and enforce these limitations. limit user token transfers and operations. Genesis records may further be used to enforce these limitations on derived tokens through use of the Authorization Cascade configuration option specified herein. If a record is unauthorized, then it will not be added to the blockchain, or if it is added to the blockchain, it will not modify the global state of the blockchain system, and any token assignments it contains will not be reflected in the token balances within the global state. I CCCI n / l 7Π7 / Β / ΥΙΛΙ 104 In at least one embodiment, any data record that references a particular user token would be subject to authorization through the authorization subroutine referenced or specified within the genesis record that defines the type of that token. Genesis records, transfer records, trade order records, settlement records, transaction records that encapsulate other data records that reference the token of the user in question, and any other data records that reference tokens of the type of token in question would require such authorization if an authorization subroutine is specified. Due to the computational cost of executing the authorization subroutine, any blockchain record subject to authorization may need to allocate a higher native token charge than would otherwise be required if it were not subject to authorization. Some portion of the native token charge assigned with registration must be used to cover the total cost of executing the authorization subroutine. Authorization subroutines are invoked and executed during block validation, at the point when block construction nodes evaluate whether a block or blockchain segment is valid to be constructed. If an authorization subroutine returns False, the record in question is still considered valid and any block that includes the record is considered valid, as long as the record and block are otherwise valid and well-formed from all others. ways. However, no modifications will be made to the global state specified within this unauthorized record type, with the exception of using the native token charge to offset execution of the authorization subroutine. Prior to validation in at least one embodiment, the network node that first learns of a record will execute its authorization subroutines before new blocks are created and transmitted to the node network. In this way, no data record will be transmitted or included in any block unless properly authorized. This would happen immediately at the point where the user constructing a data record first sends it to a network node, and would only happen if the record is provided to the node by a trusted source. In at least one embodiment, only records signed with the private key of the node's own account would be authorized in this manner before being added to a block, to prevent nodes from becoming overwhelmed by the computational burden of analyzing too many records. Authorization filters, however, in at least one embodiment, are not Turing-complete, and cannot execute any arbitrary computing procedure. In at least one embodiment, one or more filters would be applied to a record before it is transmitted to the network. 105 blockchain. If a record does not meet these filters, it cannot be incorporated into a valid block and will not be transmitted to the network at all. In at least one embodiment, the authorization filters will consist of pattern definitions of the type found within the pattern binding records (described below). For example, in at least one embodiment, pattern definitions may be written using a declarative query language, such as XPath. Similar to the process used to identify objects that meet the pattern definitions of pattern binding records, the pattern definition of an authorization filter will be applied to the set of objects that constitute and / or are related to the record that It is authorized. If the objects do not fit the filter - if there are no conforming objects within this set of objects - then the registration is not authorized. In any other way, it is authorized. In the case of a registry that operates with one or more derived tokens, in at least one embodiment, after the authorization filters and authorization subroutines corresponding to the token types named in the registry have been applied, the configuration of The base token types is examined by whatever node is evaluating and processing that record. If the base token types specify that the “authorization cascade” field is True, this will cause the node to apply the authorization filters and authorization subroutines attached to the base token types' genesis records. In at least one embodiment of the present invention, the authorization subroutine of a genesis record would not return a Boolean value, but rather would return the number of tokens that are authorized to be transferred or traded. In this way, the authorization subroutine can increase the number of tokens or decrease the number of tokens that are ultimately received as part of the transfer or transaction. In this way, a form of interest could be distributed to token holders, or maintenance fees could be imposed on token holders. Any increase in token value would reduce the total number of tokens issued or can be issued according to the genesis record; any decrease in token value would increase the tokens available for issuance. An unauthorized registration would cause the subroutine to return a negative number. Alternatively, the authorization subroutine could return a complete instance of the same record type that it receives as input. In such a case, the authorization subroutine may transform any aspect of the record, leave it unchanged, or, if the record is invalid, return an error code of some type. Transfer Record I CCCI Π / I 7Π7 / Β / ΥΙΛΙ 106 A transfer record moves a token value out of an originating account or address and to a destination account or address within the global state of a blockchain system. A transfer record is acceptable for inclusion in a new blockchain block if it is well formed, has been signed by the private key of the source address, and is otherwise valid. For a transfer record to be valid, for example, processing the record must never result in a negative token balance, or result in the global state of the blockchain itself being invalid. Transfer records may incorporate the following data (and possibly other data as well, although not all elements and characteristics are necessary in each modality): • Source account – the account that signs the transfer record, from which the value of the transferred token will be subtracted • Source token type – the type of token being transferred out of the source account • Source token value – the value in the type of source token being transferred • Source Token Fee – the amount to be included among block rewards to incentivize inclusion • Source Token Fee Token Type – the type of token being used to supply the charge; Typically, this will not be specified and will default to the native token type • Destination Account – account to receive the transferred tokens • Destination Token Type – the type of token received as a result of the transfer; if not specified, it is assumed to be the same as the source token type; if it is different from the source token type, then an attempt would be to match a trade order record that can be settled to allow the transfer to occur. • Target Token Value – The value in the target tokens that would be assigned to the target account. This field is optional and is only specified in the case where a different destination token type is specified than the source token type. If the source token type and destination token type are not the same, then a transfer record can only be included in the blockchain if it is matched with a trade order record and settled through a record. settlement that refers to the trade order. Depending on the implementation and modality, the transfer record and the settlement record may be two separate records, or the settlement may be represented by certain fields in the transfer record itself. In any case, the inclusion of such records in the blockchain will result in the target account receiving tokens of the target token type in an amount equal to the value of the i ccci η / ι znz / E / YiAi 107 destination token, and in the account that originated the trade order record that receives tokens of the source token type in an amount equal to the value of the source token. If a single trade record is insufficient to cover the full value of the transfer, then the settlement records would refer to a combination of trade orders. In at least one embodiment, a block construction node would generate this settlement record when processing a multi-token type transfer record. The block construction node would identify a matching trade order record — specifically, the trade order record that offers to buy source tokens in exchange for destination tokens at the most beneficial exchange rate among all known transaction orders — and construct a specialized settlement record that references that trade order as well as the transfer record. Any margin between the transfer record and the trade order - meaning any difference between the target token value and the token value that can be acquired by transacting the source token value - would be accumulated on the build node of blocks. According to this implementation, the multitoken type transfer record will only be accepted on the blockchain if it is accompanied by a valid settlement record, and if the settlement record points to a valid trade order record already embedded in the blockchain in a previous block (and active within the order book), or a valid trade order record that is included in the same new block. Additionally, a multi-token type transfer record cannot be added to a block if there is no trade order record available with a request price lower than the effective bid price represented by the value of the target token (or vice versa). In other words, a positive margin must be generated when processing a multi-token type transfer. In at least one embodiment, if the value of the target token is not specified at the same time that a target token type is specified within a multi-token type transfer record, then such transfer record may match any corresponding trade order. , provided that the trade order offers (or beats) the most advantageous bid or ask price specified in the standing order book at the time, excluding already matched transaction orders. The charge value included with a transfer record may be of the native token type, or it may be of a user-specified type. Depending on the implementation or modality, charges may or may not be required to be denominated in the native token type. An implementation that allows an account to store value for many token types allows, 108 among other things, more flexibility in terms of how fees are included with transfer transactions. In case charges are required to be denominated in native tokens, but if charges are denominated in a user specified rate, then they must match a trade order and be settled in a similar manner as described above in order to be accepted the transfer record. Another embodiment could combine transfer records and genesis records into a single type of record. A new token type would be declared and defined through the first transfer record containing that type being accepted on the blockchain. By convention, this would act as a “genesis” record; all rules described above would apply to such a record, and the fields described above would also be included in such record, but would be formatted and presented on the blockchain as a transfer record. The first transfer record to send tokens of a given type would act as the genesis record for that token type. Transactions v Transaction Protocol A transaction, according to at least one embodiment of the present invention, is an ordered collection of records and smart contracts that must all be added to the blockchain together, or none will be added at all. Furthermore, if a transaction and its constituent records and smart contracts are successfully added to the blockchain, no modification will be made to the global state of the blockchain system unless all records are fully authorized, and unless all smart contracts invoked while the transaction is being processed complete successfully. In other words, the transformation towards the global state of the blockchain system represented by each record and smart contract will only continue if all records and smart contracts within the transaction are able to successfully effect their individual transformations. The individual constituent records and smart contracts that comprise a transaction must always be processed and executed sequentially in the order specified by the transaction record itself - without intermediate records or smart contracts, except for arbitrage operations or other mandatory records that must be included, or smart contracts must be invoked, as a necessary implication of the inclusion of these constituent records in the blockchain. In at least one embodiment, a transaction record itself is unsigned; instead, it is secured by the signatures of the individual records it contains. The data of each of the I CCCI n / l 7Π7 / Β / ΥΙΛΙ 109 constituent records of the transaction include references to the previous record in the list, and each record is then signed individually, potentially by different parties depending on which account or originating address is included in each record. Under this arrangement, multiple parties can contribute separate records to the transaction, so that multiple entity records, and the global state transformations that each record represents, can be executed atomically. In such a scenario, the following multi-signature atomic transaction protocol can be followed to include records signed by multiple parties controlling multiple accounts. (a) The first record in the list is a “transaction header” record generated by the entity that will ultimately transmit the transaction to the blockchain network. This transaction header record is signed by this first party. (b) The first party can then add additional records to the transaction by generating new records, each record referencing the previous record. The first party would then sign each record independently. After adding records, the first party would then share the transaction and all of its constituent records with other parties, using a data transmission method capable of sharing data between computing devices. (c) Parties wishing to add records to the transaction would add records in sequence, with each record referencing the previous record, and with each record being independently signed using a private key that corresponds to its originating account or address. . Any entity that adds a new record to the transaction would receive the reference value necessary to reference any record preceding it in the list. In at least one embodiment, the reference made by a record within a list of transactions would be a deterministically generated hash of a standardized representation of the data from the previous record in the list. Since the data in each record incorporates a reference to the previous record in the list, including its cryptographic signature, no individual record in the chain can be extracted and processed separately and apart from its specific placement in the transaction. Any modification to any item in the constituent record list would invalidate the entire transaction. (d) After all parties have added records to the transaction list, the entire set of records will be shared with the first original party. The first part will add one more record to the list, a transaction footer record, and then transmit the I CCCI n / l 7Π7 / Β / ΥΙΛΙ 110 transaction and its list of records to the blockchain network. The transaction footer record must be signed by the same account that signed the transaction header record. The existence of the transaction header and transaction footer ensure that the transaction is executed together and cannot be reformed by a malicious actor. (e) Any block construction node that includes the transaction and its constituent records in a new block would first need to verify the correctness and validity of all internal references within the list of records of the transaction, as well as the validity of the individual records and their signatures. No individual constituent record would be accepted for inclusion unless the listed transaction record is included, along with all other constituent records, which require all to be valid and signed. In at least one alternative embodiment, a single omnibus transaction record may be constructed, which record would encapsulate all of the constituent records, without the constituent records each needing to be signed independently. In such an embodiment, if all constituent records have the same originating account or address, then the transaction record would only need to be signed using the private key of that issuing account. However, if the constituent records have different originating accounts or addresses, then the transaction record would have to be signed by multiple accounts or addresses; The transaction record would have to be signed once for each account or address mentioned as an originating account or address within its constituent records. Proposal Determination Procedure Within the present invention, proposal registries serve to incorporate external off-chain information into the blockchain, to be used for various purposes through smart contracts and specialized registries operating within the blockchain. Proposal records incorporate this information into the blockchain and establish its veracity, through a decision process involving proposal records, supporting reward allocation records, and decision records. In at least one embodiment of the present invention, the proposal determination has two phases: (1) the initial reward obtaining phase, in which the proposal records and the supporting reward allocation records assign the initial reward which will be distributed to the accounts that correctly determine the outcome of the proposal in the end, and (2) the determination phase, in which votes are cast in the form of token allocations for or against the proposal, such as is initially published in the proposal record 111 original. These votes are cast in the decision records. Under this procedure, the truth or falsity of a proposal is decided according to which side is willing and able to risk the highest value in tokens. Rewards assigned and distributed to the winning side (and sanctions incurred by the losing side) incentivize participants to vote for or against a proposal when those participants have specific independent knowledge of its truth or falsity - or when they are highly confident on other participants who have already cast their vote. A proposal is decided - and the proposal determination process is closed - after a well-defined amount of time has passed, typically measured in terms of blocks added to the blockchain. In at least one embodiment of the present invention, this amount of time is defined within the original proposal record when that record is added to the blockchain, initiating the determination process. Such a proposal record would specify a time (i.e. block height) when decision records will be accepted to the blockchain, and may also specify a time (i.e. block height) at which decision records will no longer be accepted. will be accepted to the blockchain, at which point the process is closed. At least one modality can decide whether to close the proposal determination process according to some function that considers both the differential value between the decision registers and the number of blocks that occur between the decision registers. If only low-value decision records are added to the end of the decision process, then it would be appropriate to reduce the amount of time required to approve (i.e., it would be appropriate to decrease the block height) before the determination process is closed. Alternatively, including a high-value decision record would extend the amount of time (increase the block height) before the determination process is closed. This will prevent late bidders from overwhelming a proposal that has a hard close, and will prevent short-time bidders from indefinitely prolonging a proposal that uses inactivity to determine the close. To provide participants in the proposal determination process with information that is potentially useful in deciding whether the proposal is true or false, according to at least one embodiment, the decision records and proposal records may incorporate evidence , or refer to external evidence, as to the truth they are stating. For example, IPFS URLs, W3C-defined DIDs, or some type of independently verifiable digital declaration could be added as supplemental data within I CCCI n / l 7Π7 / Β / ΥΙΛΙ 112 these records. References added to proposal records and decision records could point to image files, PDF files, or cryptographically signed files of any type. All participants and potential participants within the proposal determination process would benefit from the inclusion of such information because of the opportunity it would provide them to evaluate such evidence to make independent determinations as to the validity of the proposal. A particular embodiment of the proposal determination procedure is described with reference to Figure 8. At 810, a proposal record is accepted into the blockchain, which has the following fields: (a) a statement of the proposal; (b) an assignment of the reward; (c) a decision block at height D; and (d) an optional closing block at height C. In at least one embodiment, a proposal statement may also contain a proposal expiration field, which is the block height beyond which the proposal statement proposal cannot be considered true, regardless of the outcome of the proposal determination procedure. At 820, for all blocks up to the decision block at the height of block D, any account may allocate additional support rewards, which will be added to the initial aggregate reward available at block D+1. At 830, after the addition of block D, the initial decision records are transmitted over the network. At 840, the decision records are added to the new block being constructed. All smart contracts linked to a match pattern definition are invoked, potentially causing more decision records to be added. At 850, it is decided whether the closure block at height C has already been reached, but only if a closure block height was specified in the original proposal record. If the height C of the closing block has been reached (YES at step 850), then the proposal at 880 is decided by adding decision records on each side of the proposal. Rewards are assigned and contracts linked to patterns that match the decision are invoked. In any other way (NOT in step 850), it is determined at 860 whether a certain number of blocks are approved without additional votes being submitted. If so (YES at step 860), then the proposal is decided as described above for step 880. Otherwise (NO at step 860), then the block number is incremented and the block construction process a new block is started at step 870. The process then returns to step 840, where more decision records are added to the new block. All smart contracts linked to a match pattern definition are invoked, which can cause 113 potentially more decision records to be added. In at least one embodiment, a proposal record may further specify whether the inclusion of decision records in reference to that proposal will be restricted to certain accounts or addresses, whether that restriction would apply to the entire decision process, or only at the beginning. of the decision process (at or near the height of block D), and which accounts would be allowed to send decision records. In at least one embodiment, the system and procedure would have a proposal record that includes an optional list of specific accounts allowed (or required) to generate the initial set of decision records corresponding to that proposal record. Accounts not included in this list can only add decision records to subsequent blocks after the first decision records produced near the decision block. In at least one other embodiment, this restriction would not only apply to the initial set of decision records, but would also apply to all aggregated decision records for a given proposal. Only accounts in this list could generate decision records that belong to the proposal record in question, for the entire decision period. Alternatively, the proposal record can specify that a minimum number of accounts in this list must generate decision records for the process result to be valid. In at least one embodiment, a simplified decision process would be possible such that a proposal record would list only one account as allowed to generate decision records, and such that the proposal record would establish a closing block at height C that is a short distance from the decision block at height D, or even the same block. Following this approach, a user can generate a proposal that is intended to be decided by a single account (but in any case a separate account from the account that generated the proposal in the first place). In at least one embodiment, a proposal record may further be self-determined, such that the proposal is marked as already decided when the record is included in the blockchain. To enable this behavior, a field added to the proposal record would indicate that the proposal is self-decided. Such a proposal registration would not be subject to the proposal determination process described in this description, and its proposal would automatically be considered true. As a result, it is not necessary to include any reward proposal, beyond the standard fees used to incentivize inclusion in a block. I CCCI n / l 7Π7 / Β / ΥΙΛΙ 114 Proposal Reward Allocation The process of distributing proposal rewards to successful voting accounts in accordance with at least one embodiment of the present invention is described with reference to Figure 9. To determine the winning side of the proposal (True from False) according to at least one modality, the value of the tokens voting for each of the two sides is added. The side with the highest added value is then determined to be the “winning” side. Winning voters may receive a full refund of their tokens, while the tokens of all losing voters are added to the reward pool assigned to the winning voters, according to at least one embodiment of the present invention. In 910.1a assigned reward for block D+1, rD+i is the original reward of the proposal record plus the total of all supporting rewards. Starting at 920, the rD+N voting reward is distributed to the successful voting accounts in the D+N block, and in subsequent blocks. The initial voting reward for block D+N would be set to the previous block, with the reward where N = 1 being rD+i. At 930, it is determined whether or not the block with height D+N is the last block containing the winning votes regarding the proposal. If so (YES at step 930), the block building node, at step 940, will add the token value of all losing votes in blocks D+N and above and add the result to the current reward in the D+N block, whose value rD+N was previously set in the D+N-1 block. Subsequently, at step 950, the entirety of this combined reward will be distributed to the winning voting accounts in the D+N block, proportionally according to the token values ​​that each winning voting account puts at risk, and the process will end. In any other way (NOT at step 930), where the D+N block is not the last block to contain winning votes with respect to the proposal, the system proceeds to step 960, where it is determined whether the D+N block contains some vote in favor of the winning side of the proposal. If it does so, then at 970, a portion f(rD+N) of the decision reward in the D+N block will be distributed to the accounts voting with the winning side in the D+N block, proportionally according to the value of the token of each account. The remaining portion of the reward rD+N-f(rD+N) is then placed in reserve, to be used to increase the reward available in the next block, block D+N+1. The reward available for distribution within this next block, rD+N+i, will be equal to the remaining reward γο+ν-^+ν) plus a portion of the token value of the losing votes cast in block D+N, as indicated in step 990. Then, I CCCI n / l 7Π7 / Β / ΥΙΛΙ 115 increments the block number (N = N + 1) by 985 and processing returns to step 920 for the next block. If at step 960, it is determined that block D+N does not contain votes in favor of the winning side of the proposal (NOT at step 960), then no rewards are allocated in block D+N, and the entire unused reward rD+N is placed in reserve, to be used to increase the reward available for the next block, block D+N+1. In this case, the reward rD+N+i available to be allocated in block D+N+1 equals the total unallocated reward rD+N, plus the token value of the losing votes cast in block D+N, as indicated in step 980. Then, the block number (N = N + 1) is incremented by 985 and processing continues with step 920 for the next block. In at least one other embodiment (not illustrated), the ratio of token rewards in each block may be a function of both the timeliness of the vote and the amount of token placed at risk. An early but smaller amount put at risk will receive more reward than a late and larger amount put at risk. Proposal Statements When the proposal determination process successfully completes with a resulting decision that a proposal is “true,” then the proposal statement attached to the original proposal record is added to the global state as a data point that can be used throughout. the blockchain system to guide the flow of logic or otherwise modify the behavior of the system. Proposal statements are structured logical statements that (a) can be attached to another object within the global state of the blockchain system; (b) they can be attached to arbitrary strings that represent real-world concepts; or (c) they can be free-standing without being attached to any particular object. In at least one embodiment, a proposal statement that is attached to an account would add additional fields to that account, which can be accessed through reference to that account. Similarly, in at least one embodiment, a proposal declaration that is attached to a token type would add additional fields to that token type, which can be accessed via reference to that token type, or by reference to tokens of that type. Proposal statements can add one or more fields to the objects to which they are attached, or they can make logical assertions. In at least one embodiment, the declarations of the proposal would incorporate one or more Boolean declarations that each have a value, a Boolean operator, and a variable, field or characteristic of the object that describes the I CCCI n / l 7Π7 / Β / ΥΙΛΙ 116 Boolean statement. Such Boolean statements may be queryable, may match a pattern definition, or may be testable within the logic of a smart contract. In at least one embodiment, in the event that a statement of the proposal does not attach to any specific object within the global state of the blockchain system, the proposal itself exists by itself in a data structure that can be consulted together with other statements independent of the proposal. To reduce system bloat, data complexity, or computational load, how proposal statement data is stored may depend on the process by which the proposal is decided and which accounts participate in the proposal process. determination. In at least one embodiment, if the account that generates and signs a proposal record relates to the object to which the proposal statement is attached, then the proposal statement data will be stored with that object and will be retrievable with that object. Otherwise, the proposal statement data will be stored separately and can be retrieved separately from the object to which it is attached. In at least one embodiment, if a proposal record is generated and signed by the account to which your proposal statement is attached, then the proposal statement data will be stored along with that account in the global scope. . In at least another embodiment, if a proposal record is generated and signed by the local account or issuing account of a token type, then the proposal statement of that record may be stored along with any separate account to which it is attached, if that separate account has tokens of that type. In other embodiments, a proposal declaration attached to a token type would be stored along with the definition and configuration of that token type, as long as the proposal record that introduces the declaration is the local account or the issuing account. of the token type, or of the base or ancestor token types of the token type. In all three cases, an attempt to retrieve the attached object, whether an account definition or token type, will also retrieve the proposal declaration data that is attached to the object. However, in at least one embodiment, a proposal statement that is attached to an account or transaction type will not be stored and retrieved with the account or transaction type, unless the proposal record that entered that proposal statement proposal has been generated and signed by related accounts. Pattern Linking Records I CCCI Π / I 7Π7 / Β / ΥΙΛΙ 117 In at least one embodiment of the present invention, pattern linkage records link executable smart contracts within a blockchain with “pattern definitions.” Each such record may contain some or all of the following fields: an originating account or address, a token allocation used to supply charges and gas to offset processing (either as a combined field, or as two separate fields), a date expiration or block height, an execution frequency, a starting block, a smart contract or a reference to a smart contract, and a pattern definition. Pattern definitions are intended to match (a) records that might be added to the blockchain in future blocks, (b) particular system state transformations, or (c) events that occur within the course of a block being processed. forming or validating. In at least one embodiment, pattern definitions are written using a declarative query language, such as XPath. When such pattern definitions are evaluated relative to the records or events of a particular blockchain block, if they are found to match one or more such records, they are found to match one or more system state transformations performed by such records, or are found to match one or more such events, then smart contracts linked to those patterns are invoked. Such evaluation is carried out by the block construction node that is building the block in question, or the next block, depending on the modality. The block building node will be aware of the still viable pattern linking records that were added to the blockchain in some previous blocks. The node will iterate over that set of pattern binding records, matching its patterns to the records, state transformations, and events that have been included with the current block, or the most recently created block. Upon finding a match, the node will execute the smart contract referenced by that binding record. For example, a particular pattern could be defined that matches transfer records that transfer amounts greater than some specified value, and that also send tokens to some specified account. A pattern binding record containing such a pattern definition would cause any linked smart contract to be specified in the binding record to be executed in case a matching transfer record is added to the blockchain. Alternatively, a pattern binding record may match a state change that occurs during the course of evaluation of a block. For example, the contract I CCCI n / l 7Π7 / Β / ΥΙΛΙ Smart 118 of a linkage record could be executed in case the balance of some specified account exceeds some specified threshold. As an example, in at least one embodiment that uses XPath-like syntax for pattern definitions, the pattern definition that matches a transfer record with a value greater than 100 tokens may be implemented as a string of the form 7transfers[value >100]', whose pattern definition indicates that transfer objects that have a value greater than 100 are selected within a block. The pattern definition string ‘7transfers[value>100 and source_token_type=”RUC”]” would indicate that transfer records transferring more than 100 RUC tokens would match. In a more complex case, a transfer sent by an account that has attached a “jurisdiction” proposal to itself could match the pattern definition string 7transfers[account / jur¡sdict¡on!=”USA.NY”] '. A state transition of an account balance falling below 200 RUC tokens could match the pattern definition string 7accounts / 07201969 / tokens / RUC[value<200]', which would match if the account's new RUC balance 07201969 is less than 200 after the block has been processed, but was equal to or greater than 200 before the block was processed. In at least one embodiment of this type of pattern definition implementation, the root object of the expression may refer to a record type, or may refer to an object within the global state. If you are referring to a record type, then the records within a block would match. If it refers to an object in the global state, then a state transition that occurs as a result of processing a block would match. If a record matches the pattern definition, then that record is passed as an argument to the linked smart contract subroutine. If an object in the global state matches, then the record that embodies the change in global state (i.e., state transition) that occurs within that block is passed to the linked smart contract. A pattern binding record may need to include or allocate fees for the native token to incentivize its inclusion in a new block, and / or pay for the execution of the smart contract it references. Because such a charge assignment would get those charges from a specific account, the pattern binding record would need to be cryptographically signed by that account's private key. If fees are required to incentivize a block building node to include a pattern linkage record in a block, then the viability of that linkage may be limited by the number of native token fees that the linkage record includes. For example, a I CCCI n / l 7Π7 / Β / ΥΙΛΙ 119 pattern linkage registry may specify that it should be evaluated by block construction nodes for the G number of blocks, for which the computational effort, the registry allocates X tokens in charges. Each block for which the pattern linkage record is evaluated will claim some portion of these X fee tokens to be allocated to its own block reward. The allocation of a portion of the fee tokens X to the block reward for a given block is determined by some function f(X,G,N), where N is the current block. In a simple case, such that f(X,G,N) = X / G, each block in which the pattern is evaluated would get an equal share of the assigned charges. The block that first incorporates the pattern linkage record into the blockchain is incentivized to do so if the X / G ratio is high. In addition to charge tokens, each pattern binding record must also allocate enough native tokens to pay for the execution of the linked contract, i.e. “gas” tokens. Due to the “stopping problem” (designed by Turing and others), it is not known how many computing stages will be required for a linked smart contract to complete its execution. Each execution stage must consume a certain number of native tokens, and the total number of computational stages taken by a smart contract dictates the total cost of its invocation. Executing a long-lived or otherwise computationally heavy smart contract may deplete the supply “gas” tokens allocated through the bonding registry for this purpose. If the pattern bonding record spends all of its gas tokens before it has expired, that pattern bonding record will lose its viability before its scheduled expiration. After a pattern binding record is added to the chain, it must be evaluated for each block until it expires, or until you run out of native token fees to pay for the evaluation of your pattern relative to other block records, or tokens. “gas” to pay for the execution of your linked smart contract. After a block building node has executed a linked smart contract, the block building node will add a bonding reward record to the block, which record triggers the “gas” tokens that were spent through the execution of the linked smart contract to be allocated to the total block reward. In at least some embodiments, a pattern binding record may specify separate native token assignments for “gas” and “charges.” However, in other implementations, a single allocation of native tokens may represent all “gases” and “charges” in total. As charges and gas are consumed, both would draw the same I CCCI n / l 7Π7 / Β / ΥΙΛΙ 120 consumable quantity. In some embodiments, a “maximum charge” and / or a “maximum gas” may be specified per pattern binding record, which would set an upper limit for what portion of the tokens allocated to the pattern binding record can be consumed for each block. A Dutch-style auction similar in method to that described below relating to on-chain trading may be followed in at least one embodiment to determine which pattern linkage records to incorporate into the blockchain and process for each block. The processing of linkage records in a blockchain according to at least one embodiment of the present invention is described with reference to Figure 10. At 1010, the author node publishes a “pattern binding” record to the node network, including an assignment of charges. Then, at 1020, the proposed “pattern binding” record propagates throughout the network and awaits inclusion in a new block on the blockchain. In 1030, it is determined whether there are sufficient block inclusion charges allocated to the registry through the proposed “pattern linkage” registry. If so, (YES at step 1030), then the “pattern binding” record is added to the new block, and the new block is propagated and accepted into the blockchain via consensus at step 1040. Otherwise, (NOT at step 1030), the proposed “pattern binding record” is abandoned or delayed for inclusion at step 1035, and processing returns to step 1010. At step 1050, after the inclusion of pattern linkage records in a new block and the acceptance of that new block into the blockchain, their records are compared with pattern definitions of still viable linkage records (i.e. bonding records that have not expired and have not exhausted their charge allocation). If it is determined at step 1060 that the pattern definition of any binding record matches any event or record in the block (YES at step 1060), then the smart contracts associated with those binding records are executed at step 1070. A lock fee is deducted from the charge allocation of each binding record, and each linked smart contract is processed until it is terminated, or until the “gas” tokens allocated to its binding record are exhausted. In at least one embodiment, the results of these operations are incorporated into the next block that is added to the blockchain; some portion of these operations up to a certain threshold must be performed for that block to be considered valid. Alternatively, in at least one other embodiment, these operations are performed as a new block being I CCCI n / l 7Π7 / Β / ΥΙΛΙ 121 building, so that the results are incorporated into the same block that includes the records, transformations, or events that match the binding records. Following execution of the smart contract associated with a particular pattern binding record, an evaluation is performed at step 1080 to determine whether sufficient “gas” tokens and charges remain within the token allocation of that binding record, and whether the linking record has expired or otherwise not. If the binding record is not expir...

Claims

1. A computer-implemented method on a computer network, the computer-implemented method comprising: configuring a distributed electronic ledger in the electronic memory of one or more computers in a blockchain system, the distributed electronic ledger having a plurality of backward-interconnected blocks arranged as one or more instances of linear blockchain data structures, nonlinear block arrangements, n-dimensional lattice or mesh data structures, or directed acyclic graphs; configuring each of the interconnected blocks to include an ordered set of individual data records, such that at least one of the records reflects a transformation of at least a portion of the global state of the distributed electronic ledger;Configure the blockchain system to comprise a peer-to-peer network of computer nodes, with one or more computers configured as wallet nodes, and with one or more computers configured as block-building nodes; configure one or more wallet nodes to transmit one or more of the data records to one or more block-building nodes in the peer-to-peer network; and configure the one or more block-building nodes to construct one or more interconnected blocks in the distributed electronic ledger by selecting and ordering one or more of the data records to be included in said one or more new interconnected blocks.

2. The computer-implemented method according to claim 1 further comprising implementing in the blockchain system a trusted but verified data propagation process, wherein at least one block-building node is configured to create at least one new interconnected block in the blockchain system before verifying the correctness of one or more preceding blocks to which said at least one new interconnected block is linked.

3. The computer-implemented method according to claim 2, wherein the process of propagating trusted but verified data further includes the propagation of said at least one new interconnected block in the blockchain system by means of a gossip protocol.

4. The computer-implemented method according to claim 3, wherein the gossip protocol enables said at least one new interconnected block to be propagated through the blockchain system, further including: transmitting said at least one interconnected block through the gossip protocol as a block header, while excluding most of the data belonging to said at least one interconnected block.

5. The computer-implemented method according to claim 3, wherein the gossip protocol permits said at least one new interconnected block to be transmitted without one or more data records belonging to said at least one new interconnected block, such that said one or more data records are transmitted separately from said at least one new interconnected block.

6. The computer-implemented method according to claim 2, further comprising: at least one other block-building node that creates at least one next interconnected block on top of said at least one new interconnected block after said at least one new interconnected block is distributed to the blockchain system; and the at least one other block-building node simultaneously creates the at least one next interconnected block while one or more data records belonging to said at least one new interconnected block are downloaded by the at least one other block-building node, or while said at least one new interconnected block is validated.

7. The computer-implemented method according to claim 2, wherein the process of propagating trusted but verified data further includes causing the at least one block-building node to include a Bloom filter in a block header of said at least one new interconnected block in the blockchain system, such that the process of propagating trusted but verified data causes the at least one block-building node to distribute the Bloom filter with the at least one new interconnected block in the blockchain system.

8. The computer-implemented method according to claim 7, wherein the Bloom filter is configured to represent a set of distributed electronic accounting accounts or other data affected or operated during one of (i) the creation, (ii) the validation, or (iii) the execution of said at least one new interconnected block in the blockchain system.

9. The computer-implemented method according to claim 7, wherein the Bloom filter of a block is a data structure configured at least with the property that any account or other data found in the Bloom filter is likely or possible to have its state modified by the validation and execution of the block, or to have been operated on or otherwise affected by the block or by data records belonging to the block, and with the property that any account not found in the Bloom filter is certain not to change its state or be affected by the block or by data records belonging to the block.

10. The computer-implemented method according to claim 9, wherein the creation of said at least one new interconnected block further includes: identifying accounts affected or operated when one or more smart contracts are executed, or when one or more data records are added to said at least one new interconnected block; checking to ensure that each identified account is not contained within a Bloom filter of at least one previous interconnected block preceding said at least one new interconnected block; and if an identified account is contained within a Bloom filter of at least one previous interconnected block, stopping the execution of said one or more smart contracts or stopping the inclusion of said one or more data records, and discarding said smart contract or one or more data records from said at least one new interconnected block.

11. The computer-implemented method according to claim 2, wherein the process of propagating trusted but verified data uses the directed acyclic graph (DAG) data structure to arrange said at least one new interconnected block.

12. The computer-implemented method according to claim 11, wherein the process of propagating trusted but verified data allows said at least one new interconnected block to have subsequent references to one or more interconnected blocks or subchains in the blockchain system, thereby causing at least a portion of the distributed electronic ledger to constitute a directed acyclic graph (DAG).

13. The computer-implemented method according to claim 12, wherein the process of propagating trusted but verified data ensures that the multiple interconnected blocks or subchains being simultaneously constructed by said new interconnected block include records associated with distinct and mutually exclusive sets of accounts or other data, such that the multiple interconnected blocks or subchains upon which it is built affect mutually exclusive sets of accounts or other data.

14. The computer-implemented method according to claim 13, wherein the process of propagating trusted but verified data allows the multiple interconnected blocks or subchains to be quickly compared to determine if any of the multiple interconnected blocks or subchains operate on common accounts or subchains, other data.

15. The computer-implemented method according to claim 13, further comprising comparing the respective Bloom filters of the multiple interconnected blocks or subchains to determine with certainty that the interconnected blocks or subchains in the blockchain system affect or operate on mutually exclusive sets of accounts or other data.

16. The computer-implemented method according to claim 2, wherein the trusted but verified data propagation process enables the simultaneous creation of a plurality of new interconnected blocks in the distributed electronic ledger, such that multiple nodes in the blockchain system are creating one or more of the plurality of new interconnected blocks in parallel; and wherein the trusted but verified data propagation process ensures that data records are not widely propagated through the blockchain system prior to the creation of interconnected blocks, such that data records produced by a given node are shared only with certain other nodes within the blockchain system;and in which the process of propagating trusted but verified data ensures that a respective block-building node only creates said at least one new interconnected block using data records propagated by certain nodes within the blockchain system. I CCCI n / l 7P7 / B / YILI 186; 17. The computer-implemented method according to claim 2, wherein if a block-building node discovers that said at least one new interconnected block cannot be validated, said at least one new interconnected block is discarded together with any new or subsequent blocks built on top of said at least one new interconnected block; and wherein a block cannot be validated if one of the following situations occurs: (i) a Merkle tree root cannot be reproduced using a set of data records belonging to said block in the blockchain system, (ii) a block hash in said block is incorrectly specified, or (iii) a data record belonging to said block is invalid or violates a rule in the blockchain system.

18. The computer-implemented method according to claim 2, wherein the process of propagating trusted but verified data increases the transaction throughput of the blockchain system relative to the transaction throughput of a Nakamoto consensus proof-of-work blockchain system.

19. The computer-implemented method according to claim 3, wherein the at least one block-building node is an identifiable block-building node configured with a reward address that is included with at least one interconnected subject block being built by said at least one identifiable block-building node; and wherein said at least one interconnected subject block is a block cryptographically signed by said at least one identifiable block-building node using at least one cryptographic key associated with said reward address, wherein the at least one signed block is propagated on the blockchain network via the gossip protocol.

20. The computer-implemented method according to claim 20, wherein the at least one other block-building node implements a trust evaluation process, whereby said at least one other block-building node, upon receiving said signed block, determines whether to generate a new subsequent block based on said signed block or block header before validating said signed block or block header; wherein the trust evaluation process further includes evaluating whether said bounty address has signed any previous block propagated on the I CCCI n / l 7P7 / B / YILI 187 blockchain network, and wherein said previous blocks signed by said bounty address are valid or invalid.

21. The computer-implemented method according to claim 20, wherein the configuration of the trusted but verified data propagation process further includes at least one of: (a) configuring the signed block to specify a building fee as an amount of distributed electronic ledger tokens, the signed block being configured as an incentivized block, and at least one other block-building node generating a new subsequent block configured with a reference to said incentivized block; wherein the incentivized block-building fee is transferred from the reward address to a distributed ledger address specified by the at least one other block-building node;or (b) configure the signed block to specify at-risk tokens as a quantity of distributed electronic ledger tokens, the signed block functioning as a guaranteed block, and configure at least one other node on the blockchain network to construct a penalty ledger containing or referencing the guaranteed block, which penalty ledger, when incorporated into a new subsequent block, causes the specified at-risk tokens to be transferred from the reward address to a distributed ledger address specified by the at least one other node on the blockchain network, if the guaranteed block is invalid.

22. The computer-implemented method according to claim 1, wherein configuring the blockchain system further includes configuring at least one of the data records as a transaction record arranged as an ordered collection of constituent records, with each of the constituent records being either configured as a smart contract or as a record that is not a smart contract; and wherein at least one of the constituent records represents a state transformation of at least a portion of the global state of the distributed electronic ledger.

23. The computer-implemented method according to claim 22, wherein the blockchain system configuration further includes the transaction ledger incorporating a transaction header ledger, one or more additional instances of the respective constituent ledgers, and one or more cryptographic signatures. I CCCI n / l 7P7 / B / YILI 188 24. The computer-implemented method according to claim 23, wherein at least one of the one or more cryptographic signatures is a first-party signature, wherein the first-party signature further includes at least one of: digitally signing a standardized representation of a transaction footer record appended to instances of the respective constituent records, or digitally signing a standardized representation of the transaction record encapsulating the constituent records.

25. The computer-implemented method according to claim 24, wherein the transaction header record is configured to permit verification of the transaction record; and wherein verification of the transaction record includes determining that the transaction record is invalid unless the first party's signature is signed using at least one of the cryptographic keys of one or more distributed electronic accounting addresses specified by the transaction header record.

26. The computer-implemented method according to claim 25, further comprising: configuring at least one constituent record of the at least one transaction record to associate it with at least one reference to one or more preceding records that precede the at least one constituent record in the ordered collection of constituent records; wherein the at least one reference to the one or more preceding records is implemented as a deterministically generated previous record hash of a standardized representation of the data of the one or more preceding records; and wherein the standardized representation of the data of one or more preceding records includes at least one reference made in turn to the constituent records that still precede the preceding records, in the form of another previous record hash.

27. The computer-implemented method according to claim 26, further comprising matching at least one constituent record with at least one cryptographic signature, comprising: generating the at least one cryptographic signature by signing a standardized representation of the data of at least one constituent record, using cryptographic keys I CCCI n / l 7P7 / B / YILI 189 from at least one distributed electronic ledger address originating that constituent record; wherein the standardized representation includes the hash of the previous record corresponding to that constituent record.

28. The computer-implemented method according to claim 27, wherein the blockchain system configuration further includes a multi-signature atomic transaction protocol comprising: generating, by at least one blockchain system node, the ordered collection of constituent records, in each case including first a transaction header record, followed by one or more constituent record instances, and transmitting said ordered collection of constituent records to at least one other blockchain system node, or generating a transaction record instance; receiving, by at least one blockchain system node, the ordered collection of constituent records from at least one other blockchain system node, and in each case: generating a transaction record instance;or first updating said ordered collection of constituent records to include one or more additional constituent records and then transmitting said ordered collection of constituent records to at least one other node of the blockchain system, or generating a transaction record instance; the generation of a transaction record instance comprising encapsulating the ordered collection of constituent records in a transaction record, combined with one or more cryptographic signatures; and at least one node of the blockchain system that broadcasts one or more transaction records to the blockchain network, and at least one block construction node within the blockchain network that verifies the validity of one or more transaction records and the constituent records and cryptographic signatures of the one or more transaction records.

29. The computer-implemented method according to claim 28, wherein each of the one or more constituent records aggregated or included in the ordered collection of constituent records after the transaction header record includes at least one reference to at least one previous record preceding that constituent record in the at least one transaction record; wherein at least one reference to the at least one previous record in the ordered collection of constituent records is implemented as a deterministically generated previous record hash from a standardized representation of the data of the at least one previous record;and where the standardized representation of the data of at least one previous record in the ordered collection of constituent records includes at least one reference made in turn to at least one record belonging to the transaction record preceding the at least one previous record, unless the at least one previous record is a transaction header record; and wherein at least one of the one or more cryptographic signatures is signed using cryptographic keys from at least one distributed electronic ledger address originating from at least one of the one or more constituent records.

30. The computer-implemented method according to claim 22, further comprising configuring at least one block-building node to sequentially process each constituent record and smart contract within a transaction record, such that no other intermediate record or smart contract is processed until each constituent record and smart contract within the ordered collection of constituent records is processed and evaluated in the specified order, unless processing an intermediate record or smart contract is mandatory to execute at least one of the constituent records or smart contracts in the ordered collection of constituent records.

31. The computer-implemented method according to claim 23, further comprising the configuration of at least one block-building node to process the ordered collection of constituent records and smart contracts into at least one transaction record on an all-or-nothing basis, such that no transformation to any part of the global state of the distributed electronic ledger encoded by any constituent record or smart contract belonging to the ordered collection of constituent records proceeds if any individual constituent record or smart contract within the collection is invalid or fails to successfully perform the transformation of at least one transaction record.

Images