WO2021033026A1 - Techniques pour une confidentialité de données améliorée dans des contrats intelligents pour une distribution de redevance par l'intermédiaire d'un réseau de grand livre distribué - Google Patents

Techniques pour une confidentialité de données améliorée dans des contrats intelligents pour une distribution de redevance par l'intermédiaire d'un réseau de grand livre distribué Download PDF

Info

Publication number
WO2021033026A1
WO2021033026A1 PCT/IB2020/000679 IB2020000679W WO2021033026A1 WO 2021033026 A1 WO2021033026 A1 WO 2021033026A1 IB 2020000679 W IB2020000679 W IB 2020000679W WO 2021033026 A1 WO2021033026 A1 WO 2021033026A1
Authority
WO
WIPO (PCT)
Prior art keywords
royalty
participant
pending
participants
commitment
Prior art date
Application number
PCT/IB2020/000679
Other languages
English (en)
Inventor
Ivanov MYKOLA
Viktor ERMOLAEV
Shevchenko OLEKSANDR
Original Assignee
Bitfury Surround Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bitfury Surround Gmbh filed Critical Bitfury Surround Gmbh
Publication of WO2021033026A1 publication Critical patent/WO2021033026A1/fr

Links

Classifications

    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • 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
    • 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

Definitions

  • the present disclosure relates generally to smart contracts and distributed ledger (e.g., “blockchain”) networks.
  • distributed ledger e.g., “blockchain”
  • Some embodiments described herein relate specifically to techniques for enhanced data privacy in smart contracts for royalty distribution via a distributed ledger network.
  • Distributed ledger networks facilitate secure and immutable storage of data.
  • Blockchains can be used by participating entities as auditable ledgers for financial transactions.
  • maintaining the privacy of certain transaction information is also important.
  • Blockchains can be used as ledgers for transactions in cryptocurrencies such as Bitcoin and Zcash.
  • Bitcoin attempts to resolve the above-described tension between auditability and privacy by assigning pseudonyms to users, thereby discouraging others from tracing Bitcoin accounts and transactions to the true identities of the users associated therewith.
  • pseudonyms to users, thereby discouraging others from tracing Bitcoin accounts and transactions to the true identities of the users associated therewith.
  • techniques for linking Bitcoin transactions to the identities of Bitcoin users have emerged.
  • Zero-knowledge proofs are a cryptographic technique whereby the veracity of a statement about some information can be verified without revealing the information itself. In this way, zero-knowledge proofs facilitate both transaction verification and data privacy.
  • Zcash transactions are encrypted (therefore private) yet stored on a blockchain (therefore secure and immutable) and can be validated using zero-knowledge proofs (therefore auditable) without revealing the encrypted data (e.g., the addresses or values of the cryptocurrency notes used in the transaction).
  • Some techniques for constructing and verifying zero-knowledge proofs rely on commitment schemes. Commitment schemes can be used to commit to a value without revealing the value.
  • Com Pedersen commitment
  • Smart contract refers to any computer-based transaction protocol that facilitates (1) the formation of a contract by two or more parties, (2) the enforcement of the contract’s terms, (3) the performance of a party’s obligations according to the contract’s terms, and/or (4) the verification of a party’s performance according to the contract’s terms.
  • smart contracts may be used to facilitate financial transactions.
  • aspects of the contract e.g., aspects of communications and/or transactions performed pursuant to the contract
  • the transaction costs associated with formation and performance of smart contracts can be significantly lower than the transaction costs associated with traditional approaches to formation and performance of contracts.
  • IP intellectual property
  • parties that create and/or commercialize IP may receive royalties for the use of the IP.
  • Royalty-based compensation for use of copyrighted works e.g., books, movies, television shows, music, works of art, etc.
  • the royalties derived from use of a copyrighted work may be divided among a relatively large number of parties, for example, composers, songwriters, performing artists, publishers, marketing and distribution companies (e.g., “record labels”), etc.
  • the transaction costs associated with formation and performance of a royalty distribution agreement can be high relative to the value of the royalties distributed pursuant to the agreement.
  • the high transaction costs may discourage interested parties from entering into a royalty distribution agreement that would otherwise be beneficial. For at least this reason, there is need to improve the efficiency of royalty distribution techniques (e.g., to reduce the transaction costs associated with distribution of royalties).
  • Smart contracts implemented on a distributed ledger have the potential to significantly improve the efficiency of royalty distribution, but the auditable nature of a distributed ledger makes it difficult for the parties to a royalty distribution smart contract to maintain data privacy with respect to each other.
  • distributed-ledger based smart contracts whereby (1) each of the participants can claim a portion of a royalty payment, (2) auditable records by which the parties can verify that each participant has claimed an “honest” portion of the royalty payment are maintained in the distributed ledger, and (3) each participant’s “share” in the royalties remains secure and private (e.g., is not revealed to the other participants).
  • one innovative aspect of the subject matter described in this specification can be embodied in a method for maintaining data privacy among a plurality of parties to a royalty- distribution smart contract implemented using a distributed ledger, including: configuring the smart contract for distribution of royalties from an account of a payor to accounts of a plurality of participants; notifying the participants of a pending royalty payment; receiving, from each of the participants, (1) a commitment to a portion of the pending royalty payment claimed by the respective participant, and (2) a plurality of parameters of a zero-knowledge proof that the respective participant is entitled to receive the claimed portion of the pending royalty payment; verifying correctness of the portions of the royalty payment claimed by the respective participants based on verification data including (1) the commitments to the portions of the royalty payment claimed by the respective participants and (2) the parameters of the zero- knowledge proofs provided by the respective participants; causing the royalty distribution transaction to be completed; and generating a record of the royalty distribution transaction in the distributed ledger.
  • inventions of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.
  • a system of one or more computers can be configured to perform particular actions by virtue of having software, firmware, hardware, or a combination of them installed on the system (e.g., instructions stored in one or more storage devices) that in operation causes or cause the system to perform the actions.
  • One or more computer programs can be configured to perform particular actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.
  • configuring the smart contract for distribution of royalties from the account of the payor to the accounts of the participants includes forming the smart contract.
  • configuring the smart contract for distribution of royalties from the account of the payor to the accounts of the participants includes: receiving, from each of the participants, a contract formation message indicating (1) a commitment to a share of the royalties to which the respective participant is entitled and (2) one or more parameters of a range proof that the share claimed by the respective participant is positive; and verifying that the shares claimed by the participants collectively constitute a full share of the royalties.
  • each participant’s commitment to the respective participant’s share of the royalties is blinded by a blinding factor private to the respective participant.
  • verifying that the claimed shares collectively constitute the full share includes interactively verifying that the claimed shares collectively constitute the full share.
  • notifying the participants of the pending royalty payment includes: receiving, from the payor, a pending royalty payment message indicating (1) a commitment to an amount of the pending royalty payment, (2) for each of the participants, an encryption of the amount of the pending royalty payment generated using a public encryption key of the respective participant, and (3) for each of the participants, an encryption of a blinding factor used by the payor to blind the commitment to the amount of the pending royalty payment, wherein the encryption of the blinding factor is generated using the public encryption key of the respective participant; and sending, to each of the participants, a pending royalty payment message indicating at least (1) the commitment to the amount of the pending royalty payment, (2) the encryption of the amount of the pending royalty payment generated using the public encryption key of the respective participant, and (3) the encryption of the blinding factor generated using the public encryption key of the respective participant.
  • the commitment to the portion of the pending royalty payment claimed by the respective participant is a Pedersen commitment and is blinded by a blinding factor that is private to the respective participant.
  • the verification data further include: a commitment, provided by the payor, to an amount of a pending royalty payment; and for each participant, a commitment to a share of the royalties to which the respective participant is entitled.
  • the actions of the method may further include receiving a commitment to a balance of an account of the payor; and receiving, for each of the participants, a commitment to a balance of an account of the participant.
  • the commitment to the balance of the account of the payor is blinded by a blinding factor that is private to the payor, and for each of the participants, the commitment to the balance of the account of the participant is blinded by a blinding factor that is private to the respective participant.
  • causing the royalty distribution transaction to be completed includes: causing an amount of the pending royalty payment to be debited from the account of the payor; and for each of the participants, causing the portion of the pending royalty payment claimed by the respective participant to be credited to the account of the respective participant.
  • causing the amount of the pending royalty payment to be debited from the account of the payor includes subtracting a commitment to the amount of the pending royalty payment from the commitment to the balance of the account of the payor.
  • causing the portion of the pending royalty payment claimed by the respective participant to be credited to the account of the respective participant includes adding the commitment to the portion of the pending royalty payment claimed by the respective participant to the balance of the account of the respective participant.
  • generating the record of the royalty distribution transaction in the distributed ledger includes generating a transaction record including: a commitment to an amount of the pending royalty payment, for each of the participants, the commitment to the portion of the pending royalty payment claimed by the respective participant, and for each of the participants, the parameters of the zero-knowledge proof provided by the respective participant.
  • generating the record of the royalty distribution transaction in the distributed ledger further includes causing the transaction record to be added to the distributed ledger.
  • another innovative aspect of the subject matter described in this specification can be embodied in a method for maintaining data privacy among a plurality of parties to a royalty-distribution smart contract implemented using a distributed ledger, the method including: participating in a process of configuring the smart contract for distribution of royalties from an account of a payor to accounts of a plurality of participants; receiving notification of a pending royalty payment; sending, to a management module, a message indicating (1) a commitment of a participant to a portion of the pending royalty payment claimed by the participant, and (2) a plurality of parameters of a zero-knowledge proof that the participant is entitled to receive the claimed portion of the pending royalty payment; and after verification by the management module of correctness of the portion of the royalty payment claimed by the participant and correctness of one or more portions of the royalty payment claimed by one or more respective participants, receiving the portion of the pending royalty payment claimed by the participant in an account of the participant.
  • inventions of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.
  • a system of one or more computers can be configured to perform particular actions by virtue of having software, firmware, hardware, or a combination of them installed on the system (e.g., instructions stored in one or more storage devices) that in operation causes or cause the system to perform the actions.
  • One or more computer programs can be configured to perform particular actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.
  • a royalty payment owed by a royalty distributor to participants in a royalty distribution agreement may be distributed via a distributed ledger based smart contract, such that (1) each of the participants can claim a portion of the royalty payment, (2) auditable records by which the parties can verify that each participant has claimed an “honest” portion of the royalty payment are maintained in the distributed ledger, and (3) each participant’s “share” in the royalties remains secure and private, and is not revealed to the other participants.
  • the smart contract can verify that each participant has claimed an “honest” portion of a royalty payment before transferring those portions of the royalty payment to the accounts of any of the participants.
  • FIG. l is a diagram illustrating a royalty distribution system, in accordance with some embodiments.
  • FIG. 2 is a flowchart illustrating a royalty distribution method, in accordance with some embodiments.
  • FIG. 3 is a diagram of an example of a computer system.
  • a royalty distribution system 100 may include a smart contract distributed ledger subsystem 102, a royalty payor device 120, and a plurality of participant devices 130.
  • the smart contract distributed ledger subsystem 102 may include a plurality of smart contract distributed ledger devices 110 (e.g., “nodes”), each of which may maintain a distributed ledger 112 (or portion thereof) and implement a royalty distribution management module 114.
  • Each of the distributed ledger devices 110, the royalty payor device 120, and the participant devices 130 may include a computer system 300 as described below with reference to FIG. 3.
  • One or more communication networks 105 may interconnect the components of the royalty distribution system 100.
  • the royalty distribution system 100 implements a royalty distribution smart contract protocol whereby (1) a royalty payor and a plurality of royalty recipients (“participants”) form a royalty distribution smart contract, (2) the royalty payor can notify the participants that a royalty payment is available, (3) each of the participants can claim an honest portion of the royalty payment (i.e., a portion of the royalty payment to which the respective participant is entitled under the terms of the royalty distribution smart contract), (4) the participants’ claims are verified, (5) an accurate, auditable ledger of the communications sent and received by the royalty payor and the participants pursuant to the royalty distribution smart contract protocol is maintained, such that the parties can confirm that each participant has claimed an honest portion of each royalty payment, (6) the royalty payor can calculate the portion of the royalty payment to be transferred to each participant, and (7) each participant’s “share” in the royalties remains secure and private (e.g., is not revealed to the other participants).
  • a royalty payor and a plurality of royalty recipients (“participants”) form a royalty distribution smart contract
  • Activities performed pursuant to the royalty distribution smart contract protocol may be performed or controlled by smart contract modules (114, 124, 134) of the royalty distribution system’s devices (110, 120, 130).
  • each of the distributed ledger devices 110 may include a smart contract validation module 114 configured to manage the formation of royalty distribution smart contracts, validate royalty distribution transactions pursuant to the royalty distribution smart contracts, and record royalty distribution transactions in the distributed ledger 112.
  • Each payor device 120 may include a smart contract royalty payor module 124 configured to distribute royalties to participants royalty distribution agreements pursuant to the terms of the royalty distribution smart contracts.
  • Each participant device 130 may include a smart contract royalty participant module 134 configured to claim portions of pending royalty payments pursuant to the terms of the royalty distribution smart contracts.
  • the operations performed by the smart contract modules (114, 124, 134) are described in more detail below with reference to FIG. 2.
  • the distributed ledger 112 (e.g., “blockchain or “block chain”) is a distributed database that maintains a set of data records, the security of which may be enhanced by the distributed nature of the ledger.
  • each of the distributed ledger devices or multiple distributed ledger devices are operated by different entities.
  • a distributed ledger may operate without a central repository or single administrator.
  • the data records recorded in the distributed ledger 112 may be secured cryptographically and stored on the nodes of the distributed ledger.
  • a distributed ledger may provide numerous advantages over a traditional database. Multiple nodes (e.g., a large number of nodes) of the distributed ledger subsystem 102 may reach a consensus regarding the validity of a transaction contained on the transaction ledger. Similarly, when multiple versions of a document or transaction exist on the ledger, multiple nodes can converge on the most up-to-date version of the transaction.
  • Multiple nodes e.g., a large number of nodes of the distributed ledger subsystem 102 may reach a consensus regarding the validity of a transaction contained on the transaction ledger.
  • multiple nodes can converge on the most up-to-date version of the transaction.
  • the distributed ledger 114 may have two primary types of records: transaction records and confirmation records.
  • Transaction records contain the actual data stored in the ledger.
  • Confirmation records may confirm when and in what sequence certain transactions were recorded in the ledger.
  • Transactions may be created by users of the ledger in its normal course of business, for example, when a royalty payor notifies participants of a pending royalty payment, when a royalty distribution participant claims a portion of a pending royalty payment, when a royalty payment is transferred from a payor to participants, etc.
  • Confirmation records (e.g., “blocks”) may be created “miners,” which may use specialized software and/or equipment to create confirmation records. Users of the distributed ledger may create transactions that are passed around to various nodes of the distributed ledger subsystem.
  • a “valid” transaction may be one that can be validated based on a set of rules that are defined by the smart contract associated with the distributed ledger. For example, in the case of a royalty distribution smart contract, a valid transaction may be one in which the participants claim honest portions of a pending royalty payment.
  • miners are incentivized to create blocks by a rewards structure that offers a per-block reward and/or by fees offered within the validated transactions themselves. Thus, when a miner successfully validates a transaction on the distributed ledger (e.g., block chain), the miner may receive rewards and/or fees as an incentive to continue creating new blocks.
  • the distributed ledger subsystem 102 may be decentralized, meaning that a distributed ledger 112 (e.g., a decentralized ledger) is maintained on multiple nodes 110 of the distributed ledger subsystem 102.
  • a distributed ledger 112 e.g., a decentralized ledger
  • One node in the ledger subsystem may have a complete or partial copy of the entire ledger or set of transactions and/or blocks on the ledger.
  • Transactions may be initiated at a node 110 of the distributed ledger subsystem 102 and communicated to the various nodes of the subsystem 102. Any of the nodes may validate a transaction, add the transaction to its copy (or portion) of the ledger, and/or broadcast the transaction, its validation (in the form of a block) and/or other data to other nodes. This other data may include timestamps, such as is used in cryptocurrency block chains.
  • smart contracts generally may be computer processes that facilitate, verify and/or enforce negotiation and/or performance of a contract between parties.
  • Smart contracts may be to integrate the practice of contract law and related business practices with electronic commerce protocols between entities on the Internet. Smart contracts may leverage a user interface that provides one or more parties or administrators access, which may be restricted at varying levels for different people, to the terms and logic of the contract. Smart contracts may include logic that emulates contractual clauses that are partially or fully self-executing and/or self-enforcing. Examples of smart contracts may include digital rights management (DRM) used for protecting copyrighted works, financial cryptography schemes for financial contracts, admission control schemes, token bucket algorithms, other quality of service mechanisms for assistance in facilitating network service level agreements, person-to-person network mechanisms for ensuring fair contributions of users, and others.
  • DRM digital rights management
  • the management modules 114 of the nodes 110 of the distributed ledger subsystem 100 implement a royalty distribution method 200 in accordance with a secure and self-managing royalty distribution smart contract protocol.
  • the royalty distribution method 200 may include a step 210 of configuring the smart contract, a step 220 of notifying participants of a pending royalty payment, a step 230 of participants claiming honest portions of the royalty payment, a step 240 of verifying the participants’ claims, and a step 250 of recording the royalty distribution transaction on the distribute ledger 112.
  • the parties may take certain preparatory steps consistent with the royalty distribution smart contract protocol.
  • the royalty payor module 124 (acting on behalf of the payor) may establish a secure, encrypted communication channel with each of the royalty participant modules 134 (acting on behalf of the participants).
  • royalty payor module 124 may be configured to securely communicate with each of the royalty participant modules 134 via public- private encryption (e.g., the royalty payor module 124 may obtain each royalty participant module’s public encryption key).
  • the parties may agree on a commitment scheme (e.g., the Pedersen commitment scheme) and one or more parameters thereof.
  • the royalty payor module 124 and royalty participant modules 134 may agree on values for the ‘G’ and ⁇ ’ parameters of the Pedersen commitment scheme. In some embodiments, these parameter values are provided by the management module 114 and/or recorded in the distributed ledger 112.
  • the royalty payor module 124 records a commitment ‘M’ to the payor’s account balance ‘m’ in the distributed ledger.
  • the payor’s account balance commitment ‘M’ may be blinded by the payor’s blinding factor r x.
  • each of the royalty participant modules 124 records a commitment ‘Mi’ to the corresponding participant’s account balance ‘mf in the distributed ledger.
  • Each participant’s account balance commitment ‘Mi’ may be blinded by the participant’s private blinding factor n.
  • the payor module 114 and the participant modules 124 may obtain the respective blinding factors (r x , n) using any suitable technique.
  • the payor module may generate the blinding factor r x using a random number generator.
  • each of the participant modules may generate its blinding factor n using a random number generator.
  • the smart contract modules may configure (or “form”) a smart contract for distribution of royalties from the payor’s account to the participant’s accounts. Any suitable technique for forming the smart contract may be used.
  • Each participant module 134 may then transmit a contract formation message containing the corresponding participant’s share commitment Pi, range proof Qi, and parameter Bi to a management module 114.
  • Each participant’s share pi may be maintained privately and securely by the corresponding participant module 134.
  • each participant module’s blinding factor n may have the same value as used during the preliminary phase to blind the participant’s account balance, or a new value may be assigned to the blinding factor (e.g., a new random number may be generated). Assigning a new random number value to the blinding factor n each time the blinding factor is used to blind a value or generate a commitment is generally the more secure approach.
  • e e.g., a random number
  • An example of an interactive verification protocol for forming the smart contract has been described. Some aspects of the described verification protocol are similar to well-known processes used to verify a digital signature created with a private key. Other interactive verification protocols may be used. In some embodiments, a non-interactive protocol for forming the smart contract may be used.
  • the payor module 124 calculates a commitment X to the royalty amount x to be distributed.
  • the payor module may also generate, using each participant’s public encryption key, an encryption encn(x) of the royalty amount and an encryption encri(r x ) of the blinding factor r x .
  • the payor module may then transmit a pending royalty payment message to the management module 114.
  • the pending royalty payment message may include the commitment X to the royalty amount and the participant- specific encryptions of the royalty amount and the blinding factor.
  • the management module 114 may forward the pending royalty payment message to each participant module 134. Alternatively, the management module 114 may send a different message to each participant module, containing the commitment X and the encryptions generated specifically for the corresponding participant.
  • the payor module’s blinding factor r x may have the same value as used during the preliminary phase to blind the payor’s account balance, or a new value (a new random number) may be generated. Assigning a new random number value to the blinding factor r x each time the blinding factor is used to blind a value or generate a commitment is generally the more secure approach.
  • each participant module 134 generates and submits a claim for a reward fi (the portion of the royalty amount x to which the participant is entitled).
  • Each participant’s reward fi may be maintained privately and securely by the corresponding participant module 134.
  • each participant module 134 may generate a zero-knowledge proof ZKPi that Fi is a correct commitment for an honest reward fi to which the corresponding participant is actually entitled.
  • hash is a suitable hash function (e.g., a cryptographic hash),
  • the parameters ai and Ci may be random numbers, which each participant module 134 may generate using a random number generator. Having obtained the surrogate ei, each participant module 134 may calculate additional parameters of the participant’s zero-knowledge proof ZKPi as follows:
  • Each participant module 134 may then transmit a claim message to the management module 114.
  • a participant’s claim message may include the participant’s commitment Fi to the participant’s reward fi and the parameters of the participant’s zero-knowledge proof ZKPi (e.g., ei, Sii, S2 1 , Zi, tli, and t2i).
  • each participant module’s blinding factor n may have the same value as used during the preliminary phase and/or one or more of the previous method steps, or a new value may be assigned to the blinding factor (e.g., a new random number may be generated).
  • the claims submitted by the participant modules 134 are verified.
  • the management module 114 receives the participant’s claim messages, the management module has access to the following values:
  • the management module 134 may evaluate the following equalities for each participant Ui:
  • each participant’s commitment Fi is the correct commitment for the honest reward h to which the participant is entitled. If the foregoing equalities are false for a participant Ui, then that participant’s commitment Fi is not the correct commitment for the honest reward h to which the participant is entitled.
  • the management module 134 if the management module 134 has verified that each participant’s commitment Fi is the correct commitment for the honest reward fi to which the participant is entitled, the management module completes the royalty distribution transaction by (1) causing the royalty payment ‘x’ to debited from the payor’s account and causing each participant’s reward h to be credited to the participant’s account, and (2) constructing a transaction record and adding (e.g., appending) it to the distributed ledger.
  • the transaction record may include the values of X and, for each participant, the values of Pi, Fi, Sh, S2i, ei, zi, th, and t2i.
  • the royalty payment is debited from the payor’s account and the rewards are credited to the participants’ accounts using an anonymized cryptocurrency.
  • commitments to the parties’ account balances are stored in the distributed ledger, and the blinding factor r x or n that blinds a party’s account balance can be used by that party to derive the account balance from the account balance commitment.
  • an amount of currency ‘k’ may be debited from a party’s account by subtracting the commitment K to the amount of currency ‘k’ from the commitment M to the party’s account balance ‘m’.
  • an amount of currency ‘kf may be credited to a party’s account by adding the commitment K to the amount of currency ‘k to the commitment Mi to the party’s account balance ‘mi.’
  • the parties can also use the above-mentioned blinding factors to construct range proofs (e.g., to prove that the reward being transferred is positive, or to prove that the account from which the reward is being transferred has sufficient funds to provide the reward).
  • the payor module 124 may debit the entire royalty payment ‘x’ from the payor’s account (e.g., by subtracting the commitment ‘X’ from the commitment M to the payor’s account balance), and the participant modules 134 (or the management module 114) may credit each participant’s reward fi to the participant’s account (e.g., by adding the commitment Fi to the commitment Mi to the participant’s account balance). In this way, each participant can know and receive its own reward fi, without revealing the reward fi to any other parties (e.g., the payor, other participants, and third parties).
  • the royalty payment is debited from the payor’s account and the rewards are credited to the participants’ accounts using a traditional banking system.
  • the parties reveal their blinding factors (r x for the distributor, n for the participants) to the bank, which can then derive the royalty payment amount ‘x’ and the participants’ claimed rewards f from the commitments X and Fi, debit the royalty payment amount ‘x’ from the payor’s bank account, and credit each participant’s claimed reward fi to the participant’s bank account.
  • all the parties implicitly trust the bank with all the information about the flow of money pursuant to the royalty agreement.
  • the above-described technique is beneficial even in this context, because the parties first agree on a blinded version of the transfer (which is recorded in an auditable and immutable distributed ledger) and then the agreed transfer is conducted by bank. The parties can subsequently confirm whether the blinded transfers correspond to actual banking payments.
  • a payment owed by a payor to shareholders in a financial instrument may be distributed via a distributed-ledger based smart contract, such that (1) each of the shareholders claims a portion of the payment, (2) all parties to the agreement can verify that each shareholder has claimed the portion of the payment to which the shareholder is contractually entitled, and (3) each shareholder’s “share” in the financial instrument remains secure and private, and is not revealed to the other shareholders.
  • the smart contract can verify that each shareholder has claimed an “honest” portion of a payment before transferring those portions of the payment to the accounts of any of the shareholders.
  • some or all of the processing described above can be carried out on a personal computing device, on one or more centralized computing devices, or via cloud-based processing by one or more servers. In some examples, some types of processing occur on one device and other types of processing occur on another device. In some examples, some or all of the data described above can be stored on a personal computing device, in data storage hosted on one or more centralized computing devices, or via cloud-based storage. In some examples, some data are stored in one location and other data are stored in another location. In some examples, quantum computing can be used. In some examples, functional programming languages can be used. In some examples, electrical memory, such as flash-based memory, can be used.
  • FIG. 3 is a block diagram of an example computer system 300 that may be used in implementing the technology described in this document.
  • General-purpose computers, network appliances, mobile devices, or other electronic systems may also include at least portions of the system 300.
  • the system 300 includes a processor 310, a memory 320, a storage device 330, and an input/output device 340. Each of the components 310, 320, 330, and 340 may be interconnected, for example, using a system bus 350.
  • the processor 310 is capable of processing instructions for execution within the system 300.
  • the processor 310 is a single-threaded processor.
  • the processor 310 is a multi -threaded processor.
  • the processor 310 is capable of processing instructions stored in the memory 320 or on the storage device 330.
  • the memory 320 stores information within the system 300.
  • the memory 320 is a non-transitory computer-readable medium.
  • the memory 320 is a volatile memory unit.
  • the memory 320 is a non volatile memory unit.
  • the storage device 330 is capable of providing mass storage for the system 300.
  • the storage device 330 is a non-transitory computer-readable medium.
  • the storage device 330 may include, for example, a hard disk device, an optical disk device, a solid-date drive, a flash drive, or some other large capacity storage device.
  • the storage device may store long-term data (e.g., database data, file system data, etc.).
  • the input/output device 340 provides input/output operations for the system 300.
  • the input/output device 340 may include one or more of a network interface devices, e.g., an Ethernet card, a serial communication device, e.g., an RS- 232 port, and/or a wireless interface device, e.g., an 802.11 card, a 3G wireless modem, or a 4G wireless modem.
  • the input/output device may include driver devices configured to receive input data and send output data to other input/output devices, e.g., keyboard, printer and display devices 360.
  • mobile computing devices, mobile communication devices, and other devices may be used.
  • At least a portion of the approaches described above may be realized by instructions that upon execution cause one or more processing devices to carry out the processes and functions described above.
  • Such instructions may include, for example, interpreted instructions such as script instructions, or executable code, or other instructions stored in a non-transitory computer readable medium.
  • the storage device 330 may be implemented in a distributed way over a network, such as a server farm or a set of widely distributed servers, or may be implemented in a single computing device.
  • the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus.
  • the computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.
  • system may encompass all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers.
  • a processing system may include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
  • a processing system may include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
  • a computer program (which may also be referred to or described as a program, software, a software application, a module, a software module, a script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program may, but need not, correspond to a file in a file system.
  • a program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
  • a computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
  • the processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output.
  • the processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
  • Computers suitable for the execution of a computer program can include, by way of example, general or special purpose microprocessors or both, or any other kind of central processing unit.
  • a central processing unit will receive instructions and data from a read-only memory or a random access memory or both.
  • a computer generally includes a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • a computer need not have such devices.
  • a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few.
  • PDA personal digital assistant
  • GPS Global Positioning System
  • USB universal serial bus
  • Computer readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD- ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto optical disks e.g., CD- ROM and DVD-ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
  • a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
  • a display device e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
  • keyboard and a pointing device e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a
  • Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components.
  • the components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
  • LAN local area network
  • WAN wide area network
  • the computing system can include clients and servers.
  • a client and server are generally remote from each other and typically interact through a communication network.
  • the relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
  • X has a value of approximately Y” or “X is approximately equal to Y”
  • X should be understood to mean that one value (X) is within a predetermined range of another value (Y).
  • the predetermined range may be plus or minus 20%, 10%, 5%, 3%, 1%, 0.1%, or less than 0.1%, unless otherwise indicated.
  • 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.
  • ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed. Ordinal terms are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term), to distinguish the claim elements.

