|
| 1 | + Protocol update commentary |
| 2 | + |
| 3 | +Protocol Version: 7 |
| 4 | +Builds on Protocol Version: 6 |
| 5 | + |
| 6 | +Protocol version 7 introduces protocol changes in the following key areas: |
| 7 | +- smart contract costs |
| 8 | +- new smart contract queries |
| 9 | +- modified stake cooldown behavior |
| 10 | +- removal of shielded transactions |
| 11 | +- redefined block hashing |
| 12 | + |
| 13 | +This document provides commentary on each of these changes, elaborating on |
| 14 | +the rationale for each. |
| 15 | + |
| 16 | + 1. Smart Contract Costs |
| 17 | + |
| 18 | +The cost of a smart contract transaction (such as a contract init or update) |
| 19 | +is a function of the WebAssembly instructions that are executed in computing |
| 20 | +the outcome of the transaction. Each instruction is associated with a cost |
| 21 | +(measured in "interpreter energy"). When a smart contract module is deployed |
| 22 | +on the Concordium blockchain, the nodes apply a transformation on the |
| 23 | +WebAssembly code that instruments it with metering instructions, which track |
| 24 | +the interpreter energy usage during program execution. A smart contract |
| 25 | +transaction (as with other transactions) has an energy limit associated with |
| 26 | +it. If the energy usage during execution exceeds this limit, the transaction |
| 27 | +will simply fail. The energy used by the transaction is ultimately paid for |
| 28 | +by the sender of the transaction in a proportional amount of CCD, and these |
| 29 | +fees are used to recompense validators. |
| 30 | + |
| 31 | +The purpose of all of this is to limit the demands that individual |
| 32 | +transactions can place on the resources of nodes in the Concordium blockchain, |
| 33 | +specifically, execution time. Accordingly, the costs associated with |
| 34 | +instructions are intended to be a close proxy for the actual execution time. |
| 35 | +The costs are assigned based on benchmarking so that 1,000,000 energy |
| 36 | +corresponds to roughly 1 second of execution time. (Note that the actual |
| 37 | +execution time cannot be used to determine the cost of smart contract |
| 38 | +transactions, since it will vary from node to node and consensus requires |
| 39 | +that nodes agree on all details.) |
| 40 | + |
| 41 | +Concordium node version 7 improves smart contract execution by employing a |
| 42 | +compilation phase that transforms the stack-machine based WebAssembly into |
| 43 | +a register-based intermediate representation. This representation can be |
| 44 | +interpreted more efficiently, as operations are performed directly on their |
| 45 | +operands, eliminating stack manipulation. The result of this is that |
| 46 | +execution times are typically around 3 times faster. Accordingly the cost |
| 47 | +of WebAssembly instructions is redefined to reflect this. |
| 48 | + |
| 49 | +When a smart contract makes a call to another smart contract, the calling |
| 50 | +contract's state remains in memory, while the callee's state is also |
| 51 | +loaded. In the case of a long chain of such calls, this can use a lot of |
| 52 | +memory, potentially exhausting the resources of nodes. Previously, the |
| 53 | +energy limits were deemed sufficient to limit the resource usage. However, |
| 54 | +in light of reduced energy costs, it was decided to impose a limit on the |
| 55 | +depth of nested inter-contract calls to 384, to guard against resource |
| 56 | +exhaustion. Since each live execution frame can be up to 32 MB in size, |
| 57 | +this limits the total size of live execution frames to 12 GB. This limit |
| 58 | +was chosen given the minimum RAM requirement for a node of 16 GB. |
| 59 | + |
| 60 | +Further reading: |
| 61 | + In the Concordium node implementation, the metering transformation can be |
| 62 | + found at https://github.com/Concordium/concordium-base/blob/main/smart-contracts/wasm-transform/src/metering_transformation.rs |
| 63 | + |
| 64 | + |
| 65 | + 2. New Smart Contract Queries |
| 66 | + |
| 67 | +Protocol version 7 introduces new query operations that are available to |
| 68 | +smart contracts. These operations get the module reference and smart |
| 69 | +contract name associated with a smart contract instance. This can be used |
| 70 | +to check if a smart contract instance is an instance of a particular known |
| 71 | +smart contract, for example, or to check if a smart contract has been |
| 72 | +upgraded (in which case, its module reference will change). These kind of |
| 73 | +checks can be useful when designing smart contracts to interact in a |
| 74 | +partial-trust situation: a smart contract can authenticate the other |
| 75 | +contracts it interacts with before determining whether to trust them. |
| 76 | + |
| 77 | +A common question from smart contract developers (particularly those |
| 78 | +coming from Ethereum) is how to implement a factory pattern on Concordium. |
| 79 | +The architecture of Concordium's contracts (separating module deployment |
| 80 | +from contract initialization) means that typically a factory pattern is |
| 81 | +not required. However, these new contract inspection operations provide |
| 82 | +a way of emulating the factory pattern in the cases where it is needed. |
| 83 | +For details, see: |
| 84 | +https://developer.concordium.software/en/mainnet/smart-contracts/guides/factory-pattern.html |
| 85 | + |
| 86 | + 3. Stake Cooldown Changes |
| 87 | + |
| 88 | +The changes to stake cooldown have two main effects. First, when validators |
| 89 | +and delegators reduce (or remove) stake, the amount of the reduction no |
| 90 | +longer contributes to the calculations that determine lottery power and |
| 91 | +rewards (after the following payday), but is held in a cooldown state |
| 92 | +where it cannot be spent. Second, while stake is in cooldown, further |
| 93 | +changes to the stake can be made, such as increasing it, decreasing it |
| 94 | +further, removing it, or even changing between validator and delegator. |
| 95 | + |
| 96 | +The first change brings Concordium closer in line with common industry |
| 97 | +practice, while also strengthening a buffer against nothing-at-stake |
| 98 | +attacks, since a malicious validator cannot sell their stake for a |
| 99 | +certain time after they no longer have any effective power in the |
| 100 | +proof-of-stake consensus. |
| 101 | + |
| 102 | +The second change gives validators and delegators much more flexibility. |
| 103 | +Previously, while stake was in cooldown, the stake could not be changed |
| 104 | +(neither up nor down) and it was impossible to transition directly between |
| 105 | +being a validator or a delegator. In protocol version 7, both of these |
| 106 | +are possible. This change is of particular benefit to custodial staking |
| 107 | +providers, who may hold stake for multiple customers on a single (validator) |
| 108 | +account. The new arrangement allows them to withdraw funds for different |
| 109 | +customers independently. For instance, under the old scheme, if the staking |
| 110 | +provider unstaked customer A's funds, and then wished to also unstake |
| 111 | +customer B's funds, then they would have to wait two full cooldown periods |
| 112 | +before B's funds were unstaked, no matter how soon they requested them after |
| 113 | +A's funds were already being unstaked. In the new scheme, the fact that |
| 114 | +A's funds are in cooldown does nothing to prevent B's funds also moving to |
| 115 | +cooldown. |
| 116 | + |
| 117 | + 4. Removal of Shielded Transactions |
| 118 | + |
| 119 | +Shielded transactions allow accounts to send funds to each other while |
| 120 | +obscuring the exact amount of the transfer. Part of the rationale for |
| 121 | +supporting such transfers was to enhance the privacy for users, since the |
| 122 | +blockchain is an entirely public record. |
| 123 | + |
| 124 | +This feature has not seen wide adoption (at time of writing, less than |
| 125 | +200000 CCD is shielded) and has generally been more confusing than |
| 126 | +beneficial for users, who may have mistakenly shielded their balances |
| 127 | +unnecessarily, without properly understanding the use of shielded transfers. |
| 128 | + |
| 129 | +Furthermore, financial institutions with obligations under |
| 130 | +anti-money-laundering laws may be hesitant to adopt Concordium under the |
| 131 | +impression that such a feature could possibly enable money laundering. |
| 132 | +In fact, the identity disclosure authorities and identity providers can, |
| 133 | +if necessary, unmask the shielded transfers on an account, providing a |
| 134 | +deterrent against and remedy for any use of shielded transfers for money |
| 135 | +laundering. |
| 136 | + |
| 137 | +For these reasons, it was decided to remove shielded transfers, disabling |
| 138 | +the ability to shield balances and to transfer shielded amounts. However, as |
| 139 | +shielded balances are encrypted, there is no way to simply unshield balances |
| 140 | +automatically. Therefore, the ability to unshield balances remains, and |
| 141 | +existing shielded balances on accounts will remain. |
| 142 | + |
| 143 | + 5. Redefined Block Hashing |
| 144 | + |
| 145 | +The revision of the block hashing scheme in protocol version 7 is designed |
| 146 | +to simplify Merkle proofs of various properties of blocks, such as: |
| 147 | + |
| 148 | + - The outcome of a particular transaction in a block. |
| 149 | + - Which finalization committee certifies blocks in the next epoch. |
| 150 | + - That the (partial) state of a specific smart contract has a particular |
| 151 | + value. |
| 152 | + |
| 153 | +These proofs support and provide utility for light clients. A light client |
| 154 | +knows the current block height and the finalization committees for the current |
| 155 | +and next epochs. The client can update its state given a finalization proof |
| 156 | +(signed by one of the finalization committees) for a block, and a Merkle |
| 157 | +proof that establishes the new block height and finalization committees. |
| 158 | + |
| 159 | +Implementing light clients as smart contracts allows trustless bridging |
| 160 | +between suitable blockchains. Such a bridge uses light clients to validate |
| 161 | +messages sent between chains, eliminating the need to trust third-party |
| 162 | +relayers. Instead, the consensus protocol itself guarantees the integrity |
| 163 | +of the messages. A Concordium light client would verify cryptographically |
| 164 | +that the finalization committee saw the message being sent from the Concordium |
| 165 | +chain. These changes to block hashing are thus a step towards connecting |
| 166 | +Concordium to the wider blockchain ecosystem, for instance using the |
| 167 | +Inter-Blockchain Communication (IBC) protocol (https://www.ibcprotocol.dev). |
| 168 | + |
| 169 | +The same technology behind light clients can also support lightweight nodes. |
| 170 | +Currently, Concordium nodes maintain the entire state history of the |
| 171 | +blockchain, which is a significant and ever-growing quantity of data. |
| 172 | +(As of writing, this amounts to approximately 115 GB of data for mainnet.) |
| 173 | +Moreover, starting a new node from scratch is extremely time-consuming, |
| 174 | +since the node executes every one of the millions of blocks in sequence. |
| 175 | +A lightweight node would only store the recent state and an abbreviated |
| 176 | +summary of historical blocks, sufficient to prove the correctness of the |
| 177 | +current state. This would allow for faster node catch-up and reduced |
| 178 | +storage requirements. |
0 commit comments