Improved Blockchain System and Method

Abstract

A method and system for aggregating multiple signatures is disclosed, where each signature is associated with a different transaction in a block of a blockchain. The method may include receiving multiple different transactions, where each transaction includes transaction data and associated signature data, aggregating the signature data associated with the multiple received transactions to generate an aggregated signature, and generating a block of the blockchain including the transaction data, where the aggregated signature is maintained separately from the transaction data in the generated block.

Description

[Technical Field]

[0001] The present disclosure relates generally to blockchain technology, and more particularly to systems and methods for aggregating signatures associated with different transactions together into blocks of a blockchain. [Background technology]

[0002] Quantum computers threaten to disrupt the security mechanisms underpinning modern blockchain technology. The Elliptic Curve Digital Signature Algorithm (ECDSA), the cryptographic system that protects the authenticity and validity of current blockchain transactions, has known attack vectors. Finding a post-quantum solution to replace ECDSA in blockchain is not straightforward. The use of post-quantum cryptography (PQC) schemes, such as lattice-based cryptography schemes, increases the size of keys and digital signatures, impacting the overall size of the ledger and the transaction throughput of the blockchain network. Strengthening blockchain security requires a more nuanced approach than simply replacing current algorithms with post-quantum cryptography (PQC) algorithms. Summary of the Invention

[0003] Signature aggregation offers a promising solution to at least some of the aforementioned problems of the prior art, balancing high security with mitigating potential drawbacks associated with larger key and signature sizes in post-quantum cryptography schemes. Through signature aggregation, multiple signatures can be combined into a single aggregated signature, optimizing the use of cryptographic resources and minimizing the overhead associated with larger keys. This approach not only increases the efficiency of blockchain operations but also enhances the security of the network against potential quantum-based attacks on cryptographic algorithms.

[0004] According to one aspect of the present disclosure, a method for aggregating multiple signatures into a block of a blockchain is provided. Each signature may be associated with a different transaction. The method may include receiving multiple different transactions. Each transaction may include transaction data and associated signature data. The method may further include aggregating signature data associated with the multiple received transactions to generate an aggregated signature to generate a block of the blockchain, the block including the transaction data and the aggregated signature. The aggregated signature may be maintained separately from the transaction data in the generated block. At least some of the embodiments disclosed herein result in a significant reduction in the size of the aggregated signature when compared to prior art solutions that individually store each signature associated with each transaction on a block of a blockchain. At least some of the embodiments disclosed herein provide a post-quantum signature aggregation method that can aggregate multiple post-quantum signatures, such as lattice-based signatures.

[0005] According to some embodiments, each transaction is associated with a public key pk i and the private key sk i The public and private key pair may be selected using a digital signature scheme. i is the private key sk associated with the transaction i to retrieve the transaction data T associated with the transaction. xi The aggregated signature may be generated by encrypting the public key pk associated with each transaction and the plurality of transaction data. i and signature data s i generating an aggregated signature using an aggregation algorithm in combination with

[0006] Aggregating signature data associated with a plurality of received transactions to generate an aggregated signature includes providing an aggregator configured to generate aggregated signatures using an aggregation algorithm with a public key pk associated with the plurality of transactions. i , signature data s i , and transmitting the transaction data, and receiving the generated aggregated signature.

[0007] According to some embodiments, the digital signature scheme may be any one or more of a multi-use signature scheme, a post-quantum digital signature scheme, or a lattice-based cryptographic digital signature scheme. If a lattice-based cryptographic digital signature scheme is used, the lattice-based cryptographic digital signature scheme may be a hash-and-sign lattice-based cryptographic digital signature scheme, such as the Falcon signature scheme.

[0008] In some embodiments disclosed herein, the generated aggregated signature may include multiple aggregated signature components. These components may include at least a portion of a composite representation, the composite representation, or one or more outputs of a cryptographically verifiable computing algorithm. The cryptographically verifiable computing algorithm may include one of a probabilistically checkable proof and a zero-knowledge proof algorithm.

[0009] In some embodiments, aggregating signature data associated with a plurality of received transactions to generate an aggregated signature includes using a public key pk associated with the transaction. i , the transaction data T associated with the transaction xi, determining at least one composite expression for the received plurality of transactions based on any one or more of the at least one hash function, and using the at least one determined composite expression as input to a cryptographically verifiable computing algorithm to determine at least one component of an aggregated signature. The cryptographically verifiable computing algorithm may be a zero-knowledge proof algorithm, and the at least one determined composite expression may be used as a private witness.

[0010] According to some embodiments, aggregating signature data associated with a plurality of received transactions to generate an aggregated signature includes, for each transaction, i =hash(pk i ,T xi ) to calculate the first parameter r i determining pk i is the public key associated with the transaction, and T xi is transaction data associated with the transaction; and for each transaction, determining a first product r i *s i,1 (In the formula, s i,1 determining a first component a1 of an aggregated signature A by computing a first product r (where r is a first component of the signature data associated with the transaction) and summing the first product across all transactions to compute a first aggregate signature component; and i *pk i *s i,2 (In the formula, s i,2where π is a second component of signature data associated with the transaction, and summing the second products over all transactions to calculate a second aggregate signature component to determine a second component a2 of aggregated signature A; and using the second aggregate signature component a2 as input to a cryptographically verifiable computing algorithm to determine a third component π of aggregated signature A.

[0011] According to some embodiments, aggregating signature data associated with a plurality of received transactions to generate an aggregated signature includes, for each transaction, 1,i =Hash(T xi )-pk i s 2,i +q i The first parameter q such that p i determining pk i is the public key associated with the transaction, and T xi is the transaction data associated with the transaction, and s i,1 is the first component of the signature data associated with the transaction, and s i,2 is the second component of the signature data associated with the transaction, and Hash(T xi ) is a hash value of the transaction data, Hash() is a hash function, and p is a prime number. 1,i ,s 2,i ,q i}, execute a zero-knowledge proof algorithm using the set of first parameters, the first signature component, and the second signature component as a private witness, and verify the plurality of received transactions {pk i , Hash(T xi )} as the public instance and outputting an aggregated signature.

[0012] In at least some embodiments, the size of the aggregated signature is smaller than the sum of the sizes of each signature data associated with each transaction. In some embodiments, the size of the aggregated signature is sublinear with the total number of transactions. In some embodiments, the size of the aggregated signature scales logarithmically with the total number of transactions.

[0013] According to some embodiments, the total number of transactions is greater than a threshold number of transactions for which the size of the aggregated signature is less than the sum of the sizes of the individual signature data associated with each transaction. In other words, an aggregated signature may be associated with a number of transactions equal to or greater than the threshold number of transactions. The sum of the sizes of the individual signature data associated with the threshold number of transactions is greater than the size of the aggregated signature associated with the threshold number of transactions. Thus, if the number of transactions associated with the aggregated signature is greater than or equal to the threshold number of transactions, the size of the aggregated signature is less than the sum of the individual signature sizes of each transaction.

[0014] According to some embodiments, generating a block of the blockchain may include updating the pre-generated block by replacing signature data included in the pre-generated block with the aggregated signature.

[0015] According to some embodiments, the method may further include performing an aggregated signature verification algorithm using the aggregated signature, the plurality of transactions, and the plurality of public keys associated with the plurality of transactions.

[0016] According to another aspect of the present disclosure, a method is provided for verifying transactions in a block of a blockchain using aggregated signatures. The aggregated signatures may be associated with multiple transactions in the block of the blockchain and may be stored in the block of the blockchain. The method may include receiving the aggregated signatures and verifying the validity of the transactions by running an aggregated signature verification algorithm to verify the validity of the aggregated signatures.

[0017] According to yet another aspect of the present disclosure, there is provided a server including at least one processor configured to perform the aforementioned method of aggregating multiple signatures into a block of a blockchain.

[0018] According to yet another aspect of the present disclosure, there is provided a server including at least one processor configured to perform the aforementioned method of verifying transactions in a block of the blockchain using aggregated signatures stored in the block of the blockchain, wherein the aggregated signatures are associated with a plurality of transactions in the block of the blockchain.

[0019] Exemplary, non-limiting embodiments of the present disclosure will now be described with reference to the accompanying figures. [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 is a schematic diagram of a networked computer system in which the methods disclosed herein may be implemented. [Figure 2] FIG. 1 is a schematic diagram of the Bitcoin blockchain illustrating the general structure and properties of a block. [Figure 3] FIG. 1 is a schematic diagram of a known blockchain illustrating how signatures are stored in a conventional blockchain. [Figure 4] FIG. 1 is a schematic diagram illustrating a blockchain including aggregated signature blocks, according to an embodiment of the present disclosure. [Figure 5]FIG. 1 is a schematic diagram illustrating how a blockchain including an aggregated signature algorithm may be used by multiple users to aggregate digital signatures on the blockchain, according to an embodiment of the present disclosure. [Figure 6A] 1 is a process flow diagram illustrating steps involved in a method for aggregating signatures from multiple different transactions, according to some embodiments of the present disclosure. [Figure 6B-1] 5 is a flowchart illustrating a method that may be implemented to aggregate signatures from multiple different transactions in the blockchain of FIG. [Figure 6B-2] 5 is a flowchart illustrating a method that may be implemented to aggregate signatures from multiple different transactions in the blockchain of FIG. [Figure 6B-3] 5 is a flowchart illustrating a method that may be implemented to aggregate signatures from multiple different transactions in the blockchain of FIG. [Figure 7] FIG. 2 is a functional diagram illustrating how the miner of FIG. 1 generates an aggregated signature, according to some embodiments. [Figure 8] 2 outlines functional modules included in the miner of FIG. 1 configured to generate an aggregated signature, in accordance with at least some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0021] The following detailed description includes references to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the description to refer to the same or similar parts. While several exemplary embodiments are described herein, modifications, adaptations, and other implementations are possible. For example, substitutions, additions, or modifications may be made to the components illustrated in the drawings, and the exemplary methods described herein may be modified by substituting, rearranging, deleting, or adding steps to the disclosed methods. Therefore, the following detailed description is not limited to the disclosed embodiments and examples. Instead, the appropriate scope is defined by the appended claims.

[0022] Embodiments disclosed herein are directed to methods for aggregating digital signatures associated with different electronic transactions into a shared signature separate from the associated transaction data. According to some embodiments, the actual size of the aggregated signature may be smaller than the total size of all individual signatures obtained via a digital signature scheme (e.g., a post-quantum signature scheme), such as a lattice-based digital signature scheme. The embodiments disclosed herein may be implemented in the context of a blockchain network, as well as in various other distributed systems, networks, cryptographic protocols, or secure communication platforms. The following index serves as an overview of the remainder of the disclosure.

[0023] 1. System Overview 2. General structure of a blockchain 3. General structure of a blockchain block a. The general structure and characteristics of transaction data, including a typical (e.g., Bitcoin) blockchain b. The general structure and characteristics of transaction data, including the invented blockchain. 4. Exemplary Embodiments a. "Hash and Sign" Lattice-Based Cryptography b. Signature aggregation c. Use of the Falcon signature algorithm 5. Alternative Embodiments (alternative ways in which the principles of the present invention may be implemented not yet described) a. Other potential signature algorithms that may also work this way

[0024] 1. System Overview Figure 1 is a schematic diagram of a networked computer system 1 in which embodiments of the present disclosure may be implemented. In particular, Figure 1 illustrates a networked computer system 1 in which signature data associated with electronic transactions may be aggregated on a blockchain. The illustrated computer system may include a blockchain network in which a ledger of electronic transactions is maintained on the blockchain.

[0025] Electronic transaction data generated by different users are collected in a transaction pool repository 3 via a shared communication network 5. For example, first transaction data T associated with a first user at a first user terminal 7 is X1 , second transaction data T associated with the second user at the second user terminal 9 X2 , third transaction data T associated with the third user at the third user terminal 11 X3 , and fourth transaction data T associated with the fourth user at the fourth user terminal 13 X4 is transmitted to the transaction pool 3 via a shared communication network 5. The transaction data received by the transaction pool 3 is stored and then processed by at least one blockchain miner server 15.

[0026] According to some embodiments, when a predetermined threshold condition is met, at least one blockchain miner server 15 may collect a plurality of transaction data (T x1 …T x4) may be obtained. For example, the predetermined threshold condition may relate to a predetermined number of electronic transactions stored in the transaction pool 3, such that the plurality of transaction data is processed in bulk by at least one blockchain miner server 15. In some embodiments, once the stored transaction data reaches a predetermined number of transactions, at least one blockchain miner server 15 is provided with the plurality of transaction data and processes the transaction data to generate a new block that is added to the existing blockchain and / or to generate a new blockchain. The exact manner in which the new block is generated is not important to this disclosure, and the method of aggregating transaction signatures disclosed herein may be implemented in accordance with any blockchain system. Returning to the example of FIG. 1, at least one blockchain miner server 15 processes the received transaction data to aggregate signatures associated with different electronic transactions in a blockchain. The blockchain itself may further include the transaction data, and the resulting blockchain includes both the electronic transaction data and each associated signature. This allows the electronic transaction data included on the blockchain to be verified using the signature data. Collectively storing the aggregated signature data separately from the associated transaction data in blocks results in reduced storage requirements compared to conventional known blockchain solutions in which signature data is stored together with the associated electronic transaction data. This advantage will become more apparent from the more specific embodiments disclosed below.

[0027] To aid the reader in understanding this disclosure, some background information useful for better understanding this disclosure regarding blockchain is set forth below, followed by a more detailed description of how the signature aggregation method of the present disclosure may be implemented by a blockchain miner server 15 as illustrated in FIG. 1.

[0028] 1 shows a single blockchain miner server 15, it should also be understood that the number of blockchain miner servers included in the system is not important, provided there is at least one blockchain miner server. In a system including two or more blockchain miner servers 15, different blockchain miner servers may compete with each other to generate the next block in the blockchain, as occurs in conventional blockchain systems. In this regard, the signature aggregation methods disclosed herein are compatible with known blockchain systems.

[0029] 2. General structure of a blockchain By way of background, a blockchain is a distributed ledger that represents all transactions that take place within a network, such as computerized network 1 in Figure 1. Transaction data is persistently stored in files called blocks, which are organized linearly over time in a chain-like structure called a "blockchain." As new transactions occur, new blocks are created and appended to the end of the blockchain. Thus, a blockchain provides a ledger that contains a record of all transactions that have occurred over time. This is the basic structure of a blockchain.

[0030] 3. General structure of a blockchain block Here, we will explain the structure of blocks contained in the blockchain. As shown in Figure 2, each block can be divided into three sections. Block Metadata

[0200] Block header

[0202] Transaction data

[0204]

[0031] The block metadata

[0200] may contain general characteristics of the current block, including but not limited to: Magic number (file signature)

[0206] - indicates the type of data contained in the file. It is the same for all blocks belonging to the same blockchain. Size of the current block

[0208] - number of bytes that continue to the end of the block Number of transactions in the current block

[0210]

[0032] The block header describes certain characteristics of the current block, such as the time and location of the current block, including but not limited to: Block Version

[0212] - Specifies the current version of the blockchain software. Previous block header hash

[0214] - a reference to the previous block Hashes of all transactions in the block

[0216] - Merkle root hashes of all transactions in the block Timestamp

[0218] - Current block timestamp Unix time (number of seconds since 1970-01-01T00:00 UTC) · Bit difficulty

[0220] - Current mining difficulty target Nonce

[0222] - Number of attempts to solve the proof of work (starting from 0)

[0033] 3a General structure and characteristics of transaction data, including a typical (e.g., Bitcoin) blockchain A transaction represents a transfer of resources between two or more accounts on the blockchain. In some embodiments, the resources may relate to financial resources, such as the transfer of funds. A transaction references previous transaction outputs as new transaction inputs and assigns all underlying currency values to the new outputs. This is formally realized as a state transition function, with each state representing the ownership status of all digital currencies in circulation. Note that a blockchain can contain any type of transaction data, but for non-limiting purposes of describing the present invention, we will assume that the blockchain is being used as a ledger of financial transactions. Figure 3 shows a schematic diagram of how transaction data is stored in blocks of a typical blockchain. Transaction data is stored in three groups: Header

[0300] - Contains instructions for sending the original currency. It contains the hash of the previous transaction and the output of the referenced transaction. The output of the referenced transaction is used as input to the current transaction. · Data

[0302] - Recipient's public key. Digital Signatures

[0304] - Within the context of digital signature schemes, a digital signature is generated by an algorithm such as the Elliptic Curve Digital Signature Algorithm (ECDSA) currently used in the Bitcoin blockchain via a hash of a simplified version of the transaction, which is used to prove that the transaction was created by the actual owner of the underlying currency involved in the transaction.

[0034] Note the one-to-one relationship between each transaction and a digital signature.

[0035] A digital signature is the result of an asymmetric cryptography scheme, a type of cryptography technique in which the key used to encrypt data (the private key) is different from the key used to decrypt the data (the public key). Asymmetric cryptography schemes are also known as digital signature schemes.

[0036] In a public / private key scheme or digital signature scheme, the sender follows a specific process to ensure confidentiality, authenticity, and non-repudiation of the message sent to the receiver. This process may include the following steps: 1. Message Signed with Sender's Private Key: The sender first signs the message using their private key. This process involves creating a digital signature of the message. A digital signature is a unique cryptographic representation of the message generated using the sender's private key. The digital signature provides a means of proving that the message was sent by the sender who owns the private key and that the message has not been tampered with in transit. 2. Message Encryption with the Recipient's Public Key: After signing the message, the sender encrypts the entire message (including the digital signature) using the recipient's public key. The public key is part of the recipient's public / private key pair. Public keys are intended to be freely distributed so that anyone can use them to encrypt messages intended for the recipient. 3. Sending the Encrypted and Signed Message: The sender then sends the encrypted and signed message to the recipient, who is the only person in possession of the corresponding private key that can decrypt the message and verify the digital signature. 4. Receiver Decryption and Signature Verification: Upon receiving the message, the receiver uses its private key to decrypt the message and recover the original contents, including the digital signature. The receiver can then verify the digital signature using the sender's public key, which is widely available. If the digital signature is valid, it confirms the authenticity and integrity of the message, since only the sender's private key could have generated the signature.

[0037] Thus, digital signature schemes correspond to cryptographic algorithms that allow for the creation and verification of digital signatures, providing a means to ensure the authenticity and integrity of digital messages or data. It should be understood that in some alternative processes, encryption is not required.

[0038] A digital signature scheme may be defined by a set of algorithms (KeyGen, Sign, Verify) that work as follows: KeyGen(λ) → (sk, pk): Taking as input a security parameter λ that indicates the desired security level, the KeyGen algorithm generates a new random key pair (sk, pk) ∈ K S ×K P where sk is the private key or private signing key, pk is the corresponding public verification key, and K S is the private key set, and K P is the public key set. Sign(sk, μ) → s: Given a private key sk and a message μ (e.g., a transaction Tx), the Sign algorithm generates a signature s∈S, where S denotes a signature set. Verify(pk, μ, s) → b∈{0,1}: The Verify algorithm takes as input a public verification key pk, a message μ, and a signature s, and outputs a bit b, which indicates whether the signature s is valid for the given message μ with the public verification key pk.

[0039] λ translates into the security level of a digital signature scheme. λ is a measure of the scheme's resistance to various attacks, including brute force attacks and highly sophisticated mathematical attacks. λ quantifies the amount of computation required for an adversary to forge or destroy a digital signature, which essentially determines the strength of a cryptographic scheme. The security level is generally measured in bits, indicating the number of bits required to express the security parameters of the cryptographic scheme. For example, if a digital signature scheme has a security level of 128 bits, an attacker would need approximately 2000 bits to break the scheme using most well-known cryptanalytic algorithms, e.g., by using a brute force attack. 128This means that multiple operations must be performed. Security levels are often associated with the key size and other parameters of the lattice used in the scheme. Higher security levels typically require larger key sizes and more complex mathematical operations to ensure resistance to attacks. A larger key size can affect the size of the signature. In this specification, size refers to the number of bits or bytes required to store the signature / key representation, regardless of signature size or key size. The larger the signature / key size, the more data is required to represent the cryptographic signature / key. The signature or key representation can take different formats, such as a bit string or a hexadecimal string. These formats are common ways of representing the binary data that constitutes the signature / key in a human-readable or machine-readable form. The choice between a bit string and a hexadecimal string can depend on factors such as desired readability, data size, ease of handling, and compatibility with existing systems or protocols.

[0040] In a particular cryptographic scheme, a signature is a set of multiple components s=(s1,…,s M ), where M is the total number of signature components. Each part or component may have a specific purpose and contribute to the overall validity of the signature. In some cryptographic schemes, one of the signature components may correspond to the actual signature itself, generated with the signer's private key, representing the core cryptographic proof of authenticity and integrity. Meanwhile, other components may serve to augment the complexity or security of the overall scheme. These additional components may include various mathematical structures or values derived from the actual signature, private and public keys, the message being signed, or other cryptographic elements. By incorporating these extra components, the scheme may achieve certain security properties, such as increased resistance or protection against certain types of attacks.

[0041] It should also be understood that signatures can be classified as either one-time-use or multi-use based on their intended purpose and design. One-time-use signatures, as the name suggests, are signatures intended for a single transaction or message. In these schemes, each key pair is limited to a single use, significantly limiting the practical application of key pairs. The reason behind this limitation is that generating multiple signatures using the same key pair compromises the security of the key pair, and the key pair or parts of the key pair may be disclosed to other users. As a result, one-time-use signatures are not widely deployed in real-world scenarios. Conversely, in many practical applications, such as blockchain technology, multi-use signature schemes are widely used. Examples of such schemes include RSA and ECDSA. In multi-use signature schemes, a single public key can be used for multiple transactions or messages, making them more efficient and suitable for large-scale deployment in various cryptographic protocols and systems.

[0042] As mentioned above, the purpose of the Verify algorithm is to perform a calculation to verify the validity of the signature. This step may involve verifying certain mathematical relationships or constraints to ensure that the signature corresponds to a given message and was generated using the correct private key sk. A message digest h(μ) may also be used, which may correspond to a fixed-size digest or hash value of the message μ. Many verification algorithms are available, and the choice of verification algorithm depends directly on the selected KeyGen and Sign algorithms. Some digital signature schemes may use some cryptographically verifiable algorithms (e.g., RSA) to generate the signature, while other digital signature schemes may use some probabilistic or zero-knowledge proof algorithms.

[0043] A zero-knowledge proof (ZKP) algorithm is a cryptographic protocol that allows one party (the prover) to prove the correctness of a statement to another party (the verifier) without revealing any additional information (zero knowledge) other than the fact that the statement is true. In other words, the prover provides the verifier with proof of the statement's correctness. One of the properties of a zero-knowledge proof is that it can be easily verifiable. The verifier should be able to efficiently verify the proof without having to perform the same complex computations as the prover. A ZKP includes a private witness and a public instance, which may be used individually or in combination in a statement. A private witness is secret information that the prover possesses and wants to prove knowledge of without disclosing it to the verifier. A public instance, on the other hand, is publicly available information. During the proof generation process, the prover constructs a proof using the private witness and the public instance, and this proof is provided to the verifier. The verifier can then use the proof together with the public instance to verify the accuracy of the proof without knowing anything about the private witness.

[0044] In the context of digital signatures, ZKPs can be used to prove the validity of a signature without revealing the actual contents of the signature or the private key used to sign it (private witness). Zero-knowledge proofs are inherently probabilistic rather than deterministic. This probabilistic nature results from the need for multiple interactions between the prover and verifier, gradually building higher levels of assurance that the prover possesses secret knowledge without revealing it. In these interactions, the verifier interacts with the prover by asking specific questions or requesting computations that only someone with knowledge of the secret (e.g., private key or signature) can answer correctly.

[0045] As a result of these repeated interactions, ZKPs are often interactive protocols. During the interaction, the verifier poses a challenge or question to the prover, and the prover responds accordingly. The verifier accepts the proof only if the prover's response demonstrates a deep understanding of the secret, without actually disclosing the secret itself. However, this interactive reasoning can be converted into a non-interactive protocol via the Fiat-Shamir transformation. This technique is used to convert interactive identification protocols into non-interactive zero-knowledge proof systems. In this transformation, the verifier's random challenge is replaced with the result of a random oracle or hash function (which the verifier can verify the prover's correct execution to produce the randomness of the challenge). This makes the challenge unpredictable to the prover, ensuring the security of the non-interactive version and achieving the same effect as a truly random verifier challenge. For example, in a scenario where the signer (prover) has a function f and an image pk = f(sk) as public keys, the prover holds sk as a private key. To sign a message μ, a prover provides a non-interactive zero-knowledge proof that shows knowledge of sk (a private witness) that satisfies pk = f(sk) by using the message μ to create a proof challenge H(μ). Here, H is a public hash function or random oracle that maps μ to a "random looking." If the function f is one-way, the verifier can be confident that the proof could only have been created by an entity that knows sk, ensuring the security of the non-interactive zero-knowledge proof system. Examples of ZKPs include Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) and Zero-Knowledge Scalable Transparent Argument of Knowledge (zk-STARK).

[0046] Zero-knowledge proofs (ZKPs) may encode statements to be proven using various mathematical techniques or intermediate expressions, depending on the context and requirements of the zero-knowledge proof system and / or the statement that needs to be proven. The intermediate representation serves as a structured and condensed representation of a computation, decomposing the computation into mathematical constraints, logical operations, or algebraic structures to achieve a more efficient and concise representation. For example, in the case of a zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) proof, a statement is decomposed into simple arithmetic units such as addition, subtraction, multiplication, and division. These operations are then presented in the form of an arithmetic circuit, where inputs and arithmetic operations are represented as wires and gates in a directed acyclic graph (DAG). This graph processes inputs and evaluates polynomials by performing arithmetic operations on the inputs.

[0047] Within the zk-SNARK protocol, several intermediate representations play a valuable role. R1CS (Rank 1 Constraint System): R1CS is a set of constraints that allows verification of each step in an arithmetic circuit and ensures that the output of the computation is as expected. QAP (Quadratic Arithmetic Program): The prover uses a QAP to construct a proof of a statement. Instead of checking many individual constraints as in R1CS, the QAP representation bundles all these constraints into a single constraint, making verification more efficient. Finally, QAPs are used in zk-SNARK protocols to prove assertions through a dialogue between prover and verifier, providing a concise, non-interactive argument of knowledge about the validity of a statement.

[0048] The result of a ZKP algorithm can be a proof string or proof object, which provides a verifier with evidence that the prover possesses knowledge of a valid solution to a particular problem or statement. Proofs are designed to allow a verifier to efficiently verify the validity of a proof without gaining knowledge of the prover's secret. When a proof is valid, the verifier can be assured that the prover actually possesses the necessary knowledge without knowing the details of that knowledge. In the context of a digital signature scheme, a ZKP proof can be integrated as one of the components of the signature, contributing to the overall size of the signature, or it can represent the signature itself.

[0049] Traditional public-key cryptography relies on the difficulty of certain mathematical problems on classical computers, such as integer factorization or the discrete logarithm problem. However, the rise of quantum computers poses a threat to these cryptographic schemes, as quantum computers could efficiently solve these problems, rendering current cryptographic algorithms vulnerable.

[0050] To address this potential threat, various post-quantum digital signature schemes have been developed that utilize mathematical structures such as Euclidean lattices or symmetric key primitives such as cryptographic hash functions, and are believed to be resistant to attacks by large-scale quantum computers.

[0051] In response to growing concerns about quantum computing, the National Institute of Standards and Technology (NIST) began the process of developing standards for post-quantum cryptography, including encryption and digital signature schemes, in 2016. NIST's efforts to establish post-quantum digital signature guidelines aim to ensure that secure communications and digital authentication infrastructures are robust and usable even in the presence of a strong quantum adversary. In July 2022, NIST announced plans to standardize three post-quantum digital signature schemes: Falcon, Dilithium, and SPHINCS+. However, it is notable that these post-quantum signature algorithms have larger public key and signature sizes, typically in the range of 30 to 100 times larger, compared to pre-quantum signature algorithms such as ECDSA. As an example, NIST Security Level 1 (NSL)

number

[0052] Among various post-quantum cryptography (PQC) schemes, one family that has emerged as particularly promising is the lattice-based signature scheme (e.g., Falcon and Dilithium). Lattice-based cryptography relies on the difficulty of certain mathematical problems related to lattices. A lattice is a structure formed by a periodic arrangement of points in a multidimensional space. The security of lattice-based schemes is based on the difficulty of a limited class of lattice problems, ranging from the "Shortest Vector Problem" (SVP), the "Closest Vector Problem" (CVP), the "Short Integer Solution Problem" (SISP), or the "Ring Learning With Error Problem" (RLWEP), which are considered resistant to quantum attacks.

[0053] Whether implemented in software or hardware, efficient lattice-based signature schemes often establish their security through proofs in a random oracle model. These schemes can be roughly categorized into two families: the hash-and-sign family (e.g., Falcon) and signature-based identity schemes employing the Fiat-Shamir heuristic (e.g., Dilithium) or related variants.

[0054] Digital signature schemes that follow the hash-and-sign paradigm adhere to certain criteria. Before being signed, a message μ undergoes a hashing process. This involves hashing μ to a specific point h = H(μ), provided that h is within the domain of a specified trapdoor function f. The message is then hashed and becomes the subject of a signature, creating s = f-1(h). Verifying the validity of a message / signature pair (σ, μ) relies on a verification algorithm that confirms whether the equation f(s) = H(μ) holds. The connection between lattices and hash-and-sign signatures is rooted in the insight that a concise basis for lattices can potentially provide the aforementioned trapdoor function. Conversely, digital signature schemes formulated within the Fiat-Shamir paradigm take a different approach. They begin as identification schemes and are then transformed through the Fiat-Shamir transformation, a process that facilitates the conversion of an identification scheme into a signature scheme.

[0055] In almost all lattice-based signature verification processes, a central computation involves computing lattice vectors using matrix-vector multiplication to verify the validity of the lattice-based signature and ensure the authenticity and integrity of the signed message. Additional steps may also be required, such as performing range checks and ensuring that the norm of the signature is below a predetermined threshold.

[0056] 3b General Structure and Characteristics of Transaction Data According to Embodiments of the Present Disclosure The general principle of this disclosure is to aggregate digital signatures

[0304] associated with different transactions into a separate block from the associated transaction data [300, 302]. This allows the resulting blockchain to eliminate the overhead of storing one digital signature per transaction, thereby significantly reducing the size of blocks. FIG. 4 is a schematic diagram of how transaction data is stored on a blockchain, according to an embodiment. This new technique retains the structure of all transaction data 400 in FIG. 4, except for the digital signatures associated with each transaction, which are combined into a single aggregate signature 402 in FIG. 4. FIG. 5 illustrates how a blockchain including an aggregated signature algorithm can be used by multiple users to aggregate digital signatures on the blockchain. Digital signatures 500, 502, and 504 in FIG. 5 are aggregated into a single aggregate signature 506 in FIG. 5 to reduce the memory requirements for storing signatures on the blockchain.

[0057] One of the main goals of signature aggregation is to reduce the size and computational overhead of processing multiple signatures and improve the efficiency and scalability of cryptographic operations. By aggregating multiple signatures into a single signature, the overall data overhead is reduced, resulting in more efficient and manageable communication and storage.

[0058] In the context of blockchain, where multiple transactions are bundled into blocks and each transaction is associated with a signature, signature aggregation can provide several advantages and increase the overall efficiency of the blockchain. For example, signature aggregation can significantly reduce the size of each block by combining multiple signatures into a single aggregated signature. This reduction in block size directly reduces storage and bandwidth requirements, improving scalability and speeding up transaction processing. Another advantage of signature aggregation is that it can allow some of the computations related to signature verification to be performed off-chain. While performing all computations directly on the blockchain can be resource-intensive and slow, off-chain computations utilize external devices to perform these computations. The results are then verified on-chain, which is more cost-effective than performing all computations on-chain. Off-chain parties (called aggregators) may be untrusted and may not require communication with on-chain parties. This approach brings significant advantages to blockchain systems, including improved scalability and reduced on-chain resource requirements.

[0059] In the context of PQC, where lattice-based or other post-quantum cryptography schemes are used, reducing the storage requirements associated with signature aggregation is particularly advantageous due to the larger key and signature sizes inherent in many PQC algorithms.

[0060] Incorporating aggregation capacity into a digital signature scheme may involve the addition of two algorithms (Aggregate, AggregateVerify) that work as follows: Aggregate((μ i ,pk i ,s i ) i=1:N ) → A: N message key signature triples (μ1, pk1, s1), ..., (μ N ,pk N ,s N ) and outputs an aggregate signature A. AggregateVerify((μ i ,pk i ) i=1:N ,A)→b∈{0,1}:N message-key pairs (μ1,pk1),...,(μ N ,pk N ), and a list of aggregate signatures A, and outputs bit b, which indicates whether signature A is a valid aggregate signature for the given set of message-key pairs.

[0061] Thus, a digital signature scheme may be defined by a tuple of algorithms (KeyGen, Sign, Verify, Aggregate, AggregateVerify). Some alternative algorithms may require the participation of the signing entities in one or more interactions and a private key (sk). Furthermore, in certain scenarios, the Verify algorithm may be omitted, since its functionality can be included in AggregateVerify, making it possible to verify individual signatures during the verification of the aggregated signature, or alternatively, the verification phase may only check the validity of the aggregated signature, since the aggregated signature can be valid only if each individual signature is valid.

[0062] The Aggregate and AggregateVerify algorithms provide the necessary foundation for compressing digital information without sacrificing its integrity. AggregateVerify allows for the verification of aggregated signatures, confirming their ability to store compressed transaction information on the blockchain. In fact, AggregateVerify, used as a verification function, can be used to ensure that aggregate signatures are correct and verify that the set of transactions on the blockchain represents the true set of legitimate transactions submitted as input. Thus, running AggregateVerify on an aggregate signature allows the blockchain to verify the resulting aggregate signature before recording it on the chain.

[0063] The actual size of the aggregated signature A may vary depending on different scenarios and factors, including the specific signature aggregation technique used, the number of signatures being aggregated, the signature scheme itself, and any additional metadata or overhead involved in the aggregation process.

[0064] In certain scenarios, the signature aggregation scheme may involve a simple concatenation process, generating N individual signatures (s1,...,s N ), the size of the aggregate signature A formed by aggregating all the signatures is equal to N times the size s of the individual signatures, so |A| = |O(N)| = N * |s|. This mode of linear aggregation is possible for any signature scheme, without loss of generality.

[0065] However, in other cases, the aggregated signature may be more compact, resulting in a sublinear size with respect to N. For example, the size of the aggregated signature may scale logarithmically with N (|A| = |O(ln(N))|). In such cases, the aggregated signature becomes more efficient to publish than the N individual signatures in an asymptotic sense. This means that as the number of signatures N increases, the size of the aggregated signature grows more slowly than the linear increase seen when concatenating the signatures individually. There is a space-saving effect. Due to the constant factors involved in the asymptotic notation, there exists a threshold for the number of signatures N above which the compression or compactness effect is not evident. This threshold is determined by logarithmic scaling. For example, if the size of the aggregated signature is given by |A| = C1 ln(N),

number

[0066] In certain protocols, public keys (pk1,..., pk N ) may be published together with the aggregated signature. In such embodiments, assuming a logarithmic scaling, space savings can be observed when the number of signatures N satisfies the following condition. N|pk| + C1 ln(N) + C2 < N(|pk| + |s|), where C2 is a constant and |pk| is the size of an individual public key. This equation represents a trade-off between the size of the aggregated signature and the space required for the publication of the public keys.

[0067] Space savings in the aggregated signature may be achieved by using a composite expression, which refers to a structured and / or condensed representation of individual signatures using various mathematical objects or models. For example, the composite expression may correspond to a mathematical structure derived from individual signatures s, their components, or other related data (such as public keys, messages, etc.) with various cryptographic functions such as hash functions, random oracles (idealized hash functions), or bilinear pairings. Thus, the space savings (the size of the aggregated signature A) may be based on the selected composite expression. For example, an exemplary use case may include summing all signatures and storing the sum as the aggregated signature instead of storing each individual signature separately. If each signature can be represented as a number of K bits, the maximum value of the sum of N K-bit numbers is N * 2 K which becomes. Using binary logarithm notation, the maximum number of bits required to represent such a sum is floor(ln2(N * 2 K )) + 1, and an aggregated signature size that increases and decreases logarithmically with N (|A| = |O(ln(N))|) is obtained. Another example showing similar scaling may include a linear combination where the coefficients are derived from a random oracle (instead of a simple sum). This random oracle is queried for all aggregated signatures, and the resulting coefficients are used to calculate the linear combination.

[0068] Note that the space savings associated with aggregated signatures does not result from any compression techniques. Compression techniques are designed to convert data into a more compact form that can be restored or expanded for later use. However, in the case of aggregated signatures, in contrast to compression techniques, non-aggregated signatures cannot be recovered from the aggregated signature. Instead, the space savings of aggregated signatures are achieved by other means, such as using complex formulas and mathematical relationships to efficiently verify the validity of multiple signatures without storing them individually.

[0069] Similar to non-aggregate signatures, an aggregate signature A is also denoted by A=(a1,…,a M’ ), the total number of aggregated signature components is denoted by M', and these components may be part of complex expressions and may be related to each other via various mathematical relationships.

[0070] In most scenarios, aggregate signature schemes maintain a level of security within the system, despite aggregating multiple signatures, because the security level of the aggregate signature is determined by the weakest link among the individual signatures, as well as the security of the aggregation algorithm itself.

[0071] According to some embodiments, the aggregate signature A can also be generated using a zero-knowledge proof algorithm. For example, according to one embodiment, the aggregator (prover) can generate N signatures (s1,...,s2) without revealing any information. N ) (private witnesses), and a function F((μ i ,pk i ,s i ) i=1:N) = A. To accomplish this, the aggregator may use a zk-SNARK to encode all the relevant information needed to verify the validity of the individual non-aggregated signatures as several high-order polynomials over a finite field that contain more elements than the highest order of these polynomials. For example, the aggregator may compute interpolated polynomials that, when evaluated over a subset of the underlying field, provide all of the signatures being aggregated, along with additional interpolated polynomials that evaluate all corresponding public keys. The aggregator may then compute the set (μ i ,pk i ) i=1:N An unpredictable challenge is created and a proof is generated using a proof system. In embodiments using post-quantum cryptography (PQC) in a digital signature scheme, a quantum-resistant or post-quantum zero-knowledge proof (ZKP) algorithm may be used to ensure security and resistance against potential attacks from quantum computers. One example of such a post-quantum ZKP algorithm is the Aurora algorithm. For individual signatures, the ZKP proof may be integrated as one of the components of an aggregated signature A, contributing to the overall size of the signature, or it may represent the signature A itself. The size of the aggregated signature, when generated using a ZKP algorithm, depends on the particular proof system selected. Not all proof systems produce the smallest proof size for all types of statements. Therefore, certain proof systems may be more suitable for the aggregation process because they can provide more efficient and compact proofs in certain scenarios.

