Systems and methods for communicating, storing, and processing data provided by entities over a blockchain network

Abstract

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

Description

Technical Field

[0001] The present invention generally relates to a cryptographically enforced data recording and processing system. In particular, the present invention relates to a technical solution for communicating, recording and / or storing data provided to the system by an entity via or through a blockchain network. The data may indicate, for example, a selection, choice, feedback and / or decision. The present invention provides techniques for securely storing and communicating such data between entities via a blockchain network and ensuring the integrity of the data transmitted and used after transmission. The present invention also mitigates problems associated with the identification of such data sources on the network to prevent authorized activity. The present invention is applicable to (but not limited to) voting, electronic feedback submission or counting applications, or other legitimate applications where data integrity, source hiding, and enforcement of usage quotas or limits may be important. Background Art

[0002] In this document, the term "blockchain" is used to include all forms of electronic, computer-based distributed ledgers, including but not limited to consensus-based blockchain and transaction chain technologies, permissioned and unpermitted ledgers, share ledgers and their variants. It should be noted that other alternative blockchain implementations and protocols also fall within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger implemented as a decentralized, distributed computer-based system consisting of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and the data structure includes at least one input and at least one output. Each block contains a hash of the previous block, and the blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its creation. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom a transaction can be made.

[0004] To access the outputs of a transaction, these scripts are written using a stack-based scripting language.

[0005] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes perform work to ensure that each transaction is valid, with invalid transactions being rejected by the network. The software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true (TRUE), then the transaction is valid and can be written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must: (i) be validated by the first node to receive the transaction - if the transaction is validated, the node relays the transaction to other nodes in the network; (ii) be added to a new block; and (iii) be added to the public ledger of past transactions. Once recorded, the data in any given block cannot be altered retroactively without changing all subsequent blocks and the collusion of a majority of the network.

[0006] A transaction involves the transfer of one or more tokens from one node to another. A token may represent future control of network resources. In some cases, a token may represent an asset or value for legitimate applications.

[0007] Blockchain acts as a public ledger that can record transactions between parties in a verifiable and permanent manner. Blockchains have many properties, such as the irrevocability of information stored on the chain and the trust established through decentralized consensus, which make them suitable for use in a variety of applications. One of these applications is electronic voting. It should be noted that the term "voting system" is not limited to political or administrative settings in this article, but is used in a general sense to simply mean a system that is able to transmit, record, store, process and / or register selections, choices, decisions or parameters (i.e., votes) in some way. Therefore, the present invention relates to improved communication, storage and security of data between entities.

[0008] Many types of computer-implemented systems require that indications of choices / decisions or other data be communicated across a network so that the data can be acted upon or processed in some manner. In many cases, it is desirable to be able to enforce certain rules or criteria regarding the number of times a selection may be made. In other words, there may be a quota or limit on the number of times a selection or choice may be made. For the purposes of convenience and ease of reference only, we may refer to such a system as an "E-voting" system, but this should not be construed as

[0009] In order to limit the invention to a political or administrative environment. Alternatively, the term "data recording system" may be used to refer to

[0010] The present invention is not limited to the type or nature of the data received, recorded and stored.

[0011] A secure and reliable electronic voting system should prevent vote manipulation while protecting voter privacy (no participant other than the voter should know the voting results) and the correctness of the submitted ballots (invalid or unauthorized ballots should be excluded, while valid ballots should be counted in the final vote count). Blockchain can also find practical applications as a platform for recording and publishing author original data and information (such as feedback, opinions, comments, and evaluations). For example, feedback in the form of numerical ratings or reviews can influence consumer trust in products, services, and markets. Therefore, there may be an incentive to submit positive / negative feedback in an attempt to manipulate audience or market perception. Blockchain can provide an appropriate environment to prevent vote and feedback manipulation (e.g., modification, deletion, etc.) by allowing votes / feedback to be recorded publicly and permanently in an open distributed ledger without relying on a central authority to verify votes and feedback.

[0012] While the potential of deploying voting / feedback platforms using blockchain is attractive, many other issues (such as preventing multiple submissions of ballots, document checks, and protection of user privacy) remain to be addressed. In particular, protecting voter / commenter privacy may require anonymization during the vote / feedback submission process. While blockchain technology can provide pseudo-anonymity of transactions, interested third parties can combine publicly available information using auxiliary data (such as a shipping address required to complete a transaction) and analysis to associate a user identity with a specific address. Without appropriate precautions, data submitted and recorded on the blockchain (such as votes, selections, decisions, feedback, etc.) can be traced back to its source. The lack of anonymity can in turn have an adverse impact on the integrity of the data submission process. In other applications, it is also often desirable to conceal or hide the source of the data received by the system, as this may lead to the location of the source. Security can be enhanced by eliminating the traceability of the data source.

[0013] It would therefore be desirable to provide improved methods and apparatus for facilitating privacy-preserving submission of data across computer-implemented networks.