Abstract

L'invention concerne un procédé pour maintenir la confidentialité de données entre des parties à un contrat intelligent de distribution de redevance mis en œuvre à l'aide d'un registre distribué qui peut comprendre la configuration du contrat intelligent pour la distribution de droits d'auteur d'un compte payeur à des comptes de participants ; la notification aux participants d'un paiement de redevance en attente ; la réception, en provenance de chacun des participants, d'un engagement à une partie revendiquée du paiement de redevance en attente et de paramètres d'une preuve à connaissance nulle que le participant est habilité à recevoir la partie revendiquée ; la vérification de l'exactitude des parties du paiement de redevance revendiquées par les participants sur la base de données de vérification comprenant les engagements aux parties revendiquées du paiement de redevance et des paramètres des preuves de connaissance nulle ; l'achèvement de la transaction de distribution de redevance ; et la génération d'un enregistrement de la transaction de distribution de redevance dans le registre distribué.
PCT/IB2020/000679 2019-08-19 2020-08-19 Techniques pour une confidentialité de données améliorée dans des contrats intelligents pour une distribution de redevance par l'intermédiaire d'un réseau de grand livre distribué WO2021033026A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962888969P 2019-08-19 2019-08-19
US62/888,969 2019-08-19

Publications (1)

Publication Number Publication Date
WO2021033026A1 true WO2021033026A1 (fr) 2021-02-25

Family

ID=72561827

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2020/000679 WO2021033026A1 (fr) 2019-08-19 2020-08-19 Techniques pour une confidentialité de données améliorée dans des contrats intelligents pour une distribution de redevance par l'intermédiaire d'un réseau de grand livre distribué

Country Status (1)

Country Link
WO (1) WO2021033026A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019072313A2 (fr) * 2018-12-29 2019-04-18 Alibaba Group Holding Limited Système et procédé de protection d'informations
WO2019072261A2 (fr) * 2018-11-07 2019-04-18 Alibaba Group Holding Limited Régulation de transactions confidentielles de chaîne de blocs
WO2019072277A2 (fr) * 2018-11-27 2019-04-18 Alibaba Group Holding Limited Système et procédé pour la protection d'informations
US20190164153A1 (en) * 2017-11-30 2019-05-30 Shashank Agrawal Blockchain system for confidential and anonymous smart contracts

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190164153A1 (en) * 2017-11-30 2019-05-30 Shashank Agrawal Blockchain system for confidential and anonymous smart contracts
WO2019072261A2 (fr) * 2018-11-07 2019-04-18 Alibaba Group Holding Limited Régulation de transactions confidentielles de chaîne de blocs
WO2019072277A2 (fr) * 2018-11-27 2019-04-18 Alibaba Group Holding Limited Système et procédé pour la protection d'informations
WO2019072313A2 (fr) * 2018-12-29 2019-04-18 Alibaba Group Holding Limited Système et procédé de protection d'informations

