Conceptio › Archive › arXiv CS
arXiv CSopen access

TS-Verkle: A TypeScript Native Verkle Library With On-chain Verifier

2026 · arxiv_cs
arXiv CS · Papers · License: Open Access · 2026
Open Source ↗Direct PDF ↓
clouddistributed-computingparallel-computing
distributed computing, parallel computing, cloud

TS-Verkle: A TypeScript Native Verkle Library With On-chain Verifier Zhikai Li∗ , Xuekai Liu∗ Boyuan Xu, Eric Chen, and Bhaskar Krishnamachari

arXiv:2605.08682v1 [cs.DC] 9 May 2026

Viterbi School of Engineering, University of Southern California, Los Angeles, USA {leol, xuekailiu, boyuanxu, ericsc, bkrishna}@usc.edu

Abstract—Blockchain systems face significant scalability challenges due to growing data volumes and increasing transaction demands, necessitating more efficient data structures and verification mechanisms. Verkle trees, a novel data structure combining the efficiency of Merkle trees with the compactness of vector commitments, have gained attention for their potential to optimize blockchain storage and improve scalability. However, their practical implementation, especially at the smart contract level, has remained unexplored. To address these challenges, we present TS-verkle, the first known TypeScriptnative implementation of Verkle trees designed for web3 backend compatibility, coupled with a corresponding on-chain verifier written in Solidity. Our work bridges this gap by providing a concrete implementation of Verkle trees and demonstrating their feasibility for on-chain verification. While previous literature suggests Verkle trees should outperform Merkle trees due to their succinct proof size, our empirical evaluation reveals that basic implementations of Verkle trees actually incur higher costs than Merkle trees without advanced optimization techniques. This finding represents a crucial insight for blockchain developers and researchers considering Verkle tree adoption. The paper discusses implementation strategies and performance characteristics while exploring implications for scaling and data availability in decentralized blockchain systems. Index Terms—Blockchain, Smart Contracts, Merkle Tree, Verkle Tree

I. I NTRODUCTION Data integrity and validation in distributed systems have become increasingly critical challenges in modern computing. The Merkle tree, proposed by Ralph C. Merkle in 1979, emerged as a fundamental data structure addressing these challenges through its innovative approach to data verification [1]. Built upon the foundation of binary search trees, Merkle trees extend traditional tree properties by incorporating hash values at each node: non-leaf nodes contain the hash of their children, while leaf nodes store the hash of their corresponding data [2] [3]. This structure makes it possible to verify whether a leaf is part of the tree without leaking any other data except the hash value. Bitcoin, introduced by Satoshi Nakamoto in 2008, demonstrates an important application of Merkle trees. In the Bitcoin system, transactions are stored in Merkle trees, allowing block headers to contain just the root hash value to verify transactions. This approach eliminates the need to store large amounts of transaction data while maintaining verification capabilities. A detailed explanation of the verification in the Merkle tree can be found in [3] [4] [5]. *These authors contributed equally to this work.

However, despite their efficient proof mechanism using hashes instead of complete information, Merkle trees face a significant limitation: proof size scalability. Merkle tree proofs need nodes at every level, making the proof size dependent on the tree’s depth. For a standard binary Merkle tree containing n blocks of information, the proof size is O(log2 n). For example, a Merkle tree with a depth of just 30 requires about 1 kilobyte of proof data using SHA-256. This limitation has become particularly challenging with the growth of networks like Ethereum, where verifying on-chain data grows increasingly complex. Therefore, reducing the proof size of the Merkle tree becomes an important way to enhance the scalability of the blockchain system. Early attempts at optimization, such as creating k-ary Merkle trees to reduce the number of layers, actually increased proof sizes from O(log2 n) to O(k logk n). Researchers have proposed various solutions: Ayyalasomayajula and Ramkumar proved that SubTree implementation works better than LinearTree for large relational databases [6], while Mizrahi et al. developed a traffic-aware Merkle tree that organizes data based on transaction patterns to reduce average proof length [7]. Verkle tree emerges as a new data structure that significantly reduces proof sizes. The core idea is to use vector commitments instead of hash functions in k-ary Merkle trees, greatly reducing the size of proofs and making trade-offs between efficiency [8]. Specifically, in Merkle trees, the parent node is the hash value of its child nodes, while in Verkle trees, it is the vector commitment of its child nodes. Thus, the Verkle tree only needs to provide the path and minimal additional information for verification, shown in figure 1, eliminating the need for same-level nodes, which greatly reduces the proof size to O(logk n). Currently, Verkle tree has been applied to tasks such as post-quantum digital signatures [9], file verification systems [10], reducing block incentive volatility [11], and protecting distributed system logs [12]. Despite these advances, there remains a notable gap in research regarding the feasibility of replacing Merkle trees with Verkle trees in on-chain applications, particularly at the smart contract level. To address this gap, we propose TS-Verkle1 , a TypeScript library for implementing on-chain verifiers based on Verkle trees. The following will detail the TypeScript implementation of the Verkle tree structure and the smart contract that performs on-chain proof verification. We 1 Github link will be released upon acceptance

