Celo-Blockchain Release 1.5.0-beta.1

v1.5.0-beta.1 is the Baklava-only release of v1.5.0. After testing on the Baklava testnet, it will be followed by v1.5.0-stable which will be intended for mainnet and Alfajores

The baklava activation block is 9195000 targeting an activation at 12:45 PM PDT on Wednesday December 15th.

The biggest and most important change in v1.5.0 is the implementation and activation of the Espresso hard fork with the following CIPS.

• CIP-43: Block Context
• CIP-47: Increased round change timer for early rounds in IBFT
• CIP-45: Relax canPayFee condition for non-native tokens
• CIP-50: Allow unprotected transactions

Relative to v1.4.0 version 1.5.0 has the following breaking changes

Please note that reverting to Celo blockchain v1.4.0 or prior after upgrading to v1.5.0 is not possible without a resync because the blockchain database layout has changed. Please take a backup of the data directory to be able to downgrade.

Flag Changes
The following previously deprecated flags have been removed.

--pprofport value                  use --pprof.port
--pprofaddr value                  use --pprof.addr
--memprofilerate value             use --pprof.memprofilerate
--blockprofilerate value           use --pprof.blockprofilerate
--cpuprofile value                 use --pprof.cpuprofile
--bootnodesv4                      use --bootnodes
--bootnodesv5                      use --bootnodes

The following flags have been removed

--vm.evm                           no substitute
--vm.ewasm                         no substitute
WHISPER (EXPERIMENTAL) OPTIONS
--shh                              no substitute
--shh.maxmessagesize value         no substitute
--shh.pow value                    no substitute
--shh.restrict-light               no substitute

The following flags have been added

--datadir.minfreedisk
--usb
--mainnet
--txlookuplimit
--light.nosyncserve
--cache.preimages
--http.rpcprefix
--ws.rpcprefix
--bloomfilter.size

The following flags have been deprecated and will be removed in a future release.

--nousb                            USB defaults to off. Use --usb to enable
--backtrace                        use --log.backtrace
--debug                            use --log.debug
--consoleformat                    use --log.json (true for JSON, false for Term output format)

Other:
We are aware of an issue when syncing with syncmode=light, but are releasing this to start testing the other changes for the hardfork.

Docker Images

geth: us.gcr.io/celo-org/geth:1.5.0-beta.1
geth-all: us.gcr.io/celo-org/geth-all:1.5.0-beta.1

Celo-Blockchain Release 1.4.0-stable

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

This new version includes the merges of go-ethereum versions from 1.9.14 to 1.9.19. Please refer to go-ethereum release notes if you are interested in a detailed list of changes from this versions.

Highlighting two of the changes that may be considered or particularly interesting:

• Refactor on the http/ws server that limits the path where websocket server is listening to root (ethereum/go-ethereum#21441). This change can break any client that is connecting using websocket to any path different from /.
• Fix calculation and implementation of dial ratio and the max dialed connections limit (#1670).

In addition to these changes, this new version include a considerable number of improvements and bug-fixes, but it can be consider as a transition release in between the preparation for the next Expresso Hard Fork.

Docker Images

• geth: us.gcr.io/celo-org/geth:1.4.0
• geth-all: us.gcr.io/celo-org/geth-all:1.4.0

Celo-Blockchain Release 1.3.2-stable

This is a security release which updates the Go version used to compile celo-blockchain to v1.16.4, which is a security patch released yesterday, fixing a possible panic in net/http which could be triggered by a malicious server. See the Go v1.16.4 announcement for more details.

All node operators should upgrade to this version.

If you are upgrading from versions older than v1.3.1, please see also the v1.3.0 and v1.3.1 release notes as well.

Docker Images

• geth: us.gcr.io/celo-org/geth:1.3.2
• geth-all: us.gcr.io/celo-org/geth-all:1.3.2

Celo-Blockchain Release 1.3.1-stable

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

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:

• CIP 25: Ed25519 Precompile
• CIP 31: BLS Curve Operations on 12-381
• CIP 30: BLS Curve Operations on 12-377
• CIP 20: Extensible Hash Function Precompile
• CIP 21: Governable Lookback Window
• CIP 22: Epoch Snark Data
• CIP 26: Precompile for BLS
• CIP 28: Split etherbase
• CIP 35: Support for Ethereum-compatible transactions

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.

1. 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.
2. 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
3. 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)
4. 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.
5. 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...

Celo-Blockchain Release 1.3.0-beta.3

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:

1. 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!
2. 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.
3. 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.
4. 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

Celo-Blockchain Release 1.3.0-beta.2

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

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

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

Celo-Blockchain Release 1.1.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 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