06 May 18:48

oneeman

2a458af

This release brings to celo-blockchain an exciting new feature from upstream: state snapshots. Snapshots greatly improve performance in the presence of a large blockchain state. This will make possible increased throughput and reduce the impact of the growing state size on performance in the future. Later on, it will also enable the much faster snap sync method introduced upstream, but this in not included in this release.

The snapshot functionality in its initial state was included in celo-blockchain v1.3.0, but not enabled by default. v1.3.1 pulls in from upstream subsequent improvements and bugfixes to the snapshots functionality, and enables snapshots by default (#1533).

For more context about snapshots, see the Ethereum post about snapshots.

If you are upgrading from versions older than v1.3.0-stable, please also review the 1.3.0-stable release notes.

Docker images:

geth: us.gcr.io/celo-org/geth:1.3.1
geth-all: us.gcr.io/celo-org/geth-all:1.3.1

Assets 3

19 Apr 19:25

oneeman

v1.3.0

e7acdda

Celo-Blockchain Release 1.3.0-stable

Overview

Celo-blockchain v1.3.0-stable is the first mainnet release of the v1.3.x release branch. It includes considerable changes and improvements relative to v1.2.x.

Most importantly, it sets the activation block numbers for the Churrito and Donut hard forks on mainnet and Alfajores. As a consequence, all mainnet and Alfajores node operators must upgrade their nodes prior to the hard forks' activation. Unupgraded nodes will be unable to stay synced to the network after hard fork activation. Churrito and Donut are scheduled to activate together as follows:

Alfajores: block number 4960000 (est. May 4th, 2021)
Mainnet: block number 6774000 (est. May 19th, 2021)

See below for upgrade instructions. Additionally, if you use the JSON RPC API, see below regarding some small breaking changes in the behavior of eth_call.

Release highlights:

The biggest and most important change in v1.3.0 is the implementation and activation of the Donut hard fork, which includes the following CIPs:

In addition to the Churrito and Donut hard fork, the main changes are: merges from upstream (go-ethereum), optimizations to block creation, support for signing typed data (CIP-8), an exciting new tool called mycelo, and the renaming of celo-blockchain's Go module from github.com/ethereum/go-ethereum to github.com/celo-org/celo-blockchain. See below for more details.

Docker images:

geth: us.gcr.io/celo-org/geth:1.3.0
geth-all: us.gcr.io/celo-org/geth-all:1.3.0

Upgrading notes

These notes assume you are upgrading from v1.2.x. If you are upgrading from versions v1.1.x or v1.0.x, please also check the release notes from v1.1.x and v1.2.x as appropriate to your case.

Review the breaking changes listed below in the "Break Changes" section, and update your node configuration and related applications as appropriate. In particular, even users who do not run their own node but rather use 3rd party nodes via the JSON RPC API should check the breaking changes section below for the changes affecting the behavior of eth_call in some special cases.
Client flag deprecations:
- The following flags had no effect (the corresponding values were instead being taken from the genesis config) and so are being deprecated (see #1288 and #1136). If you have been using them, you should remove them:
  - --istanbul.requesttimeout
  - --istanbul.blockperiod
  - --istanbul.proposerpolicy
  - --istanbul.lookbackwindow
If you were using the --txpool.globalslots flag to limit the size of the transaction pool, you may safely remove that flag. This flag was necessary due to inefficiencies in the transaction pool and in block production which have been fixed in v1.3.0-stable (see below for more details)
If you want to make use of CIP-28 (split etherbase), you can do so, after Donut has been activated, by using --miner.validator and --tx-fee-recipient instead of --etherbase. It is possible to use the new flags before Donut is activated, but this would not have the desired effect since that depends on CIP-28 being active already. Setting the two flags to different addresses before Donut activation will lead to warnings being logged to inform you that they are not yet having the intended effect and so is not recommended.
Confirming that your node is set to activate Churrito and Donut. In the case of testnets such as Alfajores and Baklava, hard fork activation depends on using the corresponding flags (--alfajores or --baklava). Therefore, if you are running a node on Alfajores or Baklava, be sure to specify the corresponding flag if you aren't already. In the case of mainnet, no flag is needed, and hard fork activation will be set without any action needed besides upgrading. If you wish to verify that it has been set, there are two ways:
1. When the node starts up, it logs the activation blocks numbers for all hard forks. For example, a mainnet node running v1.3.0 will show the following, indicating the block number at which Churrito and Donut will activate:
```
INFO [04-14|14:59:24.238] Initialised chain configuration          config="{ChainID: 42220 Homestead: 0 DAO: <nil> DAOSupport: true EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 Constantinople: 0 Petersburg: 0 Istanbul: 0 Churrito: 6774000, Donut: 6774000, Engine: istanbul}"
```
2. While the node is running, you can see the node's hard fork activation configuration among the results of the admin_nodeInfo RPC API method, under protocols > istanbul > config. If running the admin API, you can access this either via an RPC request or from the geth attach console using admin.nodeInfo (or admin.nodeInfo.protocols.istanbul.config to get just the relevant parts). The results will indicate the block numbers at which Churrito and Donut are set to activate, e.g.
```
> admin.nodeInfo.protocols.istanbul.config
{
  FullHeaderChainAvailable: true,
  byzantiumBlock: 0,
  chainId: 42220,
  churritoBlock: 6774000,
  constantinopleBlock: 0,
  daoForkSupport: true,
  donutBlock: 6774000,
  eip150Block: 0,
  eip150Hash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  eip155Block: 0,
  eip158Block: 0,
  homesteadBlock: 0,
  istanbul: {
    blockperiod: 5,
    epoch: 17280,
    lookbackwindow: 12,
    policy: 2,
    requesttimeout: 3000
  },
  istanbulBlock: 0,
  petersburgBlock: 0
}
```

Breaking changes (relative to v1.2.x)

Besides the backwards incompatibility inherent in a hard fork (that unupgraded clients will not function properly after the hard fork is activated), there are some breaking changes in this release:

The default value for --light.serve has been changed to zero, so that serving light clients is now opt-in rather than opt-out. As a result, if you wish your node to serve light clients, you must use the --light.serve flag with a nonzero value. Note that the documentation on running a full node already included this flag, so if you were following the instructions there you don't need to change anything. On the other hand, if you do not wish to serve light clients and have been using --light.serve 0, you will no longer need to include that flag (but you need not remove it, either).
RPC calls to eth_call which don't specify a from address will now default the from field to the zero address. Previously, they defaulted to the node's first account if there was one (and the zero address otherwise). This change was adopted as part of merging changes from upstream. What this means is that, if you were making calls whose result depends on the from address, you must specify the from address yourself. See #1251 and ethereum/go-ethereum#20685 for more context.
RPC calls to eth_call which specify a non-zero gas price will fail if the from account does not have sufficient funds to pay the transaction fee. This was already the case if you were specifying a non-Celo fee currency, but constitutes a breaking change if the fee currency was set to null (meaning Celo). The reason is that, prior to this change, there was a hack in place (inherited from upstream) which modified the account's balance (in the ephemeral EVM instance, not on-chain) before processing the call, to ensure it wouldn't fail due to not being able to pay for fees. This hack led to incorrect results in calls which depend on the account's balance. This has been changed upstream and the change included in celo-blockchain as part of merging. See #1251 and ethereum/go-ethereum#20783 for more context. As a user of eth_call, we recommend you omit the gas price (which would then default to zero), or specify a gas price of zero. If you wish to simulate what would happen with a certain non-zero gas price, you may specify it, but be aware that this will lead to the call failing if the account does not have sufficient funds to pay the fees.
Validators running behind a proxy, if wishing to use Celostats, must include the --celostats flag on the validator as well on the proxy. This is as described in [the docs](https://docs.celo.org/getting-started/ma...

Assets 3

08 Apr 22:03

oneeman

1.3.0-beta.3

f34d95a

Celo-Blockchain Release 1.3.0-beta.3 Pre-release

Pre-release

This is a follow-up to previous 1.3.0 beta releases, intended only for Baklava. If you are already one of the 1.3.0 beta versions, we recommend you upgrade, but it is not required. If you are still running a version older than v1.3.x, you must upgrade, as Donut activation is set for April 13th, and older versions will cease to function properly once Donut activates. See the v1.3.0-beta release notes for more details.

Relative to v1.3.0-beta.2, it adds:

A fix for the EIP-2464 implementation. This was a new bug inherited from upstream in the EIP-2464 implementation, which caused problems on one of the Baklava Forno nodes. This release includes a fix for it, cherry-picked from upstream. Big thanks to @zviadm for reporting the problem!
Celostats reliability: nodes will be better able to stay connected to Celostats, and validators behind proxies will now report both the validator's and the proxy's versions (rather than just the proxy's), giving greater visibility into the network.
Mining optimization for large transaction pools: in combination with the exchange rate caching introduced in v1.2.5 and v1.3.0-beta.2, this eliminates large transaction pool size as a bottleneck during block construction.
Set the default pending transaction pool size back to 4096. v1.2.5 and v1.3.0-beta.2 changed this default from 4096 to 2048 due to remaining inefficiencies in mining with large transaction pools. With the new mining optimization in this release, this is no longer necessary, and so we are setting the default back to 4096.

Docker images:

geth: us.gcr.io/celo-org/geth:1.3.0-beta.3
geth-all: us.gcr.io/celo-org/geth-all:1.3.0-beta.3

Assets 3

06 Apr 14:54

oneeman

v1.3.0-beta.2

ccb791f

Celo-Blockchain Release 1.3.0-beta.2 Pre-release

Pre-release

This is a follow-up to v1.3.0-beta, intended for Baklava only. It adds the changes from v1.2.5:

#1478 Cache currency comparisons when building block
Decrease default tx pool size from 4096 to 2048

If you're upgrading from v1.2.x, please also see the release notes for v1.3.0-beta.

Docker Images

geth: us.gcr.io/celo-org/geth:1.3.0-beta.2
geth-all: us.gcr.io/celo-org/geth-all:1.3.0-beta.2

Assets 3

04 Apr 21:23

mcortesi

v1.2.5

cc43ad2

Celo-blockchain Release 1.2.5

This is a small release, with a big impact. It greatly improves the transaction throughput capability of the network; by adding a exchange rate cache when selecting transaction for building a block.

Changes are:

#1478 Cache currency comparisons when building block
Decrease default tx pool size from 4096 to 2048

Docker Images

geth: us.gcr.io/celo-org/geth:1.2.5
geth-all: us.gcr.io/celo-org/geth-all:1.2.5

Assets 3

25 Feb 21:12

oneeman

v1.2.3

6a95461

Celo-Blockchain Release 1.2.3-stable

This is a security release which fixes a couple of bugs in the transaction pool logic. These bugs could lead to transactions getting stuck in the transaction pool when they should be removed or should not have been admitted in the first place (due to being unmineable), and could have been exploited in a denial of service attack crowding out legitimate transactions. Nodes running a patched version (1.2.3 or 1.1.3) would not be affected and would have been able to include legitimate transactions in blocks as usual. Such an attack would not have created any risk of loss of funds or of consensus failure.

If you are upgrading from versions older than v1.2.x, please also see the v1.2.2-stable release notes.

Docker Images

geth: us.gcr.io/celo-org/geth:1.2.3
geth-all: us.gcr.io/celo-org/geth-all:1.2.3

Assets 3

25 Feb 21:12

oneeman

v1.1.3

2032045

Celo-Blockchain Release 1.1.3-stable

If you are using v1.2.2, please upgrade to v1.2.3 instead. We are making v1.1.3 available for any users who have not yet upgraded to v1.2.x and do not wish to do so at this time.

Docker Images

geth: us.gcr.io/celo-org/geth:1.1.3
geth-all: us.gcr.io/celo-org/geth-all:1.1.3

Assets 3

20 Jan 15:09

trianglesphere

v1.2.2

dba095d

Celo-Blockchain Release 1.2.2-stable

The major changes in the release are the addition of support for multiple proxies (#1026) and the ability to hotswap validators (#1141). There are a couple changes brought in from upstream geth to improve the dial scheduler (#1192) and improve the handling of chain repairs (#1163). This also includes several bug fixes to improve uptime: proxied validators not properly updating the proxy assignments on epoch blocks (#1240), an issue randomness beacon that could cause nodes to miss proposing and signing blocks (#1278), and fix to properly clear the message backlog (#1300).

Upgrading Notes

The communication protocol between the validator and it's proxies implemented in release 1.2 is NOT backwards compatible to the pre-1.2 protocol. If the proxy or validator is being upgraded to 1.2, then both need to be upgraded to that version.
Validators and proxies using release 1.2 are still compatible with remote nodes running previous versions.
If you are upgrading from a version earlier than 1.1.0, see 1.1.0 release notes for changes made to remove the geth init step.

Command Line Changes

--ethstats is being deprecated in favor of --celostats. --ethstats will be removed in a future version.
--proxy.proxyenodeurlpair is being deprecated in favor of --proxy.proxyenodeurlpairs. --proxy.proxyenodeurlpair will be removed in a future version. Refer to multi-proxy docs for usage.
--istanbul.replica has been added. Refer to hotswap docs for usage.

Geth Management RPC Additions

istanbul.start() and istanbul.startAtBlock()
istanbul.stop() and istanbul.stopAtBlock()
istanbul.replicaState and istanbul.validating as new fields.
istanbul.addProxy(internal enode, external enode)
istanbul.removeProxy(internal enode)
istanbul.proxies and istanbul.proxiedValidators as new fields applicable to validators and proxies, respectively.

Quick Links:

Notable Changes:

Multiproxy (#1026)
Hotswap Validators (#1141)
Chain repair fixes (#1163)
Cherry pick new dial scheduler from upstream (#1192)
Fix disconnecting unelected validators in ReplaceValidatorPeers() (#1191)
Celo1 hard fork field added to config (#1173)
Make primary protocol concept apply to specific versions of istanbul (#1201)
Make static dials subject to the maxActiveDials limit. (#1202)
Fix goroutine leak in celostats login. (#1206)
Security fix with Golang 1.14.12 (#1222, #1226)
Fixes an issue where passing the flag --ethstats or --celostats causes the node to crash (#1218)
Fixes a LES vulnerability from upstream (#1267)
Fixes an issue with the randomness beacon that could cause nodes to miss proposing and signing blocks (#1278, #1289)
Properly clears the message backlog (#1300)

Changes Since 1.2.0

Security fix with Golang 1.14.12 (#1222, #1226)
Fixes an issue where passing the flag --ethstats or --celostats causes the node to crash (#1218)
Fixes a LES vulnerability from upstream (#1267)
Fixes an issue with the randomness beacon that could cause nodes to miss proposing and signing blocks (#1278, #1289)
Properly clears the message backlog (#1300)

Docker Images

geth: us.gcr.io/celo-org/geth:1.2.2
geth-all: us.gcr.io/celo-org/geth-all:1.2.2

Assets 3

11 Jan 22:28

trianglesphere

v1.2.2-beta.2

b972aa3

Celo Blockchain v1.2.2-beta.2 Pre-release

Pre-release

This is a patch update to 1.2.2-beta to fix an issue with the randomness beacon that could cause nodes to miss proposing and signing blocks (#1278).

Docker Images

geth: us.gcr.io/celo-org/geth:1.2.2-beta.2
geth-all: us.gcr.io/celo-org/geth-all:1.2.2-beta.2

Assets 3

15 Dec 20:42

oneeman

v1.1.2

239d0b4

Celo Blockchain 1.1.2

This is a patch release with two changes:

Fix a denial-of-service vulnerability in the LES server. See GHSA-r33q-22hv-j29q for details. PR: #1266. If you wish your node to serve light clients, you should upgrade to this release as soon as possible. If you don't wish your node to serve light clients, you need not upgrade, so long as you are using the --light.serve 0 flag (which means your node won't run the LES server).
Activate the Churrito hard fork on Baklava. Churrito is, at this time, already activated on Baklava with version 1.2.2-beta. This backports Churrito's activation on Baklava to v1.1.x, so that this release will work with Baklava now that the hard fork has been activated there. Note that this change only has any effect if you're connecting to Baklava using the --baklava flag. PRs: #1173 and #1224 .

Docker Images

geth: us.gcr.io/celo-org/geth:1.1.2
geth-all: us.gcr.io/celo-org/geth-all:1.1.2

Assets 3

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Docker images:

Overview

Upgrading notes

Breaking changes (relative to v1.2.x)

Docker Images

Releases: celo-org/celo-blockchain

Celo-Blockchain Release 1.3.1-stable

Docker images:

Celo-Blockchain Release 1.3.0-stable

Overview

Upgrading notes

Breaking changes (relative to v1.2.x)

Celo-Blockchain Release 1.3.0-beta.3

Celo-Blockchain Release 1.3.0-beta.2

Celo-blockchain Release 1.2.5

Docker Images

Celo-Blockchain Release 1.2.3-stable

Celo-Blockchain Release 1.1.3-stable

Celo-Blockchain Release 1.2.2-stable

Celo Blockchain v1.2.2-beta.2

Celo Blockchain 1.1.2