3) Python implementation: Python’s verkle-trie-ref [15] serves primarily for prototyping and research. It benefits from extensive library support, including py ecc for elliptic curve operations and numpy for polynomial processing, making it valuable for theoretical validation. B. Polynomial Commitment(PC) Mechanisms

Fig. 1. A 3-ary Merkle tree (above) and a 3-ary Verkle tree (below), with proofs highlighted in yellow

hope that this library will further promote the application of Verkle trees in on-chain verification and provide a reference to improve the scalability of blockchain systems. Our contributions can be summarized as follows: • We introduce the first known TypeScript Native Verkle Tree library with on-chain verifier • We provide experimental results on Merkle Tree vs Verkle Tree on-chain verification gas cost • We introduce Ethereum Gas Cost Equations dependent on various Verkle Tree and Merkle Tree configurations • We empirically demonstrate that Verkle trees incur higher gas costs, contradicting prior theoretical efficiency assumptions. II. R ELATED W ORK This section examines existing Verkle tree implementations and analyzes the polynomial commitment mechanisms that enable Verkle trees’ functionality.

Polynomial commitments (PC) are often used as a vector commitment mechanism for Verkle trees. PC schemes enable a prover to commit to a polynomial f (x) and then provide a succinct proof that the polynomial evaluates to the claimed value y at a given point x = z. In a Verkle tree, nodes are represented as vector v = [v1 , v2 , ..., vn ] and encoded as a polynomial f (x). Commitments are made to vectors using polynomial commitments. Two widely used PC schemes are KZG commitments and Inner Product Arguments (IPA). 1) KZG Polynomial Commitments: The KZG commitment scheme, named after Kate, Zaverucha, and Goldberg, is a popular PC mechanism for Verkle tree [16]. It’s security relies on elliptic curve pairings. The size of KZG proofs is constant and independent of the polynomial degree. KZG is favored by blockchain systems such as Ethereum proto-danksharding (EIP-4844) due to its efficiency and simplicity. There are already open-source KZG libraries based on TypeScript, such as libkzg [17]. 2) Inner Product Argument (IPA) Commitments: IPA-based commitments use recursive inner products to achieve succinctness [18]. It does not require a trusted setup, relying instead on discrete logarithm assumptions. So, the proof size is dependent on the polynomial degree. Generating proofs in IPA involves multiple recursive computations, making it computationally expensive compared to KZG. It is often chosen for systems that prioritize transparency and trustlessness, such as zeroknowledge proof protocols. More comparisons of KZG and IPA are shown in Table I. In our TypeScript implementation, we focus on KZG commitments due to their efficiency and simplicity for practical Verkle tree use cases.

A. Verkle Tree Implementations Current Verkle tree implementations span a variety of programming languages, each suitable for different applications, but no project has compared both Merkle trees and Verkle trees. Notably, no language includes an on-chain validator. Our TS-Verkle implements on-chain integration, solves the onchain verification gap, and provides a side-by-side comparison between Merkle trees and Verkle trees. 1) Rust implementation: Rust implementation rust-verkle [13] leverages the language’s safety guarantees and performance optimizations. Its low-level memory management capabilities and fast cryptographic libraries optimize polynomial commitments and curve algorithms. 2) Golang implementation: The Ethereum community’s go-verkle [14] exemplifies Go’s focus on simplicity and concurrency for blockchain nodes. While offering native concurrency support, Go’s garbage collection creates minor performance tradeoffs compared to Rust implementations.

TABLE I KZG VS . IPA KZG Elliptic Curve Pairings Trusted Setup Required No Yes O(1) O(1) O(n)

Basic Tech Setup Requirements Transparent Succinct Proof Size Verify Time Prove Time

IPA Discrete Logarithm No Trusted Setup Yes No O(log n) O(log n) O(n)

III. I MPLEMENTATION The design of TS-Verkle has two major components: the local Verkle tree and the corresponding onchain verifier. A. Local Verkle Tree Our Verkle tree implementation follows a modular architecture with two primary node types: internal nodes and leaf

internal node proofs and leaf proofs as the local verifier. This ensures that any proof generated by the local Verkle tree can be efficiently verified within the constraints of the Ethereum Virtual Machine. IV. E XPERIMENTS The experimental framework was structured in two phases: local tree construction and on-chain verification. Our methodology aimed to compare the performance characteristics of Verkle trees against traditional Merkle Trees, specifically utilizing the widely-audited OpenZeppelin implementation as our baseline. A. Local Tree Construction Fig. 2. Verkle and Merkle Tree gas cost in respect to tree capacity

nodes. Each internal node maintains a mapping of up to 256 child nodes, while leaf nodes store the actual values. The implementation leverages the libkzg library [17] for polynomial commitment operations, specifically for generating and verifying single-point proofs. The core functionality is encapsulated in a VerkleTree class that handles recursive tree traversal, node insertion, and proof generation. Each node implements a common interface that includes methods for commitment generation (commit()), proof generation (getProof()), and value retrieval (get()). For proof generation, the implementation traverses the path from root to leaf, collecting necessary commitments and generating proofs at each level using KZG polynomial commitments. A Verkle proof consists of several components: i n t e r f a c e VerkleProof { stem : Uint8Array ; l e a f I n d e x : number ; i n d i c e s : number [ ] ; i n t e r n a l P r o o f s : Proof [ ] ; i n t e r n a l C h i l d C o m m i t m e n t s : Commitment [ ] ; l e a f Pr o o f : Proof ; }

The proof structure enables efficient verification by providing all necessary components: the stem-index structure for path representation, where each key is split into a stem portion (determining the path through internal nodes) and a leaf index (identifying the specific value within a leaf node). The verification process recursively validates these proofs by checking the KZG commitments at each level, ensuring the integrity of the path from the root commitment to the claimed value at the leaf node. B. On-chain Verifier The on-chain verifier implements the verification logic in Solidity, following the same mathematical principles as the local verification process. It takes a Verkle proof as input and validates the path from root to leaf by verifying the KZG polynomial commitments at each level. The implementation leverages precompiled contracts for efficient elliptic curve operations and performs the same recursive validation of

Our experimental setup focused on comparing the efficiency of Verkle trees against OpenZeppelin’s Merkle Tree implementation in managing sets of Ethereum addresses. We constructed trees of varying sizes, ranging from small sets of 23 (8) addresses to larger sets of 220 (1048576) addresses. The local construction phase involved building both types of trees and generating membership proofs for random addresses within the set. The Merkle Tree implementation followed OpenZeppelin’s standard binary tree structure. Since Verkle tree proof size is independent of the branching factor, our Verkle tree implementation utilizes a branching factor of 256 because it is the most commonly used value. B. On-chain Verification The on-chain verification phase concentrated on measuring the gas costs associated with verifying individual element proofs. We deployed both Verkle and Merkle verification contracts to a local Hardhat network and conducted systematic gas consumption analysis for proof verification operations. The verification process involves confirming that a given address exists within the original set by validating its proof against the tree’s root hash. We specifically focused on single-element verification scenarios, as our current implementation does not support batch operations. V. R ESULTS A. Verkle Tree Gas Cost Analysis TABLE II V ERKLE T REE Capacity Proof length Verification Cost Calldata Cost Total

2 levels 2562 constant 285507 25210 491527

3 levels 2563 constant 428707 27770 637287

4 levels 2564 constant 571144 30330 782284

5 levels 2565 constant 714178 32890 927878

6 levels 2566 constant 864628 35450 1080888

When using Verkle tree for verification, most of the cost comes from verification itself with the remainder going to Calldata. Analysis of the empirical results demonstrates that Verkle tree verification costs follow a logarithmic relationship with respect to capacity. The experimental data presented in Table II illustrates that while the capacity grows exponentially

with each additional level, the verification costs exhibit a linear growth rate, and so does the calldata cost. The total gas cost of verifying a single element from a Verkle tree with k branching factor and C capacity can be modeled by the equation: ⌈logk (C)⌉ × 147560 + 200900

(1)

B. Merkle Tree Gas Cost Analysis TABLE III M ERKLE T REE Capacity Proof length Verification Cost Calldata Cost Total

3 levels 23 3 25610 2816 28426

7 levels 27 7 28715 4736 33451

10 levels 210 10 31407 6386 37793

15 levels 215 15 35602 8948 44550

20 levels 220 20 39770 11500 51270

Analysis of the empirical results demonstrates that Merkle tree verification costs follow a logarithmic relationship with base 2, as opposed to base k in Verkle trees. The experimental data presented in Table III shows that capacity grows exponentially with levels, while both verification costs and proof length increase linearly with tree depth. The verification cost can be modeled by equation: (⌈log2 (C)⌉ × 1342) + 24300

(2)

C. Comparative Analysis

Fig. 3. Verkle and Merkle Tree gas cost in respect to tree capacity

Although [8] has anticipated that Verkle trees could be more efficient for larger datasets due to their constant-size proofs, figure 3, produced using (2) and (1), reveals a different outcome in terms of on-chain gas costs. The data shows that Merkle Trees consistently maintain lower total gas costs across all capacity ranges tested, contradicting initial theoretical expectations. This unexpected result can be attributed to several factors: 1) The significantly higher base verification cost for Verkle trees (285,507 gas at 2 levels) compared to Merkle Trees (25,610 gas at 3 levels) creates a substantial initial overhead that their constant-size proof advantage doesn’t overcome.

2) While Verkle trees achieve better capacity scaling (k n vs 2n ) and constant proof sizes, the actual verification computation on-chain proves to be more expensive than handling larger proof sizes in Merkle Trees. 3) The linear growth in Merkle Tree costs (approximately 1,342 gas per level) proves to be more economical than Verkle tree’s higher per-level cost (around 147,560 gas per level), even when accounting for increased calldata costs from larger proof sizes. This analysis suggests that while Verkle trees offer theoretical advantages in terms of proof size and capacity scaling, their current implementation results in higher on-chain computational costs that outweigh these benefits. For blockchain applications where gas optimization is crucial, Merkle Trees remain the more cost-effective solution across all tested capacity ranges. VI. C ONCLUSION The emergence of the Verkle tree as a new data structure marks major progress in optimizing blockchain system structure. It uses vector commitment instead of hash function to greatly reduce the proof size while considering the proof efficiency. To fill the application gap of Verkle tree in onchain verification, this paper proposes TS-Verkle, a Verkle tree library developed based on TypeScript and including on-chain validator. Through experiments, we compared the differences between Verkle tree and Merkle Tree in on-chain verification gas cost. Our development of Ethereum Gas Cost Equations reveals an important insight: while Verkle trees demonstrate theoretical advantages, their current implementation faces challenges in achieving superior gas cost efficiency compared to Merkle trees. The path forward for realizing the full potential of Verkle trees requires advancement along multiple research directions. First, exploring alternative vector commitment schemes beyond KZG and IPA presents promising opportunities. Transparent commitments and grid-based commitments could potentially reduce verification times while eliminating the need for trusted setup procedures. Second, optimization of onchain verification demands investigation into advanced techniques such as batch verification and the implementation of precompiled contracts for elliptic curve operations, both of which could significantly reduce gas costs. Back to the tree structure, potential solutions include hybrid implementations that combine the strengths of both Merkle and Verkle trees, as well as adaptive methodologies capable of dynamic tree structure optimization [19]. Looking ahead, Verkle trees hold considerable promise in improving blockchain scalability. Through our research and implementation of TS-Verkle, we have established a foundation for future exploration and development in this field. We hope that our work paves the way for continued innovation in the efficiency and scalability of decentralized systems. ACKNOWLEDGEMENT This work was supported in part by a grant from AFOSR.

