US20230198774A1 - Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys - Google Patents
Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys Download PDFInfo
- Publication number
- US20230198774A1 US20230198774A1 US18/109,017 US202318109017A US2023198774A1 US 20230198774 A1 US20230198774 A1 US 20230198774A1 US 202318109017 A US202318109017 A US 202318109017A US 2023198774 A1 US2023198774 A1 US 2023198774A1
- Authority
- US
- United States
- Prior art keywords
- dln
- account
- transaction
- distributed ledger
- processor
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000012550 audit Methods 0.000 claims description 28
- 230000015654 memory Effects 0.000 claims description 28
- 238000012546 transfer Methods 0.000 claims description 26
- 230000008569 process Effects 0.000 claims description 14
- 238000013500 data storage Methods 0.000 claims description 11
- 238000012545 processing Methods 0.000 claims description 8
- 238000012552 review Methods 0.000 description 18
- 230000009471 action Effects 0.000 description 16
- 238000012360 testing method Methods 0.000 description 8
- 230000006399 behavior Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000035515 penetration Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000010367 cloning Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000002427 irreversible effect Effects 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- 241000699670 Mus sp. Species 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3495—Performance evaluation by tracing or monitoring for systems
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3696—Methods or tools to render software testable
-
- 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/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- 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/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
-
- 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
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- 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
-
- 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
- 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
- Some embodiments described herein relate generally to distributed ledger data.
- some embodiments described herein relate to systems, apparatus, and methods for backing up and auditing distributed ledger data within a network and securely without using private keys.
- a distributed ledger is a consensus of replicated and synchronized data geographically shared across multiple notes on a network. Without using a centralized data storage, each distributed ledger database replicates and saves an identical copy of the ledger and updates itself independently.
- a distributed ledger may employ executing codes, also known as smart contracts, to manage transactions and permit trusted transactions to be carried out among disparate, anonymous parties without the need for a central authority.
- Private keys also known as private encryption keys
- a method includes generating, based on distributed ledger data associated with a first distributed ledger-based network (DLN), distributed ledger data associated with a second DLN.
- the first DLN and the second DLN each is a fork and the distributed ledger data associated with the first DLN include account data associated with a set of accounts.
- the method includes generating a request to initiate a transaction between a first account from the set of accounts and a second account from the set of accounts.
- the method includes authenticating the transaction based on a protocol associated with the second DLN and without using a private cryptographic key of the first account.
- the protocol associated with the second DLN is different from a protocol associated with the first DLN.
- the method includes sending a signal indicating the transaction was authenticated and storing information associated with the transaction in the distributed ledger data associated with the second DLN.
- FIG. 1 shows a distributed ledger-based network configured for use in conducting transactions between two participants of the distributed ledger-based network (DLN), according to some embodiments.
- DNN distributed ledger-based network
- FIG. 2 shows a schematic diagram of analyzing distributed ledger data without using private keys, according to some embodiments.
- FIG. 3 shows a diagram illustrating a block of distributed ledger data in a forked distributed ledger-based network, according to some embodiments.
- FIG. 4 is a flow chart illustrating a block of distributed ledger data in a forked distributed ledger-based network, according to some embodiments.
- parties participating in a transaction may elect to use a public distributed ledger-based network (DLN) to document the details of the transaction and manage its operations.
- DLNs can provide decentralized platforms that are transparent to at least all the participants of the networks, if not to the public at large, and as such, can be viewed as consensus-based platforms that facilitate trust between transaction participants without the need for a central authority to administer the network.
- parties participating in a transaction for a sale (e.g., private sale) of a digital music file can use a self-executing code or program (e.g., a smart contract) on the DLN to manage the sale of the music file.
- the self-executing code or smart contract can regulate the exchange of the music file and the correct payment (e.g., crypto-currency) for the file between the parties without involvement from a third party.
- the DLNs can also be used to manage transactions involving physical (e.g., non-digital) assets. In some implementations, this can be accomplished by using tokens to represent the assets, and a sale of an asset can be represented by the transfer of the token representing the asset from one party (e.g., the seller) to a second party (e.g., the buyer).
- a DLN can be and/or support a blockchain or blockchain network.
- distributed ledger-based network and “blockchain network” herein may be used interchangeably.
- self-executing code or “self-executing code segment” and “smart contract” may be used interchangeably.
- a smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of an agreement. Smart contracts allow the performance of credible transactions without third parties.
- a smart contract includes a set of contractual terms of the agreement between buyers and sellers and these contractual terms of the agreement are directly written into lines of self-executing code.
- the self-executing code and the agreements contained therein exist across distributed ledger-based network (DLN) (e.g., separate instances stored at multiple locations within the DLN).
- the self-executing code controls the execution of transactions, which are trackable and irreversible.
- These contractual terms of the agreement in smart contracts may also be referred to as a “protocol,” or “predefined rules.”
- Some example predefined rules include rules to govern and validate transactions, an algorithm that defines the mechanisms for all participating nodes to interact with each other, and, in some instances, application programming interface. For example, a music streaming platform can set up a smart contract to decentralize the collection of revenues and have a proper allocation of revenue payments to each music creator.
- An example of a predefined rule in this smart contract is that the ownership of a song is to be validated before dispersing royalty payment to the song's creator.
- Another example of a predefined rule in this smart contract is that for every $1000 of music sold, the musician gets an average royalty of $20.
- the term “transaction” may be used to refer, without limitations, to off-chain transactions (e.g., transactions involving the sale of physical or digital assets between parties) and/or on-chain representation of these off-chain transactions (e.g., the transaction of tokens that represent the assets on the blockchain network).
- the term “transaction” may also be used to refer to transactions that occur on the DLN (e.g., transfer of tokens such as but not limited to cryptocurrency between accounts on the DLN).
- the terms “off-chain” or “off-the DLN” are to be understood to refer to states or actions that are not occurring “on the blockchain network” or “on the DLN.”
- a statement such as “the data is stored off-the DLN” is to be understood to refer to the state of “the data not being stored on the storage system(s) of, or not being controlled by, the DLN (and is instead stored at or controlled by systems elsewhere, i.e., on a storage system that is not on the DLN.)
- smart contracts may be used to manage transactions or interactions on DLNs between multiple DLN participants without the need for a central authority to oversee the transactions.
- a smart contract may receive a request from a first participant (“sender”) to transfer some tokens from a DLN account of the first participant to a DLN account of a second participant (“recipient”).
- the smart contract may initiate the transfer process, i.e., the process of adjusting the token balances of the DLN accounts of the sender and the recipient as specified in the transfer request and according to any rules that may be applicable to the transaction, the DLN accounts of the sender and/or recipient, etc.
- the DLN account of the sender may be subject to a blackout period during which no tokens may be transferred out of the account.
- the smart contract may reject the transfer request or wait until the blackout period is over before proceeding with transferring the tokens.
- the DLN account of the sender may not be allowed to transfer a pre-determined number of tokens inside of or outside of a predefined period.
- a rule may include a list of accounts to which tokens from the DLN accounts of the sender can or cannot be transferred, resulting in the smart contract accepting or rejecting the transfer request, respectively.
- the use of smart contracts to manage transactions on DLNs may effectively limit the account rights of DLN account owners.
- the term “account owner” may refer to a participant of the DLN that owns or has access to the private key of an account on the DLN (e.g., such an account owner may be able to sign transactions that involve the account with the private key of the account).
- having ownership of, or access to, a private key of an account on the DLN may not indicate that the account owner also has full rights as they relate to the account.
- an account owner may take with respect to his/her DLN account due to smart contract rules that may apply to the actions and/or the account. For instance, the account owner may be blocked from transferring tokens from her/his account via a smart contract even if the tokens exist in the account and she/he has authorized the transaction (e.g., the transfer of the tokens) with a valid private key.
- an entity e.g., a reviewer, an auditor, and/or the like
- an entity that is tasked with reviewing transactions and accounts involved therewith may wish to review or analyze not only information related to the transactions and the related accounts (e.g., information related to the tokens in the accounts and/or transferred between accounts, the transaction participants, etc.), but also the behavior of the smart contract as it relates to the transactions and the related accounts (e.g., any rules that may apply to the transactions and related accounts).
- a participant of the DLN may engage an auditor to audit or review the participant's transactions and accounts involved therewith, and the auditor may wish to determine, for instance, the extent of the tokens that exist in the accounts. Further, in some implementations, the auditor may also wish to determine the extent of the rights the participant may have over the tokens in the accounts (besides, for instance, the participant's ownership of, or access to, the private keys of the accounts). That is, the auditor may wish to determine any limitations that may be placed on the tokens contained within the accounts (for example, due to smart contract rules). In such embodiments, to audit or review the accounts, the auditor may initially analyze the functionalities of the smart contract(s) of the DLN.
- the auditor may wish to establish that the smart contract, when activated by the auditor, can accurately determine or call the balance or immediate availability of tokens contained in the accounts.
- the auditor may wish to identify any smart contract rules that apply to the tokens to audit any restrictions that may be attached to the accounts (and tokens contained therein).
- Embodiments described herein can be implemented by any entities aiming to explore the behavior of smart contracts, including, but not limited to, reviewing or auditing participant's transactions and accounts, penetration testing (a simulated cyber-attack on a computer system, performed to evaluate the security of the system), and/or other system security testing.
- penetration testing a simulated cyber-attack on a computer system, performed to evaluate the security of the system
- An auditor may employ one or more techniques to analyze the functionalities of the smart contract of the DLN to establish that the smart contract, when activated by the auditor, can accurately determine or call the balance or immediate availability of tokens in accounts and/or to determine the presence of any smart contract rules that may apply to tokens in the accounts.
- the auditor may request the purported account owner (“auditee”) to transfer the tokens to a predetermined account as a demonstration of the owner's ability to transfer the tokens—that is, as a demonstration that the tokens exist in the account, the owner has the private key to the account, there are no smart contract rules limiting or restricting the owner's rights over the tokens, and/or etc.
- Such a technique may be cumbersome and costly (e.g., in the form of transaction fees) for the auditee, as well as being unscalable for the auditor.
- the auditor may fork the DLN (i.e., obtain a full copy of the first DLN, including stored smart contract data related to all transactions recorded on the distributed ledgers of the first DLN since the inception of the first DLN) and transfer the tokens in the auditee's account in the forked DLN (i.e., without affecting the first DLN) to another account as the above-noted demonstration.
- a fork or a forked DLN (or the second DLN) implements a different protocol from the protocol associated with the original DLN (or the first DLN).
- the protocol of the forked DLN may include rules that are same as the rules in the protocol of the original DLN, and also includes rules that are different from the rules in the protocol of the original DLN.
- the forked DLN can be a soft fork or a hard fork.
- the forked DLN when the computing nodes in the original DLN execute transactions only based on the protocol associated with the original DLN and not based on the new protocol in the forked DLN, the forked DLN can be referred to as a soft fork.
- participant can transact with each other using forked tokens from a DLN account of a first participant to a DLN account of a second participant.
- the auditor may have to have access to the private keys of the account owners, which may not be desirable for both the auditor and the auditee (e.g., due to security and liability reasons).
- a need exists for determining information (including, but not limited to, the balance, the availability, and the limitations) of tokens in an account and acting on the tokens without the knowledge of the private key of the account owner.
- the forked DLN can set new protocols or rules different from the first DLN.
- an account owner or the auditee
- each transaction has a header including a “From” field (e.g., the origination address of that transaction) and a “To” field (e.g., a destination address of the transaction).
- the “To” field includes an identifier of the recipient of the transaction.
- the “From” field is derived based on the signature of the sender of the transaction when the sender of the transaction signs the transaction using its private keys.
- the auditor can set new protocols that do not require each transaction to be signed.
- the “From” field e.g., the origination address of that transaction
- the sender of the transaction can set its own “From” address (e.g., a number, a text string, a symbol, an identifier, and/or the like).
- the auditor DLN client can approve the transaction without using a signature of the sender or having the sender sign the transaction with its private keys. Accordingly, analyzing the distributed ledger data (or auditing the functionalities of the smart contracts) can be achieved with flexibility and scalability.
- a method includes generating, based on distributed ledger data associated with a first distributed ledger-based network (DLN), distributed ledger data associated with a second DLN.
- the first DLN and the second DLN each is a fork and the distributed ledger data associated with the first DLN include account data associated with a set of accounts.
- the method includes generating a request to initiate a transaction between a first account from the set of accounts and a second account from the set of accounts.
- the method includes authenticating the transaction based on a protocol associated with the second DLN and without using a private cryptographic key of the first account.
- the protocol associated with the second DLN is different from a protocol associated with the first DLN.
- the method includes sending a signal indicating the transaction was authenticated and storing information associated with the transaction in the distributed ledger data associated with the second DLN.
- the term “audit” can refer to but is not limited to a review of actions taken on a DLN, a review of participants of the DLN, a review of accounts on the DLN, and/or the like.
- the actions may include transactions undertaken or represented on the DLN, such as but not limited to transactions between participants of the DLN.
- an “audit” of the transactions may include a review of the transaction data (e.g., for accuracy, completeness, and/or etc.).
- An audit or review of the participants may include, for example, a review of the participants' access to, ownership of, association with, and/or etc., with an account on the DLN.
- an “audit” of a participant on the DLN may include a review of the participant's credentials that the participant has access to, ownership of, association with, and/or etc., an account on the DLN.
- An audit or review of accounts on the DLN may include, for example, review of most or all information related to the accounts, including but not limited to contents of the accounts (e.g., assets such as but not limited to tokens contained therein), current and/or previous ownerships of the accounts, records related to the accounts, and/or the like.
- the term “auditor” may refer to the entity (e.g., person(s), companies, and/or etc.) performing the audit process as discussed above.
- an auditor may include entities that perform traditional auditing processes.
- an auditor may include entities that do not perform traditional auditing processes but may be provided access to review actions and/or accounts on the DLN, non-limiting examples of which include regulators, reviewers, observers, etc.
- the auditor may also be a participant of the DLN.
- the term “auditee” may refer to the entity (e.g., person(s), companies, and/or etc.) on the DLN that are involved in the transactions that are being audited, whose access to, ownership of, association with, and/or etc., to an account is being audited.
- the auditee may also be a participant of the DLN.
- FIG. 1 shows a distributed ledger-based network (“DLN”) configured for use in conducting transactions between two participants of the DLN, according to some embodiments.
- the DLN or blockchain network 100 includes multiple computing nodes 102 a - 102 e configured to communicate among each other via a peer-to-peer (P2P) connection.
- the computing nodes 102 a - 102 e can be computing devices including but not limited to computers, servers, processors, data/information processing machines or systems, and/or the like, and may include data storage systems such as databases, memories (volatile and/or non-volatile), etc. operatively coupled to the processors.
- the P2P connections may be provided by wired and/or wireless communications systems or networks such as but not limited to the internet, intranet, local area networks (LANs), wide area networks (WANs), etc., utilizing wireless communication protocols or standards such as WiFi®, LTE®, WiMAX®, and/or the like.
- the DLN 100 may include self-executing codes or smart contracts that are configured to be executed upon fulfillment of conditions that are agreed upon between transacting parties.
- some or all of the computing nodes 102 a - 102 e may include copies of a self-executing code that self-execute upon fulfillment of the conditions.
- the computing nodes 102 a - 102 e may communicate among each other with the results of the executions of their respective self-executing codes, for example, to arrive at a consensus on the results.
- one or a few of the computing nodes 102 a - 102 e may have self-executing codes that self-execute, and the results would be transmitted to the rest of the computing nodes 102 a - 102 e for confirmation.
- a self-executing code or a smart contract can facilitate the completion of transactions on the DLN 100 by providing the transacting parties confidence that the other party would deliver the promised product or payment.
- a smart contract can be used to verify that the seller of the file is in fact an owner of the file, the buyer of the music file has adequate resource to pay for the music file, etc. Further, the smart contract can facilitate the exchange of the music file by allowing the transfer of a payment to occur only after the transfer of the music file is completed (and validated).
- the self-executing code or smart contract may also include rules that apply to the accounts involved in the transactions and interfere with the completion of the transactions.
- the smart contract may include a rule restricting the supposed music buyer from transferring payment (e.g., tokens) for a period of time (e.g., until an investigation determines that none of the tokens are stolen, until the buyer reaches the age when she or he is allowed to access the music, etc.).
- payment e.g., tokens
- a period of time e.g., until an investigation determines that none of the tokens are stolen, until the buyer reaches the age when she or he is allowed to access the music, etc.
- the DLN 100 may be linked to one or more oracles (not shown) or data feeds that provide external data to the DLN 100 .
- self-executing codes or smart contracts can automatically execute upon realization of some conditions of a transaction, and the oracles may provide the data that can be used to evaluate whether the conditions are met.
- a transaction may be contingent on the price of a stock, a weather condition, etc., and an oracle may provide the requisite information to the smart contract facilitating the transaction.
- the smart contract upon receiving the information, may self-execute after determining that the condition for the transaction has been fulfilled.
- the oracles may facilitate for the smart contracts to send data out to external systems, for example by serving as data transmission hubs.
- At least a substantial number of the computing nodes 102 a - 102 e include copies of distributed ledger data (or a distributed ledger) 104 a - 104 e onto which transactions that occur on the network are recorded.
- the recording of the transactions on the distributed ledger data 104 a - 104 e may occur when some substantial proportion of the computing nodes 102 a - 102 e , or a subset thereof, agree on the validity of the transactions.
- the distributed ledger data 104 a - 104 e can be immutable or nearly immutable in the sense that to alter the distributed ledger data 104 a - 104 e , at least this substantial portion of the computing nodes 102 a - 102 e would have to agree, which can be increasingly difficult when the number of computing nodes 102 a - 102 e is large (and the distributed ledger data 104 a - 104 e gets longer).
- FIG. 2 shows a schematic diagram of analyzing distributed ledger data without using private keys, according to some embodiments.
- the first DLN 200 (or the original DLN) includes multiple computing nodes 202 a - 202 c configured to communicate among each other via a peer-to-peer (P2P) connection.
- the multiple computing nodes 202 a - 202 c are functionally and structurally similar to the multiple computing nodes 102 a - 102 e shown in FIG. 1 .
- Each of the computing nodes 202 a - 202 c can include a processor (not shown) and a memory (not shown) operatively coupled to the processor.
- the processor can be or include any processing device or component configured to perform the data collecting, processing and transmitting functions.
- the processor can be configured to, for example, write data into and read data from the memory, and execute the instructions stored within the memory.
- Processor can also be configured to execute and/or control, for example, the operations of the memory.
- the memory can be, for example, a random-access memory (RAM) (e.g., a dynamic RAM, a static RAM), a flash memory, a removable memory, and/or so forth.
- the memory can include, for example, a database, process, application, virtual machine, and/or some other software modules (stored and/or executing in hardware) or hardware modules.
- the first distributed ledger data 204 may include self-executing codes or smart contracts that are configured to execute upon fulfillment of predefined rules that are agreed upon between a set of accounts.
- a predefined rule in a smart contract of a music streaming service is that the ownership of a song is to be validated before dispersing royalty payment to the song's creator.
- a predefined rule in this smart contract is that a seller of the music approves the transaction with the seller's private key before the transaction is processed.
- At least a substantial number of the computing nodes 202 a - 202 c include copies of first distributed ledger data 204 onto which transactions that occur on the network are recorded. Similar to the distributed ledger data 104 a - 104 e shown in FIG.
- the first distributed ledger data 204 includes stored smart contract data related to all transactions recorded associated with a set of accounts on the first DLN 200 (for example, since the inception of the first DLN 200 .)
- Each of the computing nodes 202 a - 202 c is operatively coupled to the other computing nodes in the first DLN 200 .
- the auditor computing node 205 can include a processor (not shown) and a memory (not shown) operatively coupled to the processor.
- the processor can be or include any processing device or component configured to perform the data collecting, processing and transmitting functions.
- the processor can be configured to, for example, write data into and read data from the memory, and execute the instructions stored within the memory.
- Processor can also be configured to execute and/or control, for example, the operations of the memory.
- the memory can be, for example, a random-access memory (RAM) (e.g., a dynamic RAM, a static RAM), a flash memory, a removable memory, and/or so forth.
- the memory can include, for example, a database, process, application, virtual machine, and/or some other software modules (stored and/or executing in hardware) or hardware modules.
- an auditor computing node 205 (or a server) can generate, based on the first distributed ledger data 204 associated with the first DLN 200 , second distributed ledger data 206 associated with a second DLN 250 .
- the second distributed ledger data 206 is a forked copy of the first distributed ledger data 204 and it can include self-executing codes or smart contracts that are configured to execute upon fulfillment of conditions that are agreed upon between transacting parties.
- the first distributed ledger data 204 and the second distributed ledger data 206 include the substantially the same data when the second distributed ledger data 206 is generated.
- the second distributed ledger data 206 include recordings of transactions that occur on the first DLN 200 before the first DLN 200 is forked (i.e., pre-fork transactions) as well as recordings of transactions that occur on the second DLN 250 after the first DLN 200 is forked (i.e., post-fork transactions).
- the post-fork transactions are executed for the auditing purposes (e.g., a review of participants' access to, ownership of, association with, and/or etc. with an account on the first DLN 200 .)
- the first DLN 200 does not include the second distributed ledger data 206 or any copies of the second distributed ledger data 206 .
- the second distributed ledger data 206 can only be stored at the second DLN 250 , not the first DLN 200 .
- the first distributed ledger data 204 can be stored at the first DLN 200 and the forked DLN 250 .
- Some or all of the computing nodes 202 a - 202 c may include copies of a self-executing code that self-execute upon fulfillment of the conditions.
- the computing nodes 202 a - 202 c may communicate among each other and arrive at a consensus of the results of executing the codes.
- one or a few of the computing nodes 202 a - 202 c may self-execute the codes and transmit the results to the rest of the computing nodes 202 a - 202 c for confirmation.
- Each of the computing nodes 202 a - 202 c and the auditor computing node 205 is operatively coupled to the other computing nodes in the second DLN 250 .
- the second DLN 250 includes the computing nodes 202 a - 202 c and the auditor computing node 205 configured to generate the second distributed ledger data 206 (i.e., the forked copy of the first distributed ledger data 204 ).
- an account owner who has ownership of, or access to, a private key of an account on the first DLN 200 , may not have full rights to the tokens in its account. For example, as discussed above, there may be restrictions on actions that the account owner can take with respect to the account owner's account due to smart contract rules (or a protocol associated with the first DLN 200 ) that may apply to the actions and/or the account.
- the account owner may be blocked from transferring a certain number of tokens from account owner's account via a smart contract even if the tokens exist in the account and the account owner has authorized the transaction (e.g., the transfer of the tokens) with a valid private key.
- an entity e.g., a reviewer, an auditor, and/or the like
- an entity that is tasked with reviewing transactions and accounts involved with the first DLN may wish to review or analyze not only information related to the transactions and the related accounts (e.g., information related to the tokens in the accounts and/or transferred between accounts, the transaction participants, etc.), but also the behavior of the smart contract as it relates to the transactions and the related accounts (e.g., any rules that may apply to the transactions and related accounts).
- the auditor computing node 205 can perform an action on a pre-determined number of tokens in the first account (or the second account) based on a second protocol associated with the second DLN 250 and without using a private cryptographic key of the first account.
- the auditor computing node 205 can set the second protocol (including a second set of rules) in the second DLN 250 which are different from the first protocol (including a first set of rules) associated with the first DLN 200 .
- a smart contract includes a set of contractual terms of the agreement between buyers and sellers and these contractual terms of the agreement are directly written into lines of self-executing code.
- the self-executing code and the agreements contained therein exist across distributed ledger-based network (DLN).
- the self-executing code controls the execution of transactions, which are trackable and irreversible.
- These contractual terms of the agreement in smart contracts may also be referred to as a “protocol,” or “predefined rules.”
- the auditor computing node 205 can generate a request to perform an action on a number of tokens in the first account. For example, the auditor computing node 205 can generate a request for a transaction to transfer a pre-determined number of tokens from a first account from a set of accounts to a second account from the set of accounts, a request for holding a pre-determined number of tokens in the first account for a pre-determined period of time, and/or the like. The auditor computing node 205 can perform the action on the pre-determined number of tokens without using a private cryptographic key of the first account (or the second account).
- the auditor computing node 205 can, for example, initiate a transaction of a set of tokens from a first account to a second account by setting an origination address in the header of the transaction.
- the auditor computing node 205 can set the origination address of the transaction to be different from the origination address of the first account holder, thus, alleviating the need of using the private cryptographic key of the first account.
- the auditor computing node 205 can approve the transaction from the first account without an approval (or signature) from the account holder of the first account.
- the auditor computing node 205 can set the origination address of the transaction via a graphical user interface (not shown in FIG. 2 ).
- the auditor computing node 205 can set the origination address of the transaction to two different addresses, and the computing nodes 202 a - 202 c may recognize the transaction to be originated from two different users. For example, the auditor computing node 205 can generate a second request to initiate a second transaction between the first account and the second account.
- the second request includes a second header having a second origination address associated with the first account different from the first origination address.
- FIG. 3 shows a block diagram illustrating a block of distributed ledger data in the forked DLN, according to some embodiments.
- a block 301 of the second distributed ledger data (e.g., 206 in FIG. 2 ) includes a block header 302 and a list of transactions 303 that are recorded on the block 301 .
- the list of transactions 303 include recordings of post-fork transactions.
- the “From” field 304 (or the origination address) in the header 302 of each block is provided by the sender (i.e., the auditor computing node 205 in FIG. 2 ) of that transaction.
- the auditor computing node 205 in FIG. 2 can set its own “From” address 304 (e.g., a number, a text string, a symbol, an identifier, and/or the like) in a post-fork transaction.
- the auditor computing node 205 in FIG. 2 can choose an origination address different from the origination address of the first account.
- the auditor computing node 205 in FIG. 2 can provide different identifiers in the “From” fields of transactions and the computing nodes 202 a - 202 c in the second DLN 250 may recognize it as different users (e.g., 209 a in FIG. 2 ) and (e.g., 209 b in FIG. 2 ).
- the auditor computing node 205 in FIG. 2 can approve the post-fork transaction 308 without using a signature of the account owner or having the account owner to sign the post-fork transaction with its private keys.
- the transaction 308 can then be added to the second distributed ledger data (e.g., 206 in FIG. 2 ).
- the auditor computing node 205 may use data of the post-fork transactions and data of the pre-fork transactions to determine the audit status of an account. For example, an auditor may be tasked to review or audit the accounts and transactions of the first DLN 200 participant (“auditee”). Smart contracts may include rules that apply to the accounts, tokens contained within accounts and/or transactions involving the accounts, and as a result may effectively limit the account rights of the account owners.
- the auditor may still wish to determine if there are any restrictions placed on the account and/or the tokens due to smart contract rules (e.g., an active transfer disable mode that may be applicable to the account and/or the tokens because the tokens were stolen, etc.).
- smart contract rules e.g., an active transfer disable mode that may be applicable to the account and/or the tokens because the tokens were stolen, etc.
- the auditor computing node 205 may analyze the data of the post-fork transactions stored in the second distributed ledger data 206 based on the smart contracts related to the pre-fork transactions stored in the second distributed ledger data 206 .
- the audit status of the account can include, but is not limited to, for example the authentication of the claimed account owner, the authentication of the account, the balance of the tokens in the account, the account owner's rights and limitations to each token in the account, what actions (e.g., transfer, or hold) the account owner can perform to each token in the account, presence or absence of a specific rule on a token in the account, and/or the like.
- the auditor computing node 205 determines or verifies the audit status (e.g., information including, but not limited to, the balance, the availability, and the limitations of tokens in the first account) of the first account, the auditor computing node 205 can send a signal (e.g., an audit report) to indicate or authenticate the transaction to transfer the requested tokens from the first account to the second account, or other actions that the auditor computing node 205 performed. In some instances, the auditor computing node 205 can send a signal to indicate the status of the audit process.
- a signal e.g., an audit report
- the auditor computing node 205 can store the information associated with the transaction in the second distributed ledger data 206 associated with the second DLN 250 and generate an updated copy of the second distributed ledger data including the second distributed ledger data 206 and information associated with the transaction. In some instances, the auditor computing node 205 does not store the information associated with the transaction in the first distributed ledger data 204 associated with the first DLN 200 . In some instances, the auditor computing node 206 can remove the second distributed ledger data 206 from its memory once the audit process is completed.
- the auditor computing node 205 may be operatively coupled to the multiple computing nodes 202 a - 202 c via the first DLN 200 . Similar to the multiple computing nodes 202 a - 202 c , the auditor computing node 205 can be configured to communicate with the multiple computing nodes 202 a - 202 c to arrive at a consensus on the executions of the smart contracts. The auditor computing node 205 may store the first distributed ledger data 204 in its memory.
- forking the first DLN 200 for each account that is being audited would involve a large amount of resources (e.g., data storage, bandwidth, etc.).
- resources e.g., data storage, bandwidth, etc.
- the use of a smart contract state data storage module that stores (e.g., locally) modifications to smart contract data may allow the auditor to analyze the functionalities of the smart contracts of the DLN without forking the first DLN 200 for each account.
- a block header in the first DLN 200 includes state data related to the transactions recorded on the first DLN 200 .
- the state data examples include status of accounts, and changes thereof, of accounts of the DLN 200 , such as but not limited to, changes or state transitions of account balances as payments made from one account to another.
- the state data may include information related to the amount of tokens in the accounts of a token transferor (e.g., buyer of a product or service) and a token recipient (e.g., seller of the product or service) prior to, and/or subsequent to, the transfer of tokens as an agreed-upon payment.
- a token transferor e.g., buyer of a product or service
- a token recipient e.g., seller of the product or service
- a state data storage overlay that is linked or coupled to the a single forked DLN (e.g., 250 ) may be used to store state data changes that result when a smart contract is activated or triggered to execute a transaction (e.g., by an auditor testing the smart contract with a test transaction) such that the state data changes are not stored in the state data storage.
- a smart contract is activated or triggered to execute a transaction (e.g., by an auditor testing the smart contract with a test transaction) such that the state data changes are not stored in the state data storage.
- a transaction e.g., by an auditor testing the smart contract with a test transaction
- multiple forked DLNs e.g., data size of each forked DLN may be in a scale of GB
- An example of the state data storage of the distributed ledger data is discussed in co-pending U.S. Provisional Patent Application No. 62/834,057, filed on Apr. 15, 2019 and entitled “Systems, Apparatus and Methods for Local State Storage of Distributed Ledger Data Without Cloning,” the contents of which are incorporated herein by reference in its entirety.
- the systems, apparatus and methods disclosed herein allow an auditor to interact with a smart contract of a DLN without using account owners' private keys.
- This capability is in particular highly useful when there is a need to interact with the smart contract a significant number of times (e.g., when having to audit a large number of accounts or transactions on a DLN) since, among other reasons, accessing the private keys of account owners are not desirable for security and scalability reasons.
- the systems, apparatus and methods disclosed herein enable an auditor to audit an account on a DLN (for example, determine the balance of the account of the auditee) without having to actually transfer the tokens from the auditee's account.
- the benefits include, but are not limited to, desire to avoid transaction fees and/or difficulties that arise when there are, in particular, a large number of accounts to audit such as but not limited to high memory requirements, computer and network performance degradations, and/or etc.
- FIG. 4 is a flow chart illustrating a process of forking distributed ledger data securely without using private keys, according to some embodiments.
- the method 400 can be executed at, for example, a processor of an auditor computing node such as the auditor computing node 205 in FIG. 2 .
- the method includes generating, based on the distributed ledger data associated with the first distributed ledger-based network (DLN), distributed ledger data associated with a second DLN.
- the first DLN includes multiple computing nodes configured to communicate among each other via a peer-to-peer (P2P) connection.
- the computing nodes in the first DLN may include a copy of the self-executing codes or smart contracts that are configured to be executed upon fulfillment of conditions that are agreed upon between transacting parties connected via the first DLN.
- the computing nodes in the first DLN may communicate among each other with the results of the executions of their respective self-executing codes, for example, to arrive at a consensus on the results.
- the first DLN may include a first protocol (or a first set of rules, a first smart contract) from a set of protocols that may include rules that apply to the accounts involved in the transactions.
- the first protocol may include a rule requiring all sellers to sign each transaction with its private cryptographic key to authenticate and authorize the transaction.
- the distributed ledger data associated with the second DLN is a forked copy of the distributed ledger data associated with the first DLN (also referred to as the first distributed ledger data).
- the second distributed ledger data include recordings of transactions that occur on the first DLN before the first DLN is forked (i.e., pre-fork transactions) as well as recordings of transactions that occur on the second DLN after the first DLN is forked (i.e., post-fork transactions).
- the post-fork transactions are executed for the auditing purposes (e.g., a review of participants' access to, ownership of, association with, and/or etc.
- the first DLN does not include the second distributed ledger data or any copies of the second distributed ledger data.
- the second distributed ledger data can only be stored at the second DLN, not the first DLN.
- the first distributed ledger data can be stored at the first DLN and the forked DLN.
- the method includes generating a request to initiate a transaction between a first account from the set of accounts and a second account from the set of accounts.
- An entity e.g., a reviewer, an auditor, and/or the like
- An entity that is tasked with reviewing transactions and accounts involved with the first DLN may wish to review or analyze not only information related to the transactions and the related accounts (e.g., information related to the tokens in the accounts and/or transferred between accounts, the transaction participants, etc.), but also the behavior of the smart contract as it relates to the transactions and the related accounts (e.g., any rules that may apply to the transactions and related accounts).
- the auditor computing node can perform an action on a pre-determined number of tokens in the first account (or the second account) based on a second protocol associated with the second DLN and without using a private cryptographic key of the first account. For example, the auditor computing node can generate a request for a transaction to transfer a pre-determined number of tokens from a first account from a set of accounts to a second account from the set of accounts, a request for holding a pre-determined number of tokens in the first account for a pre-determined period of time, and/or the like.
- the method includes authenticating the transaction based on a protocol associated with the second DLN and without using a private cryptographic key of the first account.
- the auditor computing node can set the second protocol (including a second set of rules) in the second DLN, which are different from the first protocol (including a first set of rules) associated with the first DLN.
- the transactions do not need to be signed by the account owner using its private keys (or its private cryptographic key(s)).
- the auditor computing node can perform the action on the pre-determined number of tokens without using a private cryptographic key of the first account (or the second account).
- the auditor computing node can, for example, initiate a transaction of a set of tokens from a first account to a second account by setting an origination address (e.g., “From” field) in the header of the transaction.
- the auditor computing node can set the origination address of the transaction to be different from the origination address of the first account holder, thus, alleviating the need of using the private cryptographic key of the first account.
- the auditor computing node can approve the transaction from the first account without an approval (or signature) from the account holder of the first account.
- the auditor computing node can set the origination address of the transaction via a graphical user interface
- the method includes sending a signal indicating the transaction was authenticated.
- the auditor computing node determines or verifies information (including, but not limited to, the balance, the availability, and the limitations) of tokens in the first account
- the auditor computing node can send a signal (e.g., an audit report) to indicate or authenticate the transaction to transfer the requested tokens from the first account to the second account, or other actions that the auditor computing node performed.
- the auditor computing node can send a signal to indicate the status of the audit process.
- the method includes storing information associated with the transaction in the distributed ledger data associated with the second DLN.
- the auditor computing node can store the information associated with the transaction in the second distributed ledger data associated with the second DLN and generate an updated copy of the second distributed ledger data including the second distributed ledger data and information associated with the transaction.
- the auditor computing node does not store the information associated with the transaction in the distributed ledger data associated with the first DLN.
- the auditor computing node can remove the distributed ledger data associated with the second DLN from its memory once the audit process is completed.
- Embodiments described herein can be implemented by any entities aiming to explore the behavior of smart contracts, including, but not limited to, reviewing or auditing participant's transactions and accounts, penetration testing (a simulated cyber attack on a computer system, performed to evaluate the security of the system), and/or other system security testing.
- penetration testing a simulated cyber attack on a computer system, performed to evaluate the security of the system
- other system security testing a simulated cyber attack on a computer system, performed to evaluate the security of the system.
- embodiments can be implemented in any of numerous ways. For example, embodiments may be implemented using hardware, software or a combination thereof.
- the software code can be stored (e.g., on non-transitory memory) and executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers.
- a computer may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, netbook computer, or a tablet computer. Additionally, a computer may be embedded in a device not generally regarded as a computer but with suitable processing capabilities, including a smart phone, smart device, or any other suitable portable or fixed electronic device.
- a computer can have one or more input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer can receive input information through speech recognition or in other audible format.
- Such computers can be interconnected by one or more networks in any suitable form, including a local area network or a wide area network, such as an enterprise network, and intelligent network (IN) or the Internet.
- networks can be based on any suitable technology and can operate according to any suitable protocol and can include wireless networks, wired networks or fiber optic networks.
- the various methods or processes outlined herein can be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software can be written using any of a number of suitable programming languages and/or programming or scripting tools, and also can be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.
- various disclosed concepts can be embodied as a computer readable storage medium (or multiple computer readable storage media) (e.g., a computer memory, one or more floppy discs, compact discs, optical discs, magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other non-transitory medium or tangible computer storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the disclosure discussed above.
- the computer readable medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present disclosure as discussed above.
- program or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of embodiments as discussed above. Additionally, it should be appreciated that according to one aspect, one or more computer programs that when executed perform methods of the present disclosure need not reside on a single computer or processor, but can be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the disclosure.
- Computer-executable instructions can be in many forms, such as program modules, executed by one or more computers or other devices.
- program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
- functionality of the program modules can be combined or distributed as desired in various embodiments.
- data structures can be stored in computer-readable media in any suitable form.
- data structures may be shown to have fields that are related through location in the data structure. Such relationships can likewise be achieved by assigning storage for the fields with locations in a computer-readable medium that convey relationship between the fields.
- any suitable mechanism can be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags or other mechanisms that establish relationship between data elements.
- a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.
- the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements.
- This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified.
- “at least one of A and B” can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Accounting & Taxation (AREA)
- Databases & Information Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Data Mining & Analysis (AREA)
- Finance (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 16/849,005, filed Apr. 15, 2020, and entitled “Systems, Apparatus and Methods for Backing Up and Auditing Distributed Ledger Data Within a Network and Securely Without Using Private Keys,” which is a non-provisional of and claims priority under 35 U.S.C. § 119 to U.S. provisional application Ser. No. 62/833,913, filed on Apr. 15, 2019, and entitled “Systems, Apparatus and Methods for Forking Distributed Ledger Data Within a Network and Securely Without Using Private Keys,” and U.S. Provisional Patent Application No. 62/834,057, filed on Apr. 15, 2019, and entitled “Systems, Apparatus and Methods for Local State Storage of Distributed Ledger Data Without Cloning,” the contents of which are incorporated herein by reference in their entirety.
- Some embodiments described herein relate generally to distributed ledger data. In particular, but not by way of limitation, some embodiments described herein relate to systems, apparatus, and methods for backing up and auditing distributed ledger data within a network and securely without using private keys.
- A distributed ledger is a consensus of replicated and synchronized data geographically shared across multiple notes on a network. Without using a centralized data storage, each distributed ledger database replicates and saves an identical copy of the ledger and updates itself independently. A distributed ledger may employ executing codes, also known as smart contracts, to manage transactions and permit trusted transactions to be carried out among disparate, anonymous parties without the need for a central authority. Private keys (also known as private encryption keys) are typically used to sign such transactions for authentication purposes. Thus, the private keys are only known to its user and are not shared among users to ensure security.
- Accordingly, a need exists for analyzing distributed ledger data without using private keys of individual users.
- In some embodiments, a method includes generating, based on distributed ledger data associated with a first distributed ledger-based network (DLN), distributed ledger data associated with a second DLN. The first DLN and the second DLN each is a fork and the distributed ledger data associated with the first DLN include account data associated with a set of accounts. The method includes generating a request to initiate a transaction between a first account from the set of accounts and a second account from the set of accounts. The method includes authenticating the transaction based on a protocol associated with the second DLN and without using a private cryptographic key of the first account. The protocol associated with the second DLN is different from a protocol associated with the first DLN. The method includes sending a signal indicating the transaction was authenticated and storing information associated with the transaction in the distributed ledger data associated with the second DLN.
-
FIG. 1 shows a distributed ledger-based network configured for use in conducting transactions between two participants of the distributed ledger-based network (DLN), according to some embodiments. -
FIG. 2 shows a schematic diagram of analyzing distributed ledger data without using private keys, according to some embodiments. -
FIG. 3 shows a diagram illustrating a block of distributed ledger data in a forked distributed ledger-based network, according to some embodiments. -
FIG. 4 is a flow chart illustrating a block of distributed ledger data in a forked distributed ledger-based network, according to some embodiments. - In some embodiments, parties participating in a transaction may elect to use a public distributed ledger-based network (DLN) to document the details of the transaction and manage its operations. DLNs can provide decentralized platforms that are transparent to at least all the participants of the networks, if not to the public at large, and as such, can be viewed as consensus-based platforms that facilitate trust between transaction participants without the need for a central authority to administer the network. For example, parties participating in a transaction for a sale (e.g., private sale) of a digital music file can use a self-executing code or program (e.g., a smart contract) on the DLN to manage the sale of the music file. The self-executing code or smart contract can regulate the exchange of the music file and the correct payment (e.g., crypto-currency) for the file between the parties without involvement from a third party. In some embodiments, the DLNs can also be used to manage transactions involving physical (e.g., non-digital) assets. In some implementations, this can be accomplished by using tokens to represent the assets, and a sale of an asset can be represented by the transfer of the token representing the asset from one party (e.g., the seller) to a second party (e.g., the buyer).
- In some embodiments, a DLN can be and/or support a blockchain or blockchain network. In some embodiments, the terms “distributed ledger-based network” and “blockchain network” herein may be used interchangeably. Similarly, in some embodiments, the terms “self-executing code” or “self-executing code segment” and “smart contract” may be used interchangeably. A smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of an agreement. Smart contracts allow the performance of credible transactions without third parties. A smart contract includes a set of contractual terms of the agreement between buyers and sellers and these contractual terms of the agreement are directly written into lines of self-executing code. The self-executing code and the agreements contained therein exist across distributed ledger-based network (DLN) (e.g., separate instances stored at multiple locations within the DLN). The self-executing code controls the execution of transactions, which are trackable and irreversible. These contractual terms of the agreement in smart contracts may also be referred to as a “protocol,” or “predefined rules.” Some example predefined rules include rules to govern and validate transactions, an algorithm that defines the mechanisms for all participating nodes to interact with each other, and, in some instances, application programming interface. For example, a music streaming platform can set up a smart contract to decentralize the collection of revenues and have a proper allocation of revenue payments to each music creator. An example of a predefined rule in this smart contract is that the ownership of a song is to be validated before dispersing royalty payment to the song's creator. Another example of a predefined rule in this smart contract is that for every $1000 of music sold, the musician gets an average royalty of $20.
- Further, in some embodiments, the term “transaction” may be used to refer, without limitations, to off-chain transactions (e.g., transactions involving the sale of physical or digital assets between parties) and/or on-chain representation of these off-chain transactions (e.g., the transaction of tokens that represent the assets on the blockchain network). In some embodiments, the term “transaction” may also be used to refer to transactions that occur on the DLN (e.g., transfer of tokens such as but not limited to cryptocurrency between accounts on the DLN). In some embodiments, the terms “off-chain” or “off-the DLN” are to be understood to refer to states or actions that are not occurring “on the blockchain network” or “on the DLN.” For example, a statement such as “the data is stored off-the DLN” is to be understood to refer to the state of “the data not being stored on the storage system(s) of, or not being controlled by, the DLN (and is instead stored at or controlled by systems elsewhere, i.e., on a storage system that is not on the DLN.)
- In some embodiments, as noted above, smart contracts may be used to manage transactions or interactions on DLNs between multiple DLN participants without the need for a central authority to oversee the transactions. For example, a smart contract may receive a request from a first participant (“sender”) to transfer some tokens from a DLN account of the first participant to a DLN account of a second participant (“recipient”). Upon receiving the request, in some implementations, the smart contract may initiate the transfer process, i.e., the process of adjusting the token balances of the DLN accounts of the sender and the recipient as specified in the transfer request and according to any rules that may be applicable to the transaction, the DLN accounts of the sender and/or recipient, etc. For example, the DLN account of the sender may be subject to a blackout period during which no tokens may be transferred out of the account. In such cases, the smart contract may reject the transfer request or wait until the blackout period is over before proceeding with transferring the tokens. In some cases, the DLN account of the sender may not be allowed to transfer a pre-determined number of tokens inside of or outside of a predefined period. As another example, a rule may include a list of accounts to which tokens from the DLN accounts of the sender can or cannot be transferred, resulting in the smart contract accepting or rejecting the transfer request, respectively.
- Accordingly, in some embodiments, the use of smart contracts to manage transactions on DLNs may effectively limit the account rights of DLN account owners. In some embodiments, the term “account owner” may refer to a participant of the DLN that owns or has access to the private key of an account on the DLN (e.g., such an account owner may be able to sign transactions that involve the account with the private key of the account). In some implementations, having ownership of, or access to, a private key of an account on the DLN, however, may not indicate that the account owner also has full rights as they relate to the account. For example, as discussed above, there may be restrictions on actions that an account owner can take with respect to his/her DLN account due to smart contract rules that may apply to the actions and/or the account. For instance, the account owner may be blocked from transferring tokens from her/his account via a smart contract even if the tokens exist in the account and she/he has authorized the transaction (e.g., the transfer of the tokens) with a valid private key. In such implementations, an entity (e.g., a reviewer, an auditor, and/or the like) that is tasked with reviewing transactions and accounts involved therewith may wish to review or analyze not only information related to the transactions and the related accounts (e.g., information related to the tokens in the accounts and/or transferred between accounts, the transaction participants, etc.), but also the behavior of the smart contract as it relates to the transactions and the related accounts (e.g., any rules that may apply to the transactions and related accounts).
- For example, a participant of the DLN (e.g., company, individual, etc.) may engage an auditor to audit or review the participant's transactions and accounts involved therewith, and the auditor may wish to determine, for instance, the extent of the tokens that exist in the accounts. Further, in some implementations, the auditor may also wish to determine the extent of the rights the participant may have over the tokens in the accounts (besides, for instance, the participant's ownership of, or access to, the private keys of the accounts). That is, the auditor may wish to determine any limitations that may be placed on the tokens contained within the accounts (for example, due to smart contract rules). In such embodiments, to audit or review the accounts, the auditor may initially analyze the functionalities of the smart contract(s) of the DLN. For example, to audit the existence of the tokens in the accounts, the auditor may wish to establish that the smart contract, when activated by the auditor, can accurately determine or call the balance or immediate availability of tokens contained in the accounts. As another example, the auditor may wish to identify any smart contract rules that apply to the tokens to audit any restrictions that may be attached to the accounts (and tokens contained therein). Embodiments described herein can be implemented by any entities aiming to explore the behavior of smart contracts, including, but not limited to, reviewing or auditing participant's transactions and accounts, penetration testing (a simulated cyber-attack on a computer system, performed to evaluate the security of the system), and/or other system security testing. Thus, although some embodiments are described herein in the context of auditing transactions and accounts, it should be understood that such embodiments can also be used in non-auditing contexts such as penetration testing, etc.
- An auditor may employ one or more techniques to analyze the functionalities of the smart contract of the DLN to establish that the smart contract, when activated by the auditor, can accurately determine or call the balance or immediate availability of tokens in accounts and/or to determine the presence of any smart contract rules that may apply to tokens in the accounts. For example, the auditor may request the purported account owner (“auditee”) to transfer the tokens to a predetermined account as a demonstration of the owner's ability to transfer the tokens—that is, as a demonstration that the tokens exist in the account, the owner has the private key to the account, there are no smart contract rules limiting or restricting the owner's rights over the tokens, and/or etc. Such a technique, however, may be cumbersome and costly (e.g., in the form of transaction fees) for the auditee, as well as being unscalable for the auditor.
- In some instances, the auditor may fork the DLN (i.e., obtain a full copy of the first DLN, including stored smart contract data related to all transactions recorded on the distributed ledgers of the first DLN since the inception of the first DLN) and transfer the tokens in the auditee's account in the forked DLN (i.e., without affecting the first DLN) to another account as the above-noted demonstration. In some embodiments, a fork or a forked DLN (or the second DLN) implements a different protocol from the protocol associated with the original DLN (or the first DLN). In some instances, the protocol of the forked DLN may include rules that are same as the rules in the protocol of the original DLN, and also includes rules that are different from the rules in the protocol of the original DLN. The forked DLN can be a soft fork or a hard fork. In some implementations, when the computing nodes in the original DLN execute transactions only based on the protocol associated with the original DLN and not based on the new protocol in the forked DLN, the forked DLN can be referred to as a soft fork.
- In the forked DLN, participants can transact with each other using forked tokens from a DLN account of a first participant to a DLN account of a second participant. To transfer the tokens in the account of the forked DLN, however, in some cases, the auditor may have to have access to the private keys of the account owners, which may not be desirable for both the auditor and the auditee (e.g., due to security and liability reasons). Thus, a need exists for determining information (including, but not limited to, the balance, the availability, and the limitations) of tokens in an account and acting on the tokens without the knowledge of the private key of the account owner.
- In some embodiments, the forked DLN can set new protocols or rules different from the first DLN. For example, in the first DLN, an account owner (or the auditee) can be required to sign each transaction with its private key to authenticate itself. Specifically, based on the known protocols in the first DLN, each transaction has a header including a “From” field (e.g., the origination address of that transaction) and a “To” field (e.g., a destination address of the transaction). The “To” field includes an identifier of the recipient of the transaction. The “From” field is derived based on the signature of the sender of the transaction when the sender of the transaction signs the transaction using its private keys.
- In the forked DLN, the auditor can set new protocols that do not require each transaction to be signed. In some implementations, the “From” field (e.g., the origination address of that transaction) in the header of each transaction is provided by the sender of that transaction. In other words, the sender of the transaction can set its own “From” address (e.g., a number, a text string, a symbol, an identifier, and/or the like). The auditor DLN client can approve the transaction without using a signature of the sender or having the sender sign the transaction with its private keys. Accordingly, analyzing the distributed ledger data (or auditing the functionalities of the smart contracts) can be achieved with flexibility and scalability.
- In some embodiments, a method includes generating, based on distributed ledger data associated with a first distributed ledger-based network (DLN), distributed ledger data associated with a second DLN. The first DLN and the second DLN each is a fork and the distributed ledger data associated with the first DLN include account data associated with a set of accounts. The method includes generating a request to initiate a transaction between a first account from the set of accounts and a second account from the set of accounts. The method includes authenticating the transaction based on a protocol associated with the second DLN and without using a private cryptographic key of the first account. The protocol associated with the second DLN is different from a protocol associated with the first DLN. The method includes sending a signal indicating the transaction was authenticated and storing information associated with the transaction in the distributed ledger data associated with the second DLN.
- In some embodiments, the term “audit” can refer to but is not limited to a review of actions taken on a DLN, a review of participants of the DLN, a review of accounts on the DLN, and/or the like. For example, the actions may include transactions undertaken or represented on the DLN, such as but not limited to transactions between participants of the DLN. For instance, an “audit” of the transactions may include a review of the transaction data (e.g., for accuracy, completeness, and/or etc.). An audit or review of the participants may include, for example, a review of the participants' access to, ownership of, association with, and/or etc., with an account on the DLN. For instance, an “audit” of a participant on the DLN may include a review of the participant's credentials that the participant has access to, ownership of, association with, and/or etc., an account on the DLN. An audit or review of accounts on the DLN may include, for example, review of most or all information related to the accounts, including but not limited to contents of the accounts (e.g., assets such as but not limited to tokens contained therein), current and/or previous ownerships of the accounts, records related to the accounts, and/or the like. The term “auditor” may refer to the entity (e.g., person(s), companies, and/or etc.) performing the audit process as discussed above. In some implementations, an auditor may include entities that perform traditional auditing processes. In some implementations, an auditor may include entities that do not perform traditional auditing processes but may be provided access to review actions and/or accounts on the DLN, non-limiting examples of which include regulators, reviewers, observers, etc. In some implementations, the auditor may also be a participant of the DLN. The term “auditee” may refer to the entity (e.g., person(s), companies, and/or etc.) on the DLN that are involved in the transactions that are being audited, whose access to, ownership of, association with, and/or etc., to an account is being audited. In some cases, the auditee may also be a participant of the DLN.
-
FIG. 1 shows a distributed ledger-based network (“DLN”) configured for use in conducting transactions between two participants of the DLN, according to some embodiments. In some embodiments, the DLN orblockchain network 100 includes multiple computing nodes 102 a-102 e configured to communicate among each other via a peer-to-peer (P2P) connection. In some implementations, the computing nodes 102 a-102 e can be computing devices including but not limited to computers, servers, processors, data/information processing machines or systems, and/or the like, and may include data storage systems such as databases, memories (volatile and/or non-volatile), etc. operatively coupled to the processors. In some implementations, the P2P connections may be provided by wired and/or wireless communications systems or networks such as but not limited to the internet, intranet, local area networks (LANs), wide area networks (WANs), etc., utilizing wireless communication protocols or standards such as WiFi®, LTE®, WiMAX®, and/or the like. - In some embodiments, the
DLN 100 may include self-executing codes or smart contracts that are configured to be executed upon fulfillment of conditions that are agreed upon between transacting parties. For example, some or all of the computing nodes 102 a-102 e may include copies of a self-executing code that self-execute upon fulfillment of the conditions. In some implementations, the computing nodes 102 a-102 e may communicate among each other with the results of the executions of their respective self-executing codes, for example, to arrive at a consensus on the results. In some implementations, one or a few of the computing nodes 102 a-102 e may have self-executing codes that self-execute, and the results would be transmitted to the rest of the computing nodes 102 a-102 e for confirmation. - In some embodiments, a self-executing code or a smart contract can facilitate the completion of transactions on the
DLN 100 by providing the transacting parties confidence that the other party would deliver the promised product or payment. For example, with reference to the above example related to the sale of a digital music file, a smart contract can be used to verify that the seller of the file is in fact an owner of the file, the buyer of the music file has adequate resource to pay for the music file, etc. Further, the smart contract can facilitate the exchange of the music file by allowing the transfer of a payment to occur only after the transfer of the music file is completed (and validated). In some embodiments, the self-executing code or smart contract may also include rules that apply to the accounts involved in the transactions and interfere with the completion of the transactions. For example, with respect to the example of the digital music file above, the smart contract may include a rule restricting the supposed music buyer from transferring payment (e.g., tokens) for a period of time (e.g., until an investigation determines that none of the tokens are stolen, until the buyer reaches the age when she or he is allowed to access the music, etc.). - In some embodiments, the
DLN 100 may be linked to one or more oracles (not shown) or data feeds that provide external data to theDLN 100. In some implementations, as discussed above, self-executing codes or smart contracts can automatically execute upon realization of some conditions of a transaction, and the oracles may provide the data that can be used to evaluate whether the conditions are met. For example, a transaction may be contingent on the price of a stock, a weather condition, etc., and an oracle may provide the requisite information to the smart contract facilitating the transaction. The smart contract, upon receiving the information, may self-execute after determining that the condition for the transaction has been fulfilled. In some embodiments, the oracles may facilitate for the smart contracts to send data out to external systems, for example by serving as data transmission hubs. - In some embodiments, at least a substantial number of the computing nodes 102 a-102 e include copies of distributed ledger data (or a distributed ledger) 104 a-104 e onto which transactions that occur on the network are recorded. The recording of the transactions on the distributed ledger data 104 a-104 e may occur when some substantial proportion of the computing nodes 102 a-102 e, or a subset thereof, agree on the validity of the transactions. The distributed ledger data 104 a-104 e can be immutable or nearly immutable in the sense that to alter the distributed ledger data 104 a-104 e, at least this substantial portion of the computing nodes 102 a-102 e would have to agree, which can be increasingly difficult when the number of computing nodes 102 a-102 e is large (and the distributed ledger data 104 a-104 e gets longer).
-
FIG. 2 shows a schematic diagram of analyzing distributed ledger data without using private keys, according to some embodiments. In some embodiments, similar to the distributed ledger-based network (DLN) 100 shown inFIG. 1 , the first DLN 200 (or the original DLN) includes multiple computing nodes 202 a-202 c configured to communicate among each other via a peer-to-peer (P2P) connection. The multiple computing nodes 202 a-202 c are functionally and structurally similar to the multiple computing nodes 102 a-102 e shown inFIG. 1 . Each of the computing nodes 202 a-202 c can include a processor (not shown) and a memory (not shown) operatively coupled to the processor. The processor can be or include any processing device or component configured to perform the data collecting, processing and transmitting functions. The processor can be configured to, for example, write data into and read data from the memory, and execute the instructions stored within the memory. Processor can also be configured to execute and/or control, for example, the operations of the memory. The memory can be, for example, a random-access memory (RAM) (e.g., a dynamic RAM, a static RAM), a flash memory, a removable memory, and/or so forth. In some embodiments, the memory can include, for example, a database, process, application, virtual machine, and/or some other software modules (stored and/or executing in hardware) or hardware modules. - The first distributed
ledger data 204 may include self-executing codes or smart contracts that are configured to execute upon fulfillment of predefined rules that are agreed upon between a set of accounts. For example, a predefined rule in a smart contract of a music streaming service is that the ownership of a song is to be validated before dispersing royalty payment to the song's creator. For another example, a predefined rule in this smart contract is that a seller of the music approves the transaction with the seller's private key before the transaction is processed. At least a substantial number of the computing nodes 202 a-202 c include copies of first distributedledger data 204 onto which transactions that occur on the network are recorded. Similar to the distributed ledger data 104 a-104 e shown inFIG. 1 , the first distributedledger data 204 includes stored smart contract data related to all transactions recorded associated with a set of accounts on the first DLN 200 (for example, since the inception of thefirst DLN 200.) Each of the computing nodes 202 a-202 c is operatively coupled to the other computing nodes in thefirst DLN 200. - In some implementations, the
auditor computing node 205 can include a processor (not shown) and a memory (not shown) operatively coupled to the processor. The processor can be or include any processing device or component configured to perform the data collecting, processing and transmitting functions. The processor can be configured to, for example, write data into and read data from the memory, and execute the instructions stored within the memory. Processor can also be configured to execute and/or control, for example, the operations of the memory. The memory can be, for example, a random-access memory (RAM) (e.g., a dynamic RAM, a static RAM), a flash memory, a removable memory, and/or so forth. In some embodiments, the memory can include, for example, a database, process, application, virtual machine, and/or some other software modules (stored and/or executing in hardware) or hardware modules. - In some implementations, an auditor computing node 205 (or a server) can generate, based on the first distributed
ledger data 204 associated with thefirst DLN 200, second distributedledger data 206 associated with asecond DLN 250. The second distributedledger data 206 is a forked copy of the first distributedledger data 204 and it can include self-executing codes or smart contracts that are configured to execute upon fulfillment of conditions that are agreed upon between transacting parties. The first distributedledger data 204 and the second distributedledger data 206 include the substantially the same data when the second distributedledger data 206 is generated. - In some implementations, the second distributed
ledger data 206 include recordings of transactions that occur on thefirst DLN 200 before thefirst DLN 200 is forked (i.e., pre-fork transactions) as well as recordings of transactions that occur on thesecond DLN 250 after thefirst DLN 200 is forked (i.e., post-fork transactions). In some implementations, the post-fork transactions are executed for the auditing purposes (e.g., a review of participants' access to, ownership of, association with, and/or etc. with an account on thefirst DLN 200.) In some implementations, thefirst DLN 200 does not include the second distributedledger data 206 or any copies of the second distributedledger data 206. In such implementations, the second distributedledger data 206 can only be stored at thesecond DLN 250, not thefirst DLN 200. The first distributedledger data 204 can be stored at thefirst DLN 200 and the forkedDLN 250. - Some or all of the computing nodes 202 a-202 c (and/or the memory associated with each computing node) may include copies of a self-executing code that self-execute upon fulfillment of the conditions. In some implementations, the computing nodes 202 a-202 c may communicate among each other and arrive at a consensus of the results of executing the codes. In some implementations, one or a few of the computing nodes 202 a-202 c may self-execute the codes and transmit the results to the rest of the computing nodes 202 a-202 c for confirmation. Each of the computing nodes 202 a-202 c and the
auditor computing node 205 is operatively coupled to the other computing nodes in thesecond DLN 250. - In some implementations, the
second DLN 250 includes the computing nodes 202 a-202 c and theauditor computing node 205 configured to generate the second distributed ledger data 206 (i.e., the forked copy of the first distributed ledger data 204). In some implementations, an account owner, who has ownership of, or access to, a private key of an account on thefirst DLN 200, may not have full rights to the tokens in its account. For example, as discussed above, there may be restrictions on actions that the account owner can take with respect to the account owner's account due to smart contract rules (or a protocol associated with the first DLN 200) that may apply to the actions and/or the account. For instance, the account owner may be blocked from transferring a certain number of tokens from account owner's account via a smart contract even if the tokens exist in the account and the account owner has authorized the transaction (e.g., the transfer of the tokens) with a valid private key. In such instances, an entity (e.g., a reviewer, an auditor, and/or the like) that is tasked with reviewing transactions and accounts involved with the first DLN may wish to review or analyze not only information related to the transactions and the related accounts (e.g., information related to the tokens in the accounts and/or transferred between accounts, the transaction participants, etc.), but also the behavior of the smart contract as it relates to the transactions and the related accounts (e.g., any rules that may apply to the transactions and related accounts). - In these instances, the auditor, operating the
auditor computing node 205, may determine or verify information (including, but not limited to, the balance, the availability, and the limitations) of tokens in an account. Theauditor computing node 205 can perform an action on a pre-determined number of tokens in the first account (or the second account) based on a second protocol associated with thesecond DLN 250 and without using a private cryptographic key of the first account. Theauditor computing node 205 can set the second protocol (including a second set of rules) in thesecond DLN 250 which are different from the first protocol (including a first set of rules) associated with thefirst DLN 200. In thesecond DLN 250, the transactions do not need to be signed by the account owner using its private keys (or its private cryptographic key(s)). As discussed herein, a smart contract includes a set of contractual terms of the agreement between buyers and sellers and these contractual terms of the agreement are directly written into lines of self-executing code. The self-executing code and the agreements contained therein exist across distributed ledger-based network (DLN). The self-executing code controls the execution of transactions, which are trackable and irreversible. These contractual terms of the agreement in smart contracts may also be referred to as a “protocol,” or “predefined rules.” - In such implementations, the
auditor computing node 205 can generate a request to perform an action on a number of tokens in the first account. For example, theauditor computing node 205 can generate a request for a transaction to transfer a pre-determined number of tokens from a first account from a set of accounts to a second account from the set of accounts, a request for holding a pre-determined number of tokens in the first account for a pre-determined period of time, and/or the like. Theauditor computing node 205 can perform the action on the pre-determined number of tokens without using a private cryptographic key of the first account (or the second account). Specifically, theauditor computing node 205 can, for example, initiate a transaction of a set of tokens from a first account to a second account by setting an origination address in the header of the transaction. Theauditor computing node 205 can set the origination address of the transaction to be different from the origination address of the first account holder, thus, alleviating the need of using the private cryptographic key of the first account. In other words, theauditor computing node 205 can approve the transaction from the first account without an approval (or signature) from the account holder of the first account. In some instances, theauditor computing node 205 can set the origination address of the transaction via a graphical user interface (not shown inFIG. 2 ). - In some instances, the
auditor computing node 205 can set the origination address of the transaction to two different addresses, and the computing nodes 202 a-202 c may recognize the transaction to be originated from two different users. For example, theauditor computing node 205 can generate a second request to initiate a second transaction between the first account and the second account. The second request includes a second header having a second origination address associated with the first account different from the first origination address. -
FIG. 3 shows a block diagram illustrating a block of distributed ledger data in the forked DLN, according to some embodiments. In some embodiments, ablock 301 of the second distributed ledger data (e.g., 206 inFIG. 2 ) includes ablock header 302 and a list oftransactions 303 that are recorded on theblock 301. The list oftransactions 303 include recordings of post-fork transactions. In some implementations, for a post-fork transaction (e.g., an auditing transaction), the “From” field 304 (or the origination address) in theheader 302 of each block is provided by the sender (i.e., theauditor computing node 205 inFIG. 2 ) of that transaction. In other words, theauditor computing node 205 inFIG. 2 can set its own “From” address 304 (e.g., a number, a text string, a symbol, an identifier, and/or the like) in a post-fork transaction. Theauditor computing node 205 inFIG. 2 can choose an origination address different from the origination address of the first account. In some implementations, theauditor computing node 205 inFIG. 2 can provide different identifiers in the “From” fields of transactions and the computing nodes 202 a-202 c in thesecond DLN 250 may recognize it as different users (e.g., 209 a inFIG. 2 ) and (e.g., 209 b inFIG. 2 ). In other words, theauditor computing node 205 inFIG. 2 may initiate a first transaction with a first identifier in the “From” field of a first block header and a second transaction with a second identifier in the “From” field of a second block header. Theauditor computing node 205 inFIG. 2 can approve thepost-fork transaction 308 without using a signature of the account owner or having the account owner to sign the post-fork transaction with its private keys. Thetransaction 308 can then be added to the second distributed ledger data (e.g., 206 inFIG. 2 ). - An example code of implementing the method of analyzing the distributed ledger data without using private keys is shown below.
-
{ setFromAddress(address) { Validate that the transaction address is a valid wallet address. Set the from address of the transaction. Keep the from address in the transaction storage. returns if the address is a valid address. } sendTransaction( ) { Create a new raw transaction by using the object storage. Add the FROM address to the transaction. Execute the VM on the transaction and use the transaction FROM address as msg.sender Every time the VM needs the sender, provide the sender from the storage. returns the transaction receipt. } } - Returning to
FIG. 2 , in some implementations, theauditor computing node 205 may use data of the post-fork transactions and data of the pre-fork transactions to determine the audit status of an account. For example, an auditor may be tasked to review or audit the accounts and transactions of thefirst DLN 200 participant (“auditee”). Smart contracts may include rules that apply to the accounts, tokens contained within accounts and/or transactions involving the accounts, and as a result may effectively limit the account rights of the account owners. For instance, if the account owner or auditee claims to have a given number of tokens in an account (and even be able to demonstrate that the account carries the claimed number of tokens), the auditor may still wish to determine if there are any restrictions placed on the account and/or the tokens due to smart contract rules (e.g., an active transfer disable mode that may be applicable to the account and/or the tokens because the tokens were stolen, etc.). In such implementations, theauditor computing node 205 may analyze the data of the post-fork transactions stored in the second distributedledger data 206 based on the smart contracts related to the pre-fork transactions stored in the second distributedledger data 206. The audit status of the account can include, but is not limited to, for example the authentication of the claimed account owner, the authentication of the account, the balance of the tokens in the account, the account owner's rights and limitations to each token in the account, what actions (e.g., transfer, or hold) the account owner can perform to each token in the account, presence or absence of a specific rule on a token in the account, and/or the like. - Once the
auditor computing node 205 determines or verifies the audit status (e.g., information including, but not limited to, the balance, the availability, and the limitations of tokens in the first account) of the first account, theauditor computing node 205 can send a signal (e.g., an audit report) to indicate or authenticate the transaction to transfer the requested tokens from the first account to the second account, or other actions that theauditor computing node 205 performed. In some instances, theauditor computing node 205 can send a signal to indicate the status of the audit process. In some implementations, theauditor computing node 205 can store the information associated with the transaction in the second distributedledger data 206 associated with thesecond DLN 250 and generate an updated copy of the second distributed ledger data including the second distributedledger data 206 and information associated with the transaction. In some instances, theauditor computing node 205 does not store the information associated with the transaction in the first distributedledger data 204 associated with thefirst DLN 200. In some instances, theauditor computing node 206 can remove the second distributedledger data 206 from its memory once the audit process is completed. - In some implementations, the
auditor computing node 205 may be operatively coupled to the multiple computing nodes 202 a-202 c via thefirst DLN 200. Similar to the multiple computing nodes 202 a-202 c, theauditor computing node 205 can be configured to communicate with the multiple computing nodes 202 a-202 c to arrive at a consensus on the executions of the smart contracts. Theauditor computing node 205 may store the first distributedledger data 204 in its memory. - In some embodiments, forking the
first DLN 200 for each account that is being audited would involve a large amount of resources (e.g., data storage, bandwidth, etc.). In some embodiments, the use of a smart contract state data storage module that stores (e.g., locally) modifications to smart contract data may allow the auditor to analyze the functionalities of the smart contracts of the DLN without forking thefirst DLN 200 for each account. Specifically, in some implementations, a block header in thefirst DLN 200 includes state data related to the transactions recorded on thefirst DLN 200. Examples of the information contained within the state data include status of accounts, and changes thereof, of accounts of theDLN 200, such as but not limited to, changes or state transitions of account balances as payments made from one account to another. For instance, the state data may include information related to the amount of tokens in the accounts of a token transferor (e.g., buyer of a product or service) and a token recipient (e.g., seller of the product or service) prior to, and/or subsequent to, the transfer of tokens as an agreed-upon payment. To avoid forking thefirst DLN 200 for each account with each state data change, a state data storage overlay that is linked or coupled to the a single forked DLN (e.g., 250) may be used to store state data changes that result when a smart contract is activated or triggered to execute a transaction (e.g., by an auditor testing the smart contract with a test transaction) such that the state data changes are not stored in the state data storage. As such, only the state data storage overlays (with less data (e.g., ˜KB) and thus less storage space is needed) are stored for each state data change with a single forked DLN. In such implementations, multiple forked DLNs (e.g., data size of each forked DLN may be in a scale of GB) can be avoided and thus, less resources are needed for auditing. An example of the state data storage of the distributed ledger data is discussed in co-pending U.S. Provisional Patent Application No. 62/834,057, filed on Apr. 15, 2019 and entitled “Systems, Apparatus and Methods for Local State Storage of Distributed Ledger Data Without Cloning,” the contents of which are incorporated herein by reference in its entirety. - In some embodiments, the systems, apparatus and methods disclosed herein allow an auditor to interact with a smart contract of a DLN without using account owners' private keys. This capability is in particular highly useful when there is a need to interact with the smart contract a significant number of times (e.g., when having to audit a large number of accounts or transactions on a DLN) since, among other reasons, accessing the private keys of account owners are not desirable for security and scalability reasons.
- In some embodiments, the systems, apparatus and methods disclosed herein enable an auditor to audit an account on a DLN (for example, determine the balance of the account of the auditee) without having to actually transfer the tokens from the auditee's account. The benefits include, but are not limited to, desire to avoid transaction fees and/or difficulties that arise when there are, in particular, a large number of accounts to audit such as but not limited to high memory requirements, computer and network performance degradations, and/or etc.
-
FIG. 4 is a flow chart illustrating a process of forking distributed ledger data securely without using private keys, according to some embodiments. Themethod 400 can be executed at, for example, a processor of an auditor computing node such as theauditor computing node 205 inFIG. 2 . - At 401, the method includes generating, based on the distributed ledger data associated with the first distributed ledger-based network (DLN), distributed ledger data associated with a second DLN. The first DLN includes multiple computing nodes configured to communicate among each other via a peer-to-peer (P2P) connection. The computing nodes in the first DLN may include a copy of the self-executing codes or smart contracts that are configured to be executed upon fulfillment of conditions that are agreed upon between transacting parties connected via the first DLN. The computing nodes in the first DLN may communicate among each other with the results of the executions of their respective self-executing codes, for example, to arrive at a consensus on the results. The first DLN may include a first protocol (or a first set of rules, a first smart contract) from a set of protocols that may include rules that apply to the accounts involved in the transactions. For example, the first protocol may include a rule requiring all sellers to sign each transaction with its private cryptographic key to authenticate and authorize the transaction.
- The distributed ledger data associated with the second DLN (also referred to as the second distributed ledger data) is a forked copy of the distributed ledger data associated with the first DLN (also referred to as the first distributed ledger data). The second distributed ledger data include recordings of transactions that occur on the first DLN before the first DLN is forked (i.e., pre-fork transactions) as well as recordings of transactions that occur on the second DLN after the first DLN is forked (i.e., post-fork transactions). In some implementations, the post-fork transactions are executed for the auditing purposes (e.g., a review of participants' access to, ownership of, association with, and/or etc. with an account on the first DLN.) In some implementations, the first DLN does not include the second distributed ledger data or any copies of the second distributed ledger data. In such implementations, the second distributed ledger data can only be stored at the second DLN, not the first DLN. The first distributed ledger data can be stored at the first DLN and the forked DLN.
- At 403, the method includes generating a request to initiate a transaction between a first account from the set of accounts and a second account from the set of accounts. An entity (e.g., a reviewer, an auditor, and/or the like) that is tasked with reviewing transactions and accounts involved with the first DLN may wish to review or analyze not only information related to the transactions and the related accounts (e.g., information related to the tokens in the accounts and/or transferred between accounts, the transaction participants, etc.), but also the behavior of the smart contract as it relates to the transactions and the related accounts (e.g., any rules that may apply to the transactions and related accounts). The auditor computing node can perform an action on a pre-determined number of tokens in the first account (or the second account) based on a second protocol associated with the second DLN and without using a private cryptographic key of the first account. For example, the auditor computing node can generate a request for a transaction to transfer a pre-determined number of tokens from a first account from a set of accounts to a second account from the set of accounts, a request for holding a pre-determined number of tokens in the first account for a pre-determined period of time, and/or the like.
- At 405, the method includes authenticating the transaction based on a protocol associated with the second DLN and without using a private cryptographic key of the first account. The auditor computing node can set the second protocol (including a second set of rules) in the second DLN, which are different from the first protocol (including a first set of rules) associated with the first DLN. In the second DLN, the transactions do not need to be signed by the account owner using its private keys (or its private cryptographic key(s)). The auditor computing node can perform the action on the pre-determined number of tokens without using a private cryptographic key of the first account (or the second account). Specifically, the auditor computing node can, for example, initiate a transaction of a set of tokens from a first account to a second account by setting an origination address (e.g., “From” field) in the header of the transaction. The auditor computing node can set the origination address of the transaction to be different from the origination address of the first account holder, thus, alleviating the need of using the private cryptographic key of the first account. In other words, the auditor computing node can approve the transaction from the first account without an approval (or signature) from the account holder of the first account. In some instances, the auditor computing node can set the origination address of the transaction via a graphical user interface
- At 407, the method includes sending a signal indicating the transaction was authenticated. Once the auditor computing node determines or verifies information (including, but not limited to, the balance, the availability, and the limitations) of tokens in the first account, the auditor computing node can send a signal (e.g., an audit report) to indicate or authenticate the transaction to transfer the requested tokens from the first account to the second account, or other actions that the auditor computing node performed. In some instances, the auditor computing node can send a signal to indicate the status of the audit process.
- At 409, the method includes storing information associated with the transaction in the distributed ledger data associated with the second DLN. In some implementations, the auditor computing node can store the information associated with the transaction in the second distributed ledger data associated with the second DLN and generate an updated copy of the second distributed ledger data including the second distributed ledger data and information associated with the transaction. In some instances, the auditor computing node does not store the information associated with the transaction in the distributed ledger data associated with the first DLN. In some instances, the auditor computing node can remove the distributed ledger data associated with the second DLN from its memory once the audit process is completed.
- Embodiments described herein can be implemented by any entities aiming to explore the behavior of smart contracts, including, but not limited to, reviewing or auditing participant's transactions and accounts, penetration testing (a simulated cyber attack on a computer system, performed to evaluate the security of the system), and/or other system security testing. Thus, although some embodiments are described herein in the context of auditing transactions and accounts, it should be understood that such embodiments can also be used in non-auditing contexts such as penetration testing, etc.
- While various embodiments have been described and illustrated herein, one will readily envision a variety of other means and/or structures for performing the function and/or obtaining the results and/or one or more of the advantages described herein, and each of such variations and/or modifications is deemed to be within the scope of the embodiments described herein. More generally, one will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary and that the actual parameters, dimensions, materials, and/or configurations will depend upon the specific application or applications for which the teachings is/are used. One will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific embodiments described herein. It is, therefore, to be understood that the foregoing embodiments are presented by way of example only and that, within the scope of the disclosure, including the appended claims and equivalents thereto, disclosed embodiments may be practiced otherwise than as specifically described and claimed. Embodiments of the present disclosure are directed to each individual feature, system, tool, element, component, and/or method described herein. In addition, any combination of two or more such features, systems, articles, elements, components, and/or methods, if such features, systems, articles, elements, components, and/or methods are not mutually inconsistent, is included within the scope of the present disclosure.
- The above-described embodiments can be implemented in any of numerous ways. For example, embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be stored (e.g., on non-transitory memory) and executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers.
- Further, it should be appreciated that a computer may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, netbook computer, or a tablet computer. Additionally, a computer may be embedded in a device not generally regarded as a computer but with suitable processing capabilities, including a smart phone, smart device, or any other suitable portable or fixed electronic device.
- Also, a computer can have one or more input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer can receive input information through speech recognition or in other audible format.
- Such computers can be interconnected by one or more networks in any suitable form, including a local area network or a wide area network, such as an enterprise network, and intelligent network (IN) or the Internet. Such networks can be based on any suitable technology and can operate according to any suitable protocol and can include wireless networks, wired networks or fiber optic networks.
- The various methods or processes outlined herein can be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software can be written using any of a number of suitable programming languages and/or programming or scripting tools, and also can be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.
- In this respect, various disclosed concepts can be embodied as a computer readable storage medium (or multiple computer readable storage media) (e.g., a computer memory, one or more floppy discs, compact discs, optical discs, magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other non-transitory medium or tangible computer storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the disclosure discussed above. The computer readable medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present disclosure as discussed above.
- The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of embodiments as discussed above. Additionally, it should be appreciated that according to one aspect, one or more computer programs that when executed perform methods of the present disclosure need not reside on a single computer or processor, but can be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the disclosure.
- Computer-executable instructions can be in many forms, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules can be combined or distributed as desired in various embodiments.
- Also, data structures can be stored in computer-readable media in any suitable form. For simplicity of illustration, data structures may be shown to have fields that are related through location in the data structure. Such relationships can likewise be achieved by assigning storage for the fields with locations in a computer-readable medium that convey relationship between the fields. However, any suitable mechanism can be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags or other mechanisms that establish relationship between data elements.
- Also, various concepts can be embodied as one or more methods, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments can be constructed in which acts are performed in an order different than illustrated, which can include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments. All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety.
- All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and/or ordinary meanings of the defined terms.
- The indefinite articles “a” and “an,” as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean “at least one.”
- The phrase “and/or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.
- As used herein, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of” or “exactly one of,” or, when used in claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of” “only one of” or “exactly one of” “Consisting essentially of,” when used in claims, shall have its ordinary meaning as used in the field of patent law.
- As used herein, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and/or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.
- All transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of” and “consisting essentially of” shall be closed or semi-closed transitional phrases, respectively, as set forth in the United States Patent Office Manual of Patent Examining Procedures, Section 2111.03.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/109,017 US11811946B2 (en) | 2019-04-15 | 2023-02-13 | Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201962834057P | 2019-04-15 | 2019-04-15 | |
US201962833913P | 2019-04-15 | 2019-04-15 | |
US16/849,005 US11582043B2 (en) | 2019-04-15 | 2020-04-15 | Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys |
US18/109,017 US11811946B2 (en) | 2019-04-15 | 2023-02-13 | Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/849,005 Continuation US11582043B2 (en) | 2019-04-15 | 2020-04-15 | Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys |
Publications (2)
Publication Number | Publication Date |
---|---|
US20230198774A1 true US20230198774A1 (en) | 2023-06-22 |
US11811946B2 US11811946B2 (en) | 2023-11-07 |
Family
ID=70456738
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/848,284 Active 2040-05-31 US11677563B2 (en) | 2019-04-15 | 2020-04-14 | Systems, apparatus and methods for local state storage of distributed ledger data without cloning |
US16/849,005 Active 2040-11-22 US11582043B2 (en) | 2019-04-15 | 2020-04-15 | Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys |
US18/109,017 Active US11811946B2 (en) | 2019-04-15 | 2023-02-13 | Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys |
US18/170,844 Active US11924352B2 (en) | 2019-04-15 | 2023-02-17 | Systems, apparatus and methods for local state storage of distributed ledger data without cloning |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/848,284 Active 2040-05-31 US11677563B2 (en) | 2019-04-15 | 2020-04-14 | Systems, apparatus and methods for local state storage of distributed ledger data without cloning |
US16/849,005 Active 2040-11-22 US11582043B2 (en) | 2019-04-15 | 2020-04-15 | Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US18/170,844 Active US11924352B2 (en) | 2019-04-15 | 2023-02-17 | Systems, apparatus and methods for local state storage of distributed ledger data without cloning |
Country Status (2)
Country | Link |
---|---|
US (4) | US11677563B2 (en) |
WO (2) | WO2020212436A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11924352B2 (en) | 2019-04-15 | 2024-03-05 | Eygs Llp | Systems, apparatus and methods for local state storage of distributed ledger data without cloning |
US11943358B2 (en) | 2019-04-15 | 2024-03-26 | Eygs Llp | Methods and systems for identifying anonymized participants of distributed ledger-based networks using zero-knowledge proofs |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11146399B2 (en) | 2018-10-19 | 2021-10-12 | Eygs Llp | Methods and systems for retrieving zero-knowledge proof-cloaked data on distributed ledger-based networks |
US11502838B2 (en) | 2019-04-15 | 2022-11-15 | Eygs Llp | Methods and systems for tracking and recovering assets stolen on distributed ledger-based networks |
CN110097467B (en) * | 2019-05-05 | 2021-04-13 | 华中科技大学 | Side chain test system and method for safety and stability of intelligent contract |
US11989726B2 (en) | 2021-09-13 | 2024-05-21 | Salesforce, Inc. | Database system public trust ledger token creation and exchange |
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 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200082411A1 (en) * | 2018-09-07 | 2020-03-12 | Chuck Lacona | Instantaneous Financial Transaction Processing Utilizing Distributed Ledger Technology |
Family Cites Families (85)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10521776B2 (en) | 2002-10-01 | 2019-12-31 | Andrew H B Zhou | UN currency (virtual payment cards) issued by central bank or other issuer for mobile and wearable devices |
US10147076B2 (en) | 2002-10-01 | 2018-12-04 | Andrew H B Zhou | Digital currency (virtual payment cards) issued by central bank for mobile and wearable devices |
US20140279384A1 (en) * | 2013-03-15 | 2014-09-18 | Sap Ag | Monitoring financial risks using a quantity ledger |
FR3018378A1 (en) | 2014-03-12 | 2015-09-11 | Enrico Maim | TRANSACTIONAL SYSTEM AND METHOD WITH DISTRIBUTED ARCHITECTURE BASED ON TRANSFER TRANSFERS OF ACCOUNT UNITS BETWEEN ADDRESSES |
US9608829B2 (en) | 2014-07-25 | 2017-03-28 | Blockchain Technologies Corporation | System and method for creating a multi-branched blockchain with configurable protocol rules |
US9853977B1 (en) | 2015-01-26 | 2017-12-26 | Winklevoss Ip, Llc | System, method, and program product for processing secure transactions within a cloud computing system |
US11023968B2 (en) | 2015-03-05 | 2021-06-01 | Goldman Sachs & Co. LLC | Systems and methods for updating a distributed ledger based on partial validations of transactions |
US9397985B1 (en) | 2015-04-14 | 2016-07-19 | Manifold Technology, Inc. | System and method for providing a cryptographic platform for exchanging information |
US9881176B2 (en) | 2015-06-02 | 2018-01-30 | ALTR Solutions, Inc. | Fragmenting data for the purposes of persistent storage across multiple immutable data structures |
WO2016200885A1 (en) | 2015-06-08 | 2016-12-15 | Blockstream Corporation | Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction |
US20180191503A1 (en) | 2015-07-14 | 2018-07-05 | Fmr Llc | Asynchronous Crypto Asset Transfer and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems |
US9906513B2 (en) | 2015-09-28 | 2018-02-27 | Bank Of America Corporation | Network authorization system |
US10841082B2 (en) | 2015-11-24 | 2020-11-17 | Adi BEN-ARI | System and method for blockchain smart contract data privacy |
US10805393B2 (en) | 2015-12-02 | 2020-10-13 | Olea Networks, Inc. | System and method for data management structure using auditable delta records in a distributed environment |
US11158000B2 (en) | 2015-12-02 | 2021-10-26 | Michael MAZIER | Method and cryptographically secure peer-to-peer trading platform |
US9948467B2 (en) | 2015-12-21 | 2018-04-17 | Mastercard International Incorporated | Method and system for blockchain variant using digital signatures |
SG11201806404SA (en) | 2016-02-04 | 2018-08-30 | Nasdaq Tech Ab | Systems and methods for storing and sharing transactional data using distributed computer systems |
US10475030B2 (en) | 2016-02-22 | 2019-11-12 | Bank Of America Corporation | System for implementing a distributed ledger across multiple network nodes |
US10026118B2 (en) | 2016-02-22 | 2018-07-17 | Bank Of America Corporation | System for allowing external validation of data in a process data network |
US11017388B2 (en) | 2016-03-25 | 2021-05-25 | International Business Machines Corporation | Cryptographically assured zero-knowledge cloud service for composable atomic transactions |
US10157078B2 (en) | 2016-04-10 | 2018-12-18 | Bank Of America Corporation | System for transforming large scale electronic processing using application block chain |
GB201607477D0 (en) | 2016-04-29 | 2016-06-15 | Eitc Holdings Ltd | A method and system for controlling the performance of a contract using a distributed hash table and a peer to peer distributed ledger |
US9774578B1 (en) | 2016-05-23 | 2017-09-26 | Accenture Global Solutions Limited | Distributed key secret for rewritable blockchain |
US20170346639A1 (en) | 2016-05-24 | 2017-11-30 | Business Information Exchange System Corp. | Public Key Infrastructure based on the Public Certificates Ledger |
GB201611948D0 (en) | 2016-07-08 | 2016-08-24 | Kalypton Int Ltd | Distributed transcation processing and authentication system |
WO2018028777A1 (en) | 2016-08-10 | 2018-02-15 | Rwe International Se | Peer-to-peer communication system and peer-to-peer processing apparatus |
US10735182B2 (en) | 2016-08-10 | 2020-08-04 | Peer Ledger Inc. | Apparatus, system, and methods for a blockchain identity translator |
US10878522B2 (en) * | 2016-08-18 | 2020-12-29 | First American Financial Corporation | Systems and methods for using blockchains to record, manage, and transfer ownership rights to land titles |
EP3296913B1 (en) | 2016-09-15 | 2020-10-21 | Accenture Global Solutions Limited | Method and system for secure communication of a token and aggregation of the same |
US10157295B2 (en) | 2016-10-07 | 2018-12-18 | Acronis International Gmbh | System and method for file authenticity certification using blockchain network |
US11176519B2 (en) * | 2016-11-11 | 2021-11-16 | International Business Machines Corporation | Smart contract admission check and fault tolerance in a blockchain |
US10380560B2 (en) | 2016-11-14 | 2019-08-13 | International Business Machines Corporation | Enforcing multi-use constraints on a blockchain |
CN106598824B (en) | 2016-11-25 | 2018-11-20 | 深圳前海微众银行股份有限公司 | The method for analyzing performance and device of block chain |
US11204808B2 (en) | 2016-12-12 | 2021-12-21 | Intel Corporation | Offload computing protocol |
US20180189753A1 (en) | 2017-01-05 | 2018-07-05 | Beskatta, LLC | Infrastructure for obligation management and validation |
US11797982B2 (en) * | 2017-01-06 | 2023-10-24 | FirstBlood Technologies, Inc. | Digital ledger authentication using address encoding |
US10389518B2 (en) * | 2017-01-27 | 2019-08-20 | Entit Software Llc | Blockchain hash value recomputation |
US20180218176A1 (en) | 2017-01-30 | 2018-08-02 | SALT Lending Holdings, Inc. | System and method of creating an asset based automated secure agreement |
WO2018144302A1 (en) | 2017-01-31 | 2018-08-09 | Rush Thomas Jay | Blockchain data-processing engine |
EP3593305A4 (en) | 2017-03-08 | 2020-10-21 | IP Oversight Corporation | System and method for creating commodity asset-secured tokens from reserves |
US20180285217A1 (en) | 2017-03-31 | 2018-10-04 | Intel Corporation | Failover response using a known good state from a distributed ledger |
US10812270B2 (en) * | 2017-04-07 | 2020-10-20 | Citizen Hex Inc. | Techniques for increasing the probability that a transaction will be included in a target block of a blockchain |
CN107274184A (en) | 2017-05-11 | 2017-10-20 | 上海点融信息科技有限责任公司 | block chain data processing based on zero-knowledge proof |
US9870508B1 (en) | 2017-06-01 | 2018-01-16 | Unveiled Labs, Inc. | Securely authenticating a recording file from initial collection through post-production and distribution |
US20190012660A1 (en) | 2017-07-06 | 2019-01-10 | Robert Masters | Systems and methods for providing an architecture for an internet-based marketplace |
US20190012662A1 (en) | 2017-07-07 | 2019-01-10 | Symbiont.Io, Inc. | Systems, methods, and devices for reducing and/or eliminating data leakage in electronic ledger technologies for trustless order matching |
US20190034923A1 (en) | 2017-07-31 | 2019-01-31 | Chronicled, Inc | Secure and confidential custodial transaction system, method and device using zero-knowledge protocol |
US11748830B2 (en) | 2017-08-11 | 2023-09-05 | Tellurium Inc. | Distributed ledger based system and method for the settlement and transfer of title to real estate |
US10297106B1 (en) | 2017-10-31 | 2019-05-21 | Jordan Simons | Distributed multi-ledger gambling architecture |
DE112018005260T5 (en) | 2017-11-06 | 2020-06-18 | Intel Corporation | Safe device onboarding techniques |
US20190138621A1 (en) | 2017-11-07 | 2019-05-09 | FHOOSH, Inc. | High-speed secure virtual file system |
US20190173854A1 (en) | 2017-11-22 | 2019-06-06 | Michael Beck | Decentralized information sharing network |
US20190158275A1 (en) | 2017-11-22 | 2019-05-23 | Michael Beck | Digital containers for smart contracts |
US10833861B2 (en) | 2017-11-28 | 2020-11-10 | International Business Machines Corporation | Protection of confidentiality, privacy and ownership assurance in a blockchain based decentralized identity management system |
WO2019109003A1 (en) | 2017-11-30 | 2019-06-06 | Visa International Service Association | Blockchain system for confidential and anonymous smart contracts |
US11115204B2 (en) | 2017-12-18 | 2021-09-07 | Adobe Inc. | Cooperative platform for generating, securing, and verifying device graphs and contributions to device graphs |
US11151549B2 (en) | 2018-01-29 | 2021-10-19 | KRNC Inc. | Cryptographic and fiat currency mechanics |
US20190236559A1 (en) * | 2018-01-31 | 2019-08-01 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing smart flow contracts using distributed ledger technologies in a cloud based computing environment |
US10701054B2 (en) | 2018-01-31 | 2020-06-30 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment |
EP3522064B1 (en) | 2018-02-02 | 2021-12-22 | Università Degli Studi Di Trento | A method and apparatus for distributed, privacy-preserving and integrity-preserving exchange, inventory and order book |
US11048228B2 (en) | 2018-03-16 | 2021-06-29 | General Electric Company | System and method to protect items associated with additive manufacturing |
WO2019180702A1 (en) * | 2018-03-18 | 2019-09-26 | Valid Network Ltd | Method and system for assessing future execution of a smart contract based on previous executions on a blockchain-based platform |
US20190299105A1 (en) | 2018-03-27 | 2019-10-03 | Truly Simplistic Innovations Inc | Method and system for converting digital assets in a gaming platform |
CN108510251A (en) * | 2018-03-30 | 2018-09-07 | 上海分赋信息科技有限公司 | A variety of trigger mechanisms are built based on external data to execute the method and system of intelligent contract in block chain network |
US20190303541A1 (en) * | 2018-04-02 | 2019-10-03 | Ca, Inc. | Auditing smart contracts configured to manage and document software audits |
US11194837B2 (en) * | 2018-05-01 | 2021-12-07 | International Business Machines Corporation | Blockchain implementing cross-chain transactions |
GB2576081A (en) | 2018-06-03 | 2020-02-05 | Vvow Company Ltd | Peer-to-peer cryptocurrency and crypto asset trading platform |
US20200013118A1 (en) | 2018-07-06 | 2020-01-09 | Accenture Global Solutions Limited | Distributed ledger system for anonymized transaction management |
US10721069B2 (en) | 2018-08-18 | 2020-07-21 | Eygs Llp | Methods and systems for enhancing privacy and efficiency on distributed ledger-based networks |
US11057366B2 (en) | 2018-08-21 | 2021-07-06 | HYPR Corp. | Federated identity management with decentralized computing platforms |
US20200074518A1 (en) | 2018-08-28 | 2020-03-05 | Blocklyncs Llc | Digital data management |
US10742424B2 (en) | 2018-08-29 | 2020-08-11 | International Business Machines Corporation | Trusted identity solution using blockchain |
US10298395B1 (en) | 2018-09-26 | 2019-05-21 | Accenture Global Solutions Limited | Interoperability of zero-knowledge proof enabled blockchains |
US11146399B2 (en) | 2018-10-19 | 2021-10-12 | Eygs Llp | Methods and systems for retrieving zero-knowledge proof-cloaked data on distributed ledger-based networks |
CN109359948A (en) | 2018-10-26 | 2019-02-19 | 深圳市元征科技股份有限公司 | A kind of measure of managing contract and relevant device based on block chain |
US10984410B2 (en) | 2018-11-15 | 2021-04-20 | Adobe Inc. | Entity-sovereign data wallets using distributed ledger technology |
US11048690B2 (en) | 2018-11-21 | 2021-06-29 | Adobe Inc. | Contribution of multiparty data aggregation using distributed ledger technology |
US11151558B2 (en) | 2018-12-12 | 2021-10-19 | American Express Travel Related Services Company, Inc | Zero-knowledge proof payments using blockchain |
US11282076B2 (en) | 2018-12-14 | 2022-03-22 | American Express Travel Related Services Company, Inc. | Transaction account data maintenance using blockchain |
US11194961B2 (en) * | 2018-12-31 | 2021-12-07 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for adding a document history graph and corresponding hash value to a blockchain in a cloud based computing environment |
US11102003B2 (en) | 2019-02-25 | 2021-08-24 | Microsoft Technology Licensing, Llc | Ledger-independent token service |
US11422981B2 (en) * | 2019-04-09 | 2022-08-23 | International Business Machines Corporation | Information management and access control in a database |
US11502838B2 (en) | 2019-04-15 | 2022-11-15 | Eygs Llp | Methods and systems for tracking and recovering assets stolen on distributed ledger-based networks |
US11943358B2 (en) | 2019-04-15 | 2024-03-26 | Eygs Llp | Methods and systems for identifying anonymized participants of distributed ledger-based networks using zero-knowledge proofs |
US11677563B2 (en) | 2019-04-15 | 2023-06-13 | Eygs Llp | Systems, apparatus and methods for local state storage of distributed ledger data without cloning |
-
2020
- 2020-04-14 US US16/848,284 patent/US11677563B2/en active Active
- 2020-04-15 WO PCT/EP2020/060610 patent/WO2020212436A1/en active Application Filing
- 2020-04-15 WO PCT/EP2020/060626 patent/WO2020212447A1/en active Application Filing
- 2020-04-15 US US16/849,005 patent/US11582043B2/en active Active
-
2023
- 2023-02-13 US US18/109,017 patent/US11811946B2/en active Active
- 2023-02-17 US US18/170,844 patent/US11924352B2/en active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200082411A1 (en) * | 2018-09-07 | 2020-03-12 | Chuck Lacona | Instantaneous Financial Transaction Processing Utilizing Distributed Ledger Technology |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11924352B2 (en) | 2019-04-15 | 2024-03-05 | Eygs Llp | Systems, apparatus and methods for local state storage of distributed ledger data without cloning |
US11943358B2 (en) | 2019-04-15 | 2024-03-26 | Eygs Llp | Methods and systems for identifying anonymized participants of distributed ledger-based networks using zero-knowledge proofs |
Also Published As
Publication number | Publication date |
---|---|
US11811946B2 (en) | 2023-11-07 |
WO2020212436A1 (en) | 2020-10-22 |
US11582043B2 (en) | 2023-02-14 |
US20200327112A1 (en) | 2020-10-15 |
US11677563B2 (en) | 2023-06-13 |
US20230216689A1 (en) | 2023-07-06 |
US20200328899A1 (en) | 2020-10-15 |
US11924352B2 (en) | 2024-03-05 |
WO2020212447A1 (en) | 2020-10-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11811946B2 (en) | Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys | |
US11146399B2 (en) | Methods and systems for retrieving zero-knowledge proof-cloaked data on distributed ledger-based networks | |
US20230325941A1 (en) | Systems and methods of access control and system integration | |
US20200059362A1 (en) | Methods and systems for enhancing privacy on distributed ledger-based networks | |
US11232439B2 (en) | Methods and systems for preventing transaction tracing on distributed ledger-based networks | |
US20200242595A1 (en) | Systems, methods, and apparatuses utilizing a blended blockchain ledger in a cloud service to address local storage | |
US11683175B2 (en) | Methods and systems for tracking and recovering assets stolen on distributed ledger-based networks | |
US11316691B2 (en) | Methods and systems for enhancing network privacy of multiple party documents on distributed ledger-based networks | |
US20230244656A1 (en) | Blockchain-based systems and methods for communicating, storing and processing data over a blockchain network | |
US11943358B2 (en) | Methods and systems for identifying anonymized participants of distributed ledger-based networks using zero-knowledge proofs | |
CN112368699A (en) | Address management system | |
US11038685B1 (en) | Correcting blockchain transactions with cryptocurrency type mistakes | |
WO2023244993A1 (en) | Systems and methods for mitigating network congestion on blockchain networks by supporting blockchain operations through off-chain interactions | |
KR20220076486A (en) | Call-back mechanisms for blockchain transactions | |
US20240177143A1 (en) | Intermediary roles in public trust ledger actions via a database system | |
US20230368191A1 (en) | Database representation of a public trust ledger | |
US20230394481A1 (en) | Authorizing public trust ledger actions via a database system | |
WO2023183494A1 (en) | Integrated platform for digital asset registration, tracking and validation |
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: LARGE ENTITY |
|
AS | Assignment |
Owner name: EYGS LLP, UNITED KINGDOM Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GLICKSHTEIN, AMINADAV;REEL/FRAME:063040/0357 Effective date: 20221003 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |