Tl;dr Concordium has rolled out protocol version 7, a significant upgrade aimed at efficiency, flexibility, and overall network performance shaped by feedback from the community and stakeholders. Protocol 7 will make complex smart contracts more efficient to execute, make unstaking more flexible, increase the security of the chain, disable shielded transactions, as well as pave the way for light nodes. More on each of these below.

More efficient smart contract execution

By redefining the way that cost metering is done, smart contract instructions will be cheaper to execute for the same EUR/NRG rate. This reflects a more efficient implementation of the smart contract execution engine that will be introduced in this release. Continuous improvements of the way smart contract instructions are executed and metered, is part of Concordium’s continued commitment towards reasonable transaction costs, and thereby building the best-in-class developer experience.

Concurrent unstaking and restaking

When a validator or a delegator reduces or removes its stake, the amount of the stake reduction is held in a cool-down state. In the preceding protocol, during the cool-down period, the stake could not be changed, and until the cool-down period had elapsed, no more stake could be added or removed. With protocol 7, unstaking and restaking can now happen concurrently. When a validator or delegator reduces their stake, the stake reduction takes effect at the next pay day, at which point the amount of the reduction enters a cool-down queue. Further reductions to the stake will be added to the queue. And if the staker decides to increase their stake, the amount is first taken from the back of the queue, and only if the unstaking queue is empty are CCD taken from the unlocked amount in the wallet to be staked. This allows for a much more flexible stake management process for validators and delegators alike.

Introducing inactive stake

A notable change for validators and delegators concerning unstaking is that stake in the cool-down queue will no longer be considered active, meaning it won’t earn rewards. This enhances the security of the chain, as it prevents nothing-at-stake attacks, where a dishonest validator might attempt to attack the chain (e.g., double sign) in the last block before their cool-down has elapsed and their stake is released. The cool-down period now acts as a buffer between the last block where the validator’s stake is effective and the moment when their stake is unlocked in their wallet. During this period where the stake is inactive, no attacks are possible with this stake.

Removing shielding

Since the initial protocol version, the Concordium blockchain has supported shielded transfers. This mechanism allowed an account to “shield” part of its balance, cryptographically encrypting it so that the amount cannot be inspected except by the owner of the account. While the sender and receiver are publicly visible, the exact amount transferred is not.

While this feature was developed with extreme care, it became clear through our talks with regulated financial institutions that Concordium’s shielded transaction feature was a dealbreaker. In order to drive ecosystem growth, the feature will be removed from the protocol with version 7. Unshielding will still be possible, so no shielded funds will be trapped.

Optimizing the chain

With every update, the Concordium team ensures that the core protocol is improved for better DevEx and future optimizations. Two highlights for protocol 7 are the redefinition of the block hash and adding features to smart contracts that make something akin to a factory pattern.

The block hashing scheme (a block’s unique identifier) is redefined to make certain Merkle proofs shorter and simpler. The purpose of this is to support light clients: light-weight verifiers that can check properties of the chain without running the full consensus. This light client will significantly reduce a node’s operational costs. A sketch of the upcoming light node and fast catch-up has been posted on the Concordium forum.

Furthermore, smart contracts will be able to query the module reference and contract name of a smart contract instance. This can be used to identify the code that is behind a smart contract instance, for example as a means of authenticating a smart contract before interacting with it. A particular motivation for this is to implement a factory pattern.

Receive updates directly in your inbox by subscribing to the Concordium Newsletter.

‍