[0072] A further advantage may be associated with the use of zero-knowledge proof (ZKP) techniques in formulating the aggregate signature scheme. In the exemplary embodiment above, the aggregator (prover) does not reveal individual signatures to the verifier. These signatures may therefore be omitted entirely from the resulting aggregate signature, resulting in significant space savings.

[0073] In some embodiments, a non-zero-knowledge proof system may be employed. While this approach may in some circumstances reveal certain non-zero information related to the private witness (in this context, the individual signature), this may be acceptable within the framework of an aggregate signature scheme, since in many applications, digital signatures may not encapsulate private or sensitive information.

[0074] 4. Exemplary Embodiments FIG. 6A illustrates steps involved in an exemplary process for aggregating signatures in a blockchain from multiple different transactions, according to one embodiment. The process steps illustrated in FIG. 6A may be performed by at least one miner server 15 of the blockchain network 5 shown in FIG. 1. In step 1, the miner server 15 receives multiple different transactions Tx, each including transaction data and its associated signature data s. For example, the multiple transactions may correspond to multiple transactions selected from the transaction pool 3 of FIG. 1. In some embodiments, each transaction is signed using a distinct public-private key pair (pk) selected using a digital signature scheme (e.g., KeyGen, Sign, Verify). i ,sk i ) The signature data s associated with the transaction i is the private key sk associated with the transaction i Transaction data Tx i Furthermore, in some further embodiments, each signature data s i can be written using multiple different signature components i= (s i,1 ,...,s i,M ) may also be included.