[0014] Such an improved solution has now been devised. Summary of the invention

[0015] The present invention may provide a computer-implemented method and corresponding system. The method / system may be described as a blockchain-implemented method / system. The present invention may be described as a security method or cryptographic method / system, or a cryptographically-implemented method / system. The present invention may provide a secure transfer of digital assets (or "resources"). Additionally or alternatively, the present invention may provide a control mechanism for controlling the transfer of digital assets.

[0016] Additionally or alternatively, the present application may describe a computer-implemented method for submitting data from an entity to a blockchain. The data may be any type of data, including (but not limited to) feedback, decisions, selections ("votes"), or comments. Additionally or alternatively, the present invention may be described as a data transmission method. It may be used to implement the transmission of data from an entity to a blockchain.

[0017] The method may be implemented at one of a plurality of (participating) nodes. These nodes may be nodes that participate in a process of submitting and / or verifying data (eg, feedback) according to various techniques described herein.

[0018] The method may include: obtaining a first key, the first key being one of a fixed set of keys assigned to participating nodes eligible to submit data of an entity; generating first data (r j ) to submit to the blockchain; encrypting the first data using at least the first key (r j ); and submitting the encrypted first data to a mixing service, the mixing service being used to generate a mixed transaction based on the encrypted first data and at least one other encrypted data submission from one or more qualified nodes.

[0019] In some implementations, the first key may be a first key share (k j ), the first key share (k j ) is one of multiple key shares assigned to the qualified participating nodes and used to collaboratively construct the private key (k).

[0020] In some implementations, the first data (r j ) can use the first key share (k j ) and a public key associated with the entity encryption.

[0021] In some implementations, the method may further include: using a public key associated with the entity Encrypt the first key share (k j ); cooperate with other qualified participating nodes to use the first key share (k j ) generates a secret (kG); and the encrypted first key share (k j ) and the generated secret (kG) are provided to an entity node associated with the entity for use in verifying the first key share (k j )’s effectiveness.

[0022] In some implementations, the secret (kG) may be collaboratively generated based on a secret share merging process.

[0023] In some implementations, the first data (r j ) can contain alphanumeric strings.

[0024] In some implementations, the first data (r j ) may include the concatenation of a comment string and a second string containing a public key associated with the entity at least a portion of.

[0025] In some implementations, the first data (r j ) may also include a third string identifying a service provided by the entity.

[0026] In some implementations, obtaining the first key may include receiving the first key share (k j ).

[0027] In some implementations, the first key share can be received from the entity in response to transferring a token to an entity node associated with the entity to obtain a service provided by the entity.

[0028] In some implementations, the first data (r j ).

[0029] In some implementations, the first key (k i ) may be a first public key associated with the entity The first public key is one of a first set of node-specific public keys generated by the entity and distributed to the eligible participating nodes, each of the public keys in the first set having a corresponding private key retained by the entity.

[0030] In some implementations, the hybrid transaction can specify a first quantity of tokens to be transferred to the entity, the first quantity being dependent on a quantity of encrypted data submitted by the entity included as input in the hybrid transaction.

[0031] The present application also describes a computing device for executing the method, wherein the computing device is one of a plurality of participating nodes and includes at least one processor, a memory, a network interface providing a network connection, and a blockchain application including processor executable instructions.

[0032] When the processor-executable instructions are executed, the processor performs the operations of one or more methods described herein.

[0033] The present application also describes a non-transitory processor-readable medium storing processor-executable instructions for participating in a process of submitting an entity's fortune to a blockchain, wherein when the processor-executable instructions are executed by a processor in one of a plurality of participating nodes, the processor is caused to perform the operations of one or more methods described herein.

[0034] This application describes systems and methods for secure, cryptographic implementation and efficient implementation of schemes that facilitate encryption, verification, and broadcasting of data items submitted by users to a blockchain. In some useful applications, users may be participants in a voting or feedback platform. In some implementations, this application provides protocols designed to prevent data submission from malicious actors. This can maintain the integrity and reliability of the results generated by the system based on the received data. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Any features described with respect to one aspect or embodiment of the invention may also be used in one or more other aspects / embodiments. These and other aspects of the invention will become apparent and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0036] Figure 1 An example blockchain network of nodes is shown;

[0037] Figure 2 A schematic diagram showing a commitment channel established between a participating node and an entity node;

[0038] Figure 3 An example method for submitting data (e.g., feedback from an entity) to a blockchain according to an embodiment of the present application is shown in the form of a flowchart.

[0039] Figure 4 A schematic diagram showing an example process for decrypting encryption of data (eg, feedback submissions) is shown.

[0040] Figure 5 Another example method for submitting data (e.g., feedback from an entity) to a blockchain according to an embodiment of the present application is shown in the form of a flowchart.

[0041] Figure 6 An example blockchain node is shown in block diagram form. DETAILED DESCRIPTION

[0042] In the present application, the term “and / or” is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements individually, in any subcombination or all the elements, and does not necessarily exclude additional elements.

