{"id":18549,"date":"2026-03-22T15:52:45","date_gmt":"2026-03-22T15:52:45","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/03\/22\/geth-1-8-iceberg%c2%b9-ethereum-foundation-blog\/"},"modified":"2026-03-22T15:52:45","modified_gmt":"2026-03-22T15:52:45","slug":"geth-1-8-iceberg%c2%b9-ethereum-foundation-blog","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/03\/22\/geth-1-8-iceberg%c2%b9-ethereum-foundation-blog\/","title":{"rendered":"Geth 1.8 – Iceberg\u00b9 | Ethereum Foundation Blog"},"content":{"rendered":"


\n<\/p>\n

\n

After waaay too much time under development, we’re proud to finally announce version 1.8.0 of the Go Ethereum client: Iceberg<\/a>! The release fixes a lot of pain points felt by the community and ships a few notable new features, tallying up to ~170 modifications<\/a>!<\/p>\n

Please note, this release introduces a few breaking changes that may affect certain power users! If you are running a production setup, make sure you read the “Breaking changes” section at the end of this blog post!<\/span><\/strong><\/p>\n

<\/g><\/svg><\/a>Client synchronization<\/h2>\n

A huge amount of work went into this release that isn’t immediately visible, rather they’re under the hood changes to make everybody’s life just a little bit more pleasant. We’ve tried to address many of the issues our users were reporting around syncing and block processing. We’re not quite where we’d like to be, but the experience with v1.8.0 should blow all previous releases out of the water.<\/p>\n

<\/g><\/svg><\/a>Reliable light client<\/h3>\n

Geth v1.7.3 \u2013 released shortly after Devcon3 \u2013 was the first release to ship version 2 of the light client protocol. It was meant to be a huge improvement over version 1, finally enabling log filtering from Ethereum contracts. It broke the light client.<\/p>\n

The breakage was massive, with multiple experimental protocols (discovery v5, light client v2) playing badly with each other. Geth v1.7.3 tried to advertise both les\/1<\/span> and les\/2<\/span>, which conflicted in the discovery, breaking both; les\/2<\/span> servers would crash serving some light client requests; and discovery v5, running behind an undocumented port, didn’t help either.<\/p>\n

Geth v1.8.0 tries to pick up all the pieces and make les\/2<\/span> what it was supposed to be in v1.7.3. We’ve dropped support for les\/1<\/span> in the discovery, so there should be no more problems finding peers while we iron out the kinks. Light servers have been polished up to be more robust with existing connections, as well as extended to cleanly separate eth<\/span> and les<\/span> peers, preventing server side starvation. Version 4 and 5 of the discovery protocols are also running on the same port, and will from now on better avoid issues with firewalls or NAT traversals.<\/p>\n

With all of the above changes, the light client in v1.8.0 should find servers within a few seconds from startup, and synchronizing the mainnet should finish within a minute<\/strong>. Since light clients rely on charitable nodes serving them, we ask anyone running non-sensitive<\/strong> full nodes with spare capacity to consider enabling the light server to help people with less capable hardware.<\/p>\n

<\/g><\/svg><\/a>Reliable fast sync<\/h3>\n

For a long time now we’ve been receiving reports from users experiencing fast sync hangs with a “stalling peer” error message, or that trying to synchronize on an average machine often crashes with an “out of memory” error. These issues have become more and more prevalent as the Ethereum mainnet grew, yet they have been elusive to us due to their rare occurrence.<\/p>\n

The heavy internal rewrites allowed us to reliably reproduce and fix these issues. The hang was a very rare race that occurred when state sync restarted; the fix for which is amusing<\/a> given that it took us a year<\/em> to catch. The memory issue was also fixed by aggressively capping the amount of memory that sync may consume.<\/p>\n

The final result of these optimizations is that fast sync became stable again. From one perspective there are no more hangs, so you don’t have to constantly monitor the sync progress. From the other perspective memory usage is constant, so there’s no need for machines with insane RAM.<\/p>\n

\"geth-v1.8.0-sync-memory\"<\/a><\/p>\n

The above chart plots the memory usage during mainnet fast sync of two m4.2xlarge<\/span> Amazon instance types (purple = Geth 1.8, blue = Geth 1.7). At the time of writing, fast sync completes in around 3 hours on these instance types. The exponential growth of Ethereum however resulted in a state trie of around 85 million nodes, the import of which can take even half a day on end-user laptops (with an SSD). Hopefully 1.9 will tackle this issue.<\/p>\n

<\/g><\/svg><\/a>Initial state pruning<\/h3>\n

Ethereum organizes its state into a gigantic trie data structure. At the bottom \u2013 in the leaves we have the accounts \u2013 and on top of the accounts we have an 16th order Merkle trie cryptographically guaranteeing forgery resistance. We have one of these giant tries for each and every block, the latest of which weighing at around 85 million nodes. Most of these nodes are common between subsequent blocks, but every new block does add a few thousand new nodes into the trie.<\/p>\n

If we would like to know what our balance was years ago, we’d have to maintain every single version of this Merkle trie since the genesis block, which could total to almost 1TB of data currently. In reality almost nobody cares about historical data \u2013 as long as it can be recomputed \u2013 rather only about the recent<\/strong> state of the network. Fast sync gets you “quickly” to the recent state, but blindly piling blocks on top will forever use more and more disk space.<\/p>\n

The important property of the Merkle tries to be aware of is that whilst every new block adds thousands of new nodes, thousands of old ones become obsolete at the same time. If we could easily delete these obsolete ones, disk growth would be significantly capped. However, once the data is on disk, it’s extremely expensive to get rid of them.<\/p>\n

Geth v1.8.0 takes an initial stab at the problem by introducing an in-memory cache in which to store the recent trie nodes. As long as the nodes are in memory, they are cheap to reference count and garbage collect. Instead of writing each trie node to disk, we keep it around as long as possible, hoping that a future block will make it obsolete and save us a database write.<\/p>\n

\"geth-v1.8.0-pruning\"<\/a><\/p>\n

Geth v1.8.0 by default will use 25% of the user’s cache allowance (–cache<\/span>) for trie caching and will flush to disk either if the memory allowance is exceeded, or if block processing time since the last flush exceeds 5 minutes. This doesn’t completely solve database growth just yet, but looking at the disk stats between v1.8 (purple) and v1.7 (blue) in the course of a single week, pruning makes a huge difference.<\/p>\n

<\/g><\/svg><\/a>Transaction tracing<\/h2>\n

Pretty much since forever, Geth supported tracing transactions<\/a> by dumping the executed opcodes. These dumps can be invaluable for finding consensus issues among clients, but they aren’t the nicest<\/a> to look at. Although post-processing these traces is possible, it’s a waste of resources to collect so much data just to throw most of it away.<\/p>\n

<\/g><\/svg><\/a>Custom tracing scripts<\/h3>\n

The v1.5 release family of Geth introduced a new way to trace transactions by allowing users to write custom JavaScript scripts that run within the node while tracing. Instead of producing pre-defined traces, users could gather whatever data they deemed useful without having to export everything else. Although we did use it internally, the feature never really graduated to a useful and robust enough state for wide spread use.<\/p>\n

Geth v1.8.0 however completely revamps the custom tracing support. For starters, we’ve replaced the ottovm<\/span> we used previously to run the tracers, to duktape<\/span>, resulting in a 5x speed increase. We no longer require the state upon which a transaction relies to be present to trace it, rather the tracer can reconstruct anything missing from historical states (bearing the cost of re-executing the blocks in memory). Furthermore, when tracing multiple transactions at once (i.e. an entire block), those are executed concurrently, slashing tracing time by the number of available CPU cores.<\/p>\n

All said and done, writing a custom tracer is complicated<\/strong>, taking up a significant time even for veteran Ethereum developers. As such, we’ve made the decision to provide a few tracers out of the box<\/a> for users to use, and potentially improve. We eagerly await any community improvements to these, or even the addition of brand new ones!<\/p>\n