Distributed ledger based mass balancing via secret sharing

Abstract

A producer may supply amounts x.sub.i of a good to a plurality of consumers C.sub.i in a series of transactions and be subject to a mass balancing verification protocol after every K transactions. A producer platform may compute K random shares (r.sub.1 through r.sub.K) of a random value r, publish blinded amounts t.sub.i representing x.sub.i+r.sub.i to a secure, distributed transaction ledger, and transmit an encrypted r.sub.i to consumer C.sub.i using an asymmetric cryptosystem. A consumer platform may receive and decrypt r.sub.i (while the consumer Ci actually receives an amount {circumflex over (x)}.sub.i of the good from the producer), compute {circumflex over (x)}.sub.i+r.sub.i and generate a fraud alert signal if it differs from the published t.sub.i. The consumer platform may also transmit an encrypted rolling sum value to a next consumer C.sub.i+1. A verifier platform may, after K transactions, execute the mass balance verification protocol to determine a total amount of the good that the producer had collectively supplied to the consumers C.sub.i. The verifier platform may also generate a fraud alert signal when appropriate based on the total amount and a maximum allowed amount.

Claims

1. A system associated with a producer who supplies amounts x.sub.i of a good to a plurality of consumers C.sub.i in a series of transactions and is subject to a mass balancing verification protocol after every K transactions, comprising: a secure, distributed transaction ledger that stores information associated with amounts x.sub.i in a privacy-preserving form; a producer platform, including: a computer processor, and computer memory, coupled to the computer processor, storing instructions that, when executed by the computer processor cause the processor to: (i) compute K random shares (r.sub.1 through r.sub.K) of a random value r, (ii) publish blinded amounts t.sub.i representing x.sub.i+r.sub.i to the secure, distributed transaction ledger using additive secret sharing, and (iii) transmit an encrypted r.sub.i to consumer C.sub.i using an asymmetric cryptosystem; a consumer platform for each consumer C.sub.i, to: (i) receive the encrypted r.sub.i from the producer platform while the consumer C.sub.i actually receives an amount {circumflex over (x)}.sub.i of the good from the producer, (ii) execute a decryption algorithm to determine r.sub.i, (iii) automatically compute {circumflex over (x)}.sub.i+r.sub.i and transmit a fraud alert signal if it differs from the published t.sub.i, and (iv) transmit an encrypted rolling sum value to a next consumer C.sub.i+1; and a verifier platform to, after K transactions, execute the mass balance verification protocol and automatically determine a total amount of good that the producer had collectively supplied to the consumers C.sub.i, and further to transmit a fraud alert signal based on the total amount and a maximum allowed amount.

2. The system of claim 1, wherein the good supplied by the producer is associated with at least one of: (i) a product, (ii) a service, and (iii) a natural resource.

3. The system of claim 1, wherein the verifier platform is associated with at least one of: (i) a governmental authority, and (ii) a non-governmental organization.

4. The system of claim 1, wherein the secure, distributed transaction ledger is associated with blockchain technology.

5. The system of claim 1, wherein the asymmetric cryptosystem is associated with three polynomial time algorithms: (i) a probabilistic key-generation algorithm, (ii) an encryption algorithm, (iii) a probabilistic encryption algorithm, and (iv) a decryption algorithm.

6. The system of claim 5, wherein the asymmetric cryptosystem uses individual key pairs consisting of a public encryption key pk.sub.i and a secret decryption key sk.sub.i.

7. The system of claim 1, wherein the mass balancing verification protocol supports multiple producers.

8. The system of claim 1, wherein a balance is cached after every K-cycle to achieve a number of additions that is independent of a number of previous K-cycles.

9. The system of claim 1, wherein communications between producers and consumers are performed via at least one of: (i) a direct communication channel, and (ii) the secure, distributed transaction ledger.

10. The system of claim 1, wherein communications between consumers are performed via at least one of: (i) a direct communication channel, and (ii) the secure, distributed transaction ledger.

11. A computer-implemented method associated with a producer who supplies amounts x.sub.i of a good to a plurality of consumers C.sub.i in a series of transactions and is subject to a mass balancing verification protocol after every K transactions, comprising: computing, by a computer processor of a producer platform, K random shares (r.sub.1 through r.sub.K) of a random value r; publishing, by the producer platform, blinded amounts t.sub.i representing x.sub.i+r.sub.i to a secure, distributed transaction ledger using additive secret sharing to store information associated with amounts x.sub.i in a privacy-preserving form; transmitting, by the producer platform, an encrypted r.sub.i to consumer C.sub.i using an asymmetric cryptosystem; receiving, at a consumer platform of consumer C.sub.i, the encrypted r.sub.i from the producer platform while the consumer C.sub.i actually receives an amount {circumflex over (x)}.sub.i of the good from the producer; executing, by the consumer platform, a decryption algorithm to determine r.sub.i; automatically computing {circumflex over (x)}.sub.i+r.sub.i and transmitting, by the consumer platform, a fraud alert signal if differs from the published t.sub.i; transmitting an encrypted rolling sum value to a next consumer C.sub.i+1; executing, by a verifier platform after K transactions, the mass balance verification protocol and automatically determine a total amount of good that the producer had collectively supplied to the consumers C.sub.i; and transmitting, by the verifier platform, a fraud alert signal based on the total amount and a maximum allowed amount.

12. The method of claim 11, wherein the good supplied by the producer is associated with at least one of: (i) a product, (ii) a service, and (iii) a natural resource.

13. The method of claim 11, wherein the verifier platform is associated with at least one of: (i) a governmental authority, and (ii) a non-governmental organization.

14. The method of claim 11, wherein the secure, distributed transaction ledger is associated with blockchain technology.

15. The method of claim 11, wherein the asymmetric cryptosystem is associated with three polynomial time algorithms: (i) a probabilistic key-generation algorithm, (ii) an encryption algorithm, (iii) a probabilistic encryption algorithm, and (iv) a decryption algorithm.

16. The method of claim 15, wherein the asymmetric cryptosystem uses individual key pairs consisting of a public encryption key pk.sub.i and a secret decryption key sk.sub.i.

17. The method of claim 11, wherein the mass balancing verification protocol supports multiple producers.

18. A non-transitory, computer-readable medium storing instructions, that, when executed by a processor, cause the processor to perform a method associated with a producer who supplies amounts xi of a good to a plurality of consumers C.sub.i in a series of transactions and is subject to a mass balancing verification protocol after every K transactions, the method comprising: computing, by a computer processor of a producer platform, K random shares (r.sub.1 through r.sub.K) of a random value r; publishing, by the producer platform, blinded amounts t.sub.i representing x.sub.i+r.sub.i to a secure, distributed transaction ledger using additive secret sharing to store information associated with amounts x.sub.i in a privacy-preserving form; transmitting, by the producer platform, an encrypted r.sub.i to consumer C.sub.i using an asymmetric cryptosystem; receiving, at a consumer platform of consumer C.sub.i, the encrypted r.sub.i from the producer platform while the consumer C.sub.i actually receives an amount {circumflex over (x)}.sub.i of the good from the producer; executing, by the consumer platform, a decryption algorithm to determine r.sub.i; automatically computing {circumflex over (x)}.sub.i+r.sub.i and transmitting, by the consumer platform, a fraud alert signal if differs from the published t.sub.i; transmitting an encrypted rolling sum value to a next consumer C.sub.i+1; executing, by a verifier platform after K transactions, the mass balance verification protocol and automatically determine a total amount of good that the producer had collectively supplied to the consumers C.sub.i; and transmitting, by the verifier platform, a fraud alert signal based on the total amount and a maximum allowed amount.

19. The medium of claim 18, wherein a balance is cached after every K-cycle to achieve a number of additions that is independent of a number of previous K-cycles.

20. The medium of claim 18, wherein communications between producers and consumers are performed via at least one of: (i) a direct communication channel, and (ii) the secure, distributed transaction ledger.