[0043] 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 listed element alone, any subcombination, or all elements, without necessarily excluding any other elements, and without necessarily requiring the presence of all elements.

[0044] Now for illustration purposes only, we provide an example of how to implement the present invention. In our example, the present invention is implemented as a feedback submission platform, but this is purely a convenient example of how the present invention can be practiced and is not intended to be limiting.

[0045] In this application, the term "entity" refers to any entity that receives or is capable of receiving data (e.g., feedback in the form of reviews, ratings, evaluations, opinions, votes, etc.). An "entity" may additionally or alternatively refer to a representative who 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 product manufacturer), a representative of an organization (such as a customer service department of a company that collects and publishes customer reviews), or a person (such as a political candidate, employee, etc.). In the context of the data submission protocol described herein, an entity may be represented by one or more nodes in a blockchain network. In some cases, an entity may request voters or users of its products to participate in the vote / feedback submission process. When an entity's data (e.g., votes / feedback) is submitted (by users representing participating nodes), the entity is able to verify the validity of the data and simultaneously publicly disclose the submission by broadcasting it on the blockchain ledger while maintaining the anonymity of the data source.

[0046] In this application, "Reviewer" refers to an organization or individual who submits data (including, but not limited to, reviews) for an entity. For example, a reviewer can be a participant in the blockchain-based data submission protocol (BDSP) disclosed herein. Alternatively, the phrase blockchain-based feedback submission protocol can be used.

[0047] (Blockchain-based Data Submissions Protocol, or BFSP for short). A “Reviewing Node” is a node (in a blockchain network) associated with a specific reviewer, while a “Participating Node” is a node associated with a reviewer who participates in a verification or feedback submission process (such as the BDSP of the present invention).

[0048] First reference Figure 1 , Figure 1An example blockchain network 100 associated with a blockchain is shown in block diagram form. A blockchain network is a peer-to-peer open membership network that anyone can join without invitation or consent from other members. Distributed electronic devices running an instance of a blockchain protocol (under which the blockchain network 100 runs) can participate in the blockchain network 100. Such distributed electronic devices can be referred to as nodes 102.

[0049] The electronic devices that run the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including, for example, computers (e.g., desktop computers, laptops, tablet computers, servers), mobile devices (e.g., smartphones), wearable computers (e.g., smart watches), or other electronic devices.

[0050] The nodes 102 of the blockchain network 100 are connected to each other using suitable communication technologies, which may include wired and wireless communication technologies. In many cases, the blockchain network 100 is at least partially implemented through the Internet, and some individual nodes 102 may be located in geographically dispersed locations.

[0051] Nodes 102 maintain a global ledger of all transactions on the blockchain. The global ledger is a distributed ledger, and each node 102 can store a complete copy or a partial copy of the global ledger. Transactions of nodes 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. One of ordinary skill in the art will understand the details of implementing and operating a blockchain network.

[0052] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how and by whom the outputs of the transaction can be accessed. The output of a transaction can be an address to which the value is transferred as a result of the transaction. These tokens are then associated with that output address as available transaction outputs. Subsequent transactions can reference that address as an input in order to transfer those tokens to one or more other addresses.

[0053] While these transactions are pseudo-anonymous (since no personal information is included in transactions on the blockchain ledger), token transfers in a chain of transactions can be tracked, and in some cases, tokens can be linked to individuals using external data. To improve anonymity, mixing transactions can be used to pool inputs from various sources, and then the pooled tokens are divided and assigned to outputs. If all inputs and outputs are the same size, it is difficult to associate a specific input with a specific output. However, in such a transaction, at least one participating node knows the link between the input address and the output address specified by another participating node.

[0054] Some other anonymization techniques, such as ring signatures or stealth addresses, are used to try to avoid exposing the link between inputs and outputs, with varying effectiveness. Stealth addresses attempt to unlink the output address to which a specific user sent tokens. Ring signatures attempt to make the source untraceable by making it possible for any one of a set of possible signers to have signed / authorized a specific transaction.

[0055] The present invention provides a data submission protocol based on blockchain. In some embodiments, it can be described as a feedback submission protocol. For ease of explanation, the term "feedback" can be used instead of "data", but it is not intended to be limiting. More specifically, a protocol for submitting feedback using a blockchain ledger is disclosed. Participants of the protocol anonymously submit their feedback (e.g., comments) on products, services, entities, etc. to a specific entity. The feedback submission itself is encrypted and transferred to the entity through a blockchain transaction created by the feedback submitter (e.g., commenter). After receiving the 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 third party and includes a mechanism to prevent qualified participants from making multiple different feedback submissions and to prevent unqualified participants from participating in the process. Feedback submissions are anonymized by obscuring the connection between the feedback of the submitted entity and the participant who submitted the data (e.g., feedback). In particular, a mixing service (such as a transaction output shuffling process) is used to generate a mixed or joint blockchain transaction that decouples the input (of the participant) from its output (i.e., the entity receiving the feedback) address.

