<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Enhancing blockchain scalability through zero- knowledge proofs: A novel block finality system for near protocol ⋆</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Oleksandr Kuznetsov</string-name>
          <email>oleksandr.k@zpoken.io</email>
          <email>oleksandr.kuznetsov@uniecampus.it</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Anton Yezhov</string-name>
          <email>anton.yezhov@zpoken.io</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Kateryna Kuznetsova</string-name>
          <email>kateryna@proxima.one</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Vladyslav Yusiuk</string-name>
          <email>vladyslav.y@zpoken.io</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Valentyn Chernushevych</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>CPITS-II 2024: Workshop on Cybersecurity Providing in Information and Telecommunication Systems II</institution>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Vision, Robotics and Artificial Intelligence Lab</institution>
          ,
          <addr-line>12 Via Brecce Bianche, 60131 Ancona</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Zpoken OÜ</institution>
          ,
          <addr-line>Harju maakond, Kesklinna linnaosa, 7-2 Sakala tn, 10141 Tallinn</addr-line>
          ,
          <country country="EE">Estonia</country>
        </aff>
        <aff id="aff3">
          <label>3</label>
          <institution>eCampus University</institution>
          ,
          <addr-line>10 Via Isimbardi, 22060 Novedrate</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
      </contrib-group>
      <fpage>94</fpage>
      <lpage>104</lpage>
      <abstract>
        <p>This paper presents a novel zero-knowledge proof (ZKP) system for block finality verification in the NEAR Protocol, addressing critical challenges in blockchain scalability and security. We introduce a comprehensive ZKP-based verification system that encompasses block hash, signature, validator key and stake, and next block producer hash verification. Our approach achieves constant-time verification for light clients, regardless of block size or complexity, significantly enhancing the efficiency and security of light client operations. By leveraging advanced cryptographic techniques, including the Plonky2 framework, we demonstrate the feasibility of using ZKPs in high-throughput blockchain networks. Our performance evaluation provides valuable insights into the scalability and efficiency of ZKP systems in real-world blockchain environments. Results show consistent proof verification times of approximately 4 milliseconds across varying block sizes, with aggregated proof sizes remaining constant at 180,112 bytes. While proof generation times range from 13 to 18 minutes per block, the rapid verification time and compact proof size offer substantial benefits for light clients and cross-chain communication. This work contributes to the ongoing research in blockchain scalability, offering a practical solution that maintains security and decentralization while significantly reducing computational and bandwidth requirements for blockchain participants.</p>
      </abstract>
      <kwd-group>
        <kwd>eol&gt;distributed system</kwd>
        <kwd>light client</kwd>
        <kwd>blockchain scalability</kwd>
        <kwd>zero-knowledge proof</kwd>
        <kwd>NEAR protocol</kwd>
        <kwd>block finality verification</kwd>
        <kwd>cybersecurity</kwd>
        <kwd>blockchain interoperability 1</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        Blockchain technology has emerged as a transformative
force in various sectors, promising enhanced security,
transparency, and decentralization [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. However, as
blockchain applications proliferate, scalability has become a
critical challenge, particularly for high-throughput systems
like the NEAR Protocol [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. The increasing demand for
faster transaction processing and more efficient data
verification has pushed the limits of traditional blockchain
architectures, necessitating innovative solutions to
maintain the technology's core benefits while improving its
scalability [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
      </p>
      <p>
        The NEAR Protocol, designed as a sharded,
proof-ofstake blockchain, aims to address some of these scalability
issues through its unique architecture [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. However, as with
many blockchain systems, the challenge of efficient block
finality verification, especially for light clients, remains a
significant hurdle [
        <xref ref-type="bibr" rid="ref5 ref6">5, 6</xref>
        ]. Light clients, crucial for broadening
blockchain accessibility, often struggle with the trade-off
between efficiency and security guarantees when verifying
the blockchain state [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
      </p>
      <p>This paper introduces a novel zero-knowledge proof
(ZKP) system designed specifically for block finality
verification in the NEAR Protocol. Our approach leverages
advanced cryptographic techniques to create a system that
allows for rapid and secure verification of block finality,
particularly beneficial for light clients and cross-chain
communication scenarios.</p>
      <p>The core contributions of this work include:</p>
      <p>A comprehensive ZKP-based verification system
that encompasses block hash, signature, validator
key and stake, and next block producer hash
verification.</p>
      <p>Implementation of constant-time verification for
light clients, independent of block size or
complexity, significantly enhancing the efficiency
and security of light client operations.</p>
      <p>Practical demonstration of the Plonky2
framework’s capabilities in generating and
verifying zero-knowledge proofs for
highthroughput blockchain networks.</p>
      <p>Extensive performance evaluation providing
insights into the scalability and efficiency of ZKP
systems in real-world blockchain environments.
Analysis of the trade-offs between proof
generation time, verification speed, and proof size,
offering valuable data for future blockchain design
decisions.</p>
      <p>Our work builds upon a growing body of research in
blockchain scalability, zero-knowledge proofs, and
distributed systems. By addressing the specific challenges of
the NEAR Protocol while maintaining broader applicability,
we contribute to the ongoing evolution of blockchain
technology toward more scalable and efficient systems.</p>
      <p>The remainder of this paper is structured as follows:
Sections 2 and 3 provide a background on relevant concepts
and related work. Section 4 details the architecture of our
ZKP-based block finality system. Section 5 describes the
zero-knowledge proof construction. Section 6 offers a
comprehensive performance evaluation. Section 7 discusses
the implications of our findings and potential future
directions. Finally, Section 8 concludes the paper with a
summary of our key contributions and their significance in
the field of blockchain technology.</p>
    </sec>
    <sec id="sec-2">
      <title>2. Literature review</title>
      <p>The development of scalable and secure blockchain systems
has been a focal point of research in recent years, driven by
the need to address the limitations of early blockchain
implementations. This section provides an overview of key
contributions and ongoing challenges in this domain.</p>
      <p>
        Scalability has emerged as a critical issue in blockchain
systems, as highlighted by Nasir et al. (2022) [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] in their
systematic review. The authors identify scalability as a
multifaceted concept, encompassing not only network
expansion but also enhancements in processing capabilities,
memory, storage, and consensus strategies. Their work
underscores the complexity of achieving scalability while
maintaining the core benefits of blockchain technology.
      </p>
      <p>
        In response to these challenges, several innovative
approaches have been proposed. Lin et al. (2020) [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]
introduced Rapido, a multi-path off-chain payment
mechanism designed to address the overload and privacy
issues inherent in single-path payment systems like the
Lightning Network. By distributing payments across
multiple paths, Rapido not only resolves the overload issue
but also mitigates the skewness of payment channels,
demonstrating a significant improvement in success rates
compared to traditional approaches.
      </p>
      <p>
        The concept of sharding has gained traction as a
promising solution for blockchain scalability. Li et al. (2023)
[
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] provide a comprehensive survey of state-of-the-art
sharding blockchains, analyzing various models,
components, and potential attack surfaces. Their work
highlights the potential of sharding to enhance scalability
while maintaining security and decentralization, a crucial
balance in blockchain design.
      </p>
      <p>
        Addressing the scalability-security trade-off, Oliveira et
al. (2020) [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] proposed the Blockchain Reputation-Based
Consensus (BRBC) mechanism. This approach introduces a
reputation score system for nodes, allowing only those with
scores above a certain threshold to participate in block
insertion. The authors demonstrate BRBC’s resistance to
various known attacks and its ability to expel malicious
nodes efficiently, offering a novel perspective on consensus
mechanisms in blockchain networks.
      </p>
      <p>
        In the realm of practical implementations, Meeuw et al.
(2020) [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ] provide valuable insights from a real-world
blockchain-managed microgrid in Switzerland. Their study
empirically evaluates the feasibility of a Byzantine
faulttolerant blockchain system in a practical setting,
highlighting the impact of communication infrastructure
limitations on system performance. Their findings
underscore the importance of considering hardware and
network constraints in blockchain design, particularly for
applications in resource-constrained environments.
      </p>
      <p>
        The scalability of blockchain systems in distributed
environments has also been explored. Gawande et al. (2022)
[
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] present groundbreaking work on scaling community
detection algorithms on distributed-memory heterogeneous
systems, including multi-GPU setups. While not directly
focused on blockchain, their approach to parallelizing graph
algorithms offers valuable insights for improving the
efficiency of blockchain operations in distributed
environments.
      </p>
      <p>
        Otte et al. (2020) [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ] introduced TrustChain, a
Sybilresistant scalable blockchain that offers an alternative to
traditional proof-of-work mechanisms. By creating an
immutable chain of temporally ordered interactions for each
agent, TrustChain demonstrates how historical transaction
records can provide security and scalability without
requiring global consensus, a concept that could be adapted
to enhance blockchain scalability.
      </p>
      <p>
        The application of blockchain technology in specific
domains, such as energy markets, has also been explored. Li
and Zhang (2022) [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] developed a data-oriented distributed
optimization strategy for large-scale HVAC systems,
demonstrating the potential of distributed approaches in
complex systems. While not directly related to blockchain,
their work provides insights into distributed optimization
techniques that could be relevant to blockchain scalability
solutions.
      </p>
      <p>
        Rawhouser et al. (2022) [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ] examine the scaling of
blockchain technology applications in developing countries,
highlighting the importance of network effects and
innovative scaling methods. Their analysis of approaches
such as promoting technology platforms, leveraging
collective action, and navigating institutional contexts
offers valuable perspectives on the broader challenges of
scaling blockchain solutions in diverse environments.
      </p>
      <p>In conclusion, the literature reveals a multifaceted
approach to addressing blockchain scalability,
encompassing innovations in consensus mechanisms,
network architecture, and application-specific
optimizations. While significant progress has been made,
challenges remain in balancing scalability with security,
decentralization, and practical implementation constraints.
Our work aims to build upon these foundations, specifically
addressing the challenges of block finality verification in
high-throughput blockchain systems like the NEAR
Protocol.</p>
    </sec>
    <sec id="sec-3">
      <title>3. Background</title>
      <p>The development of our zero-knowledge proof system for
block finality in the NEAR Protocol builds upon a rich
foundation of cryptographic research and blockchain
technology. This section provides an overview of the key
concepts and related work that form the basis of our
research.</p>
      <sec id="sec-3-1">
        <title>3.1. Zero-knowledge proofs</title>
        <p>
          Zero-knowledge proofs (ZKPs), first introduced by
Goldwasser, Micali, and Rackoff in 1985 [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ], are
cryptographic protocols that allow one party (the prover) to
prove to another party (the verifier) that a statement is true
without revealing any information beyond the validity of
the statement itself. ZKPs possess three fundamental
properties [
          <xref ref-type="bibr" rid="ref18 ref19">18, 19</xref>
          ]:
        </p>
        <p>Completeness: If the statement is true, an honest
verifier will be convinced by an honest prover.</p>
        <p>Soundness: If the statement is false, no cheating
prover can convince an honest verifier that it is
true, except with negligible probability.</p>
        <p>Zero-knowledge: If the statement is true, the
verifier learns nothing other than the fact that the
statement is true.</p>
        <p>
          Recent advancements in ZKP systems, particularly in
the development of succinct non-interactive
zeroknowledge proofs (SNARKs) [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ] and scalable transparent
arguments of knowledge (STARKs) [
          <xref ref-type="bibr" rid="ref21">21</xref>
          ], have made ZKPs
increasingly practical for real-world applications, including
blockchain systems.
        </p>
      </sec>
      <sec id="sec-3-2">
        <title>3.2. NEAR protocol</title>
        <p>
          NEAR Protocol is a sharded, proof-of-stake blockchain
designed to address the scalability limitations of earlier
blockchain systems [
          <xref ref-type="bibr" rid="ref4">4</xref>
          ]. Key features of NEAR include:
Nightshade sharding: A unique sharding approach
that allows for horizontal scaling of the network’s
processing capacity.
        </p>
        <p>Doomslug consensus: A block production
mechanism that enables rapid block finality.</p>
        <p>WebAssembly-based smart contracts: Allowing
for more efficient and flexible smart contract
execution.





</p>
        <p>Understanding NEAR’s architecture is crucial for
appreciating the challenges and opportunities in
implementing a ZKP-based finality system.</p>
      </sec>
      <sec id="sec-3-3">
        <title>3.3. Blockchain finality and light clients</title>
        <p>Blockchain finality refers to the point at which a transaction
or block can be considered irreversible. In probabilistic
finality systems like Bitcoin, finality is achieved after a
certain number of confirmations. In contrast, systems with
deterministic finality, like NEAR, aim to provide quicker
and more definitive transaction finality.</p>
        <p>Light clients are crucial for broadening blockchain
accessibility, allowing resource-constrained devices to
interact with the blockchain without maintaining a full copy
of the chain. However, traditional light client protocols
often involve trade-offs between efficiency and security
guarantees.</p>
      </sec>
      <sec id="sec-3-4">
        <title>3.4. Related work in ZKP-based blockchain systems</title>
        <p>Several projects have explored the application of ZKPs in
blockchain systems:</p>
        <p>
          Zcash [
          <xref ref-type="bibr" rid="ref22 ref23">22, 23</xref>
          ]: Pioneered the use of zk-SNARKs for
privacy-preserving transactions in a public
blockchain.
        </p>
        <p>
          Coda Protocol (now Mina) [
          <xref ref-type="bibr" rid="ref24 ref25">24, 25</xref>
          ]: Implemented a
succinct blockchain using the recursive
composition of SNARKs.
        </p>
        <p>
          StarkWare [
          <xref ref-type="bibr" rid="ref26 ref27">26, 27</xref>
          ]: Developed STARKs for
scalable, transparent, and post-quantum secure
computation.
        </p>
        <p>Our work builds upon these foundations, specifically
addressing the challenges of block finality verification in the
context of NEAR Protocol's high-throughput, sharded
architecture.</p>
      </sec>
      <sec id="sec-3-5">
        <title>3.5. Plonky2 framework</title>
        <p>
          Our implementation leverages the Plonky2 framework, a
state-of-the-art system for generating and verifying
zeroknowledge proofs. Plonky2 combines [
          <xref ref-type="bibr" rid="ref28 ref29 ref30">28–30</xref>
          ]:
        </p>
        <p>The PLONK proof system: A universal and
updateable structured reference string (SRS)
scheme.</p>
        <p>FRI commitments: Providing a balance between
proof size and verification time.</p>
        <p>Optimized arithmetization: Enhancing the
efficiency of proof generation and verification.







</p>
        <p>Understanding Plonky2’s capabilities and limitations is
essential for contextualizing the performance
characteristics of our system.</p>
      </sec>
      <sec id="sec-3-6">
        <title>3.6. Cryptographic primitives</title>
        <p>Our system relies on several fundamental cryptographic
primitives:</p>
        <p>SHA-256: A widely-used cryptographic hash
function, crucial for block hash verification.</p>
        <p>EdDSA (Edwards-curve Digital Signature
Algorithm): An efficient digital signature scheme
used for validator signature verification.</p>
        <p>Merkle trees: Fundamental data structures for
efficient proof of membership, used in various
components of our system.</p>
        <p>The selection and implementation of these primitives
significantly influence the security and performance of our
ZKP system.</p>
        <p>By building upon this diverse foundation of
cryptographic research and blockchain technology, our
work aims to address the critical challenges of scalability
and security in modern blockchain systems, with a specific
focus on enhancing light client capabilities in the NEAR
Protocol ecosystem.</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>4. System architecture</title>
      <p>The proposed zero-knowledge proof (ZKP) system for block
finality in the NEAR Protocol represents a significant
advancement in blockchain security and scalability. This
section provides a comprehensive overview of the system’s
architecture, detailing its key components and their
integration within the existing NEAR infrastructure. By
leveraging the power of zero-knowledge proofs, our system
enhances the security and efficiency of block verification
while maintaining the decentralized nature of the
blockchain.</p>
      <sec id="sec-4-1">
        <title>4.1. High-level description of the ZKPbased block finality-proof system</title>
        <p>At its core, our system generates succinct, non-interactive
zero-knowledge proofs (SNARKs) that attest to the validity
and finality of blocks in the NEAR blockchain. The system
operates on a tri-block principle, utilizing data from three
consecutive blocks to generate and verify proofs. This
approach ensures a comprehensive validation of block data,
signatures, and state transitions.</p>
        <p>The proof generation process can be represented by the
following function:</p>
        <p>  GenerateProof (Bi , Bi1, Be, pk) ,
where: Bi is the current block being proven; Bi1 is the
subsequent block; Be is the previous epoch block; pk is
the proving key;  is the resulting zero-knowledge proof.</p>
        <p>The verification process is then represented as:</p>
        <p>0,1  VerifyProof (, vk ) ,
where vk is the verification key, and the output is a boolean
indicating the validity of the proof.</p>
        <p>This high-level structure allows for efficient verification
of block finality without requiring verifiers to process the
entire blockchain history.</p>
      </sec>
      <sec id="sec-4-2">
        <title>4.2. Key components</title>
        <p>Our system comprises four primary components, each
responsible for verifying a critical aspect of block integrity
and consensus:</p>
        <sec id="sec-4-2-1">
          <title>4.2.1. Block hash verification</title>
          <p>This component ensures the integrity of the block data by
verifying the correctness of the block hash. It implements
the SHA-256 hash function within the ZKP circuit, allowing

for efficient proof generation and verification. The process
can be represented as:</p>
          <p> hash  ProveHash(Bi , H (Bi )) ,
where H () is the SHA-256 hash function, and  hash is the
resulting proof.</p>
        </sec>
        <sec id="sec-4-2-2">
          <title>4.2.2. Signature verification</title>
          <p>This component validates the signatures of block producers,
ensuring that the block has been properly approved by
authorized validators. It implements the EdDSA
(Edwardscurve Digital Signature Algorithm) over Curve25519. The
verification process can be expressed as:</p>
          <p> sig  ProveSignature(m, , pk) ,
where m is the message (typically the block hash),  is the
signature, pk is the public key, and  sig is the resulting proof.</p>
        </sec>
        <sec id="sec-4-2-3">
          <title>4.2.3. Validator key and stake verification</title>
          <p>This component verifies that the block signers collectively
represent at least two-thirds of the total stake in the
network, a crucial aspect of NEAR’s consensus mechanism.
The process involves two main steps:</p>
          <p>Proving the existence of validator keys in the
validators list:</p>
          <p> keys  ProveValidKeys(Kv , Ka ) ,
where Kv is the set of all validator keys, and Ka is
the set of actual signers.</p>
          <p>Proving the sufficiency of stakes:</p>
          <p> stakes  ProveStakes(Sv , Sa ,T ) ,
where Sv is the total stake, Sa is the stake of actual
signers, and T is the two-thirds threshold.</p>
        </sec>
        <sec id="sec-4-2-4">
          <title>4.2.4. Next block producer hash verification</title>
          <p>This component ensures the integrity of the validator set for
the upcoming epoch by verifying the correctness of the
next_bp_hash stored in the current block. The process can
be represented as:</p>
          <p> nextbp  ProveNextBP(H (Vnext ), next bphash )
where Vnext is the validator set for the next epoch, and
nextbphash is the hash stored in the current block.</p>
        </sec>
      </sec>
      <sec id="sec-4-3">
        <title>4.3. Integration with NEAR Protocol’s existing infrastructure</title>
        <p>Our ZKP system is designed to seamlessly integrate with
NEAR’s existing blockchain infrastructure, complementing
rather than replacing current validation mechanisms. The
integration occurs at several key points:</p>
        <p>Block Production: During block production, in
addition to standard NEAR block fields, producers
generate ZK proofs for the previous block. These
proofs are included in the new block’s header.</p>
        <p>Block Propagation: When blocks are propagated
through the network, the accompanying ZK proofs
are transmitted alongside block data, allowing for
rapid verification by receiving nodes.</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>5. Zero-knowledge proof construction</title>
      <p>The efficacy of our block finality proof system for the NEAR
Protocol hinges on the robust construction of
zeroknowledge proofs. This section delves into the
cryptographic foundations of our system, detailing the
primitives employed, the design of verification circuits, and
the techniques used for proof aggregation. Our approach
leverages state-of-the-art cryptographic tools to achieve a
balance of security, efficiency, and scalability.</p>
      <sec id="sec-5-1">
        <title>5.1. Cryptographic primitives used</title>
        <p>Our system employs a carefully selected set of cryptographic
primitives, each chosen for its security properties and efficiency
in the context of zero-knowledge proofs.
5.1.1. SHA-256
We utilize the SHA-256 hash function for block hash
verification and in the construction of Merkle trees.
SHA256 is defined as:</p>
        <p>H (m)  SHA-256(m) ,
where m is the input message and H (m) is the resulting
256-bit hash.</p>
        <p>The security of SHA-256 relies on its collision resistance
and preimage resistance properties, making it suitable for
our blockchain application.</p>
        <sec id="sec-5-1-1">
          <title>5.1.2. EdDSA (Edwards-curve Digital Signature</title>
        </sec>
        <sec id="sec-5-1-2">
          <title>Algorithm)</title>
          <p>For signature verification, we implement EdDSA over the
Curve25519 elliptic curve. The EdDSA scheme consists of
three main algorithms:</p>
          <p>Key Generation: (sk, pk )  KeyGen(seed )
Signing:   Sign(sk, m)
Verification: 0,1  Verify( pk, m, ) ,
1.



where sk is the secret key, pk is the public key, m is the
message, and  is the signature.</p>
          <p>EdDSA offers several advantages, including
deterministic signatures, fast single-signature verification,
and small public keys and signatures.</p>
        </sec>
        <sec id="sec-5-1-3">
          <title>5.1.3. Plonky2 framework</title>
          <p>Our implementation is built upon the Plonky2 framework,
which combines the PLONK-proof system with optimized
arithmetization and a custom commitment scheme. Plonky2
provides:</p>
          <p>A universal and updateable structured reference
string (SRS).</p>
          <p>Efficient proof generation and verification.</p>
          <p>Support for recursive proof composition.</p>
          <p>The core of Plonky2 is based on the polynomial
interactive oracle proof (IOP) model, which can be
represented as:</p>
          <p>( , x)  Prove(C, w) , 0,1  Verify(C, x, ) ,
where C is the circuit, w is the witness, x is the public
input, and  is the proof.</p>
        </sec>
      </sec>
      <sec id="sec-5-2">
        <title>5.2. Circuit design for each verification component</title>
        <p>Each component of our system requires a carefully designed
arithmetic circuit to enable efficient zero-knowledge proof
generation:</p>
        <sec id="sec-5-2-1">
          <title>5.2.1. Block hash verification circuit</title>
          <p>The block hash verification circuit implements the SHA-256
algorithm. It consists of:</p>
          <p>Message padding and chunking.</p>
          <p>Initialize hash values and round constants.</p>
          <p>Main compression function (64 rounds).</p>
          <p>Final addition.</p>
          <p>The circuit is optimized to minimize the number of
constraints while maintaining the security properties of
SHA-256.</p>
        </sec>
        <sec id="sec-5-2-2">
          <title>5.2.2. Signature verification circuit</title>
          <p>Our EdDSA verification circuit comprises:</p>
          <p>Point decompression for the public key.</p>
          <p>Scalar multiplication for the signature.</p>
          <p>Point addition and equality check.</p>
          <p>The circuit leverages the properties of the Edwards
curve to optimize computations, particularly in the scalar
multiplication step.</p>
        </sec>
        <sec id="sec-5-2-3">
          <title>5.2.3. Validator key and stake verification circuit</title>
          <p>This circuit consists of two main components:

</p>
          <p>Merkle tree verification for proving key
membership in the validator set.</p>
          <p>Arithmetic circuit for stake summation and
threshold comparison.</p>
          <p>The circuit is designed to efficiently handle varying
numbers of validators while maintaining a fixed circuit size.</p>
        </sec>
        <sec id="sec-5-2-4">
          <title>5.2.4. Next block producer hash verification circuit</title>
          <p>Similar to the block hash verification circuit, this
component implements SHA-256 but is specifically
optimized for the fixed-size input of the validator list hash.</p>
        </sec>
      </sec>
      <sec id="sec-5-3">
        <title>5.3. Proof aggregation techniques</title>
        <p>To enhance the efficiency of our system, we employ several
proof aggregation techniques:</p>
        <sec id="sec-5-3-1">
          <title>5.3.1. Recursive SNARK Composition</title>
          <p>We utilize recursive SNARK composition to aggregate
proofs from different components. This technique allows us
to verify the correctness of multiple sub-proofs within a
single, succinct proof. The recursive composition can be
represented as:</p>
          <p> agg  Aggregate(1, 2,..., n ) ,
where  1, 2,..., n are individual proofs and  agg is the
aggregated proof.</p>
        </sec>
        <sec id="sec-5-3-2">
          <title>5.3.2. Batch verification</title>
          <p>For signature verification, we implement a batch
verification technique that allows multiple signatures to be
verified simultaneously. This approach significantly
reduces the overall computation required for verifying a
large number of signatures.</p>
        </sec>
        <sec id="sec-5-3-3">
          <title>5.3.3. Incremental aggregation</title>
          <p>Our system employs an incremental aggregation approach,
where proofs are combined as they are generated, rather
than all at once. This technique is particularly beneficial for
handling the dynamic nature of blockchain data.</p>
          <p>The incremental aggregation process can be described
as:</p>
          <p> i  Aggregate( i1, new ) ,
where  i1 is the previous aggregate proof,  new is a
newly generated proof, and  i is the updated aggregate
proof.</p>
          <p>By leveraging these advanced cryptographic primitives
and proof aggregation techniques, our system achieves a
high degree of efficiency and scalability while maintaining
strong security guarantees. The carefully designed circuits
and aggregation methods allow for rapid proof generation
and verification, crucial for the real-time demands of the
NEAR Protocol's high-throughput blockchain.</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>6. Performance evaluation</title>
      <p>Our zero-knowledge proof system for block finality in the
NEAR Protocol aims to enhance the efficiency and security
of light clients. This section presents a detailed analysis of
our system's performance based on real-world testing data.</p>
      <sec id="sec-6-1">
        <title>6.1. Experimental setup and methodology</title>
        <p>Our experiments were conducted on a dedicated server with
the following specifications:




</p>
        <p>CPU: AMD Ryzen 9 7950X 16-Core Processor.</p>
        <p>Clock Speed: 4.7 GHz (base frequency: 4.5 GHz,
max boost: 5.7 GHz).</p>
        <p>RAM: 64 GB DDR4.</p>
        <p>Storage: 1 TB NVMe SSD.</p>
        <p>Operating System: Ubuntu 20.04 LTS.</p>
        <p>We implemented our system using the Rust
programming language, leveraging the Plonky2 framework
for zero-knowledge proof generation and verification. Our
evaluation focused on four consecutive blocks from the
NEAR blockchain, chosen to represent typical network
activity.</p>
      </sec>
      <sec id="sec-6-2">
        <title>6.2. Results and analysis</title>
        <p>Our experimental results provide comprehensive insights
into the performance characteristics of our zero-knowledge
proof system for block finality in the NEAR Protocol. We
analyze each component individually to understand its
contribution to the overall system performance.</p>
        <sec id="sec-6-2-1">
          <title>6.2.1. Block hash verification performance</title>
          <p>The data reveals several important trends:</p>
          <p>Scalability: The circuit generation time and proof
generation time exhibit a near-linear relationship
with block size. This scalability is crucial for
handling the varying block sizes typical in
blockchain networks.</p>
          <p>Verification efficiency: Remarkably, the proof
verification time remains consistently low
(approximately 4 milliseconds) across all block
sizes. This consistency is particularly
advantageous for light clients, as it ensures rapid
verification regardless of block complexity.</p>
          <p>Circuit complexity: The number of gates in the
circuit grows with block size, reflecting the
increased computational requirements for larger
blocks. However, this growth is sublinear,
indicating efficient circuit design.</p>
          <p>Proof size stability: The proof size remains
constant at 165,684 bytes for most blocks, with
only a slight increase to 180,112 bytes for the
largest block. This stability is beneficial for
network bandwidth considerations and storage
requirements in light clients.</p>
          <p>These results demonstrate that our block hash
verification component achieves a balance between
scalability and efficiency, particularly in the critical aspect
of proof verification time.</p>
        </sec>
        <sec id="sec-6-2-2">
          <title>6.2.2. Signature verification performance</title>
          <p>Consistency in proof generation: Despite
variations in block size and, presumably, the
number of signatures, the proof generation time
remains remarkably consistent, ranging from
13.11 to 13.41 seconds. This consistency suggests
that our system efficiently handles varying
numbers of signatures without significant
performance degradation.</p>
          <p>Rapid verification: The proof verification times are
consistently low, ranging from 4.6 to 5.1
milliseconds. This speed is crucial for light clients,
enabling rapid confirmation of signature validity.
Proof size uniformity: The aggregated proof size
remains constant at 133,080 bytes across all tested
blocks. This uniformity is advantageous for
predictable network bandwidth usage and storage
requirements in light clients.</p>
          <p>Circuit generation variability: The circuit
generation time shows some variation (11.55 to
14.40 seconds), likely due to differences in the
complexity of signature data across blocks.
However, this one-time cost does not impact the
efficiency of subsequent proof verifications.







The performance characteristics of our signature
verification component indicate its suitability for
highthroughput blockchain systems, particularly in scenarios
requiring frequent and rapid signature validations by light
clients.</p>
        </sec>
        <sec id="sec-6-2-3">
          <title>6.2.3. Validator key and stake verification performance</title>
          <p>The validator key and stake verification component
demonstrates efficient performance across various
operations:


</p>
          <p>Stake computation efficiency: The process of
computing all stakes and checking the two-thirds
threshold collectively accounts for approximately
0.0533 seconds, demonstrating the efficiency of
our stake verification mechanism.</p>
          <p>Circuit building overhead: The time to build the
circuit (0.0341 seconds) is comparable to the proof
generation time (0.0588 seconds), indicating a
well-balanced implementation.</p>
          <p>Overall efficiency: The total time for validator key
and stake verification is approximately 0.1691
seconds, which is relatively low considering the
complexity of the operations involved.
These results suggest that our system can efficiently handle
the critical task of validator set verification, an essential
component for maintaining the security of the consensus
mechanism in proof-of-stake blockchains.</p>
        </sec>
        <sec id="sec-6-2-4">
          <title>6.2.4. Next block producer hash verification performance</title>
          <p>Consistency: The total processing time shows
remarkable consistency across different blocks,
ranging from 20.5532 to 21.1767 seconds. This
consistency is crucial for predictable performance
in the NEAR Protocol.</p>
          <p>Efficient verification: Despite the relatively long
proof generation times, the verification times are
exceptionally low, consistently around 4.5
milliseconds. This efficiency is particularly
beneficial for light clients, allowing for rapid
verification of the next block producer set.</p>
          <p>Proof size stability: The proof size remains
constant at 180,112 bytes across all tested blocks,
which is advantageous for network bandwidth
considerations and storage requirements.</p>
          <p>Component breakdown: The circuit building
phase consistently accounts for the largest portion
of the total time (approximately 60–63%), followed
by proof generation (40–41%), with SHA256
hashing and proof verification taking significantly
less time.</p>
          <p>These results demonstrate that our next block producer
hash verification component provides a robust and efficient
mechanism for ensuring the integrity of validator set
transitions, a critical aspect of maintaining long-term
blockchain security.</p>
        </sec>
        <sec id="sec-6-2-5">
          <title>6.2.5. Proof aggregation and final block verification performance</title>
          <p>The analysis of this data yields several important insights:</p>
          <p>Dominance of full aggregation: The full
aggregation process, which includes proving
signatures, aggregating them, generating
recursive proofs, and proving valid keys and
stakes, consistently accounts for the vast majority
of the total time (95–96%). This indicates that
optimizing this step could significantly improve
overall system performance.</p>
          <p>Consistency in other components: The time
required for hash proof, next BP hash proof, and
various aggregation steps remain relatively
consistent across different blocks, contributing to
predictable system behavior.</p>
          <p>Rapid final aggregation: The final aggregation
step, crucial for light client verification,
consistently takes less than 0.5 seconds. This
efficiency is key to enabling quick block finality
confirmation for light clients.</p>
          <p>Total processing time: The total proof generation
time ranges from about 806 to 1073 seconds
(approximately 13 to 18 minutes). While this may
seem substantial, it’s important to note that this
process is performed by full nodes and does not
affect the verification speed for light clients.</p>
          <p>Scalability considerations: The variation in total
processing time across different blocks suggests
that the system’s performance scales with block
complexity. However, the consistent final
aggregation time indicates that this scaling does
not significantly impact light client performance.</p>
          <p>These results demonstrate that our proof aggregation
and final block verification component effectively
consolidates the various proofs into a single, efficiently
verifiable proof, thereby enabling rapid block finality
confirmation for light clients while maintaining the security
guarantees of the underlying zero-knowledge proof system.</p>
        </sec>
      </sec>
      <sec id="sec-6-3">
        <title>6.3. Comparison with existing solutions</title>
        <p>When comparing our system to the native NEAR block
verification process, we focus on the benefits for light
clients:</p>
        <p>Verification time: Our system allows light clients
to verify blocks in about 0.47 seconds, regardless
of block complexity. This is a significant
improvement over traditional light client
verification, which may require multiple network
round-trips and processing of block headers.</p>
        <p>Data transfer: Our system requires transferring
only a constant-size proof (180,112 bytes) to light
clients, regardless of block size or transaction
count. This is substantially less than transferring
full block data or even compressed block headers.
Security guarantees: Our ZKP system provides
cryptographic assurance of block validity, offering
stronger security guarantees compared to
traditional light client verification methods that
may rely on assumptions about the network’s
honest majority.</p>
        <p>Computational requirements: While our proof
generation is computationally intensive (13–18
minutes per block), this is performed by full nodes.
Light clients only need to perform the much faster
verification step (&lt;0.5 seconds), making our
system viable even for resource-constrained
devices.




</p>
        <p>In conclusion, our ZKP-based system significantly
reduces the computational and bandwidth requirements for
light clients in the NEAR ecosystem, while enhancing
security guarantees. The trade-off of increased block
production time is outweighed by the benefits in light client
efficiency and the potential for broader blockchain
accessibility.</p>
      </sec>
    </sec>
    <sec id="sec-7">
      <title>7. Discussion</title>
      <p>The implementation and evaluation of our zero-knowledge
proof system for block finality in the NEAR Protocol offer
significant insights into the future of blockchain security
and scalability. This section discusses the broader
implications of our work, explores potential applications in
other cybersecurity domains, and addresses limitations
while outlining future research directions.</p>
      <sec id="sec-7-1">
        <title>7.1. Implications for blockchain security and scalability</title>
        <p>Our ZKP-based system demonstrates a promising approach
to enhancing both the security and scalability of blockchain
networks, particularly for light clients. The key implications
include:






</p>
      </sec>
      <sec id="sec-7-2">
        <title>7.2. Potential applications in other cybersecurity domains</title>
        <p>The principles and techniques developed in our ZKP system
have potential applications beyond blockchain technology:
Improved scalability: The constant-size proofs and
rapid verification times enable light clients to
efficiently validate the blockchain state without
downloading and processing the entire chain. This
capability could dramatically increase the number
of participants in blockchain networks without
compromising decentralization.</p>
        <p>Cross-chain interoperability: The succinct nature
of our ZKP system could facilitate more efficient
and secure cross-chain communication,
potentially accelerating the development of
interoperable blockchain ecosystems.</p>
        <p>Reduced network overhead: By minimizing the
data transfer required for block verification, our
system could contribute to reduced network
congestion and improved overall network
efficiency in blockchain systems.</p>
        <p>Secure multiparty computation: Our approach to
efficient proof aggregation could be adapted to
enhance the performance and privacy of secure
multiparty computation protocols in various
cybersecurity applications.</p>
        <p>Privacy-preserving authentication: The
zeroknowledge properties of our system could be
leveraged to develop more robust and
privacypreserving authentication mechanisms for
sensitive cybersecurity systems.</p>
        <p>Verifiable computing: The techniques used in our
block verification system could be extended to
create efficient verification mechanisms for
outsourced computation in cloud computing
environments.</p>
        <p>Secure software updates: Our ZKP system could be
adapted to provide verifiable proof of the integrity
and authenticity of software updates, enhancing
security in software distribution systems.</p>
        <p>Enhanced light client security: By providing
succinct, verifiable proof of block validity, our
system significantly reduces the trust assumptions
required for light clients. This enhancement could
lead to more secure and reliable mobile and IoT
applications in the blockchain ecosystem.
While our system demonstrates promising results, several
limitations and areas for future work remain:</p>
        <p>Proof generation time: The substantial time
required for proof generation (13–18 minutes per
block) could pose challenges for real-time block
production. Future work should focus on
optimizing this process, possibly through parallel
computation or more efficient cryptographic
constructions.</p>
        <p>Hardware requirements: The current
implementation requires significant
computational resources for proof generation.
Research into hardware acceleration techniques
could make the system more accessible to a
broader range of network participants.</p>
        <p>Post-quantum security: While our system provides
strong security guarantees under current
cryptographic assumptions, it is not yet
postquantum secure. Investigating post-quantum ZKP
schemes is a crucial area for future research.</p>
        <p>Dynamic sharding support: As NEAR Protocol
moves towards dynamic sharding, our system will
need to be adapted to efficiently handle
crossshard transactions and state transitions.</p>
        <p>Formal verification: Developing formal proofs of
the security properties of our ZKP system would
provide stronger guarantees and increase
confidence in its deployment in critical blockchain
infrastructure.</p>
      </sec>
    </sec>
    <sec id="sec-8">
      <title>8. Conclusions</title>
      <p>This paper presents a novel zero-knowledge proof system
for block finality in the NEAR Protocol, making several key
contributions to the field of blockchain security and
scalability:</p>
      <p>We developed a comprehensive ZKP-based
verification system that encompasses block hash,
signature, validator key and stake, and next block
producer hash verification.</p>
      <p>Our system achieves constant-time verification for
light clients, regardless of block size or complexity,
significantly enhancing the efficiency and security
of light client operations.</p>
      <p>We demonstrated the feasibility of using advanced
cryptographic techniques, including the Plonky2
framework, to create practical ZKP systems for
high-throughput blockchain networks.</p>
      <p>Our performance evaluation provides valuable
insights into the scalability and efficiency of ZKP
systems in real-world blockchain environments.
We anticipate increased adoption of ZKP
techniques in mainstream blockchain protocols,
driven by the growing need for scalability and
privacy in decentralized systems.</p>
      <p>Future research is likely to focus on reducing proof
generation times and hardware requirements,
making ZKP systems more accessible and practical
for a wider range of blockchain applications.</p>
      <p>The integration of post-quantum cryptographic
techniques with ZKP systems will become
increasingly important as quantum computing
advances threaten traditional cryptographic
assumptions.</p>
      <p>Cross-chain interoperability solutions based on
ZKP systems are poised to play a crucial role in the
development of a more interconnected and
efficient blockchain ecosystem.
blockchain security and scalability. As the field continues to
evolve, ZKP-based systems are set to become an integral
component of next-generation blockchain architectures,
enabling more secure, scalable, and privacy-preserving
decentralized systems.
The development and successful implementation of our ZKP
system for the NEAR Protocol point to a promising future
for ZKP-based security in blockchain systems:</p>
      <p>In conclusion, our work demonstrates the potential of
zero-knowledge proofs to address critical challenges in</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>H.</given-names>
            <surname>Singh</surname>
          </string-name>
          ,
          <article-title>Chapter 1</article-title>
          .
          <string-name>
            <surname>Decentralized</surname>
            <given-names>Web</given-names>
          </string-name>
          , Distributed Ledgers, and
          <article-title>Build-up to</article-title>
          <string-name>
            <surname>Blockchain</surname>
          </string-name>
          , Distributed Computing to Blockchain, Academic Press (
          <year>2023</year>
          )
          <fpage>3</fpage>
          -
          <lpage>17</lpage>
          . doi:
          <volume>10</volume>
          .1016/B978-0
          <source>-323-96146-2</source>
          .
          <fpage>00004</fpage>
          -
          <lpage>8</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <surname>NEAR</surname>
          </string-name>
          , Blockchains, Abstracted, (n. d.). URL: https://near.org/
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>V.</given-names>
            <surname>Zhebka</surname>
          </string-name>
          , et al.,
          <article-title>Methodology for Choosing a Consensus Algorithm for Blockchain Technology</article-title>
          ,
          <source>in: Digital Economy Concepts and Technologies</source>
          , vol.
          <volume>3665</volume>
          (
          <year>2024</year>
          )
          <fpage>106</fpage>
          -
          <lpage>113</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>Sharding</given-names>
            <surname>Design</surname>
          </string-name>
          : Nightshade, NEAR Protocol (
          <year>2023</year>
          ). URL: https://near.org/papers/nightshade/
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>K.</given-names>
            <surname>Kuznetsova</surname>
          </string-name>
          , et al.,
          <source>Solving Blockchain Scalability Problem Using ZK-SNARK, Advances in Artificial Systems for Logistics Engineering III</source>
          , Springer Nature Switzerland,
          <string-name>
            <surname>Cham</surname>
          </string-name>
          (
          <year>2023</year>
          )
          <fpage>360</fpage>
          -
          <lpage>371</lpage>
          . doi:
          <volume>10</volume>
          .1007/978-3-
          <fpage>031</fpage>
          -36115-9_
          <fpage>33</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>O.</given-names>
            <surname>Kuznetsov</surname>
          </string-name>
          , et al.,
          <article-title>Implementing Recursive Proofs for Efficient Blockchain Verification: A zk-SNARKs Approach</article-title>
          ,
          <source>Mathematical Modeling and Simulation of Systems</source>
          , Springer Nature Switzerland,
          <string-name>
            <surname>Cham</surname>
          </string-name>
          (
          <year>2024</year>
          )
          <fpage>266</fpage>
          -
          <lpage>280</lpage>
          . doi:
          <volume>10</volume>
          .1007/978-3-
          <fpage>031</fpage>
          -67348-1_
          <fpage>20</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>O.</given-names>
            <surname>Kuznetsov</surname>
          </string-name>
          , et al.,
          <article-title>Enhanced Security and Efficiency in Blockchain with Aggregated Zero-Knowledge Proof Mechanisms</article-title>
          ,
          <source>IEEE Access 12</source>
          (
          <year>2024</year>
          )
          <fpage>49228</fpage>
          -
          <lpage>49248</lpage>
          . doi:
          <volume>10</volume>
          .1109/ACCESS.
          <year>2024</year>
          .
          <volume>3384705</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>M. H.</given-names>
            <surname>Nasir</surname>
          </string-name>
          , et al.,
          <string-name>
            <surname>Scalable</surname>
            <given-names>Blockchains-A Systematic</given-names>
          </string-name>
          <string-name>
            <surname>Review</surname>
          </string-name>
          ,
          <source>Future Generation Comput. Syst</source>
          .
          <volume>126</volume>
          (
          <year>2022</year>
          )
          <fpage>136</fpage>
          -
          <lpage>162</lpage>
          . doi:
          <volume>10</volume>
          .1016/j.future.
          <year>2021</year>
          .
          <volume>07</volume>
          .035.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>C.</given-names>
            <surname>Lin</surname>
          </string-name>
          , et al.,
          <source>Rapido: Scaling Blockchain with Multipath Payment Channels, Neurocomputing</source>
          <volume>406</volume>
          (
          <year>2020</year>
          )
          <fpage>322</fpage>
          -
          <lpage>332</lpage>
          . doi:
          <volume>10</volume>
          .1016/j.neucom.
          <year>2019</year>
          .
          <volume>09</volume>
          .114.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>Y.</given-names>
            <surname>Li</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Wang</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Zhang</surname>
          </string-name>
          ,
          <article-title>A survey of state-of-the-art sharding blockchains: Models, components, and attack surfaces</article-title>
          ,
          <source>J. Netw. Comput. Appl</source>
          .
          <volume>217</volume>
          (
          <year>2023</year>
          )
          <article-title>103686</article-title>
          . doi:
          <volume>10</volume>
          .1016/j.jnca.
          <year>2023</year>
          .
          <volume>103686</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>M. T. de Oliveira</surname>
          </string-name>
          , et al.,
          <article-title>Blockchain Reputation-based Consensus: A Scalable and Resilient Mechanism for Distributed Mistrusting Applications</article-title>
          , Comput. Netw.
          <volume>179</volume>
          (
          <year>2020</year>
          )
          <article-title>107367</article-title>
          . doi:
          <volume>10</volume>
          .1016/j.comnet.
          <year>2020</year>
          .
          <volume>107367</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>A.</given-names>
            <surname>Meeuw</surname>
          </string-name>
          , et al.,
          <source>Implementing a Blockchain-based Local Energy Market: Insights on Communication and Scalability, Comput. Commun</source>
          .
          <volume>160</volume>
          (
          <year>2020</year>
          )
          <fpage>158</fpage>
          -
          <lpage>171</lpage>
          . doi:
          <volume>10</volume>
          .1016/j.comcom.
          <year>2020</year>
          .
          <volume>04</volume>
          .038.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <given-names>N.</given-names>
            <surname>Gawande</surname>
          </string-name>
          , et al.,
          <source>Towards Scaling Community Detection on Distributed-Memory Heterogeneous Systems, Parallel Computing</source>
          <volume>111</volume>
          (
          <year>2022</year>
          )
          <article-title>102898</article-title>
          . doi:
          <volume>10</volume>
          .1016/j.parco.
          <year>2022</year>
          .
          <volume>102898</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>P.</given-names>
            <surname>Otte</surname>
          </string-name>
          , M. de Vos, J. Pouwelse,
          <string-name>
            <surname>TrustChain: A SybilResistant Scalable</surname>
            <given-names>Blockchain</given-names>
          </string-name>
          ,
          <source>Future Generation Computer Systems</source>
          <volume>107</volume>
          (
          <year>2020</year>
          )
          <fpage>770</fpage>
          -
          <lpage>780</lpage>
          . doi:
          <volume>10</volume>
          .1016/j.future.
          <year>2017</year>
          .
          <volume>08</volume>
          .048.
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <given-names>Z.</given-names>
            <surname>Li</surname>
          </string-name>
          ,
          <string-name>
            <surname>J. Zhang</surname>
          </string-name>
          ,
          <article-title>Data-oriented Distributed Overall Optimization for Large-Scale HVAC Systems with Dynamic Supply Capability and Distributed Demand Response</article-title>
          ,
          <source>Building and Environment</source>
          <volume>221</volume>
          (
          <year>2022</year>
          )
          <article-title>109322</article-title>
          . doi:
          <volume>10</volume>
          .1016/j.buildenv.
          <year>2022</year>
          .
          <volume>109322</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <given-names>H.</given-names>
            <surname>Rawhouser</surname>
          </string-name>
          , et al.,
          <string-name>
            <surname>Scaling</surname>
          </string-name>
          , Blockchain Technology, and
          <article-title>Entrepreneurial Opportunities in Developing Countries</article-title>
          ,
          <source>Journal of Business Venturing Insights</source>
          <volume>18</volume>
          (
          <year>2022</year>
          )
          <article-title>e00325</article-title>
          . doi:
          <volume>10</volume>
          .1016/j.jbvi.
          <year>2022</year>
          .e00325.
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <given-names>S.</given-names>
            <surname>Goldwasser</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Micali</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Rackoff</surname>
          </string-name>
          ,
          <article-title>The Knowledge Complexity of Interactive Proof-Systems</article-title>
          ,
          <source>in: 17th Annual ACM Symposium on Theory of Computing</source>
          , Association for Computing Machinery (
          <year>1985</year>
          )
          <fpage>291</fpage>
          -
          <lpage>304</lpage>
          . doi:
          <volume>10</volume>
          .1145/22145.22178.
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <given-names>U.</given-names>
            <surname>Feige</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Fiat</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Shamir</surname>
          </string-name>
          ,
          <article-title>Zero-Knowledge Proofs of Identity</article-title>
          ,
          <source>J. Cryptology</source>
          <volume>1</volume>
          (
          <year>1988</year>
          )
          <fpage>77</fpage>
          -
          <lpage>94</lpage>
          . doi:
          <volume>10</volume>
          .1007/BF02351717.
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <given-names>A.</given-names>
            <surname>Fiat</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Shamir</surname>
          </string-name>
          , How to Prove Yourself:
          <article-title>Practical Solutions to Identification and Signature Problems, Advances in Cryptology (CRYPTO'86)</article-title>
          ,
          <source>SpringerVerlag</source>
          (
          <year>1987</year>
          )
          <fpage>186</fpage>
          -
          <lpage>194</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [20]
          <string-name>
            <given-names>E.</given-names>
            <surname>Ben-Sasson</surname>
          </string-name>
          , et al.,
          <article-title>SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge, Advances in Cryptology (CRYPTO) (</article-title>
          <year>2013</year>
          )
          <fpage>90</fpage>
          -
          <lpage>108</lpage>
          . doi:
          <volume>10</volume>
          .1007/978-3-
          <fpage>642</fpage>
          -40084-
          <issue>1</issue>
          _
          <fpage>6</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          [21]
          <string-name>
            <given-names>N.</given-names>
            <surname>Bitansky</surname>
          </string-name>
          , et al.,
          <article-title>Recursive Composition and Bootstrapping for SNARKS and Proof-Carrying Data</article-title>
          ,
          <source>in: 45th Annual ACM Symposium on Theory of Computing</source>
          , Association for Computing Machinery (
          <year>2013</year>
          )
          <fpage>111</fpage>
          -
          <lpage>120</lpage>
          . doi:
          <volume>10</volume>
          .1145/2488608.2488623.
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          [22]
          <string-name>
            <given-names>D.</given-names>
            <surname>Hopwood</surname>
          </string-name>
          , et al.,
          <source>Zcash Protocol Specification</source>
          ,
          <year>Version 2022</year>
          .
          <volume>3</volume>
          .8 [NU5] (
          <year>2022</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          [23]
          <string-name>
            <surname>Privacy-Protecting Digital</surname>
            <given-names>Currency</given-names>
          </string-name>
          ,
          <source>Zcash (n. d.)</source>
          . URL: https://z.cash/
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          [24]
          <string-name>
            <given-names>N.</given-names>
            <surname>Ariffin</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A. Z.</given-names>
            <surname>Ismail</surname>
          </string-name>
          ,
          <article-title>The Design and Implementation of Trade Finance Application based on Hyperledger Fabric Permissioned Blockchain Platform</article-title>
          ,
          <source>International Seminar on Research of Information Technology and Intelligent Systems (ISRITI)</source>
          (
          <year>2019</year>
          )
          <fpage>488</fpage>
          -
          <lpage>493</lpage>
          . doi:
          <volume>10</volume>
          .1109/ISRITI48646.
          <year>2019</year>
          .
          <volume>9034576</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          [25]
          <string-name>
            <given-names>Y. N.</given-names>
            <surname>Patil</surname>
          </string-name>
          , et al.,
          <string-name>
            <given-names>A</given-names>
            <surname>Decentralized</surname>
          </string-name>
          and Autonomous Model to Administer University Examinations,
          <source>Blockchain Technology for IoT Applications</source>
          , Springer (
          <year>2021</year>
          )
          <fpage>119</fpage>
          -
          <lpage>134</lpage>
          . doi:
          <volume>10</volume>
          .1007/
          <fpage>978</fpage>
          -981-33-4122-
          <issue>7</issue>
          _
          <fpage>6</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          [26] StarkWare, STARK Math:
          <article-title>The Journey Begins</article-title>
          ,
          <source>StarkWare</source>
          (
          <year>2020</year>
          ). URL: https://medium.com/ starkware/stark-math
          <article-title>-the-journey-begins51bd2b063c71</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          [27]
          <string-name>
            <surname>StarkWare</surname>
          </string-name>
          ,
          <string-name>
            <surname>Recursive</surname>
            <given-names>STARKs</given-names>
          </string-name>
          ,
          <source>StarkWare</source>
          (
          <year>2022</year>
          ). URL: https://medium.com/starkware/recursivestarks-78f8dd401025
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          [28]
          <string-name>
            <surname>Introducing</surname>
          </string-name>
          <article-title>Plonky2 (n</article-title>
          . d.). URL: https://polygon.technology/blog/introducingplonky2
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          [29]
          <article-title>mir-protocol/plonky2 (n</article-title>
          . d.). URL: https://github.com/mir-protocol/plonky2/tree/main
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          [30]
          <article-title>Plonky2: Fast Recursive Arguments with PLONK and FRI (</article-title>
          <year>2023</year>
          ). URL: https://github.com/mirprotocol/plonky2/blob/main/plonky2/plonky2.pdf
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>