{"id":18188,"date":"2026-03-11T19:09:58","date_gmt":"2026-03-11T19:09:58","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/03\/11\/geth-v1-10-0-ethereum-foundation-blog\/"},"modified":"2026-03-11T19:09:58","modified_gmt":"2026-03-11T19:09:58","slug":"geth-v1-10-0-ethereum-foundation-blog","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/03\/11\/geth-v1-10-0-ethereum-foundation-blog\/","title":{"rendered":"Geth v1.10.0 | Ethereum Foundation Blog"},"content":{"rendered":"<p> <br \/>\n<\/p>\n<div id=\"\">\n<p class=\"chakra-text css-gi02ar\">Oh wow, it&#8217;s been a while&#8230; over 1.5 years since we&#8217;ve released <a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/2019\/07\/10\/geth-v1-9-0\">Geth v1.9.0<\/a>. We did do 26 point releases in that time frame (about one per three weeks), but pushing out a major release is always a bit more special. The adrenaline rush of shipping new features, coupled with the fear of something going horribly wrong. Still unsure if I like it or hate it. Either way, Ethereum is evolving and we need to push the envelope to keep up with it.<\/p>\n<p class=\"chakra-text css-gi02ar\"><strong><em class=\"chakra-text css-0\">Without further ado, please welcome <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/go-ethereum\/releases\/tag\/v1.10.0\">Geth v1.10.0<\/a> to the Ethereum family.<\/em><\/strong><\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"here-be-dragons\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"here be dragons permalink\" href=\"#here-be-dragons\"><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>Here be dragons<\/h2>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Before diving into the details of our newest release, it&#8217;s essential to emphasize that <strong>with any new feature, come new risks<\/strong>. To cater for users and projects with differing risk profiles, many of our heavy hitter features can be (for now) toggled on and off individually. Whether you read the entire content of this blog post &#8211; or only skim parts interesting to you &#8211; <strong>please read the &#8216;Compatibility&#8217; section at the end of this document<\/strong>!<\/em><\/p>\n<p class=\"chakra-text css-gi02ar\">With that out of the way, let&#8217;s dive in and see what Geth v1.10.0 is all about!<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"berlin-hard-fork\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"berlin hard fork permalink\" href=\"#berlin-hard-fork\"><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>Berlin hard-fork<\/h3>\n<p class=\"chakra-text css-gi02ar\">Let&#8217;s get the elephant out of the room first. Geth v1.10.0 <strong>does not ship<\/strong> the <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/eth1.0-specs\/blob\/master\/network-upgrades\/berlin.md\"><strong><em class=\"chakra-text css-0\">Berlin hard-fork<\/em><\/strong><\/a> yet, as there was some 11th hour concerns from the Solidity team about EIP-2315. Since v1.10.0 is a major release, we don&#8217;t want to publish it too close to the fork. We will follow up with v1.10.1 soon with the final list of EIPs and block numbers baked in.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"snapshots\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"snapshots permalink\" href=\"#snapshots\"><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>Snapshots<\/h3>\n<p class=\"chakra-text css-gi02ar\">We&#8217;ve been <a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/2020\/07\/17\/ask-about-geth-snapshot-acceleration\">talking about snapshots<\/a> for such a long time now, it feels strange to finally see them in a release. Without going into too many details (see linked post), <em class=\"chakra-text css-0\">snapshots<\/em> are an acceleration data structure on top of the Ethereum state, that allows <em class=\"chakra-text css-0\">reading<\/em> accounts and contract storage significantly faster.<\/p>\n<p class=\"chakra-text css-gi02ar\">To put a number on it, the snapshot feature reduces the cost of accessing an account from <span class=\"chakra-text css-ons8vw\">O(logN)<\/span> to <span class=\"chakra-text css-ons8vw\">O(1)<\/span>. This might not seem like much at a first glance, but translated to practical terms, on mainnet with 140 million accounts, snapshots can save about 8 database lookups per account read. That&#8217;s almost <strong>an order of magnitude less<\/strong> disk lookups, guaranteed constant independent of state size.<\/p>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Whoa, does this mean we can 10x the gas limit?<\/em> No, unfortunately. Whilst snapshots do grant us a 10x read performance, EVM execution also <em class=\"chakra-text css-0\">writes<\/em> data, and these writes need to be Merkle proven. The Merkle proof requirement retains the necessity for <span class=\"chakra-text css-ons8vw\">O(logN)<\/span> disk access on writes.<\/p>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">So, what&#8217;s the point then?!<\/em> Whilst fast read access to accounts and contract storage isn&#8217;t enough to bump the gas limit, it does solve a few particularly thorny issues:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><strong>DoS.<\/strong> In 2016, Ethereum sustained its worse DoS attack ever &#8211; <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/2017.edcon.io\/ppt\/one\/Martin%20Holst%20Swende_The%20%27Shanghai%20%27Attacks_EDCON.pdf\">The Shanghai Attacks<\/a> &#8211; that lasted about 2-3 months. The attack revolved around bloating Ethereum&#8217;s state and abusing various underpriced opcodes to grind the network to a halt. After numerous client optimizations and repricing hard forks, the attack was repelled. The root cause still lingers: state access opcodes have a fixed EVM gas cost <span class=\"chakra-text css-ons8vw\">O(1)<\/span>, but an ever slowly increasing execution cost <span class=\"chakra-text css-ons8vw\">O(logN)<\/span>. We&#8217;ve bumped the gas costs in <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-150\">Tangerine Whistle<\/a>, <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-1884\">Istanbul<\/a> and now <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-2929\">Berlin<\/a> to bring the EVM costs back in line with the runtime costs, but these are stopgap measures. Snapshots on the other hand reduce execution cost of state reads to <span class=\"chakra-text css-ons8vw\">O(1)<\/span> &#8211; in line with EVM costs &#8211; thus solves the read-based DoS issues long term (don&#8217;t quote me on that).<\/li>\n<li class=\"css-0\"><strong>Call.<\/strong> Checking a smart contract&#8217;s state in Ethereum entails a mini EVM execution. Part of that is running bytecode and part of it is reading state slots from disk. If you have your personal Ethereum node that you only use for your own personal needs, there&#8217;s a high chance that the current state access speed is more than adequate. If you&#8217;re operating a node for the consumption of multiple users however, the 10x performance improvement granted by snapshots means that you can serve 10x as many queries at +- the same cost to you.<\/li>\n<li class=\"css-0\"><strong>Sync.<\/strong> There are two major ways you can synchronize an Ethereum node. You can download the blocks and execute all the transactions within; or you can download the blocks, verify the PoWs and download the state associated a recent block. The latter is much faster, but it relies on benefactors serving you a copy of the recent state. With the current Merkle-Patricia state model, these benefactors read <strong>16TB<\/strong> of data off disk to serve a syncing node. Snapshots enable serving nodes to read only <strong>96GB<\/strong> of data off disk to get a new node joined into the network. More on this in the <em class=\"chakra-text css-0\">Snap sync<\/em> section.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">As with all features, it&#8217;s a game of tradeoffs. Whilst snapshots have enormous benefits, that we believe in strongly enough to enable for everyone, there are certain costs to them:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">A snapshot is a redundant copy of the raw Ethereum state already contained in the leaves of the Merkle Patricia trie. As such, snapshots entail an additional disk overhead of about <strong>20-25GB on mainnet<\/strong> currently. Hopefully snapshots will allow us to do some further state optimizations and potentially remove some of the disk overhead of Merkle tries as they are currently.<\/li>\n<li class=\"css-0\">Since nobody has snapshots constructed in the network yet, nodes will initially need to bear the cost of iterating the state trie and creating the initial snapshot themselves. Depending on the load to your node, this might take anywhere between <strong>a day to a week<\/strong>, but you only need to do it once in the lifetime of your node (if things work as intended). The snapshot generation runs in the background, concurrently with all other node operations. We have plans to not require this once snapshots are generally available in the network. More on this in the <em class=\"chakra-text css-0\">Snap sync<\/em> section.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">If you are not confident about the snapshot feature, you <strong>can disable it<\/strong> in Geth 1.10.0 via <span class=\"chakra-text css-ons8vw\">&#8211;snapshot=false<\/span>, but be advised that we will make it mandatory long term to guarantee a baseline network health.<\/em><\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"snap-sync\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"snap sync permalink\" href=\"#snap-sync\"><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>Snap sync<\/h3>\n<p class=\"chakra-text css-gi02ar\">If you thought snapshots took a long time to ship, wait till you hear about snap sync! We&#8217;ve implemented the initial prototype of a new synchronization algorithm way back in <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/karalabe\/go-ethereum\/tree\/state-leaf-sync\">October, 2017<\/a>&#8230; then sat on the idea for over 3 years?! \ud83e\udd2f Before diving in, a bit of history.<\/p>\n<p class=\"chakra-text css-gi02ar\">When Ethereum launched, you could choose from two different ways to synchronize the network: <em class=\"chakra-text css-0\">full sync<\/em> and <em class=\"chakra-text css-0\">fast sync<\/em> (omitting light clients from this discussion). <em class=\"chakra-text css-0\">Full sync<\/em> operated by downloading the entire chain and executing all transactions; vs. <em class=\"chakra-text css-0\">fast sync<\/em> placed an initial trust in a recent-ish block, and directly downloaded the state associated with it (after which it switched to block execution like full sync). Although both modes of operation resulted in the same final dataset, they preferred different tradeoffs:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><strong>Full sync<\/strong> minimized trust, choosing to execute all transactions from genesis to head. Whilst it might be the most secure option, Ethereum mainnet currently contains over <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/etherscan.io\/txs\">1.03 billion transactions<\/a>, growing at a rate of <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/etherscan.io\/chart\/tx\">1.25 million \/ day<\/a>. Chosing to execute everything from genesis means <em class=\"chakra-text css-0\">full sync<\/em> has a forever increasing cost. Currently it takes 8-10 days to process all those transactions on a fairly powerful machine.<\/li>\n<li class=\"css-0\"><strong>Fast sync<\/strong> chose to rely on the security of the PoWs. Instead of executing all transactions, it assumed that a block with 64 valid PoWs on top would be prohibitively expensive for someone to construct, as such it&#8217;s ok to download the state associated with <span class=\"chakra-text css-ons8vw\">HEAD-64<\/span>. <em class=\"chakra-text css-0\">Fast sync<\/em> trusting the state root from a recent block, it could download the state trie directly. This replaced the need of CPU &amp; disk IO with a need for network bandwidth and latency. Specifically, Ethereum mainnet currently contains about 675 million state trie nodes, taking about 8-10 hours to download on a fairly well connected machine.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Full sync<\/em> remained available for anyone who wanted to expend the resources to verify Ethereum&#8217;s entire history, but for most people, <em class=\"chakra-text css-0\">fast sync<\/em> was more than adequate\u2122. There&#8217;s a computer science paradox, that once a system reaches 50x the usage it was designed at, it will break down. The logic is, that irrelevant how something works, push it hard enough and an unforeseen bottleneck will appear.<\/p>\n<p class=\"chakra-text css-gi02ar\">In the case of <em class=\"chakra-text css-0\">fast sync<\/em>, the unforeseen bottleneck was <strong><em class=\"chakra-text css-0\">latency<\/em><\/strong>, caused by Ethereum&#8217;s data model. Ethereum&#8217;s state trie is a Merkle tree, where the leaves contain the useful data and each node above is the hash of 16 children. Syncing from the root of the tree (the hash embedded in a block header), the only way to download everything is to request each node <strong>one-by-one<\/strong>. With 675 million nodes to download, even by batching 384 requests together, it ends up needing 1.75 million round-trips. Assuming an overly generous 50ms RTT to 10 serving peers, <em class=\"chakra-text css-0\">fast sync<\/em> is essentially <strong><em class=\"chakra-text css-0\">waiting for over 150 minutes<\/em><\/strong> for data to arrive. But network latency is only 1\/3rd of the problem.<\/p>\n<p class=\"chakra-text css-gi02ar\">When a serving peer receives a request for trie nodes, it needs to <strong>retrieve them from disk<\/strong>. Ethereum&#8217;s Merkle trie doesn&#8217;t help here either. Since trie nodes are keyed by hash, there&#8217;s no meaningful way to store\/retrieve them batched, each requiring it&#8217;s own database read. To make matters worse, LevelDB (used by Geth) stores data in 7 levels, so a random read will generally touch as many files. Multiplying it all up, a single network request of 384 nodes &#8211; at 7 reads a pop &#8211; amounts to 2.7 thousand disk reads. With the fastest SATA SSDs&#8217; speed of 100.000 IOPS, that&#8217;s 37ms extra latency. With the same 10 serving peer assumption as above, <em class=\"chakra-text css-0\">fast sync<\/em> just added an <strong>extra 108 minutes waiting time<\/strong>. But serving latency is only 1\/3 of the problem.<\/p>\n<p class=\"chakra-text css-gi02ar\">Requesting that many trie nodes individually means actually uploading that many hashes to remote peers to serve. With 675 million nodes to download, that&#8217;s 675 million hashes to upload, or 675 * 32 bytes = 21GB. At a global average of 51Mbps upload speed (X Doubt), <em class=\"chakra-text css-0\">fast sync<\/em> just added an <strong>extra 56 minutes waiting time<\/strong>. Downloads are a bit more than twice as large, so with global averages of 97Mbps, *fast sync* popped on a <strong>further 63 minutes<\/strong>. Bandwidth delays are the last 1\/3 of the problem.<\/p>\n<p class=\"chakra-text css-gi02ar\">Sum it all up, and <em class=\"chakra-text css-0\">fast sync<\/em> spends a whopping 6.3 hours doing nothing, just <strong>waiting for data<\/strong>:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><strong><em class=\"chakra-text css-0\">If<\/em><\/strong> you have an above average network link<\/li>\n<li class=\"css-0\"><strong><em class=\"chakra-text css-0\">If<\/em><\/strong> you have a good number of serving peers<\/li>\n<li class=\"css-0\"><strong><em class=\"chakra-text css-0\">If<\/em><\/strong> your peers don&#8217;t serve anyone else but you<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\"><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/devp2p\/blob\/master\/caps\/snap.md\">Snap sync<\/a><\/em> was designed to solve all three of the enumerated problems. The core idea is fairly simple: instead of downloading the trie node-by-node, <em class=\"chakra-text css-0\">snap sync<\/em> downloads the contiguous chunks of useful state data, and reconstructs the Merkle trie locally:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Without downloading intermediate Merkle trie nodes, state data can be fetched in large batches, removing the delay caused by network latency.<\/li>\n<li class=\"css-0\">Without downloading Merkle nodes, downstream data drops to half; and without addressing each piece of data individually, upstream data gets insignificant, removing the delay caused by bandwidth.<\/li>\n<li class=\"css-0\">Without requesting randomly keyed data, peers do only a couple contiguous disk reads to serve the responses, removing the delay of disk IO (<strong><em class=\"chakra-text css-0\">iff the peers already have the data stored in an appropriate flat format<\/em><\/strong>).<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">Whilst <em class=\"chakra-text css-0\">snap sync<\/em> is eerily similar to Parity&#8217;s <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/openethereum.github.io\/Warp-Sync.html\"><em class=\"chakra-text css-0\">warp sync<\/em><\/a> &#8211; and indeed took many design ideas from it &#8211; there are significant improvements over the latter:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><em class=\"chakra-text css-0\">Warp sync<\/em> relies on <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/openethereum.github.io\/Warp-Sync-Snapshot-Format\">static snapshots<\/a> created every 30000 blocks. This means serving nodes need to regenerate the snapshots every 5 days or so, but iterating the entire state trie can actually take more time than that. This means <em class=\"chakra-text css-0\">warp sync<\/em> is not sustainable long term. Opposed to this, <em class=\"chakra-text css-0\">snap sync<\/em> is based on <a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/2020\/07\/17\/ask-about-geth-snapshot-acceleration\">dynamic snapshots<\/a>, which are generated only once, no matter how slowly, and then are kept up to date as the chain progresses.<\/li>\n<li class=\"css-0\"><em class=\"chakra-text css-0\">Warp sync<\/em>&#8216;s snapshot format does not follow the Merkle trie layout, and as such chunks of warp-data <strong><em class=\"chakra-text css-0\">cannot<\/em><\/strong> be individually proven. Syncing nodes need to download the entire 20+GB dataset before they can verify it. This means <em class=\"chakra-text css-0\">warp syncing<\/em> nodes could be theoretically grieved. Opposed to this, <em class=\"chakra-text css-0\">snap sync<\/em>&#8216;s snapshot format is just the sequential Merkle leaves, which allows any range to be proven, thus bad data is detected immediately.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">To put a number on <em class=\"chakra-text css-0\">snap sync<\/em> vs <em class=\"chakra-text css-0\">fast sync<\/em>, synchronizing the mainnet state (ignoring blocks and receipts, as those are the same) against 3 serving peers, at block ~#11,177,000 produced the following results:<\/p>\n<p class=\"chakra-text css-gi02ar\"><img decoding=\"async\" alt=\"Snap Sync Benchmark\" src=\"https:\/\/blog.ethereum.org\/images\/geth-snap-sync-benchmark.png\" class=\"chakra-image css-hw6q2r\"\/><\/p>\n<p class=\"chakra-text css-gi02ar\">Do note, that <em class=\"chakra-text css-0\">snap sync<\/em> is shipped, but not yet enabled, in Geth v1.10.0. The reason is that serving <em class=\"chakra-text css-0\">snap sync<\/em> requires nodes to have the <em class=\"chakra-text css-0\">snapshot<\/em> acceleration structure already generated, which nobody has yet, as it is also shipped in v1.10.0. You can manually enable snap sync via <span class=\"chakra-text css-ons8vw\">&#8211;syncmode snap<\/span>, but be advised that we expect it <strong>not to find<\/strong> suitable peers until a few weeks after Berlin. We&#8217;ll enable it by default when we feel there are enough peers to rely on it.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"offline-pruning\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"offline pruning permalink\" href=\"#offline-pruning\"><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>Offline pruning<\/h3>\n<p class=\"chakra-text css-gi02ar\">We&#8217;re really proud of what we&#8217;ve achieved with Geth over the past years. Yet, there&#8217;s always <strong><em class=\"chakra-text css-0\">that one topic<\/em><\/strong>, which makes you flinch when asked about. For Geth, that topic is <em class=\"chakra-text css-0\">state pruning<\/em>. But what is pruning and why is it needed?<\/p>\n<p class=\"chakra-text css-gi02ar\">When processing a new block, a node takes the current state of the network as input data and mutates it according to the transactions in the block, generating a new, output data. The output state is mostly the same as the input, only a few thousand items modified. Since we can&#8217;t just overwrite the old state (otherwise we couldn&#8217;t handle block reorgs), both old and new end up on disk. <em class=\"chakra-text css-0\">(Ok, we&#8217;re a bit smarter and only push new diffs to disk if they stick around and don&#8217;t get deleted in the next few blocks, but let&#8217;s ignore that part for now).<\/em><\/p>\n<p class=\"chakra-text css-gi02ar\">Pushing these new pieces of state data, block-by-block, to the database is a problem. They keep accumulating. In theory we could &#8220;just delete&#8221; state data that&#8217;s old enough to not run the risk of a reorg, but as it turns out, that&#8217;s quite a hard problem. Since state in Ethereum is stored in a tree data structure &#8211; and since most blocks only change a small fraction of the state &#8211; these trees share huge portions of the data with one another. We can easily decide if the root of an old trie is stale and can be deleted, but it&#8217;s exceedingly costly to figure out if a node deep within an old state is still referenced by anything newer or not.<\/p>\n<p class=\"chakra-text css-gi02ar\">Throughout the years, we&#8217;ve implemented a range of pruning algorithms to delete leftovers (lost count, around 10), yet we&#8217;ve never found a solution that doesn&#8217;t break down if enough data is thrown at it. As such, people grew accustomed that Geth&#8217;s database starts slim after a <em class=\"chakra-text css-0\">fast sync<\/em>, and keeps growing until you get fed up and resync. This is frustrating to say the least, as re-downloading everything just wastes bandwidth and adds meaningless downtime to the node.<\/p>\n<p class=\"chakra-text css-gi02ar\">Geth v1.10.0 doesn&#8217;t quite solve the problem, but it takes a big step towards a better user experience. If you have <em class=\"chakra-text css-0\">snapshots<\/em> enabled and fully generated, Geth can use those as an acceleration structure to relatively quickly determine which trie nodes should be kept and which should be deleted. Pruning trie nodes based on snapshots does have the drawback that the chain may not progress during pruning. This means, that you need to stop Geth, prune its database and then restart it.<\/p>\n<p class=\"chakra-text css-gi02ar\">Execution time wise, pruning takes a few hours (greatly depends on your disk speed and accumulated junk), one third of which is indexing recent trie node from snapshots, one third deleting stale trie nodes and the last third compacting the database to reclaim freed up space. At the end of the process, your disk usage should approximately be the same as if you did a fresh sync. To prune your database, please run <span class=\"chakra-text css-ons8vw\">geth snapshot prune-state<\/span>.<\/p>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Be advised, that pruning is a <strong>new and dangerous feature<\/strong>, a failure of which can cause bad blocks. We&#8217;re confident that it&#8217;s reliable, but if something goes wrong, there&#8217;s likely no way to salvage the database. Our recommendation &#8211; at least until the feature gets battle tested &#8211; is to back up your database prior to pruning, and try with testnet nodes first before going all in on mainnet.<\/em><\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"transaction-unindexing\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"transaction unindexing permalink\" href=\"#transaction-unindexing\"><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>Transaction unindexing<\/h3>\n<p class=\"chakra-text css-gi02ar\">Ethereum has been around for a while now, and in its almost 6 years&#8217; of existence, Ethereum&#8217;s users issued over <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/etherscan.io\/chart\/tx\"><strong><em class=\"chakra-text css-0\">1 billion<\/em><\/strong><\/a> transactions. That&#8217;s a big number.<\/p>\n<p class=\"chakra-text css-gi02ar\">Node operators always took it for granted that they can look up an arbitrary transaction from the past, given only its <em class=\"chakra-text css-0\">hash<\/em>. Truth be told, it seems like a no-brainer thing to do. Running the numbers though, we end up in a surprising place. To make transactions searchable, we need to &#8211; at minimum &#8211; map the entire range of transaction hashes to the blocks they are in. With all tradeoffs made towards minimizing storage, we still need to store 1 block number (4 bytes) associated with 1 hash (32 bytes).<\/p>\n<p class=\"chakra-text css-gi02ar\">36 bytes \/ transaction doesn&#8217;t seem much, but multiplying with <em class=\"chakra-text css-0\">1 billion<\/em> transactions ends up at an impressive <strong><em class=\"chakra-text css-0\">36GB of storage<\/em><\/strong>, needed to be able to say transaction <span class=\"chakra-text css-ons8vw\">0xdeadbeef<\/span> is in block <span class=\"chakra-text css-ons8vw\">N<\/span>. It&#8217;s a lot of data and a lot of database entries to shuffle around. Storing 36GB is an acceptable price if you want to look up transactions 6 years back, but in practice, most users don&#8217;t want to. For them, the extra disk usage and IO overhead is wasted resources. It&#8217;s also important to note that transaction indices are not part of consensus and are not part of the network protocol. They are purely a locally generated acceleration structure.<\/p>\n<p class=\"chakra-text css-gi02ar\">Can we shave some &#8211; for us &#8211; useless data off of our nodes? Yes! Geth v1.10.0 switches on transaction unindexing by default and sets it to <span class=\"chakra-text css-ons8vw\">2,350,000<\/span> blocks (about 1 year). The transaction unindexer will linger in the background, and every time a new block arrives, it ensures that only transactions from the most recent <span class=\"chakra-text css-ons8vw\">N<\/span> blocks are indexed, deleting older ones. If a user decides they want access to older transactions, they can restart Geth with a higher <span class=\"chakra-text css-ons8vw\">&#8211;txlookuplimit<\/span> value, and any blocks missing from the updated range will be reindexed (note, the trigger is still block import, you have to wait for 1 new block).<\/p>\n<p class=\"chakra-text css-gi02ar\">Since about 1\/3rd of <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/etherscan.io\/chart\/tx\">Ethereum&#8217;s transaction load<\/a> happened in 2020, keeping an entire year&#8217;s worth of transaction index will still have a noticeable weight on the database. The goal of transaction unindexing is not to remove an existing feature in the name of saving space. The goal is to move towards a mode of operation where space does not grow indefinitely with chain history.<\/p>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">If you wish to <strong>disable<\/strong> transaction unindexing altogether, you can run Geth with <span class=\"chakra-text css-ons8vw\">&#8211;txlookuplimit=0<\/span>, which reverts to the old behavior of retaining the lookup map for every transaction since genesis.<\/em><\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"preimage-discarding\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"preimage discarding permalink\" href=\"#preimage-discarding\"><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>Preimage discarding<\/h3>\n<p class=\"chakra-text css-gi02ar\">Ethereum stores all its data in a Merkle Patricia trie. The values in the leaves are the raw data being stored (e.g. storage slot content, account content), and the path to the leaf is the key at which the data is stored. The keys however are <strong><em class=\"chakra-text css-0\">not<\/em><\/strong> the account addresses or storage addresses, rather the <span class=\"chakra-text css-ons8vw\">Keccak256<\/span> hashes of those. This helps balance the branch depths of the state tries. Using hashes for keys is fine as users of Ethereum only ever reference the original addresses, which can be hashed on the fly.<\/p>\n<p class=\"chakra-text css-gi02ar\">There is one use case, however, where someone has a hash stored in the state trie and wants to recover it&#8217;s preimage: debugging. When stepping over an EVM bytecode, a developer might want to glipmse over all the variables in the smart contract. The data is there, but without the preimages, its hard to say which data corresponds to which Solidity variable.<\/p>\n<p class=\"chakra-text css-gi02ar\">Originally Geth had a half-baked solution. We stored in the database all preimages that originated from user calls (e.g. sending a transaction), but not those originating from EVM calls (e.g. accessing a slot). This was not enough for Remix, so we extended our tracing API calls to support saving the preimages for all SHA3 (Keccak256) operations. Although this solved the debugging issue for Remix, it raised the question about all that data unused by non-debugging nodes.<\/p>\n<p class=\"chakra-text css-gi02ar\">The preimages aren&#8217;t particularly heavy. If you do a full sync from genesis &#8211; reexecuting all the transactions &#8211; you&#8217;ll only end up with 5GB extra load. Still, there is no reason to keep that data around for users not using it, as it only increases the load on LevelDB compactions. As such, Geth v1.10.0 <strong>disables<\/strong> preimage collection by default, but there&#8217;s no mechanism to actively delete already stored preimages.<\/p>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">If you are using your Geth instance to debug transactions, you can <strong>retain<\/strong> the original behavior via <span class=\"chakra-text css-ons8vw\">&#8211;cache.preimages<\/span>. Please note, <strong>it is not possible to regenerate preimages after the fact<\/strong>. If you run Geth with preimage collection disabled and change your mind, you&#8217;ll need to reimport the blocks.<\/em><\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"eth66-protocol\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"eth66 protocol permalink\" href=\"#eth66-protocol\"><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>ETH\/66 protocol<\/h3>\n<p class=\"chakra-text css-gi02ar\">The <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-2481\"><span class=\"chakra-text css-ons8vw\">eth\/66<\/span><\/a> protocol is a fairly small change, yet has quite a number of beneficial implications. In short, the protocol introduces request and reply IDs for all bidirectional packets. The goal behind these IDs is to more easily match up responses to requests, specifically, to more easily deliver a response to a subsystem that made the original request.<\/p>\n<p class=\"chakra-text css-gi02ar\">These IDs are not essential, and indeed we&#8217;ve been happily working around the lack of them these past 6 years. Unfortunately, all code that needs to request anything from the network becomes overly complicated, if multiple subsystems can request the same type of data concurrently. E.g. block headers can be requested by the <em class=\"chakra-text css-0\">downloader<\/em> syncing the chain; it can be requested by the <em class=\"chakra-text css-0\">fetcher<\/em> fulfilling block announcements; and it can be requested by fork challenges. Furthermore, timeouts can cause late\/unexpected deliveries or re-requests. In all these cases, when a <em class=\"chakra-text css-0\">header packet<\/em> arrives, every subsystem peeks at the data and tries to figure out if it was meant for itself or someone else. Consuming a reply not meant for a particular subsystem will cause a failure elsewhere, which needs graceful handling. It just gets messy. Doable, but messy.<\/p>\n<p class=\"chakra-text css-gi02ar\">The importance of <span class=\"chakra-text css-ons8vw\">eth\/66<\/span> in the scope of this blog post is not that it solves a particular problem, rather that <strong>it is introduced prior to the Berlin hard-fork<\/strong>. As all nodes are expected to upgrade by the fork time, this means Geth can start deprecating the old protocols after the fork. Only after discontinuing all older protocols can we rewrite Geth&#8217;s internals to take advantage of request ids. Following our <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/discord.com\/channels\/595666850260713488\/745077610685661265\/778217548893126666\">protocol deprecation schedule<\/a>, we&#8217;ll be dropping <span class=\"chakra-text css-ons8vw\">eth\/64<\/span> shortly and <span class=\"chakra-text css-ons8vw\">eth65<\/span> by the end of summer.<\/p>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Some people might consider Geth using its weight to force protocol updates on other clients. We&#8217;d like to emphasize that the <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-2718\">typed transactions<\/a> feature from the Berlin hard-fork originally called for a new protocol version. As only Geth implemented the full suite of <span class=\"chakra-text css-ons8vw\">eth\/xy<\/span> protocols, other clients requested &#8220;hacking&#8221; it into old protocol versions to avoid having to focus on networking at this time. The agreement was that Geth backports typed transaction support into all its old protocol code to buy other devs time, but in exchange will phase out the old versions in 6 months to avoid stagnation.<\/em><\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"chainid-enforcement\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"chainid enforcement permalink\" href=\"#chainid-enforcement\"><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>ChainID enforcement<\/h3>\n<p class=\"chakra-text css-gi02ar\">Way back in 2016, when <em class=\"chakra-text css-0\">TheDAO hard-fork<\/em> passed, Ethereum introduced the notion of the <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-155\"><strong><em class=\"chakra-text css-0\">chain id<\/em><\/strong><\/a>. The goal was to modify the digital signatures on transactions with a unique identifier to differentiate between what&#8217;s valid on Ethereum and what&#8217;s valid on Ethereum Classic (and what&#8217;s valid on testnets). Making a transaction valid on one network but invalid on another ensures they cannot be replayed without the owner&#8217;s knowledge.<\/p>\n<p class=\"chakra-text css-gi02ar\">In order to minimize issues around the transition, both new\/protected and old\/unprotected transactions remained valid. Fast forward 5 years, and about 15% of transaction on Ethereum are still not replay-protected. This doesn&#8217;t mean there&#8217;s an inherent vulnerability, unless you reuse the same keys across multiple networks. <strong><em class=\"chakra-text css-0\">Top tip: Don&#8217;t!<\/em><\/strong> Still, accidents happen, and certain Ethereum based networks have been known to go offline due to replay issues.<\/p>\n<p class=\"chakra-text css-gi02ar\">As much as we don&#8217;t want to play big brother, we&#8217;ve decided to try and nudge people and tooling to abandon the old, unprotected signatures and use chain ids everywhere. The easy way would be to just make unprotected transactions invalid at the consensus level, but that would leave 15% of people stranded and scattering for hotfixes. To gradually move people towards safer alternatives without pulling the rug from underneath their feet, Geth v1.10.0 will <strong>reject transactions<\/strong> on the RPC that are not replay protected. <strong>Propagation through the P2P protocols remains unchanged<\/strong> for now, but we will be pushing for rejection there too long term.<\/p>\n<p class=\"chakra-text css-gi02ar\">If you are using code generated by <span class=\"chakra-text css-ons8vw\">abigen<\/span>, <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/go-ethereum\/pull\/21356\">we&#8217;ve included<\/a> in the <span class=\"chakra-text css-ons8vw\">go-ethereum<\/span> libraries additional signer constructors to allow easily creating chain-id-bound transactors. The legacy signers included out of the box were written before EIP155 and until now you needed to construct the protected signer yourself. As this was error prone and some people assumed we guessed the chain ID internally, we decided to introduce direct APIs ourselves. <strong>We will deprecate and remove the legacy signers in the long term<\/strong>.<\/p>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Since we realize people\/tooling issuing unprotected transactions can&#8217;t change overnight, Geth v1.10.0 <strong>supports reverting<\/strong> to the old behavior and accepting non-EIP155 transactions via <span class=\"chakra-text css-ons8vw\">&#8211;rpc.allow-unprotected-txs<\/span>. Be advised that this is a temporary mechanism that <strong>will be removed<\/strong> long term.<\/em><\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"database-introspection\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"database introspection permalink\" href=\"#database-introspection\"><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>Database introspection<\/h3>\n<p class=\"chakra-text css-gi02ar\">Every now and again we receive an issue report about a corrupted database, with no real way to debug it. Shipping a 300GB data directory to us is not feasible, and sending custom dissection tools to users is cumbersome. Also since a corrupted database often manifests itself in an inability to start up Geth, even using debugging RPC APIs are useless.<\/p>\n<p class=\"chakra-text css-gi02ar\">Geth v1.10.0 ships a built-in database introspection tool to try and alleviate the situation a bit. It is a very low level accessor to LevelDB, but it allows arbitrary data retrievals, insertions and deletions. We are unsure how useful these will turn out to be, but they at least give a fighting chance to restore a broken node without having to resync.<\/p>\n<p class=\"chakra-text css-gi02ar\">The supported commands are:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">geth db inspect<\/span> &#8211; Inspect the storage size for each type of data in the database<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">geth db stats<\/span> &#8211; Print various database usage and compaction statistics<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">geth db compact<\/span> &#8211; Compact the database, optimizing read access (<strong>super slow<\/strong>)<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">geth db get<\/span> &#8211; Retrieve and print the value of a database key<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">geth db delete<\/span> &#8211; Delete a database key (<strong>super dangerous<\/strong>)<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">geth db put<\/span> &#8211; Set the value of a database key (<strong>super dangerous<\/strong>)<\/li>\n<\/ul>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"flag-deprecations\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"flag deprecations permalink\" href=\"#flag-deprecations\"><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>Flag deprecations<\/h3>\n<p class=\"chakra-text css-gi02ar\">Throughout the v1.9.x release family we&#8217;ve marked a number of CLI flags deprecated. Some of them were renamed to better follow our naming conventions, others were removed due to dropped features (notably Whisper). Throughout the previous release family, we&#8217;ve kept the old deprecated flags functional too, only printing a warning when used instead of the recommended versions.<\/p>\n<p class=\"chakra-text css-gi02ar\">Geth v1.10.0 takes the opportunity to completely remove support for the old CLI flags. Below is a list to help you fix your commands if you by any chance haven&#8217;t yet upgraded to the new versions the past year:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;rpc<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;http<\/span> &#8211; Enable the HTTP-RPC server<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;rpcaddr<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;http.addr<\/span> &#8211; HTTP-RPC server listening interface<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;rpcport<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;http.port<\/span> &#8211; HTTP-RPC server listening port<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;rpccorsdomain<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;http.corsdomain<\/span> &#8211; Domain from which to accept requests<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;rpcvhosts<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;http.vhosts<\/span> &#8211; Virtual hostnames from which to accept requests<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;rpcapi<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;http.api<\/span> &#8211; API&#8217;s offered over the HTTP-RPC interface<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;wsaddr<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;ws.addr<\/span> &#8211; WS-RPC server listening interface<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;wsport<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;ws.port<\/span> &#8211; WS-RPC server listening port<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;wsorigins<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;ws.origins<\/span> &#8211; Origins from which to accept websockets requests<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;wsapi<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;ws.api<\/span> &#8211; API&#8217;s offered over the WS-RPC interface<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;gpoblocks<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;gpo.blocks<\/span> &#8211; Number of blocks to check for gas prices<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;gpopercentile<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;gpo.percentile<\/span> &#8211; Percentile of recent txs to use as gas suggestion<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;graphql.addr<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;graphql<\/span> &#8211; Enable GraphQL on the HTTP-RPC server<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;graphql.port<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;graphql<\/span> &#8211; Enable GraphQL on the HTTP-RPC server<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;pprofport<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;pprof.port<\/span> &#8211; Profiler HTTP server listening port<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;pprofaddr<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;pprof.addr<\/span> &#8211; Profiler HTTP server listening interface<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;memprofilerate<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;pprof.memprofilerate<\/span> &#8211; Turn on memory profiling with the given rate<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;blockprofilerate<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;pprof.blockprofilerate<\/span> &#8211; Turn on block profiling with the given rate<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;cpuprofile<\/span> -&gt; <span class=\"chakra-text css-ons8vw\">&#8211;pprof.cpuprofile<\/span> &#8211; Write CPU profile to the given file<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">A handful of the above listed legacy flags may still work for a few releases, but you should not rely on them remaining available.<\/p>\n<p class=\"chakra-text css-gi02ar\">Since most people running full nodes do not use USB wallets through Geth &#8211; and since USB handling is a bit quirky on different platforms &#8211; a lot of node operators just had to explicitly turn off USB via <span class=\"chakra-text css-ons8vw\">&#8211;nosub<\/span>. To cater the defaults to the requirements of the many, Geth v1.10.0 disabled USB wallet support by default and deprecated the <span class=\"chakra-text css-ons8vw\">&#8211;nousb<\/span> flag. <strong>You can still use USB wallets, just need to explicitly request it from now on via <span class=\"chakra-text css-ons8vw\">&#8211;usb<\/span><\/strong>.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"unclean-shutdown-tracking\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"unclean shutdown tracking permalink\" href=\"#unclean-shutdown-tracking\"><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>Unclean shutdown tracking<\/h3>\n<p class=\"chakra-text css-gi02ar\">Fairly often we receive bug reports that Geth started importing old blocks on startup. This phenomenon is generally caused by the node operator terminating Geth abruptly (power outage, OOM killer, too short shutdown timeout). Since Geth keeps a lot of dirty state in memory &#8211; to avoid writing to disk things that get stale a few blocks later &#8211; an abrupt shutdown can cause these to not be flushed. With recent state missing on startup, Geth has no choice but to rewind it&#8217;s local chain to the point where it last saved the progress.<\/p>\n<p class=\"chakra-text css-gi02ar\">To avoid debating whether an operator did or did not shut down their node cleanly, and to avoid having a clean cycle after a crash hide the fact that data was lost, Geth v1.10.0 will start <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/ethereum\/go-ethereum\/pull\/21893\">tracking and reporting<\/a> node crashes. We&#8217;re hopeful that this will allow operatos to detect that their infra is misconfigured or has issue before those turn into irreversible data loss.<\/p>\n<div class=\"chakra-stack css-1jx0in4\">\n<pre><pre style=\"color:white;font-family:Consolas, Monaco, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, monospace;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;font-size:1em;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;-moz-hyphens:none;-ms-hyphens:none;hyphens:none;padding:1em;margin:0.5em 0;overflow:auto;background:#011627\"><code class=\"language-bash\" style=\"color:#d6deeb;font-family:Consolas, Monaco, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, monospace;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;font-size:1em;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;-moz-hyphens:none;-ms-hyphens:none;hyphens:none\"><span>WARN <\/span><span class=\"token\" style=\"color:rgb(199, 146, 234)\">[<\/span><span>03-03<\/span><span class=\"token\" style=\"color:rgb(127, 219, 202)\">|<\/span><span>06:36:38.734<\/span><span class=\"token\" style=\"color:rgb(199, 146, 234)\">]<\/span><span> Unclean <\/span><span class=\"token\" style=\"color:rgb(130, 170, 255)\">shutdown<\/span><span> detected        <\/span><span class=\"token assign-left\" style=\"color:rgb(214, 222, 235)\">booted<\/span><span class=\"token\" style=\"color:rgb(127, 219, 202)\">=<\/span><span class=\"token\" style=\"color:rgb(247, 140, 108)\">2021<\/span><span>-02-03T06:47:28+0000 <\/span><span class=\"token assign-left\" style=\"color:rgb(214, 222, 235)\">age<\/span><span class=\"token\" style=\"color:rgb(127, 219, 202)\">=<\/span><span>3w6d23h\n<\/span><\/code><\/pre>\n<\/div>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"compatibility\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"compatibility permalink\" href=\"#compatibility\"><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>Compatibility<\/h2>\n<p class=\"chakra-text css-gi02ar\">Doing a major release so close to a hard fork is <strong><em class=\"chakra-text css-0\">less than desired<\/em><\/strong>, to say the least. Unfortunately, shipping all the large features for the next generation Geth took 2 months longer than we&#8217;ve anticipated. To try and mitigate production problems that might occur from the upgrade, <strong>almost all new features<\/strong> can be toggled off via CLI flags. There is still 6 weeks left until the currently planned mainnet block, to ensure you have a smooth experience. Nonetheless, <strong><em class=\"chakra-text css-0\">we apologize for any inconveniences in advance<\/em><\/strong>.<\/p>\n<p class=\"chakra-text css-gi02ar\">To revert as much functionality as possible to the v1.9.x feature-set, please run Geth with:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;snapshot=false<\/span> to disable the snapshot acceleration structure and snap sync<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;txlookuplimit=0<\/span> to keep indexing all transactions, not just the last year<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;cache.preimages<\/span> tp keep generating and persisting account preimages<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;rpc.allow-unprotected-txs<\/span> &#8211; to allow non-replay-protected signatures<\/li>\n<li class=\"css-0\"><span class=\"chakra-text css-ons8vw\">&#8211;usb<\/span> &#8211; to reenable the USB wallet support<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Note, the <span class=\"chakra-text css-ons8vw\">eth_protocolVersion<\/span> API call is gone as it made no sense. If you have a <strong>very good reason<\/strong> as to why it&#8217;s needed, please reach out to discuss it.<\/em><\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"epilogue\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"epilogue permalink\" href=\"#epilogue\"><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>Epilogue<\/h2>\n<p class=\"chakra-text css-gi02ar\">As with previous major releases, we\u2019re really proud of this one too. We&#8217;ve delayed it quite a lot, but we did it in the name of stability to ensure that all the sensitive features are tested as well as we could. We&#8217;re hopeful this new release family will open the doors to a bit more transaction throughput and a bit lower fees.<\/p>\n<p class=\"chakra-text css-gi02ar\">As with all our previous releases, you can find the:<\/p>\n<\/div>\n<p><br \/>\n<br \/><a href=\"https:\/\/blog.ethereum.org\/en\/2021\/03\/03\/geth-v1-10-0\">Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Oh wow, it&#8217;s been a while&#8230; over 1.5 years since we&#8217;ve released Geth v1.9.0. We did do 26 point releases in that time frame (about one per three weeks), but pushing out a major release is always a bit more special. The adrenaline rush of shipping new features, coupled with the fear of something going [&hellip;]<\/p>\n","protected":false},"author":6,"featured_media":0,"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-18188","post","type-post","status-publish","format-standard","hentry","category-ethereum"],"_links":{"self":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/18188","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=18188"}],"version-history":[{"count":0,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/18188\/revisions"}],"wp:attachment":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media?parent=18188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/categories?post=18188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/tags?post=18188"},{"taxonomy":"kronos_expire_date","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/kronos_expire_date?post=18188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}