[0056] The proposed data submission protocol enables entities to authenticate submitted data to ensure that only submissions from qualified participants (such as approved users 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 submission (and verification)), promotes the anonymization of data, correctly delivers data to relevant entities, and incentivizes entities to undertake the task of verifying data submissions and publicly disclosing qualified data on the blockchain.

[0057] In the proposed data submission protocol, each data submission is included in a blockchain transaction that transfers tokens to the entity receiving the data. In particular, commentators participating in the protocol transfer ("pay") a fixed number of tokens to be able to submit their data. This "submission fee" is collected by the relevant entity (or data validator) after the data is successfully broadcasted on the blockchain. Thus, an entity receiving data (e.g., the data being commented on) is able to receive an amount of tokens proportional to its data share as a "reward" for validating the data submission and disclosing eligible data on the blockchain. Multiple transfer transactions containing data submissions can be combined to form a single transaction with one or more outputs (corresponding to the entities receiving the submitted data), thereby improving privacy by obfuscating the connection between the data and its source.

[0058] In the description of this article, the terms "Participating Node", "Candidate Node", "Input Address", and "Output Address" may be used. References to a node "address" are not meant to refer to the network address of a physical node. Rather, an "address" is an address specified in a transaction on a blockchain with a token allocation, and a physical node can claim ownership of that address by possessing a key corresponding to a transaction signature. In this sense, an "output address" is not the address of a participating node, but rather the address of a blockchain transaction output owned by or associated with a participating node. Similarly, an "input address" is the address of an available transaction output owned by or associated with a participating node.

[0059] As described above, the blockchain-based data submission protocol of the present invention is also suitable for use in an electronic voting (i.e., electronic vote submission) environment. Therefore, any discussion of "feedback" and feedback submission protocols in the specification will be understood to also apply to "voting" and voting protocols. In addition, the terms "rating" and "review" can be used interchangeably throughout the specification and will be understood to refer to feedback in an appropriate format (e.g., numeric rating, text, etc.) submitted to an entity by a reviewer (i.e., a verifier).

[0060] Secret Sharing

[0061] In a "Secret Sharing" scheme, a secret k is divided among n parties such that at least t+1 of the n parties need to collaborate to reconstruct k. Any subset of the n parties can reconstruct the secret k, as long as the cardinality of the subset is greater than a specified threshold t. If the cardinality of the subset is less than or equal to t, no information about the secret k is leaked. The distribution of key shares between the parties can be done using a central dealer who distributes the key shares, or it can be done through a dealer-free distribution system. Each solution has its pros and cons, and the requirements of the implemented system need to be carefully considered when choosing a distribution method.

[0062] In the data submission protocol of the present invention, the commentator can use the key shares k1, k2, k3, ... k of the key k. n to demonstrate membership in an accredited group or to demonstrate eligibility to participate in the agreement.

[0063] In some implementations, the secret sharing scheme may include embedding the secret into a t-degree polynomial. Any secret x is stored as a point f(0) in the t-degree polynomial f(x), and player i can calculate his share f(x i ). If t+1 of the n parties cooperate, they can use Lagrange Polynomial Interpolation to calculate the value of the key x using their respective shares x1, x2, …, x n Reconstruct any point on f(x) with these shares corresponding to f(x1),f(x2),…,f(x n ). Lagrange polynomial interpolation tells us that the t-order function f(x) can be reconstructed using t+1 points, p = {(x1,f(x1)),(x2,f(x2)),…,(x t+1 ,f(x t+1 ))},Right now

[0064]

[0065] in b i,p (x i )=1, and b i,p (x j )=0.

[0066] One element of a secret sharing scheme is the determination of x×G, where x is the secret key and G is a point on an elliptical curve. If f(x) is a polynomial of degree t, the secret x can be obtained by x=∑ i∈π b i,π k i Interpolation, where π is the fraction x a ,xb ,…,x t ,x t+1 π is a group of t+1 participants who collaborate to compute x×G without revealing their respective shares x i . x is the point x = 0 on the t-degree polynomial. To calculate x×G:

[0067] Each participant i calculates part b i,π x i ×G, and

[0068] All participants in π add their parts together (reconstructing the secret x via Lagrangian interpolation), giving:

[0069] b a,πxa ×G+b b,πxb ×G+…+b t+1,πxt+1 ×G=x×G

[0070] The process of calculating Q=x×G is called “Secret Share Joining”.

[0071] Commitment Channel

[0072] Various blockchain technologies may sometimes use "commitment channels" in the construction of pairwise transactions between network nodes. Commitment channels are designed to allow nodes to conduct multiple transactions without submitting all of them to the blockchain. Once a commitment channel is established between a pair of nodes, the nodes can participate in any number of transactions in a given period of time, and ultimately only two transactions are added to the blockchain. Therefore, the use of commitment channels can reduce the number of transactions that need to be added to the blockchain and reduce the associated transaction costs. Commitment channels also provide the transferor node with the flexibility to return tokens if the transferee node does not meet certain criteria, or if the transferor or transferee node decides to end the process after a certain set of transfers.

