Ethereum Blog

Geth 1.7 – Megara

Introduction

user

Péter Szilágyi


LATEST POSTS

Geth 1.6 – Puppeth Master 14th April, 2017

Whoa… Geth 1.5 17th November, 2016

announcement

Geth 1.7 – Megara

Posted on .

The Go Ethereum team is proud to announce the next release family of Geth, the first incarnation focusing on laying the groundwork for the upcoming Metropolis hard forks (Byzantium and Constantinople), consisting of 125+ code contributions for various parts of the project.

Byzantium fork

The current incarnation of Geth contains all the Byzantium EIPs implemented and also features the fork block number 1,700,000 for the Ropsten testnet transition. The block numbers for Rinkeby and the main Ethereum network will be finalized when Ropsten is deemed stable.

You can find details about individual protocol updates at the following locations:

Performance optimizations

Aside from the Byzantium hard fork, the 1.7 release series of Geth is aimed to focus primarily on performance improvements. The first release of the family already packs a heavy punch with two database schema modifications resulting in significant optimizations:

  • Transaction and receipt storage was completely reworked, cutting the data storage requirements of a fast synced node in half, from 26.3GB to 14.9GB at the time of the implementation (#14801).
  • EVM log storage and indexing was completely reworked, cutting the filtering time of the entire chain for contract events by 2-3 orders of magnitude, from minutes to under a second (#14522, #14631).

Some work-in-progress updates that appear in the next releases include:

  • Upgrading the base peer-to-peer protocol used by all Ethereum sub-protocols, cutting the bandwidth needed for a fast sync from 33.6GB to 13.5GB (#15106). This upgrade will improve the general bandwidth requirement of the network as well as light clients too.
  • Introducing a more sophisticated memory caching for state tries, reducing disk IO by a couple orders of magnitude. Exact numbers are pending a final implementation (#14952).

Trezor wallets

About this time last year we introduced support for the Ledger hardware wallet. Due to popular demand, we’ve now expanded on hardware wallet support to include the Trezor (#14885).

Note that the Trezor is more complicated then the Ledger as it requires a PIN-unlock sent from the communicating machine instead of directly input by the user. As such, when a user plugs in a Trezor, Geth will print:

New wallet appeared, failed to open url=trezor://0003:0007:00 err="trezor: pin needed"

The Geth console can be used to unlock the Trezor by invoking personal.openWallet(url), which will request the user to enter the shuffled PIN code and send that over to the Trezor for verification:

> personal.openWallet("trezor://0003:0007:00")

Look at the device for number positions

7 | 8 | 9
--+---+--
4 | 5 | 6
--+---+--
1 | 2 | 3

Please enter current PIN:

INFO [08-10|11:58:06] New wallet appeared url=trezor://0003:0007:00 status="Trezor v1.5.0 'Hi' online"

For details on how to interact with the Trezor from the JSON-RPC APIs, please consult the PR description.

Transaction journal

In the 1.6.x release family of Geth we introduced a new transaction pool to avoid propagation issues due to minimum gas-price requirements. This new pool accepted all transactions regardless of pricing, and always kept the best paying 4K of them, discarding the cheaper ones.

The new pool features a special exemption mechanism for local accounts so that a user’s own transactions are always prioritized over remote ones, even if they are under-priced compared to everyone else’s. This ensures that cheap transactions don’t get flushed out of the network during heavy usage (e.g. ICO) as long as the originating node remains online.

Geth 1.7.0 takes this protective measure a step forward by journaling all locally created transactions to disk, and loading them back up on a node restart. This ensures that even if the originating node goes offline, cheap transactions still have a chance to be included when the node comes back (#14784).

The transaction journal can be an enormous help for node operators during software upgrades by not having to worry about local transactions going missing. Furthermore, the journal also acts as a resiliency mechanism against node crashes, ensuring that no transaction data is lost.

Rinkeby updates

There have been a lot of fine-tuning of Puppeth and Rinkeby over the course of this release, such as better ethstats logging to detect malicious reporters and IP address blacklisting to deny access for them.

The Rinkeby testnet also proved vital in finding and and fixing a transaction pool event race that caused a lot of headaches around lost transactions and/or duplicate nonce assignments. All such known errors have now been fixed (#15085).

Lastly we’re extremely happy to announce that Infura became an active player in the Rinkeby test network by aiding the community both with their own bootnode as well as running an authorized signer node. This should make the Rinkeby network even more robust and resilient.

Closing remarks and important note to users

Geth 1.7.0 contains a lot of bug fixes and we consider it our best release until now, however we urge everyone to exercise caution with the upgrade and monitor it closely afterwards as it does contain non-trivial database upgrades.

Furthermore, we’d like to emphasize that the upgraded database cannot be used by previous versions of Geth. Our recommendation for production users it to sync from scratch with Geth 1.7.0, and leave the old database backed up until you confirm that the new release works correctly for all your use cases.

For a full rundown of the changes please consult the Geth 1.7.0 release milestone.

As always, binaries and mobile libraries are available on our download page.

profile

Péter Szilágyi

There are no comments.

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

View Comments (0) ...
Navigation