21. The medium of claim 18, wherein communications between consumers are performed via at least one of: (i) a direct communication channel, and (ii) the secure, distributed transaction ledger.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1A is a system incorporating one approach to mass balancing.

(2) FIG. 1B illustrates a secret sharing system.

(3) FIG. 2 is a high-level block diagram of a system in accordance with some embodiments.

(4) FIG. 3A is a producer platform method according to some embodiments.

(5) FIG. 3B is a consumer platform method in accordance with some embodiments.

(6) FIG. 3C is a verifier platform method according to some embodiments.

(7) FIG. 4 is a human machine interface display according to some embodiments.

(8) FIG. 5 is an apparatus or platform according to some embodiments.

(9) FIG. 6 is portion of a transaction data store in accordance with some embodiments.

(10) FIG. 7 is a tablet computer according to some embodiments.

DETAILED DESCRIPTION

(11) In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.

(12) One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.

(13) FIG. 1A is a system 110 incorporating one approach to mass balancing. In particular, a producer 112 provides various amounts of product x.sub.i to consumers 114 C.sub.1 through C.sub.n. Moreover, the producer 112 is assigned an overall limit or quota associated with the total amount of product that is provided. For example, the producer 112 might be an oil refinery that is only allowed to ship 10,000 barrels of oil in a particular month. In this case, the producer 112 and/or consumers 114 might record amounts of product that are provided in a secure, distributed transaction ledger 116 (e.g., C.sub.2 might indicate that it received 3,000 barrels, C.sub.3 might record that it received 1,000 barrels, etc.). It would then be relatively simple process for the system 110 to calculate the total amount of product that was sold by the producer 112 in any given month (e.g., x.sub.1+x.sub.2+ . . . +x.sub.n). Note, however, that this approach also discloses exactly how much each consumer 114 received. In some cases, parties might prefer to keep this level of detail private. For example, a company might be required disclose the overall amount it pays the board of directors without disclosing exactly how much each director earns individually.

(14) Some embodiments described herein provide a mechanism that allows for public verifiability in mass balancing scenarios and ensures privacy of the producer's production details such as amounts. The mechanism may be based on an information security technology referred to as “additive secret sharing.” As a result, a system may store single data points, e.g., amounts, on a distributed ledger in a way that preserves privacy. The data held by the distributed ledger might not reveal anything about the single amounts but still allows for public verifiability of an overall sum of produced amounts. This, in turn, may enable comparison to a producer's quota.

(15) Some embodiments disclosed herein may utilize an asymmetric cryptosystem. As used herein, the phrase “asymmetric cryptosystem” (also known as “public-key cryptography”) may refer to a cryptographic system that uses pairs of keys, including: (1) public keys, which may be disseminated widely; and (2) private keys, which are known only to the owner. The generation of such keys may depend on cryptographic algorithms (e.g., based on mathematical problems) to produce one-way functions. Effective security then only requires keeping the private key private, and the public key can be openly distributed without compromising security. In such a system, any person can encrypt a message using the receiver's public key, but that encrypted message can only be decrypted with the receiver's private key. In some cases, authentication may also be provided. For example, a sender may combine a message with a private key to create a short digital signature associated with the message. Anyone with the sender's corresponding public key can then combine the same message and a potential digital signature associated with it to determine if the signature is valid (i.e., made by the owner of the corresponding private key).

(16) An asymmetric cryptosystem may be associated with a tuple S=(G, E, D) consisting of three polynomial-time algorithms: A probabilistic key-generation algorithm G that takes a security parameter k as an input and outputs a key pair (pk, sk) consisting of a public encryption key pk and a secret decryption key sk. A (potentially probabilistic) encryption algorithm E that takes a plaintext x∈ and pk as inputs and outputs the ciphertext y=E(x, pk)∈. and denote the plaintext and ciphertext space, respectively. A decryption algorithm D that takes a ciphertext y∈ and sk as inputs and outputs the plaintext x=D(y, sk)∈.
For simplification, the encryption of x∈.sub.i under a cryptosystem S.sub.i=(G.sub.i, E.sub.i, D.sub.i) for pk.sub.i may be denoted by y=E.sub.pk.sub.i(x). Similarly, the decryption of y∈.sub.i for sk.sub.i may be denoted by x=D.sub.sk.sub.i(y).

