SYSTEMS AND METHODS FOR COMMUNICATION, STORAGE AND PROCESSING OF DATA PROVIDED BY AN ENTITY OVER A BLOCKCHAIN NETWORK

Abstract

A computer-implemented method for submitting feedback for an entity to a blockchain is disclosed. The method, which is implemented at one of a plurality of participating nodes, includes: obtaining a first key, the first key being one of a fixed set of keys distributed to participating nodes that are eligible to submit feedback for the entity; generating first feedback (r.sub.j) of the entity for submission to the blockchain; encrypting the first feedback (r.sub.j) using at least the first key; and submitting the encrypted first feedback to a mixing service, the mixing service being configured to generate a mixed transaction based on the encrypted first feedback and at least one other encrypted feedback submission from one or more eligible participating nodes.

Claims

1-15. (canceled)

16. A computer-implemented method comprising: obtaining, at an entity, encrypted data for feedback; decrypting the encrypted data using a private key of the entity to yield entity decrypted data; and decrypting the entity encrypted data, by computing an exclusive or operation between the entity decrypted data and a key share corresponding to a node that transmitted the encrypted data, to yield decrypted data, wherein use of the key share indicates that the node is eligible to provide feedback.

17. The method of claim 16, wherein the encrypted data is obtained from a mixing service, the mixing service being configured to generate a mixed transaction based on the encrypted data and at least one other encrypted data provided from one or more eligible nodes.

18. The method of claim 17, wherein the mixed transaction specifies a first quantity of tokens to transfer to the entity, the first quantity depending on a number of encrypted data submissions of the entity that are included as inputs in the mixed transaction.

19. The method of claim 16, further comprising requesting, by the entity, a plurality of nodes to provide feedback.

20. The method of claim 19, wherein a response to the request is associated with a key of a fixed set of keys distributed to the plurality of nodes eligible to respond.

21. The method of claim 16, wherein the entity distributes key shares to a plurality of nodes eligible to provide feedback.

22. The method of claim 21, wherein a key share is distributed from the entity in response to a transfer of tokens to an entity node associated with the entity for a service rendered by the entity.

23. The method of claim 16, wherein the key share is one of a plurality of key shares that are distributed to eligible nodes and that are used for collaboratively constructing a key of the eligible nodes.

24. The method of claim 23, wherein the encrypted data is encrypted using the key share and a public key associated with the entity.

25. The method of claim 16, further comprising: verifying the node is eligible to participate by identifying a secret included with the decrypted data indicative of the node collaborating with other eligible nodes.

26. The method of claim 25, wherein the secret is collaboratively generated based on a secret share joining process.

27. The method of claim 16, wherein the encrypted data indicates a service provided by the entity.

28. A computing device to verify feedback submitted to a blockchain, the computing device comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, cause the computing device to execute the method in claim 16.

29. A non-transitory processor-readable medium storing processor-executable instructions, that when executed by a processor, cause the processor to execute the method in claim 16.

30. The non-transitory processor-readable medium of claim 29, wherein the encrypted data is obtained from a mixing service, the mixing service being configured to generate a mixed transaction based on the encrypted data and at least one other encrypted data provided from one or more eligible nodes.

31. The non-transitory processor-readable medium of claim 30, wherein the mixed transaction specifies a first quantity of tokens to transfer to the entity, the first quantity depending on a number of encrypted data submissions of the entity that are included as inputs in the mixed transaction.

32. The non-transitory processor-readable medium of claim 29, wherein the instructions further cause the processor to request a plurality of nodes to provide feedback.

33. The non-transitory processor-readable medium of claim 32, wherein a response to the request is associated with a key of a fixed set of keys distributed to the plurality of nodes eligible to respond.

34. The non-transitory processor-readable medium of claim 32, wherein the instructions further cause the processor to distribute key shares to the plurality of nodes eligible to provide feedback.

35. The non-transitory processor-readable medium of claim 29, wherein the instructions further cause the processor to verify the node is eligible to participate by identifying a secret included with the decrypted data indicative of the node collaborating with other eligible nodes.

Description

[0033] Any feature described in relation to one aspect or embodiment of the invention may also be used in respect of one or more other aspects/embodiments. These and other aspects of the present invention will be apparent from and elucidated with reference to, the embodiment described herein. An embodiment of the present invention will now be described, by way of example only, and with reference to the accompany drawings, in which:

[0034] FIG. 1 illustrates an example blockchain network of nodes.

[0035] FIG. 2 shows a schematic diagram of a commitment channel established between a participating node and an entity node.

[0036] FIG. 3 shows, in flowchart form, an example method for submitting data e.g. feedback for an entity to a blockchain, in accordance with an embodiment of the present application.

