From 81e48ee4ad3036f72c337060d492974880276b57 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Fri, 14 Jun 2024 13:25:17 +0200 Subject: [PATCH 1/8] Initial protocol 7 update proposal. --- updates/P7.txt | 320 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 320 insertions(+) create mode 100644 updates/P7.txt diff --git a/updates/P7.txt b/updates/P7.txt new file mode 100644 index 0000000..fba4fa0 --- /dev/null +++ b/updates/P7.txt @@ -0,0 +1,320 @@ + Protocol update + +Protocol Version: 7 +Builds on Protocol Version: 6 + + Abstract + +This document describes the changes in Concordium protocol version 7 compared to +protocol version 6. + +The protocol change has the following main effects +- redefines smart contract costs, reducing the cost of smart contract calls; +- adds support for querying the module reference and contract name of a smart + contract instance in smart contracts; +- changes cooldown behavior so that: + * when validators and delegators reduce their stake, the reduction is + immediately effective for future stake calculations, and the amount of the + reduction is looked for a cooldown period; + * validators and delegators can make further changes to their stake while + they already have stake in cooldown; +- disallows shielded (or encrypted) transfer transactions (`TransferToEncrypted`, + `EncryptedAmountTransfer` and `EncryptedAmountTransferWithMemo`). + + Background + +Smart contract execution costs are reduced in protocol version 7 because of +efficiency improvements in the implementation of smart contract execution. +The revised cost model is based on an execution model where the interpreter +stack is compiled to registers. + +The new protocol version also imposes a limit on the nesting depth of +inter-contract calls to 384. This is since each live execution frame can +require up to 32MB of memory, so limiting the number of active execution +frames in this way safeguards against excessive memory use. + + * * * + +As of protocol version 7, smart contracts are 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, where one +smart contract (the factory) is responsible for initializing instances of +another (the product). On Concordium, one smart contract cannot directly +create instances of another, but it can be used to invoke an initialization +method on another. The additional queries allow the factory to ensure that +the contract instance it is initializing is of the correct type. + + * * * + +Prior to protocol version 7, when a validator or a delegator reduces or +removes its stake, the amount of the stake reduction is held in a cooldown +state. During the cooldown period, the stake cannot be spent, and remains +part of the effective stake (used for lottery and reward calculation). Once +the cooldown period has elapsed, the stake is available to be spent, and +no longer contributes to the effective stake of the baker or delegator. +While the cooldown is in effect on an account, no other changes can be made +to the account's stake. + +From protocol version 7, when a validator or delegator reduces its stake, +the stake reduction takes effect straight away, but the amount of the +reduction enters a cooldown queue. (Note that "straight away" here does +not mean that is has an instant effect on the lottery and rewards. The +effective stakes of bakers and delegators are sampled in the first block +of the last epoch before each payday, with the sampled stakes being used +from the upcoming payday. Although the change is recorded on the account +immediately, it will be between 1 epoch and 1 payday plus 1 epoch until +the change affects the proof-of-stake lottery used for consensus.) +Stake in the cooldown queue is considered to be inactive stake, and, as +such, does not contribute to the lottery calculation. However, the +inactive stake still cannot be spent, although it is possible to transfer +it back to active stake. + +When stake is removed from a validator or delegator, it enters cooldown +at the point that the removed stake is no longer part of the effective +stake for lottery calculations. Specifically, when the stake is removed, +it first enters a "pre-pre-cooldown" state. When the stake snapshot is +taken for next payday (in the first block of the epoch before the payday) +it is moved from "pre-pre-cooldown" to "pre-cooldown". At the subsequent +payday, it is moved from "pre-cooldown" into "cooldown", and the cooldown +expiry time is set based on the cooldown time chain parameter. In +particular, the cooldown officially starts at this payday. At the first +payday at or after the cooldown expiry time, the stake finally exits +"cooldown" and becomes available to spend. An account's active stake +can be reduced while there is still inactive stake in cooldown, leading +to multiple amounts in cooldown (or pre-cooldown or pre-pre-cooldown) +that expire at different times. + +If the active stake on an account is increased, the increase is first +transferred from the inactive stake in preference to taking from the +unstaked balance. Specifically, it is taken first from "pre-pre-cooldown", +then "pre-cooldown", and then from the "cooldown" stakes in decreasing +order of expiry time. An account can also switch freely between being +a validator and being a delegator without its stake entering cooldown. +(Prior to protocol version 7, it was necessary to remove the validator +or delegator on an account, waiting out the cooldown period, before +instating a delegator or validator.) As a consequence of this, from +protocol version 7, no distinction is drawn between the cooldown time +for validators and for delegators: stake entering cooldown expires +after the minimum of both times. + +The purpose of these changes is to maximise the flexibility of staking, +while still ensuring that any stake must still be locked for the +cooldown period before it can be spent. + + * * * + +Since the initial protocol version, the Concordium block chain has +supported shielded transfers (also known as encrypted transfers). +This mechanism allows 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 (using its secret encryption key). +An account can transfer an amount from its shielded balance to another +account. While the sender and receiver are publicly visible, the exact +amount transferred (in CCD) is not. An account can also decrypt funds from +its shielded balance, enabling them to be spent as normal. Each of +these operations makes use of zero-knowledge proofs to ensure that +the transfers are carried out correctly (i.e. without creating or +destroying any CCDs) while not revealing the encrypted values. + +This feature has not seen widespread use. Moreover, the presence of +shielded transfers is seen as a barrier to adoption of Concordium +by some risk-averse parties. As such, the shielded transfers are +no longer supported as of protocol version 7. + +In particular, shielding (or encrypting) a public balance and +transferring shielded funds from one account to another are +disallowed from protocol version 7. Unshielding (i.e., transferring +funds from an account's shielded funds to its own unshielded funds) +remains enabled. This ensures that accounts do not simply lose any +funds that they previously shielded. + + Changes + +The following behaviors are changed in protocol version 7. + +1. The cost metering for smart contract execution is redefined. The new + instruction costs of WebAssembly instructions are defined below. + (1 Energy = 1000 Interpreter Energy.) + + Instruction Old cost (Interpreter Energy) New cost (Interpreter Energy) + + nop 1 1 + unreachable 0 0 + block 0 0 + loop 0 0 + if 10 4 + br 8 + target arity (0 or 1) 2 + br_if 10 4 + br_table 10 + target arity 7 + return 8 + return arity 2 + call 26 + #arg + #res 6 + #arg + #res + call_indirect 28 + 2*(#arg + #res) 8 + |_ 1.1*(#arg + #res) _| + + drop 2 0 + select 3 2 + + local.get 3 0 + local.set 3 0 + local.tee 3 0 + global.get 3 1 + global.set 3 1 + + inn.load* 4 1 + i32.store 8 2 + i64.store 10 2 + i32.store8 5 2 + i32.store16 8 2 + i64.store8 7 2 + i64.store16 9 2 + i64.store32 10 2 + memory.size 4 1 + memory.grow 10 + 100 * #pages 10 + 100 * #pages + + inn.const 2 0 + inn.eqz 3 1 + inn.clz 3 1 + inn.ctz 3 1 + inn.popcnt 3 1 + inn.eq 4 1 + inn.ne 4 1 + inn.lt* 4 1 + inn.gt* 4 1 + inn.le* 4 1 + inn.ge* 4 1 + inn.add 4 1 + inn.sub 4 1 + inn.mul 5 2 + inn.div* 5 2 + inn.rem* 5 2 + inn.and 4 1 + inn.or 4 1 + inn.xor 4 1 + inn.shl 4 1 + inn.shr* 4 1 + inn.rotl 4 1 + inn.rotr 4 1 + i32.wrap_i64 3 1 + inn.extend* 3 1 + + (Here, target arity and return arity are the arity of the target + label and the current activation frame respectively; #arg and + #res are the numbers of arguments and results of the function + being called; and #pages is the number of memory pages requested + by memory.grow.) + + The cost (in Energy) of looking up a contract module is reduced from + |_ size / 50 _| to |_ size / 500 _|, where size is the size of the + module's WebAssembly source in bytes, not including custom sections. + This cost is incurred on contract initialization, update, upgrading and + inter-contract calls. + +2. The maximum nesting depth of V1 contract calls is limited to 384. + +3. In V1 smart contracts, the `invoke` operations allows for two + additional operations: + + - Query smart contract module reference: + * Instruction tag: 7 + * Payload: + - contract index (8 bytes, little endian) + - contract subindex (8 bytes, little endian) + * Return codes: + - 0: success + the return value is the module reference of the specified + contract instance + - 3: missing contract + there is no contract instance with the given address + * Cost: 200 Energy + - Query smart contract name: + * Instruction tag: 8 + * Payload: + - contract index (8 bytes, little endian) + - contract subindex (8 bytes, little endian) + * Return codes: + - 0: success + the return value is the name of the `init` method used to + create the contract instance (including the "init_" prefix) + - 3: missing contract + there is no contract instance with the given address + * Cost: 200 Energy + +4. The following changes apply to staking: + - The stake of an account is divided into + * Active stake: this determines the baker or validator's + stake for future snapshots that determine the stake + distribution for the purposes of lottery calculation and + reward distribution. + * Inactive stake: this does not contribute to lottery or + reward calculations, but is locked for a period of time. + The inactive stake can consist of multiple amounts that + can be in the following states: + - cooldown with a specific expiry time + - pre-cooldown + - pre-pre-cooldown + - When a validator or delegator is removed from an account, the + validator or delegator record is removed from the account and + the active stake is moved to the inactive stake in the + pre-pre-cooldown stake. + - When a validator or delegator has its stake reduced, the amount + of the reduction is moved to the inactive stake in the + pre-pre-cooldown stake. + - When a validator or delegator has its stake increased (including if + an account becomes a validator or delegator when it was neither), + the amount of the increase will be taken preferentially from + inactive stake in the the following order: + * pre-pre-cooldown + * pre-cooldown + * cooldown (starting from the highest expiry timestamp) + - A validator or delegator may switch to the other role at any time + (by a `ConfigureBaker` or `ConfigureDelegator` transaction). It is + only subject to cooldown in this process insofar as the stake is + reduced. + - At the first block in an epoch, the following occur: + * If the epoch is the first of a new payday (a payday epoch) then + all amounts in cooldown that are set to expire at or before the + transition time for the previous epoch (the payday time) are + released from the inactive stake of accounts. All amounts in + pre-cooldown are moved into cooldown, with the expiry time set + to be the minimum of the current validator and delegator cooldown + time parameters (accounting for any parameter changes up to the + current block) after the payday time. + [Note: as before, at payday the current epoch stakes and capital + distribution are updated based on the snapshot taken in the + previous epoch, and all rewards are paid out that have accrued.] + * If the epoch is the last before a new payday (a snapshot epoch) + then all amounts in pre-pre-cooldown are transferred to pre-cooldown. + [Note: as before, in a snapshot epoch, the snapshot of the stakes + and capital distribution is taken for the next payday.] + +5. The transaction payload types `TransferToEncrypted`, + `EncryptedAmountTransfer` and `EncryptedAmountTransferWithMemo` are + considered invalid. Transactions of these types will be rejected with + a `SerializationFailure` result. + + Effects + +1. At the protocol update, the following changes apply to validator and + delegator accounts: + * If the account was pending cooldown, it is removed from + the pending state and the amount of the reduction in stake will be moved + from its active stake to the pre-pre-cooldown inactive stake. + * If the account was pending removal (of the validator or delegator), + the validator or delegator record is removed from the account and the + active stake is moved to the pre-pre-cooldown inactive stake. + +2. Behavior of existing V1 contract instances may be affected in the + following scenarios: + - The cost of smart contract execution is changed as described above. + - If the contract execution exceeds a nesting depth of 384 contract + calls, the execution will fail. + - If the contract uses the `invoke` operation with tags 7 or 8, prior + to the update a runtime error would be triggered; after the update + the behavior will be as defined above (querying the module reference + or name). + + Protocol update instruction + +The protocol update instruction is identified by the SHA256 hash of +this file. There is no auxiliary data for the update instruction. From bf809739a3208b441ebc49b9068719869cf6c098 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Tue, 18 Jun 2024 17:13:32 +0200 Subject: [PATCH 2/8] Address review comments. --- updates/P7.txt | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/updates/P7.txt b/updates/P7.txt index fba4fa0..be10ca3 100644 --- a/updates/P7.txt +++ b/updates/P7.txt @@ -15,7 +15,7 @@ The protocol change has the following main effects - changes cooldown behavior so that: * when validators and delegators reduce their stake, the reduction is immediately effective for future stake calculations, and the amount of the - reduction is looked for a cooldown period; + reduction is locked for a cooldown period; * validators and delegators can make further changes to their stake while they already have stake in cooldown; - disallows shielded (or encrypted) transfer transactions (`TransferToEncrypted`, @@ -60,10 +60,10 @@ to the account's stake. From protocol version 7, when a validator or delegator reduces its stake, the stake reduction takes effect straight away, but the amount of the reduction enters a cooldown queue. (Note that "straight away" here does -not mean that is has an instant effect on the lottery and rewards. The +not mean that it has an instant effect on the lottery and rewards. The effective stakes of bakers and delegators are sampled in the first block of the last epoch before each payday, with the sampled stakes being used -from the upcoming payday. Although the change is recorded on the account +for the upcoming payday. Although the change is recorded on the account immediately, it will be between 1 epoch and 1 payday plus 1 epoch until the change affects the proof-of-stake lottery used for consensus.) Stake in the cooldown queue is considered to be inactive stake, and, as @@ -75,7 +75,7 @@ When stake is removed from a validator or delegator, it enters cooldown at the point that the removed stake is no longer part of the effective stake for lottery calculations. Specifically, when the stake is removed, it first enters a "pre-pre-cooldown" state. When the stake snapshot is -taken for next payday (in the first block of the epoch before the payday) +taken for the next payday (in the first block of the epoch before the payday) it is moved from "pre-pre-cooldown" to "pre-cooldown". At the subsequent payday, it is moved from "pre-cooldown" into "cooldown", and the cooldown expiry time is set based on the cooldown time chain parameter. In @@ -100,12 +100,12 @@ for validators and for delegators: stake entering cooldown expires after the minimum of both times. The purpose of these changes is to maximise the flexibility of staking, -while still ensuring that any stake must still be locked for the -cooldown period before it can be spent. +while ensuring that any stake must still be locked for the cooldown +period before it can be spent. * * * -Since the initial protocol version, the Concordium block chain has +Since the initial protocol version, the Concordium blockchain has supported shielded transfers (also known as encrypted transfers). This mechanism allows an account to "shield" part of its balance, cryptographically encrypting it so that the amount cannot be inspected @@ -127,16 +127,16 @@ In particular, shielding (or encrypting) a public balance and transferring shielded funds from one account to another are disallowed from protocol version 7. Unshielding (i.e., transferring funds from an account's shielded funds to its own unshielded funds) -remains enabled. This ensures that accounts do not simply lose any -funds that they previously shielded. +remains enabled. This ensures that accounts do not lose any funds that +they previously shielded. Changes The following behaviors are changed in protocol version 7. 1. The cost metering for smart contract execution is redefined. The new - instruction costs of WebAssembly instructions are defined below. - (1 Energy = 1000 Interpreter Energy.) + instruction costs of WebAssembly instructions are defined below + (1 Energy = 1000 Interpreter Energy): Instruction Old cost (Interpreter Energy) New cost (Interpreter Energy) @@ -150,7 +150,7 @@ The following behaviors are changed in protocol version 7. br_table 10 + target arity 7 return 8 + return arity 2 call 26 + #arg + #res 6 + #arg + #res - call_indirect 28 + 2*(#arg + #res) 8 + |_ 1.1*(#arg + #res) _| + call_indirect 28 + 2*(#arg + #res) 8 + floor(1.1*(#arg + #res)) drop 2 0 select 3 2 @@ -202,17 +202,19 @@ The following behaviors are changed in protocol version 7. label and the current activation frame respectively; #arg and #res are the numbers of arguments and results of the function being called; and #pages is the number of memory pages requested - by memory.grow.) + by memory.grow. "inn" indicates both "i32" and "i64" variants, and + where instructions are suffixed with *, the line applies to all variants. + For instance, inn.load* includes i32.load8_s, i64.load8_u, etc.) The cost (in Energy) of looking up a contract module is reduced from - |_ size / 50 _| to |_ size / 500 _|, where size is the size of the + floor(size / 50) to floor(size / 500), where size is the size of the module's WebAssembly source in bytes, not including custom sections. This cost is incurred on contract initialization, update, upgrading and inter-contract calls. 2. The maximum nesting depth of V1 contract calls is limited to 384. -3. In V1 smart contracts, the `invoke` operations allows for two +3. In V1 smart contracts, the `invoke` host function allows for two additional operations: - Query smart contract module reference: @@ -263,7 +265,7 @@ The following behaviors are changed in protocol version 7. - When a validator or delegator has its stake increased (including if an account becomes a validator or delegator when it was neither), the amount of the increase will be taken preferentially from - inactive stake in the the following order: + inactive stake in the following order: * pre-pre-cooldown * pre-cooldown * cooldown (starting from the highest expiry timestamp) From 82b3cfe56b4c2b1212f17470dfbce35f73724273 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Wed, 19 Jun 2024 16:06:12 +0200 Subject: [PATCH 3/8] Add changed block hashing scheme. --- updates/P7.txt | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) diff --git a/updates/P7.txt b/updates/P7.txt index be10ca3..05c1bdd 100644 --- a/updates/P7.txt +++ b/updates/P7.txt @@ -20,6 +20,7 @@ The protocol change has the following main effects they already have stake in cooldown; - disallows shielded (or encrypted) transfer transactions (`TransferToEncrypted`, `EncryptedAmountTransfer` and `EncryptedAmountTransferWithMemo`). +- redefines the block hashing scheme to better support light clients. Background @@ -110,6 +111,12 @@ supported shielded transfers (also known as encrypted transfers). This mechanism allows 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 (using its secret encryption key). +(It is possible for a sufficient combination of identity disclosure +authorities (e.g. 2 of 3) to act in concert with the identity provider +for an account to recover the secret encryption key (for instance, if +compelled to do so by legal authorities) and thus decrypt the shielded +balance and transfers on that account.) + An account can transfer an amount from its shielded balance to another account. While the sender and receiver are publicly visible, the exact amount transferred (in CCD) is not. An account can also decrypt funds from @@ -130,6 +137,25 @@ funds from an account's shielded funds to its own unshielded funds) remains enabled. This ensures that accounts do not lose any funds that they previously shielded. + * * * + +A block hash is a cryptographic hash of the contents of a block, and serves +as a unique identifier for the block. The block hash is not only derived from +the header fields of a block, but also the state of the chain after executing +the block, including the current state of each account and smart contract. +The block hashing scheme determines how the block hash is derived from this +data. In particular, individual elements are hashed and their hashes are +combined and hashed again into a Merkle tree structure. This structure makes +it possible to prove that a block (whose hash is known to the verifier) +contains some specific data (such as the balance of a particular +account) without providing the entirety of the data comprising the block. + +In protocol version 7, the block hashing scheme is redefined. The revised +definition makes 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, by making use of +Merkle proofs. + Changes The following behaviors are changed in protocol version 7. @@ -295,6 +321,56 @@ The following behaviors are changed in protocol version 7. considered invalid. Transactions of these types will be rejected with a `SerializationFailure` result. +6. The block hashing for a (non-genesis) block in protocol version 7 follows + the structure below: + + [BlockHash] + |- protocol version + |- [...] + |- [BlockHeaderHash] + | |- round + | |- epoch + | |- [parent BlockHash] + | + |- [BlockQuasiHash] + |- [metaHash] + | |- [bakerInfoHash] + | | |- [timestampBakerHash] + | | | |- timestamp + | | | |- baker ID + | | | + | | |- [nonceHash] + | | |- block nonce + | | + | |- [certificatesHash] + | |- [QuorumCertificate hash] + | | |- [parent BlockHash] + | | |- QC round + | | |- QC epoch + | | |- aggregate signature + | | |- signatories + | | + | |- [timeoutFinalizationHash] + | |- [Option TimeoutCertificate hash] + | |- [Option FinalizationEntry hash] + | + |- [dataHash] + |- [transactions hash] + |- [BlockResultHash] + |- [...] + | |- [BlockStateHash] + | |- [TransactionOutcomesHash] + | + |- [...] + |- [block height info hash] + | |- absolute block height + | |- genesis index + | |- relative block height + | + |- [...] + |- [current FinalizationCommitteeHash] + |- [next FinalizationCommitteeHash] + Effects 1. At the protocol update, the following changes apply to validator and From 9fdc0d2e5a589b8149a85dd9b1f5aca643d36506 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Wed, 19 Jun 2024 18:12:02 +0200 Subject: [PATCH 4/8] Adding P7 commentary. --- commentary/P7-commentary.txt | 137 +++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 commentary/P7-commentary.txt diff --git a/commentary/P7-commentary.txt b/commentary/P7-commentary.txt new file mode 100644 index 0000000..a66d3ed --- /dev/null +++ b/commentary/P7-commentary.txt @@ -0,0 +1,137 @@ + Protocol update commentary + +Protocol Version: 7 +Builds on Protocol Version: 6 + +Protocol version 7 introduces protocol changes in the following key areas: +- smart contract costs +- new smart contract queries +- modified stake cooldown behavior +- removal of shielded transactions +- redefined block hashing + +This document provides commentary on each of these changes, elaborating on +the rationale for each. + + 1. Smart Contract Costs + +The cost of a smart contract transaction (such as a contract init or update) +is a function of the WebAssembly instructions that are execute in computing +the outcome of the transaction. Each instruction is associated with a cost +(measured in "interpreter energy"). When a smart contract module is deployed +on the Concordium blockchain, the nodes apply a transformation on the +WebAssembly code that instruments it with metering instructions, which track +the interpreter energy usage during program execution. A smart contract +transaction (as with other transactions) has an energy limit associated with +it. If the energy usage during execution exceeds this limit, the transaction +will simply fail. The energy used by the transaction is ultimately paid for +by the sender of the transaction in a proportional amount of CCD, and these +fees are used to recompense validators. + +The purpose of all of this is to limit the demands that individual +transactions can place on the resources of nodes in the concordium blockchain, +specifically, execution time. Accordingly, the costs associated with +instructions are intended to be a close proxy for the actual execution time. +The costs are assigned based on benchmarking so that 1000000 energy +corresponds to roughly 1 second of execution time. (Note that the actual +execution time cannot be used to determine the cost of smart contract +transactions, since it will vary from node to node and consensus requires +that nodes agree on all details.) + +Concordium node version 7 improves smart contract execution by employing a +compilation phase that transforms the stack-machine based WebAssembly into +a register-based intermediate representation. This representation can be +interpreted more efficiently, as operations are performed directly on their +operands, eliminating stack manipulation. The result of this is that +execution times are typically around 3 times faster. Accordingly the cost +of WebAssembly instructions is redefined to reflect this. + +When a smart contract makes a call to another smart contract, the calling +contract's state remains in memory, while the callee's state is also +loaded. In the case of a long chain of such calls, this can use a lot of +memory, potentially exhausting the resources of nodes. Previously, the +energy limits were deemed sufficient to limit the resource usage. However, +in light of reduced energy costs, it was decided to impose a limit on the +depth of nested inter-contract calls to 384, to guard against resource +exhaustion. + + 2. New Smart Contract Queries + +Protocol version 7 introduces new query operations that are available to +smart contracts. These operations get the module reference and smart +contract name associated with a smart contract instance. This can be used +to check if a smart contract instance is an instance of a particular known +smart contract, for example, or to check if a smart contract has been +upgraded (in which case, its module reference will change). These kind of +checks can be useful when designing smart contracts to interact in a +partial-trust situation: a smart contract can authenticate the other +contracts it interacts with before determining whether to trust them. + +A common question from smart contract developers (particularly those +coming from Ethereum) is how to implement a factory pattern on Concordium. +The architecture of Concordium's contracts (separating module deployment +from contract initialization) means that typically a factory pattern is +not required. However, these new contract inspection operations provide +a way of emulating the factory pattern in the cases where it is needed. +For details, see: +https://developer.concordium.software/en/mainnet/smart-contracts/guides/factory-pattern.html + + 3. Stake Cooldown Changes + +The changes to stake cooldown have two main effects. First, when validators +and delegators reduce (or remove) stake, the amount of the reduction no +longer contributes to the calculations that determine lottery power and +rewards (after the following payday), but is held in a cooldown state +where it cannot be spent. Second, while stake is in cooldown, further +changes to the stake can be made, such as increasing it, decreasing it +further, removing it, or even changing between validator and delegator. + +The first change brings Concordium closer in line with common industry +practice, while also strengthening a buffer against nothing-at-stake +attacks, since a malicious validator cannot sell their stake for a +certain time after they no longer have any effective power in the +proof-of-stake consensus. + +The second change gives validators and delegators much more flexibility. +Previously, while stake was in cooldown, the stake could not be changed +(neither up nor down) and it was impossible to transition directly between +being a validator or a delegator. In protocol version 7, both of these +are possible. This change is of particular benefit to custodial staking +providers, who may hold stake for multiple customers on a single (validator) +account. The new arrangement allows them to withdraw funds for different +customers independently. For instance, under the old scheme, if the staking +provider unstaked customer A's funds, and then wished to also unstake +customer B's funds, then they would have to wait two full cooldown periods +before B's funds were unstaked, no matter how soon they requested them after +A's funds were already being unstaked. In the new scheme, the fact that +A's funds are in cooldown does nothing to prevent B's funds also moving to +cooldown. + + 4. Removal of Shielded Transactions + +Shielded transactions allow accounts to send funds to each other while +obscuring the exact amount of the transfer. Part of the rationale for +supporting such transfers was to enhance the privacy for users, since the +blockchain is an entirely public record. + +This feature has not seen wide adoption (at time of writing, less than +200000 CCD is shielded) and has generally been more confusing than +beneficial for users, who may have mistakenly shieled their balances +unnecessarily, without properly understanding the use of shielded transfers. + +Furthermore, financial institutions with obligations under +anti-money-laundering laws may be hesitant to adopt Concordium under the +impression that such a feature could possibly enable money laundering. +In fact, the identity disclosure authorities and identity providers can, +if necessary, unmask the shielded transfers on an account, providing a +deterrent against and remedy for any use of shielded transfers for money +laundering. + +For these reasons, it was decided to remove shielded transfers, disabling +the ability to shield balances and to transfer shielded amounts. However, as +shielded balances are encrypted, there is no way to simply unshield balances +automatically. Therefore, the ability to unshield balances remains, and +existing shielded balances on accounts will remain. + + 5. Redefined Block Hashing + From 2e651e3669538004436554f4f0ecde9b66693e60 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Fri, 21 Jun 2024 14:45:04 +0200 Subject: [PATCH 5/8] More commentary and review revisions. --- commentary/P7-commentary.txt | 50 +++++++++++++++++++++++++++++++++--- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/commentary/P7-commentary.txt b/commentary/P7-commentary.txt index a66d3ed..61d4f67 100644 --- a/commentary/P7-commentary.txt +++ b/commentary/P7-commentary.txt @@ -16,7 +16,7 @@ the rationale for each. 1. Smart Contract Costs The cost of a smart contract transaction (such as a contract init or update) -is a function of the WebAssembly instructions that are execute in computing +is a function of the WebAssembly instructions that are executed in computing the outcome of the transaction. Each instruction is associated with a cost (measured in "interpreter energy"). When a smart contract module is deployed on the Concordium blockchain, the nodes apply a transformation on the @@ -29,10 +29,10 @@ by the sender of the transaction in a proportional amount of CCD, and these fees are used to recompense validators. The purpose of all of this is to limit the demands that individual -transactions can place on the resources of nodes in the concordium blockchain, +transactions can place on the resources of nodes in the Concordium blockchain, specifically, execution time. Accordingly, the costs associated with instructions are intended to be a close proxy for the actual execution time. -The costs are assigned based on benchmarking so that 1000000 energy +The costs are assigned based on benchmarking so that 1,000,000 energy corresponds to roughly 1 second of execution time. (Note that the actual execution time cannot be used to determine the cost of smart contract transactions, since it will vary from node to node and consensus requires @@ -53,7 +53,14 @@ memory, potentially exhausting the resources of nodes. Previously, the energy limits were deemed sufficient to limit the resource usage. However, in light of reduced energy costs, it was decided to impose a limit on the depth of nested inter-contract calls to 384, to guard against resource -exhaustion. +exhaustion. Since each live execution frame can be up to 32 MB in size, +this limits the total size of live execution frames to 12 GB. This limit +was chosen given the minimum RAM requirement for a node of 16 GB. + +Further reading: + In the Concordium node implementation, the metering transformation can be + found at https://github.com/Concordium/concordium-base/blob/main/smart-contracts/wasm-transform/src/metering_transformation.rs + 2. New Smart Contract Queries @@ -135,3 +142,38 @@ existing shielded balances on accounts will remain. 5. Redefined Block Hashing +The revision of the block hashing scheme in protocol version 7 is designed +to simplify Merkle proofs of various properties of blocks, such as: + + - The outcome of a particular transaction in a block. + - Which finalization committee certifies blocks in the next epoch. + - That the (partial) state of a specific smart contract has a particular + value. + +These proofs support and provide utility for light clients. A light client +knows the current block height and the finalization committees for the current +and next epochs. The client can update its state given a finalization proof +(signed by one of the finalization committees) for a block, and a Merkle +proof that establishes the new block height and finalization committees. + +Implementing light clients as smart contracts allows trustless bridging +between suitable blockchains. Such a bridge uses light clients to validate +messages sent between chains, eliminating the need to trust third-party +relayers. Instead, the consensus protocol itself guarantees the integrity +of the messages. A Concordium light client would verify cryptographically +that the finalization committee saw the message being sent from the Concordium +chain. These changes to block hashing are thus a step towards connecting +Concordium to the wider blockchain ecosystem, for instance using the +Inter-Blockchain Communication (IBC) protocol (https://www.ibcprotocol.dev). + +The same technology behind light clients can also support lightweight nodes. +Currently, Concordium nodes maintain the entire state history of the +blockchain, which is a significant and ever-growing quantity of data. +(As of writing, this amounts to approximately 115 GB of data for mainnet.) +Moreover, starting a new node from scratch is extremely time-consuming, +since the node executes every one of the millions of blocks in sequence. +A lightweight node would only store the recent state and an abbreviated +summary of historical blocks, sufficient to prove the correctness of the +current state. This would allow for for faster node catch-up and reduced +storage requirements. + From e67aa9fefebb1f6028c3eca8c998d714daa09e67 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Fri, 21 Jun 2024 15:12:24 +0200 Subject: [PATCH 6/8] Update meta --- README.md | 2 +- source/index.rst | 1 + source/updates/P7.rst | 25 +++++++++++++++++++++++++ 3 files changed, 27 insertions(+), 1 deletion(-) create mode 100644 source/updates/P7.rst diff --git a/README.md b/README.md index e6724ce..1aaca8c 100644 --- a/README.md +++ b/README.md @@ -23,7 +23,7 @@ The table lists already effective as well as *planned/draft* protocol updates. | Sirius (P4) | Delegation and new contract state | Jun 13, 2022 | Jun 23, 2022 | [P4.txt](../main/updates/P4.txt) | [P4-commentary.txt](../main/commentary/P4-commentary.txt) | `20c6f246713e573fb5bfdf1e59c0a6f1a37cded34ff68fda4a60aa2ed9b151aa` | `4c135293c661cc57890aab1889e8263db70e3a857983e6aa7ffa5ea6806b9338` | `476093e74014d9c735de0173a653f094f15ee1a4d2693f24bddd184672723d98` | | P5 | Smart contract upgradability, performance improvements | Nov 22, 2022 | Dec 13, 2022 | [P5.txt](../main/updates/P5.txt) | [P5-commentary.txt](../main/commentary/P5-commentary.txt) | `af5684e70c1438e442066d017e4410af6da2b53bfa651a07d81efa2aa668db20` | `6ca196c7fa2f3e0e64b7fa9b6c7299c5196ff38122768b799fab612db31b2114` | `5443ee296c0a87af8631998e5e7edd80ac4edec5c64255bdf8415af6e4bd0f43` | | P6 | Concordium BFT consensus protocol, changes in Wasm validation and execution | Aug 21, 2023 | Sep 25, 2023 | [P6.txt](../main/updates/P6.txt) | [P6-commentary.txt](../main/commentary/P6-commentary.txt) | `ede9cf0b2185e9e8657f5c3fd8b6f30cef2f1ef4d9692aa4f6ef6a9fb4a762cd` | `358633697957ac1c3f91adc40f75d1ff951a11bc89826567a4118ce0371c17bf` | `5406c159c36841803d7eecba4aa5c21c6a72693a854ea88851218cfe8b31465c` | - +| P7 | Smart contract costs and new queries, stake cooldown changes, disabling shielded transfers, revised block hashing | - | - | [P7.txt](../main/updates/P7.txt) | [P7-commentary.txt](../main/commentary/P7-commentary.txt) | `b2b5d200c532143a586b1c68cfc0ea77a2f253038855aab35d6be72877c954d6` | - | - | ## Website diff --git a/source/index.rst b/source/index.rst index 5c15858..96f9899 100644 --- a/source/index.rst +++ b/source/index.rst @@ -11,6 +11,7 @@ Concordium Interoperability Specifications updates/P4 updates/P5 updates/P6 + updates/P7 .. toctree:: :maxdepth: 1 diff --git a/source/updates/P7.rst b/source/updates/P7.rst new file mode 100644 index 0000000..265392a --- /dev/null +++ b/source/updates/P7.rst @@ -0,0 +1,25 @@ +===================================================================================================================================== +Protocol Update 7 - Smart contract costs and new queries, stake cooldown changes, disabling shielded transfers, revised block hashing +===================================================================================================================================== + +.. list-table:: + :stub-columns: 1 + + * - Effective on Testnet + - TBD + * - Effective on Mainnet + - TBD + * - Specification hash + - ``b2b5d200c532143a586b1c68cfc0ea77a2f253038855aab35d6be72877c954d6`` + +Specification +============= + +.. include:: ../../updates/P6.txt + :literal: + +Commentary +========== + +.. include:: ../../commentary/P6-commentary.txt + :literal: From 3cab557941bb1dea5d7aab17369a88df8c390ac6 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Fri, 21 Jun 2024 15:16:59 +0200 Subject: [PATCH 7/8] Address review comments. --- commentary/P7-commentary.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/commentary/P7-commentary.txt b/commentary/P7-commentary.txt index 61d4f67..f95b898 100644 --- a/commentary/P7-commentary.txt +++ b/commentary/P7-commentary.txt @@ -174,6 +174,5 @@ Moreover, starting a new node from scratch is extremely time-consuming, since the node executes every one of the millions of blocks in sequence. A lightweight node would only store the recent state and an abbreviated summary of historical blocks, sufficient to prove the correctness of the -current state. This would allow for for faster node catch-up and reduced +current state. This would allow for faster node catch-up and reduced storage requirements. - From 07e80e9ad8a06c7aaf2523906a410811aab96738 Mon Sep 17 00:00:00 2001 From: Thomas Dinsdale-Young Date: Tue, 25 Jun 2024 16:48:03 +0200 Subject: [PATCH 8/8] Address comments. --- README.md | 2 +- commentary/P7-commentary.txt | 2 +- source/updates/P7.rst | 2 +- updates/P7.txt | 6 +++--- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 1aaca8c..cf9ac1d 100644 --- a/README.md +++ b/README.md @@ -23,7 +23,7 @@ The table lists already effective as well as *planned/draft* protocol updates. | Sirius (P4) | Delegation and new contract state | Jun 13, 2022 | Jun 23, 2022 | [P4.txt](../main/updates/P4.txt) | [P4-commentary.txt](../main/commentary/P4-commentary.txt) | `20c6f246713e573fb5bfdf1e59c0a6f1a37cded34ff68fda4a60aa2ed9b151aa` | `4c135293c661cc57890aab1889e8263db70e3a857983e6aa7ffa5ea6806b9338` | `476093e74014d9c735de0173a653f094f15ee1a4d2693f24bddd184672723d98` | | P5 | Smart contract upgradability, performance improvements | Nov 22, 2022 | Dec 13, 2022 | [P5.txt](../main/updates/P5.txt) | [P5-commentary.txt](../main/commentary/P5-commentary.txt) | `af5684e70c1438e442066d017e4410af6da2b53bfa651a07d81efa2aa668db20` | `6ca196c7fa2f3e0e64b7fa9b6c7299c5196ff38122768b799fab612db31b2114` | `5443ee296c0a87af8631998e5e7edd80ac4edec5c64255bdf8415af6e4bd0f43` | | P6 | Concordium BFT consensus protocol, changes in Wasm validation and execution | Aug 21, 2023 | Sep 25, 2023 | [P6.txt](../main/updates/P6.txt) | [P6-commentary.txt](../main/commentary/P6-commentary.txt) | `ede9cf0b2185e9e8657f5c3fd8b6f30cef2f1ef4d9692aa4f6ef6a9fb4a762cd` | `358633697957ac1c3f91adc40f75d1ff951a11bc89826567a4118ce0371c17bf` | `5406c159c36841803d7eecba4aa5c21c6a72693a854ea88851218cfe8b31465c` | -| P7 | Smart contract costs and new queries, stake cooldown changes, disabling shielded transfers, revised block hashing | - | - | [P7.txt](../main/updates/P7.txt) | [P7-commentary.txt](../main/commentary/P7-commentary.txt) | `b2b5d200c532143a586b1c68cfc0ea77a2f253038855aab35d6be72877c954d6` | - | - | +| P7 | Smart contract costs and new queries, stake cooldown changes, disabling shielded transfers, revised block hashing | - | - | [P7.txt](../main/updates/P7.txt) | [P7-commentary.txt](../main/commentary/P7-commentary.txt) | `e68ea0b16bbadfa5e5da768ed9afe0880bd572e29337fe6fb584f293ed7699d6` | - | - | ## Website diff --git a/commentary/P7-commentary.txt b/commentary/P7-commentary.txt index f95b898..d6c6175 100644 --- a/commentary/P7-commentary.txt +++ b/commentary/P7-commentary.txt @@ -123,7 +123,7 @@ blockchain is an entirely public record. This feature has not seen wide adoption (at time of writing, less than 200000 CCD is shielded) and has generally been more confusing than -beneficial for users, who may have mistakenly shieled their balances +beneficial for users, who may have mistakenly shielded their balances unnecessarily, without properly understanding the use of shielded transfers. Furthermore, financial institutions with obligations under diff --git a/source/updates/P7.rst b/source/updates/P7.rst index 265392a..ed85c65 100644 --- a/source/updates/P7.rst +++ b/source/updates/P7.rst @@ -10,7 +10,7 @@ Protocol Update 7 - Smart contract costs and new queries, stake cooldown changes * - Effective on Mainnet - TBD * - Specification hash - - ``b2b5d200c532143a586b1c68cfc0ea77a2f253038855aab35d6be72877c954d6`` + - ``e68ea0b16bbadfa5e5da768ed9afe0880bd572e29337fe6fb584f293ed7699d6`` Specification ============= diff --git a/updates/P7.txt b/updates/P7.txt index 05c1bdd..b23aae2 100644 --- a/updates/P7.txt +++ b/updates/P7.txt @@ -54,7 +54,7 @@ removes its stake, the amount of the stake reduction is held in a cooldown state. During the cooldown period, the stake cannot be spent, and remains part of the effective stake (used for lottery and reward calculation). Once the cooldown period has elapsed, the stake is available to be spent, and -no longer contributes to the effective stake of the baker or delegator. +no longer contributes to the effective stake of the validator or delegator. While the cooldown is in effect on an account, no other changes can be made to the account's stake. @@ -62,7 +62,7 @@ From protocol version 7, when a validator or delegator reduces its stake, the stake reduction takes effect straight away, but the amount of the reduction enters a cooldown queue. (Note that "straight away" here does not mean that it has an instant effect on the lottery and rewards. The -effective stakes of bakers and delegators are sampled in the first block +effective stakes of validators and delegators are sampled in the first block of the last epoch before each payday, with the sampled stakes being used for the upcoming payday. Although the change is recorded on the account immediately, it will be between 1 epoch and 1 payday plus 1 epoch until @@ -270,7 +270,7 @@ The following behaviors are changed in protocol version 7. 4. The following changes apply to staking: - The stake of an account is divided into - * Active stake: this determines the baker or validator's + * Active stake: this determines the validator or delegator's stake for future snapshots that determine the stake distribution for the purposes of lottery calculation and reward distribution.