ABSTRACT
Abstract
An improved system implements Fitness Gradient Consensus including hash distance and bucket consensus variations within a digital blockchain by calculating the highest fitness value competing blocks to resolve conflicts and allocate the rewards associated with building new blocks. The consensus system applies conflict resolution formulas to incentivize block-building nodes to share blocks generated, as it completes construction, to improve chances of a reward, resulting in enhanced speed and security of blockchain.
The hash distance consensus utilizes a hash distance scalar value as part of its fitness metric, and the bucket consensus assigns tokens to buckets and calculates an aggregate value of the assigned tokens. A trust-but-verify variant increases transactional throughput and reduces linearity and computational constraints.
The system also utilizes novel record types, such as token genesis, transfer, transaction, trade order, settlement, proposition, determination, and pattern linkage records to facilitate the automation of financial, commercial and legal processes.
Description
RELATED APPLICATION
This application is a continuation of U.S. application Ser. No. 18/046,252, filed Oct. 13, 2022, which is a continuation of U.S. application Ser. No. 16/902,010 filed on Jun. 15, 2020, now U.S. Pat. No. 11,509,464, issued on Nov. 22, 2022, which claims the benefit of provisional application 62/861,086 filed on Jun. 13, 2019. The entire teachings of the above applications are incorporated herein by reference.
TECHNICAL FIELD
The present disclosure generally relates to a field of blockchain technology, which is also known as a distributed electronic ledger for storing data that multiple parties may access, modify, update, maintain and verify. More specifically, the present disclosure pertains to a consensus chain selection method (the Fitness Gradient consensus method) which simplifies or eliminates a wasteful and resource-intensive proof-of-work step in determining which chain or block should be selected from among competing chains and blocks to be used to continue building the blockchain. Additionally, the present disclosure pertains to certain complex distributed data records which interoperate to provide the distributed electronic ledger with certain specialized capabilities.
BACKGROUND
Distributed electronic ledgers or blockchains may be held or maintained by individual parties, or may contain entries for different parties and be replicated and distributed amongst various participants on a network. Distributed electronic ledgers are utilized for various applications, including exchange and recording of transactions in crypto currencies, such as, for example, transactions involving Bitcoin, Ethereum, Ripple (XPR) and other crypto currencies.
In addition, blockchains may also be used for recording and confirming the identity or existence of a person, object or event. The data records confirming such identity or existence may then be utilized for such application as confirming the identity of an account holder, or to confirm the relationship between two account holders, or to confirm the occurrence of an event in the real-world, and then to use that information to direct contract behavior.
Blockchains may also be utilized as a solution for recording, tracking and mediating ownership of an asset or multiple assets, the latter encoded as a token (or multiple tokens) on a blockchain, which may be transferred or otherwise manipulated via distributed electronic ledger elements such as smart contracts and on-chain data records.
In addition, blockchains may also be utilized to facilitate foreign exchange 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 (ex. a bank) that issues such tokens and trades or contracts with another institution (ex. a different bank) using smart contracts on a blockchain, in order to affect the transfer of asset tokens (and underlying assets) from one third-party entity to another. Such a transfer may be conditioned upon the verification that such requirements as may be set forth in the associated smart contract for that asset token have been met.
SUMMARY
In view of the foregoing, it is one object and a feature of example embodiments to provide a computing system and method for a distributed electronic ledger or blockchain implementation that utilizes a Fitness Gradient consensus method to determine which of the competing nodes is selected to receive a reward for a particular block or a chain having been added to the blockchain. Another object and a feature of example embodiments is to implement a Fitness Gradient consensus to determine which node is permitted to build the next block on the distributed electronic ledger or blockchain, or which block or chain is used as a base upon which to continue building the distributed electronic ledger or blockchain, and how to resolve a conflict between any block or chains in case of a conflict among alternative competing blocks or chains.
Another object and a feature of the present disclosure is the implementation of a Hash Distance consensus variant and/or a Bucket consensus variant of the Fitness 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 Fitness Gradient consensus method of the present disclosure reduce or eliminate the less efficient Proof-of-Work consensus method by re-conceptualizing the conflict resolution role and process of consensus as a generic problem of evaluating Fitness among competing blocks or chains. In accordance with at least one embodiment, the Hash Distance consensus variant may utilize a hash distance scalar value as part of its Fitness metric when comparing chains for conflict resolution. The Bucket consensus variant may incorporate the act of âfreezingâ tokens as a complementary method to generate a Fitness metric to use in comparing chains.
Another object and a feature of the present disclosure is the implementation of a Fitness Gradient consensus or a variant that incorporates the âtrust but verifyâ methodology for determining which of the competing blocks or chains is added to the blockchain or distributed ledger, and which of the competing nodes is selected to receive a reward for the block or chain that is being added to the blockchain or distributed ledger. This strategy significantly increases transactional throughput of the presently known systems by reducing linearity constraints (and other computational constraints that delay overall system processing) and allows the system-processing throughput to approach the theoretical maximum throughput for blockchains and distributed electronic ledger systems in general.
Another object and a feature of example embodiments is the use and implementation of the Bloom filters in order to represent all accounts affected during execution of a block. It also allows the new block to be built without having to execute the prior block in order to determine which accounts may have been updated in the course of that block's execution.
Yet another object and a feature of the present disclosure is 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 a feature of the present disclosure is implementation of a method to stabilize the supply and price of blockchain tokens using information with regards to the native token fees specified in the data records added to new blocks. In addition, the present disclosure provides greater native token price and supply stability by using the on-chain data relating to the trades between native and user-defined token pairs as inflation or deflation indicators.
Still another object of the present disclosure is to implement a system and a method for implementation and maintenance of a network-connected distributed ledger computer system that includes (1) an interconnected network of a plurality of computers, each including a processor executing computer instructions stored in an electronic memory of each computer for implementing and maintaining a distributed electronic ledger system implemented as a backward-linked blockchain of multiple interconnected blockchain blocks; (2) a first node on said network of computers, wherein the processor of the first node executes peer-to-peer software to create a first competing block or a block chain segment to be added to the blockchain; (3) a second node on said network of computers, wherein the processor of the second node executes peer-to-peer software to create a second competing block or a block chain segment to be added to the blockchain; (4) the network computers (nodes) executing computer instructions that apply a Fitness Gradient consensus to calculate and apply a highest fitness value calculation among the competing first and second blocks or blockchain segments; (5) the nodes executing computer software in accordance with at least one embodiment for determining which of the first or second nodes is permitted to add a next block or a block chain segment on the blockchain and which of the first or second nodes is allowed to share a reward for the added block or the block chain segment; and (6) adding the next block or block chain segment onto the blockchain after the determination.
Another object and a feature of the present disclosure is use of different record types, including token genesis records, transfer records, trade order records, settlement records, proposition records, determination records, and pattern linkage records. These different records, and the Fitness Gradient consensus methodology and its variants are useful in (1) implementing real-world event-driven smart contract execution systems that utilize blockchains and blockchain-based systems; (2) identity confirmation processing using blockchains and blockchain-based systems; (3) asset title and tracking blockchains and blockchain-based systems; (4) currency-based asset tokens, foreign exchange trading and remittances processes utilizing blockchains and blockchain-based systems; and (5) implementing an automated system for the issuance, sale, transfer and trading of tokens that may be characterized as securities, and which are regulated as securities in accordance with multiple security regulations, rules and restrictions governing securities transactions.
Yet another object and a feature of the present disclosure is utilization of different record types, including without limitation token genesis records, transfer records, trade order records, settlement records, proposition records, determination records and/or pattern linkage records to implement derived and base tokens, and controlling the supply and value of tokens, as well as transfer and trading of tokens.
Another object and a feature of the present disclosure is utilization of different record types, including without limitation token genesis records, transfer records, trade order records, settlement records, proposition records, determination records and/or pattern linkage records to facilitate the exchange of different token types (ex. native tokens and different user tokens) and also implementation of other trading orders (ex. market orders, limit orders and stop-loss orders).
These and other objects, advantages, aspects and features of the present disclosure are as described below and/or appreciated and well understood by those of ordinary skill in the art.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing may be apparent from the following more particular description of example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments.
The above and other features and aspects of the present disclosure may become more apparent upon reading the following detailed description in conjunction with the accompanying drawings, in which:
FIG. 1 illustrates the general structure and organization of various components of a blockchain on a distributed network in accordance with at least one embodiment of the present disclosure.
FIG. 2 illustrates the general structure and organization of a blockchain in accordance with at least one embodiment of the present disclosure.
FIG. 3 illustrates the process flow for the Bucket consensus implementation of a Fitness Gradient consensus system and method in accordance with at least one embodiment of the present disclosure.
FIGS. 4 A and 4 B illustrate the Bucket consensus structure, organization and information stored in a bucket implementation of a Fitness Gradient consensus system and method in accordance with at least one embodiment of the present disclosure.
FIG. 5 illustrates a Fitness Gradient consensus determination between two competing blockchains A and B for the block N, in accordance with at least one embodiment of the Fitness Gradient consensus system and method of the present disclosure.
FIG. 6 illustrates the organization and data stored in a block in accordance with at least one embodiment of the present disclosure.
FIG. 7 illustrates a flowchart and algorithm of trading between native and user-defined token pairs in accordance with at least one embodiment that increases and/or assures the native token price and supply stability.
FIG. 8 illustrates proposition determination procedure in accordance with at least one embodiment.
FIG. 9 illustrates the process of distribution of proposition rewards to successful voting accounts in accordance with at least one embodiment.
FIG. 10 illustrates processing of linkage records on a blockchain in accordance with at least one embodiment.
FIG. 11 illustrates processing of trading records on a blockchain in accordance with at least one embodiment.
FIG. 12 A-D illustrates a simplified process of block propagation processing using the âtrust-but-verifyâ variation of the Fitness Gradient consensus using Bloom filters in accordance with at least one embodiment.
FIG. 13 A illustrates a ranking by âfitnessâ of the blocks with Bloom Filters for a simplified process using the âtrust-but-verifyâ variation of the Fitness Gradient consensus in accordance with at least one embodiment.
FIG. 13 B illustrates the difference between a linear blockchain and a directed acyclic graph implementation of the âtrust-but-verifyâ variation of the Fitness Gradient consensus in accordance with at least one embodiment.
DETAILED DESCRIPTION
<para-num num="[003
RELATED APPLICATION
This application is a continuation of U.S. application Ser. No. 18/046,252, filed Oct. 13, 2022, which is a continuation of U.S. application Ser. No. 16/902,010 filed on Jun. 15, 2020, now U.S. Pat. No. 11,509,464, issued on Nov. 22, 2022, which claims the benefit of provisional application 62/861,086 filed on Jun. 13, 2019. The entire teachings of the above applications are incorporated herein by reference.
TECHNICAL FIELD
The present disclosure generally relates to a field of blockchain technology, which is also known as a distributed electronic ledger for storing data that multiple parties may access, modify, update, maintain and verify. More specifically, the present disclosure pertains to a consensus chain selection method (the Fitness Gradient consensus method) which simplifies or eliminates a wasteful and resource-intensive proof-of-work step in determining which chain or block should be selected from among competing chains and blocks to be used to continue building the blockchain. Additionally, the present disclosure pertains to certain complex distributed data records which interoperate to provide the distributed electronic ledger with certain specialized capabilities.
BACKGROUND
Distributed electronic ledgers or blockchains may be held or maintained by individual parties, or may contain entries for different parties and be replicated and distributed amongst various participants on a network. Distributed electronic ledgers are utilized for various applications, including exchange and recording of transactions in crypto currencies, such as, for example, transactions involving Bitcoin, Ethereum, Ripple (XPR) and other crypto currencies.
In addition, blockchains may also be used for recording and confirming the identity or existence of a person, object or event. The data records confirming such identity or existence may then be utilized for such application as confirming the identity of an account holder, or to confirm the relationship between two account holders, or to confirm the occurrence of an event in the real-world, and then to use that information to direct contract behavior.
Blockchains may also be utilized as a solution for recording, tracking and mediating ownership of an asset or multiple assets, the latter encoded as a token (or multiple tokens) on a blockchain, which may be transferred or otherwise manipulated via distributed electronic ledger elements such as smart contracts and on-chain data records.
In addition, blockchains may also be utilized to facilitate foreign exchange 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 (ex. a bank) that issues such tokens and trades or contracts with another institution (ex. a different bank) using smart contracts on a blockchain, in order to affect the transfer of asset tokens (and underlying assets) from one third-party entity to another. Such a transfer may be conditioned upon the verification that such requirements as may be set forth in the associated smart contract for that asset token have been met.
SUMMARY
In view of the foregoing, it is one object and a feature of example embodiments to provide a computing system and method for a distributed electronic ledger or blockchain implementation that utilizes a Fitness Gradient consensus method to determine which of the competing nodes is selected to receive a reward for a particular block or a chain having been added to the blockchain. Another object and a feature of example embodiments is to implement a Fitness Gradient consensus to determine which node is permitted to build the next block on the distributed electronic ledger or blockchain, or which block or chain is used as a base upon which to continue building the distributed electronic ledger or blockchain, and how to resolve a conflict between any block or chains in case of a conflict among alternative competing blocks or chains.
Another object and a feature of the present disclosure is the implementation of a Hash Distance consensus variant and/or a Bucket consensus variant of the Fitness 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 Fitness Gradient consensus method of the present disclosure reduce or eliminate the less efficient Proof-of-Work consensus method by re-conceptualizing the conflict resolution role and process of consensus as a generic problem of evaluating Fitness among competing blocks or chains. In accordance with at least one embodiment, the Hash Distance consensus variant may utilize a hash distance scalar value as part of its Fitness metric when comparing chains for conflict resolution. The Bucket consensus variant may incorporate the act of âfreezingâ tokens as a complementary method to generate a Fitness metric to use in comparing chains.
Another object and a feature of the present disclosure is the implementation of a Fitness Gradient consensus or a variant that incorporates the âtrust but verifyâ methodology for determining which of the competing blocks or chains is added to the blockchain or distributed ledger, and which of the competing nodes is selected to receive a reward for the block or chain that is being added to the blockchain or distributed ledger. This strategy significantly increases transactional throughput of the presently known systems by reducing linearity constraints (and other computational constraints that delay overall system processing) and allows the system-processing throughput to approach the theoretical maximum throughput for blockchains and distributed electronic ledger systems in general.
Another object and a feature of example embodiments is the use and implementation of the Bloom filters in order to represent all accounts affected during execution of a block. It also allows the new block to be built without having to execute the prior block in order to determine which accounts may have been updated in the course of that block's execution.
Yet another object and a feature of the present disclosure is 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 a feature of the present disclosure is implementation of a method to stabilize the supply and price of blockchain tokens using information with regards to the native token fees specified in the data records added to new blocks. In addition, the present disclosure provides greater native token price and supply stability by using the on-chain data relating to the trades between native and user-defined token pairs as inflation or deflation indicators.
Still another object of the present disclosure is to implement a system and a method for implementation and maintenance of a network-connected distributed ledger computer system that includes (1) an interconnected network of a plurality of computers, each including a processor executing computer instructions stored in an electronic memory of each computer for implementing and maintaining a distributed electronic ledger system implemented as a backward-linked blockchain of multiple interconnected blockchain blocks; (2) a first node on said network of computers, wherein the processor of the first node executes peer-to-peer software to create a first competing block or a block chain segment to be added to the blockchain; (3) a second node on said network of computers, wherein the processor of the second node executes peer-to-peer software to create a second competing block or a block chain segment to be added to the blockchain; (4) the network computers (nodes) executing computer instructions that apply a Fitness Gradient consensus to calculate and apply a highest fitness value calculation among the competing first and second blocks or blockchain segments; (5) the nodes executing computer software in accordance with at least one embodiment for determining which of the first or second nodes is permitted to add a next block or a block chain segment on the blockchain and which of the first or second nodes is allowed to share a reward for the added block or the block chain segment; and (6) adding the next block or block chain segment onto the blockchain after the determination.
Another object and a feature of the present disclosure is use of different record types, including token genesis records, transfer records, trade order records, settlement records, proposition records, determination records, and pattern linkage records. These different records, and the Fitness Gradient consensus methodology and its variants are useful in (1) implementing real-world event-driven smart contract execution systems that utilize blockchains and blockchain-based systems; (2) identity confirmation processing using blockchains and blockchain-based systems; (3) asset title and tracking blockchains and blockchain-based systems; (4) currency-based asset tokens, foreign exchange trading and remittances processes utilizing blockchains and blockchain-based systems; and (5) implementing an automated system for the issuance, sale, transfer and trading of tokens that may be characterized as securities, and which are regulated as securities in accordance with multiple security regulations, rules and restrictions governing securities transactions.
Yet another object and a feature of the present disclosure is utilization of different record types, including without limitation token genesis records, transfer records, trade order records, settlement records, proposition records, determination records and/or pattern linkage records to implement derived and base tokens, and controlling the supply and value of tokens, as well as transfer and trading of tokens.
Another object and a feature of the present disclosure is utilization of different record types, including without limitation token genesis records, transfer records, trade order records, settlement records, proposition records, determination records and/or pattern linkage records to facilitate the exchange of different token types (ex. native tokens and different user tokens) and also implementation of other trading orders (ex. market orders, limit orders and stop-loss orders).
These and other objects, advantages, aspects and features of the present disclosure are as described below and/or appreciated and well understood by those of ordinary skill in the art.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing may be apparent from the following more particular description of example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments.
The above and other features and aspects of the present disclosure may become more apparent upon reading the following detailed description in conjunction with the accompanying drawings, in which:
FIG. 1 illustrates the general structure and organization of various components of a blockchain on a distributed network in accordance with at least one embodiment of the present disclosure.
FIG. 2 illustrates the general structure and organization of a blockchain in accordance with at least one embodiment of the present disclosure.
FIG. 3 illustrates the process flow for the Bucket consensus implementation of a Fitness Gradient consensus system and method in accordance with at least one embodiment of the present disclosure.
FIGS. 4 A and 4 B illustrate the Bucket consensus structure, organization and information stored in a bucket implementation of a Fitness Gradient consensus system and method in accordance with at least one embodiment of the present disclosure.
FIG. 5 illustrates a Fitness Gradient consensus determination between two competing blockchains A and B for the block N, in accordance with at least one embodiment of the Fitness Gradient consensus system and method of the present disclosure.
FIG. 6 illustrates the organization and data stored in a block in accordance with at least one embodiment of the present disclosure.
FIG. 7 illustrates a flowchart and algorithm of trading between native and user-defined token pairs in accordance with at least one embodiment that increases and/or assures the native token price and supply stability.
FIG. 8 illustrates proposition determination procedure in accordance with at least one embodiment.
FIG. 9 illustrates the process of distribution of proposition rewards to successful voting accounts in accordance with at least one embodiment.
FIG. 10 illustrates processing of linkage records on a blockchain in accordance with at least one embodiment.
FIG. 11 illustrates processing of trading records on a blockchain in accordance with at least one embodiment.
FIG. 12 A-D illustrates a simplified process of block propagation processing using the âtrust-but-verifyâ variation of the Fitness Gradient consensus using Bloom filters in accordance with at least one embodiment.
FIG. 13 A illustrates a ranking by âfitnessâ of the blocks with Bloom Filters for a simplified process using the âtrust-but-verifyâ variation of the Fitness Gradient consensus in accordance with at least one embodiment.
FIG. 13 B illustrates the difference between a linear blockchain and a directed acyclic graph implementation of the âtrust-but-verifyâ variation of the Fitness Gradient consensus in accordance with at least one embodiment.
DETAILED DESCRIPTION
A description of example embodiments follows.
While example embodiments have been particularly shown and described, it may be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the embodiments encompassed by the appended claims.
The present disclosure is now described with reference to the drawings, wherein the like reference numerals are used to refer to the like elements. In the following description, the following terms are useful for the understanding of the use and operation of a system or a component of a system that includes at least one embodiment of the present disclosure.
Blockchain Structure and Organization
A blockchain data structure is an append-only, immutable 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, the state of which at any given moment is determined by applying discrete data transformations in a certain, well-defined order. By design, a blockchain data structure is typically used to host a distributed electronic ledger, such that the individual data transformations of the distributed electronic ledger 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 structure 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 to the distributed electronic ledger itself that is implemented upon such a data structure.
A âBlockchain Systemâ is a system of computational devices connected to each other via a distributed data interchange network, within which, in combination with any associated software, a blockchain and distributed ledger may be implemented.
FIG. 1 illustrates the overall structure of a blockchain system utilized on a distributed data interchange network. A blockchain system 100 typically includes a blockchain processing device 110 , a wallet device 120 , a blockchain data browsing device 130 , and a vendor device 140 , all of which are connected 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 vendor devices 140 , each connected to the Internet 190 (or a distributed network). In addition to separate blockchain processing devices 110 , separate wallet devices 120 , separate blockchain data browsing devices 130 , and separate vendor 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 which are also connected 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, purpose-built computation device, or other type of computation device, with one or more 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 vendor device 140 , and the combination device 150 typically have the same components as the blockchain processing device 110 .
The blockchain processing device 110 functions as a âBlock-Building Nodeâ, which is also referred to as a âminerâ in proof-of-work blockchains. Block-Building 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-Building Nodes are also responsible for algorithmically confirming whether the 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 disclosure, each Block-Building Node is associated with an account or address on the blockchain, to which account or address block mining rewards may be assigned. Such an account or address can also be used by a Block Building Node to securely identify itself and its activities within the network and on the 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 may only include data records that are appropriately authorized. In addition to storing cryptographic keys and other secure data, Wallets are able to generate and cryptographically sign new data records and transmit them to one or more Block-Building Nodes, typically via the Internet 190 or other network.
The blockchain data browsing device 130 functions to provide users with a means to read, view or otherwise access data associated with the blockchain, on a read-only basis.
The vendor device 140 may include one or more computers or other computer processing devices that facilitate the activity of Blockchain Vendors. The term âBlockchain Vendorâ, in the context of the present 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 some manner verified, confirmed, provided or conveyed via a blockchainâfor example, identity verification services. A vendor device runs software that enables Blockchain Vendors to provide such services.
The term âNodeâ in the present application refers to a computer such as a mobile phone, smartphone, tablet, laptop, desktop computer, server computer, a purpose-built computation device or other computation device that runs blockchain peer-to-peer software and communicates with other similar computers operating on a connected distributed data interchange network like the Internet.
The term âNode Networkâ refers to a collection of computers running the same blockchain peer-to-peer software, working to build a single, shared blockchain, and connected to each other via a connected distributed data interchange network 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 may contain record and/or transaction data. Alternately, blocks may reference such data via a cryptographic hash or digest summarizing the data, which hash or digest may be generated by a separate data structure that contains the records and transactions, for example a Merkle tree. For cryptocurrency blockchains, cryptocurrency ownership is linked to 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, beginning at its origin.
The general structure of a linear blockchain data structure 200 is illustrated with reference to FIG. 2 . The blockchain data structure 200 is an append-only, immutable data structure that comprises one or more individual blocks 210 A-C, shown in FIG. 2 as
Blocks
10 , 11 and 12 . Each block 210 A-C represents a unique set of data records 220 A-C. These data records of a particular block may not be contained in that block, but instead may be represented in the block by one or more cryptographic hash values, either the root(s) of one or more a Merkle trees 225 A-D (shown in FIG. 2 for the Tx_Root hash for Block 210 B, or the hash of an aggregated data structure (such as, the hash of some key-value map). Each cryptographic hash 230 is unique for the data that it is derived from, and may by design change radically even if the smallest aspect of its underlying data is altered.
Each block 210 A-C on the blockchain data structure 200 can be described by, or in terms of the cryptographic hash of its contents 220 A-C. The âBlock Hashâ, in the context of the present application, is this cryptographic hash of the contents of a particular block. Each block refers to its preceding block in the chain 200 by that preceding block's block hash 240 A-C, and includes that reference amongst its own data (i.e. the data that is used to derive its own block hash). In other words, block 210 B stores as its own data the block hash 240 B of the preceding block 210 A. Each block may also store the timestamp 250 (shown for Block 210 B in FIG. 2 ), which could indicate the time of the formation or acceptance of the block onto the blockchain.
This organization secures the immutability of the blockchain data structure 200 . Given the existence of any block in a well-formed blockchain data structure (for instance, the last block on the chain), the entirety of the preceding chain, including both blocks and all the records they represent, are immutable. Any change to any record or any block may have a cascading effect on the cryptographic hashes that constitute the chain, and may invalidate any and all downstream blocks in their original form. Thus, any change in any record of the last block 210 N on the chain 200 may invalidate all downstream (linked) blocks.
A new node that enters 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 properly linked. This bootstrapping validation is performed in sequence, from the first block 210 A and its first record to the last block 210 N and its last record.
In addition, every new block generated by any Block-Building Node(s) on the Node Network must be validated by other Block-Building Nodes, or it may not be added to the Blockchain. Furthermore, because the validation process and new block creation process may be performed 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 more than one valid instance of the ledger or Blockchain exists on the network. This is decision process often termed as a âConflict Resolutionâ. The term âConsensus Algorithmâ refers to the deterministic procedure followed by the Block-Building Nodes of the network to unambiguously 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. Because all Nodes on 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 agreeing to a single distributed ledger or Blockchain.
The âTokenâ, in the context of the present application, refers to a unit of value that is tracked within the blockchain. Tokens belong to particular accounts or addresses, and may 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 instance, as a reward that incentivizes Block Building Nodes to contribute computational resources to the operation of the networkâor Tokens may be generated via certain types of records, namely the âGenesis Recordsâ.
Each Block Building Node keeps a duplicate copy of the token values associated with each account or address within the blockchain. At any given point, the current state of tokens, accounts or addresses is encoded within the blockchain as the whole series of records that have been added to the blockchain prior to that point. Thus, in order to reliably determine the current token balance for any given account or address, a node may execute and validate the entire history of the distributed ledger or Blockchain, creating and transferring tokens between accounts and addresses until the current state is reached. Once the full chain has been validated, updates are applied by accepting and validating, or by generating, new blocks.
The âAccountâ, in the context of the present application, is an address with which certain data on the blockchain is associated. Tokens, smart contracts, or other data may be associated with an account. The account number is related 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's key may be considered valid and included on the blockchain. In some embodiments, the account number may be a hash or other transformation of a single public key.
The âTransferâ, or âToken Transferâ, in the context of this application, is a particular record type that re-assigns a certain token value from the signing account to some destination account.
The âToken Feeâ, 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 disclosure deal with more complexity with regards to fees, because certain records are re-executed for a number of blocks in succession.
The âSmart Contractâ, in the context of this application, is a small executable program that may be added as a record to the blockchain. A variety of smart contract runtimes exist, and a variety of higher-level languages compile down to such contract runtime executables.
The âBlockchain Segmentâ, in the context of the present application, is a discrete, 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 canonical blockchain. Each block within a blockchain segment 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 blockchain's origin, and the block in question. When blockchain segments are compared for purpose of conflict resolution, they may typically both originate at the same block height.
Overview of Blockchain Consensus Algorithms
One 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 may implement a consensus algorithm as a way for different untrusted nodes to come to agreement as to the current state of the blockchain in question.
The present disclosure, in at least one embodiment, utilizes and implements the Fitness Gradient Consensus, and in other embodiments utilizes and implements certain variations of Fitness Gradient Consensus, including Hash Distance consensus and Bucket consensus. These consensus methods and systems replace known consensus methodologies, including the original Nakamoto âproof-of-workâ consensus methodology, and known âproof-of-stakeâ consensus methodologies, within a blockchain system.
Atypical blockchain comprises an ordered set of âblocksâ, wherein the order of these blocks is embodied in a chain of references from each block to its preceding block (or to multiple preceding blocks). Each back reference is a unique cryptographically-generated digest or hash of the contents of the preceding block. Such back reference data is accreted to the other data encapsulated in the block, which together is passed through a cryptographic digest function or hash function to determine the unique reference that may be contained in the subsequent block. Blocks within blockchains that utilize non-linear arrangements of blocks may contain multiple back references.
The creation, sequencing and linkage of new blocks, and the contents of each new block, are determined by network-linked computers (Block-Building Nodes) that have been granted the right to make decisions on behalf of the whole network, according to a consensus algorithm. In a blockchain system, multiple block-building nodes may be working simultaneously to create new blocks and add them to the blockchain, thereby growing the blockchain and adding new data records to it.
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 from among the different versions that it has learned about from other nodes over the network. Block-building nodes typically abandon the new blocks they are attempting to build after confirming that the blockchain version they are building upon has been superseded by a new version of the blockchain. The nodes may then proceed to generate new blocks that reference (i.e. build upon) the new version of the blockchain.
For example, in one embodiment, if the block-building nodes within a blockchain system are working to build a new block at height N, when one of those nodes successfully generates a valid new block at height N and links it to the canonical blockchain, this new expanded blockchain may supersede the prior version. At that point the nodes that become aware of the new version may begin working to build the subsequent block at height N plus 1, which may have reference back to the block at height N.
However, competing nodes may simultaneously propose alternate blocks and alternate chains. When two or more competing versions of the same blockchain vie for supremacy within a single blockchain system, this occurrence is known as a âfork.â Conflicts between different blockchain versions or segments caused by a fork can be resolved deterministically within a blockchain system provided that the nodes within the network are fully informed as to the nature of each fork. Being presented with the same set of choices, all nodes within a blockchain system may use the same consensus algorithm to choose the same fork. For this reason, a blockchain system may remain cohesive provided that all participating nodes implement the same consensus algorithm. Each node may use the consensus algorithm to determine which alternate chain terminating with a block at height N to reference when building a block at height N plus 1.
Within each block, data is represented as a set of records or transactions. Records and transactions included in 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 on which blocks and records are included in the blockchain and which are notâwhich agreement is enabled by the system's consensus algorithmâthe block-building nodes are able to ensure that the whole system maintains the same global state.
Some portion of the records or transactions within blocks typically memorialize the creation or transfer of tokens. Token values are re-assigned from a certain specified source addresses to certain specified destination address via individual data records, each of which is cryptographic signed to prove that each transfer is authorized. Alternately, tokens are added to accounts or to addresses as per the consensus algorithm when a block is created.
In cryptocurrency blockchains, a block-building node that successfully adds a new block to the blockchain may typically receive a token reward. In order to incentivize nodes to compete in producing new blocks and to validate future updates to the blockchain, each new block contains a record that assigns a token reward to an address specified by the node that creates the block. Including such an incentive acts to increase participation in the block-building 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 utilizes a proof-of-work algorithm, for example, miners receive token rewards for having solved certain computational problems. These block-building nodes earn the right to add new blocks to the blockchain after having solved a computational problem before any other node has done so.
Fitness Gradient Consensus Compared to Known Consensus Strategies
The Fitness Gradient consensus algorithm and the Hash Distance and Bucket consensus variations of the present disclosure, utilized with one or more embodiments, are distinct in a number of important ways from the known proof-of-concept and proof-of-stake consensus strategies that are used for various existing blockchains.
One important difference between the Fitness Gradient consensus method of the present disclosure, as compared to the existing and known consensus methodologies (including the proof-of-work and proof-of-stake consensus methodologies) is that in the Fitness Gradient system and method, no block or node is privileged. Instead, all active nodes may be simultaneously building blocks and broadcasting the blocks they are constructing. Every node is incentivized (but not required) to share every block it generates, as soon as it completes construction, in order to improve the node's chances for receiving a reward for the new block. If that block happens to have the highest Fitness among competing blocks, then the use of that block may spread across the network; a lower-Fitness block may be discarded.
By contrast, in the well-known blockchain consensus approaches that are in use today, a node may broadcast a block only after the node has attained some privileged status-which is different from the methodology used in the Fitness Gradient consensus of at least one embodiment of the present disclosure. Among the consensus approaches that are in use today, different consensus approaches may assign a block-building node its privileged status through different means.
Another difference between the Fitness Gradient consensus and existing known consensus methodologies is that existing approaches rely wholly on either computational power or cryptographic power to secure blockchain systems. By contrast, the Hash Distance consensus and Bucket consensus implementations of Fitness Gradient consensus, implemented in accordance with at least one embodiment, calculate Fitness through a process that combines both computational power and cryptographic power (i.e. control over tokens on the chain). By using a ratio of tokens sent within the blockchain per hash distance as a Fitness metric, Fitness Gradient consensus methods diminish or eliminate the possibility of computationally powerful nodes exerting concentrated influence over the production of blocks. Any node attempting to exert concentrated influence may have to control a disproportionate amount of both participating computational power and tokens held on-chain. In a widely distributed network, with many participating nodes, such possibility may be difficult if not impossible for a single actor to achieve, both technologically and also economically.
Another difference between the Fitness Gradient consensus of the present disclosure and known proof-of-work consensus and proof-of-stake consensus types is the way that nodes choose which block to reference when assembling new blocks (i.e., which block or blockchain segment to build upon), and by implication which node is given the right to include data records in the block and to assign the token reward of that block.
The Fitness Gradient and the Hash Distance/Bucket consensus methods of the present disclosure do not use separate algorithms or metrics when deciding which block to build upon on the one hand, and which chain to choose when resolving conflicts on the other hand. Instead, each potential new block that is broadcast to the network is evaluated as a competing chain with the same algorithm that is used to evaluate and compare potential forks. This simplification makes the application of the Fitness Gradient 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 needed to create and verify a new block, and also promotes participation of more nodes in the consensus/conflict resolution process.
In at least one embodiment of the present disclosure, single new blocks are evaluated as a fork or blockchain segment of height one, but are simultaneously evaluated against forks/blockchain segments of arbitrary height if the forks all branch from the same initial state.
In comparison, the known proof-of-work and proof-of-stake algorithms are concerned with determining which node may be permitted to broadcast the next block, on a per block basis. In the event that two nodes satisfy criteria to permit them both to generate the next block on 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 chain should be discarded, and which chain should be used to continue building upon.
Fitness Gradient consensus in general, as well as Hash Distance (which is a sub-type of Fitness Gradient consensus in at least one embodiment of the present disclosure) and Bucket consensus (which is a sub-type of Hash Distance consensus in at least one embodiment of the present disclosure) in particular, all use formulae to calculate a well-defined scalar value (i.e. Fitness) for each blockchain segment, in order to compare blocks or blockchain segments. These formulae determine whether one block or blockchain segment is selected over another on a non-binary basis (not strictly a yes/no validity choice). A large number of blocks and chains may be valid, but only the chain with the highest Fitness is chosen by participating nodes.
Nodes continually grow the chain, adding blocks and broadcasting the Fitness value of their chains across the network. When a node learns of a higher-Fitness chain, it requests and receives a chain update from the node in possession of that chain, and then undertakes block-generation activity building on that chain. In at least one embodiment, a node may be participating in new block-generation activity for one or a number of different chains simultaneously, but may discard the lower-Fitness chains (or segments) in favor of building on the higher-Fitness chain once it can confirm that the higher-Fitness chain is in fact valid.
In the known proof-of-work consensus systems, the determination as to whether or not a particular block is valid and qualified is a binary determination. Each of multiple âminerâ nodes may race to solve the math problem that may make its block valid. The first node to generate a valid block broadcasts that block, and thereby claims the right to specify the next block accepted by the network (and to claim the reward for the solved cryptographic problem and the new block creation/validation). 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 math 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 ruleset.
Similar
CLAIMS
Claims ( 22 )
1 . An electronic system comprising:
an interconnected network of a plurality of computers, each including a processor executing computer instructions stored in an electronic memory of each computer for implementing and maintaining a distributed electronic ledger system implemented as a backward-linked blockchain of multiple interconnected blockchain blocks; a first block-building node on said network of computers, wherein the processor of the first node executes peer-to-peer software to create a first competing block or blockchain segment to be added to the blockchain; a second block-building node on said network of computers, wherein the processor of the second node executes peer-to-peer software to create a second competing block or blockchain segment to be added to the blockchain, wherein each of the first and second block-building nodes implement a trust-but-verify procedure in which they begin working to create one or more new blocks before each respective node has completed verifying the correctness of a preceding block to which the one or more new blocks is linked; one or more evaluating nodes executing computer instructions that apply a consensus algorithm to calculate and assign a first fitness value to the first competing block or blockchain segment and calculate and assign a second fitness value to the second competing block or blockchain segment; and determine which of the first or second blocks or blockchain segments will be the next block or blockchain segment incorporated into said blockchain based on comparing the first fitness value and the second fitness value; and incorporate the next block or blockchain segment into the blockchain after such determination has been made.
2 . The system of claim 1 , wherein the first fitness value is a first numerical score that is derived from a state of the first competing block or blockchain segment, and the second fitness value is a second numerical score that is derived from a state of the second competing block or blockchain segment.
3 . The system of claim 1 , wherein each of the first fitness value and the second fitness value is a function of a numerical distance between the hash of each block on the chain, and a target hash of each block, and wherein said numerical distance is determined algorithmically by a software evaluation of one or more blocks of the blockchain.
4 . The system of claim 1 , wherein each of the first and second block-building nodes is configured to begin working to create one or more new blocks only after a time delay has passed since the creation of the preceding block.
5 . The system of claim 4 , wherein the time delay is defined in terms of a number of computational units required to be executed in sequence.
6 . The system of claim 1 , wherein the first and second block-building nodes do not broadcast individual records contained in the one or more new blocks, and wherein the evaluating nodes determine which of the first or second blocks or blockchain segments will be the next block or blockchain segment incorporated into said blockchain without downloading said individual records.
7 . The system of claim 1 , wherein the first and second block-building nodes propagate said one or more new blocks across the interconnected network via a gossip protocol, and said one or more new blocks are propagated across the interconnected network as a block header, while excluding one or more data records belonging to said one or more new blocks.
8 . The system of claim 1 , wherein the trust-but-verify procedure allows said one or more new blocks to have back-references to one or more sub-chains in the distributed electronic ledger system.
9 . The system of claim 1 , wherein the first and second block-building nodes exclude accounts from the one or more new blocks if said accounts appeared in the preceding block.
10 . The system of claim 1 , wherein each of said one or more new blocks contains a Bloom filter in the block header, the Bloom filter storing information regarding which addresses or user accounts within the system have had their state modified by one or more data records associated with the block.
11 . The system of claim 10 , wherein the Bloom filter is configured to represent a set of distributed electronic ledger accounts or other data affected or operated upon during execution of said one or more new blocks.
12 . The system of claim 11 , wherein if an account or other data is found in the Bloom filter then it is possible or likely to have its state modified by the validation and execution of the block, and if an account is not found in the Bloom filter then it is certain that the state of the account that is not found in the Bloom filter will be unchanged by the validation of the block.
13 . The system of claim 12 , wherein the Bloom filter of at least one preceding block is used by the first or the second block-building nodes on the network to determine which data records may be included in a new block that links to that preceding block, by excluding from the new block any data records that reference the same addresses or user accounts recorded in the Bloom filter of the preceding block.
14 . The system of claim 12 , wherein the first or the second block-building node is configured to compare respective Bloom filters of two blocks or sub-chains in order to determine if they are both operating upon any of the same accounts or other data.
15 . The system of claim 1 , wherein said one or more new blocks are arranged in a directed acyclic graph, DAG, data structure.
16 . The system of claim 1 , wherein if either the first or second block-building node discovers that said one or more new blocks cannot be validated, said one or more new blocks is discarded along with any new or subsequent block which is built upon said one or more new blocks; and wherein a block cannot be validated if: (i) a Merkle tree root cannot be reproduced using a set of data records belonging to said block in the distributed electronic ledger 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 distributed electronic ledger system.
17 . The system of claim 1 , wherein each of the first and second block-building node is configured with a reward account address, and each of the first and second block-building node signs each block it produces using a respective private key associated with the reward account address.
18 . The system of claim 1 , wherein each of the first and second block-building node assigns a risk rating to other nodes, and only builds on the preceding block without validation if the preceding block has originated from a node that satisfies a risk threshold of the respective first or second block building node.
19 . The system of claim 1 , wherein:
the one or more new blocks created by the first block-building node comprise a first incentivized block specifying a build fee, wherein the build fee is transferred from an account address associated with the first block-building node to an account address of another block-building node which generates a new subsequent block configured with a reference to said first incentivized block; and the one or more new blocks created by the second block-building node comprise a second incentivized block specifying a build fee, wherein the build fee is transferred from an account address associated with the second block-building node to an account address of another block-building node which generates a new subsequent block configured with a reference to said second incentivized block.
20 . The system of claim 1 , wherein:
the one or more new blocks created by the first block-building node comprise a first guaranteed block which includes an amount-at-risk, and another node in the interconnected network is configured to construct a penalty record that references the guaranteed block in response to determining that the guaranteed block is invalid, wherein said penalty record, when incorporated into a subsequent new block, causes the amount-at-risk to be transferred from the account address associated with the first block-building node to an account address specified by the other node in the interconnected network; and the one or more new blocks created by the second block-building node comprise a second guaranteed block which includes an amount-at-risk, and another node in the interconnected network is configured to construct a penalty record that references the guaranteed block in response to determining that the guaranteed block is invalid, wherein said penalty record, when incorporated into a subsequent new block, causes the amount-at-risk to be transferred from the account address associated with the second block-building node to an account address specified by the other node in the interconnected network.
21 . The system of claim 1 , wherein the first and second block-building nodes lock a plurality of associated tokens for a period of time in exchange for a portion of a reward, wherein the number of tokens locked increases the fitness value calculated for the block or blockchain segment within which those tokens were initially locked.
22 . In a computerized network of a plurality of computers, executing computer instructions stored in electronic memory for implementing and maintaining a distributed electronic ledger system, a consensus determination method comprising:
creating and maintaining in the electronic memory of at least one the plurality of networked computers the distributed electronic ledger, implemented as a backward-linked blockchain of a plurality of interconnected blockchain blocks; utilizing a consensus process for determining which of a first block-building node and a second block-building node of the computerized network is permitted to add a next block on said blockchain and which node is allowed to share a reward for the next block added to the blockchain; executing by a processor of the first block-building node on the network a peer-to-peer software to create a first competing block or a block chain segment to be added to the blockchain; executing by a processor of the second block-building node on the network a peer-to-peer software to create a second competing block or a block chain segment to be added to the blockchain, wherein each of the first and second block-building nodes implement a trust-but-verify procedure in which they begin working to create one or more new blocks before each respective node has completed verifying the correctness of a preceding block to which the one or more new blocks is linked; one or more evaluating nodes of the computerized network executing instructions that apply a consensus algorithm to calculate and assign a first fitness value to the first competing block or blockchain segment and calculate and assign a second fitness value to the second competing block or blockchain segment; and determining which of the first or second blocks or blockchain segments will be a next block or blockchain segment incorporated into said blockchain based on comparing the first fitness value and the second fitness value; and incorporating the next block or blockchain segment into the blockchain after the determination.
US19/027,456
2019-06-13
2025-01-17
Trust-But-Verify Blockchain System
Pending
US20250167995A1
( en )
Priority Applications (1)
Application Number
Priority Date
Filing Date
Title
US19/027,456
US20250167995A1
( en )
2019-06-13
2025-01-17
Trust-But-Verify Blockchain System
Applications Claiming Priority (4)
Application Number
Priority Date
Filing Date
Title
US201962861086P
2019-06-13
2019-06-13
US16/902,010
US11509464B2
( en )
2019-06-13
2020-06-15
System and method using a fitness-gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
US18/046,252
US20230261863A1
( en )
2019-06-13
2022-10-13
System and method using a fitness - gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
US19/027,456
US20250167995A1
( en )
2019-06-13
2025-01-17
Trust-But-Verify Blockchain System
Related Parent Applications (1)
Application Number
Title
Priority Date
Filing Date
US18/046,252
Continuation
US20230261863A1
( en )
2019-06-13
2022-10-13
System and method using a fitness - gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
Publications (1)
Publication Number
Publication Date
US20250167995A1
true
US20250167995A1 ( en )
2025-05-22
Family
ID=73744830
Family Applications (5)
Application Number
Title
Priority Date
Filing Date
US16/902,010
Active
2041-06-02
US11509464B2
( en )
2019-06-13
2020-06-15
System and method using a fitness-gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
US18/046,252
Pending
US20230261863A1
( en )
2019-06-13
2022-10-13
System and method using a fitness - gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
US19/006,689
Pending
US20250219825A1
( en )
2019-06-13
2024-12-31
Identity Permissioning Blockchain Systems and Methods
US19/006,686
Pending
US20250219824A1
( en )
2019-06-13
2024-12-31
Multidevice Blockchain Systems and Methods
US19/027,456
Pending
US20250167995A1
( en )
2019-06-13
2025-01-17
Trust-But-Verify Blockchain System
Family Applications Before (4)
Application Number
Title
Priority Date
Filing Date
US16/902,010
Active
2041-06-02
US11509464B2
( en )
2019-06-13
2020-06-15
System and method using a fitness-gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
US18/046,252
Pending
US20230261863A1
( en )
2019-06-13
2022-10-13
System and method using a fitness - gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
US19/006,689
Pending
US20250219825A1
( en )
2019-06-13
2024-12-31
Identity Permissioning Blockchain Systems and Methods
US19/006,686
Pending
US20250219824A1
( en )
2019-06-13
2024-12-31
Multidevice Blockchain Systems and Methods
Country Status (12)
Country
Link
US
( 5 )
US11509464B2
( en )
EP
( 1 )
EP3983907A4
( en )
KR
( 1 )
KR20220063147A
( en )
AU
( 1 )
AU2020291554A1
( en )
CA
( 1 )
CA3141042A1
( en )
CL
( 7 )
CL2021003329A1
( en )
CO
( 1 )
CO2022000054A2
( en )
CR
( 2 )
CR20240221A
( en )
IL
( 1 )
IL288930A
( en )
MX
( 1 )
MX2021015531A
( en )
PH
( 1 )
PH12021553118A1
( en )
WO
( 1 )
WO2020252479A1
( en )
Cited By (1)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20240297787A1
( en )
*
2020-07-02
2024-09-05
Steven Ali Ghabel
Blockchain-based authentication system and method
Families Citing this family (139)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US9407539B1
( en )
*
2011-06-24
2016-08-02
Amazon Technologies, Inc.
Techniques for utilizing network destination identifiers simultaneously announced from multiple locations
US11068979B1
( en )
*
2011-11-07
2021-07-20
Nyse Chicago, Inc.
Fee/rebate contingent order matching system and method
US12184781B2
( en )
2017-07-10
2024-12-31
Burstiq, Inc.
Systems and methods for accessing digital assets in a blockchain using owner consent contracts
EP3435270B1
( en )
*
2017-07-27
2020-09-23
Siemens Aktiengesellschaft
Device and method for cryptographically protected operation of a virtual machine
US12361488B2
( en )
2017-09-27
2025-07-15
Dtcc Digital (Us) Inc.
Method, apparatus, and computer-readable medium for compliance aware tokenization and control of asset value
US20190311357A1
( en )
*
2018-04-04
2019-10-10
Vijay Madisetti
Method and System for Exchange of Value or Tokens Between Blockchain Networks
US11640640B2
( en )
2018-01-23
2023-05-02
Click IPO Holdings, LLC
Systems and methods for allocating assets to directed and interest-based participants
US11063745B1
( en )
*
2018-02-13
2021-07-13
EMC IP Holding Company LLC
Distributed ledger for multi-cloud service automation
US11323530B2
( en )
*
2018-06-06
2022-05-03
International Business Machines Corporation
Proxy agents and proxy ledgers on a blockchain
US11475435B2
( en )
*
2018-09-19
2022-10-18
Jpmorgan Chase Bank, N.A.
Method and system for generating digital wallet accounts
US11341451B2
( en )
*
2018-10-10
2022-05-24
Questaweb Holdings Inc.
Hierarchical blockchain architecture for global trade management
US11514434B2
( en )
*
2018-11-06
2022-11-29
Capital One Services, Llc
Localized blockchain utilizing mesh networks for localized events
US11616816B2
( en )
*
2018-12-28
2023-03-28
Speedchain, Inc.
Distributed ledger based document image extracting and processing within an enterprise system
US20200387974A1
( en )
*
2019-04-16
2020-12-10
Erich Lawson Spangenberg
System and method for providing patent title insurance with centralized and distributed data architectures
US20200387975A1
( en )
*
2019-04-16
2020-12-10
Erich Lawson Spangenberg
System and method for providing patent title insurance with centralized and distributed data architectures
PH12021553118A1
( en )
*
2019-06-13
2022-08-01
Gutierrez Sheris Luis Eduardo
System and method using a fitness-gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
EP3754899B1
( en )
*
2019-06-20
2022-03-02
Telefónica Iot & Big Data Tech, S.A.
Method and system for inter-dlt networks trust enhancement
US20210035246A1
( en )
*
2019-07-30
2021-02-04
Intellectual Technologies PDE. LTD.
Intellectual property asset management system using distributed ledger technology
US11520904B2
( en )
*
2019-08-27
2022-12-06
Accenture Global Solutions Limited
AI-based blockchain hybrid consensus
US11245525B2
( en )
*
2019-09-10
2022-02-08
Bank Of America Corporation
Managing a third-party recipient digital resource vehicle via a distributed trust computing network
KR102057570B1
( en )
*
2019-09-16
2020-01-23
(주) 모ë¡ë³´ê¸°
Blockchain network
JP6710401B1
( en )
*
2019-12-05
2020-06-17
ï½ï½ï½ï½ï½ï½ ï½ï¼¡ï½ï½ï½æ ªå¼ä¼ç¤¾
Method and management server for managing object
CA3104145A1
( en )
*
2019-12-27
2021-06-27
10353744 Canada Ltd.
Computer system and computer-implemented method for creating a savings plan for specific purchases
EP3851974B1
( en )
*
2020-01-20
2023-07-26
Decard Ag
System and a method implementing a directed acyclic graph (dag) consensus algorithm via a gossip protocol
US11429602B2
( en )
*
2020-01-24
2022-08-30
Bank Of America Corporation
Multi-dimensional modeling of resource interaction processors
US12099997B1
( en )
2020-01-31
2024-09-24
Steven Mark Hoffberg
Tokenized fungible liabilities
US11245541B2
( en )
*
2020-03-30
2022-02-08
Lenovo (Singapore) Pte. Ltd.
Required meeting participant identification
US11538070B2
( en )
*
2020-04-13
2022-12-27
Linkplicity Gmbh
Blockchain-based system and method for peer-to-peer online advertising auction
US11539787B2
( en )
2020-04-30
2022-12-27
T-Mobile Usa, Inc.
5G enabled massively distributed on-demand personal cloud system and method
US11418587B2
( en )
*
2020-04-30
2022-08-16
T-Mobile Usa, Inc.
5G on-demand dynamically instantiated blockchain for highly distributed peer-to-peer consumer cloud
US20230169517A1
( en )
*
2020-06-24
2023-06-01
Wells Fargo Bank, N.A.
Compliance model utilizing distributed ledger technology
US12395552B2
( en )
2020-06-30
2025-08-19
Interdigital Patent Holdings, Inc.
Methods, architectures, apparatuses and systems directed to enablers for blockchain-enabled wireless systems
WO2022006361A1
( en )
2020-06-30
2022-01-06
Interdigital Patent Holdings, Inc.
Methods, architectures, apparatuses and systems directed to messaging through blockchain networks
CN111737363B
( en )
*
2020-07-22
2024-12-06
ç¾åº¦å¨çº¿ç½ç»ææ¯ï¼å京ï¼æéå ¬å¸
Blockchain operation method, device, equipment and storage medium
US20220036455A1
( en )
2020-07-28
2022-02-03
Dmg Blockchain Solutions Inc.
Selection of cryptographic identifiers in a block
US11651096B2
( en )
*
2020-08-24
2023-05-16
Burstiq, Inc.
Systems and methods for accessing digital assets in a blockchain using global consent contracts
CA3091660A1
( en )
*
2020-08-31
2021-11-03
Polymath Inc.
Method, system, and medium for blockchain-enabled atomic settlement
CN112132575A
( en )
*
2020-09-04
2020-12-25
æµåæºæ°ä¿¡æ¯ç§ææéå ¬å¸
Method for exchanging decentralized token with low sliding point and high fluidity
US11711286B2
( en )
*
2020-09-27
2023-07-25
International Business Machines Corporation
Compliance mechanisms in blockchain networks
US11750636B1
( en )
*
2020-11-09
2023-09-05
Two Six Labs, LLC
Expression analysis for preventing cyberattacks
CN114519044A
( en )
*
2020-11-20
2022-05-20
å¯æ³°åå·¥ä¸ï¼æ·±å³ï¼æéå ¬å¸
Data query method, block chain system, sharing device and query device
US11949788B1
( en )
2020-11-21
2024-04-02
CodeNotary Inc.
System and method to shorten cryptographic proofs
US11683173B2
( en )
*
2020-12-08
2023-06-20
International Business Machines Corporation
Consensus algorithm for distributed ledger technology
US12225108B2
( en )
*
2020-12-14
2025-02-11
Brandon E. D'Amore
Stranded blockchain
CN114666327B
( en )
*
2020-12-23
2023-12-19
å¯æ³°åå·¥ä¸ï¼æ·±å³ï¼æéå ¬å¸
Block packing method and device based on block chain transaction and electronic equipment
CN114760316B
( en )
*
2020-12-28
2023-09-26
å¯æ³°åå·¥ä¸ï¼æ·±å³ï¼æéå ¬å¸
Block chain construction method and related equipment
CN113269637B
( en )
*
2020-12-28
2024-06-18
ä¸æµ·é¶æ°ä¼åä¿¡æ¯ç§ææéå ¬å¸
Block chain-based intelligent device data certification and verification method
CN112749165B
( en )
*
2021-01-06
2024-05-28
ä¸æµ·é¶æ°ä¼åä¿¡æ¯ç§ææéå ¬å¸
Electronic data exchange method based on block chain
CN112819625B
( en )
*
2021-02-01
2023-11-28
æå·å¤æç¾ç§ææéå ¬å¸
Parallel chain arbitration consensus method, computer device, and storage medium
WO2022197650A1
( en )
*
2021-03-15
2022-09-22
Interdigital Patent Holdings, Inc.
Methods, architectures, apparatuses and systems directed to blockchain-enabled model storage, sharing and deployment for supporting distributed learning
CN113114465B
( en )
*
2021-03-19
2022-10-11
éå²æµ·å°ç§ææéå ¬å¸
Method and device for processing attribution authority, storage medium and electronic device
US11133936B1
( en )
*
2021-03-22
2021-09-28
Matthew Branton
Methods and systems for introducing self-contained intent functionality into decentralized computer networks
CN112995356B
( en )
*
2021-04-19
2022-05-06
æµæ±å·¥å大å¦
A blockchain-based domain name resolution service system and method
US11373170B1
( en )
2021-04-20
2022-06-28
Dmg Blockchain Solutions, Inc.
Custom mempool protocol associated with processing of cryptographic events
US11640639B2
( en )
*
2021-05-04
2023-05-02
Click IPO Holdings, LLC
Systems and methods for allocating fractional shares of a public offering
CN115374214B
( en )
*
2021-05-19
2025-05-16
ä¸å½ç§»å¨éä¿¡éå¢è¾½å®æéå ¬å¸
Data storage method, device, equipment and computer storage medium
EP4099253A1
( en )
*
2021-06-04
2022-12-07
Wrightbrothers Co., Ltd.
Service server, method, and computer-readable storage medium for providing tracking service for transportation device based on blockchain network system
CN113438308B
( en )
*
2021-06-23
2022-12-23
ä¸æµ·ç®èç½ç»ç§ææéå ¬å¸
Efficient communication method and system based on block chain
EP4117229A1
( en )
*
2021-07-05
2023-01-11
Bull SAS
Method for detecting anomaly(-ies) in a blockchain network and blockchain network implementing such a method
CN115577039B
( en )
*
2021-07-05
2025-12-19
è ¾è®¯ç§æï¼æ·±å³ï¼æéå ¬å¸
Block processing method, device, verification node and storage medium
CN113259494B
( en )
*
2021-07-12
2021-11-12
æ·±å³å¸åæµ·ååç§ææéå ¬å¸
File storage method and device, electronic equipment and storage medium
CN113595736B
( en )
*
2021-07-21
2022-06-14
æ·±å³å¸ä¿¡å®æ°åç§ææéå ¬å¸
Block chain based information transmission method, system, device and storage medium
CN117716666A
( en )
*
2021-07-29
2024-03-15
索尼éå¢å ¬å¸
Method for providing autonomous identity cloud service to user, cloud service method, cloud server, autonomous identity method
US12154042B2
( en )
*
2021-08-16
2024-11-26
Adobe Inc.
Systems for estimating terminal event likelihood
CN113658003B
( en )
*
2021-08-17
2024-03-29
å·¥é¶ç§ææéå ¬å¸
Transaction method, device, equipment and storage medium based on blockchain network
US11494760B1
( en )
*
2021-09-03
2022-11-08
Arif Khan
Creating and managing artificially intelligent entities represented by non-fungible tokens on a blockchain
CN113806800B
( en )
*
2021-09-14
2023-07-11
ä¸èçå·¥å¦é¢
Privacy protection method and system for improving communication efficiency and reasonably distributing rewards
CN113706056A
( en )
*
2021-09-23
2021-11-26
常å·å¸å ¬å ±èµæºäº¤æä¸å¿
Bidding unit performance identification early warning method, device, equipment and storage medium
US11546358B1
( en )
*
2021-10-01
2023-01-03
Netskope, Inc.
Authorization token confidence system
US20230130347A1
( en )
*
2021-10-26
2023-04-27
Mastercard Asia/Pacific Pte. Ltd.
Methods and systems for generating and validating transactions on a distributed ledger
CN116050508B
( en )
*
2021-10-28
2024-07-12
è ¾è®¯ç§æï¼æ·±å³ï¼æéå ¬å¸
Neural network training method and device
CN114221961B
( en )
*
2021-12-14
2024-03-26
æ·±å³åæµ·å¾®ä¼é¶è¡è¡ä»½æéå ¬å¸
Hierarchical DAG blockchain generation method, apparatus, medium, and program product
WO2023141519A2
( en )
*
2022-01-19
2023-07-27
Life Token Software, Inc.
Method and system for issuing tokens and providing tokenized rewards
KR20230115721A
( en )
*
2022-01-27
2023-08-03
주ìíì¬ ë¯¸ëì
Method for blockchain consensus, device of blockchain consensus, computer program for performing method therefor and computer readable storage medium storing same
JP7076757B2
( en )
*
2022-01-29
2022-05-30
ç´æ¨¹ æ´ç°
Blockchain system and computer program with improved throughput by dividing blocks
US20230245134A1
( en )
*
2022-02-02
2023-08-03
Walmart Apollo, Llc
System and method for automatic product source tracing
US12381731B2
( en )
*
2022-02-03
2025-08-05
Tassat Group Inc.
Method, controller, and computer-readable medium of a distributed ledger network for initiating a net transmission among a plurality of clients of the distributed ledger network
WO2023150659A1
( en )
*
2022-02-03
2023-08-10
Tassat Group Inc.
Computer-based platforms and systems for asynchronous parallel network operations and methods of use thereof
US12411714B2
( en )
*
2022-02-03
2025-09-09
Tassat Group Inc.
Method, controller, and computer-readable medium of a distributed ledger network for uninterrupted transmission processing and continuous net transmission among a plurality of clients of the distributed ledger network
US11948192B2
( en )
*
2022-02-09
2024-04-02
Jpmorgan Chase Bank, N.A.
Method and system for providing high-speed storage and retrieval of information
JP2025506047A
( en )
*
2022-02-14
2025-03-05
ãã£ã®ã¥ã¢ ãã¯ããã¸ã¼ãºï¼ ã¤ã³ã³ã¼ãã¬ã¤ããã
Integrated financial services platform and method of use
CN114827167B
( en )
*
2022-03-03
2023-10-17
æå·å¤æç¾ç§ææéå ¬å¸
Node selection and transaction transmission method, device and storage medium
US12033150B2
( en )
*
2022-03-14
2024-07-09
CipherTrace, Inc.
Systems and processes for generating a single cryptocurrency address mapping space for a plurality of cryptocurrencies by clustering
WO2023182902A1
( en )
*
2022-03-21
2023-09-28
NECHAEV, Mark Aleksandrovich
Blockchain technology based ownership distribution method and system
CN115208880B
( en )
*
2022-03-29
2023-11-10
æ·±å³å¤§å¦
Expected block generation method, expected block generation device, computer equipment and storage medium
US12175464B2
( en )
*
2022-04-15
2024-12-24
Block, Inc.
Blockchain agnostic token network
US20230334447A1
( en )
*
2022-04-15
2023-10-19
Tassat Group Inc.
Computer-based platforms and systems for asynchronous parallel network instruction architecture and methods of use thereof
CN114760078B
( en )
*
2022-06-15
2022-09-06
å京亿èµéç§æåå±æéè´£ä»»å ¬å¸
Method and system for preventing malicious tampering of page request parameters
CN115314513B
( en )
*
2022-06-16
2023-09-19
å京é®çµå¤§å¦
Blockchain-based trust twin method and related equipment
CN115186030B
( en )
*
2022-06-27
2025-10-28
æå·æºªå¡ç§ææéå ¬å¸
A blockchain consensus method and device
US11914560B2
( en )
*
2022-06-30
2024-02-27
Coinbase, Inc.
Systems and methods for creating a reorganization-immune blockchain index using mono-increasing sequence records
CN117408694A
( en )
*
2022-07-07
2024-01-16
è ¾è®¯ç§æï¼æ·±å³ï¼æéå ¬å¸
Data processing methods, devices and equipment, media, products
US20240020703A1
( en )
*
2022-07-18
2024-01-18
Lenovo (Singapore) Pte. Ltd
Avoiding irreversible ledger transactions having an incorrect address
US12500752B2
( en )
*
2022-08-25