Introduction

A month and a half after the release of Gubiq 2.2, the Ubiq developers are proud to present to you Gubiq 2.3! We are very grateful to the loyal community in upgrading and helping us to test this release.

Gubiq 2.3 is based on the last release of the upstream Geth 1.8.x branch and contains around 1505 commits merged from upstream Go-Etheruem.

This is an optional release but highly recommended.

The next release of Gubiq will require further internal testing and will be our hard fork release according to the published Gubiq Roadmap.

Depending on how testing goes we may consolidate the next release so that it contains both the Byzantium hard fork and the Constantinople+St. Petersburg hard fork which means there will be only 1 hard fork. There are some benefits to this including reduced coordination and reduced ecosystem interruptions.

Gubiq 2.3

Gubiq 2.3 full node is now available:

https://github.com/ubiq/go-ubiq/releases/tag/v2.3.0

Note that this release introduces state pruning and upgrades the on-disk database so it cannot be used by previous versions of Gubiq once upgraded (you will need to re-sync from scratch to downgrade to an older version of Gubiq).

All services which run Ubiq nodes are encouraged to upgrade but this is considered an optional upgrade as there are no hard fork changes. Fusion wallet will be updated to point to the latest version and you will automatically be prompted to upgrade.

Changes

Initial State Pruning

Gubiq v2.3 introduces 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.

Gubiq v2.3 by default will use 25% of the user’s cache allowance ( --cache ) 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 pruning makes a huge difference.

Trie pruning

Trie pruning is enabled on all --syncmode variations (including --syncmode=full ). If you are running an archive node where you would like to retain all historical data, you should disable pruning via --gcmode=archive .

“Full” will prune historic state, “archive” will do no pruning, so there are some more options in terms of running nodes.

Fast sync — validation of headers only with full pruning:

--syncmode=fast

Full validation with pruning:

--syncmode=full --gcmode=full

Full validation with no pruning:

--syncmode=full --gcmode=archive

A fast sync or full sync with pruning will come out with chaindata at ~2GB (this is a full copy of the chain but historic states pruned). A full archive sync (no pruning) will come out at around 12.3GB.

Most users only operate at the head of the chain so have no need to keep historic state (it is used for retrieving values from the past, for example the address balance at block 2000, or contract state at block 10000.)

Support for Go 1.12

All binaries have been built with the latest Go 1.12 and compatibility changes have been integrated.

Enjoy!