ConceptioArchiveGoogle Patents
Google Patentsopen access

Method and system for tuning blockchain scalability, decentralization, and … — Dr. Vijay Madisetti (US20240427796A1)

Dr. Vijay Madisetti · Google Patents
Google Patents · Patents · License: Open Access
Open Source ↗
patent, google patents, intellectual property, US20240427796A1, Dr. Vijay Madisetti, Vijay Madisetti, en, 2024

ABSTRACT

Abstract

A method for sharing data between blockchains in a multi-chain network including receiving a first plurality of account addresses associated with first and second blockchains and an account state for each account associated with the first plurality of account addresses, generating a first hash tree comprising a mapping between the first plurality of account addresses and the account states, defining a world state trie, generating a root hash of the world state trie, receiving a first plurality of transactions associated with the first and second blockchains, generating a second hash tree comprising the first plurality of transactions, defining a transactions trie, and generating a root hash of the transactions trie.

Description

RELATED APPLICATIONS

This application is a continuation reissue application of and claims priority under at least one of 35 U.S.C. § 120 and 37 CFR 1.177 of U.S. Reissue patent application Ser. No. 17/452,839 (Attorney Docket No. 3026.00027) filed on Oct. 29, 2021 and titled Method and System for Tuning Blockchain Scalability, Decentralization, and Security for Fast and Low-Cost Payment and Transaction Processing, which in turn is a continuation application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/375,351, now U.S. Pat. No. 10,459,946, issued Oct. 29, 2019 (Attorney Docket No. 3026.00020) filed on Apr. 4, 2019 and titled Method and System for Tuning Blockchain Scalability, Decentralization, and Security for Fast and Low-Cost Payment and Transaction Processing, which in turn is a continuation application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/135,701, now U.S. Pat. No. 10,255,342, issued Apr. 9, 2019 (Attorney Docket No. 3026.00014) filed on Sep. 19, 2018 and titled Method and System for Tuning Blockchain Scalability, Decentralization, and Security for Fast and Low-Cost Payment and Transaction Processing, which in turn is a continuation-in-part application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/119,163, now U.S. Pat. No. 10,289,631, issued May 14, 2019 (Attorney Docket No. 3026.00012) filed on Aug. 31, 2018 and titled Method and System for Tuning Blockchain Scalability for Fast and Low-Cost Payment and Transaction Processing, which in turn is a continuation application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 15/942,604, now U.S. Pat. No. 10,102,265, issued Oct. 16, 2018 (Attorney Docket No. 3026.00007) filed on Apr. 2, 2018 and titled Method and System for Tuning Blockchain Scalability for Fast and Low-Cost Payment and Transaction Processing, which in turn claims priority under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/484,555filed on Apr. 12, 2017 and titled Method and System for Tuning Blockchain Scalability, which in turn claims priority under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/620,616filed on Jan. 23, 2018 and titled Fast & Low Cost Payment and Transaction Processing on Blockchain Networks, which in turn is a continuation-in-part application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/127,283, now U.S. Pat. No. 10,243,743, issued Mar. 26, 2019 (Attorney Docket No. 3026.00011) filed on Sep. 11, 2018 and titled Tokens or Crypto Currency Using Smart Contracts and Blockchains, which in turn claims priority under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/557,820 filed on Sep. 13, 2017 and titled Tokens or Crypto Currency for Change Using Smart Contracts and Blockchains, which in turn claims priority under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/618,784filed on Jan. 18, 2018 and titled Additional Features of CoinBank and nCash NCC Tokens. The contents of these applications are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to blockchain-scalability, fast and low-cost payment and transaction processing on blockchain networks.

BACKGROUND OF THE INVENTION

Blockchain is a distributed and public ledger which maintains records of all the transactions. A blockchain network is a truly peer-to-peer network and it does not require a trusted central authority or intermediaries to authenticate or to settle the transactions or to control the network infrastructure. Users can interact and transact with the blockchain networks through Externally Owned Account (EOAs), which are owned and controlled by the users. Each EOA has a balance (in certain units of a Cryptocurrency associated with the Blockchain network) associated with it. EOAs do not have any associated code. All transactions on a blockchain network are initiated by EOAs. These accounts can send transactions to other EOAs or contract accounts. Another type of accounts support by second generation programmable Blockchain platforms are the Contract Accounts. A Contract Account is created and owned by an EOA and is controlled by the associated contract code which is stored with the account. The contract code execution is triggered by transactions sent by EOAs or messages sent by other contracts.

Blockchain networks can either be public or private. Public blockchain networks are free and open to all and any user can create an account and participate in the consensus mechanism on a public blockchain and view all the transactions on the network. Private blockchain networks are usually controlled and operated by a single organization and the transactions can be viewed only by the users within the organization. Public blockchain networks are usually unpermissioned or permissionless, as any node can participate in consensus process. Some public blockchain networks adopt a permissioned model where the consensus process is controlled by a pre-selected set of nodes. Private blockchain networks usually adopt the permissioned model. While public blockchain networks can be considered as fully decentralized, private blockchain networks are partially decentralized.

Organizations can have multiple private blockchain networks where each network is dedicated to a specific use case or department or business vertical. The blockchain networks within an organization may be created either using the same blockchain platform or technology or with different platforms or technologies.

On each blockchain network, a user can create multiple Externally Owned Accounts (EOAs). Each Externally Owned Account (EOA) has a public-private keypair associated with it. The account address is derived from the public key. When a new EOA is created, a keyfile is created which has the public and private keys associated with the account. The private key is encrypted with the password which is provided while creating the account. For sending transactions to other accounts, the private key and the account password are required.

Existing Blockchain platforms face scalability concerns. The transaction validation and consensus mechanisms (such as proof-of-work) used in blockchain networks and other parameters such as the block-size and block-time determine how fast the network can process and confirm the transactions. While commercial payment networks can process thousands of transactions per second, blockchain networks can take from a few seconds to several minutes for a transaction to be confirmed and have much less transaction throughput as compared to commercial payment networks. For example, Bitcoin network takes 10 minutes or longer to confirm transactions and achieves about 3-7 transactions/sec throughput. Similarly, Ethereum blockchain network where the block-time is roughly 17 seconds, and achieves about 7-15 transactions/sec throughput. Furthermore, many blockchain applications require multiple confirmations for newly mined blocks to secure the transactions from double-spending. For such applications, it may take several minutes for a transaction to be confirmed. While it is possible to make the block-times faster, so that the transactions can be processed faster, however, this would impact network security. Fast block-times would make it impossible for average-sized miners to run as full nodes and only the powerful miners would be able to afford the resources required to mine successfully on the blockchain network. Thus, fast block-times can lead to centralization risks. There exists a tradeoff between how fast the transactions can be processed on a blockchain network and the level of decentralization that can be maintained.

For distributed data systems, a trade-off exists between consistency and availability. These trade-offs are explained with the CAP Theorem, which states that under partitioning, a distributed data system can either be consistent or available but not both at the same time. According to the CAP theorem the system can either favor consistency and partition tolerance over availability, or favor availability and partition tolerance over consistency. The CAP theorem applies to blockchain networks as well. Blockchain gives up on consistency to be available and partition tolerant.

Blockchain protocols allow may limited and local adjustments to the blockchain parameters. In one approach, the parameter adjustment rules are defined in the client code itself (which is used by the blockchain nodes to transact and mine on the network) and the parameter values are adjusted for each block. This approach works for minor adjustments to blockchain parameters which can be defined in the blockchain client code. For major changes to the blockchain protocol, hard forks have to be typically used. A hard fork is a change to the underlying blockchain protocol. Hard forks are issued after a consensus is reached among the blockchain community about the changes to be incorporated in the fork. For issuing a hard fork, all the blockchain clients (which may be implemented in different programming languages) are updated and new releases of these clients are issued. The blockchain peers are then notified to upgrade their blockchain clients so that the new blockchain protocol can come into effect. Since a blockchain network is a peer-to-peer and decentralized network, realizing hard forks can be complex and time consuming. Miner nodes who do not upgrade their blockchain clients after a hard fork is issued will continue to mine on the pre-fork blockchain which is incompatible with the new blockchain protocol. It is expected that over time the miners running the old clients will eventually upgrade to the new clients so that they can continue to mine successfully on the main blockchain that follows the new protocol. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