(17) Some embodiments described herein may utilize additive secret sharing. As used herein, the phrase “additive secret sharing” may refer to a party that wants to split a secret into several shares given to shareholders, in such a way that each individual shareholder does not know the secret, yet if enough shareholders re-combine their shares then the secret can be reconstructed. FIG. 1B illustrates a secret sharing system 120. The system 120 lets a party split some secret information s 124 ∈GF(q) in n parts such that these n parts together represent s 124. We denote a secret-shared value s by s 122 while the i-th part, called share, is denoted by s.sub.i 122. Note that the additive secret sharing system 120 ensures privacy and correctness. Privacy guarantees that no share leaks any non-trivial information about s 124 while correctness ensures that s 124 can be reconstructed by combining the n shares. To share a value s 124, one chooses n−1 random shares s.sub.1, . . . , s.sub.n-1 uniformly at random. The n-th share is computed as follows:

(18) ${〚s〛}_n=s-\underset{i=1}{\overset{n-1}{.Math.}}{〚s〛}_i$

(19) Some embodiments described herein may utilize one or more secure, distributed transaction ledgers. As used herein, the phrase “distributed ledger” (also called a shared ledger or distributed ledger technology) may refer to a consensus of replicated, shared, and synchronized digital data that might be geographically spread across multiple sites, countries, or institutions without incorporating a central administrator or centralized data storage. A peer-to-peer network and consensus algorithms may help ensure accurate replication. For example, a distributed ledger database might be spread across several nodes (e.g., devices) on a peer-to-peer network, and each node may replicate and save an identical copy of the ledger (updating itself independently). When a ledger update happens, each node may construct the new transaction and the nodes may vote by consensus algorithm on which copy is correct. Once a consensus has been determined, all of the nodes update themselves with the new, correct copy of the ledger. Security may be accomplished through cryptographic keys and signatures. As long as most of the nodes are honest, such a secure, distributed ledger will ensure data integrity. One very common form of distributed ledger is blockchain technology (e.g., associated with a public or private blockchain).

(20) FIG. 2 is a high-level block diagram of a system 200 in accordance with some embodiments. The system 200 includes a producer platform 210 that supplies an amount of good to consumers associated with consumer platforms 220 C.sub.1 through C.sub.n in a series of transactions. Moreover, information about the transactions is recorded in a secure, distributed transaction ledger 250. The consumer platforms 220 might generate a fraud alert signal (e.g., when they suspect that the producer platform 210 is not being honest about an amount of good that was provided). Similar, a verifier platform 290 might analyze information in the distributed transaction ledger 250 and generate a fraud alert signal (e.g., when the producer platform 210 exceeds a production quota). According to some embodiments, portions of the system 200 might operate automatically or be initiated via a command from a remote operator or administrator interface device. As used herein, the term “automatically” may refer to, for example, actions that can be performed with little or no human intervention.

(21) As used herein, devices, including those associated with the system 200 and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network (“LAN”), a Metropolitan Area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.

(22) The producer platform 210 and/or the other devices in the system 200 may store information into and/or retrieve information from various data stores (e.g., data storage devices), which may be locally stored or reside remote from the producer platform 210 and/or the other devices. Although a single producer platform 210 and verifier platform 290 are shown in FIG. 2, any number of such devices may be included. Moreover, various devices described herein might be combined according to embodiments of the present invention. For example, in some embodiments, the secure, distributed transaction ledger 250 and verifier platform 290 might comprise a single apparatus. Some or all of the system 200 functions may be performed by a constellation of networked apparatuses, such as in a distributed processing or cloud-based architecture.

