Blockchain-based anonymous cryptographic voting method and system

Abstract

Embodiments of the present application relate to anonymous cryptographic voting methods and systems based on blockchain. A system can facilitate voting (e.g., blockchain-based) recorded based on distributed ledger technology (DLT). Nodes configured to support a voter role can access DLT records to determine answers and / or parameters for a vote. An organizer of a vote can provide a voter token to a voter, which grants the voter a voting value. A voter can distribute the voting value to answers using a commitment token that binds the voter to a particular voting value without leaking the particular voting value when in cryptographic form. A voter can distribute the commitment token to multiple answers. In some cases, distributing the commitment token to multiple answers can foil attempts to determine one or more targets to which the voter delivered a non-empty voting value.

Description

[0001] Divisional Application Instructions

[0002] This application is a divisional application of Chinese invention patent application No. 201980022265.2, entitled "Anonymous Cryptographic Voting Method and System Based on Blockchain", which was filed internationally on January 25, 2019, entered the Chinese national phase on September 25, 2020.

[0003] Priority requirements

[0004] This application also claims priority to U.S. Patent Application Serial No. 16 / 212,026, filed December 6, 2018, entitled “Blockchain-Based Anonymized Cryptoologic Voting”. This application also claims priority to Russian Patent Application Serial No. 2018103253, filed January 29, 2018, entitled “Electronic Voting and Verification in an e-BallotVoting System”. Technical Field

[0005] This disclosure relates to blockchain-based cryptographic voting. Background Technology

[0006] Driven by enormous customer demand, the rapid development of electronic and communication technologies has led to the emergence of complex verifiable ledger systems. Improvements in the hardware and software implementations of the underlying processing of verifiable ledger systems will enhance their security, reliability, and speed. Attached Figure Description

[0007] Figure 1 An example voting environment is shown.

[0008] Figure 2 It shows Figure 1 The example voting environment illustrates the interaction flow within that environment.

[0009] Figure 3 An example of anonymous cryptographic voting logic is shown.

[0010] Figure 4 An example of voting organization logic is shown.

[0011] Figure 5 Example voting audit logic is shown.

[0012] Figure 6 An example voting logic execution environment is shown.

[0013] Figure 7An example organizational logic execution environment is shown.

[0014] Figure 8 An example audit logic execution environment is shown.

[0015] Figure 9 An example mediated voting environment is shown.

[0016] Figure 10 The example of the compilation logic for mediator voting values ​​is shown. Detailed Implementation

[0017] Distributed ledger technology (DLT), powered by blockchain and other cryptographic structures, provides a platform for recording transactions and preventing subsequent tampering of these records. In voting systems, including private organization voting (e.g., shareholder votes, member votes, employee votes, or other private organization elections), surveys, polls, or other question-and-answer systems, DLT allows for verifiable records (e.g., virtual paper signatures), including situations where elections are conducted remotely (e.g., via telecommunications networks). Furthermore, digital signatures and other digital identity technologies allow for the secure identification of voters, voting organizers, and / or auditors.

[0018] In some cases, implementing DLT can allow for unsecret voting. Unsecret voting (e.g., submitting answers within a voting system) may be feasible in certain voting systems. For example, the identity of a single voter can be part of a public record.

[0019] In certain circumstances, secret voting can be performed on verifiable DLT records. The techniques and architectures discussed below provide verifiable DLT records while maintaining the anonymity of voters (e.g., through pseudonyms or other obfuscation). These techniques and architectures enhance the privacy of verifiable DLT voting by using tokens (e.g., commitment tokens, range proof tokens, voter tokens, organizer tokens, result tokens, validity tokens, or other tokens), identifiers, and / or other cryptographic primitives to hide the true identity of voters and obscure the content of individual votes. These techniques and architectures enhance the security of secret voting by providing a distributed ledger (e.g., backed by cryptographic structures) that can be audited by nodes under the control of voters, organizers, and / or third parties. Thus, stakeholders can later verify the accuracy and validity of votes made under these techniques and architectures. Invalid or tampered results may be rejected. In some cases, auditors can record their vote proofs in the DLT record, further enhancing the security and confidence of the voting system. These techniques and architectures improve the efficiency and flexibility of secret voting by using one or more of the aforementioned cryptographic primitives and / or cryptographic structures that can run in local or networked computer environments. Therefore, the environment implementing the example provides improved efficiency by preserving the confidentiality and secure identity of the vote, without requiring actual travel or gathering of participating parties. In summary, the technologies and architectures discussed (including tokens, identifiers, distributed ledgers, and cryptographic structures) offer technical solutions to the technical challenges of increasing the privacy, security, efficiency, and flexibility of voting systems. Thus, the technologies and architectures discussed provide an improvement over existing market solutions.

[0020] Figure 1 An example voting environment 100 is illustrated. In example environment 100, node 102 stores (e.g., all or part) DLT records 104 in memory, such as a distributed ledger stored as a blockchain or other cryptographic structure. Node 102 can form a distributed network by redundantly storing DLT records 104 and reaching consensus on transactions and updates published to the DLT records. Various sequencing consensus mechanisms and / or DLT architectures (e.g., DLT environments) can be used. In some cases, a node may retain information about the state of the DLT records related to its transactions, and the node may not necessarily store portions of the DLT records that are beyond the relevant information.

[0021] Figure 2The example voting environment 100 and the flow of tokens, data, and interactions within it are illustrated. The token flow between nodes is shown. However, in various implementations, the token flow can be achieved through transactions recorded on a DLT record. Therefore, instead of physically transferring tokens or data representations to another node, nodes can record the transfer of token control / ownership to a DLT record. Cryptographic structures can include data blocks such as blocks, which are linked to other data blocks within the data blocks via cryptographic primitives such as hashes. For example, in a blockchain, a series of blocks can be linked and protected from data tampering by blocks in the series that include hashes of previous blocks in the series. Cryptographic primitives can include hashes, commitments, certificates, signatures, keys, identifiers, passwords, state inputs, or other cryptographic entities that can provide secure identity, data integrity, data obfuscation, or other security features.

[0022] Node 102 can represent one or more roles (e.g., voter 110, organizer 120, answerer 130, auditor 140, and / or other roles) on DLT record 104. Node 102 can adopt one or more roles via identifiers (e.g., voter identifier 112, organizer identifier 122, answerer identifier 132, auditor identifier 142, and other identifiers). In some cases, a role can be adopted by a node without any specific identifier; for example, in some cases, a node can assume the auditor role without a pre-specified identifier. In some cases, a node acting as an auditor can provide an identifier to distinguish itself from other auditor nodes or other participating nodes. Identifiers can include public keys associated with individual members of various roles (e.g., for use in asymmetric encryption algorithms).

[0023] Based on virtually any authorization system that uses authentication for assigning roles or login certificates, node 102 can function within a role, such as voter 110, organizer 120, answerer 130, auditor 140, or other roles. For example, an organizer can assign itself the organizer role and then specify the voter and answerer. In this example, an auditor could include volunteer participants and could self-assign. Other configurations can be used. When assigning / login access permissions based on roles, the node can access the role's private key (e.g., paired with the role's public key).

[0024] Organizer 120 can establish a vote 150, such as a set of answers 130 with answer identifier 132, and organizer token 124 holds the voting value of vote 150. In various implementations discussed throughout the disclosure, the vote may include, for example, a set of permitted answers for the vote and define rules for valid votes through its digital structure. Organizer can designate voters 110. Organizer can distribute the established voting value in organizer token 124 to voters via voter token 114. In various implementations throughout the disclosure, voter tokens may include a data structure that uses cryptographic primitives to transfer voting values ​​to voters. Voter tokens may be recorded in voter transactions.

[0025] Voter 110 can receive voter token 114. Voter 110 can distribute the voting value in the voter token to answer 130. In some cases, the voting value in the voter token can be binary (e.g., yes / no), integer (e.g., n votes), or fractional (e.g., the number of votes can be split according to a decimal value). In some cases, the transfer of voting value may be restricted to a specific range. For example, organizer 120 can configure vote 150 to disallow negative voting values ​​to prevent voters from awarding useless negative voting values ​​to an answer, thereby increasing the voting value that voters can award to another answer.

[0026] Voters can send their vote to the answer using a commitment token (134). Throughout the various publicly disclosed implementations, the commitment token can contain a cryptographic commitment to the vote value granted in the commitment token. This commitment does not reveal the vote value. However, any later-revealed vote value can be compared to the commitment. For example, a commitment algorithm can be applied to the revealed vote value to recreate the commitment in the commitment token. If the recreated commitment value does not match the commitment value in the commitment token, the revealed vote value can be marked as invalid.

