{"id":18058,"date":"2026-03-08T02:09:12","date_gmt":"2026-03-08T02:09:12","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/03\/08\/verkle-tree-structure-ethereum-foundation-blog\/"},"modified":"2026-03-08T02:09:12","modified_gmt":"2026-03-08T02:09:12","slug":"verkle-tree-structure-ethereum-foundation-blog","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/03\/08\/verkle-tree-structure-ethereum-foundation-blog\/","title":{"rendered":"Verkle tree structure | Ethereum Foundation Blog"},"content":{"rendered":"<p> <br \/>\n<\/p>\n<div id=\"\">\n<p class=\"chakra-text css-gi02ar\">A Verkle tree is a commitment scheme that works similar to a Merkle tree, but has much smaller witnesses. It works by replacing the hashes in a Merkle tree with a vector commitment, which makes wider branching factors more efficient.<\/p>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Thanks to Kevaundray Wedderburn for feedback on the post.<\/em><\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"overview\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"overview permalink\" href=\"#overview\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Overview<\/h2>\n<p class=\"chakra-text css-gi02ar\">For details on how verkle trees work, see:<\/p>\n<p class=\"chakra-text css-gi02ar\">The aim of this post is to explain the concrete layout of the <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/notes.ethereum.org\/@vbuterin\/verkle_tree_eip\">draft verkle tree EIP<\/a>. It is aimed at client developers who want to implement verkle trees and are looking for an introduction before delving deeper into the EIP.<\/p>\n<p class=\"chakra-text css-gi02ar\">Verkle trees introduce a number of changes to the tree structure. The most significant changes are:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">a switch from 20 byte keys to 32 byte keys (not to be confused with 32 byte addresses, which is a separate change);<\/li>\n<li class=\"css-0\">the merge of the account and storage tries; and finally<\/li>\n<li class=\"css-0\">The introduction of the verkle trie itself, which uses vector commitments instead of hashes.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">As the vector commitment scheme for the verkle tree, we use <em class=\"chakra-text css-0\">Pedersen commitments<\/em>. Pedersen commitments are based on elliptic curves. For an introduction to Pedersen commitments and how to use them as polynomial or vector commitments using Inner Product Argumentss, see <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/dankradfeist.de\/ethereum\/2021\/07\/27\/inner-product-arguments.html\">here<\/a>.<\/p>\n<p class=\"chakra-text css-gi02ar\">The curve we are using is <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/ethresear.ch\/t\/introducing-bandersnatch-a-fast-elliptic-curve-built-over-the-bls12-381-scalar-field\/9957\">Bandersnatch<\/a>. This curve was chosen because it is performant, and also because it will allow efficient SNARKs in BLS12_381 to reason about the verkle tree in the future. This can be useful for rollups as well as allowing an upgrade where all witnesses can be compressed into one SNARK once that becomes practical, without needing a further commitment update.<\/p>\n<p class=\"chakra-text css-gi02ar\">The curve order\/scalar field size of bandersnatch is <em class=\"chakra-text css-0\">p = 13108968793781547619861935127046491459309155893440570251786403306729687672801<\/em>, which is a 253 bit prime. As a result of this, we can only safely commit to bit strings of at most 252 bits, otherwise the field overflows. We chose a branching factor (width) of 256 for the verkle tree, which means each commitment can commit to up to 256 values of 252 bits each (or to be precise, integers up to <em class=\"chakra-text css-0\">p &#8211; 1<\/em>). We write this as <em class=\"chakra-text css-0\">Commit(v\u2080, v\u2081, &#8230;, v\u2082\u2085\u2085)<\/em> to commit to the list <em class=\"chakra-text css-0\">v<\/em> of length 256.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"layout-of-the-verkle-tree\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"layout of the verkle tree permalink\" href=\"#layout-of-the-verkle-tree\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Layout of the verkle tree<\/h2>\n<p class=\"chakra-text css-gi02ar\">One of the design goals with the verkle tree EIP is to make accesses to neighbouring positions (e.g. storage with almost the same address or neighbouring code chunks) cheap to access. In order to do this, a key consists of a <em class=\"chakra-text css-0\">stem<\/em> of 31 bytes and a <em class=\"chakra-text css-0\">suffix<\/em> of one byte for a total of 32 bytes. The key scheme is designed so that &#8220;close&#8221; storage locations are mapped to the same stem and a different suffix. For details please look at the <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/notes.ethereum.org\/@vbuterin\/verkle_tree_eip\">EIP draft<\/a>.<\/p>\n<p class=\"chakra-text css-gi02ar\">The verkle tree itself is then composed of two types of nodes:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><em class=\"chakra-text css-0\">Extension nodes<\/em>, that represent 256 values with the same stem but different suffixes<\/li>\n<li class=\"css-0\"><em class=\"chakra-text css-0\">Inner nodes<\/em>, that have up to 256 children, which can be either other inner nodes or extension nodes.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">The commitment to an extension node is a commitment to a 4 element vector; the remaining positions will be 0. It is:<\/p>\n<p class=\"chakra-text css-gi02ar\"><img decoding=\"async\" alt=\"\" src=\"https:\/\/blog.ethereum.org\/images\/posts\/commitment.png\" class=\"chakra-image css-hw6q2r\"\/><\/p>\n<p class=\"chakra-text css-gi02ar\">C\u2081 and C\u2082 are two further commitments that commit to all the values with stem equal to <em class=\"chakra-text css-0\">stem<\/em>. The reason we need two commitments is that values have 32 bytes, but we can only store 252 bits per field element. A single commitment would thus not be enough to store 256 values. So instead C\u2081 stores the values for suffix 0 to 127, and C\u2082 stores 128 to 255, where the values are split in two in order to fit into the field size (we&#8217;ll come to that later.)<\/p>\n<p class=\"chakra-text css-gi02ar\">The extension together with the commitments C\u2081 and C\u2082 are referred to as &#8220;extension-and-suffix tree&#8221; (EaS for short).<\/p>\n<p class=\"chakra-text css-gi02ar\"><img decoding=\"async\" alt=\"\" src=\"https:\/\/blog.ethereum.org\/images\/posts\/upload_11c3da539634c3490428842b8e330fee.jpg\" class=\"chakra-image css-hw6q2r\"\/><br \/>\n<strong>Figure 1<\/strong> <em class=\"chakra-text css-0\">Representation of a walk through a verkle tree for the key <span class=\"chakra-text css-ons8vw\">0xfe0002abcd..ff04<\/span>: the path goes through 3 internal nodes with 256 children each (254, 0, 2), one extension node representing <span class=\"chakra-text css-ons8vw\">abcd..ff<\/span> and the two suffix tree commitments, including the value for <span class=\"chakra-text css-ons8vw\">04<\/span>, v\u2084. Note that <span class=\"chakra-text css-ons8vw\">stem<\/span> is actually the first 31 bytes of the key, including the path through the internal nodes.<\/em><\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"commitment-to-the-values-leaf-nodes\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"commitment to the values leaf nodes permalink\" href=\"#commitment-to-the-values-leaf-nodes\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Commitment to the values leaf nodes<\/h3>\n<p class=\"chakra-text css-gi02ar\">Each extension and suffix tree node contains 256 values. Because a value is 256 bits wide, and we can only store 252 bits safely in one field element, four bits would be lost if we simply tried so store one value in one field element.<\/p>\n<p class=\"chakra-text css-gi02ar\">To circumvent this problem, we chose to partition the group of 256 values into two groups of 128 values each. Each 32-byte value in a group is split into two 16-byte values. So a value v\u1d62\u2208 \ud835\udd39\u2083\u2082 is turned into v\u207d\u02e1\u1d52\u02b7\u1d49\u02b3\u207e\u1d62 \u2208 \ud835\udd39\u2081\u2086 and v\u207d\u1d58\u1d56\u1d56\u1d49\u02b3\u207e\u1d62\u2208 \ud835\udd39\u2081\u2086 such that v\u207d\u02e1\u1d52\u02b7\u1d49\u02b3\u207e\u1d62 ++ v\u207d\u1d58\u1d56\u1d56\u1d49\u02b3\u207e\u1d62= v\u1d62.<\/p>\n<p class=\"chakra-text css-gi02ar\">A &#8220;leaf marker&#8221; is added to the v\u207d\u02e1\u1d52\u02b7\u1d49\u02b3\u207e\u1d62, to differentiate between a leaf that has never been accessed and a leaf that has been overwritten with 0s. <strong>No value ever gets deleted from a verkle tree<\/strong>. This is needed for upcoming state expiry schemes. That marker is set at the 129th bit, i.e. v\u207d\u02e1\u1d52\u02b7\u1d49\u02b3 \u1d50\u1d52\u1d48\u2071\u1da0\u2071\u1d49\u1d48\u207e\u1d62 = v\u207d\u02e1\u1d52\u02b7\u1d49\u02b3\u207e\u1d62 + 2\u00b9\u00b2\u2078 if v\u1d62 has been accessed before, and v\u207d\u02e1\u1d52\u02b7\u1d49\u02b3 \u1d50\u1d52\u1d48\u2071\u1da0\u2071\u1d49\u1d48\u207e\u1d62 = 0 if v\u1d62 has never been accessed.<\/p>\n<p class=\"chakra-text css-gi02ar\">The two commitments C\u2081 and C\u2082 are then defined as<\/p>\n<p class=\"chakra-text css-gi02ar\"><img decoding=\"async\" alt=\"\" src=\"https:\/\/blog.ethereum.org\/images\/posts\/c1-c2.png\" class=\"chakra-image css-hw6q2r\"\/><\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"commitment-of-extension-nodes\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"commitment of extension nodes permalink\" href=\"#commitment-of-extension-nodes\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Commitment of extension nodes<\/h3>\n<p class=\"chakra-text css-gi02ar\">The commitment to an extension node is composed of an &#8220;extension marker&#8221;, which is just the number 1, the two subtree commitments C\u2081 and C\u2082, and the <em class=\"chakra-text css-0\">stem<\/em> of the key leading to this extension node.<\/p>\n<p class=\"chakra-text css-gi02ar\"><img decoding=\"async\" alt=\"\" src=\"https:\/\/blog.ethereum.org\/images\/posts\/commitment.png\" class=\"chakra-image css-hw6q2r\"\/><\/p>\n<p class=\"chakra-text css-gi02ar\">Unlike extension nodes in the Merkle-Patricia tree, which only contain the section of the key that bridges the parent internal node to the child internal node, the stem covers the whole key up to that point. This is because verkle trees are designed with stateless proofs in mind: if a new key is inserted that &#8220;splits&#8221; the extension in two, the older sibling need not be updated, which allows for a smaller proof.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"commitment-of-internal-nodes\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"commitment of internal nodes permalink\" href=\"#commitment-of-internal-nodes\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Commitment of Internal nodes<\/h3>\n<p class=\"chakra-text css-gi02ar\">Internal nodes have the simpler calculation method for their commitments: the node is seen as a vector of 256 values, that are the (field representation of the) root commitment of each of their 256 subtrees. The commitment for an empty subtree is 0. If the subtree is not empty, then the commitment for the internal node is<\/p>\n<p class=\"chakra-text css-gi02ar\"><img decoding=\"async\" alt=\"\" src=\"https:\/\/blog.ethereum.org\/images\/posts\/internal.png\" class=\"chakra-image css-hw6q2r\"\/><\/p>\n<p class=\"chakra-text css-gi02ar\">where the C\u1d62 are the children of the internal node, and 0 if a child is empty.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"insertion-into-the-tree\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"insertion into the tree permalink\" href=\"#insertion-into-the-tree\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Insertion into the tree<\/h2>\n<p class=\"chakra-text css-gi02ar\">Figure 2 is an illustration of the process of inserting a new value into the tree, which gets interesting when the stems collide on several initial bytes.<\/p>\n<p class=\"chakra-text css-gi02ar\"><img decoding=\"async\" alt=\"\" src=\"https:\/\/blog.ethereum.org\/images\/posts\/upload_5196292ae56f82a63cf260429315b736.png\" class=\"chakra-image css-hw6q2r\"\/><\/p>\n<p class=\"chakra-text css-gi02ar\"><strong>Figure 2<\/strong> <em class=\"chakra-text css-0\">Value v\u2081\u2089\u2082 is inserted at location <span class=\"chakra-text css-ons8vw\">0000010000&#8230;0000<\/span> in a verkle tree containing only value v\u2081\u2082\u2087 at location <span class=\"chakra-text css-ons8vw\">0000000000&#8230;0000<\/span>. Because the stems differ at the third byte, two internal nodes are added until the differing byte. Then another &#8220;extension-and-suffix&#8221; tree is inserted, with a full 31-byte stem. The initial node is untouched, and C\u00b2\u2080 has the same value as C\u2070\u2080 before the insertion.<\/em><\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"shallower-trees-smaller-proofs\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"shallower trees smaller proofs permalink\" href=\"#shallower-trees-smaller-proofs\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Shallower trees, smaller proofs<\/h2>\n<p class=\"chakra-text css-gi02ar\">The verkle tree structure makes for shallower trees, which reduces the amount of stored data. Its real power, however, comes from the ability to produce smaller proofs, i.e. witnesses. This will be explained in the next article.<\/p>\n<\/div>\n<p><br \/>\n<br \/><a href=\"https:\/\/blog.ethereum.org\/en\/2021\/12\/02\/verkle-tree-structure\">Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>A Verkle tree is a commitment scheme that works similar to a Merkle tree, but has much smaller witnesses. It works by replacing the hashes in a Merkle tree with a vector commitment, which makes wider branching factors more efficient. Thanks to Kevaundray Wedderburn for feedback on the post. Overview For details on how verkle [&hellip;]<\/p>\n","protected":false},"author":6,"featured_media":18059,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"tdm_status":"","tdm_grid_status":"","footnotes":""},"categories":[24],"tags":[],"kronos_expire_date":[],"class_list":["post-18058","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ethereum"],"_links":{"self":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/18058","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/comments?post=18058"}],"version-history":[{"count":0,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/18058\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media\/18059"}],"wp:attachment":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media?parent=18058"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/categories?post=18058"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/tags?post=18058"},{"taxonomy":"kronos_expire_date","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/kronos_expire_date?post=18058"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}