Similar Documents

Publication Publication Date Title
KR102180991B1 (ko) 블록 체인 기밀 거래의 규제
CN108833081B (zh) 一种基于区块链的设备组网认证方法
RU2736447C1 (ru) Перекрестная торговля активами в сетях блокчейнов
CN108418689B (zh) 一种适合区块链隐私保护的零知识证明方法和介质
CN110337665B (zh) 用于信息保护的系统和方法
CN110089069B (zh) 用于信息保护的系统和方法
JP6942136B2 (ja) デジタルコンテンツの制御及び配信のためのブロックチェーンにより実施される方法
CN111316615B (zh) 使用调解器计算机系统确保计算机程序正确执行的系统和方法
Baum et al. P2DEX: privacy-preserving decentralized cryptocurrency exchange
Dagher et al. Provisions: Privacy-preserving proofs of solvency for bitcoin exchanges
US20200193432A1 (en) Method and system for settling a blockchain transaction
US20200127813A1 (en) Method and system for creating a user identity
JP2023134800A (ja) 分散協調を用いるスマートコントラクトの実行
WO2019109003A1 (fr) Système de chaîne de blocs pour contrats intelligents confidentiels et anonymes
CN108418783A (zh) 一种保护区块链智能合约隐私的方法、介质
Mahmoud et al. Research challenges and opportunities in blockchain and cryptocurrencies
KR20180115764A (ko) 블록체인에서 교환을 구현하기 위한 토큰화 방법 및 시스템
KR20200141502A (ko) 즉각적인 오프라인 블록체인 트랜잭션의 보안을 증가시키는 데 적합한 컴퓨터 구현된 시스템 및 방법
Ferrer-Gomila et al. A fair contract signing protocol with blockchain support
Khalil et al. Tex-a securely scalable trustless exchange
JP2020078081A (ja) ブロックチェーン機密トランザクションの管理
CN110728576A (zh) 一种基于零知识证明的去中心化匿名数据交易方法
Huang et al. zkChain: A privacy‐preserving model based on zk‐SNARKs and hash chain for efficient transfer of assets
Li et al. Secure electronic ticketing system based on consortium blockchain
Pestana et al. Themis: A decentralized privacy-preserving ad platform with reporting integrity

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20775395

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20775395

Country of ref document: EP

Kind code of ref document: A1