WO2024249467A2 - Système, procédé et produit programme d'ordinateur pour des engagements clé-valeur d'accumulateurs et des engagements vectoriels - Google Patents

Système, procédé et produit programme d'ordinateur pour des engagements clé-valeur d'accumulateurs et des engagements vectoriels Download PDF

Info

Publication number
WO2024249467A2
WO2024249467A2 PCT/US2024/031372 US2024031372W WO2024249467A2 WO 2024249467 A2 WO2024249467 A2 WO 2024249467A2 US 2024031372 W US2024031372 W US 2024031372W WO 2024249467 A2 WO2024249467 A2 WO 2024249467A2
Authority
WO
WIPO (PCT)
Prior art keywords
commitment
key
accumulator
value
vector
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2024/031372
Other languages
English (en)
Other versions
WO2024249467A3 (fr
Inventor
Ioanna KARANTAIDOU
Srinivasan Raghuraman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa International Service Association filed Critical Visa International Service Association
Publication of WO2024249467A2 publication Critical patent/WO2024249467A2/fr
Publication of WO2024249467A3 publication Critical patent/WO2024249467A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • a state of the blockchain network is represented by a key-value map (M), including one or more keys that represent the public addresses of the parties (e.g., users, entities, etc.) involved, and one or more values that represent the attributes associated with the keys (e.g., transactions, balance amount, transaction details, smart contracts, a nonce used only once, etc.).
  • the key-value map provides a snapshot of the blockchain network (e.g., the entire blockchain network, complete blockchain network at a particular point in time, etc.). The snapshot represents the current state of the blockchain network, used by nodes of the blockchain network to validate transactions, enforce rules, and maintain consensus across a specified blockchain network.
  • the snapshot includes data and information necessary to determine the current state and condition of each element of the blockchain network (e.g., details required to represent the state of the blockchain network accurately at a specific point in time).
  • the key-value map is used to check if the user based on their public key has a balance of at least the amount transferred. On confirmation of the transaction, the balance of the parties may be updated in a key-value map.
  • blockchain e.g., cryptocurrency, etc.
  • blockchains have experienced significant growth since the introduction of Bitcoin. With significant increases in the number of transactions, blockchains, in particular cryptocurrencies, are expected to experience substantially greater throughputs with many more additional accounts.
  • a system comprising: at least one processor, configured to: generate an accumulator commitment for a plurality of key-value pairs of a block in a blockchain network, the accumulator commitment cryptographically adding each key-value commitment of the block; obtain a new transaction for the block; determine a membership proof or non- membership proof to verify at least one accumulated value from one or more previous transactions; and authenticate the new transaction based on at least one proof to verify membership or non-membership based on the at least one accumulated value.
  • the at least one processor is further programmed or configured to: determine a multi-hop proof for a plurality of 5UJ0107.DOCX Page 2 of 92 Attorney Docket No.08223-2400886 (6654WO01) transactions; generate a vector commitment from the accumulator commitment by converting each key-value commitment of the plurality of key-value pairs of the accumulator commitment to a corresponding key-value commitment of the vector commitment; authenticate at least one second transaction by using at least one property of the vector commitment to execute the multi-hop proof; and update the accumulator commitment by adding a key-value pair to the accumulator commitment for the second transaction in response to verifying the second transaction based on the vector commitment.
  • the vector commitment increases in length to commit each key-value commitment stored by the accumulator commitment, and the increases in the length of the vector commitment comprise a plurality of keys that commit a domain of the accumulator commitment.
  • the at least one processor is further programmed or configured to: determine a current state of the blockchain network based on combining the accumulator commitment of a current block of the blockchain network with each previous accumulator commitment representing each previous block of the blockchain network, wherein a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of the blockchain network, the accumulator commitment includes a key-value map associated with the current state of the current block, the current state of the blockchain network is determined by accumulating each accumulator commitment stored in each previous block of the blockchain network, wherein each new block in the blockchain network stores a reference back to a accumulator commitment of a previous block of the blockchain network, and wherein one or more key-value pairs of the accumulator commitment of the previous block comprises information that verifies at least one transaction of the current block.
  • the at least one processor is further programmed or configured to: transform each key-value pair of the plurality of key- value pairs of the accumulator commitment by: encode a plurality of keys of the plurality of key-value pairs into a probabilistic data structure by encoding the plurality of keys to include a test indicator that provides a signal in response to determining a 5UJ0107.
  • DOCX Page 3 of 92 Attorney Docket No.08223-2400886 (6654WO01) specified key is in a set; and compress a plurality of values of the plurality of key-value pairs into a compact format that provides access to information associated with the plurality of values when compared to one or more test values.
  • the at least one processor is further programmed or configured to: generate a compact representation of the plurality of keys by hashing each key of the plurality of keys and resetting bits for each hashed key based on one or more resulting hash values, the compact representation of the plurality of keys is configured to store the plurality of keys and information for querying the one or more key-value pairs.
  • the accumulator commitment is associated with a key-value map, wherein access to a plurality of values of the accumulator commitment is provided in response to a proof of knowledge determination of the key-value map for a key in the accumulator commitment, and wherein one or more blocks participate in transaction verification based only on commitment to a state without storing a current state of the blockchain network.
  • the state of each previous block in the blockchain network is cryptographically included in each subsequent block as a commitment to a previous state of the blockchain network.
  • each encoded key of a plurality of encoded keys of the accumulator commitment are each represented by a corresponding hexadecimal string based on the one or more key-value pairs and are compacted to between 2-bytes and 6-bytes.
  • a computer- implemented method comprising: Generating an accumulator commitment for a plurality of key-value pairs of a block in a blockchain network, the accumulator commitment cryptographically adding each key-value commitment of the block; obtaining a new transaction for the block; determining a membership proof or non- membership proof to verify at least one accumulated value from one or more previous transactions; and authenticating the new transaction based on at least one proof to verify membership or non-membership based on the at least one accumulated value.
  • the vector commitment increases in length to commit each key-value commitment stored by the accumulator commitment, and the increases in the length of the vector commitment comprise a plurality of keys that commit a domain of the accumulator commitment.
  • each key-value pair of the plurality of key-value pairs of the accumulator commitment by: encode a plurality of keys of the plurality of key-value pairs into a probabilistic data structure by encoding the plurality of keys to include a test indicator that provides a signal in response to determining a specified key is in a set; and compress a plurality of values of the plurality of key-value pairs into a compact format that provides access to information associated with the plurality of values when compared to one or more test values.
  • encoding the plurality of keys using a probabilistic data structure comprises: generating a compact representation of the plurality of keys by hashing each key of the plurality of keys and resetting bits for each hashed key based on one or more resulting hash values, the compact representation of the plurality of keys is configured to store the plurality of keys and information for querying the one or more key-value pairs.
  • the accumulator commitment is associated with a key-value map, wherein access to a plurality of values of the accumulator commitment is provided in response to a proof of knowledge determination of the key-value map for a key in the accumulator commitment, and wherein one or more blocks participate in transaction verification based only on commitment to a state without storing a current state of the blockchain network.
  • the state of each previous block in the blockchain network is cryptographically included in each subsequent block as a commitment to a previous state of the blockchain network.
  • each encoded key of a plurality of encoded keys of the accumulator commitment are each represented by a corresponding hexadecimal string based on the one or more key-value pairs and are compacted to between 2-bytes and 6-bytes.
  • a computer program product comprising at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: generate an accumulator commitment for a plurality of key-value pairs of a block in a blockchain network, the accumulator commitment cryptographically adding each key-value commitment of the block; obtain a new transaction for the block; determine a membership proof or non-membership proof to verify at least one accumulated value from one or more previous transactions; and authenticate the new transaction based on at least one proof to verify membership or non-membership based on the at least one accumulated value.
  • the at least one non-transitory computer-readable medium includes further program instructions that, when executed by at least one processor, cause the at least one processor to: determine a multi-hop proof for a plurality of transactions; generate a vector commitment from the accumulator commitment by converting each key-value commitment of the plurality of 5UJ0107.DOCX Page 6 of 92 Attorney Docket No.08223-2400886 (6654WO01) key-value pairs of the accumulator commitment to a corresponding key-value commitment of the vector commitment; authenticate at least one second transaction by using at least one property of the vector commitment to execute the multi-hop proof; and update the accumulator commitment by adding a key-value pair to the accumulator commitment for the second transaction in response to verifying the second transaction based on the vector commitment.
  • a system comprising: at least one processor, configured to: generate a key-value commitment to a plurality of key-value pairs; determine a proof for a new transaction associated with a current block in a blockchain network based on an aggregation of transaction parameters from one or more previous transactions; verify the new transaction by authenticating the one or more previous transactions using a primitive of a vector commitment to solve the proof; and update the vector commitment by cryptographically adding a new key-value commitment to verify the new transaction.
  • the at least one processor is further configured to: determine the proof for the new transaction comprises: generate a plurality of proofs, each of the plurality of proofs corresponding to an operation of the vector commitment, the plurality of proofs comprising at least one proof configured to verify a state transition in a blockchain due to an addition of the new transaction. aggregate the plurality of proofs into a batch; verify the plurality of proofs in the batch based on a single computation of the vector commitment; and generate a verification result based on verifying the plurality of proofs.
  • the at least one processor is further configured to: generate an accumulator commitment from the vector commitment by converting each key-value pair of the plurality of key-value pairs of the vector commitment to a corresponding key-value pair of the accumulator commitment; and authenticate the new transaction by verifying membership or non-membership of the corresponding key-value pair in the accumulator commitment with at least one property of the accumulator commitment.
  • generating the accumulator commitment from the vector commitment extends the at least one property of the vector commitment to include one or more properties of the accumulator commitment for operating on a plurality of key-value commitments.
  • the at least one processor is further configured to: authenticate without revealing one or more intermediate state transitions or an entire key-value map of the blockchain network by using at least one primitive of the accumulator commitment to execute the proof to verify at least one of a signature, a proof of membership, a state of the vector commitment, or an amount associated with at least one transaction of the one or more previous transactions, and the proof is a multi-hop proof algorithm.
  • the at least one processor is further configured to: determine a current state of the blockchain network based on combining the vector commitment of the current block of the blockchain network with each previous vector commitment representing each previous block of the blockchain network, wherein a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of the blockchain network, the vector commitment includes a key-value map associated with the current state of the current block, the current state of the blockchain network is determined by aggregating each vector commitment stored in each previous block of the blockchain network, wherein each new block in the blockchain network stores a reference back to a vector commitment of a previous block of the blockchain network, and wherein one or more key-value pairs of the vector commitment of the previous block comprises information that verifies at least one transaction of the current block.
  • the at least one processor is further configured to: transform each key-value pair of the plurality of key-value pairs of the vector commitment; encode a plurality of keys of the plurality of key-value pairs into a probabilistic data structure by encoding the plurality of keys to include a test algorithm that provides a signal in response to determining a specified key is in a set; and compress a plurality of values of the plurality of key-value pairs into a compact format that provides access to information associated with the plurality of values when compared to one or more test values.
  • the at least one processor is further configured to: generate a compact representation of the plurality of keys by hashing each key of the plurality of keys and resetting bits for each hashed key based on one or more resulting hash values, the compact representation of the plurality of keys is configured to store the plurality of keys and information for querying the one or more key-value pairs.
  • the vector commitment provides a key-value map, wherein access to a plurality of values of the vector commitment is provided in response to a proof of knowledge determination of the key-value map for a key in the vector commitment, and wherein one or more blocks participate in transaction verification based only on commitment to a state without storing a current state of the blockchain network.
  • the state of each previous block in the blockchain network is cryptographically accumulated in each subsequent header of each subsequent block as a vector commitment to a previous state of the blockchain network.
  • encoding the vector commitment comprises encoding the plurality of values directly as a linear function to form a linear combination of one or more vector elements, and wherein additions, updates, modifications, and/or deletions of values to the vector commitment are made by updating the linear function directly, and each encoded key of a plurality of encoded keys of the vector commitment are represented by a corresponding hexadecimal string based on the one or more key-value pairs and are compacted between 2-bytes and 6- bytes.
  • a computer- implemented method comprising: generating a key-value commitment to a plurality of key-value pairs; determining a proof for a new transaction associated with a current block in a blockchain network based on an aggregation of transaction parameters from one or more previous transactions; verifying the new transaction by authenticating the one or more previous transactions using a primitive of a vector commitment to solve the proof; and updating the vector commitment by cryptographically adding a new key- value commitment to verify the new transaction.
  • determining the proof for the new transaction comprises: determining the proof for the new transaction comprises: generating a plurality of proofs, each of the plurality of proofs corresponding to an operation of the vector commitment, the plurality of proofs comprising at least one proof configured to verify a state transition in a blockchain due to an addition of the new transaction; aggregating the plurality of proofs into a batch; verifying the plurality of proofs in the batch based on a single computation of the vector 5UJ0107.DOCX Page 9 of 92 Attorney Docket No.08223-2400886 (6654WO01) commitment; and generating a verification result based on verifying the plurality of proofs.
  • verifying the new transaction comprises: authenticating, by a validator node, the one or more previous transactions without revealing one or more intermediate state transitions or an entire key-value map of the blockchain network by using at least one primitive of the accumulator commitment to execute the proof to verify at least one of a signature, a proof of membership, a state of the vector commitment, or an amount associated with at least one transaction of the one or more previous transactions, and the proof is a multi-hop proof algorithm.
  • determining a current state of the blockchain network based on combining the vector commitment of the current block of the blockchain network with each previous vector commitment representing each previous block of the blockchain network, wherein a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of the blockchain network, the vector commitment includes a key- value map associated with the current state of the current block, the current state of the blockchain network is determined by aggregating each vector commitment stored in each previous block of the blockchain network, wherein each new block in the blockchain network stores a reference back to a vector commitment of a previous block of the blockchain network, and wherein one or more key-value pairs of the vector commitment of the previous block comprises information that verifies at least one transaction of the current block.
  • a computer program product comprising at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: generate a key-value commitment to a plurality of key- value pairs; determine a proof for a new transaction associated with a current block in a blockchain network based on an aggregation of transaction parameters from one or more previous transactions; verify the new transaction by authenticating the one or more previous transactions using a primitive of a vector commitment to solve the proof; and update the vector commitment by cryptographically adding a new key-value commitment to verify the new transaction.
  • the at least one non-transitory computer-readable medium includes further program instructions that, when executed by at least one processor, cause the at least one processor to: generate a plurality of proofs, each of the plurality of proofs corresponding to an operation of the vector commitment, the plurality of proofs comprising at least one proof configured to verify a state transition in a blockchain due to an addition of the new transaction. aggregate the plurality of proofs into a batch; verify the plurality of proofs in the batch based on a single computation of the vector commitment; generate a verification result based on verifying the plurality of proofs.
  • a system comprising: at least one processor, configured to: generate an accumulator commitment for a plurality of key-value pairs of a block in a blockchain network, the accumulator commitment cryptographically adding each key- value commitment of the block; obtain a new transaction for the block; determine a membership proof or non-membership proof to verify at least one accumulated value from one or more previous transactions; and authenticate the new transaction based on at least one proof to verify membership or non-membership based on the at least one accumulated value.
  • Clause 2 The system of clause 1, wherein the at least one processor is further programmed or configured to: determine a multi-hop proof for a plurality of transactions; generate a vector commitment from the accumulator commitment by converting each key-value commitment of the plurality of key-value pairs of the accumulator commitment to a corresponding key-value commitment of the vector commitment; authenticate at least one second transaction by using at least one property of the vector commitment to execute the multi-hop proof; and update the accumulator commitment by adding a key-value pair to the accumulator commitment for the second transaction in response to verifying the second transaction based on the vector commitment.
  • Clause 3 The system of clause 1 or 2, wherein generating the vector commitment from the accumulator commitment extends at least one property of the accumulator commitment to include one or more properties of the vector commitment to operate on the plurality of key-value pairs, wherein the vector commitment increases in length to commit each key-value commitment stored by the accumulator commitment, and the increases in the length of the vector commitment comprise a plurality of keys that commit a domain of the accumulator commitment.
  • Clause 4 The system of any of clauses 1-3, wherein the at least one processor is further programmed or configured to: determine a current state of the blockchain network based on combining the accumulator commitment of a current block of the blockchain network with each previous accumulator commitment representing each previous block of the blockchain network, wherein a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of the blockchain network, wherein the accumulator commitment includes a key-value map associated with the current state of the current block, wherein the current state of the blockchain network is determined by accumulating 5UJ0107.DOCX Page 12 of 92 Attorney Docket No.08223-2400886 (6654WO01) each accumulator commitment stored in each previous block of the blockchain network, wherein each new block in the blockchain network stores a reference back to a accumulator commitment of a previous block of the blockchain network, and wherein one or more key-value pairs of the accumulator commitment of the previous block comprises information that verifies at least one transaction of
  • Clause 5 The system of any of clauses 1-4, wherein the at least one processor is further programmed or configured to: transform each key-value pair of the plurality of key-value pairs of the accumulator commitment by: encode a plurality of keys of the plurality of key-value pairs into a probabilistic data structure by encoding the plurality of keys to include a test indicator that provides a signal in response to determining a specified key is in a set; and compress a plurality of values of the plurality of key-value pairs into a compact format that provides access to information associated with the plurality of values when compared to one or more test values.
  • Clause 6 The system of any of clauses 1-5, wherein the at least one processor is further programmed or configured to: generate a compact representation of the plurality of keys by hashing each key of the plurality of keys and resetting bits for each hashed key based on one or more resulting hash values, wherein the compact representation of the plurality of keys is configured to store the plurality of keys and information for querying the one or more key-value pairs.
  • Clause 7 The system of any of clauses 1-6, wherein the accumulator commitment is associated with a key-value map, wherein access to a plurality of values of the accumulator commitment is provided in response to a proof of knowledge determination of the key-value map for a key in the accumulator commitment, and wherein one or more blocks participate in transaction verification based only on commitment to a state without storing a current state of the blockchain network.
  • Clause 8 The system of any of clauses 1-7, wherein the state of each previous block in the blockchain network is cryptographically included in each subsequent block as a commitment to a previous state of the blockchain network.
  • Clause 9 The system of any of clauses 1-8, wherein each encoded key of a plurality of encoded keys of the accumulator commitment are each represented by a corresponding hexadecimal string based on the one or more key-value pairs and are compacted to between 2-bytes and 6-bytes.
  • Clause 10 A computer-implemented method, comprising: Generating an accumulator commitment for a plurality of key-value pairs of a block in a blockchain 5UJ0107.DOCX Page 13 of 92 Attorney Docket No.08223-2400886 (6654WO01) network, the accumulator commitment cryptographically adding each key-value commitment of the block; obtaining a new transaction for the block; determining a membership proof or non-membership proof to verify at least one accumulated value from one or more previous transactions; and authenticating the new transaction based on at least one proof to verify membership or non-membership based on the at least one accumulated value.
  • Clause 11 The computer-implemented method of clause 10, comprising: determining a multi-hop proof algorithm for a second transaction; generating a vector commitment from the accumulator commitment by converting each key-value commitment of the plurality of key-value pairs of the accumulator commitment to a corresponding key-value commitment of the vector commitment; authenticating the second transaction using at least one property of the vector commitment to execute the multi-hop proof algorithm; and updating the accumulator commitment by adding a key-value pair to the accumulator commitment for the second transaction in response to verifying the second transaction based on the vector commitment.
  • Clause 12 The computer-implemented method of clause 10 or 11, wherein generating the vector commitment from the accumulator commitment extends at least one property of the accumulator commitment to include one or more properties of the vector commitment to operate on the plurality of key-value pairs, wherein the vector commitment increases in length to commit each key-value commitment stored by the accumulator commitment, and the increases in the length of the vector commitment comprise a plurality of keys that commit a domain of the accumulator commitment.
  • Clause 13 The computer-implemented method of any of clauses 10-12, further comprising: determining a current state of the blockchain network based on combining the accumulator commitment of a current block of the blockchain network with each previous accumulator commitment representing each previous block of the blockchain network, wherein a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of the blockchain network, wherein the accumulator commitment includes a key-value map associated with the current state of the current block, wherein the current state of the blockchain network is determined by accumulating each accumulator commitment stored in each previous block of the blockchain network, wherein each new block in the blockchain network stores a reference back to a accumulator commitment of a previous block of the blockchain network, and wherein one or more key-value pairs of the accumulator 5UJ0107.
  • DOCX Page 14 of 92 Attorney Docket No.08223-2400886 (6654WO01) commitment of the previous block comprises information that verifies at least one transaction of the current block.
  • Clause 14 The computer-implemented method of any of clauses 10-13, further comprising: transform each key-value pair of the plurality of key-value pairs of the accumulator commitment by: encode a plurality of keys of the plurality of key-value pairs into a probabilistic data structure by encoding the plurality of keys to include a test indicator that provides a signal in response to determining a specified key is in a set; and compress a plurality of values of the plurality of key-value pairs into a compact format that provides access to information associated with the plurality of values when compared to one or more test values.
  • Clause 15 The computer-implemented method of any of clauses 10-14, wherein encoding the plurality of keys using a probabilistic data structure comprises: generating a compact representation of the plurality of keys by hashing each key of the plurality of keys and resetting bits for each hashed key based on one or more resulting hash values, wherein the compact representation of the plurality of keys is configured to store the plurality of keys and information for querying the one or more key-value pairs.
  • Clause 16 The computer-implemented method of any of clauses 10-15, wherein the accumulator commitment is associated with a key-value map, wherein access to a plurality of values of the accumulator commitment is provided in response to a proof of knowledge determination of the key-value map for a key in the accumulator commitment, and wherein one or more blocks participate in transaction verification based only on commitment to a state without storing a current state of the blockchain network.
  • Clause 17 The computer-implemented method of any of clauses 10-16, wherein the state of each previous block in the blockchain network is cryptographically included in each subsequent block as a commitment to a previous state of the blockchain network.
  • Clause 18 The computer-implemented method of any of clauses 10-17, wherein each encoded key of a plurality of encoded keys of the accumulator commitment are each represented by a corresponding hexadecimal string based on the one or more key-value pairs and are compacted to between 2-bytes and 6-bytes.
  • a computer program product comprising at least one non- transitory computer-readable medium including program instructions that, when 5UJ0107.DOCX Page 15 of 92 Attorney Docket No.08223-2400886 (6654WO01) executed by at least one processor, cause the at least one processor to: generate an accumulator commitment for a plurality of key-value pairs of a block in a blockchain network, the accumulator commitment cryptographically adding each key-value commitment of the block; obtain a new transaction for the block; determine a membership proof or non-membership proof to verify at least one accumulated value from one or more previous transactions; and authenticate the new transaction based on at least one proof to verify membership or non-membership based on the at least one accumulated value.
  • Clause 20 The computer program product of clause 19, wherein the at least one non-transitory computer-readable medium includes further program instructions that, when executed by at least one processor, cause the at least one processor to: determine a multi-hop proof for a plurality of transactions; generate a vector commitment from the accumulator commitment by converting each key-value commitment of the plurality of key-value pairs of the accumulator commitment to a corresponding key-value commitment of the vector commitment; authenticate at least one second transaction by using at least one property of the vector commitment to execute the multi-hop proof; and update the accumulator commitment by adding a key-value pair to the accumulator commitment for the second transaction in response to verifying the second transaction based on the vector commitment.
  • a system comprising: at least one processor, configured to: generate a key-value commitment to a plurality of key-value pairs; determine a proof for a new transaction associated with a current block in a blockchain network based on an aggregation of transaction parameters from one or more previous transactions; verify the new transaction by authenticating the one or more previous transactions using a primitive of a vector commitment to solve the proof; and update the vector commitment by cryptographically adding a new key-value commitment to verify the new transaction.
  • Clause 22 The system of clause 21, wherein the at least one processor is further configured to: determine the proof for the new transaction comprises: generate a plurality of proofs, each of the plurality of proofs corresponding to an operation of the vector commitment, the plurality of proofs comprising at least one proof configured to verify a state transition in a blockchain due to an addition of the new transaction. aggregate the plurality of proofs into a batch; verify the plurality of proofs in the batch 5UJ0107.DOCX Page 16 of 92 Attorney Docket No.08223-2400886 (6654WO01) based on a single computation of the vector commitment; and generate a verification result based on verifying the plurality of proofs.
  • Clause 23 The system of clause 21 or 22, wherein the at least one processor is further configured to: generate an accumulator commitment from the vector commitment by converting each key-value pair of the plurality of key-value pairs of the vector commitment to a corresponding key-value pair of the accumulator commitment; and authenticate the new transaction by verifying membership or non- membership of the corresponding key-value pair in the accumulator commitment with at least one property of the accumulator commitment.
  • Clause 24 The system of any of clauses 21-23, wherein generating the accumulator commitment from the vector commitment extends the at least one property of the vector commitment to include one or more properties of the accumulator commitment for operating on a plurality of key-value commitments.
  • Clause 25 The system of any of clauses 21-24, wherein the at least one processor is further configured to: authenticate without revealing one or more intermediate state transitions or an entire key-value map of the blockchain network by using at least one primitive of the accumulator commitment to execute the proof to verify at least one of a signature, a proof of membership, a state of the vector commitment, or an amount associated with at least one transaction of the one or more previous transactions, and wherein the proof is a multi-hop proof algorithm.
  • Clause 26 The system of any of clauses 21-25, wherein the at least one processor is further configured to: determine a current state of the blockchain network based on combining the vector commitment of the current block of the blockchain network with each previous vector commitment representing each previous block of the blockchain network, wherein a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of the blockchain network, wherein the vector commitment includes a key-value map associated with the current state of the current block, wherein the current state of the blockchain network is determined by aggregating each vector commitment stored in each previous block of the blockchain network, wherein each new block in the blockchain network stores a reference back to a vector commitment of a previous block of the blockchain network, and wherein one or more key-value pairs of the vector commitment of the previous block comprises information that verifies at least one transaction of the current block.
  • Clause 27 The system of any of clauses 21-26, wherein the at least one processor is further configured to: transform each key-value pair of the plurality of key- value pairs of the vector commitment; encode a plurality of keys of the plurality of key- value pairs into a probabilistic data structure by encoding the plurality of keys to include a test algorithm that provides a signal in response to determining a specified key is in a set; and compress a plurality of values of the plurality of key-value pairs into a compact format that provides access to information associated with the plurality of values when compared to one or more test values.
  • Clause 28 The system of any of clauses 21-27, wherein the at least one processor is further configured to: generate a compact representation of the plurality of keys by hashing each key of the plurality of keys and resetting bits for each hashed key based on one or more resulting hash values, wherein the compact representation of the plurality of keys is configured to store the plurality of keys and information for querying the one or more key-value pairs.
  • Clause 29 The system of any of clauses 21-28, wherein the vector commitment provides a key-value map, wherein access to a plurality of values of the vector commitment is provided in response to a proof of knowledge determination of the key-value map for a key in the vector commitment, and wherein one or more blocks participate in transaction verification based only on commitment to a state without storing a current state of the blockchain network.
  • Clause 30 The system of any of clauses 21-29, wherein the state of each previous block in the blockchain network is cryptographically accumulated in each subsequent header of each subsequent block as a vector commitment to a previous state of the blockchain network.
  • Clause 31 The system of any of clauses 21-30, wherein encoding the vector commitment comprises encoding the plurality of values directly as a linear function to form a linear combination of one or more vector elements, and wherein additions, updates, modifications, and/or deletions of values to the vector commitment are made by updating the linear function directly, and each encoded key of a plurality of encoded keys of the vector commitment are represented by a corresponding hexadecimal string based on the one or more key-value pairs and are compacted between 2-bytes and 6- bytes.
  • Clause 32 A computer-implemented method, comprising: generating a key- value commitment to a plurality of key-value pairs; determining a proof for a new 5UJ0107.DOCX Page 18 of 92 Attorney Docket No.08223-2400886 (6654WO01) transaction associated with a current block in a blockchain network based on an aggregation of transaction parameters from one or more previous transactions; verifying the new transaction by authenticating the one or more previous transactions using a primitive of a vector commitment to solve the proof; and updating the vector commitment by cryptographically adding a new key-value commitment to verify the new transaction.
  • determining the proof for the new transaction comprises: determining the proof for the new transaction comprises: generating a plurality of proofs, each of the plurality of proofs corresponding to an operation of the vector commitment, the plurality of proofs comprising at least one proof configured to verify a state transition in a blockchain due to an addition of the new transaction; aggregating the plurality of proofs into a batch; verifying the plurality of proofs in the batch based on a single computation of the vector commitment; and generating a verification result based on verifying the plurality of proofs.
  • Clause 34 The computer-implemented method of clause 32 or 33, further comprising: generating an accumulator commitment from the vector commitment by converting each key-value pair of the plurality of key-value pairs of the vector commitment to a corresponding key-value pair of the accumulator commitment; and authenticating the new transaction by verifying membership or non-membership of the corresponding key-value pair in the accumulator commitment with at least one property of the accumulator commitment.
  • Clause 35 The computer-implemented method of any of clauses 32-34, wherein generating the accumulator commitment from the vector commitment extends the at least one property of the vector commitment to include one or more properties of the accumulator commitment for operating on a plurality of key-value commitments.
  • Clause 36 The computer-implemented method of any of clauses 32-35, wherein verifying the new transaction comprises: authenticating, by a validator node, the one or more previous transactions without revealing one or more intermediate state transitions or an entire key-value map of the blockchain network by using at least one primitive of the accumulator commitment to execute the proof to verify at least one of a signature, a proof of membership, a state of the vector commitment, or an amount associated with at least one transaction of the one or more previous transactions, and wherein the proof is a multi-hop proof algorithm.
  • Clause 37 The computer-implemented method of any of clauses 32-36, further comprising: determining a current state of the blockchain network based on combining the vector commitment of the current block of the blockchain network with each previous vector commitment representing each previous block of the blockchain network, wherein a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of the blockchain network, wherein the vector commitment includes a key-value map associated with the current state of the current block, wherein the current state of the blockchain network is determined by aggregating each vector commitment stored in each previous block of the blockchain network, wherein each new block in the blockchain network stores a reference back to a vector commitment of a previous block of the blockchain network, and wherein one or more key-value pairs of the vector commitment of the previous block comprises information that verifies at least one transaction of the current block.
  • Clause 38 The computer-implemented method of any of clauses 32-37, further comprising: transforming each key-value pair of the plurality of key-value pairs of the vector commitment; encoding a plurality of keys of the plurality of key-value pairs into a probabilistic data structure by encoding the plurality of keys to include a test algorithm that provides a signal in response to determining a specified key is in a set; and compressing a plurality of values of the plurality of key-value pairs into a compact format that provides access to information associated with the plurality of values when compared to one or more test values.
  • a computer program product comprising at least one non- transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: generate a key-value commitment to a plurality of key-value pairs; determine a proof for a new transaction associated with a current block in a blockchain network based on an aggregation of transaction parameters from one or more previous transactions; verify the new transaction by authenticating the one or more previous transactions using a primitive of a vector commitment to solve the proof; and update the vector commitment by cryptographically adding a new key-value commitment to verify the new transaction.
  • Clause 40 The computer program product of clause 39, wherein the at least one non-transitory computer-readable medium includes further program instructions that, when executed by at least one processor, cause the at least one processor to: generate a plurality of proofs, each of the plurality of proofs corresponding to an 5UJ0107.DOCX Page 20 of 92 Attorney Docket No.08223-2400886 (6654WO01) operation of the vector commitment, the plurality of proofs comprising at least one proof configured to verify a state transition in a blockchain due to an addition of the new transaction.
  • FIG. 1 is a schematic diagram of a blockchain system for key-value commitments from accumulators and vector commitments according to some non- limiting embodiments or aspects;
  • FIG. 2 is a schematic diagram of a blockchain system implementing key- value commitments from accumulators and vector commitments according to some non-limiting embodiments or aspects;
  • FIG.3 is a flow diagram of a method for key-value commitments from vector commitments according to some non-limiting embodiments or aspects; [0096] FIG.
  • FIG. 4 is a flow diagram of a method for key-value commitment from accumulator commitments according to some non-limiting embodiments or aspects; and 5UJ0107.DOCX Page 21 of 92 Attorney Docket No.08223-2400886 (6654WO01) [0097]
  • FIG.5 illustrates example components of a device according to some non- limiting embodiments or aspects. DETAILED DESCRIPTION [0098]
  • the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and derivatives thereof shall relate to the embodiments as they are oriented in the drawing figures.
  • satisfying a threshold may refer to a value being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc.
  • the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more” and “at least one.”
  • the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, and/or the like) and may be used interchangeably with “one or more” or “at least one.” Where only one item is intended, the term “one” or similar language is used.
  • the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based at least partially on” unless explicitly stated otherwise.
  • references to an action being “based on” a condition may refer to the action being “in response to” the condition.
  • the phrases “based on” and “in response to” may, in some non-limiting embodiments or aspects, refer to a condition for automatically triggering 5UJ0107.
  • DOCX Page 22 of 92 Attorney Docket No.08223-2400886 (6654WO01) an action e.g., a specific operation of an electronic device, such as a computing device, a processor, and/or the like.
  • the term “communication” may refer to the reception, receipt, transmission, transfer, provision, and/or the like of data (e.g., information, signals, messages, instructions, commands, and/or the like).
  • one unit e.g., a device, a system, a component of a device or system, combinations thereof, and/or the like
  • another unit means that the one unit is able to directly or indirectly receive information from and/or transmit information to the other unit.
  • This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and/or the like) that is wired and/or wireless in nature.
  • two units may be in communication with each other even though the information transmitted may be modified, processed, relayed, and/or routed between the first and second unit.
  • a first unit may be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit.
  • a first unit may be in communication with a second unit if at least one intermediary unit processes information received from the first unit and communicates the processed information to the second unit.
  • a message may refer to a network packet (e.g., a data packet and/or the like) that includes data. It will be appreciated that numerous other arrangements are possible.
  • the term “computing device” may refer to one or more electronic devices configured to process data.
  • a computing device may, in some examples, include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and/or the like.
  • a computing device may be a mobile device.
  • a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., watches, glasses, lenses, sensors, clothing, and/or the like), a personal digital assistant (PDA), and/or other like devices.
  • a computing device may also be a desktop computer or other form of non-mobile computer.
  • server may refer to or include one or more computing devices that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the Internet, although it will be 5UJ0107.
  • DOCX Page 23 of 92 Attorney Docket No.08223-2400886 (6654WO01) appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible.
  • system may refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of such, and/or the like).
  • references to “a device,” “a server,” “a processor,” and/or the like, as used herein, may refer to a previously-recited device, server, or processor that is recited as performing a previous step or function, a different device, server, or processor, and/or a combination of devices, servers, and/or processors.
  • a first device, a first server, or a first processor that is recited as performing a first step or a first function may refer to the same or different device, server, or processor recited as performing a second step or a second function.
  • the term “node” or “blockchain node” may refer to one or more devices (e.g., computer, mobile phone, connected devices, etc.) that participates in a blockchain system (e.g., a participant in the blockchain network responsible for maintaining a copy of the ledger and participating in network activities, etc.). Nodes may perform various roles and take on responsibilities within the blockchain network (e.g., miners, validators, users, etc.).
  • a node may maintain a copy of the entire blockchain network.
  • a node validates transactions and contributes information to a consensus mechanism.
  • Each node communicates with each of the other nodes in the blockchain system to propagate transactions, share updated information, determine consensus on the state of the blockchain, and/or the like.
  • Multiple nodes collectively validate and add blocks to the blockchain network, ensuring the integrity and security of the blockchain system.
  • a node may obtain or determine information about a blockchain network, such as, for example, determining the validity of transactions, the integrity of blocks, the condition of smart contracts, accounts, and/or the like.
  • Such blockchain information may be used to provide the truth of a blockchain at a specific moment (e.g., the state of the blockchain represented at a specific point in time, etc.) as a reliable reference point for analysis, reconstruction, and/or the like.
  • the term, “block” or a “block of a blockchain network” may refer to a component (e.g., an element of a blockchain, etc.).
  • a block may include a 5UJ0107.DOCX Page 24 of 92 Attorney Docket No.08223-2400886 (6654WO01) data structure with transactions that have been added to the blockchain in a sequential manner.
  • a block may comprise a batch or other logical grouping of valid transactions related to the block.
  • Each block may include a link (e.g., a hash, cryptographic structure, and/or the like) pointing to a previous block.
  • the link may create a chain of blocks (e.g., a blockchain, etc.).
  • a block comprises a number of transactions (e.g., multiple transactions, etc.) that may be validated by the network. Each block is validated before being added to the existing blockchain network.
  • Each of the blocks organizes transactions and maintains a chronological record of each transaction that has occurred in the blockchain network.
  • distributed ledger may refer to a decentralized database maintained across multiple nodes in the network, forming the foundation for immutable and transparent record-keeping capabilities of blockchain systems.
  • the decentralized database exists across multiple locations or among multiple participants of a blockchain network.
  • Each participant or node in the network may include copy of the ledger.
  • Changes to the ledger may be propagated to participants in a decentralized manner.
  • the distributed ledger is formed by the chain of blocks containing transaction records. Each block may be linked to the previous one through cryptographic hashes, creating a chronological and immutable record of transactions.
  • Each node in the blockchain network maintains a copy of the distributed ledger. This ensures redundancy and resilience, as the ledger is not stored in a single location and is not controlled by a central authority. Changes to the ledger, such as the addition of new transactions in a block, are synchronized across all nodes through a consensus mechanism.
  • consensus mechanisms such as proof of work (PoW) or proof of stake, ensure that all nodes in the network agree on the validity of transactions and the state of the ledger. This consensus is reached through a process that involves the majority of participants in the network agreeing on the next valid block to be added to the chain.
  • the term "primitive” may refer a fundamental cryptographic operation or building block used in the process of creating and verifying accumulator commitments or vector commitments. Specifically, these primitives include the operations and algorithms used for creating accumulator commitments or vector commitments, including cryptographic operations that combine multiple key-value pairs into a single, compact commitment, use hash functions and/or other cryptographic techniques to ensure the commitment is secure and efficient.
  • the term “acquirer institution” may refer to an entity licensed and/or approved by a transaction service provider to originate transactions (e.g., payment transactions) using a payment device associated with the transaction service provider.
  • the transactions the acquirer institution may originate may include payment transactions (e.g., purchases, original credit transactions (OCTs), account funding transactions (AFTs), and/or the like).
  • an acquirer institution may be a financial institution, such as a bank.
  • the term “acquirer system” may refer to one or more computing devices operated by or on behalf of an acquirer institution, such as a server computer executing one or more software applications.
  • the term “account identifier” may include one or more primary account numbers (PANs), tokens, or other identifiers associated with a customer account.
  • PANs primary account numbers
  • token may refer to an identifier that is used as a substitute or replacement identifier for an original account identifier, such as a PAN.
  • Account identifiers may be alphanumeric or any combination of characters and/or symbols.
  • Tokens may be associated with a PAN or other original account identifier in one or more data structures (e.g., one or more databases, and/or the like) such that they may be used to conduct a transaction without directly using the original account identifier.
  • an original account identifier such as a PAN
  • the terms “electronic wallet” and “electronic wallet application” refer to one or more electronic devices and/or software applications 5UJ0107.DOCX Page 26 of 92 Attorney Docket No.08223-2400886 (6654WO01) configured to initiate and/or conduct payment transactions.
  • an electronic wallet may include a mobile device executing an electronic wallet application and may further include server-side software and/or databases for maintaining and providing transaction data to the mobile device.
  • An “electronic wallet provider” may include an entity that provides and/or maintains an electronic wallet for a customer, such as Google Pay®, Android Pay®, Apple Pay®, Samsung Pay®, and/or other like electronic payment systems.
  • an issuer bank may be an electronic wallet provider.
  • issuer institution may refer to one or more entities, such as a bank, that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and/or debit payments.
  • an issuer institution may provide an account identifier, such as a PAN, to a customer that uniquely identifies one or more accounts associated with that customer.
  • the account identifier may be embodied on a portable financial device, such as a physical financial instrument, e.g., a payment card, and/or may be electronic and used for electronic payments.
  • issuer system refers to one or more computer devices operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications.
  • an issuer system may include one or more authorization servers for authorizing a transaction.
  • the term “merchant” may refer to an individual or entity that provides goods and/or services, or access to goods and/or services, to customers based on a transaction, such as a payment transaction.
  • the term “merchant” or “merchant system” may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer executing one or more software applications.
  • a “point-of-sale system,” as used herein, may refer to one or more computers and/or peripheral devices used by a merchant to engage in payment transactions with customers, including one or more card readers, near-field communication (NFC) receivers, RFID receivers, and/or other contactless transceivers or receivers, contact-based receivers, payment terminals, computers, servers, input devices, and/or other like devices that may be used to initiate a payment transaction.
  • NFC near-field communication
  • RFID receivers RFID receivers
  • contactless transceivers or receivers contact-based receivers
  • payment terminals computers, servers, input devices, and/or other like devices that may be used to initiate a payment transaction.
  • the term “payment device” may refer to a payment card (e.g., a credit or debit card), a gift card, a smartcard, smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account 5UJ0107.
  • DOCX Page 27 of 92 Attorney Docket No.08223-2400886 (6654WO01) information a keychain device or fob, an RFID transponder, a retailer discount or loyalty card, a cellular phone, an electronic wallet mobile application, a personal digital assistant (PDA), a pager, a security card, a computing device, an access card, a wireless terminal, a transponder, and/or the like.
  • the payment device may include volatile or non-volatile memory to store information (e.g., an account identifier, a name of the account holder, and/or the like).
  • the term “payment gateway” may refer to an entity and/or a payment processing system operated by or on behalf of such an entity (e.g., a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator that contracts with an acquirer, a payment aggregator, and/or the like), which provides payment services (e.g., transaction service provider payment services, payment processing services, and/or the like) to one or more merchants.
  • the payment services may be associated with the use of portable financial devices managed by a transaction service provider.
  • the term “payment gateway system” may refer to one or more computer systems, computer devices, servers, groups of servers, and/or the like, operated by or on behalf of a payment gateway.
  • the term “transaction service provider” may refer to an entity that receives transaction authorization requests from merchants or other entities and provides guarantees of payment, in some cases through an agreement between the transaction service provider and an issuer institution.
  • a transaction service provider may include a payment network such as Visa® or any other entity that processes transactions.
  • transaction processing system may refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications.
  • a transaction processing server may include one or more processors and, in some non-limiting embodiments, may be operated by or on behalf of a transaction service provider.
  • public key encryption may refer to encoding a message to protect it from unwanted viewers by passing the message through a mathematical function (called a “cipher”) which uses a key to hide the original values in the message, and decoding the message depends on having the key that returns the values back to their original state, allowing the message to be read.
  • public key encryption e.g., asymmetric encryption
  • It’s called public key because one key is made widely available (the “public key”) while the other is kept private (the “private key”) to ensure the security of the message.
  • Public key encryption relies on private keys being kept secure, secret, and unavailable to those who may intercept, attack, or adulterate messages. Whether the public key is used to encrypt or verify the message depends on the nature of the message.
  • the private key is used to sign a message anyone may read, but cannot tamper with, at least without invalidating the signature.
  • everyone is able to encrypt a message, but not open it (e.g., not able to be intercepted by the wrong person, etc.)
  • it is encrypted with the public key, but only decrypted with the associated private key.
  • hashing e.g., a hash function
  • Hash functions are one-way algorithms, based on a mathematical function which takes an arbitrary input message and produces a deterministic output (e.g. a message digest).
  • hashing a message commonly serves one of two purposes, to protect the confidentiality of secret information (e.g. to validate the correctness of a password) or to confirm a message has been unmodified (e.g. to confirm the integrity of downloaded software).
  • message integrity may be determined, by hashing a copy of the original message and comparing the result to the original message’s digest value. One does not need to read the message itself to determine that the message has not been modified, just need the output of hashing the message (e.g., message digest).
  • satisfying a threshold may refer to a value (e.g., a score, a power consumption, etc.) being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc.
  • a value e.g., a score, a power consumption, etc.
  • each of the blocks e.g., each block of a blockchain 5UJ0107.DOCX Page 29 of 92 Attorney Docket No.08223-2400886 (6654WO01) network, ledger, etc.
  • a complete state of the blockchain network e.g., a complete ledger of the blockchain network, etc.
  • storing the entire state of the blockchain network also requires availability of significant processing, storage and capacity resources. Additionally, as the blockchain network grows in size, and the number of transactions increases, storage of the state of each node may become a bottleneck for processing transactions.
  • each node of the blockchain system may synchronize a local state of the blockchain network (e.g., while operating on a current or active block with a state associated with each of the other blocks of the blockchain network, etc.).
  • the synchronization process involves time-consuming and resource-intensive operations that must be performed for each node (e.g., downloading block information, verifying, storing, encrypting, etc.) to account for each block (e.g., each of a plurality of stored blocks, ledgers, ancestor/parent blocks, etc.).
  • Pruning may involve removing unnecessary or obsolete data from 5UJ0107.
  • Archiving may involve storing historical data that is no longer actively used but may be needed for auditing, compliance, or other purposes.
  • pruning and archiving may also change the integrity and consistency of the pruned data across the entire blockchain network.
  • data when data is pruned or archived, it can affect the integrity and consistency of the blockchain network.
  • pruned or archived data may no longer be available for verification, which can impact the integrity of the blockchain.
  • changes to the data structure resulting from pruning or archiving may lead to inconsistencies across the network, as some nodes may have access to different subsets of data than others.
  • KVC key-value commitments
  • ACC accumulator commitments
  • VC vector commitments
  • a commitment to the state of each block of the blockchain network may be generated more accurately and efficiently with KVC from ACC and VC. In this way, a more accurate and efficient synchronization occurs as a new block joins the network (or an existing block moves offline, comes back online, etc.).
  • Nodes may quickly synchronize with the entire blockchain network by obtaining a commitment to the state for efficiently verifying the state changes in each block of the blockchain network based on the novel primitives described in some non-limiting embodiments or aspects (e.g., a VC, an accumulator commitment, etc.).
  • a commitment to the state of each block of the blockchain network eliminates a need to transmit the entire state of the blockchain network, such as, for example, to a central repository. This also eliminates a significant 5UJ0107.DOCX Page 31 of 92 Attorney Docket No.08223-2400886 (6654WO01) amount of bandwidth use and reduces a necessity for a significant amount of transmission data that would otherwise be needed for unnecessary transmissions. In this way, network efficiency is improved along with reducing bandwidth requirements.
  • a blockchain network with KVC from accumulators and VC allows each block of the blockchain network to store only a commitment to the state that may be used to determine information about the blockchain.
  • a blockchain network with KVC from accumulators and VC provide more accurate and efficient pruning and/or archiving of historical data while still maintaining commitments for verifying integrity of the blockchain. This enables nodes to participate in transaction validation without the need to store the entire state of the ledger for more accurate, accessible, efficient, and scalable communication.
  • FIG.1 shown is a diagram of blockchain network 100 with KVC from accumulators and VC, according to some non-limiting embodiments or aspects.
  • the blockchain network 100 provides a decentralized, distributed ledger that may be public or private. As shown in FIG.
  • blockchain network 100 includes first block 102a, second block 102b, and third block 102n (e.g., referred to collectively as blocks 102a-102n, list of blocks 102a-102n, etc.). Each of blocks 102a-102n, include a respective set of transactions 104a-104n. [0132] In some non-limiting embodiments or aspects, blockchain network 100 is arranged so that the data is stored in blocks 102a-102n. In some examples, the data stored in the blocks 102a-102n may not be altered without the consensus of the entire blockchain network (e.g., each computer, device, system, and/or the like participating in the blockchain system, etc.).
  • a key-value pair comprises a pair of data elements where the key may comprise a unique identifier and the value may comprise the associated data.
  • the KVC allows for efficient and secure storage and retrieval of these key-value pairs, where a commitment value is computed based on the pairs and the party may later prove that a particular key-value pair was included in the commitment.
  • blocks 102a-102n include variables (e.g., one or more fields in a header, etc.) that store information about the location of a variable in another block.
  • blockchain network 100 may include P1, P2, and P3 which may link the list of blocks.
  • blockchain network 100 may include a sequence of blocks (102a, 102b, ... 102n, etc.), where each of the blocks (e.g., 102a, 102b, ...102n) has specific data and links to the following block via a pointer, another structure, and/or the like.
  • block 102a may point to a position of a variable in block 102b
  • block 102b may point to a position of another variable in block 102c, and so on and so forth, until block 102n, which is the current block.
  • Blocks 102a-102n form a chain of blocks which contain specific information (e.g., a blockchain, a distributed database, a distributed ledger, etc.).
  • first block 102a may not contain a pointer since it is the first in a chain.
  • a blockchain combines a secure group of blocks together into a network (e.g., peer-to-peer (“P2P”), etc.). The chain also provides decentralization to blockchain network 100.
  • P2P peer-to-peer
  • blockchain network 100 is a combination of computers and blocks that are decentralized by linking to each other instead of a central server.
  • the structure of blockchain network 100 is represented by the list of blocks 102a-102n with transactions in a particular order.
  • blocks 102a-102n may be stored as a flat file or in the form of a simple database.
  • a blockchain consists of a secure series of blocks organized into a network, as an example, operating on a peer- to-peer (P2P) basis. This chain of blocks ensures decentralization within blockchain network 100.
  • Blockchain network 100 comprises interconnected computers and blocks, distributing authority across the network instead of relying on a central server.
  • the structure of blockchain network 100 is delineated by a sequence of blocks (102a- 102n) shown in FIG.1.
  • each block includes transactions associated with blockchain network 100 and arranged in a specific order.
  • Blocks 102a-102n may be stored as a flat file or within a simple database. 5UJ0107.
  • DOCX Page 33 of 92 Attorney Docket No.08223-2400886 (6654WO01) [0138]
  • a key-value pair is stored in a KVC data structure that consists of a unique key and an associated value.
  • the key is a unique identifier that is used to look up the value associated with it.
  • This type of data structure is often used in programming languages, databases, and other systems to represent and manipulate data.
  • each record may be represented as a set of key-value pairs with each key corresponding to a field in the record and each value containing the data for that field.
  • a KVC in the blockchain network 100 provides a commitment (C) for a key-value pair (e.g. a key-value pair in KV-maps 106a, 106b, etc.) that may reveal (e.g., open, share, etc.) a commitment (C) for any specific key stored therein.
  • the KVC is concise for efficiency in storage and transmission.
  • KVC reduces the size (e.g., cryptographically, etc.) of the commitment (C) for storing significantly less than the size of a key-value map.
  • the KVC also is configured to receive and determine one or more updates to the KV-map 106a-106n, such as adding new key-value pairs or updating the value associated with an existing key.
  • the KVC includes dynamic changes to the data while maintaining the integrity of a KVC.
  • KV map M e.g., M ⁇ K ⁇ V
  • KV map M may comprise a collection of key-value pairs (k, v), such that KM represents the set of keys for which values have been stored in the map M.
  • the KVC may comprise a non- interactive primitive, such that, the KVC may be defined by specific algorithms that allow for the commitment to take place, as well as a later opening of the commitment (C) for any given key (e.g., specific keys may be later revealed or opened from the commitment, etc.) from which the associated value is obtained.
  • the KVC is configured to receive security parameters. In response to receiving the security parameters, the KVC produce correct proofs ⁇ k for each of the keys k in the key set KM. For example, KVC obtains each of the one or more security parameters ⁇ , one or more public parameters pp, the commitment (C) (e.g., obtained through a sequence of insert and update operations) to form a correctness requirement.
  • a key- value pair (k, v) is part of the map M, and then the verification algorithm Ver should output 1 with probability 1 when provided with C, (k, v), and the corresponding proof ⁇ k. 5UJ0107.
  • DOCX Page 34 of 92 Attorney Docket No.08223-2400886 (6654WO01) [0142]
  • a security requirement for KVC includes key binding that is computationally infeasible to attack for an adversary. For example, even with knowledge of the public parameters pp, to produce two different proofs for the same key or a proof for a key that has not been inserted, is computationally infeasible.
  • KVC restricts an adversary from executing the Insert operation more than once for any given key.
  • KVC comprises one or more membership proofs for ensuring integrity and authenticity of key-value mappings within blockchain network 100.
  • the membership proofs include non-membership proofs which extend to a demonstration that a key k' has not been inserted into the map.
  • the proofs comprise non-membership proofs (e.g., to prove non- membership, etc.), for updating non-membership proofs (e.g., a non-membership proof update), and verifying non-membership (e.g., KVC verification, etc.).
  • KVC is computed based on a set of key-value pairs, where each pair associates a unique key with a corresponding value.
  • the commitment value C is derived from the entire set of key-value pairs, and the party may later prove that a particular key-value pair was included in the commitment without revealing the other pairs.
  • Alice may want to commit to a set of key- value pairs (k1:v1, k2:v2, k3:v3).
  • Alice may compute a commitment value C based on these pairs using a cryptographic function such as a hash function. Alice may then publicly disclose the commitment value C without revealing the underlying key-value pairs.
  • KVCs allow for the efficient and secure storage and retrieval of sets of key-value pairs. A commitment value is computed based on the pairs, and the party can later prove that a particular key-value pair was included in the commitment.
  • blockchain network 100 includes first block 102a, second block 102b, and third block 102n (e.g., referred to collectively as blocks 102a-102n, list of blocks 102a-102n, etc.).
  • Each of blocks 102a-102n include a respective set of transactions 104a-104n.
  • the key-value pairs stored in each of blocks 102a-102n must be accurate and free from tampering (e.g., not tampered with, etc.).
  • anyone who wants to verify the state of a particular account may use cryptographic proofs to ensure the integrity of the set of transactions 104a-104n in blocks 102a-102n by demonstrating that a specified key-value pair was included in the commitment value.
  • the integrity of blocks 102a-102n may be demonstrated for a specified key- value pair stored therein without revealing any other key-value pairs in the commitment.
  • the commitment value represents the aggregated state of blockchain network 100 at a specific point in time. It serves as a summary or hash of all the data contained within blockchain network 100 up to that point. With cryptographic proofs, it becomes possible to verify the state of a particular account within blockchain network 100.
  • blockchain network 100 provides KV-maps 106a-106n comprising an accumulator of key-values for operating in an efficient and scalable blockchain network 100.
  • other applications that require the storage and retrieval of large numbers of key-value pairs may also operate with the new accumulator for KVC.
  • KV-maps 106a-106n may be performed by KV-maps 106a-106n, including key generation, insertion of new key- value pairs, updating the commitment, updating proofs, and verification of commitments and proofs.
  • KVC enables the secure and efficient generation and management of key-value mappings within a cryptographic framework.
  • key generation for KV-maps 106a-106n provides that: (pp,C) ⁇ $ KeyGen(1 ⁇ ).
  • key generation for KVC receives or obtains as input the security parameter ⁇ and outputs public parameters pp.
  • the key generation outputs public parameters pp that define the key and value spaces.
  • key insertion for KV-maps 106a-106n provides that: (C, ⁇ k, upd) ⁇ Insert(C, (k, v)).
  • the key insertion given a commitment string C and a key-value pair (k, v), outputs an updated commitment string C, and a proof ⁇ k (e.g., a proof demonstrating that v is the value corresponding to k).
  • Update information upd may also be included.
  • key update for KV-maps 106a-106n provides that: (C, upd) ⁇ Update(C, (k, ⁇ )).
  • this KVC update represents the update algorithm, based on a commitment string C, a key k, and an update value ⁇ .
  • KVC update outputs an updated commitment string C and update information upd.
  • this KVC update does not require knowledge of the value corresponding to the key k, thereby providing or allowing for efficient updates to the commitment.
  • proof update for KV-maps 106a-106n provides that: ⁇ k ⁇ ProofUpdate(k, ⁇ k, upd).
  • the proof update obtains or receives a key k, a proof ⁇ k for some value corresponding to k, and update information upd. Based on the input information, the proof update outputs an updated proof ⁇ k.
  • the proof update enables the updating of proofs to maintain correctness in the face of changes to the commitment.
  • correctness verifier for KV- maps 106a-106n provides that: 1/0 ⁇ Ver(C, (k, v), ⁇ k).
  • the correctness verifier receives a commitment string C, a key-value pair (k, v), and a proof ⁇ k.
  • the correctness verifier receives the inputs and generates outputs of either 1 (e.g., accept, etc.) or 0 (e.g., reject, etc.).
  • This algorithm verifies the correctness of the commitment and the proof for a given key-value pair.
  • oblivious accumulators or accumulators refer to a cryptographic data structure to support membership queries and dynamic updates to KV-maps 106a-106n without requiring a trapdoor.
  • accumulators which are used to efficiently manage and verify membership in a set while supporting dynamic updates, may operate in a trapdoorless setting.
  • a trapdoorless setting there may be no secret information (e.g., a 5UJ0107.DOCX Page 37 of 92 Attorney Docket No.08223-2400886 (6654WO01) trapdoor, etc.) required for updates.
  • participants in blockchain network 100 may have or obtain equal access to update the accumulator.
  • updates to KV-maps 106a- 106n may include accumulator commitments ACC 108a-108c.
  • ACC 108a comprises oblivious accumulators that provide positive membership queries to efficiently and accurately determine whether an element belongs to the set represented by ACC 108a.
  • ACC 108a-108n may support dynamic updates, allow for additions and deletions to the set without requiring a trapdoor for access, and/or the like.
  • updates to the ACC 108a- 108n are additive.
  • modifying a value v by an amount ⁇ involves changing v to v + ⁇ .
  • updates to ACC 108a-108n may include incrementing or decrementing existing values rather than replacing them entirely.
  • updates to the ACC include setup, addition, deletion, commitment, membership proof creation, proof update, verification, and/or the like, for improvements which enable secure management of set membership with dynamic updates within blockchain network 100.
  • a setup for ACC 108a-108n is provided by a setup algorithm (e.g., Acc.Setup, etc.).
  • a setup algorithm e.g., Acc.Setup, etc.
  • (pp,C0) ⁇ Acc.Setup(1 ⁇ ) represents the setup algorithm.
  • Acc.Setup obtains or receives the security parameter ⁇ , and then outputs public parameters pp, which implicitly define the accumulator domain D, and the initial accumulator value C0 for the empty set.
  • ACC 108a-108n provides an addition algorithm (e.g., Acc.Add, etc.).
  • an addition algorithm e.g., Acc.Add, etc.
  • U ⁇ u ⁇ and an element ⁇ belonging to the accumulator domain D
  • addition algorithm outputs update information u.
  • addition algorithm generates a membership proof wx demonstrating that ⁇ is in the accumulator and auxiliary information aux.
  • ACC 108a-108n provides a deletion algorithm (e.g., Acc.Del, etc.).
  • a deletion algorithm e.g., Acc.Del, etc.
  • u ⁇ Acc.Del (U, x, aux) represents the deletion algorithm.
  • U ⁇ u ⁇ , an element ⁇ belonging to the accumulator domain D, and auxiliary information aux.
  • the ACC deletion algorithm outputs update information u.
  • the deletion algorithm handles the removal of elements from the accumulator.
  • ACC 108a- 108n provides a commitment algorithm (e.g., Acc.Commit, etc.).
  • C ⁇ Acc.Commit (U) represents the commit algorithm.
  • commitment algorithm returns the accumulator value C. If all elements are added by the same entity, the set U may be viewed as ⁇ x, aux ⁇ .
  • addition for ACC 108a-108n provides a membership proof creation algorithm (e.g., Acc.WitCreate, etc.).
  • wx ⁇ Acc.WitCreate U, aux
  • membership proof creation algorithm outputs a membership proof wx demonstrating that ⁇ is in the accumulator.
  • the membership proof creation algorithm may create proofs for elements at any point in time, not necessarily during their addition.
  • addition for ACC 108a-108n provides a membership proof update algorithm (e.g., Acc.WitUpdate, etc.).
  • w′x ⁇ Acc.WitUpdate (wx, u) The membership proof update algorithm represents the witness update algorithm.
  • ACC 108a-108n provides a verification algorithm (e.g., Acc.Ver, etc.). For example, 0/1 ⁇ Acc.Ver(C, x, wx): This verification algorithm represents the verification algorithm. For example, given an accumulator value C, an element ⁇ belonging to the accumulator domain D, and a membership proof wx, it outputs either 1 (accept) or 0 (reject).
  • a verification algorithm e.g., Acc.Ver, etc.
  • This verification algorithm represents the verification algorithm. For example, given an accumulator value C, an element ⁇ belonging to the accumulator domain D, and a membership proof wx, it outputs either 1 (accept) or 0 (reject).
  • input for the commitment algorithm includes the set of updates U rather than the set of elements X. Accordingly, instead of directly providing the elements that have been 5UJ0107.DOCX Page 39 of 92 Attorney Docket No.08223-2400886 (6654WO01) added to or removed from the accumulator, the algorithm receives a set of updates that encapsulates these changes.
  • the deletion algorithm e.g., Acc.Del
  • the witness creation algorithm e.g., Acc.WitCreate, etc.
  • auxiliary information aux e.g., Acc.WitCreate, etc.
  • blockchain network 100 maintains accountability and prevents unauthorized removal or manipulation of elements and contributing to security and integrity of the accumulator within the blockchain network (e.g., the cryptographic framework, etc.).
  • Acc.Ver (C, x, wx) will output 1 for C being the output of accumulator commitment and wx being the output of accumulator witness create.
  • the verification algorithm where ⁇ is the accumulator value, ⁇ is the element being verified, and ⁇ is the membership proof for ⁇ .
  • membership soundness guarantees that a malicious entity that picks a set ⁇ cannot give a valid proof ⁇ for ⁇ not in ⁇ .
  • membership soundness represents the probability that a probabilistic polynomial-time (PPT) adversary may produce a valid proof for an element that is not in the set. If the probability is negligible, it ensures soundness. For example, for any PPT adversary A, the following holds: pp ⁇ Acc. Setup (1 ⁇ ) ⁇ ⁇ ⁇ Acc.
  • element hiding guarantees that a malicious entity that picks two elements in D cannot guess which one was added and then deleted given the updates and the accumulator value changes.
  • PPT adversary A the probability is determined, such that a PPT adversary may correctly guess which of two elements was added and then deleted from the accumulator. If the probability is at most equal to: 7 B + negl (6), this may indicate that the adversary's ability to distinguish is not significantly better than random chance.
  • add-delete indistinguishability guarantees that a malicious entity cannot guess whether an element ⁇ in the accumulator was deleted or a new element was added given the updates and the accumulator value changes.
  • PPT adversary A the following holds: 5UJ0107.DOCX Page 41 of 92 Attorney Docket No.08223-2400886 (6654WO01)
  • the probability is determined such that a PPT adversary may correctly guess whether an element in the accumulator was added or deleted based on accumulator value changes and updates. If the probability is at most equal to: + negl (6), this indicates that the adversary's ability to distinguish is not significantly better than using random chance.
  • add-delete unlinkability guarantees that a malicious entity that picks two elements in I cannot guess which one was deleted given the updates and the accumulator value changes.
  • PPT adversary + the following holds: [0178]
  • the above represents the probability that a PPT adversary may correctly guess which of two elements was added and then deleted from the accumulator. If the probability is at most 7 B + negl (6), this indicates that the adversary's ability to distinguish is not significantly better than random chance.
  • the following functionality of the accumulators e.g., ACC 108a, 108b ... 108n is provided.
  • Accumulators 108a- 108n may provide a cryptographic primitive used to aggregate and maintain a set of elements such that one may efficiently prove membership or non-membership of an element in the set. Accumulators 108a-108n provide operations for adding, deleting, and committing elements to the accumulator, as well as generating and updating membership witnesses. [0180] In some non-limiting embodiments or aspects, accumulators 108a-108n are set (e.g., input, initialized, etc.) by accumulator setup algorithm (e.g., Acc.Setup C1 ⁇ D) which interfaces and coordinates with KV-maps 106a-106n, to execute KVC.KeyGen.
  • accumulator setup algorithm e.g., Acc.Setup C1 ⁇ D
  • the accumulator setup algorithm initializes parameters required for the accumulator.
  • accumulator setup algorithm first runs the KVC.KeyGen function with the security parameter C1 ⁇ D to obtain public parameters (pp) and an initial commitment (C0) for the KVC.
  • the accumulator setup algorithm then defines ⁇ 0,1 ⁇ ⁇ ⁇ I ⁇ X, where X is the key domain of the KVC.
  • hash functions are defined to map elements to keys in the KVC key domain. These hash functions are typically defined to map elements to keys in the KVC key domain.
  • an accumulator addition algorithm intakes an element ⁇ and adds it to the accumulator, generating the necessary proofs and updating information in the process. For example, accumulator addition algorithm first selects a random value r. Accumulator addition algorithm then computes a key k based on the randomness r and the input value ⁇ using a hash function T 7 . [0182] In some non-limiting embodiments or aspects, accumulator addition algorithm inserts the key-value pair (Y, 1)) into the commitment C using the KVC.Insert operation. The accumulator addition algorithm generates a new commitment C and a proof ⁇ k, and also provides update information u.
  • accumulator addition algorithm e.g., Acc.Add
  • the accumulator addition algorithm releases the update information u. It then sets auxiliary information ⁇ to associate the value ⁇ with the randomness r.
  • the accumulator addition algorithm provides a witness ⁇ : based on the proofs generated during the insertion process.
  • the witness includes the proof C ⁇ [P( ⁇ ,:) ) associated with the hash of r and ⁇ , as well as another proof C ⁇ [P( ⁇ ,:) ) that is derived from additional processing involving r and ⁇ .
  • the witness ⁇ contains information necessary to verify the presence of ⁇ in the accumulator.
  • ⁇ : is set to ⁇ [P( ⁇ ,:) , ⁇ ⁇ ⁇ ⁇ [ ⁇ _ ⁇ ( ⁇ ⁇ ,: ⁇ ) D ⁇ .
  • KVC.Insert releases update information, sets auxiliary information, and sets a witness.
  • accumulator delete (e.g., Acc.Del, etc.) first parses the auxiliary information ⁇ , which is assumed to be in the form (x, r). This indicates that ⁇ is associated with randomness r. Based on the parsed auxiliary information (x, r), accumulator delete computes a key k using a hash function H2. Accumulator delete then executes the KVC.Insert operation to insert the key-value 5UJ0107.DOCX Page 43 of 92 Attorney Docket No.08223-2400886 (6654WO01) pair (k, 1) into the commitment C. This operation generates a new commitment C, a proof ⁇ k, and update information u.
  • Acc.Del removes an element ⁇ from the accumulator by computing the appropriate key k, inserting it into the commitment using the KVC.Insert operation and releasing the update information ⁇ .
  • the accumulator commit algorithm e.g., Acc.Commit
  • accumulator commit algorithm executes the KVC.Insert operation for each pair (Y,a) to update the commitment ⁇ accordingly.
  • accumulator commit algorithm returns the resulting commitment ⁇ .
  • a witness create algorithm (e.g., Acc.WitCreate) generates a witness for the element ⁇ based on the given set of updates F and the auxiliary information ⁇ , which is assumed to contain the pair ( ⁇ ,N). For each update ⁇ in F that does not involve ⁇ , the witness create algorithm parses F to extract key-value pairs (Y,a) and executes the KVC.Insert operation to update the commitment ⁇ accordingly. For the update involving ⁇ , the function parses the auxiliary information ⁇ to obtain the pair ( ⁇ , N). Then, it computes a key Y based on N and ⁇ using the hash function T 7 .
  • a witness create algorithm e.g., Acc.WitCreate
  • a witness update algorithm (e.g., Acc.WitUpdate) updates a witness ⁇ with new information ⁇ .
  • witness update algorithm receives the existing witness ⁇ and the update information ⁇ u as inputs.
  • witness update algorithm then updates the witness ⁇ ′ using the update information ⁇ and the existing proofs stored in ⁇ .
  • Acc.WitUpdate updates the witness ⁇ with new information ⁇ by updating the proofs associated with the hash functions and T B 5UJ0107.
  • accumulator verifier checks the validity of the witness ⁇ : associated with the element ⁇ in the accumulator ⁇ using the verification algorithms provided by the KVC for both hash functions and T B .
  • accumulator verifier e.g., Acc.Ver
  • the function decomposes ⁇ : into proofs associated with two hash functions: ⁇ [P( ⁇ ,:) and ⁇ [_( ⁇ ,:) .
  • the KVC map and the ACC 108a-108n are related by the KVC map.
  • the KVC map is a structure that stores key-value pairs (k, v) where k is the key and v is the corresponding value.
  • the KVC map is represented by a commitment string C that encapsulates the state of the KVC map after performing various operations like insertion and updates.
  • the accumulator commitment is another cryptographic primitive used to generate commitments to sets of updates (U, x) where U represents the set of all updates and ⁇ is an element being added or deleted.
  • the accumulator interfaces with the KVC map when generating commitments and proofs for key-value pairs. For example, in operations like addition (Acc.Add) and deletion (Acc.Del), the accumulator generates proofs and update tokens based on elements inserted or deleted.
  • KV-maps 106a-106n and ACC 108a-108n together 5UJ0107.
  • DOCX Page 45 of 92 Attorney Docket No.08223-2400886 (6654WO01) provide cryptographic functionalities such as commitment, proof generation, and verification for key-value pairs and updates.
  • VC 110a-110n may provide a cryptographic primitive used to aggregate and maintain a set of elements such that one may efficiently prove membership or non-membership of an element in the set.
  • VC 110a-110n provide operations for adding, deleting, and committing elements to the KVC, as well as generating and updating membership witnesses.
  • one or more operations provide KeyGen (Key Generation).
  • the KeyGen operation generates the public parameters (pp) for the VC. It takes as input the security parameter 6 ⁇ and the length of vectors d.
  • the output of KeyGen is the public parameters ee, which are used in subsequent operations of the VC.
  • KeyGen initializes the VC by generating public parameters ee, which are necessary for the initialization. These public parameters ee are typically used throughout the execution of the to perform commitments, openings, and other operations. [0193] In some non-limiting embodiments or aspects, the accumulator activates one or more operations or primitives of VC to handle dynamic key-value pairs while maintaining efficient proof and update mechanisms.
  • the accumulator activates one or more operations or primitives of VC to handle Key Generation: (ee, ⁇ ) ⁇ fg ⁇ Key klmC1 ⁇ D, f, g ⁇ ee initializes the key-value accumulator commitment (KVAC). Runs g ⁇ . Key Gen C1 ⁇ , 1D to get parameters for a vector of length 1. VC. Commit oo (0) is used to get initial commitments ⁇ ] and ⁇ p . The accumulator leverages a VC to build a KVAC. The improvement is that it inherits the efficient properties of VCs, including the ability to handle updates and proofs efficiently.
  • KVAC key-value accumulator commitment
  • the accumulator activates one or more operations or primitives of VC to handle Insertion: ( ⁇ , ⁇ ] , ⁇ ) ⁇ fg. Insert ( ⁇ , (Y, a)).
  • Extend Length(pp, q) is executed to extend the parameters for the vector length to d + 1
  • the accumulator activates one or more operations or primitives of VC to handle Verification: ⁇ fg ⁇ Ver( ⁇ , (Y, a), ⁇ ] ):Outputs the logical AND Y, pos, ⁇ xyz D and pos, ⁇ xyz D. Verification checks that a given key-value pair is correctly committed by checking the proofs against the current state of the VC for keys and values. When the data is updated, the proofs must also be updated to remain valid. by adjusting the proofs based on the changes in the committed data.
  • the accumulator activates one or more operations or primitives of VC to inherit all the properties of the VC, such as multi-hop aggregation.
  • accumulator commitment proves that a key is not part of the set.
  • a VC is a cryptographic primitive.
  • a VC allows for efficient and compact representation of a vector of data elements typically represented as a list or an array and provides efficient proofs of the existence or non-existence of a data element at a specific position (POS) in the vector.
  • KVC key-binding refers to the property of a KVC such that the commitments generated by the VC are bound to the keys and values they represent.
  • a commitment is made to a 5UJ0107.
  • KVC key-binding is formalized through a game between a challenger and an adversary, where the adversary tries to manipulate the commitments and proofs produced by the KVC.
  • the goal of this game is to ensure that even if the adversary has access to the public parameters of the KVC and may make certain queries to the challenger, they cannot produce fake proofs with a non- negligible probability.
  • KVC key-binding ensures the integrity and authenticity of the commitments in a KVC, preventing unauthorized modifications or forgeries.
  • a random variable is defined as k ⁇ bi ⁇ n ⁇ d , ⁇ , ⁇ through a game between a challenger ⁇ T and ⁇ as follows: k bind ⁇ ⁇ , ⁇ , ⁇ bind [0203]
  • ⁇ T samples (ee, ⁇ ) ⁇ $KeyGenC1 ⁇ D and sends them to ⁇ .
  • ⁇ T also maintains its own state comprising a key-value map ⁇ ⁇ f ⁇ g initialized to the empty map and the initial commitment value ⁇ .
  • ⁇ issues queries in one of the following forms: (Insert, (Y, a) ): ⁇ T checks if ⁇ contains a tuple of the form (Y, ⁇ ). If so, ⁇ T responds with ⁇ . If not, ⁇ T updates ⁇ to ⁇ ⁇ ⁇ (Y, a) ⁇ and executes Insert ( ⁇ , (Y, a)) to obtain a new commitment ⁇ . (Update, ): ⁇ T checks if ⁇ contains a tuple of the form (Y, a). If not, ⁇ T responds with ⁇ .
  • ⁇ T updates ⁇ to ( ⁇ ⁇ ⁇ (Y, a + ⁇ ) ⁇ ) ⁇ ⁇ (Y, a) ⁇ and executes Update( ⁇ , (Y, ⁇ )) to obtain a new commitment ⁇ .
  • A then sends a final output to ⁇ T of one of the following forms: Type 1: a key Y such that ⁇ does not contain a tuple of the form (Y, ⁇ ), a value a, and a proof ⁇ ] .
  • Type 2 a key Y such that ⁇ contains a tuple of the form (Y, ⁇ ), a pair of values (a, a >) where a ⁇ a > , and a pair of proofs ( ⁇ ] , ⁇ > ] ) .
  • ⁇ T outputs success.
  • the value of the random variable k ⁇ bi ⁇ n ⁇ d , ⁇ , ⁇ is defined to be the output of ⁇ T, namely, failure or success. 5UJ0107.
  • the commitment ⁇ is honestly generated by the challenger CH based on the queries issued by the adversary +.
  • the definition only uses the Insert and Update routines of the KVC, as these are the only two that impact the value of the commitment.
  • the adversary may perform all operations by itself given the public parameters.
  • the purpose of the game is to define the honestly generated commitment with respect to which the adversary will attempt to produce “fake” proofs.
  • no PPT adversary will be able to produce “fake” proofs.
  • KVC are not required to satisfy any sort of hiding property, although one may also define KVC that are hiding.
  • a KVC is hiding if an adversary cannot distinguish whether a commitment was created to a key-value map M or to another key-value map M > even after learning the values corresponding to keys that have the same value in both maps. Accordingly, a KVC is considered key- binding if no adversary that runs in probabilistic polynomial time (PPT) may produce fake proofs successfully with a non-negligible probability.
  • PPT probabilistic polynomial time
  • KVC that do offer hiding properties may be configured or programmed.
  • a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of blockchain 100 may perform 5UJ0107.DOCX Page 49 of 92 Attorney Docket No.08223-2400886 (6654WO01) one or more functions described as being performed by another set of systems or another set of devices of system 100.
  • FIG. 2 shown is a diagram of an example blockchain system 200 comprising KVCs from accumulators and/or VC, according to some non- limiting embodiments or aspects.
  • Blockchain system 200 provides a decentralized, distributed ledger that may be public or private.
  • blockchain system 200 includes transaction submission system 202, commitment generation system 204, transaction authorization system 206, block generation system 208, blockchain node software 210, and commitment verification system 212.
  • the systems and software of the blockchain network together create and maintain a secure and transparent blockchain network 100 as shown in FIG. 1, which allows users to create and validate transactions with KVCs from accumulators and VC.
  • the state of the system is represented as a set of key-value pairs where the keys represent the unique addresses of user accounts and the values represent the balance or state of each account. These key-value pairs are stored in a distributed data structure of blockchain network 100, a continuously growing list of blocks that are linked together using cryptographic hashes.
  • transaction submission system 202 provides a user interface (UI).
  • transaction submission system 202 may include one or more devices capable of providing a UI to users.
  • transaction submission system 202 provides a UI for creating blockchain transactions.
  • transaction submission system 202 executes a UI to users to submit each new transaction or a group of transactions to blockchain network 100.
  • transaction submission system 202 may be a simple command-line interface or a more complex web-based application.
  • commitment generation system 204 generates or creates a commitment to the state of blockchain network 100.
  • commitment generation system 204 may include one or more devices capable of creating a commitment to the state of blockchain network 100.
  • commitment generation system 204 generates a snapshot memorializing the state of blockchain network 100.
  • Commitment generation system 204 may be part of blockchain node software 210 or a part of a separate system that is run by one or more validator nodes.
  • 5UJ0107.DOCX Page 50 of 92 Attorney Docket No.08223-2400886 (6654WO01) commitment generation system 204 generates a commitment value that is computed based on the current set of key-value pairs using a cryptographic function such as a hash function. This commitment value is then stored in blockchain network 100 along with transaction data.
  • blockchain node software 210 may include one or more devices capable of creating and verifying transactions. In addition, blockchain node software 210 may include one or more devices capable of creating new blocks. Blockchain node software 210 may include one or more devices capable of communicating with other nodes in blockchain network 100. [0221] In some non-limiting embodiments or aspects, commitment verification system 212 may include one or more devices capable of verifying a commitment to the state of blockchain network 100. Commitment verification system 212 may be part of the operating system for blockchain node software 210 or a separate system that is run by validator nodes.
  • commitment generation system 204 may determine the KVC (e.g., accumulator commitment, vector commitment, KVC, etc.) based on a set of cryptographic primitives, including pseudorandom functions, collision-resistant hash functions, and commitments.
  • KVC e.g., accumulator commitment, vector commitment, KVC, etc.
  • Commitment generation system 204 may provide primitives to enable efficient and secure storage and retrieval of key-value pairs, while also supporting advanced features including dynamic updates, compact proofs, and authenticated queries.
  • Commitment verification system 212 may determine that a KVC may achieve high performance and scalability while maintaining strong security guarantees.
  • the primitives may be used to operate on a 5UJ0107.
  • DOCX Page 51 of 92 Attorney Docket No.08223-2400886 (6654WO01) tuple (e.g., a representation of a key-value pair that a party may desire to add, update, delete, etc.) to the map.
  • the tuple could represent a transaction where the key is the transaction ID, and the value is the transaction details.
  • an accumulator and a VC may be provided, generated, used in combination for certain blockchain systems to achieve specific properties and functionalities.
  • an accumulator is a data structure that accumulates the commitments of key-value pairs into a single value. It allows for efficient and compact representation of a large number of key-value pairs (e.g., key-value pairs for transactions, state updates, etc.) in a single value.
  • the accumulator may be updated with new commitments as new data elements are added to blockchain network 100 and may be used to efficiently verify the membership or non-membership of a specific data element in the accumulated set.
  • An accumulator commitment may include the following: [0225]
  • the combination of an accumulator and a VC may provide certain benefits in blockchain system 200.
  • the accumulator may provide an efficient and compact representation of the entire set of data elements.
  • the VC may provide efficient proofs and operations for individual data elements within the set. This may enable various functionalities, such as efficient verification of the state changes in a block, efficient synchronization of light clients, or efficient proofs of inclusion or non-inclusion of specific data elements.
  • the VC may provide additional KVAC properties for implementing blockchain network 100.
  • VC may support an algorithm to extend a length of the VC and may output one or more new parameters as described above for the extended length.
  • the VC inherits all the VC properties such as multi-hop aggregation.
  • the accumulators may be used to store and maintain the commitments for the key-value pairs. Specifically, each key-value pair may be hashed using a collision- resistant hash function to produce a commitment value in an accumulator structure 5UJ0107.
  • DOCX Page 52 of 92 Attorney Docket No.08223-2400886 (6654WO01) (e.g., accumulator commitment, vector commitment, etc.) using an appropriate update algorithm (shown above).
  • blockchain system 200 may provide an accumulator data structure that provides efficient, secure updates and queries. Each block may represent a subset of the key-value pairs, and the root block may contain the commitment for the entire set of key-value pairs in all the blocks of blockchain network 100. [0230] In some non-limiting embodiments or aspects, blockchain system 200 may add a new key-value pair to the key-value maps 106a-106n. For example, in some non-limiting embodiments or aspects, blockchain system 200 may provide blockchain node software 210 for the party who will add a key-value pair, such as by selecting a unique key and computing its corresponding value.
  • Blockchain system 200 generates a commitment to the existing key-value pairs for the party in the map using the VC and/or accumulator commitment.
  • Blockchain system 200 then computes a new commitment value for the party by adding the commitment value of the existing map to the commitment of the new key-value pair.
  • Blockchain system 200 then publicly discloses the new commitment value for the party along with a proof that the new key- value pair is included in the commitment.
  • One or more other parties may verify the proof using the public parameters of blockchain network 100 and the new commitment value to ensure that the new key-value pair is included in the map.
  • blockchain system 200 proves the inclusion of a particular key-value pair in the accumulator.
  • blockchain system 200 updates a value for the party by computing a new commitment value using an updated key-value pair.
  • Blockchain system 200 then generates a proof to show that the old value was replaced by the new value.
  • the proof may include a constant number of group elements and may be verified by blockchain system 200 using just a few group exponentiations.
  • the updated commitment value and the proof are then published to blockchain network 100, allowing others to verify that the old value was replaced by the new value.
  • a new key may be used by an online store to introduce a new product to your customers. In order to do this, the store would need to add a new key-value pair to your map.
  • the key could be the name or SKU of the new product and the value could include information such as the product description, price, and availability.
  • the use of accumulators in the KVC provides an efficient and secure way to store and maintain the commitments for large numbers of key-value pairs, while also enabling efficient and secure proofs of inclusion and non-inclusion.
  • blockchain system 200 provides a commitment that provides constant-size proofs of membership for key-value maps, without requiring the commitment size to grow as the number of keys in the KV-map grow.
  • the encoding and proofs may comprise just two and three group elements respectively making them highly efficient.
  • Blockchain system 200 provides a chaining technique which links together multiple key-value pairs into a single chain.
  • blockchain system 200 may prove membership of a key-value pair in the accumulator.
  • a prover may provide a proof consisting of two group elements (e.g., a commitment value for the chain that contains the key-value pair, and a proof of inclusion in that chain, etc.).
  • blockchain system 200 provides a proof of inclusion comprising three group elements (e.g., a commitment value for the key-value pair, a witness for 5UJ0107.DOCX Page 54 of 92 Attorney Docket No.08223-2400886 (6654WO01) the PRF used to assign the key-value pair to the chain, and a representation of the key-value pair with respect to the commitment value for the chain, etc.).
  • blockchain system 200 verifies the proof.
  • Blockchain system 200 computes a plurality of group exponentiations and a plurality of hash function evaluations.
  • Blockchain system 200 may generate a commitment value for a key-value pair based on the specific key and its associated value using a cryptographic commitment. This commitment value is included in accumulator data structure to represent the key-value pair in blockchain network 100.
  • Blockchain system 200 may generate a commitment value for blockchain network 100 that represents an entire state of blockchain network 100, including each of the key-value pairs that have been committed to blockchain network 100 over time. Such a commitment value may be computed using similar cryptographic commitment s.
  • the commitment value may include each of the nodes in the accumulator data structure (e.g., accumulator commitment data structure, VC data structure, etc.), not just a single key-value pair. This allows the entire blockchain network 100 to be represented by a single commitment value making it easier to verify the integrity of the entire blockchain network 100.
  • one or more keys represent the unique identifiers for the key-value pairs. The one or more keys may be used to index the values in the data structure and compute the commitment value for the KVAC.
  • blockchain system 200 may commit to a set of key-value pairs using the KVC, a party first computes a commitment value based on a polynomial generated from the key-value pairs.
  • the commitment value may be published publicly, while the key-value pairs remain private.
  • blockchain system 200 may generate a cryptographic proof using the commitment value and the relevant key-value pair.
  • Blockchain system 200 may verify the proof. For example, the proof is verified by any third party using blockchain system 200 without revealing any information about the other key-value pairs in the commitment.
  • Blockchain system 200 provides a way (e.g., one or more properties or algorithms, as shown above, etc.) to update a value associated with a particular key in the key-value map without having to compute a new commitment value for the entire map. Instead, an additive update to the value associated with the key may be made, and a new commitment value may be computed based on the updated map. [0245] Blockchain system 200 provides additive updates to key values using the same level of efficiency as proofs of membership. In this way, the cost of updating a value associated with a key is the same as the cost of proving that a particular key- value pair is a member of the map.
  • blockchain system 200 provides an accumulator commitment for membership and non-membership proofs in blockchain system 200.
  • the accumulator may be used to generate proofs for both membership and non-membership of data elements in the set.
  • blockchain system 200 proves that a data element is a member of a set. For example, blockchain system 200 generates a membership proof using the accumulator for the prover.
  • the membership proof includes a subset of accumulated values along with other necessary information.
  • blockchain system 200 allows the verifier to verify that the data element is included in the set. The verifier may then efficiently verify the membership proof using the accumulator without having to individually check each element in the set.
  • blockchain system 200 proves that a data element is not a member of a set.
  • blockchain system 200 generates a non-membership proof using the accumulator for the prover.
  • the non- membership proof includes a subset of accumulated values along with other necessary information.
  • blockchain system 200 allows the verifier to verify that the data element is not included in the set.
  • the verifier may then efficiently verify the non-membership proof using the accumulator without having to check each element in the set.
  • the accumulator is used for both membership and non- membership proofs allowing the prover to efficiently prove the existence or non- existence of data elements in the set depending on the scenario. This may be useful 5UJ0107.
  • DOCX Page 56 of 92 Attorney Docket No.08223-2400886 (6654WO01) in various blockchain network 100 use cases where efficient verification of membership or non-membership is required, such as verifying the validity of transaction inputs or outputs, checking for duplicate entries, or verifying access control to certain data or resources.
  • blockchain system 200 provides an accumulator commitment that supports non-membership for element k.
  • a KVC is derived from an accumulator commitment.
  • a KVC is derived from a VC via an accumulator commitment.
  • a VC may be derived from the accumulator commitment.
  • an accumulator may be generated from a VC.
  • each VC position corresponds to one accumulator domain element.
  • a position opening to 1 corresponds to membership of the element
  • opening to 0 e.g., zero
  • blockchain system 200 may include a commitment to a complete accumulator domain (e.g., an operation equivalent to running a VC setup over a structure including each key of the possible key-value pair, etc.).
  • VC and accumulator commitments are cryptographic primitives that provide efficient ways to verify the integrity and membership of data elements in a compact manner.
  • VC allow for the representation of a vector of data elements, such as a list or an array and provide efficient proofs of existence or non-existence of specific elements within the vector.
  • VC may be more efficient than existing primitives when operating on sets of data that may require frequent updates or random access.
  • accumulator commitments allow the accumulation of multiple data elements into a single commitment, which may be efficiently and accurately verified. They may also provide a way to verify the membership or non- membership of specific elements in a set without revealing an entire set. Accumulators may be more efficient than existing primitives when operating on large data sets, such as, when efficient proof generation and verification is needed.
  • the state typically includes various components, such as account balances, transaction history, smart contract states, network parameters, other relevant data, and/or the like.
  • account balances may represent the amount of cryptocurrency held by each account/address in the network.
  • a transaction history may include a record of each of the transactions that have occurred within the network, including sender, receiver, and transaction details.
  • smart contract states are stored, if the network supports smart contracts.
  • the current state of deployed contracts may include variable values and contract-specific data.
  • Network parameters may include configuration settings and rules governing the operation of the network, such as block size, block time, consensus algorithm, and/or the like.
  • the state of a cryptocurrency network is dynamic and continuously evolving. For example, as blockchain system 200 obtains or stores each new transaction or block added to blockchain network 100, substantially simultaneous, with the storing of the changes made to the state.
  • the state comprises a representation of the current truth (e.g., the validity of the transactions, KVC, etc.) of the network.
  • Blockchain system 200 may use the state to validate transactions, enforce rules, maintain consensus across the network, and/or the like.
  • Blockchain system 200 may maintain an accurate and up-to-date representation of the network’s state to ensure proper functioning of the cryptocurrency ecosystem.
  • Blockchain system 200 may ensure that participants may reliably determine account balances, verify the validity of transactions, and make informed decisions based on the current state of the network. 5UJ0107.DOCX Page 58 of 92 Attorney Docket No.08223-2400886 (6654WO01) [0260]
  • Blockchain system 200 may use KVCs from accumulators and VC to provide KVC that offer succinct encodings of key-value maps resulting in compact commitment values.
  • the commitment value consists of just two group elements.
  • Blockchain system 200 provides compact representation, reduces storage requirements, enables faster data processing, and/or the like.
  • Blockchain system 200 may use KVC generated from accumulators and VC for efficient membership proofs. For example, proving the existence of a certain item in the commitment requires only three group elements. The verification of such proofs requires only five exponentiations. This efficiency reduces the computational overhead associated with validating the membership of specific items. Succinctness of a proof, as used herein, refers to the property of a proof whereby the size of the proof is relatively small compared to the size of the statement being proven. In other words, a succinct proof provides a compact representation of the evidence or information needed to demonstrate the validity or truth of a statement. [0262] Blockchain system 200 may generate encodings that reduce a computational and communication overhead associated with verifying the proof.
  • a succinct proof allows for more efficient verification processes as it requires fewer computational resources and less data transmission.
  • blockchain system 200 may provide a succinct proof by using advanced cryptographic techniques.
  • Blockchain system 200 may minimize the size of the proof while still providing a convincing demonstration of the statement’s validity, in this way, optimizing cryptographic techniques of blockchain network 100, such as zero-knowledge proofs, probabilistically checkable proofs, succinct data structures, and/or the like.
  • Blockchain system 200 may provide succinct proofs, so that cryptographic systems may operate more efficiently, allow for faster verification, and reduce the overall resource requirements. This property is particularly important in blockchain system 200 and other distributed environments where the verification of proofs needs to be performed by multiple parties across the network.
  • Blockchain system 200 may use KVC from accumulators and VC to provide fast updates.
  • blockchain system 200 may insert new items, update the values of existing items (e.g., additive updates, etc.), update membership proofs, and/or the like. In any update scenario, at most four exponentiations are required.
  • DOCX Page 59 of 92 Attorney Docket No.08223-2400886 (6654WO01) such an example, updating the value of an item does not require knowledge of its existing value, enhancing the flexibility and efficiency of the update process.
  • Blockchain system 200 may use KVC from accumulators and VC to provide a trustless blockchain network 100 (e.g., a system or protocol design where participants may interact and transact without needing to trust each other or rely on a centralized authority, etc.).
  • blockchain system 200 may provide an encoding that may be established without relying on a centralized or trusted authority.
  • blockchain system 200 uses a trustless blockchain network 100 to enhance decentralization, security, and trustworthiness of blockchain system 200 and blockchain network 100. In such an example, blockchain system 200 enhances the security and correctness of blockchain network 100.
  • blockchain system 200 may provide a trustless blockchain network 100 so that participants do not have to trust that other actors will behave honestly or that a central authority will not abuse its power.
  • Blockchain system 200 may determine or provide cryptographic primitives and consensus mechanisms formed from accumulator commitments and VC to verify transactions, verify exchanges of information, verify proofs or statements, perform other operations, and/or the like without having to trust other participants or a central authority.
  • blockchain system 200 may provide a trustless blockchain network 100 using cryptographic techniques, such as public-key cryptography, digital signatures, zero-knowledge proofs, distributed consensus algorithms, proof-of-work algorithms, proof-of-stake algorithms, and/or the like.
  • Blockchain system 200 provides commitments from accumulators and VC to independently verify the validity and integrity of transactions, proofs, system states, and/or the like without a need to trust other parties. In this way, participants may engage in interactions with blockchain network 100 with reduced reliance on external entities. In this way, blockchain system 200 may provide commitments from accumulators and VC to mitigate the risk of fraud, manipulation, or censorship. Trustless setups are commonly found in blockchain network 100 and other decentralized systems where participants seek to maintain control over their assets and information without relying on a central authority. [0267] In some non-limiting embodiments or aspects, blockchain system 200 may use KVC from accumulators and VC to allow for the aggregation and batching of multiple proofs.
  • Batching in VC may refer to the ability to commit to multiple VC simultaneously using a single commitment. Instead of committing to individual vectors separately, a single VC may be used to commit to a list of vectors in one shot. For example, blockchain system 200 may generate a matrix M whose columns are the vectors to be committed to.
  • the commitment to the matrix M is then computed, and this commitment may be used by blockchain system 200 to verify any linear combination of the vectors in the matrix.
  • the prover would need to provide a witness that proves knowledge of the corresponding row i of the matrix. Batching may greatly reduce the communication and computation costs of VC, especially when dealing with large numbers of vectors.
  • the number and arrangement of systems and devices shown in FIG.2 are provided as an example. There may be additional systems and/or devices, fewer systems and/or devices, different systems and/or devices, and/or differently arranged systems and/or devices than those shown in FIG.2.
  • FIG.2 may be implemented within a single system or device, or a single system or device shown in FIG.2 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of blockchain system 200 may perform one or more functions described as being performed by another set of systems or another set of devices of system 200.
  • FIG.3 shown is a flow diagram for a method for generating KVC from VC according to some non-limiting embodiments or aspects.
  • one or more of the steps of process 300 may be performed (e.g., completely, partially, and/or the like) in a decentralized, distributed ledger that may be public or private, such as blockchain network 100 (e.g., one or more blocks of blockchain network 100, structures of blockchain network 100, etc.) by blockchain system 200 (e.g., one or more devices of blockchain system 200).
  • blockchain network 100 e.g., one or more blocks of blockchain network 100, structures of blockchain network 100, etc.
  • blockchain system 200 e.g., one or more devices of blockchain system 200.
  • one or more of the steps of process 300 may be performed (e.g., completely, partially, and/or the like) by another system, another device, another group of systems, or another group of devices, separate from or including the aforementioned devices, such as transaction submission system 202, 5UJ0107.DOCX Page 61 of 92 Attorney Docket No.08223-2400886 (6654WO01) commitment generation system 204, transaction authorization system 206, block generation system 208, or commitment verification system 212. [0271] As shown in FIG.3, at step 302, process 300 may include generating a KVC to a plurality of key-value pairs. For example, blockchain system 200 generates a KVC to a plurality of key-value pairs.
  • Blockchain system 200 generates an accumulator commitment, a VC, or a KVC for a plurality of key-value pairs of a block in a blockchain network.
  • blockchain system 200 generates a KVC to a plurality of key-value pairs based on a cryptographic data structure that allows a user to commit to a vector (e.g., an ordered set, etc.) of values such that the user may later reveal and prove the value of specific elements without revealing the entire vector.
  • Operation includes primitives for inserting new values, updating existing values, deleting values from the VC, and/or the like.
  • State transition as used herein, may refer to the change in the state of a system or ledger.
  • a state transition typically refers to the change in the blockchain’s state due to the addition of a new transaction.
  • a blockchain where each block contains several transactions, and the VC is used to manage and verify the state of the blockchain efficiently for a new block of transactions added.
  • proofs may be generated for each operation: This may include proofs for each transaction verifying the addition or update of data within the VC.
  • a proof may verify that the state of the blockchain has transitioned correctly. This proof verifies that blockchain network 100 has moved from the previous valid state (before the transactions in the new block) to the new valid state (after the transactions have been processed).
  • the commitment to the plurality of key-value pairs may be 5UJ0107.
  • the key vector and the corresponding value vector each include a vector length configured to be increased as additional key-values are stored to the VC.
  • blockchain system 200 obtains key-value pairs for a transaction or a current block in blockchain network 100.
  • Blockchain system 200 then generates a commitment to each of the key-value pairs for a current block (e.g., as the key-value pairs are obtained, in a batch, etc.).
  • the commitment to the plurality of key- value pairs may then be stored in a VC.
  • the VC may include a key vector and a corresponding value vector, such that the key vector and the corresponding value vector each have a vector length configured to be increased (e.g., as key-values arrive, are obtained, handled, etc.).
  • the additional key-values are stored to the VC.
  • blockchain system 200 generates an accumulator commitment from the VC.
  • blockchain system 200 may generate an accumulator commitment by converting each key-value pair of the plurality of key-value pairs of the VC to a corresponding key-value pair of the accumulator commitment.
  • each VC element corresponds to one accumulator domain element.
  • blockchain system 200 generates the accumulator commitment from the VC to extend the at least one property of the VC (e.g., each VC includes properties for manipulating the VC, etc.). For example, blockchain system 200 extends the VC to include one or more properties of the accumulator commitment for operating on a plurality of KVC. For example, blockchain system 200 extends the VC to include one or more properties of the accumulator commitment, such as membership, non-membership, and/or the like. In some non-limiting embodiments or aspects, blockchain system 200 may test membership and non-membership to determine a presence of a key.
  • blockchain system 200 transforms each key-value pair of the plurality of key-value pairs of the VC.
  • blockchain system 200 encodes a plurality of keys of the plurality of key- value pairs.
  • Blockchain system 200 may encode the plurality of keys into a probabilistic data structure.
  • blockchain system 200 may encode the plurality of keys (e.g., the VC, etc.) to include a test algorithm that provides a signal in response to determining a given key is in a set. In this way, blockchain system 200 compresses a plurality of values of the plurality of key-value pairs into a compact format.
  • blockchain system 200 encodes the plurality of values to provide access to information (e.g., cryptographically derived information, etc.) associated with the plurality of values when compared to one or more test values.
  • blockchain system 200 encodes the VC by encoding the plurality of values directly as a linear function to form a linear combination of one or more vector elements. The additions, updates, modifications, and/or deletions of values to the VC may then be made by updating the linear function directly (e.g., aggregating updates with existing values, accumulating, etc.).
  • each encoded key of a plurality of encoded keys of the VC may be represented by a corresponding hexadecimal string based on the one or more key-value pairs.
  • the encoded keys may be compacted (or compressed) to between 2-bytes and 6-bytes.
  • generating a compact representation of the plurality of keys by hashing each key of the plurality of keys and resetting bits for each hashed key based on one or more resulting hash values, wherein the compact representation of the plurality of keys is configured to store the plurality of keys and information for querying the one or more key-value pairs.
  • a root of each block comprises a commitment to a state of a corresponding block.
  • each block of blockchain network 100 represents a subset of the key-value pairs.
  • the state of each previous block in the blockchain network 100 is cryptographically included in each subsequent header of each subsequent block as a commitment to a previous state of blockchain network 100.
  • blockchain system 200 stores a cryptographic value in a current block that cryptographically represents information about a previous block that is used to form a commitment to a previous state of blockchain network 100 (e.g., or a current state of blockchain network 100 as the new block is added, etc.).
  • process 300 may include determining a proof for a new transaction associated with a current block based on an aggregation of transaction parameters from previous transactions.
  • DOCX Page 64 of 92 Attorney Docket No.08223-2400886 (6654WO01) 210 determine a proof for a new transaction associated with a current block based on an aggregation of transaction parameters from previous transactions.
  • commitment generation system 204, transaction authorization system 206, block generation system 208, and/or blockchain node software 210 may determine a proof algorithm for a new transaction associated with the current block based on an aggregation of transaction parameters from one or more previous transactions.
  • blockchain system 200 determines a proof algorithm for a new transaction associated with the current block based on an aggregation of transaction parameters from one or more previous transactions.
  • blockchain system 200 determines the proof algorithm for the new transaction. For example, blockchain system 200 generates a plurality of proofs, such that each of the plurality of proofs correspond to an update operation of the VC.
  • the plurality of proofs may include at least one proof configured to verify a state transition of an update operation.
  • blockchain system 200 aggregates the plurality of proofs into a batch.
  • the VC provides a key-value map.
  • blockchain system 200 verifies the plurality of proofs in the batch. For example, blockchain system 200 verifies the plurality of proofs in the batch based on a single computation of the VC.
  • blockchain system 200 generates a verification result based on a plurality of proofs.
  • access to a plurality of values of the commitment is provided by blockchain system 200 in response to a proof of knowledge determination of the key-value map for a key in the VC.
  • blockchain system 200 receives, transmits, obtains, and/or the like, a proof of knowledge determination of the key-value map for a key in the VC.
  • one or more blocks participate in transaction verification based only on commitment to a state without storing a current state of blockchain network 100.
  • process 300 may include verifying the new transaction by authenticating the previous transactions using a primitive of a VC to solve the proof algorithm.
  • blockchain system 200 verifies the new transaction by authenticating the previous transactions using a primitive of a VC to solve the proof algorithm.
  • blockchain system 200 verifies the new transaction based on authenticating the one or more previous transactions using at least one primitive of the VC to solve the proof algorithm.
  • blockchain system 200 verifies the new transaction based on authenticating the one or more previous transactions using at least one primitive of the VC to solve the proof algorithm.
  • blockchain system 200 authenticates the one or more previous transactions without revealing one or more intermediate state transitions or an entire key-value map of the blockchain network 100. For example, blockchain system 200, by using at least one primitive of the accumulator commitment to execute the proof algorithm, verifies at least one of a signature, a proof of membership, a state of the VC, or an amount associated with at least one transaction of the one or more previous transactions, wherein the proof algorithm is a multi-hop proof algorithm.
  • blockchain system 200 provides multi-hop aggregation.
  • multi-hop aggregation in conjunction with VC may aggregate or accumulate data elements in a vector through a series of hops or intermediate stages rather than aggregating them all at once.
  • Multi-hop aggregation provides improved efficiency in terms of computational cost, communication overhead, and storage requirements.
  • blockchain system 200 provides multi-hop aggregation instead of recomputing an entire commitment. This may eliminate high computational cost and communication overhead, especially for large vectors.
  • Blockchain system 200 provides multi-hop aggregation so that updates may be performed incrementally through intermediate stages allowing for more efficient computation and communication.
  • blockchain system 200 divides the VC into smaller segments or partitions and performs local aggregation or commitment on each segment.
  • the resulting intermediate commitments are then combined or aggregated to form a global commitment for the entire vector.
  • This process may be repeated in multiple stages, with each stage aggregating a smaller set of commitments, until the final global commitment is 5UJ0107.
  • blockchain system 200 adds a new transaction that requires referencing previous inputs. For example, a user may want to transfer digital assets or cryptocurrencies from one account to another.
  • blockchain system 200 ensures that the sender has the authority to spend the digital assets or cryptocurrencies being transferred.
  • blockchain system 200 ensures a new transaction references the previous transaction outputs (or inputs) that are associated with the sender’s account. For example, previous transaction outputs serve as the source of funds for the new transaction, and their inclusion in the new transaction provides evidence that the sender has the right to spend those specific digital assets or cryptocurrencies.
  • blockchain system 200 verifies the existence and validity of the referenced previous inputs by checking the corresponding proofs.
  • Blockchain system 200 may generate multi-hop aggregation proofs for VC. Once the referenced inputs are verified, the new transaction is considered valid and may be added to blockchain network 100 or ledger as a new block. The new transaction and updated blockchain network 100 or ledger then serve as the basis for subsequent transactions and updates in blockchain system 200.
  • Blockchain system 200 may authenticate the new transaction based on verifying membership or non-membership of a key-value pair. For example, blockchain system 200 verifies the new transaction after determining the one or more previous transactions are authenticated. For example, blockchain system 200 authenticates the new transaction using at least one primitive of the VC to solve the proof algorithm. In another example, blockchain system 200 authenticates the new transaction using at least one primitive of the accumulator commitment to solve the proof algorithm.
  • process 300 may include updating the VC by cryptographically adding a KVC for the new transaction verifying the new transaction.
  • blockchain system 200 updates the VC by adding a key-value pair to the VC for the new transaction in response to verifying the new transaction.
  • blockchain system 200 updates the VC by adding a key-value pair to the VC for the new transaction in response to verifying the new transaction.
  • blockchain system 200 determines a current state of blockchain network 100. For example, the current state of blockchain network 100 as determined in the VC is based on the current block of the blockchain network 100. However, each previous VC representing each previous block of blockchain network 100 may be used to ensure the previous state of the blockchain (e.g., before the current block, etc.).
  • a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of blockchain network 100.
  • blockchain system 200 determines a current state of blockchain network 100 based on a key-value map stored in a VC or an accumulator commitment of the key-value pairs.
  • the VC stores a representation of the key-value map associated with the current state of the current block.
  • blockchain system 200 determines the current state of blockchain network 100 by aggregating each VC stored in each previous block of blockchain network 100 (e.g., a root of each block, a root node, etc.).
  • each new block in blockchain network 100 stores a reference back to a VC of a previous block (as shown in FIG. 1) of blockchain network 100.
  • Blockchain system 200 may aggregate each VC reference to determine or generate a state of blockchain network 100.
  • one or more key-value pairs of the VC of the previous block may be accessed for information that verifies at least one transaction of the current block. 5UJ0107.
  • DOCX Page 68 of 92 Attorney Docket No.08223-2400886 (6654WO01)
  • FIG. 4 a flowchart of an example process 400 for KVC from accumulators according to some non-limiting embodiments or aspects.
  • one or more of the steps of process 400 may be performed (e.g., completely, partially, and/or the like) in a decentralized, distributed ledger that may be public or private, such as blockchain network 100 (e.g., one or more blocks blockchain network 100, structures of blockchain network 100, etc.) by blockchain system 200 (e.g., one or more devices of blockchain system 200).
  • blockchain network 100 e.g., one or more blocks blockchain network 100, structures of blockchain network 100, etc.
  • blockchain system 200 e.g., one or more devices of blockchain system 200.
  • one or more of the steps of process 400 may be performed (e.g., completely, partially, and/or the like) by another system, another device, another group of systems, or another group of devices, separate from or including the aforementioned devices, such as transaction submission system 202, commitment generation system 204, transaction authorization system 206, block generation system 208, or commitment verification system 212.
  • process 400 may include generating an accumulator commitment for a plurality of key-value pairs of a block in a blockchain network, the accumulator commitment cryptographically adding each KVC of the block.
  • blockchain system 200 generates an accumulator commitment for a plurality of key-value pairs of a block in a blockchain network, the accumulator commitment cryptographically adding each KVC of the block.
  • generating an accumulator commitment for a plurality of key-value pairs of a block in a blockchain network includes generating an accumulator commitment by creating a single cryptographic value (e.g., the accumulator commitment), which represents each of the key-value pairs in a block, another quantifiable structure, and/or the like. There are multiple key- value pairs within the block.
  • Each key-value pair is a distinct piece of data where the key is an identifier and the value is the associated data.
  • Each block may include several transactions or pieces of data represented as key-value pairs.
  • block generation system 208 generates the accumulator commitment cryptographically by adding each KVC. This means that for each key-value pair in the block, an individual cryptographic commitment is made. One or more individual commitments are then combined (e.g., added, accumulated, etc.) into a single accumulator commitment using the cryptographic properties and operations described herein.
  • block generation system 208 generates the accumulator commitment cryptographically such that the accumulator commitment securely encapsulates all the individual KVC. This allows anyone with the accumulator commitment to verify that a specific key-value pair is included in the block without having to reference the entire block’s data. The single commitment provides the verification of any individual key-value pair’s inclusion in the block enhancing the integrity and security of the data within the blockchain.
  • blockchain system 200 generates a commitment to a plurality of key-value pairs for a block in blockchain network 100, the commitment to the plurality of key-value pairs stored in an accumulator commitment comprising each key-value pair, the accumulator commitment comprising each new key added to the block and at least one value commitment associated with each new key added to the block.
  • blockchain system 200 generates a commitment to a plurality of key-value pairs for a block in blockchain network 100. The commitment to the plurality of key-value pairs may be stored by blockchain system 200 in an accumulator commitment.
  • blockchain system 200 generates the accumulator commitment to each key-value pair, such that each new key added to the block and at least one value are included in a commitment.
  • the commitment is associated (e.g., stores, links, etc.) to each new key added to the block.
  • a root of each block e.g., a root of each block stored in a header block, etc.
  • the state of each previous block in blockchain network 100 is cryptographically included in each subsequent header of each subsequent block as a commitment to a previous state of blockchain network 100.
  • each block stores the commitment to a state of the previous block which cryptographically includes the commitment to the state of each previous block.
  • each block of blockchain network 100 represents a subset of the key-value pairs, such as the subset of the key- value pairs that form blockchain network 100.
  • blockchain system 200 transforms each key-value pair of the plurality of key-value pairs of the accumulator commitment.
  • blockchain system 200 encodes a plurality of keys of the plurality of key-value pairs into a probabilistic data structure by encoding the plurality 5UJ0107.
  • DOCX Page 70 of 92 Attorney Docket No.08223-2400886 (6654WO01) of keys to include a test algorithm that provides a signal in response to determining a given key is in a set.
  • blockchain system 200 compresses a plurality of values of the plurality of key-value pairs into a compact format.
  • blockchain system 200 compresses a plurality of values to provide access to information associated with the plurality of values when compared to one or more test values.
  • blockchain system 200 compresses a plurality of values to encode the VC.
  • blockchain system 200 encodes the VC directly as a linear function to form a linear combination of one or more vector elements of the VC.
  • the encoded key (e.g., each of a plurality of encoded keys of the vector commitment, etc.) may be represented by a corresponding hexadecimal string based on the one or more key-value pairs.
  • the encoded key may be compacted to between 2-bytes and 6-bytes.
  • the additions, updates, modifications, and/or deletions of values to the VC are made by updating the linear function directly.
  • blockchain system 200 generates a compact representation of the plurality of keys. For example, blockchain system 200 hashes each key of the plurality of keys and resetting bits for each hashed key based on one or more resulting hash values.
  • the compact representation of the plurality of keys may be configured to store the plurality of keys, such that the compact representation includes information for querying the one or more key-value pairs.
  • process 400 may include obtaining a new transaction for the block. For example, in some non-limiting embodiments or aspects, blockchain system 200 obtains a new transaction for the block.
  • blockchain system 200 determines a multi-hop proof algorithm for a second transaction. For example, blockchain system 200 generates a VC from the accumulator commitment. In such an example, blockchain system 200 converts each KVC of the plurality of key-value pairs of the accumulator commitment to a corresponding KVC of the VC. Blockchain system 200 also authenticates the second transaction. Blockchain system 200 determines at least one property of the VC to execute the multi-hop proof algorithm. Blockchain system 200 updates the accumulator commitment by adding a key-value pair to the accumulator commitment for the second transaction.
  • blockchain system 200 updates the accumulator commitment by adding a key-value pair to the accumulator.
  • blockchain system 200 generates the VC from the accumulator commitment.
  • blockchain system 200 extends a property of the accumulator commitment to include one or more properties of the VC for operating on the plurality of key-value pairs. The VC then increases in length to commit each KVC stored by the accumulator commitment.
  • blockchain system 200 generates the accumulator commitment from a VC by matching each position of the VC to a domain element of the accumulator commitment. This allows blockchain system 200 to increase the length of the VC to include each key of a plurality of potential keys to commit the domain element of the accumulator commitment.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 determine a multi-hop proof algorithm for a second transaction.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 select or compute a specific algorithm that will generate a proof spanning multiple transactions.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 generate a VC from an accumulator commitment by converting each KVC of the plurality of key-value pairs of the accumulator commitment to a corresponding KVC of the VC.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 converts (e.g., translate, repurpose, etc.) the existing accumulator commitment into a VC.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 convert the commitments of individual key-value pairs from the accumulator structure into a format suitable for a VC. This conversion ensures that each key-value pair is represented accurately within the new commitment structure.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 5UJ0107.DOCX Page 72 of 92 Attorney Docket No.08223-2400886 (6654WO01) authenticate the second transaction by using at least one property of the VC to execute the multi-hop proof.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 execute (e.g., perform, instantiate, produce, etc.) properties of the VC to verify a transaction.
  • the VC may provide a framework that supports efficient verification via its properties (i.e., succinctness and security) to validate the transaction through the multi-hop proof.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 verifies that the transaction is legitimate and correctly related to previous transactions.
  • block generation system 208, commitment verification system 212, and/or transaction authorization system 206 update the accumulator commitment by adding a key-value pair to the accumulator commitment for the second transaction in response to verifying the second transaction based on the VC. For example, after the second transaction is authenticated, block generation system 208, commitment verification system 212, and/or transaction authorization system 206 update the accumulator commitment to include a new key- value pair corresponding to the second transaction. In some non-limiting embodiments or aspects, block generation system 208, commitment verification system 212, and/or transaction authorization system 206 verify or prove that the accumulator reflects the most recent state of the blockchain incorporating the verified transaction into its cryptographic structure.
  • process 400 may include determining a membership proof or non-membership proof configured to verify at least one accumulated value from one or more previous transactions.
  • blockchain system 200 determines a membership proof or non-membership proof configured to verify at least one accumulated value from one or more previous transactions.
  • blockchain node software 210 generates or solves a membership proof. For example, a cryptographic proof that a specific key-value pair is included in the accumulator commitment (e.g., ACC 108a- 108n, etc.).
  • blockchain node software 210 generates or solves a non-membership proof.
  • a non-membership proof is a cryptographic proof that a specific key-value pair is not included in the accumulator commitment (e.g., conversely to the membership proof which verifies existence, etc.).
  • the non-membership proof signals that a particular key-value pair is absent from the block. It also relies on the accumulator commitment to verify absence securely.
  • blockchain node software 210 verifies accumulated values from previous transactions. For example, the membership and non-membership proofs may be used to verify accumulated values from one or more previous transactions. This means that these proofs are not just limited to the current block but may also be used to check the inclusion or exclusion of key-value pairs in earlier blocks.
  • blockchain node software 210 verifies that accumulated values may verify inclusion, for example, blockchain node software 210 proves that a key-value pair is part of the accumulated data. In another example, blockchain node software 210 verifies exclusion, thereby proving that a key-value pair is not part of the accumulated data.
  • blockchain node software 210 provides historical verification, for example, blockchain node software 210 checks accumulated values across multiple blocks, not just a current block (e.g., not just a block containing the current transaction, etc.). This improves the integrity and trustworthiness of data in blockchain network 100 allowing users to efficiently verify the presence or absence of specific data without needing to access or process the entire dataset.
  • blockchain node software 210 generates or provides an accumulator commitment that comprises cryptographic representation encapsulating multiple key-value pairs associated within a block.
  • blockchain node software 210 confirms a membership proof. For example, when a particular key-value pair exists within the accumulator commitment.
  • blockchain node software 210 may authenticate key-value pairs against the existing accumulated values.
  • blockchain node software 210 confirms non-membership proof.
  • Blockchain node software 210 confirms that a particular key-value pair does not exist within the accumulator commitment. 5UJ0107.
  • Blockchain node software 210 also confirms that duplicate or unauthorized key-value pairs are not added to the blockchain.
  • process 400 may include authenticating the new transaction using at least one proof to verify membership or non-membership based on the at least one accumulated value.
  • blockchain node software 210 or blockchain system 200 authenticate the new transaction using at least one primitive of the accumulator commitment to verify membership or non-membership of the at least one accumulated value.
  • blockchain system 200 authenticates the new transaction using at least one primitive of the accumulator commitment to verify membership or non-membership of the at least one accumulated value.
  • block generation system 208 verifies new transactions. For example, when a new transaction is processed, block generation system 208 authenticates by using the membership or non-membership proofs generated from the accumulator commitment.
  • block generation system 208 verifies whether it should be included or excluded based on the accumulated values from previous transactions. For example, if the new transaction attempts to add a key-value pair that already exists in the accumulated values, the membership proof will confirm its presence, preventing duplicates. Conversely, the non-membership proof will ensure that new key-value pairs are legitimate and not previously included. [0337] Block generation system 208 verifies the integrity of the blockchain by preventing unauthorized changes and verifying that each new transaction match (e.g., conform, fit, accept, etc.) the existing state of accumulated data. The use of these cryptographic primitives enhances trust in the blockchain’s immutability and correctness.
  • block generation system 208 verifies efficiently and securely validates whether the data in the new transactions is consistent with the previously accumulated values while maintaining or addressing the integrity and reliability of the blockchain.
  • transaction authorization system 206, block generation system 208, blockchain node software 210, commitment verification system 212 create accumulator commitments.
  • blockchain node software 210 combines multiple key-value pairs into a single, compact 5UJ0107.DOCX Page 75 of 92 Attorney Docket No.08223-2400886 (6654WO01) commitment.
  • blockchain node software 210 generates hash functions or other cryptographic techniques to ensure the commitment is secure and efficient.
  • transaction authorization system 206, block generation system 208, blockchain node software 210, commitment verification system 212 create the accumulator commitment from a set of key-value pairs.
  • transaction authorization system 206, block generation system 208, blockchain node software 210, commitment verification system 212 generate the membership and non-membership proofs.
  • transaction authorization system 206, block generation system 208, blockchain node software 210, commitment verification system 212 verify these proofs to authenticate new transactions in the blockchain network.
  • transaction authorization system 206, block generation system 208, blockchain node software 210, commitment verification system 212 activate (e.g., use) primitives for ensuring the security, efficiency, and integrity of the accumulator commitment process within the blockchain.
  • a state of each previous block is determined by a commitment value of a key-value map stored for each previous block of blockchain network 100.
  • blockchain system 200 determines a current state of blockchain network 100 based on a key-value map stored in a VC or an accumulator commitment of the key-value pairs.
  • the VC stores a representation of the key-value map associated with the current state of the current block.
  • blockchain system 200 determines the current state of blockchain network 100 by aggregating each VC stored in each previous block of blockchain network 100 (e.g., a root of each block, etc.). For example, each new block in blockchain network 100 stores a reference back to a VC of a previous block of blockchain network 100, by aggregating each VC reference a state of the blockchain network 100 is generated. [0344] In some non-limiting embodiments or aspects, one or more key-value pairs of the VC of the previous block may be accessed for information that verifies at least one transaction of the current block. [0345] Referring now to FIG. 5, shown is a diagram of example components of device 500, according to some non-limiting embodiments or aspects.
  • Device 500 may 5UJ0107.
  • DOCX Page 76 of 92 Attorney Docket No.08223-2400886 correspond to one or more devices (e.g., one or more servers, one or more processors, one or more mobile devices, etc.) in blockchain system 200.
  • Device 500 may correspond to one or more devices (e.g., one or more servers, one or more processors, one or more mobile devices, etc.) for executing blockchain network 100.
  • such systems or devices may include at least one device 500 and/or at least one component of device 500.
  • device 500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG.1. Additionally, or alternatively, a set of components (e.g., one or more components) of device 500 may perform one or more functions described as being performed by another set of components of device 500.
  • device 500 may include bus 502, processor 504, memory 506, storage component 508, input component 510, output component 512, and communication interface 514.
  • Bus 502 may include a component that permits communication among the components of device 500.
  • processor 504 may be implemented in hardware, firmware, or a combination of hardware and software.
  • processor 504 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that may be programmed to perform a function.
  • Memory 506 may include random access memory (RAM), read only memory (ROM), and/or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and/or instructions for use by processor 504. [0347] With continued reference to FIG.
  • storage component 508 may store information and/or software related to the operation and use of device 500.
  • storage component 508 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid-state disk, etc.) and/or another type of computer-readable medium.
  • Input component 510 may include a component that 5UJ0107.DOCX Page 77 of 92 Attorney Docket No.08223-2400886 (6654WO01) permits device 500 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.).
  • input component 510 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.).
  • Output component 512 may include a component that provides output information from device 500 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.).
  • Communication interface 514 may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables device 500 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections.
  • Communication interface 514 may permit device 500 to receive information from another device and/or provide information to another device.
  • communication interface 514 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi® interface, a cellular network interface, and/or the like.
  • Device 500 may perform one or more processes described herein. Device 500 may perform these processes based on processor 504 executing software instructions stored by a computer-readable medium, such as memory 506 and/or storage component 508.
  • a computer-readable medium may include any non-transitory memory device.
  • a memory device includes memory space located inside of a single physical storage device or memory space spread across multiple physical storage devices.
  • Software instructions may be read into memory 506 and/or storage component 508 from another computer-readable medium or from another device via communication interface 514. When executed, software instructions stored in memory 506 and/or storage component 508 may cause processor 504 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.
  • the term “configured to,” as used herein, may refer to an arrangement of software, device(s), and/or hardware for performing and/or enabling one or more functions (e.g., actions, processes, steps of a process, and/or the like).
  • a processor configured to may refer to a 5UJ0107.
  • DOCX Page 78 of 92 Attorney Docket No.08223-2400886 (6654WO01) processor that executes software instructions (e.g., program code) that cause the processor to perform one or more functions.
  • software instructions e.g., program code

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système, un procédé et des produits programmes d'ordinateur pour des engagements clé-valeur d'accumulateurs et des engagements vectoriels. Le système comprend au moins un processeur, configuré pour générer un engagement d'accumulateur pour une pluralité de paires clé-valeur d'un bloc dans un réseau de chaînes de blocs, l'engagement d'accumulateur ajoutant de manière cryptographique chaque engagement clé-valeur du bloc ; obtenir une nouvelle transaction pour le bloc ; déterminer une preuve d'appartenance ou une preuve de non-appartenance servant à vérifier au moins une valeur accumulée à partir d'une ou de plusieurs transactions précédentes ; et authentifier la nouvelle transaction sur la base d'au moins une preuve servant à vérifier l'appartenance ou la non-appartenance sur la base de la ou des valeurs accumulées.
PCT/US2024/031372 2023-05-31 2024-05-29 Système, procédé et produit programme d'ordinateur pour des engagements clé-valeur d'accumulateurs et des engagements vectoriels Ceased WO2024249467A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363469961P 2023-05-31 2023-05-31
US63/469,961 2023-05-31