[0027] To obfuscate which answers a voter assigns a voting value to, a voter can also assign an empty voting value to an answer (e.g., zero or other worthless voting value). For example, voter 110 may appear to send a token to every answer. However, some part of the tokens sent could be empty tokens. This can thwart attempts to determine a particular voter's answer selection by monitoring which answers 130 receive tokens from the voter.

[0028] In some implementations, homomorphic commitments can be used with commitment tokens. A homomorphic commitment is a commitment whose sum of tokens equals the sum of all tokens sent by the voter. Homomorphic commitments can support aggregated voting value verification. For example, auditor 140 can check that the sum of tokens received by answer 130 equals the sum of tokens sent by voter 110. This check can be performed without relying on knowledge of the individual votes of voter 110.

[0029] Token transfers (e.g., from organizer 120 to voter 110 and from voter 110 to the answer) can be recorded on DLT record 104 to preserve the integrity of the transaction for later verification and to create an immutable (e.g., functionally immutable) virtual paper record. For example, without the cooperation of at least a majority (e.g., one-third, half, or other portions, depending on the consensus process used by the DLT) of participating nodes, the DLT record cannot be altered without inconsistencies with data integrity cryptographic primitives (e.g., hashes, checksums, or other data integrity protection primitives). Furthermore, without widespread cooperation, nodes may maintain evidence of DLT forks. Therefore, attempts to secretly alter the voting results stored on the DLT record are likely to be thwarted by any node that alters the DLT record.

[0030] Node 102 can perform multiple roles simultaneously. For example, two separate identities (e.g., voter and organizer) can be served by a single node. Furthermore, a particular identity can serve multiple roles. For example, an organizer can be a voter and / or an answerer. An auditor can also be a voter, organizer, or answerer. Other combinations are also possible.

[0031] Alternatively or concurrently, roles can be performed by non-participant nodes. For example, a particular node may not necessarily have write privileges to the voting system's DLT records (e.g., a non-participant node). However, a particular node can represent one or more roles. A particular node can perform the tasks of a role by requesting DLT records from participating nodes. Therefore, a user performing a role may not necessarily need to log in to a node that is a participant in the DLT itself. In the example scenario, a user performing a voter role can log in to a remote terminal and perform voting by sending a message requesting a DLT transaction, rather than having the remote terminal directly attach a DLT transaction.

[0032] The following is for reference. Figure 3 , Figure 4 and Figure 5 Example logic for supporting the operations of voter 110, organizer 120, and auditor 140 is discussed. Now refer to... Figure 3 , Figure 3 An example anonymous cryptographic voting logic (ACVL 200) is shown. ACVL 200 can be implemented on circuitry such as a cryptographic voting circuit. ACVL 200 can access DLT record 104 to obtain the vote (202) that voter 110 intends to vote on. The vote can specify answer 130 by providing an answer identifier 132. The answer identifier can include the public key assigned to answer 130. The public key can allow the voter to address the commitment token 134 to the answer by encrypting the commitment token (or a portion thereof) using the public key of the answer.

[0033] ACVL 200 can also receive voter tokens (204) on behalf of the voter. The voter token can be sent by organizer 120 and is addressed to the voter's voter identifier. Similarly, the voter's public key can be used as the voter identifier. ACVL 200 can determine the number of voting values ​​granted to the voter via the voter token (206). Voting values ​​are the voting rights assigned to the voter to exercise their voting rights. Voter 110 receives voting values ​​from organizer 120 via the token. The voter can then assign the received voting values ​​to one or more answers. The voting values ​​received by the answers can be totaled to determine the winning answer based on victory conditions determined by the voting. For example, conditions may include receiving more voting values ​​than other answers (e.g., multiple voting values), receiving a majority of voting values, exceeding a defined voting value threshold, or other conditions. Furthermore, multiple conditions can be combined.

[0034] In response to voter input, ACVL 200 can determine a portion (208) of the received voting value to be committed to the target answer. For example, in a binary voting value system, ACVL 200 can commit the entire voting value to the target answer. Throughout the system, ACVL 200 can commit a discrete sum (which may be less than the whole). Once the commitment is determined, ACVL 200 can generate a commitment token that binds voter 110 to the determined voting value commitment. The commitment token 134 can implement a cryptographic commitment to bind the voter. As an illustrative example, the commitment token 134 can contain a hash of the committed voting value. In various implementations throughout the disclosure, the committed voting value can include a determined number of voting values ​​expected to be transferred in a transaction. When the transferring party generates a cryptographic commitment specifying that number, the voting value becomes a “commitment.” The cryptographic commitment prevents the transferring party from later requesting a different number for transfer. Accordingly, any party asserting that the voting value committed by ACVL 200 is a specific number can check this by hashing its assertion number. If the hash output does not match the hash in the commitment token, the assertion count is inaccurate. However, other cryptographic primitives can be used to form commitments.

[0035] In some implementations, a commitment from the homomorphic commitment class can be used instead of the hash above. A homomorphic commitment is a commitment with the additional property that the sum of two commitments is a sum of commitments, for example, commitment (a) + commitment (b) = commitment (a + b).

[0036] An example of such allocation is that a voter assigns their vote to the answer, or an intermediary assigns their vote to the voter they represent.

[0037] An example of a homomorphic commitment (C) could include:

[0038] C = aA + bB (Equation 1)

[0039] Where A is the first point on the elliptic curve (e.g., the quantity point), and B is the second point on the elliptic curve (e.g., the blind point). aA is the quantity term, and bB is the blind term. Factor a is the voting value. Factor b is the blind factor that obfuscates the voting value a. In some cases, b can be chosen randomly (e.g., pseudo-random, random, or other nondeterministic choice). In some implementations, the allowed range of b may be large, thus thwarting attempts to determine the commitment token by determining that a larger value C is more likely to have a non-zero voting value. For example, the range of b can be approximately the size of the elliptic field of the curve generated by the function G (see below). B can be determined based on A. In some cases, B can be associated with A via a hash function to thwart attempts to predict B for all A. For example, B can be determined using the following formula:

[0040] (Equation 2)

[0041] Where H is the hash function, and P is the function that transforms the hash output of H into points on an elliptic curve. Example hash functions can include the SHA256 algorithm. However, other hash functions can be used.

[0042] A can be determined using the elliptic curve generating function and the shared key k. Therefore, A can be determined by calculating the following formula:

[0043] (Equation 3)

[0044] The organizer or voting organization logic (BOL) 300 on behalf of the organizer can determine the generation function G and the shared key k. The organizer 120 can establish A and B by providing k and G and allowing participants (e.g., voter 110, answerer 130, auditor 140) to compute A and B. BOL 300 can also specify the hash function H and the function P.

[0045] Example commitment tokens using the above commitment C can include:

[0046] (Equation 4)

[0047] Where [CT] is the commitment token structure. Encryption is specified based on the identifier (e.g., public key) of the recipient of the voting value. Therefore, although the second and third fields of the example commitment token are in encrypted form (e.g., cryptographic form), the commitment token publicly binds the voter (or other voting value provider) to the committed voting value 'a', without exposing 'a' until... Decrypted.

[0048] In some cases, to further obfuscate 'a', random 'salt's can be added before applying 'C'.

[0049] AVCL can utilize the summation property of the homomorphic commitments described above in subsequent transfers of the voting value. Once a receiver has received the token, including the sender's commitment to its value 'a' and the cryptographic voting value (e.g., value 'a'), the receiver can distribute the token to two or more other receivers. The sender can use the homomorphic property to create commitments to the tokens for these new receivers. For example, for a distribution to two parts a1 and a2 (where the values ​​a1 and a2 sum to the initially received value 'a': a1 + a2 = a), the commitments to a1 and a2 sum to the commitment to 'a': Therefore, AVCL can use homomorphic properties to generate a verification sum and verify that the sum of transferred voting values ​​(e.g., the verification sum) matches the voting values ​​in the source tokens(s). In various implementations throughout this disclosure, the verification sum may include the sum of voting values ​​(or information related to the sum) in one or more tokens used to confirm that a valid number of voting values ​​have been transferred in the sum token.

[0050] Once the ACVL 200 generates a commitment token, it can request the target transaction to record the allocation of the commitment token to the target answer (210). To establish the authenticity of the target transaction, the ACVL 200 can use a cryptographic key associated with the voter's voter identifier. For example, the voter identifier may include a public key, and the cryptographic key may include a private key paired with the public key. The ACVL 200 can establish the authenticity of the target transaction by digitally signing the commitment token using the private key.

[0051] ACVL 200 can account for the target transaction (212) by subtracting the committed vote value from the vote value of the voter who received the self-voter token.