[0037] FIG. 4 shows a schematic diagram representing an example process of decrypting an encryption of a data e.g., feedback submission.

[0038] FIG. 5 shows, in flowchart form, another example method for submitting data e.g. feedback for an entity to a blockchain, in accordance with an embodiment of the present application.

[0039] FIG. 6 shows, in block diagram form, an example blockchain node.

[0040] In the present application, the term “and/or” is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, and without necessarily excluding additional elements.

[0041] In the present application, the phrase “at least one of . . . or . . . ” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements.

[0042] We now provide an example of how the invention could be implemented, for the purposes of illustration only. In our example, the invention is implemented as a feedback submission platform but this is purely one convenient example of how the invention could be put into practice and is not intended to be limiting.

[0043] In the present application, the term “entity” refers to any entity that receives or is capable of receiving data (for example, feedback in the form of reviews, ratings, evaluations, comments, votes, etc.). An “entity” may additionally or alternatively refer to a representative that is authorized to receive and verify data such as votes/feedback on behalf of an entity. For example, an “entity” may be an organization, such as a service provider or a product manufacturer, a representative of an organization (e.g., the customer service department of a company collecting and posting client reviews), or a person (e.g., a political candidate, an employee, etc.). In the context of the data submissions protocol described herein, an entity may be represented by one or more nodes in a blockchain network. In some cases, an entity may solicit voters or users of their products to participate in a vote/feedback submission process. As data e.g., votes/feedback for an entity are submitted (by users, represented as participating nodes), the entity is able to verify the validity of the data, and publicly disclose the submissions, while maintaining the anonymity of the sources of the data, by broadcasting them on the blockchain ledger.

[0044] In the present application, a “reviewer” refers to an organization or an individual that submits data (including, but not limited to, reviews) for an entity. A reviewer may, for example, be a participant in the Blockchain-based Data Submissions Protocol (BDSP) disclosed herein. Alternatively, the phrase Blockchain-based Feedback Submissions Protocol (BFSP) may be used. A “reviewing node” is a node (in a blockchain network) that is associated with a particular reviewer, and a “participating node” is a node associated with a reviewer that participates in a verification or feedback submissions process, such as the BDSP of the present disclosure.

[0045] Reference will first be made to FIG. 1 which illustrates, in block diagram form, an example blockchain network 100 associated with a blockchain. The blockchain network is a peer-to-peer open membership network which may be joined by anyone, without invitation or without consent from other members. Distributed electronic devices running an instance of the blockchain protocol under which the blockchain network 100 operates may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be a Bitcoin protocol, or other cryptocurrency, for example.

[0046] The electronic devices that run the blockchain protocol and that form the nodes 102 of the blockchain network 100 may be of various types including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such a smartphones, wearable computers such as smart watches or other electronic devices.

[0047] Nodes 102 of the blockchain network 100 are coupled to one another using suitable communication technologies which may include wired and wireless communication technologies. In many cases, the blockchain network 100 is implemented at least partly over the Internet, and some of the individual nodes 102 may be located in geographically dispersed locations.

[0048] Nodes 102 maintain a global ledger of all transactions on the blockchain. The global ledger is a distributed ledger and each node 102 may store a complete copy or a partial copy of the global ledger. Transactions by a node 102 affecting the global ledger are verified by other nodes 102 so that the validity of the global ledger is maintained. The details of implementing and operating a blockchain network, such as one using the Bitcoin protocol, will be appreciated by those ordinarily skilled in the art.

[0049] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded into the inputs and outputs specify how and by whom the outputs of the transactions can be accessed. The output of a transaction may be an address to which tokens are transferred as a result of the transaction. Those tokens are then associated with that output address as an available transaction output. In the context of a cryptocurrency, like Bitcoin, an available transaction output may be referred to as an unspent transaction output (UTXO). A subsequent transaction may then reference that address as an input in order to transfer those tokens to one or more other addresses.

[0050] While the transactions are pseudo-anonymous in that no personal information is contained in the transactions on the blockchain ledger, it is possible to trace the transfer of tokens in chains of transactions and, in some cases, to link tokens to an individual using external data. In order to increase anonymity, a mixing transaction may be used to pool inputs from a variety of sources and then to divide and allocate the pooled tokens to outputs. If all the inputs and outputs are the same size, it is difficult to associate a particular input with a particular output. However, in such transactions at least one participating node is aware of the linkage between an input address and output address specified by another participating node. In such mixing transactions, such as a CoinJoin operation in the Bitcoin protocol, a single transaction having multiple inputs and multiple outputs is used to mix the tokens.

