WO2021033026A1 - Techniques for enhanced data privacy in smart contracts for royalty distribution via a distributed ledger network - Google Patents

Abstract

A method for maintaining data privacy among parties to a royalty-distribution smart contract implemented using a distributed ledger may include configuring the smart contract for distribution of royalties from a payor account to accounts of participants; notifying the participants of a pending royalty payment; receiving from each of the participants a commitment to a claimed portion of the pending royalty payment and parameters of a zero-knowledge proof that the participant is entitled to receive the claimed portion; verifying correctness of the portions of the royalty payment claimed by the participants based on verification data including the commitments to the claimed portions of the royalty payment and the parameters of the zero-knowledge proofs; causing the royalty distribution transaction to be completed; and generating a record of the royalty distribution transaction in the distributed ledger.

Description

TECHNIQUES FOR ENHANCED DATA PRIVACY IN SMART CONTRACTS FOR ROYALTY DISTRIBUTION VIA A DISTRIBUTED LEDGER NETWORK

CROSS REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application No. 62/888,969, titled “Techniques for Enhanced Data Privacy in Smart Contracts for Royalty Distribution via a Distributed Ledger Network” and filed on August 19, 2019, which is hereby incorporated by reference herein to the maximum extent permitted by applicable law.

FIELD OF INVENTION

The present disclosure relates generally to smart contracts and distributed ledger (e.g., “blockchain”) networks. Some embodiments described herein relate specifically to techniques for enhanced data privacy in smart contracts for royalty distribution via a distributed ledger network.

BACKGROUND

Distributed ledger networks (e.g., blockchain networks or “blockchains”) facilitate secure and immutable storage of data. Blockchains can be used by participating entities as auditable ledgers for financial transactions. However, for many financial transactions, maintaining the privacy of certain transaction information is also important. There can be tension between the goals of making transactions auditable via a distributed ledger while also maintaining data privacy among parties to the transactions.

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. However, techniques for linking Bitcoin transactions to the identities of Bitcoin users have emerged.

Zcash attempts to resolve the above-described tension using zero-knowledge proofs (ZKPs). 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. In a Pedersen commitment scheme, a party can commit to a value ‘x’ while concealing that value from others by encrypting that value as a Pedersen commitment (“Com”) constructed as follows: X = Com(x, r) = x*G + r*H, where G and H are public values and ‘r’ is a “blinding factor.” Given a Pedersen commitment “Com(x)”, the value ‘x’ can be discovered by parties that already know the blinding factor r.

The Pedersen commitment scheme is homomorphic, in the sense that Com(xl, rl) + Com(x2, r2) = xl*G + rl*H + x2*G + r2*H = (xl + x2)*G + (rl + r2)*H = Com(xl+x2, rl + r2). That is, the sum of the commitments to xl and x2 is equal to a commitment to (xl + x2), as long as the sum of the blinding factors for the first two commitments is equal to the blinding factor for the third commitment.

Distributed ledgers are sometimes uses to implement smart contracts. In general, the term “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. For example, smart contracts may be used to facilitate financial transactions. When a smart contract is implemented using a distributed ledger, aspects of the contract (e.g., aspects of communications and/or transactions performed pursuant to the contract) may be visible to the users of the distributed ledger. 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.

In industries that monetize intellectual property (IP), parties that create and/or commercialize IP (e.g., patented inventions, trademarks, copyrighted works, etc.) 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.) is particularly common. In some cases (e.g., the streaming or broadcast of music), 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. SUMMARY OF THE INVENTION

In some cases, 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. In such cases, 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. Thus, there is an urgent need for 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).

In general, 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.

Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the 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.

The foregoing and other embodiments can each optionally include one or more of the following features, alone or in combination. In some embodiments, 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. In some embodiments, 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. In some embodiments, each participant’s commitment to the respective participant’s share of the royalties is blinded by a blinding factor private to the respective participant. In some embodiments, verifying that the claimed shares collectively constitute the full share includes interactively verifying that the claimed shares collectively constitute the full share.

In some embodiments, 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.

In some embodiments, 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. In some embodiments, 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. In some embodiments, 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.

In some embodiments, 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.

In some embodiments, 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. In some embodiments, for each participant, 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.

In some embodiments, 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. In some embodiments, 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.

In general, 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.

Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the 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.

Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. 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. Furthermore, 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.

The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

The foregoing Background and Summary, including the description of some embodiments, motivations therefor, and/or advantages thereof, are intended to assist the reader in understanding the present disclosure, and do not in any way limit the scope of any of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS Certain advantages of some embodiments may be understood by referring to the following description taken in conjunction with the accompanying drawings. In the drawings, like reference characters generally refer to the same parts throughout the different views. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating principles of some embodiments of the invention.

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; and

FIG. 3 is a diagram of an example of a computer system.

DETAILED DESCRIPTION

A Royalty Distribution System

Referring to FIG. 1, 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.