[0075] In some embodiments, signatures s associated with multiple different transactions Tx iis a multi-use signature. Furthermore, in some other embodiments, the signature data s i and the corresponding public key pk i and the private key sk i The pair may be generated using a post-quantum cryptographic digital signature scheme. By using post-quantum cryptography for signature generation, a blockchain network may enhance the security of the blockchain network against potential threats posed by advances in quantum computing and future-proof the system. More specifically, in some embodiments, the post-quantum cryptographic digital signature scheme is a lattice-based cryptographic digital signature scheme. Examples of lattice-based cryptographic digital signature schemes include Falcon, Dilithium qTESLA, Rainbow, and Bliss digital signature schemes. In yet another embodiment, the lattice-based cryptographic digital signature scheme is a hash-and-sign signature. The Falcon signature scheme is an example of a hash-and-sign lattice-based signature.

[0076] When multiple transactions are received, the server miner 15, in step 2, creates the signature data s associated with these transactions. i to generate an aggregated signature A. This aggregation process generates a set of transaction key signature triples (Tx1, pk1, s1), ..., (Tx N ,pk N ,s N) in a particular embodiment, at least one miner server 15 may act as an aggregator, meaning that the miner 15 generates the aggregated signature and performs the computations necessary to achieve this. Alternatively, generation of the aggregated signature may be performed off-chain by an external aggregator. This external aggregator may be untrusted and may not need to interact with any on-chain parties other than the at least one miner server 15. Thus, aggregating signature data may include sending a plurality of different transactions configured to generate an aggregated signature to an external aggregator, and receiving the generated aggregated signature from the external aggregator.