General approaches for blockchain scalability can be categorized into the following areas:

Blockchain parameter tuning approaches: These approaches involve tuning the blockchain parameters such as block-size and block-time (or block-interval) to increase the transaction throughput and reduce transaction latency using local and limited approaches that require client upgrades and lengthy consensus. On-chain Scaling with Sharding: Sharding involves splitting the task of consensus among concurrently operating sets of nodes, to improve the transaction throughput and reduce the per-node processing and storage requirements. Sharding approaches for blockchain either shard transaction processing or shard the state. Off-chain Scaling with Channels: Channels based approaches use off-chain peer-to-peer payment channels that allow transactions to occur directly between participants rather than sending transactions on the blockchain, and the blockchain is used as a settlement mechanism. Alternative blockchain designs and protocols: Other blockchain scalability approaches are based on using alternative blockchain designs and protocols. For example, the Bitcoin-NG proposal addresses the scalability bottleneck by having two types of blocks: key-blocks and microblocks. Key-blocks are used for leader election every epoch. Microblocks contain transactions and are generated by the epoch leader. Microblocks can be issued at very high speed as they are signed with the leader's private key and contain no proof of work.

Transaction processing on existing public blockchain networks requires high transaction fees to be paid to the network. The volume of transactions on the public blockchain networks increase, the fees will also increase. Due to high transaction fees, sending micro-transactions (or low value transactions) on the public blockchain networks are not economically feasible as the value of such transactions is lower than the fees paid to process the transactions.

This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

SUMMARY OF THE INVENTION

With the above in mind, embodiments of the present invention are related to a method of capturing the Decentralization, Scalability and Security (DSS) constraints for blockchain networks.

In some embodiments, the method may further comprise quantifying the Decentralization, Scalability and Security levels based on various blockchain parameters.

Furthermore, embodiments of the invention may be directed to a system and associated methods for communicating the tuning parameters to the nodes in a blockchain network, so that the network can be tuned in an adaptive manner.

In some embodiments, the method may further comprise a unified model for tuning blockchain, without use of hard forks.

In some embodiments, the method may further comprise creating application-specific blockchain flavors which desired levels of Decentralization, Scalability and Security.

In some embodiments, the method may further comprise an adaptive tuning approach for blockchain parameters to meet the desired levels of Decentralization, Scalability and Security.

In some embodiments, the method may further comprise secure communication of the tuning parameters to the nodes in the blockchain network. The advantages to this embodiment of the invention for communicating the tuning parameters are as follows:

Allows changing the blockchain parameters dynamically, typically without expensive hard forks. Allows the network to continue to process transactions while the changes are being applied. Provides a secure way of deciding what changes are to be applied and how the changes are to be communicated. Provision for rollbacks and checkpointing to handle anomalous conditions.

Another embodiment of the invention may be directed to a system for tuning the scalability of a blockchain network through an on-chain scaling approach to increase transaction throughput and reduce transaction latency.

Furthermore, embodiments of the invention may be directed to a system for tuning the scalability of a blockchain network through an off-chain scaling approach to enable micro-transactions between parties. The privacy of the micro-transactions on the private chain in the off-chain scaling embodiment is preserved as only a summarized view of the micro-transactions received in a particular time-period is recorded on the main blockchain. Use of specific protocols for communication of the tuning parameters in a secure, fault-tolerant and consistent manner that allows checkpointing and rollback is also provided.

Another embodiment of the invention may be directed to a system for checkpointing transactions between private and public blockchain networks.

Another embodiment of the invention may be directed to a system for cross-chain payments.

Another embodiment of the invention may be directed to a method of smart contract mirroring

Another embodiment of the invention may be directed to a method of transaction replication and partitioning to speed up transactions.

Another embodim

RELATED APPLICATIONS

This application is a continuation reissue application of and claims priority under at least one of 35 U.S.C. § 120 and 37 CFR 1.177 of U.S. Reissue patent application Ser. No. 17/452,839 (Attorney Docket No. 3026.00027) filed on Oct. 29, 2021 and titled Method and System for Tuning Blockchain Scalability, Decentralization, and Security for Fast and Low-Cost Payment and Transaction Processing, which in turn is a continuation application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/375,351, now U.S. Pat. No. 10,459,946, issued Oct. 29, 2019 (Attorney Docket No. 3026.00020) filed on Apr. 4, 2019 and titled Method and System for Tuning Blockchain Scalability, Decentralization, and Security for Fast and Low-Cost Payment and Transaction Processing, which in turn is a continuation application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/135,701, now U.S. Pat. No. 10,255,342, issued Apr. 9, 2019 (Attorney Docket No. 3026.00014) filed on Sep. 19, 2018 and titled Method and System for Tuning Blockchain Scalability, Decentralization, and Security for Fast and Low-Cost Payment and Transaction Processing, which in turn is a continuation-in-part application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/119,163, now U.S. Pat. No. 10,289,631, issued May 14, 2019 (Attorney Docket No. 3026.00012) filed on Aug. 31, 2018 and titled Method and System for Tuning Blockchain Scalability for Fast and Low-Cost Payment and Transaction Processing, which in turn is a continuation application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 15/942,604, now U.S. Pat. No. 10,102,265, issued Oct. 16, 2018 (Attorney Docket No. 3026.00007) filed on Apr. 2, 2018 and titled Method and System for Tuning Blockchain Scalability for Fast and Low-Cost Payment and Transaction Processing, which in turn claims priority under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/484,555filed on Apr. 12, 2017 and titled Method and System for Tuning Blockchain Scalability, which in turn claims priority under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/620,616filed on Jan. 23, 2018 and titled Fast & Low Cost Payment and Transaction Processing on Blockchain Networks, which in turn is a continuation-in-part application of and claims priority under 35 U.S.C. § 120 of U.S. patent application Ser. No. 16/127,283, now U.S. Pat. No. 10,243,743, issued Mar. 26, 2019 (Attorney Docket No. 3026.00011) filed on Sep. 11, 2018 and titled Tokens or Crypto Currency Using Smart Contracts and Blockchains, which in turn claims priority under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/557,820 filed on Sep. 13, 2017 and titled Tokens or Crypto Currency for Change Using Smart Contracts and Blockchains, which in turn claims priority under 35 U.S.C. § 119 (e) of U.S. Provisional Patent Application Ser. No. 62/618,784filed on Jan. 18, 2018 and titled Additional Features of CoinBank and nCash NCC Tokens. The contents of these applications are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to blockchain-scalability, fast and low-cost payment and transaction processing on blockchain networks.

BACKGROUND OF THE INVENTION

Blockchain is a distributed and public ledger which maintains records of all the transactions. A blockchain network is a truly peer-to-peer network and it does not require a trusted central authority or intermediaries to authenticate or to settle the transactions or to control the network infrastructure. Users can interact and transact with the blockchain networks through Externally Owned Account (EOAs), which are owned and controlled by the users. Each EOA has a balance (in certain units of a Cryptocurrency associated with the Blockchain network) associated with it. EOAs do not have any associated code. All transactions on a blockchain network are initiated by EOAs. These accounts can send transactions to other EOAs or contract accounts. Another type of accounts support by second generation programmable Blockchain platforms are the Contract Accounts. A Contract Account is created and owned by an EOA and is controlled by the associated contract code which is stored with the account. The contract code execution is triggered by transactions sent by EOAs or messages sent by other contracts.

Blockchain networks can either be public or private. Public blockchain networks are free and open to all and any user can create an account and participate in the consensus mechanism on a public blockchain and view all the transactions on the network. Private blockchain networks are usually controlled and operated by a single organization and the transactions can be viewed only by the users within the organization. Public blockchain networks are usually unpermissioned or permissionless, as any node can participate in consensus process. Some public blockchain networks adopt a permissioned model where the consensus process is controlled by a pre-selected set of nodes. Private blockchain networks usually adopt the permissioned model. While public blockchain networks can be considered as fully decentralized, private blockchain networks are partially decentralized.

Organizations can have multiple private blockchain networks where each network is dedicated to a specific use case or department or business vertical. The blockchain networks within an organization may be created either using the same blockchain platform or technology or with different platforms or technologies.