[0073] In at least one embodiment of the committed channel implementation, a pair of network nodes U A and U B Collaboratively generate three blockchain transactions: Commitment Transaction (T C ), return transaction(T r,0 ) and transfer transactions (T t ). Figure 2 The transferor node U A and the transferee node U B The commitment channel U A →U B Schematic diagram of commitment transaction T CRepresents the commitment component of a commitment channel in which the transferor U A Send / promise a specified set of tokens x to be transferred to U B In some embodiments, the commitment transaction may be a 2-to-2 multi-signature Pay-To-Script-Hash (P2SH) transaction. Return Transaction T r,0 If the transferee node U B If the established criteria for the committed transaction cannot be completed within the specified time, the previously committed token x will be returned to U A After nLockTime expires at a specific time point, the return transaction is eligible to be submitted to the blockchain. In order to successfully execute the return transaction, the transferor node U A and the transferee node U B Both signatures. Transfer transaction T t is the actual sending of the promised token x to the transferee node U B Only when the transferee node U B The transfer transaction is executed only when certain criteria are met. For example, in order for the transfer transaction to be successfully submitted to the blockchain, it may be necessary for at least the transferee node U B digital signature.

[0074] Data submission protocol based on blockchain (BFSP)

[0075] This application describes methods and systems for submitting (or "transmitting") data for entities using blockchain. In particular, this application proposes a data submission protocol (blockchain-based data submission protocol, or BDSP) that leverages blockchain concepts to allow reviewers to submit data anonymously and record the data publicly and permanently on a distributed ledger. BDSP aims to decouple data from reviewers or other data sources that submit data, and only allow "approved" reviewers to accept / consider disclosure of their data. By facilitating the public disclosure of feedback on the blockchain, BDSP can help prevent entities and / or third parties from manipulating data (such as feedback and / or voting, ratings, etc.). In addition, BDSP also encourages entities that receive reviewer data to take on the task of verifying the validity of data submissions and broadcasting qualified data on the blockchain.

[0076] BDSP includes multiple participant nodes (corresponding to reviewers) and at least one entity node (corresponding to an entity that receives or is capable of receiving data such as reviews, ratings, etc.). More specifically, BDSP is applicable to a node that wishes to provide a user with a user-friendly interface for one or more entities C1, ..., C n Two or more reviewers U1,…,U providing data nFor example, a reviewer may be a voter who votes for one of a set of candidates, or a member of a group who provides reviews for one or more other members. Alternatively, a reviewer may be a customer of a service provider or product manufacturer who has been granted explicit permission to submit reviews of a particular service or product. As previously discussed, to participate in a BDSP and submit data for one of these entities, a reviewer may be required to transfer a fixed number of tokens to the entity to which the data is directed. The transfer of tokens represents a reward to the relevant entity (or data validator) for checking and broadcasting the data submission.

[0077] Reference now Figure 3 , Figure 3 An example method 300 for submitting an entity's data to a blockchain is shown in the form of a flow chart. The method 300 may be performed, for example, by one or more participating nodes participating in a BDSP. As described above, a plurality of nodes corresponding to a plurality of commenters ("participating nodes") and one or more entities ("entity nodes") participate in the BDSP. In some implementations, each node is a wallet or other such blockchain entity.

[0078] For simplicity, the following description of BDSP uses the example of multiple reviewers submitting data for a single entity. As described below, the reasoning easily extends to the data submission process for multiple entities. That is, the use case of BDSP submitting data for a single entity is easily generalized to submitting data for multiple different entities.