(23) A user or administrator may access the system 200 via a remote device (e.g., a Personal Computer (“PC”), tablet, or smartphone) to view information about and/or manage operational information in accordance with any of the embodiments described herein. In some cases, an interactive graphical user interface display may let an operator or administrator define and/or adjust certain parameters (e.g., to configure quota rules or requirements, add consumers, etc.) and/or provide or receive automatically generated recommendations or results from the system 200.

(24) FIG. 3A is a method that might be performed by the producer platform 210 in the system 200 described with respect to FIG. 2. The flow charts described herein do not imply a fixed order to the steps, and embodiments of the present invention may be practiced in any order that is practicable. Note that any of the methods described herein may be performed by hardware, software, or any combination of these approaches. For example, a computer-readable storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein.

(25) The methods of FIGS. 3A through 3C might be associated with, for example, a verification process that is to be performed after every K transactions have been executed and recorded (e.g., after five product shipments to various consumers). At S312, a computer processor of a producer platform may compute K random shares (r.sub.1 through r.sub.K) of a random value r. At S314, the producer platform may then publish blinded amounts t.sub.i representing x.sub.i+r.sub.i to a secure, distributed transaction ledger (e.g., implemented with blockchain technology) using additive secret sharing to store information associated with amounts x.sub.i in a privacy-preserving form. That is, looking at the stored value will not reveal x.sub.i unless information about the random share r.sub.i is also known. At S316, the producer platform may transmit an encrypted r.sub.i to consumer C.sub.i using an asymmetric cryptosystem.

(26) The information transmitted at S316 may then be evaluated by the consumer C.sub.i. For example, FIG. 3B is a method that might be performed by the consumer platforms 220 in the system 200 described with respect to FIG. 2. At S322, a consumer platform of consumer C.sub.i may receive the encrypted r.sub.i from the producer platform while the consumer Ci actually receives an amount {circumflex over (x)}.sub.i of the good from the producer. The consumer platform may then execute a decryption algorithm to determine r.sub.i at S324. At S326, the consumer platform may then calculate {circumflex over (x)}.sub.i+r.sub.i and generate a fraud alert signal if {circumflex over (x)}.sub.i+r.sub.i differs from the published t.sub.i. For example, if the producer platform delivered 5,000 gallons of product to the consumer platform but published a blinded value of t.sub.i={circumflex over (x)}.sub.i+r.sub.i to the secure, distributed transaction ledger indicating that only 2,500 gallons were delivered, the consumer platform might at S326 generate a fraud alert signal to a governmental authority. As will be explained, the consumer platform may also transmit an encrypted rolling sum value to a next consumer C.sub.i+1 at S328.

(27) FIG. 3C is a method that might be performed by the verifier platform 290 in the system 200 described with respect to FIG. 2. At S332, a verifier platform, after K transactions, may execute a mass balance verification protocol to determine a total amount of good that the producer had collectively supplied to the consumers C.sub.i. At S334, the verifier platform may generate a fraud alert signal when appropriate based on the total amount and a maximum allowed amount. For example, if a producer was authorized to sell 100 jet engines in a single year, the verifier platform might generate a fraud alert signal when it determined that the producer has delivered 110 jet engines so far this year.

(28) For simplification purposes, assume that a single producer P transfers amounts x.sub.i of a particular good to consumers C.sub.i. These amounts are published via a distributed ledger DL in a privacy-preserving form. Each of these entries can be verified by the respective consumer C.sub.i. This may be referred to as “single amount verification.” Furthermore, the producer P tries to convince verifier V that the total amount x=Σ.sub.i x.sub.i does not exceed a maximum x.sub.max (e.g., a threshold quota). This maximum amount x.sub.max of a good that producer P is entitled to produce is public information. This verification may be referred to as “balance verification.”

(29) Also assume that every consumer C.sub.i has an individual key pair (pk.sub.i, sk.sub.i) of an asymmetric cryptosystem, consisting of a public encryption key pk.sub.i and a secret decryption key sk.sub.i. Applying the encryption function E.sub.pk.sub.i(⋅) to a plaintext x yields the corresponding ciphertext y, i.e., E.sub.pk.sub.i(x)=y. Accordingly, applying the decryption function D.sub.sk.sub.i(⋅) to a ciphertext y yields the corresponding plaintext x, i.e., D.sub.sk.sub.i(y)=x.