[0051] Some other anonymizing techniques are used to try to avoid revealing links between an input and an output, such as ring signatures or stealth addresses, with varied effectiveness. Stealth addresses try to de-link the output address to which tokens are sent from a particular user. Ring signatures try to make a source untraceable by making it equi-probable that any one of a group of possible signatories was the one that signed/authorized a particular transaction.

[0052] The present disclosure provides a blockchain-based data submissions protocol. It may be described in some embodiments as a feedback submissions protocol. The term “feedback” may be used for convenience of illustration instead of “data” but is not intended to be limiting. More specifically, a protocol for submitting feedback using a blockchain ledger is disclosed. A participant of the protocol anonymously submits their feedback (e.g., review) for a product, service, entity, etc. to a specific entity. The feedback submission itself is encrypted and transmitted to the entity by means of a blockchain transaction created by the submitter of the feedback (e.g., reviewer). Upon receiving a feedback submission, the entity can verify the validity of the submission and, if valid, broadcast the feedback on the public ledger. The protocol does not rely on a trusted thirty party, and includes a mechanism to discourage eligible participants from casting multiple different feedback submissions and to prevent non-eligible ones from taking part in the process. Feedback submissions are anonymized by obscuring the connection between submitted feedback for an entity and the participant submitting the data e.g., feedback. In particular, a mixing service, such as a transaction output shuffling process, is employed to generate a mixed, or joint, blockchain transaction which delinks inputs (of participants) from their output (i.e., entity receiving feedback) addresses.

