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