(30) Further assume a balance verification frequency of once every K produced amounts. At the beginning of each K-cycle, P secret-shares a random value r by computing K random shares such that r.sub.1=r.sub.1, . . . , r.sub.K=r.sub.K of r such that r=Σ.sub.i=1.sup.K r.sub.i.

(31) The protocol specification includes an amount publication that begins with the producer P blinding the amount x.sub.i by adding the i-th random share r.sub.i. Producer P then publishes the resulting blinded value t.sub.i via the distributed ledger DL as follows:
P.fwdarw.DL:t.sub.i=x.sub.i+r.sub.i
The amount publication then has producer P encrypt r.sub.i with consumer C.sub.i's public key and send the resulting ciphertext s.sub.i to consumer C.sub.i as follows:
P.fwdarw.C.sub.i:s.sub.i=E.sub.pk.sub.i(r.sub.i)

(32) Next, the protocol specification performs single amount verification. Initially, consumer C.sub.i decrypts s.sub.i and obtains the random blinding share r.sub.i used for blinding as follows:
C.sub.i:r.sub.i=D.sub.sk.sub.i(s)
Next in the single amount verification, consumer C.sub.i adds the decrypted r.sub.i to the (physically) received amount {circumflex over (x)}.sub.i and verifies t.sub.i by comparing it to this sum. If the two values are not equal, consumer C.sub.i reports fraud as follows:
C.sub.i:t.sub.i{circumflex over (x)}.sub.i+r.sub.i

(33) a) if t.sub.i≠{circumflex over (x)}.sub.i+r.sub.i: report fraud (producer dishonest)

(34) Finally, the single amount verification performs the following to allow for removing the overall blinding r=Σ.sub.i r.sub.i later during balance verification, the consumers maintain the sum r.sub.Σ of the used r.sub.i. To do so, each consumer C.sub.i sends r.sub.Σ to the consumer C.sub.i+1 of the next transaction. To prevent consumer C.sub.2 from learning r.sub.1, consumer C.sub.1 blinds r.sub.1 with a randomly chosen r.sub.0. The sum r.sub.Σ is transferred in an encrypted form from consumer C.sub.i to consumer C.sub.i+1 to prevent uninvolved participants from inferring r.sub.i by comparing two consecutive r.sub.Σ as follows:
C.sub.i.fwdarw.C.sub.i+1:

(35) a) If i=1: E.sub.pk.sub.i+1(r.sub.Σ)=E.sub.pk.sub.i+1(r.sub.0+r.sub.1) with r.sub.0∈.sub.i

(36) b) If 1<i<K: E.sub.pk.sub.i+1(r.sub.Σ)=E.sub.pk.sub.i+1(D.sub.sk.sub.i(r.sub.Σ)+r.sub.i)

(37) c) If i=K: E.sub.pk.sub.1(r.sub.Σ)=E.sub.pk.sub.1(D.sub.sk.sub.i(r.sub.Σ)+r.sub.i)

(38) Next, the protocol specification performs balance verification. Initially the balance verification, after K produced amounts (i.e., at the end of a K-cycle or “epoch”), consumer C.sub.1 subtracts r.sub.0 from the blinded sum r.sub.Σ of random values r.sub.i to obtain the unblinded sum. The unblinded sum of the j-th K-cycle is denoted by r.sub.Σ.sub.j. Consumer C.sub.1 publishes the unblinded sum r.sub.Σ.sub.j via distributed ledger DL as follows:
C.sub.1.fwdarw.DL: if i=K:r.sub.Σ.sub.j=D.sub.sk.sub.1(r.sub.Σ)−r.sub.0
Balance verification then involves, once every K produced amounts (i.e., once i=K), verifier V computes the balance by adding all t.sub.i and subtracting their sum from the maximum amount x.sub.max. The random shares r.sub.i (used in each t.sub.i=x.sub.i+r.sub.i) of each K-cycle add up to r.sub.Σ=r. Therefore, the r.sub.Σ.sub.1, . . . , r.sub.Σ.sub.j of the completed K-cycles need to be added for the blindings to cancel out. The result is the balance δ.sub.j of the j-th K-cycle as follows:
V: δ.sub.j=x.sub.max−Σ.sub.it.sub.i+Σ.sub.jr.sub.Σ.sub.j

