Blockchain sharding systems and zero-knowledge proof systems

Abstract

Embodiments are directed toward a blockchain system including a global state and an assemblage of blocks, each block representing a collection of state transformation records, each state transformation record describing a state transformation performed on the global state, where preceding blocks referenced by any given block contain state transformation records describing state transformations performed on the global state prior to the evaluation of the given block, and where at least one state transformation record is a zero-knowledge transformation record encoding a zero-knowledge state transformation description, which zero-knowledge transformation record comprises at least the following elements: paths identifying the locations of the elements of a discrete data subset, a revised data subset, and a transition proof implemented as a non-interactive zero-knowledge proof, which transition proof proves that the transition from the discrete data subset to the revised data subset follows the established rules of the blockchain system.

Description

RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 608,018, filed on December 8, 2023. The entire teachings of this application and appendices filed therewith are incorporated herein by reference. BACKGROUND

[0002] Zero-knowledge proofs (ZKPs) are a cryptographic process that can allow parties to verify a statement's truth without revealing information beyond the statement itself. ZKPs can be used in blockchain technology to validate transactions. In an example, a "prover" creates a proof using their knowledge of a system's inputs, and a "verifier" confirms the proof was calculated correctly. Typically, the verifier cannot see the information, but they can confirm the proof is valid. SUMMARY

[0003] While Zero-Knowledge Proofs (ZKPs)’s can help blockchain systems with privacy compliance, issues remain. For example, ZKPs implemented on blockchain systems come at high computational cost, complexity in implementation, potential scalability issues, lack of user-friendliness, and suffer from interoperability challenges between different blockchains, which can hinder their widespread adoption despite the promise of enhanced privacy.

[0004] Example embodiments disclosed herein can address some of the drawbacks related to conventional ZKPs and blockchain systems. The present disclosure includes exemplary blockchain systems that address issues related to management and mitigation of risks presented by probabilistic blockchain consensus mechanisms, and the optimization of transaction processes, including payment channels. Such systems described herein provide, for example, enhanced security, scalability, and efficiency of blockchain-based systems.

[0005] In some embodiments described herein, a system may be provided that leverages the use of payment channels and payment channel networks to optimize transaction scalability, reduce fees, and enhance privacy. In one or more embodiments, payment channels operate as time-locked escrow contracts, enabling two parties to transact off-chain while potentially utilizing the blockchain only for the opening and closing of the channel.

[0006] An embodiment is directed toward a computer-implemented blockchain system including a global state and an assemblage of blocks, each block representing a collection of state transformation records, each state transformation record describing a state transformation performed on the global state, and each block referencing one or more preceding blocks, where preceding blocks referenced by any given block contain state transformation records describing state transformations performed on the global state prior to the evaluation of the given block, and where at least one state transformation record is a zeroknowledge transformation record encoding a zero-knowledge state transformation description, which zero-knowledge transformation record includes at least the following elements: one or more addresses or paths identifying or referencing the one or more locations of the elements of a discrete data subset within the global state, which discrete data subset includes either a contiguous subset or a non-contiguous subset of the data comprised by the global state; a revised data subset, representing a new revised version of some portion of or subset of said discrete data subset; and a transition proof implemented as a non-interactive zero-knowledge proof, which transition proof proves that the transition from the discrete data subset to the revised data subset follows the established rules of the blockchain system.

[0007] In an embodiment, the zero-knowledge transformation record includes one of: the discrete data subset itself, one or more cryptographic hashes of one or more elements of the discrete data subset, or both the discrete data subset and one or more cryptographic hashes of one or more elements of the discrete data subset.

[0008] In an embodiment, the transition proof corresponds to one of a set of pre-defined transition types for which corresponding non-interactive zero-knowledge proofs may be generated.

[0009] In a further embodiment, each pre-defined transition type corresponds to an encoded state-transition implementation encoded as an algorithmic encoding, which algorithmic encoding may comprise one or more of an algebraic circuit, a virtual algebraic circuit, an algebraic intermediary representation, or other algebraic encoding or algorithmic encoding.

[0010] In a further embodiment, the encoded state-transition implementation receives certain data as input, and generates certain data as output, and where a portion of the input data is private input data, and the remainder of the input data is public input data.

[0011] In a further embodiment, the public input data includes the discrete data subset.

[0012] In a further embodiment, the public input data includes the revised data subset.

[0013] In a further embodiment, the output of the encoded state-transition implementation includes the revised data subset.

[0014] In a further embodiment, the transition proof is generated by a process that includes: a compilation step where the algorithmic encoding is compiled into a set of polynomial equations, an evaluation of the polynomial equasions at one or more random points, producing values that are included in the transition proof.

[0015] In an embodiment, the transition proof is implemented as a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK).

[0016] In an embodiment, the transition proof is implemented as a zero-knowledge succinct transparent argument of knowledge (zk-STARK).

[0017] In an embodiment, an issuer of a currency denominated token is configured to hold a reserve for every corresponding unit of currency denominated tokens issued by the issuer,

[0018] In an embodiment, the reserve may be a collection of assets or a store of value.

[0019] In an embodiment, a token may be issued by a token issuer to a plurality of users, the token issuer configured to: (i) approve use of the token to at least a subset of the plurality of users, and (ii) disapprove use of the token to at least a second subset of the plurality of users.

[0020] In an embodiment, a decision indicator may be configured to mark at least a user of the plurality of users as approved, wherein only approved users may have access to a payment channel on the blockchain.

[0021] In an embodiment, the decision indicator is a user account.

[0022] An embodiment includes the decision indicator being associated with an edge node on the blockchain, the decision indicator further configured to indicate that an account belongs to an edge node or an interconnection node.

[0023] In an embodiment the token is configured with a permissioning constraint configured to permit a first interconnection account to open a payment channel with a second interconnection account, wherein the payment channel is opened by at least the first account and the second account, and wherein at least one permission constraint prohibits the payment channel transactions or records that are signed by the first account but do not reference the second account.

[0024] An embodiment includes using a first cryptographic key for sending payments across a payment channel network, and a second cryptographic key for receiving payments across the payment channel network.

[0025] In an embodiment the first cryptographic key includes a restriction disallowing funds to be removed from a wallet of a user,

[0026] In an embodiment, the first cryptographic key may be used to negotiate the receipt of payment.

[0027] In an embodiment, the first cryptographic key may be used to sign data elements sent during the receipt of payment.

[0028] An embodiment is further configured to generate, by a user, an alternative pair of cryptographic keys, provide the alternative pair of cryptographic keys to a persistent server, associate an account with at least one permissioning constraint configured to restrict the use of the alternative pair of cryptographic keys such that the pair of cryptographic keys may only be used to sign payment channel records or transactions that update payment channels in such a manner that the user’s payment channel balance increases compared to the previous channel state.

[0029] An embodiment further includes one or more permissioning constraints configured to determine whether one or more cryptographic keys are permitted to authorize a payment channel record or transaction.

[0030] In an embodiment any payment negotiated using a cryptographic key is in the direction of the user.

[0031] In an embodiment the blockchain is further configured to open, close, and update payment channels on-chain through zero-knowledge payment channel records or transactions.

[0032] In an embodiment an account on the blockchain is configured with one or more private ledgers represented in a blockchain global state by one or more cryptographic hash digests.

[0033] An embodiment further includes an open payment channel configured on the blockchain with a channel private ledger, wherein the channel private ledger is configured to encode a token balance of at least two participants within the payment channel.

[0034] An embodiment further includes implementing a zero-knowledge algorithmic encoding corresponding to a pre-defined type of global state information.

[0035] An embodiment further includes an expression of a permission constraint encoding corresponding to a zero-knowledge expression encoding, wherein zero-knowledge expression encoding includes a zero-knowledge algorithmic encoding, each zero-knowledge expression encoding configured to perform an operation that is encoded by its corresponding expression.

[0036] An embodiment further includes at least one anchor block configured to limit the reorganization of blocks beyond a threshold block depth.

[0037] In an embodiment, the anchor block further configured to be spaced at regular intervals.

[0038] Another embodiment is directed toward validating and accepting zero-knowledge transformation records. The method includes a validating computer configured to store the blockchain’s global state in a retrievable storage medium, a wallet computer connected to the validating computer via a computer network, the wallet computer generating a new zeroknowledge transformation record. The validating computer receiving the zero-knowledge transformation record from the wallet computer, and subsequently performing validation of the zero-knowledge transformation record. Said validation includes the validating node retrieving a retrieved data subset from the global state, which subset of global state data corresponds to the discrete data subset referenced or included in the zero-knowledge transformation record, the validating node verifying that the discrete data subset included in the zero-knowledge transformation record or referenced by the zero-knowledge transformation record is equivalent to the retrieved data subset, the validating node verifying that the non-interactive zero-knowledge proof is valid when verified combination with the discrete data subset (or retrieved data subset) and revised data subset—and possibly in combination additional Public Input Data included with the zero-knowledge record in certain cases, in the case that the non-interactive zero-knowledge proof is successfully verified and the zero-knowledge transformation record is deemed valid, the validating node replacing some portion of the discrete data subset with elements of the revised data subset, where the portion of the discrete data subset that is replaced by elements of the revised data subset is decided according to which pre-defined transition type the non-interactive zero-knowledge proof corresponds to.

[0039] In embodiments, the discrete data subset includes at least one permission encoding, which permission encoding either is itself interpretable by the encoded statetransition implementation, or transformed into an equivalent format interpretable by the encoded state-transition implementation.

[0040] In embodiments, the permission encoding, or a transformation thereof, is interpreted or evaluated within the encoded state-transition implementation.

[0041] In embodiments, a state transformation corresponding to the encoded statetransition implementation is undertaken only if the permission encoding is interpreted or evaluated with a result indicating that said state transformation is permitted.

[0042] In embodiments, the permission encoding includes a logical function encoded as interpretable or executable computer code.

[0043] In embodiments, the logical function is configured to accept one or more permission inputs and the logical function is configured to output a permission output.

[0044] In embodiments, the permission output corresponds to either a permitted transition status or a not-permitted transition status, given the one or more permission inputs. Whereby the state transformation corresponding to the encoded state-transition implementation is undertaken only in cases where the permission output given the one or more permission inputs corresponds to the permitted transition status, and the state transformation is not undertaken in cases where the permission output given the one or more permission inputs corresponds to the non-permitted transition status.

[0045] In embodiments, the one or more permission inputs comprise a subset of the public input data and private input data received by the encoded state-transition implementation.

[0046] In embodiments, the logical function, or a transformation thereof into an equivalent format interpretable by the algorithmic encoding, is interpreted or executed within the algorithmic encoding.

[0047] In embodiments, the non-interactive zero knowledge proof is deemed valid only in the case where the logical function outputs a value corresponding to the permitted transition status within the algorithmic encoding.

[0048] In embodiments, the permission encoding includes a pattern encoding, where the state transformation corresponding to the encoded state transformation implementation is permitted only in the case that the pattern encoding matches at least a portion of the private input data, or a portion of the public input data, or a combination thereof.

[0049] In embodiments, the pattern encoding, or a transformation thereof into an equivalent format interpretable by the algorithmic encoding, is compared to a portion of the input data received by the algorithmic encoding, within the algorithmic encoding itself, and in which the transition proof is verified successfully only in the case where the pattern encoding matches said input data within the algorithmic encoding.

[0050] In embodiments, the discrete data subset includes one or more account records, each account record including one or more private ledgers, each private ledger including at least one cryptographic hash digest the preimage of which is an unmasked private ledger, which at least one unmasked private ledger contains one or more token balances.

[0051] In embodiments, the at least one unmasked private ledger is implemented as a Hash Tree or Merkle Tree, where the root of the tree corresponds to the private ledger’s cryptographic hash digest.

[0052] In embodiments, the at least one unmasked private ledger is implemented as a Merkle Trie or Merkle Patricia Trie, where the root of the trie corresponds to the private ledger’s cryptographic hash digest.

[0053] In embodiments, the at least one unmasked private ledger is implemented as a Merkle Proof or partial Merkle Tree or partial Merkle Patricia Trie, and where the root of the proof, tree or trie corresponds to the private ledger’s cryptographic hash digest.

[0054] In embodiments, the private input data includes the at least one unmasked private ledger, which at least one unmasked private ledger is excluded from the discrete data subset and from the public input data; and where the private input data also includes information regarding at least one quantity of tokens.

[0055] In embodiments, the encoded state transformation implementation includes a private state transformation. Including the encoded state transformation implementation computing at least one derived hash, which derived hash is the cryptographic hash of the at least one unmasked private ledger, the encoded state transformation implementation determining that such at least one derived hash equals the at least one cryptographic hash digest of the private ledger which corresponds to that at least one unmasked private ledger, the encoded state transformation implementation modifying the unmasked private ledger in a manner consistent with the token quantity information included in the private input data, and the encoded state transformation implementation computing a revised cryptographic hash digest of the modified unmasked private ledger, which revised cryptographic hash digest corresponds to the output of the encoded state transformation implementation.

[0056] In embodiments, the private state transformation also includes a step whereby at least one permission encoding included in the public input data is evaluated in combination with a portion of the input data received by the encoded state transformation implementation, whereby the state transformation corresponding to the encoded state transformation implementation is only undertaken if the permission encoding is interpreted or evaluated in a manner indicating that said state transformation is permitted.

[0057] In embodiments, a zero-knowledge transformation record is accepted and included in the blockchain only in the case where one or more permission encodings included in the record’s discrete data subset are interpreted or evaluated in a manner indicating that the state transformation corresponding to the zero-knowledge transformation record is permitted.

[0058] In embodiments, the validating computer replaces at least one cryptographic hash digest of the one or more account record’s one or more private ledgers in the global state with the revised cryptographic hash digest, in the event that the zero-knowledge transformation record is accepted and included in the blockchain.

[0059] Another embodiment is directed toward a computer implemented method of updating data of a blockchain divided into a plurality of shards, including assigning a mining node to a shard of the blockchain. Further, at the mining node, generating a candidate block representing transactions involving accounts associated with the shard, and transmitting the candidate block to a peer node assigned to the shard. Further, at the peer node, selecting among the candidate block and a plurality of other candidate blocks for inclusion in a respective one of a plurality of block sequences, the selection being based on a fitness value of the candidate block, developing the plurality of block sequences by generating subsequent blocks in each of the plurality of block sequences, selectively discarding a subset of the plurality of block sequences in response to detecting an invalid step within the block sequence, and updating the shard to include at least one of the plurality of block sequences.

[0060] An embodiment further includes, assigning the mining node to at least two shards of the blockchain including the shard, an account associated with the mining node being included in one of the at least two shards.

[0061] In an embodiment, generating the candidate block includes generating a bloom filter indicating all of the accounts with which the mining node has interacted.

[0062] In an embodiment, preventing the mining node from mining transactions involving accounts that are not included in the shards assigned to the mining node.

[0063] In an embodiment, generating the candidate block includes generating a candidate block header that indicates a quantity of fuel tokens.

[0064] In an embodiment, determining whether the candidate block header is valid based on whether the quantity of fuel tokens exceeds a quantity of fuel tokens held by an account associated with the mining node.

[0065] Another embodiment includes, performing a fraud analysis of the plurality of block sequences, wherein detecting the invalid step is based on the fraud analysis.

[0066] An embodiment is directed toward a computer-implemented blockchain sharding system. The system comprising a global state and at least two block-building nodes, wherein the global state includes at least four shards, each shard comprising a mutually exclusive portion of the global state, each block building node configured to store global state data comprising at least two shards, and at least one of the at least two block building nodes configured to store global data excluding at least two shards.

[0067] An embodiment is configured to implement a consensus procedure, the consensus procedure is performed in sequential rounds, each new block built belongs to a single round, and operates on at least two shards of the global state, and each round includes one or more new blocks operating on non-overlapping mutually exclusive shards of the global state.

[0068] In an embodiment, each new block includes a block hash of one or more preceding blocks of the preceding round, the block has configured to reference a preceding block operating on at least one of the same shards as the new block.

[0069] An embodiment is directed toward a computer-implemented blockchain sharding system. The system includes a global state and two or more block building nodes.

[0070] In an embodiment, the global state includes at least three shards. Each shard includes a mutually exclusive portion of the global state, and each block-building node is configured to store global data, excluding at least one shard.

[0071] An embodiment is configured to implement a consensus procedure performed in sequential rounds. Each new block built belongs to a specific round, operating on at least one shard of the global state, each round includes one or more new blocks operating on nonoverlapping mutually exclusive shards of the global state.

[0072] In an embodiment, each new block includes a block hash of one or more preceding blocks of the preceding round, the block hash configured to reference a preceding block operating on at least one of the same shards as the new block.

[0073] An embodiment is directed toward a computer-implemented method for accepting electronic payment. The system includes a point-of-sale computer device, at least one authorization computer devices, and a consumer smartphone with at least one camera, and a processor and memory with computer code instructions stored thereon. The processor and the memory are configured to cause the system to connect the point-of-sale computer device to a packet-switched computer network, connect the at least one authorization computer devices to the packet-switched computer network, connect the consumer smartphone to the packet-switched computer network, configure the point-of-sale computer device with at least one graphical display, configure the point-of-sale computer device to share a session identifier with the at least one of the one or more authorization computer devices, display, on the point-of-sale consumer device graphical display, a graphical encoding of a payment request, wherein the graphical encoding of the payment request includes an encoding of the session identifier, capture, via the at least one camera of the consumer smart phone, an image of the graphical encoding of the payment request, display, on the consumer smart phone, a useracceptance message, wherein the message requests acceptance of the payment request by a user of the consumer smart phone, indicate acceptance of the payment request via an indication of acceptance of the user of the consumer smart phone, construct a data record configured to encode a payment instruction to conform to the payment request, wherein the data record encoding of the payment instruction encodes the session identifier, and transmit the data record to at least one of the one ore more authorization computer devices via the packet-switched computer network. The at least one of the one or more authorization computer devices are configured to perform a verification of the correctness and authenticity of the payment instruction encoded in the data record. The point-of-sale computer device is configured to receive, via the packet-switched computer network, a confirmation that the correctness and authenticity of the payment instruction encoded in the data record has been verified.

[0074] An embodiment further includes a cryptographic signature of the data record attached to the data record prior to transmission to the one or more authorization computer devices. The cryptographic signature is generated using an asymmetric cryptographic signature algorithm. The cryptographic signature is generated using a private key corresponding to a public key stored in a data storage of at least one of the one or more authorization computer devices.

[0075] In an embodiment, the public key corresponds to a money balance stored in at least one of the one or more authorization computer devices; and wherein the verification of the correctness and authenticity of the payment instruction encoded in the data record includes a verification that the cryptographic signature is valid and was generated with a private key corresponding to said public key.

[0076] In an embodiment, at least one of the one or more authorization computer devices is a blockchain validation computer device hosting a blockchain validation software program. The blockchain validation software program is configured to maintain a connection to one or more additional blockchain validator computer devices hosting one or more additional blockchain validation software programs. The blockchain validator computer devices are connected to the packet-switched computer network. The data record is a blockchain data record, the acceptance of which by the blockchain configured to effectuate a change to a global state of the blockchain.

[0077] In an embodiment, the data storage includes an encoding of the blockchain’s global state, and wherein the data record is configured to encode a transformation to the blockchain’s global state.

[0078] In an embodiment, the point-of-sale computer device is configured to open a socket connection to at least one of the one or more authorization computer devices before displaying on the graphical display the graphical encoding of the payment request.

[0079] In an embodiment, the point-of-sale computer device, after displaying the graphical encoding of the payment request on the graphical display, is configured to poll at least one of the one or more authentication computer devices, sending in reference to the session ID.

[0080] In an embodiment, the point-of-sale computer device is configured as part of a cash-register system at a physical retail location.

[0081] In an embodiment, the point-of-sale computer device is a personal computer, the personal computer being configured to execute a web browser software, and wherein the graphical representation of the payment request is displayed in a graphical-user-interface window of the web browser software.

[0082] An embodiment is directed toward a distributed electronic ledger configured in the electronic memory of one or more computers in a blockchain system, the distributed electronic ledger having a plurality of backward-linked interconnected blocks, arranged as one or more instances of linear blockchain data structures, non-linear block arrangements, n-dimensional mesh or lattice 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; configuring 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; configuring the 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 configuring 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.

[0083] An embodiment further includes the blockchain system comprising at least one or more of the following software system components: payment channel liquidity, payment channel permissioning, safe offline payment channel availability, zero-knowledge permissioning, anchor blocks, block-building and protocol validation functions, message signing protocol, consensus protocols, synchronization with traditional database systems, and integration with external off-chain payment systems.

[0084] An embodiment is directed towards a system for securing ownership of tokens, cryptocurrency, or other assets held or tracked on a blockchain by using cryptographic key pairs to sign one or more records, the system comprising at least one blockchain account having one or more cryptographic key pairs, and wherein at least one of the one or more records is configured to encode one or more transformations to a global state maintained by the blockchain.

[0085] An embodiment further includes the system for securing ownership of tokens, cryptocurrency, or other assets held or tracked on a blockchain comprising at least one of the following software system components: payment channel liquidity, payment channel permissioning, safe offline payment channel availability, zero-knowledge permissioning, anchor blocks, block-building and protocol validation functions, message signing protocol, consensus protocols, synchronization with traditional database systems, and integration with external off-chain payment systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] The foregoing will 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.

[0087] FIG. lisa diagram illustrating a comparison of the relative risk of reorganization occurring for an example smaller blockchain network and an example larger blockchain network.

[0088] FIG. 2 is an illustration of certain anchor block concepts, according to an embodiment.

[0089] FIG. 3 is a diagram illustrating how anchor blocks may serve as an additional risk mitigator for payment channel operations, according to an embodiment.

[0090] FIG. 4 is a payment channel network illustrating the progress of a payment in a network, and how a payment is conveyed to a recipient from a sender, according to an embodiment.

[0091] FIG. 5 is a diagram illustrating that the individual payment channels established between nodes are implemented as a payment channel structure which may be established through a sequence of defined steps and states, according to an embodiment.

[0092] FIG. 6 is a diagram illustrating a payment channel lifecycle demonstrating how two channel partners may conduct multiple value transfers while maintaining only two on-chain transactions, according to an embodiment.

[0093] FIGs. 7A - 7E are diagrams illustrating that each iteration or round of a consensus process forms a “block ring” that should include blocks that incorporate transformations of mutually-exclusive shards, according to an embodiment.

[0094] FIG. 8 is a diagram of an example sharding system, according to an embodiment.

[0095] FIGs. 9A and 9B are diagrams illustrating elements of an invalid transaction fraud proof, according to an embodiment.

[0096] FIG. 10A is a diagram illustrating elements of a state-disjunction fraud proof, according to an embodiment.

[0097] FIG. 10B and 10C are diagrams illustrating elements a of state-disjunction fraud proof, according to an embodiment.

[0098] FIG. 10D is a diagram illustrating elements of an invalid-transaction fraud proof, according to an embodiment

[0099] FIGs. 10E and 10F are diagrams illustrating elements of an invalid transaction fraud proof, according to an embodiment.

[00100] FIG. 11 is a diagram of an example sharding system, according to an embodiment.

[00101] FIGs. 12A - 12B is a diagram illustrating elements of a synchronization system, according to an embodiment.

[00102] FIGs.l3A and 13B are diagrams of elements of a synchronization system architecture, according to an embodiment.

[00103] FIGs. 14A - 14E are diagrams of elements of a synchronization system architecture, according to an embodiment.

[00104] FIGs.l5A and 15B are diagrams of elements of a synchronization system architecture, according to an embodiment.

[00105] FIG. 16 is a schematic view of a computer network in which embodiments may be implemented.

[00106] FIG. 17 is a block diagram illustrating an embodiment of a computer node in the computer network of FIG. 16.

[00107] FIG. 18 is a schematic illustration of a mobile device interacting with a quick response code on a computer monitor, according to an embodiment.

[00108] FIG. 19A is a block diagram of an example structure of a blockchain system utilized on a distributed data interchange network according to an example embodiment.

[00109] FIG. 19B is a simplified block diagram showing exemplary blockchain layers according to an embodiment. DETAILED DESCRIPTION

[00110] A description of example embodiments follows.

[00111] The teachings of all patents, published applications and references cited herein are incorporated by reference in their entirety.

[00112] FIG. 19A is a block diagram of an example structure of a blockchain system 2000 utilized on a distributed data interchange network according to an example embodiment. In one example, the blockchain system 2000 may be configured as described in U.S. Patent No. 11,509, 464 issued November 22, 2022, the entire teachings of which are incorporated herein by reference.

[00113] A blockchain system 2000 typically includes a blockchain processing device 2010, a wallet device 2020, a blockchain data browsing device 2030, and a vendor device 2040, all of which may be connected to the internet 2090 (or a distributed network). The blockchain system may include multiple blockchain processing devices 2010, multiple wallet devices 2020, multiple blockchain data browsing devices 2030, and multiple vendor devices 2040, each connected to the internet 2090. In addition to separate blockchain processing devices 2010, separate wallet devices 2020, separate blockchain data browsing devices 2030, and separate vendor devices 2040, a blockchain system may contain combination devices that combine features and functionality of all or some portion of these devices, or that simultaneously may perform the function of all or some portion of these devices, and which are also connected to a distributed network (e.g. internet) 2090.

