US20180300382A1 - Method and System for Tuning Blockchain Scalability for Fast and Low-Cost Payment and Transaction Processing - Google Patents

Method and System for Tuning Blockchain Scalability for Fast and Low-Cost Payment and Transaction Processing Download PDF

Info

Publication number
US20180300382A1
US20180300382A1 US15/942,604 US201815942604A US2018300382A1 US 20180300382 A1 US20180300382 A1 US 20180300382A1 US 201815942604 A US201815942604 A US 201815942604A US 2018300382 A1 US2018300382 A1 US 2018300382A1
Authority
US
United States
Prior art keywords
private
blockchain network
smart contract
block
transactions
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US15/942,604
Other versions
US10102265B1 (en
Inventor
Vijay K. Madisetti
Arshdeep Bahga
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Madisetti Vijay K
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US15/942,604 priority Critical patent/US10102265B1/en
Priority to US16/119,163 priority patent/US10289631B2/en
Assigned to MADISETTI, VIJAY K. reassignment MADISETTI, VIJAY K. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BAHGA, Arshdeep
Priority to US16/135,701 priority patent/US10255342B2/en
Priority to US16/136,637 priority patent/US10204148B2/en
Publication of US10102265B1 publication Critical patent/US10102265B1/en
Application granted granted Critical
Publication of US20180300382A1 publication Critical patent/US20180300382A1/en
Priority to US16/223,237 priority patent/US10394845B2/en
Priority to US16/375,351 priority patent/US10459946B2/en
Priority to US16/564,063 priority patent/US10579643B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G06F17/30575—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0658—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed locally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present invention relates to blockchain-scalability, fast and low-cost payment and transaction processing on blockchain networks.
  • 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.
  • EOAs Externally Owned Account
  • 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.
  • Each Externally Owned Account has a public-private keypair associated with it.
  • the account address is derived from the public key.
  • 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.
  • Blockchain networks 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.
  • 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.
  • Bitcoin network takes 10 minutes or longer to confirm transactions and achieves about 3-7 transactions/sec throughput.
  • Ethereum blockchain network where the block-time is roughly 17 seconds, and achieves about 7-15 transactions/sec throughput.
  • many blockchain applications require multiple confirmations for newly mined blocks to secure the transactions from double-spending.
  • CAP Theorem 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.
  • 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.
  • 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.
  • all the blockchain clients (which may be implemented in different programming languages) are pdated 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.
  • embodiments of the present invention are related to a method of capturing the Decentralization, Scalability and Security (DSS) constraints for blockchain networks.
  • DSS Decentralization, Scalability and Security
  • the method may further comprise quantifying the Decentralization, Scalability and Security levels based on various blockchain parameters.
  • 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.
  • the method may further comprise a unified model for tuning blockchain, without use of hard forks.
  • the method may further comprise creating application-specific blockchain flavors which desired levels of Decentralization, Scalability and Security.
  • the method may further comprise an adaptive tuning approach for blockchain parameters to meet the desired levels of Decentralization, Scalability and Security.
  • 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:
  • 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.
  • 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 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.
  • 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 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.
  • 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
  • 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 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.
  • Further embodiments of the invention may include 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 public 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; performing a synchronization process between the first private smart contract and a smart contract linked to the public blockchain network, defining a public smart contract, the synchronization process including:.
  • the method of synchronizing transactions also includes determining an account on the first private blockchain network that has a token balance decrease, defining a decreasing account.
  • the method of synchronizing transactions also includes 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 of synchronizing transactions also includes determining if a total token supply on the private blockchain network has increased since an immediate previous synchronization process.
  • the method of synchronizing transactions also includes if the total token supply on the private blockchain network has increased, creating new tokens and sending them to the vault account.
  • the method of synchronizing transactions also includes 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 of synchronizing transactions also includes determining an account on the first private blockchain network that has a token balance increase, defining an increasing account.
  • the method of synchronizing transactions also includes 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 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 public 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 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 of synchronizing transactions also includes where the first private smart contract is a multi-signature smart contract including a plurality of signatures, each signature being associated with a user.
  • 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 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 public 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.
  • Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.
  • FIG. 1 For embodiments of the invention, may include a system for synchronizing transactions between private and public blockchains including: a processor.
  • the system also includes a data store positioned in communication with the processor.
  • the system also includes a network communication device positioned in communication with each of the processor, the data store, and a network.
  • the system also includes where the network communication device is operable to receive a first plurality of transactions on a first private blockchain network.
  • the processor is operable to record the first plurality of transactions to a first private block on the first private blockchain network.
  • the system also includes where the network communication device is operable to receive a second plurality of transactions on the first private blockchain network.
  • the system also includes where the processor is operable to record the second plurality of transactions to a second private block on the first private blockchain network.
  • the system also includes where the processor is operable to generate a first merged block including the first private block and the second private block.
  • the system also includes where the processor is operable to record the first merged block to a single block on a second blockchain network.
  • the system also includes where the processor is operable to record 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 system also includes where the processor is operable to perform 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 system also includes where the processor is operable to perform 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 system 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.
  • inventions 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.
  • 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.
  • DSS Decentralization, Scalability and Security
  • 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.
  • 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.
  • EOAs Externally Owned Account
  • 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 .
  • 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.
  • 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).
  • PoW proof-of-work
  • 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.
  • Parent Hash (prevhash) 162 Each block in a blockchain is linked to its parent through the parentHash, which is the hash of the parent block header.
  • Coinbase Address (coinbase) 182 This is a 20-byte address of the account to which all the rewards for mining of the block and the execution of contracts are transferred.
  • Block Difficulty (difficulty) 168 This field specifies a difficulty value for mining. A block is valid only if it contains a valid proof-of-work (PoW) of a given difficulty.
  • PoW proof-of-work
  • Gas Limit (gas_limit) 184 The gas limit value is the limit of gas expenditure for the block.
  • Gas Used (gas_used) 186 This is the total gas used for all the transactions in the block.
  • Extra Data (extra_data) 170 Optional 32-byte extra data can be provided in the block.
  • State Root (state_root) 174 This is the 32 byte hash of the root of the block's state trie after the transactions are executed.
  • Transactions List Root (tx_list_root) 176 This is the 32 byte hash of the root of the block's transaction trie which is populated with the transactions in the block.
  • Receipts Root (receipts_root) 190 This is the 32 byte hash of the root of the block's receipts trie which is populated with the receipts of the transaction in the transactions list of the block.
  • Bloom Filter (bloom) 172 Bloom filter composed from the set of logs created through execution of the transactions in the block.
  • Each of the block headers 156 , 158 may comprise the above-recited fields.
  • DSS Decentralization, Scalability and Security
  • the DSS theorem states that it is impossible to simultaneously provide high levels of Decentralization, Scalability and Security (DSS) for blockchain networks.
  • DSS Decentralization, Scalability and Security
  • L D Decentralization
  • L Sc Scalability
  • L Se Security
  • DSS Decentralization, Scalability and Security
  • the level of Decentralization (L D ) is quantified in terms of the following blockchain parameters 250 :
  • N T Total number of nodes in the network 256 ;
  • N P Number of peers connected to each node 258 ;
  • B p Minimum bandwidth required by a node to mine on the network 260 ;
  • C p Minimum processing power required by a node to mine on the network 262 ;
  • D p Minimum disk I/O required by a node to mine on the network 264 ;
  • M p Minimum memory required by a node to mine on the network 268 ;
  • T bs Bootstrap time for a node to start mining 270 .
  • L D The level of Decentralization
  • the level of Scalability (L Sc ) is quantified in terms of the following blockchain parameters 252 :
  • T tx Transaction latency 274 .
  • L Sc The level of Scalability (L Sc ) is specified as:
  • the level of Security (L Se ) is quantified in terms of the following blockchain parameters 254 :
  • T bp Block propagation delay 278 .
  • L Se The level of Security
  • the unified model and protocol for tuning blockchain provides a standardized way of comparing various blockchain scalability approaches. With this model we can quantify the benefits of various scaling approaches in the form of DSS levels (where each level is on the scale of 0 to 10).
  • the DSS model 300 can be created by learning the dependencies between DSS levels based on experimental measurement of the various blockchain parameters for a blockchain network.
  • Each blockchain network has its own DSS model.
  • the DSS model is dependent on the blockchain technology or platform (such as Bitcoin, Ethereum) and also its network deployment (e.g. public unpermissioned or private permissioned).
  • the tuning process involves providing the blockchain tuning parameters as input 302 to the DSS model 300 for a blockchain network.
  • the output 304 of the DSS model are the levels of decentralization (L D ) 306 , scalability (L Sc ) 308 and security (L se ) 310 , where the levels are related according to equation 312, with L Sc 308 being inversely proportional to L D 306 which is in turn inversely proportional to L se 310 .
  • the tuning is also especially useful when nodes in the blockchain network fail or the network may be partitioned so that reallocation of work may be suitably done.
  • the DSS theorem described above is compatible with and complimentary to a consistency, availability and partition tolerance (CAP) theorem applied to a blockchain network.
  • CAP consistency, availability and partition tolerance
  • a blockchain network is always be available and eventually-consistent.
  • a blockchain network cannot simultaneously have high levels of Decentralization, Scalability and Security.
  • the levels of Decentralization, Scalability and Security for blockchain networks are tunable subject to the DSS constraints.
  • Blockchain platforms may use different consensus mechanisms, blockchain designs or parameters to tune the consistency, availability and partition-tolerance of the blockchain network. With a DSS model for a blockchain network, it is possible to quantify the effects of various consensus mechanisms, blockchain designs or parameters on the decentralization, scalability and security of the blockchain network.
  • the DSS unified model described above allows creating application-specific blockchain flavors, which use the same blockchain technology or platform but differ only in the blockchain parameters.
  • the Ethereum blockchain platform can be used to create multiple blockchain networks or deployments, where each network may have a different level of decentralization, scalability and security based on the business or application requirements.
  • the adaptive tuning method starts at step 380 with fixing the DSS levels for a blockchain based on application requirements. For example if a blockchain is to be used for applications requiring high transaction throughput, the scalability levels may be fixed to higher levels (such as 8-10) while the security and decentralization levels may be fixed to relatively lower levels (such as 4-6).
  • step 382 use DSS model for the blockchain is used to determine the values of blockchain parameters required to meet the required DSS levels.
  • the blockchain can be setup with these values of blockchain parameters.
  • the performance of the blockchain and its various metrics are monitored continuously, at step 384 , through specialized control packets/messages that request Quality of Performance (QoP) values that are measured throughout the network, and based on this a decision can be made to initiate, stop, or rollback adaptive tuning processes, so that the system is efficient and consistent.
  • QoP Quality of Performance
  • the target DSS levels may be identified from the DSS model for the blockchain network.
  • a check is performed if the DSS levels deviate from the desired levels. If the DSS levels deviate from the desired levels, the blockchain parameters are tuned, at step 390 , to meet the desired DSS levels.
  • the GetQoP message 400 may comprise a Message ID 408 and is used to request the QoP metrics for the specified metric-IDs 410 , 412 , 414 .
  • the response to a GetQoP message is a QoP message 402 which contains a Message ID 416 , metric-IDs requested and their values 418 , 420 , 422 .
  • the DSS model is used at regular intervals of time to compute the current DSS levels. If the current DSS levels deviate from the desired levels, the blockchain parameters can be tuned to meet the desired DSS levels.
  • the system can rollback to previous parameters sets that were check-pointed or stored (with in an incremental manner or in an absolute manner; a choice that is related to storage and security requirements).
  • An embodiment of the invention provides 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.
  • the supervisor nodes hold a stake in the blockchain network. The stake can be in the form of a bond.
  • the supervisor nodes monitor the blockchain network performance and decide how to adjust the blockchain parameters, based on the adaptive tuning approach described above.
  • the parameter update announcements are issued after the supervisor nodes come to a consensus on the updates to be made to the parameters. Once the supervisor nodes come to a consensus on an update, one of the supervisor nodes is randomly chosen to create an announcement message.
  • the announcement message is signed by the supervisor node's private key.
  • the supervisor can also rollback or cancel the update to the last check-pointed state. These changes can be made as extensions to existing protocols, such as but not limited to Ethereum Wire Protocol, RLPx, Whisper, or SNMP and its variants.
  • the NewTuningAnnoucement message 404 is used to announce an update to the tuning parameters. This message contains a Message ID 416 , an announcement number 426 , the address of the supervisor node issuing the announcement 428 , and the tuning parameter IDs and the respective values 430 , 432 .
  • a supervisor can issue a RollbackTuningAnnouncement 406 which contains a Message ID 434 , the number of the announcement message 436 , which is rolled back, and the issuing supervisor node address 438 .
  • the announcement messages are transmitted over the blockchain wire protocol (like other messages such as new block announcements).
  • the underlying network and transport protocol allows the integrity of the announcement messages to be verified. Integrity verification is performed by recovering the public key from the signature and matching it with the expected value, for instance.
  • the nodes in a blockchain network may continue to process the transactions while the announcement messages are propagated through the network.
  • a blockchain design comprising two types of blocks—normal blocks and microblocks, is presented.
  • Normal blocks such as 500 , 502 are created by the miners on the blockchain network and require proof-of-work mining separated by a block interval 506 .
  • a block is cryptographically secured by a nonce that proves that a certain amount of work was done to find the nonce input to the PoW algorithm.
  • the normal blocks represents an eventually consistent state of the network, or points of consensus in the network.
  • Micro-blocks, such as 504 are generated in the block-interval between two normal-blocks.
  • Micro-blocks are created by a bonded-validator chosen by the network.
  • micro-blocks There is no mining involved in creation of micro-blocks.
  • the validator chosen after each normal block is created generates micro-blocks by validating the transactions received after the creation of the last normal block and updates the state. Since no proof-of-work computation is involved, micro-blocks can be created at a very fast rate. Micro-blocks increase transaction throughput and reduce transaction latency in a blockchain network. The micro-block size and micro-block interval can be tuned.
  • the structure of normal blocks is similar to the blocks in existing second generation blockchain networks such as Ethereum.
  • Micro-Block Number (number) 564 This is the number of the micro-block.
  • Timestamp (timestamp) 556 This is the UNIX timestamp value at the creation of the block.
  • Parent Hash (prevhash) 554 : Hash of the parent block header.
  • Validator Address (address): This is the address of the account the validator who created the micro-block.
  • Gas Limit (gas_limit) 568 The gas limit value is the limit of gas expenditure for the block.
  • Gas Used (gas_used) 570 This is the total gas used for all the transactions in the block.
  • Extra Data (extra_data) 558 Optional 32-byte extra data can be provided in the block.
  • State Root (state_root) 562 This is the 32 byte hash of the root of the block's state tree after the transactions are executed.
  • Transactions List Root (tx_list_root) 572 : This is the 32-byte hash of the root of the block's transaction tree which is populated with the transactions in the block.
  • Receipts Root (receipts_root) 574 : This is the 32-byte hash of the root of the block's receipts tree which is populated with the receipts of the transaction in the transactions list of the block.
  • Bloom Filter (bloom) 560 Bloom filter composed from the set of logs created through execution of the transactions in the block.
  • Microblocks are generated by a ‘bonded-validator’ chosen by the network. Each validator owns a ‘stake’ in the network in the form of a bond or security-deposit. The validators who post a bond, or in other words, make the security deposit, are called ‘bonded validators’. Given a point of consensus (i.e. a block at a certain height), a validator is randomly selected and assigned the right to create micro-blocks till the next block is mined. The higher the security deposit made by a validator, higher is its probability of being chosen to create the micro-blocks. Validators earn 10 rewards to validating transactions in micro-blocks. Any malicious validator who tries to cheat the network and vote for a microblock with invalid transactions loses its deposit and the right to generate new microblocks.
  • An embodiment of the invention provides a system, protocol, and associated methods for off-chain scaling of a blockchain network 600 .
  • the off-chain scaling method involves one or more permissioned private chains or sub-chains 602 which are linked to the main blockchain through one or more smart contracts 604 .
  • the participants in the blockchain network who need to transact frequently can register themselves on such a private and transact directly with each other rather than sending transactions through the main blockchain.
  • the consensus mechanism in a permissioned private chain is controlled by a pre-selected set of nodes. Due to the permissioned model of consensus in a private chain, the consensus mechanism is much faster than the main blockchain.
  • a private chain can enable micro-transactions between the participants which can be processed much faster.
  • the state of a private chain is regularly checkpointed to the main blockchain through the smart contracts.
  • the main blockchain serves as a ‘summarized’ or ‘abstract’ version of all the private chains linked to it. For example, a single transaction can be created on the main chain which captures the multiple micro-transactions on the private chain 608 , 610 , 612 .
  • the off-chain scaling method involves one super-chain 650 and one or more levels of sub-chains 652 , 654 , 656 .
  • the super-chain acts as summarized version of the level-1 sub-chain.
  • level-(N ⁇ 1) sub-chain acts as a summarized version of the level-N sub-chain.
  • a single block in the super-chain can include summarized transactions from multiple blocks in the sub-chain.
  • a sub-chain can capture the sale of individual items (as micro-transactions) and the super-chain can capture a summary of all the transactions every hour, such that a single transaction is created every hour showing one summary sale of all the items sold in that hour.
  • the DSS unified model can be used to tune to the super-chain and sub-chains to meet the application requirements.
  • Transactions are typically conducted on private permissioned blockchain networks 706 , 708 that may share a global database 700 through a private blockchain database manager/network 718 .
  • Selected (and expensive/infrequent) transactions are checkpointed 716 on the public blockchain 702 .
  • the use of smart contracts allows suitable identification and processing of transactions in private or public blockchains and checkpointing at select times through use of policies that may be dynamically enforced. This approach improves the efficiency, speed and reduces the cost of transactions.
  • the private permissioned blockchain networks 706 , 708 may be used for multiple e-commerce applications, including trading, payments, HR, taxes, auctions, etc.
  • Private permissioned blockchain networks 706 , 708 carry out the majority of the smart contracts and other transactions on the B interfaces 714 , while periodically checkpointing to the Public Blockchain 702 to synchronize some bulk/block transactions. This reduces the costs and tariff incurred if directly using the A Interface 712 for all transactions.
  • FIG. 14 is an illustration of checkpointing process between private and public blockchains with the use of a public-private gateway, are described in more detail.
  • a public-private gateway that interfaces with the e-commerce infrastructure 710 through the C Interface 722 and forwards the transactions to the public blockchain 702 over the A Interface 704 .
  • a User- 1 770 having an account on a public blockchain network- 1 754 sends a payment in a cryptocurrency or token on blockchain network- 1 to User- 2 768 who has an account on a public blockchain network- 2 758 .
  • the public blockchain networks 754 , 758 , 752 each having an associated database 764 , 760 , 762 , interface with a private blockchain network 750 and its database 756 through blockchain bridges. Bridges allow inter-chain blockchain transactions.
  • a blockchain bridge 766 receives transactions from a public blockchain network and forwards the transactions to the connected private blockchain network. Similarly, the transactions received from a private blockchain network are forwarded to the connected private blockchain network.
  • a bridge 804 connects two blockchain networks 800 , 802 and allows transactions to be forwarded from one blockchain network to another.
  • a bridge 804 may be implemented through a combination of blockchain accounts 812 , 810 , and smart contracts 806 , 808 , on the connected blockchain networks 800 , 802 , with on-chain or off-chain payment settlements 814 between the blockchain accounts.
  • User- 1 856 and User- 2 860 have accounts on a private and permissioned blockchain network 850 and a public blockchain network 852 .
  • the private and permissioned blockchain network 850 is used for frequent transactions between the users 856 , 860 .
  • the transactions are processed fast and with low fees on the private and permissioned blockchain network 850 .
  • the transactions between the users 856 , 860 are checkpointed 858 on the public blockchain network 852 at regular intervals.
  • a third blockchain network 854 may be may be used for user identity and access management.
  • User-A 902 , User-B 904 , User-C 906 , User-D 908 all have starting balances of 100 (in a certain cryptocurrency or a token which can be transacted on a private blockchain network).
  • the table 900 shows examples of transactions that transfer value between the users. After the transactions in table 900 are processed, the ending balance of the User-A is 108, User-B is 107, User-C is 98 and User-D is 87.
  • the transactions on the private blockchain network as shown in table 900 between the same pair of users are merged yielding a combined transactions 922 .
  • the merged transactions as shown in table 920 are sent to the public blockchain network.
  • the values of the starting and ending balances of User-A 902 , User-B 904 , User-C 906 , User-D 908 for the transactions processed on the private blockchain network are the same as the merged transactions processed on the public blockchain network.
  • To prevent double spending from accounts participating in off the public chain transfers i.e.
  • the accounts on the public blockchain can be locked in the time interval between two synchronization points of the private and public chains. This is to prevent the transfer of tokens from accounts on the public chain while there are unsynchronized transactions on the private chain.
  • Smart contracts on the public blockchain can be used for locking the accounts and preventing transfer or withdrawal of tokens while there are unsynchronized transactions on the private chain.
  • Private blockchain network 950 has fast block generation time as a result the transactions can be processed very fast.
  • the consensus mechanism on the private blockchain network 950 can be chosen such that the transaction can be processed with negligible or near zero fees.
  • Public blockchain network 952 has slower block generation time as a result transactions are processed slower on the public blockchain.
  • Public blockchain networks typically have high transaction fees. By merging multiple transaction on the private blockchain into a single transaction on the public blockchain, the effective fees paid per transaction can be lowered.
  • the private blockchain network 954 has fast block generation time (of the order of few milliseconds) and the transactions are processed very fast.
  • the transactions on the private blockchain network 954 (between the same pair of users and received in a given time interval) are merged and sent to the private blockchain network 956 which has slower block generation time (of the order of few seconds) than private blockchain network 954 .
  • the transactions on the private blockchain network 956 (between the same pair of users and received in a given time interval) are merged and sent to the public blockchain network 958 which has slow block generation time (of the order of few minutes) than private blockchain network 954 .
  • the same smart contract (such as an ERC20 token contract) can be deployed on the private and public blockchain networks 1000 , 1002 .
  • the smart contract 1006 on the private blockchain network 1000 is mirrored 1010 as the smart contract 1008 on the public blockchain network 1002 where the transactions on the private blockchain and periodically synchronized and checkpointed on the public blockchain network.
  • the private blockchain network 1000 can process the transactions very fast and with near zero transaction fees. The transactions are periodically combined and sent in the public blockchain network 1002 thus synchronizing the smart contracts on the private and public chains.
  • the sync and checkpointing process 1004 can be triggered at fixed time intervals (such as every few hours) or after fixed number of blocks on the private chain (e.g. after every 100 blocks on the private chain).
  • Private blockchain network 1000 may adopt a different consensus algorithm (such as Proof of Authority or Delegated Proof of Stake) from the public blockchain network 1002 .
  • Private and permissioned blockchain networks 1050 , 1054 , 1056 have the same smart contract deployed at addresses 1068 , 1070 , 1064 and mirrored to the smart contract 1066 deployed on the public blockchain network 1052 .
  • Multiple private and permissioned blockchain networks are used for the purposes of replication, partitioning and transaction speedup. For example, in a payment application, all transactions between a subset- 1 of users can be processed on private and permissioned blockchain network 1050 , whereas transactions between another subset- 2 of users can be processed on the private and permissioned blockchain network 1054 , thus partitioning the transaction processing for the payment application across two blockchain.
  • Another use of having multiple private and permissioned blockchain networks 1050 , 1054 , 1056 to process transactions for an application is that while one network is being synchronized and checkpointed 1058 , 1060 , 1062 with the public blockchain network 1052 , the transactions can be sent to the other private blockchain network to prevent double spending.
  • Transactions sent by users 1082 between private blockchain networks 1000 and public blockchain networks 1002 that are synced and checkpointed 1004 are filtered by a transactions filter 1080 based on the transaction value, sender and receiver information, source of transaction and other meta-data associated with the transaction.
  • the transaction filtering process can segregate the transactions into different classes such as follows:
  • a private blockchain infrastructure comprising a private blockchain network 1104 , a private blockchain database 1100 and a private decentralized storage network 1102 is used. While the private blockchain infrastructure is used for offloading frequent transactions and big data, a public blockchain infrastructure comprising a public blockchain network 1110 , a public blockchain database 1114 and public private decentralized storage network 1116 is used for combined or important or summarized transactions and data. Data can be synchronized and checkpointed 1108 between the private and public blockchain networks 1104 , 1110 .
  • Users 1200 can access the payment application through a mobile or web application 1202 which communicates with the application backend (cloud and blockchain) through APIs.
  • the access to the backend APIs is controlled through the API gateway 1204 .
  • a number of compute instances 1208 , 1210 , 1212 , under one load balancer 1206 may run the application servers.
  • the application data is stored in a replicated master-slave database comprising a master database instance 1214 and a slave database instance 1216 .
  • the application servers process the API requests (such as for transfer of tokens on the blockchain) and post transactions to a private blockchain network 1218 .
  • the compute instances on which such application servers run also have blockchain client applications installed.
  • the blockchain transactions and the state of smart contracts are synchronized and checkpointed 1220 on the public blockchain network 1222 at regular time intervals.
  • Web and mobile applications do not have to be aware of the blockchain platform being used.
  • the web and mobile applications (which are themselves deployed on a server or local machine or device) need not run blockchain clients and synchronize the complete blockchain state to process the blockchain transactions.
  • Transactions can be processed much faster on the private blockchain.
  • the combined transactions and the state of the smart contracts on the private blockchain can be synchronized and checkpointed with the public blockchain at regular intervals in an asynchronous manner without the users having to wait for the transactions to be processed.
  • the API gateway may use a cache to serve data which is requested frequently (such as balances of blockchain accounts or smart contract state variables).
  • the compute instances that run the application servers and blockchain clients may be placed under an auto-scaling group to enable the backend system to scale-up or down automatically based on demand.
  • the database system maintains records of user and transactions data and serves requests from the application servers. This allows users to efficiently query for data such as history of all transactions, user profile data and other application specific data that need not be stored on the blockchain.
  • multi-signature and multi-party smart contracts 1310 , 1312 on multiple private and permissioned blockchains which are synchronized and checkpointed 1324 , 1326 to a single public blockchain and associated smart contracts 1318 , 1320 , are described in more detail.
  • Applications involving multiple parties to smart contracts 1300 , 1302 , 1304 , 1306 , 1308 can leverage private and permissioned blockchain networks 1314 , 1316 for improving scalability, speeding up transactions, and reducing transaction processing fees.
  • LC Letter of Credit
  • SBLC Standby Letters of Credit
  • Each party is represented on the blockchain through a registry smart contract.
  • the parties include a buyer, seller, issuing bank, advising bank and shipping company.
  • These parties are represented on the blockchain through registry contracts such as Buyer Registry Contract 1402 , Seller Registry Contract 1404 , Issuing Bank Registry Contract 1410 , Advising Bank Registry Contract 1412 , Carrier Registry Contract 1400 , Sales Contract 1406 , Letter of Credit Contract 1408 .
  • the multi-signature (multisig) smart contracts 1310 , 1312 on the private and permissioned blockchain networks 1314 , 1316 require multiple parties to sign various transactions sent to these contracts (i.e. M-of-N signatures, such as 1-of-2, 2-of-2, 2-of-3, 3-of-5, 5-of-9).
  • M-of-N signatures such as 1-of-2, 2-of-2, 2-of-3, 3-of-5, 5-of-9.
  • the state of the multisig contracts is synchronized and checkpointed in the equivalent or simplified contracts 1318 , 1320 on the public blockchain network 1322 .
  • the smart contracts capture different steps involved in the trade process and the interaction between the parties. For example, in the Letter of Credit application, the Buyer and Seller have a Sales contract between them.
  • the Issuing Bank sends a Letter of Credit contract to the seller.
  • the Seller ships the goods through the Shipping company and records the shipping information in the Shipping contract.
  • the Seller gets a transport verification message (or documents) which are sent to the Advising bank.
  • the Advising bank sends the transport verification message (or documents) to the Issuing Bank.
  • the Issuing Bank releases the payment and sends the transport verification message (or documents) to the buyer.
  • the buyer takes possession of the goods from the shipping company by presenting the transport verification message (or documents) to the shipping company.
  • the smart contracts allow easier and faster verification of information.
  • the transactions to update the state of smart contracts and messages are cryptographically signed by the concerned parties. Suitable checks in the Letter of Credit and related smart contracts can prevent reuse of the Letter of Credit. Requiring multiple signatures for certain smart contracts (such as Letter of Credit smart contract), can prevent fraud (for example, a bank employee fraudulently issuing a Letter of Credit without verifying buyer's financial standing or collateral). Furthermore, each party involved is aware of the state of the contracts leading to greater transparency in the whole trade process.
  • a system and associated methods for securely linking blockchain accounts to real users as described in related U.S. patent application Ser. No. 15/863,128 titled Method and System for Blockchain-Based Combined Identity, Ownership and Custody Management filed Jan. 5, 2018, the content of which is incorporated herein by reference except to the extent disclosure therein is inconsistent with disclosure herein.
  • a user identity registration and certification procedure is performed that comprises receiving hashed user identification information that has been signed with a private key of the user from the user, defining a seal contract, generating an address of the seal contract, defined as a sealed user record address, and providing the sealed user record address.
  • the procedure may further comprise receiving a hashed verification record from a certificate authority, generating an address of a verification contract from the hashed verification record, defined as a sealed verification record address and providing the sealed verification record address. Furthermore, the procedure may further comprise generating a certification contract from a combination of the sealed user record address, a certification token, and the sealed verification record address, providing a certification contract address, receiving a verification record by a certification authority comprising the hashed user identification information and a token, and receiving a combination of the certification contract address and the seal contract, defining a received certification contract address and a received seal contract, respectively.
  • the procedure may further comprise obtaining each of the sealed user record address and the sealed verification record address from the certification contract address, retrieving the seal contract from the sealed user record address, defining a retrieved seal contract, decrypting the retrieved seal contract using a public key associated with the user, defining a decrypted retrieved seal contract, and comparing the decrypted retrieved seal contract and the received seal contract.
  • the procedure may comprise retrieving the verification contract from the sealed verification record address, defining a retrieved verification contract, obtaining a certification token from the certification contract address, generating a hashed confirming verification record by hashing the combination of the decrypted retrieved seal contract and the certification token, and comparing the hashed confirming verification record to the retrieved verification contract.
  • a session certification token for a decentralized application may be generated.
  • the procedure may comprise transmitting the session certification token to the user.
  • Soft smart contracts are contracts which have multiple variants (for example multiple variants of a Letter of Credit or Sales contract) and a particular variant of a smart contract may be selected based on additional application or trade specific meta-data available (for example, trade process meta-data 1454 such as the countries of the buyer and seller or type of trade).
  • FIG. 29 illustrates a Soft Smart Contract-A 1450 which has multiple variants of smart contracts (Variant- 1 1470 , Variant- 2 1472 , Variant-N 1474 ) and a Soft Smart Contract-B 1452 which has multiple variants of smart contracts (Variant- 1 1476 , Variant- 2 1478 , Variant-N 1480 ).
  • Variant- 1 1462 Variant- 1 1470 of Soft Smart Contract-A 1450 and Variant- 2 1478 of Soft Smart Contract-B 1452 are used.
  • Variant- 2 1464 Variant-N 1474 of Soft Smart Contract-A and Variant- 1 1476 of Soft Smart Contract-B are used.
  • the selection of a particular variant of a soft smart contract is done based on application or process specific meta-data 1454 .
  • the smart contracts for Application/Process- 1 1462 are deployed on private and permissioned blockchain network- 1 1456 .
  • the smart contracts for Application/Process- 2 1464 are deployed on private and permissioned blockchain network- 2 1458 .
  • the state of the smart contracts on the private and permissioned blockchain networks 1456 , 1458 are synchronized and checkpointed 1466 , 1468 in the equivalent or simplified smart contracts the public blockchain network 1460 .
  • the contract syncer service can be run periodically (after few hours or once every day) to sync two token smart contracts deployed on private and public blockchain networks.
  • the syncer service takes as input a list of all accounts on the private that transacted during the day with the token contract.
  • the syncer service syncs the smart contract states by performing the following steps:
  • STEP-1 For all accounts whose token balance has decreased on the private chain as compared to the last synced balance on public chain, move the difference in balance from the corresponding account on public chain to a vault account on public chain.
  • STEP-2 If the total token supply on the private chain has increased since the last synced balance on public chain, create new tokens (equal to the difference of total token supply on private and public chains) and send to vault account on public chain. Whereas, if the total token supply on the private chain has decreased since the last synced balance on public chain, burn tokens (equal to the difference of total token supply on private and public chains) from the vault account on public chain.
  • STEP-3 For all accounts whose token balance has increased on the private chain as compared to the last synced balance on public chain, move the difference in balance from the vault account on public chain to the corresponding account on the public chain.
  • Appendix-A shows the results of a simulation using the syncer service.
  • the transactions are of three types—(1) transaction to create tokens which are credited to an account, (2) transaction to burn tokens from an account, (2) transaction to transfer token from one account to another.
  • Simulation results show transactions on the private chain and public chain, the token balances and total token supply.
  • the state of the token contract on the private chain is synced with the state of the token contract on the public chain at midnight.
  • Simulation results show that a 94% reduction in the number of transactions is achieved for syncing the token smart contract states on the private and public chains.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

A method of synchronizing transactions between blockchains comprising receiving first and second pluralities of transactions on a first private blockchain network and recording them to first and second private blocks on the first private blockchain network, respectively, generating a first merged block comprising the first private block and the second private block and recording the first merged block to a single block on a second blockchain network, recording each of the first and second private blocks and the first merged block to a first private smart contract linked to the first private blockchain network, 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, and performing a checkpointing process between the first private smart contract and the second smart contract. The first private blockchain network has a parameter difference from the second blockchain network.

Description

    RELATED APPLICATIONS
  • This application claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application Ser. No. 62/484,555 filed on Apr. 12, 2017 and titled Method and System for Tuning Blockchain Scalability, and U.S. Provisional Patent Application Ser. No. 62/620,616 filed on Jan. 23, 2018 and titled Fast & Low Cost Payment and Transaction Processing on Blockchain Networks, the entire contents of which 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
  • 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 pdated 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 invention may include 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 public 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; performing a synchronization process between the first private smart contract and a smart contract linked to the public blockchain network, defining a public smart contract, the synchronization process including:. The method of synchronizing transactions also includes determining an account on the first private blockchain network that has a token balance decrease, defining a decreasing account. The method of synchronizing transactions also includes 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 of synchronizing transactions also includes determining if a total token supply on the private blockchain network has increased since an immediate previous synchronization process. The method of synchronizing transactions also includes if the total token supply on the private blockchain network has increased, creating new tokens and sending them to the vault account. The method of synchronizing transactions also includes 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 of synchronizing transactions also includes determining an account on the first private blockchain network that has a token balance increase, defining an increasing account. The method of synchronizing transactions also includes 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 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 public 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 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 of synchronizing transactions also includes where the first private smart contract is a multi-signature smart contract including a plurality of signatures, each signature being associated with a user. 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 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 public 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. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.
  • Further embodiments of the invention may include a system for synchronizing transactions between private and public blockchains including: a processor. The system also includes a data store positioned in communication with the processor. The system also includes a network communication device positioned in communication with each of the processor, the data store, and a network. The system also includes where the network communication device is operable to receive a first plurality of transactions on a first private blockchain network. The system also includes where the processor is operable to record the first plurality of transactions to a first private block on the first private blockchain network. The system also includes where the network communication device is operable to receive a second plurality of transactions on the first private blockchain network. The system also includes where the processor is operable to record the second plurality of transactions to a second private block on the first private blockchain network. The system also includes where the processor is operable to generate a first merged block including the first private block and the second private block. The system also includes where the processor is operable to record the first merged block to a single block on a second blockchain network. The system also includes where the processor is operable to record 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 system also includes where the processor is operable to perform 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 system also includes where the processor is operable to perform 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 system 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.
    • BRIEF DESCRIPTION OF THE DRAWINGS
  • 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.
    •  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.
  • Parent Hash (prevhash) 162: Each block in a blockchain is linked to its parent through the parentHash, which is the hash of the parent block header.
  • Coinbase Address (coinbase) 182: This is a 20-byte address of the account to which all the rewards for mining of the block and the execution of contracts are transferred.
  • Block Difficulty (difficulty) 168: This field specifies a difficulty value for mining. A block is valid only if it contains a valid proof-of-work (PoW) of a given difficulty.
  • Gas Limit (gas_limit) 184: The gas limit value is the limit of gas expenditure for the block.
  • Gas Used (gas_used) 186: This is the total gas used for all the transactions in the block.
  • Extra Data (extra_data) 170: Optional 32-byte extra data can be provided in the block.
  • Uncles Hash (uncles_hash) 188: This is the 32 byte hash of the RLP encoded list of uncle headers.
  • State Root (state_root) 174: This is the 32 byte hash of the root of the block's state trie after the transactions are executed.
  • Transactions List Root (tx_list_root) 176: This is the 32 byte hash of the root of the block's transaction trie which is populated with the transactions in the block.
  • Receipts Root (receipts_root) 190: This is the 32 byte hash of the root of the block's receipts trie which is populated with the receipts of the transaction in the transactions list of the block.
  • Bloom Filter (bloom) 172: Bloom filter composed from the set of logs created through execution of the transactions in the block.
  • Each of the block headers 156, 158 may comprise the above-recited fields.
  • Referring to FIG. 3, a Decentralization, Scalability and Security (DSS) framework or theorem which captures the constraints between decentralization, scalability and security for a blockchain network, is described in more detail. An embodiment of the invention provides method for capturing the tradeoffs between blockchain decentralization, scalability and security. Decentralization, scalability and security for a blockchain network are defined as follows:
      • Decentralization: Decentralization 200 of a blockchain network is defined by the ability of the network to process and settle the transactions without the need for a central authority. 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. The level of decentralization of a blockchain network depends on the resource requirements for the peers to participate in a network. Higher the resource requirements for peers, lowers the level of decentralization as only peers with powerful hardware will be able participate and mine on the network.
      • Scalability: Scalability 202 of a blockchain network is defined by the ability of the network to process a growing number of transactions. Scalability for a blockchain network is defined in terms of metrics such as transaction throughput and transaction latency. As a reference, Bitcoin network takes 10 min or longer to confirm transactions and achieves a throughput of 3-7 transactions/sec.
      • Security: Security 204 for a blockchain network is defined as the ability of the network to be secure against attackers and prevent double spending. Blockchain has the ability to establish trust in a peer-to-peer network through a distributed consensus mechanism rather than relying on a powerful central authority.
  • The DSS theorem states that it is impossible to simultaneously provide high levels of Decentralization, Scalability and Security (DSS) for blockchain networks.
  • The levels of Decentralization (LD), Scalability (LSc) and Security (LSe) for blockchain networks are tunable subject to the following constraints:

  • L Sc∝(1/L D)a∝(1/L Se)b
  • where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows:
      • Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212.
      • Scalability and Decentralization: The level of scalability in a blockchain network is inversely proportional to the level of decentralization. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of decentralization of the network decreases 208. For example, a scaling-up measure such as increasing block size (to increase transaction throughput) reduces the level of decentralization as the computational and storage load on each node will increase and the nodes running on commodity hardware will not be able to catch-up and mine on the network. Inversely, as scalability decreases, decentralization increases 210.
      • Decentralization and Security: The level of decentralization in a blockchain network is directly proportional to the level of security or inversely proportional to level of insecurity 206. If the level of decentralization of blockchain network is decreased, the security of the network decreases or insecurity increases 216. For example, a lower-level of decentralization means that the network is controlled by groups of miners or mining pools. Mining pools can collude to compromise the security of the network and attempt a ‘51% attack’. In a 51% attack, the pool can rewrite the blockchain history and do double-spending to their advantage. Inversely, as decentralization increases, insecurity decreases 218.
  • Referring now to FIG. 4, for example, and without limitation, the decentralization, scalability and security parameters, are described in more detail. The level of Decentralization (LD) is quantified in terms of the following blockchain parameters 250:
  • NT: Total number of nodes in the network 256;
  • NP: Number of peers connected to each node 258;
  • Bp: Minimum bandwidth required by a node to mine on the network 260;
  • Cp: Minimum processing power required by a node to mine on the network 262;
  • Dp: Minimum disk I/O required by a node to mine on the network 264;
  • Mp: Minimum memory required by a node to mine on the network 268; and
  • Tbs: Bootstrap time for a node to start mining 270.
  • The level of Decentralization (LD) is specified as:

  • L D =fn(N T ,N P ,B p ,C p ,D p ,M p ,T bs)

  • where:

  • 0<=L D<=10
  • LD=0: No decentralization
  • LD=10: Highly decentralized
  • The level of Scalability (LSc) is quantified in terms of the following blockchain parameters 252:
  • Ptx: Transaction throughput 272; and
  • Ttx: Transaction latency 274.
  • The level of Scalability (LSc) is specified as:

  • L Sc =fn(P tx ,T tx)

  • where:

  • 0<=L Sc<=10
  • LSc=0: No scalability
  • LSc=10: Highly scalable
  • The level of Security (LSe) is quantified in terms of the following blockchain parameters 254:
  • Sr: Stale block rate 276; and
  • Tbp: Block propagation delay 278.
  • The level of Security (LSe) is specified as:

  • L Se =fn(S r ,T bp)

  • where:

  • 0<=L Se<=10
  • LSe=0: No security
  • LSe=10: Highly secure
  • Referring now to FIG. 5, a unified model and protocol for tuning blockchain, is described in more detail. The unified model and protocol for tuning blockchain provides a standardized way of comparing various blockchain scalability approaches. With this model we can quantify the benefits of various scaling approaches in the form of DSS levels (where each level is on the scale of 0 to 10). The DSS model 300 can be created by learning the dependencies between DSS levels based on experimental measurement of the various blockchain parameters for a blockchain network. Each blockchain network has its own DSS model. The DSS model is dependent on the blockchain technology or platform (such as Bitcoin, Ethereum) and also its network deployment (e.g. public unpermissioned or private permissioned). Once a DSS model is built for a blockchain network, the blockchain can be tuned according to various scaling approaches, and the benefits of these approaches can be compared in the form of DSS levels. The tuning process involves providing the blockchain tuning parameters as input 302 to the DSS model 300 for a blockchain network. The output 304 of the DSS model are the levels of decentralization (LD) 306, scalability (LSc) 308 and security (Lse) 310, where the levels are related according to equation 312, with LSc 308 being inversely proportional to L D 306 which is in turn inversely proportional to L se 310. The tuning is also especially useful when nodes in the blockchain network fail or the network may be partitioned so that reallocation of work may be suitably done.
  • The DSS theorem described above is compatible with and complimentary to a consistency, availability and partition tolerance (CAP) theorem applied to a blockchain network. According to CAP for blockchain, a blockchain network is always be available and eventually-consistent. Whereas, according to DSS for a blockchain, a blockchain network cannot simultaneously have high levels of Decentralization, Scalability and Security. The levels of Decentralization, Scalability and Security for blockchain networks are tunable subject to the DSS constraints. Blockchain platforms may use different consensus mechanisms, blockchain designs or parameters to tune the consistency, availability and partition-tolerance of the blockchain network. With a DSS model for a blockchain network, it is possible to quantify the effects of various consensus mechanisms, blockchain designs or parameters on the decentralization, scalability and security of the blockchain network. For example, with a DSS model, we can compare the effects of switching the consensus mechanism on a blockchain network from Proof-of-Work to Proof-of-Stake. Similarly, we can compare the effects of changing the block-size and block-interval parameters for a blockchain network.
  • Referring now to FIG. 6, a method aspect of the present invention for creating application-specific blockchain flavors, is described in more detail. The DSS unified model described above, allows creating application-specific blockchain flavors, which use the same blockchain technology or platform but differ only in the blockchain parameters. For example, the Ethereum blockchain platform can be used to create multiple blockchain networks or deployments, where each network may have a different level of decentralization, scalability and security based on the business or application requirements. For a blockchain network which is to be used for applications involving sensitive data (such as healthcare), it may be desirable to have higher levels of security by compromising on the scalability or decentralization, having inputs 352 such as relatively smaller block sizes SB of, for instance, 0.1 megabytes, and a block interval of 60 seconds which, when applied to the DSS model 350, yielding output 354. Whereas, for a blockchain network which is to be used for Internet of Things (IoT) applications, it may be desirable to have higher levels of scalability by compromising on the security or decentralization, having inputs 358 of a block size of 0.5 megabytes and a block interval of 60 seconds that, when DSS model 356 is applied, yields output 360. One of ordinary skill in the art may perform this analysis.
  • Referring now to FIG. 7, a method aspect of the present invention for adaptive tuning of blockchain parameters, without significant client release updates, is described in more detail. The adaptive tuning method starts at step 380 with fixing the DSS levels for a blockchain based on application requirements. For example if a blockchain is to be used for applications requiring high transaction throughput, the scalability levels may be fixed to higher levels (such as 8-10) while the security and decentralization levels may be fixed to relatively lower levels (such as 4-6). Next, at step 382 use DSS model for the blockchain is used to determine the values of blockchain parameters required to meet the required DSS levels. Next, the blockchain can be setup with these values of blockchain parameters. Once the blockchain network is setup, the performance of the blockchain and its various metrics are monitored continuously, at step 384, through specialized control packets/messages that request Quality of Performance (QoP) values that are measured throughout the network, and based on this a decision can be made to initiate, stop, or rollback adaptive tuning processes, so that the system is efficient and consistent. At step 386 the target DSS levels may be identified from the DSS model for the blockchain network. At step 388, a check is performed if the DSS levels deviate from the desired levels. If the DSS levels deviate from the desired levels, the blockchain parameters are tuned, at step 390, to meet the desired DSS levels.
  • Referring now to FIG. 8, the structure of control messages as extension to the existing Ethereum Blockchain Wire Protocol, is described in more detail. The GetQoP message 400 may comprise a Message ID 408 and is used to request the QoP metrics for the specified metric- IDs 410, 412, 414. The response to a GetQoP message is a QoP message 402 which contains a Message ID 416, metric-IDs requested and their values 418, 420, 422. The DSS model is used at regular intervals of time to compute the current DSS levels. If the current DSS levels deviate from the desired levels, the blockchain parameters can be tuned to meet the desired DSS levels. If there exist timeouts or some other problems (message losses or network fragmentation/node failures) with implementation of the tuning update, the system can rollback to previous parameters sets that were check-pointed or stored (with in an incremental manner or in an absolute manner; a choice that is related to storage and security requirements).
  • An embodiment of the invention provides 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. We propose a set of nodes called the ‘Supervisor’ nodes in a blockchain network who supervise the tuning updates to the blockchain. The supervisor nodes hold a stake in the blockchain network. The stake can be in the form of a bond. The supervisor nodes monitor the blockchain network performance and decide how to adjust the blockchain parameters, based on the adaptive tuning approach described above. The parameter update announcements are issued after the supervisor nodes come to a consensus on the updates to be made to the parameters. Once the supervisor nodes come to a consensus on an update, one of the supervisor nodes is randomly chosen to create an announcement message. The announcement message is signed by the supervisor node's private key. The supervisor can also rollback or cancel the update to the last check-pointed state. These changes can be made as extensions to existing protocols, such as but not limited to Ethereum Wire Protocol, RLPx, Whisper, or SNMP and its variants. The NewTuningAnnoucement message 404 is used to announce an update to the tuning parameters. This message contains a Message ID 416, an announcement number 426, the address of the supervisor node issuing the announcement 428, and the tuning parameter IDs and the respective values 430, 432. To rollback an announcement or update to tuning parameters, a supervisor can issue a RollbackTuningAnnouncement 406 which contains a Message ID 434, the number of the announcement message 436, which is rolled back, and the issuing supervisor node address 438. We propose an enhancement to the existing blockchain wire protocols to allow the tuning announcement messages to be exchanged in a peer-to-peer blockchain network. The announcement messages are transmitted over the blockchain wire protocol (like other messages such as new block announcements). The underlying network and transport protocol allows the integrity of the announcement messages to be verified. Integrity verification is performed by recovering the public key from the signature and matching it with the expected value, for instance. The nodes in a blockchain network may continue to process the transactions while the announcement messages are propagated through the network. While these messages are being propagated, some miner nodes may use old tuning parameters for creating new blocks, whereas other miner nodes who received the announcement messages will use the latest announced blockchain parameters. This may lead to short forks being created on each new announcement. These forks are resolved when the next block is mined and the blocks using older parameters are ignored. Alternatively, the transactions may be halted for a period of synchronization before resuming. Suitable checkpointing methods may be used to rollback for any inconsistent application of parameters, or other faults and timeouts.
  • Referring now to FIG. 9, a method aspect of the present invention for on-chain scaling is described in more detail. A blockchain design comprising two types of blocks—normal blocks and microblocks, is presented. Normal blocks such as 500, 502 are created by the miners on the blockchain network and require proof-of-work mining separated by a block interval 506. A block is cryptographically secured by a nonce that proves that a certain amount of work was done to find the nonce input to the PoW algorithm. The normal blocks represents an eventually consistent state of the network, or points of consensus in the network. Micro-blocks, such as 504, are generated in the block-interval between two normal-blocks. Micro-blocks are created by a bonded-validator chosen by the network. There is no mining involved in creation of micro-blocks. The validator chosen after each normal block is created, generates micro-blocks by validating the transactions received after the creation of the last normal block and updates the state. Since no proof-of-work computation is involved, micro-blocks can be created at a very fast rate. Micro-blocks increase transaction throughput and reduce transaction latency in a blockchain network. The micro-block size and micro-block interval can be tuned. The structure of normal blocks is similar to the blocks in existing second generation blockchain networks such as Ethereum.
  • Referring now to FIG. 10, the structure of an exemplary microblock 550 and the fields 552 in a microblock are described in more detail as follows:
  • Micro-Block Number (number) 564: This is the number of the micro-block.
  • Timestamp (timestamp) 556: This is the UNIX timestamp value at the creation of the block.
  • Parent Hash (prevhash) 554: Hash of the parent block header. Validator Address (address): This is the address of the account the validator who created the micro-block.
  • Gas Limit (gas_limit) 568: The gas limit value is the limit of gas expenditure for the block.
  • Gas Used (gas_used) 570: This is the total gas used for all the transactions in the block.
  • Extra Data (extra_data) 558: Optional 32-byte extra data can be provided in the block.
  • State Root (state_root) 562: This is the 32 byte hash of the root of the block's state tree after the transactions are executed.
  • Transactions List Root (tx_list_root) 572: This is the 32-byte hash of the root of the block's transaction tree which is populated with the transactions in the block.
  • Receipts Root (receipts_root) 574: This is the 32-byte hash of the root of the block's receipts tree which is populated with the receipts of the transaction in the transactions list of the block.
  • Bloom Filter (bloom) 560: Bloom filter composed from the set of logs created through execution of the transactions in the block.
  • Microblocks are generated by a ‘bonded-validator’ chosen by the network. Each validator owns a ‘stake’ in the network in the form of a bond or security-deposit. The validators who post a bond, or in other words, make the security deposit, are called ‘bonded validators’. Given a point of consensus (i.e. a block at a certain height), a validator is randomly selected and assigned the right to create micro-blocks till the next block is mined. The higher the security deposit made by a validator, higher is its probability of being chosen to create the micro-blocks. Validators earn 10 rewards to validating transactions in micro-blocks. Any malicious validator who tries to cheat the network and vote for a microblock with invalid transactions loses its deposit and the right to generate new microblocks.
  • Referring now to FIG. 11, an off-chain scaling approach, is described in more detail. An embodiment of the invention provides a system, protocol, and associated methods for off-chain scaling of a blockchain network 600. The off-chain scaling method involves one or more permissioned private chains or sub-chains 602 which are linked to the main blockchain through one or more smart contracts 604. The participants in the blockchain network who need to transact frequently can register themselves on such a private and transact directly with each other rather than sending transactions through the main blockchain. The consensus mechanism in a permissioned private chain is controlled by a pre-selected set of nodes. Due to the permissioned model of consensus in a private chain, the consensus mechanism is much faster than the main blockchain. As a result, a private chain can enable micro-transactions between the participants which can be processed much faster. The state of a private chain is regularly checkpointed to the main blockchain through the smart contracts. Thus the main blockchain serves as a ‘summarized’ or ‘abstract’ version of all the private chains linked to it. For example, a single transaction can be created on the main chain which captures the multiple micro-transactions on the private chain 608, 610, 612.
  • Referring now to FIG. 12, an illustration of super-chains and sub-chains as used in the off-chain scaling approach, is described in more detail. The off-chain scaling method involves one super-chain 650 and one or more levels of sub-chains 652, 654, 656. The super-chain acts as summarized version of the level-1 sub-chain. Similarly, level-(N−1) sub-chain acts as a summarized version of the level-N sub-chain. A single block in the super-chain can include summarized transactions from multiple blocks in the sub-chain. For example, for a retail blockchain application, a sub-chain can capture the sale of individual items (as micro-transactions) and the super-chain can capture a summary of all the transactions every hour, such that a single transaction is created every hour showing one summary sale of all the items sold in that hour. The DSS unified model can be used to tune to the super-chain and sub-chains to meet the application requirements.
  • Referring now to FIG. 13, the checkpointing process between private and public blockchains and the interfaces involved, are described in more detail. Transactions are typically conducted on private permissioned blockchain networks 706, 708 that may share a global database 700 through a private blockchain database manager/network 718. Selected (and expensive/infrequent) transactions are checkpointed 716 on the public blockchain 702. The use of smart contracts allows suitable identification and processing of transactions in private or public blockchains and checkpointing at select times through use of policies that may be dynamically enforced. This approach improves the efficiency, speed and reduces the cost of transactions. The private permissioned blockchain networks 706, 708 may be used for multiple e-commerce applications, including trading, payments, HR, taxes, auctions, etc. Private permissioned blockchain networks 706, 708 carry out the majority of the smart contracts and other transactions on the B interfaces 714, while periodically checkpointing to the Public Blockchain 702 to synchronize some bulk/block transactions. This reduces the costs and tariff incurred if directly using the A Interface 712 for all transactions.
  • Referring now to FIG. 14, is an illustration of checkpointing process between private and public blockchains with the use of a public-private gateway, are described in more detail. In this model, a public-private gateway that interfaces with the e-commerce infrastructure 710 through the C Interface 722 and forwards the transactions to the public blockchain 702 over the A Interface 704.
  • Referring now to FIG. 15, the cross-chain payments process, is described in more detail. In the scenarios illustrated in the figure, a User-1 770 having an account on a public blockchain network-1 754 sends a payment in a cryptocurrency or token on blockchain network-1 to User-2 768 who has an account on a public blockchain network-2 758. The public blockchain networks 754, 758, 752, each having an associated database 764, 760, 762, interface with a private blockchain network 750 and its database 756 through blockchain bridges. Bridges allow inter-chain blockchain transactions. A blockchain bridge 766 receives transactions from a public blockchain network and forwards the transactions to the connected private blockchain network. Similarly, the transactions received from a private blockchain network are forwarded to the connected private blockchain network.
  • Referring now to FIG. 16, inter-chain transactions and payments bridge, are described in more detail. A bridge 804 connects two blockchain networks 800, 802 and allows transactions to be forwarded from one blockchain network to another. A bridge 804 may be implemented through a combination of blockchain accounts 812, 810, and smart contracts 806, 808, on the connected blockchain networks 800, 802, with on-chain or off-chain payment settlements 814 between the blockchain accounts.
  • Referring now to FIG. 17, an illustration of fast and low cost transactions on a private blockchain network with periodic checkpointing on a public blockchain network, is described in more detail. User-1 856 and User-2 860 have accounts on a private and permissioned blockchain network 850 and a public blockchain network 852. The private and permissioned blockchain network 850 is used for frequent transactions between the users 856,860. The transactions are processed fast and with low fees on the private and permissioned blockchain network 850. The transactions between the users 856,860 are checkpointed 858 on the public blockchain network 852 at regular intervals. During the checkpointing process, multiple transactions on the private and permissioned blockchain network 850 are combined into a single transaction and sent to the public blockchain network 852. A third blockchain network 854 may be may be used for user identity and access management.
  • Referring now to FIG. 18, an example of transactions processed on a private blockchain network (off the main public chain), is described in more detail. User-A 902, User-B 904, User-C 906, User-D 908 all have starting balances of 100 (in a certain cryptocurrency or a token which can be transacted on a private blockchain network). The table 900 shows examples of transactions that transfer value between the users. After the transactions in table 900 are processed, the ending balance of the User-A is 108, User-B is 107, User-C is 98 and User-D is 87.
  • Referring now to FIG. 19, and continuing to refer to FIG. 18, an example of combined transactions processed on a public blockchain network, is described in more detail. The transactions on the private blockchain network as shown in table 900, between the same pair of users are merged yielding a combined transactions 922. The merged transactions as shown in table 920 are sent to the public blockchain network. The values of the starting and ending balances of User-A 902, User-B 904, User-C 906, User-D 908 for the transactions processed on the private blockchain network are the same as the merged transactions processed on the public blockchain network. To prevent double spending from accounts participating in off the public chain transfers (i.e. transfers on the private chain), the accounts on the public blockchain can be locked in the time interval between two synchronization points of the private and public chains. This is to prevent the transfer of tokens from accounts on the public chain while there are unsynchronized transactions on the private chain. Smart contracts on the public blockchain can be used for locking the accounts and preventing transfer or withdrawal of tokens while there are unsynchronized transactions on the private chain.
  • Referring now to FIG. 20, an example synchronizing transactions between private and public blockchains, is described in more detail. Private blockchain network 950 has fast block generation time as a result the transactions can be processed very fast. The consensus mechanism on the private blockchain network 950 can be chosen such that the transaction can be processed with negligible or near zero fees. Public blockchain network 952 has slower block generation time as a result transactions are processed slower on the public blockchain. Public blockchain networks typically have high transaction fees. By merging multiple transaction on the private blockchain into a single transaction on the public blockchain, the effective fees paid per transaction can be lowered.
  • Referring now to FIG. 21, an example synchronizing transactions between multiple private and public blockchains, is described in more detail. The private blockchain network 954 has fast block generation time (of the order of few milliseconds) and the transactions are processed very fast. The transactions on the private blockchain network 954 (between the same pair of users and received in a given time interval) are merged and sent to the private blockchain network 956 which has slower block generation time (of the order of few seconds) than private blockchain network 954. The transactions on the private blockchain network 956 (between the same pair of users and received in a given time interval) are merged and sent to the public blockchain network 958 which has slow block generation time (of the order of few minutes) than private blockchain network 954.
  • Referring now to FIG. 22, a method of smart contract mirroring, is described in more detail. The same smart contract (such as an ERC20 token contract) can be deployed on the private and public blockchain networks 1000, 1002. The smart contract 1006 on the private blockchain network 1000 is mirrored 1010 as the smart contract 1008 on the public blockchain network 1002 where the transactions on the private blockchain and periodically synchronized and checkpointed on the public blockchain network. The private blockchain network 1000 can process the transactions very fast and with near zero transaction fees. The transactions are periodically combined and sent in the public blockchain network 1002 thus synchronizing the smart contracts on the private and public chains. The sync and checkpointing process 1004 can be triggered at fixed time intervals (such as every few hours) or after fixed number of blocks on the private chain (e.g. after every 100 blocks on the private chain). Private blockchain network 1000 may adopt a different consensus algorithm (such as Proof of Authority or Delegated Proof of Stake) from the public blockchain network 1002.
  • Referring now to FIG. 23, the use of multiple chains for replication, partitioning and transaction speedup, is described in more detail. Private and permissioned blockchain networks 1050, 1054, 1056 have the same smart contract deployed at addresses 1068, 1070, 1064 and mirrored to the smart contract 1066 deployed on the public blockchain network 1052. Multiple private and permissioned blockchain networks are used for the purposes of replication, partitioning and transaction speedup. For example, in a payment application, all transactions between a subset-1 of users can be processed on private and permissioned blockchain network 1050, whereas transactions between another subset-2 of users can be processed on the private and permissioned blockchain network 1054, thus partitioning the transaction processing for the payment application across two blockchain. Another use of having multiple private and permissioned blockchain networks 1050, 1054, 1056 to process transactions for an application is that while one network is being synchronized and checkpointed 1058, 1060, 1062 with the public blockchain network 1052, the transactions can be sent to the other private blockchain network to prevent double spending.
  • Referring now to FIG. 24, a transactions filter for filtering transactions into different classes, is described in more detail. Transactions sent by users 1082 between private blockchain networks 1000 and public blockchain networks 1002 that are synced and checkpointed 1004 are filtered by a transactions filter 1080 based on the transaction value, sender and receiver information, source of transaction and other meta-data associated with the transaction. The transaction filtering process can segregate the transactions into different classes such as follows:
      • Class 1: Small value transactions are completed on private blockchain with no syncing.
      • Class 2: Large value transactions are synced immediately.
      • Class 3: Other transactions will be synced in batch mode.
      • Class 4: Transactions which seem suspicious are be sent for additional processing.
  • Referring now to FIG. 25, the use of a private blockchain infrastructure to offload frequent transactions and big data, is described in more detail. Since blockchain and smart contracts are not designed to store large amounts of data and big files, such information can be stored on a decentralized storage platform (such as IPFS or Swarm). In this approach, while the data is stored off the blockchain within a storage platform, the hash of the data (which is used to uniquely identify the data) is stored on the blockchain as state variables within a smart contract. The benefit of this approach is that while standardized data fields can be stored as state variables in a smart contract, the abstract data types and large files can be stored off the blockchain and pointers to the data (content-hash) stored with the smart contracts 1106, 1112. For scaling and speeding up applications that involve frequent transactions between users or devices (such as IoT applications) or applications that involve large amounts of data (such as healthcare applications), a private blockchain infrastructure comprising a private blockchain network 1104, a private blockchain database 1100 and a private decentralized storage network 1102 is used. While the private blockchain infrastructure is used for offloading frequent transactions and big data, a public blockchain infrastructure comprising a public blockchain network 1110, a public blockchain database 1114 and public private decentralized storage network 1116 is used for combined or important or summarized transactions and data. Data can be synchronized and checkpointed 1108 between the private and public blockchain networks 1104, 1110.
  • Referring now to FIG. 26, an exemplary cloud and blockchain backend architecture for a payments application, is described in more detail. Users 1200 can access the payment application through a mobile or web application 1202 which communicates with the application backend (cloud and blockchain) through APIs. The access to the backend APIs is controlled through the API gateway 1204. A number of compute instances 1208, 1210, 1212, under one load balancer 1206 may run the application servers. The application data is stored in a replicated master-slave database comprising a master database instance 1214 and a slave database instance 1216. The application servers process the API requests (such as for transfer of tokens on the blockchain) and post transactions to a private blockchain network 1218. To enable the application servers to communicate with the private blockchain network 1218, the compute instances on which such application servers run also have blockchain client applications installed. The blockchain transactions and the state of smart contracts are synchronized and checkpointed 1220 on the public blockchain network 1222 at regular time intervals. The advantages of using an architecture as illustrated in FIG. 25 are as follows:
  • Web and mobile applications do not have to be aware of the blockchain platform being used. The web and mobile applications (which are themselves deployed on a server or local machine or device) need not run blockchain clients and synchronize the complete blockchain state to process the blockchain transactions.
  • Transactions can be processed much faster on the private blockchain. The combined transactions and the state of the smart contracts on the private blockchain can be synchronized and checkpointed with the public blockchain at regular intervals in an asynchronous manner without the users having to wait for the transactions to be processed.
  • The API gateway may use a cache to serve data which is requested frequently (such as balances of blockchain accounts or smart contract state variables).
  • The compute instances that run the application servers and blockchain clients may be placed under an auto-scaling group to enable the backend system to scale-up or down automatically based on demand.
  • The database system maintains records of user and transactions data and serves requests from the application servers. This allows users to efficiently query for data such as history of all transactions, user profile data and other application specific data that need not be stored on the blockchain.
  • Referring now to FIG. 27 and additionally referring to FIG. 28, the use of multi-signature and multi-party smart contracts 1310, 1312 on multiple private and permissioned blockchains which are synchronized and checkpointed 1324, 1326 to a single public blockchain and associated smart contracts 1318, 1320, are described in more detail. Applications involving multiple parties to smart contracts 1300, 1302, 1304, 1306, 1308, (for example, in the case of a trade process that involves Letter of Credit (LC) or Standby Letters of Credit (SBLC) contracts between the parties to the trade) can leverage private and permissioned blockchain networks 1314, 1316 for improving scalability, speeding up transactions, and reducing transaction processing fees. Each party is represented on the blockchain through a registry smart contract. For example, in a trade process that involves the use of Letter of Credit, the parties include a buyer, seller, issuing bank, advising bank and shipping company. These parties are represented on the blockchain through registry contracts such as Buyer Registry Contract 1402, Seller Registry Contract 1404, Issuing Bank Registry Contract 1410, Advising Bank Registry Contract 1412, Carrier Registry Contract 1400, Sales Contract 1406, Letter of Credit Contract 1408.
  • The multi-signature (multisig) smart contracts 1310, 1312 on the private and permissioned blockchain networks 1314, 1316 require multiple parties to sign various transactions sent to these contracts (i.e. M-of-N signatures, such as 1-of-2, 2-of-2, 2-of-3, 3-of-5, 5-of-9). The state of the multisig contracts is synchronized and checkpointed in the equivalent or simplified contracts 1318, 1320 on the public blockchain network 1322.
  • The smart contracts capture different steps involved in the trade process and the interaction between the parties. For example, in the Letter of Credit application, the Buyer and Seller have a Sales contract between them. The Issuing Bank sends a Letter of Credit contract to the seller. The Seller ships the goods through the Shipping company and records the shipping information in the Shipping contract. The Seller gets a transport verification message (or documents) which are sent to the Advising bank. The Advising bank sends the transport verification message (or documents) to the Issuing Bank. The Issuing Bank releases the payment and sends the transport verification message (or documents) to the buyer. The buyer takes possession of the goods from the shipping company by presenting the transport verification message (or documents) to the shipping company. In this application the smart contracts allow easier and faster verification of information. The transactions to update the state of smart contracts and messages are cryptographically signed by the concerned parties. Suitable checks in the Letter of Credit and related smart contracts can prevent reuse of the Letter of Credit. Requiring multiple signatures for certain smart contracts (such as Letter of Credit smart contract), can prevent fraud (for example, a bank employee fraudulently issuing a Letter of Credit without verifying buyer's financial standing or collateral). Furthermore, each party involved is aware of the state of the contracts leading to greater transparency in the whole trade process.
  • Unlike the simplified existing implementations of Letter of Credit smart contracts on a blockchain network or multisig contracts [References: https://github.com/sunil-gunasekaran/Letter_Of_Credit/tree/master/LOC/contracts https://github.com/haribalaji79/letterofcredit_blockchain], the technique here does the following:
      • The smart contracts are structured as multi-party and multi-signature contracts and deployed on private and permissioned blockchain network. The state of the such contracts is synchronized and checkpointed in the equivalent or simplified contracts on the public blockchain network.
      • Offloading the smart contracts on a private and permissioned blockchain network improves scalability, speeds up transactions, and reduces transaction processing fees.
      • For different trades, different private and permissioned blockchain networks may be used. The state of the smart contracts on such multiple private and permissioned blockchain networks can be synchronized and checkpointed on a single public blockchain network.
      • The private and permissioned blockchain networks may have a different consensus mechanism from the public blockchain. For example, a Proof-of-Stake or Proof-of-Authority consensus may be used on private and permissioned blockchains whereas the public blockchain may use a Proof-of-Work consensus mechanism.
      • The identity information of each party may be maintained on a separate blockchain network. An identity verification and certification procedure is performed for securely linking blockchain accounts to real users.
      • Smart contracts may have multiple variants (for example multiple variants of a Letter of Credit contract) and a particular variant of a smart contract may be selected based on additional meta-data available (for example, trade process meta-data such as the countries of the buyer and seller or type of trade).
  • The identity (and associated blockchain accounts) of each party involved in such contracts may be separately verified through an identity verification process. A system and associated methods for securely linking blockchain accounts to real users, as described in related U.S. patent application Ser. No. 15/863,128 titled Method and System for Blockchain-Based Combined Identity, Ownership and Custody Management filed Jan. 5, 2018, the content of which is incorporated herein by reference except to the extent disclosure therein is inconsistent with disclosure herein. A user identity registration and certification procedure is performed that comprises receiving hashed user identification information that has been signed with a private key of the user from the user, defining a seal contract, generating an address of the seal contract, defined as a sealed user record address, and providing the sealed user record address. The procedure may further comprise receiving a hashed verification record from a certificate authority, generating an address of a verification contract from the hashed verification record, defined as a sealed verification record address and providing the sealed verification record address. Furthermore, the procedure may further comprise generating a certification contract from a combination of the sealed user record address, a certification token, and the sealed verification record address, providing a certification contract address, receiving a verification record by a certification authority comprising the hashed user identification information and a token, and receiving a combination of the certification contract address and the seal contract, defining a received certification contract address and a received seal contract, respectively. Additionally, the procedure may further comprise obtaining each of the sealed user record address and the sealed verification record address from the certification contract address, retrieving the seal contract from the sealed user record address, defining a retrieved seal contract, decrypting the retrieved seal contract using a public key associated with the user, defining a decrypted retrieved seal contract, and comparing the decrypted retrieved seal contract and the received seal contract. Yet further, the procedure may comprise retrieving the verification contract from the sealed verification record address, defining a retrieved verification contract, obtaining a certification token from the certification contract address, generating a hashed confirming verification record by hashing the combination of the decrypted retrieved seal contract and the certification token, and comparing the hashed confirming verification record to the retrieved verification contract. Upon a comparison of the decrypted retrieved seal contract and the received seal contract indicating they are at least a partial match and the comparison of the hashed confirming verification record to the retrieved verification contract indicating they are at least a partial match, a session certification token for a decentralized application may be generated. Finally, the procedure may comprise transmitting the session certification token to the user.
  • Referring now to FIG. 29, an illustration of “soft” smart contracts, is described in more detail. Soft smart contracts are contracts which have multiple variants (for example multiple variants of a Letter of Credit or Sales contract) and a particular variant of a smart contract may be selected based on additional application or trade specific meta-data available (for example, trade process meta-data 1454 such as the countries of the buyer and seller or type of trade). FIG. 29 illustrates a Soft Smart Contract-A 1450 which has multiple variants of smart contracts (Variant-1 1470, Variant-2 1472, Variant-N 1474) and a Soft Smart Contract-B 1452 which has multiple variants of smart contracts (Variant-1 1476, Variant-2 1478, Variant-N 1480). For Application/Process-1 1462, Variant-1 1470 of Soft Smart Contract-A 1450 and Variant-2 1478 of Soft Smart Contract-B 1452 are used. For Application/Process-2 1464, Variant-N 1474 of Soft Smart Contract-A and Variant-1 1476 of Soft Smart Contract-B are used. The selection of a particular variant of a soft smart contract is done based on application or process specific meta-data 1454. The smart contracts for Application/Process-1 1462 are deployed on private and permissioned blockchain network-1 1456. The smart contracts for Application/Process-2 1464 are deployed on private and permissioned blockchain network-2 1458. The state of the smart contracts on the private and permissioned blockchain networks 1456, 1458 are synchronized and checkpointed 1466, 1468 in the equivalent or simplified smart contracts the public blockchain network 1460.
  • Referring now to FIG. 30, a reference implementation of a token smart contract synchronizing service that syncs token smart contracts between a private blockchain and a public blockchain, is described in more detail. The contract syncer service can be run periodically (after few hours or once every day) to sync two token smart contracts deployed on private and public blockchain networks. The syncer service takes as input a list of all accounts on the private that transacted during the day with the token contract. The syncer service syncs the smart contract states by performing the following steps:
  • STEP-1: For all accounts whose token balance has decreased on the private chain as compared to the last synced balance on public chain, move the difference in balance from the corresponding account on public chain to a vault account on public chain.
  • STEP-2: If the total token supply on the private chain has increased since the last synced balance on public chain, create new tokens (equal to the difference of total token supply on private and public chains) and send to vault account on public chain. Whereas, if the total token supply on the private chain has decreased since the last synced balance on public chain, burn tokens (equal to the difference of total token supply on private and public chains) from the vault account on public chain.
  • STEP-3: For all accounts whose token balance has increased on the private chain as compared to the last synced balance on public chain, move the difference in balance from the vault account on public chain to the corresponding account on the public chain.
  • Appendix-A provided shows the results of a simulation using the syncer service. In the simulation shown, there are five accounts which transact with the token contract. The transactions are of three types—(1) transaction to create tokens which are credited to an account, (2) transaction to burn tokens from an account, (2) transaction to transfer token from one account to another. Simulation results show transactions on the private chain and public chain, the token balances and total token supply. The state of the token contract on the private chain is synced with the state of the token contract on the public chain at midnight. Simulation results show that a 94% reduction in the number of transactions is achieved for syncing the token smart contract states on the private and public chains.

Claims (20)

What is claimed is:
1. A method of synchronizing transactions between blockchains comprising:
receiving a first plurality of transactions on a first private blockchain network;
recording the first plurality of transactions to a first private block on the first private blockchain network;
receiving a second plurality of transactions on the first private blockchain network;
recording the second plurality of transactions to a second private block on the first private blockchain network;
generating a first merged block comprising the first private block and the second private block;
recording the first merged block to a single block on a second blockchain network;
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;
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; and
performing a checkpointing process between the first private smart contract and the second smart contract comprising recording the state of the first private smart contract to the second smart contract, defining a checkpointed first private smart contract;
wherein the first private blockchain network has a parameter difference from the second blockchain network selected from the group consisting 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.
2. The method of claim 1 wherein:
the second blockchain network is a public blockchain network; and
the second smart contract is a public smart contract.
3. The method of claim 2 wherein:
the first plurality of transactions comprises a plurality of transactions between two users, each transaction between the two users comprising 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; and
the first merged block comprises a combined transaction comprising a net token value equaling the net of transfers of tokens between the two users in the plurality of transactions between the two users.
4. The method of claim 3 wherein the first private smart contract is a multi-signature smart contract comprising a plurality of signatures, each signature being associated with a user.
5. The method of claim 4 wherein an identity of a user having a signature comprised by the first private smart contract is validated by an identity verification and certification procedure.
6. The method of claim 5 wherein the identity verification and certification procedure comprises retrieving identity verifying information from an identity verification blockchain network.
7. The method of claim 4 wherein the first private smart contract comprises at least three signatures, each signature being associated with a separate user.
8. The method of claim 2 further comprising:
receiving a third plurality of transactions on a second private blockchain network;
recording the third plurality of transactions to a third private block on the second private blockchain network;
receiving a fourth plurality of transactions on the second private blockchain network;
recording the fourth plurality of transactions to a fourth private block on the second private blockchain network;
generating a second merged block comprising the third private block and the fourth private block;
recording the second merged block to a single block on the public blockchain network;
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;
performing a synchronization process between the second private smart contract and the public smart contract; and
performing a checkpointing process between the second private smart contract and the public smart contract comprising recording the state of the second private smart contract to the public smart contract, defining a checkpointed second private smart contract;
wherein the second private blockchain network has a parameter difference from the public blockchain network selected from the group consisting 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.
9. The method of claim 2 further comprising:
receiving a third plurality of transactions on a second private blockchain network;
recording the third plurality of transactions to a third private block on the second private blockchain network;
receiving a fourth plurality of transactions on the second private blockchain network;
recording the fourth plurality of transactions to a fourth private block on the second private blockchain network;
generating a second merged block comprising the third private block and the fourth private block;
recording the second merged block to a single block on the public blockchain network;
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;
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; and
performing a checkpointing process between the second private smart contract and the public smart contract comprising recording the state of the second private smart contract to the second public smart contract, defining a checkpointed second private smart contract;
wherein the second private blockchain network has a parameter difference from the public blockchain network selected from the group consisting 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.
10. The method of claim 2 wherein the synchronization process comprises:
determining an account on the first private blockchain network that has a token balance decrease, defining a decreasing account;
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;
determining if a total token supply on the private blockchain network has increased since an immediate previous synchronization process;
if the total token supply on the private blockchain network has increased, creating new tokens and sending them to the vault account;
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;
determining an account on the first private blockchain network that has a token balance increase, defining an increasing account; and
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.
11. The method of claim 1 wherein the second blockchain network is a second private blockchain network and the second smart contract is a second private smart contract, the method further comprising receiving a third plurality of transactions on the first private blockchain network;
recording the third plurality of transactions to a third private block on the first private blockchain network;
receiving a fourth plurality of transactions on the first private blockchain network;
recording the fourth plurality of transactions to a fourth private block on the first private blockchain network;
generating a second merged block comprising the third private block and the fourth private block;
recording the second merged block to the second private blockchain network; and
generating a third merged block comprising each of the first and second merged blocks; and
recording the third merged block to a third blockchain network.
12. The method of claim 11 wherein 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 consisting 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.
13. The method of claim 11 wherein:
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.
14. The method of claim 11 further comprising:
recording the third and fourth private blocks and the second merged block to the first private blockchain smart contract;
performing a synchronization process between the first private smart contract and the second smart contract; and
performing a checkpointing process between the first private smart contract and the second private smart contract comprising recording the state of the first private smart contract to the second private smart contract, redefining the checkpointed first private smart contract;
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;
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; and
performing a checkpointing process between the third private smart contract and the fourth smart contract comprising recording the state of the third private smart contract to the fourth smart contract, defining a checkpointed third private smart contract.
15. The method of claim 11 wherein the third blockchain network is a public blockchain network.
16. The method of claim 1 further comprising:
applying a filter to the first plurality of transactions;
determining a subset of transactions of the first plurality of transactions; and
excluding the subset of transactions from being recorded to the first merged block.
17. The method of claim 1 further comprising:
identifying a failure of the first private blockchain network;
recording a transaction on the first private blockchain network to a first private blockchain network transaction log, defining a logged transaction;
retrieving the checkpointed first private smart contract from the second smart contract;
recording the checkpointed first private smart contract to the first private blockchain network, defining a restored first private smart contract; and
recording the logged transaction to the restored first private smart contract.
18. A method of synchronizing transactions between private and public blockchains comprising:
receiving a first plurality of transactions on a first private blockchain network;
recording the first plurality of transactions to a first private block on the first private blockchain network;
receiving a second plurality of transactions on the first private blockchain network;
recording the second plurality of transactions to a second private block on the first private blockchain network;
generating a first merged block comprising the first private block and the second private block;
recording the first merged block to a single block on a public blockchain network;
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;
performing a synchronization process between the first private smart contract and a smart contract linked to the public blockchain network, defining a public smart contract, the synchronization process comprising:
determining an account on the first private blockchain network that has a token balance decrease, defining a decreasing account;
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;
determining if a total token supply on the private blockchain network has increased since an immediate previous synchronization process;
if the total token supply on the private blockchain network has increased, creating new tokens and sending them to the vault account;
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;
determining an account on the first private blockchain network that has a token balance increase, defining an increasing account; and
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; and
performing a checkpointing process between the first private smart contract and the second smart contract comprising recording the state of the first private smart contract to the public smart contract, defining a checkpointed first private smart contract;
wherein the first private blockchain network has a parameter difference from the public blockchain network selected from the group consisting 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; and
wherein the first private smart contract is a multi-signature smart contract comprising a plurality of signatures, each signature being associated with a user.
19. The method of claim 18 wherein:
the first plurality of transactions comprises a plurality of transactions between two users, each transaction between the two users comprising 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 public blockchain network; and
the first merged block comprises a combined transaction comprising a net token value equaling the net of transfers of tokens between the two users in the plurality of transactions between the two users.
20. A system for synchronizing transactions between blockchains comprising:
a processor;
a data store positioned in communication with the processor; and
a network communication device positioned in communication with each of the processor, the data store, and a network;
wherein the network communication device is operable to receive a first plurality of transactions on a first private blockchain network;
wherein the processor is operable to record the first plurality of transactions to a first private block on the first private blockchain network;
wherein the network communication device is operable to receive a second plurality of transactions on the first private blockchain network;
wherein the processor is operable to record the second plurality of transactions to a second private block on the first private blockchain network;
wherein the processor is operable to generate a first merged block comprising the first private block and the second private block;
wherein the processor is operable to record the first merged block to a single block on a second blockchain network;
wherein the processor is operable to record 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;
wherein the processor is operable to perform 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; and
wherein the processor is operable to perform a checkpointing process between the first private smart contract and the second smart contract comprising recording the state of the first private smart contract to the second smart contract, defining a checkpointed first private smart contract;
wherein the first private blockchain network has a parameter difference from the second blockchain network selected from the group consisting 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.
US15/942,604 2017-04-12 2018-04-02 Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing Active US10102265B1 (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
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/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/136,637 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/223,237 US10394845B2 (en) 2017-04-12 2018-12-18 Method and system for tuning blockchain scalability 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

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762484555P 2017-04-12 2017-04-12
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

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US16/127,283 Continuation-In-Part US10243743B1 (en) 2017-04-12 2018-09-11 Tokens or crypto currency using smart contracts and blockchains

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/119,163 Continuation US10289631B2 (en) 2017-04-12 2018-08-31 Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing

Publications (2)

Publication Number Publication Date
US10102265B1 US10102265B1 (en) 2018-10-16
US20180300382A1 true US20180300382A1 (en) 2018-10-18

Family

ID=63761632

Family Applications (3)

Application Number Title Priority Date Filing Date
US15/942,604 Active 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 Active 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/223,237 Active US10394845B2 (en) 2017-04-12 2018-12-18 Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing

Family Applications After (2)

Application Number Title Priority Date Filing Date
US16/119,163 Active 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/223,237 Active US10394845B2 (en) 2017-04-12 2018-12-18 Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing

Country Status (1)

Country Link
US (3) US10102265B1 (en)

Cited By (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109379429A (en) * 2018-10-25 2019-02-22 龚玉环 A kind of multichain management method and system based on block chain
CN109391690A (en) * 2018-10-18 2019-02-26 尚维斯 A kind of method that a plurality of block chain is added in list account
WO2019075560A1 (en) * 2017-10-16 2019-04-25 Btl Group Ltd. Method and system for facilitating data transfer between blockchains
CN109788042A (en) * 2018-12-28 2019-05-21 贵州蓝石科技有限公司 A kind of packet-based block chain network node communication method
CN109788045A (en) * 2018-12-28 2019-05-21 贵州蓝石科技有限公司 A kind of Intelligent routing processing method in block chain
CN109873881A (en) * 2019-01-04 2019-06-11 中国联合网络通信集团有限公司 The method and system of the autonomous number of selecting based on block chain
CN109951546A (en) * 2019-03-15 2019-06-28 百度在线网络技术（北京）有限公司 Transactions requests processing method, device, equipment and medium based on intelligent contract
US20190228469A1 (en) * 2018-01-22 2019-07-25 Blend Labs, Inc. Method and apparatus for a consumer controlled, decentralized financial profile
US20190244195A1 (en) * 2018-11-07 2019-08-08 Alibaba Group Holding Limited Blockchain system supporting public and private transactions under account models
CN110149202A (en) * 2019-04-26 2019-08-20 平安科技（深圳）有限公司 Parameter configuration, reconstructing method, device, equipment and medium based on block chain
CN110278462A (en) * 2019-06-20 2019-09-24 北京工业大学 A kind of mobile film projection authorization management method based on block chain
CN110321326A (en) * 2019-05-17 2019-10-11 杭州亦笔科技有限公司 A kind of block chained file fragment search method
CN110401534A (en) * 2019-09-04 2019-11-01 朱子腾 Account system based on no coin block chain
CN110598420A (en) * 2019-09-17 2019-12-20 北京丁牛科技有限公司 Cross-file intelligent contract reentry vulnerability defense method and device
US20200007343A1 (en) * 2018-06-28 2020-01-02 Blockchain Integrated Partners, Llc Systems and methods for data validation and assurance
TWI683590B (en) * 2018-11-28 2020-01-21 財團法人資訊工業策進會 Control method and control system for internet of things device
CN110753026A (en) * 2019-02-27 2020-02-04 北京嘀嘀无限科技发展有限公司 Block chain-based fragmentation method and device
US10552556B2 (en) 2017-08-03 2020-02-04 Liquineq AG System and method for performance testing of scalable distributed network transactional databases
CN110798509A (en) * 2019-07-15 2020-02-14 腾讯科技（深圳）有限公司 Block data synchronization method, device, medium and electronic equipment
US20200073962A1 (en) * 2018-08-29 2020-03-05 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
CN110929288A (en) * 2018-12-07 2020-03-27 深圳市智税链科技有限公司 Method for generating public key certificate, certificate authority and medium
US10650023B2 (en) * 2018-07-24 2020-05-12 Booz Allen Hamilton, Inc. Process for establishing trust between multiple autonomous systems for the purposes of command and control
KR20200067117A (en) * 2018-11-30 2020-06-11 알리바바 그룹 홀딩 리미티드 Platform for atomic transmission of smart assets within the blockchain network
US20200202350A1 (en) * 2017-08-29 2020-06-25 nChain Holdings Limited Constraints on outputs of an unlocking transaction in a blockchain
JP2020109617A (en) * 2019-01-02 2020-07-16 ライン プラス コーポレーションＬＩＮＥ Ｐｌｕｓ Ｃｏｒｐｏｒａｔｉｏｎ Transaction processing system and method for enabling extention of block chain
US20200252404A1 (en) * 2019-01-31 2020-08-06 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a declarative, metadata driven, cryptographically verifiable multi-network (multi-tenant) shared ledger
US20200250174A1 (en) * 2019-01-31 2020-08-06 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing efficient storage and validation of data and metadata within a blockchain using distributed ledger technology (dlt)
US20200311718A1 (en) * 2017-12-01 2020-10-01 Quant Network Ltd. Blockchain communications and ordering
EP3726774A1 (en) * 2019-04-16 2020-10-21 Nokia Solutions and Networks Oy Transparent blockchain sidechains to support blockchain processing heterogeneity
US20200334667A1 (en) * 2017-11-13 2020-10-22 Newglobes Ltd. Novel means and methods for implementation of secure transactions
US20200342449A1 (en) * 2019-04-29 2020-10-29 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing an api gateway to authorize and charge a fee for a transaction between cloud computing customers using distributed ledger technologies (dlt)
EP3742675A1 (en) * 2019-05-24 2020-11-25 Samsung SDS Co., Ltd. Accelerated processing apparatus for transaction considering transaction failure probability and method thereof
EP3748914A1 (en) * 2019-06-03 2020-12-09 Samsung SDS Co., Ltd. Accelerated processing apparatus for transaction and method thereof
CN112104558A (en) * 2020-10-30 2020-12-18 上海交通大学 Method, system, terminal and medium for implementing block chain distribution network
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
WO2021066954A1 (en) * 2019-10-04 2021-04-08 Microsoft Technology Licensing, Llc Subscription to dependencies in smart contracts
WO2021068477A1 (en) * 2019-10-11 2021-04-15 深圳壹账通智能科技有限公司 Block processing method, apparatus, computer device and storage medium
WO2021082340A1 (en) * 2019-10-30 2021-05-06 北京海益同展信息科技有限公司 Data processing method, apparatus, system, and storage medium
CN112910950A (en) * 2021-01-13 2021-06-04 杭州趣链科技有限公司 Uplink method and device for data to be uplink and block link point equipment
US11061886B2 (en) 2018-06-28 2021-07-13 Blockchain Integrated Partners, Llc Systems and methods for data validation and assurance
US20210243201A1 (en) * 2018-06-14 2021-08-05 Hewlett Packard Enterprise Development Lp Blockchain-based verification framework
US11108564B2 (en) * 2018-09-20 2021-08-31 Accenture Global Solutions Limited Cryptologic self-executing blockchain export commitment
US11107075B2 (en) 2018-05-10 2021-08-31 Advanced New Technologies Co., Ltd. Blockchain data processing methods, apparatuses, devices, and systems
US11159306B2 (en) * 2018-04-24 2021-10-26 Duvon Corporation Autonomous exchange via entrusted ledger token and transaction management
US11165787B2 (en) 2019-08-26 2021-11-02 Bank Of America Corporation System for authorization of electronic data access and processing functions within a distributed server network
US11196542B2 (en) 2018-08-29 2021-12-07 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US20210406877A1 (en) * 2018-09-29 2021-12-30 Jiangsu Fuzamei Technology Co. Ltd Digital Asset Custody Method and Apparatus and Storage Medium
KR20220001101A (en) * 2020-06-29 2022-01-05 한국전자통신연구원 Method and apparatus for generating block in blockchain system
US20220004539A1 (en) * 2020-07-06 2022-01-06 International Business Machines Corporation Privacy preserving architecture for permissioned blockchains
US20220058622A1 (en) * 2018-08-06 2022-02-24 Inveniam Capital Partners, Inc. Protocols in Blockchain Environments
US11281658B2 (en) * 2018-04-16 2022-03-22 Bc Development Labs Gmbh Trustless stateless incentivized remote node network using minimal verification clients
US20220108313A1 (en) * 2019-02-07 2022-04-07 Indian Institute Of Technology, Delhi Method in blockchain systems for fast stabilization and increased responsiveness
US11315112B2 (en) 2018-05-10 2022-04-26 Advanced New Technologies Co., Ltd. Blockchain data processing method, apparatus, device, and system
WO2022083871A1 (en) * 2020-10-22 2022-04-28 Qpq Ltd A system and method for self-adaptive and autonomous sharding of distributed ledger technology platforms
US11334439B2 (en) 2018-08-29 2022-05-17 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
KR20220071699A (en) * 2020-11-24 2022-05-31 제주대학교 산학협력단 Transaction data traffic control system and method in blockchain networks
US11356506B2 (en) * 2020-10-01 2022-06-07 Bank Of America Corporation System for optimizing data acceptance and data storage in a distributed computing network
US11373173B2 (en) * 2018-05-16 2022-06-28 Hitachi, Ltd. Distributed ledger system, distributed ledger subsystem, and distributed ledger node
WO2022141711A1 (en) * 2020-12-31 2022-07-07 杭州趣链科技有限公司 Method for asynchronous execution of transaction in blockchain, system and related device
US11386428B2 (en) 2018-08-07 2022-07-12 Advanced New Technologies Co., Ltd. Dual transaction method and system based on centralization and decentralization
US20220277300A1 (en) * 2019-09-24 2022-09-01 Jingdong Technology Information Technology Co., Ltd. Method and apparatus for executing smart contract
US20220366079A1 (en) * 2018-08-30 2022-11-17 Www.Trustscience.Com Inc. Data safe
USRE49334E1 (en) 2005-10-04 2022-12-13 Hoffberg Family Trust 2 Multifactorial optimization system and method
EP3881194A4 (en) * 2018-11-16 2022-12-14 Christopher Lyndon Higgins Distributed ledger systems, methods and devices
US20230017855A1 (en) * 2017-08-03 2023-01-19 Liquineq AG Distributed smart wallet communications platform
US20230046901A1 (en) * 2021-08-13 2023-02-16 NEC Laboratories Europe GmbH Blockchain based layer 2 application for delegated off-chain payments using cryptocurrencies
US11606442B2 (en) 2019-06-07 2023-03-14 Microsoft Technology Licensing, Llc Subscription to edits of blockchain transaction
US20230360158A1 (en) * 2022-05-09 2023-11-09 Bank Of America Corporation Intelligent transfer of assets using blockchain technology
US11824864B2 (en) 2019-01-31 2023-11-21 Salesforce, Inc. Systems, methods, and apparatuses for implementing a declarative and metadata driven blockchain platform using distributed ledger technology (DLT)
US11863686B2 (en) 2017-01-30 2024-01-02 Inveniam Capital Partners, Inc. Validating authenticity of electronic documents shared via computer networks
US11880349B2 (en) 2019-04-30 2024-01-23 Salesforce, Inc. System or method to query or search a metadata driven distributed ledger or blockchain
US11899817B2 (en) 2019-01-31 2024-02-13 Salesforce, Inc. Systems, methods, and apparatuses for storing PII information via a metadata driven blockchain using distributed and decentralized storage for sensitive user information
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
US12118556B2 (en) * 2018-09-05 2024-10-15 International Business Machines Corporation Database configuration for asset transfers
US12147417B2 (en) 2022-02-09 2024-11-19 Blockchains, Inc. Trustless stateless incentivized remote node network using minimal verification clients

Families Citing this family (177)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11521290B2 (en) * 2013-05-22 2022-12-06 Patrick Damien O'Brien Systems and methods for storing contract information on multiple blockchain ledgers
US10992649B2 (en) * 2016-04-01 2021-04-27 Consensys Software Inc. Systems and methods for privacy in distributed ledger transactions
US10411897B2 (en) 2017-02-17 2019-09-10 Factom, Inc. Secret sharing via blockchains
US10817873B2 (en) 2017-03-22 2020-10-27 Factom, Inc. Auditing of electronic documents
US10740733B2 (en) * 2017-05-25 2020-08-11 Oracle International Corporaton Sharded permissioned distributed ledgers
EP3664005B1 (en) * 2017-06-07 2021-12-08 Nchain Holdings Limited Credential generation and distribution method and system for a blockchain network
EP3639469B1 (en) * 2017-06-14 2024-04-03 nChain Licensing AG Systems and methods for addressing security-related vulnerabilities arising in relation to off-blockchain channels in the event of failures in a network
US11238164B2 (en) * 2017-07-10 2022-02-01 Burstiq, Inc. Secure adaptive data storage platform
US10547594B2 (en) * 2017-08-17 2020-01-28 Domanicom Corporation Systems and methods for implementing data communication with security tokens
US10735199B2 (en) * 2018-01-02 2020-08-04 Bank Of America Corporation File based transmission validation and failure location identification system
US11251937B2 (en) * 2018-01-21 2022-02-15 CipherTrace, Inc. Distributed security mechanism for blockchains and distributed ledgers
US11153097B1 (en) * 2018-03-01 2021-10-19 Wells Fargo Bank, N.A. Systems and methods for distributed extensible blockchain structures
CN108712257B (en) * 2018-04-03 2020-04-17 阿里巴巴集团控股有限公司 Cross-block-chain authentication method and device and electronic equipment
US11170366B2 (en) 2018-05-18 2021-11-09 Inveniam Capital Partners, Inc. Private blockchain services
US10783164B2 (en) 2018-05-18 2020-09-22 Factom, Inc. Import and export in blockchain environments
US11134120B2 (en) 2018-05-18 2021-09-28 Inveniam Capital Partners, Inc. Load balancing in blockchain environments
US20190354606A1 (en) * 2018-05-18 2019-11-21 Factom Private Cryptocoinage in Blockchain Environments
US10095888B1 (en) * 2018-06-04 2018-10-09 Capital One Services, Llc Secure decentralized system utilizing smart contracts, a blockchain, and/or a distributed file system
US11507928B2 (en) * 2018-06-05 2022-11-22 International Business Machines Corporation Blockchain and cryptocurrency for real-time vehicle accident management
US10409783B1 (en) 2018-06-06 2019-09-10 Capital One Services, Llc Distributed work data management
CN108847925B (en) * 2018-06-20 2020-09-15 深圳大学 Fragment block chain generation method based on tree structure
US10764258B2 (en) * 2018-06-29 2020-09-01 Arm Ip Limited Blockchain infrastructure for securing and/or managing electronic artifacts
GB201811263D0 (en) * 2018-07-10 2018-08-29 Netmaster Solutions Ltd A method and system for managing digital using a blockchain
US11374753B2 (en) 2018-07-27 2022-06-28 Hrl Laboratories, Llc System and method for selective transparency for public ledgers
EP3831012B1 (en) * 2018-07-27 2023-08-23 HRL Laboratories, LLC Bidirectional blockchain
US11328290B2 (en) 2018-08-06 2022-05-10 Inveniam Capital Partners, Inc. Stable cryptocurrency coinage
US11989208B2 (en) 2018-08-06 2024-05-21 Inveniam Capital Partners, Inc. Transactional sharding of blockchain transactions
US10915521B2 (en) * 2018-08-21 2021-02-09 Syniverse Technologies, Llc Blockchain gateway device and associated method of use
US11314699B1 (en) 2018-09-06 2022-04-26 Side, Inc. Single-tier blockchain-based system and method for document transformation and accountability
US12095934B2 (en) 2018-09-13 2024-09-17 International Business Machines Corporation Sparse peer with transient participation
US11861697B1 (en) * 2018-09-14 2024-01-02 United Services Automobile Association (Usaa) Distributed ledger for letter of credit tracking
US11386494B2 (en) * 2018-09-19 2022-07-12 Coinone Inc. Cryptocurrency trading method and system
US10812581B2 (en) 2018-10-12 2020-10-20 Bank Of America Corporation Heterogeneous distributed ledger data curator
US20210314154A1 (en) * 2018-10-17 2021-10-07 Hewlett-Packard Development Company, L.P. Apparatus and method for dynamic sharding of concurrent blockchains
KR102444425B1 (en) 2018-10-23 2022-09-16 삼성에스디에스 주식회사 Apparatus for performing batch processing for blockchain transactions and method thereof
US10855447B2 (en) * 2018-10-30 2020-12-01 EMC IP Holding Company LLC Request approval using blockchain technology
CN109639410B (en) 2018-10-31 2021-04-06 创新先进技术有限公司 Block chain-based data evidence storing method and device and electronic equipment
US11100090B2 (en) * 2018-11-06 2021-08-24 International Business Machines Corporation Offloaded chaincode execution for a database
CN109462587B (en) * 2018-11-09 2020-03-27 四川虹微技术有限公司 Block chain layered consensus method, block chain network system and block chain node
CN109670800A (en) * 2018-11-15 2019-04-23 亦非云互联网技术（上海）有限公司 Transaction processing method and system, storage medium and terminal based on ether mill
JP6699861B2 (en) 2018-11-16 2020-05-27 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ Cross-chain interaction using domain name method in blockchain system
EP3549324B1 (en) 2018-11-16 2020-10-07 Alibaba Group Holding Limited A domain name management scheme for cross-chain interactions in blockchain systems
CA3041163C (en) * 2018-11-16 2020-10-06 Alibaba Group Holding Limited A domain name scheme for cross-chain interactions in blockchain systems
CN110035046B (en) * 2018-11-16 2020-02-21 阿里巴巴集团控股有限公司 Cross-block chain interaction system
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 创新先进技术有限公司 Data reading method and system based on multiple block chain networks
CN111899102A (en) * 2018-11-30 2020-11-06 创新先进技术有限公司 Method for realizing privacy protection in block chain
CN109600433B (en) * 2018-12-06 2022-03-29 北京磁云数字科技有限公司 Method and device for summarizing data in system
CN109636389B (en) * 2018-12-13 2020-09-22 东软集团股份有限公司 Method, device, equipment and storage medium for determining block chaining-out time
US11348101B2 (en) * 2018-12-19 2022-05-31 International Business Machines Corporation Post-settlement processes
US11720545B2 (en) 2018-12-19 2023-08-08 International Business Machines Corporation Optimization of chaincode statements
WO2020124199A1 (en) * 2018-12-19 2020-06-25 Glance Pay Inc. Method, system, and computer readable medium for transferring cryptographic tokens
CN109413228B (en) * 2018-12-20 2021-06-01 全链通有限公司 IPv6 generation method and system based on block chain domain name system
US10637644B1 (en) * 2018-12-21 2020-04-28 Capital One Services, Llc System and method for authorizing transactions in an authorized member network
CN109711192B (en) * 2018-12-24 2021-10-01 众安信息技术服务有限公司 Method and system for inter-node transaction of block chain system
US11588643B2 (en) * 2018-12-27 2023-02-21 Paypal, Inc. Blockchain management system
KR20200083940A (en) * 2018-12-28 2020-07-09 알리바바 그룹 홀딩 리미티드 Accelerate transaction delivery in blockchain networks using transaction retransmission
US11977537B2 (en) * 2018-12-28 2024-05-07 Hefei Dappworks Technology Co., Ltd. Method and device of processing data for blockchain, and blockchain system
EP3571655B1 (en) * 2018-12-28 2021-09-29 Advanced New Technologies Co., Ltd. Accelerating transaction deliveries in blockchain networks using acceleration nodes
JP2020516108A (en) * 2018-12-28 2020-05-28 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ Improving Blockchain Transaction Speed Using Global Acceleration Nodes
CN109767216B (en) * 2018-12-29 2020-10-02 莆田市烛火信息技术有限公司 Account book accounting system of block chain network with regularly converged parallel chains
US11018848B2 (en) 2019-01-02 2021-05-25 Bank Of America Corporation Blockchain management platform for performing asset adjustment, cross sectional editing, and bonding
US11012232B2 (en) 2019-01-02 2021-05-18 Bank Of America Corporation Blockchain management platform for performing asset adjustment, cross sectional editing, and bonding
US11115186B2 (en) 2019-01-02 2021-09-07 Bank Of America Corporation Blockchain management platform for performing asset adjustment, cross sectional editing, and bonding
CN109673010B (en) * 2019-01-04 2021-09-21 中国联合网络通信集团有限公司 Block chain-based number portability method and device and storage medium
US11177962B2 (en) * 2019-02-05 2021-11-16 Visa International Service Association Optimizations for verification of interactions system and method
CN109784020A (en) * 2019-02-15 2019-05-21 上海优扬新媒信息技术有限公司 A kind of block chain right management method and device
CN111612614A (en) * 2019-02-26 2020-09-01 傲为信息技术(江苏)有限公司 Public link-based sub-chain service system
JP6806924B2 (en) * 2019-03-04 2021-01-06 アリババ グループ ホウルディング リミテッド Methods and equipment for processing certificates in blockchain systems
EP3938989A4 (en) * 2019-03-15 2022-11-23 Madisetti, Vijay Method and system for exchange of value or tokens between blockchain networks
CN109992624B (en) * 2019-03-15 2024-03-22 深圳前海微众银行股份有限公司 Synchronous storage method and device for Block chain and computer equipment
US11159308B2 (en) 2019-03-20 2021-10-26 PolySign, Inc. Preventing an erroneous transmission of a copy of a record of data to a distributed ledger system
US11038685B1 (en) * 2019-03-22 2021-06-15 Turing Technology, Inc. Correcting blockchain transactions with cryptocurrency type mistakes
EP3716565A1 (en) * 2019-03-27 2020-09-30 Nokia Technologies Oy Controlled data access in a communication network
CN110084594A (en) * 2019-04-01 2019-08-02 杜晓楠 A kind of block chain method of commerce and device by lightning network
US11151261B2 (en) 2019-04-03 2021-10-19 Cisco Technology, Inc. Blockchain system with severable data and cryptographic proof
US11108553B2 (en) * 2019-04-05 2021-08-31 International Business Machines Corporation Database transaction guaranteed commitment
CN110018840B (en) * 2019-04-11 2021-12-03 深圳市迅雷网络技术有限公司 Intelligent contract upgrading method and device, block chain link point equipment and medium
US20200327556A1 (en) * 2019-04-12 2020-10-15 Salesforce.Com, Inc. Method to accept certifications with blockchain transactions
US11372817B2 (en) 2019-04-18 2022-06-28 International Business Machines Corporation Synchronization of peers
CN110189161B (en) * 2019-04-26 2022-06-17 华中科技大学 Block chain consensus method and system for realizing marketing label sharing
US11194770B2 (en) * 2019-05-02 2021-12-07 International Business Machines Corporation Database mergeable ledgers
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
US11050822B2 (en) 2019-06-05 2021-06-29 International Business Machines Corporation Secure data dissemination
CR20220015A (en) * 2019-06-13 2022-04-22 Gutierrez Sheris Luis Eduardo System and method using a fitness-gradient blockchain consensus
CN110335041B (en) * 2019-06-20 2021-07-16 腾讯科技（深圳）有限公司 Consistency detection method, device, equipment and storage medium for intelligent contract calling
CN110347684B (en) * 2019-06-28 2020-09-01 阿里巴巴集团控股有限公司 Block chain based hierarchical storage method and device and electronic equipment
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
US10853341B2 (en) 2019-06-28 2020-12-01 Advanced New Technologies Co., Ltd. Blockchain based hierarchical data storage
CN110443704B (en) * 2019-06-28 2021-02-19 创新先进技术有限公司 Method and device for sending resources in cross-link mode
CN112003703B (en) * 2019-06-28 2023-08-22 创新先进技术有限公司 Method and device for transmitting authenticatable message across chains
US10742415B2 (en) * 2019-06-28 2020-08-11 Alibaba Group Holding Limited Method and apparatus for inter-blockchain transmission of authenticable message
US11651082B2 (en) * 2019-07-11 2023-05-16 Battelle Memorial Institute Blockchain applicability framework
EP3669281B1 (en) 2019-07-11 2024-04-03 Advanced New Technologies Co., Ltd. Shared blockchain data storage
US11310055B2 (en) * 2019-07-11 2022-04-19 PolySign, Inc. Preventing an incorrect transmission of a copy of a record of data to a distributed ledger system
SG11202001989WA (en) * 2019-07-11 2020-04-29 Alibaba Group Holding Ltd Shared blockchain data storage
CN111108478B (en) 2019-07-11 2023-11-21 创新先进技术有限公司 Method, system and apparatus for communicating and sharing blockchain data
CN110557427B (en) * 2019-07-15 2022-07-26 浙江工业大学 Intelligent home security control method for balancing network performance and security
CN110458702A (en) * 2019-07-15 2019-11-15 阿里巴巴集团控股有限公司 Based on the virtual resource allocation method and device of block chain, electronic equipment
US10785168B2 (en) 2019-07-15 2020-09-22 Alibaba Group Holding Limited Allocating virtual resource based on block chain
MY192336A (en) * 2019-07-23 2022-08-17 Advanced New Technologies Co Ltd Managing transactions on blockchain networks
CN110417889B (en) * 2019-07-30 2022-02-01 中国联合网络通信集团有限公司 Data transmission method and device based on IPFS
US11556909B2 (en) * 2019-08-16 2023-01-17 Visa International Service Association Universal payment channels
US11159326B1 (en) * 2019-08-29 2021-10-26 Hiro Systems Pbc Client-side authentication system and associated method
CN110598416B (en) * 2019-08-30 2020-12-04 创新先进技术有限公司 Transaction scheduling method and device
US10762228B2 (en) 2019-08-30 2020-09-01 Alibaba Group Holding Limited Transaction scheduling method and apparatus
US11228452B2 (en) 2019-09-16 2022-01-18 Cisco Technology, Inc. Distributed certificate authority
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
CN110807684B (en) * 2019-10-16 2022-08-19 广州快批信息科技有限公司 Block chain technology-based sales document storage method, device, server and medium
CN110780848B (en) * 2019-10-16 2023-05-12 上海链度科技有限公司 Dual-random generation method and supervision system based on block chain distributed random process
CN110796391A (en) * 2019-11-12 2020-02-14 北京芯际科技有限公司 Block chain-based construction worker performance data method
CN110807672A (en) * 2019-11-12 2020-02-18 北京芯际科技有限公司 Block chain-based point cashing method
US11720526B2 (en) 2019-11-12 2023-08-08 ClearTrace Technologies, Inc. Sustainable energy tracking system utilizing blockchain technology and Merkle tree hashing structure
US10698728B1 (en) * 2019-11-15 2020-06-30 Blockstack Pbc Systems and methods for forming application-specific blockchains
US11468044B2 (en) 2019-11-25 2022-10-11 Visa International Service Association Optimizations for verification of interactions system and method using probability density functions
US11138576B2 (en) * 2019-11-25 2021-10-05 Mastercard International Incorporated Method and system for net settlement of withheld funds via blockchain
CN111209339B (en) * 2020-01-03 2021-09-14 腾讯科技（深圳）有限公司 Block synchronization method, device, computer and storage medium
CN111241115B (en) * 2020-01-07 2022-02-22 腾讯科技（深圳）有限公司 Data synchronization method, device, equipment and storage medium
US11343075B2 (en) 2020-01-17 2022-05-24 Inveniam Capital Partners, Inc. RAM hashing in blockchain environments
US11323269B2 (en) * 2020-01-20 2022-05-03 International Business Machines Corporation Preserving privacy of linked cross-network transactions
US20230074590A1 (en) * 2020-01-22 2023-03-09 The Flowchain Foundation Limited Storage Virtualization Architecture with Hybrid Blockchain and the Method Thereof
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities
US11874804B2 (en) 2020-02-05 2024-01-16 International Business Machines Corporation Load balancing based blockchain transaction submission
CN111327610B (en) * 2020-02-17 2022-03-01 湖南天河国云科技有限公司 Block chain system registration method and device based on credit score and storage medium
US11682095B2 (en) 2020-02-25 2023-06-20 Mark Coast Methods and apparatus for performing agricultural transactions
CN111339114B (en) * 2020-02-28 2023-05-09 百度在线网络技术（北京）有限公司 Data access method, device, equipment and storage medium
CN111461371B (en) * 2020-03-20 2022-02-15 广州大学 Network taxi booking method and system combining public chain and private chain
US11138586B1 (en) 2020-03-23 2021-10-05 Daxchain Limited Digital asset exchange system and related methods
CN111400106B (en) * 2020-03-27 2023-07-28 百度国际科技（深圳）有限公司 Block chain account book synchronization method and device and electronic equipment
CN111476671A (en) * 2020-04-08 2020-07-31 杭州复杂美科技有限公司 Block chain rollback insurance method, equipment and storage medium
US11539787B2 (en) 2020-04-30 2022-12-27 T-Mobile Usa, Inc. 5G enabled massively distributed on-demand personal cloud system and method
US11418587B2 (en) 2020-04-30 2022-08-16 T-Mobile Usa, Inc. 5G on-demand dynamically instantiated blockchain for highly distributed peer-to-peer consumer cloud
SG10202004063TA (en) * 2020-05-04 2021-01-28 Alipay Labs Singapore Pte Ltd Method and system for determining blockchain-based gridlock resolution
CN111523895A (en) * 2020-05-06 2020-08-11 杭州复杂美科技有限公司 Data delay publishing method, device and storage medium
CN111932250A (en) * 2020-06-08 2020-11-13 国网浙江省电力有限公司台州供电公司 Method for realizing power grid information sharing based on block chain technology
CN111523900A (en) 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 Block chain consensus method, device and system based on Byzantine fault-tolerant algorithm
CN111526217B (en) 2020-07-03 2020-10-09 支付宝(杭州)信息技术有限公司 Consensus method and system in block chain
US11550949B2 (en) * 2020-07-21 2023-01-10 Constella Intelligence, Inc. Secure exchange of password presence data
CN111767347B (en) * 2020-07-27 2021-09-10 腾讯科技（深圳）有限公司 Switching method and device of consensus algorithm, node equipment and storage medium
WO2022027175A1 (en) * 2020-08-03 2022-02-10 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain transaction processing systems and methods
CN111949634A (en) * 2020-08-07 2020-11-17 广州科创空间信息科技有限公司 Method for synchronously migrating block chain data
US11651096B2 (en) 2020-08-24 2023-05-16 Burstiq, Inc. Systems and methods for accessing digital assets in a blockchain using global consent contracts
US11615074B2 (en) 2020-10-01 2023-03-28 Bank Of America Corporation System and methods for intelligent path selection of enhanced distributed processors
US20220114580A1 (en) * 2020-10-08 2022-04-14 Kpmg Llp Tokenized energy settlements application
CN112311933B (en) * 2020-10-27 2021-10-15 杭州天宽科技有限公司 Sensitive information shielding method and system
CN112258183B (en) * 2020-10-28 2023-08-01 成都质数斯达克科技有限公司 Cross-chain private transaction method, blockchain network and electronic equipment
US11509719B2 (en) 2020-12-03 2022-11-22 Seagate Technology Llc Blockchain technology in data storage system
CN112488680B (en) * 2020-12-04 2024-02-20 深圳前海微众银行股份有限公司 Private transaction processing method and device based on blockchain
JP6858919B2 (en) * 2020-12-04 2021-04-14 アリババ グループ ホウルディング リミテッド Methods and equipment for processing certificates in blockchain systems
US11438175B2 (en) 2020-12-29 2022-09-06 CipherTrace, Inc. Systems and methods for correlating cryptographic addresses between blockchain networks
CN114692174B (en) * 2020-12-30 2024-08-27 航天信息股份有限公司 Electronic license service system, method, device, medium and equipment
CN112732720B (en) * 2021-01-11 2022-05-24 杭州复杂美科技有限公司 Data storage method, data query method, computer device and storage medium
CN112733204B (en) * 2021-01-16 2023-01-20 阳江市链点创新科技发展有限公司 Anti-counterfeiting tracing method based on block chain and multiple signature technology
CA3206764C (en) 2021-01-29 2024-02-27 Troy Martin Sustainable energy physical delivery tracking and verification of actual environmental impact
US12026789B2 (en) 2021-02-08 2024-07-02 CipherTrace, Inc. Systems and methods of forensic analysis of cryptocurrency transactions
CN113518103A (en) * 2021-03-01 2021-10-19 唐芮 Industrial Internet of things networking control method and system
US12008526B2 (en) 2021-03-26 2024-06-11 Inveniam Capital Partners, Inc. Computer system and method for programmatic collateralization services
CN113364754B (en) * 2021-05-31 2023-10-13 支付宝(杭州)信息技术有限公司 Data sharing method, device and equipment
CN113411383B (en) * 2021-06-11 2022-12-06 深圳市好实再科技有限公司 Commodity information query method and system based on block chain and storage medium
US12137179B2 (en) 2021-06-19 2024-11-05 Inveniam Capital Partners, Inc. Systems and methods for processing blockchain transactions
US12007972B2 (en) 2021-06-19 2024-06-11 Inveniam Capital Partners, Inc. Systems and methods for processing blockchain transactions
US20230043731A1 (en) 2021-08-06 2023-02-09 Salesforce.Com, Inc. Database system public trust ledger architecture
CN113628052A (en) * 2021-08-18 2021-11-09 杭州云象网络技术有限公司 Block chain asset and contract processing method, system and device based on prediction machine
US11989726B2 (en) 2021-09-13 2024-05-21 Salesforce, Inc. Database system public trust ledger token creation and exchange
WO2023102180A1 (en) * 2021-12-03 2023-06-08 Ava Labs, Inc. Token-less and key-value mapping virtual machines
US11770445B2 (en) 2022-01-25 2023-09-26 Salesforce, Inc. Decentralized information management database system
US20230376918A1 (en) * 2022-03-30 2023-11-23 chaya Gangadarappa Blockchain-based digital payments platform
US11880372B2 (en) 2022-05-10 2024-01-23 Salesforce, Inc. Distributed metadata definition and storage in a database system for public trust ledger smart contracts
CN115204827A (en) * 2022-07-13 2022-10-18 李蹊 Human resource management system and method based on block chain technology
CN115378951B (en) * 2022-07-20 2024-07-16 中国科学院计算技术研究所 Dynamic controllable blockchain multi-person channel efficient hybrid consensus method and system
CN116028990B (en) * 2023-03-30 2023-07-18 中国科学技术大学 Anti-tampering privacy protection log auditing method based on blockchain
CN116110228B (en) * 2023-04-06 2023-07-07 齐鲁云商数字科技股份有限公司 Urban traffic rapid guiding system based on block chain
CN117592985B (en) * 2024-01-18 2024-05-07 广东通莞科技股份有限公司 Pos machine settlement business data management system based on blockchain
CN118195641B (en) * 2024-05-17 2024-08-06 智联信通科技股份有限公司 Block chain-based intelligent manufacturing field production whole-flow traceability method

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160283920A1 (en) 2015-03-28 2016-09-29 Justin Fisher Authentication and verification of digital data utilizing blockchain technology
US11200564B2 (en) * 2015-03-31 2021-12-14 Nasdaq, Inc. Systems and methods of blockchain transaction recordation
US20170132625A1 (en) * 2015-11-05 2017-05-11 Mastercard International Incorporated Method and system for use of a blockchain in a transaction processing network
US10841082B2 (en) 2015-11-24 2020-11-17 Adi BEN-ARI System and method for blockchain smart contract data privacy
US10142347B2 (en) * 2016-02-10 2018-11-27 Bank Of America Corporation System for centralized control of secure access to process data network
US10636033B2 (en) * 2016-02-22 2020-04-28 Bank Of America Corporation System for routing of process authorizations and settlement to a user in a process data network
US10440101B2 (en) 2016-02-22 2019-10-08 Bank Of America Corporation System for external validation of private-to-public transition protocols
US10157078B2 (en) 2016-04-10 2018-12-18 Bank Of America Corporation System for transforming large scale electronic processing using application block chain
US10362058B2 (en) * 2016-05-13 2019-07-23 Vmware, Inc Secure and scalable data transfer using a hybrid blockchain-based approach
US10114980B2 (en) * 2016-07-21 2018-10-30 Acronis International Gmbh System and method for verifying data integrity using a blockchain network
US10402796B2 (en) * 2016-08-29 2019-09-03 Bank Of America Corporation Application life-cycle transition record recreation system
US20180130034A1 (en) * 2016-11-07 2018-05-10 LedgerDomain, LLC Extended blockchains for event tracking and management
US20180285217A1 (en) * 2017-03-31 2018-10-04 Intel Corporation Failover response using a known good state from a distributed ledger

Cited By (98)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE49334E1 (en) 2005-10-04 2022-12-13 Hoffberg Family Trust 2 Multifactorial optimization system and method
US11863686B2 (en) 2017-01-30 2024-01-02 Inveniam Capital Partners, Inc. Validating authenticity of electronic documents shared via computer networks
US10552556B2 (en) 2017-08-03 2020-02-04 Liquineq AG System and method for performance testing of scalable distributed network transactional databases
US12051060B2 (en) * 2017-08-03 2024-07-30 Liquineq AG Distributed smart wallet communications platform
US20230017855A1 (en) * 2017-08-03 2023-01-19 Liquineq AG Distributed smart wallet communications platform
US20200202350A1 (en) * 2017-08-29 2020-06-25 nChain Holdings Limited Constraints on outputs of an unlocking transaction in a blockchain
US12026710B2 (en) * 2017-08-29 2024-07-02 Nchain Licensing Ag Constraints on outputs of an unlocking transaction in a blockchain
US11941624B2 (en) 2017-08-29 2024-03-26 Nchain Licensing Ag Concurrent state machine processing using a blockchain
US10764034B2 (en) 2017-10-16 2020-09-01 North Peak Resources Ltd. Method and system for facilitating data transfer between blockchains
WO2019075560A1 (en) * 2017-10-16 2019-04-25 Btl Group Ltd. Method and system for facilitating data transfer between blockchains
US20200334667A1 (en) * 2017-11-13 2020-10-22 Newglobes Ltd. Novel means and methods for implementation of secure transactions
US11842335B2 (en) * 2017-12-01 2023-12-12 Quant Network Ltd. Blockchain communications and ordering
US20200311718A1 (en) * 2017-12-01 2020-10-01 Quant Network Ltd. Blockchain communications and ordering
US20190228469A1 (en) * 2018-01-22 2019-07-25 Blend Labs, Inc. Method and apparatus for a consumer controlled, decentralized financial profile
US11281658B2 (en) * 2018-04-16 2022-03-22 Bc Development Labs Gmbh Trustless stateless incentivized remote node network using minimal verification clients
US11159306B2 (en) * 2018-04-24 2021-10-26 Duvon Corporation Autonomous exchange via entrusted ledger token and transaction management
US11107075B2 (en) 2018-05-10 2021-08-31 Advanced New Technologies Co., Ltd. Blockchain data processing methods, apparatuses, devices, and systems
US11315112B2 (en) 2018-05-10 2022-04-26 Advanced New Technologies Co., Ltd. Blockchain data processing method, apparatus, device, and system
US11373173B2 (en) * 2018-05-16 2022-06-28 Hitachi, Ltd. Distributed ledger system, distributed ledger subsystem, and distributed ledger node
US20210243201A1 (en) * 2018-06-14 2021-08-05 Hewlett Packard Enterprise Development Lp Blockchain-based verification framework
US20200007343A1 (en) * 2018-06-28 2020-01-02 Blockchain Integrated Partners, Llc Systems and methods for data validation and assurance
US11874819B2 (en) 2018-06-28 2024-01-16 Blockchain Integrated Partners, Llc Systems and methods for data validation and assurance
US11061886B2 (en) 2018-06-28 2021-07-13 Blockchain Integrated Partners, Llc Systems and methods for data validation and assurance
US11392615B2 (en) * 2018-07-24 2022-07-19 Booz Allen Hamilton, Inc. Process for establishing trust between multiple autonomous systems for the purposes of command and control
US10650023B2 (en) * 2018-07-24 2020-05-12 Booz Allen Hamilton, Inc. Process for establishing trust between multiple autonomous systems for the purposes of command and control
US20220058622A1 (en) * 2018-08-06 2022-02-24 Inveniam Capital Partners, Inc. Protocols in Blockchain Environments
US11386428B2 (en) 2018-08-07 2022-07-12 Advanced New Technologies Co., Ltd. Dual transaction method and system based on centralization and decentralization
US11334439B2 (en) 2018-08-29 2022-05-17 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US10901957B2 (en) * 2018-08-29 2021-01-26 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US20200073962A1 (en) * 2018-08-29 2020-03-05 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US11196542B2 (en) 2018-08-29 2021-12-07 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US20220366079A1 (en) * 2018-08-30 2022-11-17 Www.Trustscience.Com Inc. Data safe
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
US12118556B2 (en) * 2018-09-05 2024-10-15 International Business Machines Corporation Database configuration for asset transfers
US11108564B2 (en) * 2018-09-20 2021-08-31 Accenture Global Solutions Limited Cryptologic self-executing blockchain export commitment
US20210406877A1 (en) * 2018-09-29 2021-12-30 Jiangsu Fuzamei Technology Co. Ltd Digital Asset Custody Method and Apparatus and Storage Medium
CN109391690A (en) * 2018-10-18 2019-02-26 尚维斯 A kind of method that a plurality of block chain is added in list account
CN109379429A (en) * 2018-10-25 2019-02-22 龚玉环 A kind of multichain management method and system based on block chain
US20190244195A1 (en) * 2018-11-07 2019-08-08 Alibaba Group Holding Limited Blockchain system supporting public and private transactions under account models
US12131318B2 (en) 2018-11-16 2024-10-29 Christopher Lyndon Higgins Distributed ledger systems, methods and devices
EP3881194A4 (en) * 2018-11-16 2022-12-14 Christopher Lyndon Higgins Distributed ledger systems, methods and devices
TWI683590B (en) * 2018-11-28 2020-01-21 財團法人資訊工業策進會 Control method and control system for internet of things device
KR20200067117A (en) * 2018-11-30 2020-06-11 알리바바 그룹 홀딩 리미티드 Platform for atomic transmission of smart assets within the blockchain network
US11030188B2 (en) 2018-11-30 2021-06-08 Advanced New Technologies Co., Ltd. Platform for atomic transfer of smart assets within blockchain networks
KR102151895B1 (en) 2018-11-30 2020-09-03 알리바바 그룹 홀딩 리미티드 A platform for atomic transmission of smart assets within a blockchain network
CN110929288A (en) * 2018-12-07 2020-03-27 深圳市智税链科技有限公司 Method for generating public key certificate, certificate authority and medium
CN109788045A (en) * 2018-12-28 2019-05-21 贵州蓝石科技有限公司 A kind of Intelligent routing processing method in block chain
CN109788042A (en) * 2018-12-28 2019-05-21 贵州蓝石科技有限公司 A kind of packet-based block chain network node communication method
JP2020109617A (en) * 2019-01-02 2020-07-16 ライン プラス コーポレーションＬＩＮＥ Ｐｌｕｓ Ｃｏｒｐｏｒａｔｉｏｎ Transaction processing system and method for enabling extention of block chain
JP7460348B2 (en) 2019-01-02 2024-04-02 ライン プラス コーポレーション Transaction processing system and method enabling blockchain expansion
CN109873881A (en) * 2019-01-04 2019-06-11 中国联合网络通信集团有限公司 The method and system of the autonomous number of selecting based on block chain
US11811769B2 (en) * 2019-01-31 2023-11-07 Salesforce, Inc. Systems, methods, and apparatuses for implementing a declarative, metadata driven, cryptographically verifiable multi-network (multi-tenant) shared ledger
US11899817B2 (en) 2019-01-31 2024-02-13 Salesforce, Inc. Systems, methods, and apparatuses for storing PII information via a metadata driven blockchain using distributed and decentralized storage for sensitive user information
US20200250174A1 (en) * 2019-01-31 2020-08-06 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing efficient storage and validation of data and metadata within a blockchain using distributed ledger technology (dlt)
US20200252404A1 (en) * 2019-01-31 2020-08-06 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a declarative, metadata driven, cryptographically verifiable multi-network (multi-tenant) shared ledger
US11971874B2 (en) * 2019-01-31 2024-04-30 Salesforce, Inc. Systems, methods, and apparatuses for implementing efficient storage and validation of data and metadata within a blockchain using distributed ledger technology (DLT)
US11824864B2 (en) 2019-01-31 2023-11-21 Salesforce, Inc. Systems, methods, and apparatuses for implementing a declarative and metadata driven blockchain platform using distributed ledger technology (DLT)
US20220108313A1 (en) * 2019-02-07 2022-04-07 Indian Institute Of Technology, Delhi Method in blockchain systems for fast stabilization and increased responsiveness
CN110753026A (en) * 2019-02-27 2020-02-04 北京嘀嘀无限科技发展有限公司 Block chain-based fragmentation method and device
CN109951546A (en) * 2019-03-15 2019-06-28 百度在线网络技术（北京）有限公司 Transactions requests processing method, device, equipment and medium based on intelligent contract
EP3726774A1 (en) * 2019-04-16 2020-10-21 Nokia Solutions and Networks Oy Transparent blockchain sidechains to support blockchain processing heterogeneity
CN110149202A (en) * 2019-04-26 2019-08-20 平安科技（深圳）有限公司 Parameter configuration, reconstructing method, device, equipment and medium based on block chain
US20200342449A1 (en) * 2019-04-29 2020-10-29 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing an api gateway to authorize and charge a fee for a transaction between cloud computing customers using distributed ledger technologies (dlt)
US11880349B2 (en) 2019-04-30 2024-01-23 Salesforce, Inc. System or method to query or search a metadata driven distributed ledger or blockchain
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
CN110321326A (en) * 2019-05-17 2019-10-11 杭州亦笔科技有限公司 A kind of block chained file fragment search method
EP3742675A1 (en) * 2019-05-24 2020-11-25 Samsung SDS Co., Ltd. Accelerated processing apparatus for transaction considering transaction failure probability and method thereof
EP3748914A1 (en) * 2019-06-03 2020-12-09 Samsung SDS Co., Ltd. Accelerated processing apparatus for transaction and method thereof
US11507565B2 (en) * 2019-06-03 2022-11-22 Samsung Sds Co., Ltd. Accelerated processing apparatus for transaction and method thereof
US11606442B2 (en) 2019-06-07 2023-03-14 Microsoft Technology Licensing, Llc Subscription to edits of blockchain transaction
CN110278462A (en) * 2019-06-20 2019-09-24 北京工业大学 A kind of mobile film projection authorization management method based on block chain
CN110798509A (en) * 2019-07-15 2020-02-14 腾讯科技（深圳）有限公司 Block data synchronization method, device, medium and electronic equipment
US11881939B2 (en) 2019-08-26 2024-01-23 Bank Of America Corporation System for authorization of electronic data access and processing functions within a distributed server network
US11165787B2 (en) 2019-08-26 2021-11-02 Bank Of America Corporation System for authorization of electronic data access and processing functions within a distributed server network
CN110401534A (en) * 2019-09-04 2019-11-01 朱子腾 Account system based on no coin block chain
CN110598420A (en) * 2019-09-17 2019-12-20 北京丁牛科技有限公司 Cross-file intelligent contract reentry vulnerability defense method and device
US20220277300A1 (en) * 2019-09-24 2022-09-01 Jingdong Technology Information Technology Co., Ltd. Method and apparatus for executing smart contract
EP3982320A4 (en) * 2019-09-24 2023-06-14 Jingdong Technology Information Technology Co., Ltd. Method and device for executing smart contract
US11115804B2 (en) 2019-10-04 2021-09-07 Microsoft Technology Licensing, Llc Subscription to dependencies in smart contracts
WO2021066954A1 (en) * 2019-10-04 2021-04-08 Microsoft Technology Licensing, Llc Subscription to dependencies in smart contracts
WO2021068477A1 (en) * 2019-10-11 2021-04-15 深圳壹账通智能科技有限公司 Block processing method, apparatus, computer device and storage medium
WO2021082340A1 (en) * 2019-10-30 2021-05-06 北京海益同展信息科技有限公司 Data processing method, apparatus, system, and storage medium
KR20220001101A (en) * 2020-06-29 2022-01-05 한국전자통신연구원 Method and apparatus for generating block in blockchain system
US12003645B2 (en) 2020-06-29 2024-06-04 Electronics And Telecommunications Research Institute Method and apparatus for creating blocks in blockchain system
KR102582359B1 (en) * 2020-06-29 2023-09-25 한국전자통신연구원 Method and apparatus for generating block in blockchain system
US11853291B2 (en) * 2020-07-06 2023-12-26 International Business Machines Corporation Privacy preserving architecture for permissioned blockchains
US20220004539A1 (en) * 2020-07-06 2022-01-06 International Business Machines Corporation Privacy preserving architecture for permissioned blockchains
US11356506B2 (en) * 2020-10-01 2022-06-07 Bank Of America Corporation System for optimizing data acceptance and data storage in a distributed computing network
WO2022083871A1 (en) * 2020-10-22 2022-04-28 Qpq Ltd A system and method for self-adaptive and autonomous sharding of distributed ledger technology platforms
CN112104558A (en) * 2020-10-30 2020-12-18 上海交通大学 Method, system, terminal and medium for implementing block chain distribution network
KR20220071699A (en) * 2020-11-24 2022-05-31 제주대학교 산학협력단 Transaction data traffic control system and method in blockchain networks
WO2022114436A1 (en) * 2020-11-24 2022-06-02 제주대학교 산학협력단 System and method for controlling traffic of blockchain transaction data
KR102415298B1 (en) * 2020-11-24 2022-06-30 제주대학교 산학협력단 Transaction data traffic control system and method in blockchain networks
WO2022141711A1 (en) * 2020-12-31 2022-07-07 杭州趣链科技有限公司 Method for asynchronous execution of transaction in blockchain, system and related device
CN112910950A (en) * 2021-01-13 2021-06-04 杭州趣链科技有限公司 Uplink method and device for data to be uplink and block link point equipment
US20230046901A1 (en) * 2021-08-13 2023-02-16 NEC Laboratories Europe GmbH Blockchain based layer 2 application for delegated off-chain payments using cryptocurrencies
US12147417B2 (en) 2022-02-09 2024-11-19 Blockchains, Inc. Trustless stateless incentivized remote node network using minimal verification clients
US20230360158A1 (en) * 2022-05-09 2023-11-09 Bank Of America Corporation Intelligent transfer of assets using blockchain technology

Also Published As

Publication number Publication date
US20180373776A1 (en) 2018-12-27
US20190146979A1 (en) 2019-05-16
US10102265B1 (en) 2018-10-16
US10289631B2 (en) 2019-05-14
US10394845B2 (en) 2019-08-27

Similar Documents

Publication Publication Date Title
US10394845B2 (en) Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing
US10579643B2 (en) Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing
US20240248894A1 (en) Dag based methods and systems of transaction processing in a distributed ledger
Sabry et al. The road to the blockchain technology: Concept and types
Decker et al. Bitcoin meets strong consistency
CN109219940B (en) Private node and processing method in private node
US10282558B2 (en) System and method for maintaining a segregated database in a multiple distributed ledger system
US20200401578A1 (en) System and method for managing a blockchain cloud service
US20190172026A1 (en) Cross blockchain secure transactions
US20200151686A1 (en) System and method for cross-border blockchain platform
US20190251199A1 (en) Transactions Across Blockchain Networks
Bozic et al. Securing virtual machine orchestration with blockchains
JP2022508247A (en) High-performance distributed recording system with reliability-based consensus
CN118395709A (en) Computer-implemented system and method for connecting blockchain to digital twinning
US11822538B2 (en) Systems and methods of transaction identification generation for transaction-based environment
AU2019204733A1 (en) Performing parallel execution of transactions in a distributed ledger system
JP2022509933A (en) High-performance distributed recording system with key management
JP2022512324A (en) High-performance distributed recording system with secure interoperability to external systems
CN109727132B (en) Method and device for acquiring block chain consensus node, electronic equipment and storage medium
TW202135504A (en) Platform services verification
JP2022508211A (en) High-performance distributed recording system with hosted origin service
US11775553B2 (en) Data integrity of replicated databases
CN115280346A (en) Block chain transaction double cost proof
EP3876472B1 (en) Verifiably unique transfer of exclusive control of data units
JP7574990B2 (en) Information processing device and program

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: SMAL); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

AS Assignment

Owner name: MADISETTI, VIJAY K., GEORGIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BAHGA, ARSHDEEP;REEL/FRAME:046862/0137

Effective date: 20180913

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2551); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

Year of fee payment: 4