[0052] Voting systems including ACVL 200, BOL 300, and Voting Audit Logic (BAL) 400 can operate in a variety of different DLT environments. For example, voting systems can be applied to systems using unspent output transaction models, account transaction models, or other transaction models. In an example system with an unspent output transaction model, ACVL 200 can generate a pausing token (e.g., with the same structure as a commitment token) that grants the remaining voting value (e.g., the voter's voting value minus the committed voting value) back to voter 110. The remaining token can be included in the target transaction. In some cases, where the commitment token transfers all remaining voting values, the remaining token can include a token holding an empty voting value. In an example system with an account transaction model, the committed voting value can be subtracted from the account storing the voter's voting value.

[0053] In various implementations, any voting value grant token (e.g., organizer token, voter token, pause token, or other voting value transfer token) can use the structure (e.g., the structure in Equation 4 above or other token structures) and the cryptographic primitives used in the aforementioned commitment token.

[0054] ACVL 200 can include a range proof token (214) along with the commitment token in the target transaction. The range proof token can be used, for example, by a node acting as an auditor, to publicly establish that the commitment value transferred by the commitment token falls within a specified range. In some cases, the organizer can specify allowed ranges for voting value transfers. For example, negative numbers can be disallowed and / or numbers above / below a specified threshold voting value can be prohibited. The range proof token can establish that the commitment voting value is within this range without having to publicly disclose the commitment voting value. Information can be considered publicly disclosed when it is accessible without access to one or more secret (e.g., private) cryptographic keys.

[0055] Various range proofs can be implemented within a range proof token. For example, an example range proof discussed in Russian patent application serial number 2018103253, entitled "Electronic Voting and Verification in an e-Ballot Voting System," filed on January 29, 2018, which is previously incorporated herein by reference, can be used. It describes a range proof based on… An example range proof for Borromean signatures of rings, each ring having two keys (L, L'). The range proof can establish a commitment value within an allowed range, such as [0, M]. Signatures are also discussed in Maxwell, G. and Poelstra A., Borromean RingSignatures, accessible at https: / / qithub.com / - Blockstream / borromean paper / raw / master / borromean draft 0.019ade1 e49.pdf.

[0056] A range proof token, which includes a range proof of the commitment value, can be included in the same transaction in which the commitment token is transmitted. Alternatively or concurrently, the range proof token can be included in different transactions. In some cases, multiple range proofs can be generated for a single commitment token. For example, a first range proof token can establish a commitment value within [N, M], and then a second range proof token can establish a commitment value within [X, Y], where N, M and X, Y establish different ranges.

[0057] To establish the authenticity of the range proof token, ACVL can sign the range proof token using a cryptographic key associated with the voter identifier.

[0058] ACVL 200 can determine another portion (216) of the vote value used to commit to the completed answer. ACVL 200 can send tokens to multiple answers to confuse the answers chosen by voter 110. In the example scenario, ACVL 200 can send a commitment token to each answer (some of which may be empty, e.g., a commitment token containing a zero-value vote) to thwart attempts to determine the voter's voting pattern by monitoring which answers receive tokens. ACVL 200 can generate a completion commitment token (e.g., a commitment token generated to complete the determined allocation to the answer and / or ensure that multiple answers receive commitment tokens from the voter) to ensure that multiple answers receive commitment tokens from the voter. In some cases, multiple commitment tokens can be transferred in a single transaction. Throughout the various implementations of this disclosure, names such as "target" or "complete" may be used for naming convenience to establish contextual order, but do not necessarily have to specify a technical distinction. For example, a "target" commitment token could be a commitment token sent during the voting process, while a "complete" commitment token could specify a final or subsequent token sent during the voting process. Therefore, the technical features applicable to the name "target" can be equally applied to the name "completion".

[0059] ACVL 200 can sign a record (218) of a transaction that requests completion of a token. ACVL 200 may include a range proof token (220) corresponding to the completion token. In some cases, such as the example range proof described previously by reference in Russian patent application serial number 2018103253 entitled “Electronic Voting and Verification in an e-BallotVoting System”, filed on January 29, 2018, which is incorporated herein by reference, the range proof token can provide range proof for multiple tokens.

[0060] In certain cases, when implementing homomorphic commitments, ACVL 200 can provide a sum token that can be verified based on the property that the sum of homomorphic commitments equals the sum of commitments.

[0061] In various implementations, ACVL 200 may include a reference to a source token (e.g., the source of the voting value to be distributed in a transaction, such as voter token 114, a pause token, or other tokens) and a sum token (222) in the transaction. The source token can be referenced to analyze the sum token that matches the transferred commitment token. Through analysis, the total voting value in the source token can be compared to the total voting value transferred by multiple commitment tokens and / or remaining tokens in the transaction. If the voting value in the source token matches the transferred voting value, the transaction may be valid. Because a transaction may include a pause token, the voter 110 (or other role) transferring the voting value does not necessarily need to transfer (e.g., to someone else) the entire voting value in the source token to make the voting value in the tokens in the transaction equal to the voting value in the source token. In other words, voter 110 can retain the voting value through the pause token.

[0062] In some cases, the sum token can be functionally merged with other tokens. For example, sum information can be extracted from an example range proof described in Russian patent application serial number 2018103253, filed January 29, 2018, entitled "Electronic Voting and Verification in an e-Ballot Voting System," which is incorporated herein by reference. Therefore, a range proof token using the example range proof can be used as a sum token. To verify the commitment token, ACVL 200 (or other logic, BOL 300, BAL 400) can sum the key L from the example range proof token. In this example, the sum of key L can be equal to the source token when the voting value transferred by the token in the transaction is equal to the voting value in the source token. The consistency of key L with the token in the transaction can be verified by performing a range proof on the token. Throughout various implementations of this disclosure, the sum information may include information that can support the determination of the sum of voting values ​​used to generate the checksum.

[0063] In the example transaction, ACVL 200 can refer to the source token and the range proof to transfer multiple commitment tokens (e.g., n commitment tokens). Example structures may include:

[0064] [Transaction]= (5)

[0065] Where [ST] is the source token, P is the range proof token consisting of keys L and L' including n commitment tokens, and [RT] is the pause token. Transaction verification may also include verifying that the source token is assigned to the identifier of the transaction requester.

[0066] Now for reference Figure 4The example BOL 300 is shown. In various implementations, BOL 300 can be used to set up a vote on behalf of an organizer. BOL 300 can be implemented on a circuit (e.g., a voting organization circuit). The example BOL 300 can generate a vote (302) with an answer. The answer can have a corresponding answer identifier. For example, the vote can specify the individual public key of the answer.

[0067] Voters (e.g., via ACVL 200) can use answer identifiers to instruct commitment tokens to assign voting values ​​to answers based on their voting preferences and obfuscation schemes.

[0068] BOL 300 can specify the allowed range for the transfer of voting value for vote 150 (304).

[0069] To set the initial supply of voting values ​​for distribution to voters, BOL 300 can generate an organizer token (306). In various implementations throughout this disclosure, the organizer token may include a cryptographic data structure that can be generated to transfer the initial distribution of voting values ​​to voters (or to initiate a transfer through a third-party intermediary).

[0070] BOL 300 can establish a vote (308) by requesting a transaction to record vote 150 to the DLT record. Additionally or alternatively, the transaction can establish an organizer token.

[0071] In one example, a transaction that establishes a vote (e.g., with n answers) can have the following structure:

[0072] [Transaction]= (6)

[0073] Where [OT]' represents the non-transferable establishment of the organizer token, Bal is the vote, Al is the answer identifier, {Range} is a field specifying the allowed range of vote value transfers, {TType} is a field specifying the permitted token type (e.g., binary, integer, decimal, or other voting types), k is the key used for generating the number point, G is the elliptic curve generation function, and H is the hash function used to generate the blind point from the number point. In some cases, BOL 300 can, for example, use the private key associated with the public key established by BOL 300 as the organizer identifier to digitally sign the vote.

[0074] In some cases, voting can also assign voter identifiers to authorized voters.

[0075] In some cases, BOL 300 can specify the voter by transferring the voting value via a voter token. In other words, the vote value is authorized to be received at a specific identifier. In some implementations, the system may not allow the answer to retransfer the voting value received from the voter via a commitment token (e.g., as a second-round voter). In other words, the commitment token will not be a valid source token. For example, the voting value in the organizer token, voter token, and rest token can be retransferred after being received, but the voting value in the commitment token may not be allowed to be retransferred. Furthermore, the organizer can use one or more intermediaries to distribute the voting value to the voters. For example, the organizer can transfer the voting value to an intermediary, which can then transfer that voting value (or a portion thereof) to the voter. Multiple layers of intermediaries can be used. In some implementations, any token containing the voting value (including the commitment token) can act as a source token. The received voting value can be passed between the voter and the answer until the election ends.

[0076] In various implementations, the election can end in response to an event (e.g., a voting value threshold implemented by the answer, a request from the organizer or other role, the final voter casting a vote, or other events) or at a specified time. BOL 300 can establish conditions for ending the vote within the voting period.

[0077] BOL 300 can determine the distribution of voting values ​​(310). In various implementations throughout the public disclosure, the distribution of voting values ​​can be specified in detail as the amount of voting value that can be transferred to individual voters.

[0078] BOL 300 can allocate voting values ​​to voters, such as voting values ​​consistent with voting value distribution, through transactions that request the transfer of voter tokens to voters (312). The voting value granted to voters (e.g., the granted voting value) can be subtracted from the organizer's voting value established by the organizer token (314). Transactions can also transfer pause tokens back to the organizer, which can allow the organizer to be promoted to a voter role or continue distributing voting values ​​to voters with remaining voting values ​​in the pause token.

[0079] In one example, a transaction that transfers voter tokens (e.g., n voter tokens) can have the following structure:

[0080] [Transaction]= (7)

[0081] Where [OT] is the organizer token (e.g., the source token), [VT] is the voter token, and [RT] is the pause token. Although not shown, transactions may also include sum tokens and / or range proof tokens to support verification.

[0082] Now for reference Figure 5The example shown is BAL 400. In various implementations, BAL 400 can be used to audit voting-related transactions on behalf of an auditor. BAL 400 can be implemented on circuits (e.g., voting audit circuits). BAL 400, for example, can improve the security and accuracy of a voting system through its operation via technological solutions. BAL 400 can verify the accuracy and integrity of transactions using analysis and, in some cases, records using cryptographic primitives and structures.

[0083] Referring now to the operation of BAL 400, BAL can access votes recorded on one or more DLT records. For example, BAL 400 can access votes previously set by BOL 300 (402) on behalf of the organizer. BAL 400 can access voter transactions for verification. In various implementations throughout this disclosure, voter transactions may include DLT records of the transfer of vote values. Voter transactions may include one or more commitment tokens and / or other tokens, such as range proof tokens, pausing tokens, and / or sum tokens. Voter transactions may reference voter tokens and / or pausing tokens that can be used as source tokens for voter transactions. BAL 400 can access voter tokens, for example, from the organizer transaction that initially granted the voter token. Verification can be applied to virtually any transaction recorded on the DLT. Therefore, BAL 400 can verify individual transactions and / or the entire voting process.

[0084] BAL 400 can compare the intended recipient of the voter token with the identifier of the voter requesting the voter transaction (404). Through this comparison, BAL 400 can confirm that the underlying voting value of the voter transaction originates from the voter requesting the transaction. In some cases, this may thwart attempts to secretly vote using voting value owned by another voter (or other entity).

[0085] Additionally or alternatively, BAL 400 can access DLT records to verify that the voter token has not been previously used in another voter transaction (406). In other words, BAL 400 can verify that the voter token is not "double-spent".

[0086] BAL 400 can access the sum information of commitment tokens in the voter transaction (408). For example, BAL 400 can access the sum token (or other tokens that can be used as the sum token, such as the range proof token based on the range proof example above).

[0087] BAL 400 can compare the sum information with the voter token (or other source token) (410). BAL 400 can use the comparison to determine whether the voting value transferred in the voter transaction (e.g., via the commitment token and / or pausing token) matches the voter voting value in the voter token. BAL 400 can also use the above logic to verify other transaction types (e.g., organizer transactions).

[0088] In response to determining whether a match exists, BAL 400 can generate a validity indication (412) for the voter transaction. Throughout various implementations of this disclosure, the validity indication can confirm a valid voter transaction and / or flag an invalid transaction. In some cases, generating a validity indication (e.g., which may include cryptographic primitives, such as a digital signature signing a data indication valid for a particular vote (or an individual voter transaction in a vote)) may be accompanied by sending the validity indication to the voter and / or organizer requesting the voter transaction. In some cases, BAL 400 can send the validity indication to some and / or all participants in the vote (e.g., broadcast or multicast).

[0089] In various implementations, validity indications can be recorded as validity tokens in the DLT record. Validity tokens can include a reference to the voting transaction and a validity indication. In some cases, validity tokens can be digitally signed by auditors on behalf of BAL 400. The more auditors who unanimously agree to sign the token to indicate the validity / invalidity of the voting transaction, the greater the likelihood that the auditor's conclusion is correct and reliable.

[0090] In some implementations, the voter may have the opportunity to correct an invalid transaction in response to an invalidation indication. For example, correction may be allowed before the election ends. ACVL 200 can request a new transaction that references an old transaction. The new transaction may reallocate voter tokens (or other source tokens) in different ways to attempt to achieve validity.

[0091] In various implementations, invalid transactions can be ignored. For example, participants can treat operations as if no transaction has occurred. In some cases, transactions that depend on invalid transactions can also be ignored.

[0092] In some implementations, one or more invalid transactions can invalidate the entire election. For example, an organizer can invalidally allocate organizer tokens to voter tokens. Voter tokens allocated in this way can be invalid. Therefore, voters placed using these voter tokens can be invalid. Thus, in response to an invalid organizer transaction, the entire election can be invalid.

[0093] In some cases, an election can be invalid based on a threshold number of invalid transactions. For example, if a majority (or other partial) voter transaction is invalid, the entire election can be invalid. In other cases, the threshold number can be determined based on the outcome. For example, if the votes transferred in invalid transactions may have altered the election result, the election can be invalid.

[0094] Additionally or alternatively, BAL 400 may verify a transaction by performing a range proof on the individual token transferred by the transaction (e.g., by accessing a range proof token). BAL 400 may access the range proof token (414). BAL 400 may perform a range proof (416). In various implementations, in addition to or instead of verification based on summation information, the validity token (e.g., generated in 412 above) may include a validity indication based on a range proof.

[0095] ACVL 200, BOL 300 and / or BAL 400 can be implemented on circuits that exist in a variety of execution environments. Figure 5 , Figure 6 and Figure 7 Example execution environments for ACVL 200, BOL 300, and / or BAL 400 are shown. In various implementations, the underlying hardware used to implement execution of any of the ACVL 200, BOL 300, and / or BAL 400 can be used to implement execution or other executions.

[0096] Now for reference Figure 6 The example voting logic execution environment (VLEE) 500 is shown. The example VLEE 500 can be used as a hardware platform for the ACVL 200. The VLEE 500 may include system logic 514. The system logic may include a processor 516, memory 520, and / or other circuitry.

[0097] The memory 520, together with the processor 516, can support the execution of ACVL 200. The memory 520 may also include applications and structures 566, such as coded objects, templates, or other structures, to support voter token reception, commitment token distribution, and token generation.

[0098] The VLEE 500 may also include a communication interface 512, which may support wireless (e.g., Bluetooth, Wi-Fi, WLAN, cellular (4G, LTE / A)) and / or wired Ethernet, Gigabit Ethernet, and optical network protocols. The communication interface 512 may also include a serial interface, such as Universal Serial Bus (USB), Serial ATA, IEEE 1394, a lighting port, and I / O. 2C, slimBus, or other serial interfaces. The VLEE 500 may include power functions 534 and various input interfaces 528. The VLEE may also include a user interface 518, which may include human-machine interface devices and / or graphical user interfaces (GUIs). In various implementations, the system logic 514 may be distributed across multiple physical servers and / or implemented as virtual machines.

[0099] In some cases, a VLEE 500 can be a specially defined computing system deployed in a cloud platform. In other cases, the parameters defining a VLEE 500 can be specified in a manifest used for cloud deployment. The manifest can be used by operators to requisition cloud-based hardware resources and then deploy logical components of the VLEE 500 (e.g., ACVL 200) onto those resources. In some cases, the manifest can be stored as a preference file, such as YAML (which also uses another markup language), JavaScript Object Notation (JSON), or other preference file types.

[0100] Now for reference Figure 7 The example Organizational Logic Execution Environment (OLEE) 600 is shown. The example OLEE 600 can be used as a hardware platform for the BOL 300. The OLEE 600 may include system logic 614. The system logic may include a processor 616, memory 620, and / or other circuitry.

[0101] The memory 620, together with the processor 616, can support the execution of BOL 300. The memory 620 may also include applications and structures 666, such as coded objects, templates, or other structures, to support organizer token creation, vote generation / establishment, and token generation.

[0102] The OLEE 600 may also include a communication interface 612, which may support wireless (e.g., Bluetooth, Wi-Fi, WLAN, cellular (4G, LTE / A)) and / or wired Ethernet, Gigabit Ethernet, and optical network protocols. The communication interface 612 may also include a serial interface, such as Universal Serial Bus (USB), Serial ATA, IEEE 1394, a lighting port, and I / O. 2 C, slimBus, or other serial interfaces. OLEE 600 may include power function 634 and various input interfaces 628. OLEE may also include a user interface 618, which may include human-machine interface devices and / or graphical user interfaces (GUIs). In various implementations, system logic 614 may be distributed across multiple physical servers and / or implemented as virtual machines.

[0103] In some cases, OLEE 600 can be a specially defined computing system deployed in a cloud platform. In other cases, the parameters defining OLEE 600 can be specified in a manifest used for cloud deployment. The manifest can be used by operators to requisition cloud-based hardware resources and then deploy logical components of OLEE 600 (e.g., BOL 300) onto those resources. In some cases, the manifest can be stored as a preference file, such as YAML (which also uses another markup language), JavaScript Object Notation (JSON), or other preference file types.

[0104] Now for reference Figure 8 The example Audit Logic Execution Environment (ALEE) 700 is shown. The example ALEE 700 can be used as a hardware platform for the BAL 400. The ALEE 700 may include system logic 714. The system logic may include a processor 716, memory 720, and / or other circuitry.

[0105] The memory 720, together with the processor 716, can support the execution of BAL 400. The memory 720 may also include applications and structures 766, such as coded objects, templates, or other structures, to support transaction validation, range validation execution, and validity token generation.

[0106] The ALEE 700 may also include a communication interface 712, which supports wireless (e.g., Bluetooth, Wi-Fi, WLAN, cellular (4G, LTE / A)) and / or wired Ethernet, Gigabit Ethernet, and optical network protocols. The communication interface 712 may also include a serial interface, such as Universal Serial Bus (USB), Serial ATA, IEEE 1394, a lighting port, and I / O. 2 C, slimBus, or other serial interfaces. ALEE 700 may include power function 734 and various input interfaces 728. ALEE may also include a user interface 718, which may include human-machine interface devices and / or graphical user interfaces (GUIs). In various implementations, system logic 714 may be distributed across multiple physical servers and / or implemented as virtual machines.

[0107] In some cases, the ALEE 700 can be a specially defined computing system deployed in a cloud platform. In other cases, the parameters defining the ALEE 700 can be specified in a manifest used for cloud deployment. The manifest can be used by operators to requisition cloud-based hardware resources and then deploy logical components of the ALEE 700 (e.g., BAL 400) onto those resources. In some cases, the manifest can be stored as a preference file, such as YAML (which also uses another markup language), JavaScript Object Notation (JSON), or other preference file types.

[0108] As mentioned above, the underlying hardware of the execution environment can simultaneously implement multiple execution environments. In some cases, concurrent implementations can be used to support the operation of a specific node based on multiple roles. Furthermore, any of the VLEE 500, OLEE 600, and ALEE 700 can be used to implement decryption and analysis operations for the response role.

[0109] Now, turning to the discussion of voter anonymity, commitment tokens in various implementations can preserve the pseudonymity of voters. For example, an answer might be able to determine which voter identities provided commitment tokens for that answer. In other words, a voter can be anonymous to a regular auditor (e.g., a regular auditor might not necessarily know which answers a particular voter identity sent non-zero vote values ​​to), but pseudonymous to the answer role (e.g., the answer might have knowledge of the specific number of vote values ​​transferred from a particular voter identifier). However, through historical analysis, data breaches, or security vulnerabilities, pseudonymous voter identities can be associated with the voter's personal identity.

[0110] In some implementations, voting value compilation (e.g., mixing and / or other intermediate role obfuscation) can be used to provide additional protection against answer roles for voter anonymity. Figure 9 An example mediated voting environment 800 is illustrated. In the example mediated voting environment 800, voter 110 sends a commitment token to intermediary 810, for example, via intermediary identifier 812. Intermediary 810 may mix or otherwise obfuscate individual voting value transfers and provide a compiled token with a compiled voting value transfer to the answer that has removed the identity of the individual pseudonymous voter.

[0111] Using a middleman shifts the anonymous handling of questions from the answer to the middleman. In some cases, voters can control the choice of middleman. For example, the organizer can choose the answer, but voters are free to specify the middleman (or choose from a list of permitted middlemen). Therefore, because voters can control the choice of middleman while the organizer specifies the answer, voters can trust the middleman more than the answer.

[0112] Now for reference Figure 10Example Intermediate Voting Value Compilation Logic (IVCL) 900 is shown. IVCL 900 can access commitment tokens transferred to the IVCL for safekeeping (902). IVCL 900 can determine which answer an individual commitment token is for (904). IVCL 900 can compile the voting value in the commitment token for a specific answer into a compilation token. IVCL 900 can request a compilation transaction that combines multiple tokens for a specific answer into a single compilation token (906). IVCL 900 can address the compilation token to an answer identifier (908).

[0113] In the example scenario, IVCL 900 requests a compilation transaction, which includes compilation tokens addressed to a specific answer. Commitment tokens can be used to prove that the voting value in the compilation tokens is valid. IVCL 900 can identify the commitment tokens addressed to each answer. The compilation transaction can provide sum information and / or range proofs for the commitment tokens.

[0114] Auditors can use summation information to confirm that the voting value in the commitment token is the same as the voting value in the compilation token. For example, with ACVL 200, voters can prove a compilation transaction by recording a signature token in the DLT record. The signature token can confirm that the IVCL 900 correctly identifies the address of the voter's commitment token. As the number of signature tokens from different voters increases, confidence in the electronic result can be enhanced. In a mediated voting environment, the anonymity of voters' answers can be protected by transferring pseudonyms to the mediated party. Voters can send commitment tokens to multiple answers. Therefore, identifying a specific token from a voter as being addressed to a specific answer does not necessarily reveal the voting value committed within the token or that the answer actually committed any voting value.

[0115] In various implementations, peer-to-peer hybrids can be used. Implementations such as ValueShuffle, DiceMix, and CoinShuffle++, as described by Ruffing and Moreno-Sanchez in their 2017 paper "Mixing Confidential Transactions: Comprehensive Transaction Privacy for Bitcoin" (http: / / eprint.iacr.org / 2017 / 238.pdf), can be used. ValueShuffle and CoinShuffle++ are described as allowing transaction privacy through hybrid homomorphic commitments. This scheme leverages the additivity of homomorphic commitments. For example, these schemes provide the sum and difference of values ​​used in a transaction without disclosing the sum itself. In this case, when generating tokens, ACVL 200 (or other token transfer logic) can provide the sum and / or difference of the transaction voting value and blind value instead of the actual value encrypted using the public key of the recipient of the committed token. These sums / differences allow the answer to determine the sum of voting values ​​received from multiple tokens, but not necessarily the ability to determine the individual voting value from the individual token. The scheme can be modified, but the value transferred in the transaction is replaced with the voting value transfer. Therefore, using the peer-to-peer hybrid scheme described above, anonymity can be preserved for roles other than voters. In a peer-to-peer hybrid, it is not necessarily required to include intermediaries to protect anonymity. Therefore, non-intermediary voting environments (e.g., example voting environment 100) can be used.

[0116] The methods, devices, architectures, processes, circuits, and logic described above can be implemented in many different ways and in many different combinations of hardware and software. For example, a full or partial implementation may be a circuit including an instruction processor, such as a central processing unit (CPU), microcontroller, or microprocessor; or as an application-specific integrated circuit (ASIC), programmable logic device (PLD), or field-programmable gate array (FPGA); or as a circuit containing discrete logic or other circuit components, including analog circuit components, digital circuit components, or both; or any combination thereof. As an example, the circuit may include discrete interconnected hardware components, or may be combined on a single integrated circuit chip, distributed among multiple integrated circuit chips, or implemented in a multi-chip module (MCM) of multiple integrated circuit chips in a common package.

[0117] Therefore, the circuit can store or access instructions for execution, or its function can be implemented solely in hardware. Instructions can be stored in tangible storage media other than transient signals, such as flash memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM); or on a disk or optical disc, such as an optical disc read-only memory (CDROM), a hard disk drive (HDD), or other disk or optical disc; or on or on other machine-readable media. Products such as computer program products may include storage media and instructions stored on or on that media, and these instructions, when executed by circuitry in the device, may cause the device to perform any of the processes described above or shown in the accompanying drawings.

[0118] The implementation can be distributed. For example, the circuit may include multiple different system components, such as multiple processors and memories, and may span multiple distributed processing systems. Parameters, databases, and other data structures may be stored and managed separately, may be merged into a single memory or database, may be organized logically and physically in many different ways, and may be implemented in many different ways. Example implementations include linked lists, program variables, hash tables, arrays, records (e.g., database records), objects, and implicit storage mechanisms. Instructions may form parts of a single program (e.g., subroutines or other code segments), may form multiple separate programs, may be distributed across multiple memories and processors, and may be implemented in many different ways. Example implementations include standalone programs and, as part of a library, such as a shared library like a dynamic link library (DLL). This library may, for example, contain shared data and one or more shared programs that include instructions that, when executed by the circuit, perform any of the processes shown above or in the accompanying figures.

[0119] A1. In one example, a cryptographic voting method includes: acquiring a vote established on a distributed ledger, the vote specifying an answer having a corresponding answer identifier; receiving a voter token that grants a voter voting value to a voter, the voter token being received in response to a transaction on the distributed ledger addressing the voter's voter identifier; determining a target commitment vote value to be assigned to a target answer among the answers, the target commitment vote value including at least a portion of the voter voting value; generating a target commitment token configured to bind the voter to the target commitment vote value without revealing the target commitment vote value when in cryptographic form; determining a completion commitment vote value to be assigned to a second answer among the answers, the completion commitment vote value including a null value or another portion of the voter voting value; generating a completion commitment token configured to bind the voter to the completion commitment vote value without revealing the completion commitment vote value when in cryptographic form; and a second transaction on the distributed ledger requesting the transfer of the completion commitment token to the corresponding answer identifier of the second answer.

[0120] A2. The cryptographic voting method according to Example A1, wherein the first transaction and the second transaction comprise the same transaction.

[0121] A3. The cryptographic voting method according to any one of Examples A1 or A2, wherein: the completed commitment voting value includes a null value; and the request for the second transaction includes a transfer of at least a portion of the voting value that is obfuscated and transferred to the target answer.

[0122] A4. A cryptographic voting method according to any one of Examples A1 to A3, wherein: the voter identifier is associated with the voter's public key; and the target commitment token is digitally signed using a private key paired with the public key.

[0123] A5. The cryptographic voting method according to any one of Examples A1 to A4 further includes subtracting the target commitment voting value and the completion voting value from the voter's voting value.

[0124] A6. The cryptographic voting method according to Example A5, wherein subtracting the completed voting value includes producing a voter's voting value that results in an empty result.

[0125] A7. The cryptographic voting method according to any one of Examples A1 to A6 further includes sending a pause token back to the voter, the pause token including the remaining voting value after the second transaction.

[0126] A8. A cryptographic voting method according to any one of Examples A1 to A7, wherein generating the target commitment token comprises: applying the target commitment voting value to a quantity point on an elliptic curve to generate a quantity term; applying a random blind value to a blind point on the elliptic curve to generate a blind term; and merging the quantity term and the blind term.

[0127] A9. The cryptographic voting method according to Example A8 further includes selecting the blind point by applying a hash function to the number point.

[0128] A10. The cryptographic voting method according to any one of Examples A1 to A9 further includes generating a range proof token, the range proof token being configured to establish that the target commitment vote value is within an allowed range for the vote when compared with the target commitment token.

[0129] B1. In one example, a cryptographic voting method includes: accessing a vote established on a blockchain, the vote specifying a plurality of answers having corresponding answer identifiers; determining a voting value distribution to be assigned to the plurality of answers, the voting value distribution distributing voter voting values ​​received within voter tokens; generating a commitment token for each of the plurality of answers, the commitment token being configured to bind a voter to the voting value distribution without revealing an individual commitment voting value within an individual commitment token in the commitment token when the commitment token is in cryptographic form, and at least one of the commitment tokens including an empty voting value; and requesting a transaction on the blockchain to transfer the commitment token to the plurality of answers, wherein the transfer of at least one of the commitment tokens including the empty voting value obscures the voting value distribution.

[0130] B2. The cryptographic voting method according to Example B1, wherein generating the commitment token for each of the plurality of answers comprises: applying the individual commitment vote value to a quantity point on an elliptic curve to generate an individual quantity item; applying a random blind value to a blind point on the elliptic curve to generate an individual blind item; and merging the individual quantity item and the individual blind item.

[0131] B3. The cryptographic voting method according to Example B2 further includes selecting the blind point by applying a hash function to the number of points.

[0132] B4. The cryptographic voting method according to any one of Examples B1 to B3 further includes: generating a pause token configured to transfer remaining voting values; and requesting the transaction on the blockchain further includes requesting the transfer of the pause token back to the voter.

[0133] C1. In one example, a cryptographic voting system includes: a network interface circuit configured to: acquire a vote established on a distributed ledger, the vote specifying an answer having a corresponding answer identifier; and receive a voter token, the voter token granting a voter voting value to a voter, the voter token being received in response to a transaction on the distributed ledger addressing the voter's voter identifier; and a cryptographic voting circuit communicating with the network interface circuit, the cryptographic voting circuit being configured to: determine a target commitment vote value to be assigned to a target answer among the answers, the target commitment vote value including at least a portion of the voter voting value; and generate a target commitment token, the target commitment token being configured to bind the voter to the target commitment vote value without... The transaction involves: revealing the target commitment vote value in cryptographic form; requesting a first transaction on the distributed ledger to transfer the target commitment token to the corresponding answer identifier of the target answer using a cryptographic key associated with the voter identifier; determining a completion commitment vote value to be assigned to a second answer among the answers, the completion commitment vote value including a null value or another portion of the voter vote value; generating a completion commitment token configured to bind the voter to the completion commitment vote value without revealing the completion commitment vote value in cryptographic form; and a second transaction on the distributed ledger to request the transfer of the completion commitment token to the corresponding answer identifier of the second answer using the cryptographic key associated with the voter identifier.

[0134] C2. The cryptographic voting system according to Example C1, wherein the first transaction and the second transaction comprise the same transaction.

[0135] C3. A cryptographic voting system according to any one of Examples C1 or C2, wherein: the completed commitment voting value includes a null value; and the cryptographic voting circuit is configured to request the second transaction by obfuscating the transfer of at least a portion of the voting value transferred to the target answer.

[0136] C4. A cryptographic voting system according to any one of Examples C1 to C3, wherein: the voter identifier includes the voter's public key; and the cryptographic voting circuit is configured to use the cryptographic key by digitally signing the target commitment token using a private key paired with the public key.

[0137] C5. According to any one of Examples C1 to C4, the cryptographic voting circuit is further configured to subtract the target commitment vote value and the completion vote value from the voter's vote value.

[0138] C6. The cryptographic voting system according to Example C5, wherein the cryptographic voting circuit is configured to subtract the completed voting value by generating a voter's vote value that results in an empty result.

[0139] D1. In one example, a cryptographic voting method includes: accessing votes for a specified answer; determining the distribution of voting values; generating a compilation token by mixing the voting values ​​with those of other voters; and initiating a request for a transaction to transmit the compilation token to the first answer among the answers.

[0140] D2. The cryptographic voting method according to Example D1, wherein the mixed voting value includes performing a peer-to-peer mixing scheme.

[0141] D3. The cryptographic voting method according to Example D2, wherein performing a peer-to-peer hybrid scheme includes performing a peer-to-peer hybrid scheme without intermediaries.

[0142] D4. The cryptographic voting method according to Example D1, wherein the mixed voting value includes a transaction requesting the transmission of the voting value to an intermediary.

[0143] D5. The cryptographic voting method according to Example D1 further includes implementing any of the features according to any one of Examples A1 to A10 and B1 to B4.

[0144] E1. In one example, a cryptographic voting organization method includes: generating a vote with an answer including an answer identifier, the answer identifier being configured to guide the reception of a commitment token including a committed voting value transferred from a voter, the commitment token being configured to bind the voter to the committed voting value without revealing the committed voting value when in cryptographic form, and the committed voting value including a null value or at least a portion of a voter's voting value; generating an organizer token including an organizer's voting value; establishing the vote and the organizer token on a ledger; determining the distribution of the voting value; requesting a transaction to transfer a voter token to a voter identifier of the voter, and the voter token granting the voter's voting value to the voter; and accounting for the transaction by subtracting the voter's voting value from the organizer's voting value.

[0145] E2. The cryptographic voting organization method according to Example E1, wherein requesting the transaction further includes requesting the transaction to send a pause token back to the organizer, the pause token including a remaining voting value corresponding to the organizer's voting value, wherein at least the voter's voting value is subtracted.

[0146] E3. A cryptographic voting method according to any one of Examples E1 or E2, wherein generating the vote includes generating a vote that allows the transfer of non-integer voting values.

[0147] E4. A cryptographic voting organization method according to any one of Examples E1 to E3, wherein generating the vote includes specifying a permissible range for the transfer of voting values ​​for the vote.

[0148] E5. A cryptographic voting organization method according to any one of Examples E1 to E4, wherein generating the vote includes designating a public key as an answer identifier.

[0149] E6. A cryptographic voting organization method according to any one of Examples E1 to E5, wherein generating the vote includes designating a public key as the voter identifier.

[0150] E7. According to the cryptographic voting organization method described in Example E6, the structure for the transaction includes: the voter token; a quantity field specifying the voter's voting value, the quantity field being encrypted with the public key; and a blind field specifying a blind factor for obfuscating the quantity field, the blind field being encrypted with the public key.

[0151] E8. A cryptographic voting organization method according to any one of Examples E1 to E7, wherein: the distributed ledger includes a blockchain; and establishing the vote and the organizer token includes: causing the vote to be recorded on the blockchain; and designating a public key as an organizer identifier.

[0152] E9. The cryptographic voting organization method according to any one of Examples E1 to E8, the generation of a vote further includes specifying a plurality of points on an elliptic curve for the generation of tokens used to transmit voting values, the plurality of points including: a quantity point; and a blind point.

[0153] E10. The cryptographic voting organization method according to Example E9, wherein: specifying a number point includes specifying a cryptographic key for a curve generation function to be applied to the elliptic curve; and specifying a blind point includes specifying a hash function to be applied to the number point to generate the blind point.

[0154] F1. In one example, a cryptographic voting organization system includes: a memory configured to store a distributed ledger; and voting organization circuitry in data communication with the memory, the voting organization circuitry being configured to: generate a vote with an answer including an answer identifier, the answer identifier being configured to guide the reception of a commitment token including a committed voting value transferred from a voter, the commitment token being configured to bind the voter to the committed voting value without revealing the committed voting value when in cryptographic form, the committed voting value including a null value or at least a portion of a voter's voting value; generate an organizer token including an organizer's voting value; establish the vote and the organizer token on the ledger; determine the distribution of the voting value; request a transaction to transfer a voter token to a voter identifier of the voter, the voter token granting the voter's voting value to the voter; and account for the transaction by subtracting the voter's voting value from the organizer's voting value.

[0155] F2. The cryptographic voting organization system according to Example F1, wherein the voting organization circuit is further configured to request the transaction by requesting the transaction to send back a pause token to the organizer, the pause token including a remaining voting value corresponding to the organizer's voting value, wherein at least the voter's voting value is subtracted.

[0156] F3. A cryptographic voting organization system according to any one of Examples F1 or F2, wherein the voting organization circuit is further configured to generate the vote by generating a vote that allows the transfer of non-integer voting values.

[0157] F4. A cryptographic voting organization system according to any one of Examples F1 to F3, wherein the voting organization circuit is further configured to generate the vote by specifying an allowed range of voting value transfers for the vote.

[0158] F5. A cryptographic voting organization system according to any one of Examples F1 to F4, wherein the voting organization circuit is further configured to generate the vote by specifying a public key to be used as the answer identifier.

[0159] F6. A cryptographic voting organization system according to any one of Examples F1 to F5, wherein generating the vote includes specifying a public key to be used as the voter identifier.

[0160] F7. The cryptographic voting organization system according to Example F6, wherein the voting organization circuit is further configured to generate the vote by specifying a structure of the transaction, the structure including: the voter token; a quantity field specifying the voter's vote value, the quantity field being encrypted with the public key; and a blind field specifying a blind factor for obfuscating the quantity field, the blind field being encrypted with the public key.

[0161] G1. In one example, a product includes a machine-readable medium other than transient signals; and instructions stored on the machine-readable medium, the instructions being configured to, upon execution, cause a machine to: generate a vote with an answer including an answer identifier, the answer identifier being configured to guide a commitment token including a committed vote value transferred from a voter, the commitment token being configured to bind the voter to the committed vote value without revealing the committed vote value when in cryptographic form, the committed vote value including a null value or at least a portion of a voter's vote value; generate an organizer token including an organizer's vote value; establish the vote and the organizer token on a ledger; determine the distribution of the vote value; request a transaction to transfer a voter token to a voter identifier of the voter, the voter token granting the voter's vote value to the voter; and account for the transaction by subtracting the voter's vote value from the organizer's vote value.

[0162] G2. According to the product described in Example G1, the instructions are further configured to cause the machine to generate a vote by specifying multiple points on an elliptic curve for the generation of tokens used to transfer voting values, the multiple points including: quantity points; and blind spots.

[0163] G3. According to the product of Example G2, the instructions are also configured to cause the machine to: specify a number point by specifying a cryptographic key for a curve generation function to be applied to the elliptic curve; and specify a blind point by specifying a hash function to be applied to the number point to generate the blind point.

[0164] H1. In one example, a cryptographic voting auditing method includes: providing security and accuracy for a distributed ledger-based cryptographic voting system by: accessing a vote recorded on the distributed ledger, the vote establishing an answer with a corresponding answer identifier; accessing a voter transaction recorded on the distributed ledger; accessing a first voter token referenced within the voter transaction, the first voter token transferring a voter's vote value for a committed vote value within a commitment token allocated by the transaction, the commitment token being configured to bind the voter to the committed vote value without revealing individual committed vote values ​​when in cryptographic form, each of the committed vote values ​​including a null value or at least a portion of the voter's vote value; verifying the validity of the commitment token by: determining a verification sum by analyzing voter sum information for each commitment token in the commitment tokens without relying on knowledge of individual committed vote values; comparing the verification sum with the first voter token; and generating a validity indication in response to verifying the validity of the voter transaction.

[0165] H2. The cryptographic voting auditing method according to Example H1 further includes recording the validity indication as a validity token in the distributed token.

[0166] H3. A cryptographic voting auditing method according to any one of Examples H1 or H2, wherein comparing the verification sum with the first voter token includes determining a mismatch between the verification sum and the first voter token when the first voter token is in the cryptographic form.

[0167] H4. The cryptographic voting auditing method according to Example H3, wherein the sum information includes information extracted from the range proof token provided within the voter transaction.

[0168] H5. The cryptographic voting auditing method according to any one of Examples H3 or H4 further includes recording the validity indication to the distributed ledger to invalidate the voter transaction.

[0169] H6. The cryptographic voting auditing method according to any one of Examples H3 to H5 further includes recording the validity indication in the distributed ledger to request a change to the voter transaction to match the verification sum.

[0170] H7. The cryptographic voting auditing method according to any one of Examples H1 to H6 further includes: accessing an organizer token established on the distributed ledger, the organizer token establishing an organizer voting value; and accessing an organizer transaction recorded on the distributed ledger, the organizer transaction referencing an organizer token specifying an organizer voting value; granting a voter token to the voter via a voter identifier for the voter using the organizer token as a source token, the voter token including the first voter token; and providing organizer summation information for each voter token in the voter tokens.

[0171] H9. The cryptographic voting auditing method according to Example H7, wherein verifying the validity of the voter transaction further includes comparing the organizer token with the organizer summation information.

[0172] H9. A cryptographic voting auditing method according to any one of Examples H1 to H8, wherein: the method further includes accessing a range proof token within the voter transaction; and verifying the validity of the voter transaction further includes comparing the range proof token with a first commitment token among the commitment tokens to determine whether a first commitment vote value transferred via the first commitment token is within the permissible range for the vote.

[0173] H10. The cryptographic voting auditing method according to Example H9 further includes: determining that the first committed voting value is within an allowable range for the vote by determining that the voting value is non-negative.

[0174] H11. A cryptographic voting auditing method according to any one of Examples H1 to H10, wherein analyzing the summation information includes summing the keys stored in the scope proof token within the voter's transaction.

[0175] H12. A cryptographic voting auditing method according to any one of Examples H1 to H10, wherein verifying the validity of the commitment token includes comparing the recipient identifier of the first voter token with the voter identifier of the voter requesting the voter transaction.

[0176] I1. In one example, a cryptographic voting auditing system includes: a network interface circuit configured to: access a vote recorded on a distributed ledger, the vote establishing an answer with a corresponding answer identifier; access a voter transaction recorded on the distributed ledger; and access a first voter token referenced within the voter transaction, the first voter token transferring a voter's vote value for a committed vote value within a commitment token allocated by the transaction, the commitment token being configured to bind the voter to the committed vote value without revealing individual committed vote values ​​when in cryptographic form, each committed vote in the committed vote value. The value includes a null value or at least a portion of the voter's vote value; and a voting audit circuit, which communicates data with the network interface circuit, the voting audit circuit being configured to: verify the validity of the commitment token by: comparing the recipient identifier of the first voter token with the voter identifier of the voter requesting the voter transaction; determining a verification sum by analyzing the voter sum information for each commitment token in the commitment tokens without relying on knowledge of individual commitment vote values; and comparing the verification sum with the first voter token; and generating a validity indication in response to verifying the validity of the voter transaction.

[0177] I2. The cryptographic voting auditing system according to Example 11, wherein the voting auditing circuit is further configured to record the validity indication as a validity token to the distributed token.

[0178] I3. A cryptographic voting auditing system according to any one of Examples 11 or 12, wherein the voting auditing circuit is further configured to compare the verification sum with the first voter token by determining a mismatch between the verification sum and the first voter token when the first voter token is in the cryptographic form.

[0179] I4. The cryptographic voting auditing system according to Example I3, wherein the sum information includes information extracted from the range proof token provided within the voter transaction.

[0180] I5. A cryptographic voting organization system according to any one of Examples I4 or I3, wherein the voting auditing circuit is further configured to record the validity indication to the distributed ledger to invalidate the voter transaction.

[0181] I6. A cryptographic voting auditing system according to any one of Examples 11 to 15, wherein the voting auditing circuit is further configured to record the validity indication into the distributed ledger to request a change to the voter transaction to match the verification sum.

[0182] I7. A cryptographic voting auditing system according to any one of Examples 11 to 16, wherein the voting auditing circuitry is further configured to: access an organizer token established on the distributed ledger, the organizer token establishing an organizer voting value; and access an organizer transaction recorded on the distributed ledger, the organizer transaction: referencing an organizer token specifying an organizer voting value; granting a voter token to the voter via a voter identifier for the voter using the organizer token as a source token, the voter token including the first voter token; and providing organizer summation information for each voter token in the voter tokens.

[0183] J1. In one example, a product includes: a machine-readable medium other than transient signals; and instructions stored on the machine-readable medium, the instructions being configured to, upon execution, cause a machine to: access a vote recorded on a distributed ledger, the vote establishing an answer with a corresponding answer identifier; access a voter transaction recorded on the distributed ledger; access a first voter token referenced within the voter transaction, the first voter token transferring a voter's vote value for a committed vote value within a commitment token allocated by the transaction, the commitment token being configured to bind the voter to the committed vote value without revealing individual committed vote values ​​when in cryptographic form, each of the committed vote values ​​including a null value or at least a portion of the voter's vote value; verify the validity of the commitment token by: comparing the recipient identifier of the first voter token with the voter identifier of the voter requesting the voter transaction; determining a verification sum by analyzing voter sum information for each commitment token in the commitment tokens without relying on knowledge of individual committed vote values; comparing the verification sum with the first voter token; and generating a validity indication in response to verifying the validity of the voter transaction.

[0184] J2. The product according to Example J1, wherein the instructions are further configured to analyze summation information by summing the keys stored in the range proof token within the voter transaction.

[0185] K1. In one example, a system includes circuitry configured to implement a cryptographic voting method according to any one of examples A1 to A10, B1 to B4, D1 to D4, E1 to E11, and H1 to H12.

[0186] L1. In one example, a product includes instructions stored on a machine-readable medium, the instructions being configured to cause a machine to implement a cryptographic voting method according to any one of examples A1 to A10, B1 to B4, D1 to D4, E1 to E11, and H1 to H12.

[0187] M1. In one example, one approach includes implementing any one or any combination of the features described in the previous disclosures.

[0188] N1. In one example, a system is configured to implement any one or any combination of the features described in the previous disclosures.

[0189] Various implementations have been described in detail. However, many other implementations are also possible. For example, any component and function in the architecture can be hosted in a virtual machine managed by a cloud service provider. That is, while some implementations may be entirely localized within a given enterprise, others may be entirely migrated to the cloud, or be a hybrid implementation combining on-premises and cloud implementations. Regarding query devices, the smartphone apps and desktop computers mentioned above are just specific examples, and other query devices can be used, including hands-free systems in vehicles, digital personal assistants in smartphones or desktop PCs, home hands-free control systems, and many other types of devices.

Claims

1. A method for anonymous cryptographic voting based on blockchain, comprising: Generate a vote with answers. The answer includes an answer identifier, which is configured as follows: Guide the receipt of commitment tokens, including the committed voting value transferred from voters. The commitment token is configured to bind the voter to the committed voting value without revealing the committed voting value when in cryptographic form, and The committed voting value includes a null value or at least a portion of the voter's voting value; Initiate the establishment of the aforementioned vote on the distributed ledger; The distribution of voting values ​​is determined by identifying the appropriate number of voting values ​​that can be transferred to individual voters. Request transaction, The transaction transfers the voter token to the voter's voter identifier, and The voter token grants the voter the voter's voting value; as well as The transaction is accounted for by recording the votes of the voters on the distributed ledger.

2. The method of claim 1, wherein requesting the transaction further comprises: The request is for the transaction to send a pause token back to the organizer, and The pause token includes the remaining voting value corresponding to the initial voting value, wherein at least the voter's voting value is subtracted.

3. The method of claim 1, wherein generating the vote includes generating a vote that allows the transfer of non-integer voting values.

4. The method of claim 1, wherein generating the vote includes specifying a permissible range for the transfer of voting value for the vote.

5. The method of claim 1, wherein generating the vote includes designating a public key as the answer identifier.

6. The method of claim 1, wherein generating the vote includes designating a public key as the voter identifier.

7. The method of claim 6, wherein the structure for the transaction comprises: The voter token; The quantity field specifies the voter's vote value, and the quantity field is encrypted using the public key; as well as A blind field, specifying a blind factor used to obfuscate the quantity field, is encrypted using the public key.

8. The method according to claim 1, wherein: The distributed ledger includes a blockchain; and Establishing the voting process includes: The vote was recorded on the blockchain; and Specify the public key as the organizer identifier.

9. The method according to claim 1, further comprising: Multiple points are specified on the elliptic curve for the generation of tokens that transmit voting values, said multiple points including: Quantity points; and Blind spot.

10. The method according to claim 9, wherein: The specified number of points includes: Specify the cryptographic key to be applied to the curve generation function for the elliptic curve; and The specified blind spots include: Specify the hash function to be applied to the number of points to generate the blind spot.

11. A system for blockchain-based anonymous cryptographic voting, comprising: The storage device is configured to store a distributed ledger. as well as The voting organization circuit communicates with the memory data, and the voting organization circuit is configured to: Generate a vote with an answer, wherein the answer includes an answer identifier, which is configured as follows: Guide the reception of a commitment token comprising a committed vote value transferred from a voter, the commitment token being configured to bind the voter to the committed vote value without revealing the committed vote value when in cryptographic form, the committed vote value comprising a null value or at least a portion of the voter's vote value; Initiate the establishment of the vote on the distributed ledger; The distribution of voting values ​​is determined by identifying the appropriate number of voting values ​​that can be transferred to individual voters. A request transaction is made that transfers a voter token to the voter's voter identifier, and the voter token grants the voter's vote value to the voter. as well as The transaction is accounted for by recording the votes of the voters on the distributed ledger.

12. The system of claim 11, wherein the voting organization circuit is further configured to request the transaction by requesting the transaction to send a pause token back to the organizer, the pause token comprising a remaining voting value corresponding to the organizer's voting value, wherein at least the voter's voting value is subtracted.

13. The system of claim 11, wherein the voting organization circuit is further configured to generate the vote by generating a vote that allows the transfer of non-integer voting values.

14. The system of claim 11, wherein the voting organization circuit is further configured to generate the vote by specifying an allowable range for the transfer of voting value for the vote.

15. The system of claim 11, wherein the voting organization circuit is further configured to generate the vote by specifying a public key as the answer identifier.

16. The system of claim 11, wherein generating the vote includes designating a public key as the voter identifier.

17. The system of claim 16, wherein the voting organization circuit is further configured to generate the vote by specifying a structure for the transaction, the structure comprising: The voter token; The quantity field specifies the voter's vote value, and the quantity field is encrypted using the public key; as well as A blind field, specifying a blind factor used to obfuscate the quantity field, is encrypted using the public key.

18. A non-transitory computer-readable storage medium storing instructions, which, when executed by a machine, cause the machine to perform a method for anonymous cryptographic voting based on a blockchain, comprising: Generate a vote with an answer, wherein the answer includes an answer identifier, which is configured as follows: Guide the reception of a commitment token comprising a committed vote value transferred from a voter, the commitment token being configured to bind the voter to the committed vote value without revealing the committed vote value when in cryptographic form, the committed vote value comprising a null value or at least a portion of the voter's vote value; The establishment of the vote is triggered on the distributed ledger; The distribution of voting values ​​is determined by identifying the appropriate number of voting values ​​that can be transferred to individual voters. A request transaction is made that transfers a voter token to the voter's voter identifier, and the voter token grants the voter's vote value to the voter. as well as The transaction is accounted for by recording the votes of the voters on the distributed ledger.

19. The non-transitory computer-readable storage medium of claim 18, wherein the instructions are further configured to cause the machine to designate a plurality of points on an elliptic curve for the generation of tokens for transmitting voting values, the plurality of points comprising: Quantity points; as well as Blind spot.

20. The non-transitory computer-readable storage medium of claim 19, wherein the instructions are further configured to cause the machine to: The number of points is specified by specifying the cryptographic key to be applied to the curve generation function for the elliptic curve; and The blind spot is specified by specifying the hash function to be applied to the number of points to generate the blind spot.

Images