[0079] Method 300 is performed by a blockchain network (such as Figure 1 The method 300 is implemented as a node in the blockchain network 100 of the BDSP. At operation 302, the method 300 begins with a node joining the process of submitting feedback for a particular entity. The joining step can be implemented in a decentralized manner or by a central authority that assembles a group of suitable participating nodes based at least in part on ensuring that a sufficient number of nodes are included in the group to allow anonymization of the submitted data. For example, before launching the BDSP, three or more participating nodes may need to join to ensure that no individual (i.e., reviewer, candidate, third party) can directly identify the source of any submitted feedback (except for the feedback they themselves have submitted). In some embodiments, multiple reviewers can be combined to collaboratively participate in the BDSP.

[0080] In operation 304, the node obtains a first key, where the first key is one of a fixed set of keys assigned to participating nodes that are eligible to submit data (e.g., feedback) to an entity. The fixed set of nodes participating in the protocol effectively agrees on a key that allows access to the data submission process. In some embodiments, the participating nodes participate in a secret sharing process (e.g., a dealer-free scheme) to distribute key shares k1, k2, ..., k n, the key share can be used to collaboratively construct the secret k. That is, the first key obtained by the node can be the first key share k of the group private key k j , where the first key share k j It is one of the multiple key shares assigned to eligible participating nodes. In this way, the reviewer himself has a certain degree of control over other reviewers who are approved to participate in the BDSP.

[0081] In operation 306, the node generates data of the entity (eg, feedback r j ) to submit to the blockchain. Feedback j The format can be adapted to different protocol requirements. Feedback j This can be, for example, a simple numeric 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 j is an alphanumeric string, such as

[0082] review=r j =useful000062727hj9

[0083] Sample Feedback j The second string may include a comment string ("Helpful") concatenated with a second identifiable string ("000062727hj9"). In some cases, the second string may include an identifying feedback string. j For example, the second string may include a first number l of characters from the entity public key and a second number p of characters from the commenter's key share. The second string may be padded with an escape sequence (e.g., a set of 0s) that separates the comment string from the commenter entity information.

[0084] In operation 308, the feedback r is encrypted using at least the first key obtained by the node in operation 304. j For example, feedback r j The key share k of the group private key k can be used j In some embodiments, encryption is performed using a public key associated with the entity and the commenter's key share k j To encrypt feedback r j As part of the BDSP, each entity (or the entity's feedback verifier) ​​may be provided with a public-secret key pair The public key associated with the BDSP entity can be distributed to participating reviewers and used to encrypt feedback submissions. Encrypting feedback using the entity's public key j Helps ensure that only interested entities can decrypt and access feedback.

[0085] In some cases, an entity may wish to verify the validity of the key shares that reviewers used to encrypt their respective feedback. For example, an entity can use existing solutions (such as Verifiable Secret Sharing (VSS) or Publicly Verifiable Secret Sharing (PVSS) schemes) to verify that the key shares of participating reviewers are consistent with the encrypted "secret". To facilitate this share verification process, reviewers in the BDSP can encrypt their key shares using the public key associated with the entity of their choice and collaborate with other qualified reviewers to generate a secret kG using their key shares. For example, the secret kG can be generated using a secret share merging process. The encrypted key shares and the generated secret can then be provided to the entity for verification of the validity of the key shares. For example, the (encrypted) key shares of reviewers for a particular entity can be anonymously aggregated as part of the BDSP and made accessible to the entity.

[0086] Use the commenter's key share k j and the entity's public key Feedback j An example of encryption is as follows:

[0087]

[0088] in Represents the exclusive or (XOR) between two strings.

[0089] Figure 4 A schematic diagram is shown showing the process of decrypting a feedback submission encrypted using the above example scheme (A). j The encryption is done by entity C i Decrypt it using its private key, thus converting C i Identified as feedback j In step 404, by calculating the decrypted data from step 402 and the corresponding commentator's key share k j The encrypted feedback submission is further decrypted by XORing the key shares of the reviewers who are eligible to submit feedback for the entity. As part of the BDSP, the key shares of the reviewers who are eligible to submit feedback for the entity can be collected (for example) anonymously from qualified reviewers and made accessible to the entity. The entity will be able to obtain the feedback r in step 304 by performing the following operation j ,

[0090]

[0091] Feedback jThis "double encryption" - first using the key share k j , then use the public key - Allows for a double check of the correctness of the data. Specifically, the entity can first decrypt the data using its public key and then verify the feedback provided r j Encrypted commenters are indeed eligible to participate in the BDSP (i.e. submit feedback to the entity).

[0092] return Figure 3 In step 310, the node submits the encrypted feedback submission to the hybrid service. The hybrid service is used to j The encrypted and at least one other encrypted feedback from one or more other eligible participating nodes is submitted to generate a hybrid blockchain transaction. j The encryption of feedback can be included in a transaction that transfers a fixed number of tokens to the entity to which the feedback is directed, and two or more such transactions (including encrypted feedback submissions from at least one other reviewer participating in the BDSP) can be combined into a single joint transaction. For example, a token mixing solution can be used to combine the transfer transactions. In some token mixing solutions, a set of participants each contributes to one of the inputs of the joint transaction and provides an output address for the output of the joint transaction. A token "shuffling" solution can be implemented at the BFSP to decouple the output address of the joint transaction from the participants who participated in the transaction input. This "shuffling" technique can help to obfuscate the connection between submitted feedback and its source (i.e., the reviewer) while still using blockchain transactions to transmit encrypted feedback data. A joint transaction transfers a certain number of tokens to a specified entity, where the total number of tokens transferred depends on the number of (encrypted) feedback submissions included in the transaction as input.

[0093] In BDSP, the encrypted feedback submission can be included as a data element in the script associated with the transfer transaction from the participating node to the relevant entity. The encrypted feedback submission can be used with the operation code OP_RETURN <data>This opcode can be stored as data in the script, with up to 40 bytes of data, or alternatively, as metadata in the output script of an m-out-of-n multisignature scheme. For example, in a two-out-of-three multisignature script, of the three data elements reserved for the public key, two can be used for the public key and one is used to store the encrypted feedback submission:

[0094]

[0095] in Represents the metadata corresponding to the encrypted feedback submission that the reviewer wishes to be stored in the transaction.

[0096] Blockchain transactions in BDSP for transferring encrypted feedback and tokens to related entities can be constructed using commitment channels. More specifically, from commenter U i To the designated entity C i Transferring encrypted feedback submissions and tokens can be effected by a combination of three transactions: Commitment Transaction T C 、Return transaction T r,i , and transfer transaction T t . Transaction T C Represents the commitment section of the Feedback Submission Agreement. Commenter U i Submit a specified amount of tokens x to be transferred to an output managed by either: i and entity C i Signed two-thirds of the multi-signature script, or knowing the (decrypted) feedback r j and C i Two-thirds of the multi-signature script of the signature. Feedback j The encryption of is submitted as metadata in the multi-signature script. The commitment transaction can be viewed as a commentator U i Input to a hybrid (federated) blockchain transaction between a collection of participating nodes in a BDSP and one or more entity nodes.

[0097] BDSP proposes a transaction T r,i There are two possible variations. In the first version T r,1 In the transaction T C The submitted token x is returned to the commenter U i Predefined return address. To prevent traceability of token movement, the return address is chosen to be different from the one used by the commenter U i The return of tokens may be affected if a submitted feedback submission is not properly broadcast on the blockchain within a predetermined period of time. This can occur if the entity is unable to decrypt the feedback submission because the reviewer is malicious and does not have the credentials to access the feedback, or if the entity (or review validator) simply decides not to broadcast the feedback and receive a transfer of the associated tokens.

[0098] Returns an alternative version of the transaction T r,2 In the process, a number of tokens equal to x / n (where n is the number of reviewers participating in the BDSP) are transferred to all participating reviewers after the expiration of a specified period of time. This procedure can be seen as a penalty for reviewers who submit false feedback (e.g., reviews that cannot be decrypted by any entity or reviews that were not transferred by qualified reviewers).

[0099] Transaction T t is to transfer x tokens from commenter U i Transfer to Entity C i In order for the transaction to be successfully executed, the (decrypted) feedback r j and entity C i The transfer transaction can be regarded as the output of a joint transaction formed between a participating node in the BDSP and one or more entity nodes.

[0100] In some implementations, reviewers may submit their feedback to a third-party entity that is independent of the relevant entity to which the feedback is directed. In particular, reviewers may wish to provide their opinions on products, services, etc. provided by certain entities without these entities influencing or deciding whether to publish the submitted feedback. For example, reviews may be submitted to operators of third-party review platforms (such as online forums, media channels, industry regulators, etc.) that are independent of the reviewed entity through hybrid blockchain transactions in BDSP, so that the submitted reviews (whether positive or negative) can be broadcasted through the blockchain without being influenced or interfered with by the relevant reviewed (or evaluated) entity.