Publications (2)

Publication Number Publication Date
WO2024249467A2 true WO2024249467A2 (fr) 2024-12-05
WO2024249467A3 WO2024249467A3 (fr) 2025-04-03

Family

ID=93658734

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/031372 Ceased WO2024249467A2 (fr) 2023-05-31 2024-05-29 Système, procédé et produit programme d'ordinateur pour des engagements clé-valeur d'accumulateurs et des engagements vectoriels

Country Status (1)

Country Link
WO (1) WO2024249467A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119759909A (zh) * 2024-12-23 2025-04-04 广东思创智联科技股份有限公司 一种基于事件驱动的数据转换方法及系统
CN121217470A (zh) * 2025-11-26 2025-12-26 浙江大学 一种基于选集承诺的双层加密批量解封方法及系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102738013B1 (ko) * 2017-11-09 2024-12-05 엔체인 홀딩스 리미티드 확인 키를 변경으로부터 보호하고 정확성 증명의 유효성을 확인하기 위한 시스템
CN114503509B (zh) * 2019-09-25 2024-04-23 维萨国际服务协会 密钥-值映射承诺系统和方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119759909A (zh) * 2024-12-23 2025-04-04 广东思创智联科技股份有限公司 一种基于事件驱动的数据转换方法及系统
CN119759909B (zh) * 2024-12-23 2025-09-26 广东思创智联科技股份有限公司 一种基于事件驱动的数据转换方法及系统
CN121217470A (zh) * 2025-11-26 2025-12-26 浙江大学 一种基于选集承诺的双层加密批量解封方法及系统