On each blockchain network, a user can create multiple Externally Owned Accounts (EOAs). Each Externally Owned Account (EOA) has a public-private keypair associated with it. The account address is derived from the public key. When a new EOA is created, a keyfile is created which has the public and private keys associated with the account. The private key is encrypted with the password which is provided while creating the account. For sending transactions to other accounts, the private key and the account password are required.

Existing Blockchain platforms face scalability concerns. The transaction validation and consensus mechanisms (such as proof-of-work) used in blockchain networks and other parameters such as the block-size and block-time determine how fast the network can process and confirm the transactions. While commercial payment networks can process thousands of transactions per second, blockchain networks can take from a few seconds to several minutes for a transaction to be confirmed and have much less transaction throughput as compared to commercial payment networks. For example, Bitcoin network takes 10 minutes or longer to confirm transactions and achieves about 3-7 transactions/sec throughput. Similarly, Ethereum blockchain network where the block-time is roughly 17 seconds, and achieves about 7-15 transactions/sec throughput. Furthermore, many blockchain applications require multiple confirmations for newly mined blocks to secure the transactions from double-spending. For such applications, it may take several minutes for a transaction to be confirmed. While it is possible to make the block-times faster, so that the transactions can be processed faster, however, this would impact network security. Fast block-times would make it impossible for average-sized miners to run as full nodes and only the powerful miners would be able to afford the resources required to mine successfully on the blockchain network. Thus, fast block-times can lead to centralization risks. There exists a tradeoff between how fast the transactions can be processed on a blockchain network and the level of decentralization that can be maintained.

For distributed data systems, a trade-off exists between consistency and availability. These trade-offs are explained with the CAP Theorem, which states that under partitioning, a distributed data system can either be consistent or available but not both at the same time. According to the CAP theorem the system can either favor consistency and partition tolerance over availability, or favor availability and partition tolerance over consistency. The CAP theorem applies to blockchain networks as well. Blockchain gives up on consistency to be available and partition tolerant.

Blockchain protocols allow may limited and local adjustments to the blockchain parameters. In one approach, the parameter adjustment rules are defined in the client code itself (which is used by the blockchain nodes to transact and mine on the network) and the parameter values are adjusted for each block. This approach works for minor adjustments to blockchain parameters which can be defined in the blockchain client code. For major changes to the blockchain protocol, hard forks have to be typically used. A hard fork is a change to the underlying blockchain protocol. Hard forks are issued after a consensus is reached among the blockchain community about the changes to be incorporated in the fork. For issuing a hard fork, all the blockchain clients (which may be implemented in different programming languages) are updated and new releases of these clients are issued. The blockchain peers are then notified to upgrade their blockchain clients so that the new blockchain protocol can come into effect. Since a blockchain network is a peer-to-peer and decentralized network, realizing hard forks can be complex and time consuming. Miner nodes who do not upgrade their blockchain clients after a hard fork is issued will continue to mine on the pre-fork blockchain which is incompatible with the new blockchain protocol. It is expected that over time the miners running the old clients will eventually upgrade to the new clients so that they can continue to mine successfully on the main blockchain that follows the new protocol. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

General approaches for blockchain scalability can be categorized into the following areas:

Blockchain parameter tuning approaches: These approaches involve tuning the blockchain parameters such as block-size and block-time (or block-interval) to increase the transaction throughput and reduce transaction latency using local and limited approaches that require client upgrades and lengthy consensus. On-chain Scaling with Sharding: Sharding involves splitting the task of consensus among concurrently operating sets of nodes, to improve the transaction throughput and reduce the per-node processing and storage requirements. Sharding approaches for blockchain either shard transaction processing or shard the state. Off-chain Scaling with Channels: Channels based approaches use off-chain peer-to-peer payment channels that allow transactions to occur directly between participants rather than sending transactions on the blockchain, and the blockchain is used as a settlement mechanism. Alternative blockchain designs and protocols: Other blockchain scalability approaches are based on using alternative blockchain designs and protocols. For example, the Bitcoin-NG proposal addresses the scalability bottleneck by having two types of blocks: key-blocks and microblocks. Key-blocks are used for leader election every epoch. Microblocks contain transactions and are generated by the epoch leader. Microblocks can be issued at very high speed as they are signed with the leader's private key and contain no proof of work.

Transaction processing on existing public blockchain networks requires high transaction fees to be paid to the network. The volume of transactions on the public blockchain networks increase, the fees will also increase. Due to high transaction fees, sending micro-transactions (or low value transactions) on the public blockchain networks are not economically feasible as the value of such transactions is lower than the fees paid to process the transactions.

This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

SUMMARY OF THE INVENTION

With the above in mind, embodiments of the present invention are related to a method of capturing the Decentralization, Scalability and Security (DSS) constraints for blockchain networks.

In some embodiments, the method may further comprise quantifying the Decentralization, Scalability and Security levels based on various blockchain parameters.

Furthermore, embodiments of the invention may be directed to a system and associated methods for communicating the tuning parameters to the nodes in a blockchain network, so that the network can be tuned in an adaptive manner.

In some embodiments, the method may further comprise a unified model for tuning blockchain, without use of hard forks.

In some embodiments, the method may further comprise creating application-specific blockchain flavors which desired levels of Decentralization, Scalability and Security.

In some embodiments, the method may further comprise an adaptive tuning approach for blockchain parameters to meet the desired levels of Decentralization, Scalability and Security.

In some embodiments, the method may further comprise secure communication of the tuning parameters to the nodes in the blockchain network. The advantages to this embodiment of the invention for communicating the tuning parameters are as follows:

Allows changing the blockchain parameters dynamically, typically without expensive hard forks. Allows the network to continue to process transactions while the changes are being applied. Provides a secure way of deciding what changes are to be applied and how the changes are to be communicated. Provision for rollbacks and checkpointing to handle anomalous conditions.

Another embodiment of the invention may be directed to a system for tuning the scalability of a blockchain network through an on-chain scaling approach to increase transaction throughput and reduce transaction latency.

Furthermore, embodiments of the invention may be directed to a system for tuning the scalability of a blockchain network through an off-chain scaling approach to enable micro-transactions between parties. The privacy of the micro-transactions on the private chain in the off-chain scaling embodiment is preserved as only a summarized view of the micro-transactions received in a particular time-period is recorded on the main blockchain. Use of specific protocols for communication of the tuning parameters in a secure, fault-tolerant and consistent manner that allows checkpointing and rollback is also provided.

Another embodiment of the invention may be directed to a system for checkpointing transactions between private and public blockchain networks.

Another embodiment of the invention may be directed to a system for cross-chain payments.

Another embodiment of the invention may be directed to a method of smart contract mirroring

Another embodiment of the invention may be directed to a method of transaction replication and partitioning to speed up transactions.

Another embodiment of the invention may be directed to a method of filtering transactions into different classes and processing the transaction on private or public blockchain networks based on the class of transaction.

Embodiments of the present invention differ from existing off-chain solutions such as the Lightning Network and Raiden Network which leverage bidirectional payment channels to address the issues of scalability, latency and transaction fees for blockchain based payment applications and token transfers. Payment channels allow off-chain transfer of on-chain tokens or cryptocurrencies. A payment channel is created between two participants by depositing a certain amount of tokens in smart contract. A payment channel is an agreement between two participants where the sender sets up a deposit in a smart contract for the receiver. Payments or transfer of tokens between the participants can then be done by sending signed messages without going through global consensus on the blockchain. Eventual settlement of payments between the participants happens when a payment channel is closed by either participant. The payment channel smart contract validates the last signed message and settles the claims. Payment channels can also be combined into a network, where a path connecting any two participants can be found. This allows payments between participants, who do not have direct channels between each other. A limitation of payment channels is that the participants need to lock up tokens in a payment channel contract upfront. The value of a payment cannot exceed the deposit used to setup a payment channel. Embodiments of the present invention adopt a different approach from payment channels by using a combination of public and private blockchain network with regular synchronization and checkpointing of transactions and mirroring of smart contract states. This approach does not require locking up funds upfront as in the case of payment channels. Double spending is prevented by synchronizing the accounts at regular intervals and combining and recording the transactions (done on a private blockchain) to a public blockchain network. Additionally, for accounts participating in off the public chain transfers (i.e. transfers on a private blockchain), the withdrawal or transfer of tokens from the public blockchain accounts can be disabled or locked through the use of smart contracts, to prevent the same funds from being sent elsewhere in the time interval between two synchronization points.