In some embodiments, 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).

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). For example, 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.

In some embodiments, 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. In some cases, 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.

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. In some distributed ledger systems, 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. 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.

Still referring to FIG. 1, smart contracts generally may be computer processes that facilitate, verify and/or enforce negotiation and/or performance of a contract between parties.

One purpose of 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.

Royalty Distribution Method

In some embodiments, 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. Referring to FIG. 2, 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. Prior to initiating the royalty distribution method 200, the parties may take certain preparatory steps consistent with the royalty distribution smart contract protocol. In some embodiments, 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). For example, 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). In some embodiments, the parties may agree on a commitment scheme (e.g., the Pedersen commitment scheme) and one or more parameters thereof. For example, 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.

In some embodiments, 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. In some embodiments, 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. In some embodiments, the payor module may generate the blinding factor r_x using a random number generator. In some embodiments, each of the participant modules may generate its blinding factor n using a random number generator.

Still referring to FIG. 2, at step 210 the smart contract modules (114, 124, 134) 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.

In some embodiments, each participant module 134 calculates a share commitment Pi = Com(pi, n) = pi*G + h*H for the participant’s share pi in the royalties, a range proof Qi enabling public verification that the share pi corresponding to the participant’s share commitment Pi is positive, and a parameter Bi = bi*H, where bi is a random number. 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. During step 210, 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.

After receiving the contract formation messages from the participant modules 134, the management module 114 may confirm that the participants’ shares pi collectively constitute a 100% share in the royalties. In some embodiments, the management module 114 uses an interactive verification protocol to obtain this confirmation. For example, the management module 114 may verify the range proofs Qi received from the participant modules, generate a challenge value ‘e’ (e.g., a random number), and send the challenge value to each participant module 134. After receiving the challenge, each participant module 134 may respond by generating a challenge response Si = bi + e*n and transmitting the challenge response Si to the management module. After receiving the challenge responses, the management module 114 may evaluate the following expression: e * [ sum(Pi) - G ] = H * sum(si) - sum(Bi). If the management module 114 determines that the expression is true, the interactive verification is complete and the management module 114 forms the smart contract.

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.

Still referring to FIG. 2, at step 220 the participants are notified of a pending royalty payment. In some embodiments, the payor module 124 calculates a commitment X to the royalty amount x to be distributed. The commitment X may be a Pedersen commitment, with r_x used as the blinding factor (e.g., X = Com(x, r_x) = x*G + r_x*H). 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.

During step 220, 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.

At step 230, 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). In some embodiments, each participant module 134 decrypts the values of the royalty payment (x) and the payor’s blinding factor (r_x) (e.g., using the participant’s private encryption key and the encryptions encn(x) and encri(r_x) received at step 220), determines the corresponding participant’s reward (e.g., by calculation fi = pi * x), and determines the participant’s commitment Fi to its reward fi (e.g., by calculating Fi = Com(fi, n) = fi*G + n*H) Each participant’s reward fi may be maintained privately and securely by the corresponding participant module 134.

In addition, 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. In some embodiments, each participant module 134 may generate its zero- knowledge proof ZKPi using a non-interactive protocol. For example, in accordance with the Fiat-Shamir heuristic, each participant module 134 may obtain a surrogate ‘efi for the verifier’s challenge. The surrogate ei may be calculated as follows: ei = hash(Sfi, S2i), where

“hash” is a suitable hash function (e.g., a cryptographic hash),

Sli = Com(ai, Ci) = ai*G + Ci*H, and S2i = Com_x(ai, Ci) = ai*X + Ci*H.

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:

¾ = ¾ + ei*pi, tli = Ci + ei*n, and t2i = Ci + ei*(ri - pi*r_x).

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₁, Zi, tli, and t2i).

An example of a non-interactive protocol for generating a zero-knowledge proof has been described. In some embodiments, an interactive protocol for generating zero-knowledge proofs may be used. During step 230, 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).

At step 240, the claims submitted by the participant modules 134 are verified. One of ordinary skill in the art will observe that after the management module 114 receives the participant’s claim messages, the management module has access to the following values:

X (the payor’ s commitment to the total royalty amount x, blinded with the blinding factor r_x provided by the payor to the participants),

Pi (each participant’s commitment to its share pi, blinded with a private blinding factor n),

Fi (each participant’s commitment to its reward fi, blinded with a private blinding factor n),

Sli and S2i (each participant’s commitments to random numbers in different bases), ei (each participant’s surrogate for the verifier’s challenge), and zi, th, and t2i (each participant’s responses to the verifier’s challenge).

To verify the submitted claims, the management module 134 may evaluate the following equalities for each participant Ui:

(Eq. 1) Com(zi, th) = Sh + ei*Pi, and

(Eq. 2) Com_x(zi, t2i) = S2i + ei*Fi (where Com_x(zi, t2i) is defined as Zi*X + t2i*H).

If the foregoing equalities are true for each of the participants, then 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.

At step 250, 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.

In some embodiments, the royalty payment is debited from the payor’s account and the rewards are credited to the participants’ accounts using an anonymized cryptocurrency. As discussed above, 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. In the anonymized cryptocurrency system, 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’. Likewise, 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).

Rather than individually transferring each participant’s reward from the payor’s account to the participant’s account, the payor module 124 (or the management module 114) 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).

In some embodiments, the royalty payment is debited from the payor’s account and the rewards are credited to the participants’ accounts using a traditional banking system. In this case, 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. In this case, all the parties implicitly trust the bank with all the information about the flow of money pursuant to the royalty agreement. Nevertheless, 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.

Some embodiments have been described in which a smart contract is used to distribute royalty payments for the use of copyrighted works (e.g., music). More generally, in accordance with some embodiments, 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. Furthermore, 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.

Computer-Based Implementations

In some examples, 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. In some implementations, the processor 310 is a single-threaded processor. In some implementations, 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. In some implementations, the memory 320 is a non-transitory computer-readable medium. In some implementations, the memory 320 is a volatile memory unit. In some implementations, the memory 320 is a non volatile memory unit.

The storage device 330 is capable of providing mass storage for the system 300. In some implementations, the storage device 330 is a non-transitory computer-readable medium. In various different implementations, 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. For example, 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. In some implementations, 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. In some implementations, 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. In some examples, mobile computing devices, mobile communication devices, and other devices may be used.

In some implementations, 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.

Although an example processing system has been described in Fig. 3, embodiments of the subject matter, functional operations and processes described in this specification can be implemented in other types of digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible nonvolatile program carrier for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, 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.

The term “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. Generally, 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. Generally, 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. However, a computer need not have such devices. Moreover, 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.

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. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on 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. 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. In addition, 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 web browser on a user’s user device in response to requests received from the web browser.

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.

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.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous. Other steps or stages may be provided, or steps or stages may be eliminated, from the described processes. Accordingly, other implementations are within the scope of the following claims.

Terminology

The phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.

The term “approximately”, the phrase “approximately equal to”, and other similar phrases, as used in the specification and the claims (e.g., “X has a value of approximately Y” or “X is approximately equal to Y”), 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.

The indefinite articles “a” and “an,” as used 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 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 in the specification and in the claims, “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 the 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 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 the claims, shall have its ordinary meaning as used in the field of patent law.

As used in the specification and in the claims, 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.

The use of “including,” “comprising,” “having,” “containing,” “involving,” and variations thereof, is meant to encompass the items listed thereafter and additional items.

Use of 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.

Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.

Claims

CLAIMS What is claimed is:

1. A method for maintaining data privacy among a plurality of parties to a royalty- distribution smart contract implemented using a distributed ledger, the method comprising: 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.

2. The method of claim 1, wherein configuring the smart contract for distribution of royalties from the account of the payor to the accounts of the participants comprises forming the smart contract.

3. The method of claim 1, wherein configuring the smart contract for distribution of royalties from the account of the payor to the accounts of the participants comprises: 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.

4. The method of claim 3, wherein each participant’s commitment to the respective participant’s share of the royalties is blinded by a blinding factor private to the respective participant.

5. The method of claim 3, wherein verifying that the claimed shares collectively constitute the full share comprises interactively verifying that the claimed shares collectively constitute the full share.

6. The method of claim 1, wherein notifying the participants of the pending royalty payment comprises: 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.

7. The method of claim 1, wherein 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.

8. The method of claim 1, wherein 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.

9. The method of claim 1, further comprising: 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.

10. The method of claim 9, wherein: 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.

11. The method of claim 9, wherein causing the royalty distribution transaction to be completed comprises: 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.

12. The method of claim 11, wherein causing the amount of the pending royalty payment to be debited from the account of the payor comprises subtracting a commitment to the amount of the pending royalty payment from the commitment to the balance of the account of the payor.

13. The method of claim 12, wherein: for each participant, causing the portion of the pending royalty payment claimed by the respective participant to be credited to the account of the respective participant comprises 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.

14. The method of claim 1, wherein generating the record of the royalty distribution transaction in the distributed ledger comprises generating a transaction record comprising: 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.

15. The method of claim 14, wherein generating the record of the royalty distribution transaction in the distributed ledger further comprises causing the transaction record to be added to the distributed ledger.

16. A royalty distribution system comprising: one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations for maintaining data privacy among a plurality of parties to a royalty- distribution smart contract implemented using a distributed ledger, the operations 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.

17. A method for maintaining data privacy among a plurality of parties to a royalty- distribution smart contract implemented using a distributed ledger, the method comprising: 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.

18. A royalty distribution system comprising: one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations for maintaining data privacy among a plurality of parties to a royalty- distribution smart contract implemented using a distributed ledger, the operations 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.