[00114] The blockchain processing device 2010 may be a computational device, such as a computing device, computer, 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 2012, computer memory 2014 for storing computer instructions, a database 2016 for processing blockchain information (including records and / or transactions), and a communication module 2018 for connecting to the internet 2090 and / or the distributed network. The blockchain processing device may also optionally include a display 2055 (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 2020, the blockchain data browsing device 2030, the vendor device 2040, and the combination device typically have the same or similar components as the blockchain processing device 2010.

[00115] The blockchain processing device 2010 functions as a “block-building node”, which may be referred to as a “miner” in proof-of-work blockchains, and may be referred to as a “miner” in certain embodiments. 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. Blockbuilding nodes are also responsible for propagating blocks and data records within the network. In at least one embodiment, each block-building node may be 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 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.

[00116] In an embodiment, the wallet device 2020 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 can ensure that block building nodes include data records that are appropriately authorized. In addition to storing cryptographic keys and other secure data, wallets may be able to generate and cryptographically sign new data records and transmit them to one or more block-building nodes, typically via the internet 2090 or other network.

[00117] The blockchain data browsing device 2030 functions to provide users with a means to read, view or otherwise access data associated with the blockchain, on a read-only basis.

[00118] The vendor device 2040 may include one or more computers or other computer processing devices that facilitate the activity of blockchain vendors. A blockchain vendor may be an 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.

[00119] A node may be a computational device, such as a computing device, 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.

[00120] A node network may be 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.

[00121] Data records accepted for inclusion in a blockchain may be 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 may be 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.

[00122] Blockchain System and Zero-Knowledge Architetures

[00123] In an embodiment, a computer-implemented blockchain system may be provided. The system may include a global state and an assemblage of blocks, where each block may be configured to represent a collection of records and / or transactions. Each record or transaction may be configured to describe a state transformation performed on the global state, and each block may be configured to reference one or more preceding blocks. Preceding blocks referenced by any given block may contain records and / or transactions which may be configured to describe state transformations performed on the global state.

[00124] In one or more embodiments, the global state is a shared or replicated distributed ledger or other data representation replicated by one or more computer nodes connected to the blockchain system, which represents the current state of data stored on the blockchain.

[00125] The terms “state transformation”, “state transition”, “transformation” and “transition” and “state change” herein refer to the process by which the global state is updated to reflect new information. These terms are used interchangeably herein to describe the same process of state change.

[00126] In certain embodiments, the terms “record” and “transaction”, as used herein, may refer to data, operations, instructions or other encoded elements submitted for inclusion in the blockchain that, when validated and incorporated into one or more new blocks by one or more block-building nodes, effectuate a state transformation. These terms are used without distinction and are intended to encompass a broad range of activities or data types, including but not limited to value transfers, state updates, instructions for smart contract execution, or any other information that may alter the global state of the blockchain. Records and / or transactions may be validated and incorporated into the blockchain in accordance with the blockchain's consensus and protocol rules and logic. In various embodiments, according to such rules and logic, records and / or transactions may be cryptographically signed, which signature, and the public key associated with the signature, is evaluated as part of the process of validating said records and / or transactions. Upon successful incorporation into a new block, a record or transaction updates the blockchain's global state to reflect the change to the global state encoded by said record or transaction according to the rules of the blockchain state transformation protocol implemented and / or enforced by the blockchain node. The terminology used herein is maximally inclusive and does not limit the type, format, or purpose of the data or actions represented by records and transactions, unless otherwise explicitly and unambiguously specified.

[00127] In one or more embodiments, the process of updating the blockchain's global state relies on the successful execution of operations defined and / or encoded by records or transactions, which may include, but are not limited to, transfers of value, modifications to stored data, the creation or execution of smart contracts, creation, configuration, issuance, minting or transfer of tokens, or other computational or state transformation tasks. These updates are effectuated by block-building nodes, which validate, organize, and append records or transactions into a new block. Each new block extends the blockchain, thereby recording the associated state transformations and effectuating that the global state be updated in a manner consistent with the protocol rules implemented and enforced by the one or more block-building nodes.

[00128] In various embodiments, terms such as tokens, balances, funds, units of value, and similar expressions, both singular and plural, are used interchangeably to describe the representation of value within the network. For the purposes of this description, references to one term should be understood to encompass embodiments of the others, as they all reflect the same underlying concept of a quantifiable measure of ownership, entitlement, or utility associated with a blockchain address or account. This interchangeable usage is intentional to streamline the explanation and avoid repetitive distinctions between terms that functionally overlap.

[00129] In certain embodiments, said blockchain system comprises a blockchain network, which may comprise a plurality of nodes, serving distinct roles to support the functionality, security, and accessibility of the system.

[00130] In certain embodiments, a node within said blockchain network is defined as a single computing device equipped with one or more processors (e.g., central processing units (CPUs) and / or graphics processing units (GPUs)), memory (e.g., volatile memory such as RAM), storage (e.g., non-volatile storage such as solid-state drives or hard disk drives), and network connectivity hardware (e.g., Ethernet or wireless communication interfaces). A node may operate by executing software configured to interact with the blockchain network. This software may include, but is not limited to, functionality for transmitting, receiving, validating, and storing blockchain data, as well as performing specific roles such as block building, transaction validation, or cryptographic signing. In various embodiments, nodes may vary in computational capability and configuration, ranging from resource-constrained devices (e.g. smart phones and hardware crypto wallets) to high-performance servers, and may operate independently or in coordination with other nodes. Nodes may also be virtual nodes, whereby one or more of the elements that constitute a physical node are implemented in software, or whereby the physical attributes of a single physical computing device or system are shared by a plurality of virtual nodes compartmentalized by software. The definition of a node is non-limiting and may encompass any computing device or system capable of executing the blockchain software and fulfilling the requirements of the protocol.

[00131] In one or more embodiments, nodes may communicate between and among themselves through one or more computer networks, network protocols and / or communication protocols, including communication protocols such as, for example, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or various packet-switched network protocols. In one or more embodiments, various nodes and servers within a blockchain network may communicate and exchange, broadcast and / or transmit data through a decentralized, peer-to-peer (P2P) architecture, and data may be shared, transmitted, broadcast, received or exchanged through the use of a peer-to-peer communications protocol, which may be a gossip protocol or other protocol. Such network connectivity between and among nodes may allow one or more of messages, records, transactions and / or state updates to be shared, propagated, transmitted, and / or broadcast by, between and / or among the various nodes.

[00132] In one or more embodiments, nodes may include one or more of block-building nodes, validator nodes, wallet nodes, and interface servers. Individual nodes may be specialized in the role they perform, or single physical or virtual nodes may perform multiple roles, such as, for example, acting simultaneously as a block-building node, validator node, wallet node, or interface server, depending on the implementation and configuration of the system.

[00133] One or more embodiments may include Block-building nodes which function to incorporate records and / or transactions into a blockchain by incorporating said records and / or transactions into new blocks, which blocks may in turn be incorporated into said blockchain. They also act to ensure the integrity and consistency of the blockchain’s state by implementing, executing and enforcing the rules of the blockchain protocol. Block-building nodes may exchange critical data such as block headers, block data, record and / or transaction encodings, transaction metadata, cryptographic proofs and other data with other nodes of the network. Block-building nodes may also receive, send, and / or exchange data with other nodes and receive user-submitted records and / or transactions from other nodes and provide information regarding the global state.

[00134] In one or more embodiments, validator nodes may perform most of the tasks and activities of block-building nodes, but excluding some tasks, such as, for example, building new blocks and appending such blocks to the blockchain, depending on the embodiment. Validator nodes, like block-building nodes, replicate, synchronize and / or maintain at least a portion of the global state. In some embodiments, a node may serve both as a block-builder and validator, combining the tasks of producing blocks and verifying the validity of new blocks produced by other nodes in the blockchain network. In some such embodiments where the block-building node and validator node roles may overlap, the terms “validator node” and “block-building node” may be used interchangeably; however, in embodiments where the roles do not overlap, each term retains a distinct meaning.

[00135] In one or more embodiments, wallet nodes may serve as means of access for users to interact with the blockchain, providing a means for said users to access to and / or retrieve blockchain data, and enabling the creation, encoding, cryptographic signing, sharing, and / or transmission of blockchain records and / or transactions.

[00136] In one or more embodiments, wallet nodes securely store private cryptographic keys, which cryptographic keys may be used to sign records and / or transactions and thereby potentially authorize the state transformation encoded on said records and / or transactions. Wallet nodes may send signed records or transactions to block-building nodes or interface servers for processing and validation. They may also retrieve blockchain updates, such as account balances or transaction confirmations, directly from interface nodes, validator nodes, block-building nodes, or other nodes. In various embodiments, wallet nodes may be implemented in various forms, including as software applications, hardware devices, or embedded components within other systems, such as smartphones, desktop applications, or web interfaces.

[00137] In one or more embodiments, nodes referred to herein as interface servers may act as intermediaries, facilitating interactions between a blockchain and a plurality of off-chain devices, systems, services, protocols, applications and / or data (external systems). Interface servers may provide connectivity for applications and third-party systems by exposing APIs, RPC endpoints, or other interfaces that allow, for example, records and / or transactions to be submitted and blockchain data to be queried. Interface servers may handle high-level functionality, such as translating user-friendly inputs into protocol-compliant records and / or transactions, exposing or retrieving blockchain data, or aggregating blockchain data for analysis and reporting. In one or more embodiments, interface servers comprise artificially intelligent components or interface with artificially intelligence systems to perform analysis of system activity, to generate content, media or data that may be written to the blockchain, or to assist in various interactions between an interface server and other nodes within the blockchain system. In some embodiments, an interface server may also function as a wallet node, validator node or other type of node, combining roles to streamline operation.

[00138] According to various embodiments, communication between nodes may follow structured protocols designed for scalability and security. Nodes may exchange data such as transaction details, block updates, and state proofs using predefined messaging formats. For example, wallet nodes may send signed transactions to block-building nodes for validation and inclusion, while interface servers may facilitate high-volume communication by aggregating user interactions and forwarding them to appropriate nodes.

[00139] In various embodiments, the terms account and address may be used to describe elements of the blockchain system. While the terms are largely used interchangeably herein, subtle distinctions may exist depending on the nature of the embodiment. An account generally refers to a logical construct within a blockchain's global state, encompassing both an identifier (such as an address) and persistent on-chain data, such as, for example, balances, user identity data, cryptographic proofs, permissions, permissioning constraints, device identifiers, configurations, statistics, key-value data, smart contract code, cryptographic keys, or other data that may be encoded. An address, in contrast, may refer to a public-facing identifier acting as a reference to on-chain data, including account data, and which may in certain embodiments be derived from cryptographic keys. An address may also be used to designate the originator, target, or receiver of a record or transaction. In one or more embodiments the term address, like the term account, may be used both to refer to the identifier or reference associated with one or more on-chain data elements, or it may be used to refer to the on-chain data elements themselves.

[00140] In certain embodiments, for example, an address may reference an account among a plurality accounts, whereby the blockchain global state comprises persistent (although potentially mutable) state data elements or state data structures each directly associated with an account. In alternate embodiments, an address may reference unspent transaction outputs (UTXOs), which represent discrete units of value created and consumed by transactions. In UTXO-based systems, an address serves to identify the owner or recipient of these outputs, but the state is managed at the level of individual UTXOs rather than aggregated at the account level. Some embodiments may support hybrid models, where addresses may simultaneously represent and / or reference accounts, UTXOs, or other constructs depending on the context.

[00141] For the purposes of this description, where the term account is used, it should be understood that an address may be substituted where appropriate, and vice versa. This flexibility accommodates the wide variety of blockchain designs and implementations that may leverage different mechanisms for tracking and managing state. The use of these terms is non-limiting and intended to cover all configurations where accounts, addresses, UTXOs, or other analogous constructs are employed to achieve the described functionality. For example, in account-based systems, an address may map directly to an account, while in UTXO-based systems, an address may serve as a reference to multiple UTXOs. In either case, the terms account and address should be interpreted in a manner consistent with the blockchain architecture in use.

[00142] The term blockchain as used in this description is non-limiting and is intended to encompass a wide variety of distributed ledger and / or distributed database structures and implementations. The term blockchain is often associated with a sequential chain of blocks linked to each other through backwards references, with each such backwards reference (backreference) being a cryptographic hash digest of the referenced block; however, the term may also refer to other arrangements of block data, including but not limited to directed acyclic graphs (DAGs), parallel blockchains, lattice or mesh data structures, sharded chains, sidechains, or hybrid models. The use of the term blockchain is therefore intended to cover any distributed ledger technology or architecture that achieves similar objectives of decentralized, secure, and immutable recordkeeping.

[00143] In certain embodiments, the terms on-chain and off-chain are used to distinguish between various operations, data, records, transactions, processes, executable code, interactions and other elements of a blockchain system based on their relationship to the blockchain’s global state. On-chain refers to various operations, data, records, transactions, processes, executable code, interactions and / or other elements that are directly incorporated into a blockchain, effectuating updates to a global state and / or becoming part of an immutable ledger. Conversely, off-chain refers to elements of the blockchain system not directly incorporated into the blockchain’s global state, or not occurring as part of the evaluation, execution and application of records and / or transactions in the process of performing transformations of the global state—but which instead may exist or occur in systems or environments external to the blockchain.

[00144] Various implementations of non-interactive zero-knowledge proof systems comprise a mechanism for encoding algorithms or other computational processes, procedures or instructions in a form that may be used to generate a zero-knowledge proof. Such implementations include ZK-SNARK implementations, which may encode algorithms or other computational process, procedures or instructions as algebraic circuits and / or virtual algebraic circuits, and include ZK-STARK implementations which may encode algorithms or other computational process, procedures or instructions as algebraic intermediary representations, among other implementations. Such algebraic circuits, arithmetic circuits, and algebraic intermediary representations and other algorithm and computation encoding are herein referred to as “zero-knowledge algorithmic encodings”, “algorithmic encodings” or “algebraic encodings”. The terms “zero-knowledge algorithmic encodings”, “algorithmic encodings”, “algebraic encodings”, etc, herein include such possible encodings as algebraic circuits used by known ZK-SNARK systems, and “algebraic intermediary representations” used by known ZK-STARK systems, among others

[00145] Any embodiment, system or method herein described which comprises a noninteractive zero-knowledge proof may be optionally implemented using any ZK-SNARK system, ZK-STARK system, or other non-interactive zero-knowledge proof system, interchangeably. Likewise, any embodiment, system or method describe herein which comprises an algorithmic encoding or a zero-knowledge algorithmic encoding may be optionally implemented using any algebraic circuit, algebraic intermediary representation, or other algorithmic encoding suitable for use in the generation of a non-interactive zeroknowledge proof.

[00146] Blockchain Synchronization With Traditional Database Systems

[00147] In accordance with various embodiments of the present invention, a blockchain system may be implemented comprising one or more synchronization systems (See FIG. 12) configured to maintain consistency between a blockchain network and one or more off-chain databases or external data management systems, including such systems as relational databases, relational database management systems (RDBMS), document-oriented databases, graph databases, key-value stores, time-series databases, and other data management systems, which individually and collectively may be referred to herein as “traditional databases” or “traditional database systems”. In certain embodiments, said one or more synchronization systems may comprise one or more interface nodes and / or said traditional database systems may operate separate and apart from the block-building and protocol validation functions of the block-building and validator nodes of the blockchain system’s blockchain network.

[00148] In one or more embodiments, said one or more synchronization systems may be configured to handle various operational scenarios, including, but not limited to, one or more of the following: handling of synchronous off-chain payment authorization requests; blockchain reorganization events which occurs prior blockchain finalization; reorganization events occurring after transaction finality has been reached; situations where transferred value may be unavailable due to reorganization after an external transfer has been authorized or finalized; expiration of pending transactions that have not yet been incorporated into any block; conflicts between endogenous transactions (originating from within the system) and exogenous transactions (originating from outside the system); and / or cases where messages may be lost or delayed between the blockchain network and the one or more traditional databases.

[00149] In accordance with various embodiments of the present invention, synchronization systems are configured to read data from blockchain networks and make updates to database entries in one or more traditional database systems—where these database entries are broadly defined as individual units of data stored within any type of database system, including but not limited to records or rows in relational databases, documents in document-oriented databases, key-value pairs in key-value stores, nodes and edges in graph databases, and other data structures used to represent and store information.

[00150] In at least one embodiment, the one or more synchronization systems may optionally maintain separate data structures for tracking pending transactions, finalized transactions, and / or transactions that may require reconciliation due to reorganization events. In some embodiments, the synchronization system may comprise, incorporate, interact with, connect to, and / or use one or more event streaming platforms or publish-subscribe messaging systems, which individually and collectively may be referred to herein as “event messaging systems”, and which systems may include without limitation message brokers, event logs, message buses, and other messaging infrastructures, examples of which may include, but are not limited to, Apache Kafka, RabbitMQ, Apache Pulsar, Amazon Kinesis, Google Cloud Pub / Sub, or similar capabilities implemented in a more generalized database such as an RDBMS, object oriented database, etc. In one or more embodiments, such one or more event messaging systems may provide guaranteed message delivery and order preservation, and / or may be capable of retaining messages for configurable periods of time, and / or may be designed to handle real-time data flows.

[00151] In accordance with one or more embodiments of the present invention, one or more synchronization systems may be implemented that processes both external blockchain records and / or transactions and internally-generated blockchain records and / or transactions. The synchronization system may include one or more nodes configured to detect and process blockchain records and / or transactions that are directed to one or more accounts or addresses recorded by the synchronization system, which records and / or transactions may be referred to as "exogenous" transactions in that they originate from outside of the synchronization system and its connected wallet nodes. Additionally, the synchronization system may be configured to generate and transmit to the blockchain network one or more transactions of its own, which transactions may be referred to as "endogenous" transactions in that they originate from within a synchronization system itself, or in one or more implementations from wallet nodes connected to or integrated with the synchronization system. In various embodiments, the synchronization system may include one or more interfaces through which external processes may communicate with the synchronization system, and through which requests may be received that cause the synchronization system to generate and / or transmit to the blockchain network endogenous blockchain records and / or transactions. Said synchronization systems may be configured to track the state of both exogenous and endogenous transactions as they progress through various stages of blockchain inclusion and finalization, and may maintain in one or more traditional databases entries reflecting the state of such transactions. In at least one embodiment, the synchronization system may include one or more processes for detecting and handling blockchain reorganization events that may affect either exogenous or endogenous transactions that have been previously added to the blockchain.

[00152] As a general matter, and as pertain to one or more embodiments of the present invention, certain technical challenges may arise from fundamental architectural differences between blockchain networks and traditional databases. In many implementations, a blockchain network may process all transactions asynchronously, with transactions remaining in a pending status for an indefinite period before being added to a block, and with the possibility that transactions may be reorganized or reversed even after being added to a block or otherwise incorporated into the blockchain. A blockchain network may implement logical constraints and validation rules and / or protocol rules that are enforced internally within the block-building nodes and validator nodes, potentially resulting in transactions being rejected, modified, or reordered after submission. In contrast, a traditional database system may be configured to process transactions synchronously and atomically, with immediate success / failure status, and may, in various implementations, be tightly integrated with realtime financial and business systems that require instantaneous confirmation of transaction status. Furthermore, many traditional database implementations may maintain referential integrity and transaction isolation through database-level locking mechanisms that presume reliable transaction ordering and finality. An architectural mismatch between the asynchronous, eventually-consistent nature of blockchain networks and the synchronous, immediately-consistent nature of many traditional database systems may present significant technical challenges when attempting to bridge these two paradigms, particularly in financial applications where transaction ordering, finality, and consistency are critical requirements.

[00153] Generally, and as pertain to various embodiments, technical challenges described above may be further complicated in implementations where financial institutions or payment networks may require real-time transaction confirmation and settlement, while nonetheless integrating blockchain systems for various purposes, including to leverage the benefits of blockchain networks for certain aspects of transaction processing, record keeping, or inter-institutional settlement. In at least one embodiment, special consideration may need to be given to scenarios where reorganization or reversal of blockchain transactions could impact real-world financial settlements that have already been processed through traditional banking systems. Additional, in various implementations, complexity may arise from differences in how such systems handle transaction atomicity—while a traditional database may provide some or all ACID (Atomicity, Consistency, Isolation, Durability) guarantees within a single database instance, a blockchain network may need to achieve consensus across multiple distributed nodes before transaction finality can be assured, potentially leading to temporary inconsistencies between the blockchain state and corresponding records in a traditional database.

[00154] Accordingly, various embodiments of the present invention address and resolve these issues by providing synchronization systems that manage and maintain consistency between the blockchain network and traditional database systems.

[00155] At least one embodiment of the present invention comprises a system and / or method to maintain authoritative balance tracking within a blockchain-based system while also supporting real-time payment systems. Such real-time payment systems, which may include without limitation payment card networks, point-of-sale networks, automated teller machine networks, and other transaction processing networks, typically require synchronous authorization to be obtained from an authoritative system before a transaction may be completed. However, blockchain system implementations may operate in a fundamentally asynchronous manner, whereby transactions submitted to the blockchain network may not reach finality until some number of blocks have been added to the blockchain after the block containing the transaction. This asynchronous operation may create difficulties in some implementations when attempting to use blockchain account balances as an authoritative source for real-time transaction authorization, as the state of account balances within a blockchain may be subject to reorganization or reversion for some time after a record or transaction is broadcast, shared or posted to the blockchain network. For instance, and without limitation, a first transaction appearing to authorize a payment card transaction may be superseded by a second transaction that depletes the account balance before the first transaction reaches finality, potentially creating a situation where an already-authorized payment cannot be settled.

[00156] Various embodiments of the present invention address these technical challenges through at least two distinct approaches. In a first approach, embodiments of said synchronization system may provide an interface or connection between such real-time payment systems and one or more payment channels that are constructed on top of the blockchain system. Such payment channels may, in at least one embodiment, provide synchronous transaction capability by relying on the finality characteristics of payment channel networks, which in various embodiments are able to offer instantaneous finality by relying on escrow balances that have already reached finality within escrow accounts on the blockchain. Various embodiments of the present invention comprise a connection between one or more such real-time payment systems and one or more payment channels or payment channel networks implemented as described variously elsewhere herein.

[00157] One or more embodiments may consist of a real-time payment authorization request of a real-time payment network causing a synchronization service to use a cryptographic key of an account or address to authorize a payment channel payment (wherein such payment channel payment is implemented as described variously elsewhere herein) from such account or address to an account or address which is a treasury account which holds balances which include value owed to the real-time payment network. In various embodiments, said payment may be effectuated within a single payment channel or it may be effectuated through a multi-step or multi-hop payment in a payment channel network.

[00158] One or more embodiments may consist of a computer device or mobile device which may authorize payments issued from a source account (which may be a bank, savings and loan, brokerage, pre-paid, stored-value, or other money account held in a traditional database system) issuing an instruction to a forwarding service (which may implement, incorporate or comprise one or more of a synchronization service, an interface node, or a payment channel node) with instructions to make a payment to an account or address of a payment channel network (destination account), where said forwarding service may reduce the balance of the source account, and issue a payment channel payment to the destination account, from an account or address controlled, owned or managed by said server computer device. Said account or address in various embodiments may comprise a treasury account aggregating value owned, used or controlled by the forwarding service, or said account or address may comprise a synchronized and replicated account corresponding to the source account.

[00159] In a second approach, which in one or more embodiments may be implemented either separately from or in combination with the first approach, a synchronization system may be implemented that includes one or more interface nodes. Such interface nodes may comprise or interact with traditional database systems, which traditional database systems maintain synchronized database entries that correspond to both pending and finalized blockchain transactions, in one or more embodiments enabling the interface nodes to provide synchronous responses to real-time payment systems while managing the risk that blockchain reorganizations or other blockchain events may affect the finality of transactions. The interface nodes may, in various embodiments, implement one or more strategies to ensure that real-time payment authorizations do not create undue risk of payment default, reversal or conflict when synchronized with a blockchain system, including without limitation maintaining designated treasury accounts, implementing exposure limits, and coordinating failover procedures in the event that blockchain reorganizations affect transaction finality.

[00160] In accordance with various aspects of the present invention, additional technical challenges may arise when attempting to synchronize data between a blockchain network and a traditional database system. In one or more embodiments, a blockchain reorganization event may occur when one or more blocks previously added to a blockchain are removed and replaced by one or more different blocks, which blocks may contain different sets of transactions and may reflect different transformations of the global state. Reorganization events may, in certain embodiments, create a technological challenge in maintaining synchronization between blockchain state and traditional database system state, particularly in cases where a traditional database already stores data from transactions that may have been previously incorporated into blocks that may be eliminated by the reorganization. The difficulty may be further complicated in implementations where the traditional database is being used to provide synchronous responses to user requests, such that the traditional database may need to maintain an accurate representation of account balances and transaction status even while reorganization events may occur, may have occurred, or may be in the process of occurring. This synchronization challenge may be particularly acute in cases where the reorganization affects blocks that had previously been considered "final". In some embodiments, one or more solutions to this technical challenge may be required to ensure reliable operation of any system that connects, synchronizes or bridges blockchain networks and traditional database implementations.

[00161] Certain embodiments of the present invention may address these technical challenges by implementing one or more synchronization systems comprising one or more interface nodes configured to manage synchronization between blockchain and traditional database implementations, which interface nodes may continue to manage or maintain this synchronization even in the event of blockchain reorganization. In various embodiments, such interface nodes may comprise, incorporate, interact with, connect to, and / or use one or more traditional database systems and / or event messaging systems, and may implement a system and / or method to track both blockchain state and traditional database system state in a manner that permits recovery from reorganization events.

[00162] One or more embodiments may comprise one or more synchronization systems that implement a two-phase update process, whereby available balances may be adjusted immediately upon transaction initiation, while current (or final) balances may only be modified after transaction finality has been confirmed. In one or more embodiments, synchronization systems may maintain a principle of updating traditional database system state quickly when an update, operation or event may be protective of or may reduce financial or operational risk, may increase liability or loss, or is otherwise undesirable to the operators of said system; and updating traditional system state slowly when an operation or event may increase financial or operational risk, may decrease liability or loss, or is otherwise beneficial to the operators of said system.

[00163] The synchronization systems may, in various embodiments, maintain two distinct balance values for accounts that it manages: an "available balance" and a "current balance." The available balance may be reduced as soon as a record or transaction that spends or otherwise decreases an account’s balance is initiated, even before that transfer has been added to any block. Conversely, the available balance may be increased only when an inbound transfer or other record or transaction increasing the balance has reached finality, and the current balance may also only be modified when transactions reach finality. In various embodiments, “double spending” is prevented because various operations are blocked from occurring if they result in a negative available balance, including, for instance, providing authorization for real-time non-blockchain payments.

[00164] Nevertheless, in at least one embodiment, the available balance may potentially be less than zero in certain circumstances, for example in the case where a reorganization results in an exogenous record or transaction being added to the blockchain before an endogenous transaction that is generated to fund an already-approved external real-time payment. In various such cases, a previously-unknown exogenous record or transactions reduces account balances to less than the amount of an already-approved endogenous transaction, resulting in the settlement obligation crated by authorizing the external real-time transaction being unfunded. In certain embodiments, the on-chain balance for an account cannot be less than zero; in other embodiments, the on-chain balance can reflect a negative. One or more processes within the synchronization system may monitor accounts having negative balances (either within the traditional database, or within the blockchain, or both) and may automatically generate new blockchain transactions to reclaim value transferred to such accounts, potentially implementing one or more strategies to maximize the probability that such reclamation transactions will be successful.

[00165] Synchronization System Components And Interactions

[00166] According to various embodiments of the present invention, one or more synchronization systems may comprise one or more of (a) a transaction processing component that receives transaction requests from wallet nodes and / or external systems and initiates various system operations; (b) a transaction writer component that submits cryptographically signed records and / or transactions to the blockchain network for inclusion in blocks, including records and / or transactions it may sign using secured private keys; (c) a transaction reader component that monitors the blockchain for new blocks and for reorganization events; (d) a message handler that processes blockchain transactions and updates traditional database system state; and / or (e) a transaction tracker component that maintains synchronization between blockchain and traditional database systems even while reorganization is occurring. Each aforementioned component, according to example embodiments, may be implemented in software running on one or more interface nodes or other computing devices, and may be run as two or more separate runtimes, or may be combined together into a single executable software.

[00167] These one or more synchronization systems may, in certain embodiments, maintain pending database entries in the one or more traditional database systems that reflect blockchain records and / or transactions that have not yet reached finality, and may update those pending database entries if a reorganization eliminates or modifies any such non-final transactions. One or more such synchronization systems may also maintain reversal database entries in certain implementations, which reversal database entries may be used to compensate for reorganizations that affect transactions previously considered final.

[00168] Transaction Origination and Writing To The Blockchain

[00169] In accordance with various embodiments, one or more transaction processing components may comprise one or more interface nodes and / or other computer devices configured to process records and / or transactions received from one or more external systems and / or wallet nodes. Said external systems and / or wallet nodes may include, without limitation, mobile devices, desktop computers, servers, or other computing devices running software capable of connecting to and / or communicating with said transaction processing components via a computer network. In certain embodiments, said transaction processing components may write or transmit these received records and / or transactions to the blockchain network, and may also generate and write or transmit additional blockchain records and / or transactions in response to one or more events or requests. These events and requests may include, but are not limited to, payment channel open, close and update events, payment authorization requests from point-of-sale systems, account recovery requests from wallet nodes, card activation requests, transfer requests from external payment networks, withdrawal requests, identity verification events, multi-device registration events, and account configuration updates.

[00170] In certain embodiments, if said events and / or requests do not themselves comprise valid and complete cryptographically-signed blockchain requests and / or transactions, or if additional requests and / or transactions are required according to the nature of the event or request, a synchronization system may process such events and requests by generating one or more corresponding records and / or transactions, which may include without limitation payment channel records, transfer records, configuration records, account update records, or other types of blockchain records or transactions. A synchronization system may sign these generated records and / or transactions using one or more cryptographic keys associated with treasury accounts, user accounts, or other system accounts or addresses, and may submit these signed records and / or transactions to the blockchain network for inclusion in one or more blocks.

[00171] A transaction processing component may comprise one or more web servers, application servers, database servers, and associated software components that collectively provide transaction processing services, including but not limited to validating incoming transactions, maintaining account state and balances, tracking transaction status, managing user profiles and credentials, processing authorization requests, handling multi-device registration, coordinating with external payment networks, implementing identity verification workflows, and / or synchronizing state between the blockchain network and local databases. A transaction processing component may implement various means for users and external services and applications to access and interact with the synchronization system specifically and the blockchain network generally, which means of access and interaction include but are not limited to JSON-RPC APIs, REST APIs, WebSocket connections, OAuth2 authentication flows, webhook integrations, mobile application SDKs, browser-based interfaces, commandline interfaces, and programmatic library interfaces. These interfaces may enable functions including account management, transaction submission, balance queries, transaction history retrieval, blockchain status monitoring, smart contract interaction, and system configuration.

[00172] In at least one embodiment, a transaction processing component may interface with wallet nodes and / or external systems via one or more network interfaces, and a transaction writer component may manage cryptographic keys and sign blockchain transactions, which components may exchange messages or otherwise communicate with each other via one or more event messaging systems. In one or more embodiments, said transaction processing component may receive and process requests via one or more network interfaces, may maintain account state in one or more databases, and / or may generate events or messages to be processed by the transaction writer component. In various embodiments, the transaction writer component may store and manage cryptographic keys, may sign blockchain transactions, and / or may update the transaction processing component via events or messages with regards to blockchain interactions. In several embodiments, the separation of these components may enhance security by isolating cryptographic operations and key storage from public network interfaces. The event messaging system may provide reliable communication between these subsystems while maintaining their isolation, and may enable asynchronous processing of blockchain operations in a manner that is independent from request processing operations.

[00173] In various embodiments, a transaction processing component may implement one or more public API endpoints that receive and process various requests, including without limitation money transfer requests, account management requests, requests to write or transmit records and / or transactions to a blockchain network, and other operational requests from wallet nodes and / or external systems. The component may process these requests by performing one or more traditional database operations—including operations to record transaction details, perform account updates, or make configuration changes—and may generate one or more entries written to an event messaging system directing the transaction writer component to write or transmit corresponding blockchain transactions to a blockchain network. For payment-related requests, in at least one embodiment, the transaction processing component may interact with one or more payment card networks to authorize charges, process refunds, or handle other card-related operations. In certain embodiments, the component may comprise a network connection to, or a means of exchanging messages with, various types of payment networks, including, without limitation, credit card networks, debit card networks, electronic funds transfer systems, automated clearing house (ACH) networks, wire transfer systems, online payment gateways, mobile payment platforms, digital wallet services, peer-to-peer payment systems, and other financial transaction processing networks.

[00174] According to various embodiments, the transaction processing component may maintain transaction, event and account state information in one or more traditional databases, with database entries potentially having multiple possible statuses including, but not limited to, pending and final status. A pending status may indicate that a blockchain operation is still in process, with an associated record or transaction not yet added to a block, or a block not yet final, while a final or confirmed status may indicate that the corresponding blockchain operation has been completed and confirmed final. According to an embodiment, a transaction processing component specifically, and a synchronization system generally, may track multiple balance values for accounts and / or addresses, including an available balance that reflects pending operations, records and / or transactions, and a current balance that reflects only finalized operations, records and / or transactions. In certain embodiments, various account operations and record / transaction processing decisions may depend on the state of relevant database records—for example, new records and / or transactions may be rejected if an account's available balance would become negative, even if pending transactions have not yet been finalized.

[00175] In various embodiments, for payment card and other real-time payment operations, the transaction processing component may implement interfaces to one or more payment networks to enable real-time payment authorization and settlement. According to one or more embodiments, synchronization systems may process real-time payment authorizations by one or more of the following: a transaction processing component writing traditional database entries in a pending status; a transaction writer component generating appropriate blockchain records and / or transactions; the transaction processing component updating traditional database entries based on settlement messages received from payment networks; and a transaction reader component writing updates based on on-chain blockchain activity. In one or more embodiments, the transaction processing component may support multiple types of payment operations including, but not limited to, purchases, refunds, chargebacks, and card activation requests. Each such operation may involve multiple blockchain state transformations and traditional database updates as the operation progresses through various stages of completion.

[00176] In accordance with various embodiments, a transaction writer component may perform various functions, including, but not limited to, one or more of the following: (a) it may receive fully-formed blockchain records and / or transactions via an event messaging system, and may add these to a blockchain network transaction pool for eventual inclusion in new blocks; (b) it may monitor one or more event message queues for transaction creation requests from the transaction processing subsystem, and in response to such requests, may create and cryptographically sign one or more blockchain transactions and add these to a blockchain network transaction pool; (c) it may monitor the expiration of transactions that have not yet been incorporated into any block, and may generate replacement transactions in certain circumstances; (d) it may handle blockchain reorganizations by processing transaction reversals and re-submissions.

[00177] In one or more embodiments, one or more components of synchronization systems—including but not limited to the transaction writer component, the transaction reader component, or the message handler—may transmit status updates regarding expired and replacement transactions to various other subsystems via, for example, but not limited to, event messaging systems, web service notifications, or publish-and-subscribe mechanisms. Depending on the embodiment, they may implement timeout and retry mechanisms for operations that depend on external systems or blockchain confirmation, allowing operations to be cancelled or retried if they do not complete within expected timeframes.

[00178] According to one or more embodiments, in the event of a blockchain reorganization, where previously processed blocks are replaced by a different chain of blocks, the transaction writer component may identify affected transactions and initiate appropriate remedial actions. The component may evaluate whether re-submitted transactions require modified parameters, such as updated nonces or gas prices.

[00179] In one or more embodiments, a transaction writer component may maintain transaction queues to manage the ordering and timing of transaction submissions to the blockchain network. In several embodiments, these queues may ensure proper nonce ordering for transactions from the same account and may implement rate limiting or batching of transaction submissions.

[00180] Block And Transaction Reading

[00181] In accordance with at least one embodiment of the present invention, a synchronization system may be implemented that includes one or more transaction reader components operating on one or more interface nodes. Such transaction reader components may monitor the blockchain network for new blocks and may process the records and / or transactions contained within such blocks as the blocks are added to the blockchain.

[00182] In one or more embodiments, said transaction reader component processing said records and / or transactions comprises the transaction reader component writing entries corresponding to records and / or transactions and / or other blockchain events to an event messaging system. As said entries are written to said event messaging system, a message handler (running concurrently, in parallel, or sequentially with the transaction reader) reads each transaction in turn. As the message handler reads each record or transaction, it may update one or more database entries in the traditional database system, including without limitation updating account balances, transaction status indicators, transaction histories, account and / or address configurations, user data associated with accounts and / or addresses, order books, sale and purchase orders, new token creation events, and token configurations.

[00183] In at least one embodiment, the message handler may identify whether processed transactions originated from interface nodes within the synchronization system ("endogenous" transactions) or from external sources ("exogenous" transactions), and may update the traditional database system differently depending on the origin of such transactions. Furthermore, in various embodiments, the message handler may, upon reading an entry from the event messaging system, communicate with other systems over a network—for instance, by calling APIs, invoking webhooks, or utilizing other communication protocols—to exchange data, execute algorithms, trigger events, or coordinate operations, possibly enhancing interoperability and integration with third-party services or applications.

[00184] In various embodiments, the one or more synchronization systems may implement one or more strategies to handle blockchain reorganizations, including without limitation rewinding database updates that were performed in response to transactions that are eliminated due to blockchain reorganization. Such rewinding processes may, in at least one embodiment, distinguish between transactions that have not yet reached finality and transactions that have reached finality, implementing different reversal strategies in each case. For transactions that have not yet reached finality, the rewinding process may return database entries to their previous state and may re-queue transactions (for example, endogenous transactions) for re-submission to the blockchain. For transactions that have reached finality, the rewinding process may generate compensating database entries to reverse the effects of eliminated transactions while maintaining a record of such transactions and their reversals.

[00185] The interface nodes implementing the synchronization system may, in various embodiments, communicate with each other and with the blockchain network using one or more event messaging systems. Such event messaging systems may enable the interface nodes to coordinate their activities and to ensure that database entries remain synchronized across various synchronization systems. In at least one embodiment, an event messaging system may be used to transmit information about pending transactions, finalized transactions, and blockchain reorganizations between interface nodes. The event messaging systems may also be used to coordinate the re-submission of transactions that are eliminated due to blockchain reorganization.

[00186] In accordance with at least one embodiment of the present invention, the synchronization process may proceed in a series of one or more distinct steps. A transaction reader component operating on one or more interface nodes may first detect that a new block has been added to the blockchain. The transaction reader component may examine each record and / or transaction contained within the new block; for each record and / or transaction, the transaction reader component may generate one or more entries in an event messaging system reflecting a pending status for that blockchain record or transaction. These database entries may include one or more of the following elements, without limitation: the block number of the block containing the transaction, a transaction identifier, source and destination account information, token type and quantity information, and current status information.

[00187] In one or more embodiments, an additional type of transaction reader component may be implemented which read records and / or transactions from the pending transaction pool (mempool) of a blockchain network, before they have been included in any block. In certain embodiments, records and / or transactions read from the mempool may be added to a traditional database in a “pending but not yet accepted” status, in a similar manner as new endogenous records and transactions. By incorporating these pending transactions into the traditional database sooner, a synchronization system can prevent conflicts making provisional updates—such as updates to an account or address’ available balance—before the transactions are confirmed on the blockchain. This approach allows for earlier detection of potential conflicts (such as double-spending) and enhances the consistency between the blockchain network and off-chain database systems. Conversely, exogenous transactions in certain alternate embodiments may only be known to the synchronization system when the transaction is detected within a block.

[00188] In accordance with at least one embodiment, as said records and / or transactions are written to one or more event messaging systems by one or more transaction reader components, said records and / or transactions may be read by one or more message handlers. Upon detecting a blockchain record or transaction that comprises a transfer of value between one or more accounts managed by synchronization systems, said one or more message handlers may update the traditional database, recording that transfer as a database object in a pending status. The transfer may persist in a pending status until the record or transaction reaches finality, which may occur after a configurable number of blocks have been added to the blockchain following the block containing the record or transaction, determined according to various heuristics or algorithms, depending on the embodiment. While the transfer remains in pending status, the available balance of the source / sending account may be decreased to reflect the pending outflow, but the current balance may remain unchanged until finality is deemed to be reached. After finality is deemed to be reached, according to the embodiment, the one or more synchronization systems may update the database entries to reflect that the transfer has been finalized, potentially updating both available and current balances.

[00189] Records and / or transactions that perform transformations of global blockchain state other than transfers of value may also effectuate provisional updates and insertions within the traditional database system when first read by a message handler; the traditional database entries corresponding to such records and / or transaction would only be updated to reflect a final status when such records and / or transactions are deemed final.

[00190] In certain embodiments, two message handlers may read from the same event messaging system, one at an offset from the other. The first message handler may treat each record or transaction as pending, and would make appropriate updates and insertions in the traditional database system to reflect a provisional status. The second message handler may read each transaction at an offset equal to a finalization block depth or finalization time duration, such that each transaction would be finalized when read. The second message handler would perform a finalization update for every traditional database entry corresponding to a record or transaction that had been read, so as to reflect a non-provisional or final status (for instance, by causing a balance change made to available balance to also be reflected in current balance).

[00191] In one or more embodiments, the synchronization process may vary depending on whether the record or transaction originated from within the synchronization system ("endogenous") or from an external source ("exogenous"). For endogenous records or transactions transferring or otherwise using funds out of an account or address, an available balance may be reduced—or the traditional database state may be otherwise provisionally updated—before the transaction is submitted to the blockchain network, and a database entry tracking said endogenous records or transactions may be placed into a pending status within the database. In several embodiments, the synchronization system may update the database entries pertaining to exogenous records and / or transactions upon detection within a new block, potentially recording the block number and updating status information, but maintaining the pending status until finality is reached. In one or more embodiments, endogenous records and / or transactions may be received and / or generated by a transaction processing component or a transaction writer component, while exogenous records and / or transactions may be first detected and / or processed by a transaction reader component or a message handler.

[00192] Reorganization Handling

[00193] In accordance with various embodiments of the present invention, one or more interface nodes of the one or more synchronization systems may implement a multi-step procedure to maintain synchronization between blockchain and traditional database systems in the event of a reorganization.

[00194] Various embodiments of the present invention may utilize an event messaging system that maintains an ordered sequence of blockchain events, including blocks, records and / or transactions, even after they have been synchronized with a traditional database system, thereby preserving the original processing order within the event messaging system itself. When interface nodes detect a blockchain reorganization event, by, for example observing that a newly-received block references a different previous block hash than the last block processed, they may append a "reorganization marker" to this ordered sequence to indicate the position of the last common block shared between the old and new blockchain forks, and then begin appending new blocks from the reorganized chain. Message handlers monitoring the data structure, upon encountering the reorganization marker, initiate a "rewind" process by iterating backwards through the preserved event sequence to the last common block, enabling precise reversal of state transitions affected by the reorganization. After completing the rewind, message handlers process the newly appended blocks, records and / or transactions following the reorganization marker, potentially comparing them against a transaction tracker component to identify transactions that may need to be regenerated or resubmitted, thus facilitating accurate reconstruction of the database state.

[00195] In some embodiments, a transaction reader component of an interface node may first detect a reorganization event by observing that a newly-received block references a different previous block hash than the last block processed. The transaction reader may then iterate backwards through previously-processed entries corresponding to records, transactions, blocks and / or other blockchain events stored by an event messaging system until discovering a "last common block" that exists in both the old and new blockchain forks. The transaction reader may also, during the same iteration, or in a separate iteration over the same data, construct a list of entries potentially subject to reversal and re-submission or reprocessing (the reversal entries).

[00196] In an alternate embodiment, the transaction reader my discover the last common block and construct the list of reversal entries though a direct interaction with one or more block-building nodes; in yet another version, a message handler may undertake either approach.

[00197] Upon identifying this last common block, the transaction reader may, in some implementations, add a reorganization marker to the event messaging system with information regarding the reorganization. In one or more embodiments, the transaction reader component may append to the event messaging system each of the reversal entries, in reverse order, such that by progressing forward through the entries a consumer would move backwards through the history of the blockchain’s execution. Upon adding a reorganization marker to the event messaging system and / or appending the reversal entries to the event messaging system, the transaction reader may, in one or more embodiments, re-initiate its previous block-reading activities, and process the blocks of the previously-unknown fork starting from the block following the “last common block”. In one or more embodiments, concurrent with, parallel with or subsequent to this reorganization processing by the transaction reader component, the one or more message handlers may then process the reorganization by iterating forward through the reversal entries, initiating a reversal operation of each reversal entry against corresponding data in the traditional database system.

[00198] In various embodiments, the specific nature of each reversal operation performed by the message handler may depend on whether corresponding records and / or transactions have achieved finality. For non-final records and / or transactions, the message handler may in some embodiments revert pending status of a database entry and place affected records, transactions or other blockchain events back into a "pending but not yet accepted" status, which may be indicative of records, transactions and / or other blockchain events that have been proposed but have not yet been including in any block. For final records and / or transactions, one or more message handlers may instead generate reversal records in the traditional database system while leaving the original database entries in place, potentially also applying certain modifications, but without reversing the entry entirely. In certain embodiments, account balances in may potentially be allowed to become negative, either only in the traditional database system, or in both the traditional database system and the blockchain global state. After processing the reversal entries, one or more message handlers may proceed to process entries corresponding to new blocks from the reorganized chain, potentially comparing newly-processed transactions against the records, transactions and / or blockchain events added to a transaction tracker component, so as to identify records, transactions and / or blockchain events that may potentially need to be re-applied to the traditional database state, and / or may potentially need to be re-submitted to the blockchain network.

[00199] In one or more embodiments, either the transaction reader or the message handler may potentially add individual reversed records and / or transactions to said transaction tracker component, while either process iterates through the reversal entries as per its respective process. Following a reorganization, after the message handler has processed all reversal entries and then all entries corresponding to records and / or transactions of new blocks introduced by the reorganization, the synchronization systems may initiate a process to once again add to the blockchain one or more records and / or transactions still remaining with the transaction tracker component, which process may also involve a transaction writer component or other component, depending on the embodiment.

[00200] In various embodiments of the present invention, the synchronization system may also implement special handling for endogenous transactions during reorganization processing. In certain embodiments only endogenous transactions that may be added to the transaction tracker component, particularly in embodiments where such transactions may need to be re-submitted to the blockchain. In an alternate embodiment, both endogenous and exogenous records and transactions may be added to the transaction tracker component, but endogenous transactions are handled in a different manner.

[00201] After a synchronization system attempts to submit remaining records and / or transactions of the transaction tracker component to the blockchain, the synchronization system may, in some embodiments, attempt to regenerate one or more of any remaining endogenous records and / or transactions, potentially with updated nonce values and expiration dates. This may occur in an embodiment if the original records and / or transactions have expired or have become invalid without first being successfully incorporated into a block. In certain implementations, interface nodes may also split larger transactions into one or more smaller transactions during regeneration, or may otherwise make other modifications to these replacement records and / or transactions, particularly in cases where reduced account balances or other features of said records and / or transactions may have prevented the originals from being processed. Through this coordinated processing of reorganization events, one or more embodiments of the present invention may maintain consistency between blockchain and traditional database system state while preserving the intent of endogenous transactions wherever possible.

[00202] In some embodiments of the present invention, said one or more synchronization systems may implement additional compensating actions related to reorganization processing. In certain implementations, account operations may be frozen or restricted when reorganization causes account balances to become negative. Interface nodes may also, in some embodiments, implement an "exposure limit" mechanism that caps the total value of non-final transactions that may be processed for a given account, thereby limiting potential losses from reorganization events. Various implementations may also include notification mechanisms to alert system operators and / or end users when reorganization events occur, particularly in cases where such events affect transactions previously considered final. Through these various mechanisms, operating individually, or in coordination, embodiments of the present invention may provide robust handling of blockchain reorganization events while maintaining synchronization between blockchain and traditional database systems.

[00203] Expiration

[00204] In accordance with at least one embodiment of the present invention, blockchain records or transactions may be configured to include an expiration time or expiration block height, after which the records or transactions may no longer be considered valid according to the blockchain protocol. This expiration capability may provide significant advantages over transactions or records that do not specify any expiration, given that non-expiring transactions may potentially be executed at any time after they are signed unless explicit double-spend prevention techniques are employed. For instance, and without limitation, if a first transaction is signed but not immediately added to the blockchain, a user may have difficulty constructing a second transaction that spends or otherwise interacts with a source account’s balance. In some embodiments, a second transaction cannot be included without either blocking the first transaction, or succeeding it on the blockchain, due to the known technique of implementing a sequential transaction counter for addresses and / or accounts. In other embodiments, the second transaction may not block or depend on the first, but may nonetheless use the same token balance, leading to an indefinitely confusing contingency. By incorporating expiration times or expiration block heights, various embodiments of the present invention may prevent such scenarios.

[00205] In at least one embodiment, when a transaction or record includes an expiration time or block height, the blockchain network may reject as invalid any attempt to add that transaction or record to the blockchain after the specified expiration. This may enable the synchronization system to identify and handle expired transactions without requiring complex coordination between interface nodes. For instance, and without limitation, if a transaction expires before being added to any block, the synchronization system may detect this expiration and may automatically update database entries to reflect that the transaction has been canceled. In some embodiments, the synchronization system may attempt to re-generate expired transactions with new expiration times, potentially implementing various strategies to maximize the probability that re-generated transactions will be successfully added to the blockchain.

[00206] Various embodiments may implement different strategies for selecting appropriate expiration times or expiration block heights. These strategies may be contingent on, without limitation, estimated block generation times, network congestion levels, transaction and / or record priority, blockchain fees / pricing, and historical transaction processing times. The expiration time or expiration block height may, in at least one embodiment, be selected to provide sufficient time for the transaction to be added to the blockchain under normal operating conditions while still preventing indefinite transaction validity. The synchronization system may, in several embodiments, monitor transaction expiration and may implement various strategies to handle cases where transactions are at risk of expiring, potentially including, without limitation, re-generating records and / or transactions with extended expiration times and / or increased transaction fees, or simply allowing such transactions and / or records to expire.

[00207] In accordance with at least one embodiment of the present invention, when a wallet node connected to the synchronization system, or when an interface node within the synchronization system generates a record or transaction, said record and / or transaction may be configured with an expiration time or expiration block height. An interface node may then create database entries reflecting a pending status for said record or transaction, including the expiration time or block height. In certain embodiments, these database entries may affect available balances immediately, even before the transaction is added to any block, in order to prevent duplicate spending.

[00208] Subsequently, in various embodiments, an expiration detection routine implemented in one or more interface nodes of a synchronization system may monitor both the blockchain network and pending database entries in order to identify expired transactions. Upon detecting an expired transaction, said synchronization system may initiate an expiration handling procedure.

[00209] In an embodiment, following detecting an expired transaction that has not yet been added to any block, an expiration handling procedure may include one or more of, without limitation: updating database entries to reflect that the transaction has been canceled due to expiration, reversing any changes made to available balances when the transaction was initiated, and / or potentially initiating generation of a new transaction to replace the expired transaction, depending on the nature of the embodiment, and depending on the type or configuration of the expired record or transaction. In an embodiment, the expiration handling procedure may also trigger notifying other interface nodes about the expired transaction, enabling those nodes to update their database entries accordingly.

[00210] Conversely, in possible embodiments, upon detecting a record or transaction that has been added to a block, but which has not yet reached finality, where such record or transaction has a configured expiration date occurring in the past, an interface node of said synchronization system may implement a different expiration handling procedure. This procedure may include, without limitation, monitoring subsequent blocks to determine whether the expired transaction is eliminated from the blockchain due to reorganization, and potentially initiating generation of a new transaction only if the expired transaction is subsequently eliminated. As with other records and / or transactions not yet finalized, in one or more embodiments, the synchronization system may maintain the database entry associated with such records and / or transactions in a pending status until either finality is reached, or the record or transaction is eliminated from the blockchain in a reorganization.

[00211] In at least one embodiment, the synchronization system may implement retry procedures for expired transactions. These procedures may vary depending on the circumstances of expiration. For instance, and without limitation, if a transaction expires due to network congestion before being added to any block, the synchronization system may generate a new transaction with an increased transaction fee and an extended expiration time. However, if a transaction expires after being added to a block but before reaching finality, the synchronization system may wait to determine whether that transaction will be finalized (or, alternately, removed from the blockchain in a reorganization) before attempting to generate a replacement transaction. The retry procedures may implement various strategies to prevent duplicate transactions and to ensure that replacement transactions are properly sequenced.

[00212] The synchronization system may also, in various embodiments, maintain historical records of expired transactions and their replacements. These records may be used to implement various monitoring and reporting functions, potentially including without limitation: identifying patterns of transaction expiration, evaluating the effectiveness of different expiration time selection strategies, and generating alerts when transaction expiration rates exceed configured thresholds. The historical records may also be used to prevent duplicate transaction submission and to ensure proper sequencing of replacement transactions.

[00213] In various embodiments of the present invention, the synchronization system may incorporate additional handling to address transaction and / or record expiration during reorganization processing. During reorganization processing, one or more interface nodes may need to evaluate whether tracked transactions have expired or will expire before they can be re-submitted to the blockchain network. In certain embodiments, removed / eliminated transactions that have not expired may be added again to the blockchain after a reorganization, while transactions that have already expired may require special handling or cancellation.

[00214] In accordance with certain aspects of the present invention, interface nodes may implement different expiration handling procedures depending on the type of transaction being processed. For endogenous transactions originating from interface nodes of the synchronization system or related systems, one or more interface nodes may attempt to regenerate expired transactions with new expiration values, particularly in implementations where the original transaction intent can still be fulfilled. When regenerating such transactions, interface nodes may in some embodiments also update other transaction parameters such as gas prices and nonce values to improve the probability of successful processing. For exogenous transactions originating from external sources, one or more interface nodes may instead need to cancel or reverse expired transactions and potentially initiate compensating updates to data within the traditional database system, such as reversing pending status changes or notifying external systems of the expiration.

[00215] Various embodiments of the present invention may also implement special handling for expired records and / or transactions in the event of a reorganization. In some implementations, a reorganization event may result in transactions to expiring before they can be reprocessed, particularly in cases where the original expiration values were close to the current block height. Interface nodes may, in certain embodiments, implement a "time buffer" mechanism that ensures that records and / or transactions they generate have sufficient time to be processed before expiration. Some implementations may also include retry logic that attempts to reprocess expired transactions multiple times with progressively larger expiration windows before considering them permanently failed.

[00216] Smart Contract Synchronization

[00217] In accordance with at least one embodiment of the present invention, the synchronization system may process smart contract executions detected within blocks added to the blockchain. When processing a block containing a smart contract execution, a transaction reader component may examine log entries generated during that execution to identify token movements and other state changes affecting accounts managed and / or tracked by the synchronization system. In various implementations, these log entries may be processed to generate corresponding database entries within the synchronization system, potentially implementing various strategies to process smart contract execution pending and finalized states for effects of smart contract execution.

[00218] In accordance with various embodiments of the present invention, a smart contract is a program that executes on a blockchain network's virtual machine environment—such as the Ethereum Virtual Machine (EVM), Web Assembly (WASM), or similar execution platforms. Smart contracts may be Turing-complete, depending on a gas budget to limit execution time, or they may not be Turing-complete, potentially lacking loop or recursion capabilities, as in the case of Bitcoin Script. These programs are composed of executable code and, depending on the embodiment, may define functions and state variables. In one or more embodiments, smart contracts may perform computations, manage data storage, and interact with other contracts or accounts or addresses on the blockchain. Smart contracts operate deterministically, meaning that given the same input and state, they will produce the same output and state changes across all nodes in the network.

[00219] A contract execution record or transaction refers to the data generated when a smart contract is invoked or executed on the blockchain network through the inclusion of a specialized record or transaction in a new block. In various embodiments, this transaction may include details such as the sender's address, the recipient's address (which may be a smart contract), input data (such as function calls and parameters), and computational resource metrics such as gas budget, which may be directly specified or derived from other values. The execution of the transaction results in the execution of the smart contract, effectuating state transformations resulting from the execution of the smart contract code.

[00220] In an embodiment of the present invention, a block-building node generates a receipt in the process of executing a smart contract. This receipt may comprise details including, but not limited to: a transaction hash, a block number, gas consumed, execution status (success or failure), state changes to accounts or storage variables, execution timestamp, sender and recipient addresses, possible output data produced by the smart contract functions, and emitted logs or events. By generating and recording this receipt, the block-building node provides a verifiable record of the smart contract's execution, which can be stored on the blockchain ledger and accessed for auditing, confirming transaction outcomes, and ensuring the integrity of operations within the blockchain network.

[00221] In one or more embodiments, each state transformation effectuated by a smart contract execution may correspond to a log entry included in the receipt. Because all state transformations effectuated by a smart contract execution are encoded as log entries in the receipt, in at least one embodiment the synchronization system may not need to predict or simulate the outcome of that execution in order to synchronize said state modifications with one or more traditional database systems. Rather, the synchronization system may, in at least one embodiment, read and process said log entries in the manner described elsewhere herein as pertain to the synchronization system’s record and / or transaction processing.

[00222] In one or more embodiments, the synchronization system may process smart contract state transformations in a manner equivalent to the state transformations effectuated by individual records and / or transactions. In a manner comparable to the handling of records and / or transactions, in one or more embodiments, these log entries may be read by a transaction reader, they may be written to an event management system, and upon being read by a message handler, they effectuate the creation, modification or configuration of database entries tracking value transferred between and among accounts as a result of the smart contract execution. In at least one embodiment, these database entries may include references to the original smart contract invocation, potentially enabling the synchronization system to link related elements and potentially track the provenance of value transfers resulting from smart contract execution. In certain embodiments, database entries are also configured with a reference to the individual log entries that they correspond to. In at least one embodiment, one or more state transformations that may be effectuated by a smart contract execution may correspond on a one-to-one basis to one or more analogous record or transaction types that effectuate the same one or more state transformations.

[00223] In at least one embodiment, database entries generated and configured according to this process may be assigned the block number or block height of the block containing the execution record or transaction that generated the corresponding log entries. In various embodiments, these records may be subject to the same finality requirements as other blockchain transactions, potentially remaining in a pending status until this block has been deemed final by the synchronization system.

[00224] In accordance with at least one embodiment of the present invention, the synchronization system may perform one or more different operations, including but not limited to the following: first, the synchronization system may update the database entries for the original transfer to include the block number; second, the synchronization system may examine log entries generated during the smart contract execution to identify any transfers or other effects relevant to accounts managed by the synchronization system, third, for each relevant log entry, the synchronization system may generate new database entries tracking those effects.

[00225] The transaction reader process may, in various embodiments, handle different types of log entries in specific ways. For log entries indicating transfers to managed accounts, the process may generate pending in-transfer records and may increase the available balance of the destination account. For log entries indicating transfers from managed accounts, the process may generate pending out-transfer records and may verify that sufficient balance remains available. In at least one embodiment, all database entries generated from log entries may be assigned the block number of the block containing the smart contract execution, and may remain in a pending status until that block reaches finality.

[00226] In one or more embodiments, the synchronization system may maintain detailed audit records of all smart contract interactions and their effects. Such records may include, without limitation, the original invocation transaction, all generated log entries, all subsequent database entries and balance updates, and any reorganization events affecting those records. In at least one embodiment, these audit records may enable the synchronization system to reconstruct the complete history of any smart contract interaction, potentially including all intermediate states and any subsequent modifications or reversals. This audit capability may be particularly valuable when troubleshooting complex smart contract interactions or when investigating suspected errors in the synchronization process.

[00227] Third-Party Payment For Requests, Records, Or Transactions

[00228] In various blockchain systems, cryptographic signatures are essential for authorizing updates to the global state of a blockchain network. Specifically, any record or transaction that intends to modify the blockchain's state may need to be authenticated using a cryptographic signature. This signature may be generated using a private key associated with an originating account or address, ensuring that only the legitimate owner of an account or address can authorize actions affecting assets or data owned by, controlled by, or otherwise belonging to that account or address. The use of cryptographic signatures may serve as a security mechanism to prevent unauthorized modifications by malicious actors, thereby maintaining the integrity and trustworthiness of the blockchain network.

[00229] For example, when a user wishes to transfer tokens from their account to another, they may need to create a record or transaction and sign it with their private key. The cryptographic signature may serve to verify the authenticity of the transaction and prove that it was authorized by the account holder. Similarly, deploying a new smart contract or executing a function within an existing smart contract may require the initiator to sign the transaction. By enforcing the use of cryptographic signatures for these types of updates, blockchain networks may ensure that all changes to the global state are properly authorized and can be independently verified by all participating nodes.

[00230] In many blockchain networks, transaction fees, also called gas fees, may be required for executing and validating transactions and smart contracts. These fees may typically be paid by the originator of the transaction, who pays to cover the computational resources used. This mechanism may improve the efficient allocation of network resources and may deter malicious activities by imposing costs on network use. However, it may also present a challenge when one party wishes to pay fees on behalf of another. For example, a service provider may want to sponsor transaction fees to enhance user experience or promote adoption of a decentralized application. Known protocols require the sender's account to have enough balance to cover the fees. This complicates scenarios where end-users lack tokens required to pay fees or when simplifying blockchain interactions is desired.

[00231] To address this challenge, one or more embodiments of the present invention implement a two-phase process, whereby a blockchain record or transaction is first signed by the originator of the blockchain operation and is then signed by a separate account that pays the transaction fees.

[00232] In accordance with at least one embodiment of the present invention, a synchronization system or interface node may be implemented that enables one or more blockchain records to be submitted to a blockchain system by one or more wallet accounts, where such records may include signatures authorizing transfers or other state changes, but where blockchain processing fees for such records may be paid by one or more accounts or addresses controlled by the synchronization system or interface node, instead of accounts or addresses controlled by the one or more wallet accounts.

[00233] In at least one embodiment, the synchronization system may receive one or more signed records from a wallet account, where the one or more signed records have been cryptographically signed using a private key associated with one or more source accounts or addresses. The synchronization system may then encapsulate or wrap the records within a new blockchain transaction, which transaction may be signed by a private key controlled by the synchronization system or interface node, and which transaction may provide for payment of blockchain processing fees. The synchronization system may then transmit the new blockchain transaction to one or more blockchain nodes for validation and inclusion in a new block. In this way, wallet accounts may be relieved of the burden of maintaining a balance of native blockchain tokens used for payment of processing fees, as the synchronization system may pay such fees on behalf of the wallet accounts. The signed records submitted by wallet accounts may include, but are not limited to, transfer records moving token value between accounts, smart contract invocations, configuration records modifying account settings, updates made to identity information stored on accounts, and other records affecting blockchain state.

[00234] In at least one embodiment of the present invention, a synchronization system or interface node may receive one or more signed records submitted from one or more wallet accounts, and may aggregate or group those records as constituent records within a composite transaction. The composite transaction may then be configured by the synchronization system or interface node to ensure that blockchain processing fees are paid by accounts or addresses controlled by the synchronization system, covering the fees for executing the one or more constituent records, while the underlying constituent records remain signed by private keys controlled by the one or more wallet accounts that originated those records. This configuration enables the composite transaction to maintain cryptographic proof of authorization by the originating wallet accounts while delegating payment of processing fees to the synchronization system or interface node.

[00235] In accordance with at least one embodiment of the present invention, requests submitted by wallet nodes to an interface node may comprise one or more constituent records to be incorporated into atomic records or atomic transactions, which atomic records or atomic transactions may be encoded in a manner that ensures said one or more constituent records will be executed together along with an atomic transaction envelope, as per the blockchain protocol. The constituent records submitted to the interface node may thus be wrapped or encapsulated within an atomic transaction signed by the interface node, which atomic transaction provides for payment of blockchain processing fees by an account controlled by the interface node. In one or more embodiments, the interface node may configure atomic transaction records and atomic record chains to ensure that blockchain processing fees are paid by one or more accounts or addresses controlled by the interface node, while the underlying constituent records remain signed by private keys controlled by the one or more wallet accounts that originated those records. In this way, cryptographic proof of authorization by the wallet accounts may be maintained while delegating fee payment responsibility to the interface node. In one or more embodiments, said interface node constitutes a portion of, or comprises, a synchronization system.

[00236] In one or more embodiments, the composite transactions and / or the atomic transactions may also be configured with additional validation rules, criteria or conditions that may need to be satisfied before the constituent records may be processed, which rules, criteria or conditions may include, without limitation: requiring certain blockchain account annotations to be present; requiring certain token balances to be available; requiring certain smart contract conditions to be met; defining dependencies between constituent records that are satisfied for successful processing; requiring that the constituent records be executed on an all-or-nothing basis; requiring that the constituent records execute until the first record that fails; and / or requiring other configurable criteria to be satisfied.

[00237] In an alternate embodiment, rather than encapsulating or wrapping the original signed record with a new transaction, the synchronization system or interface node may append an additional cryptographic signature to the original record, where the additional signature is interpreted by the blockchain protocol of the blockchain network as belonging to a separate account that is responsible for paying transaction fees of the original record.

[00238] According to certain embodiments, instead of receiving signed records as part of requests submitted from wallet nodes, a synchronization system comprising one or more computer devices may read atomic transactions and / or composite transactions from a pending transaction pool of a blockchain network, and unwrap the constituent records encapsulated by said atomic transactions and / or composite transactions. The synchronization system may then encapsulate or wrap said constituent transactions again with a new atomic transaction or composite transaction, which new atomic transaction or new composite transaction may include a transaction fee paid by an account or address controlled by the synchronization system, before writing, sharing or transmitting said atomic transaction or composite transaction on the blockchain network. By this method said synchronization system may offer a service of paying for blockchain records and / or transactions without those records and / or transactions needing to be submitted directly to said synchronization system.

[00239] In various embodiments, one or more synchronization systems may accept one or more forms of compensation from the users of wallet accounts for the payment of blockchain processing fees and other services. Such compensation may be received in advance of any services being rendered, or may be received in arrears after services have been performed, or may be drawn from one or more funding accounts maintained by users with the synchronization system. The compensation may be provided in various forms including, but not limited to: official currency deposits, cryptocurrency transfers, credit card payments, automated clearing house (ACH) transfers, wire transfers, bank-to-bank transfers, prepaid value cards, electronic payment systems, mobile payment applications, digital wallet transfers, merchant services payments, remittance networks, app-store payments, mobile payments, or other electronic value transfer mechanisms. Said one or more synchronization systems may, in at least one embodiment, maintain records of services provided and fees paid, and may implement various accounting and reconciliation processes to ensure proper tracking of compensation received and services rendered; such accounting and reconciliation processes may, certain embodiments, track payments made and services rendered according to the one or more blockchain accounts or addresses of its users and / or customers. The synchronization system may optionally implement different fee structures, payment schedules, and compensation arrangements for different users, user categories, or transaction types. In some embodiments, the synchronization system may automatically draw required compensation from designated funding sources when balances fall below specified thresholds, or may implement various automated billing and collection processes for compensation owed.

[00240] According to various embodiments, a synchronization system or interface node may implement a message authentication system comprising one or more application programming interfaces (APIs) that accept requests signed using cryptographic keys associated with blockchain accounts. The system may authenticate such requests by verifying that messages have been cryptographically signed using private keys corresponding to public keys recorded within the blockchain for the accounts initiating such requests. In at least one embodiment, an API request message may include a payload containing the details of the requested operation, a signature generated by signing said payload with a private key, and information identifying the account making the request. The system may verify the signature against the public key associated with the identified account before processing the request. In an embodiment, a request may be an HTTP or HTTPS request, the payload may comprise the body of an HTTP or HTTPS message combined in a deterministic way with certain metadata and / or certain HTTP or HTTPS header data, while the cryptographic signature may be included along with the account information as one or more fields of the HTTP or HTTPS header. The message signing protocol may be implemented using various cryptographic schemes including asymmetric key cryptography, elliptic curve cryptography, or other suitable cryptographic methods. Such signed API requests may be used in various embodiments for various operations including, but not limited to: submitting transactions, querying account information, requesting blockchain status updates, managing account settings, initiating token transfers, deploying smart contracts, updating account configurations, managing identity information, and other account-related operations.

[00241] In accordance with at least one embodiment, the blockchain system may associate signed API requests with payment accounts or payment arrangements, such that requests properly signed by accounts having payment arrangements may be automatically accepted and processed. The system may maintain records linking blockchain accounts to payment methods, payment accounts, or compensation arrangements. When a signed API request is received from a wallet or other client application, the system may verify both the cryptographic signature and the existence of valid payment arrangements for the signing account. If both the signature is valid and payment arrangements are confirmed, the system may process the request and perform any associated operations, with fees being charged according to the established payment arrangements.

[00242] In at least some embodiments, a synchronization system or interface node may pay blockchain transaction fees, API request fees, or other service fees on behalf of wallet accounts without requiring direct compensation, in order to achieve various business objectives. Such objectives may include incentivizing adoption of the blockchain system by new users, encouraging increased transaction volume, promoting specific token types or smart contracts, supporting promotional campaigns, or enabling access to other revenuegenerating services. The synchronization system or interface node may implement different fee payment policies for different categories of users, time periods, geographic regions, or blockchain operations. The payment of fees may be subject to various conditions such as maximum amounts, time restrictions, volume caps, or service utilization requirements. The synchronization system or interface node may dynamically adjust these policies based on factors including network congestion, fee rates, user behavior patterns, marketing objectives, or system economics.

[00243] Synchronization System Illustrations

[00244] In accordance with at least one embodiment of the present invention, and with reference to FIGs. 12A and 12B, a synchronization system (1200) may include one or more transaction reader components (1202) that monitor a block-building node or validator node (1201) for new blocks. The transaction reader components may write information about new blocks, records and / or transactions to one or more event messaging systems (1206), which may include entries labeled in the diagram with version and fork information (e.g., blvltl, blvlt2, etc.). The transaction reader (1202) may comprise components responsible for reading from the event messaging system(s) (1205) and for writing to the event messaging system(s) (1203). In an example implementation, said event messaging system (1206) may be implemented as an Apache Kafka instance comprising various topics. At least one message handler (1207) may read entries from the event messaging system(s) (1206). The message handler may delegate all or a portion of this responsibility to one or more handler delegates (1209, 1210, 1211, 1212, 1215, 1216) that each are implemented to handle specific types of record or transaction. The message handler and message handler delegates may be responsible for updating the traditional database system (1226) which comprises account and address data storage, so as to reflect whatever state transformation may be encoded in the event messaging system entry they are handling.

[00245] According an embodiment, the synchronization system illustrated in FIGs. 12A and 12B may implement specific procedures for handling blockchain reorganizations. When a reorganization is detected, the transaction reader (1202) may write (1203) reversal entries to the event messaging system (indicated as blvltl_rev, blvlt2_rev, etc.) which entries are then processed by the message handler (1207) and one or more handler delegates (1210 1215, 1216) specifically responsible for reversal events. These reversal handler delegates operate on the traditional database system (1226) which (as stated above) comprises account and address data traditional database, to temporarily store reversed records and / or transactions subject to re-entry. Said message handler and handler delegates may process incoming blockchain events, validate transaction parameters, update account balances in the RDBMS, and maintain pending transaction records until finality is reached.

[00246] A cleanup component (1208) may be implicated in the reorganization-handling process at the final stage, after all the new fork’s blocks, records, transactions, and / or events have been processed by the message handler (1207) and its delegates. Said cleanup component (1208) may read all the records, transactions and / or events that remain in the transaction tracker component (1213) and evaluate them for re-creation or re-introduction to the blockchain. The cleanup component will add eligible records, transactions and / or events from the transaction tracking component to a write-to-blockchain event messaging system (1214) that is monitored by a transaction writer component (1218) responsible for submitting new transactions to the blockchain network.

[00247] In addition to the cleanup component (1208), in one or more embodiments a transaction processing component (1217) may also add record, transaction, and / or event entries to the write-to-blockchain event messaging system (1214), with the intent of passing them to the transaction writer component (1218) for them to be submitted to the blockchain network.

[00248] For transactions that expire before being added to the blockchain, one or more embodiments may implement specific handling procedures through an expiration handler component (1223), which may construct new records or transactions as replacements of original expired records or transactions; in at least one embodiment, such new records and / or transactions may include an "excludes" field referencing the original transaction, potentially preventing both transactions from being added to the blockchain simultaneously. Another component (1222) may create new transactions based on system events or requirements. The system may update a traditional database system (1226) when constructing new transactions, potentially implementing various strategies to ensure that the new transaction remains valid given current blockchain state. New transactions may be submitted to the mempool of the blockchain network (1221) for inclusion into the blockchain.

[00249] The system may also include a component (1219) for writing or transmitting wallet-generated records and / or transactions with the blockchain network (1221), as well as a component (1220) for writing or transmitting records and / or transactions that need to be resubmitted to the blockchain because they were eliminated in a prior reorganization.

[00250] FIGs.l3A and 13B are diagrams of synchronization system (1300), according to an embodiment. The synchronization system 1300 may include a point of sale system (POS) (1301) comprising a user interface that provides means for, among other things, the acceptance and origination of payment transactions, payment messages, payment requests, and / or payment instructions. Said POS may relay such payment-related elements to—or coordinate regarding the origination of such payment-related elements with—a transaction processing component (1311) of the synchronization system (1300) using various interfaces and / or protocols, such as ISO 8583 service, HTTP web service, or payment channel connection (1304).

[00251] The synchronization system (1300) may also interface with a web browser (1302) displaying a White-Label Web GUI (1305) rendered by the synchronization system. In various embodiments, said White-Label Web GUI may implement a user interface providing user access to transaction history data and / or provide means to modify system configuration.

[00252] A mobile device (1303) acting as a wallet node may execute a mobile application (1306) which may generate, sign, send, and / or transmit one or more payment messages, payment transactions, blockchain records, blockchain transactions, and / or other messages or communications or combinations thereof. Such communications may include the transmission of signed blockchain records (1307) transmitted inside messages of a web service protocol, which in example embodiments may be implemented using, for instance, “representational state transfer” (REST) or “javascript object notation remote procedure calls” JSON-RPC or a similar HTTP or HTTPS protocol, or another networking protocol.

[00253] In certain embodiments, said mobile device (1303) may also communicate with one or more external systems (1309, 1310) which operate outside the synchronization system but connect to it via one or more web services or microservice APIs, including systems that may implement web Services and / or web hooks (1309) and other existing and established systems (1310).

[00254] In an example implementation, the POS (1301) may exchange HTTP web service message packets (or packets of another protocol) with a transaction processing component of the synchronization system (1311), in order to initiate a payment session and obtain a session identifier or request identifier. Said POS (1301) may render a QR code or other graphical encoding of payment instructions or a payment request, which may encode such details as a session identifier or request identifier. In certain embodiments, the POS may open and maintain a socket connection, which may be implemented as a WebSocket connection, with said transaction processing component, which socket connection may stay open for the duration of a payment session. The mobile device (1303) via the mobile application (1306) and using a camera of the mobile device may then capture a digital image of said QR code or said graphical encoding and interpret said payment instructions or said payment request, loading the details of said payment instructions or said payment request into a memory storage of said mobile device.

[00255] In an embodiment, said mobile application may display one or more details of said payment instructions or said payment request on a graphical display or screen of said mobile device, which details may also include merchant identifying information regarding the owner or controller of a merchant blockchain account, which merchant identifying information is also included in the details of said payment instructions or said payment request. The mobile application may retrieve account data or an account data structure of said merchant blockchain account by, for example, (a) sending a message or request—for example, in an embodiment, an HTTPS web service message such as a JSON-RPC request or REST reqeust—to the synchronization system via the transaction processing component (1311), which may retrieve said account data or account data structure that has been cached in a traditional database server (1301), or (b) retrieving said account data structure from a blockchain global state by communicating with a block-building node integrated into the synchronization system (1319, connection not shown), or by communicating directly with another validator node or block-building node of the blockchain network (1321).

[00256] In various embodiments, the mobile application (1303) may compare the identifying information of the payment instructions or payment request with the account data or account data structure, and display a result of that comparison on the screen of said mobile device, warning a user of a mismatch and cautioning against proceeding against a transaction if there is a mismatch between the merchant identifying details encoded in the payment instructions or payment request, and the merchant identifying details encoded in the account data structure of the merchant blockchain account. In one or more embodiments, said comparison may comprise the comparison of a hash digest of a canonical encoding of said merchant identifying details, which hash digest may be calculated by the mobile application using the merchant identifying details encoded in the payment instructions or payment request, and which hash digest may be included in the account data structure of the merchant blockchain account.

[00257] In an example embodiment, said mobile application may, through a graphical user interface rendered on its graphical display or screen, present a user with an option to approve a payment conforming to the payment instructions or payment request, and upon user approval, said mobile application (1303), which may store one or more cryptographic keys of one or more wallet blockchain accounts in a memory of the mobile device, may use said one or more keys to cryptographically sign one or more blockchain records and / or transactions authorizing a transfer of tokens from a wallet blockchain account to said merchant blockchain account. Said mobile application may then encapsulate the one or more blockchain records inside one or more network messages (for example, a web service message such as a REST message or JSON-RPC message, or another type of network message) (1307) and send such messages to said transaction processing component (1311), to be processed as a payment satisfying the payment instructions or payment request of said POS (1301). In one or more embodiments, said one or more blockchain records or said one or more web service messages may incorporate or encode the session identifier or request identifier of the original payment instructions or payment request.

[00258] Said messages and / or signed blockchain records and / or transactions (1307) sent by said mobile application (1306) to said transaction processing component (1311) may be submitted by the transaction processing component to a permission checking / fraud detection module (1313), which may perform a risk assessment calculation or other evaluation to estimate or determine a probability or a risk metric that the payment effectuated by said messages, records and / or transactions may be reversed subsequent to initial acceptance, if it is accepted. In certain embodiments, said evaluation may incorporate a consultation of an available balance of said wallet blockchain account, which may or may not be tracked in a traditional database; if the available balance less the payment amount is less than zero, then the message, record or transaction will be rejected. In various embodiments, said probability or risk metric may represent a probability (a) that a blockchain record and / or transaction may become invalid or may be otherwise blocked as a result of a blockchain reorganization or other blockchain events or operations, and / or that (b) upon final asynchronous evaluation and execution by a block-building node, that the wallet blockchain account will have insufficient funds and cause the record or transaction to be invalid, blocking the payment within the blockchain. In certain embodiments, said fraud detection module may be configured to include a machine-learning model trained on a dataset that includes, for example, fraudulent and non-fraudulent messages, records and transactions, a history of blockchain records and / or transactions, a history of blockchain reorganization events, and / or other transactional or behavioral data.

[00259] In one or more embodiments, provided that said permission checking / fraud detection module (1313) calculates a probability value or a risk metric within an acceptable threshold, and otherwise does not deem a message, record or transaction invalid or unacceptable, said transaction processing component may perform one or both of the following actions: (a) insert or update various data in the traditional database server (1312); and / or (b) cause one or more messages, events, records and / or transactions to be written as entries to an event messaging system (1316), which entries will ultimately be read and processed by a transaction writer component (1317). In one or more embodiments, successful processing of said entries by said transaction writer component (1317) will result in one or more records and / or transactions being submitted to the block-building node (1319) (i.e. “endogenous payments”) for promulgation to the blockchain network (1321) and ultimate execution and inclusion into the blockchain.

[00260] In one or more embodiments, upon successfully updating the traditional database server and / or adding entries to the event messaging system, the transaction processing component (1311) may transmit a message to the POS system (1301) indicating that the payment associated with said session identifier or request identifier was completed, which session identifier or request identifier said transaction processing component may read from the messages and / or signed blockchain records and / or transactions (1307) sent by said mobile application (1306).

[00261] In certain embodiments, the mobile application (1303), upon receiving payment approval from a user, rather than sending a one or more messages, records and / or transactions (1307) to the transaction processing component (1311), the mobile application will transmit one or more blockchain records and / or transactions directly to a block building node or validator node of the blockchain network (1321) in order to satisfy the payment instructions or payment request, which record and / or transactions will ultimately be processed as exogenous transactions.

[00262] In one or more embodiments, the mobile application may submit a record or transaction directly to the blockchain network (i.e. an “exogenous payment”) in order to satisfy the payment instructions or payment request of the POS system may incorporate or encode a session identifier or request identifier corresponding to the payment instructions or payment request. An exogenous payment may be incorporated into a new block by a blockbuilding node (1319), which block may be read by a block reader component (1320), which will write the block details, including the exogenous payment, into an event messaging system (1318). A message handler (1315) may subsequently read the exogenous payment from the event messaging system (1318) and then write to the traditional database server (1312) relevant data with regards to the exogenous payment, updating status.

[00263] The transaction processing component (1311), upon detecting an update made to the traditional database server (1312) reflecting the completion of the pending payment corresponding to the session identifier or request identifier (1312), or otherwise being notified of the exogenous payment, may then transmit a message to the POS system (1301) indicating that the payment associated with said session identifier or request identifier was completed. In an alternate embodiment, the message handler itself, or a separate component invoked by the message handler, may communicate such an update to the POS system regarding the completion of the payment associated with the session identifier or request identifier, instead of the transaction processing component.

[00264] In various embodiments, a notification regarding the completion and / or satisfaction of payment instructions or payment requests, which completion and / or satisfaction is achieved by the incorporation into the blockchain of one or more cryptographically signed blockchain records and / or transactions authorizing a transfer of tokens from a wallet blockchain account to a merchant blockchain account—which records and / or transactions may be exogenous, or, alternately, exogenous—may be sent to the POS system after the block containing said one or more records and / or transactions reaches finality, or before it reaches finality, based on a configuration of the synchronization system (1300), or based on a risk determination made by the transaction processing component or the permission checker / fraud detection model.

[00265] According to some embodiments, in the event of a reorganization, the message handler (1315) will also serve the purpose of adding to the event messaging system (1316) one or more records and / or transactions that have been removed from the blockchain as a result of the reorganization, which removed records and / or transactions may be resubmitted to the Block-building node (1319) by the transaction writer component (1317).

[00266] In at least one embodiment, the one or more synchronization systems may optionally maintain separate data structures for tracking pending transactions, finalized transactions, and / or transactions that may require reconciliation due to reorganization events. In some embodiments, the synchronization system may comprise, incorporate, interact with, connect to, and / or use one or more event streaming platforms or publish-subscribe messaging systems, which individually and collectively may be referred to herein as “event messaging systems”, and which systems may include without limitation message brokers, event logs, message buses, and other messaging infrastructures, examples of which may include, but are not limited to, Apache Kafka, RabbitMQ, Apache Pulsar, Amazon Kinesis, Google Cloud Pub / Sub, or similar capabilities implemented in a more generalized database such as an RDBMS, object oriented database, etc. In one or more embodiments, such one or more event messaging systems may provide guaranteed message delivery and order preservation, and / or may be capable of retaining messages for configurable periods of time, and / or may be designed to handle real-time data flows.

[00267] FIGs.l4A-14B are diagrams of an example implementation of a synchronization system 1400 including a distributed data streaming platform that can store, process, and analyze transaction data in real time (event messaging system), according to an embodiment. The synchronization system is initialized 1401, and the distributed data streaming platform that is configured to generate an instruction queue message 1402 (event messaging system message), such as, Apache Kafka, RabbitMQ, Apache Pulsar, Amazon Kinesis, Google Cloud Pub / Sub, or similar capabilities implemented in a more generalized database such as an RDBMS, object oriented database, etc. In an embodiment, the instruction queue message may be configured with a specific topic that acts as an instruction queue, essentially containing commands or directives for a system to perform a specific action, where each message is processed in order by one or more users within a consumer group, effectively creating a queue-like behavior within the publish-subscribe model of event messaging system.

[00268] In an embodiment, one example technical advantage of integrating an event messaging system in the synchronization system 1400 as an instruction queue is its exceptional ability to handle high volumes of messages with low latency, making it ideal for real-time data streaming and processing in the synchronization system 1400. Further, the synchronization system 1400 may be configured to utilize event messaging system messages to help improve scalability, fault tolerance, and durable message storage. In this way, the synchronization system 1400 can provide reliable data delivery even in implementations of large-scale distributed systems; this may be beneficial for this example embodiment of the synchronization system 1400 as it may be configured with event-driven architecture, while utilizing log aggregation and real-time analytics, in various embodiments.

[00269] At 1404-1406, the type of event messaging system message is assessed by the synchronization system 1400. Event messaging system messages typically consist of a variable-length header, a variable-length opaque key byte array and a variable-length opaque value byte array and have an associated API. The data type of the event messaging system message may be assessed from the event messaging system topic, from which the synchronization system 1400 can determine the message format, which provide information about, among other things, the appropriate APIs, the wire protocol, or the on disk storage associated with the event messaging system message.

[00270] For example, in a possible embodiment, event messaging system messages may be written in batches (record batches). A record batch contains one or more records. In a degenerate case, a record batch may contain a single record. When assessing the type of event messaging system message, in an embodiment the synchronization system 1400 may process the event messaging system message's CRC and CRC32. Said CRC may cover the data from the attributes to the end of the batch, and may be located after the magic byte. The synchronization system may configure the clients to parse the magic byte before deciding how to interpret the bytes between the batch length and the magic byte. In an example embodiment, the partition leader epoch field may not typically be included in the CRC computation of the event messaging system to avoid the need to recompute the CRC when this field is assigned for every batch that is received by the broker. The CRC-32C (Castagnoli) polynomial may be used for such computation, in an example implementation.

[00271] At 1403, the event messaging system tracking data structure is computed, which is a specialized data structure used to keep track of the offset (position) of a consumer within a topic partition, essentially remembering where a consumer left off reading messages within a specific partition to ensure efficient message processing and prevent data loss.

[00272] At 1407, the event messaging system message is delivered to the process handler where envelope processing 1411, 1414 is handled. At 1412, the process handler performs individual record processing, and blockchain parameters are configured at 1415. The process handler further assesses signer account info, blockch number, parentld, and devicelD 1410. If the event messaging system message includes ARC Record at 1412, the process handler delivers each constituent with extra data and sets the blockchain parameters at 1415. A constituent ARC record is configured as a single, individual piece of data that makes up a larger, complex message, essentially a building block within a structured event messaging system message that can be processed independently within a stream processing pipeline.

[00273] At 1433, the account entry service process of the synchronization system, 1400 is executed, which may include the following processes and configurations (1) reserving Available Balance (only sender), (2) creating entries, (3) creating and validate entries, (4) checking and reserving available balance, (5) creating cancelled entries, (6) executing the entries, (7) executing as complete, (8) executing cancelled, (9) updating entries status, (10) updating entries status (status, block number) updating entries Status (status, block Number, minor, actual fee used), and (11) reverting completed entries.

[00274] At 1434, accounting is performed by the synchronization system 1400, where the following processes and configurations may be performed (1) deducting amount from available balance, (2) refunding amount to available balance, (3) deducting amount from current balance, (4) adding Amount To Both Balance. At 1435, the account token balance is stored to one or more off-chain databases or external data management systems.

[00275] The process handler at 1418-1424 commits block finality, meaning that the transaction is confirmed and added to a blockchain's block, and the transaction receipt 1437 is sent to the minor 1417.

[00276] At 1436, this blockchain state change is recorded on the event messaging system data mesh architecture of the synchronization system 1400, including the blockchain ledger and one or more off-chain databases or external data management systems. The reward for the blockchain building node (minor) 1419 is committed, such as a reward block. At 1439, the synchronization system 1420, 1421, 1422, 1423 commits finality for each transaction fetched 1440, and the synchronization system 1400 checks ensures that a receipt is generated 1425-1432.

[00277] FIGs.l5A and 15B are diagrams of synchronization system architecture, according to an embodiment. The synchronization system 1500 includes a mobile application or wallet device 1501, which is configured to interface with the synchronization system client library 1512, blockchain client library 1502, and secure enclave 1504. The synchronization system 1500 configures the mobile application / wallet device 1501, client library 1502 to interface with the blockchain API 1505 and token issuer 1508 using the internet / mobile network 1507 through the HTTP Proxy Service 1509 via Wallet Link RPC API 1506. The mobile application or wallet device 1501 may be configured by the synchronization system 1500 to direct transactions 1503 to the HTTP Proxy Service 1509 with the token issuer 1508. The web application firewall 1510 at the internet / mobile network 1507 may be configured to inspect JSON-RPC payloads so that only specified method invocations are permitted. The synchronization system 1500 may be configured to interface with interconnect bridge 1515, which implements the synchronization system WebHook API. The transaction processing component 1513 can be configured to interface with a blockchain KYC utility compliance system 1521 to provide document analysis, ensure KYC compliance, limit fraud, money laundering, terrorist financing, and other illegal and other illicit activities. The synchronization system 1500 can be configured to execute external services, such as automated analysis service, redundant instance, chain-of-authority private keys at 1522 through the cloud firewall 1538. The synchronization system 1500 may include block building node 1531, transaction writer component 1532, and the chain-of-authority private keys 1539. The interconnect bridge 1515 may communicate via an external connection 1517 with the external backend 1516 and various databases 1536. The transaction processing component 1513 may interface with a block building node 1519, an event messaging system 1527, and databases 1528. Block building node 1519 processes may cause a blockchain synch 1520. Through an interconnect bridge 1515, the transaction processing component 1513 may access to a synchronization system authentication library 1529. The transaction writer component 1530 may interface with a vault network 1533, high-security vault keys 1532 and a blockchain building node 1531.

[00278] Digital Processing Systems

[00279] FIG. 16 is a schematic view of a computer network in which embodiments may be implemented.

[00280] Client computer(s) / devices 50 and server computer(s) 60 provide processing, storage, and input / output (I / O) devices executing application programs and the like. The server 60 may be a gateway or a persistent server. Client computer(s) / device(s) 50 can also be linked through communications network 70 to other computing devices, including other client device(s) / processor(s) 50 and server computer(s) 60. Communications network 70 can be part of a remote access network, a global network (e.g., the Internet), cloud computing servers or service, a worldwide collection of computers, local area or wide area networks, and gateways that currently use respective protocols (e.g., TCP / IP, Bluetooth®, etc.) to communicate with one another. Other electronic device / computer network architectures are suitable.

[00281] In certain embodiment of the present invention, at least one wallet node may be implemented as software application executing on a client computer (50), which wallet node may implement a zero-knowledge proof prover. Said wallet node (50) may execute said zeroknowledge proof prover so as to generate a zero-knowledge proof; said wallet node may then incorporate said zero-knowledge proof into a zero-knowledge record, which it may then submit for processing over a computer network (17) to one or more block-building nodes comprising one or more servers (60) connected to said network. Said one or more blockbuilding nodes may then verify said zero-knowledge proof though the use of a zeroknowledge proof verifier software executing within the computer memory of said server (60).

[00282] FIG. 17 is a block diagram illustrating an example embodiment of a computer node (e.g., client processor(s) / device(s) 50 or server computer(s) 60) in the computer network 70 of FIG. 16. Each computer node 50, 60 contains system bus 79, where a bus is a set of hardware lines used for data transfer among components of a computer or processing system. The system bus 79 is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, I / O ports, network ports, etc.) that enables transfer of information between the elements. Attached to the system bus 79 is an I / O devices interface 82 for connecting various input and output devices (e.g., keyboard, mouse, display(s), printer(s), speaker(s), etc.) to the computer node 50, 60. A network interface 86 allows the computer node to connect to various other devices attached to a network (e.g., the network 70 of FIG. 16). A memory 90 provides volatile storage for computer software instructions 92a and data 94a used to implement an embodiment of the present disclosure. A disk storage 95 provides non-volatile storage for the computer software instructions 92b and data 94b used to implement an embodiment of the present disclosure. A central processor unit 84 is also attached to the system bus 79 and provides for execution of computer instructions.

