7.0.5 (testnet)

Concordium node version 7.0.5 fixes a bug in the handling of smart contract names that could cause the node to crash.

This is a critical bug fix, and node runners should update as soon as possible.

Note: version 7.0.5 is initially released for testnet. Mainnet nodes should upgrade to version 6.3.2 instead, until it is released for mainnet.

Changes

• Fix inconsistent handling of valid contract names.

6.3.2

Concordium node version 6.3.2 fixes a bug in the handling of smart contract names that could cause the node to crash.

This is a critical bug fix, and node runners should update as soon as possible.

Note: version 6.3.2 is intended for mainnet. Testnet nodes should upgrade to version 7.0.5 instead.

Changes

• Fix inconsistent handling of valid contract names.

7.0.4

Concordium node version 7.0.4 contains support for protocol version 7. This protocol version introduces changes to stake cooldown behaviour, disables shielded transfers, reduces smart contract execution costs, adds new smart contract functionality, and redefines the block hashing scheme.

Changes

Protocol version 7 introduces the following changes:

• The cool-down behavior when the stake of a validator or delegator is reduced or removed is changed:

  • When stake is reduced, the reduction is immediately effective for future stake calculations, and the amount of the reduction is locked for a cool-down period. (Previously, the reduction was only effective after the cool-down period.)

  • Validators and delegators can make further changes to their stake while they already have stake in cooldown. This includes registering as a validator when the account was previously a delegator, or vice versa. (Previously, the account had to wait for the cool-down period to end before making further changes.)

• Shielded transfers are no longer supported in the protocol. It is still possible to unshield a previously shielded balance.

• Smart contract execution costs are reduced. This reflects a more efficient implementation of the smart contract execution engine introduced in this release.

• Smart contracts can now query the module reference and contract name of a smart contract instance.

• The block hashing scheme is redefined to better support light clients.

Additionaly, the node release includes a number of fixes and improvements:

• Logging around protocol updates is improved.

• Failed gRPC requests are now logged at DEBUG level.

• Fixed a bug where GetBakersRewardPeriod returns incorrect data.

• Fixed a bug where GetPoolInfo returns incorrect data.

• Fixed a bug where a configure-validator transaction that is rejected for having a duplicate aggregation key reports the old key of the validator, rather than the new (duplicative) key.

• Improved the behavior of the node in the event of an unrecoverable error in consensus.

6.3.1

6.3.1

Node version 6.3.1 is a bug-fix release. This fixes a rare but critical bug that can cause the chain to stop producing blocks.

Changes

• Fix a bug where a node may fail to produce a timeout certificate due to incorrectly computing the total weight of finalizers that have signed timeout messages.

6.3.0

6.3.0 is a maintenance release of the node with some robustness and performance improvements.

Changes

• Fix a bug where GetBlockPendingUpdates fails to report pending updates to the finalization
  committee parameters.
• Run GRPC queries in dedicated threads. This improves node resource management
  and increases responsiveness of the GRPC server in cases of high number of
  concurrent queries. To support this a new option --grpc2-max-threads
  (environment variable CONCORDIUM_NODE_GRPC2_MAX_THREADS) is
  added which specifies the number of threads that the node should use for
  processing gRPC requests. If not set this defaults to the number of (logical)
  CPUs.
• The option --grpc2-max-concurrent-streams now defaults to 200 from the
  previous unbounded value. This makes the node defaults safer.

6.2.3

Node version 6.2.3 removes V1 API, supports new "validator" terminology in place of "baker", and improves account state management to reduce memory and disk usage.

The node's public API is extended with a new DryRun endpoint that can simulate effects of sequences of transactions.

Changes

• The transaction table is only used for tracking next available account nonce
  for accounts that have non-finalized transactions. This reduces memory usage
  and startup time.

• The account map is now kept solely on disk in a separate lmdb database and it is no longer part of the internal block state database.
  This change results in less memory usage per account and a decrease in the growth of the database.

• Support validatorId in addition to bakerId in the credentials to start a validator.

• Add options CONCORDIUM_NODE_VALIDATOR_CREDENTIALS_FILE and
  CONCORDIUM_NODE_VALIDATOR_DECRYPT_CREDENTIALS that alias
  CONCORDIUM_NODE_BAKER_CREDENTIALS_FILE
CONCORDIUM_NODE_BAKER_DECRYPT_CREDENTIALS, respectively
  The latter two options are still available, but hidden in the help text.

• Remove V1 GRPC API from the node. This removes configuration options
  CONCORDIUM_NODE_RPC_SERVER_PORT, CONCORDIUM_NODE_RPC_SERVER_ADDRESS,
  CONCORDIUM_NODE_RPC_SERVER_TOKEN, CONCORDIUM_NODE_DISABLE_RPC_SERVER_NODE_ENDPOINTS
  and their command line equivalents.

• Add an additional health-check service to the V2 GRPC API.
  This service conforms to the standard GRPC health service API.

• New DryRun endpoint that allows simulating the execution of transactions.

6.1.7

Node 6.1.7 release adds improved node API, especially in relation to staking, and makes the node substantially more robust in certain scenarios.

In particular the node now remembers its peers across restarts, so it is less reliant on a bootstrapper.

The gRPC V2 API has also received a number of configuration options for limiting resources it is allowed to use, making the node more robust.

Detailed changes

• Add load-shedding to the V2 GRPC API. In particular, if at the time of the
  request the node is already handling more than
  CONCORDIUM_NODE_GRPC2_MAX_CONCURRENT_REQUESTS requests then the incoming
  request will be immediately rejected.
• Fix a regression in the start up time. When upgrading from an earlier version, the first start-up
  time may be longer than usual, as the genesis state hashes are computed. Subsequent restarts
  will not suffer this penalty.
• Enable out of band catchup by default in all distributions.
• Expose the health check service via grpc-web when grpc-web is enabled.
• Support for out-of-band catch-up for protocol versions beyond P6.
• Extend Prometheus exporter with metric grpc_connected_clients, see
  docs/prometheus-exporter.md for more details.
• Add configuration options for imposing resource limits to the V2 gRPC server.
  The following environment variables are added
  • CONCORDIUM_NODE_GRPC2_KEEPALIVE_INTERVAL
  • CONCORDIUM_NODE_GRPC2_KEEPALIVE_TIMEOUT
  • CONCORDIUM_NODE_GRPC2_TCP_KEEPALIVE
  • CONCORDIUM_NODE_GRPC2_INVOKE_MAX_ENERGY
  • CONCORDIUM_NODE_GRPC2_MAX_CONCURRENT_REQUESTS
  • CONCORDIUM_NODE_GRPC2_MAX_CONCURRENT_REQUESTS_PER_CONNECTION
  • CONCORDIUM_NODE_GRPC2_MAX_CONCURRENT_STREAMS
  • CONCORDIUM_NODE_GRPC2_MAX_CONNECTIONS
  • CONCORDIUM_NODE_GRPC2_REQUEST_TIMEOUT
    See
    docs/grpc2.md
    for an explanation of the options.
• Fix incorrect peer_bucket_size metric calculation exposed by the
  bootstrapper. What was counted was not the number of peers in the bucket, but
  rather, roughly, how many times peers that are in the bucket have
  reconnected.
• Fix a bug where the block state hash was not returned properly for the genesis block.
• Do not reset banned peers on startup by default.
• The node remembers peers across restarts. When starting up it will try to connect to stored peers in addition to any supplied bootstrap and given nodes.
  Use the new flag --clear-persisted-peers (environment variable CONCORDIUM_NODE_CLEAR_PERSISTED_PEERS) to clear stored peers on startup.
• Renamed the flag --no-clear-bans to clear-bans. When set it will clear the banned peers on startup.
• Fix a bug where credential registration IDs for genesis accounts were not
  correctly recorded. As a result, the index of accounts by credential ids was
  incorrect if the chain was started from genesis by node versions 5.1.3 up to
  and including 6.0. If a chain was started by an older node version and then
  the node was upgraded the index is loaded correctly. This index is used when
  checking for duplicate credential registration IDs, and when looking up an
  account via a credential registration ID.
• Fix a bug in the InvokeInstance endpoint where the amount sent was
  used incorrectly. The consequence was that in some cases the calls would fail
  with an error indicating insufficient amount on the account where the amount
  was sufficient for the transaction.
• Fix a bug where it was not possible to use the collector with a node configured with TLS.
  One has to configure the grpc-host flag of the collector with domain stated in the certificate that the
  node is configured with.
• Apply fix for processing of chain parameter updates when they occur at the same time
  retroactively to all protocol versions. This may break compatibility with any local/private
  chains on which the bug occurs.
• Remove the concept of pending blocks.
• GetPoolInfo now also returns the commission rates for the current reward period.
• Add GetBakersRewardPeriod to GRPCV2 API. Provided a block, then it returns information about bakers
  for the reward period of the block.
• Add endpoint GetBlockCertificates to GRPCV2 API. Provided a block, then it returns
  quorum certificate, timeout certificate and epoch finalization entry contained in the block (where present).
• Add endpoint GetBakerEarliestWinTime to GRPCV2 API. Provided a baker ID, it returns the
  earliest time at which the node projects that the baker could be required to bake a block.
• Add endpoint GetFirstBlockEpoch to GRPCV2 API. It returns the block hash of the first block in
  a given epoch.
• Add endpoint GitWinningBakersEpoch to GRPCV2 API. It returns a list of the bakers that won
  rounds in a specified (finalized) epoch. This only supports consensus version 1.
• Fix a bug in how the last timeout certificate is recovered at start-up.
• Fix the behaviour of the block last finalized pointer in the GetBlockInfo so that it
  consistently returns the last finalized block at the time the block was baked.