[0077] In some embodiments, if multiple distinct transactions comprise a number N of transactions, the size of the aggregated signature A is the sum of the number of distinct transactions (s i ) i=1:N Alternatively, the number of transactions N may be less than a threshold number N of signatures for which compression or compactness effects are not evident. th In fact, in some embodiments, the size of the aggregated signature A may be sublinear in size with respect to N. For example, in some embodiments, the size of the aggregated signature A may scale logarithmically with N (|A|=|O(ln(N))|). As the number of transactions N exceeds this threshold (Nth), the aggregated signature becomes increasingly advantageous in terms of space efficiency, as its size grows at a slower rate compared to the cumulative size of the individual signatures for each transaction.

[0078] In some embodiments, aggregate signature A may be generated using a zero-knowledge proof algorithm or a post-quantum zero-knowledge proof algorithm. Examples of post-quantum zero-knowledge proof algorithms may include the Aurora algorithm.

[0079] In some embodiments, the aggregated signature A may be composed of multiple aggregated signature components A=(a1,...,a M’ ), where M′ denotes the total number of aggregated signature components. These components may be parts of a complex formula, a complex formula, the output of a cryptographically verifiable computing algorithm, or a combination thereof. Examples of cryptographically verifiable computing algorithms may include zero-knowledge proof algorithms (e.g., Aurora algorithm, Plonky2, zk-STARK) or probabilistically checkable proofs. Alternatively, in some other embodiments, aggregate signature A may include a single component that may be a complex formula or the output of a cryptographically verifiable computing algorithm.

[0080] Finally, in step 3 of Figure 6A, the miner server 15 generates a block of the blockchain. This block includes the transaction data and the aggregated signature, where the aggregated signature is maintained separately from the transaction data in the generated block. In some embodiments, the block may have been previously generated, so generating the block of the blockchain may involve updating the existing block by replacing all individual signatures with the aggregated signature A. In some embodiments, the block may be entirely new, so generating the block of the blockchain may involve creating a new block that directly includes the aggregated signature.