[00283] Software components 92A, 92B of the computer-implemented system may be configured using any known programming language, including any high-level, object-oriented programming language or configured in firmware. The computer-implemented system may include instances of processes that enable execution of transactions and recordation of transactions. The computer-implemented system may include instances of a blockchain software components described herein, which can be implemented a computing device that communicates with the blockchain network, for example, through a blockchain protocol, secure sockets layer (SSL), or any other suitable protocol. The computer-implemented system may be configured with blockchain software components 92A, 92B that can help enable implementations disclosed herein, such as payment channel liquidity, payment channel permissioning, safe offline payment channel availability, zero-knowledge permissioning, anchor blocks, block-building and protocol validation functions, message signing protocol, and consensus protocols.

[00284] In an example mobile implementation, a mobile agent implementation may be provided. A client-server environment can be used to enable mobile services. It can use, for example, the Extensible Messaging and Presence Protocol (XMPP) to tether a wallet on the device 50. The blockchain network or a server 60 can then issue commands to the mobile device on request. The mobile user interface framework used to access certain components of the computer-implemented system may be based on XHP, Javelin, or WURFL. In another example mobile implementation for OS X and iOS operating computer-implemented systems and their respective APIs, Cocoa and Cocoa Touch may be used to implement the client-side components using Objective-C or any other high-level programming language that adds Smalltalk-style messaging to the C programming language.

[00285] An example embodiment includes device code 92A, 92B executed in the trusted execution environment (TEE) or trust platform module (TPM). The TEE or TPM is a hardware environment that runs instructions and stores data outside the main operating computer-implemented system (OS) of a device. This protects sensitive code and data from malware or snooping with purpose-built hardware governed by an computer-implemented system of endorsements, beginning with the device manufacturer. The computer-implemented system may perform checks on the TEE or TPM, such as executing BIOS checks, to verify that the folders (e.g., wallets) stored in the TEE / TPM have not been altered by malicious actors.

[00286] Further example embodiments disclosed herein may be configured using a computer program product; for example, controls may be programmed in software for implementing example embodiments. Further example embodiments may include a non-transitory computer-readable medium containing instructions that may be executed by a processor which, when loaded and executed, cause the processor to complete methods described herein.

[00287] In one embodiment, the processor routines 92a-92b and data 94a-94b are a computer program product (generally referenced as 92), including a computer readable medium (e.g., a removable storage medium such as DVD-ROM(s), CD-ROM(s), diskette(s), tape(s), etc.) that provides at least a portion of the software instructions for the disclosure system. Computer program product 92 can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication, and / or wireless connection. In other embodiments, the disclosure programs are a computer program propagated signal product embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s)). Such carrier medium or signals provide at least a portion of the software instructions for the present disclosure routine s / program 92.