[0053] The proposed data submissions protocol may enable an entity to authenticate submitted data to ensure that only those submissions from eligible participants (such as endorsed, or previous, users of the entity's products or services) are accepted by the entity and broadcast on the blockchain. The proposed protocol leverages blockchain concepts to provide a system/platform for data e.g., feedback submissions (and verification) which facilitates anonymizing of data, proper delivery of data to the relevant entities, and incentivizing entities to undertake the tasks of verifying data submissions and publicly disclosing the eligible data on the blockchain.

[0054] In the proposed data submissions protocol, each data submission is included in a blockchain transaction that transfers tokens to the entity receiving the data. In particular, reviewers that participate in the protocol transfer (“pay”) a fixed quantity of tokens to be able to submit their data. This “submissions fee” is collected by the relevant entity (or data verifier) upon successful broadcast of the data on the blockchain. Entities receiving data (e.g., being reviewed) are thus able to receive a quantity of tokens that is proportional to their share of data, as a “reward” for their verification of data submissions and disclosure of eligible data on the blockchain. A plurality of transfer transactions containing data submissions may be combined to form a single transaction with one or more outputs (corresponding to entities receiving submitted data), thereby increasing privacy by obfuscating the connections between data and their sources.

[0055] In the description herein, the terms “participating node”, “candidate node”, “input address”, and “output address” may be used. The reference to an “address” of a node is not meant to refer to a network address of a physical node. Instead, the “address” is an address specified in a transaction on the blockchain having an allocation of tokens to which the physical node can claim ownership by having a key that corresponds to a signature on the transaction. In this sense, the “output address” is not an address of a participating node, but is a blockchain transaction output address that is owned by or associated with a participating node. Likewise, the “input address” is an address of an available transaction output (in cryptocurrency terms, a UXTO) that is owned by or associated with a participating node.

[0056] As explained above, the blockchain-based data submissions protocol of the present disclosure is also suitable for deploying in the electronic voting (i.e., e-vote submission) context. Therefore, any discussion of “feedback” and feedback submissions protocols in the description will be understood to also apply to “votes” and voting protocols. Furthermore, the terms “rating” and “review” may be used interchangeably throughout the description, and will be understood as referring to a suitably formatted feedback (e.g., numerical rating, text, etc.) submitted by a reviewer (i.e. verifier) to an entity.

[0057] Secret Sharing

[0058] In a “secret sharing” scheme, a secret k is divided among n parties, such that at least t+1 of the n parties are required to collaborate in order to reconstruct k. Any subset of the n parties may reconstruct the secret k so long as the cardinality of the subset is greater than a specified threshold value t. If the cardinality of the subset is less than or equal to t, then no information about the secret k is revealed. The distribution of key shares among parties may be done using a central dealer who assigns key shares, or through a dealer-less system of distribution. Each solution has its advantages and disadvantages requiring careful consideration of the requirements of the system being implemented when choosing between distribution methods.

[0059] In the data submissions protocol of the present disclosure, key shares k.sub.1, k.sub.2, k.sub.3, . . . k.sub.n of a key k may be used by reviewers to attest their membership to an endorsed group or otherwise demonstrate that they are eligible to participate in the protocol.

[0060] In some implementations, a secret sharing scheme may involve embedding the secret in a polynomial of degree t. An arbitrary secret, x, is stored as point f (0) in a t-degree polynomial f (x) and player i can calculate its share f (x.sub.i). If t+1 out of n parties collaborate, they can reconstruct any point on f (x) with their respective shares (of key x) x.sub.1, x.sub.2, . . . , x.sub.n which correspond to f (x.sub.1), f (x.sub.2), . . . , f (x.sub.n), using Lagrange Polynomial Interpolation. Lagrange Polynomial Interpolation tells us that a function f (x) with degree t can be reconstructed with t+1 points, p={(x.sub.1, f (x.sub.1)), (x.sub.2, f (x.sub.2)), . . . , (x.sub.t+1, f (x.sub.t+1))}, namely by

[00001]$f\left(x\right)={.Math.}_{i\in p}f\left(x_i\right){.Math.}_{j\in p,j\ne i}\frac{x-x_j}{x_i-x_j}={.Math.}_{i\in p}f\left(x_i\right)b_{i,p}\left(x\right),\mathrm{where}{b}_{i,p}\left(x\right)={.Math.}_{j\in p,j\ne i}\frac{x-x_j}{x_i-x_j},b_{i,p}\left(x_i\right)=1,\mathrm{and}{b}_{i,p}\left(x_j\right)=0.$

[0061] One element of the secret sharing scheme is the determination of x×G, where x is the secret key and G is a point on the Elliptical Curve. If f (x) is a t-degree polynomial, the secret x can be interpolated by x=Σ.sub.i∈πb.sub.i,πk.sub.i, where π is a size t+1 subset of shares x.sub.a, x.sub.b, . . . , x.sub.t, x.sub.t+1 and b is an interpolating factor. π is a group of t+1 participants collaborating to calculate x×G without revealing their respective share, x.sub.i. x is the x=0 point on a t-degree polynomial. To calculate x×G: [0062] each participant i calculates a part b.sub.i,πx.sub.i×G, and [0063] all participants in π add their part together (reconstructing the secret x via Lagrange interpolation) giving:

b.sub.a,πx.sub.a×G+b.sub.b,90 x.sub.b×G+ . . . +b.sub.t+1,πx.sub.t+1×G=x×G

[0064] This process of calculating Q=x×G is referred to as “Secret Share Joining”.

[0065] Commitment Channels

[0066] Various blockchain technologies, such as Bitcoin, may sometimes employ “commitment channels” in the construction of pairwise transactions between network nodes. Commitment channels are designed to allow nodes to make multiple transactions without having all of the transactions committed to the blockchain. Once a commitment channel is established between a pair of nodes, the nodes can engage in as many transactions as they would like in a given time period, with only two of the transactions ultimately being added to the blockchain. As a result, the use of commitment channels can lead to a reduction in the number of transactions that are required to be added to the blockchain and a reduction in associated transaction costs. A commitment channel also offers a transferor node the flexibility of having tokens returned if specific criteria are not met by the transferee node or if either the transferor or transferee node determined to end the process after a certain set of transfers.

[0067] In at least one embodiment of a commitment channel implementation, a pair of network nodes, U.sub.A and U.sub.B, collaborate to generate three blockchain transactions: a commitment transaction (T.sub.C), a return transaction (T.sub.r,0), and a transfer transaction (T.sub.t). FIG. 2 shows a schematic diagram of a commitment channel U.sub.A.fwdarw.U.sub.B between transferor node U.sub.A and transferee node U.sub.B. The commitment transaction, T.sub.C represents the commitment component of the commitment channel in which the transferor U.sub.A sends/commits a specified set of tokens, x, for transfer to U.sub.B. The commitment transaction may, in some embodiments, be a 2-of-2 multi-signature pay-to-script-hash (P2SH) transaction. The return transaction, T.sub.r,0 is a transaction that returns the previously committed tokens, x, back to U.sub.A if the transferee node U.sub.B is unable to complete, in an allotted time, a stated criteria for the commitment transaction. The return transaction becomes eligible for submission to the blockchain after a specific point in time, nLockTime, has expired. For the return transaction to be executed successfully, it requires the signatures of both the transferor node U.sub.A and transferee node U.sub.B. The transfer transaction, T.sub.t is the transaction that actually sends the committed tokens, x, to the transferee node U.sub.B. The transfer transaction is executed only if certain criteria are met by the transferee node U.sub.B. For example, in order for the transfer transaction to be successfully submitted to the blockchain, it may require at least the digital signature of the transferee node U.sub.B.

[0068] Blockchain-Based Data Submissions Protocol (BFSP)

[0069] The present application describes methods and systems for submitting (or “transferring”) data for entities using a blockchain. In particular, the present application proposes a data submissions protocol (Blockchain-based Data Submissions Protocol, or BDSP) which leverages blockchain concepts to allow reviewers to submit data anonymously and to have the data recorded publicly and permanently on a distributed ledger. The BDSP is designed to delink the data from the reviewers or other data sources submitting them, and to only allow “approved” reviewers to have their data accepted/considered for disclosure. By facilitating the public disclosure of feedback on a blockchain, the BDSP may help to prevent manipulation of data (e.g., feedback and/or votes, ratings, etc.) by entities and/or third parties. Furthermore, the BDSP provides an incentive for entities receiving data from reviewers to undertake the tasks of verifying the validity of data submissions and broadcasting the eligible data on a blockchain.

[0070] The BDSP includes a plurality of participating nodes (corresponding to reviewers) and at least one entity node (corresponding to entities that receive or are able to receive data such as reviews, ratings, etc.). More specifically, the BDSP is suitable for a group of two or more reviewers, U.sub.1, . . . , U.sub.n, who wish to provide data for one or more entities, C.sub.1, . . . , C.sub.n. For example, the reviewers may be voters casting ballots for one of a set of candidates or members of a group providing reviews of one or more other members. The reviewers may, alternatively, be customers of service providers or product manufacturers that have been granted express permission to submit reviews of specific services or products. As previously explained, to take part in the BDSP and submit data for one of the entities, a reviewer may be required to transfer a fixed quantity of tokens to the entity for whom the data is intended. The transfer of tokens represents a reward to the relevant entity (or data verifier) for checking and broadcasting data submission.

[0071] Reference is now made to FIG. 3, which shows, in flowchart form, an example method 300 for submitting data for an entity to a blockchain. The method 300 may, for example, be performed by one or more participating nodes participating in the BDSP. As noted above, a plurality of nodes corresponding to multiple reviewers (“participating nodes”) and one or more entities (“entity nodes”) take part in the BDSP. In some implementations, each node is a wallet or other such blockchain entity.

[0072] For simplicity, the following description of BDSP uses the example of multiple reviewers submitting data for a single entity. As will be explained below, the reasoning is easily extended to a data submissions process for multiple entities. That is, the use case of BDSP to submit data for a single entity is readily generalizable to submitting data for a plurality of different entities.

[0073] The method 300 is implemented by a node in a blockchain network, such as network 100 of FIG. 1. The method 300 begins with the node joining a process for submitting feedback for a particular entity, in operation 302. The joining step may be implemented in a decentralized manner or through a central authority that assembles a suitable group of participating nodes based, at least in part, on ensuring inclusion of a sufficient number of nodes in the group to allow for anonymization of the submitted data. For example, three or more participating nodes may be required to join before the BDSP can be initiated, to ensure that no individual (i.e., reviewers, candidates, third parties) is able to directly identify the source of any submitted feedback (other than the feedback that they themselves have submitted). In some embodiments, multiple reviewers may join together to collaboratively participate in the BDSP.

[0074] In operation 304, the node obtains a first key, where the first key is one of a fixed set of keys distributed to those participating nodes that are eligible to submit data e.g., feedback for the entity. A fixed set of nodes participating in the protocol effectively agree on the keys that would allow access to the data submissions process. In some embodiments, the participating nodes engage in a secret sharing procedure (e.g., dealer-less scheme) to distribute key shares k.sub.1, k.sub.2, . . . , k.sub.n that can be used to collaboratively construct a secret k. That is, the first key obtained by the node may be a first key share k.sub.j of a group private key k, where the first key share k.sub.j is one of a plurality of key shares that are distributed to eligible participating nodes. In this way, the reviewers themselves have a degree of control on the other reviewers that are endorsed for participation in the BDSP.

[0075] In operation 306, the node generates data e.g., feedback r.sub.j for the entity for submission to the blockchain. The format of feedback r.sub.j may be adaptable to different protocol requirements. The feedback r.sub.j may, for example, be a simple numerical rating (e.g., 0-10 preference) or a review submission (e.g., a descriptor, a fixed-length text block, etc.). In some embodiments, the feedback r.sub.j is an alphanumeric string, such as

review=r.sub.j=useful000062727hj9

[0076] The example feedback r.sub.j includes a review string (“useful”) that is concatenated with a second identifiable string (“000062727hj9”). The second string may, in some cases, include information identifying the relevant reviewer-entity pair for the feedback r.sub.j. For example, the second string may include a first number, l, of characters from the entity's public key and a second number, p, of characters from the reviewer's key share. The second string may be padded with an escape sequence (e.g., a set of 0's) which separates the review string from the reviewer-entity information.

[0077] In operation 308, the feedback r.sub.j is encrypted using at least the first key obtained by the node in operation 304. For example, the feedback r.sub.j may be encrypted with a key share k.sub.j of a group private key k. In some embodiments, the feedback r.sub.j is encrypted using both a public key associated with the entity and the reviewer's key share k.sub.j. As part of the BDSP, each entity (or feedback verifier for an entity) may be provided with a public-secret key pair (Pk.sub.C.sub.i, Sk.sub.C.sub.i). The public keys associated with the entities of the BDSP can be distributed to the participating reviewers and used to encrypt feedback submissions. Encrypting feedback r.sub.j with the public key of an entity helps to ensure that only the interested entity will be able to decrypt and access the feedback.

[0078] An entity may, in some cases, desire to verify the validity of key shares that are used by reviewers to encrypt their respective feedback. The entity can, for example, use existing solutions, such as verifiable secret sharing (VSS) or publicly verifiable secret sharing (PVSS) schemes, to verify that key shares of participating reviewers are consistent with an encrypted “secret”. To facilitate this share verification procedure, reviewers in the BDSP can encrypt their key shares using the public key associated with their entity-of-choice, and collaborate with other eligible reviewers to generate a secret, kG, using their key share. The secret, kG, may, for example, be generated using a secret sharing joining process. The encrypted key share and the generated secret can then be provided to the entity for use in verifying the validity of the key share. For example, the (encrypted) key shares of the reviewers of a particular entity may be pooled in an anonymous manner as part of the BDSP and made accessible to the entity.

[0079] One example of an encryption for feedback r.sub.j using the reviewer's key share k.sub.j and the entity's public key Pk.sub.C.sub.i is given by:

[00002]$\begin{array}{cc}{\mathrm{Enc}}_{{\mathrm{Pk}}_{C_i}}\left(r_j\oplus k_j\right)& \left(A\right)\end{array}$

[0080] where ⊕ represents the XOR (“exclusive or”) between the two strings.

[0081] FIG. 4 shows a schematic diagram representing the process of decrypting a feedback submission that is encrypted using the example scheme (A) above. At step 402, the encryption of feedback r.sub.j is decrypted by entity C.sub.j, using its private key, thereby identifying C.sub.j as the entity for which the feedback r.sub.j is destined. At step 404, the encrypted feedback submission is further decrypted, by computing the XOR between the decrypted data from step 402 and a corresponding reviewer's key share k.sub.j. The key shares of reviewers that are eligible to submit feedback for the entity may, for example, be pooled in an anonymous manner from the eligible reviewers and made accessible to the entity, as part of the BDSP. The entity would be able to obtain the feedback r.sub.j at step 304 by performing the operation,

r.sub.j⊕k.sub.j⊕k.sub.j=r.sub.j

[0082] This “double encryption” of feedback r.sub.j—first with the key share k.sub.j and then with the public key Pk.sub.C.sub.i—allows for a double check on the correctness of the data. In particular, the entity can first decrypt the data using their public key, and subsequently verify that the reviewer providing the encryption of feedback r.sub.j is indeed eligible to participate in the BDSP (i.e., submit feedback to the entity).

[0083] Returning to FIG. 3, in step 310, the node submits the encrypted feedback submission to a mixing service. The mixing service is configured to generate a mixed blockchain transaction based on the encryption of feedback r.sub.j and at least one other encrypted feedback submission from one or more other eligible participating nodes. The encryption of feedback r.sub.j may be included in a transaction transferring a fixed quantity of tokens to the entity for whom the feedback is intended, and two or more such transactions (including encrypted feedback submissions from at least one other reviewer participating in the BDSP) may be combined into a single, joint transaction. For example, the transfer transactions may be combined using a token mixing solution such as CoinJoin. In CoinJoin, a set of participants each contribute with one of the inputs of a joint transaction and provide one output address for the outputs of the joint transaction. Token “shuffling” solutions, such as CoinShuffle, CoinShuffle++, and Circle Shuffle, may be implemented in the BFSP to delink the output addresses of the joint transaction from the participants contributing the inputs of the transaction. Such “shuffling” techniques may facilitate obscuring the connections between submitted feedback and their sources (i.e., reviewers) while still using blockchain transactions to transmit encrypted feedback data. The joint transaction transfers a quantity of tokens to the designated entities, where the total quantity of tokens transferred depends on the number of (encrypted) feedback submissions that are included as inputs in the transaction.

[0084] In the BDSP, an encrypted feedback submission may be included as a data element in a script associated with a transfer transaction from a participating node to the relevant entity. In the context of the Bitcoin protocol, an encrypted feedback submission may be stored as data in script using the opcode OP_RETURN <data>, which allows for the storage of up to 40 bytes of data, or alternatively, as metadata in an output script for an m-of-n multi-signature scheme. As an example, in a 2-of-3 multi-signature script, of the three data elements that are reserved for public keys, two may be used for public keys and one to store an encrypted feedback submission:

[00003]$\mathrm{OP\_}0\mathrm{SigASigB}.Math.\mathrm{OP\_}2{\mathrm{Enc}}_{{\mathrm{Pk}}_{C_i}}\left(r_j\oplus k_j\right)\mathrm{PubAPubBOP\_}3\mathrm{OP\_CHECKMULTSIG}.Math.$

[0085] where

[00004]$\mathrm{meta}1={\mathrm{Enc}}_{{\mathrm{Pk}}_{C_i}}\left(r_j\oplus k_j\right)$

represents metadata, corresponding to an encrypted feedback submission, that a reviewer wishes to store in the transaction.

[0086] The blockchain transactions that are used in the BDSP to convey encrypted feedback and tokens to the relevant entities may be constructed using commitment channels. More specifically, the transmission of an encrypted feedback submission and tokens to a designated entity, C.sub.i, from a reviewer, U.sub.i, may be effected by a set of three transactions: a commitment transaction T.sub.C, a return transaction T.sub.r,i, and a transfer transaction T.sub.t. The transaction T.sub.C represents the commitment component of the feedback submissions protocol. The reviewer U.sub.i commits a specified quantity of tokens, x, that is transferred to an output governed by either: a 2-of-3 multi-signature script, requiring signatures of U.sub.i and entity C.sub.i, or knowledge of the (decrypted) feedback r.sub.i and signature of C.sub.i. The encryption of feedback r.sub.j is submitted as metadata in the multi-signature script. The commitment transaction may be considered as the input contributed by reviewer U.sub.i to the mixed (joint) blockchain transaction between a set of participating nodes and one or more entity nodes in the BDSP.

[0087] Two possible variations of transaction T.sub.r,i are proposed in the BDSP. In a first version, T.sub.r,1, the committed tokens, x, of the transaction T.sub.C are returned to a return address predefined by reviewer U.sub.i. To prevent traceability of movement of tokens, the return address is selected to be one that is different from an input address associated with reviewer U.sub.i. The return of tokens may be effected if a submitted feedback submission is not correctly broadcast on the blockchain within a predetermined period of time. Such scenarios may arise if the entity is unable to decrypt a feedback submission as the submitting reviewer was malicious and did not possess the credential to access the feedback, or if the entity (or review verifier) simply decided not to broadcast the feedback and receive the associated transfer of tokens.

[0088] In an alternate version of the return transaction, T.sub.r,2, a quantity of tokens equal to x/n, where n is the number of reviewers participating in the BDSP, is transferred to all participating reviewers after expiration of a specified period of time. This procedure could be considered as penalizing those reviewers that submit flawed feedback (e.g., reviews that cannot be decrypted by any of the entities or that are not transmitted by eligible reviewers).

[0089] The transaction T.sub.t is the transfer of x tokens from reviewer U.sub.i to entity C.sub.i. For this transaction to be successfully executed, the knowledge of the (decrypted) feedback r.sub.j and the signature of entity C.sub.i are required. The transfer transaction may be considered as outputs of the joint transaction that is formed between participating nodes and one or more entity nodes in the BDSP.

[0090] In some implementations, reviewers may submit their feedback to third-party entities that are independent of the relevant entity for whom the feedback is intended. In particular, reviewers may wish to provide their opinions of products, services, etc. that are provided by certain entities, without those entities influencing or making the decision whether to publish the submitted feedback. For example, reviews may be submitted, by means of mixed blockchain transactions in the BDSP, to operators of third-party review platforms (e.g., online forum, media outlets, industry regulation bodies, etc.) that are independent of the entities that are reviewed, such that submitted reviews, whether positive or negative, may be broadcast via a blockchain, without the influence or intervention of the relevant being reviewed (or assessed, etc.).

[0091] Reference is now made to FIG. 5, which shows another example method 500 for submitting data such as feedback for an entity to a blockchain. The method 500 is implemented by a (participating) node in a blockchain network, such as network 100 of FIG. 1. In some instances, the method 500 may be suitable for systems/platforms for reviewing products and services that are offered by manufacturers and/or service providers. For example, the method 500 may be incorporated into a feedback submissions platform for online marketplaces.

[0092] Entities that offer products/services can give permission to previous clients to publicly and anonymously submit their reviews, using transactions recorded on the blockchain, based, at least in part, on the operations of method 500.

[0093] Operations 502, 506 and 510 of method 500 are similar to operations 302, 306 and 310, respectively, of method 300 described with respect to FIG. 3, and will not be discussed in great detail. The participating node joins a feedback submissions process, implemented as part of the BDSP, in operation 502. In operation 504, the node obtains a first key, the first key being one of a fixed set of keys distributed to nodes eligible to submit feedback for the entity. The first key may be a first key share k.sub.j of a private key k. In particular, the entity (or a representative on behalf of the entity) may distribute key shares k.sub.1, . . . , k.sub.n to users who received its products/services, to be used for feedback encryption and validation. The key share k.sub.j may be released to the reviewer (i.e., user/client), for example, in response to receiving a transaction (e.g., transfer of tokens) or payment for a service that is rendered by the entity to the reviewer/user/client (the key share may, for example, be encrypted with the user/client's public key). Alternatively, an entity may, instead of distributing to users/clients their public key and individual key shares, generate a set of public-private key pairs, one for each eligible or endorsed reviewer. That is, an entity, C.sub.i may produce a set of node-specific keys for the set of endorsed users/clients, where

keys={(Pk.sub.C.sub.i.sup.1, Sk.sub.C.sub.i.sup.1), (Pk.sub.C.sub.i.sup.2, Sk.sub.C.sub.i.sup.2), . . . , (Pk.sub.C.sub.i.sup.n, Sk.sub.C.sub.i.sup.n)}

[0094] and secretly send the public keys Pk.sub.C.sub.j's to the respective reviewers.

[0095] In operation 506, the node generates feedback r.sub.j of the entity for submission to the blockchain. The format of feedback r.sub.j may be similar to that described with respect to operation 306 of method 300. In the specific context of method 500, the feedback r.sub.j may additionally include a string which identifies a product/service that is provided by the entity and being reviewed by the user/client. An example feedback r.sub.j may be in the form,

review=r.sub.j=useful000062727hj9#productID

[0096] In operation 508, the feedback r.sub.j is encrypted prior to being transmitted to the entity for whom the feedback is intended. The encryption scheme (A) discussed above may be applied in operation 408. That is, the reviewer may compute (off-chain) the encryption

[00005]${\mathrm{Enc}}_{{\mathrm{Pk}}_{C_i}}\left(r_j\oplus k_j\right)$

of feedback r.sub.j, where ⊕ represents the XOR between the two strings. Alternatively, if the entity has produced node-specific public-private key pairs for the eligible reviewers, the feedback r.sub.j may be encrypted simply by using the node-/user-specific public key Pk.sub.C.sub.i.sup.j for the entity. The encrypted feedback may be computed off-chain by the reviewer, whereby the entity retains the corresponding decryption key allowing the entity to obtain the feedback.

[0097] In operation 510, the encrypted feedback is submitted to a mixing service to generate a joint transaction that will be recorded on the blockchain. As explained above, an entity that is reviewed can verify the validity of a feedback submission, by checking whether the feedback is submitted by an eligible/endorsed reviewer (e.g., verifying that the reviewer possesses a valid key share of a group private key for an endorsed group). The entity can decrypt the encryption of the feedback and subsequently broadcast the feedback on the blockchain. The validation and broadcasting of the submitted feedback, then, are pre-conditions for the entity to receive tokens transferred by the reviewer as part of the feedback submission transaction.

[0098] Reference will now be made to FIG. 6, which shows, in block diagram form, a simplified example of a node 600, which may, in the context of the present disclosure, be a participating node and/or an entity node. The node 600 includes a processor 602, which may include one or more microprocessors, application specific integrated chips (ASICs), microcontrollers, or similar computer processing devices. The node 600 further includes memory 604, which may include persistent and non-persistent memory, to store values, variables, and in some instances processor-executable program instructions, and a network interface 606 to provide network connectivity over wired or wireless networks.

[0099] The node 600 includes a processor-executable blockchain application 608 containing processor-executable instructions that, when executed, cause the processor 602 to carry out one or more of the functions or operations described herein.

[0100] It will be understood that the devices and processes described herein and any module, routine, process, thread, application, or other software component implementing the described method/process for configuring the blockchain node may be realized using standard computer programming techniques and languages. The present application is not limited to particular processors, computer languages, computer programming conventions, data structures, or other such implementation details.

[0101] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word “comprising” and “comprises”, and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.