[0081] 4a Post-quantum signature aggregation using hash-and-sign lattice-based signature schemes (e.g., Falcon signatures) According to some quantum-resistant embodiments, a quantum-resistant signature scheme can be selected. For example, the selected signature scheme can be related to a lattice cryptography scheme or any other quantum-resistant lattice cryptography scheme. An aggregate signature can then be generated using the mathematical properties of lattice-based public key cryptography. The following sections of the description will detail the procedure illustrated in FIG. 6A, particularly as applied to signatures generated using the Falcon signature scheme. Nevertheless, it is important to understand that the described method can be adapted to encompass various types of hash-and-sign lattice-based signature schemes. A common feature shared among these different schemes is a verification algorithm that involves verifying the validity of a particular vector by determining whether it exhibits short properties within the lattice.

[0082] The Falcon signature scheme consists of three stages: (1) Key generation FALCON ) outputs the public key pk and the private key sk. (2) Signature Function (Sign FALCON ) is the sum of sk and transaction data T x and outputs a signature s = (s1, s2) using two signature components (polynomials) s1 and s2. Here, s2 represents the actual signature generated using the private key sk, and s1 satisfies the following relation s1 = hash(T x )-s2*pk mod Φmodp, hash() is a hash function that outputs the elements in the polynomial ring, and T x is the transaction data, pk is the public key corresponding to the private key sk, Φ is a monic polynomial, and p is a prime number. (3) Verification function (Verify FALCON ) is pk, s, T x Obtain s1+s2·pk=hash(T x), and outputs the validity of the signature (true or false) by checking that ||s|| is below some bound (a suitably short vector). The product s2·pk refers to polynomial multiplication. Note that all elements are typically in a polynomial ring (a mathematical structure), and hash functions output elements on a polynomial ring. For example, Falcon signatures are one lattice-based signature scheme of this type.

[0083] Stage (1) enables the creation of an asymmetric key pair that is used to provide secure private transaction broadcasting in a blockchain environment. The private key, for example, provides access to the available funds of a user account, ensuring that only those with the private key can access the available funds in the account. The public key is used to prove ownership of the funds when transacting those funds in a manner that is publicly verifiable by the rest of the network participants.

[0084] Stage (2) allows the payer to prove that they own the funds involved in the transaction. When a transaction is made, the payer signs the transaction with their private key. The resulting output is a digital signature that allows the payee to verify the payer's identity.

[0085] Stage (3) is the process by which the payee can verify the sender's proof that they own the funds involved in the transaction. The payee decrypts the signed message from stage (2) using the sender's corresponding public key (pk) to verify the sender's identity.

[0086] The transaction data (i.e., message), signature, and their corresponding public key, {(T xi ,s i ,pk i )} i=1~k Given a set of i, the signature s for all i i The method for aggregating is as follows: First, k random values r1,...,r k =Hash2({pk i ,T xi},pp,β) is computed, where pp is some public parameter and Hash2 is a hash function that outputs some value less than some bound β. β is a predetermined value of a form defined in the chosen signature scheme, and that value is provided by the output of the Hash2 algorithm. In other words, for each transaction T xi For the value r i is calculated according to the above formula. The parameters pp and β are included to improve security. Their values may depend on the signature scheme selected. For example, if the Falcon signature scheme is used, the value of β may be determined according to Equation 2.15 in the publication entitled "FALCON: Fast Fourier Transform Lattice-based Compact Signature over NTRU," specification 1.2, by Fouque et al., available at the address https: / / falcon-sign.info / falcon.pdf. Therefore, in some embodiments, those parameters may be omitted entirely, in which case r,...,r k =Hash2(pk i ,T xi ). Any cryptographic hash function can be used. The value r i Once determined, the signature s i can be aggregated.

[0087] (Process 1) The process for aggregating an aggregate signature is shown in Figure 7. The aggregate signature includes three components a1, a2, and π, and is defined as A = (a1, a2π). Components a1 and a2 are expressed by the following formula: a1 = Σr i *s i,1 ,a2=Σr i *pk i *s i,2The third component of aggregate signature A, π, can be calculated using a zero-knowledge proof algorithm from knowledge of component signatures a2. This also verifies that a2 was generated correctly. One example of a zero-knowledge proof algorithm that may be used is the Aurora algorithm, which has the added advantage of being quantum-safe. More information about the Aurora algorithm can be found at https: / / eprint.iacr.org / 2018 / 828.pdf. However, it should be understood that any zero-knowledge proof algorithm may be used, including, but not limited to, a recursive zero-knowledge proof algorithm, but if it is desired that the method be quantum-safe, then a quantum-safe zero-knowledge proof algorithm is required.

[0088] Given a message T xi , signed s i , and the public key pk i Regarding F({T xi ,s i ,pk i} i )=Σr i *pk i *s i, There exists a function F() such that = a2. Therefore, the zero-knowledge proof algorithm is xi , signed s i , public key pk i Given,F,, we can prove the function,F(),from which the third aggregated signature component,π,can be determined.,This process is illustrated in Figure 7.

[0089] Alternatively, in some embodiments, the process for aggregating aggregate signatures may involve only generating proofs using a zero-knowledge proof algorithm. In such embodiments, the use of compound expressions a1 and a2 is not necessary, and the aggregated signature A may be uniquely represented by the proof π, since it plays a more valuable role in the verification process of the aggregated signatures. In other words, the aggregation mechanism does not rely on a particular compound expression for the aggregated signature, but instead relies on zero-knowledge proofs to create the aggregated signatures. However, the process may require the use of compound expressions to generate the private witness, or at least one component of the private witness. An example of such a process is provided below. (Process 2) 1.i-th signature (s 1,i ,s 2,i ) and the corresponding public key and message (pk i ,m i ) 2.Hash(m i ) 3. q in [-(p-1) / 2,(p-1) / 2] i stHash(m i )-pk i s 2,i +q i Calculate p. 4.s 1,i =Hash(m i )-pk i s 2,i +q i Calculate p 5. Private Witness 1,i ,s 2,1 ,q i} i=1~N ) and public instance ({pk i ,Hash(m i )} i=1~N ) and implement a zk proof system for the following arithmetic relations 1. For i in [N}, s 2,i All coefficients in, i.e., s in [-(p-1) / 2,(p-1) / 2] 2,i Perform range check on 2. For i in [N], s 1,i =Hash(m i )-pk i s 2,i +q i Check p for equality 3. For i in [N], q i All coefficients in, i.e., q in [-(p-1) / 2,(p-1) / 2] i Perform range checks on 4. For i in [N], range check ||s 1,i || 2 +||s 2,i || 2 <β 2 Do 6. Output the aggregated signature π, which is the proof output by the ZK proof system.

[0090] To implement the above method, the miner 15 may include an aggregation processing module 801, a proof system module 803, and a memory module 805, as shown in FIG. xi , signed s i , public key pk i Data received via input / output module 807, such as , may be processed by aggregation processing module 801. For example, aggregation module 801 implementing Process 1 may generate a value r i Alternatively, when implementing process 2, the aggregation module 801 may be configured to generate a private witness value q i and s 1,iIn other words, the aggregation processing module 801 may calculate an aggregate signature component or a portion of a private witness used to implement a zero-knowledge proof algorithm. The proof system module 803 may be configured to generate the third aggregated signature component π (Process 1), as described above, by employing a zero-knowledge proof algorithm or by directly calculating the aggregated signature represented by π (Process 2). To achieve this, the system module 803 generates the third aggregated signature component π (Process 1), as described above, by employing a zero-knowledge proof algorithm or by directly calculating the aggregated signature represented by π (Process 2). 2, or the private witness ({s 1,i ,s 2,i, q i}i=0~T The aggregated signature components a1, a2, π may be stored in memory module 805 for later appending to a blockchain block, as illustrated in FIG. 5.

[0091] Note that a miner 15 with a set of messages, signatures, and public keys can execute the aggregate signature algorithm described in Process 1 or 2 and output a valid result. Thus, the miner 15 processes the set of messages, signatures, and public keys and outputs the components necessary to define a single aggregate signature A that mathematically describes the contents of the aggregated set. Aggregate signatures reduce the space overhead of storing N messages on the blockchain as long as the size of the aggregate signature is less than N times the length of the individual non-aggregate signatures. This is true in this case for a given number of messages N. Because both the compound formulas a1 and a2 and the proof π scale sublinearly (e.g., logarithmically) with N, there exists a threshold number of signatures above which no significant space savings are observed. In the specific case of Falcon signatures, this threshold number corresponds to approximately 150 signatures.

[0092] This advantage is compounded when applied to post-quantum cryptographic signatures, where the length of these signatures is always longer than that of non-quantum resistant signatures. Thus, the signature aggregation method disclosed herein provides a space-efficient way to store post-quantum signatures in any finite memory space. This is particularly true for storing transaction signatures in a blockchain environment. In such applications, a message is sent to a public key pk i Signed by the public key pk i Transaction T associated with xi (described in Section 3a). Once a transaction is submitted to the blockchain, it is broadcast to a network of blockchain miners, who are responsible for constructing the next block of transactions. Any blockchain miner with the set of transactions, signatures, and public keys can generate an aggregate signature and output a valid aggregate signature A, so that any blockchain miner server 15 in the network can propose the next block containing a space-efficient aggregate signature A.

[0093] Similarly, any authorized user 7, 9, 11, or 13 may verify the validity of a transaction on the blockchain by verifying the validity of the associated aggregated signature. This is described further below. In contrast to traditional blockchain signature verification schemes in which a signature associated with a particular transaction is verified, the aggregated signature method disclosed herein requires that an aggregated signature be verified for the associated transaction on the blockchain. Transaction verification is typically performed by a verifying entity that may be associated with any one of users 7, 9, 11, or 13 of FIG. 1. However, it should be understood that any entity with a genuine need to verify transactions on the blockchain may verify the aggregated signature. The verification process is not limited to users 7, 9, 11, or 13.

[0094] (Algorithm 1) The verification algorithm for checking the aggregated signature corresponding to process 1 is as follows: (1) a1 + a2 = Σr i *hash(T xi ) / / r i *(s i,1 +pk i *s i,2 )=r i *hash(T xi ) (2) ||a1|| is r i is small, s i is small, so it falls below a certain limit β / / . (3) ||s i,2 || is below a certain limit β for all i, a2=r i *pk i *s i,2 The correctness of the proof of a2 containing a is generated. β depends on the signature scheme chosen. For example, for the Falcon signature scheme, β can be determined according to equation 2.15 outlined in the document https: / / falcon-sign.info / falcon.pdf.

[0095] The verifier, which may be any one of users 7, 9, 11, and 13 in FIG. 1, receives the transaction data T xi , the associated public key p ki , and an aggregate signature A=(a1, a2, π), and the aggregate signature A is xi It should be understood that the verifier wishes to determine that the transaction data T xi , parameter r i The above algorithm can be used in combination with knowledge of the hash function associated with the adopted key signing protocol to calculate the sum of the first and second aggregate signature components a1 and a2. Regarding Process 2, the verification algorithm (Algorithm 2) focuses only on verifying the proof generated by the zero-knowledge proof system, as this proof fully represents the aggregated signature.

[0096] In practice, the size of the aggregate signature of 1,024 Falcon signatures is 117 KB, which is 16% of the original size of all 1,024 Falcon signatures. Furthermore, because the aggregate signature is generated using a zero-knowledge proof system, it is possible to further reduce the size of the aggregate signature with a better proof system. The verification function provides the necessary security behind the aggregation function. Because miners output a single aggregate signature that describes the contents of the aggregated set, a method for verifying the accuracy of the aggregate signature is required. As shown in Figure 7, a2 is generated by the proof system module 803, which is constructed using only the actual inputs of the aggregated set. To prove that the output aggregate signature reflects the correct input set, a proof of the correctness of a2 must be generated, which is only possible if the aggregate signature contains a correct a2. Taken together, Equation 1 and Algorithm 1 provide the necessary evidence for compressing digital information without sacrificing information. Algorithm 1 allows for the verification of the aggregated signature and confirms the ability of the aggregated signature to store compressed transaction information on the blockchain. In fact, Algorithm 1 used as a verifier can be used to ensure that the aggregate signature is correct and to verify that the set of transactions on the blockchain represents the true set of transactions submitted as input. Thus, by running Algorithm 1 as a verifier for the aggregate signature, the blockchain is able to verify the resulting aggregate signature before recording it on the chain where it will reside forever.

[0097] 5. Running on a physical device Implementing the signature aggregation method (Equation 1) and signature verification method (Algorithm 1) described herein in a computerized network such as that illustrated in Figure 1 requires slight modification of a typical blockchain network in two ways: 1. Issuance of a private-public key pair 2. Transaction Processing

[0098] 1. Issuance of a private-public key pair When a user, such as a user on user terminal 7, 9, 11, or 13 in Figure 1, creates a new account on computerized network 1, the user is issued a private-public key pair. According to some embodiments, particularly where quantum resistance is desired, instead of generating the key pair using an elliptic curve (as is done in typical blockchains, e.g., the Bitcoin blockchain), the key pair is generated from a post-quantum digital signature algorithm, e.g., based on a lattice, such as the Falcon signature protocol. This ensures that the key pair is quantum-resistant and less susceptible to attacks from quantum computers.

[0099] 2. Transaction Processing Using Zero-Knowledge Proofs (ZKPs) In a typical blockchain, when users submit transactions to the network, each transaction is processed independently. Each transaction includes its own header, data, and digital signature and is sequentially added to a block. According to embodiments of the present disclosure, instead of processing each transaction individually, digital signatures from multiple transactions are aggregated into a single signature. This aggregation may occur, for example, on the blockchain miner server 15. According to some embodiments, the blockchain miner server 15 may process transactions in exchange for some local currency provided as a reward. The blockchain miner server 15 is responsible for implementing the signature aggregation algorithm and submitting a new block containing the aggregate signature. A zero-knowledge proof algorithm is used to generate at least one of the components of the aggregated signature. The aggregate signature can then be verified using the verification algorithm described in Algorithm 1. Verification of the aggregate signature can be performed by any user on user terminals 7, 9, 11, or 13 of FIG. 1.

[0100] FIG. 6B illustrates how the blockchain miner server 15 of FIG. 1 interacts with user transactions to aggregate multiple transactions. The miner server 15 of FIG. 1 receives new transactions from the communication network 5 of FIG. 1 sent by users, such as users on user terminals 7, 9, 11, and 13 of FIG. 1, as detailed in step 1 of FIG. 6B. The miner server 15 then verifies the validity of the incoming transaction based on the digital signature and format of the incoming transaction in step 2. If the transaction's validity is verified, the transaction is sent back to the communication network 5 and stored in the transaction pool 3 of FIG. 1, as detailed in step 3 of FIG. 6B. The validity verification process may include several steps. For example, the miner 15 may check the transaction format to ensure that the transaction contains all necessary information (sender / recipient addresses, transaction amount, transaction header structure, etc.), verify that the sender has sufficient funds to perform the transaction since the funds balance must be greater than or equal to the transaction amount, and / or prevent double spending by ensuring that the same funds are not used in another transaction. Additionally, the authenticity and integrity of the signature associated with the transaction may be further verified. This subprocess may include obtaining the user (signer) public key pk, extracting the signature data s from the transaction Tx, performing a verification algorithm Verify(pk, Tx, σ) using the public key and the signature data, and verifying that the transaction was indeed signed by the owner of the private key sk associated with the public key pk used in the signature σ via the output b of the verification algorithm. The miner server 15 of FIG. 1 continues to add to the transaction pool 3 of FIG. 1 until the communication network 5 alerts the miner server 15 that there are enough transactions in the transaction pool 3 to propose a new blockchain block, as detailed in steps 4 and 5 of FIG. 6B.When the miner server 15 is ready to propose a new block, transactions from the transaction pool 3 are collected to form the new block, as detailed in step 6 of FIG. 6B. The miner server 15 then generates a cryptographic proof (e.g., a proof of work) to prove to the communication network 5 that a certain amount of computation was spent collecting the transactions to propose the new block, as detailed in step 7 of FIG. 6B. Upon completion of the proof of work in step 7, the miner server 15 proposes the new block to the network, as outlined in step 8. After the new block is proposed to the communication network 5, as detailed in step 9 of FIG. 6B, the miner server 15 is notified of the new block proposal. The miner server 15 then attempts to verify the block's validity, as detailed in step 10 of FIG. 6B. To be considered valid, the newly proposed block may include the correct aggregate signature of all transactions in the previous block and the correct hash of the previous block, ensuring that the transaction data is immutable. Once the block is verified as valid, the miner server 15 may calculate an aggregate signature, as detailed in step 11 of Figure 6B. Once calculated, the aggregate signature is added to the blockchain, as detailed in step 12.

[0101] While the foregoing embodiments are described within the context of a single miner 15, it is important to understand that the network 5 may include multiple miners. Additionally, certain steps of the method illustrated in FIG. 6B may be performed by different miners. For example, validating the block in step 10 may involve a consensus algorithm involving some or all miners in the network. Similarly, it is important to understand that the miner proposing the block may not necessarily be the same miner as the one responsible for generating the aggregated signature.

[0102] In embodiments where the aggregated signatures are incorporated into a block after validation, the block is mutable, i.e., the contents of the block can be modified after its creation. However, in other embodiments, the block can be immutable, i.e., once a block is created and added to the blockchain, its contents cannot be changed. In such embodiments, the signature aggregation step (step 11 in FIG. 6B) can be performed simultaneously with new block generation (step 6 in FIG. 6B). The digital signatures are aggregated, and the aggregated signature is incorporated into the block before it is added to the blockchain.

[0103] The above method may also include a step of verifying the aggregated signature after it has been generated, which involves verifying the aggregated signature by combining the set of transactions and their corresponding public keys (Tx i ,pk i ) i=1:N The process includes utilizing the aggregated signature verification algorithm (e.g., AggregateVerify) in conjunction with the blockchain network 5. This verification ensures the authenticity and integrity of the aggregated signature and its association with the transaction. This verification step can be performed by any node in the blockchain network 5. The decentralized nature of the blockchain network allows multiple nodes to independently verify the aggregated signature, promoting trust and consensus in the validity verification process.

[0104] In some embodiments, verifying an aggregated signature may essentially include verifying all individual signatures that make up the aggregate. Due to this “batch verification” feature, it may not be necessary to verify each individual signature separately in step 2 of FIG. 6B, since verifying individual signatures before the aggregation step may result in redundancy (the same signatures may be verified again during verification of the aggregated signature). By employing batch verification with an aggregated signature, the verification process may be more efficient and reduce computational overhead. The aggregated signature provides a compact representation of the individual signatures, and its verification encompasses verifying the validity of all included signatures in a single step.

[0105] While in the preceding embodiments of this disclosure, the proof system module 803 is disclosed as applying a zero-knowledge proof algorithm to determine the third aggregated signature component π or to determine the aggregated signature directly, it should be understood that in alternative embodiments, because the transaction data may be public, any cryptographically verifiable computing algorithm, such as a probabilistic proof algorithm, or either a zero-knowledge or non-zero-knowledge proof algorithm, may be used. In other words, if the transaction data is public, zero-knowledge is not required, and therefore other cryptographically verifiable computing algorithms may also be used.

[0106] In embodiments where signature aggregation may be performed off-chain, the input / output module 807 may be configured to transmit the transaction data Tx, the signature s, and the public key pk to an external aggregator (not shown) and collect the aggregated signatures generated by the external aggregator.

[0107] The above description has been presented for illustrative purposes. It is not exhaustive or limited to the precise form or embodiment disclosed. Modifications and adaptations of the embodiments will become apparent from consideration of the specification and practice of the disclosed embodiments. For example, the described functional modules of the minor may be implemented using hardware and / or software. Further, while certain components are described as being coupled to each other, such components may be integrated or distributed with each other in any suitable manner.

[0108] Furthermore, although exemplary embodiments are described herein, the scope includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations, and / or variations based on this disclosure. Elements in the claims should be construed broadly based on the language used in the claims and not limited to the examples set forth herein, which examples should be construed as non-exclusive.

[0109] Other embodiments will be apparent from consideration of the specification and practice of the embodiments disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the disclosed embodiments being indicated by the following claims.

Claims

1. 1. A method of aggregating multiple signatures into a block on a blockchain, each signature associated with a different transaction, comprising: receiving a plurality of different transactions, each transaction including transaction data and associated signature data; aggregating the signature data associated with the plurality of received transactions to generate an aggregated signature; generating a block of a blockchain including the transaction data; wherein the aggregated signatures are maintained separately from the transaction data in the generated blocks.

2. Each transaction has a public key pk ｉ and the private key sk ｉ the public and private key pair is selected using a digital signature scheme and is associated with signature data s associated with the transaction. ｉ is the private key sk associated with the transaction ｉ , and the transaction data T associated with the transaction is calculated using ｘｉ The method of claim 1 , wherein the encrypted data is generated by encrypting the encrypted data.

3. aggregating the signature data associated with the plurality of received transactions to generate the aggregated signature includes: ｉ and the signature data s ｉ and an aggregation algorithm in combination to generate the aggregated signature.

4. aggregating the signature data associated with the plurality of received transactions to generate the aggregated signature; an aggregator configured to generate the aggregated signatures using an aggregation algorithm, the public key pk associated with the plurality of transactions; ｉ , the signature data s ｉ and transmitting the transaction data; and receiving the generated aggregated signature.

5. The method according to any one of claims 2 to 4, wherein the digital signature scheme is a multi-use signature scheme.

6. The method of any one of claims 2 to 5, wherein the digital signature scheme is a post-quantum digital signature scheme.

7. The method of claim 6 , wherein the post-quantum digital signature scheme is a lattice-based cryptographic digital signature scheme.

8. The method of claim 7 , wherein the lattice-based cryptographic digital signature scheme is a hash-and-sign lattice-based cryptographic digital signature scheme.

9. The method of claim 8 , wherein the hash-and-signature-based cryptographic signature scheme is a Falcon signature scheme.

10. 10. The method of any one of the preceding claims, wherein the aggregated signature comprises a plurality of aggregated signature components.

11. 11. The method of claim 10, wherein the plurality of aggregated signature components comprises any one or more of: at least a portion of a complex expression; a complex expression; or one or more outputs of a cryptographically verifiable computing algorithm.

12. the cryptographically verifiable computing algorithm: a) Probabilistically checkable proofs, a) a zero-knowledge proof algorithm.

13. aggregating the signature data associated with the plurality of received transactions to generate the aggregated signature; The public key pk associated with the transaction ｉ , the transaction data T associated with the transaction ｘｉ , at least one complex expression for the received transactions based on any one or more of the at least one hash function; and using the at least one determined compound expression as input to a cryptographically verifiable computing algorithm to determine at least one component of the aggregated signature.

14. 14. The method of claim 13, wherein the cryptographically verifiable computing algorithm is a zero-knowledge proof algorithm and the at least one determined complex formula is used as a private witness.

15. aggregating the signature data associated with the plurality of received transactions to generate the aggregated signature; For each transaction, r ｉ = hash(pk ｉ , T ｘｉ ) to obtain the first parameter r ｉ determining pk ｉ is the public key associated with the transaction, and T ｘｉ is the transaction data associated with the transaction; For each transaction, the first product r ｉ *s ｉ，１ (In the formula, s ｉ，１ where x is a first component of the signature data associated with a transaction, and summing the first product across all transactions to calculate the first aggregate signature component. １ and determining For each transaction, the second product r ｉ *pk ｉ *s ｉ，２ (In the formula, s ｉ，２ is a second component of the signature data associated with a transaction), and summing the second product across all transactions to calculate the second aggregate signature component, ２ and determining the second aggregate signature component a ２ and using π as input to a cryptographically verifiable computing algorithm to determine a third component π of the aggregated signature A.

16. aggregating the signature data associated with the plurality of received transactions to generate the aggregated signature; For each transaction, s １，ｉ =Hash(T ｘｉ )-pk ｉ s ２，ｉ +q ｉ The first parameter q is ｉ determining pk ｉ is the public key associated with the transaction, and T ｘｉ is the transaction data associated with the transaction, and s ｉ，１ is a first component of the signature data associated with the transaction, and s ｉ，２ is a second component of the signature data associated with the transaction, and Hash(T ｘｉ ) is a hash value of the transaction data, Hash() is a hash function, and p is a prime number; The plurality of received transactions {s １，ｉ , s ２，ｉ , q ｉ }, and performing a zero-knowledge proof algorithm using the set of the first parameters, the first signature component, and the second signature component as a private witness to obtain the set of the public keys and the hash values of the transaction data for the plurality of received transactions {pk ｉ , Hash(T ｘｉ 10. The method of claim 8 or 9, comprising: outputting the aggregated signature using {\displaystyle \mathbb {R}\mathbb {R}} as a public instance.

17. 10. A method according to any one of the preceding claims, wherein the size of the aggregated signature is smaller than the sum of the sizes of each signature data associated with each transaction.

18. 10. The method of any one of the preceding claims, wherein the size of the aggregated signature is sublinear with respect to the total number of transactions.

19. 20. The method of claim 18, wherein the size of the aggregated signature scales logarithmically with the total number of transactions.

20. 20. The method of claim 18, wherein the total number of transactions is greater than a threshold number of transactions for which the size of the aggregated signature is less than the sum of the sizes of each signature data associated with each transaction.

21. 10. The method of any one of the preceding claims, wherein generating the block of the blockchain comprises updating a pre-generated block containing the plurality of received transactions by replacing signature data included in the pre-generated block with the aggregated signature.

22. 10. The method of any one of the preceding claims, comprising performing an aggregated signature verification algorithm using the aggregated signature, the plurality of transactions, and a plurality of public keys associated with the plurality of transactions.

23. 1. A method for verifying transactions in a block of a blockchain using an aggregated signature, wherein the aggregated signature is associated with a plurality of transactions in the block of the blockchain, and the aggregated signature is stored in the block of the blockchain separately from the plurality of transactions in the block, the method comprising: receiving the aggregated signature; and verifying the authenticity of the transaction by executing an aggregated signature verification algorithm to verify the authenticity of the aggregated signature.

24. A server comprising at least one processor configured to perform the method of any one of claims 1 to 23.

Images