[0101] Reference now Figure 5 , Figure 5 Another example method 500 for submitting data (such as feedback) of an entity to a blockchain is shown. The method 500 is performed by a blockchain network (such as Figure 1 The method 500 may be implemented by a (participating) node in a blockchain network 100 of the embodiment of the present invention. In some cases, the method 500 may be applicable to a system / platform for reviewing products and services provided by manufacturers and / or service providers. For example, the method 500 may be incorporated into a feedback submission platform of an online marketplace. The entity providing the product / service may, based at least in part on the operation of the method 500, use transactions recorded on the blockchain to grant previous customers permission to submit their reviews publicly and anonymously.

[0102] Operations 502, 506, and 510 of method 500 are similar to those of reference Figure 3 Operations 302, 306, and 310 of the described method 300 will not be discussed in detail. The participating node joins the feedback submission process implemented as part of the BDSP in operation 502. In operation 504, the node obtains a first key, which is one of a fixed set of keys assigned to nodes that are eligible to submit feedback for an entity. The first key may be a first key share k of a private key k. j Specifically, the entity (or a representative of the entity) can assign key shares k1,…,k n Assigned to users who receive its products / services for feedback encryption and verification. Key share k j Can be released to a reviewer (i.e., user / client), for example, in response to receiving a transaction (e.g., transfer of a token) or payment for a service provided by the entity to the reviewer / user / client (e.g., the key share can be encrypted using the user / client's public key). Alternatively, the entity can generate a collection of public-private key pairs, one for each qualified or approved reviewer, rather than assigning a user / client their public key and a single key share. That is, entity C i A set of node-specific keys may be generated for a set of approved users / clients, where

[0103]

[0104] and secretly pass the public key Sent to the appropriate reviewers.

[0105] In operation 506, the node generates feedback r of the entity j to submit to the blockchain. Feedback j The format of may be similar to the format described with reference to operation 306 of method 300. In the specific context of method 500, the feedback r j Might additionally include a string identifying the product / service provided by the entity and reviewed by the user / client. j It can be in the following forms:

[0106] review=r j =useful000062727hj9#productID

[0107] In operation 508, feedback r j is encrypted before being sent to the entity to which the feedback is directed. The above encryption scheme (A) may be applied in operation 408. That is, the commenter may calculate the (off-chain) feedback r j Encryption,

[0108]

[0109] in represents the XOR between two strings. Alternatively, if the entity has generated node-specific public-private key pairs for qualified commenters, then this can be done simply by using the entity's node / user-specific public key To encrypt feedback r j The encrypted feedback can be computed off-chain by the reviewer, whereby the entity retains the corresponding decryption key, allowing the entity to obtain the feedback.

[0110] In operation 510, the encrypted feedback is submitted to the mixing service to generate a joint transaction to be recorded on the blockchain. As described above, the entity being reviewed can verify the validity of the feedback submission by checking whether the feedback was submitted by a qualified / approved reviewer (e.g., verifying that the reviewer possesses a valid key share of the group private key of the approved group). The entity can decrypt the encryption of the feedback and then broadcast the feedback on the blockchain. The verification and broadcast of the submitted feedback is then a prerequisite for the entity to receive the token transferred by the reviewer as part of the feedback submission transaction.

[0111] Reference Figure 6 , Figure 6 A simplified example of a participating node 600 is shown in block diagram form, which in the context of the present invention may 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 also includes a memory 604 and a network interface 606, which may include persistent and non-persistent memory to store values, variables, and in some cases processor executable program instructions, and a network interface 606 that provides network connectivity via a wired or wireless network.

[0112] Participating node 600 includes a processor-executable blockchain application 608 that includes processor-executable instructions that, when executed, cause processor 602 to perform one or more functions or operations described herein.

[0113] It should be understood that the devices and processes described herein and any modules, routines, processes, threads, applications, or other software components that implement the methods / processes for configuring blockchain nodes can be implemented using standard computer programming techniques and languages. The present application is not limited to a specific processor, computer language, computer programming convention, data structure, or other such implementation details.

[0114] It should be noted that the above embodiments illustrate rather than limit the present invention, and those skilled in the art will be able to design many alternative embodiments. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. The words "comprising" and "comprises" etc. do not exclude the presence of other elements and steps as a whole, even though these elements and steps are not listed in any claim or specification. In this specification, "comprises" means "includes or consists of...", and "comprising" means "including or consists of...". The singular reference of an element does not mean to exclude the plural reference of these elements, and vice versa. The present invention can be implemented by means of hardware comprising several different elements, and by means of a suitably programmed computer. In a device claim that lists several ways, several of these ways can be embodied by the same component of hardware. The fact that certain measures are listed in mutually different dependent claims does not indicate that the combination of these measures cannot be used advantageously.< / data>

Claims

1. A computer-implemented method comprising: Obtain a first key, wherein the first key is a key in a fixed key set assigned to a node, wherein the node is a node that is qualified to submit data of an entity to a blockchain, wherein the first key is a first key share (k) of a private key (k) j ), the first key share (k j ) is one of a plurality of key shares assigned to one or more eligible nodes and used to collaboratively construct the private key (k); Generate the first data of the entity (r j ) to submit to the blockchain; Encrypting the first data using at least the first key j );and The encrypted first data is submitted to a mixing service, the mixing service being configured to generate a mixing transaction based on the encrypted first data and at least one other encrypted data submission from one or more qualified nodes.

2. The method according to claim 1, wherein: The first data (r j ) using the first key share (k j ) and a public key associated with the entity encryption.

3. The method according to claim 2, further comprising: Using the public key associated with the entity in question Encrypt the first key share (k j ); Cooperate with other qualified nodes to use the first key share (k j ) generates a secret (kG); and The encrypted first key share (k j ) and the generated secret (kG) are provided to an entity node associated with the entity for use in verifying the first key share (k j )’s effectiveness.

4. The method according to claim 3, wherein: The secret (kG) is collaboratively generated based on a secret share merging process.

5. The method according to claim 1, wherein: The first data (r j ) includes alphanumeric strings.

6. The method according to claim 5, wherein: The first data (r j ) comprises the concatenation of a data string and a second string containing a public key associated with the entity at least a portion of.

7. The method according to claim 6, wherein: The first data (r j ) also includes a third string identifying a service provided by the entity.

8. The method according to claim 1, wherein: Obtaining the first key includes receiving the first key share (k j ).

9. The method according to claim 1, wherein: The first data is encrypted using XOR encryption. j ).

10. A computing device participating in a process of submitting an entity's data to a blockchain, the computing device comprising at least one processor, a memory, a network interface providing a network connection, and a blockchain application containing processor-executable instructions, which, when executed, cause the processor to perform the method of any one of claims 1 to 9.

11. A non-transitory processor-readable medium storing processor-executable instructions for participating in a process of submitting an entity's data to a blockchain, wherein: When the processor-executable instructions are executed by a processor, the processor is caused to perform the method according to any one of claims 1 to 9.

Images