(39) a) If δ.sub.j<0: report fraud (mass balance exceeded)

(40) b) If δ.sub.j=0: report fraud once P publishes another t.sub.i

(41) For recurring balance verification, a verifier V might speed up the calculation of δ.sub.j by caching the balance after every K-cycle (either locally by each verifier V or on distributed ledger DL) and thus achieve a number of additions that is independent of the number of previous K-cycles. To do so, when computing δ.sub.j the verifier V may subtract the t.sub.i of the current K-cycle from the previous balance δ.sub.j−1 and add r.sub.Σ.sub.j of the current round.

(42) Furthermore, according to some embodiments producer P could secret-share r=0 instead of some random r. This may simplify the balance computation because the random r.sub.i of a K-cycle will cancel out automatically (assuming that the producer P always behaves in an honest fashion during secret sharing).

(43) Note that any communication between producers P and consumers C (or between consumers C and other consumers C) might be performed via direct communication channels and/or through the distributed ledger DL.

(44) FIG. 4 is a human machine interface display 400 in accordance with some embodiments. The display 400 includes a graphical representation 410 of a blockchain based mass balancing via secret sharing system in accordance with any of the embodiments described herein. Selection of an element on the display 400 (e.g., via a touchscreen or a computer mouse pointer 420) may result in display of a pop-up window containing more detailed information about that element and/or various options (e.g., to add consumers, adjust quota rules or amounts, etc.). Selection of an “Adjust System” icon 430 may also let an operator or administrator alter or fine tune the operation of the system.

(45) Note that the embodiments described herein may also be implemented using any number of different hardware configurations. For example, FIG. 5 is a block diagram of an apparatus or platform 500 that may be, for example, associated with the system 200 of FIG. 2 (and/or any other system described herein). The platform 500 comprises a processor 510, such as one or more commercially available Central Processing Units (“CPUs”) in the form of one-chip microprocessors, coupled to a communication device 560 configured to communicate via a communication network (not shown in FIG. 5). The communication device 560 may be used to communicate, for example, with one or more remote user platforms, administrator platforms, etc. The platform 500 further includes an input device 540 (e.g., a computer mouse and/or keyboard to enter consumer information, quota amounts, etc.) and/an output device 550 (e.g., a computer monitor to render a display, transmit recommendations, and/or create reports about mass balance verification results etc.). According to some embodiments, a mobile device, monitoring physical system, and/or PC may be used to exchange information with the platform 500.

(46) The processor 510 also communicates with a storage device 530. The storage device 530 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 530 stores a program 512 and/or a verification engine 514 for controlling the processor 510. The processor 510 performs instructions of the programs 512, 514, and thereby operates in accordance with any of the embodiments described herein. For example, when the platform 500 is associated with a producer the processor 510 may compute K random shares (r.sub.1 through r.sub.K) of a random value r, publish blinded amounts t.sub.i representing x.sub.i+r.sub.i to a secure, distributed transaction ledger using additive secret sharing to store information associated with amounts x.sub.i in a privacy-preserving form, and transmit an encrypted r.sub.i to consumer C.sub.i using an asymmetric cryptosystem. When the platform 500 is associated with a consumer, the processor 510 may receive the encrypted r.sub.i from the producer platform (while the consumer C.sub.i actually receives an amount {circumflex over (x)}.sub.i of the good from the producer), execute a decryption algorithm to determine r.sub.i, and compute {circumflex over (x)}.sub.i+r.sub.i and generate a fraud alert signal if differs from the published t.sub.i. The processor 510 may also transmit an encrypted rolling sum value to a next consumer C.sub.i+1. When the platform 500 is associated with a verifier, the processor 510 may execute a mass balance verification protocol to determine a total amount of good that the producer had collectively supplied to the consumers C.sub.i. The processor 510 may also generate a fraud alert signal when appropriate based on the total amount and a maximum allowed amount (e.g., a production quota).

(47) The programs 512, 514 may be stored in a compressed, uncompiled and/or encrypted format. The programs 512, 514 may furthermore include other program elements, such as an operating system, clipboard application, a database management system, and/or device drivers used by the processor 510 to interface with peripheral devices.

(48) As used herein, information may be “received” by or “transmitted” to, for example: (i) the platform 500 from another device; or (ii) a software application or module within the platform 500 from another software application, module, or any other source.

(49) In some embodiments (such as the one shown in FIG. 5), the storage device 530 further stores a transaction data store 600. An example of a database that may be used in connection with the platform 500 will now be described in detail with respect to FIG. 6. Note that the database described herein is only one example, and additional and/or different information may be stored therein. Moreover, various databases might be split or combined in accordance with any of the embodiments described herein.

(50) Referring to FIG. 6, a table is shown that represents the transaction data store 600 that may be stored at the platform 500 according to some embodiments. The table may include, for example, entries associated with transactions between a producer and consumers. The table may also define fields 602, 604, 606, 608, 610 for each of the entries. The fields 602, 604, 606, 608, 610 may, according to some embodiments, specify: a transaction identifier and date 602, a producer identifier and quota 604, a consumer identifier 606, a transaction verified indication 608, and fraud signal with a total amount 610. The transaction store 600 may be created and updated, for example, when a distributed ledger is updated with information about a new supply of an amount of good from a producer to a consumer, a change in quota, etc.

(51) The transaction identifier and date 602 might be a unique alphanumeric label that is associated with a transaction between a producer and a consumer along with a date that the transaction was executed. The producer identifier and quota 604 might identify who supplied the good to the consumer (along with any mass balance limits associated with that type of good). The consumer identifier 606 might identify who received the good and the transaction verified indication 608 might indicate whether or not that party has verified that the producer reported the correct amount (as compared to the physical amount that was received). The fraud signal 610 might indicate that the system has detected that the producer has exceeded the associated quote (along with the actual total amount of good that was provided by the producer to all of the consumers in aggregate without revealing exactly how much each consumer received individually).

(52) Thus, embodiments may let the data required for mass balancing be kept confidential. Instead, the information is made available in a privacy preserving way. This enables novel business scenarios for distributed ledgers, such as blockchains, where confidentiality can play a substantial role. Furthermore, by using additive secret sharing, embodiments may not only help ensure confidentiality but may also reduce computational complexity (encouraging good scalability). Furthermore, embodiments may enable a variety of use cases based on latest technologies (e.g., distributed ledgers and/or blockchain as well as secret sharing) to improve analytics and intelligent processes in enterprise applications.

(53) Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with some embodiments of the present invention (e.g., some of the information associated with the databases described herein may be combined or stored in external systems). Moreover, although some embodiments are focused on particular types of producers, consumers, and goods, any of the embodiments described herein could be applied to other types of applications. For example, a protocol might help ensure that a single consumer does not exceed an overall quota limiting how much of a particular type of good they are allowed purchase from various producers (without revealing how much each producer individually sold to that consumer).

(54) Moreover, the displays shown herein are provided only as examples, and any other type of user interface could be implemented. For example, FIG. 7 illustrates a tablet computer 700 with a mass balancing protocol display 710. The display 710 might be used, for example, by an operator or administrator to configure consumer parameters, producer variables (e.g., quotas, blockchain information, etc.). Selection of an adjust system icon 720 might, for example, let an operator add a new consumer platform to the system (along with details about a consumer communication channel, cryptography keys, purchase order and payment identifiers, etc.).

(55) The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.