R EFERENCES [1] R. C. Merkle, “A digital signature based on a conventional encryption function,” in Conference on the theory and application of cryptographic techniques. Springer, 1987, pp. 369–378. [2] G. Becker, “Merkle signature schemes, merkle trees and their cryptanalysis,” Ruhr-University Bochum, Tech. Rep, vol. 12, p. 19, 2008. [3] S. Jing, X. Zheng, and Z. Chen, “Review and investigation of merkle tree’s technical principles and related application fields,” in 2021 International Conference on Artificial Intelligence, Big Data and Algorithms (CAIBDA), 2021, pp. 86–90. [4] H. Liu, X. Luo, H. Liu, and X. Xia, “Merkle tree: A fundamental component of blockchains,” in 2021 International Conference on Electronic Information Engineering and Computer Science (EIECS), 2021, pp. 556–561. [5] P. Berman, M. Karpinski, and Y. Nekrich, “Optimal trade-off for merkle tree traversal,” Theoretical Computer Science, vol. 372, no. 1, pp. 26–36, 2007. [6] P. Ayyalasomayajula and M. Ramkumar, “Optimization of merkle tree structures: A focus on subtree implementation,” in 2023 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC), 2023, pp. 59–67. [7] A. Mizrahi, N. Koren, and O. Rottenstreich, “Optimizing merkle proof size for blockchain transactions,” in 2021 International Conference on COMmunication Systems & NETworkS (COMSNETS), 2021, pp. 299– 307. [8] J. Kuszmaul, “Verkle trees,” Verkle Trees, vol. 1, no. 1, 2019. [9] M. Iavich, T. Kuchukhidze, and R. Bocu, “A post-quantum digital signature using verkle trees and lattices.” Symmetry (20738994), vol. 15, no. 12, 2023. [10] K.-W. Lin and Y.-C. Chen, “A file verification scheme based on verkle trees,” in 2023 International Conference on Consumer Electronics Taiwan (ICCE-Taiwan), 2023, pp. 295–296. [11] X. Zhao, G. Zhang, H.-W. Long, and Y.-W. Si, “Minimizing block incentive volatility through verkle tree-based dynamic transaction storage,” Decision Support Systems, vol. 180, p. 114180, 2024. [12] V. Boiko, N. Vasilenko, and V. Slatvinska, “Distributed systems log protection from cyberattacks by verkle trees,” in International ScientificPractical Conference” Information Technology for Education, Science and Technics”. Springer, 2024, pp. 221–234. [13] C. Crypto, “rust-verkle,” 2024. [Online]. Available: https://github.com/crate-crypto/rust-verkle [14] ethereum, “go-verkle,” 2024. [Online]. Available: https://github.com/ethereum/go-verkle?tab=readme-ov-file [15] C. Crypto, “verkle-trie-ref,” 2022. [Online]. Available: https://github.com/crate-crypto/verkle-trie-ref?tab=readme-ovfile#terminology [16] A. Kate, G. M. Zaverucha, and I. Goldberg, “Constant-size commitments to polynomials and their applications,” in Advances in CryptologyASIACRYPT 2010: 16th International Conference on the Theory and Application of Cryptology and Information Security, Singapore, December 5-9, 2010. Proceedings 16. Springer, 2010, pp. 177–194. [17] K. Jie, “libkzg,” 2020. [Online]. Available: https://github.com/weijiekoh/libkzg [18] J. Bootle, A. Cerulli, P. Chaidos, J. Groth, and C. Petit, “Efficient zeroknowledge arguments for arithmetic circuits in the discrete log setting,” in Advances in Cryptology–EUROCRYPT 2016: 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May 8-12, 2016, Proceedings, Part II 35. Springer, 2016, pp. 327–357. [19] O. Kuznetsov, D. Kanonik, A. Rusnak, A. Yezhov, O. Domin, and K. Kuznetsova, “Adaptive merkle trees for enhanced blockchain scalability,” Internet of Things, vol. 27, p. 101315, 2024.

Record · ID 175223 · SHA-256 ed95c43637d4cb6b
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.