• Add debug-level logging when a round is advanced, either due to a quorum certificate or a
  timeout certificate.

6.0.4

Node version 6 adds support for protocol version 6.

Protocol 6 is a major protocol update that implements the new consensus algorithm, Concordium BFT.
In addition to the new consensus, protocol 6 adds new functionality to smart contracts. In particular it makes it easier to support sponsored transactions.

Additionally, node version 6 will not start V1 GRPC server by default. This is in preparation for the removal of the V1 API in a release in November. Please migrate services to V2 API.

Changes

• Support the new ConcordiumBFT consensus (protocol version 6).
• Fix a bug that causes bakers in genesis to restake their earnings when they should not. This affects genesis data at protocol version P5; P1-P4 genesis data are not affected. This breaks compatibility with chains started with P5 genesis data, where some genesis bakers are not set to restake earnings. Other chains (including mainnet and testnet) are not affected.
• Changes to the GetConsensusStatus endpoint:
  • Slot duration only returned in protocol versions 0-5.
  • Endpoint extended to return current timeout duration, current round, current epoch and trigger block time in protocol version 6.
• Changes to the GetBlockInfo endpoint:
  • Block slot only returned in protocol versions 0-5.
  • In protocol version 6, the returned finalized block is the last finalized block until itself is finalized. Then it is itself.
  • Endpoint extended to return block round and epoch in protocol version 6.
• Changes to the ElectionInfo endpoint:
  • Election difficulty only returned in protocol versions 0-5.
• Remove configuration option no-rpc-server and environment variable
  CONCORDIUM_NODE_DISABLE_RPC_SERVER, as well as default values of
  rpc-server-port (CONCORDIUM_NODE_RPC_SERVER_PORT) and rpc-server-addr
  (CONCORDIUM_NODE_RPC_SERVER_ADDR). The V1 gRPC server is only started if
  both of these options are supplied.
• Fix a network layer bug where initial messages after the handshake could be dropped in some circumstances.
• Fix a bug that caused an incorrect reporting of total stake in the first payday just after genesis when the node started from genesis at protocols 4 or 5.
• Smart contract changes and bugfixes
  • Revise the behaviour of rollbacks in P6.
  • Changes in Wasm validation and execution in P6
    • Disallow globals in initialization sections for V1 contracts in P6.
    • Support sign extension instructions in Wasm in P6.
    • Do not count custom sections towards module size when executing contracts.
    • Support new invoke operations for retrieving account keys and checking signatures.

5.4.2

This minor release extends the node API, makes it easier to use the node's grpc-web API, and contains robustness improvements.

Changes

• Support using block height as block identifiers in gRPC v2 API.
• Extend gRPC v2 API call GetBlockInfo with the protocol version of the block.
• Do not use peer buckets when running as a normal node (not as a bootstrapper).
• Enable CORS support in grpc-web. This only applies when grpc-web is enabled.
• Robustness and security improvements.

5.3.2

This release brings improvements to the node monitoring and bugfixes in the GRPC V2 API.

Additionally, the node collector that is part of the distributions is migrated to V2 API.

Changelog

• Extend Prometheus exporter with metric peer_bucket_size, see
  docs/prometheus-exporter.md for more details.
• Add an option --grpc2-health-min-peers (environment variable CONCORDIUM_NODE_GRPC2_HEALTH_MIN_PEERS)
  that causes the grpc V2 health endpoint to check minimum number of peers.
• Extend the node health check so that if the node is configured with baker
  credentials then it is required to be in the baking committee for it to be
  considered healthy.
• Add a new option --grpc2-invoke-max-energy (environment variable
  CONCORDIUM_NODE_GRPC2_INVOKE_MAX_ENERGY) that allows the node runner to
  control the maximum amount of energy allowed by an InvokeInstance (and the
  V1 GRPC InvokeContract) call. The behaviour of the endpoint is slightly
  changed as well. The energy is no longer required in the request, and the
  effective energy used by the call will be min(request.energy, grpc-invoke-max-energy). This differs from the previous behaviour where a
  request would fail if the request either omitted the energy, or supplied an
  excessive value.
• Fix a bug that could cause the node to hang indefinitely during the out-of-
  band-catchup when the node is a finalizer.
• Fix an additional bug in GetAccountInfo endpoint in GRPCv2 where
  incoming_amounts field of encrypted amounts was not always set correctly.
• The node collector is migrated to a separate package and now uses the V2 GRPC API.
• Extend Prometheus exporter with metrics: grpc_request_response_time_seconds, grpc_in_flight_requests, consensus_baking_committee, consensus_finalization_committee, consensus_baking_lottery_power, consensus_baked_blocks_total, consensus_finalized_baked_blocks_total, network_soft_banned_peers_total, consensus_non_finalized_transactions and consensus_unsupported_pending_protocol_version see docs/prometheus-exporter.md for more details.