Also Published As

Publication number Publication date
WO2024249467A3 (fr) 2025-04-03

Similar Documents

Publication Publication Date Title
US12295074B2 (en) Verification of interactions system and method
US12470399B2 (en) Methods and systems for ownership verification using blockchain
US12074986B2 (en) Hash function attacks
EP3449450B1 (fr) Mise en oeuvre d'une fonctionnalité de porte logique à l'aide d'une chaîne de blocs
CN114761952B (zh) 提供安全联合机器学习的技术
CN113875190B (zh) 基于哈希的验证方法和装置
WO2024249467A2 (fr) Système, procédé et produit programme d'ordinateur pour des engagements clé-valeur d'accumulateurs et des engagements vectoriels
US20230316272A1 (en) Divisible tokens
EP3973661B1 (fr) Preuve de connaissance
CN114747172B (zh) 加密链接身份
US20220239500A1 (en) Blockchain transaction comprising runnable code for hash-based verification
JP2024525196A (ja) マルチレベルブロックチェーン
Gupta et al. Enhancing blockchain scalability and security: the early fraud detection (EFD) framework for optimistic rollups
US12346895B2 (en) Delegated certificate authority system and method
US12483419B2 (en) Apparatus and method for first value device verification
Li Optimized blockchain deployment and application for trusted industrial internet of things
CN119072899A (zh) 语句证明和验证
Wu et al. Multi-layered retrieval integrity verification mechanism for blockchain oracle
US20230177500A1 (en) Method of conducting financial transactions
KR102954552B1 (ko) 해시 기반 검증을 위한 실행 가능한 코드를 포함하는 블록체인 트랜잭션
Sharad Mangrulkar et al. Essentials of Blockchain Programming
Slowak Sparse and Event-Based Client Designs for EVM-Compatible Blockchains: A Sparse Node Implementation for Ethereum
Jaiswal Introduction to Blockchain and Its Application
KR20230135482A (ko) Did 기반의 생체정보 인증을 이용한 결제 시스템
CN118216122A (zh) 用于分布式区块链功能的方法和系统

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE