10.0.8

Concordium node version 10.0.8 includes fixes for a number of security issues. In particular, it fixes an issue where a specially-crafted scheduled transfer transaction could result in corrupted account balances. It also improves the handling of network messages to protect against denial-of-service attacks.

Changes

• Treat scheduled transfers where the total transferred amount overflows as invalid.
• Enhance node performance by limiting outbound queue saturation to peers that are slow in processing messages.
• Prohibit peers from sending unsolicited PeerList messages
• Enhance node performance by limiting inbound queue saturation from peers that send messages aggressively by using backpressure.
• Introduce a background queue for processing messages that don't require the global block state lock.

10.0.5

Concordium node version 10.0.5 includes fixes to improve the security of gRPC endpoints.

Changes

• Disable administrative gRPC endpoints by default. These can be enabled by specifying a CONCORDIUM_NODE_GRPC2_ENDPOINT_CONFIG that enables them explicitly.

10.0.4

Concordium node version 10.0.4 contains support for protocol version 10. This protocol version introduces support for sponsored transactions.

Changes

Support for protocol version 10:

• Extended the GRPC API to support submitting sponsored transactions.
• Processing sponsored transactions

Additionally, the following changes are included in the release

• Fix a bug (present in 8.1.0 - 10.0.1 versions) where a protocol update can be executed twice, resulting in a corrupted database. Means of recovery from the bug has also been added.
• Fix a bug where transactions are not reported as committed when they appear in live blocks.
• Fixed the build_catchup_url in the Ubuntu build release pipeline.

9.0.7

Concordium node version 9.0.7 contains support for protocol version 9. Protocol version 9 introduces Protocol-Level Tokens (PLTs), which enable chain-native support for tokens other than CCD, without reliance on smart contracts. Protocol version 9 supports the following PLT functionality:

• creating new PLTs (through the CreatePLT chain update);

• transferring PLTs between accounts;

• minting and burning PLTs (limited to the nominated token governance account);

• managing permissions for which accounts can send and receive each PLT through an allow- or deny-list (limited to the governance account); and

• globally pausing or unpausing balance changing operations for a PLT (limited to the governance account).

The node API is updated to support PLTs as follows:

• GetAccountInfo reports information about PLTs associated with the account, including any balance.

• GetTokenList reports a list of the registered PLTs on the chain.

• GetTokenInfo gets the global state information for a particular PLT.

Note: Ubuntu 20.04 LTS is no longer supported; the minimum supported version for this release is 22.04 LTS.

8.0.3

Concordium node version 8.0.3 contains support for protocol version 8. This protocol version introduces support for automatically suspending inactive validators.

Changes

Protocol version 8 introduces the following changes:

• Validators are automatically suspended if they do not produce blocks for a certain number of rounds.

• The configure-validator transaction can suspend or resume a validator, including adding a validator in a suspended state.

• Suspended validators are paused from participating in the consensus algorithm.

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

• Add suspension info to BakerPoolStatus / CurrentPaydayBakerPoolStatus query results.

• Add GetConsensusDetailedStatus gRPC endpoint for getting detailed information on the status of the consensus, at consensus version 1.

• Update Rust version to 1.82.

• Update GHC version to 9.6.6 (LTS-22.39).

• Add GetScheduledReleaseAccounts endpoint for querying the list of accounts that have scheduled releases.

• Add GetCooldownAccounts, GetPreCooldownAccounts and GetPrePreCooldownAccounts endpoints for querying the lists of accounts that have pending cooldowns in protocol version 7 onwards.

• gRPC endpoints DryRun, GetBlockItemStatus and GetBlockTransactionEvents now report the parameter used to initialize a smart contract instance as part of a ContractInitializedEvent.

• Fix a bug where, after a protocol update in consensus version 1 (P6 onwards), a node may miscalculate the absolute height of blocks when it is restarted.

• Fix a bug where GetBlockInfo reports the parent block of a genesis block to be the last finalized block of the previous genesis index, instead of the terminal block.

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.