Delayed Proof of Validity

Abstract

A method and system are disclosed for delaying the generation of validity proofs and the integration of the validity proofs into blocks of a blockchain operated by a network, each validity proof being associated with a plurality of different transactions. The method may include receiving a plurality of different transactions, each transaction including transaction data and associated validity data, generating a plurality of new blocks on the blockchain including the transaction data, generating in parallel, within a predetermined time, one or more validity proofs associated with one or more blocks from the plurality of new blocks based on the associated validity data, and incorporating the one or more validity proofs into the blockchain after the predetermined time.

Description

[Technical Field]

[0001] The present disclosure relates generally to blockchain technology, and more particularly to a system and method that uses a proof system to address limitations in current blockchain formats. [Background technology]

[0002] In blockchain networks, such as decentralized cryptocurrency networks, transactions must be verified for validity before they are recorded on the blockchain. To establish the authenticity of a transaction, some blockchains use validity proofs, i.e., summary data obtained by processing a typically large dataset associated with the transaction, to verify the transaction's validity. Validity proofs are typically used to enhance privacy and improve scalability. Because each block relies on some kind of validity proof, the time required to generate and add a block to a blockchain must be at least as long as the time required to generate that proof. However, as threats attempting to defeat security mechanisms currently applied to blockchain technology become increasingly sophisticated, validity proofs have become more complex, and the time required to generate those proofs has increased, depending on the security level of the underlying proofs. Proof generation requires an increasingly long time, slowing the generation of blockchain blocks and impacting the usefulness of blockchains in certain applications. Therefore, there is a need to find ways to mitigate the latency introduced into blockchains by proof systems that require longer time to generate proofs than the time required to generate new blocks.

[0003] At least some embodiments of the present disclosure provide a solution to the above-mentioned problems and can be implemented in any system that uses a proof system where validity proofs are published sequentially and proof generation becomes a bottleneck for the creation of new blocks in the blockchain. Summary of the Invention [Means for solving the problem]

[0004] According to one aspect of the present disclosure, there is provided a method for generating validity proofs associated with one or more transactions associated with one or more existing blocks of a blockchain. The method may include receiving a plurality of validity data. Each validity data may be associated with a different transaction associated with the one or more existing blocks of the blockchain. The method may further include generating one or more validity proofs associated with the plurality of validity data and incorporating the generated one or more validity proofs into a block of the blockchain.

[0005] At least some of the embodiments disclosed herein may reduce the latency introduced into block generation by attestation systems compared to prior art solutions that require each newly generated block to include a validity proof by separating the generation of validity proofs from block generation. As validity proofs become increasingly complex, the computation of validity proofs can itself introduce significant latency into the prior art block generation process. This problem may be exacerbated as increasingly sophisticated and complex block generation and validity proofs are implemented to defend against increasingly sophisticated cyber threats from malicious users with an ever-increasing amount of available processing resources.

[0006] According to some embodiments, the generated one or more validity proofs may be retroactively incorporated into one or more existing blocks of the blockchain, which may be associated with transactions with which the one or more validity proofs are associated.

[0007] In some of the embodiments disclosed herein, generating one or more validity proofs may include performing a cost-benefit analysis with respect to the validity proof generation process. If the result of the cost-benefit analysis is positive, one or more validity proofs may be generated. The cost-benefit analysis may be based on at least one of potential rewards to a miner, time efficiency, processing efficiency, storage efficiency, energy consumption, or a combination thereof. In some embodiments, the result of the cost-benefit analysis may be positive if the potential rewards to a miner for generating one or more validity proofs offset the energy costs of generating the one or more validity proofs. Additionally or alternatively, the result of the cost-benefit analysis may be positive if the space savings obtained by storing one or more generated validity proofs compared to the storage of associated validity data is equal to or greater than a threshold. In some embodiments, the result of the cost-benefit analysis may be positive if the space savings obtained by storing one or more generated validity proofs compared to the storage of associated validity data offset the energy costs of generating the one or more validity proofs.

[0008] According to some embodiments, the generated one or more validity proofs may be incorporated into a currently being generated block of the blockchain, allowing for verification of transaction data contained in one or more existing blocks included in the blockchain.

[0009] In some embodiments, one or more existing blocks may precede the currently generated block by a time period equal to or greater than the time required to generate one or more validity proofs. One or more existing blocks may precede the currently generated block by a predetermined number of blocks on the blockchain. The time it takes to generate the predetermined number of blocks may be proportional to a time period equal to or greater than the time required to generate one or more validity proofs. The time period may be parameterized by at least two parameters k and j, and the time period may be equal to k±j. Furthermore, the value of parameter k may depend on the computational power associated with at least one miner linked to the blockchain, and parameter j may be associated with the stability of the blockchain network.

[0010] In some embodiments, the plurality of validity data may be received from a database accessible to one or more miners included in the blockchain network. In some embodiments, the plurality of validity data may be received from a database distributed among multiple nodes included in the blockchain network. In some embodiments, the plurality of validity data may be received from a peer-to-peer distributed database. In some embodiments, the database may include only validity data.

[0011] In at least some embodiments, the received plurality of validity data comprises a plurality of signature data s i Each signature data may be associated with a different transaction associated with one or more existing blocks of the blockchain. Each transaction may include 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 TX associated with that transaction.i The .times. ...

[0012] According to some embodiments, the digital signature scheme may be one or more of a multi-use signature scheme, a quantum-resistant digital signature scheme, or a lattice cryptography digital signature scheme. The lattice cryptography digital signature scheme may be a hash-and-sign lattice cryptography digital signature scheme such as the Falcon signature scheme.

[0013] Generating the one or more validity proofs may include aggregating the plurality of signature data using an aggregation algorithm to generate one or more aggregate signatures.

[0014] In some embodiments disclosed herein, the size of each of the one or more aggregate signatures may be smaller than the total size of the individual signature data being aggregated. The size of the one or more aggregate signatures may be sublinear with respect to the total number of signature data being aggregated. Additionally or alternatively, the size may scale logarithmically with respect to the total number of signature data being aggregated.

[0015] According to some embodiments, the method may further include receiving a plurality of different transactions, each transaction including the transaction data, and generating, in parallel, a plurality of new blocks on the blockchain including the transaction data.

[0016] According to another aspect of the present invention, a server including at least one processor configured to receive a plurality of validity data, each of which may be associated with a different transaction associated with one or more existing blocks of the blockchain, is provided. The at least one processor may be further configured to generate one or more validity proofs associated with the plurality of validity data and incorporate the generated one or more validity proofs into a block of the blockchain.

[0017] According to some embodiments, at least one processor of the server may be configured to perform the above-described method.

[0018] The foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the scope of the claims.

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

[0020] [Figure 1] FIG. 1 is a schematic diagram of a networked computer system implementing a conventional blockchain network. [Figure 2] FIG. 2 is a schematic diagram of a blockchain generated by the system of FIG. 1 , showing the general structure and properties of a blockchain block. [Figure 3] FIG. 1 is a schematic diagram of a networked computer system according to an embodiment of the present invention configured to implement the methods disclosed herein. [Figure 4] FIG. 4 is a schematic diagram of an exemplary modified blockchain generated by the system of FIG. 3 in accordance with an embodiment of the present disclosure. [Figure 5A] FIG. 1 is a schematic comparison diagram illustrating how a time-delayed validity proof for a single block of a blockchain is stored using immutable blocks in accordance with the methods disclosed herein, compared to how validity proofs are stored in known blockchains. [Figure 5B] FIG. 1 is a schematic comparison diagram illustrating how time-delayed validity proofs associated with at least two blocks of a blockchain are stored using immutable blocks in accordance with the methods disclosed herein, compared to how validity proofs are stored in known blockchains. [Figure 5C]5C is a process flowchart illustrating a method for generating a validity proof for the immutable blocks of FIGS. 5A and 5B in accordance with one or more embodiments. [Figure 6] FIG. 1 is a schematic diagram of an alternative networked computer system including a single database for storing validity data and transaction data, configured to implement the methods disclosed herein, in accordance with one or more embodiments of the present disclosure. [Figure 7A] FIG. 10 is a schematic diagram of another modified blockchain prior to generation of a validity proof, in accordance with one or more embodiments of the present disclosure. [Figure 7B] FIG. 7B is a schematic diagram of the modified blockchain of FIG. 7A after a time-delayed validity proof has been generated in accordance with the methods disclosed herein. [Figure 8A] FIG. 10 is a schematic comparison diagram illustrating how time-delayed validity proofs associated with at least two blocks of a blockchain using variable blocks can be retroactively stored in a previously generated block of a blockchain in accordance with the methods disclosed herein, compared to how validity proofs are stored in known blockchains. [Figure 8B] 8B is a process flow diagram illustrating validity proof generation for the variable block of FIG. 8A according to embodiments disclosed herein. [Figure 9] 1 is a process flow diagram illustrating an exemplary cost-benefit analysis used to determine whether to generate a validity certificate, according to embodiments disclosed herein. [Figure 10A] 1 is a process flow diagram illustrating a method for incorporating validity proofs into a blockchain, according to an embodiment of the present disclosure. [Figure 10B] 1 is a process flowchart illustrating a method for incorporating validity proofs into a blockchain in parallel with the generation of new blocks, according to an embodiment 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 relate to methods for time-delaying the generation of validity proofs associated with blocks of a blockchain and the integration of those validity proofs into blocks of a blockchain without interrupting or otherwise delaying the creation of new blocks in the blockchain. The methods disclosed herein may be implemented in a blockchain network.

[0023] The following disclosure begins with an overview of conventional blockchain systems to provide the reader with the necessary background information to better understand the present disclosure. This overview is intended to help the reader understand existing blockchain structures and processes. Subsequent sections disclose specific implementation details of the present method for delaying the generation of validity proofs and integrating the validity proofs into blocks of a blockchain. Details are also provided on how the methods disclosed herein for delaying validity proofs may be implemented by a blockchain miner server.

[0024] The remaining explanation is outlined below. 1. Overview of conventional blockchain systems 2. Traditional Blockchain Structure 3. Traditional Blockchain Block Structure a) The general structure and properties of transaction data contained in traditional (e.g., Bitcoin) blockchains 4. Blockchain and Proof Systems a) The latency introduced by generating a validity proof b) Digital Signature 5. Solutions Provided by the Present Disclosure a) Immutable Blocks 1. Operating Principle 2. Working Example b) Variable Block 1. Operating Principle 2. Working Example 6. Exemplary Process for Proof of Validity Generation: Signature Aggregation 7. Implementation on physical devices 8.Other

[0025] 1. Overview of conventional blockchain systems 1 is a schematic diagram of a networked computer system 101 configured to implement a conventional blockchain. For example, such a blockchain may function as a digital ledger of electronic transactions, although it should be understood that in principle any type of data may be stored on a blockchain.

[0026] Electronic transaction data generated by different users are collected together in a transaction pool repository 103 via a shared communication network 105. For example, first transaction data TX1 associated with a first user at a first user terminal 107, second transaction data TX2 associated with a second user at a second user terminal 109, third transaction data TX3 associated with a third user at a third user terminal 111, and fourth transaction data TX4 associated with a fourth user at a fourth user terminal 113 are transmitted to the transaction pool 103 via the shared communication network 105. The transaction data received by the transaction pool 103 are stored and then processed by at least one blockchain miner server 115.

[0027] When a predetermined threshold condition is met, at least one blockchain miner server 115 retrieves multiple transaction data (TX1...TX4) stored in the transaction pool 103. For example, the predetermined threshold condition may relate to a predetermined number of electronic transactions stored in the transaction pool 103. The retrieved transaction data is processed in bulk by the at least one blockchain miner server 115. Alternatively, when the threshold condition is met, the multiple transaction data is provided to the at least one blockchain miner server 115. The retrieved or received transaction data is processed to generate new blocks that are added to an existing blockchain and / or to generate blocks for a new blockchain, as the case may be. The at least one blockchain miner server 115 processes the transaction data to generate validity proofs associated with different electronic transactions. The blockchain itself may further include the transaction data, such that the resulting blockchain includes both the electronic transaction data and the associated validity proofs. This allows the electronic transaction data included in the blockchain to be verified using the validity proofs.

[0028] Although the system of Figure 1 shows a single blockchain miner server 115, it should be understood that a blockchain network typically includes multiple different blockchain miner servers, with the different blockchain miner servers competing to generate the next block in the blockchain and the associated validity proof.

[0029] 2. Traditional Blockchain Structure By way of background, a blockchain is a distributed ledger that represents all transactions that take place within a network. Transaction data is permanently 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 added 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. Traditional Blockchain Block Structure 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 200 Block header 202 Transaction Data 204

[0031] The block metadata 200 may include general properties of the current block, which may include, but are not limited to: Magic number (file signature) 206 - indicates the type of data contained in the file. All blocks belonging to the same blockchain are the same. · Size of current block 208 - number of bytes to the end of the block. · Number of transactions in the current block: 210.

[0032] The block header describes certain properties of the current block, such as its time and location, which may include, but are not limited to: Block Version 212 - Specifies the current version of the blockchain software. Previous block header hash 214 - a reference to the previous block. Hashes of all transactions in the block216 - The Merkle root hash of all transactions in the block. Timestamp 218 - The timestamp of the current block in Unix time (number of seconds since 00:00 UTC, January 1, 1970). Bit difficulty 220 - Current mining difficulty target. Nonce222 - Number of attempts (starting from 0) to solve the Proof-of-Work.

[0033] a) The general structure and properties of transaction data contained in traditional (e.g., Bitcoin) blockchains. A transaction represents the movement of some resource between two or more accounts on the blockchain. In some embodiments, the resource may relate to a financial resource, such as a fund transfer. A transaction references previous transaction outputs as new transaction inputs and assigns all base currency values ​​to the new output. This is formally realized as a state transition function, with each state representing the ownership state of all digital currencies in circulation. Note that while a blockchain can contain any type of transaction data, for non-limiting purposes of describing the present invention, it is assumed that the blockchain is being used as a ledger of financial transactions. A schematic diagram illustrating how transaction data 204 is stored in blocks of a typical blockchain is shown in Figure 2. Transaction data 204 is stored in three groups: Header 224 - Contains instructions for sending base currency. 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 226 - recipient's public key. Digital Signature 228 - An ECDSA signature over a hash of a simplified version of the transaction. This 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 an ECDSA digital signature.

[0035] 4. Blockchain and Proof Systems a) The latency introduced by generating a validity proof Proof generation is accomplished in terms of proof systems that allow users to "prove" things about the world without disclosing complete information about what is being proven. This has desirable properties for data privacy systems, where users may want to hide sensitive information from unintended parties. Such techniques are also useful for reducing space requirements in space-constrained digital systems by providing validity proofs of some information rather than providing raw bit string length information. In these proof systems, proof generation is often a computationally expensive operation that can cause significant latency in downstream operations. Technologies such as distributed ledger technology (DLT), or blockchain, are particularly susceptible to these latencies. Below, we describe how latency issues arise in blockchain systems when the time it takes to generate a validity proof for some validity data in a block exceeds the time it takes the blockchain network to generate a new block. Suppose a proof system generates proofs for some information in a block to reduce the number of bytes required to store that information on-chain. This requires that the next block cannot be generated until all information in the current block is finalized (i.e., validity proofs have been generated), because the next block references the current block via a hash of all data in the current block. This is true for all subsequent blocks, and the time required to create a new block depends on the time required to generate a validity proof for the data contained in the block. A digital signature is an example of validity data that miners check to create a validity proof.

[0036] b) Digital Signature A digital signature is the result of asymmetric cryptography, a type of encryption technique in which the key used to encrypt data (the private key) is distinct from the key used to decrypt it (the public key). Asymmetric cryptography is also known as a digital signature scheme.

[0037] In public / private key or digital signature schemes, 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 signing with the sender's private key: First, the sender signs the message using their private key. This process involves creating a digital signature for the message. A digital signature is a unique cryptographic representation of the message that is 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. The public key is intended to be freely distributed so that anyone can use it to encrypt a message 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 their private key to decrypt the message and recover the original content, including the digital signature. The receiver can then verify the digital signature using the sender's widely available public key. If the digital signature is valid, the receiver confirms the authenticity and integrity of the message, since only the sender's private key could have generated the signature.

[0038] 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.

[0039] A digital signature scheme may be defined by a set of algorithms (KeyGen, Sign, Verify) that work as follows: KeyGen(λ) → (sk, pk): The KeyGen algorithm takes as input λ as a security parameter indicating the desired security level and generates a new random key pair (sk, pk) ∈ Ks × Kp, where sk is the private key or private signing key, pk is the corresponding public verification key, Ks is the private key set, and Kp 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 the 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.

[0040] λ represents the security level of a digital signature scheme. It is a measure of how resistant the scheme is to various attacks, including brute-force attacks and sophisticated mathematical attacks. It quantifies the amount of computation required for an adversary to forge or crack a digital signature, essentially determining the strength of the cryptographic scheme. The security level is typically measured in bits and indicates the number of bits required to represent the security parameters of the cryptographic scheme. For example, if a digital signature scheme has a security level of 128 bits, this means that an attacker would need to perform approximately 2128 operations using the best-known cryptanalysis algorithm to crack the scheme, e.g., by using a brute-force attack. The security level is 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 s. As used herein, size refers to the number of bits or bytes required to store the signature / key representation, regardless of the signature size or key size. The larger the signature / key size, the more data is required to represent the cryptographic signature / key. The representation of a signature or key can take various formats, such as a bit string or a hex string. These formats are common ways to represent the binary data that makes up a signature / key in a human-readable or machine-readable form. The choice between a bit string and a hex string may depend on factors such as desired readability, data size, ease of handling, and compatibility with existing systems or protocols.

[0041] In a particular cryptographic scheme, a signature may be represented by multiple components s = (s1, ..., sM), 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 using the signer's private key, and represent a core cryptographic proof of authenticity and integrity. Meanwhile, other components may serve to increase 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 additional components, the scheme may achieve specific security properties, such as increased resistance or protection against specific types of attacks.

[0042] 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. As the name suggests, one-time-use signatures are intended for a single transaction or message. In these schemes, each key pair is limited to a single use, significantly limiting their practical application. The reason behind this limitation is that generating multiple signatures using the same key pair compromises the security of the key pair, potentially exposing the key pair or portions of the key pair to other users. As a result, one-time-use signatures are not commonly 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. Multi-use signature schemes allow a single public key to be used for multiple transactions or messages, making them more efficient and suitable for large-scale deployment in various cryptographic protocols and systems.

[0043] 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.

[0044] A zero-knowledge proof (ZKP) algorithm is a cryptographic protocol that allows one party (the prover) to prove the validity 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 validity. One property of a zero-knowledge proof is that it may 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 private witnesses and public instances, which may be used individually or in combination in a statement. A private witness is secret information possessed by the prover, whose knowledge the prover wishes to prove without revealing to the verifier. A public instance, on the other hand, is information that is publicly available. During the proof generation process, the prover constructs a proof using the private witness and the public instance, which is then provided to the verifier. The verifier can then use the proof together with the public instance to verify the correctness of the proof, without knowing anything about the private witness.

[0045] 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 (a private witness). Zero-knowledge proofs are inherently probabilistic rather than deterministic. This probabilistic nature arises from the need for multiple rounds of interaction between the prover and verifier to gradually build higher levels of assurance that the prover possesses without revealing secret knowledge. In these interactions, the verifier challenges 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.

[0046] As a result of these repeated interactions, ZKPs are often interactive protocols. During the interaction, the verifier presents 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 also be converted into a non-interactive protocol through 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 inspect to confirm that the prover performed correctly to generate its randomness). This ensures that the challenge is 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 a signer (prover) has a function f and an image pk = f(sk) as a public key, the signer (prover) holds sk as a private key. To sign a message μ, a prover provides a non-interactive zero-knowledge proof that they know sk (a private witness) such that pk = f(sk) and uses the message μ to create a proof challenge H(μ), where H is a public hash function or random oracle that maps μ to something that "looks random." If the function f is one-way, the verifier can be confident that the proof could only be 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).

[0047] Zero-knowledge proofs (ZKPs) may encode statements to be proven using various mathematical techniques or intermediate representations, depending on the context and requirements of the ZKP 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 a zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) proof, the statement is decomposed into simple units of arithmetic operations such as addition, subtraction, multiplication, and division. These operations are then presented in the form of an arithmetic circuit, in which inputs and arithmetic operations are represented as wires and gates in a directed acyclic graph (DAG). This graph processes inputs and performs arithmetic operations on the inputs to determine the value of a polynomial.

[0048] Within the zk-SNARK protocol, several intermediate representations play an important role. R1CS (Rank-1 Constraint System): R1CS is a set of constraints that allows verification of each step of an arithmetic circuit and ensures that the output of the computation is as expected. QAP (Quadratic Arithmetic Program): The prover utilizes 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, we use QAP in the zk-SNARK protocol to prove assertions through an interaction between the prover and the verifier, providing a concise, non-interactive proof of knowledge for the validity of a statement.

[0049] The result of a ZKP algorithm can be a proof string or proof object, providing the verifier with evidence that the prover possesses knowledge of a valid solution to a concrete problem or statement. Proofs are designed so that the verifier can efficiently verify the validity of a proof without gaining any knowledge of the prover's secret. If the proof is valid, the verifier can be confident that the prover actually possesses the necessary knowledge without knowing any details about it. In the context of a digital signature scheme, a ZKP proof may be integrated as one of the components of signature s, contributing to the overall size of the signature, or it may represent signature s itself.

[0050] 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 methods, as quantum computers can efficiently solve these problems, rendering current cryptographic algorithms vulnerable.

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

[0052] In response to growing concerns about quantum computers, the National Institute of Standards and Technology (NIST) began the process of developing standards for quantum-resistant cryptography, including encryption and digital signature schemes, in 2016. NIST's efforts to establish quantum-resistant digital signature guidelines aim to ensure that secure communications and digital authentication infrastructures remain robust and usable even in the presence of a powerful quantum adversary. In July 2022, NIST announced plans to standardize three quantum-resistant digital signature schemes: Falcon, Dilithium, and SPHINCS+. However, it should be noted that these quantum-resistant signature algorithms have larger public key and signature sizes, typically 30 to 100 times larger, compared to pre-quantum signature algorithms such as ECDSA. As an example, for NIST Security Level 1 (λ ≈ 128 bits), the sizes of the cryptographic components in different signature schemes can be compared as follows: In the Falcon scheme, the public key is 897 bytes, the private key is 1281 bytes, and the signature is 690 bytes. Similarly, in the Dilithium scheme, the public key is 1184 bytes, the private key is 2800 bytes, and the signature is 2044 bytes. In contrast, traditional ECDSA schemes have smaller sizes, with a public key of 64 bytes, a private key of 96 bytes, and a signature of 64 bytes. It is important to note that in the field of post-quantum cryptography (PQC) schemes, both one-time-use signatures, such as one-time hash-based signatures, and multi-use signatures, such as Falcon signatures, coexist.

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

[0054] Efficient lattice signature schemes, both software and hardware implementations, often establish their security through proofs in the random oracle model. These schemes can be broadly categorized into two families: the hash-and-sign family (e.g., Falcon) and signatures based on identity schemes using the Fiat-Shamir heuristic (e.g., Dilithium) or related variations.

[0055] Digital signature schemes following the hash-and-sign paradigm adhere to certain criteria: a message μ is hashed before being signed. This involves hashing μ to a specific point h = H(μ), where h is within the domain of a specified trapdoor function f. After the message is hashed, it is then subject to signing, creating s = f-1(h). Verifying the validity of a message / signature pair (σ, μ) relies on a verification algorithm that checks 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 a lattice may be able to 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 their conversion to signature schemes.

[0056] In almost all lattice signature verification processes, a central computation involves computing a lattice vector using matrix-vector multiplication to verify the validity of the lattice 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.

[0057] 5. Solutions Provided by the Present Disclosure The general principle is to allow one or more blockchain blocks to be generated during the time period required to generate a validity proof for a previously generated block. In other words, the method described herein allows for the generation of a validity proof for a particular block in parallel with the generation of a new block on the blockchain. This can be achieved by decoupling the generation of validity proofs from block generation on the blockchain. The method disclosed herein provides at least the same security guarantees as existing blockchain methods, allowing the use of a proof system at the base layer of the blockchain without sacrificing security or scalability. At least two embodiments of how validity proofs can be decoupled from block generation are envisioned and are described below.

[0058] a) Immutable Blocks 1. Operating Principle The general principle of this embodiment is to incorporate one or more generated validity proofs into a currently generated block. The one or more validity proofs may be related to validity data contained in one or more previously generated blocks, i.e., data enabling verification of transaction data contained in one or more previously generated blocks. The previously generated blocks may precede the currently generated block by a period equal to or longer than the time required to generate the one or more validity proofs. Thus, validity data stored in a block may be replaced by validity proof stored in a later block. More specifically, according to some embodiments, data related to the validity proof of block i (validity data) is not stored in block i; instead, the validity proof of block i is stored in blocks i+k±j, where k is a parameter representing the latency of generating the validity proof of block i measured with respect to the number of blocks generated since block i was generated, and j is a variable that dynamically changes the window size determined by k. Adjustment of parameter k may depend on the computing power of various miners in the network, while parameter j depends on the stability of the blockchain network (e.g., the stability of the Internet connection) and may be adjusted accordingly. During time k±j while the validity proof is being generated, the original transaction data is accessible by miners in a shared database, allowing the generation of intermediate blocks and thus maintaining the functionality of the blockchain. The data for which the validity proof is being generated is temporarily moved (during time k±j) off-chain to a publicly available database accessible to miners while the validity proof is being generated. Once the validity proof is generated, it is stored in the most recently generated block on the blockchain. Note that the indies i, k, and j may also be related to the passage of time. Whether the time latency required to generate the validity proof is quantified in terms of the number of blocks generated or the actual elapsed time is not important for the purposes of this invention.

[0059] Figure 3 is a schematic diagram of a networked computer system 301 in which embodiments of the present disclosure may be implemented. Figure 3 illustrates a networked computer system 301 that may integrate validity data associated with electronic transactions together into a blockchain. The illustrated computer system 301 may include a blockchain network in which a ledger of electronic transactions is maintained on the blockchain.

[0060] Electronic transaction data generated by different users is collected in a transaction pool repository 303 via a shared communication network 305. A difference with conventional blockchain networks is shown here: instead of transmitting all global transaction data (e.g., header, data, signature, or any other associated data) as shown in Figures 1 and 2, users specifically transmit validity data associated with the transaction separately from the transaction data. For example, first transaction data TX1 is associated with first data VD1 and a first user at first user terminal 307; second transaction data TX2 is associated with second validity data VD2 and a second user at second user terminal 309; third transaction data TX3 is associated with third validity data VD3 and a third user at third user terminal 311; and fourth transaction data TX4 is associated with fourth validity data VD4 and a fourth user at fourth user terminal 313. Transaction data is transmitted over a shared communications network 305 to a transaction pool 303, while validity data is transmitted to a validity data pool 319. Although shown as separate repositories, the validity data pool 319 and the transaction pool 303 may be associated with a shared repository. In some embodiments, the transaction pool 303 and the validity data pool 319 may be associated with a database. In some embodiments, the database may be associated with a distributed database, such as a peer-to-peer database distributed across a network.

[0061] Transaction data received by the transaction pool 303 may be stored and then processed by at least one blockchain miner server 315, 317. Validity data received by the validity data pool 319 may be stored and then processed by at least one blockchain miner server 315, 317. In some embodiments, the same miner server may process both validity data and transaction data. Alternatively, a different blockchain miner server may process validity data than the blockchain miner server that processes transaction data. For example, blockchain miner server A 315 may process transaction data, and blockchain miner server B 317 may process validity data. For present purposes, it is immaterial whether transaction data and validity data are processed by the same or separate miner servers. Roles in this context are interchangeable. A miner server may choose to only generate new blocks and wait for other miners to provide (delayed) validity proofs, or vice versa. Furthermore, a miner server may play both roles simultaneously. Different configurations and role assignments may be consistent with specific incentive mechanisms and reward schemes. 3 shows two blockchain miner servers 315 and 317, it should also be understood that the number of blockchain miner servers included in the system is not important, as long as there is at least one blockchain miner server. In a system that includes more than one blockchain miner server 315 and 317, different blockchain miner servers may compete to generate the next block in the blockchain and the validity proof.

[0062] Because transaction data and validity data are separated, the required blockchain structure is non-standard. Figure 4 is a schematic diagram of a modified blockchain structure that may be used in accordance with the disclosed methods. The primary difference with respect to traditional blockchain structures, such as the blockchain of Figure 2, is that the validity data 402, 404, 406 associated with transactions is separated from the transaction data and stored off-chain on a database, which may be associated with the validity data pool 315 as described above or a distributed database. The database may be accessible to all miners. The block header 408 may be slightly modified as a result of the separation of validity data and transaction data, in the sense that the Merkle root hash 410 is the result of hashing all transaction data contained in the block, excluding the validity data. As usual, a hash of every block header is generated and referenced by the next block.

[0063] 5A is a schematic comparison diagram illustrating the general structure of blocks in a blockchain in which validity proofs are separated from block generation, in accordance with embodiments disclosed herein, compared to a standard blockchain structure in which each block includes its associated validity proof. Using the blockchain structure of embodiments disclosed herein, validity proofs may be generated according to the following steps: 1. Blocks 501, 503, 505 are generated by the blockchain network and may contain complete block information excluding information for which a validity proof is generated (a validity proof was not previously provided at the time of block generation). Information related to the validity proof may be stored in a public database, such as the validity data pool 319. 2. The miner generates a validity proof 507 using information in the public database, i.e., the information in the validity data pool 319 of block 501. In some embodiments, multiple miners may compete with each other to generate validity proofs. 3. Once a validity proof is generated, it is included in block i+k±j 509. Once a validity proof is added to block i+k±j 509, the information associated with the validity proof contained in the validity data pool 319 is removed from the database. 4. Any miner included in the network may verify validity proofs to prove the authenticity and integrity of all data on the network. In particular, miners may have a stronger incentive to verify these proofs; if a miner discovers that a fraudulent entity has created an invalid proof, the miner can simply replace the invalid proof with a valid proof and claim the reward, since invalid proofs should not be accepted by any participants in the network. Note that verifying validity proofs, like verifying the correctness of mined blocks, is a process that may take constant time O(1), i.e., it does not depend on the number of transactions or validity data. Therefore, verifying validity proofs at block generation time may not introduce any additional latency. While FIG. 5A illustrates an exemplary embodiment in which validity proofs are generated for a single block, it should be understood that this process can be applied to any number of blocks. For example, FIG. 5B illustrates an exemplary embodiment in which validity proofs are generated for two blocks 501 and 503 and included in a subsequent block 509.

[0064] Blocks i+k±j may be selected depending on the time required to generate the validity proof. For example, the time required to generate the validity proof may be known based on available processing power, and the time required to generate a block of the blockchain is also known, so the time required to generate the validity proof can be expressed in terms of the number of blocks. In this way, a fixed rule can be established that a validity proof for block i will be generated and included in blocks i+k±j.

[0065] According to this embodiment, the miner will eventually generate a validity proof, since the data for which the validity proof is generated must be stored off-chain and eventually published on-chain, which can be achieved by making this a necessary step in proposing block i+k±j.

[0066] FIG. 5C is a flowchart illustrating an exemplary validity proof generation process 550 for use in embodiments involving immutable blocks, i.e., blocks whose contents cannot be subsequently changed once generated. Process 550 may be implemented by at least one miner server, such as miner servers 315, 317 shown in FIG. 3. In step 552, the at least one miner server receives a plurality of validity data. Each validity data may be associated with a different transaction associated with one or more existing blocks of the blockchain, i.e., previously generated blocks. The plurality of validity data may also be received from an accessible database (e.g., validity data pool 319). For example, referring to FIG. 5B, a miner server, such as server 317 of FIG. 3, may receive a plurality of validity data associated with transactions included in existing and previously generated blocks 501 and 503.

[0067] Next, the at least one minor server generates one or more validity proofs associated with the plurality of validity data in step 554. For example, with reference to FIG. 5B, the at least one minor server (e.g., miner 317) can generate validity proof 507 associated with existing blocks 501 and 503.

[0068] Finally, in step 556, at least one miner server incorporates the generated one or more validity proofs into a block of the blockchain that is currently being generated. As shown in FIG. 5B, at least one miner server (e.g., miner 317) may incorporate the generated one or more validity proofs 507 into a currently being generated block 509. The one or more generated validity proofs (e.g., validity proof 507 of block {i, i+1}) may be used to validate transaction data (e.g., TXs) included in one or more existing blocks (e.g., 501, 503) included in the blockchain. i , TXs i+1 ) may be possible to verify.

[0069] During the time required to generate validity proofs associated with one or more existing blocks, validity data associated with transactions in those blocks may be temporarily stored in a designated database, such as validity data pool database 319 of FIG. 3. Once validity proofs for the validity data of the target block are generated and the validity data is stored on-chain, the validity data stored in the designated database can be removed from the designated database as it is no longer needed. In this sense, the designated database, such as data pool database 319, serves as temporary storage of validity data for use in the validity proof generation process. Validity data pool database 319 may be thought of as a temporary holding repository for data for which validity proofs are actively being generated (e.g., for times k±j).

[0070] According to this embodiment, each block may contain the standard information present in a traditional blockchain block (shown in FIG. 4), with one exception: validity data associated with the block's transactions. Specifically, the space traditionally used to store validity data may be replaced with validity proofs of k±j blocks in the past. In other words, the current block may not contain its own validity proof, but instead incorporates the validity proof of the previous block. Because the validity proof associated with a particular block is generated after the block is generated, some blocks, particularly blocks generated by the system before the system has had time to generate validity proofs for the blockchain's blocks, may not contain any validity proof. For example, referring to FIG. 5B, at the time block 505(i+2) is generated, the validity proofs of blocks 501(i) and 503(i+1) are not yet available. This is why block 505 does not store its own transaction data (TXs). i+2 ) is the reason why it contains only

[0071] Also note that the genesis block, denoted as the initial block for i=1, along with potentially one or more subsequent blocks (e.g., i=2, 3, 4...), depending on the values ​​of k±j, may consist only of transaction data without any validity proof linked to the previous block, since no such block exists.

[0072] 2. Working Example A non-limiting example of the proposed solution is described for the scenario of generating a validity proof for a set of digital signatures associated with multiple transactions. According to this embodiment, the digital signatures of all transactions in an associated block are moved off-chain to a database available to miners, who may access the database to generate the validity proof. In some embodiments, the database may be a publicly available database. Once the validity proof is generated, it is incorporated into the latest block on the blockchain. The following notation is used to denote the set of transaction data {TX1, TX2, ..., TX Ni} i is used to denote the set of digital signatures {s1,s2,…,s Ni} i where N i represents the number of transactions contained in the i-th block.

[0073] Assuming the current block is i, the procedure is as follows: 1. The miner submits the proof of validity of the i-th block, i.e., {s1, s2, …, s Ni} i We will work to generate a proof of validity for On the other hand, for the next k±j blocks, 2. Users 307, 309, 311, and 313 submit transactions to the blockchain network for blocks of height i+k±j. 3. Miners collect transactions, organize them into blocks, and propose them at height i + k ± j. The number of transactions held is {TX1, TX2, …, TX Ni+k±j} i+k±j is. 4. For the block proposed at height i+k±j, the miner creates transactions {TX1, TX2, …, TX Ni+k±j} i+k±j , and optionally the validity of the digital signatures {s1, s2, ..., s Ni+k±j} i+k±j Check the validity of. 5. Miners execute all instructions necessary to generate a new block proposed at height i + k ± j. 6. The miner proposes a new block i+k±j to the network, containing the proof of validity of the i-th block. 7. Other miners can verify the validity proof of block i and form consensus on a block of height i + k ± j. If a miner discovers an invalid proof, the miner replaces the invalid proof with a valid proof and claims the reward.

[0074] The structure of a blockchain block is modified so that signatures are completely eliminated from the block, and only the signature validity proof for the block is included in the block k±j blocks after it. Each block contains the typical information stored in a blockchain block, except that the digital signatures associated with the transactions in that block are either replaced with the validity proof of the block k±j blocks before, or the space is left empty. As usual, a hash of all the information in that block (the block hash) is generated and referenced by the next block. During the time required to generate the validity proof for block i, the transactions {TX1, TX2, ..., TX Ni} i The digital signatures {s1, s2, …, s Ni} i is stored in the validity data pool database 319. The digital signature of the ith block {s1, s2, ..., s Ni} i Once a validity proof for is generated, that proof is included in a block of height i+k±j. Because the digital signatures for block i are now on-chain, they are removed from the database 319 that temporarily stores digital signatures while their validity proofs are being generated. The validity data pool database 319 can thus be thought of as a sliding window that holds data for which validity proofs are to be generated (typically for time k±j).

[0075] b) Variable Block 1. Operating Principle According to another embodiment, data stored in a blockchain block may be replaced with a validity proof within the same block (as opposed to being stored in a later block as in the previous embodiment). The data required to generate a validity proof stored in block i may be replaced with the validity proof generated in block i+k±j, where k is a parameter representing the latency of generating the validity proof, measured in number of blocks, and j is a variable for dynamically changing k. In this embodiment, the need to modify a previous block without changing the block hash necessitates a modification to the way the block hash is calculated. Instead of calculating the block hash as a hash of all data available in the block, the data for which a validity proof is to be generated is excluded from the block hash. This allows the flexibility to replace that data with a validity proof for that data once a validity proof is generated, while still preserving the ability to add new blocks in the meantime.

[0076] 6 is a schematic diagram of a networked computer system 601 in which embodiments of the present disclosure may be implemented. Figure 6 illustrates a networked computer system 601 that may integrate validity data associated with electronic transactions together on a blockchain. The illustrated computer system may include a blockchain network in which a ledger of electronic transactions is maintained on the blockchain, thereby eliminating the need to maintain a separate validity data pool 319 as shown in Figure 3.

[0077] Electronic transaction data generated by different users 607, 609, 611, 613 are collected together in a transaction pool repository 603 via a shared communications network 605. In contrast to the previous embodiment, instead of transmitting all global transaction data (e.g., header, data, signature, or any other associated data) as shown in Figures 1 and 2, users 607, 609, 611, 613 specifically transmit validity data associated with the transaction separately from the transaction data. Similarly, validity data associated with the transaction may be analyzed separately from the transaction data, but is transmitted along with the transaction data. For example, first transaction data TX1 is associated with first validity data VD1 and a first user at first user terminal 607, second transaction data TX2 is associated with second validity data VD2 and a second user at second user terminal 609, third transaction data TX3 is associated with third validity data VD3 and a third user at third user terminal 611, and fourth transaction data TX4 is associated with fourth validity data VD4 and a fourth user at fourth user terminal 613. Both the transaction data and validity data are transmitted to transaction pool 603 via shared communications network 605. Although represented as an external database, transaction data pool 603 may be a shared database (e.g., a peer-to-peer database). The transaction data and validity data received by transaction pool 603 are stored and then processed by at least one blockchain miner server 615. Another blockchain miner 617 may receive the validity data stored in a block of the blockchain and generate a validity proof for that block, which may then replace the validity data in the block. While Figure 6 shows two different miners performing the processing tasks of block generation and validity proof generation separately, it should be understood that a single miner may perform both tasks.The specific roles played by miners may be interchangeable, for example, with some miner servers focusing solely on block production or validity proof generation, or both simultaneously, depending on the specific implementation of the disclosed embodiments. Whether miners play one or more different roles may depend on the details of the incentive structure adopted by the implementing blockchain network. It should also be understood that while the system of FIG. 6 shows two blockchain miner servers 615 and 617, the number of blockchain miner servers included in the system is not important as long as there is at least one blockchain miner server, and in some embodiments, it is contemplated that the system may include three or more miners. In a system including two or more blockchain miner servers 615, 617, different blockchain miner servers may compete to generate the next block and validity proof in the blockchain, as occurs in conventional blockchain systems.

[0078] According to this embodiment, the structure of the blockchain may be non-standard. FIG. 7A is a schematic diagram of an exemplary non-standard blockchain structure for use in the present method. In contrast to the conventional blockchain structure shown in FIG. 2, validity data 702, 704, 706 associated with transactions is separated from the transaction data. As a result, in some embodiments, the block header 708 may be slightly modified in the sense that the Merkle root hash 710 is the result of hashing all transaction data contained in the block, excluding the validity data. In some other embodiments, the Merkle root hash 710 may generate a hash of all transaction data contained in the block, including the separated validity data. As usual, a hash of the block header is generated and referenced by the next block. FIG. 7B is a schematic diagram of the exemplary non-standard blockchain structure of FIG. 7A, in which some of the validity data stored in the blockchain block has been replaced with validity proofs within the same block. More specifically, in this example, the validity data for block N 702 and block N-2 706 has been replaced with validity proofs for block N 712 and block N-2 716, respectively. The validity data of block N-1 704 remains in place in block N-1.

[0079] 8A is a schematic comparison diagram illustrating how another non-standard blockchain may be used in accordance with embodiments disclosed herein. Specifically, the illustrated non-standard blockchain may be used by multiple miners to generate validity proofs on a blockchain in accordance with embodiments disclosed herein. In FIG. 8A, the non-standard blockchain is compared to a standard blockchain structure to illustrate how validity proofs are currently generated on a blockchain. Using the illustrated non-standard blockchain structure, validity proofs may be generated according to the following method steps: 1. Blocks 801 and 803 are proposed to the network with the complete block information included, and the block hash is generated using the complete block information minus the validity data, as described above. 2. Miners compete to generate validity proofs 805 for one or more blocks (in this case, block i and block i+1). 3. The first miner (after time k±j) generates a validity proof and proposes to include the generated proof in one or more blocks (in this case, block i and block i+1). 4. Other miners can verify the validity of the proof.

[0080] Although FIG. 8A illustrates an exemplary embodiment in which a validity proof is generated for multiple blocks (two in this case), it should be understood that this process can be applied to a single block.

[0081] 8B is a flowchart illustrating an example validity proof generation process 850 for a mutable block, i.e., a block whose contents may later be changed after it is generated and placed on the blockchain. Consistent with disclosed embodiments, such a method for retroactively amending an existing block of a blockchain may be performed by at least one miner server, such as miner servers 615, 617 of FIG. 6.

[0082] Method 850 begins at step 852 with receiving a plurality of validity data. Each validity data may be associated with a different transaction associated with one or more existing blocks, i.e., previously generated blocks, of the blockchain. For example, referring to FIG. 8A, a miner server (e.g., miner 617) may receive a plurality of validity data associated with transactions included in existing and previously generated blocks 801 and 803.

[0083] In step 854, one or more validity proofs associated with the plurality of validity data are generated. Referring to Figure 8A, at least one minor server may generate a validity proof 805 associated with the existing blocks 801, 803.

[0084] Finally, in step 856, process 850 may include retroactively incorporating the generated validity proof(s) into one or more existing blocks of the blockchain. Retroactively incorporating validity proof(s) into existing blocks may include replacing validity data stored in those blocks with subsequently generated validity proof(s). Additionally, the generated validity proof(s) may be incorporated into one or more existing blocks associated with transactions with which the one or more validity proof(s) are associated. As shown in FIG. 8A , at least one miner server may retroactively incorporate validity proof 805 associated with block i 801 into block 801, thereby replacing the validity data of this particular block. A similar operation is performed for block i+1 803. Consistent with the present disclosure, one or more generated validity proof(s) (e.g., validity proof 805 for block {i, i+1}) may be used to retroactively incorporate transaction data (e.g., TXs) included in one or more existing blocks (e.g., 801, 803) included in the blockchain. i , TXs i+1 ) may be possible to verify.

[0085] In contrast to the previous embodiment, in this embodiment, the miner does not ultimately need to generate a validity proof because the data for which the validity proof is generated is still stored on-chain. The decision to generate a validity proof may be based on a cost-benefit analysis 900, as shown in the flowchart of FIG. 9. The cost-benefit analysis 900 may be performed during steps 854 and 856 of process 850. At least one miner, such as miner 617, may perform a cost-benefit analysis for generating a validity proof for a block (901). If the result of the cost analysis in step 903 is positive (“yes”), the miner generates a validity proof in step 905 and replaces the validity data in the block with the validity proof in step 907. If the result of the cost analysis in step 903 is not positive (“no”), the miner does not modify the contents of the block and instead leaves the validity data in the block in step 909. This may be important in applications where there is no marginal utility in expending computational power to generate a validity proof. The cost-benefit analysis may be based on potential rewards to miners, time efficiency, processing efficiency, storage efficiency, energy consumption, or a combination thereof. For example, in some embodiments, the viability of the overall process may depend on an economic balance between the rewards a miner server receives for successfully generating a validity proof and the energy consumption costs associated with generating the proof. If the rewards do not offset the energy costs, the process may be deemed unprofitable. Similarly, if the time required to generate the proof exceeds an acceptable time efficiency limit or if the processing overhead adversely affects the overall efficiency of the blockchain (e.g., introducing undesirable latency), generation of the validity proof may be halted. Conversely, if the storage required to store the validity proof is less than the storage required to store the validity data, thus resulting in net storage savings, the cost-benefit analysis may be positive and generation of the validity proof may proceed. Recognizing that certain factors, even seemingly harmful, may have positive consequences, one or more of these factors may be considered in the cost-benefit analysis.For example, the process of generating one or more validity proofs requires the expenditure of time, money, and / or processing power, which may be offset by the resulting savings in storage on the blockchain, resulting in a net positive impact. A cost-benefit analysis considers these factors and the current state of both the blockchain and associated miners each time a validity proof is attempted to be generated. As a result, the results of the analysis may depend on the content of each proof and may be influenced by the current state of the network and blockchain. Therefore, it is envisioned that a blockchain may contain a mixture of blocks that contain validity proofs and blocks that simply contain validity data. Such a mixture of blocks is shown, for example, in FIG. 7B.

[0086] According to some embodiments, the cost-benefit analysis may include determining whether an estimated time required to generate one or more validity proofs is equal to or less than a predetermined time threshold. If the determined time is equal to or less than the predetermined threshold, the cost-benefit analysis may be positive, in which case the miner proceeds to generate one or more validity proofs. The estimated time may be determined based on available processing resources. Thus, a first miner with more processing resources than a second miner may determine that the estimated time is shorter than the second miner due to the difference in available processing resources.

[0087] Similarly, in some embodiments, the cost-benefit analysis may include determining whether the estimated processing overhead required to generate the one or more validity proofs is less than or equal to a predetermined processing overhead threshold. If the determined processing overhead is less than or equal to the threshold, the cost-benefit analysis may be positive, in which case the miner proceeds to generate the one or more validity proofs.

[0088] 2. Working Example A non-limiting example of how this embodiment may be implemented is described with respect to an embodiment in which a validity proof is generated for a set of digital signatures associated with multiple transactions, where the block hash function is modified to exclude the set of digital signatures as input. Assuming the current block is block i, the procedure is as follows: 1. The miner creates a set of digital signatures (for block i, {s1, s2, …, s Ni} i , for block i+1, {s1,s2,…,s Ni+1} i+1 It will continue to propose new blocks forever, including new ones. 2. At any time a miner generates a proof of validity for the previous block, the set of digital signatures is replaced with that block's proof of validity.

[0089] 6. Exemplary Process for Proof of Validity Generation: Signature Aggregation According to one embodiment, when generating a validity proof for a set of digital signatures associated with multiple transactions, the process of generating the validity proof may include generating an aggregate signature. One of the primary 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. Aggregating multiple signatures into a single signature may reduce overall data overhead, leading to more efficient and manageable communication and storage.

[0090] In the context of blockchains, where multiple transactions are bundled into a single block and each transaction is associated with a signature, signature aggregation can offer several advantages, increasing 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 aggregate signature. This reduction in block size translates directly to reduced storage and bandwidth requirements, resulting in improved scalability and faster transaction processing. Another advantage of signature aggregation is that it can allow some of the computations associated with 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 calculations. 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 untrustworthy and may not need to communicate with on-chain parties. This approach offers significant advantages to blockchain systems, including improved scalability and reduced on-chain resource requirements. For example, with reference to Figures 3 and 6, miner B 317, 617 may represent an off-chain aggregator responsible for generating aggregate signatures associated with blocks, while miner A may represent an on-chain miner responsible for generating new blocks.

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

[0092] Incorporating aggregation capabilities 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 an aggregate signature A, the output outputs bit b, which indicates whether signature A is a valid aggregate signature for the given set of message-key pairs.

[0093] 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 signing entities and private keys (sk) in one or more rounds of interaction. Furthermore, in certain scenarios, the Verify algorithm may be omitted since its functionality can be incorporated into AggregateVerify, allowing verification of individual signatures during the verification of the aggregate signature, or alternatively, during the verification phase, only the validity of the aggregate signature may be checked, since the aggregate signature may be valid if and only if each individual signature is valid.

[0094] The Aggregate and AggregateVerify algorithms provide the necessary foundation for compressing digital information without sacrificing its integrity. AggregateVerify allows for the verification of aggregate signatures, ensuring that aggregate signatures can be stored as compressed transaction information on the blockchain. In fact, AggregateVerify, used as a verification function, establishes that an aggregate signature is correct and can be used to verify that the set of transactions on the blockchain represents the true set of valid transactions submitted as input. Thus, running AggregateVerify on an aggregate signature allows the blockchain to verify the resulting aggregate signature before recording it on-chain.

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

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

[0097] However, in other cases, the aggregated signature can be more compact and, as a result, be sub-linear in size with respect to N. For example, the size of the aggregated signature can scale logarithmically with N (|A| = |O(ln(N))|). In such cases, the aggregated signature becomes more efficiently published in an asymptotic sense than N individual signatures. This means that as the number N of signatures increases, the size of the aggregated signature increases more slowly than the linear increase seen when concatenating the signatures individually. There is a space-saving effect. Due to the constant coefficient included in the asymptotic notation, there is a threshold with respect to the number N of signatures below which the compression or compactification effect is not obvious. This threshold is determined by the logarithmic scaling. For example, when the size of the aggregated signature is given by |A| = C1 ln(N) where C1 ≈ 20 * |s|, the space-saving effect becomes significant only when the value of N exceeds 90. Further, the threshold is affected by any additional data that may be included in the aggregated signature during the aggregation process. As the size of this additional data increases, the threshold also increases, which means that more signatures are required to obtain a significant space-saving effect. The additional data contributes to the overall size of the aggregated signature and affects the point at which the compactification effect becomes apparent.

[0098] In a particular protocol, the public keys (pk1,..., pk N ) may be published along with the aggregated signature. In such an embodiment, assuming logarithmic scaling, space savings may be seen when the number N of signatures 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 the trade-off between the size of the aggregated signature and the space required for the publication of the public keys.

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

[0100] Note that the space savings associated with aggregate signatures do not result from any compression techniques. Compression techniques are designed to convert data into a more compact form that can be restored or decompressed for later use. However, in contrast to compression techniques, in the case of aggregate signatures, it is not possible to recover non-aggregate signatures from the aggregate signature. Instead, space savings in aggregate 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.

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

[0102] 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 between the individual signatures and by the security of the aggregation algorithm itself.

[0103] According to some embodiments, the aggregate signature A may also be generated using a zero-knowledge proof algorithm. For example, according to one embodiment, the aggregator (prover) generates a set of N signatures (s1,...,s N ) (private witness), and the function F((μ i ,pk i ,s i )i =1:N )=A without revealing any information. To achieve this, the aggregator can use zk-SNARKs to encode all the relevant information needed to verify the individual disaggregated signatures into several high-degree polynomials over a finite field, where the finite field contains more elements than the highest degree of these polynomials. For example, the aggregator can compute interpolating polynomials that provide all the signatures being aggregated when evaluated over a subset of the underlying field, along with additional interpolating polynomials that evaluate all the corresponding public keys. The aggregator can then use the set (μ i ,pk i ) i=1:NAn 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 quantum-resistant zero-knowledge proof (ZKP) algorithm may be used to ensure security and resistance against potential attacks from quantum computers. One example of such a quantum-resistant ZKP algorithm is the Aurora algorithm. With respect to individual signatures, the ZKP proof may be integrated as one of the components of an aggregate signature A, contributing to the overall size of the signature, or it may represent the signature A itself. The size of an aggregate signature generated using a ZKP algorithm depends on the specific 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.

[0104] 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 described above, the aggregator (prover) refrains from disclosing its individual signatures to the verifier. As a result, these signatures may be omitted entirely from the resulting aggregate signature, realizing significant space savings.

[0105] In some embodiments, a non-zero-knowledge proof system may be used. While this approach may, in some circumstances, reveal certain non-zero information about the private witness (individual signatures in this context), this may be acceptable within the framework of an aggregate signature scheme, since in many applications, the digital signature may not contain any private or confidential information. It is important to understand that the use of a digital signature as a means of validity proof is only one of various possibilities for data that may serve as a validity proof. Various types of data linked to transactions on a blockchain or block may be incorporated into a validity proof through a process of compression and / or aggregation.

[0106] 7. Running on a physical device 10A illustrates how a blockchain miner server 315, 317, 615, 617 interacts with user transactions to delay the generation of validity proofs and their integration into blocks in the blockchain, according to embodiments disclosed herein. The miner server 315, 317, 615, 617 receives multiple validity data VD from the communication network 305, 605, as detailed in step 1002 of FIG. 10A. The validity data may be submitted by users, e.g., users of user terminals 307, 309, 311, 313, 607, 609, 611, 613, and stored in a block in the blockchain, the transaction pool 603, or the validity data pool 319. In some embodiments, the received multiple validity data VD may correspond to multiple digital signatures or signature data s, each of which may be associated with a different transaction associated with one or more existing blocks in the blockchain. Each transaction is signed using a distinct public-private key pair (PK) chosen using a digital signature method (e.g., KeyGen, Sign, Verify). i ,sk i ) The signature data associated with the transaction s iis the transaction data TX i the private key sk associated with that transaction 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.

[0107] In some embodiments, signatures s associated with multiple different transactions TX i is 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 quantum-safe digital signature scheme. By using quantum-safe cryptography for signature generation, a blockchain network can enhance its security and future-proof the system against potential threats posed by advances in quantum computing. More specifically, in some embodiments, the quantum-safe digital signature scheme is a lattice-based digital signature scheme. Examples of lattice-based digital signature schemes include Falcon, Dilithium qTESLA, Rainbow, and Bliss digital signature schemes. In yet another embodiment, the lattice-based digital signature scheme is a hash-and-sign signature scheme. The Falcon signature scheme is an example of a hash-and-sign lattice signature scheme.

[0108] Next, in step 1004, the miner servers 315, 317, 615, and 617 may generate one or more validity proofs associated with one or more blocks from the plurality of new blocks based on the associated validity data VD. In step 1006, the miner servers 315, 317, 615, and 317 incorporate the one or more validity proofs generated in the previous step into a block of the blockchain. In one embodiment, the block of the blockchain may be immutable. In such a scenario, incorporating the validity proofs into the blockchain proceeds as shown in Figures 5A-5C and described above in relevant parts of this description. Alternatively, the block of the blockchain may be mutable. In such a scenario, incorporating the validity proofs into the blockchain proceeds as shown in Figures 8A-8B and described above in relevant parts of this description.

[0109] In some embodiments, generating one or more validity proofs may include aggregating multiple digital signatures. This aggregation process may include using an aggregate signature algorithm (e.g., Aggregate) that includes a set of transaction-key-signature triples (TX1, pk1, s1), ..., (TXN, pkN, sN).

[0110] In some embodiments, if the plurality of distinct transactions includes N transactions, the size of the aggregate signature A is the sum of the sizes of all N individual signatures associated with the plurality of distinct transactions (s i ) i=1:N Alternatively, the number of transactions N may be less than the threshold number of signatures N th, below which threshold number no compression or compaction effects are evident. Indeed, in some embodiments, the size of the aggregate signature A may be sublinear with N. For example, in some embodiments, the size of the aggregate signature A may scale logarithmically with N (|A|=|O(ln(N))|). As the number of transactions N exceeds this threshold (Nth), aggregate signatures become increasingly advantageous in terms of space efficiency because their size grows at a slower rate compared to the cumulative size of each transaction's individual signatures.

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

[0112] In some embodiments, an aggregate signature A may be formed by multiple aggregate signature components A=(a1,...,a M’ ), where M′ denotes the total number of aggregate signature components. These components may be parts of a complex formula, a complex formula, the output of a cryptographically verifiable computation algorithm, or a combination thereof. Examples of cryptographically verifiable computation 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 computation algorithm.

[0113] 10B illustrates an alternative process for how a blockchain miner server 315, 615 interacts with user transactions to delay the generation of validity proofs and their integration into blocks in the blockchain, according to embodiments disclosed herein. The miner server 315, 615 receives multiple different transactions sent by users (e.g., users of user terminals 307, 309, 311, 313, 607, 609, 611, 613) from the communication network 305, 605, each transaction including transaction data TX and associated validity data VD, and the transactions are stored in the transaction pool 303, 603, as detailed in step 1012 of FIG. 10B.

[0114] Next, in step 1014, the miner server 315, 615 validates the incoming transaction by generating one or more validity proofs associated with one or more blocks from the plurality of new blocks based on the associated validity data VD. In step 1016, the miner server 315, 615 incorporates the one or more validity proofs generated in the previous step into the blockchain. In one embodiment, the blocks of the blockchain may be immutable. In such a scenario, the incorporation of validity proofs into the blockchain proceeds as shown in FIG. 5 and as described above in the relevant parts of this description. Alternatively, the blocks of the blockchain may be mutable. In such a scenario, the incorporation of validity proofs into the blockchain proceeds as shown in FIG. 8 and as described above in the relevant parts of this description.

[0115] As mentioned above, the received validity data may include multiple signature data, and generating the one or more validity proofs may include aggregating the multiple signature data using an aggregation algorithm to generate one or more aggregate signatures. Accordingly, all embodiments described above in connection with process 1000 shown in FIG. 10A remain valid and are incorporated herein in their entirety without restatement.

[0116] When the number of received transactions reaches a threshold number of transactions, which may be predetermined, the miner server 315, 615 can begin generating one or more new blocks in parallel in step 1018. The new block includes the transactions. The generation of the new block may conform to a proof-of-work (PoW) protocol, in which the miner server 315, 615 may generate a cryptographic hash less than a target hash to prove to the network 305, 605 that a certain amount of computational effort has been expended on the received transactions, the miner server 315, 615 proposes the new block to the network 305, 605, consensus is reached, and the block is added to the blockchain. PoW is just one of several consensus mechanisms that may be used. In other scenarios, a different consensus mechanism may be utilized, such as a proof-of-stake protocol or any other suitable consensus mechanism.

[0117] In both the block generation process and the proof-of-validity generation process, miners may participate in a competitive mechanism, with the probability of winning rewards typically roughly corresponding to the computing power possessed by each individual miner.

[0118] 8.Other In the disclosed embodiments, blockchain transactions are still considered immutable, in the sense that they are final according to traditional blockchain consensus protocols. Once transaction details are accepted by the network, third parties cannot tamper with any transaction details. The issue of immutability / mutability refers only to the structure of the blockchain. According to one embodiment disclosed herein, blocks are immutable, in the sense that once a new block is generated, its contents can never be changed or altered. According to an alternative embodiment disclosed herein, the blockchain itself is mutable in one specific way, in that validity data within a block can be replaced with a validity proof.

[0119] The disclosed methods and protocols specify the results that miners must achieve to claim rewards, while allowing miners the freedom to choose their preferred methods for achieving these results. This flexibility also extends to the hardware used by miner servers. For example, the overall computing power of each miner may vary and may change depending on competition and the number of miners employed. In the early stages, when the network is small and competition is limited, it may be more practical to use general-purpose computers or GPUs. As competition intensifies, it may become more advantageous to use specialized hardware tailored to mining operations.

[0120] The foregoing description has been presented for purposes of illustration. It is not exhaustive or limited to the precise form or embodiment disclosed. Modifications and adaptations of the embodiments will be apparent from consideration of the specification and practice of the disclosed embodiments. For example, minor described functional modules 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 with each other or distributed in any suitable manner.

[0121] Furthermore, although exemplary embodiments have been 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 alterations based on this disclosure. Claim elements should be interpreted broadly based on the terms used in the claims and not limited to the examples set forth herein, which examples should be construed as non-exclusive.

[0122] 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 for generating a validity proof associated with one or more transactions associated with one or more existing blocks of a blockchain, comprising: receiving a plurality of validity data, each validity data associated with a different transaction associated with the one or more existing blocks of the blockchain; generating one or more validity certificates associated with the plurality of validity data; and incorporating the generated one or more validity proofs into a block of the blockchain.

2. incorporating the one or more generated validity proofs into the block of the blockchain; 10. The method of claim 1, comprising retroactively incorporating the generated one or more validity proofs into one or more existing blocks of the blockchain.

3. 3. The method of claim 2, wherein the generated one or more validity proofs are incorporated into the one or more existing blocks associated with the transaction with which the one or more validity proofs are associated.

4. 4. The method of claim 2 or 3, wherein generating the one or more validity certificates associated with the plurality of validity data comprises performing a cost-benefit analysis on the validity certificate generation process, and generating one or more validity certificates associated with the plurality of validity data when a result of the cost-benefit analysis is positive.

5. 5. The method of claim 4, wherein the cost-benefit analysis is based on one or more of the following: potential reward to a miner generating the one or more proofs of validity; time efficiency; processing efficiency; storage efficiency; and energy consumption.

6. 6. The method of claim 5, wherein when the cost-benefit analysis is based on the potential reward to the miner for generating the one or more validity proofs, the result of the cost-benefit analysis is positive if the reward to the miner for generating the one or more validity proofs offsets the energy cost of generating the one or more validity proofs.

7. 6. The method of claim 5, wherein when the cost-benefit analysis is based on storage efficiency, the result of the cost-benefit analysis is positive if the space savings obtained by storing the one or more generated validity proof compared to the storage required to store the associated validity data is equal to or exceeds a threshold.

8. incorporating the one or more generated validity proofs into a block of the blockchain; 2. The method of claim 1, further comprising incorporating the generated one or more validity proofs into a currently generated block of the blockchain, wherein the one or more validity proofs enable verification of transaction data included in one or more previously generated blocks included in the blockchain.

9. 9. The method of claim 8, wherein the one or more previously generated blocks precede the currently generated block by a period equal to or greater than the time required to generate the one or more validity proofs.

10. 10. The method of claim 8 or 9, wherein the one or more previously generated blocks precede the currently generated block by a predetermined number of blocks on the blockchain, and the time taken to generate the predetermined number of blocks is proportional to a period of time equal to or longer than the time required to generate the one or more validity proofs.

11. 11. The method according to claim 9 or 10, wherein the period is parameterized by at least two parameters k and j, the period being equal to k±j.

12. 12. The method of claim 11, wherein the value of the parameter k depends on a computing power associated with at least one miner associated with the blockchain, and the parameter j is associated with the stability of the blockchain network.

13. The method comprises:

10. The method of any one of the preceding claims, comprising receiving the plurality of validity data from a database accessible to one or more miners included in a blockchain network.

14. The method comprises:

14. The method of any one of claims 1 to 13, comprising receiving the plurality of validity data from a database distributed across a plurality of nodes included in a blockchain network.

15. The method comprises: The method of claim 14 , comprising receiving the plurality of validity data from a peer-to-peer distributed database.

16. 10. A method according to any one of the preceding claims, wherein the database contains only validity data.

17. The received plurality of validity data is a plurality of signature data s ｉ 10. The method of claim 1, wherein each signature data is associated with a different transaction associated with the one or more existing blocks of the blockchain.

18. Each transaction has a public key pk ｉ and the private key sk ｉ The public key and private key pair are generated according to a digital signature scheme, and the signature data s associated with the transaction is ｉ is the transaction data TX associated with the transaction ｉ the private key sk associated with the transaction ｉ 18. The method of claim 17, wherein the data is generated by encrypting the data with

19. 20. The method of claim 18, wherein the digital signature scheme is a multi-use signature scheme.

20. 20. The method of claim 18 or 19, wherein the digital signature scheme is a quantum-resistant digital signature scheme.

21. 21. The method of claim 20, wherein the quantum-resistant digital signature scheme is a lattice cryptography digital signature scheme.

22. The method of claim 21 , wherein the lattice cryptography digital signature scheme is a hash-and-sign lattice cryptography digital signature scheme.

23. 23. The method of claim 22, wherein the hash-and-sign lattice cryptographic digital signature scheme is a FALCON signature scheme.

24. 24. The method of claim 17, wherein generating one or more validity proofs comprises aggregating the plurality of signature data using an aggregation algorithm to generate one or more aggregate signatures.

25. 25. The method of claim 24, wherein the size of each of the one or more aggregate signatures is smaller than the total size of the individual signature data that is aggregated.

26. 26. The method of claim 24 or 25, wherein the size of the one or more aggregate signatures is sublinear with respect to the total number of signature data to be aggregated.

27. The method of any one of claims 24 to 26, wherein the size of the one or more aggregate signatures scales logarithmically with the total number of signature data to be aggregated.

28. A plurality of different transactions, each transaction comprising transaction data TX ｉ receiving a plurality of different transactions, including: generating a plurality of new blocks on the blockchain in parallel, the new blocks including the transaction data; 10. The method of any one of the preceding claims, further comprising:

29. 1. A server including a processor, the processor comprising: receiving a plurality of validity data, each validity data associated with a different transaction associated with the one or more existing blocks of the blockchain; generating one or more validity certificates associated with the plurality of validity data; A server configured to incorporate the one or more generated validity proofs into a block of the blockchain.

30. the processor:

30. The server of claim 29, configured to retroactively incorporate the generated one or more validity proofs into one or more existing blocks of the blockchain.

31. the processor:

31. The server of claim 30, configured to incorporate the generated one or more validity proofs into the one or more existing blocks associated with the transaction with which the one or more validity proofs are associated.

32. the processor:

31. The server of claim 30, configured to perform a cost-benefit analysis on the process of generating the validity certificate, and when a result of the cost-benefit analysis is positive, generate one or more validity certificates associated with the plurality of validity data.

33. 33. The server of claim 32, wherein the processor is configured to perform the cost-benefit analysis based on one or more of the following: potential reward for generating the one or more validity proofs, time efficiency, processing efficiency, storage efficiency, and energy consumption.

34. the processor:

30. The server of claim 29, configured to incorporate the generated one or more validity proofs into a currently generated block of the blockchain, the one or more validity proofs enabling verification of transaction data included in one or more previously generated blocks included in the blockchain.

35. 35. The server of claim 34, wherein the one or more previously generated blocks precede the currently generated block by a period equal to or greater than the time required to generate the one or more validity proofs.

36. 36. The server of claim 34 or 35, wherein the one or more previously generated blocks precede the currently generated block by a predetermined number of blocks on the blockchain, and wherein the time taken to generate the predetermined number of blocks is proportional to a period of time equal to or longer than the time required to generate the one or more validity proofs.

37. 37. The server of claim 35 or 36, wherein the processor is configured to parameterize the period by at least two parameters k and j, the period being equal to k±j.

38. 38. The server of claim 37, wherein the value of the parameter k depends on a computing power associated with at least one miner associated with the blockchain, and the parameter j is associated with the stability of the blockchain network.

39. the processor: The server of any one of claims 29 to 38, configured to receive the plurality of validity data from a database accessible to one or more miners included in a blockchain network.

40. the processor: The server of any one of claims 29 to 39, configured to receive the plurality of validity data from a database distributed across a plurality of nodes included in a blockchain network.

41. the processor:

41. The server of claim 40, configured to receive the plurality of validity data from a peer-to-peer distributed database.

42. A server according to any one of claims 29 to 41, wherein the database contains only validity data.

43. The received plurality of validity data are a plurality of signature data s ｉ wherein each signature data is associated with a different transaction associated with the one or more existing blocks of the blockchain.

44. Each transaction has a public key pk ｉ and the private key sk ｉ the public key and private key pair is generated according to a digital signature scheme, and the signature data s associated with the transaction is ｉ is the transaction data TX associated with the transaction ｉ the private key sk associated with the transaction ｉ 44. The server of claim 43, wherein the encrypted data is generated by encrypting the encrypted data with

45. 45. The server of claim 44, wherein the digital signature scheme is a multi-use signature scheme.

46. 46. ​​The server of claim 44 or 45, wherein the digital signature scheme is a quantum-resistant digital signature scheme.

47. 47. The server of claim 46, wherein the quantum-resistant digital signature scheme is a lattice cryptography digital signature scheme.

48. 48. The server of claim 47, wherein the lattice cryptography digital signature scheme is a hash-and-sign lattice cryptography digital signature scheme.

49. 49. The server of claim 48, wherein the hash-and-sign lattice cryptographic digital signature scheme is a FALCON signature scheme.

50. 50. The server of claim 43, wherein the processor is configured to generate one or more validity proofs, the generating comprising aggregating the plurality of signature data using an aggregation algorithm to generate one or more aggregate signatures.

51. 51. The server of claim 50, wherein the size of each of the one or more aggregate signatures is smaller than the total size of the individual signature data being aggregated.

52. 52. The server of claim 50 or 51, wherein the size of the one or more aggregate signatures is sublinear with respect to the total number of signature data to be aggregated.

53. 53. The server of any one of claims 50 to 52, wherein the size of the one or more aggregate signatures scales logarithmically with the total number of signature data to be aggregated.

54. the processor: Each is transaction data TX ｉ receive multiple different transactions, including 10. The server of any one of the preceding claims, further configured to generate in parallel a plurality of new blocks on the blockchain comprising the transaction data.

Images