A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a method of synchronizing transactions between private and public blockchains including: receiving a first plurality of transactions on a first private blockchain network. The method of synchronizing transactions also includes recording the first plurality of transactions to a first private block on the first private blockchain network. The method of synchronizing transactions also includes receiving a second plurality of transactions on the first private blockchain network. The method of synchronizing transactions also includes recording the second plurality of transactions to a second private block on the first private blockchain network. The method of synchronizing transactions also includes generating a first merged block including the first private block and the second private block. The method of synchronizing transactions also includes recording the first merged block to a single block on a second blockchain network. The method of synchronizing transactions also includes recording each of the first private block, the second private block, and the first merged block to a smart contract linked to the first private blockchain network, defining a first private smart contract. The method of synchronizing transactions also includes performing a synchronization process between the first private smart contract and a second smart contract linked to the second blockchain network, defining a second smart contract. The method of synchronizing transactions also includes performing a checkpointing process between the first private smart contract and the second smart contract including recording the state of the first private smart contract to the second smart contract, defining a checkpointed first private smart contract. The method of synchronizing transactions also includes where the first private blockchain network has a parameter difference from the second blockchain network selected from the group including of block generation time, number of network nodes, number of connected peers, minimum network bandwidth requirement, minimum mining processing power requirement, minimum mining disk input/output requirement, minimum mining memory requirement, mining bootstrap time requirement, transaction throughput, transaction latency, stale block rate, and block propagation delay. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The method where: the second blockchain network is a public blockchain network. The method may also include the second smart contract is a public smart contract. The method where: the first plurality of transactions includes a plurality of transactions between two users, each transaction between the two users including a transfer of tokens from one user to the other, each user having an account on each of the first private blockchain network and the second blockchain network. The method may also include the first merged block includes a combined transaction including a net token value equaling the net of transfers of tokens between the two users in the plurality of transactions between the two users. The method where the first private smart contract is a multi-signature smart contract including a plurality of signatures, each signature being associated with a user. The method where an identity of a user having a signature included by the first private smart contract is validated by an identity verification and certification procedure. The method where the identity verification and certification procedure includes retrieving identity verifying information from an identity verification blockchain network. The method where the first private smart contract includes at least three signatures, each signature being associated with a separate user. The method further including: receiving a third plurality of transactions on a second private blockchain network. The method may also include recording the third plurality of transactions to a third private block on the second private blockchain network. The method may also include receiving a fourth plurality of transactions on the second private blockchain network. The method may also include recording the fourth plurality of transactions to a fourth private block on the second private blockchain network. The method may also include generating a second merged block including the third private block and the fourth private block. The method may also include recording the second merged block to a single block on the public blockchain network. The method may also include recording each of the third private block, the fourth private block, and the second merged block to a smart contract linked to the second private blockchain network, defining a second private smart contract. The method may also include performing a synchronization process between the second private smart contract and the public smart contract. The method may also include performing a checkpointing process between the second private smart contract and the public smart contract including recording the state of the second private smart contract to the public smart contract, defining a checkpointed second private smart contract. The method may also include where the second private blockchain network has a parameter difference from the public blockchain network selected from the group including of block generation time, number of network nodes, number of connected peers, minimum network bandwidth requirement, minimum mining processing power requirement, minimum mining disk input/output requirement, minimum mining memory requirement, mining bootstrap time requirement, transaction throughput, transaction latency, stale block rate, and block propagation delay. The method further including: receiving a third plurality of transactions on a second private blockchain network. The method may also include recording the third plurality of transactions to a third private block on the second private blockchain network. The method may also include receiving a fourth plurality of transactions on the second private blockchain network. The method may also include recording the fourth plurality of transactions to a fourth private block on the second private blockchain network. The method may also include generating a second merged block including the third private block and the fourth private block. The method may also include recording the second merged block to a single block on the public blockchain network. The method may also include recording each of the third private block, the fourth private block, and the second merged block to a smart contract linked to the second private blockchain network, defining a second private smart contract. The method may also include performing a synchronization process between the second private smart contract and a second smart contract linked to the public blockchain network, defining a second public smart contract. The method may also include performing a checkpointing process between the second private smart contract and the public smart contract including recording the state of the second private smart contract to the second public smart contract, defining a checkpointed second private smart contract. The method may also include where the second private blockchain network has a parameter difference from the public blockchain network selected from the group including of block generation time, number of network nodes, number of connected peers, minimum network bandwidth requirement, minimum mining processing power requirement, minimum mining disk input/output requirement, minimum mining memory requirement, mining bootstrap time requirement, transaction throughput, transaction latency, stale block rate, and block propagation delay. The method where the synchronization process includes: determining an account on the first private blockchain network that has a token balance decrease, defining a decreasing account. The method may also include moving a value of the token balance decrease from an account on the public blockchain network corresponding to the decreasing account to a vault account on the public blockchain network. The method may also include determining if a total token supply on the private blockchain network has increased since an immediate previous synchronization process. The method may also include if the total token supply on the private blockchain network has increased, creating new tokens and sending them to the vault account. The method may also include if the total token supply on the private blockchain network has not increased, burning an amount of tokens from the vault account equal to the token balance decrease. The method may also include determining an account on the first private blockchain network that has a token balance increase, defining an increasing account. The method may also include moving a value of the token balance increase from the vault account to an account on the public blockchain network corresponding to the increasing account. The method where the second blockchain network is a second private blockchain network and the second smart contract is a second private smart contract, the method further including. The method may also include receiving a third plurality of transactions on the first private blockchain network. The method may also include recording the third plurality of transactions to a third private block on the first private blockchain network. The method may also include receiving a fourth plurality of transactions on the first private blockchain network. The method may also include recording the fourth plurality of transactions to a fourth private block on the first private blockchain network. The method may also include generating a second merged block including the third private block and the fourth private block. The method may also include recording the second merged block to the second private blockchain network. The method may also include generating a third merged block including each of the first and second merged blocks. The method may also include recording the third merged block to a third blockchain network. The method where the second private blockchain network has a parameter difference from each of the first private blockchain network and the third blockchain network selected from the group including of block generation time number of network nodes, number of connected peers, minimum network bandwidth requirement, minimum mining processing power requirement, minimum mining disk input/output requirement, minimum mining memory requirement, mining bootstrap time requirement, transaction throughput, transaction latency, stale block rate, and block propagation delay. The method where: a block generation time of the first private blockchain network is within a range from 1 millisecond (ms) to 10 ms, a block generation time of the second private blockchain network is within a range from 1 second to 10 seconds, and a block generation time of the third blockchain network is within a range from 1 minute to 10 minutes. The method further including: recording the third and fourth private blocks and the second merged block to the first private blockchain smart contract. The method may also include performing a synchronization process between the first private smart contract and the second smart contract. The method may also include performing a checkpointing process between the first private smart contract and the second private smart contract including recording the state of the first private smart contract to the second private smart contract, redefining the checkpointed first private smart contract. The method may also include recording each of the first, second, and third merged blocks to a third smart contract linked to the second private blockchain network, defining a third private smart contract. The method may also include performing a synchronization process between the third private smart contract and a fourth smart contract linked to the third blockchain network, defining a fourth smart contract. The method may also include performing a checkpointing process between the third private smart contract and the fourth smart contract including recording the state of the third private smart contract to the fourth smart contract, defining a checkpointed third private smart contract. The method where the third blockchain network is a public blockchain network. The method further including: applying a filter to the first plurality of transactions. The method may also include determining a subset of transactions of the first plurality of transactions. The method may also include excluding the subset of transactions from being recorded to the first merged block. The method further including: identifying a failure of the first private blockchain network. The method may also include recording a transaction on the first private blockchain network to a first private blockchain network transaction log, defining a logged transaction. The method may also include retrieving the checkpointed first private smart contract from the second smart contract. The method may also include recording the checkpointed first private smart contract to the first private blockchain network, defining a restored first private smart contract. The method may also include recording the logged transaction to the restored first private smart contract. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