[00288] In alternate embodiments, the propagated signal is an analog carrier wave or digital signal carried on the propagated medium. For example, the propagated signal may be a digitized signal propagated over a global network (e.g., the Internet), a telecommunications network, or other network (such as the network 70 of FIG. 16). In one embodiment, the propagated signal is a signal that is transmitted over the propagation medium over a period of time, such as the instructions for a software application sent in packets over a network over a period of milliseconds, seconds, minutes, or longer. In another embodiment, the computer readable medium of the computer program product 92 is a propagation medium that the computer system 50 may receive and read, such as by receiving the propagation medium and identifying a propagated signal embodied in the propagation medium, as described above for computer program propagated signal product.

[00289] Generally speaking, the term “carrier medium” or transient carrier encompasses the foregoing transient signals, propagated signals, propagated medium, storage medium, and the like.

[00290] In other embodiments, the program product 92 may be implemented as a Software as a Service (SaaS) implementation, or other installation or communication supporting endusers.

[00291] Embodiments or aspects thereof may be implemented in the form of hardware including but not limited to hardware circuitry, firmware, or software. If implemented in software, the software may be stored on any non-transient computer readable medium that is configured to enable a processor to load the software or subsets of instructions thereof. The processor then executes the instructions and is configured to operate or cause an apparatus to operate in a manner as described herein.

[00292] Further, hardware, firmware, software, routines, or instructions may be described herein as performing certain actions and / or functions of the data processors. However, it should be appreciated that such descriptions contained herein are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.

[00293] Quick Response (OR) Embodiment

[00294] At least one embodiment is directed toward a computer-implemented method 1800 for accepting electronic payment. FIG. 18 shows a diagram illustrating an embodiment wherein a mobile device, such as a cell phone, captures a quick response (QR) code shown on a computer screen. The method includes a point-of-sale computer device 1802, at least one authorization computer devices (which in certain embodiments may constitute, comprise or form a part of a synchronization system), and a consumer smartphone 1804 with at least one camera 1803, and a processor and memory with computer code instructions stored thereon. The method connects the point-of-sale computer device to a packet-switched computer network, as well as connecting the at least one authorization computer devices to the packet-switched computer network, and the smartphone to the packet-switched computer network.

[00295] The point-of-sale computer device may have at least one graphical display. The method configures the point-of-sale computer device to share a session identifier with the at least one of the one or more authorization computer devices. The point-of-sale consumer device then will display, a graphical encoding of a payment request 1801 (e.g., a QR code), wherein the graphical encoding of the payment request comprises an encoding of the session identifier (which may also be a request identifier in certain embodiments). The smart phone will capture an image of the graphical encoding of the payment request. The smart phone will display a user-acceptance message, wherein the message requests acceptance of the payment request by a user of the consumer smart phone. The user of the smartphone may then accept the payment request using the smart phone, and the phone will indicate acceptance of the payment request.

[00296] The method constructs a data record configured to encode a payment instruction to conform to the payment request, wherein the data record encoding of the payment instruction encodes the session identifier (which in certain embodiments may be a request identifier) and transmits the data record to at least one of the one or more authorization computer devices via the packet-switched computer network. The at least one of the one or more authorization computer devices is configured to perform a verification of the correctness and authenticity of the payment instruction encoded in the data record. The point-of-sale computer device is configured to receive, via the packet-switched computer network, a confirmation that the correctness and authenticity of the payment instruction encoded in the data record has been verified.

[00297] In an embodiment, a cryptographic signature of the data record may be attached to the data record prior to transmission to the one or more authorization computer devices. The cryptographic signature may be generated using an asymmetric cryptographic signature algorithm, and the cryptographic signature may be generated generated using a private key corresponding to a public key stored in a data storage of at least one of the one or more authorization computer devices.

[00298] In an embodiment, the public key may correspond to a money balance stored in at least one of the one or more authorization computer devices; and wherein the verification of the correctness and authenticity of the payment instruction encoded in the data record may comprise a verification that the cryptographic signature is valid and was generated with a private key corresponding to said public key.

[00299] In an embodiment, the at least one of the one or more authorization computer devices is a blockchain validation computer device hosting a blockchain validation software program. The blockchain validation software program is configured to maintain a connection to one or more additional blockchain validator computer devices hosting one or more additional blockchain validation software programs. The blockchain validator computer devices are connected to the packet-switched computer network. The data record is a blockchain data record, the acceptance of which by the blockchain configured to effectuate a change to a global state of the blockchain.

[00300] In an embodiment, the data storage comprises an encoding of the blockchain’s global state, and wherein the data record is configured to encode a transformation to the blockchain’s global state.

[00301] In an embodiment, the point-of-sale computer device is configured to open a socket connection to at least one of the one or more authorization computer devices before displaying on the graphical display the graphical encoding of the payment request.

[00302] In an embodiment, the point-of-sale computer device, after displaying the graphical encoding of the payment request on the graphical display, is configured to poll at least one of the one or more authentication computer devices, sending in reference to the session ID.

[00303] In an embodiment, wherein the point-of-sale computer device is configured as part of a cash-register system at a physical retail location.

[00304] In an embodiment, wherein the point-of-sale computer device is a personal computer, the personal computer being configured to execute a web browser software, and wherein the graphical representation of the payment request is displayed in a graphical-userinterface window of the web browser software.

[00305] Zero Knowledge Systems

[00306] In an embodiment, at least one record or transaction may be configured as a zeroknowledge record or transaction encoding of a zero-knowledge state transformation description. The encoding of the zero-knowledge record may include at least the following elements: (1) one or more addresses or paths identifying or referencing the one or more locations of the elements of a discrete data subset within the global state, which discrete data subset comprises either a contiguous subset or a non-contiguous subset of the data comprised by the global state, (2) a revised data subset, representing a new revised version of some portion of or subset of said discrete data subset, or (3) a transition proof implemented as a non-interactive zero-knowledge proof, which transition proof proves that the transition from the discrete data subset to the revised data subset follows the established rules of the blockchain system.

[00307] In an embodiment, a zero-knowledge record may include at least one of: (1) the discrete data subset itself, (2) one or more cryptographic hashes of one or more elements of the discrete data subset, or (3) both the discrete data subset and one or more cryptographic hashes of one or more elements of the discrete data subset. The transition proof may be configured to correspond to one of a set of pre-defined transition types for which corresponding non-interactive zero-knowledge proofs may be generated. Each pre-defined transition type may be configured to correspond to an encoded state-transition implementation encoded as a zero-knowledge algorithmic encoding. The encoded statetransition implementation may be configured to receive certain data as input, and generates certain data as output, and where a portion of the input data is private input data, and the remainder of the input data is public input data. The public input data may be configured to include the discrete data subset. The output of the encoded state-transition implementation is the revised data subset.

[00308] In an embodiment, the transition proof may be generated by a process that includes: (1) a compilation step where the zero-knowledge algorithmic encoding is compiled into a set of polynomial equations, and (2) evaluation of the polynomials at one or more random points, producing values that are included in the transition proof.

[00309] In one or more embodiments, said transition proof may be generated through any zero-knowledge proof system or method which implements the requisite features and capabilities, including zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) systems or methods, and / or a zero-knowledge succinct transparent argument of knowledge (zk-STARK) systems or methods. See, for example, U.S. Provisional Application No. 63 / 608,018, filed on December 8, 2023, Appendix (Zero-Knowledge Succinct Transparent Argument of Knowledge (zk-STARK)), which is incorporated herein by reference in its entirety.

[00310] In various embodiments, methods and systems for validating and accepting zeroknowledge records and / or transactions may be provided. A validating computer may be configured to store the blockchain's global state in a retrievable storage medium. A wallet computer node, connected to the validating computer node via a computer network, may be configured to generate a new zero-knowledge record. The validating computer node may be configured to receive the zero-knowledge record from the wallet computer node, and may subsequently perform validation of the zero-knowledge record. Such validation may include configuring the validating node to retrieve a retrieved data subset from the global state, which may be a subset of global state data that corresponds to the discrete data subset referenced or included in the zero-knowledge record. The validating node may be configured to verify that the discrete data subset included in the zero-knowledge record or referenced by the zeroknowledge record is equivalent to the retrieved data subset. The validating node may be configured to verify that the non-interactive zero-knowledge proof is valid when verified combination with the discrete data subset (or retrieved data subset) and revised data subset-and possibly in combination additional Public Input Data included with the zero-knowledge record in certain cases.

[00311] In an embodiment, in the case that the non-interactive zero-knowledge proof is successfully verified and the zero-knowledge record is deemed valid, the validating node may be configured to replace some portion of the discrete data subset with elements of the revised data subset, where the portion of the discrete data subset that is replaced by elements of the revised data subset is decided according to which pre-defined transition type the noninteractive zero-knowledge proof corresponds to. The discrete data subset may be configured to include at least one permission encoding, which permission encoding either is itself interpretable by the encoded state-transition implementation, or is transformed into an equivalent format interpretable by the encoded state-transition implementation. The permission encoding, or a transformation thereof, may be interpreted or evaluated within the encoded state-transition implementation.

[00312] In an embodiment, a state transformation corresponding to the encoded statetransition implementation is undertaken only if the permission encoding is interpreted or evaluated with a result indicating that said state transformation is permitted. The permission encoding may comprise a logical function encoded as interpretable or executable computer code. The logical function may be configured to accept one or more permission inputs and the logical function is configured to output a permission output. The permission output may correspond to either a permitted transition status or a not-permitted transition status, given the one or more permission inputs. The state transformation corresponding to the encoded statetransition implementation may be undertaken only in cases where the permission output given the one or more permission inputs corresponds to the permitted transition status, and the state transformation may not be undertaken in cases where the permission output given the one or more permission inputs corresponds to the non-permitted transition status. One or more permission inputs may comprise a subset of the public input data and private input data received by the encoded state-transition implementation. The logical function, or a transformation thereof may be configured into an equivalent format interpretable by the zeroknowledge algorithmic encoding, and may be interpreted or executed within the zeroknowledge algorithmic encoding. An example implementation of a zero-knowledge algorithmic encoding (e.g., Arithmetic Circuit) is disclosed in U.S. Provisional Application No. 63 / 608,018, filed on December 8, 2023 Appendix 4, incorporated herein by reference in its entirety. In an embodiment, the zero-knowledge algorithmic encoding may be implemented in a CPU with embedded Zero Knowledge Processing Unit (ZPU) and programmable hardware accelerator. This hybrid CPU / ZPU may be optimized to improve packet processing for verifying blockchain transactions using zkSNARK transaction processing.

[00313] In an embodiment, the non-interactive zero knowledge proof may be deemed valid only in the case where the logical function outputs a value corresponding to the permitted transition status within the zero-knowledge algorithmic encoding. In the event the permission encoding comprises a pattern encoding, the state transformation corresponding to the encoded state transformation implementation may be permitted only in the case that the pattern encoding matches at least a portion of the private input data, or a portion of the public input data, or a combination thereof. The pattern encoding, or a transformation thereof may be configured into an equivalent format interpretable by the zero-knowledge algorithmic encoding, which may then be compared to a portion of the input data received by the zeroknowledge algorithmic encoding, within the zero-knowledge algorithmic encoding itself, and in which the transition proof is verified successfully only in the case where the pattern encoding matches said input data within the zero-knowledge algorithmic encoding. The discrete data subset may include one or more account records, each account record including one or more private ledgers, each private ledger comprising at least one cryptographic hash digest the preimage of which is an unmasked private ledger, which at least one unmasked private ledger contains one or more token balances. At least one unmasked private ledger may be implemented as a Hash Tree or Merkle Tree, where the root of the tree corresponds to the private ledger's cryptographic hash digest. At least one unmasked private ledger may be implemented as a Merkle Trie or Merkle Patricia Trie, where the root of the trie corresponds to the private ledger's cryptographic hash digest. At least one unmasked private ledger may be implemented as a Merkle Proof or partial Merkle Tree or partial Merkle Patricia Trie, and where the root of the proof, tree or trie corresponds to the private ledger's cryptographic hash digest. The private input data may include the at least one unmasked private ledger, which at least one unmasked private ledger is excluded from the discrete data subset and from the public input data; and where the private input data also includes information regarding at least one quantity of tokens.

[00314] In an embodiment, the encoded state transformation implementation may be configured as a private state transformation. The encoded state transformation implementation computing at least one derived hash, which derived hash is the cryptographic hash of the at least one unmasked private ledger. The encoded state transformation implementation may be configured to determine that such at least one derived hash equals the at least one cryptographic hash digest of the private ledger which corresponds to that at least one unmasked private ledger. The encoded state transformation implementation may be configured to modify the unmasked private ledger in a manner consistent with the token quantity information included in the private input data. The encoded state transformation implementation may be configured to compute a revised cryptographic hash digest of the modified unmasked private ledger, which revised cryptographic hash digest corresponds to the output of the encoded state transformation implementation. The private state transformation may be configured to include a computational process whereby at least one permission encoding included in the public input data is evaluated in combination with a portion of the input data received by the encoded state transformation implementation, whereby the state transformation corresponding to the encoded state transformation implementation is only undertaken if the permission encoding is interpreted or evaluated in a manner indicating that said state transformation is permitted. The zero-knowledge record may be accepted and included in the blockchain only in the case where one or more permission encodings included in the record's discrete data subset are interpreted or evaluated in a manner indicating that the state transformation corresponding to the zero-knowledge record is permitted.

[00315] In an embodiment, the validating computer may be configured to replace at least one cryptographic hash digest of the one or more account record's one or more private ledgers in the global state with the revised cryptographic hash digest if the zero-knowledge record is accepted and included in the blockchain.

[00316] Zero-Knowledge-Encoded Global State Transformations

[00317] One or more non-limiting embodiments of the present invention comprises blockchain systems that comprise block-building nodes evaluating zero-knowledge records and / or zero-knowledge transactions which records and / or, when valid, encodes transformations to the global states of said blockchain systems.

[00318] In one or more possible such embodiments, transformations to said global state may be effectuated by the inclusion of one or more zero-knowledge records and / or zeroknowledge transactions in one or more blocks added to the blockchain. In at least one embodiment, a zero-knowledge record or zero-knowledge transaction is a blockchain record or blockchain transaction that encodes a global state transformation in the form of a noninteractive zero-knowledge proof, which non-interactive zero-knowledge proof comprises updates and modifications to the global state, to which updates and modifications to the global state may be confirmed to be valid through the verification of the zero-knowledge proof.

[00319] In one or more embodiments, said zero-knowledge records and / or transactions may improve the execution speed of blockchain systems by reducing the time required to assess the validity of records and / or transactions added to the blockchain, and by reducing the time required to apply the global state transformations encoded by said records and / or transactions. In certain configurations, said zero-knowledge records and / or transactions may also improve the privacy of blockchain systems by allowing certain values to be hidden which might otherwise be public on the blockchain. One or more embodiments of the present invention may also incorporate the interpretation of permissioning constraints into the creation and verification of zero-knowledge proofs, which zero-knowledge interpretation of permissioning constraints may permit a public proof of compliance with regulatory requirements to be publicly posted on a public blockchain without revealing publicly the details of a blockchain record and / or transaction.

[00320] In one or more embodiments, one or more zero-knowledge record types and / or zero-knowledge transaction types trigger one or more types of transformation to the global state, such that global state transformations of said type occur when records and / or transactions of said types are added to the blockchain following one or more validations of said records and / or transactions, whereby said one or more validations are performed by evaluating a non-interactive zero-knowledge proof included in the encoding of said one or more zero-knowledge records and / or transactions.

[00321] In one or more embodiments, relevant elements of the initial global state prior to state transformation may be included as public inputs to the non-interactive zero-knowledge proofs algorithmic encoding, and updates and modifications to the blockchain global state that result from said global state transformation may be included among public outputs of the algorithmic encoding. In an embodiment, a zero-knowledge record and / or transaction comprises these inputs and outputs, as well as the non-interactive zero-knowledge proof demonstrating that said state transformation is valid.

[00322] In one or more alternate embodiments, updates and modifications to the blockchain global state that result from said global state transformation may be included among public inputs of a algorithmic encoding, and a public output of the of the zeroknowledge algorithmic encoding may comprise a Boolean values, an integer, or some other data element or elements that result from a confirmation that the updates and modifications to the blockchain global state are valid transformations of the initial global state elements provided as inputs to the zero-knowledge algorithmic encoding, according to the rules of the algorithmic encoding.

[00323] In at least one embodiment, said zero-knowledge record and / or zero-knowledge transaction may comprise one or more zero-knowledge proofs, one or more algorithmic encodings or references to one or more pre-specified algorithmic encodings, one or more public inputs to the one or more algorithmic encodings, and / or one or more public outputs of the one or more algorithmic encodings, among other elements.

[00324] In one or more embodiments of the present invention, one or more public inputs and / or private inputs to a non-interactive zero-knowledge proofs algorithmic encoding may comprise one or more complex or nested data structures encoded according to a standardized format or representation—for example, according to the “Recursive Length Prefix” format utilized by the Ethereum blockchain, or the “JSON Canonicalization Scheme” specified by IETF RFC 8785, or the “Concise Binary Object Representation” specified by RFC 7049, or some other deterministically ordered and encoded data representation. In at least one embodiment, such standardized encoding format or representation is an encoding format or representation which may be deterministically transformed back and forth between other encoding formats or representations, and may be transformed back and forth to the encoding format of the blockchain’s global state as it is encoded in a block-building node of the blockchain system. Complex or nested data structures encoded according to a standardized format or representation as described herein are also called “deterministic data” or “deterministic data structures”; data extracted or copied from the blockchain global state as it is encoded in a block-building node of the blockchain is also called “state data” or “state data structures”.

[00325] In one or more embodiments, a zero-knowledge proof verification implementation may be encapsulated inside an encapsulating function implemented in software, which function accepts as input one or more state data structures and / or deterministic data structures, and as output returns one or more state data structures and / or deterministic data structures. In an embodiment, the implementation of the encapsulating function may comprise one or more transformations of one or more state data structures into one or more deterministic data structures, and vice-versa, or one or more transformations between different deterministic data structures. In an embodiment, one or more data structures that can contain arrays, dictionaries, integers, strings, etc., map onto various internal data elements of one or more deterministic data structures.

[00326] In an embodiment, a zero-knowledge record or zero-knowledge transaction may be passed as an argument into said encapsulating function, which function may verify the zero-knowledge proof of the transaction along with possible other elements of the transaction. The encapsulating function may thereby authorize a block-building node to apply the global state transformation encoded by the zero-knowledge record or zero-knowledge transaction; or, alternately, if the record or transaction is deemed invalid, thereby cause the block-building node to discard the record or transaction, or add the record or transaction to a new block without applying the global state transformation.

[00327] In one or more embodiments, deterministic data structures representing token configurations or wallet accounts may be passed into a zero-knowledge algorithmic encoding, allowing an encoded permissioning constraint to be extracted from said deterministic data structures. In one or more embodiments, an interpreter of one or more encoded permissioning constraints may be implemented within the algorithmic encoding. In an embodiment, a permissioning constraint may be executed inside the algorithmic encoding, and the rules of the permissioning constraint may be enforced according to the result of said execution in the off-chain computation encoded by the non-interactive zero-knowledge proof.

[00328] In one or more embodiments of the present invention, zero-knowledge algorithmic encodings may be implemented corresponding to a variety of possible state transformations. Some such state transformations may comprise simple state transformations corresponding to simple zero-knowledge algorithmic encodings, and some such state transformations may comprise complex state transformations corresponding to more complex zero-knowledge algorithmic encodings. A non-exhaustive list of possible zero-knowledge algorithmic encodings that may or may not be implemented, and corresponding state transformations, include the following: (a) Token transfer algorithmic encodings, which may encode transfers of tokens between and among blockchain accounts and / or addresses within the global state. (b) Permission-constrained algorithmic encodings, which may encode various global state transformations that comprise a computational step which determines whether a permissioning constraint is satisfied or not. (c) Privacy algorithmic encodings, which may encode global state transformations where one or more data values being transformed are subjected to a cryptographic hash before being written to the public global state encoding within a block-building node.

[00329] In an embodiment, global state transformations may be effectuated both by standard blockchain records and / or transactions on the one hand, which such records and / or transactions do not comprise any zero-knowledge proof element, and, on the other hand, zero-knowledge records and / or zero-knowledge transactions. In such an embodiment, a block-building node may evaluate one or more zero-knowledge records and / or zeroknowledge transactions for inclusion in a new block, which evaluation comprises an evaluation of the zero-knowledge proof, specified algorithmic encoding, public inputs and public outputs of said zero-knowledge records and / or transactions; in addition, within the same block, said block-building node may also evaluate for inclusion one or more blockchain records and / or transactions that do not comprise any zero-knowledge element, the evaluation of which may require the step-by-step execution of state transformation computation before the validity of such records and / or transactions can be established.

[00330] In an embodiment, a global state transformation corresponding to a zeroknowledge algorithmic encoding may be defined as a transformation made to the input data that results in the output data.

[00331] In an alternate embodiment, a global state transformation corresponding to a zeroknowledge algorithmic encoding may be defined as a transformation made to one or more input data elements of the algorithmic encoding, which transformation results in one or more other input data elements of the algorithmic encoding. In such an embodiment, one or more output data elements of said algorithmic encoding may comprise a Boolean value, an integer, or some other data element or elements that result from a confirmation that said transformation is valid.

[00332] In one or more embodiments, zero-knowledge records and / or zero-knowledge transactions may configure one or more of the following fields, among others: (a) A list of accounts and / or addresses within the global state, which addresses correspond to public inputs to the zero-knowledge algorithmic encodings of the zero-knowledge records and / or transactions, which accounts and / or addresses may be used to retrieve the state data comprising said public inputs. (b) A zero-knowledge algorithmic encoding type, identifying a pre-defined zeroknowledge algorithmic encoding which been used to compute a state transformation and generate a zero-knowledge proof. An embodiment may configure a separate field for algorithmic encoding type, or, alternately, a more general record type field may indirectly imply the algorithmic encoding, with a different record type for each algorithmic encoding type implemented. (c) A non-interactive zero-knowledge proof generated by the sender of the record or transaction, generated using the algorithmic encoding type specified. (d) One or more data elements corresponding to outputs of the zero-knowledge algorithmic encoding. In an embodiment, if the record or transaction is deemed valid, one or more of said data elements will replace global state elements located at one or more accounts and / or addresses specified in the first field above. In various embodiments said data may be simple or complex; said data may be added to the global state in its original encoding or after having been transformed into a different encoding; said data may comprise deterministic data structures or other data representations. In an alternate embodiment, said data elements may comprise output of the of the zeroknowledge algorithmic encoding a confirmation that a data transformation encoded by the algorithmic encoding is executed correctly, which output data elements may including such possibilities as a Boolean value, an integer, or some other data element or elements. (e) One or more data elements corresponding to additional public inputs to the zero-knowledge algorithmic encoding. In an embodiment, said data elements may be deterministic data structures, and may be passed in as inputs to the algorithmic encoding either in an original state or after having been transformed into a different encoding format. In an embodiment, said input data elements may include data the formation of which results from a valid and successful data transformation encoded by the zero-knowledge algorithmic encoding. (f) One or more cryptographic signatures generated using one or more private keys corresponding to one or more public keys associated with the accounts and / or addresses specified in the first field above.

[00333] In one or more embodiments, the processing of zero-knowledge records and / or zero-knowledge transactions by block-building nodes comprises a procedure having one or more of the following steps: (a) It is confirmed that the one or more cryptographic signatures do in fact correspond to the appropriate accounts and / or addresses specified. (b) The state data structures that are stored at the given accounts and / or addresses within the global state are retrieved. (c) An encapsulating function is called, which function encapsulates the processing of the indicated algorithmic encoding, accepting as arguments the input data elements, the non-interactive zero-knowledge proof, the output data elements, and any record or transaction metadata that might be required for the processing of that particular algorithmic encoding—for instance, information regarding which addresses, accounts, or devices signed the record or transaction. Inside that function: i. The input data elements and output data elements are transformed into the format acceptable for the proof evaluation; ii. The proof inputs and outputs are assembled into the appropriate aggregate form for proof evaluation; iii. The proof s validity is determined, as informed by the inputs and outputs. (d) If the proof is invalid, the function outputs an indicator of that invalidity, potentially as an error code or other computational encoding of invalidity. (e) If the proof is valid, then the function outputs a mapping of the output data elements to one or more accounts and / or addresses within the global data structure, or to some constituent element of the state data corresponding to said one or more accounts and / or addresses. (f) If the proof is valid, the global data structure is updated, replacing the state data structures previously corresponding with by those account addresses with the deterministic data structures specified as output.

[00334] In an embodiment, the construction of each type of zero-knowledge algorithmic encoding, and the creation of each non-interactive zero-knowledge proof that is included with each zero-knowledge record and / or transaction, are particular to the type of transformation of the sate data structure which corresponds to that specific algorithmic encoding type.

[00335] In one or more possible embodiments of the present invention, a zero-knowledge token transfer procedure may be implemented comprising one or more of the following steps: (a) An algorithmic encoding may be implemented to accept as public input one or more state data structures of the sender and recipient accounts or addresses. The private input of the algorithmic encoding may be the details of the transfer: one or more token quantity values, and optionally one or more token types. The public output may be two new state data structures, corresponding to the blockchain accounts or addresses of each of the parties participating in the transfer. Alternately, said two new state data structures may also be among the public inputs to the algorithmic encoding, and the public output instead includes one or more indicators as to whether the transfer was successful, which indicators may comprise Boolean values, integer values, or other data elements. (b) The algorithmic encoding may perform the operation of generating a new sender state data structure wherein the sender’s balances of the indicated tokens are decreased by the indicated quantities, and a new recipient state data structure where the recipient’s balances of the indicated tokens are increased by the indicated quantities. (c) The wallet of the sender may execute this algorithmic encoding with the indicated inputs and capture the outputs and generate the non-interactive zeroknowledge proof. The wallet may then generate a zero-knowledge record comprising various data fields. (d) The zero-knowledge record is sent to the miner / validator network, and when it is successfully verified and included in a new block, one or more sender and recipient state data structures are replaced with one or more input and / or output data elements including in the zero-knowledge record.

[00336] One or more embodiments implement the preceding zero-knowledge token transfer process, but also include the interpretation of permissioning constraints within an algorithmic encoding, also referred to as zero-knowledge permissioning. This implementation requires that an interpreter of a permissioning constraint encoding be implemented as a zeroknowledge algorithmic encoding, or a portion, aspect or sub-routine of an algorithmic encoding within a larger algorithmic encoding.

[00337] In one or more embodiments, each expression of a permissioning constraint encoding corresponds to a particular zero-knowledge expression encoding, which zeroknowledge expression encoding comprises a particular zero-knowledge algorithmic encoding, or to a particular portion, aspect or sub-routine of an algorithmic encoding, which particular zero-knowledge algorithmic encoding, or particular portion, aspect or subroutine of an algorithmic encoding may be incorporated into a larger zero-knowledge algorithmic encoding. Each zero-knowledge expression encoding within the context of a larger noninteractive zero-knowledge proof system performs the operation that is encoded by its corresponding expression. An interpreter of permissioning constraint encodings implemented within a zero-knowledge algorithmic encoding comprises a number of zero-knowledge expression encodings which operate on a permissioning constraint as it is interpreted within the zero-knowledge algorithmic encoding. Non-limiting examples of possible expressions that may correspond to particular zero-knowledge expression encodings include Boolean equivalence expressions, inequalities, negations, data retrieval operations,

[00338] In an embodiment, such zero-knowledge expression encodings may avoid implementing any non-terminating operations, or operations that may not terminate depending on input data, and therefore said zero-knowledge expression encodings may avoid implementing such operations as loops, recursive functions, and / or variable assignments. Similarly, in an embodiment, a permissioning constraint interpreter implemented in a zeroknowledge algorithmic encoding may avoid implementing any non-terminating operations, or operations that may not terminate depending on input data, and therefore said permissioning constraint interpreter implemented in a zero-knowledge algorithmic encoding may avoid implementing such operations as loops, recursive functions, and / or variable assignments.

[00339] In an embodiment, such zero-knowledge expression encodings may exclude function declarations, definitions or implementations, such that only built-in functions are available for use within permissioning constraints. Any such built-in function in such a scenario should therefore correspond to a particular zero-knowledge expression encoding.

[00340] In an embodiment, functions that operate on lists may be capped in terms of the number of iterations they are permitted to undertake. Such functions when implemented as zero-knowledge expression encodings may or may not be implemented using looping logic, depending on the capabilities of the underlying zero-knowledge algorithmic encoding system or method.

[00341] Zero-Knowledge Privacy Ledgers

[00342] Known blockchain systems are known to make the value of tokens held by accounts and / or addresses public. If an account or address using such a blockchain system is identified as belonging to a particular person or business, the token balance information of that person or business becomes publicly known.

[00343] One or more potential embodiments of the present invention solve this problem by implementing privacy-enhancing zero-knowledge blockchain systems or methods comprising accounts which hide the value of tokens currently held by those accounts.

[00344] In one or more potential embodiments, a blockchain account or address may comprise a state data structure containing a masked privacy ledger. Said masked privacy ledger may comprise a hash digest which is a hash of an unmasked privacy ledger, which unmasked privacy leger comprises a deterministic data structure stored off-chain. Alternately, a masked privacy ledger may itself comprise a deterministic data structure comprising masked elements and unmasked elements, which masked elements comprise one or more hash digests of one or more data elements of an unmasked privacy ledger, and which unmasked elements comprise one or more data elements equivalent to one or more data elements of the unmasked privacy ledger, which unmasked privacy ledger comprises a deterministic data structure stored off-chain.

[00345] In one or more embodiments, said unmasked privacy ledger may comprise a Merkle tree or trie, herein referred to as an unmasked Merkle ledger. In one or more possible embodiments, the root of an unmasked Merkle ledger may constitute a hash digest of the masked privacy ledger. Alternately, the masked privacy ledger may comprise a masked Merkle ledger which is a Merkle tree or trie comprising a transformation of the unmasked Merkle ledger such that one or more branches or leaves of said unmasked Merkle ledger are replaced within the masked Merkle ledger by stub branches or leaves comprising individual hash digests of said branches or leaves.

[00346] In one or more embodiments, said masked Merkle ledger may be configured as a “privacy tree” comprising one or more of the following aspects: (a) In an embodiment, one or more nodes of a privacy tree may contain unhashed original data, which nodes may have one or more siblings which are stub branches or leaves that may act as expansion points of the privacy tree. (b) In an alternate embodiment, a privacy tree may exclude non-hashed original data, and may comprise only stub branches and leaves. One or more stub branches or leaves may each comprise a random or pseudo-random value. (c) In an embodiment, each node comprising non-hashed original data of the privacy tree may be accompanied by two or more stub branch siblings. In such an embodiment, when new content is added to the privacy tree, it is added in a balanced way, such that nodes at a tree depth of N+l are only added when all stub branches have already been replaced with new content at tree depth N. In other words, in such a configuration, it would only be permitted for new nodes to be added to the privacy tree in a manner that improves the tree’s balance; otherwise, such an addition would be invalid. (d) In an embodiment, only a user that owns or controls an account or address knows all the non-hashed original data of the unmasked Merkle ledger corresponding to a privacy tree constituting the privacy ledger of the account or address, but any valid private transaction moving tokens into the account may nonetheless add to the account. In such an embodiment, tokens may be transferred to said account or address in a blockchain record or transaction signed by the sender of said tokens, without requiring the signature of the recipient account or address. In an embodiment, a recipient account or address of such a transfer may use said tokens through the inclusion in the blockchain of a zero-knowledge record or transaction the zero-knowledge-proof of which comprises a transformation of the privacy tree to incorporate the received token values.

[00347] In an embodiment, a user that desires to receive a transfer from a sender may share all or a portion of their unmasked privacy ledger with the sender, which recipient’s unmasked privacy ledger may be included among the private inputs to a zero-knowledge algorithmic encoding of the zero-knowledge record or transaction. Such a zero-knowledge algorithmic encoding may be of a type that includes among its outputs masked private ledger data for both sender and receiver accounts, all of which may be updated in the global state upon inclusion of the valid record or transaction in the blockchain. In an embodiment, if the unmasked privacy ledger is an unmasked Merkle ledger, then only a Merkle proof inclusive of the node comprising the token balance being updated would need to be shared, because such data in combination with public global state data would be sufficient to generate an updated masked private ledger.

[00348] In an embodiment, rather than a recipient sharing all or a portion of their unmasked private ledger with a sender, a recipient may share nothing in advance. Instead, a zero-knowledge algorithmic encoding may accept among its public inputs a masked private ledger of the recipient, and include among its outputs an updated masked private ledger which will be used to update the masked private ledger on the recipient’s account. In an embodiment, the updated masked private ledger may incorporate token values received as a new unmasked element; in this embodiment, the amount transferred would public, even if the balances held by both parties are not. In an alternate embodiment, the zero-knowledge algorithmic encoding includes among its outputs one or more unmasked elements of the unmasked private ledger, in addition to the updated masked private ledger; said unmasked elements of the masked private ledger would not be incorporated in the blockchain’s global state, but instead would be transmitted privately to the recipient, to be stored privately by the recipient, and used subsequently by the recipient to retrieve said tokens received, or in an alternate embodiment, to effectuate the inclusion of the zero-knowledge record or transaction in the blockchain.

[00349] In one or more embodiments, a private zero-knowledge record or transaction may be configured as a zero-knowledge record or transaction comprising a zero knowledge proof generated using a privacy-preserving zero-knowledge algorithmic encoding, which is a zeroknowledge algorithmic encoding which includes among its private inputs the unmasked privacy ledger of one or more parties participating in the token transfer (as senders or recipients). In one or more embodiments, said privacy-preserving zero-knowledge algorithmic encoding may also include as private inputs the transfer details of the state transformation, including one or more of the following private inputs, among others: one or more token values being spent or transferred, one or more token types being spent or transferred, token configuration state data, and / or token permissioning constraints associated with one or more token types. Public inputs to said privacy-preserving zero-knowledge algorithmic encoding may include the state data structures corresponding to one or more of the accounts and / or addresses participating in the transfer. In an alternate embodiment, token type, token configuration, and / or token permissioning constraints associated with one or more tokens may instead be included among the public inputs to said privacy-preserving zeroknowledge algorithmic encoding, rather than the private inputs.

[00350] In one or more embodiments, a privacy-preserving zero-knowledge algorithmic encoding may extract one or more permissioning constraint encodings from one or more account or address state data structures or from one or more token configuration state data structures, and interpret said permissioning constraints to determine whether the transfer is permitted. Said privacy-preserving zero-knowledge algorithmic encoding may then compute the transfer instruction included in the private inputs by decrementing the value of said tokens in the unmasked privacy ledger of the sender. A new hash of the unmasked privacy ledger node from which the transfer is extracted would be generated, and that node would be updated in the masked privacy ledger, and relevant hash digests would be computed. In an embodiment, an indicator of which node of the unmasked privacy ledger is to be used to fund the transfer may be included in the private inputs.

[00351] In an embodiment, the output of a zero-knowledge algorithmic encoding comprises at least one updated masked privacy ledger derived from the unmasked privacy ledger after it has been updated within the zero-knowledge algorithmic encoding. Upon evaluation of a private zero-knowledge record or transaction, and upon verification of the validity of the zero-knowledge proof said record or transaction comprises, a block-building node may replace one or more masked ledgers of the global state with one or more updated masked ledgers output from the zero-knowledge algorithmic encoding.

[00352] In an alternate embodiment, one or more updated masked private ledgers are included among the public inputs of the zero-knowledge algorithmic encoding, which one or more updated masked private ledgers may be used by a block-building node to replace one or more masked private ledgers of the global state upon evaluation and successful validation of a private zero-knowledge record or transaction. In such an embodiment, the public output of the zero-knowledge algorithmic encoding may be a Boolean value, an integer, or some other data element or elements that result from a successful evaluation of the one or more masked private ledger inputs within the zero-knowledge algorithmic encoding, which evaluation establishes that said one or more masked private ledger public inputs are one or more valid transformations of one or more unmasked private ledger private inputs, as may be appropriate depending on the other inputs to said zero-knowledge algorithmic encoding.

[00353] In one or more embodiments, because token types and token values are included as part of the private data, the nature of a transfer encoded by a private zero-knowledge record or transaction will not be publicly known when the record or transaction is added to the chain.

[00354] In one or more alternate embodiments, the inclusion of token types and / or token configuration state data among the necessary public data reveals some information about which tokens were transferred. In an embodiment, however, type and state data pertaining to some unused additional token types may be added in order to obfuscate the question.

[00355] In one or more alternate embodiments, Token type information and token configuration state data may be included in the public data in order to simplify the evaluation of permissioning constraints. If token configuration state data and token type are public, then the permissioning constraints can be evaluated by the operation of the block-building node, rather than being interpreted within a zero-knowledge algorithmic encoding. Such an embodiment requires a less complex implementation than the alternative.

[00356] In one or more embodiments, private zero-knowledge records and / or transactions are not able to hide the fact that one or more accounts and / or addresses have transacted with each other, in part because the masked privacy ledger of one or more accounts and / or addresses should be updated upon acceptance, execution and inclusion of said private zeroknowledge records and / or transactions in the blockchain, which requires a global state of a public blockchain to be modified to reflect updated privacy ledgers of said one or more accounts and / or addresses.

[00357] In an embodiment, a recipient’s the privacy tree may add new nodes with every in-bound transfer; as a result, the size of the privacy tree may grow with every transfer into the account.

[00358] In an embodiment, a privacy tree may undergo a consolidation transformation in order to re-claim space. Such a consolidation transformation may comprise one or more of the following aspects: (a) A zero-knowledge algorithmic encoding may be defined which algorithmic encoding performs a consolidation of a privacy tree, or, alternatively, confirms that an updated masked privacy tree is a consolidated version of an original masked privacy tree. (b) A zero-knowledge record or transaction may be configured which corresponds to the consolidation algorithmic encoding, which zero-knowledge record and / or transaction, when it is properly formed with a valid zero-knowledge proof and is incorporated into a new block by a block-building node, effectuates a consolidation transformation of a privacy tree of an account or address of a blockchain global state. (c) A public input to the algorithmic encoding may comprise a masked privacy tree that is undergoing a consolidation. A private input to the algorithmic encoding may comprise the unmasked version of said unconsolidated privacy tree, with all the non-hashed content directly accessible. (d) A consolidated version of the unmasked privacy tree (unmasked consolidated privacy tree) may be included as a private input or a private output of the algorithmic encoding. A masked version of said consolidated privacy tree (masked consolidated privacy tree) may constitute a public input or public output of the algorithmic encoding. (e) The zero-knowledge algorithmic encoding may implement one or more of the following steps: i. confirm that the unmasked version of the privacy tree does in fact conform to the masked version of the privacy tree; ii. deterministically transform the unmasked version of the original privacy tree into an unmasked consolidated privacy tree (the consolidation transformation); iii. transform the unmasked consolidated privacy tree into a masked consolidated privacy tree (the masking transformation); iv. validate that the unmasked consolidated privacy tree is in fact the correct unmasked version of the privacy tree that is included among the private inputs or private outputs of the algorithmic encoding; and / or v. validate that the masked consolidated privacy tree is in fact the correct masked version of the privacy tree that is included among the private inputs and / or private outputs of the algorithmic encoding. (f) The consolidation transformation may comprise a combining of all nonhashed elements of an unmasked privacy tree pertaining to a particular token type (or other unit of value) into a single node of the privacy tree, for each token type or other units of value found in the privacy tree. Although individual transfers may result in real content nodes that comprise token ledgers containing only one token balance each, the consolidated node may potentially comprise a token ledger that contains multiple token balances; alternately, different nodes may each contain separate token balances or other units of value. (g) This algorithmic encoding may allow portions of the unmasked privacy tree to contain masked nodes. This may be necessary to allow for the consolidation of derived from private transfers that the account / address owner was never notified of. For the account / address owner to know the unmasked content of all of the real content nodes, it would need to have been informed by senders of unmasked data corresponding to the masked data added by the senders. This data, and any token balances or other value it may correspond to, would be inaccessible to (h) The consolidation transformation may also involve a step whereby data is discarded if the that the zero-knowledge record and / or transaction is configured to discard such data. Such discarded data may be either data present in the unmasked privacy tree in an non-hashed, unmasked state, and data that remains masked. The instructions to discard should somehow also be included in the private inputs of the circuit. Such tokens or values would effectively be destroyed.

[00359] Two-Phase Zero-Knowledge Transfers

[00360] According to a possible set of embodiments, a blockchain account or address may correspond to a privacy ledger the masked version of which is encoded in the global state only as a hash digest. The unmasked version of said privacy ledger, which may be stored off-chain, may comprise a Merkle tree or trie, or may comprise other less complex data, such as a simple string, or a deterministic data structure that is not a Merkle tree or trie.

[00361] In one or more embodiments, a transfer of tokens or other units of value from one privacy ledger to another privacy ledger would comprise a two-step process involving two zero-knowledge records and / or transactions. The first record or transaction authorizes the movement of tokens or other value units out of a sender’s privacy ledger, and the second record or transaction allows the movement of said tokens or value units into a recipient’s privacy ledger.

[00362] The sender zero-knowledge record may be added to the blockchain by the sender of tokens or other units of value. The sender zero-knowledge record includes inputs and outputs of a sender zero-knowledge algorithmic encoding which algorithmic encoding corresponds to a state transformation whereby the sender’s masked private ledger is transformed to an updated masked private ledger.

[00363] In an embodiment, the public inputs to the sender zero-knowledge algorithmic encoding may include an original masked private ledger extracted from a state data structure of a sender’s account or address. The private inputs may include transfer details, including type, configuration and quantity information regarding transferred token values or other units of value transferred, as well as an original unmasked private ledger of the sender, which original unmasked private ledger may be hashed within the recipient zero-knowledge algorithmic encoding to produce a hash digest equivalent to the original masked private ledger.

[00364] In an embodiment, an updated masked private ledger of the sender may be included as an input or as an output of the sender zero-knowledge algorithmic encoding. If the updated masked private ledger is included as an output, said algorithmic encoding will compute this output value first by transforming the sender’s original unmasked private ledger into an updated unmasked private ledger, and then by hashing said updated unmasked private ledger to produce a hash digest, which hash digest will form said output. If the updated masked private ledger is included as an input, said algorithmic encoding will first compute said hash digest, and then will compare said hash digest to the updated masked private ledger provided as input.

[00365] Similarly, in an embodiment, a transfer hash digest comprising a hash digest of the transfer’s token or unit of value type, configuration and / or quantity may also be included as an input or as an output of the sender zero-knowledge algorithmic encoding. If the transfer hash digest is included as an output, said algorithmic encoding will compute this output value by computing a hash digest of the transfer’s token / value type, configuration and / or quantity data included as a private input, which hash digest will form said output. If the transfer hash digest is included as an input, said algorithmic encoding will first compute a hash digest of the transfer’s token / value type, configuration and / or quantity data, and then will compare said hash digest to the transfer hash digest provided as input.

[00366] In an embodiment, said sender zero-knowledge record may be generated through a first zero-knowledge proving process by which a zero-knowledge proof is generated and incorporated into said recipient zero-knowledge record. Said zero-knowledge proof comprises a non-interactive zero knowledge proof which encodes a proof of one or more of the following data relationships: (a) the updated masked private ledger of the sender account or address is a hash digest computed by hashing the updated unmasked private ledger of the sender account or address; (b) the updated unmasked private ledger of the sender account or address is a transformation of the original unmasked private ledger, which transformation comprises a decrease in the quantity of the transferred tokens or value units specified in the private input; (c) the original masked private ledger of the sender account or address is a hash digest computed by hashing the original unmasked private ledger of the sender account or address; (d) transfer hash digest is a hash digest computed by hashing the transfer’s token / value type, configuration and / or quantity data included among the algorithmic encoding’s private inputs

[00367] In an embodiment, when an instance of said sender zero-knowledge record / transaction is evaluated, additional validation steps will be performed on said zeroknowledge record or transaction. Such validation steps may include, among others: a confirmation that a recipient account or address is encoded in the record or transaction; a confirmation that a sender’s account or address is encoded in the record or transaction; a confirmation that the original masked privacy ledger provided as an input to the sender zeroknowledge algorithmic encoding is a hash digest value equal to the hash digest value of the sender’s current masked privacy ledger referenced by the sender’s account or address stored in the global state. Only public inputs and outputs will be included with the record / transaction, and not any private inputs or outputs.

[00368] Upon said sender zero-knowledge record or transaction being validated successfully and incorporated into a block by a block-building node, said block-building node will cause the original masked privacy ledger of the sender to be replaced with the updated masked privacy ledger of the sender.

[00369] The recipient zero-knowledge record may be added to the blockchain after the sender zero-knowledge record is added to the blockchain. The recipient zero-knowledge record references the first transaction, and includes inputs and outputs of a recipient zeroknowledge algorithmic encoding which algorithmic encoding corresponds to a state transformation whereby the recipient’s original masked private ledger is transformed to an updated masked private ledger.

[00370] In an embodiment, the public inputs to the recipient zero-knowledge algorithmic encoding may include an original masked private ledger extracted from a state data structure of a recipient’s account or address. The private inputs may include transfer details, including type, configuration and quantity information regarding transferred token values or other units of value transferred, as well as an original unmasked private ledger of the recipient, which original unmasked private ledger may be hashed within the recipient zero-knowledge algorithmic encoding to produce a hash digest equivalent to the original masked private ledger.

[00371] In an embodiment, an updated masked private ledger of the recipient may be included as an input or as an output of the recipient zero-knowledge algorithmic encoding. If the updated masked private ledger is included as an output, said algorithmic encoding will compute this output value first by transforming the recipient’s original unmasked private ledger into an updated unmasked private ledger, and then by hashing said updated unmasked private ledger to produce a hash digest, which hash digest will form said output. If the updated masked private ledger is included as an input, said algorithmic encoding will first compute said hash digest, and then will compare said hash digest to the updated masked private ledger provided as input.

[00372] Similarly, in an embodiment, a transfer hash digest comprising a hash digest of the transfer’s token or unit of value type, configuration and / or quantity may also be included as an input or as an output of the recipient zero-knowledge algorithmic encoding. If the transfer hash digest is included as an output, said algorithmic encoding will compute this output value by computing a hash digest of the transfer’s token / value type, configuration and / or quantity data included as a private input, which hash digest will form said output. If the transfer hash digest is included as an input, said algorithmic encoding will first compute a hash digest of the transfer’s token / value type, configuration and / or quantity data, and then will compare said hash digest to the transfer hash digest provided as input.

[00373] In an embodiment, said recipient zero-knowledge record may be generated through a recipient zero-knowledge proving process by which a zero-knowledge proof is generated and incorporated into said recipient zero-knowledge record. Said zero-knowledge proof comprises a non-interactive zero knowledge proof which encodes a proof of one or more of the following data relationships: (a) the updated masked private ledger of the recipient’s account or address is a hash digest computed by hashing the updated unmasked private ledger of the recipient’s account or address; (b) the updated unmasked private ledger of the recipient’s account or address is a transformation of the original unmasked private ledger, which transformation comprises an increase in the quantity of the transferred tokens or value units specified in the private input; (c) the original masked private ledger of the recipient account or address is a hash digest computed by hashing the original unmasked private ledger of the recipient account or address; (d) transfer hash digest is a hash digest computed by hashing the transfer’s token / value type, configuration and / or quantity data included among the algorithmic encoding’s private inputs

[00374] In an embodiment, when an instance of said recipient zero-knowledge record / transaction is evaluated, additional validation steps will be performed on said zeroknowledge record or transaction. Such validation steps may include, among others: a confirmation that a reference to or identifier of a sender zero-knowledge record or transaction is encoded in the recipient zero-knowledge record or transaction; a confirmation that the a recipient account or address encoded in the referenced sender zero-knowledge record or transaction matches the account or address of the recipient; a confirmation that the original masked privacy ledger provided as an input to the recipient zero-knowledge algorithmic encoding is a hash digest value equal to the hash digest value of the recipient’s current masked privacy ledger referenced by the recipient’s account or address stored in the global state. Only public inputs and outputs will be included with the record / transaction, and not any private inputs or outputs.

[00375] Upon said recipient zero-knowledge record or transaction being validated successfully and incorporated into a block by a block-building node, said block-building node will cause the original masked privacy ledger of the recipient to be replaced with the updated masked privacy ledger of the recipient.

[00376] In an embodiment, the sender and the recipient may exchange information off-chain regarding the transaction, via one or more electronic or non-electronic means, which means may include (but are not limited to) messages transmitted over a packet-switched network, messages transmitted via analogue or digital radio transmission, messages transmitted via infrared signal, messages encoded as images scanned by an optical scanning device, magnetically-encoded media, messages conveyed by sound, and other communications media. Said information shared by the sender to the recipient may include one or more of the following: (a) One or all of the type, configuration and / or quantity of the token(s) or unit(s) of value that were transferred, hashed to produce the transfer hash digest; (b) A reference number or transaction number the sender may use to identify the zero-knowledge record or transaction; (c) The zero-knowledge record or transaction itself.

[00377] In an embodiment, a recipient may construct, assemble or encode a recipient zeroknowledge record or transaction by incorporating one or more information elements shared by the sender.

[00378] In an embodiment, a recipient zero-knowledge record or transaction may be added to the blockchain after a sender zero-knowledge record or transaction has already been added to the blockchain, or, optionally, the recipient zero-knowledge record or transaction may be added to the blockchain together with the sender zero-knowledge record or transaction, in combination in a manner that the second record or transaction executes immediately following the first record or transaction without any interruption, to be executed atomically in a single combined state transformation.

[00379] In an embodiment, said two-step process involving two zero-knowledge records and / or transactions may co-exist with other zero-knowledge record and / or transaction implementation described herein.

[00380] One or more of the embodiments described above may also include systems or methods of applying permissioning constraints to the process of generating and / or validating the zero-knowledge records or transactions described.

[00381] In one or more embodiments, a permissioning constraint may be executed and evaluated by a block-building node prior to validating the zero-knowledge proof and other elements of a zero-knowledge transaction or record. Said permissioning constraint may be associated, for instance, with a particular account or address, or with a particular token type, or other element of the global state which is implicated by the publicly-readable encoding of the zero-knowledge record or transaction being evaluated. In an embodiment, a permissioning constraint may evaluate whether, in a non-limiting example, a particular type of token or unit of value may be used or referenced somehow by a one or more zeroknowledge records or transactions, or, in another non-limiting example, whether a particular account or address may originate or be referenced by one or more zero-knowledge records or transactions.

[00382] In one or more embodiments, a permissioning constraint may be encoded in a manner that is interpretable executed and evaluated within a zero-knowledge algorithmic encoding associated with one or more zero-knowledge records or transactions, such that said permissioning constraint may operate on private non-public data of a zero-knowledge proof of the zero-knowledge record or transaction, and whereby said zero-knowledge proof may prove whether or not the permissioning constraint has been satisfied by the private and public data thereof.

[00383] In one or more possible embodiments described herein, the zero-knowledge algorithmic encodings used should not contain or implement any loops or recursions. A permissioning constraint interpreter may need to unroll any iterative function into a branching logic of fixed depth. In an embodiment, the number of iterations available for a permissioning constraint may be limited; alternately, the size of data structures upon which a permissioning constraint may operate may be limited so that iterations are only of a maximum length.

[00384] Consensus And Reorganization Risk

[00385] Various embodiments disclosed herein include improvements in blockchain systems related to the management and mitigation of risks presented by probabilistic blockchain consensus mechanisms, and the optimization of transaction processes through off-chain solutions, including as payment channels. Such details described herein provide means enhance the security, scalability, and efficiency of blockchain-based systems. Each described feature is optional, and various configurations or combinations of the described features may be implemented in various embodiments.

[00386] Blockchain networks rely on consensus protocols to validate and append new blocks of transactions to the blockchain. Such protocols may include such protocols as, for example, Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Fitness Gradient Consensus (FGC), and hybrid systems combining one or more of these mechanisms. In an example embodiment, protocols like PoW, PoS, FGC, and their variants, depending on the nature of the embodiment, may be susceptible to blockchain reorganization in the event of a network partition, as nodes may create divergent chains that require reconciliation once the partition is resolved.

[00387] This susceptibility to reorganization highlights the importance of transaction finality in blockchain systems. Transaction finality refers to the assurance that a transaction, once confirmed, is permanently included in the blockchain and cannot be altered or reversed. For example, in consensus protocols like PoW, PoS and FCG, finality is probabilistic, meaning that the certainty of a transaction being final increases as more blocks are appended after it. However, during events such as, for example, network partitions or attacks, these protocols may experience temporary chain divergences, leaving transactions vulnerable to reorganization.

[00388] Reorganization occurs when a blockchain replaces a previously accepted sequence of blocks with a new, longer chain, typically due to network partitions or competing forks. Transactions in the discarded blocks are not invalidated but may be delayed, reordered, or excluded from the new chain, creating uncertainty for users. A key risk is that a reorganized transaction may result in a double-spend, where the same tokens or funds are spent in conflicting transactions on different branches of the chain. This risk is particularly significant in off-chain scenarios, such as payments for goods or services, where recipients may act on a transaction before it is final. In such cases, a double-spend could leave recipients without payment, eroding trust in the blockchain’s reliability.

[00389] This highlights the importance of transaction finality, which is the point at which the probability of reorganization becomes negligible, ensuring that confirmed transactions are permanently recorded, such that transformations to the global state effectuated by said records and / or transactions cannot be altered or reversed.

[00390] One aspect of the embodiment addresses the risks posed by a blockchain reorganization generally, as well as the specific risk of a "51% attack," a vulnerability of some probabilistic consensus protocols, and a possible vulnerability of embodiments of the present invention that utilize such probabilistic consensus protocols. A 51% attack may occur when an entity or a coordinated group of entities gains control of the majority of a network's computational power or is able to harness new computational power greater than the computational power of the network. This majority control may enable the attacker to potentially rewrite blockchain history by reorganizing blocks already incorporated into the blockchain, thereby enabling actions such as the deletion of transactions. Note, however, that random reorganizations or those caused by network partitions pose similar if not the same risks to users as a 51% attack; furthermore, networks that are not susceptible to 51% attacks may nonetheless be susceptible to reorganizations under other circumstances. Regardless of the cause, a reorganization may delay, reorder, or exclude transactions, creating uncertainty and undermining trust in the blockchain. For users, the cause of the reorganization is irrelevant—the lack of finality impacts the system’s reliability and security.

[00391] The probability that a particular block will be reorganized out of existence—or that a 51% attack may succeed in effectuating a reorganization—diminishes with increasing block age and network size. Specifically, the amount of computational power that may be required to successfully execute such an attack increases for older blocks or for blockchains with larger mining networks. Thus, in embodiments involving larger blockchain networks, transactions embedded in older blocks may be less susceptible to reorganization.

[00392] FIG. 1 illustrates a comparison 100 of the relative risk of reorganization occurring for a smaller network 101 and a larger network 107, according to various example embodiments or implementations. It should be understood that the probability values depicted in FIG. 1 are provided purely for illustrative and exemplary purposes to demonstrate relative differences in attack vulnerability between smaller networks 101 and larger networks 107. The specific numerical values shown are exemplary only and actual networks may exhibit different probability values, where the probability represents that there will be a reorganization at the same depth if there is a fork, at different times. This probability recedes as you go deeper into the blockchain, where a higher depth corresponds to a greater age of a block. For blockchain networks that may be subject to reorganization, a payment channel network may provide finality as long as the timeclock of the payment channel is longer than the likely depth of a reorganization.

[00393] These payment channels provide a solution for the finality of payments. The smaller networks 101 may exhibit a difference in reorganization vulnerability depending on the recency of the network, in an example implementation. The recent small-network block 102 may experience a probability value of 40%, the less recent small-network block 103 may experience a probability value of 20% the aging small-network block 104 may experience a probability value of 10%, the older small-network block 105 may experience a probability value of 5%, and the oldest small-network block 106 may experience a probability value of 2%. The larger networks 107 may also exhibit a difference in reorganization vulnerability depending on the recency of the block. The recent large-network block 108 may experience a probability value of 20%, the less recent large-network block 109 may experience a probability value of 8% the aging large-network block 110 may experience a probability value of 3%, the older large-network block 111 may experience a probability value of 1%, and the oldest large-network block 112 may experience a probability value of 0.1%. A key principle illustrated is that larger networks 107 generally demonstrate lower reversal probabilities than smaller networks 101 for blocks of comparable age, and that reversal probabilities generally decrease as blocks age within both network sizes, i.e., as you go deeper. The anchor block solution is that the depth can be guaranteed through an anchor. The anchor blocks have a feature that makes it harder to reorganize. In an embodiment, the anchor block may get a fitness enhancement, for example through a formal mechanical aspect that enables issuers of tokens to have extra weight when creating a block, therefore making it less likely or impossible for a reorganization to occur past the depth where one or more of these blocks have been included in the blockchain. This is important for payment channels because even in the event of a reorganization, as long as the payment channels are longer than the probabilistic limit of the length of the reorganization's new fork, the payment channel may not be removed from the blockchain. Therefore, the payment channel provides a mechanism of finality provided that the timelock on the escrow contract is longer than the length or age of the fork. The anchor block decreases the probability of a fork at that block.

[00394] The nature of reorganization risk in certain embodiments is illustrated in diagram 100 of FIG. 1 discussed herein. Depending on the nature of the embodiment, reorganization risk may be described in the form of block reversal probabilities, which may vary based on multiple factors including, but not limited to, network size and block age. For example, in some embodiments involving smaller networks 101, newer blocks may face relatively higher reversal probabilities, which is shown in the diagram to be 40% 102 in some cases. In various embodiments, such probabilities may demonstrate progressive reduction with block age, shown in the diagram to decrease to 20% 103, then to 10% 104, then to 5% 105, and potentially reaching 2% 106 for older blocks.

[00395] Some embodiments involving larger networks 107 may demonstrate a similar pattern of probability reduction with block age while maintaining comparatively lower probabilities across all block ages. For instance, in the example illustrated by the diagram, newer blocks in larger networks may face reversal probabilities of 20% 108, with such probabilities potentially decreasing to 8% 109 for somewhat older blocks, then to 3% 110, then to 1% 111, and potentially reaching 0.1% 112 for the oldest blocks. In various embodiments, this pattern may demonstrate both the enhanced security of larger networks and the increasing security of older blocks.

[00396] Nonetheless, in various embodiments, a particular "certainty value" may be assigned to blocks, indicating the likelihood of their permanence based on the observed network size and mining power distribution. Depending on the embodiment, said certainty value may be purely conceptual, or it may be computed or evaluated heuristically by participating nodes, and used to make various decisions and / or to compute various conditionals in the course of the implementation’s operation.

[00397] Various embodiments of the present invention implement mitigation strategies to reduce the probability or the impact of reorganization. These modifications may reduce the time required for block confirmations and adjust computational power requirements to disincentivize majority control.

[00398] Finality Determination

[00399] In various embodiments, systems and methods may be provided for determining blockchain consensus finality through various computational frameworks. For example, some implementations may employ calculations to determine potential reorganization probabilities based measurements or estimates of network computational power, token ownership distribution among block-building nodes, age of token ownership distribution among such nodes, the performance of a random function, or another variable or set of variables the values of which are dependent on network makeup or network performance or on a stochastically or probabilistically determined metric related to said blockchain.

[00400] Certain embodiments may implement such certainty calculations with recognition that block reversal probabilities may vary based on multiple factors including, but not limited to, network size and block age. Such probabilities may demonstrate progressive reduction with block age in some embodiments. Such calculations may, in certain embodiments, enable assignment of certainty values to individual blocks, where such certainty values may represent likelihoods that specific blocks (inclusive of subsequent blocks) may be removed from the blockchain through a reorganization. In other variated embodiments, blockchain finality is determined according to a more simple heuristic, for example whether or not a block has reached a certain depth or age.

[00401] In certain embodiments, said probability frameworks may enable implementation of dynamic confirmation threshold systems. For example, some implementations may establish one or more certainty thresholds that may be achieved at varying times depending on network characteristics. Such timing variations may, in some embodiments, result in a block and its transactions being deemed final within broad timeframes, potentially ranging from a few seconds to up to or even more than an hour or several hours or more, with specific timing potentially being determined by network size and other relevant factors. Various embodiments may implement systems whereby records and / or transactions may be designated as "confirmed" upon their containing blocks achieving designated certainty thresholds, which records and / or transactions are designated as “pending” until it’s block is deemed final.

[00402] Some implementations may employ such confirmation frameworks to implement loss prevention systems. For example, certain embodiments may incorporate timing controls that maintain holds on various activities until relevant certainty thresholds are achieved. Such activities may include, but are not limited to, transmission of off-chain or external payment, initiation of shipping processes, execution of asset transfers, transmission of money-transfers, crediting of bank accounts, application of refunds, or activation of payment channels funded by on-chain transactions. Various embodiments may thereby provide protection mechanisms against potential losses that might otherwise occur during chain reorganization events. In some implementations, such protection mechanisms may be particularly relevant to high-value transactions that may require confirmation by one or more anchor blocks before being considered final.

[00403] In various embodiments, such confirmation and security frameworks may be integrated with other security mechanisms including, but not limited to, anchor blocks (204a-n, 300a-n discussed below in relation to FIGs. 2 and 3, respectively) and payment channels (See, FIG. 5 discussed below). Some implementations may enable these various security mechanisms to work in concert, potentially providing enhanced protection against the potential impacts of reorganization (such as double-spends) while maintaining efficient transaction processing capabilities. Certain embodiments may employ these integrated security approaches to balance transaction speed requirements with security needs, potentially enabling rapid processing of lower-risk transactions while maintaining heightened security measures for higher-risk transactions.

[00404] Anchor Block Backstop

[00405] Certain embodiments may employ “anchor blocks” as a means to reduce the likelihood, frequency, or impact of reorganizations. Such blocks may be periodically inserted into the blockchain, and thus act reduce the risk of reorganization of blocks preceding insertion point. The presence of anchor blocks within a blockchain restrict or reduce a maximum chain reorganization length, mitigating the risk of reorganization and of doublespend attacks. In various embodiments, anchor blocks may be validated and signed by a subset of block-building nodes explicitly designated as trusted.

[00406] In one or more embodiments, anchor blocks may act as backstops, limiting the possibility for blocks to be reorganized beyond a threshold block depth (distance from the most recent block). In one embodiment, anchor blocks may be spaced at regular intervals, and any proposed chain fork extending beyond a length of N blocks should include at least one anchor block at depth N or more recent to be accepted by the network. This approach effectively prevents malicious reorganization of the blockchain past the anchor block.

[00407] In various embodiments, the interval between anchor blocks may vary based on network parameters, such as the number of active miners and the total computational power of the network. Depending on the embodiment, in a smaller network, anchor blocks may occur, for example, as frequently as every few minutes or even multiple times in a minute, whereas in a larger network, intervals may range, for example, from days to weeks. In some embodiments, such intervals may be adjustable and configurable based on network requirements and desired security thresholds.

[00408] Certain embodiments may implement dynamic adjustment of the interval based on real-time network metrics. For example, some implementations may decrease the interval (thereby increasing anchor block frequency) if the network size decreases below certain thresholds, or increase the interval if the network grows beyond certain thresholds. Various embodiments may also consider additional factors such as network hash rate, mining difficulty, or various other metrics determinable the blockchain global state and / or on-chain data when determining appropriate intervals between anchor blocks.

[00409] In one or more embodiments, blockchain records and / or transactions achieve finality when the block containing said record or transaction is followed by a defined number of additional blocks, including one or more anchor blocks. This multi-block confirmation process ensures that transactions are secure against potential reorganizations. The inclusion of an anchor block may in some embodiments reduce reorganization risk to near zero.

[00410] FIG. 2 shows an illustration 200 of certain anchor block concepts, according to at least one example embodiment. Such anchor blocks 204a-n may, in certain implementations, be subject to additional validation requirements beyond standard consensus rules. For example, some embodiments may require that every Nth block be validated and signed by one of a limited set of trusted nodes. In certain embodiments, the system may be configured to avoid repetition in block-building responsibility among these trusted nodes, and / or it may be configured to permit said trusted nodes to compete among themselves to generate a new block. Double spends 201 may happen when forks emerge that are longer than expected. In one or more embodiments, anchor blocks 204a-n may provide an upper limit for the length of forks that may contain a double-spend attack. Unless 202 a fork is longer than length N is signed by at least one anchor node 204a-n, it that fork may not be accepted by the rest of the network. Double spends may be avoided 203 with greater certainty by not accepting a transaction’s finality until the block that contains it is built upon by a chain of length N.

[00411] Depending on the embodiment, the time interval between anchor blocks may be fixed, or it be configured to vary based on some on-chain metric, for instance total network computational power, the difficulty of an algorithmic problem being solved, the aggregate value of locked tokens, or the number of block-building nodes participating in the network, with smaller networks or networks achieving lower metrics benefiting from and configuring smaller intervals than larger networks or networks achieving higher metrics.

[00412] Various embodiments may employ said anchor blocks to reduce the risk or negative impact of a reorganization that may result from a blockchain fork. For example, in some embodiments, a fork of length greater than N may be rejected by the network unless it contains at least one authorized anchor node 202 at a depth less than N, or alternately at a depth less than N+l. In certain embodiments, a blockchain network may assign higher trust values to anchor blocks they create compared to blocks created by standard nodes. This trust differential may enable anchor blocks to function as secure backstops, potentially establishing hard upper limits on record and / or transaction confirmation time that may be independent of network size.

[00413] In one or more embodiments, anchor blocks may be produced through competitive processes rather than through direct selection. For example, some implementations may allow both trusted nodes and untrusted nodes to compete to produce a block at any given block height. Various embodiments may provide trusted nodes with certain probabilistic advantages in such competition. In some embodiments, for instance within a proof-of-work system, trusted nodes may be assigned lower difficulty targets to satisfy algorithmic requirements compared to untrusted nodes. Some embodiments may implement other probabilistic selection processes wherein trusted nodes may be given higher selection probabilities compared to untrusted nodes.

[00414] In certain embodiments, while trusted nodes may enjoy competitive advantages, such advantages may be probabilistic in nature and may not guarantee selection of trusted nodes' blocks. For example, some implementations operating with larger networks may still frequently select blocks produced by untrusted nodes despite the probabilistic advantage given to trusted nodes. Various embodiments may configure trusted nodes to compete with each other on equal footing. Some implementations may distribute unequal competitive advantages among trusted nodes according to one or more objectively-determined metrics.

[00415] In various embodiments, while anchor blocks produced by trusted nodes may serve particular security functions as described herein, the competitive block production process may continue to provide opportunities for untrusted nodes to contribute blocks to the chain, even if designated anchor block heights are specified by the embodiment. Some implementations may dynamically adjust the probabilistic advantages given to trusted nodes based on network conditions such as size, security requirements, or other metrics.

[00416] In contrast, in alternate embodiments, the anchor block mechanism may, provide a deterministic approach to transaction finality by ensuring that a valid fork should contain anchor blocks.

[00417] In one or more embodiments, trusted nodes may attempt to communicate with each other outside the public blockchain protocol, in order to detect if the blockchain fork they are connecting to is also subscribed-to by a minimum threshold of trusted nodes, or if the fork may be a minority fork, an isolated fork, or may otherwise be subject to reorganization in the future. In such an embodiment, a trusted node that finds itself out-ofsync with other trusted nodes may abstain from generating any anchor blocks, and any wallet node or interface node services or activities provided in conjunction with said trusted node may be paused until said trusted node synchronizes its version of the global state with the majority fork, connected fork, or whatever other fork is likely to persist due to the participation of other trusted nodes.

[00418] Payment Channel Networks, Structures And Processes

[00419] Embodiments described herein also contemplate the use of payment channels and payment channel networks to optimize transaction scalability, reduce fees, and enhance privacy. In one or more embodiments, payment channels operate as time-locked escrow contracts, enabling two parties to transact off-chain while potentially utilizing the blockchain only for the opening and closing of the channel.

[00420] Payment channel networks, such as the Bitcoin Lightning Network, offer substantial advantages over traditional on-chain blockchain payments by enabling faster, more cost-effective, and scalable transactions. These networks allow participants to conduct off-chain transfers, reducing congestion and transaction fees while maintaining the security of the underlying blockchain. By aggregating the value multiple payments into a single on-chain settlement, users minimize fees and optimize efficiency, particularly during periods of high blockchain activity.

[00421] A key benefit of these networks is near-instantaneous payment processing. Once a payment channel is established, value can be transferred without waiting for block confirmations, making payment channel networks ideal for applications such as retail payments, micropayments, and cross-border transfers. Additionally, payment channel networks enhance scalability by shifting many payments off-chain, potentially reducing record and / or transaction processing load of a blockchain, and increasing payment throughput of the overall system.

[00422] In one or more embodiments, payment channel networks may also provide enhanced resilience to blockchain reorganizations, which may occur, for example, in the context of a network partition, 51% attack or similar disruption. By facilitating payments off-chain, payment channels may reduce the exposure of individual payments to the risk of reversal or invalidation. In certain embodiments, only the opening and closing events of the channel are recorded on-chain, and these on-chain events may optionally incorporate additional protective mechanisms. In certain embodiments, such protective mechanisms may include anchor blocks and / or configurable confirmation delays, to further mitigate risks. This configuration allows one or more payment channels to avoid being disrupted by a blockchain reorganization, thereby reducing the likelihood of financial losses or service disruptions for participants.

[00423] Payment channels and payment channel networks also provide a significant advancement over traditional consumer payment networks, such as Visa and Mastercard, by enabling instantaneous or near-instantaneous settlement between the payer, merchant, and intermediaries. In a payment channel network, funds received can be immediately reused, even before being recorded back on the blockchain, allowing for real-time liquidity. Syncing the payment channel to the blockchain for final settlement incurs only minimal delay, ensuring rapid and seamless finalization.

[00424] Additionally, payment channels eliminate the risks of default and chargebacks that are present in traditional payment systems. Transactions within payment channels are cryptographically secured and finalized through mutually signed amendments, ensuring they are irrevocable and fraud-resistant. This design removes reliance on third-party arbitration, providing both payers and merchants with greater security, certainty, and efficiency compared to conventional payment networks.

[00425] Payment channels are created and controlled by signatures added to payment channel records and / or transactions, which signatures are generated by keys, which keys are associated with addresses or accounts. A signature signs a transaction to create an account, and a signature authorizes the various transactions that update the account.

[00426] Nodes within a payment channel network each control one or more blockchain addresses or accounts, which blockchain addresses or accounts provide the node with the ability to open channels with other nodes in the network, and exchange value within the network.

[00427] The lifecycle of a payment channel typically involves several key steps, beginning with opening the channel, where two parties contribute value to a shared escrow contract. This transaction is recorded on the blockchain as the opening transaction, establishing the initial state of the channel. During the off-chain transactions phase, the parties exchange payments privately through signed amendments that update the escrow balance without interacting with the blockchain. These amendments serve as a secure record of the transaction history, maintaining the confidentiality of individual payment details. To enhance efficiency and ensure synchronization with the blockchain, the payment channel supports periodic updates. These updates allow the current state of the channel to be recorded on the blockchain at predefined intervals or upon mutual agreement, ensuring consistency and reducing potential disputes, all without requiring the channel to be closed. Finally, in the closing phase, either party may submit the final amendment to the blockchain, prompting the escrow contract to distribute the remaining balances according to the latest agreed state, thereby concluding the channel's lifecycle.

[00428] FIG. 4 shows a payment channel network 400 illustrating the progress of a payment in a network, and how a payment is conveyed to a recipient from a sender, according to at least one example embodiment. Various embodiments may implement a decentralized payment channel network structure comprising multiple interconnected components. In some implementations, the network may include one or more block-building nodes 408 that validate and process on-chain transactions, such as channel opening and closing operations, while a plurality of payment channel nodes 403, 404, 405, 406, and 407 form the core of the off-chain payment routing infrastructure, including edge nodes 403 and 405, as well as interconnection nodes 404, 407, and 406. Each payment channel node may maintain multiple payment channels with other payment channel nodes, enabling the formation of diverse payment routes through the network while reducing on-chain transactions. The payment channel node with which a node has opened a payment channel is the channel partner of that node.

[00429] According to certain embodiments, end-user components may interface with the network through specialized access points. For example, sender wallet (payment channel wallet) nodes 401 may comprise user interface elements and cryptographic capabilities that enable users to initiate payments, but such wallet nodes may interact with the network exclusively through one or more edge nodes 403. Similarly, payment channel merchant or recipient interfaces 402 may comprise point-of-sale or payment acceptance wallet nodes or interface nodes which may connect through one or more separate edge nodes 405. This structure may create an architecture where wallet nodes and interface nodes connect to edge nodes, and interconnect nodes maintain interconnected payment channels with each other, while a plurality of these components exchange data and synchronize state with block building nodes 408, which update the global state by incorporating records and / or transactions generated by the other components of the system.

[00430] In some implementations, the relationships between components may be governed by specific rules and constraints. Payment channel nodes 403, 404, 405, 406 and 407 may establish and maintain off-chain payment channels with multiple peer payment channel, creating a plurality of possible payment routes, while also serving as access points for their associated wallets and merchant interfaces. Block-building nodes 408 may process and validate the on-chain transactions that secure these payment channels, including channel creation, closure, and dispute resolution operations, without being directly involved in individual payments. This architecture may enable high-throughput payment flows while maintaining security through a combination of off-chain efficiency and on-chain settlement guarantees.

[00431] According to various embodiments, a payment flow through a decentralized payment channel network 400 may be described. Said payment flow may be initiated when a merchant or other intended recipient desires to receive payment. In some implementations, the recipient's system may generate a unique secret confirmation code and establish a conditional payment route through the network, communicating this secret code to the prospective sender through a payment initiation message 409. This secret confirmation code may serve multiple purposes: it may prove payment completion, prevent intermediate nodes from claiming funds without recipient confirmation, and ensure atomic execution of the multi-hop payment.

[00432] In certain embodiments, the payment process may begin at a sender's wallet node 401. This wallet node 401 may maintain an exclusive relationship with a specific payment channel node 403, which may serve as the wallet's sole entry point into the payment channel network. One or more embodiments may require the wallet node 401 to operate as a captive system of its associated edge node 403, necessarily accepting the fee structures and operational parameters established by that edge node; alternate embodiments allow wallet nodes to connect to multiple edge nodes. The edge node 403, upon receiving a payment request from its associated wallet node 401, may begin orchestrating the payment's journey through the network.

[00433] Various embodiments may implement various routing mechanisms as the payment propagates through the network of payment channel nodes 403, 404, 405, 406, and 407. Payment channel nodes may maintain fee schedules for routing services, and the network may employ pathfinding algorithms to identify optimal routes. These algorithms may consider multiple factors, including but not limited to: aggregate routing fees across each potential path, available channel liquidity, channel reliability metrics, and historical performance data. The system may dynamically adjust routes based on real-time network conditions and may maintain alternative routes as contingencies.

[00434] In certain embodiments, the sender 401 and recipient 402 may operate using different tokens, currencies, or other units of value, requiring currency conversion or token exchange as part of the payment flow. Some implementations may enable payment channel nodes 403, 404, 405, 406, and 407 to maintain current exchange rate information and offer different conversion rates for various token pairs or currency pairs. The pathfinding algorithms may incorporate these exchange rates alongside routing fees to optimize various payment parameters according to configured preferences. For example, some embodiments may optimize routes to maximize the value received by the recipient 402 by identifying paths with favorable combinations of exchange rates and routing fees. Other implementations may optimize to minimize the amount the sender 401 should pay to deliver a specified value to the recipient 402. Various embodiments may enable participants to specify their optimization preferences, such as fastest settlement time, lowest aggregate fees, best exchange rates, or weighted combinations thereof. The system may calculate optimal routes that satisfy these preferences while accounting for the available liquidity in each candidate payment channel and the various exchange rates and fees offered by each payment channel node 403, 404, 405, 406, and 407 along potential paths.

[00435] In certain embodiments, the payment channel nodes 403, 404, 405, 406, and 407 may implement a staged settlement protocol that ensures payment security and atomicity. Each payment channel node's channel update may be conditional upon successful completion of all subsequent hops, with the secret confirmation code serving as proof of completion. This staging mechanism may protect against partial payments, ensure that routing nodes cannot lose funds due to downstream payment failures, and maintain the atomic nature of the overall transaction.

[00436] According to some implementations, each hop in the payment route may establish conditional payment commitments that are secured by cryptographic hashes of the secret confirmation code. When the payment reaches the recipient's payment channel node 405, the recipient 402 may verify the incoming payment details and reveal the secret code to claim the funds. This revelation of the secret confirmation code may trigger a cascade of settlement operations, propagating backward through the payment route. Each participating payment channel node 405, 404, and 403 may validate the secret code, settle its incoming payment channel, and reveal the secret to its predecessor in the route, creating an atomic chain of settlements that either completes fully or fails completely.

[00437] Various implementations may employ timeouts and fallback mechanisms at each hop to handle potential failures or delays. If the recipient 402 fails to reveal the secret confirmation code within a specified timeframe, or if any intermediate node becomes unresponsive, the conditional payments may automatically cancel, releasing reserved funds and allowing nodes to attempt alternate routes. This timeout mechanism may work in conjunction with the routing system to ensure reliable payment delivery while protecting participants from locked funds or incomplete transfers.

[00438] In certain embodiments of a payment channel network, said secret confirmation code comprises a hash pre-image of a cryptographic hash function (the pre-image), which is initially shared by the sender wallet node with the recipient wallet node or interface node in a direct communication, and which in the final stage may be propagated from the recipient wallet node or interface node 402 back to the original sender, facilitating the settlement of the payment across the network of payment channels.

[00439] In various embodiments, a payment channel network payment relies on Hash Time-Locked Contracts (HTLCs), which may require the recipient of a payment to reveal the pre-image in order to claim funds. The pre-image is a piece of data that satisfies the hash condition and unlocks the payment, as per the mechanism of the HTLC. When the ultimate receiver of the payment claims the funds associated with the HTLC, the receiver wallet node or interface node may share the pre-image with their edge node, which will in turn share it with its direct channel partner, in at least one embodiment by signing and sharing an updated payment channel record or transaction that includes the pre-image and resolved HTLC. The channel partner may then reclaim their portion of the payment from the next channel in the chain, by in turn revealing the pre-image to their next channel partner in the chain, in an embodiment by signing and sharing an updated payment channel record or transaction that includes the pre-image and resolved HTLC. The propagation of the pre-image continues in a reverse sequence, with each channel partner updating their respective channel state and exchanging new transactions with their counterparty to reflect the settled HTLC.

[00440] As the pre-image propagates back toward the original sender, each intermediate channel updates its local state, reducing the locked HTLC funds and restoring available liquidity. This process ensures that each intermediary receives their portion of the payment, covering the amount they forwarded plus any fees they are entitled to for routing the payment. The final settlement results in updated channel balances for all participating nodes, ensuring that the payment is securely and efficiently processed end-to-end.

[00441] In certain embodiments, if the pre-image required to resolve HTLC is not shared, the payment cannot be settled, and the locked funds remain inaccessible until the contract expires, effectively nullifying or voiding the payment. This may occur if the recipient chooses not to claim the payment, communication fails, or the network is disrupted. The system enforces atomicity, ensuring incomplete payments do not affect channel balances, and participants can take corrective actions if needed.

[00442] In various embodiments, this propagation mechanism enables trustless, atomic multi-hop payments. It ensures that funds are only released when the ultimate receiver claims the payment and provides the required pre-image, preventing any intermediate node from being at risk of loss. This process is non-limiting and may vary in specific implementations, as alternative methods of propagating the pre-image or resolving HTLCs could be employed while maintaining the principles of atomicity, security, and decentralization.

[00443] FIG. 5 shows a diagram 500 illustrating that in various embodiments, the individual payment channels established between nodes (i.e. between channel partners) are implemented as a payment channel structure 500 which may be established through a sequence of defined steps and states. Initially, during a channel establishment phase, two participating nodes may contribute funds to an escrow contract 501 that may be recorded on a blockchain network 502 for processing. This initial escrow contract may establish starting parameters including, but not limited to, initial value allocations, time lock parameters, and penalty conditions.

[00444] Some embodiments may maintain two sets of reciprocal amendments to the initial payment channel escrow contract, wherein a first set of contract amendments 508 may be stored off-chain in a first channel partner’s node 509, while a mirrored set of contract amendments 506 may be maintained at a second channel partner’s node 505. Each reciprocal amendment may already be signed by one channel partner node and sent to the other channel partner node, such that either node may close and settle the escrow contract by cryptographically signing and submitting to the blockchain network the amendment shared by its counterparty 502. In at least one implementation, said contract amendments (508, 506) may be implemented as zero-knowledge payment channel records.

[00445] In certain embodiments, while the payment channel remains open, parties may exchange payments 507 through the transfer of signed reciprocal amendments to the escrow contract. These amendments may update the escrow balance to reflect the value that has been transferred. Each time a new set of reciprocal amendments is generated, prior amendments representing old escrow states may be discarded and replaced. The block-building node 502 may ultimately process these amendments during channel closing events, or, alternately, on-chain updates to the channel that do not close the channel. However, in various embodiments, all or most amendments are held off-chain while the payment channel stays open.

[00446] Various embodiments may protect against fraudulent submissions through a "token penalty" mechanism, which token penalty may be imposed by the application of a “revocation key”. If a cheating channel partner attempts to submit an outdated amendment through the blockchain network 502, the counterparty channel partner may write the revocation key to the blockchain, causing the revocation penalty to be paid to the counterparty channel partner at the expense of the cheating channel partner. This penalty mechanism may be enforced through time-locked amendments that prevent immediate settlement, providing time for a penalty record or transaction to be incorporated into the blockchain.

[00447] Some embodiments may implement settlement procedures wherein either party's node 505, 509 may initiate channel closure 504 by submitting a final contract state in the form of a final update or closing payment channel record or transaction 503 to the blockchain network 502. To enable penalty enforcement, the escrow may remain frozen during a lock period to give counterparties time to submit penalty keys if outdated amendments are broadcast.

[00448] In certain implementations, every time new amendments are exchanged between the channel partner’s nodes 505, 709, revocation keys pertaining to the previous generation of amendments may also be exchanged, effectively invalidating those prior amendments and rendering them worthless if submitted to the blockchain network 502.

[00449] Various embodiments may enable the channel to remain open indefinitely, with the first channel partner node 509 and second channel partner node 505 continuing to exchange payments and amendments 507 with only the opening payment channels being incorporated into the blockchain through the block-building node 502, with a closing payment channel record being held off-chain until the point that the channel is closed. In alternate embodiments, a payment channel may remain open indefinitely, but an update payment channel record or transaction may be periodically added to the blockchain periodically; such a record may act as the equivalent of a close payment channel record or transaction immediately followed by an open payment channel record between the same channel partners.

[00450] FIG. 6 shows a diagram 600 illustrating a payment channel lifecycle demonstrating how two channel partners may conduct multiple value transfers while maintaining only two on-chain transactions, according to an embodiment. During channel establishment, depicted in element 601, a first channel partner and a second channel partner may each commit value to a shared escrow contract, with the first channel partner making $300 available in its unspent portion and the second channel partner maintaining $300 in its reserve portion, in the example shown. This establishment may be recorded as a single on-chain transaction creating a cryptographically secure escrow.

[00451] In accordance with some embodiments, following establishment, the first channel partner may initiate a payment of $100 to the second channel partner as depicted 602. To effectuate this payment, the channel partners may exchange cryptographically signed state update or closing payment channel records or transactions that reflect adjusted channel balances. Through this exchange of reciprocal records, the first channel partner’s available portion may be decremented by the value spent (depicted as $100 in the example shown) while the second channel partner’s escrow amount may be incremented by the same amount. This modification of escrow balances may be maintained off-chain between the parties, avoiding the need to synchronize with the blockchain.

[00452] Subsequently, in some embodiments, value may shift from one channel partner to the other in response to an external payment 603. In the example shown, after the first channel partner transfers $300 to the second channel partner through a separate off-chain payment, the parties exchange updated payment channel records or transactions reflecting an increase in the first channel partner’s escrow balance by $300, and a decrease in the second channel partner’s escrow balance by an equivalent amount. An embodiment implementing such a method of modifying channel balances following an external provides a means for external funds to be added to a channel partner’s account.

[00453] In accordance with some embodiments, as depicted in element 604, the first party may conduct multiple sequential payments through the second party. As the first party depletes their available funds, the state updates may continuously adjust the balance allocation between the parties, with each update superseding all previous states.

[00454] When all desired transfers are complete, in some embodiments, either party may initiate channel closure by broadcasting the most recent valid state to the blockchain. This settlement, representing only the second on-chain transaction in the channel's lifecycle, may distribute the escrowed funds according to the final agreed-upon allocation. Through this mechanism, the payment channel may enable an unlimited number of value transfers while requiring only two on-chain transactions - one for opening and one for closing.

[00455] It should be understood that while specific currency amounts are shown in FIG. 6 600, these values are exemplary only. Actual implementations may support any denomination of value compatible with the underlying blockchain system, bounded only by the initial channel capacity established during funding. The illustrated amounts serve primarily to demonstrate the relative relationships between sequential channel states and the preservation of total value across all state transformations.

[00456] Payment Channels And Reorganizations

[00457] Payment channels may, in various embodiments, provide enhanced protection against blockchain reorganization through multiple coordinated timing mechanisms. In some implementations, initial protection may be achieved by requiring that no payments be processed across a payment channel until some margin of time after the on-chain transaction that opened the payment channel achieves finality (in whatever manner finality might be determined for said embodiments). After such point, subsequent payments across that payment channel may be considered to have to have immediate effective finality, effectively eliminating reorganization risk for those in-channel transactions.

[00458] The specific nature of finality for certain such embodiments is important, however. Further protection may, in some implementations...

Claims

1. A computer-implemented blockchain system comprising:a global state and an assemblage of blocks, each block representing a collection of state transformation records, each state transformation record describing a state transformation performed on the global state, each block referencing one or more preceding blocks;wherein preceding blocks referenced by any given block contain state transformation records describing state transformations performed on the global state prior to the evaluation of the given block; andwherein at least one state transformation record is a zero-knowledge transformation record encoding a zero-knowledge state transformation description, which zero-knowledge transformation record comprises:one or more addresses or paths identifying or referencing the one or more locations of the elements of a discrete data subset within the global state, wherein discrete data subset comprises either a contiguous subset or a noncontiguous subset of the data comprised by the global state;a revised discrete data subset, representing a new revised version of at least a portion of or subset of the discrete data subset; anda transition proof implemented as a non-interactive zero-knowledge proof, wherein the transition proof proves that the transition from the discrete data subset to the revised data subset follows the established rules of the blockchain system.

2. The system of Claim 1, wherein the zero-knowledge transformation record comprises at least one of:the discrete data subset; andone or more cryptographic hashes of one or more elements of the discrete data subset.

3. The system of Claim 1, wherein the transition proof corresponds to one of a set of pre-defined transition types for which corresponding non-interactive zero-knowledge proofs may be generated.

4. The system of Claim 3, wherein each pre-defined transition type corresponds to an encoded state-transition implementation encoded as an algorithmic encoding;wherein the algorithmic encoding comprises one or more of an algebraic circuit, a virtual algebraic circuit, an algebraic intermediary representation, or other algebraic encoding or algorithmic encoding.

5. The system of Claim 4, where the encoded state-transition implementation receives input data, and generates output data, wherein a portion of the input data is private input data, and the remainder of the input data is public input data.

6. The system of Claim 5, wherein the public input data comprises the discrete data subset.

7. The system of Claim 5, wherein the output of the encoded state-transition implementation comprises the revised data subset.

8. The system of Claim 4, wherein the transition proof is generated by a process, said process comprising:a compilation process where the algorithmic encoding is compiled into a set of polynomial equations; andan evaluation of the polynomical equations at one or more random points, producing values that are included in the transition proof.

9. The system of Claim 8, wherein the transition proof is implemented as a zeroknowledge succinct non-interactive argument of knowledge (zk-SNARK).

10. The system of Claim 8, wherein the transition proof is implemented as a zeroknowledge succinct transparent argument of knowledge (zk-STARK).

11. The system of Claim 1, further comprising an issuer of a currency denominated token configured to hold a reserve for every corresponding unit of currency denominated tokens issued by the issuer.

12. The system of Claim 1, further comprising a token issued by a token issuer to a plurality of users, the token issuer configured to: (i) approve use of the token to at least a subset of the plurality of users, and (ii) disapprove use of the token to at least a second subset of the plurality of users.

13. The system of Claim 12, further comprising a decision indicator configured to mark at least a user of the plurality of users as approved, wherein only approved users may have access to a payment channel on the blockchain.

14. The system of Claim 13, wherein the decision indicator is a user account.

15. The system of Claim 13, further comprising the decision indicator being associatedwith an edge node on the blockchain, the decision indicator further configured to indicate that an account belongs to an edge node or an interconnection node.

16. The system of Claim 12, where the token is configured with a permissioning constraint configured to permit a first interconnection account to open a payment channel with a second interconnection account, wherein the payment channel is opened by at least the first account and the second account, and wherein at least one permission constraint prohibits the payment channel transactions or records that are signed by the first account but do not reference the second account.

17. The system of Claim 1, further comprising using a first cryptographic key for sending payments across a payment channel network, and a second cryptographic key for receiving payments across the payment channel network.

18. The system of Claim 17, wherein the first cryptographic key:comprises a restriction disallowing funds to be removed from a wallet of a user; andsigns data elements sent during the receipt of payment.

19. The system of Claim 17, further configured to:generate, by a user, an alternative pair of cryptographic keys;provide the alternative pair of cryptographic keys to a persistent server;associate an account with at least one permissioning constraint configured to restrict the use of the alternative pair of cryptographic keys such that the pair of cryptographic keys may only be used to sign payment channel records or transactions that update payment channels in such a manner that the user’s payment channel balance increases compared to the previous channel state.

20. The system of Claim 17, further comprising one or more permissioning constraints configured to determine whether one or more cryptographic keys are permitted to authorize a payment channel record or transaction.

21. The system of Claim 17, wherein any payment negotiated using a cryptographic key is in the direction of the user.

22. The system of Claim 1, wherein the blockchain is further configured to open, close, and update payment channels on-chain through zero-knowledge payment channel records or transactions.

23. The system of Claim 22, wherein an account on the blockchain is configured with one or more private ledgers represented in a blockchain global state by one or more cryptographic hash digests.

24. The system of Claim 22, further comprising an open payment channel configured on the blockchain with a channel private ledger, wherein the channel private ledger is configured to encode a token balance of at least two participants within the payment channel.

25. The system of Claim 22, further comprising implementing a zero-knowledge algorithmic encoding corresponding to a pre-defined type of global state information.

26. The system of Claim 1, further comprising:an expression of a permission constraint encoding corresponding to a zeroknowledge expression encoding, wherein zero-knowledge expression encoding comprises a zero-knowledge algorithmic encoding;each zero-knowledge expression encoding configured to perform an operation that is encoded by its corresponding expression.

27. The system of Claim 1, further comprising at least one anchor block configured to limit the reorganization of blocks beyond a threshold block depth.

28. The system of Claim 27, wherein the anchor block further configured to be spaced at regular intervals.

29. A computer-implemented method as in Claim 1 for validating and accepting zeroknowledge transformation records, comprising:a validating computer configured to store the blockchain’s global state in a retrievable storage medium;a wallet computer connected to the validating computer via a computer network, the wallet computer generating a new zero-knowledge transformation record; andthe validating computer receiving the zero-knowledge transformation record from the wallet computer, and subsequently performing validation of the zeroknowledge transformation record, said validation comprising:the validating node retrieving a retrieved data subset from the global state, which subset of global state data corresponds to the discrete data subset referenced or included in the zero-knowledge transformation record;the validating node verifying that the discrete data subset included in the zero-knowledge transformation record or referenced by the zeroknowledge transformation record is equivalent to the retrieved data subset;the validating node verifying that the non-interactive zero-knowledge proof is valid when verified combination with the discrete data subset (or retrieved data subset) and revised data subset—and possibly in combination additional Public Input Data included with the zero-knowledge record in certain cases;in the case that the non-interactive zero-knowledge proof is successfully verified and the zero-knowledge transformation record is deemed valid, the validating node replacing some portion of the discrete data subset with elements of the revised data subset, where the portion of the discrete data subset that is replaced by elements of the revised data subset is decided according to which pre-defined transition type the non-interactive zeroknowledge proof corresponds to.

30. The system or method of any of the preceding claims in which the discrete data subset comprises at least one permission encoding, which permission encoding either is itself interpretable by the encoded state-transition implementation, or is transformed into an equivalent format interpretable by the encoded state-transition implementation.

31. The system or method of any of the preceding claims in which the permission encoding, or a transformation thereof, is interpreted or evaluated within the encoded state-transition Implementation.

32. The system or method of any of the preceding claims in which a state transformation corresponding to the encoded state-transition implementation is undertaken only if the permission encoding is interpreted or evaluated with a result indicating that said state transformation is permitted.

33. The system or method of any of the preceding claims in which the permission encoding comprises a logical function encoded as interpretable or executable computer code.

34. The system or method of any of the preceding claims in which the logical function is configured to accept one or more permission inputs and the logical function is configured to output a permission output.

35. The system or method of any of the preceding claims in which the permission output corresponds to either a permitted transition status or a not-permitted transition status, given the one or more permission inputs;whereby the state transformation corresponding to the encoded state-transition implementation is undertaken only in cases where the permission output given the one or more permission inputs corresponds to the permitted transition status, and the state transformation is not undertaken in cases where the permission output given the one or more permission inputs corresponds to the non-permitted transition status.

36. The system or method of any of the preceding claims where the one or more permission inputs comprise a subset of the public input data and private input data received by the encoded state-transition implementation.

37. The system or method of any of the preceding claims where the logical function, or a transformation thereof into an equivalent format interpretable by the algorithmic encoding, is interpreted or executed within the algorithmic encoding.

38. The system or method of any of the preceding claims in which the non-interactive zero knowledge proof is deemed valid only in the case where the logical functionoutputs a value corresponding to the permitted transition status within the algorithmic encoding.

39. The system or method of any of the preceding claims in which the permission encoding comprises a pattern encoding, where the state transformation corresponding to the encoded state transformation implementation is permitted only in the case that the pattern encoding matches at least a portion of the private input data, or a portion of the public input data, or a combination thereof.

40. The system or method of any of the preceding claims where the pattern encoding, or a transformation thereof into an equivalent format interpretable by the algorithmic encoding, is compared to a portion of the input data received by the algorithmic encoding, within the algorithmic encoding itself, and in which the transition proof is verified successfully only in the case where the pattern encoding matches said input data within the algorithmic encoding.

41. The system or method of any of the preceding claims in which the discrete data subset comprises one or more account records, each account record including one or more private ledgers, each private ledger comprising at least one cryptographic hash digest the preimage of which is an unmasked private ledger, which at least one unmasked private ledger contains one or more token balances.

42. The system or method of any of the preceding claims where the at least one unmasked private ledger is implemented as a Hash Tree or Merkle Tree, where the root of the tree corresponds to the private ledger’s cryptographic hash digest.

43. The system or method of any of the preceding claims where the at least one unmasked private ledger is implemented as a Merkle Trie or Merkle Patricia Trie, where the root of the trie corresponds to the private ledger’s cryptographic hash digest.

44. The system or method of any of the preceding claims where the at least one unmasked private ledger is implemented as a Merkle Proof or partial Merkle Tree or partial Merkle Patricia Trie, and where the root of the proof, tree or trie corresponds to the private ledger’s cryptographic hash digest.

45. The system or method of any of the preceding claims where the private input data comprises the at least one unmasked private ledger, which at least one unmasked private ledger is excluded from the discrete data subset and from the public input data; and where the private input data also comprises information regarding at least one quantity of tokens.

46. The system or method of any of the preceding claims where the encoded state transformation implementation comprises a private state transformation, comprising: the encoded state transformation implementation computing at least one derived hash, which derived hash is the cryptographic hash of the at least one unmasked private ledger;the encoded state transformation implementation determining that such at least one derived hash equals the at least one cryptographic hash digest of the private ledger which corresponds to that at least one unmasked private ledger;the encoded state transformation implementation modifying the unmasked private ledger in a manner consistent with the token quantity information included in the private input data;the encoded state transformation implementation computing a revised cryptographic hash digest of the modified unmasked private ledger, which revised cryptographic hash digest corresponds to the output of the encoded state transformation implementation.

47. The system or method of any of the preceding claims where the private state transformation also comprises a process whereby at least one permission encoding included in the public input data is evaluated in combination with a portion of the input data received by the encoded state transformation implementation, whereby the state transformation corresponding to the encoded state transformation implementation is only undertaken if the permission encoding is interpreted or evaluated in a manner indicating that said state transformation is permitted.

48. The system or method of any of the preceding claims in which a zero-knowledge transformation record is accepted and included in the blockchain only in the case where one or more permission encodings included in the record’s discrete data subset are interpreted or evaluated in a manner indicating that the state transformation corresponding to the zero-knowledge transformation record is permitted.

49. The system or method of any of the preceding claims where the validating computer replaces at least one cryptographic hash digest of the one or more account record’s one or more private ledgers in the global state with the revised cryptographic hash digest, in the event that the zero-knowledge transformation record is accepted and included in the blockchain.

50. A computer implemented method of updating data of a blockchain divided into a plurality of shards, comprising:assigning a mining node to a shard of the blockchain;at the mining node:generating a candidate block representing transactions involving accounts associated with the shard; andtransmitting the candidate block to a peer node assigned to the shard; andat the peer node:selecting among the candidate block and a plurality of other candidate blocks for inclusion in a respective one of a plurality of block sequences, the selection being based on a fitness value of the candidate;developing the plurality of block sequences by generating subsequent blocks in each of the plurality of block sequences;selectively discarding a subset of the plurality of block sequences in response to detecting an invalid process within the block sequence; andupdating the shard to include at least one of the plurality of block sequences.

51. The method of Claim 32, further comprising assigning the mining node to at least two shards of the blockchain including the shard, an account associated with the mining node being included in one of the at least two shards.

52. The method of Claim 32, wherein generating the candidate block includes generating a bloom filter indicating all of the accounts with which the mining node has interacted.

53. The method of Claim 32, further comprising preventing the mining node from mining transactions involving accounts that are not included in the shards assigned to the mining node.

54. The method of Claim 32, wherein generating the candidate block includes generating a candidate block header that indicates a quantity of fuel tokens.

55. The method of Claim 36, further comprising determining whether the candidate block header is valid based on whether the quantity of fuel tokens exceeds a quantity of fuel tokens held by an account associated with the mining node.

56. The method of Claim 32, further comprising performing a fraud analysis of the plurality of block sequences, wherein detecting the invalid process is based on the fraud analysis.

57. A computer-implemented blockchain sharding system, the system comprising a global state and at least two block-building nodes, wherein the global state comprises at least four shards;each shard comprising a mutually exclusive portion of the global state;each block building node configured to store global state data comprising at least two shards; andat least one of the at least two block building nodes configured to store global data excluding at least two shards.

58. The system of Claim 57, the system further configured to:implement a consensus procedure, wherein the consensus procedure is performed in sequential rounds;wherein each new block built belongs to a single round, and operates on at least two shards of the global state; andwherein each round comprises one or more new blocks operating on nonoverlapping mutually exclusive shards of the global state.

59. The system of Claim 57, wherein each new block comprises a block hash of one or more preceding blocks of the preceding round, the block has configured to reference a preceding block operating on at least one of the same shards as the new block.

60. A computer-implemented blockchain sharding system, the system comprising a global state and two or more block building nodes.

61. The system of Claim 60, further comprising:the global state comprising at least three shards;wherein each shard comprises a mutually exclusive portion of the global state;wherein each block-building node is configured to store global data, excluding at least one shard.

62. The system of Claim 60, wherein the system is configured to:implement a consensus procedure performed in sequential rounds;wherein each new block built belongs to a specific round, operating on at least one shard of the global state; andwherein each round comprises one or more new blocks operating on nonoverlapping mutually exclusive shards of the global state.

63. The system of Claim 60, wherein each new block comprises a block hash of one or more preceding blocks of the preceding round, the block hash configured to reference a preceding block operating on at least one of the same shards as the new block.

64. A computer-implemented method in 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-linked interconnected blocks, arranged as one or more instances of linear blockchain data structures, non-linear block arrangements, n-dimensional mesh or lattice 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;configuring 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;configuring the 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 configuring 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.

65. A system for securing ownership of tokens, cryptocurrency, or other assets held or tracked on a blockchain by using cryptographic key pairs to sign one or more records, the system comprising:at least one blockchain account having one or more cryptographic key pairs, andwherein at least one of the one or more records is configured to encode one or more transformations to a global state maintained by the blockchain.

66. The computer-implemented method of Claim 64 or 65, wherein the blockchain system includes at least one of the following software system components: payment channel liquidity, payment channel permissioning, safe offline payment channel availability, zero-knowledge permissioning, anchor blocks, block-building and protocol validation functions, message signing protocol, consensus protocols, synchronization with traditional database systems, and integration with external off-chain payment systems.

Images