Further embodiments of the present invention are related to a method for sharing data between blockchains in a multi-chain network comprising receiving a first plurality of account addresses associated with first and second blockchains and an account state for each account associated with the first plurality of account addresses, generating a first hash tree comprising a mapping between the first plurality of account addresses and the account states, defining a world state tri, and generating a root hash of the world state trie. The method may further comprise receiving a first plurality of transactions associated with the first and second blockchains, generating a second hash tree comprising the first plurality of transactions, defining a transactions trie, and generating a root hash of the transactions trie.

In some embodiments, the root hash of both of the world state trie and the transaction trie may be recorded to each block of the first and second blockchains. At least a portion of both of the world state trie and the transactions trie are accessible by the first and second blockchains. In some embodiments, the first blockchain may have a parameter difference from the second blockchain selected from the group consisting of block generation time, transaction throughput, transaction latency, stale block rate, block propagation delay, and consensus algorithm used.

In some embodiments, the entirety of at least one of the state trie and the transactions trie is accessible by the first and second blockchains. In further embodiments, the entirety of both of the state trie and the transactions trie may be accessible by the first and second blockchains.

The second blockchain may be relatively decentralized compared to the first blockchain. The first blockchain may be fully centralized. The second blockchain may be fully decentralized.

In some embodiments, account addresses for the first blockchain may be within an address space separate from an address space from account addresses for the second blockchain. In some embodiments, account addresses for the first blockchain may be within the same address space as account addresses for the second blockchain.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present invention are illustrated as an example and are not limited by the figures of the accompanying drawings, in which like references may indicate similar elements.

FIG. 1 is an illustration of the blockchain account types and interactions.

FIG. 2 is an illustration of an existing blockchain design used by public blockchain networks such as Ethereum.

FIG. 3 is an illustration of the Decentralization, Scalability and Security (DSS) framework for a blockchain network, according to an embodiment of the invention.

FIG. 4 is an illustration of exemplary decentralization, scalability and security parameters, according to an embodiment of the invention.

FIG. 5 is an illustration of unified model and protocol for tuning blockchain, according to an embodiment of the invention.

FIG. 6 is an illustration of a method for creating application-specific blockchain flavors, according to an embodiment of the invention.

FIG. 7 is an illustration of a method for adaptive tuning of blockchain parameters, according to an embodiment of the invention.

FIG. 8 is an illustration of the structure of control messages as extension to the existing Ethereum Blockchain Wire Protocol, according to an embodiment of the invention.

FIG. 9 is an illustration of blockchain design for increasing scalability (on-chain approach), according to an embodiment of the invention.

FIG. 10 is an illustration of the structure for a micro-block in the on-chain scaling approach, according to an embodiment of the invention.

FIG. 11 is an illustration of an off-chain scaling approach, according to an embodiment of the invention.

FIG. 12 is an illustration of super-chains and sub-chains as used in the off-chain scaling approach, according to an embodiment of the invention.

FIG. 13 is an illustration of the checkpointing process between private and public blockchains and the interfaces involved, according to an embodiment of the invention;

FIG. 14 is an illustration of checkpointing process between private and public blockchains with the use of a public-private gateway, according to an embodiment of the invention.

FIG. 15 is an illustration of a cross-chain payments process, according to an embodiment of the invention.

FIG. 16 is an illustration of interchain transactions and a payments bridge, according to an embodiment of the invention.

FIG. 17 is an illustration of fast and low-cost transactions on a private blockchain network with periodic checkpointing on a public blockchain network, according to an embodiment of the invention.

FIG. 18 is an illustration of an example of transactions processed on a private blockchain network (off the main public chain), according to an embodiment of the invention.

FIG. 19 is an illustration of an example of combined transactions processed on a public blockchain network, according to an embodiment of the invention.

FIG. 20 is an illustration of an example synchronizing transactions between private and public blockchains, according to an embodiment of the invention.

FIG. 21 is an illustration of an example synchronizing transactions between multiple private and public blockchains, according to an embodiment of the invention.

FIG. 22 is an illustration of a method of smart contract mirroring, according to an embodiment of the invention.

FIG. 23 is an illustration of the use of multiple chains for replication, partitioning and transaction speedup, according to an embodiment of the invention.

FIG. 24 is an illustration of a transactions filter for filtering transactions into different classes, according to an embodiment of the invention.

FIG. 25 is an illustration of the use of a private blockchain infrastructure for offloading frequent transactions and big data, according to an embodiment of the invention.

FIG. 26 is an illustration of an exemplary cloud and blockchain backend architecture for a payments application, according to an embodiment of the invention.

FIG. 27 is an illustration of multi-signature and multi-party smart contracts on multiple private and permissioned blockchains which are synchronized and checkpointed to a single public blockchain, according to an embodiment of the invention.

FIG. 28 is an illustration of the multi-signature and multi-party smart contracts in a Letter of Credit application, according to an embodiment of the invention/

FIG. 29 is an illustration of “soft” smart contracts, according to an embodiment of the invention.

FIG. 30 is a reference implementation of a token smart contract synchronizing service that syncs token smart contracts between a private blockchain and a public blockchain, according to an embodiment of the invention.

FIG. 31 is an illustration of a distributed publish-subscribe messaging framework according to an embodiment of the invention.

FIG. 32 is an illustration of the consumer/subscriber actions supported in the publish-subscribe messaging framework according to an embodiment of the invention.

FIG. 33 is an illustration of a BlockGrid architecture according to an embodiment of the invention.

FIG. 34 is an illustration of relationships between blocks on different blockchains within the BlockGrid architecture according to an embodiment of the invention.

FIG. 35 is an illustration of transaction and state storage in the BlockGrid network according to an embodiment of the invention.

FIG. 36 is an illustration of different transaction types which are routed through the bulletin board publish-subscribe framework according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Those of ordinary skill in the art realize that the following descriptions of the embodiments of the present invention are illustrative and are not intended to be limiting in any way. Other embodiments of the present invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. Like numbers refer to like elements throughout.

Although the following detailed description contains many specifics for the purposes of illustration, anyone of ordinary skill in the art will appreciate that many variations and alterations to the following details are within the scope of the invention. Accordingly, the following embodiments of the invention are set forth without any loss of generality to, and without imposing limitations upon, the claimed invention.

In this detailed description of the present invention, a person skilled in the art should note that directional terms, such as “above,” “below,” “upper,” “lower,” and other like terms are used for the convenience of the reader in reference to the drawings. Also, a person skilled in the art should notice this description may contain other terminology to convey position, orientation, and direction without departing from the principles of the present invention.

Furthermore, in this detailed description, a person skilled in the art should note that quantitative qualifying terms such as “generally,” “substantially,” “mostly,” and other terms are used, in general, to mean that the referred to object, characteristic, or quality constitutes a majority of the subject of the reference. The meaning of any of these terms is dependent upon the context within which it is used, and the meaning may be expressly modified.

Referring now to FIG. 1 , for example, and without limitation, blockchain account types and interactions between them, are described in more detail. Blockchain is a distributed and public ledger which maintains records of all the transactions. A blockchain network 100 is a truly peer-to-peer network and it does not require a trusted central authority or intermediaries to authenticate or to settle the transactions or to control the network infrastructure. Users can interact and transact with the blockchain networks through Externally Owned Account (EOAs) 110 , which are owned and controlled by the users. Each EOA 110 has an account address 102 , account public- private keys 104 and a balance 106 (in certain units of a Cryptocurrency associated with the Blockchain network) associated with it. EOAs do not have any associated code. All transactions 120 on a blockchain network are initiated by EOAs. These accounts can send transactions to other EOAs or contract accounts. Another type of accounts support by second generation programmable Blockchain platforms are the Contract Accounts 108 . A Contract Account 108 is created and owned by an EOA 110 , is located at a contract address 112 , and is controlled by the associated contract code 114 which is stored with the contract account 108 . Additionally, the contract account 108 may comprise a balance 116 , which may be identical to the balance 106 of the EOA 110 . The contract code 114 execution is triggered by transactions 118 sent by EOAs or messages sent by other contracts.

Referring now to FIG. 2 , for example, and without limitation, a structure of blockchain is described in more detail. A blockchain comprises a sequence of

blocks

150 , 152 , 154 generated after block intervals

192 , 194 , where each block is identified by its cryptographic hash (the nonce field) 178 and references the hash of its parent block. The cryptographic hash of a block is used to verify that a sufficient amount of computation has been carried out on this block and the block contains a valid proof-of-work (PoW). Each block maintains records of all the transactions on the network received since the creation of its previous block. Instead of storing the information on all the transactions within the block itself, a special data structure called a Merkle tree is used to store the transactions and only the hash of the root of the Merkle tree is stored in the block. A block header 160 has the following fields:

Block Number (number) 164 : This is a scalar value equal to the number of ancestors of the block. For genesis block, the block number is zero. Timestamp (timestamp) 180 : This is the UNIX timestamp value at the creation of the block. Nonce (nonce) 178 : The nonce field is a 64-bit hash, which along with mixhash field is used to verify that a sufficient amount of computation has been carried out on this block, and the block contains a valid proof-of-work (PoW). Mix Hash (mixhash) 166 : The mixhash field is a 256-bit hash, which along with nonce field is used to verify that the block contains a valid proof-of-work.

CLAIMS

Claims ( 38 )

1 . (canceled)

2 . (canceled)

3 . (canceled)

4 . (canceled)

5 . (canceled)

6 . (canceled)

7 . (canceled)

8 . (canceled)

9 . (canceled)

10 . (canceled)

11 . (canceled)

12 . (canceled)

13 . (canceled)

14 . (canceled)

15 . (canceled)

16 . (canceled)

17 . (canceled)

18 . (canceled)

19 . (canceled)

20 . (canceled)

21 . A method of performing cross-chain blockchain transactions comprising:

receiving a first transaction request on a first blockchain network, the first transaction request comprising:

a transaction value expressed in terms of at least one of a first quantity of a first cryptocurrency and a first token; and

a sending address, the sending address being a wallet on the first blockchain network;

a receiving address, the receiving address being a wallet on a second blockchain network;

executing a first bridge smart contract on the first blockchain network operable to:

lock the at least one of the first quantity of the first cryptocurrency and the first token owned by the sending address; and

upon receiving an indication of burning, unlock the first quantity of the first cryptocurrency;

executing a second bridge smart contract on the second blockchain network, the second bridge smart contract being operable to:

create at least one of a second quantity of a second cryptocurrency and a second token on the second blockchain network, the at least one of the second cryptocurrency and the second token being credited to the receiving address and having a value derived from the transaction value of the first transaction request;

burn the at least one of the second quantity of the second cryptocurrency and the second token; and

send an indication to the first bridge smart contract the burning of the at least one of the second quantity of the second cryptocurrency and the second token.

22 . The method of claim 21 wherein a node on a third blockchain network owns the first bridge smart contract and the second bridge smart contract.

23 . The method of claim 21 wherein settlement of the first transaction is performed on at least one of the first blockchain network and the second blockchain network.

24 . The method of claim 21 wherein settlement of the first transaction is performed on neither of the first blockchain network and the second blockchain network.

25 . A method of performing cross-chain blockchain transactions comprising:

executing a first bridge smart contract on a first blockchain network operable to lock at least one of a first quantity of a first cryptocurrency owned by a sending address on the first blockchain network and a first token owned by the sending address; and executing a second bridge smart contract on a second blockchain network operable to create at least one of a second quantity of a second cryptocurrency and a second token, the at least one of the second cryptocurrency and the second token being credited to a receiving address on the second blockchain network and having a value derived from the at least one of the first quantity of the first cryptocurrency and the first token.

26 . The method of claim 25 wherein:

the second bridge smart contract is further configured to:

burn the at least one of the second quantity of the second cryptocurrency and the second token; and

indicate to the first bridge smart contract the burning of the at least one of the second quantity of the second cryptocurrency and the second token; and

the first contract is further configured to, upon receiving the indication of burning from the second bridge smart contract, unlock the first quantity of the first cryptocurrency.

27 . The method of claim 26 wherein a node on a third blockchain network owns the first bridge smart contract and the second bridge smart contract.

28 . The method of claim 25 wherein the first bridge account and the second bridge account are owned by a blockchain node on a third blockchain network.

29 . The method of claim 25 wherein settlement of the first transaction is performed on at least one of the first blockchain network and the second blockchain network.

30 . The method of claim 25 wherein settlement of the first transaction is performed on neither of the first blockchain network and the second blockchain network.

31 . The method of claim 25 further comprising receiving a first transaction request on the first blockchain network, the first transaction request comprising:

a transaction value expressed in terms of the at least one of the first quantity of the first cryptocurrency and the first token;

the sending address, the sending address being a wallet on the first blockchain network; and

the receiving address, the receiving address being a wallet on a second blockchain network.

32 . A server of performing cross-chain blockchain transactions comprising:

a data processing apparatus; and a computer-accessible medium having software stored thereon that is executable by the data processing apparatus, the software being configured to:

transmit instructions to a first blockchain network to execute a first bridge smart contract on the first blockchain network operable to lock at least one of a first quantity of a first cryptocurrency owned by a sending address on the first blockchain network and a first token owned by the sending address on the first blockchain network; and

transmit instructions to a second blockchain network to execute a second bridge smart contract on the second blockchain network operable to create at least one of a second quantity of a second cryptocurrency and a second token. the at least one of the second cryptocurrency and the second token being credited to a receiving address on the second blockchain network and having a value derived from a value of the at least one of the first quantity of the first cryptocurrency and the first token.

33 . The server of claim 32 wherein:

the instruction to execute the second bridge smart contract are further configured to make the second bridge smart contract operable to:

burn the at least one of the second quantity of the second cryptocurrency and the second token; and

indicate to the first bridge smart contract the burning of the at least one of the second quantity of the second cryptocurrency and the second token; and

the instruction to execute the first contract are further configured to make the first bridge smart contract operable to, upon receiving the indication of burning from the second bridge smart contract, unlock the first quantity of the first cryptocurrency.

34 . The server of claim 33 wherein the server is a node on a third blockchain network and owns the first bridge smart contract and the second bridge smart contract.

35 . The server of claim 32 wherein the server is a node on a third blockchain network and owns the first bridge smart contract and the second bridge smart contract.

36 . The server of claim 32 wherein the software is configured to execute the first bridge smart contract responsive to receiving a first transaction request on the first blockchain network related to a first transaction, the first transaction request comprising:

a transaction value expressed in terms of the at least one of the first quantity of the first cryptocurrency and the first token; and

the sending address, the sending address being a wallet on the first blockchain network; and

the receiving address, the receiving address being a wallet on the second blockchain network.

37 . The server of claim 36 wherein settlement of the first transaction is performed on at least one of the first blockchain network and the second blockchain network.

38 . The server of claim 36 wherein settlement of the first transaction is performed on neither of the first blockchain network and the second blockchain network.

US17/823,532

2017-04-12

2022-08-31

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

Pending

US20240427796A1

( en )

Priority Applications (1)

Application Number

Priority Date

Filing Date

Title

US17/823,532

US20240427796A1

( en )

2017-04-12

2022-08-31

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

Applications Claiming Priority (12)

Application Number

Priority Date

Filing Date

Title

US201762484555P

2017-04-12

2017-04-12

US201762557820P

2017-09-13

2017-09-13

US201862618784P

2018-01-18

2018-01-18

US201862620616P

2018-01-23

2018-01-23

US15/942,604

US10102265B1

( en )

2017-04-12

2018-04-02

Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing

US16/119,163

US10289631B2

( en )

2017-04-12

2018-08-31

Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing

US16/127,283

US10243743B1

( en )

2017-09-13

2018-09-11

Tokens or crypto currency using smart contracts and blockchains

US16/135,701

US10255342B2

( en )

2017-04-12

2018-09-19

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US16/375,351

US10459946B2

( en )

2017-04-12

2019-04-04

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US16/564,063

US10579643B2

( en )

2017-04-12

2019-09-09

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US202117452839A

2021-10-29

2021-10-29

US17/823,532

US20240427796A1

( en )

2017-04-12

2022-08-31

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

Related Parent Applications (1)

Application Number

Title

Priority Date

Filing Date

US202117452839A

Continuation

2017-04-12

2021-10-29

Publications (1)

Publication Number

Publication Date

US20240427796A1

true

US20240427796A1 ( en )

2024-12-26

Family

ID=64999002

Family Applications (5)

Application Number

Title

Priority Date

Filing Date

US16/135,701

Active

US10255342B2

( en )

2017-04-12

2018-09-19

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US16/136,637

Active

US10204148B2

( en )

2017-04-12

2018-09-20

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US16/375,351

Active

US10459946B2

( en )

2017-04-12

2019-04-04

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US16/564,063

Active

US10579643B2

( en )

2017-04-12

2019-09-09

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US17/823,532

Pending

US20240427796A1

( en )

2017-04-12

2022-08-31

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

Family Applications Before (4)

Application Number

Title

Priority Date

Filing Date

US16/135,701

Active

US10255342B2

( en )

2017-04-12

2018-09-19

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US16/136,637

Active

US10204148B2

( en )

2017-04-12

2018-09-20

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US16/375,351

Active

US10459946B2

( en )

2017-04-12

2019-04-04

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

US16/564,063

Active

US10579643B2

( en )

2017-04-12

2019-09-09

Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing

Country Status (1)

Country

Link

US

( 5 )

US10255342B2

( en )

Cited By (1)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20230412393A1

( en )

*

2022-06-17

2023-12-21

Forte Labs, Inc.

Multisignature Custody of Digital Assets

Families Citing this family (173)

* Cited by examiner, † Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US8874477B2

( en )

2005-10-04

2014-10-28

Steven Mark Hoffberg

Multifactorial optimization system and method

WO2018201147A2

( en )

*

2017-04-28

2018-11-01

Neuromesh Inc.

Methods, apparatus, and systems for controlling internet-connected devices having embedded systems with dedicated functions

CN110915188B

( en )

*

2017-06-30

2023-04-04

区块链控股有限公司

Method and system for efficiently propagated probabilistic relays in blockchain networks

US12184781B2

( en )

2017-07-10

2024-12-31

Burstiq, Inc.

Systems and methods for accessing digital assets in a blockchain using owner consent contracts

US11238164B2

( en )

*

2017-07-10

2022-02-01

Burstiq, Inc.

Secure adaptive data storage platform

US20190066068A1

( en )

*

2017-08-22

2019-02-28

Sap Se

Transaction Platform Providing Unified Interaction with Multiple Heterogeneous Blockchains

US20190066101A1

( en )

*

2017-08-22

2019-02-28

Sap Se

Transaction Platform Providing Unified View on Multiple Heterogeneous Blockchains

US10896418B2

( en )

*

2017-12-29

2021-01-19

Ebay Inc.

Secure management of data files using a blockchain

US12481987B2

( en )

*

2018-01-21

2025-11-25

CipherTrace, Inc

Verification systems for blockchains and distributed ledgers

US11251937B2

( en )

*

2018-01-21

2022-02-15

CipherTrace, Inc.

Distributed security mechanism for blockchains and distributed ledgers

WO2019144156A1

( en )

*

2018-01-22

2019-07-25

Blend Labs, Inc.

Method and apparatus for a consumer controlled, decentralized financial profile

US20190287099A1

( en )

*

2018-03-18

2019-09-19

James Tan

Distributed ledger update method

US20190306235A1

( en )

*

2018-03-27

2019-10-03

Makecents Llc

Private Blockchain With Decentralized External Gateway

CN108650182B

( en )

*

2018-04-20

2020-09-25

腾讯科技(深圳)有限公司

Network communication method, system, device, equipment and storage medium

CN108647968A

( en )

2018-05-10

2018-10-12

阿里巴巴集团控股有限公司

A kind of block chain data processing method, device, processing equipment and system

CN108632045A

( en )

2018-05-10

2018-10-09

阿里巴巴集团控股有限公司

A kind of block chain data processing method, device, processing equipment and system

US11836718B2

( en )

2018-05-31

2023-12-05

CipherTrace, Inc.

Systems and methods for crypto currency automated transaction flow detection

US10409783B1

( en )

2018-06-06

2019-09-10

Capital One Services, Llc

Distributed work data management

US10771240B2

( en )

*

2018-06-13

2020-09-08

Dynamic Blockchains Inc

Dynamic blockchain system and method for providing efficient and secure distributed data access, data storage and data transport

JP7073977B2

( en )

*

2018-08-09

2022-05-24

日本電信電話株式会社

Message information management system, message information management method, message information management device and message information management program

US11233648B2

( en )

*

2018-09-04

2022-01-25

Microsoft Technology Licensing, Llc

Identity system for use with blockchain platform

US10893123B2

( en )

*

2018-09-05

2021-01-12

Moac Block Chain Tech Inc.

Apparatus and method for flexible access control and resource control in a decentralized system

US11803664B2

( en )

2018-10-09

2023-10-31

Ebay Inc.

Distributed application architectures using blockchain and distributed file systems

EP3637673B1

( en )

*

2018-10-10

2022-02-02

Sap Se

Secure data sharing

US10841213B2

( en )

*

2018-10-15

2020-11-17

Moac Blockchain Tech Inc

Apparatus and method for communication between chains in a decentralized system

KR102519646B1

( en )

*

2018-10-26

2023-04-06

삼성에스디에스 주식회사

Method for sharing information based on anchoring and anchoring apparatus supporting the same

US11100090B2

( en )

*

2018-11-06

2021-08-24

International Business Machines Corporation

Offloaded chaincode execution for a database

US11546373B2

( en )

2018-11-20

2023-01-03

CipherTrace, Inc.

Cryptocurrency based malware and ransomware detection systems and methods

CN110020945B

( en )

*

2018-11-27

2020-10-30

创新先进技术有限公司

A data reading method and system based on multiple blockchain networks

CN110060153B

( en )

*

2018-11-27

2020-11-17

创新先进技术有限公司

Data evidence storage method and system based on multiple block chain networks

EP3891687A1

( en )

*

2018-12-05

2021-10-13

Telefonaktiebolaget Lm Ericsson (Publ)

Method and system for determining a state of an account in a network device running a light client protocol of a distributed ledger technology network

US11080403B1

( en )

*

2018-12-19

2021-08-03

Hewlett-Packard Development Company, L.P.

Securely constructing a trusted virtual environment

US10861008B2

( en )

2018-12-21

2020-12-08

Capital One Services, Llc

System and method for optimizing cryptocurrency transactions

US10637644B1

( en )

*

2018-12-21

2020-04-28

Capital One Services, Llc

System and method for authorizing transactions in an authorized member network

US11108559B2

( en )

*

2019-01-02

2021-08-31

International Business Machines Corporation

Producing proof of receipt, existence and other data provenance evidence

WO2020144022A1

( en )

*

2019-01-09

2020-07-16

British Telecommunications Public Limited Company

Probabilistic shared secret validation

CN111475309A

( en )

*

2019-01-24

2020-07-31

北京京东尚科信息技术有限公司

Data processing method, device, block chain service system and storage medium

CN109829718B

( en )

*

2019-01-30

2022-12-23

缀初网络技术(上海)有限公司

Block chain multi-level framework based on storage application scene and operation method thereof

CN109949156B

( en )

*

2019-02-28

2024-03-01

矩阵元技术(深圳)有限公司

Data processing method and server of blockchain contracts

US10425230B1

( en )

*

2019-03-01

2019-09-24

Capital One Services, Llc

Identity and electronic signature verification in blockchain

US10911523B2

( en )

*

2019-03-18

2021-02-02

Microsoft Technology Licensing, Llc

Broadcast intent signaling using a decentralized network

AU2019204730C1

( en )

2019-04-03

2021-04-29

Advanced New Technologies Co., Ltd.

Processing and storing blockchain data under a trusted execution environment

RU2706183C1

( en )

*

2019-04-11

2019-11-14

Алексей Владиславович Потанин

Method of fixing data associated with production and sale of products, and corresponding system

US20200334677A1

( en )

*

2019-04-16

2020-10-22

Nokia Solutions And Networks Oy

Transparent blockchain sidechains to support blockchain processing heterogeneity

CN110071969B

( en )

*

2019-04-17

2021-11-30

杭州云象网络技术有限公司

Data security sharing method based on multi-chain architecture

CN111768202B

( en )

*

2019-04-24

2024-06-18

北京京东尚科信息技术有限公司

A payment verification method, payment verification node, full node and storage medium

US11995647B2

( en )

*

2019-04-30

2024-05-28

Salesforce, Inc.

System and method of providing interoperable distributed and decentralized ledgers using consensus on consensus and delegated consensus

US11551216B2

( en )

2019-05-01

2023-01-10

Sony Corporation

Transaction security on distributed-ledger based MaaS platform

US11526487B2

( en )

*

2019-05-17

2022-12-13

International Business Machines Corporation

Database world state integrity validation

US11204933B2

( en )

*

2019-05-23

2021-12-21

Advanced New Technologies Co., Ltd.

Data manipulation record storage method, system, apparatus, and device

US11501269B1

( en )

2019-05-28

2022-11-15

Hiro Systems Pbc

Decentralized fair mining pools

US11290280B1

( en )

*

2019-05-28

2022-03-29

Hiro Systems Pbc

Cryptocurrency mining using a single-leader election algorithm

PH12021553118A1

( en )

*

2019-06-13

2022-08-01

Gutierrez Sheris Luis Eduardo

System and method using a fitness-gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records

CN110190971B

( en )

*

2019-06-27

2022-03-15

浪潮卓数大数据产业发展有限公司

JWT token authentication method based on block chain

CN112003703B

( en )

*

2019-06-28

2023-08-22

创新先进技术有限公司

A method and device for sending certifiable messages across chains

US11336451B2

( en )

*

2019-06-28

2022-05-17

Advanced New Technologies Co., Ltd.

Cross-blockchain resource transmission

US11356282B2

( en )

*

2019-06-28

2022-06-07

Advanced New Technologies Co., Ltd.

Sending cross-chain authenticatable messages

US11251966B2

( en )

2019-06-28

2022-02-15

Advanced New Technologies Co., Ltd.

Sending cross-chain authenticatable messages

SG11202002017YA

( en )

2019-07-11

2020-04-29

Alibaba Group Holding Ltd

Shared blockchain data storage

SG11202001975SA

( en )

*

2019-07-11

2020-04-29

Alibaba Group Holding Ltd

Shared blockchain data storage

CN111448781B

( en )

2019-07-11

2022-08-26

创新先进技术有限公司

Computer-implemented method for communicating shared blockchain data

MY192336A

( en )

2019-07-23

2022-08-17

Advanced New Technologies Co Ltd

Managing transactions on blockchain networks

CN114341906A

( en )

*

2019-08-09

2022-04-12

谷本広志

Program, challenge support system, challenge support method, and terminal

US11556909B2

( en )

2019-08-16

2023-01-17

Visa International Service Association

Universal payment channels

US12238209B2

( en )

2019-08-16

2025-02-25

Visa International Service Association

Conditional offline interaction system and method

CN110597907B

( en )

*

2019-09-10

2021-10-29

腾讯科技(深圳)有限公司

Cross-blockchain data information synchronization method, device, device and medium

US11902456B2

( en )

*

2019-09-11

2024-02-13

Visa International Service Association

Blockchain sharding with adjustable quorums

US11228452B2

( en )

2019-09-16

2022-01-18

Cisco Technology, Inc.

Distributed certificate authority

US12081672B2

( en )

*

2019-09-17

2024-09-03

Micron Technology, Inc.

Distributed ledger appliance and methods of use

CN110659907B

( en )

*

2019-09-24

2021-11-12

北京海益同展信息科技有限公司

Method and device for executing intelligent contracts

US11954681B2

( en )

*

2019-09-30

2024-04-09

Southeast University

Blockchain-enhanced open internet of things access architecture

CN113329031B

( en )

*

2019-10-10

2023-06-13

深圳前海微众银行股份有限公司

A method and device for generating a state tree of a block

US11403283B2

( en )

2019-10-15

2022-08-02

Sony Corporation

Distributed ledger based generation of electronic documents

CN110737664B

( en )

*

2019-10-21

2022-11-25

深圳前海微众银行股份有限公司

Method and device for synchronizing block chain link points

US12155764B2

( en )

2019-10-29

2024-11-26

International Business Machines Corporation

Optimal endorser node determination based on state

PL4032052T3

( en )

*

2019-11-08

2024-10-28

Algorand Labs S.r.l.

Performing transactions using private and public blockchains

US11720526B2

( en )

2019-11-12

2023-08-08

ClearTrace Technologies, Inc.

Sustainable energy tracking system utilizing blockchain technology and Merkle tree hashing structure

US20220405765A1

( en )

*

2019-11-18

2022-12-22

Omnibek Ip Holding Llc

Know your customer (kyc) and anti-money laundering (aml) verification in a multi-decentralized private blockchains network

US11354198B2

( en )

*

2019-11-19

2022-06-07

International Business Machines Corporation

Snapshot for world state recovery

CN111080290B

( en )

*

2019-11-19

2023-05-26

杭州趣链科技有限公司

A blockchain transaction execution and data storage method based on account classification

CN110889763B

( en )

*

2019-11-21

2023-05-23

云南经济管理学院

A financial management system based on big data

CN110866830B

( en )

*

2019-11-25

2024-08-23

腾讯科技(深圳)有限公司

A data processing method and related device based on blockchain

US11138576B2

( en )

*

2019-11-25

2021-10-05

Mastercard International Incorporated

Method and system for net settlement of withheld funds via blockchain

US11563679B1

( en )

2019-12-12

2023-01-24

Architecture Technology Corporation

Distributed ledger adjustment in response to disconnected peer

KR102541781B1

( en )

*

2019-12-26

2023-06-08

서강대학교 산학협력단

Method for enhancing the throughput of a blockchain network

CN111080298B

( en )

*

2019-12-26

2023-12-29

电子科技大学

Block generation and transaction verification method suitable for energy block chain

CN111046109B

( en )

*

2019-12-27

2023-09-15

深圳市迅雷网络技术有限公司

A cross-chain task processing method, device, equipment and readable storage medium

US11475453B2

( en )

2019-12-31

2022-10-18

Capital One Services, Llc

System and techniques for utilizing a smart contracts library

CN111241069B

( en )

*

2020-01-19

2023-10-20

上海墨珩网络科技有限公司

Block chain-based data flattening method and system

US12099997B1

( en )

2020-01-31

2024-09-24

Steven Mark Hoffberg

Tokenized fungible liabilities

SG11202013213UA

( en )

*

2020-02-03

2021-01-28

Alipay Hangzhou Inf Tech Co Ltd

Blockchain-Based Trustable Guarantees

EP3799643B1

( en )

*

2020-02-03

2023-11-08

Alipay (Hangzhou) Information Technology Co., Ltd.

Blockchain-based trustable guarantees

SG11202013145YA

( en )

*

2020-02-03

2021-01-28

Alipay Hangzhou Inf Tech Co Ltd

Blockchain-based trustable guarantees

CN111418184B

( en )

*

2020-02-03

2022-09-09

支付宝(杭州)信息技术有限公司

Blockchain-based Trusted Guarantee

SG11202012851YA

( en )

*

2020-02-03

2021-01-28

Alipay Hangzhou Inf Tech Co Ltd

Blockchain-based trustable guarantees

EP3799644B1

( en )

*

2020-02-03

2022-11-02

Alipay (Hangzhou) Information Technology Co., Ltd.

Blockchain-based trustable guarantees

CA3166813A1

( en )

*

2020-02-04

2021-08-12

Greg CHEW

A system and a method for performing atomic swap transactions of digital records among a plurality of distributed databases

CN111258508B

( en )

*

2020-02-16

2020-11-10

西安奥卡云数据科技有限公司

Metadata management method in distributed object storage

CN111309809A

( en )

*

2020-02-19

2020-06-19

财付通支付科技有限公司

Block header storage method and equipment thereof

Related documents

Record · ID 607092
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.