From cdcfd4bfbea57494ec95578d33848b163e95e1fd Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 19 Jan 2023 10:58:53 +0000 Subject: [PATCH 001/103] fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation --- protocol/0035-LIQM-liquidity_monitoring.md | 23 +++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index 4d3008e6a..3908ad293 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -16,9 +16,11 @@ Note that [target stake](./0041-TSTK-target_stake.md) is defined in a separate s (*) Having `best_bid` and `best_offer` implies that `mid` also exists. If, in the future, [LP batch orders](./0038-OLIQ-liquidity_provision_order_type.md) are updated to allow other pegs then the protocol must enforce that they are also on the book. -## Liquidity auction network parameters +## Liquidity auction parameters -**c1** - constant multiple for [target stake](./0041-TSTK-target_stake.md) triggering the commencement of liquidity auction. In this spec it is referred to as `c_1` but in fact it's name is `market.liquidity.targetstake.triggering.ratio` and it's a market parameter (with a network parameter providing a default value for markets that don't specify it). +**c1** - constant multiple for [target stake](./0041-TSTK-target_stake.md) triggering the commencement of liquidity auction. In this spec it is referred to as `c_1` but in fact it `triggering_ratio` in `LiquidityMonitoringParameters` in market creation or update proposal. + +There is also a network parameter `market.liquidity.targetstake.triggering.ratio` which carries the suggested default value *but has no effect on the running system*. ## Total stake @@ -75,12 +77,11 @@ As mentioned, as a consequence, intrablock, we may end with one side of the book ## Acceptance Criteria 1. The scenarios in the feature test [0026-AUCT-auction_interaction.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0026-AUCT-auction_interaction.feature) are verified and pass. (0035-LIQM-001) -2. An incoming order that would consume `best_bid` or `best_offer` gets executed (unless it will also trigger price monitoring auction at the same time), the trades are generated. The volume implied by LP provision is removed (from both sides of the book and for all LPs). If `best_bid` is missing but `best_ask` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_ask` as peg are still deployed. If `best_ask` is missing but `best_bid` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_bid` as peg are still deployed. The market goes into a liquidity auction at the end of a block (because there is a peg missing and the liquidity provision volume is not deployed). (0035-LIQM-002) -3. A market which enters a state requiring liquidity auction at the end of a block through increased open interest remains in open trading between entering that state and the end of the block. (0035-LIQM-003) -4. A market which enters a state requiring liquidity auction at the end of a block through decreased total stake (e.g. through LP bankruptcy) remains in open trading between entering that state and the end of the block. (0035-LIQM-004) -5. A market which enters a state requiring liquidity auction through increased open interest during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-005) -6. A market which enters a state requiring liquidity auction through reduced current stake (e.g. through LP bankruptcy) during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-006) -7. A liquidity provider cannot remove their liquidity within the block if this would bring the current total stake below the target stake as of that transaction. (0035-LIQM-007) -8. If the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) -9. When the network parameter `market.liquidity.targetstake.triggering.ratio` is updated via governance, future new market and update market proposals which do not specify a `triggeringRatio` should copy the new network parameter as the market parameter value. (0035-LIQM-009) -10. When the market parameter `triggeringRatio` for an existing market is updated via governance, the next time conditions for entering auction are evaluated, the new triggering ratio is applied. (0035-LIQM-010) +1. An incoming order that would consume `best_bid` or `best_offer` gets executed (unless it will also trigger price monitoring auction at the same time), the trades are generated. The volume implied by LP provision is removed (from both sides of the book and for all LPs). If `best_bid` is missing but `best_ask` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_ask` as peg are still deployed. If `best_ask` is missing but `best_bid` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_bid` as peg are still deployed. The market goes into a liquidity auction at the end of a block (because there is a peg missing and the liquidity provision volume is not deployed). (0035-LIQM-002) +1. A market which enters a state requiring liquidity auction at the end of a block through increased open interest remains in open trading between entering that state and the end of the block. (0035-LIQM-003) +1. A market which enters a state requiring liquidity auction at the end of a block through decreased total stake (e.g. through LP bankruptcy) remains in open trading between entering that state and the end of the block. (0035-LIQM-004) +1. A market which enters a state requiring liquidity auction through increased open interest during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-005) +1. A market which enters a state requiring liquidity auction through reduced current stake (e.g. through LP bankruptcy) during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-006) +1. A liquidity provider cannot remove their liquidity within the block if this would bring the current total stake below the target stake as of that transaction. (0035-LIQM-007) +1. If the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) +1. When the market parameter `triggeringRatio` for an existing market is updated via governance, the next time conditions for entering auction are evaluated, the new triggering ratio is applied. (0035-LIQM-010) From d99362169182158aec59879725fcb79c22cd781a Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 19 Jan 2023 11:14:47 +0000 Subject: [PATCH 002/103] fix: duplicate AC codes in 0069-VCBS (#1536) --- protocol/0069-VCBS-validators_chosen_by_stake.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 5b9c41ccc..de2847c52 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -511,13 +511,13 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). 1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-COSMICELEVATOR-002) 1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-COSMICELEVATOR-003) 1. It is possible to submit a transaction to update the weights. (0069-COSMICELEVATOR-004) -1. Can update multisig for new validator, and expect rewards (0069-VCBS-050) +1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-051) +1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. From c2cb333d4db75ee0e0cf631d18a2f2f32e6dd193 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 19 Jan 2023 11:33:26 +0000 Subject: [PATCH 003/103] chore: trailing spaces --- protocol/0035-LIQM-liquidity_monitoring.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index 3908ad293..eeb0ff634 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -18,9 +18,9 @@ Note that [target stake](./0041-TSTK-target_stake.md) is defined in a separate s ## Liquidity auction parameters -**c1** - constant multiple for [target stake](./0041-TSTK-target_stake.md) triggering the commencement of liquidity auction. In this spec it is referred to as `c_1` but in fact it `triggering_ratio` in `LiquidityMonitoringParameters` in market creation or update proposal. +**c1** - constant multiple for [target stake](./0041-TSTK-target_stake.md) triggering the commencement of liquidity auction. In this spec it is referred to as `c_1` but in fact it `triggering_ratio` in `LiquidityMonitoringParameters` in market creation or update proposal. -There is also a network parameter `market.liquidity.targetstake.triggering.ratio` which carries the suggested default value *but has no effect on the running system*. +There is also a network parameter `market.liquidity.targetstake.triggering.ratio` which carries the suggested default value *but has no effect on the running system*. ## Total stake From 30a078db7063fa8a41cff5bca527b037c046e6b3 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 19 Jan 2023 11:44:45 +0000 Subject: [PATCH 004/103] fix: remove the unused netparam; not liking that --- protocol/0035-LIQM-liquidity_monitoring.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index eeb0ff634..28cea94cd 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -20,8 +20,6 @@ Note that [target stake](./0041-TSTK-target_stake.md) is defined in a separate s **c1** - constant multiple for [target stake](./0041-TSTK-target_stake.md) triggering the commencement of liquidity auction. In this spec it is referred to as `c_1` but in fact it `triggering_ratio` in `LiquidityMonitoringParameters` in market creation or update proposal. -There is also a network parameter `market.liquidity.targetstake.triggering.ratio` which carries the suggested default value *but has no effect on the running system*. - ## Total stake `total_stake` is the sum the stake amounts committed by all the LPs in the market (see [LP mechanics](./0044-LIME-lp_mechanics.md)) for how LPs commit stake and what it obliges them to do. From 4ff8a82c93d7680d8b4b232677d418ea27559320 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 19 Jan 2023 12:45:23 +0000 Subject: [PATCH 005/103] chore: remove untestable AC from 0018 (#1530) --- protocol/0018-RSKM-quant_risk_models.ipynb | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/protocol/0018-RSKM-quant_risk_models.ipynb b/protocol/0018-RSKM-quant_risk_models.ipynb index faf8bef4a..8f60842e0 100644 --- a/protocol/0018-RSKM-quant_risk_models.ipynb +++ b/protocol/0018-RSKM-quant_risk_models.ipynb @@ -108,15 +108,13 @@ "source": [ "## Acceptance Criteria\n", "\n", - "1. [ ] Different markets can have a different risk model (i.e. a market A can be specified to run with risk model R1 while market B can be specified to run with risk model R2). (0018-RSKM-001)\n", - "1. [ ] The risk factors are recalculated only when the inputs have changed since the last call. (0018-RSKM-002)\n", - "1. [ ] If any of the input data has changed then an update to risk factors is initiated. (0018-RSKM-003)\n", - "1. [ ] Risk factors are agreed upon by consensus. (0018-RSKM-004)\n", - "1. [ ] If the risk factor calculation reports \"guaranteed accuracy\" then the risk factors are appropriately rounded. (0018-RSKM-005)\n", - "1. [ ] If an async update to risk factors is already running, don't start a new one until the previous one has finished. (0018-RSKM-006)\n", - "1. [ ] Quant risk suite can compute max move up/down ($\\Delta^-$ and $\\Delta^+$) given current price level and a projection horizon such that the resulting prices are within a specified probability level. (0018-RSKM-007)\n", - "1. [ ] Quant risk suite can compute probability of trading at a given level. (0018-RSKM-008)\n", - "1. [ ] Lognormal risk model has defined ranges of valid parameters and market proposals and market update proposals are checked against these. The ranges can be found in core (https://github.com/vegaprotocol/vega/blob/develop/commands/proposal_submission.go#L820). (0018-RSKM-009)" + "1. Different markets can have a different risk model (i.e. a market A can be specified to run with risk model R1 while market B can be specified to run with risk model R2). (0018-RSKM-001)\n", + "1. If any of the input data has changed then an update to risk factors is initiated. (0018-RSKM-003)\n", + "1. Risk factors are agreed upon by consensus. (0018-RSKM-004)\n", + "1. If the risk factor calculation reports \"guaranteed accuracy\" then the risk factors are appropriately rounded. (0018-RSKM-005)\n", + "1. Quant risk suite can compute max move up/down ($\\Delta^-$ and $\\Delta^+$) given current price level and a projection horizon such that the resulting prices are within a specified probability level. (0018-RSKM-007)\n", + "1. Quant risk suite can compute probability of trading at a given level. (0018-RSKM-008)\n", + "1. Lognormal risk model has defined ranges of valid parameters and market proposals and market update proposals are checked against these. The ranges can be found in core (https://github.com/vegaprotocol/vega/blob/develop/commands/proposal_submission.go#L820). (0018-RSKM-009)" ] }, { From fd16996b83e62a32dce7b793c9391221ba415846 Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Thu, 19 Jan 2023 13:31:17 +0000 Subject: [PATCH 006/103] chore: reword 0063-VALK-013 --- protocol/0063-VALK-validator_vega_master_keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0063-VALK-validator_vega_master_keys.md b/protocol/0063-VALK-validator_vega_master_keys.md index 1fc34d3f4..2f753a209 100644 --- a/protocol/0063-VALK-validator_vega_master_keys.md +++ b/protocol/0063-VALK-validator_vega_master_keys.md @@ -46,4 +46,4 @@ The public master key has to be added to validators' identities in the genesis c - If several key change transactions are submitted simultaneously (i.e., a new key change is submitted before the target block of a previous one is reached, if key change message 1 has a lower sequence number and a higher/the same target block as change message 2, then the key established by message 2 is not replaced by the key from message 1. This can be done either by managing the parallel executions appropriately or by rejecting additional submissions(0063-VALK-010) - Once the target block of a key change action us reached, all preceding keys (the original key as well as all hot keys rotated in through a key-change ,messager with a lower sequence number) are invalid. (0063-VALK-011) - Key change message with a lower sequence number than the last one executed are rejected. (0063-VALK-012) -- Once a validator hot key has been rotated, reward balances are carried over to the new key. (0063-VALK-013) +- Once a validator hot key has been rotated, it is possible to withdraw all rewards in the original keys account or submit a transfer to move them to the new key's account i.e the old key is still functional as a non-validator vega key. (0063-VALK-013) From 5c5cd6a15a8e7279e7b864194882a9df1144ddfa Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Thu, 19 Jan 2023 13:38:41 +0000 Subject: [PATCH 007/103] Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md --- protocol/0035-LIQM-liquidity_monitoring.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index 28cea94cd..89341e67a 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -83,3 +83,4 @@ As mentioned, as a consequence, intrablock, we may end with one side of the book 1. A liquidity provider cannot remove their liquidity within the block if this would bring the current total stake below the target stake as of that transaction. (0035-LIQM-007) 1. If the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) 1. When the market parameter `triggeringRatio` for an existing market is updated via governance, the next time conditions for entering auction are evaluated, the new triggering ratio is applied. (0035-LIQM-010) +1. When proposing a new market if the triggering_ratio is not supplied then the current value of `market.liquidity.targetstake.triggering.ratio` is used in its place. (0035-LIQM-011) From 9dba3121d04d8be30bb609317441c89851971ed4 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 19 Jan 2023 13:45:39 +0000 Subject: [PATCH 008/103] fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) --- protocol/0035-LIQM-liquidity_monitoring.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index 89341e67a..8a7d58986 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -83,4 +83,4 @@ As mentioned, as a consequence, intrablock, we may end with one side of the book 1. A liquidity provider cannot remove their liquidity within the block if this would bring the current total stake below the target stake as of that transaction. (0035-LIQM-007) 1. If the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) 1. When the market parameter `triggeringRatio` for an existing market is updated via governance, the next time conditions for entering auction are evaluated, the new triggering ratio is applied. (0035-LIQM-010) -1. When proposing a new market if the triggering_ratio is not supplied then the current value of `market.liquidity.targetstake.triggering.ratio` is used in its place. (0035-LIQM-011) +1. When proposing a new market if the triggering_ratio is not supplied then the current value of `market.liquidity.targetstake.triggering.ratio` is used in its place. (0035-LIQM-011) From fad492eeb327b4d9006d3551c24bdb89531cfdf2 Mon Sep 17 00:00:00 2001 From: RomanLeca Date: Thu, 19 Jan 2023 16:31:43 +0200 Subject: [PATCH 009/103] Update 0011-NP-CLIE-client-interaction-tests.md --- non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index 488e3834c..b83585410 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -13,8 +13,8 @@ This specification contains a set of tests/acceptance criteria that clients (wal 3. The parameter `spam.pow.difficulty` is increased. Verify that: - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-003) 4. The parameter `spam.pow.difficulty` is decreased. Verify that - - This is communicated to the wallet, and the wallet use these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-004) + - This is communicated to the wallet, and the wallet uses these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-004) 5. The parameter `spam.pow.increaseDifficulty` is changed from `0` to `1`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-005) -6. The parameter `spam.pow.increaseDifficulty` is changed from `1` to `0`. Verify that +6. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` PoWs tied to a given block before using another. If this results in none being available the transaction should not be sent. (0011-NP-CLIE-006) From f7b5aad27a9ab539a9ab5d2a790234f9d8fb9e92 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 19 Jan 2023 14:52:31 +0000 Subject: [PATCH 010/103] feat: allow any key to request multisg signers update bundle --- protocol/0069-VCBS-validators_chosen_by_stake.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index de2847c52..aa154f6fa 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -524,3 +524,4 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that no rewards are paid out on the first epoch. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. +1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) From c98ec2899fb97e3f0da436d958eb72e342985906 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 19 Jan 2023 14:54:09 +0000 Subject: [PATCH 011/103] feat: clarify spam status --- protocol/0069-VCBS-validators_chosen_by_stake.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index aa154f6fa..57cd4692d 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -524,4 +524,4 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that no rewards are paid out on the first epoch. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) +1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) From c5423e5ecbdbb48a4575ff0da6817da4bb0b7457 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 17 Jan 2023 16:18:15 +0100 Subject: [PATCH 012/103] refactor: let max oi drop during auciton --- protocol/0041-TSTK-target_stake.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index f767ffa25..a7d77df0c 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -21,6 +21,8 @@ The parameter c_1 is a market parameter (with network parameter `market.liquidit First, `max_oi` is defined maximum (open interest) measured over a time window, `t_window = [max(t-market.stake.target.timeWindow,t0),t]`. Here `t` is current time with `t0` being the end of market opening auction. Note that `max_oi` should be calculated recorded per transaction, so if there are multiple OI changes withing the same block (which implies the same timestamp), we should pick the max one, NOT the last one that was processed. +If the market is in auction mode the `max_oi` can only increase while `auction duration` <= `market.stake.target.timeWindow`. Once the market's been in the auction for more than `market.stake.target.timeWindow` the `max_oi` is whatever the current positions and `indicative_uncrossing_volume` imply - specifically, this allows the `target_stake` to drop as a result of trades generated in the auction so that `target_stake` > `supplied_stake` (even in absence of changes to `supplied_stake`) and the market can go back to its default trading mode. + Example 1: `t_market.stake.target.timeWindow = 1 hour` the market opened at `t_0 = 1:55`. From 08906798bfab4e7806902f35cfce5971be6c8fd7 Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Mon, 23 Jan 2023 15:56:27 +0000 Subject: [PATCH 013/103] Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section --- protocol/0062-SPAM-spam_protection.md | 79 +++++++++++++-------------- 1 file changed, 38 insertions(+), 41 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index b657774ab..ff2aafbca 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -1,82 +1,79 @@ # Spam protection -At this point, we cannot reject a transaction based on any data that is not the shared state -of the blockchain. This means, it is unavoidable that one spammer can essentially fill a block. +At this point, the network cannot reject a transaction based on any data that is not the shared state of the blockchain. This means, it is unavoidable that one spammer can essentially fill a block. -What we can do is: +What the network can do is: - remove the offending transactions after the block is scheduled, i.e., not process them - update the state once a block is finalised and block transactions based on the new state - delete transactions from every (honest) validators mempool based on the new state. -Thus, no matter what the anti-spam policy is, there is a scenario where someone creates -a lot of identities and spams one block with each. Therefore, we have to enforce a minimum -investment to be allowed to send anything to the Vega network. +Thus, no matter what the anti-spam policy is, there is a scenario where someone creates a lot of identities and spams one block with each. Therefore, we have to enforce a minimum investment to be allowed to send anything to the Vega network. -For governance votes, that means that there is a minimum amount of tokens required to be allowed -to issue a proposal/vote (`spam.protection.proposal.min.tokens`/`spam.protection.voting.min.tokens`). If the network detects successful spam in spite of this minimum, then the limit can be increased automatically. +## Governance spam -For SW, we only have governance, so the following two policies will do: +The spam protection enforcement for governance actions require that a public key must have a set minimum amount of tokens to be allowed to issue a proposal or vote on a proposal (`spam.protection.proposal.min.tokens`/`spam.protection.voting.min.tokens`). If the network detects successful spam in spite of this minimum, then the limit can be increased automatically. -Vote transactions can be rejected if a if a party has less than `spam.protection.voting.min.tokens`. Any governance proposal transaction can be rejected if a party has less than `spam.protection.proposal.min.tokens`. Setting these reasonably high provides some level of protection. -Any qualified voter can vote `spam.protection.max.votes` times per epoch per active proposal (e.g., if it's `3` then one initial vote and twice change their mind). +The following three policies are also specific to governance actions: -If 3 blocks in a row for filled with spam i.e., parties sending substantially more than 3 votes, let's say 50 votes), -then the number of required tokens is doubled, up to a maximum of 1600 (if someone pays 1.5 million to spam us for 60 -seconds so be it). +- Vote transactions can be rejected if a party has less than `spam.protection.voting.min.tokens`. +- Any governance proposal transaction can be rejected if a party has less than `spam.protection.proposal.min.tokens`. Setting these reasonably high provides some level of protection. +- Any qualified voter can vote `spam.protection.max.votes` times per epoch per active proposal (e.g., if it's `3` then one initial vote and 2 follow-on votes to change their mind. -All parameters are up to discussion/governance vote. A change of parameters is taking effect in the epoch following the acceptance of the -corresponding proposals. +If 3 blocks in a row are filled with spam, i.e., parties send substantially more than 3 votes, let's say 50 votes), then the number of required tokens is doubled, up to a maximum of 1600. -## More detailed description +All are network parameters and thus up for discussion/governance vote. A change of parameters takes effect in the epoch following the acceptance of the corresponding proposal. ### Policy Enforcement -The policy enforcement mechanism rejects messages that do not follow the anti-spam rules. This can happen in two different ways: +The policy enforcement mechanism rejects governance messages that do not follow the anti-spam rules. This can happen in two different ways: -- pre-block reject: A transaction is rejected before it enters the validators mempool. For Tendermint-internal reasons, this can only happen based on the global state coordinated through the previous block; especially, it cannot be based on any other transactions received by the validator but not yet put into a block (e.g., only three transactions per party per block). Once a block is scheduled, all validators also test all transactions in their mempool if they are still passing the test, and remove them otherwise. -- post-block-reject: A transaction has made it into the block, but is rejected before it is passed to the application layer. This mechanism allows for more fine-grained policies than the previous one, but at the price that the offending transaction has already taken up space in the blockchain. +- pre-block rejection: A transaction is rejected before it enters the validators' mempool. For Tendermint-internal reasons, this can only happen based on the global state coordinated through the previous block; in particular, it cannot be based on any other transactions received by the validator but not yet put into a block (e.g., only three transactions per party per block). Once a block is scheduled, all validators also test all transactions in their mempool to confirm they are still passing the test, and remove them otherwise. +- post-block-rejection: A transaction has made it into the block, but is rejected before it is passed to the application layer. This mechanism allows for more fine-grained policies than the previous one, but at the price that the offending transaction has already taken up space in the blockchain. -For Sweetwater, the policies we enforce are relatively simple: +The policies enforced are relatively simple: -```math - = 3 - = 1 - = 3 - = 200000 +```text +num_votes = 3 +min_voting_tokens = 1 +num_proposals = 3 +min_proposing_tokens = 200000 ``` -- Any tokenholder with more than `` tokens has `` voting attempts per epoch and proposal, i.e., they can change their mind `-1` times in one epoch. This means, a transaction is pre_block rejected, if there are `` or more votes on the same proposal in the blockchain in this epoch, and post_block rejected, if there are `` or more on the same proposal in the blockchain plus earlier in the current block. -- Any tokenholder that had more than 50% if its post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all its governance related transactions ( but no no trading related transactions) are immediately rejected. E.g. if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so a it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. - -The voting counters are unaffected by the ban, so voting again on an issue that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now likely to not trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. - -- A proposal can only be issued by a tokenholder owning more than `` at the start of the epoch. Also (like above), only `` proposals can be made per tokenholder per epoch, i.e., every proposal past `` in an epoch is rejected by post-block-reject (if there sum of proposals in past blocks and the ones in the current block exceed ``) or pre-block reject (if the sum of proposals already in the blockchain for that epoch equals or exceeds ``. This parameter is the same for all proposals (also market-creation related ones). There also is a separate parameter to the same end that is enforced in the core. For SW, both these parameters have the same value. In the future, we can set the spam protection value lower, as the amplification effect of a proposal (i.e., a proposal resulting in a very large number of votes) would also be covered by the core then. +- Any tokenholder with more than `min_voting_tokens` tokens on a public key has `num_votes` voting attempts per epoch and proposal, i.e., they can change their mind `num_votes-1` times in one epoch. This means a transaction is pre-block rejected if there are `num_votes` or more on the same proposal in the blockchain in the same epoch, and post_block rejected if there are `num_votes` or more on the same proposal in the blockchain plus earlier in the current block. +- Any tokenholder that had more than 50% of its governance transactions post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all of its governance related transactions (but no trading related transactions) are immediately rejected. E.g., if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. The voting counters are unaffected by the ban, so voting again on a proposal that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now unlikely to trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. +- A proposal can only be issued by a tokenholder with more than `min_proposing_tokens` associated with one public key at the start of the epoch. Also (like above), only `num_proposals` proposals can be made per tokenholder per epoch. For example, every proposal past `num_proposals` in an epoch is rejected by post-block-rejected if the sum of their proposals in past blocks and the ones in the current block exceed `num_proposals`, or pre-block rejected if the sum of proposals already in the blockchain for that epoch equals or exceeds `num_proposals`. This parameter is the same for **all proposals**. There also is a separate parameter to the same end that is enforced in the core. For Sweetwater, both these parameters had the same value, but the spam protection value can be set lower, as the amplification effect of a proposal (i.e., a proposal resulting in a very large number of votes) would also then be covered by the core. ### Notes - What counts is the number of tokens at the beginning of the epoch. While it is unlikely (given gas prices and ETH speed) that the same token is moved around to different entities, this explicitly doesn't work. -- This means that every tokenholder with more than `` can spam exactly one block on SW. +- Every tokenholder with more than `min_voting_tokens` can spam exactly one block. - There is some likelihood that policies will change. It would thus be good to have a clean separation of policy definition and enforcement, so a change in the policies can be implemented and tested independently of the enforcement code. ### Increasing thresholds -If on average for the last 10 blocks, more than 30% of all voting and proposal transactions need to be post-rejected, then the network is -under Spam attack. In this case, the `` value is doubled, until it reaches 1600. The threshold -is then not increased for another 10 blocks. At the beginning of every epoch, the value of `` is reset to its original. +If on average for the last 10 blocks, more than 30% of all voting and proposal transactions need to be post-rejected, then the network is under spam attack. In this case, the `min_voting_tokens` value is doubled, until it reaches 1600. The threshold is then not increased for another 10 blocks. At the beginning of every epoch, the value of `min_voting_tokens` is reset to its original. + +### Issues -### Issues: It is possible for a tokenholder to deliberately spam the network to block poorer parties from voting +**It is possible for a tokenholder to deliberately spam the network to block poorer parties from voting.** -Due to the banning policy this is not doable from one account, but with a sybil attack it can be done. If this ends up being a problem, we can address it by increasing the ban-time. +Due to the banning policy this is not doable from one key, but with a sybil attack it can be done. If this ends up being a problem, we can address it by increasing the ban-time. -### Withdrawal Spam +## Withdrawal spam As unclaimed withdrawals do not automatically expire, an attacker could generate a large number of messages as well as an ever-growing data structure through [withdrawal requests](0030-ETHM-multisig_control_spec.md). To avoid this, all withdrawal requests need a minimum withdrawal amount controlled by the network parameter `spam.protection.minimumWitdrawalQuantumMultiple`. -The minimum allowed withdrawal amount is `spam.protection.minimumWitdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any vega asset that has roughly value of 1 USD. +The minimum allowed withdrawal amount is `spam.protection.minimumWitdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any Vega asset that has a rough value of 1 USD. + Any withdrawal requests for a smaller amounts are immediately rejected. +### Related topics + +- [Spam protection: Proof of work](https://github.com/vegaprotocol/specs/blob/master/protocol/0072-SPPW-spam-protection-PoW.md) +- [Transaction gas and priority](https://github.com/vegaprotocol/specs/blob/master/protocol/0079-TGAP-transaction_gas_and_priority.md) + ### Acceptance Criteria A spam attack using votes/governance proposals is detected and the votes transactions are rejected, i.e., a party that issues too many votes/governance proposals gets the follow on transactions rejected. This means (given the original parameters parameters from [0054-NETP-network_parameters.md](https://github.com/vegaprotocol/specs-internal/blob/master/protocol/0054-NETP-network_parameters.md)) @@ -92,7 +89,7 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Transaction creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004) - Transaction submitting votes by parties with less than `spam.protection.voting.min.tokens` vega associated are rejected. (0062-SPAM-005) - Transactions submitting a vote more than `spam.protection.max.votes` times on any one proposal are rejected. (0062-SPAM-006) -- Above thresholds are exceeded in one block, leading to a post-block-reject (0062-SPAM-007) +- Above thresholds are exceeded in one block, leading to a post-block-rejection (0062-SPAM-007) - If 50% of a parties votes/transactions are post-block-rejected, it is blocked for 4 Epochs and unblocked afterwards again (0062-SPAM-008) - It is possible for spam transactions to fill a block (0062-SPAM-010) - Parties that continue spamming are blocked and eventually unblocked again (0062-SPAM-011) From 2069690ee8a59a45962acd1c79b92f1a42282549 Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Wed, 25 Jan 2023 16:40:42 +0000 Subject: [PATCH 014/103] fix spelling in spam protection spec (#1553) --- protocol/0062-SPAM-spam_protection.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index ff2aafbca..4e56e7583 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -6,7 +6,7 @@ What the network can do is: - remove the offending transactions after the block is scheduled, i.e., not process them - update the state once a block is finalised and block transactions based on the new state -- delete transactions from every (honest) validators mempool based on the new state. +- delete transactions from every (honest) validator's mempool based on the new state. Thus, no matter what the anti-spam policy is, there is a scenario where someone creates a lot of identities and spams one block with each. Therefore, we have to enforce a minimum investment to be allowed to send anything to the Vega network. @@ -64,10 +64,11 @@ Due to the banning policy this is not doable from one key, but with a sybil atta As unclaimed withdrawals do not automatically expire, an attacker could generate a large number of messages as well as an ever-growing data structure through [withdrawal requests](0030-ETHM-multisig_control_spec.md). -To avoid this, all withdrawal requests need a minimum withdrawal amount controlled by the network parameter `spam.protection.minimumWitdrawalQuantumMultiple`. -The minimum allowed withdrawal amount is `spam.protection.minimumWitdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any Vega asset that has a rough value of 1 USD. +To avoid this, all withdrawal requests need a minimum withdrawal amount controlled by the network parameter `spam.protection.minimumWithdrawalQuantumMultiple`. -Any withdrawal requests for a smaller amounts are immediately rejected. +The minimum allowed withdrawal amount is `spam.protection.minimumWithdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any asset on Vega that has a rough value of 1 USD. + +Any withdrawal request for a smaller amount is immediately rejected. ### Related topics @@ -76,7 +77,7 @@ Any withdrawal requests for a smaller amounts are immediately rejected. ### Acceptance Criteria -A spam attack using votes/governance proposals is detected and the votes transactions are rejected, i.e., a party that issues too many votes/governance proposals gets the follow on transactions rejected. This means (given the original parameters parameters from [0054-NETP-network_parameters.md](https://github.com/vegaprotocol/specs-internal/blob/master/protocol/0054-NETP-network_parameters.md)) +A spam attack using votes/governance proposals is detected and the votes transactions are rejected, i.e., a party that issues too many votes/governance proposals gets the follow-on transactions rejected. This means (given the original parameters from [0054-NETP-network_parameters.md](https://github.com/vegaprotocol/specs-internal/blob/master/protocol/0054-NETP-network_parameters.md)) More than 360 delegation changes in one epoch (or, respectively, the value of `spam.protection.max.delegation`). This includes the undelegate transactions. Specifically, verify: @@ -86,8 +87,8 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Delegating while having less than one vega (`10^18` of our smallest unit) (`spam.protection.delegation.min.tokens`) (0062-SPAM-002) - Making a proposal when having less than 100.000 vega (`spam.protection.proposal.min.tokens`) (0062-SPAM-003) - Changing the value of network parameter `spam.protection.proposal.min.tokens` will immediately change the minimum number of associated tokens needed for any kind of governance proposal. Proposals already active aren't affected.(0062-SPAM-014) -- Transaction creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004) -- Transaction submitting votes by parties with less than `spam.protection.voting.min.tokens` vega associated are rejected. (0062-SPAM-005) +- Transactions creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004) +- Transactions submitting votes by parties with less than `spam.protection.voting.min.tokens` of Vega associated are rejected. (0062-SPAM-005) - Transactions submitting a vote more than `spam.protection.max.votes` times on any one proposal are rejected. (0062-SPAM-006) - Above thresholds are exceeded in one block, leading to a post-block-rejection (0062-SPAM-007) - If 50% of a parties votes/transactions are post-block-rejected, it is blocked for 4 Epochs and unblocked afterwards again (0062-SPAM-008) @@ -101,10 +102,10 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - If a party gets banned several times during an epoch, all banns last for the defined time or until the epoch ends (try with at least three banns) (0062-SPAM-018) - During a ban due to too many votes, all governance related transactions are rejected (0062-SPAM-019) - After having been banned for too many votes and unbanned, with the maximum number of votes in that epoch exceeded, any additional votes are rejected without a new ban. (0062-SPAM-020) -- Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWitdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021) -- Try to set `spam.protection.minimumWitdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) -- Increase `spam.protection.minimumWitdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) -- Decrease `spam.protection.minimumWitdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) -- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWitdrawalQuantumMultiple` to a value that that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001) +- Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWithdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021) +- Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) +- Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) +- Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) +- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001) -> **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed on a follow up version. +> **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. From ff8266a526963dc4f71ecbee8dbe0c991b72fda5 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Thu, 26 Jan 2023 05:46:53 -0800 Subject: [PATCH 015/103] Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 --- protocol/0069-VCBS-validators_chosen_by_stake.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 57cd4692d..967f906b0 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -406,13 +406,13 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Also verify that the ersatz validator with the insufficient own but the most delegated stake has a ranking score of 0 and doesn't get promoted. - No validator with stake attached to them is ever completely removed 1. (Alternative until we can build a large enough network for above AC ) (0069-VCBS-059) - 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, + 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, + 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) - 2 ersatz validators have 6000 stake and sufficient `ownstake` From 282901933eba85fe24f81202cc474f5fcd827153 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Thu, 26 Jan 2023 05:51:43 -0800 Subject: [PATCH 016/103] Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 --- protocol/0069-VCBS-validators_chosen_by_stake.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 967f906b0..c63fa5380 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -411,11 +411,13 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` + - the pending validator has sufficiemt 'ownstake' - Verify that the the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) - 2 ersatz validators have 6000 stake and sufficient `ownstake` + - the pending validator has sufficient 'ownstake' - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, From 7e8aaf6d5deef328b2dcd7dbf52fdc915c90e61d Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Thu, 26 Jan 2023 07:44:08 -0800 Subject: [PATCH 017/103] Update 0062-SPAM-spam_protection.md --- protocol/0062-SPAM-spam_protection.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 4e56e7583..1f3ff24c1 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -34,12 +34,20 @@ The policy enforcement mechanism rejects governance messages that do not follow The policies enforced are relatively simple: ```text -num_votes = 3 -min_voting_tokens = 1 -num_proposals = 3 -min_proposing_tokens = 200000 +num_votes = 3 // maximum number of times per epoch a tokenholder van change their vote on an issue +min_voting_tokens = 1 // minimum tokens required to be allowed to vote +num_proposals = 3 // maximum number of governance proposals per tokenholder per epoch +min_proposing_tokens = 200000 // minimum amount of tokens required to make governance proposals +max_delegations = 390 // maximal number of de-delegations per tokenholder per epioch +min_tokens_for_delegation = 1 // minimum number of tokens needed to re-delegate +minimum_withdrawal = 10 // minimum amount of asset withdrawals +min_transfer = 0.1 // minimum amount of assets for internal transfers +max_transfer_commands_per_epoch = 20 // maximal amount of internal asset transfers per epoch per key +max_batch_size = 15 // maximal number of transactions allowed in one batch; this is the maximum size of a batch ``` +(for consistency reasons, the prevailing source for all parameter values is the code file in https://github.com/vegaprotocol/vega/core/netparams/defaults.go; in case of differences, the information in that file is the valid one). + - Any tokenholder with more than `min_voting_tokens` tokens on a public key has `num_votes` voting attempts per epoch and proposal, i.e., they can change their mind `num_votes-1` times in one epoch. This means a transaction is pre-block rejected if there are `num_votes` or more on the same proposal in the blockchain in the same epoch, and post_block rejected if there are `num_votes` or more on the same proposal in the blockchain plus earlier in the current block. - Any tokenholder that had more than 50% of its governance transactions post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all of its governance related transactions (but no trading related transactions) are immediately rejected. E.g., if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. The voting counters are unaffected by the ban, so voting again on a proposal that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now unlikely to trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. - A proposal can only be issued by a tokenholder with more than `min_proposing_tokens` associated with one public key at the start of the epoch. Also (like above), only `num_proposals` proposals can be made per tokenholder per epoch. For example, every proposal past `num_proposals` in an epoch is rejected by post-block-rejected if the sum of their proposals in past blocks and the ones in the current block exceed `num_proposals`, or pre-block rejected if the sum of proposals already in the blockchain for that epoch equals or exceeds `num_proposals`. This parameter is the same for **all proposals**. There also is a separate parameter to the same end that is enforced in the core. For Sweetwater, both these parameters had the same value, but the spam protection value can be set lower, as the amplification effect of a proposal (i.e., a proposal resulting in a very large number of votes) would also then be covered by the core. From f9f0364b851da2d1a0566bff6b09513b3e2e8e08 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Thu, 26 Jan 2023 07:49:47 -0800 Subject: [PATCH 018/103] Update 0062-SPAM-spam_protection.md fixed link to defaults.go --- protocol/0062-SPAM-spam_protection.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 1f3ff24c1..4859236e5 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -46,7 +46,9 @@ max_transfer_commands_per_epoch = 20 // maximal amount of internal asset transf max_batch_size = 15 // maximal number of transactions allowed in one batch; this is the maximum size of a batch ``` -(for consistency reasons, the prevailing source for all parameter values is the code file in https://github.com/vegaprotocol/vega/core/netparams/defaults.go; in case of differences, the information in that file is the valid one). +(for consistency reasons, the prevailing source for all parameter values is the code file in +https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go +. In case of differences, the information in that file is the valid one). - Any tokenholder with more than `min_voting_tokens` tokens on a public key has `num_votes` voting attempts per epoch and proposal, i.e., they can change their mind `num_votes-1` times in one epoch. This means a transaction is pre-block rejected if there are `num_votes` or more on the same proposal in the blockchain in the same epoch, and post_block rejected if there are `num_votes` or more on the same proposal in the blockchain plus earlier in the current block. - Any tokenholder that had more than 50% of its governance transactions post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all of its governance related transactions (but no trading related transactions) are immediately rejected. E.g., if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. The voting counters are unaffected by the ban, so voting again on a proposal that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now unlikely to trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. From 1ba47f4e134c3bdf2eaebe9b2fba586513d1bdc9 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 27 Jan 2023 20:01:39 +0000 Subject: [PATCH 019/103] Add quality checks to the makefile (#1556) --- .github/workflows/config/markdownlint.json | 4 +-- makefile | 23 +++++++++++++--- markdownlint.sh | 9 +++++++ protocol/0057-TRAN-transfers.md | 2 +- protocol/0062-SPAM-spam_protection.md | 4 +-- .../0069-VCBS-validators_chosen_by_stake.md | 4 +-- spellcheck.sh | 13 +++++++++ spellcheck.yaml | 27 ------------------- 8 files changed, 48 insertions(+), 38 deletions(-) create mode 100755 markdownlint.sh create mode 100755 spellcheck.sh diff --git a/.github/workflows/config/markdownlint.json b/.github/workflows/config/markdownlint.json index 403f776d9..ea3d61a0c 100644 --- a/.github/workflows/config/markdownlint.json +++ b/.github/workflows/config/markdownlint.json @@ -5,5 +5,5 @@ "commands-show-output": false, "no-bare-urls": true, "no-inline-html": false, - "no-hard-tabs": false, -} \ No newline at end of file + "no-hard-tabs": false +} diff --git a/makefile b/makefile index d2e5fe53a..5ffda02a0 100644 --- a/makefile +++ b/makefile @@ -1,18 +1,35 @@ -all: names codes references +# Set default to run all checks if none specified +.DEFAULT_GOAL := all + +all: spellcheck markdownlint names codes links references # Check that all the specifications are named appropriately +.PHONY: names names: npx @vegaprotocol/approbation check-filenames # Count how many Acceptance Criteria each specification has +.PHONY: codes codes: npx @vegaprotocol/approbation check-codes # Which Acceptance Criteria are referenced in which feature files? +.PHONY: references references: npx @vegaprotocol/approbation check-references # Imperfect, but useful - hence not included in ALL +.PHONY: links links: - npx markdown-link-check protocol/*.md - npx markdown-link-check non-protocol-specs/*.md + npx --yes markdown-link-check protocol/*.md + npx --yes markdown-link-check non-protocol-specs/*.md + +# check the markdown formatting (/protocol specs only at this time) +.PHONY: markdownlint +markdownlint: + @./markdownlint.sh + +# check the markdown spelling (/protocol specs only at this time) +.PHONY: spellcheck +spellcheck: + @./spellcheck.sh diff --git a/markdownlint.sh b/markdownlint.sh new file mode 100755 index 000000000..bf1aa2fcd --- /dev/null +++ b/markdownlint.sh @@ -0,0 +1,9 @@ +#!/bin/bash -x + +echo "Installing markdownlint-cli..." + +npm install -g markdownlint-cli --yes + +echo "Running markdownlint-cli..." + +markdownlint --ignore-path .github/workflows/config/markdownlintignore --config .github/workflows/config/markdownlint.json . diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 11a88d6bb..e957fe2db 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -120,7 +120,7 @@ Note: if there is no market with contribution to the reward metric - no transfer A fee is taken from all transfers, and paid out to validators in a similar manner to the existing [infrastructure fees](0059-simple-POS-rewards.md). For recurring transfers, the fee is charged each time the transfer occurs. -The fee is set by the `transfer.fee.factor` [network parameter](#network-parameter) that defines the proportion of each transfer taken as a fee. +The fee is set by the `transfer.fee.factor` [network parameter](#network-parameters) that defines the proportion of each transfer taken as a fee. The fee is taken from the transfer initiator's account immediately on execution, and is taken on top of the total amount transferred. It is [paid in to the infrastructure fee pool](./0029-fees.md#collecting-and-distributing-fees). Fees are charged in the asset that is being transferred. diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 4859236e5..bf2f1f0f2 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -46,9 +46,7 @@ max_transfer_commands_per_epoch = 20 // maximal amount of internal asset transf max_batch_size = 15 // maximal number of transactions allowed in one batch; this is the maximum size of a batch ``` -(for consistency reasons, the prevailing source for all parameter values is the code file in -https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go -. In case of differences, the information in that file is the valid one). +(for consistency reasons, the prevailing source for all parameter values is the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go)code file. In case of differences, the information in that file is the valid one). - Any tokenholder with more than `min_voting_tokens` tokens on a public key has `num_votes` voting attempts per epoch and proposal, i.e., they can change their mind `num_votes-1` times in one epoch. This means a transaction is pre-block rejected if there are `num_votes` or more on the same proposal in the blockchain in the same epoch, and post_block rejected if there are `num_votes` or more on the same proposal in the blockchain plus earlier in the current block. - Any tokenholder that had more than 50% of its governance transactions post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all of its governance related transactions (but no trading related transactions) are immediately rejected. E.g., if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. The voting counters are unaffected by the ban, so voting again on a proposal that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now unlikely to trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index c63fa5380..b073fb258 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -411,13 +411,13 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` - - the pending validator has sufficiemt 'ownstake' + - the pending validator has sufficient `ownstake` - Verify that the the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) - 2 ersatz validators have 6000 stake and sufficient `ownstake` - - the pending validator has sufficient 'ownstake' + - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, diff --git a/spellcheck.sh b/spellcheck.sh new file mode 100755 index 000000000..5f0c26bd4 --- /dev/null +++ b/spellcheck.sh @@ -0,0 +1,13 @@ +#!/bin/bash -x + +echo "Installing pyspelling..." + +pip3 install pyspelling + +echo "Installing aspell..." + +brew install aspell + +echo "Running the spell checker..." + +pyspelling --config spellcheck.yaml diff --git a/spellcheck.yaml b/spellcheck.yaml index afac368e5..27149b6ba 100644 --- a/spellcheck.yaml +++ b/spellcheck.yaml @@ -46,30 +46,3 @@ matrix: - api-ref-button - code - pre - - - name: Python - sources: - - "scripts/*.py" - default_encoding: utf-8 - aspell: - d: en_GB - lang: en - dictionary: - encoding: utf-8 - output: .pyspelling-custom-py.dic.tmp - wordlists: - - wordlist.txt - pipeline: - - pyspelling.filters.context: - context_visible_first: true - escapes: '\\[\\`]' - delimiters: - # Ignore multiline content between (possibly indented) triple backticks - - open: '(?s)^(?P[ ]*```)' - close: '^(?P=open)$' - # Ignore text between inline back ticks - - open: '(?P`)' - close: '(?P=open)' - - pyspelling.filters.python: - strings: false - comments: false From 01e6b3f7490e0764653edfce29500150ca3e5c00 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 30 Jan 2023 08:33:06 +0000 Subject: [PATCH 020/103] fix: broken links in the specs (#1557) --- .../config/markdownlinkcheckignore.json | 12 ++++++++++++ makefile | 4 ++-- protocol/0013-ACCT-accounts.md | 8 ++++---- ...0015-INSR-market_insurance_pool_collateral.md | 2 +- protocol/0020-APIS-core_api.md | 6 +++--- protocol/0026-AUCT-auctions.md | 2 +- protocol/0027-ASSP-asset_proposal.md | 2 +- protocol/0028-GOVE-governance.md | 2 +- .../0038-OLIQ-liquidity_provision_order_type.md | 4 ++-- protocol/0050-EPOC-epochs.md | 2 +- protocol/0051-PROD-product.md | 2 +- protocol/0056-REWA-rewards_overview.md | 4 ++-- protocol/0057-TRAN-transfers.md | 14 +++++++------- .../0059-STKG-simple_staking_and_delegating.md | 8 ++++---- protocol/0060-WEND-wendy.md | 2 +- ...4-VALP-validator_performance_based_rewards.md | 4 ++-- protocol/0065-FTCO-floating_point_consensus.md | 2 +- protocol/0068-MATC-matching_engine.md | 16 ++++++++-------- protocol/0069-VCBS-validators_chosen_by_stake.md | 2 +- .../0071-STAK-erc20_governance_token_staking.md | 2 +- protocol/0073-LIMN-limited_network_life.md | 4 ++-- protocol/0075-PLUP-protocol_upgrades.md | 2 +- protocol/0076-DANO-data-node.md | 2 +- protocol/README.md | 3 +-- 24 files changed, 61 insertions(+), 50 deletions(-) create mode 100644 .github/workflows/config/markdownlinkcheckignore.json diff --git a/.github/workflows/config/markdownlinkcheckignore.json b/.github/workflows/config/markdownlinkcheckignore.json new file mode 100644 index 000000000..eff12910e --- /dev/null +++ b/.github/workflows/config/markdownlinkcheckignore.json @@ -0,0 +1,12 @@ +{ + "ignorePatterns": [ + { + "_comment": "Finds /protocol AC codes e.g. #0001-MKTF-001", + "pattern": "^#[0-9]{4}-[A-Z]{4}-[0-9]{3}" + }, + { + "_comment": "Finds /non-protocol-specs AC codes e.g. #0001-NP-LIQB-001", + "pattern": "^#[0-9]{4}-[A-Z]{2}-[A-Z]{4}-[0-9]{3}" + } + ] +} diff --git a/makefile b/makefile index 5ffda02a0..c192ee4bd 100644 --- a/makefile +++ b/makefile @@ -21,8 +21,8 @@ references: # Imperfect, but useful - hence not included in ALL .PHONY: links links: - npx --yes markdown-link-check protocol/*.md - npx --yes markdown-link-check non-protocol-specs/*.md + npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json protocol/*.md + npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json non-protocol-specs/*.md # check the markdown formatting (/protocol specs only at this time) .PHONY: markdownlint diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 745d6504a..9d82ff779 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -10,7 +10,7 @@ Any party can submit a withdrawal transaction to withdraw assets from the genera Any party can set up a transfer from their general account to other Vega accounts as described by the [transfer spec](./0057-TRAN-transfers.md). -Note that a party can also associate the governance / staking asset via the [Vega staking bridge contract](../non-protocol-specs/0006-NP-STAK-erc20_governance_token_staking.md) but this number is *not* an account balance because it *cannot* be used as [collateral](./0005-COLL-collateral.md) for trading and it cannot be transferred. +Note that a party can also associate the governance / staking asset via the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) but this number is *not* an account balance because it *cannot* be used as [collateral](./0005-COLL-collateral.md) for trading and it cannot be transferred. ## Accounts controlled by Vega @@ -81,13 +81,13 @@ Every market will have at least one insurance pool account that holds collateral **Creation/Deletion:** -When a [market launches](./0043-MKTL_market_livecycle.md), an insurance pool account is created for that market for each settlement asset. This account is used by the protocol during the collection of [margin requirements](./0010-MARG-margin_orchestration.md) and the collection of [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md). +When a [market launches](./0043-MKTL-market_lifecycle.md), an insurance pool account is created for that market for each settlement asset. This account is used by the protocol during the collection of [margin requirements](./0010-MARG-margin_orchestration.md) and the collection of [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md). When a market is finalised / closed remaining funds are distributed to the on chain treasury. This occurs using ledger entries to preserve double entry accounting records within the collateral engine. ## Staking accounts -In Vega governance is controlled by a [governance token](./0029-GOVE-governance.md#governance-asset) which is [nominated and staked](./0059-STKG-simple_staking_and_governance.md), and is held in a smart contract on Ethereum. As the assets are held off-chain, a party's staking balance is treated differently to the account types above. +In Vega governance is controlled by a [governance token](./0028-GOVE-governance.md#governance-asset) which is [nominated and staked](./0059-STKG-simple_staking_and_delegating.md), and is held in a smart contract on Ethereum. As the assets are held off-chain, a party's staking balance is treated differently to the account types above. - Like [margin accounts](#margin-accounts), a party cannot transfer or place orders with the balance in staking accounts @@ -129,7 +129,7 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Special case: Staking accounts -One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](../non-protocol-specs/0006-NP-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. For more information on staking and stake delegation see [Simple staking and delegation](./0050-STKG-simple_staking_and_delegating.md). +One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](./0071-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. For more information on staking and stake delegation see [Simple staking and delegation](./0059-STKG-simple_staking_and_delegating.md). ### Party staking accounts diff --git a/protocol/0015-INSR-market_insurance_pool_collateral.md b/protocol/0015-INSR-market_insurance_pool_collateral.md index 830e6bcf6..0b9bd267e 100644 --- a/protocol/0015-INSR-market_insurance_pool_collateral.md +++ b/protocol/0015-INSR-market_insurance_pool_collateral.md @@ -20,4 +20,4 @@ When a market is finalised / closed remaining funds are distributed equally amon - When a market proposal gets accepted and the opening auction commences, there is an insurance account that is available for use by that market for the settlement asset of that market and its balance is zero. (0015-INSR-001) - When the market enters transitions from "trading terminated state" to "settled" state (see [market lifecyle](0043-MKTL-market_lifecycle.md)), the insurance pool account has its balance[redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. (0015-INSR-002) -- The [insurance pool feature test](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0015-INSR-insurance_pool_balance_test.feature) is passing. (0015-INSR-003) +- The [insurance pool feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0015-INSR-insurance_pool_balance_test.feature) is passing. (0015-INSR-003) diff --git a/protocol/0020-APIS-core_api.md b/protocol/0020-APIS-core_api.md index 2748655b3..d129cc0b6 100644 --- a/protocol/0020-APIS-core_api.md +++ b/protocol/0020-APIS-core_api.md @@ -17,9 +17,9 @@ To *observe the operation, and validate the state of the protocol, we must be ab ### Governance - List all [governance proposals](./0028-GOVE-governance.md), regardless of state -- List all proposals, filtered by the [party identitifier](./0016-PART-party.md) of the party that created it. +- List all proposals, filtered by the [party identitifier](./0017-PART-party.md) of the party that created it. - Retrieve a specified proposal -- List all [votes](./0027-GOVE-governance.md#voting-for-a-proposal) +- List all [votes](./0028-GOVE-governance.md#voting-for-a-proposal) - List [governance stake](./0059-STKG-simple_staking_and_delegating.md) for a specific party - List [delegations](./0059-STKG-simple_staking_and_delegating.md) for a specific party @@ -35,7 +35,7 @@ To *observe the operation, and validate the state of the protocol, we must be ab ### Party -- List all known [parties](./0016-PART-party.md). +- List all known [parties](./0017-PART-party.md). ### [Network wide limits](./0078-NWLI-network_wide_limits.md) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index f9238487c..4db5087ed 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -170,7 +170,7 @@ message Market { - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: 1. the enactment time assuming there are orders crossing on the book, [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) and after the auction uncrossing we will have best bid and best ask so that [liquidity can be deployed](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-009) 1. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed and we have limit orders such that after the auction uncrossing we will have best bid and best ask so that [liquidity can be deployed](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-010) - 1. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) and after the auction uncrossing we will have best bid and best ask but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md0041). It will only end if + 1. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) and after the auction uncrossing we will have best bid and best ask but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-011) - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-012) 1. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but after the auction uncrossing we will not have diff --git a/protocol/0027-ASSP-asset_proposal.md b/protocol/0027-ASSP-asset_proposal.md index 54e8ae551..4e22102eb 100644 --- a/protocol/0027-ASSP-asset_proposal.md +++ b/protocol/0027-ASSP-asset_proposal.md @@ -190,7 +190,7 @@ This must be an integer strictly greater than `0`. - `validationTimestamp` must occur after the governance proposal opens voting, and before it closes (0027-ASSP-017) - `validationTimestamp` must be provided and in the future for all new ERC20 asset proposals (0027-ASSP-018) - `quantum` must be an integer strictly greater than `0` (0027-ASSP-019) -- If there is a proposal for some ERC20 asset already present then another proposal for the same ERC20 asset will be rejected. (0027-0027-ASSP-020) +- If there is a proposal for some ERC20 asset already present then another proposal for the same ERC20 asset will be rejected. (0027-ASSP-020) - There can be multiple concurrent proposals for the same new ERC20 asset (same means identical Ethereum address). Once the nodes agree (based on events from the external blockchain queue), that the asset is enabled on the bridge all the remaining proposals for the same asset are rejected. (0027-COSMICELEVATOR-025) - An invalid contract address, specified in the ERC20 proposal **must** be rejected(0027-ASSP-021) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 269f9c573..c889f8343 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -57,7 +57,7 @@ A party on the Vega network will have a weighting for each type of proposal that To submit a proposal the party has to have more (strictly greater) than a minimum set by a network parameter `governance.proposal.market.minProposerBalance` of the governance tokens associated to the Vega network via the [Ethereum staking bridge](0071-STAK-erc20_governance_token_staking.md) (the network parameter sets the number of tokens). The minimum valid value for this parameter is `0`. -Weighting will initially be determined by the sum of the locked and staked token balances on the [staking bridge](../non-protocol-specs/0004-NP-APIN-api_node.md). +Weighting will initially be determined by the sum of the locked and staked token balances on the [staking bridge](./0076-DANO-data-node.md). In future, governance weighting for some proposal types will be based on alternative measures, such as: diff --git a/protocol/0038-OLIQ-liquidity_provision_order_type.md b/protocol/0038-OLIQ-liquidity_provision_order_type.md index 10cffaf50..f340d1972 100644 --- a/protocol/0038-OLIQ-liquidity_provision_order_type.md +++ b/protocol/0038-OLIQ-liquidity_provision_order_type.md @@ -196,8 +196,8 @@ Note that any other orders that the LP has on the book (limit orders, other pegg ## Acceptance Criteria -- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios there. (0038-OLIQ-001); -- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios that test fractional order sizes (smallest order position of 0.01). (0038-OLIQ-002); +- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios there. (0038-OLIQ-001); +- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios that test fractional order sizes (smallest order position of 0.01). (0038-OLIQ-002); - If an LP order has offset set such that the resulting price falls outside `[min_lp_vol_price, max_lp_vol_price]` then the system adjusts it automatically so that it's placed on the bound (0038-OLIQ-011) ### LP commitment order creation diff --git a/protocol/0050-EPOC-epochs.md b/protocol/0050-EPOC-epochs.md index b5767c721..2c439e83a 100644 --- a/protocol/0050-EPOC-epochs.md +++ b/protocol/0050-EPOC-epochs.md @@ -217,4 +217,4 @@ Nomination takes effect at epoch changeover: ## See also -- [0059 - STKG - Simple staking and delegating](./0059-STKG-simple_staking_and_delegating) - staking and delegation are both calculated in terms of epochs. +- [0059 - STKG - Simple staking and delegating](./0059-STKG-simple_staking_and_delegating.md) - staking and delegation are both calculated in terms of epochs. diff --git a/protocol/0051-PROD-product.md b/protocol/0051-PROD-product.md index 8908f8fd5..b64a11abb 100644 --- a/protocol/0051-PROD-product.md +++ b/protocol/0051-PROD-product.md @@ -128,5 +128,5 @@ Product updates via governance: ## See also -- [Product: Built In Futures](./016-PFUT-product_builtin_future.md) +- [Product: Built In Futures](./0016-PFUT-product_builtin_future.md) - [Product: Cash settled Perpetual Future](./0053-PERP-product_builtin_perpetual_future.md) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 83eeb87f2..65792570a 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -3,12 +3,12 @@ The reward framework provides a mechanism for measuring and rewarding a number of key activities on the Vega network. These rewards operate in addition to the main protocol economic incentives which come from [fees](0029-FEES-fees.md) on every trade. -These fees are the fundamental income stream for [liquidity providers LPs](0042-LIQF-setting_fees_and_rewarding_lps.md) and [validators](0061-REWP-simple_pos_rewards_sweetwater.md). +These fees are the fundamental income stream for [liquidity providers LPs](0042-LIQF-setting_fees_and_rewarding_lps.md) and [validators](./0061-REWP-pos_rewards.md). The additional rewards described here can be funded arbitrarily by users of the network and may be used by the project team, token holders (via governance), and individual traders and market makers to incentivise mutually beneficial behaviour. Note that transfers via governance, including to fund rewards, is a post-Oregon Trail feature. -Note that validator rewards (and the reward account for those) is covered in [validator rewards](0061-REWP-simple_pos_rewards_sweetwater.md) and is separate from the trading reward framework described here. +Note that validator rewards (and the reward account for those) is covered in [validator rewards](./0061-REWP-pos_rewards.md) and is separate from the trading reward framework described here. ## New network parameter for market creation threshold diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index e957fe2db..b327a8015 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -6,18 +6,18 @@ These transfers are not to be confused with the internal concept of transfers wh Allowing users to initiate transfers allows for the following capabilities: - A user can transfer funds from a public key A to a public key B. -- A user can transfer funds from and to a locked account used for staking (yet to be specified) [LOCKED_FOR_STAKING](0059-STKG-simple_staking_and_delegating.md). +- A user can transfer funds from and to a locked account used for staking (yet to be specified) [LOCKED_FOR_STAKING](./0059-STKG-simple_staking_and_delegating.md). - A user can set up a recurring transfer. - A user can set up a recurring transfer to one or more [reward accounts](0056-REWA-rewards_overview.md#reward-accounts). ## Limits -Transfer can only be initiated by a party using their own funds from [accounts](./0013-accounts.md) that they are in control of: +Transfer can only be initiated by a party using their own funds from [accounts](./0013-ACCT-accounts.md) that they are in control of: Here's the list of accounts types from which a user send funds from: - [GENERAL](0013-ACCT-accounts.md) -- [LOCKED_FOR_STAKING](./0059-simple-staking-and-delegating.md) (not in Oregon Trail) +- [LOCKED_FOR_STAKING](./0059-STKG-simple_staking_and_delegating.md) (not in Oregon Trail) Here's the list of accounts types into which funds can be sent: @@ -39,7 +39,7 @@ In order to prevent the abuse of user-initiated transfers as spam attack there w ## Minimum transfer amount -This is controlled by the `transfer.minTransferQuantumMultiple` and quantum specified for the [asset](0040-asset-framework.md)). +This is controlled by the `transfer.minTransferQuantumMultiple` and quantum specified for the [asset](0040-ASSF-asset_framework.md)). The minimum transfer amount is `transfer.minTransferQuantumMultiple x quantum`. ## Recurring transfers @@ -61,7 +61,7 @@ Party1 can have a recurring transfer rt1 from A1 to A2 and another one (call it A recurring transfers needs to contain this specific information: -- start amount uint specifying the amount (interpreted according to the number of decimals specified by the [asset](0040-asset-framework.md)). +- start amount uint specifying the amount (interpreted according to the number of decimals specified by the [asset](0040-ASSF-asset_framework.md)). - start epoch: at the end of this epoch the first recurring transfer will be made between - end epoch (optional): at the end of this epoch the last recurring transfer will be made between, optional. If not specified the transfer run until cancelled (by its creator or by the network as described below). - factor, decimal > 0.0 (a factor used with the amount specified for the transfer). @@ -118,11 +118,11 @@ Note: if there is no market with contribution to the reward metric - no transfer ## Fees -A fee is taken from all transfers, and paid out to validators in a similar manner to the existing [infrastructure fees](0059-simple-POS-rewards.md). For recurring transfers, the fee is charged each time the transfer occurs. +A fee is taken from all transfers, and paid out to validators in a similar manner to the existing [infrastructure fees](0061-REWP-pos_rewards.md). For recurring transfers, the fee is charged each time the transfer occurs. The fee is set by the `transfer.fee.factor` [network parameter](#network-parameters) that defines the proportion of each transfer taken as a fee. The fee is taken from the transfer initiator's account immediately on execution, and is taken on top of the total amount transferred. -It is [paid in to the infrastructure fee pool](./0029-fees.md#collecting-and-distributing-fees). +It is [paid in to the infrastructure fee pool](./0029-FEES-fees.md#collecting-and-distributing-fees). Fees are charged in the asset that is being transferred. ## Proposed command diff --git a/protocol/0059-STKG-simple_staking_and_delegating.md b/protocol/0059-STKG-simple_staking_and_delegating.md index b1e4f50ff..b5a4b4838 100644 --- a/protocol/0059-STKG-simple_staking_and_delegating.md +++ b/protocol/0059-STKG-simple_staking_and_delegating.md @@ -8,7 +8,7 @@ Validators and delegators receive incentives from the network, depending on vari Staking requires the combined action of: -- Associating tokens on the [Vega staking bridge contract](./0071-NP-STAK-erc20_governance_token_staking.md); and +- Associating tokens on the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md); and - Nominating these tokens to one or more validators - Delegation in some contexts is used to mean `associate + nominate`. For the purposes of this document, once it's clear from context that association has happened `delegate` and `nominate` may be used interchangeably. @@ -193,7 +193,7 @@ These accounts will be created: ### Adding more stake -- More tokens may be locked at any time on the [Vega staking bridge contract](./0071-NP-STAK-erc20_governance_token_staking.md) (0059-STKG-008) +- More tokens may be locked at any time on the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) (0059-STKG-008) - More stake may be delegated at any time (see [function: Stake](./0071-STAK-erc20_governance_token_staking.md) - amount refers to size by which to increment existing staked amount) (0059-STKG-009) - Same timings apply as per staking for the first time (0059-STKG-010) @@ -211,7 +211,7 @@ These accounts will be created: - Changing the validator to whom a participant wants to validate to involves: - Announcing removal of stake for current validator - - Staking on the new validator, as per normal [function: Stake](../non-protocol-specs/0006-NP-STAK-erc20_governance_token_staking.md) + - Staking on the new validator, as per normal [function: Stake](./0071-STAK-erc20_governance_token_staking.md) - These can happen concurrently, so that at the next epoch, the stake is removed from the current validator and staked on the new validator ## Auto delegation scenarios @@ -255,5 +255,5 @@ These accounts will be created: - [0013-ACCT Acccounts](./0013-ACCT-accounts.md) - staking accounts are not like other account types, but the differences are covered here. - [0028-GOVE Governance](./0028-GOVE-governance.md) - a party's stake controls their ability to participate in governance. -- [0069-VALW Validators chosen by stake](./0069-VALW-validators_chosen_by_stake.md) - staking and delegation is used to pick validators. +- [0069-VALW Validators chosen by stake](./0069-VCBS-validators_chosen_by_stake.md) - staking and delegation is used to pick validators. - [0050-EPOC Epochs](./0050-EPOC-epochs.md) - epochs control how frequently validator sets can change as a result of staking and delegation. diff --git a/protocol/0060-WEND-wendy.md b/protocol/0060-WEND-wendy.md index 0b03d35ab..37c8d89ef 100644 --- a/protocol/0060-WEND-wendy.md +++ b/protocol/0060-WEND-wendy.md @@ -2,7 +2,7 @@ ## Sources -- [Paper](https://github.com/vegaprotocol/research-internal/blob/master/Fairness/SBC22/Wendy2b.pdf) +- [Paper](https://vega.xyz/papers/Wendy_Grows_Up.pdf) - [Code so far](https://github.com/vegaprotocol/wendy) ## Implementation diff --git a/protocol/0064-VALP-validator_performance_based_rewards.md b/protocol/0064-VALP-validator_performance_based_rewards.md index eb5b4e1e6..ff169cdf3 100644 --- a/protocol/0064-VALP-validator_performance_based_rewards.md +++ b/protocol/0064-VALP-validator_performance_based_rewards.md @@ -5,7 +5,7 @@ The Vega chain is a delegated proof-of-stake based chain where validators are rewarded from fees generated or from on-chain treasury. The rewards are based on their own stake and the amount of stake delegated to them, -see [validator rewards](./0061-REWP-simple_pos_rewards_sweetwater.md), as well as their performance score. +see [validator rewards](./0061-REWP-pos_rewards.md), as well as their performance score. The purpose of the specification is to define how the validator rewards will be additionally scaled based on their performance. @@ -48,7 +48,7 @@ The message with the signed block hash must be in blocks `b + numBlocks` to `b + Initially the performance score is set to `0`. Both Tendermint validators and pending validators should be signing and sending these messages but only for the pending validators does this impact their score. -The performance score should be available on all the same API endpoints as the `validatorScore` from [validator rewards](./0061-REWP-simple_pos_rewards_sweetwater.md). +The performance score should be available on all the same API endpoints as the `validatorScore` from [validator rewards](./0061-REWP-pos_rewards.md). ## Acceptance criteria diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index e8f945860..f068ef9a2 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -6,7 +6,7 @@ Any intermediate results originating from 3rd party-libraries relying on floatin ## Background -Computations within a blockchain-based system [need to be deterministic](https://docs.tendermint.com/master/introduction/what-is-tendermint.html#a-note-on-determinism) as otherwise application state between nodes replicating it can start to differ potentially leading to a consensus failure. This issue has been long known in a different type of a distributed system: [networked games](https://gafferongames.com/post/floating_point_determinism/). +Computations within a blockchain-based system [need to be deterministic](https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html#a-note-on-determinism) as otherwise application state between nodes replicating it can start to differ potentially leading to a consensus failure. This issue has been long known in a different type of a distributed system: [networked games](https://gafferongames.com/post/floating_point_determinism/). The two strategies for dealing with the problem have been to either synchronise the entire game state across all agents or to assure that computations yield identical results irrespective of the platform they run on. While the first strategy might work for games with limited state size due to the use of a central server it cannot be applied to a peer-to-peer application like `vega` which relies on low latency. The second strategy is trivial to implement for `integer` or `decimal` data types, but while still possible, much [more complex](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) in case of `floating-point` datatypes as it usually involves rewriting a lot of the tooling and libraries that the application relies on. diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index 55f6b25d1..957c07474 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -6,7 +6,7 @@ The matching engine co-ordinates the trading of incoming orders with existing or ### In a market that is in [Continuous Trading](./0001-MKTF-market_framework.md#trading-mode---continuous-trading) -An [Immediate or Cancel (IOC)](./0014-ORDT_order_types.md#time-in-force---validity) order: +An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validity) order: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001) - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002) @@ -15,7 +15,7 @@ An [Immediate or Cancel (IOC)](./0014-ORDT_order_types.md#time-in-force---validi - If there is a partial match then the remaining will be cancelled. (0068-MATC-005) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) -A [Fill or KILL (FOK)](./0014-ORDT-order-types.md#time-in-force---validity) order: +A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will either be: @@ -23,7 +23,7 @@ A [Fill or KILL (FOK)](./0014-ORDT-order-types.md#time-in-force---validity) orde - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-011) -For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order-types.md#time-in-force---validity) orders: +For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order_types.md#time-in-force--validity) orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014) @@ -35,9 +35,9 @@ For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)]( In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): -- [IOC/FOK/GFN](./0014-ORDT-order-types.md#time-in-force---validity) +- [IOC/FOK/GFN](./0014-ORDT-order_types.md#time-in-force--validity) - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021) -- GTC/GTT/GFA](./0014-ORDT-order-types.md#time-in-force---validity) +- [GTC/GTT/GFA](./0014-ORDT-order_types.md#time-in-force--validity) - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022) - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023) - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024) @@ -47,14 +47,14 @@ In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): When a [market moves into an auction](./0026-AUCT-auctions.md#upon-entering-auction-mode): - All [PEGGED](./0014-ORDT-order_types.md#auction) orders are parked (and have their status set to PARKED). (0068-MATC-026) -- All [GFN](./0014-ORDT-order-types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027) -- All [GTC/GTT](./0014-ORDT-order-types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028) +- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027) +- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028) When a market [market exits an auction](./0026-AUCT-auctions.md#upon-exiting-auction-mode): - The book is uncrossed. (0068-MATC-029) - Self trading is allowed during uncrossing. (0068-MATC-030) -- All [GFA](./0014-ORDT-order-types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031) +- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced where possible. (0068-MATC-032) - Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index b073fb258..60f87a3f2 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -14,7 +14,7 @@ Note that to be eligible as a potential validator certain criteria need to be me 1. Own stake >= `reward.staking.delegation.minimumValidatorStake`. 1. Network has verified key ownership (see below). -At the end of each epoch Vega will calculate the unnormalised `validator_score`, see [rewards spec](./0061-REWP-simple_pos_rewards_sweetwater.md). +At the end of each epoch Vega will calculate the unnormalised `validator_score`, see [rewards spec](./0061-REWP-pos_rewards.md). For validators currently in the Vega validator set it will scale the `validator_score` by `(1+network.validators.incumbentBonus)`. Note that this number combines own + delegated stake together with `performance_score` which measures basic node performance. diff --git a/protocol/0071-STAK-erc20_governance_token_staking.md b/protocol/0071-STAK-erc20_governance_token_staking.md index e01662902..836b8caa6 100644 --- a/protocol/0071-STAK-erc20_governance_token_staking.md +++ b/protocol/0071-STAK-erc20_governance_token_staking.md @@ -75,7 +75,7 @@ Functions: ### ERC-20 vesting contract (`ERC20_Vesting.sol`) -The ERC-20 vesting contract implements the [Token V2](./0002-NP-TOKT-token_v2.md) specification and must also support the staking of tokens it holds as specified here. It will [ERC20_Vesting.sol](https://github.com/vegaprotocol/Vega_Token_V2/blob/main/contracts/ERC20_Vesting.sol) emit the `Stake_Deposited` and `Stake_Removed` events. +The ERC-20 vesting contract implements the [Token V2](../non-protocol-specs/0002-NP-TOKT-token_v2.md) specification and must also support the staking of tokens it holds as specified here. It will [ERC20_Vesting.sol](https://github.com/vegaprotocol/Vega_Token_V2/blob/main/contracts/ERC20_Vesting.sol) emit the `Stake_Deposited` and `Stake_Removed` events. Functions: diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 8c1fd777e..74c1ac985 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -45,8 +45,8 @@ Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_ - Staking: - last block of a confirmed stake_deposit on the staking contract on the Ethereum chain with `number_of_confirmations`. [Ethereum bridge](./0031-ETHB-ethereum_bridge_spec.md#network-parameters) - last block of a confirmed stake_deposit on the vesting contract on the Ethereum chain with `number_of_confirmations`. [Ethereum bridge](./0031-ETHB-ethereum_bridge_spec.md#network-parameters) - - all the staking events from both contracts [staking](./protocol/0059-STKG-simple_staking_and_delegating.md) - - all the pending staking events [staking](./protocol/0059-STKG-simple_staking_and_delegating.md) + - all the staking events from both contracts [staking](./0059-STKG-simple_staking_and_delegating.md) + - all the pending staking events [staking](./0059-STKG-simple_staking_and_delegating.md) When to create a checkpoint: diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index f2dc33b82..00614548b 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -4,7 +4,7 @@ ### Current state of upgrading the vega network -As of today, upgrading the protocol is near impossible when a major changes to the step are possible without proceeding with a [Limited Network Life checkpoint restore](./non-protocol-specs/0005-NP-LIMN-limited_network_life.md). This functionality has the following significant issues: +As of today, upgrading the protocol is near impossible when a major changes to the step are possible without proceeding with a [Limited Network Life checkpoint restore](./0073-LIMN-limited_network_life.md). This functionality has the following significant issues: - A synchronous restart is required - All node need to be restarted in a very short time so all state can be restore from Ethereum, and the network can start properly with a checkpoint. diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 7867ce8e7..302716bea 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -84,7 +84,7 @@ All proposals ever submitted + votes (asset, network parameter change, market). ### Market Data -- as [specified in](./0021-market-data-spec.md). This is emitted once per block. This is kept for backward compatibility. Note that below we may duplicate some of this. +- as [specified in](./0021-MDAT-market_data_spec.md). This is emitted once per block. This is kept for backward compatibility. Note that below we may duplicate some of this. ### Market lifecycle events diff --git a/protocol/README.md b/protocol/README.md index f12c15573..90d265af2 100644 --- a/protocol/README.md +++ b/protocol/README.md @@ -61,7 +61,6 @@ - [Market insurance pool](./0015-INSR-market_insurance_pool_collateral.md) - [Margin calculator](./0019-MCAL-margin_calculator.md) - [Quant risk models (Python notebook)](./0018-RSKM-quant_risk_models.ipynb) -- [Quant risk model Calibrators](./0023-CALI-calibrators.md) ## Data Sourcing @@ -81,7 +80,7 @@ - [Staking & Delegating](./0059-STKG-simple_staking_and_delegating.md) - [Rewards Overview](./0056-REWA-rewards_overview.md) -- [Simple Proof Of Stake rewards](./0058-REWS-simple_pos_rewards.md) +- [Simple Proof Of Stake rewards](./0061-REWP-pos_rewards.md) - [On chain treasury](./0055-TREA-on_chain_treasury.md) ## Architecture From f36cdf6747afd2a04125138a774710d3741fa71c Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 30 Jan 2023 08:35:25 +0000 Subject: [PATCH 021/103] fix: remove broken kraken link --- protocol/0031-ETHB-ethereum_bridge_spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index 1145d9516..7a88be6cf 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -26,7 +26,7 @@ Each bridge contains two primary functions and emits two primary events, each ta ### Block confirmations -It is normal behaviour when validating transfers to wait a certain number of blocks for a deposit to be 'confirmed'. For example, [this is Kraken's wait time](https://support.kraken.com/hc/en-us/articles/203325283-Cryptocurrency-deposit-processing-times). We need to do the same, to be sure that enough time has passed that it is a certainty that the event we saw is included in the chain. +It is normal behaviour when validating transfers to wait a certain number of blocks for a deposit to be 'confirmed'. We need to do the same, to have acceptably high probability that the event is on the longest chain and there won't be a fork in the future which will invalidate this. We achieve this by ensuring that enough time has passed. This will need to be configured per chain that we connect to. ETH, ERC-20, ERC-XXX can all share a value, which should be configurable and changeable via governance. For Ethereum, this should be 20 confirmations. It is safe to lower this for development networks. From 15ad1cc55b2de08dcf50bcdbc1c01ff280f96f5c Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 31 Jan 2023 15:03:07 +0100 Subject: [PATCH 022/103] refactor: clarify 0042-LIQF-018 --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 7042b7a0a..62ae33e8f 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -277,4 +277,4 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e ### Distribution -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) +- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment (and the traded value is the same in both epochs). (0042-LIQF-018) From 160b84e4a8a4027fdbc1b03221d0cc5e27fdb29b Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 1 Feb 2023 08:48:19 +0000 Subject: [PATCH 023/103] feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md --- .github/workflows/config/markdownlintignore | 5 +- glossaries/distributed-ledger-glossary.md | 18 +- glossaries/staking-and-governance.md | 15 +- glossaries/trading-and-protocol-glossary.md | 204 +++++++++--------- makefile | 28 ++- .../0001-NP-LIQB-liquidity_providing_bots.md | 33 +-- non-protocol-specs/0002-NP-TOKT-token_v2.md | 12 +- ...0003-NP-LIMI-limits_aka_training_wheels.md | 74 +++---- ...007-NP-SNTP-sweetwater_signed_netparams.md | 11 +- .../0008-NP-NULB-null_blockchain_vega.md | 6 +- spellcheck.sh | 4 + spellcheck.yaml | 5 +- wordlist.txt | 16 ++ 13 files changed, 236 insertions(+), 195 deletions(-) diff --git a/.github/workflows/config/markdownlintignore b/.github/workflows/config/markdownlintignore index d0cb33a3d..d7c52fd53 100644 --- a/.github/workflows/config/markdownlintignore +++ b/.github/workflows/config/markdownlintignore @@ -1,3 +1,2 @@ -glossaries/* -non-protocol-specs/* -user-interface/* \ No newline at end of file +user-interface/* +LICENSE.md \ No newline at end of file diff --git a/glossaries/distributed-ledger-glossary.md b/glossaries/distributed-ledger-glossary.md index db5db5012..53d8a1091 100644 --- a/glossaries/distributed-ledger-glossary.md +++ b/glossaries/distributed-ledger-glossary.md @@ -2,7 +2,7 @@ ## ABI -Application Binary Interface - A JSON representation list of a smart contract's functions and arguments. It is used by wallets or clients to produce a transaction that interacts with a contract that exists on the the Ethereum chain - mapping function calls and parameters in to a bytecode form that the [EVM](#EVM) will execute. +Application Binary Interface - A JSON representation list of a smart contract's functions and arguments. It is used by wallets or clients to produce a transaction that interacts with a contract that exists on the the Ethereum chain - mapping function calls and parameters in to a bytecode form that the [EVM](#evm) will execute. ## Algorithm @@ -12,7 +12,7 @@ A generally understood set of rules and calculations for solving a particular pr The process of verifying that an actor (person or machine) is who they claim they are. -## Authorization +## Authorisation The process of verifying that an actor (person or machine) is allowed to take an action. @@ -47,7 +47,7 @@ Short for [Distributed Ledger Technology](https://en.wikipedia.org/wiki/Distribu ## Erasure Coding -... TODO but see [here](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding). +... `TODO` but see [here](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding). ## Eventual consistency @@ -77,7 +77,7 @@ A rule for determining which fork is correct when faced with multiple possibly-v The [Greedy Heaviest-Observed Subtree](https://eprint.iacr.org/2013/881.pdf), a fork choice rule. -## Hashchain +## Hash chain ... @@ -95,7 +95,7 @@ The amount of time before a system can achieve both consensus and finality; it's ## Longest Chain -The longest chain approach is one way to solve consensus. It consists of a mechanism that (not necessarily uniquely) determinas a leader that can propose the next block in the blockchain. If a node sees a longer chain than the one it knows, it uses that one as its new chain. Longest chain protocols do not offer finallity, i.e., every block can (theoretically) be undone. +The longest chain approach is one way to solve consensus. It consists of a mechanism that (not necessarily uniquely) determines a leader that can propose the next block in the blockchain. If a node sees a longer chain than the one it knows, it uses that one as its new chain. Longest chain protocols do not offer finality, i.e., every block can (theoretically) be undone. ## MainNet @@ -137,7 +137,7 @@ There are entire protocols ([Band](https://bandprotocol.com/), [Chainlink](https ## Reliable Broadcast -A reliable broadcast assures that all receiving of a broadcasr nodes receive the same set of messages, and that a message sent by an honest sender is received. ... see [here](https://www.semanticscholar.org/paper/Asynchronous-consensus-and-broadcast-protocols-Bracha-Toueg/130ce1bcd496a7b9192f5f53dd8d7ef626e40675), +A reliable broadcast assures that all receiving of a broadcast nodes receive the same set of messages, and that a message sent by an honest sender is received. ... see [here](https://www.semanticscholar.org/paper/Asynchronous-consensus-and-broadcast-protocols-Bracha-Toueg/130ce1bcd496a7b9192f5f53dd8d7ef626e40675), [here](https://www.shoup.net/papers/ckps.pdf) or [here](https://arxiv.org/pdf/1510.06882.pdf). ## State Channels @@ -162,7 +162,7 @@ The amount of data that can be processed by a system in a given unit of time, e. ## Validators -From the [Tendermint documentation](https://docs.tendermint.com/master/nodes/validators.html): -> Validators are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key. +From the [Tendermint documentation](https://docs.tendermint.com/v0.34/tendermint-core/validators.html): -> Some Proof-of-Stake consensus algorithms aim to create a "completely" decentralized system where all stakeholders (even those who are not always available online) participate in the committing of blocks. [Tendermint](#tendermint) has a different approach to block creation. Validators are expected to be online, and the set of validators is permissioned/curated by some external process. +> Validators are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key. +> Some Proof-of-Stake consensus algorithms aim to create a "completely" decentralised system where all stakeholders (even those who are not always available online) participate in the committing of blocks. [Tendermint](#tendermint) has a different approach to block creation. Validators are expected to be online, and the set of validators is permissioned/curated by some external process. diff --git a/glossaries/staking-and-governance.md b/glossaries/staking-and-governance.md index 28364df09..95aa5873d 100644 --- a/glossaries/staking-and-governance.md +++ b/glossaries/staking-and-governance.md @@ -6,21 +6,22 @@ This is a general term that may have specific meaning in different contexts. Veg ## Delegation -This is the process of assigning Vega tokens to validators on Vega chain. It is a two step process consisting of -1) [Association](#associate) which happens on the Ethereum blockchain by interaction with the Staking and Delegation bridges. -2) [Nomination](#nominate) which happens on the Vega blockchain, assigning voting power to validators. +This is the process of assigning Vega tokens to validators on Vega chain. It is a two step process consisting of: + +1. [Association](#associate) which happens on the Ethereum blockchain by interaction with the Staking and Delegation bridges. +1. [Nomination](#nominate) which happens on the Vega blockchain, assigning voting power to validators. ## Associate -This allows a user with Vega Tokens on Ethereum to associate their tokens with a vega key so that the Vega key can participate in [Governance](#Governance) and [Nominate](#Nominate) their Stake to a [validator](distributed-ledger-glossary.md#validators). +This allows a user with Vega Tokens on Ethereum to associate their tokens with a vega key so that the Vega key can participate in [Governance](#governance) and [Nominate](#nominate) their Stake to a [validator](distributed-ledger-glossary.md#validators). This is done by interaction with the Staking and Delegation bridge contracts (the vesting contract implements this functionality for Vega held by the vesting contract). ## Dissociate To opposite of association. Tokens can be dissociated via Ethereum staking and delegation bridge. Vega tokens are thus no longer associated to a Vega key (on either the Staking bridge or the Vesting contract, depending on how they were [Associated](#associate)). This means that in the future they can be associated to a different (or same) Vega key. -This action happens on Ethereum. The staking and delegation smart contract and does not know when an [Epoch](#Epoch) ends meaning the relevant Vega key will not be due any rewards from that epoch. -Users are recommended to first [De-nominate](#De-nominate) sufficient amount using their Vega key and interacting with the Vega chain. This way, when the Epoch ends they can dissociate without loosing any due rewards. Moreover they get to choose which validator they are removing their nomination from. +This action happens on Ethereum. The staking and delegation smart contract and does not know when an [Epoch](#epoch) ends meaning the relevant Vega key will not be due any rewards from that epoch. +Users are recommended to first [De-nominate](#de-nominate) sufficient amount using their Vega key and interacting with the Vega chain. This way, when the Epoch ends they can dissociate without loosing any due rewards. Moreover they get to choose which validator they are removing their nomination from. ## Governance @@ -44,4 +45,4 @@ A window of time, In which tokens that are staked on a are due a reward. If toke ## Self Staking -That act of putting Vega tokens on a Validator node that you are running, as apposed to having tokens staked on a node via [Nomination](#Nominate). +That act of putting Vega tokens on a Validator node that you are running, as apposed to having tokens staked on a node via [Nomination](#nominate). diff --git a/glossaries/trading-and-protocol-glossary.md b/glossaries/trading-and-protocol-glossary.md index 9abcca051..28307da7f 100644 --- a/glossaries/trading-and-protocol-glossary.md +++ b/glossaries/trading-and-protocol-glossary.md @@ -4,38 +4,32 @@ ### Average Entry Price -This is the *volume weighted price* of a trader's [Open Volume](#open-volume). The open volume will always be comprised of all buys or all sells. +This is the **volume weighted price** of a trader's [Open Volume](#open-volume). The open volume will always be comprised of all buys or all sells. -*Example 1 - all buys:* +**Example 1 - all buys:** A trader has 3 price levels at which their open volume was purchased: -1. Long 3 contracts @ $100 -2. Long 2 contracts @ $80 -3. Long 5 contracts @ $150 +1. Long 3 contracts @ $100 +1. Long 2 contracts @ $80 +1. Long 5 contracts @ $150 -***Average Entry Price*** = (3 * $100 + 2 * $80 + 5 * $150)/(3 + 2 + 5) = ($300 + $160 + $750) / 10 = $121 +**Average Entry Price** = `(3 * $100 + 2 * $80 + 5 * $150)/(3 + 2 + 5) = ($300 + $160 + $750) / 10 = $121` -*Example 2 - all sells:* +**Example 2 - all sells:** A trader has 3 price levels at which their open volume was sold: -1. Short -3 contracts @ $100 -2. Short -2 contracts @ $80 -3. Short -5 contracts @ $150 +1. Short -3 contracts @ $100 +1. Short -2 contracts @ $80 +1. Short -5 contracts @ $150 Note, with position management we treat the volume of sells as negative for calculation purposes (not necessarily display purposes to users). Note, that in this calculation however, the negatives cancel each other out. -***Average Entry Price*** = (-3 * $100 + -2 * $80 + -5 * $150)/(-3 - 2 - 5) = (-$300 - $160 - $750) / -10 = $121 +**Average Entry Price** = `(-3 * $100 + -2 * $80 + -5 * $150)/(-3 - 2 - 5) = (-$300 - $160 - $750) / -10 = $121` The Average Entry Price is useful when calculating [Unrealised P&L](#unrealised-pnl) or [Realised P&L](#realised-pnl) -### Fills - -> Fill is the term used to refer to the satisfying of an order to trade a financial asset. It is the basic act of any market transaction – when an order has been completed, it is often referred to as ‘filled’ or as the order having been executed. However, it is worth noting that there is no guarantee that every trade will become filled. - -[IG Index: Fill Definition](https://www.ig.com/uk/glossary-trading-terms/fill-definition) - ## B ### Base currency @@ -58,11 +52,11 @@ When a trader's collateral level in the risk universe drops below the [close out ### Closed position -The set of long and short contracts with price and volume specified that are matched as offset volume during the [FIFO](#fifo) netting process. +The set of long and short contracts with price and volume specified that are matched as offset volume during the [FIFO](#fifo-first-in-first-out) netting process. ### Closed volume -The volume that is matched into [closed volume](#closed-volume) during the [FIFO](#fifo) netting process. It is measured as the sum of the buys of the matched volume. So, if 2 long (or +2) contracts are netted with 2 short (or -2) contracts, the ***Closed Volume*** = 2. +The volume that is matched into [closed volume](#closed-volume) during the [FIFO](#fifo-first-in-first-out) netting process. It is measured as the sum of the buys of the matched volume. So, if 2 long (or +2) contracts are netted with 2 short (or -2) contracts, the **Closed Volume** = 2. The profit or loss that a trader locks in when they close volume is called the [Realised P&L](#realised-pnl) and is not affected by future price moves in the instrument. @@ -83,6 +77,7 @@ Any order that trades any amount and as much as possible but does not remain on ### Fees Fees are incurred on trades in Vega. There are three categories of fee, each of which is paid out to different participants: + - Infrastructure fee: paid to [validators](#validators), - Maker fee: paid to the price maker, - Liquidity fee: paid to [Liquidity Providers](#liquidity-providers) @@ -95,40 +90,40 @@ A matching methodology which prioritises older volume as an offset when counter Use Case 2 - Calculating a trader's open and closed position. -***Example - FIFO on an individual trader's trades:*** - -1. 24-July-07:00 Buy 3 contracts @ $100 -2. 24-July-07:10 Sell 1 contract @ $400 -3. 24-July-07:14 Sell 6 contracts @ $370 -4. 24-July-07:15 Buy 2 contracts @ $80 -5. 24-July-07:46 Buy 5 contracts @ $150 -6. 24-July-09:00 Sell 2 contracts @ $300 -7. 24-July-10:10 Sell 2 contract @ $ 320 -7. 24-July-10:10 Sell 3 contract @ $ 379 - -*Fifo matching - calculating [closed position](#open-position)s*: - -* -1 contract @ $400 -* +1 contract @ $100 -* -2 contract @ $370 -* +2 contract @ $100 -* +2 contract @ $80 -* -2 contract @ $370 -* +2 contract @ $150 -* -2 contract @ $370 -* -2 contract @ $300 -* +2 contract @ $150 -* -1 contract @ $320 -* +1 contract @ $150 +**Example - FIFO on an individual trader's trades:** + +1. 24-July-07:00 Buy 3 contracts @ $100 +1. 24-July-07:10 Sell 1 contract @ $400 +1. 24-July-07:14 Sell 6 contracts @ $370 +1. 24-July-07:15 Buy 2 contracts @ $80 +1. 24-July-07:46 Buy 5 contracts @ $150 +1. 24-July-09:00 Sell 2 contracts @ $300 +1. 24-July-10:10 Sell 2 contract @ $ 320 +1. 24-July-10:10 Sell 3 contract @ $ 379 + +**Fifo matching - calculating [closed position](#open-position)s**: + +- -1 contract @ $400 +- +1 contract @ $100 +- -2 contract @ $370 +- +2 contract @ $100 +- +2 contract @ $80 +- -2 contract @ $370 +- +2 contract @ $150 +- -2 contract @ $370 +- -2 contract @ $300 +- +2 contract @ $150 +- -1 contract @ $320 +- +1 contract @ $150 The above represent the [closed position](#closed-position) which can be inputted into the [Realised P&L](#realised-pnl) calculation to determine how profitable these trades were. The [closed volume](#closed-volume) is considered to be 9 (offset) contracts. -*Fifo matching - remainder [open position](#open-position)*: +**Fifo matching - remainder [open position](#open-position)**: The remainder (unmatched) positions are comprised of: -* -1 contract @ $320 -* -3 contract @ $379 +- -1 contract @ $320 +- -3 contract @ $379 The above represent the [open position](#open-position) which can be inputted into the [Unrealised P&L](#unrealised-pnl) and the [Average Entry Price](#average-entry-price) calculations. @@ -166,16 +161,17 @@ An order that trades any amount and as much as possible and remains on the book ### Instrument -An instance of a *smart product* that can be traded on Vega network with all parameters required for settlement and / or margin requirements specified. +An instance of a **smart product** that can be traded on Vega network with all parameters required for settlement and / or margin requirements specified. Parameters: -* Name: Example: BTCUSD Dec 2018 Future. -* Underlying -* Base currency -* Tick size -* Expiry -* Payoff / settlement formula -* Minimum contract size + +- Name: Example: `BTCUSD` Dec 2018 Future. +- Underlying +- Base currency +- Tick size +- Expiry +- Payoff / settlement formula +- Minimum contract size ### Insurance Pool @@ -189,7 +185,7 @@ The net riskiest composition of a trader's open positions and live orders. For ### Liquidity Providers -Liquidity providers commit a bond and place a special Liquidity Commitment that automatically maintains orders on the book for a specific market. In return, liquidity providers earn a [fee](#fee) for ensuring that markets always have open volume. See [the liquidity provision spec](./../protocol/0044-LIME-lp_mechanics.md) for more detail. +Liquidity providers commit a bond and place a special Liquidity Commitment that automatically maintains orders on the book for a specific market. In return, liquidity providers earn a [fee](#fees) for ensuring that markets always have open volume. See [the liquidity provision spec](./../protocol/0044-LIME-lp_mechanics.md) for more detail. ## M @@ -201,8 +197,8 @@ The amount of collateral (due in the base currency of the product) that a trader An instrument's market valuation at any point in time. This will be set to the higher / lower of the: -* last traded price; -* bid / offer +- last traded price; +- bid / offer ### Mark to Market @@ -240,23 +236,23 @@ Assume an individual has a set of trades which they have executed on one market. Calculate: -1. Open Volume Sign: If sum of the long volume > sum of the short volume, trader's open position is net long (and vice versa). +1. Open Volume Sign: If sum of the long volume > sum of the short volume, trader's open position is net long (and vice versa). -2. Closed Volume Amount: If Open Volume Sign > 0, the ***Closed Volume Amount*** is the sum of the short volume of the trades (and vice versa). +1. Closed Volume Amount: If Open Volume Sign > 0, the **Closed Volume Amount** is the sum of the short volume of the trades (and vice versa). -3. Closed Long Contracts - ***the first n volume***, where n is the ***Closed Volume Amount*** (note this methodology is a shortcut way to implementing FIFO at any point in time). +1. Closed Long Contracts - **the first n volume**, where n is the **Closed Volume Amount** (note this methodology is a shortcut way to implementing FIFO at any point in time). -4. Closed Short Contracts - ***the first n volume***, where n is the ***Closed Volume Amount*** (note this methodology is a shortcut way to implementing FIFO at any point in time). +1. Closed Short Contracts - **the first n volume**, where n is the **Closed Volume Amount** (note this methodology is a shortcut way to implementing FIFO at any point in time). -5. Open Contracts - whatever is left of the volume that isn't in ***Closed Long Contracts*** or ***Closed Short Contracts***. These will always be either long contracts OR short contracts but never both (else they'd have been matched off). Contracts specify a price level and a volume. They are not trades, as they may be residual volume from a trade that has been partially matched. +1. Open Contracts - whatever is left of the volume that isn't in **Closed Long Contracts** or **Closed Short Contracts**. These will always be either long contracts OR short contracts but never both (else they'd have been matched off). Contracts specify a price level and a volume. They are not trades, as they may be residual volume from a trade that has been partially matched. -* ***Realised Volume*** is the ***Closed Volume Amount*** +- **Realised Volume** is the **Closed Volume Amount** -* ***Realised PnL*** = ***Closed Volume Amount*** * (***Average Entry Price*** (of Closed Short Contracts) - [Average Entry Price](#average-entry-prive) (of Closed Long Contracts)) +- **Realised PnL** = **Closed Volume Amount** * (**Average Entry Price** (of Closed Short Contracts) - [Average Entry Price](#average-entry-price) (of Closed Long Contracts)) -* ***Unrealised Volume*** is the sum of the volume of all the ***Open Contracts*** +- **Unrealised Volume** is the sum of the volume of all the **Open Contracts** -* ***Unrealised PnL*** = ***Unrealised Volume*** * (***Mark Price*** - ***Average Entry Price***(of Open Contracts)) +- **Unrealised PnL** = **Unrealised Volume** * (**Mark Price** - **Average Entry Price**(of Open Contracts)) ### Notional Value @@ -271,12 +267,12 @@ Reported for a market / instrument, this is the sum of [Open Volume](#open-volum Example (assume zero trading in the market so far): 1. Candida buys 4 contracts from David. The Open Interest is 4. -2. Candida then sells her 4 contracts back to David. The Open Interest is 0. -3. Rather than selling back to David, Candida sells to Chris. The Open Interest is 4. +1. Candida then sells her 4 contracts back to David. The Open Interest is 0. +1. Rather than selling back to David, Candida sells to Chris. The Open Interest is 4. ### Open position -The set of long OR short contracts with price and volume specified that are NOT matched as offset volume during the [FIFO](#fifo) netting process. They are the residual contracts that have exposure to the market price changes and require margin to be deposited. +The set of long OR short contracts with price and volume specified that are NOT matched as offset volume during the [FIFO](#fifo-first-in-first-out) netting process. They are the residual contracts that have exposure to the market price changes and require margin to be deposited. ### Open Volume @@ -284,10 +280,10 @@ This the total volume of long OR short [open position](#open-position). Example, if an individual trader's [open position](#open-position) on an instrument is: -* +1 @ $100 -* +4 @ 109 +- +1 @ $100 +- +4 @ 109 -The ***Open Volume*** = 1 + 4 = 5 contracts +The **Open Volume** = 1 + 4 = 5 contracts The exposure that a trader has on their Open Volume to the market's price moves is called the [unrealised P&L](#unrealised-pnl) @@ -307,7 +303,7 @@ The risk value of the total open interest for an instrument calculated by the ri ### Oracle Feed -A definite source of price information for an underlying (could come from another instrument's market activity (eg. trading or prices) on the Vega network, or from an external source). +A definite source of price information for an underlying (could come from another instrument's market activity (e.g. trading or prices) on the Vega network, or from an external source). ### Order Book @@ -337,26 +333,26 @@ For the creation an instrument, the time between the initial proposal period and ### Realised PnL -The ***Realised PnL*** calculates the profitability that has been locked in by a trader who exits an existing [open position](#open-position). -The inputs to a ***Realised PnL*** calculation is the set of positions, including specification of volume and price, that are the result of matched volume, calculated by [FIFO](#fifo). +The **Realised PnL** calculates the profitability that has been locked in by a trader who exits an existing [open position](#open-position). +The inputs to a **Realised PnL** calculation is the set of positions, including specification of volume and price, that are the result of matched volume, calculated by [FIFO](#fifo-first-in-first-out). Example: A trader's closed position is comprised of the following: -1. +3 contracts @ $100 -2. +2 contracts @ $80 -3. +5 contracts @ $150 -4. -1 contract @ $400 -5. -6 contracts @ $370 -6. -2 contracts @ $300 -7. -1 contract @ $ 320 +1. +3 contracts @ $100 +1. +2 contracts @ $80 +1. +5 contracts @ $150 +1. -1 contract @ $400 +1. -6 contracts @ $370 +1. -2 contracts @ $300 +1. -1 contract @ $ 320 -Note, for closed positions, the number of longs and number of shorts should equal each other (in this case we are 10 long and 10 short). Short positions are represented by -'ve numbers for volume. +Note, for closed positions, the number of longs and number of shorts should equal each other (in this case we are 10 long and 10 short). Short positions are represented by `-ve` numbers for volume. -***Realised PnL*** = Total Volume * (Average Entry Price (sells) - Average Entry Price (buys)) +**Realised PnL** = `Total Volume * (Average Entry Price (sells) - Average Entry Price (buys)) = 10 ( (-1 * $400 + -6 * $370 + -2 * $300 + -1 * $320 )/-10 - (3 * $100 + $2 * 80 + 5 * $150)/10 ) -= 10 ($354 - $121) = $2330 += 10 ($354 - $121) = $2330` ### Risk Engine @@ -398,7 +394,7 @@ Staking and delegation are used relatively interchangeably as in Vega, staking h ### Trade Volume -The number of contracts multiplied by the size of each contract for each market. For example, the market may have a contract size of $1USD and one trade may be for 10 contracts. The *trade volume* then equals $1 x 10 = $10. +The number of contracts multiplied by the size of each contract for each market. For example, the market may have a contract size of $1USD and one trade may be for 10 contracts. The _trade volume_ then equals $1 x 10 = $10. ### Trade Entry Price @@ -408,49 +404,49 @@ The quote price which a buyer and seller are matched at. ### Unrealised PnL -The ***Unrealised PnL*** calculates the profitability that a trader would receive if they were able to close their open positions at the current market price, as measured by the [mark price](#mark-price). It is sometimes referred to as [mark to market](#mark-to-market). It helps traders to understand what the 'value' of their portfolio is. Also they are required to cover any unrealised losses in their margin requirements. +The **Unrealised PnL** calculates the profitability that a trader would receive if they were able to close their open positions at the current market price, as measured by the [mark price](#mark-price). It is sometimes referred to as [mark to market](#mark-to-market). It helps traders to understand what the 'value' of their portfolio is. Also they are required to cover any unrealised losses in their margin requirements. -The inputs to a ***Unrealised PnL*** calculation is the set of trades (or partial trades) which specify volume and price, that are the result of unmatched volume, calculated by [FIFO](#fifo). This will always be either all buys or all sells. +The inputs to a **Unrealised PnL** calculation is the set of trades (or partial trades) which specify volume and price, that are the result of unmatched volume, calculated by [FIFO](#fifo-first-in-first-out). This will always be either all buys or all sells. -***Example 1 (trader has a net long open position):*** +**Example 1 (trader has a net long open position):** A trader's open volume is comprised of the following: -1. +3 contracts @ $100 -2. +2 contracts @ $80 -3. +5 contracts @ $150 +1. +3 contracts @ $100 +1. +2 contracts @ $80 +1. +5 contracts @ $150 Let's assume the latest [mark price](#mark-price) is set by the last trade in this market at $120. -***Unrealised PnL*** = Total Volume * ([mark price](#mark-price) - [average entry price](#average-entry-price)) +**Unrealised PnL** = `Total Volume * ([mark price](#mark-price) - [average entry price](#average-entry-price)) = 10 ( $120 - (3 * $100 + $2 * 80 + 5 * $150)/Abs(10) ) -= 10 ($120 - $121) = - $10 += 10 ($120 - $121) = - $10` The trader has made a loss of -$10 across their trades. However, this isn't locked in (realised) and the market may still move back in their favour. -***Example 2 (trader has a net short open position):*** +**Example 2 (trader has a net short open position):** A trader's open volume is comprised of the following: -1. -1 contract @ $750 -2. -6 contracts @ $330 -3. -2 contracts @ $999 +1. -1 contract @ $750 +1. -6 contracts @ $330 +1. -2 contracts @ $999 Let's assume the latest [mark price](#mark-price) is set by the last trade in this market at $666. -***Unealised PnL*** = Total Volume * ([mark price](#mark-price) - [average entry price](#average-entry-price)) +_Unrealised PnL_ = `Total Volume * ([mark price](#mark-price) - [average entry price](#average-entry-price)) = -9 * ( $666 - (-1 * $750 + -6 * $330 + -2 * $999)/-9 ) -= -9 * ($666 - $525.33) = - $140.67 += -9 * ($666 - $525.33) = - $140.67` The trader has made a loss of -$140.67 across their trades. However, this isn't locked in (realised) and the market may still move back in their favour. -# V +## V -## Validators +### Validators Validators are the nodes that run Vega and participate in the creation of the blocks. See [the distributed ledger glossary](distributed-ledger-glossary.md#validators) for more information on validators. -## Vega time +### Vega time Vega time is the current time of the chain (decided through consensus); it's based on the timestamp* agreed by the nodes. Vega needs validators to have a share idea of what time it is, regardless of their location or their clock being incorrect. diff --git a/makefile b/makefile index c192ee4bd..9f36d8ccf 100644 --- a/makefile +++ b/makefile @@ -1,7 +1,7 @@ # Set default to run all checks if none specified .DEFAULT_GOAL := all -all: spellcheck markdownlint names codes links references +all: spellcheck markdownlint names codes references links clean # Check that all the specifications are named appropriately .PHONY: names @@ -13,16 +13,33 @@ names: codes: npx @vegaprotocol/approbation check-codes +TEMP=./.build +.PHONY:clone-sources +clone-sources: + @mkdir -p $(TEMP) + + @echo "Cloning/updating test repos..." + @cd $(TEMP); \ + git -C MultisigControl pull || git clone https://github.com/vegaprotocol/MultisigControl.git & \ + git -C vega pull || git clone https://github.com/vegaprotocol/vega.git & \ + git -C vega_token_v2 pull || git clone https://github.com/vegaprotocol/vega_token_v2.git & \ + git -C staking_bridge pull || git clone https://github.com/vegaprotocol/staking_bridge.git & \ + git -C system-tests pull || git clone https://github.com/vegaprotocol/system-tests.git + # Which Acceptance Criteria are referenced in which feature files? +# Runs make clone-sources in a shell so that it properly waits for them to run in parallel and finish .PHONY: references references: - npx @vegaprotocol/approbation check-references + @$(MAKE) clone-sources + + cd $(TEMP); npx -y @vegaprotocol/approbation@latest check-references --specs="../*protocol*/*.{md,ipynb}" --tests="./**/*.{js,py,feature}" --categories="../protocol/categories.json" --show-branches --show-mystery --verbose --show-files + + @$(MAKE) clean # Imperfect, but useful - hence not included in ALL .PHONY: links links: - npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json protocol/*.md - npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json non-protocol-specs/*.md + npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json ./*protocol*/*.md # check the markdown formatting (/protocol specs only at this time) .PHONY: markdownlint @@ -33,3 +50,6 @@ markdownlint: .PHONY: spellcheck spellcheck: @./spellcheck.sh + +clean: + rm -rf $(TEMP) diff --git a/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md b/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md index dc24dc444..37efa641e 100644 --- a/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md +++ b/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md @@ -3,7 +3,9 @@ ## Introduction At the moment bots on Vega run on certain markets to make them look "real". + For that purpose they: + 1. Are given large amounts of collateral via faucets. 1. Keep track of current spot or futures price on another exchange (at e.g. 30s, 5 min intervals) 1. Post GTC limit orders randomly on both sides of the order book at random volumes using the above reference price as mid. @@ -12,10 +14,12 @@ This achieves the following: the price on the market looks "real" and there is v The downside is that if the bot is "unlucky" they can run out of even large amount of collateral and their orders / positions are liquidated. To avoid this they need regular collateral top-ups. -From Flamenco Tavern onvards any market on Vega will need a committed liquidity provider, see [LP mechanics spec](../protocol/0044-LIME-lp_mechanics.md) to function. See also [LP order type spec](../protocol/0038-OLIQ-liquidity_provision_order_type.md). +From Flamenco Tavern onwards any market on Vega will need a committed liquidity provider, see [LP mechanics spec](../protocol/0044-LIME-lp_mechanics.md) to function. See also [LP order type spec](../protocol/0038-OLIQ-liquidity_provision_order_type.md). If a feature is marked as "optional" then the bot can be configured in such a way that it is not providing this functionality but still doing other tasks. -The aim of this spec is bots that + +The aim of this spec is bots that: + 1. submit a market proposal (optional) or connects to an existing market 1. serve as a liquidity provider for the market by submitting the [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md) (optional). 1. participate in an opening auction (optional) @@ -33,15 +37,15 @@ The bot needs to be able to query Vega to know the risk model and parameters for - vega Wallet credentials - market proposal file - market ID (the market to engage with), can come from proposal above -- reference price source (optional), it is assumed that this is updated in real time. provided by an independent process / bot to keep things simple here. So in particular if a price source has API time limits then a separate bot / process should be accessing the price source and making up random price moves to fill the time(*) and , *not* the bot we are specifying here. +- reference price source (optional), it is assumed that this is updated in real time. provided by an independent process / bot to keep things simple here. So in particular if a price source has API time limits then a separate bot / process should be accessing the price source and making up random price moves to fill the `time(*)` and , _not_ the bot we are specifying here. - `expectedMarkPrice` (optional, can be from the reference price above). This will be used in markets that don't yet have mark price to calculate margin cost of orders meeting liquidity requirement. - `auctionVolume` - `maxLong` and `maxShort` position limits and `posManagementFraction` controlling size of market order used to manage position - `stakeFraction`, `ordersFraction`, these will be used in rule-of-thumb heuristics to decide how the bot should deploy collateral. -- `shorteningShape`, `longeningShape` both of these are *both* sides of the book (note that the initial shape used will be the buying shape because being long is a little cheaper in position margin than being short) +- `shorteningShape`, `longeningShape` both of these are _both_ sides of the book (note that the initial shape used will be the buying shape because being long is a little cheaper in position margin than being short) - `positionManagementSleep` e.g. 10s and `posManagementFraction` e.g. `0.1` - `marketPriceSteeringRate` e.g. 2 per second would be 2 -- `targetLNVol` target log-normal volatility (e.g. 0.5 for 50%), `limitOrderDistributionParams` (a little data structure which sets the algo and params for how limits orders are generated). +- `targetLNVol` target log-normal volatility (e.g. 0.5 for 50%), `limitOrderDistributionParams` (a little data structure which sets the algorithm and parameters for how limits orders are generated). (*) This separate process will then also need to use correct distributions to make the price moves look plausible. @@ -50,10 +54,8 @@ The bot needs to be able to query Vega to know the risk model and parameters for This is only relevant if the option to submit a market proposal is enabled. The bot will read the required market proposal from a file (configuration option), decide if it has minimum LP stake in the right asset, check it's got enough vote tokens and then submit the proposal and vote for it. They will also need to submit [liquidity shapes](../protocol/0038-OLIQ-liquidity_provision_order_type.md) but that will be treated below. -To decide that it will ask Vega for `assetBalance`, `quantum` for asset and `min_LP_stake_quantum_multiple` and proceed if -``` -assetBalance x stakeFraction > min_LP_stake_quantum_multiple x quantum -``` +To decide that it will ask Vega for `assetBalance`, `quantum` for asset and `min_LP_stake_quantum_multiple` and proceed if `assetBalance x stakeFraction > min_LP_stake_quantum_multiple x quantum` + It will then check whether it has enough collateral for maintaining the commitment but that will be described below as it applies below too. ### Serving as a liquidity provider for a market @@ -108,7 +110,7 @@ fi This section is only relevant if the option to participate in an opening auction is selected and the relevant market given by the market ID is still in an opening auction. If the bot has `currentPrice` then it should place buy / sell limit orders (good till time with duration a bit longer than opening auction length) in the auction at random distance and volume away from `currentPrice` up to total `auctionVolume`. -The distance and volume should be consistent with market risk parameters (spec work for later, Witold, do you feel like coming up with a formula?) +The distance and volume should be consistent with market risk parameters. ### Create markets that look real @@ -129,6 +131,7 @@ limitOrderDistributionParams = { numIdenticalBots = 3 } ``` + With the above example you can generate the correct orders using the method in the [notebook](./0010-NP-BOTC-bot_parameter_calc_and_test.ipynb) with `delta=tickSize x numTicksFromMid` and `N = 3600 x 2 / 3`. Another Example: @@ -145,13 +148,13 @@ limitOrderDistributionParams = { } ``` -Again, the algorithm for choosing the parameters and generating samples is in the [notebook](./BotParameterCalcAndTest.ipynb) with `delta=tickSize x numTicksFromMid` and `N = 3600 x 0.5 / 10`. +Again, the algorithm for choosing the parameters and generating samples is in the [notebook](./0010-NP-BOTC-bot_parameter_calc_and_test.ipynb) with `delta=tickSize x numTicksFromMid` and `N = 3600 x 0.5 / 10`. -Generate the orders using the above method *but*: +Generate the orders using the above method _but_: -If the position of the bot is long *only* place sell orders. +If the position of the bot is long _only_ place sell orders. -If the position of the bot is short *only* place buy orders here. +If the position of the bot is short _only_ place buy orders here. ### Manage their position @@ -211,7 +214,7 @@ Don't use any of the pseudocode above! 1. Bot can submit a market proposal (optional), commit liquidity and then manage it's position as described above, see also [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md). (0001-NP-LIQB-001) 1. Bot can connect to an existing market, submit an [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md) and then manage it's position as described above. (0001-NP-LIQB-002) -1. Bot can participate in an opening auction placing orders around target price (set via params, see above).(0001-NP-LIQB-003) +1. Bot can participate in an opening auction placing orders around target price (set via parameters, see above).(0001-NP-LIQB-003) 1. Can read a price target from external source and and places limit orders that "steer" the price up-or-down as appropriate and have the right `targetLNVol` using one of the methods above (note that this has to take into account other identical bots trying to do the same on the same market).(0001-NP-LIQB-004) 1. Bot manages its position in such a way that it stays close to zero and starts placing market orders if configured maxima are breached.(0001-NP-LIQB-005) 1. The repository is public from the start. diff --git a/non-protocol-specs/0002-NP-TOKT-token_v2.md b/non-protocol-specs/0002-NP-TOKT-token_v2.md index b8008fc5d..a4e0f3b87 100644 --- a/non-protocol-specs/0002-NP-TOKT-token_v2.md +++ b/non-protocol-specs/0002-NP-TOKT-token_v2.md @@ -1,6 +1,6 @@ # Token V2 -Version 2 of the $VEGA token replaces the existing token and providse two crucial upgrades: +Version 2 of the $VEGA token replaces the existing token and provides two crucial upgrades: 1. It allows for more sophisticated unlocking (vesting) schedules to be implemented and enforced on chain 1. It places the total supply of the token in the control of network/token holder governance @@ -8,7 +8,7 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia ## 1. Token supply 1. Supply is fixed initially at `64,999,723` -1. Supply canot be increased before a date (TBC) known as the `supply fix cut-off date` +1. Supply cannot be increased before a date (TBC) known as the `supply fix cut-off date` 1. After the `supply fix cut-off date`, supply **can** be increased by community governance on the Vega chain (i.e. via multisig control) 1. Supply cannot be changed by the contract owner/administrator 1. If supply is ever increased, the issuance of this supply should be done by the Vega chain too (i.e. via multisig control). It is not obvious that we need to enforce this, as long as multisig control can be an allowed issuer. @@ -20,7 +20,7 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia 1. Deployment/activation of the token contract will automatically issue tokens based on the wallet balances of the V1 token at deployment time 1. The contract owner must be able to assign vesting tranches for auto-issued tokens 1. Tokens held by a single address may comprise tokens in multiple tranches -1. Each address receiving auto-issed tokens may have a different vesting tranche +1. Each address receiving auto-issued tokens may have a different vesting tranche 1. Auto-issued tokens with no assigned vesting tranche must remain locked ## 3. Issuance mechanics @@ -56,7 +56,7 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia ## 6. Security and control -1. It should be possible for the contract owner to be a multisig, an instance of multisig control, or another smart cnotract, if needed +1. It should be possible for the contract owner to be a multisig, an instance of multisig control, or another smart contract, if needed 1. The contract owner must not be able to change anything about tokens that have been issued and unlocked 1. The contract owner must not be able to change the supply of the token 1. The contract owner must not be able to effect a token contract upgrade @@ -64,7 +64,7 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia ## 7. Staking and delegation -1. Staking mostly occurs on the Vega protocol side, however for two reasons, it _may_ be sensible or necessary to include some support for it in the token itself: +1. Staking mostly occurs on the Vega protocol side, however for two reasons, it *may* be sensible or necessary to include some support for it in the token itself: 1. We need to support staking of locked tokens 1. There may be a security advantage to not having staked tokens under the control of the bridge/multisigcontrol (i.e. so that taking over the validators/network would not allow you to also take ownership of **all** staked tokens) @@ -73,4 +73,4 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia 1. Unlocked tokens that have been transferred away cannot be or remain staked. 1. Once staked on the Vega side, tokens cannot be allowed to be transferred to another address even if they are unlocked from the perspective of vesting -For instance these goals could be achieved by using a special "stake" function on the smart contract that interacts with the bridge/multisigcontrol to mark them as staked (for either valdiator staking or delegation), and allowing "unstaking" to occur only from the Vega side, via multisigcontrol. This way even once vested, the tokens would still be marked as staked until the network releases them, and even though the network has control over whether they are staked, it does not hold them in the bridge pool while staked and cannot transfer them. +For instance these goals could be achieved by using a special "stake" function on the smart contract that interacts with the bridge/multisigcontrol to mark them as staked (for either validator staking or delegation), and allowing "unstaking" to occur only from the Vega side, via multisigcontrol. This way even once vested, the tokens would still be marked as staked until the network releases them, and even though the network has control over whether they are staked, it does not hold them in the bridge pool while staked and cannot transfer them. diff --git a/non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md b/non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md index 3b3ee2f5a..6761e86af 100644 --- a/non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md +++ b/non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md @@ -2,11 +2,12 @@ This spec describes a set of limits and controls that must be supported by deployments of the Vega system to mitigate the risk of loss or misappropriation of funds early in the life of the system while it is relatively less well tested and more likely to contain major bugs or mechanism design issues. The aim is to achieve this by implementing features which reduce both the expected magnitude and the probability of financial loss, from the perspective of participants interacting with the Vega protocol. -These limits are expected to be used in early deployments of Vega and are desiogned to be raised and/or removed over time via the governance protocol as the security and the robustness of the implementation is demonstrated. +These limits are expected to be used in early deployments of Vega and are designed to be raised and/or removed over time via the governance protocol as the security and the robustness of the implementation is demonstrated. ## Principles These features: + - Must not introduce points of centralisation. They are therefore designed to be operated by decentralised governance protocols in keeping with the core Vega protocol. - Should be as simple as possible and should operate correctly independent of whether any aspect of the core protocol is functioning as expected (i.e. they should allow recovery from issues in which someone is able to exploit bugs in products, margins, data sourcing, settlement, collateral, etc.). - Are designed to be resilient to failure of the Vega chain and operable assuming only the continued existence of an honest quorum of validators (with their private keys) and the multisig control and bridge pool contract holding control over assets on the Ethereum chain. @@ -21,9 +22,9 @@ These features: For Sweetwater, we only require the ability to: 1. Prevent the submission of market creation proposals until a validator initiated and agreed change to the genesis configuration -2. Prevent the submission of asset addition proposals until a validator initiated and agreed change to the genesis configuration -3. Set a date/time before which no market creation proposal will be enacted as a network parameter (note if the above submission prevention is in place the proposal must still be rejected after this date) -4. Set a date/time before which no asset addition proposal will be enacted as a network parameter (note if the above submission prevention is in place the proposal must still be rejected after this date) +1. Prevent the submission of asset addition proposals until a validator initiated and agreed change to the genesis configuration +1. Set a date/time before which no market creation proposal will be enacted as a network parameter (note if the above submission prevention is in place the proposal must still be rejected after this date) +1. Set a date/time before which no asset addition proposal will be enacted as a network parameter (note if the above submission prevention is in place the proposal must still be rejected after this date) At genesis, Sweetwater will be started with only one asset: VEGA. As no new assets can be proposed (limit 2), only VEGA tokens can be deposited or withdrawn via the bridge. There will be no markets at genesis, and due to point 1 above, no markets can be created. @@ -86,10 +87,10 @@ This is primarily for liquidity providers and other sophisticated participants a ## Limitations - These features do not protect against a malicious validator set. -- No attempt is made to prevent sybils with these features, although the ratio between gas fees for deposites and withdrawals and the limits per public key will affect the attractiveness of **any** money making scheme whether by intended or unintended behaviour of the protocol, therefore low limits can provide some level of mitigation here. +- No attempt is made to prevent sybils with these features, although the ratio between gas fees for deposits and withdrawals and the limits per public key will affect the attractiveness of **any** money making scheme whether by intended or unintended behaviour of the protocol, therefore low limits can provide some level of mitigation here. - Users could submit multiple small withdrawals to get around the size limits for delays. To mitigate this, sizes can be set such that gas costs of such an approach would be significant, or to zero so that all withdrawals are delayed. -- -# Network Parameters + +## Network Parameters | Property | Type | Example value | Description | |------------------|--------| ------------|--------------| @@ -108,7 +109,7 @@ This is primarily for liquidity providers and other sophisticated participants a - Any valid market creation proposal is allowed, as per [0028-GOVE](./../protocol/0028-GOVE-governance.md) - With `propose_market_enabled_from` set to the past - Any valid market creation proposal is allowed, as per [0028-GOVE](./../protocol/0028-GOVE-governance.md) -2. Asset creation can be restricted using genesis configuration (0028-GOVE-025) +1. Asset creation can be restricted using genesis configuration (0028-GOVE-025) - With `propose_asset_enabled` set to true in the genesis configuration - With `propose_asset_enabled_from` set to the future: - Any asset creation proposal is rejected @@ -116,34 +117,33 @@ This is primarily for liquidity providers and other sophisticated participants a - Any valid asset creation proposal is allowed, as per [0028-GOVE](./../protocol/0028-GOVE-governance.md) - With `propose_asset_enabled_from` set to the past: - Any valid asset creation proposal is allowed, as per [0028-GOVE](./../protocol/0028-GOVE-governance.md) -3. `propose_market_enabled_from` can be changed through a network parameter update proposal (0028-GOVE-008) -4. `propose_asset_enabled_from` can be changed through a network parameter update proposal (0028-GOVE-008) +1. `propose_market_enabled_from` can be changed through a network parameter update proposal (0028-GOVE-008) +1. `propose_asset_enabled_from` can be changed through a network parameter update proposal (0028-GOVE-008) ### Smart contract criteria -5. `max lifetime deposit` is enforced by the [ERC20 bridge](./../protocol/0031-ETHB-ethereum_bridge_spec.md) (0003-NP-LIMI-001) - - This does not apply to the [governance staking contract](./../glossaries/staking-and-governance.md) - - With an Ethereum address that has never deposited to Vega before: - - A valid deposit transaction that is less than `max lifetime deposit` is not rejected - - A valid second deposit transaction that, in addition to the first TX exceeds `max lifetime deposit` is rejected - - This is true even if both TXs target different [Vega public keys](./../protocol/0017-PART-party.md) - - Withdrawing all funds after the first transaction, then placing a valid second deposit transaction that causes total lifetime deposits to exceed `max lifetime deposit` is still rejected - - A single deposit transaction that is more than `max lifetime deposit` rejected - -6. `max lifetime deposit` can be overridden for specific Ethereum addresses through an Ethereum transaction (0003-NP-LIMI-002) - - An ETH address that is listed on the smart contract as exempt can deposit more than `max lifetime deposit` - - Any ETH address can use a method on the smart contract to add or remove itself (own ETH address) from the exemption list - -7. `max lifetime deposit` can be updated per asset via an Ethereum transaction (0003-NP-LIMI-003) -8. Validators can, via multisig, stop and recommence processing bridge transactions (0003-NP-LIMI-004) - - A representative set of validators can produce a multisig transaction that stops all future deposits and withdrawals - - A representative set of validators can produce a multisig transaction that allows the bridge to resume processing future deposits and withdrawals - - All withdrawals that are submitted while the bridge is 'stopped' are rejected - - All deposits that are submitted while the bridge is 'stopped' are rejected -9. Withdrawal delay network parameter requires a wait between withdrawals creation & submission if it meets or exceeds a threshold (0003-NP-LIMI-005) - - For valid withdrawals that have been approved by validators, when the user submits the TX to the bridge smart contract: - - If the withdrawal amount is below or equal to `withdrawal delay threshold`, the withdrawal is accepted by the bridge smart contract - - If the withdrawal amount is above `withdrawal delay threshold` for the asset, - - If it is submitted before `withdrawal delay period`, it is rejected by the bridge smart contract - - If it is submitted after `withdrawal delay period`, it is accepted by the bridge smart contract - - `withdrawal delay threshold` can be changed, per asset, by multisig control on the bridge contract -10. A withdrawal that is subject to delay can be cancelled by a validator (0003-NP-LIMI-006) + +1. `max lifetime deposit` is enforced by the [ERC20 bridge](./../protocol/0031-ETHB-ethereum_bridge_spec.md) (0003-NP-LIMI-001) + - This does not apply to the [governance staking contract](./../glossaries/staking-and-governance.md) + - With an Ethereum address that has never deposited to Vega before: + - A valid deposit transaction that is less than `max lifetime deposit` is not rejected + - A valid second deposit transaction that, in addition to the first TX exceeds `max lifetime deposit` is rejected + - This is true even if both TXs target different [Vega public keys](./../protocol/0017-PART-party.md) + - Withdrawing all funds after the first transaction, then placing a valid second deposit transaction that causes total lifetime deposits to exceed `max lifetime deposit` is still rejected + - A single deposit transaction that is more than `max lifetime deposit` rejected +1. `max lifetime deposit` can be overridden for specific Ethereum addresses through an Ethereum transaction (0003-NP-LIMI-002) + - An ETH address that is listed on the smart contract as exempt can deposit more than `max lifetime deposit` + - Any ETH address can use a method on the smart contract to add or remove itself (own ETH address) from the exemption list +1. `max lifetime deposit` can be updated per asset via an Ethereum transaction (0003-NP-LIMI-003) +1. Validators can, via multisig, stop and recommence processing bridge transactions (0003-NP-LIMI-004) + - A representative set of validators can produce a multisig transaction that stops all future deposits and withdrawals + - A representative set of validators can produce a multisig transaction that allows the bridge to resume processing future deposits and withdrawals + - All withdrawals that are submitted while the bridge is 'stopped' are rejected + - All deposits that are submitted while the bridge is 'stopped' are rejected +1. Withdrawal delay network parameter requires a wait between withdrawals creation & submission if it meets or exceeds a threshold (0003-NP-LIMI-005) + - For valid withdrawals that have been approved by validators, when the user submits the TX to the bridge smart contract: + - If the withdrawal amount is below or equal to `withdrawal delay threshold`, the withdrawal is accepted by the bridge smart contract + - If the withdrawal amount is above `withdrawal delay threshold` for the asset, + - If it is submitted before `withdrawal delay period`, it is rejected by the bridge smart contract + - If it is submitted after `withdrawal delay period`, it is accepted by the bridge smart contract + - `withdrawal delay threshold` can be changed, per asset, by multisig control on the bridge contract +1. A withdrawal that is subject to delay can be cancelled by a validator (0003-NP-LIMI-006) diff --git a/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md b/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md index 55351b0b6..5ccba9522 100644 --- a/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md +++ b/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md @@ -1,11 +1,12 @@ # Network Parameters Signed for Sweetwater There are parameters within Vega that influence the behaviour of the system: + - some are set in genesis block but fixed once network is running, - while others are changeable by on-chain [governance](../protocol/0028-GOVE-governance.md) but initialised to genesis values during network launch. For more info see [network paramters](../protocol/0054-NETP-network_parameters.md) -On [Sweetwater Release](../milestones/2.5-Sweetwater.md) Vega Team wishes to control how certain parameters are initialised while letting validators change others as they see fit. -As the process of decentalisation progresses Vega Team the number of such parameters will be reduced. +On [Sweetwater (Restricted Mainnet) Release](https://github.com/orgs/vegaprotocol/projects/114) Vega Team wishes to control how certain parameters are initialised while letting validators change others as they see fit. +As the process of decentralisation progresses Vega Team the number of such parameters will be reduced. ## Signing @@ -16,8 +17,8 @@ The configuration of the network parameters defined here will be signed and veri The values to be specified as a PR against ??? repo. -TODO: once the repo is chosen put a link here. -TODO: find where `validator min balance` is defined and reference correctly. +`TODO`: once the repo is chosen put a link here. +`TODO`: find where `validator min balance` is defined and reference correctly. | Name | Comment | Suggested value (optional) | |-------------------------------------------------------------|:------------------------------------------------------------------:| :-------------------------:| @@ -25,7 +26,7 @@ TODO: find where `validator min balance` is defined and reference correctly. | `validator min balance` | Not in [network paramters](../protocol/0054-NETP-network_parameters.md) | 3000 VEGA | | `governance.proposal.updateNetParam.requiredMajority` | So that what is set in genesis cannot be changed too easily | 0.5 | | `governance.proposal.updateNetParam.requiredParticipation` | So that what is set in genesis cannot be changed too easily | 0.5 | -| `validators.epoch.length` | Rewards currently make an assumption on epoch lenght, best fix it. | 1 day | +| `validators.epoch.length` | Rewards currently make an assumption on epoch length, best fix it. | 1 day | | `genesis asset section` | Only one asset: VEGA | | | `blockchains.ethereumConfig` | Sets collateral and staking bridge addresses. | | | `network.checkpoint.chainEndOfLifeDate` | Can enforce code upgrade by setting this not too far ahead. | 21 days | diff --git a/non-protocol-specs/0008-NP-NULB-null_blockchain_vega.md b/non-protocol-specs/0008-NP-NULB-null_blockchain_vega.md index e07077cc8..df25159a0 100644 --- a/non-protocol-specs/0008-NP-NULB-null_blockchain_vega.md +++ b/non-protocol-specs/0008-NP-NULB-null_blockchain_vega.md @@ -41,9 +41,7 @@ An extra API is added to allow the user to control the time and block start/end - The null blockchain block time does not control the automatic creation of blocks - With the block time set to `1 second`, if at block height 1 I perform no actions for 5 seconds, the block height will still be 1 (0008-NP-NULB-003) - With the transactions-per-block configuration set to `2` - - If at block height 1 I submit 3 transactions, the block height will have increased to 2 (0008-NP-NULB-004) - - If at block height 1 I submit 1 transaction, the block height will still be 1 (0008-NP-NULB-005) + - If at block height 1 I submit 3 transactions, the block height will have increased to 2 (0008-NP-NULB-004) + - If at block height 1 I submit 1 transaction, the block height will still be 1 (0008-NP-NULB-005) - If at block height 1 I move time forward by 1s, the block height will have increased to 2 (0008-NP-NULB-006) - There is golang example which creates three parties, gives them assets, one party proposes a market and acts as LP, the remaining two parties trade, placing one trade per day for "365 days". The LP party submits a trading terminated transaction after "365 days" and a subsequent settlement price transaction and the market settles. (0008-NP-NULB-007) - - diff --git a/spellcheck.sh b/spellcheck.sh index 5f0c26bd4..84df29653 100755 --- a/spellcheck.sh +++ b/spellcheck.sh @@ -11,3 +11,7 @@ brew install aspell echo "Running the spell checker..." pyspelling --config spellcheck.yaml + +echo "Remove dictionary binary..." + +rm -r dictionary.dic diff --git a/spellcheck.yaml b/spellcheck.yaml index 27149b6ba..dd46032a7 100644 --- a/spellcheck.yaml +++ b/spellcheck.yaml @@ -6,6 +6,9 @@ matrix: - name: Markdown sources: - 'protocol/*.md' + - 'non-protocol-specs/*.md' + - 'glossaries/*.md' + - 'README.md' default_encoding: utf-8 aspell: d: en_GB @@ -13,7 +16,7 @@ matrix: ignore-case: true dictionary: encoding: utf-8 - output: .pyspelling-custom-md-en.dic.tmp + # output: .pyspelling-custom-md-en.dic.tmp wordlists: - wordlist.txt pipeline: diff --git a/wordlist.txt b/wordlist.txt index f3ee3e846..9b8fac7bd 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -27,6 +27,7 @@ CCP ccy ceil ceiled +CFD CSF checkpointing CLEF @@ -54,6 +55,7 @@ datetime decentralised decentralises decrypt +decrypted decrypts delegateable delegator @@ -61,6 +63,7 @@ delegators deterministically discoverability disincentivise +DLT DPOS durations ECDSA @@ -108,12 +111,14 @@ GTC GTT Gwei hardcoded +Homomorphic HSM HTTP HTTPS IBC incentivise incentivised +incrementing init initialisation initialise @@ -126,12 +131,14 @@ IOC JSON keyholder keypair +keypairs keystore KMS lifecycle linearised linkings linux +Liskov liveness LNL lognormal @@ -145,6 +152,7 @@ margining messager math mempool +Merkle MetaMask microstructure midprice @@ -193,6 +201,7 @@ RPC runnable runtime scalable +scalability Scholes selectable sepolia @@ -214,10 +223,15 @@ SSL suboptimal subtype subtypes +SVTs SweetWater +sybil +sybils tau +TBC Tendermint testnet +testnets TIF tokenholder tokenholders @@ -226,7 +240,9 @@ trackable Tron trustless tx +TXs quant +UI uint unmarshal unamended From f957111d929a1ef8bdc304a1c3b954a485293346 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Wed, 1 Feb 2023 01:47:14 -0800 Subject: [PATCH 024/103] Update 0069-VCBS-validators_chosen_by_stake.md Added ACs to match the implementation so its codified (i.e., if an Ersatzvalidator drops below ownstake and there's no-one there to replace it, it is not demoted to pending. --- protocol/0069-VCBS-validators_chosen_by_stake.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 60f87a3f2..2b38a5d4c 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -420,6 +420,22 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. + + + 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, + - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) + - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) + - 1 validator drops to the lowest delegated stake (1000) + - 1 ersatz validator has 6000 stake and sufficient `ownstake` + - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. + 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, + - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) + - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) + - 2 ersatz validators have 6000 stake and sufficient `ownstake` + - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is not removed + + + 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators From 998012019d7d53b6fde8393dc962dc1c324f4498 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Wed, 1 Feb 2023 01:51:29 -0800 Subject: [PATCH 025/103] Update 0069-VCBS-validators_chosen_by_stake.md --- protocol/0069-VCBS-validators_chosen_by_stake.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 2b38a5d4c..cdd3daa72 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -428,12 +428,13 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, + - Add a new pending validator with enough ownstake; verify that it replaces the ersatzvalidator that had insufficient ownstake. + 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) - 2 ersatz validators have 6000 stake and sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is not removed - + 1. Set 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, From 3cd1498af9929077d745f00463b610f91fe407a6 Mon Sep 17 00:00:00 2001 From: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Date: Wed, 1 Feb 2023 11:27:18 +0000 Subject: [PATCH 026/103] fix: Update acceptance criteria to correctly reflect implementation (#1549) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0076-DANO-data-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 302716bea..027bb220f 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -190,4 +190,4 @@ It must be possible to add to the data node APIs that return the result of calcu 1. The event bus stream is available from validators, non validators and the DataNode (0076-DANO-017) 1. All events that are emitted on the full unfiltered event stream are processed by the DataNode (no data is lost) (0076-DANO-018) 1. If a DataNode loses connection to a Vega node if will attempt to reconnect and if the cached data received from the Vega node is enough to continue working it can resume being a DataNode. (0076-DANO-019) -1. The DataNode must provide its current block height and connection status on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021) +1. The DataNode must provide its current block height and vega time on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021) From 23e87a846a4d20663fb0f1ad8612776020e9315c Mon Sep 17 00:00:00 2001 From: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Date: Wed, 1 Feb 2023 13:32:23 +0200 Subject: [PATCH 027/103] fix: update epoch ACs (#1555) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0050-EPOC-epochs.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0050-EPOC-epochs.md b/protocol/0050-EPOC-epochs.md index 2c439e83a..517da9c74 100644 --- a/protocol/0050-EPOC-epochs.md +++ b/protocol/0050-EPOC-epochs.md @@ -199,15 +199,15 @@ All parameters that are changed through a governance vote are valid starting the Epochs change at the end of the first block that is after the epoch expiry has passed: -- Given an epoch length of `1d`, with a block time of `1h`, at block 1 the current epoch is `1` (0050-EPOC-001) -- Given an epoch length of `1d`, with a block time of `1h`, at end of block 23 the current epoch is `1` (0050-EPOC-002) -- Given an epoch length of `1d`, with a block time of `1h`, at end of block 24 the current epoch is `2` (0050-EPOC-003) +- Given an epoch length of `x`, with a block time arbitrary but `0050-EPOC-001) +- Given an epoch length of `x`, with a block time `x/y`, at end of block `y-1` the current epoch is `1` (0050-EPOC-002) +- Given an epoch length of `x`, with a block time of `x/y`, at end of block `y` the current epoch is `2` (0050-EPOC-003) Edge case: Multiple epochs can pass within the same block (0050-EPOC-004): -- Given an epoch length of `1s`, with a block time of `1m`, at end of block 1 the current epoch is `1` -- Given an epoch length of `1s`, with a block time of `1m`, at end of block 61 the current epoch is `61` - +- Given an epoch length of `x`, with a block time of `x*y`, at end of block 1 the current epoch is `1` +- Given an epoch length of `x`, with a block time of `x*y`, at end of block `y+1` the current epoch is `y+1` + Nomination takes effect at epoch changeover: - During epoch 1, `party 1` nominates any valid amount to `validator 1` From c7ff0b80a8eb25e617ef85f3cb925e8a1fec6db9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 2 Feb 2023 09:51:52 +0000 Subject: [PATCH 028/103] feat: update 0042, LP fee Transfer, Distribution --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 62ae33e8f..f17bbd850 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -199,7 +199,7 @@ On every trade, liquidity fee should be collected immediately into an account fo This account is not under control of the LP party (they cannot initiate transfers in or out of the account). The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. -A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's margin account for the market. If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. +A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market. If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. The liquidity fees are distributed pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. @@ -234,9 +234,9 @@ LP 4 els = 0.33 When the time defined by `market.liquidity.providers.fee.distributionTimeStep` elapses we do transfers: ```math -67.275 ETH from LP 1's LP account to LP 1's margin account -25.875 ETH from LP 2's LP account to LP 2's margin account -10.350 ETH from LP 3's LP account to LP 3's margin account +67.275 ETH from LP 1's LP account to LP 1's general account +25.875 ETH from LP 2's LP account to LP 2's general account +10.350 ETH from LP 3's LP account to LP 3's general account ``` ### APIs for fee splits and payments @@ -277,4 +277,4 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e ### Distribution -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment (and the traded value is the same in both epochs). (0042-LIQF-018) +- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-018) From e0e5a50344664ed05d4abccbcfde97ca99562841 Mon Sep 17 00:00:00 2001 From: Edd Date: Thu, 2 Feb 2023 14:06:03 +0000 Subject: [PATCH 029/103] Add build folder to gitigore The approbation checks in `makefile` use this folder. Make sure it's not checked in. --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index c612fbd71..a6ea1c192 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,6 @@ .ipynb_checkpoints/ .obsidian/ .vscode/ + +# Used by makefile to clone repos for approbation checks +.build/ From 9c6965a7f333c3731b5099f0cefe44116944c1a3 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Thu, 2 Feb 2023 14:12:00 +0000 Subject: [PATCH 030/103] Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index f17bbd850..5c8395d70 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -199,7 +199,8 @@ On every trade, liquidity fee should be collected immediately into an account fo This account is not under control of the LP party (they cannot initiate transfers in or out of the account). The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. -A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market. If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. +A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. +If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. The liquidity fees are distributed pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. From 8fc249b564a3f0567ce3f67b7cf4e262699f57e5 Mon Sep 17 00:00:00 2001 From: Edd Date: Thu, 2 Feb 2023 14:19:51 +0000 Subject: [PATCH 031/103] Ignore dictionary Spellcheck creates a dictionary file. Ensure it isn't committed. --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index a6ea1c192..590772b83 100644 --- a/.gitignore +++ b/.gitignore @@ -6,3 +6,6 @@ # Used by makefile to clone repos for approbation checks .build/ + +# Used by ./spellcheck.sh +dictionary.dic From a3b706b9aab998284a187ea8ac82f7eaedf81fcb Mon Sep 17 00:00:00 2001 From: Edd Date: Thu, 2 Feb 2023 14:50:25 +0000 Subject: [PATCH 032/103] Un parallelise clone-sources in makefile The makefile tried to be clever and run all the remote-repo clones for Approbation checks in parallel. Due to my limited makefile skills, the check could run before a clone was finished. Run them in series instead. This also improves the output a little --- makefile | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/makefile b/makefile index 9f36d8ccf..77684ee69 100644 --- a/makefile +++ b/makefile @@ -6,11 +6,13 @@ all: spellcheck markdownlint names codes references links clean # Check that all the specifications are named appropriately .PHONY: names names: + @$(MAKE) clone-sources npx @vegaprotocol/approbation check-filenames # Count how many Acceptance Criteria each specification has .PHONY: codes codes: + @$(MAKE) clone-sources npx @vegaprotocol/approbation check-codes TEMP=./.build @@ -19,12 +21,22 @@ clone-sources: @mkdir -p $(TEMP) @echo "Cloning/updating test repos..." + @echo "===============================" + @echo "" @cd $(TEMP); \ - git -C MultisigControl pull || git clone https://github.com/vegaprotocol/MultisigControl.git & \ - git -C vega pull || git clone https://github.com/vegaprotocol/vega.git & \ - git -C vega_token_v2 pull || git clone https://github.com/vegaprotocol/vega_token_v2.git & \ - git -C staking_bridge pull || git clone https://github.com/vegaprotocol/staking_bridge.git & \ + echo "- MultisigControl"; \ + git -C MultisigControl pull || git clone https://github.com/vegaprotocol/MultisigControl.git; \ + echo "- Vega"; \ + git -C vega pull || git clone https://github.com/vegaprotocol/vega.git; \ + echo "- Vega_token_v2"; \ + git -C vega_token_v2 pull || git clone https://github.com/vegaprotocol/vega_token_v2.git; \ + echo "- staking_bridge"; \ + git -C staking_bridge pull || git clone https://github.com/vegaprotocol/staking_bridge.git; \ + echo "- system-tests"; \ git -C system-tests pull || git clone https://github.com/vegaprotocol/system-tests.git + @echo "" + @echo "===============================" + @echo "" # Which Acceptance Criteria are referenced in which feature files? # Runs make clone-sources in a shell so that it properly waits for them to run in parallel and finish @@ -34,8 +46,6 @@ references: cd $(TEMP); npx -y @vegaprotocol/approbation@latest check-references --specs="../*protocol*/*.{md,ipynb}" --tests="./**/*.{js,py,feature}" --categories="../protocol/categories.json" --show-branches --show-mystery --verbose --show-files - @$(MAKE) clean - # Imperfect, but useful - hence not included in ALL .PHONY: links links: From 125da9ca8ef5d01f4c5543bd6723ba27b6458102 Mon Sep 17 00:00:00 2001 From: Edd Date: Thu, 2 Feb 2023 14:54:54 +0000 Subject: [PATCH 033/103] Add specs param to names and codes in makefile The old behaviour (default paths) should have been deprecated ages ago, but hasn't been. This change makes it provide the same paths as the defaults. --- makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/makefile b/makefile index 77684ee69..47682edc2 100644 --- a/makefile +++ b/makefile @@ -7,13 +7,13 @@ all: spellcheck markdownlint names codes references links clean .PHONY: names names: @$(MAKE) clone-sources - npx @vegaprotocol/approbation check-filenames + npx @vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" # Count how many Acceptance Criteria each specification has .PHONY: codes codes: @$(MAKE) clone-sources - npx @vegaprotocol/approbation check-codes + npx @vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" TEMP=./.build .PHONY:clone-sources From 9a289625bef13b758d933b8fdc6e3915dc4f1275 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 3 Feb 2023 10:08:57 +0000 Subject: [PATCH 034/103] feat: update maker fee transfer account --- protocol/0029-FEES-fees.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index df2b0b826..b26721742 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -94,9 +94,9 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ## Acceptance Criteria - Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001) -- Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their margin account and the remainder is split between the market making pool and staging pool. (0029-FEES-002) -- Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their margin account and the remainder is split between the market making pool and staging pool. (0029-FEES-003) -- Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their margin account and the remainder is split between the market making pool and staging pool. (0029-FEES-004) +- Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-002) +- Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-003) +- Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-004) - Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) From 81db528beb2cc4ebac132321d5d04ed2898939b1 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Fri, 3 Feb 2023 03:08:01 -0800 Subject: [PATCH 035/103] Update 0069-VCBS-validators_chosen_by_stake.md --- protocol/0069-VCBS-validators_chosen_by_stake.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index cdd3daa72..ef6a92ad1 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -434,9 +434,11 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) - 2 ersatz validators have 6000 stake and sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is not removed - 1. Set - - + - Now reduce the ownstake of both ersatzvalidators and one real validator below the ownstake requirement; verify that both ersatzvalidators are not demoted to pending, and that the tendermint validator is not demotet to ersatz (i.e., tendermint validators are not demoted if there is no appropriate ersatz). + - Reduce the ownstake of both ersatzvalidators to 0. Verify that both ersatzvalidators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). + - Reduce the ownstake of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient ownstake is not. + + 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators From e61c3d6d0ab3d4d4ce8a757a2b45b94fdaebf1fb Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Fri, 3 Feb 2023 11:49:28 +0000 Subject: [PATCH 036/103] Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0029-FEES-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index b26721742..7dfd78f1d 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -94,7 +94,7 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ## Acceptance Criteria - Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001) -- Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-002) +- Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) - Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-003) - Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-004) - Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005) From 10d105b18a00f2a1a1e4a2598807fd99ff1ae879 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Fri, 3 Feb 2023 12:02:40 +0000 Subject: [PATCH 037/103] Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0029-FEES-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 7dfd78f1d..8aca0963d 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -95,7 +95,7 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001) - Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) -- Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-003) +- Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-003) - Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-004) - Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) From 98ba795825608f6dabb0c51fdda557161e813da7 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Fri, 3 Feb 2023 12:02:49 +0000 Subject: [PATCH 038/103] Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0029-FEES-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 8aca0963d..64bef4130 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -96,7 +96,7 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001) - Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) - Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-003) -- Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staging pool. (0029-FEES-004) +- Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-004) - Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) From 822bf36e9c0e46cc7ede5c1aa283932b27e9d0db Mon Sep 17 00:00:00 2001 From: RomanLeca Date: Mon, 6 Feb 2023 17:28:53 +0200 Subject: [PATCH 039/103] Update 0048-DSRI-data_source_internal.md --- protocol/0048-DSRI-data_source_internal.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index 7e4fb9210..ffa3333f3 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -122,6 +122,7 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna - update the market to have a time based termination - update the market to have an earlier time based termination - wait until the first timer to tick + - send through valid settlement data - assert the the market settles successfully 1. Time based termination across multiple markets (0048-DSRI-014) - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time From f1564deb81e999de6605e426abd85aeaa5c8b55e Mon Sep 17 00:00:00 2001 From: claudiumilea Date: Tue, 7 Feb 2023 11:08:56 +0200 Subject: [PATCH 040/103] fix: refactor 0069-VCBS-052 (#1570) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> --- protocol/0069-VCBS-validators_chosen_by_stake.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 60f87a3f2..c59e3c007 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -438,8 +438,8 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Restart the validator, run until the end of the epoch - Verify that this validator is paid reward as ersatz validator and that their stake score under reward is anti-whaled 1. Number of slots decreased (0069-VCBS-052): - - Setup a network with 7 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - - Decrease the number of tendermint validators to 5. + - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). + - Decrease the number of tendermint validators to 3. - Verify that in each of the following two epochs, the validator with the lowest score is demoted to Ersatz validator and an Ersatz validator is demoted to pending 1. Number of Ersatz validators increased (0069-VCBS-058): - Setup a network with 4 Tendermint validators, 2 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5), and 2 pending validators From c504e4f07c2fe0b00e252000622ee0af0c02f89c Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 7 Feb 2023 09:51:17 +0000 Subject: [PATCH 041/103] fix: MD and spelling lint checks --- protocol/0069-VCBS-validators_chosen_by_stake.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 12ec62267..5f64501d9 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -420,25 +420,21 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. - - 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - - Add a new pending validator with enough ownstake; verify that it replaces the ersatzvalidator that had insufficient ownstake. + - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatzvalidator that had insufficient `ownstake`. 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) - 2 ersatz validators have 6000 stake and sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is not removed - - Now reduce the ownstake of both ersatzvalidators and one real validator below the ownstake requirement; verify that both ersatzvalidators are not demoted to pending, and that the tendermint validator is not demotet to ersatz (i.e., tendermint validators are not demoted if there is no appropriate ersatz). - - Reduce the ownstake of both ersatzvalidators to 0. Verify that both ersatzvalidators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). - - Reduce the ownstake of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient ownstake is not. - - + - Now reduce the `ownstake` of both ersatz validators and one real validator below the `ownstake` requirement; verify that both ersatz validators are not demoted to pending, and that the tendermint validator is not demoted to ersatz (i.e., tendermint validators are not demoted if there is no appropriate ersatz). + - Reduce the `ownstake` of both ersatz validators to 0. Verify that both ersatz validators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). + - Reduce the `ownstake` of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient `ownstake` is not. 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators @@ -541,6 +537,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). 1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. + - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Verify that no rewards are paid out on the first epoch. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. From 51cadee9dd0cf890c6ab6640f38eefbd7bde9df8 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 7 Feb 2023 09:53:22 +0000 Subject: [PATCH 042/103] fix: MD and spelling lint errors --- protocol/0069-VCBS-validators_chosen_by_stake.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 5f64501d9..f76fb16f7 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -426,12 +426,12 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatzvalidator that had insufficient `ownstake`. + - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatz validator that had insufficient `ownstake`. 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) - 2 ersatz validators have 6000 stake and sufficient `ownstake` - - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is not removed + - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is not removed - Now reduce the `ownstake` of both ersatz validators and one real validator below the `ownstake` requirement; verify that both ersatz validators are not demoted to pending, and that the tendermint validator is not demoted to ersatz (i.e., tendermint validators are not demoted if there is no appropriate ersatz). - Reduce the `ownstake` of both ersatz validators to 0. Verify that both ersatz validators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). - Reduce the `ownstake` of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient `ownstake` is not. From b160b7ee5f134a3f72ad6017ab257c02f3133908 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 7 Feb 2023 09:58:06 +0000 Subject: [PATCH 043/103] fix: update wording for AC 0059-VCBS-016- (#1566) --- protocol/0059-STKG-simple_staking_and_delegating.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0059-STKG-simple_staking_and_delegating.md b/protocol/0059-STKG-simple_staking_and_delegating.md index b5a4b4838..3cb481662 100644 --- a/protocol/0059-STKG-simple_staking_and_delegating.md +++ b/protocol/0059-STKG-simple_staking_and_delegating.md @@ -205,7 +205,7 @@ These accounts will be created: - Removal of delegation may happen in the following 2 ways: - Announcing removal, but maintaining stake until last block of the current epoch. This "announced stake" may be then (re)delegated (e.g. to a different validator). (0059-STKG-014) - Announcing removal and withdrawing stake immediately. Rewards are still collected for this stake until the end of the epoch, but they are sent to the on-chain treasury account for that asset. (0059-STKG-015) -- Every 30 seconds (and at the end of an epoch) the associated stake is reconciled against the current nomination to ensure that the total nomination is not exceeding the total association. In case it does we proportionally un-nominate from the validators until the nomination is not exceeding the association. It's worth mentioning that this only affects the balance of the current epoch - we don't attempt to reconcile the balance for the next epoch until the epoch ends, so if for example the party had an association of a 100 tokens, then they requested to nominate 100 tokens to `validator1`, their balance for the next epoch would remain 100 until the end of the epoch even if they immediately dissociate the 100 tokens. (0059-STKG-016) +- Every 30 seconds (and at the end of an epoch) the associated stake is reconciled against the current nomination to ensure that the total nomination is not exceeding the total association. In case it does we proportionally un-nominate from the validators until the nomination is not exceeding the association. It's worth mentioning that for the current epoch nomination balance we consider the minimum stake that the party had for the duration of the period evaluated (from the beginning of the epoch). Also, for next epoch's nomination balance we consider the current balance of the association. Have one party stake 100 tokens split 70-30 between two validators. With a an epoch of length 5 minutes, at the beginning of the epoch remove 50 tokens off the stake. Within 30 seconds of the confirmation of updated association, verify that the nomination balances for the current epoch and next has been removed with respect to the 70/30 split, such that it is now 35/15. (0059-STKG-016) ### Changing delegation From 2e2d3b8ffceb538c5e12de0b989a0ce5487d7b79 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Tue, 7 Feb 2023 06:26:40 -0800 Subject: [PATCH 044/103] Update 0062-SPAM-spam_protection.md (#1571) * Update 0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0062-SPAM-spam_protection.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index bf2f1f0f2..b6209beaa 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -48,6 +48,8 @@ max_batch_size = 15 // maximal number of transactions allowed (for consistency reasons, the prevailing source for all parameter values is the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go)code file. In case of differences, the information in that file is the valid one). +As (due to Tendermint constraints) it is currently possible to exceed all thresholds within one block, an attacker can always spam one block; to mitigate this, a attacker that does so is temporarily banned. For now, all bans are independent, i.e., a ban due to excessive voting only affects further votes. + - Any tokenholder with more than `min_voting_tokens` tokens on a public key has `num_votes` voting attempts per epoch and proposal, i.e., they can change their mind `num_votes-1` times in one epoch. This means a transaction is pre-block rejected if there are `num_votes` or more on the same proposal in the blockchain in the same epoch, and post_block rejected if there are `num_votes` or more on the same proposal in the blockchain plus earlier in the current block. - Any tokenholder that had more than 50% of its governance transactions post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all of its governance related transactions (but no trading related transactions) are immediately rejected. E.g., if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. The voting counters are unaffected by the ban, so voting again on a proposal that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now unlikely to trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. - A proposal can only be issued by a tokenholder with more than `min_proposing_tokens` associated with one public key at the start of the epoch. Also (like above), only `num_proposals` proposals can be made per tokenholder per epoch. For example, every proposal past `num_proposals` in an epoch is rejected by post-block-rejected if the sum of their proposals in past blocks and the ones in the current block exceed `num_proposals`, or pre-block rejected if the sum of proposals already in the blockchain for that epoch equals or exceeds `num_proposals`. This parameter is the same for **all proposals**. There also is a separate parameter to the same end that is enforced in the core. For Sweetwater, both these parameters had the same value, but the spam protection value can be set lower, as the amplification effect of a proposal (i.e., a proposal resulting in a very large number of votes) would also then be covered by the core. @@ -108,7 +110,7 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - If the ban of a party ends because the epoch ends, transactions from that party are no longer rejected (0062-SPAM-016) - If a party gets banned, the ban ends due to the epoch ending, and it gets banned again at the beginning of the new epoch, the ban still lasts the entire time (or until the next epoch end), i.e., the ban-expiration timer is reset. (0062-SPAM-017) - If a party gets banned several times during an epoch, all banns last for the defined time or until the epoch ends (try with at least three banns) (0062-SPAM-018) -- During a ban due to too many votes, all governance related transactions are rejected (0062-SPAM-019) +- A ban only affects transactions of the type that caused the ban, i.e., a voting ban only affects further votes.(0062-SPAM-019) - After having been banned for too many votes and unbanned, with the maximum number of votes in that epoch exceeded, any additional votes are rejected without a new ban. (0062-SPAM-020) - Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWithdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021) - Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) From b31101a768033394a4a5e1566c38cbda4ad71037 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Tue, 7 Feb 2023 06:28:40 -0800 Subject: [PATCH 045/103] Update 0011-NP-CLIE-client-interaction-tests.md (#1542) * Update 0011-NP-CLIE-client-interaction-tests.md Added ACs to test static spam protection (wallet doesn't allow you to get banned) * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update 0011-NP-CLIE-client-interaction-tests.md * chore: fix spelling and MD lint checks --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport --- .../0011-NP-CLIE-client-interaction-tests.md | 21 ++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index b83585410..0df16908b 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -8,13 +8,24 @@ This specification contains a set of tests/acceptance criteria that clients (wal 1. The parameter `spam.pow.numberofTxPerBlock` is decreased. Verify that: - The new parameter is communicated to and adapted by the wallet, i.e., if a user has too many transactions according to the new parameter, the wallet does not submit transactions with a too low PoW difficulty (either by submitting a PoW of higher difficulty, or by submitting the transactions later). (0011-NP-CLIE-001) -2. The parameter `spam.pow.numberOfTxPerBlock` is increased. Verify that: +1. The parameter `spam.pow.numberOfTxPerBlock` is increased. Verify that: - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This means that a wallet that has had a number of transactions exceeding the previous limit, but not the current one, does not increase the PoW difficulty or delay the transactions (0011-NP-CLIE-002) -3. The parameter `spam.pow.difficulty` is increased. Verify that: +1. The parameter `spam.pow.difficulty` is increased. Verify that: - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-003) -4. The parameter `spam.pow.difficulty` is decreased. Verify that +1. The parameter `spam.pow.difficulty` is decreased. Verify that - This is communicated to the wallet, and the wallet uses these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-004) -5. The parameter `spam.pow.increaseDifficulty` is changed from `0` to `1`. Verify that +1. The parameter `spam.pow.increaseDifficulty` is changed from `0` to `1`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-005) -6. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that +1. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` PoWs tied to a given block before using another. If this results in none being available the transaction should not be sent. (0011-NP-CLIE-006) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10. Send significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` (about 100 is a good number) transactions at the same time, and keep sending transactions at a rate of more than 20 in the time a block is processed for at least 10 more blocks. Assure that does not get banned, and either sends all transactions eventually, or returns a meaningful error. (0011-NP-CLIE-007) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and gets banned.(0011-NP-CLIE-008) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least a 10 minutes. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and gets banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-009) +1. Submit significantly (ten times) as many votes than allowed (`SpamProtectionMaxVotes` = 3) for the same issue at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-010) +1. Submit significantly (ten times) as many proposals than allowed (`SpamProtectionMaxProposals` = 3)at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-011) +1. Submit significantly (ten times) as many delegation changes than allowed (`SpamProtectionMaxDelegations` = 390)at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-012) +1. Submit one less than (`SpamProtectionMaxVotes` = 3) , i.e., 2 votes in the same epoch. Once all votes are processed, submit 2 new votes at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new simultaneous votes on that issue in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-013) +1. Submit one less than (`SpamProtectionMaxProposals` = 3) , i.e., 2 proposals in an epoch from an account that has more than `SpamProtectionMinTokensForProposal` tokens). Once all proposals are processed, submit 2 new proposals at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new proposals at the same time in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-014) +1. Submit one less than (`SpamProtectionMaxDelegations` = 390) , i.e., 389 delegations in the same epoch from an account that has more than `SpamProtectionMinTokensForDelegation` tokens). Once all delegations are processed, submit 100 new delegations at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 100 new delegations at once in the next epoch and verify that the wallet allows it (and the account does not get blocked).(0011-NP-CLIE-015) +1. Create a key with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. Submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the account never gets banned, and that the client never crashed. (0011-NP-CLIE-016) +1. Create 20 keys with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. For all keys (within their respective wallets), submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the no account ever gets banned, and that the clients never crash. (0011-NP-CLIE-017) From 35cd1db0e79649d49891cd240ec0e08097585df3 Mon Sep 17 00:00:00 2001 From: RomanLeca Date: Tue, 7 Feb 2023 17:38:06 +0200 Subject: [PATCH 046/103] Update 0011-NP-CLIE-client-interaction-tests.md (#1579) --- .../0011-NP-CLIE-client-interaction-tests.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index 0df16908b..cf3e95385 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -19,13 +19,13 @@ This specification contains a set of tests/acceptance criteria that clients (wal 1. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` PoWs tied to a given block before using another. If this results in none being available the transaction should not be sent. (0011-NP-CLIE-006) 1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10. Send significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` (about 100 is a good number) transactions at the same time, and keep sending transactions at a rate of more than 20 in the time a block is processed for at least 10 more blocks. Assure that does not get banned, and either sends all transactions eventually, or returns a meaningful error. (0011-NP-CLIE-007) -1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and gets banned.(0011-NP-CLIE-008) -1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least a 10 minutes. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and gets banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-009) -1. Submit significantly (ten times) as many votes than allowed (`SpamProtectionMaxVotes` = 3) for the same issue at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-010) -1. Submit significantly (ten times) as many proposals than allowed (`SpamProtectionMaxProposals` = 3)at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-011) -1. Submit significantly (ten times) as many delegation changes than allowed (`SpamProtectionMaxDelegations` = 390)at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-012) -1. Submit one less than (`SpamProtectionMaxVotes` = 3) , i.e., 2 votes in the same epoch. Once all votes are processed, submit 2 new votes at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new simultaneous votes on that issue in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-013) -1. Submit one less than (`SpamProtectionMaxProposals` = 3) , i.e., 2 proposals in an epoch from an account that has more than `SpamProtectionMinTokensForProposal` tokens). Once all proposals are processed, submit 2 new proposals at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new proposals at the same time in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-014) -1. Submit one less than (`SpamProtectionMaxDelegations` = 390) , i.e., 389 delegations in the same epoch from an account that has more than `SpamProtectionMinTokensForDelegation` tokens). Once all delegations are processed, submit 100 new delegations at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 100 new delegations at once in the next epoch and verify that the wallet allows it (and the account does not get blocked).(0011-NP-CLIE-015) -1. Create a key with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. Submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the account never gets banned, and that the client never crashed. (0011-NP-CLIE-016) -1. Create 20 keys with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. For all keys (within their respective wallets), submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the no account ever gets banned, and that the clients never crash. (0011-NP-CLIE-017) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and get banned.(0011-NP-CLIE-008) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least 10 minutes. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and get banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-009) +1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same issue at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-010) +1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-011) +1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-012) +1. Submit one vote less than (`SpamProtectionMaxVotes` = 3) , i.e., 2 votes in the same epoch. Once all votes are processed, submit 2 new votes at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new simultaneous votes on that issue in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-013) +1. Submit one proposal less than (`SpamProtectionMaxProposals` = 3) , i.e., 2 proposals in an epoch from an account that has more than `SpamProtectionMinTokensForProposal` tokens). Once all proposals are processed, submit 2 new proposals at once (still in the same epoch). Verify that the wallet does not allow more than 1 proposal to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new proposals at the same time in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-014) +1. Submit one delegation less than (`SpamProtectionMaxDelegations` = 390) , i.e., 389 delegations in the same epoch from an account that has more than `SpamProtectionMinTokensForDelegation` tokens). Once all delegations are processed, submit 100 new delegations at once (still in the same epoch). Verify that the wallet does not allow more than 1 delegation to be submitted simultaneously, i.e., cause the account to get blocked. Submit 100 new delegations at once in the next epoch and verify that the wallet allows it (and the account does not get blocked).(0011-NP-CLIE-015) +1. Create a key with sufficient tokens to be allowed to submit proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. Submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the account never gets banned, and that the client never crashed. (0011-NP-CLIE-016) +1. Create 20 keys with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. For all keys (within their respective wallets), submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that no account ever gets banned, and that the clients never crash. (0011-NP-CLIE-017) From 988fd23afa18c0c67d05f61481f0a16ede1549db Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 7 Feb 2023 20:30:01 +0100 Subject: [PATCH 047/103] refactor: clarify AC --- protocol/0012-POSR-position_resolution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index b20e732f8..35b2028c7 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -8,7 +8,7 @@ - Mark Price is never updated during position resolution (0012-POSR-004) - Non-distressed traders who trade with the network because their open orders are hit during the close out trade have their positions settled correctly. (0012-POSR-005) - When a distressed party has a [staking account](./0013-ACCT-accounts.md) with the same currency as the settlement currency of the market where it's distressed the staking account is NOT used in margin search and liquidation. (0012-POSR-006) -- When a party is distressed at the point of leaving an auction it should get closed out immediately. (0012-POSR-007) +- When a party is distressed at the point of leaving an auction it should get closed out as soon as the market returns to continuous trading mode and all the parked orders (pegged and LP) get added back to the order book. (0012-POSR-008) ## Summary From 561cca15231a1c79a230896b238b778ac0484eb1 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 09:19:56 +0000 Subject: [PATCH 048/103] fix: adding bound on slippage part of margin --- protocol/0019-MCAL-margin_calculator.md | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index aed53b19e..617564a94 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -38,6 +38,7 @@ The calculator takes as inputs: - `mark price` - `scaling levels` defined in the risk parameters for a market - `quantitative risk factors` +- `market.maxSlippageFraction` which is an optional market creation parameter with a default of `0.1` i.e. `10%`. Note: `open_volume` may be fractional, depending on the `Position Decimal Places` specified in the [Market Framework](./0001-MKTF-market_framework.md). If this is the case, it may also be that order/positions sizes and open volume are stored as integers (i.e. int64). In this case, **care must be taken** to ensure that the actual fractional sizes are used when calculating margins. For example, if Position Decimals Places (PDP) = 3, then an open volume of 12345 is actually 12.345 (`12345 / 10^3`). This is important to avoid margins being off by orders of magnitude. It is notable because outside of margin calculations, and display to end users, the integer values can generally be used as-is. Note also that if PDP is negative e.g. PDP = -2 then an integer open volume of 12345 is actually 1234500. @@ -79,7 +80,13 @@ In this simple methodology, a linearised margin formula is used to return the ma with -`maintenance_margin_long_open_position = max(slippage_volume * slippage_per_unit, 0) + slippage_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, +``` +maintenance_margin_long_open_position + = max(min(slippage_volume * slippage_per_unit, slippage_volume * mark_price * market.maxSlippageFraction), 0) + + slippage_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] +``` + +and `maintenance_margin_long_open_orders = buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, @@ -104,11 +111,10 @@ where `exit_price` is the price that would be achieved on the order book if the trader's position size on market were exited. Specifically: - **Long positions** are exited by the system considering what the volume weighted price of **selling** the size of the open long position (not riskiest long position) on the order book (i.e. by selling to the bids on the order book). If there is no open long position, the slippage per unit is zero. -- **Short positions** are exited by the system considering what the volume weighted price of **buying** the size of the open short position (not riskiest short position) on the order book (i.e. by buying from the offers (asks) on the order book). If there is no open short position, the slippage per unit is zero. -Note, if there is insufficient order book volume for this `exit_price` to be calculated (per position), the `exit_price` is the price that would be achieved for as much of the volume that could theoretically be closed (in general we expect market protection mechanisms make this unlikely to occur). +- **Short positions** are exited by the system considering what the volume weighted price of **buying** the size of the open short position (not riskiest short position) on the order book (i.e. by buying from the offers (asks) on the order book). If there is no open short position, the slippage per unit is zero. -If there is zero order book volume on the relevant side of the order book to calculate the `exit_price`, the most recent calculation of the mark price, should be used instead. +If there is zero or insufficient order book volume on the relevant side of the order book to calculate the `exit_price`, then take `slippage_per_unit = +Infinity` which means that `min(slippage_volume * slippage_per_unit, slippage_volume * mark_price * market.maxSlippageFraction) = slippage_volume * mark_price * market.maxSlippageFraction` above. ### **Step 2** @@ -120,7 +126,13 @@ Else with -`maintenance_margin_short_open_position = max(abs(slippage_volume) * slippage_per_unit, 0) + abs(slippage_volume) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]` +``` +maintenance_margin_short_open_position + = max(min(abs(slippage_volume) * slippage_per_unit, abs(slippage_volume) * mark_price * market.maxSlippageFraction), 0) + + abs(slippage_volume) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] +``` + +and `maintenance_margin_short_open_orders = abs(sell_orders) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]`, From f104c75bc28710bb6e5964b5c678604fd537ff79 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 09:26:57 +0000 Subject: [PATCH 049/103] fix: adding bound on slippage part of margin - ACs --- protocol/0019-MCAL-margin_calculator.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 617564a94..c4490caa8 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -12,6 +12,17 @@ 8. A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-008) 9. For each market and each party which has either orders or positions on the market, the API provides the 4 margin levels. (0019-MCAL-009) 10. A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-010) +11. If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction = 0.5` and `RF shourt = 0.1` and order book is +``` +buy 1 @ 15 000 +buy 10 @ 14 900 +and +sell 1 @ 100 000 +sell 10 @ 100 100 +``` +then the maintenance margin for the party is `0.5 x 1 x 15 900 + 0.1 x 1 x 15 900 = 9 540`. +12. In the same situation as above, if `market.maxSlippageFraction = 100` (i.e. 10 000%) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. +13. If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. ## Summary From f7fdfaa859eec7ba2643fdfab0120ec69f2a6b96 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 09:46:45 +0000 Subject: [PATCH 050/103] chore: lint --- protocol/0019-MCAL-margin_calculator.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index c4490caa8..da02285c1 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -13,14 +13,16 @@ 9. For each market and each party which has either orders or positions on the market, the API provides the 4 margin levels. (0019-MCAL-009) 10. A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-010) 11. If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction = 0.5` and `RF shourt = 0.1` and order book is -``` + +```book buy 1 @ 15 000 buy 10 @ 14 900 and sell 1 @ 100 000 sell 10 @ 100 100 ``` -then the maintenance margin for the party is `0.5 x 1 x 15 900 + 0.1 x 1 x 15 900 = 9 540`. + +then the maintenance margin for the party is `0.5 x 1 x 15 900 + 0.1 x 1 x 15 900 = 9 540`. 12. In the same situation as above, if `market.maxSlippageFraction = 100` (i.e. 10 000%) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. 13. If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. @@ -49,7 +51,7 @@ The calculator takes as inputs: - `mark price` - `scaling levels` defined in the risk parameters for a market - `quantitative risk factors` -- `market.maxSlippageFraction` which is an optional market creation parameter with a default of `0.1` i.e. `10%`. +- `market.maxSlippageFraction` which is an optional market creation parameter with a default of `0.1` i.e. `10%`. Note: `open_volume` may be fractional, depending on the `Position Decimal Places` specified in the [Market Framework](./0001-MKTF-market_framework.md). If this is the case, it may also be that order/positions sizes and open volume are stored as integers (i.e. int64). In this case, **care must be taken** to ensure that the actual fractional sizes are used when calculating margins. For example, if Position Decimals Places (PDP) = 3, then an open volume of 12345 is actually 12.345 (`12345 / 10^3`). This is important to avoid margins being off by orders of magnitude. It is notable because outside of margin calculations, and display to end users, the integer values can generally be used as-is. Note also that if PDP is negative e.g. PDP = -2 then an integer open volume of 12345 is actually 1234500. @@ -91,7 +93,7 @@ In this simple methodology, a linearised margin formula is used to return the ma with -``` +```formula maintenance_margin_long_open_position = max(min(slippage_volume * slippage_per_unit, slippage_volume * mark_price * market.maxSlippageFraction), 0) + slippage_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] @@ -137,7 +139,7 @@ Else with -``` +```formula maintenance_margin_short_open_position = max(min(abs(slippage_volume) * slippage_per_unit, abs(slippage_volume) * mark_price * market.maxSlippageFraction), 0) + abs(slippage_volume) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] From f829d55662ee2205379fffdf70a35ac9a69b26b7 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 09:55:22 +0000 Subject: [PATCH 051/103] chore: format --- protocol/0019-MCAL-margin_calculator.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index da02285c1..242f74590 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -23,6 +23,7 @@ sell 10 @ 100 100 ``` then the maintenance margin for the party is `0.5 x 1 x 15 900 + 0.1 x 1 x 15 900 = 9 540`. + 12. In the same situation as above, if `market.maxSlippageFraction = 100` (i.e. 10 000%) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. 13. If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. From 172e54245b134e74264a487800ec1f416b36c68b Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 09:56:24 +0000 Subject: [PATCH 052/103] chore: add ac codes --- protocol/0019-MCAL-margin_calculator.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 242f74590..4f659909e 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -22,10 +22,10 @@ sell 1 @ 100 000 sell 10 @ 100 100 ``` -then the maintenance margin for the party is `0.5 x 1 x 15 900 + 0.1 x 1 x 15 900 = 9 540`. +then the maintenance margin for the party is `0.5 x 1 x 15 900 + 0.1 x 1 x 15 900 = 9 540`. (0019-MCAL-011) -12. In the same situation as above, if `market.maxSlippageFraction = 100` (i.e. 10 000%) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. -13. If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. +12. In the same situation as above, if `market.maxSlippageFraction = 100` (i.e. 10 000%) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. (0019-MCAL-012) +13. If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. (0019-MCAL-013) ## Summary From 1e672eebeab0b7ab62665ac9df873ebefae405ab Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 10:00:27 +0000 Subject: [PATCH 053/103] chore: lint --- protocol/0019-MCAL-margin_calculator.md | 37 ++++++++++++++++--------- 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 4f659909e..3106a8621 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -2,17 +2,27 @@ ## Acceptance Criteria -1. Get four margin levels for one or more parties (0019-MCAL-001) -2. Margin levels are correctly calculated against riskiest long and short positions (0019-MCAL-002) -3. Zero position and zero orders results in all zero margin levels (0019-MCAL-003) -4. If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to the initial mark price, as set by a market parameter. (0019-MCAL-004) -5. If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to the *volume weighted price of the order book bids*. (0019-MCAL-005) -6. If `riskiest short < 0` and there are no offers on the order book, the `exit price` is equal to the initial mark price, as set by a market parameter. (0019-MCAL-006) -7. If `riskiest short < 0 && 0 < *sum of absolute volume of order book offers* < riskiest short`, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-007) -8. A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-008) -9. For each market and each party which has either orders or positions on the market, the API provides the 4 margin levels. (0019-MCAL-009) -10. A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-010) -11. If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction = 0.5` and `RF shourt = 0.1` and order book is +- Get four margin levels for one or more parties (0019-MCAL-001) + +- Margin levels are correctly calculated against riskiest long and short positions (0019-MCAL-002) + +- Zero position and zero orders results in all zero margin levels (0019-MCAL-003) + +- If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to the initial mark price, as set by a market parameter. (0019-MCAL-004) + +- If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to the *volume weighted price of the order book bids*. (0019-MCAL-005) + +- If `riskiest short < 0` and there are no offers on the order book, the `exit price` is equal to the initial mark price, as set by a market parameter. (0019-MCAL-006) + +- If `riskiest short < 0 && 0 < *sum of absolute volume of order book offers* < riskiest short`, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-007) + +- A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-008) + +- For each market and each party which has either orders or positions on the market, the API provides the 4 margin levels. (0019-MCAL-009) + +- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-010) + +- If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction = 0.5` and `RF shourt = 0.1` and order book is ```book buy 1 @ 15 000 @@ -24,8 +34,9 @@ sell 10 @ 100 100 then the maintenance margin for the party is `0.5 x 1 x 15 900 + 0.1 x 1 x 15 900 = 9 540`. (0019-MCAL-011) -12. In the same situation as above, if `market.maxSlippageFraction = 100` (i.e. 10 000%) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. (0019-MCAL-012) -13. If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. (0019-MCAL-013) +- In the same situation as above, if `market.maxSlippageFraction = 100` (i.e. 10 000%) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. (0019-MCAL-012) + +- If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. (0019-MCAL-013) ## Summary From b437b3113dfe5aae12bb1b0e256abc56c4fc69e5 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 10:19:38 +0000 Subject: [PATCH 054/103] feat: make it nonlinear --- protocol/0019-MCAL-margin_calculator.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 3106a8621..412a3a993 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -22,7 +22,7 @@ - A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-010) -- If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction = 0.5` and `RF shourt = 0.1` and order book is +- If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction[1] = 0.25`, `market.maxSlippageFraction[2] = 0.25` and `RF shourt = 0.1` and order book is ```book buy 1 @ 15 000 @@ -32,9 +32,9 @@ sell 1 @ 100 000 sell 10 @ 100 100 ``` -then the maintenance margin for the party is `0.5 x 1 x 15 900 + 0.1 x 1 x 15 900 = 9 540`. (0019-MCAL-011) +then the maintenance margin for the party is `15 900 x (0.25 x 1 + 0.25 x 1 x 1) + 0.1 x 1 x 15 900 = 9 540`. (0019-MCAL-011) -- In the same situation as above, if `market.maxSlippageFraction = 100` (i.e. 10 000%) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. (0019-MCAL-012) +- In the same situation as above, if `market.maxSlippageFraction[1] = 100`, `market.maxSlippageFraction[2] = 100` (i.e. 10 000% for both) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. (0019-MCAL-012) - If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. (0019-MCAL-013) @@ -63,7 +63,7 @@ The calculator takes as inputs: - `mark price` - `scaling levels` defined in the risk parameters for a market - `quantitative risk factors` -- `market.maxSlippageFraction` which is an optional market creation parameter with a default of `0.1` i.e. `10%`. +- `market.maxSlippageFactors` which is a 2 dimensional decimal optional market creation parameter with a default of `[0.1,0.1]` i.e. `[10%,10]` with the following validation: `0 <= market.maxSlippageFactors[1] <= 1 000 000` and `0 <= market.maxSlippageFactors[2] <= 1 000 000`. Note: `open_volume` may be fractional, depending on the `Position Decimal Places` specified in the [Market Framework](./0001-MKTF-market_framework.md). If this is the case, it may also be that order/positions sizes and open volume are stored as integers (i.e. int64). In this case, **care must be taken** to ensure that the actual fractional sizes are used when calculating margins. For example, if Position Decimals Places (PDP) = 3, then an open volume of 12345 is actually 12.345 (`12345 / 10^3`). This is important to avoid margins being off by orders of magnitude. It is notable because outside of margin calculations, and display to end users, the integer values can generally be used as-is. Note also that if PDP is negative e.g. PDP = -2 then an integer open volume of 12345 is actually 1234500. @@ -107,7 +107,7 @@ with ```formula maintenance_margin_long_open_position - = max(min(slippage_volume * slippage_per_unit, slippage_volume * mark_price * market.maxSlippageFraction), 0) + = max(min(slippage_volume * slippage_per_unit, mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])), 0) + slippage_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] ``` @@ -153,7 +153,7 @@ with ```formula maintenance_margin_short_open_position - = max(min(abs(slippage_volume) * slippage_per_unit, abs(slippage_volume) * mark_price * market.maxSlippageFraction), 0) + = max(min(abs(slippage_volume) * slippage_per_unit, mark_price * (abs(slippage_volume) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) + abs(slippage_volume) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] ``` From 1051d505a6dae50d1fb3a3c252348672196c2940 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 10:21:40 +0000 Subject: [PATCH 055/103] fix: remove obsolete ac --- protocol/0019-MCAL-margin_calculator.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 412a3a993..dadcf81b1 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -12,8 +12,6 @@ - If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to the *volume weighted price of the order book bids*. (0019-MCAL-005) -- If `riskiest short < 0` and there are no offers on the order book, the `exit price` is equal to the initial mark price, as set by a market parameter. (0019-MCAL-006) - - If `riskiest short < 0 && 0 < *sum of absolute volume of order book offers* < riskiest short`, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-007) - A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-008) From 173003e8eb47d6f531f0c21d5bdb4bf5ca482bf1 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 11:13:20 +0000 Subject: [PATCH 056/103] fix: typo --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index dadcf81b1..6e7dbbef1 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -61,7 +61,7 @@ The calculator takes as inputs: - `mark price` - `scaling levels` defined in the risk parameters for a market - `quantitative risk factors` -- `market.maxSlippageFactors` which is a 2 dimensional decimal optional market creation parameter with a default of `[0.1,0.1]` i.e. `[10%,10]` with the following validation: `0 <= market.maxSlippageFactors[1] <= 1 000 000` and `0 <= market.maxSlippageFactors[2] <= 1 000 000`. +- `market.maxSlippageFactors` which is a 2 dimensional decimal optional market creation parameter with a default of `[0.1,0.1]` i.e. `[10%,10%]` with the following validation: `0 <= market.maxSlippageFactors[1] <= 1 000 000` and `0 <= market.maxSlippageFactors[2] <= 1 000 000`. Note: `open_volume` may be fractional, depending on the `Position Decimal Places` specified in the [Market Framework](./0001-MKTF-market_framework.md). If this is the case, it may also be that order/positions sizes and open volume are stored as integers (i.e. int64). In this case, **care must be taken** to ensure that the actual fractional sizes are used when calculating margins. For example, if Position Decimals Places (PDP) = 3, then an open volume of 12345 is actually 12.345 (`12345 / 10^3`). This is important to avoid margins being off by orders of magnitude. It is notable because outside of margin calculations, and display to end users, the integer values can generally be used as-is. Note also that if PDP is negative e.g. PDP = -2 then an integer open volume of 12345 is actually 1234500. From 154314f7f9588497f41510f0804c8d45a8c115da Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 8 Feb 2023 13:58:12 +0000 Subject: [PATCH 057/103] fix: typo from comments Co-authored-by: Tom --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 6e7dbbef1..a3b7eba98 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -20,7 +20,7 @@ - A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-010) -- If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction[1] = 0.25`, `market.maxSlippageFraction[2] = 0.25` and `RF shourt = 0.1` and order book is +- If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction[1] = 0.25`, `market.maxSlippageFraction[2] = 0.25` and `RF short = 0.1` and order book is ```book buy 1 @ 15 000 From 7ea2498ea6ba8903613506c7947f279536b79f5a Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 8 Feb 2023 13:59:56 +0000 Subject: [PATCH 058/103] fix: code block in list formatting (#1584) --- protocol/0019-MCAL-margin_calculator.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index a3b7eba98..58566e4e2 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -22,15 +22,15 @@ - If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction[1] = 0.25`, `market.maxSlippageFraction[2] = 0.25` and `RF short = 0.1` and order book is -```book -buy 1 @ 15 000 -buy 10 @ 14 900 -and -sell 1 @ 100 000 -sell 10 @ 100 100 -``` - -then the maintenance margin for the party is `15 900 x (0.25 x 1 + 0.25 x 1 x 1) + 0.1 x 1 x 15 900 = 9 540`. (0019-MCAL-011) + ```book + buy 1 @ 15 000 + buy 10 @ 14 900 + and + sell 1 @ 100 000 + sell 10 @ 100 100 + ``` + + then the maintenance margin for the party is `15 900 x (0.25 x 1 + 0.25 x 1 x 1) + 0.1 x 1 x 15 900 = 9 540`. (0019-MCAL-011) - In the same situation as above, if `market.maxSlippageFraction[1] = 100`, `market.maxSlippageFraction[2] = 100` (i.e. 10 000% for both) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. (0019-MCAL-012) From 00af44244dfeb55496779da127666cc099802efe Mon Sep 17 00:00:00 2001 From: MuthuVega Date: Thu, 9 Feb 2023 16:10:04 +0000 Subject: [PATCH 059/103] chore: Remove untestable acceptance criteria --- protocol/0076-DANO-data-node.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 027bb220f..3a90a2361 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -188,6 +188,5 @@ It must be possible to add to the data node APIs that return the result of calcu 1. The DataNode must be able to handle brief network outages and disconnects from the vega node (0076-DANO-015) 1. The validator node will only accept requests for event bus subscriptions. All other API subscription requests will be invalid. (0076-DANO-016) 1. The event bus stream is available from validators, non validators and the DataNode (0076-DANO-017) -1. All events that are emitted on the full unfiltered event stream are processed by the DataNode (no data is lost) (0076-DANO-018) 1. If a DataNode loses connection to a Vega node if will attempt to reconnect and if the cached data received from the Vega node is enough to continue working it can resume being a DataNode. (0076-DANO-019) 1. The DataNode must provide its current block height and vega time on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021) From a1fa7a1b52828928e16385be8deec4967ee42c0f Mon Sep 17 00:00:00 2001 From: Philip Scott Date: Fri, 10 Feb 2023 09:51:05 +0000 Subject: [PATCH 060/103] feat: add rate limit spec --- protocol/0076-DANO-data-node.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 3a90a2361..6149edcb8 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -183,6 +183,21 @@ It must be possible to add to the data node APIs that return the result of calcu 2. Standard nodes should retain data in accordance with the configured data retention policy (0076-DANO-027) 3. Archival nodes should retain all data from the height at which they joined the network (0076-DANO-028) +### API Request Rate Limiting + +1. Datanode should provide an optional mechanism for limiting the average number of requests per second over on its API +2. That rate should be specified in the datanode configuration file +3. A client may, over a short period of time, make requests at a greater frequency than the limit as long as the average rate over a longer period of time is not exceeded. +4. The extent to which clients may of 'burst' requests should also be capped and specified in the datanode configuration file +5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator +6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them +7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata +8. If the client continues to make requests that generate error responses due to rate limiting, eventually the client should banned +9. The ban denies all access to the API for a configurable length of time +10. For that time, any requests will receive an API appropriate error response indicating that they are banned +11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests +12. Where one API makes use of another (e.g. GraphQL making use of gRPC), rate limits should be enforced only once, on the side that faces the client + ### General Acceptance 1. The DataNode must be able to handle brief network outages and disconnects from the vega node (0076-DANO-015) From eb959ff22dd2879a2f83df8758c1c3901c1ff6ae Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Mon, 13 Feb 2023 10:42:28 +0000 Subject: [PATCH 061/103] Update 0057-TRAN-transfers.md (#1588) * Update 0057-TRAN-transfers.md * Update 0057-TRAN-transfers.md --- protocol/0057-TRAN-transfers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index b327a8015..e9096d209 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -276,7 +276,7 @@ A user's recurring transfer to a reward account does not occur if there are no p If the network parameter `transfer.minTransferFeeFactor` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-062) -If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied from the next Epoch on, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-060) +If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. In the case of a decrease, existing recurring transfers are not cancelled. (0057-TRAN-060) If the network parameter `transfer.minTransferQuantumMultiple` is modified, this modification is applied immediately on, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-061) From 8ce66ce4e0f7f838df2b3aa776f7b7415a83cc8e Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 13 Feb 2023 11:48:36 +0000 Subject: [PATCH 062/103] chore: add AC codes --- protocol/0076-DANO-data-node.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 6149edcb8..e36d08fcb 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -187,16 +187,16 @@ It must be possible to add to the data node APIs that return the result of calcu 1. Datanode should provide an optional mechanism for limiting the average number of requests per second over on its API 2. That rate should be specified in the datanode configuration file -3. A client may, over a short period of time, make requests at a greater frequency than the limit as long as the average rate over a longer period of time is not exceeded. -4. The extent to which clients may of 'burst' requests should also be capped and specified in the datanode configuration file -5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator -6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them -7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata -8. If the client continues to make requests that generate error responses due to rate limiting, eventually the client should banned -9. The ban denies all access to the API for a configurable length of time -10. For that time, any requests will receive an API appropriate error response indicating that they are banned -11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests -12. Where one API makes use of another (e.g. GraphQL making use of gRPC), rate limits should be enforced only once, on the side that faces the client +3. A client may, over a short period of time, make requests at a greater frequency than the limit as long as the average rate over a longer period of time is not exceeded. (0076-DANO-029) +4. The extent to which clients may of 'burst' requests should also be capped and specified in the datanode configuration file (0076-DANO-030) +5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator (0076-DANO-031) +6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them (0076-DANO-032) +7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata (0076-DANO-033) +8. If the client continues to make requests that generate error responses due to rate limiting, eventually the client should banned (0076-DANO-034) +9. The ban denies all access to the API for a configurable length of time (0076-DANO-035) +10. For that time, any requests will receive an API appropriate error response indicating that they are banned (0076-DANO-036) +11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests (0076-DANO-037) +12. Where one API makes use of another (e.g. GraphQL making use of gRPC), rate limits should be enforced only once, on the side that faces the client (0076-DANO-038) ### General Acceptance From 5a6c2f159edf88467be3f294045fc219425ac5ba Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Tue, 14 Feb 2023 12:34:42 +0000 Subject: [PATCH 063/103] Update 0057-TRAN-transfers.md (#1590) --- protocol/0057-TRAN-transfers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index e9096d209..52bf0480e 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -273,7 +273,7 @@ A user's recurring transfer to a reward account does not occur if there are no p - In the second epoch, 2 * 10^6 trading occurs, and at the end of the epoch the transfer to the reward account occurs - At the end of the third epoch, no transfer occurs -If the network parameter `transfer.minTransferFeeFactor` is modified, this modification is applied +If the network parameter `transfer.fee.factor` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-062) If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. In the case of a decrease, existing recurring transfers are not cancelled. (0057-TRAN-060) From 328939b9edcf45d1a25a1e884ee5f6dd261123fa Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Wed, 15 Feb 2023 02:22:35 -0800 Subject: [PATCH 064/103] Update 0069-VCBS-validators_chosen_by_stake.md Added Acs for IssueSignature --- .../0069-VCBS-validators_chosen_by_stake.md | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index f76fb16f7..e04482317 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -543,3 +543,35 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. 1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) + +### Re-Issuing Signature Bundles by non Validators + +1. Submit two IssueSignature requests from the same Vega-Key (but for different bundles) for the same block. Verify that only one of the requests is executed, but both pass consensus. (Note: This AC may need replacement with the new Tendermint API). Repeat this test for in the next epoch and verify that the relult is the same. +(0069-VCBS-069) + +1. Submit two IssueSignature requests from the same Vega Key (but for different bundles) so that they are proposed for different blocks. Verify that the second one does not make it through consensus, but gets rejected earlier. Repeat this rest in the next epoch and verify that the result is the same. +(0069-VCBS-070) + +1. Submit two IssueSignature requests for the same bundle from different Vega keys, in a way that they end up in the same block. Verify that both get executed. +(0069-VCBS-071) + +1. Submit two IssueSignature requests for the same bundle from different Vwga keys in different blocks. Verify that both get executed. +(0069-VCBS-072) + +1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 IssueSignature requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one IssueSignature request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. +(0069-VCBS-073) + +1. Issue a request from a Vega key with a wrong singature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. +(0069-VCBS-074) + +1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. +(0069-VCBS-075) + + + + + + + + + From 4a36b9e1ae72e2bfb888c3959f4c231973532408 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Thu, 16 Feb 2023 02:07:12 -0800 Subject: [PATCH 065/103] Update 0069-VCBS-validators_chosen_by_stake.md --- protocol/0069-VCBS-validators_chosen_by_stake.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index e04482317..5ca99fafc 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -561,7 +561,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). 1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 IssueSignature requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one IssueSignature request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. (0069-VCBS-073) -1. Issue a request from a Vega key with a wrong singature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. +1. Issue a request from a Vega key with a wrong signature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. (0069-VCBS-074) 1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. @@ -570,8 +570,3 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - - - - - From c2ab3df6555bc1702f859edbd19e188882171f2e Mon Sep 17 00:00:00 2001 From: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Date: Thu, 16 Feb 2023 17:50:27 +0000 Subject: [PATCH 066/103] fix: Expand acceptance criteria to make them clear for 0011-NP-CLIE-client-interaction (#1585) * fix: Expand acceptance criteria to make them clear * chore: Fix formatting * fix: Address review comments --------- Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> --- .../0011-NP-CLIE-client-interaction-tests.md | 37 ++++++++++--------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index cf3e95385..39d3512cb 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -7,25 +7,28 @@ This specification contains a set of tests/acceptance criteria that clients (wal ## Acceptance criteria 1. The parameter `spam.pow.numberofTxPerBlock` is decreased. Verify that: - - The new parameter is communicated to and adapted by the wallet, i.e., if a user has too many transactions according to the new parameter, the wallet does not submit transactions with a too low PoW difficulty (either by submitting a PoW of higher difficulty, or by submitting the transactions later). (0011-NP-CLIE-001) + - The new parameter is communicated to and adapted/used by the wallet, i.e., if a user has too many transactions according to the new parameter, the wallet does not submit the excess transactions and returns an appropriate error message OR reprocesses the transactions. (0011-NP-CLIE-001) + - The new parameter is communicated to and adapted/used by the wallet, i.e., if a user has too many transactions according to the new parameter, AND if the parameter `spam.pow.increaseDifficulty` is set to `1`, the wallet submits the excess transactions by submitting a PoW of higher difficulty. (0011-NP-CLIE-002) 1. The parameter `spam.pow.numberOfTxPerBlock` is increased. Verify that: - - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This means that a wallet that has had a number of transactions exceeding the previous limit, but not the current one, does not increase the PoW difficulty or delay the transactions (0011-NP-CLIE-002) + - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. + - This means that a wallet, for each transaction tied to a block with a height lower than the one in which the change happened will honour the previous limit. (0011-NP-CLIE-003) + - This means that a wallet, for each transaction tied to a block with a height higher than the one in which the change happened will honour the new limit. (0011-NP-CLIE-004) 1. The parameter `spam.pow.difficulty` is increased. Verify that: - - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-003) + - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-005) 1. The parameter `spam.pow.difficulty` is decreased. Verify that - - This is communicated to the wallet, and the wallet uses these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-004) + - This is communicated to the wallet, and the wallet uses these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-006) 1. The parameter `spam.pow.increaseDifficulty` is changed from `0` to `1`. Verify that - - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-005) + - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-007) 1. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` PoWs tied to a given block before using another. If this results in none being available the transaction should not be sent. (0011-NP-CLIE-006) -1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10. Send significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` (about 100 is a good number) transactions at the same time, and keep sending transactions at a rate of more than 20 in the time a block is processed for at least 10 more blocks. Assure that does not get banned, and either sends all transactions eventually, or returns a meaningful error. (0011-NP-CLIE-007) -1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and get banned.(0011-NP-CLIE-008) -1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least 10 minutes. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and get banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-009) -1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same issue at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-010) -1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-011) -1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-012) -1. Submit one vote less than (`SpamProtectionMaxVotes` = 3) , i.e., 2 votes in the same epoch. Once all votes are processed, submit 2 new votes at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new simultaneous votes on that issue in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-013) -1. Submit one proposal less than (`SpamProtectionMaxProposals` = 3) , i.e., 2 proposals in an epoch from an account that has more than `SpamProtectionMinTokensForProposal` tokens). Once all proposals are processed, submit 2 new proposals at once (still in the same epoch). Verify that the wallet does not allow more than 1 proposal to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new proposals at the same time in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-014) -1. Submit one delegation less than (`SpamProtectionMaxDelegations` = 390) , i.e., 389 delegations in the same epoch from an account that has more than `SpamProtectionMinTokensForDelegation` tokens). Once all delegations are processed, submit 100 new delegations at once (still in the same epoch). Verify that the wallet does not allow more than 1 delegation to be submitted simultaneously, i.e., cause the account to get blocked. Submit 100 new delegations at once in the next epoch and verify that the wallet allows it (and the account does not get blocked).(0011-NP-CLIE-015) -1. Create a key with sufficient tokens to be allowed to submit proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. Submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the account never gets banned, and that the client never crashed. (0011-NP-CLIE-016) -1. Create 20 keys with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. For all keys (within their respective wallets), submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that no account ever gets banned, and that the clients never crash. (0011-NP-CLIE-017) + - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` number of transactions when tied to a block higher than the one in which the change happened. In case of excess transactions (i.e. greater than `spam.pow.numberofTxPerBlock`), transactions should not be sent and returns an appropriate error message OR reprocesses the transactions. (0011-NP-CLIE-008) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10. Send significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` (about 100 is a good number) transactions at the same time, and keep sending transactions at a rate of more than 20 in the time a block is processed for at least 10 more blocks. Assure that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error. (0011-NP-CLIE-009) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client reprocesses the transactions or removes the transactions to not exceed the transactions-per-block limit and hence not get banned.(0011-NP-CLIE-010) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least 10 minutes. Assure that the client reprocesses the transactions or removes the transactions to not exceed the transactions-per-block limit and hence not get banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-011) +1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same proposal at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-012) +1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-013) +1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-014) +1. Submit one vote less than (`SpamProtectionMaxVotes` = 3) , i.e., 2 votes in the same epoch. Once all votes are processed, submit 2 new votes at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., does not cause the account to get blocked. Submit 2 new simultaneous votes on that proposal in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-015) +1. Submit one proposal less than (`SpamProtectionMaxProposals` = 3) , i.e., 2 proposals in an epoch from an account that has more than `SpamProtectionMinTokensForProposal` tokens). Once all proposals are processed, submit 2 new proposals at once (still in the same epoch). Verify that the wallet does not allow more than 1 proposal to be submitted simultaneously, i.e., does not cause the account to get blocked. Submit 2 new proposals at the same time in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-016) +1. Submit one delegation less than (`SpamProtectionMaxDelegations` = 10) , i.e., 9 delegations in the same epoch from an account that has more than `SpamProtectionMinTokensForDelegation` tokens). Once all delegations are processed, submit 5 new delegations at once (still in the same epoch). Verify that the wallet does not allow more than 1 delegation to be submitted simultaneously, i.e., does not cause the account to get blocked. Submit 10 new delegations at once in the next epoch and verify that the wallet allows it (and the account does not get blocked).(0011-NP-CLIE-017) +1. Create a key with sufficient tokens to be allowed to submit proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. Submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the wallet returns an error for the excess transactions OR reprocesses the transactions. Verify the account never gets banned, and that the client never crashed. (0011-NP-CLIE-018) +1. Create 20 keys with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. For all keys (within their respective wallets), submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the wallet returns an error for the excess transactions OR reprocesses the transactions. Verify that no account ever gets banned, and that the clients never crash. (0011-NP-CLIE-019) From 4bf559e1950a0c8800fa7e468a621efff4a4fb5e Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Fri, 17 Feb 2023 16:48:38 +0000 Subject: [PATCH 067/103] feat: Add new PLUP AC for state-sync in protocol upgrade. --- protocol/0075-PLUP-protocol_upgrades.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index 00614548b..0fd167b83 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -156,6 +156,7 @@ For the purposes of protocol upgrade each validator that participates in consens - (0075-PLUP-023) Post a validator becoming a consensus-participating validator they should be immediately allowed to propose an upgrade and be included in the overall total count - (0075-PLUP-024) Ensure that required majority is not met when enough validators join between validator proposals and target block, i.e: In a network with 5 validators, required majority is two thirds, 4 vote to upgrade, 2 more validators join before upgrade block and do not vote. Upgrade does not take place. - (0075-PLUP-025) Node starting from snapshot which has a proposal at a given block, ensure during replay when the block height is reached a new version is loaded and also post load an upgrade takes place at target block. +- (0075-PLUP-045) Arrange a network where n nodes are required for consensus, and at least n+1 nodes in the network. Schedule a protocol upgrade where n-1 nodes automatically start on the new version after upgrade, i.e: No consensus after upgrade. Start the (n+1)th node and consensus is achieved. For the nth node, clear vega and tm, and restart the node using state-sync at the upgrade block height. All nodes produce blocks. ## LNL Checkpoints From 77323e437d3bcfaff76adfdc2a51f1313ad22c01 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 20 Feb 2023 15:55:15 +0000 Subject: [PATCH 068/103] feat: add closeout API --- protocol/0007-POSN-non_core_positions_api.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/protocol/0007-POSN-non_core_positions_api.md b/protocol/0007-POSN-non_core_positions_api.md index 43fab6c21..cca62ed61 100644 --- a/protocol/0007-POSN-non_core_positions_api.md +++ b/protocol/0007-POSN-non_core_positions_api.md @@ -12,6 +12,9 @@ The Position API provides access to net position per party per market. Specifica - Uses VW methodology to adjust the realised PnL resulting from any trade that caused volume to have been closed out. (0007-POSN-006) - Stores all traders’ realised PnL for every trade that caused volume to have been closed out. (0007-POSN-007) - Stores all traders' total realised PnL. (0007-POSN-008) +- Stores a status field for all the traders, the status field will be set to ORDERS_CLOSED if a trader was distressed based on the margin requirements for their worst possible long/short, but their margin balance was sufficient to maintain their open position (i.e. their active orders will be removed from the book, after which the party was no longer distressed) (0007-POSN-015) +- The status field will be set to CLOSED_OUT if the party was closed out (0007-POSN-016) + ## Summary @@ -58,6 +61,9 @@ The API is expected to expose: - When a party has a position which gets (partially) closed-out, the unrealised PnL should reflect the change of position while the realised PnL reflect the closed-out position (0007-POSN-011) - During settlement, all the parties' position should become 0, unrealised PnL should become 0 and realised PnL should update based on settlement price (0007-POSN-012) - If a party is subject to loss socialisation (its MTM gains get scaled down) the loss amount (forgone profit) should get recorded in realised PnL(0007-POSN-013) +- If a party is subject to loss socialisation, the profits that could not be paid out due to loss socialisation is logged as "loss socialisation amount" which is accessible from API (0007-POSN-014) + +realised/unrealised PnL will remain the same, but during MTM, if we have to perform loss socialisation, we now keep track of the profits that could not be paid out. Loss soc. amount is the total amount that the party missed out on ## Definitions / glossary From 525437a9527324c7de14c794ca5584d23d0a301c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 20 Feb 2023 16:01:16 +0000 Subject: [PATCH 069/103] chore: tidy up --- protocol/0007-POSN-non_core_positions_api.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0007-POSN-non_core_positions_api.md b/protocol/0007-POSN-non_core_positions_api.md index cca62ed61..48b9d1dac 100644 --- a/protocol/0007-POSN-non_core_positions_api.md +++ b/protocol/0007-POSN-non_core_positions_api.md @@ -63,8 +63,6 @@ The API is expected to expose: - If a party is subject to loss socialisation (its MTM gains get scaled down) the loss amount (forgone profit) should get recorded in realised PnL(0007-POSN-013) - If a party is subject to loss socialisation, the profits that could not be paid out due to loss socialisation is logged as "loss socialisation amount" which is accessible from API (0007-POSN-014) -realised/unrealised PnL will remain the same, but during MTM, if we have to perform loss socialisation, we now keep track of the profits that could not be paid out. Loss soc. amount is the total amount that the party missed out on - ## Definitions / glossary | Term | Definition | From fd5c2a2cab6ad2fce4d80e22dbcdd07a85af9c8d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 20 Feb 2023 16:03:44 +0000 Subject: [PATCH 070/103] chore: remove blank line --- protocol/0007-POSN-non_core_positions_api.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0007-POSN-non_core_positions_api.md b/protocol/0007-POSN-non_core_positions_api.md index 48b9d1dac..a5fa0f244 100644 --- a/protocol/0007-POSN-non_core_positions_api.md +++ b/protocol/0007-POSN-non_core_positions_api.md @@ -15,7 +15,6 @@ The Position API provides access to net position per party per market. Specifica - Stores a status field for all the traders, the status field will be set to ORDERS_CLOSED if a trader was distressed based on the margin requirements for their worst possible long/short, but their margin balance was sufficient to maintain their open position (i.e. their active orders will be removed from the book, after which the party was no longer distressed) (0007-POSN-015) - The status field will be set to CLOSED_OUT if the party was closed out (0007-POSN-016) - ## Summary ## Reference-level explanation From 06c64e9c5e08833ded5bdeb76ac87af0ad5db900 Mon Sep 17 00:00:00 2001 From: Philip Scott Date: Mon, 20 Feb 2023 16:59:18 +0000 Subject: [PATCH 071/103] chore: by more specific about when a client should be banned --- protocol/0076-DANO-data-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index e36d08fcb..af5e19252 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -192,7 +192,7 @@ It must be possible to add to the data node APIs that return the result of calcu 5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator (0076-DANO-031) 6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them (0076-DANO-032) 7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata (0076-DANO-033) -8. If the client continues to make requests that generate error responses due to rate limiting, eventually the client should banned (0076-DANO-034) +8. If the rate of denied (due to rate limiting) requests subsequently exceed the same maximum rate/burst parameters the client should be banned (0076-DANO-034) 9. The ban denies all access to the API for a configurable length of time (0076-DANO-035) 10. For that time, any requests will receive an API appropriate error response indicating that they are banned (0076-DANO-036) 11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests (0076-DANO-037) From 9fa4e6d0acd6ffcd3e58bdd8a786c0dbf54fb989 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 22 Feb 2023 12:32:38 +0000 Subject: [PATCH 072/103] feat: update formula line 140 --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 58566e4e2..66af89cd7 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -137,7 +137,7 @@ where - **Short positions** are exited by the system considering what the volume weighted price of **buying** the size of the open short position (not riskiest short position) on the order book (i.e. by buying from the offers (asks) on the order book). If there is no open short position, the slippage per unit is zero. -If there is zero or insufficient order book volume on the relevant side of the order book to calculate the `exit_price`, then take `slippage_per_unit = +Infinity` which means that `min(slippage_volume * slippage_per_unit, slippage_volume * mark_price * market.maxSlippageFraction) = slippage_volume * mark_price * market.maxSlippageFraction` above. +If there is zero or insufficient order book volume on the relevant side of the order book to calculate the `exit_price`, then take `slippage_per_unit = +Infinity` which means that `min(slippage_volume * slippage_per_unit, mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])) = mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])` above. ### **Step 2** From 09922301b9ecdf694263a6688e7b837f6bce066a Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Thu, 23 Feb 2023 17:19:25 +0000 Subject: [PATCH 073/103] fix: Add extra cases for various things that might be affected by validators joining and leaving. --- protocol/0069-VCBS-validators_chosen_by_stake.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index f76fb16f7..41e8f6511 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -487,6 +487,9 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that at the end of the Epoch, the Ersatz validators get 40% of the reward that the validators get (in total) - Set the `rewardFactor` to 0.32832979375934745648654893643856748734895749785943759843759437549837534987593483498 - Verify that all validators round the value of reward for the Ersatz validators to the same value. +1. Ensure multisig threshold is set to '999' (require all signatures). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt a withdrawal. (0069-VCBS-069) +1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070) +1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the smart contract). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the same contract. (0069-VCBS-072) ### Announce Node @@ -543,3 +546,4 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. 1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) +1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071) \ No newline at end of file From c1a3e168ba7250c9d61124929a374669f3b8fdf6 Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Fri, 24 Feb 2023 13:35:11 +0000 Subject: [PATCH 074/103] fix: Review comments for new ACs. --- protocol/0069-VCBS-validators_chosen_by_stake.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 41e8f6511..2acc71dfc 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -487,9 +487,9 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that at the end of the Epoch, the Ersatz validators get 40% of the reward that the validators get (in total) - Set the `rewardFactor` to 0.32832979375934745648654893643856748734895749785943759843759437549837534987593483498 - Verify that all validators round the value of reward for the Ersatz validators to the same value. -1. Ensure multisig threshold is set to '999' (require all signatures). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt a withdrawal. (0069-VCBS-069) +1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069) 1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070) -1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the smart contract). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the same contract. (0069-VCBS-072) +1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072) ### Announce Node From 53638b7ac251ed49655e810c3408d43f5820eb4d Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Fri, 24 Feb 2023 15:16:31 +0000 Subject: [PATCH 075/103] fix: Satisfy the linter. --- protocol/0069-VCBS-validators_chosen_by_stake.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 2acc71dfc..66f84c8ce 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -546,4 +546,4 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. 1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) -1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071) \ No newline at end of file +1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071) From 8df7df8e315361e43cc54bb41d477816427d600d Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 24 Feb 2023 14:26:01 +0000 Subject: [PATCH 076/103] refactor: add slippage to orders --- protocol/0019-MCAL-margin_calculator.md | 47 ++++++------------------- 1 file changed, 10 insertions(+), 37 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 66af89cd7..54ac87513 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -99,35 +99,17 @@ If `riskiest long == 0` then `maintenance_margin_long = 0`. In this simple methodology, a linearised margin formula is used to return the maintenance margin, using risk factors returned by the [quantitative model](./0018-RSKM-quant_risk_models.ipynb). -`maintenance_margin_long = maintenance_margin_long_open_position + maintenance_margin_long_open_orders` - with ```formula -maintenance_margin_long_open_position - = max(min(slippage_volume * slippage_per_unit, mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])), 0) - + slippage_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] +maintenance_margin_long + = max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + + max(open_volume, 0) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, ``` -and - -`maintenance_margin_long_open_orders = buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, - where -`slippage_volume = max( open_volume, 0 )`, - -and - -if `open_volume > 0` then - -`slippage_per_unit = Product.value(market_observable) - Product.value(exit_price)`, - -else `slippage_per_unit = 0`. - -where - -`market_observable` = `settlement_mark_price` if in continuous trading and `indicative_uncrossing_price` if in an auction +`market_observable` = `settlement_mark_price` if in continuous trading, refer to [auction subsection](#margin-calculation-for-auctions) for details of the auction behaviour. `settlement_mark_price` refers to the mark price most recently utilised in [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md). If no previous mark to market settlement has occurred, the initial mark price, as defined by a market parameter, should be used. @@ -145,24 +127,16 @@ If `riskiest short == 0` then `maintenance_margin_short = 0`. Else -`maintenance_margin_short = maintenance_margin_short_open_position + maintenance_margin_short_open_orders` - -with ```formula -maintenance_margin_short_open_position - = max(min(abs(slippage_volume) * slippage_per_unit, mark_price * (abs(slippage_volume) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) - + abs(slippage_volume) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] +maintenance_margin_short + = max(min(abs(riskiest short) * slippage_per_unit, mark_price * (abs(riskiest short) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) + + abs(min( open_volume, 0 )) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] + abs(sell_orders) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]` ``` -and - -`maintenance_margin_short_open_orders = abs(sell_orders) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]`, where meanings of terms in Step 1 apply except for: -`slippage_volume = min( open_volume, 0 )`, - `slippage_per_unit = -1 * (Product.value(market_observable) - Product.value(exit_price) )` ### **Step 3** @@ -173,16 +147,15 @@ where meanings of terms in Step 1 apply except for: We are assuming that: -- `indicative_uncrossing_price` is *not* the mark price, so no mark-to-market transfers happen (update mark-to-market spec) - mark price never changes during an auction, so it's the last mark price from before auction, - during an auction we never release money from the margin account, however we top-it-up as required, - no closeouts during auctions Use the same calculation as above with the following re-defined: -- in `slippage_per_unit` we use `indicative_uncrossing_price` instead of `exit_price`. If there is no `indicative_uncrossing_price` then use `slippage_per_unit = 0`. -- For the open position part of the margin use the mark price. -- For the orders part of the margin: if mark price is not available (as is the case during the opening auction) use `market_observable = indicative_uncrossing_price`. If there is no current `indicative_uncrossing_price`, then use the volume weighted average price of the party's long / short orders. +- For the orders part of the margin: use `market_observable` = volume weighted average price of the party's long / short orders. + +Note that because the order book is empty during auctions we will always end up with the slippage value implied by the the slippage cap. ## Scaling other margin levels From 1a1f26ff7d9dcd619165982df247939b3d08a02d Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 24 Feb 2023 15:08:03 +0000 Subject: [PATCH 077/103] refactor: update examples --- protocol/0019-MCAL-margin_calculator.md | 39 ++++++++++--------------- 1 file changed, 15 insertions(+), 24 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 54ac87513..fae2e6374 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -8,7 +8,7 @@ - Zero position and zero orders results in all zero margin levels (0019-MCAL-003) -- If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to the initial mark price, as set by a market parameter. (0019-MCAL-004) +- If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to initity and hence the slippage cap is used as the slippage component of the margin calculation. (0019-MCAL-014) - If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to the *volume weighted price of the order book bids*. (0019-MCAL-005) @@ -194,10 +194,13 @@ bids: [ {volume: 7, price: $108} ] +market.maxSlippageFraction[1] = 0.25 +market.maxSlippageFraction[2] = 0.001 + risk_factor_short = 0.11 risk_factor_long = 0.1 -last_trade = $144 +mark_price = $144 search_level_scaling_factor = 1.1 initial_margin_scaling_factor = 1.2 @@ -207,21 +210,20 @@ Trader1_futures_position = {open_volume: 10, buys: 4, sells: 8} getMargins(Trader1_position) -riskiest long = max( open_volume + buy_orders, 0 ) = max( 10 + 4, 0 ) = 14 -riskiest short = min( open_volume + sell_orders, 0 ) = min( 10 - 8, 0 ) = 0 +riskiest_long = max( open_volume + buy_orders, 0 ) = max( 10 + 4, 0 ) = 14 +riskiest_short = min( open_volume + sell_orders, 0 ) = min( 10 - 8, 0 ) = 0 # Step 1 ## exit price considers what selling the open position (10) on the order book would achieve. -slippage_per_unit = Product.value(previous_mark_price) - Product.value(exit_price) = Product.value($144) - Product.value((1*120 + 4*110 + 5*108)/10) = 144 - 110 = 34 - -slippage_volume = max( open_volume, 0 ) = max ( 10, 0 ) = 10 +slippage_per_unit = Product.value(market_observable) - Product.value(exit_price) = Product.value($144) - Product.value((1*120 + 4*110 + 5*108)/10) = 144 - 110 = 34 +maintenance_margin_long =max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + + max(open_volume, 0 ) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] -maintenance_margin_long = max(slippage_volume * slippage_per_unit, 0) + slippage_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] -= max(10 * 34, 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 541.6 += max(min(14 * 34, 144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 677.6 # Step 2 @@ -229,13 +231,13 @@ Since riskiest short == 0 then maintenance_margin_short = 0 # Step 3 -maintenance_margin = max ( 541.6, 0) = 541.6 +maintenance_margin = max ( 677.6, 0) = 677.6 # Step 4 -collateral_release_level = 541.6 * collateral_release_scaling_factor = 541.6 * 1.1 -initial_margin = 541.6 * initial_margin_scaling_factor = 541.6 * 1.2 -search_level = 541.6 * search_level_scaling_factor = 541.6 * 1.3 +collateral_release_level = 677.6 * collateral_release_scaling_factor = 677.6 * 1.1 +initial_margin = 677.6 * initial_margin_scaling_factor = 677.6 * 1.2 +search_level = 677.6 * search_level_scaling_factor = 677.6 * 1.3 ``` @@ -256,9 +258,6 @@ riskiest long: 2 riskiest short: -1 -slippage volume long: 1 - -slippage volume short: 0 #### *case-2* @@ -266,20 +265,12 @@ riskiest long: 1 riskiest short: -1 -slippage volume long: 0 - -slippage volume short: -1 - #### *case-3* riskiest long: 1 riskiest short: -1 -slippage volume long: 1 - -slippage volume short: 0 - ## SCENARIOS Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) From c782c46e07dcddeb952b7825e76e074e052f68ab Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 24 Feb 2023 15:11:22 +0000 Subject: [PATCH 078/103] chore: fix linter issues --- protocol/0019-MCAL-margin_calculator.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index fae2e6374..cc4133a20 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -127,14 +127,12 @@ If `riskiest short == 0` then `maintenance_margin_short = 0`. Else - ```formula maintenance_margin_short = max(min(abs(riskiest short) * slippage_per_unit, mark_price * (abs(riskiest short) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) + abs(min( open_volume, 0 )) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] + abs(sell_orders) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]` ``` - where meanings of terms in Step 1 apply except for: `slippage_per_unit = -1 * (Product.value(market_observable) - Product.value(exit_price) )` @@ -258,7 +256,6 @@ riskiest long: 2 riskiest short: -1 - #### *case-2* riskiest long: 1 From 348902e3964c57809ddab88c53eb1c0eec9dcbf6 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 24 Feb 2023 15:15:24 +0000 Subject: [PATCH 079/103] refactor: fix typo --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index cc4133a20..7a86b6b54 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -8,7 +8,7 @@ - Zero position and zero orders results in all zero margin levels (0019-MCAL-003) -- If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to initity and hence the slippage cap is used as the slippage component of the margin calculation. (0019-MCAL-014) +- If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to infinity and hence the slippage cap is used as the slippage component of the margin calculation. (0019-MCAL-014) - If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to the *volume weighted price of the order book bids*. (0019-MCAL-005) From bded26377351885c7d7d2a239844c9c86cc0f154 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 24 Feb 2023 15:40:12 +0000 Subject: [PATCH 080/103] refactor: formlise margin level treatment --- protocol/0010-MARG-margin_orchestration.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/protocol/0010-MARG-margin_orchestration.md b/protocol/0010-MARG-margin_orchestration.md index 79acb0ee1..e2129a8eb 100644 --- a/protocol/0010-MARG-margin_orchestration.md +++ b/protocol/0010-MARG-margin_orchestration.md @@ -77,6 +77,11 @@ The protocol compares these levels to the balance in the trader's margin account | greater than _collateral release level_ | Collateral release | Collateral release | greater than _collateral search level_ and less than _initial margin_ | no action | No financial risk to network +When posting a new order the initial margin for the overall position including the new order is calculated and order is only allowed to go ahead if party has enough funds to bring their margin account balance to that figure. An exception to this is when a party has an open position and tries to reduce it, but cannot afford the new margin. Then orders from the opposite side (short orders for a long position, long orders for a short position) are accepted as follows: + +- limit order: accept order when sum sizes of all the party's order's for that side of the book including the one being posted is less than or equal to the absolute open volume that a party has, +- market order: accept order as long as its size is less than or equal to the absolute open volume that a party has. + #### Collateral search When a trader's balance in their margin account (for a market) is less than their position’s collateral search level the protocol will attempt to transfer sufficient collateral from the trader’s main collateral account to top up their margin account to the level of the _initial margin_. From d370414db5a996315d10fda14947f6bcb5e9af0e Mon Sep 17 00:00:00 2001 From: Witold Date: Sat, 25 Feb 2023 14:42:29 +0100 Subject: [PATCH 081/103] refactor: amend/add ACs --- protocol/0019-MCAL-margin_calculator.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 7a86b6b54..3d61678ba 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -10,9 +10,13 @@ - If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to infinity and hence the slippage cap is used as the slippage component of the margin calculation. (0019-MCAL-014) -- If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to the *volume weighted price of the order book bids*. (0019-MCAL-005) +- If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to infinity. (0019-MCAL-015) -- If `riskiest short < 0 && 0 < *sum of absolute volume of order book offers* < riskiest short`, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-007) +- If `riskiest short < 0 && 0 < *sum of absolute volume of order book offers* < abs(riskiest short)`, the `exit price` is equal to infinity. (0019-MCAL-016) + +- If `riskiest long > 0 && riskiest long < *sum of volume of order book bids*`, the `exit price` is equal to the *volume weighted price of the order book bids* with cumulative volume equal to the riskiest long, starting from best bid. (0019-MCAL-017) + +- If `riskiest short < 0 && 0 abs(riskiest short) == *sum of absolute volume of order book offers* < `, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-018) - A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-008) From 6ba9f9433ae5d60bd0c0f40c622f69f976e236ba Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Mon, 27 Feb 2023 22:54:08 +0000 Subject: [PATCH 082/103] Update 0042-LIQF-setting_fees_and_rewarding_lps.md (#1598) * Update 0042-LIQF-setting_fees_and_rewarding_lps.md * fix: linting errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport --- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 5c8395d70..cf6f7ae81 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -271,6 +271,19 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e - If a market has `market.liquidity.providers.fee.distributionTimeStep` set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) - All liquidity providers with `average fraction of liquidity provided by committed LP > 0` in the market receive a greater than zero amount of liquidity fee. The only exception is if a non-zero amount is rounded to zero due to integer representation. (0042-LIQF-015) +### LP JOINING AND LEAVING MARKETS + +- An LP joining a market that is below the target stake with a higher fee bid than the current fee: their fee is used (0042-LIQF-019) +- An LP joining a market that is below the target stake with a lower fee bid than the current fee: fee doesn't change (0042-LIQF-020) +- An LP joining a market that is above the target stake with a sufficiently large commitment to push ALL higher bids above the target stake and a lower fee bid than the current fee: their fee is used (0042-LIQF-021) +- An LP joining a market that is above the target stake with a commitment not large enough to push any higher bids above the target stake, and a lower fee bid than the current fee: the fee doesn't change (0042-LIQF-022) +- An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a lower fee bid than the current fee: the fee changes to the other lower bid (0042-LIQF-023) +- An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a higher fee bid than the current fee: the fee doesn't change (0042-LIQF-024) +- An LP leaves a market that is above target stake when their fee bid is currently being used: fee changes to fee bid by the LP who takes their place in the bidding order (0042-LIQF-025) +- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size changes the LP that meets the target stake: fee changes to fee bid by the LP that is now at the place in the bid order to provide the target stake (0042-LIQF-026) +- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size doesn't the LP that meets the target stake: fee doesn't change (0042-LIQF-027) +- An LP leaves a market that is above target stake when their fee bid is higher than the one currently being used: fee doesn't change (0042-LIQF-028) + ### API - Equity-like share of each active LP can be obtained via the API (0042-LIQF-016) From e274bdc9a076bcc071a740c8e74d902d1d927af9 Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 28 Feb 2023 09:04:54 +0000 Subject: [PATCH 083/103] fix: linting error --- protocol/0019-MCAL-margin_calculator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 3d61678ba..74efc324b 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -16,7 +16,7 @@ - If `riskiest long > 0 && riskiest long < *sum of volume of order book bids*`, the `exit price` is equal to the *volume weighted price of the order book bids* with cumulative volume equal to the riskiest long, starting from best bid. (0019-MCAL-017) -- If `riskiest short < 0 && 0 abs(riskiest short) == *sum of absolute volume of order book offers* < `, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-018) +- If `riskiest short < 0 && 0 abs(riskiest short) == *sum of absolute volume of order book offers* <`, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-018) - A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-008) From 348c7f10611ee0456de2bf6c939002bd4eafbd23 Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 28 Feb 2023 09:16:22 +0000 Subject: [PATCH 084/103] fix: MD lint and spelling --- protocol/0069-VCBS-validators_chosen_by_stake.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 5ca99fafc..d1e278d8f 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -546,19 +546,19 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). ### Re-Issuing Signature Bundles by non Validators -1. Submit two IssueSignature requests from the same Vega-Key (but for different bundles) for the same block. Verify that only one of the requests is executed, but both pass consensus. (Note: This AC may need replacement with the new Tendermint API). Repeat this test for in the next epoch and verify that the relult is the same. +1. Submit two `IssueSignature` requests from the same Vega-Key (but for different bundles) for the same block. Verify that only one of the requests is executed, but both pass consensus. (Note: This AC may need replacement with the new Tendermint API). Repeat this test for in the next epoch and verify that the result is the same. (0069-VCBS-069) -1. Submit two IssueSignature requests from the same Vega Key (but for different bundles) so that they are proposed for different blocks. Verify that the second one does not make it through consensus, but gets rejected earlier. Repeat this rest in the next epoch and verify that the result is the same. +1. Submit two `IssueSignature` requests from the same Vega Key (but for different bundles) so that they are proposed for different blocks. Verify that the second one does not make it through consensus, but gets rejected earlier. Repeat this rest in the next epoch and verify that the result is the same. (0069-VCBS-070) -1. Submit two IssueSignature requests for the same bundle from different Vega keys, in a way that they end up in the same block. Verify that both get executed. +1. Submit two `IssueSignature` requests for the same bundle from different Vega keys, in a way that they end up in the same block. Verify that both get executed. (0069-VCBS-071) -1. Submit two IssueSignature requests for the same bundle from different Vwga keys in different blocks. Verify that both get executed. +1. Submit two `IssueSignature` requests for the same bundle from different Vega keys in different blocks. Verify that both get executed. (0069-VCBS-072) -1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 IssueSignature requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one IssueSignature request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. +1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 `IssueSignature` requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one `IssueSignature` request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. (0069-VCBS-073) 1. Issue a request from a Vega key with a wrong signature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. @@ -566,7 +566,3 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). 1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. (0069-VCBS-075) - - - - From 5c6d57191dc7106999cd5879489b36a6347c1b94 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Thu, 2 Mar 2023 09:25:57 +0000 Subject: [PATCH 085/103] Update 0069-VCBS-validators_chosen_by_stake.md (#1604) * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * fix: MD linting and spelling errors --------- Co-authored-by: gordsport --- .../0069-VCBS-validators_chosen_by_stake.md | 46 +++++++++++++------ 1 file changed, 32 insertions(+), 14 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 66f84c8ce..a3024f03d 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -397,22 +397,26 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Self-delegate to all of them. - Announce 2 new nodes but self-delegate only to one of them. - Verify that, after 1000 blocks and on the following epoch, only the validator to which we self-delegated got promoted and we now have 4 Tendermint validators and 1 pending validator. -1. Change `ownstake` requirement (0069-VCBS-053) - - Network with 5 tendermint validators and 7 ersatz validators + +### `Ownstake` Scenarios + +1. `Ownstake` scenario1 (0069-VCBS-053) + - Network with 3 tendermint validators and 7 ersatz validators - In the same epoch, change the network parameter `reward.staking.delegation.minimumValidatorStake` in a way that 3 tendermint validators and 3 ersatz validators drop below the `ownstake` requirement, and change the delegation so that 4 (not affected) Ersatz validators have a higher score than two (not affected) Validators. Also, give one of the Ersatz validators with insufficient `ownstake` the highest stake (delegated) of all Ersatz validators. - At the end of the epoch all validators with insufficient own stake will get a ranking score of 0. - No ersatz validator with insufficient stake will get unlisted as ersatz validator - The 3 tendermint validators would be swapped with the top 3 ersatz validators over the following 3 epochs - Also verify that the ersatz validator with the insufficient own but the most delegated stake has a ranking score of 0 and doesn't get promoted. - No validator with stake attached to them is ever completely removed -1. (Alternative until we can build a large enough network for above AC ) (0069-VCBS-059) - 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, +1. `Ownstake` scenario2 (0069-VCBS-073) +Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` - the pending validator has sufficient `ownstake` - - Verify that the the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. + - Verify that the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. +1. `Ownstake` scenario3 (0069-VCBS-074) 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -420,6 +424,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. +1. `Ownstake` scenario4 (0069-VCBS-075) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -427,6 +432,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatz validator that had insufficient `ownstake`. +1. `Ownstake` scenario5 (0069-VCBS-076) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -435,14 +441,21 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Now reduce the `ownstake` of both ersatz validators and one real validator below the `ownstake` requirement; verify that both ersatz validators are not demoted to pending, and that the tendermint validator is not demoted to ersatz (i.e., tendermint validators are not demoted if there is no appropriate ersatz). - Reduce the `ownstake` of both ersatz validators to 0. Verify that both ersatz validators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). - Reduce the `ownstake` of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient `ownstake` is not. + +1. `Ownstake` scenario6 (0069-VCBS-077) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators + +1. `Ownstake` scenario7 (0069-VCBS-078) -Verify that 2 validators are replaced, one in each epoch 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, and higher stake than the validators - Verify that one validator is replaced the following epoch, one in the epoch after + +### Ersatz Rewards + 1. Ersatz validator reward (0069-VCBS-061) - Setup a network with 5 validators with the following distribution of delegation: - 10%, 10%, 10%, 10%. 60% of the total delegation of tendermint validators @@ -452,6 +465,19 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - At the end of the epoch expect the validator with 60% of the stake to be swapped as a tendermint validator for one of the ersatz validators. - Restart the validator, run until the end of the epoch - Verify that this validator is paid reward as ersatz validator and that their stake score under reward is anti-whaled + +1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057) + - Setup a network with 5 Tendermint validators, 3 Ersatz Validators, `network.validators.ersatz.rewardfactor` = 0 + - Verify that at the end of the Epoch, the Ersatz Validators get no reward + - Increase the `rewardFactor` to 0.5 + - Verify that at the end of the Epoch, the Ersatz validators get half the reward that the validators get (in total) + - Decrease the `rewardFactor` to 0.4 + - Verify that at the end of the Epoch, the Ersatz validators get 40% of the reward that the validators get (in total) + - Set the `rewardFactor` to 0.32832979375934745648654893643856748734895749785943759843759437549837534987593483498 + - Verify that all validators round the value of reward for the Ersatz validators to the same value. + +### Slot Adjustments + 1. Number of slots decreased (0069-VCBS-052): - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - Decrease the number of tendermint validators to 3. @@ -478,15 +504,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that all Validators round it the same way, and that there are no Ersatz validators - Set the factor to 3.00000000000000000000000000000000000000001 and run the network with just one tendermint (consensus) validator. - Verify that all Validators round it the same way, and that there are three Ersatz validators -1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057) - - Setup a network with 5 Tendermint validators, 3 Ersatz Validators, `network.validators.ersatz.rewardfactor` = 0 - - Verify that at the end of the Epoch, the Ersatz Validators get no reward - - Increase the `rewardFactor` to 0.5 - - Verify that at the end of the Epoch, the Ersatz validators get half the reward that the validators get (in total) - - Decrease the `rewardFactor` to 0.4 - - Verify that at the end of the Epoch, the Ersatz validators get 40% of the reward that the validators get (in total) - - Set the `rewardFactor` to 0.32832979375934745648654893643856748734895749785943759843759437549837534987593483498 - - Verify that all validators round the value of reward for the Ersatz validators to the same value. + 1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069) 1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070) 1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072) From 0bb3cb36b166496f283f96f9d25cf2ec7aaaf764 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Thu, 2 Mar 2023 01:57:16 -0800 Subject: [PATCH 086/103] Update 0069-VCBS-validators_chosen_by_stake.md (#1596) * Update 0069-VCBS-validators_chosen_by_stake.md * fix: spelling errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport --- protocol/0069-VCBS-validators_chosen_by_stake.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index a3024f03d..a7033bf3f 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -33,7 +33,7 @@ Note that we only do this check once per epoch so at most one validator can be c The same way, if there are free slots for ersatz validators and nodes that have submitted the transaction to join and satisfy all joining conditions, they are added as ersatz validators in the next round. -If a node that submitted the transaction to join and satisfies all other conditions and has a higher score than the lowest scoring ersatz validator (scaled up by the incumbent factor), then (assuming it did not just become a Tendermint validator), it becomes an ersatz validator and the lowest scoring ersatz validator is demoted to pending validator. The 'transaction to join' of a validator demoted this way remains active until the delegated stake drops below the required minimum +If a node that submitted the transaction to join and satisfies all other conditions and has a higher score than the lowest scoring ersatz validator (scaled up by the incumbent factor), then (assuming it did not just become a Tendermint validator), it becomes an ersatz validator and the lowest scoring ersatz validator is demoted to pending (also referred to as candidate) validator. The 'transaction to join' of a validator demoted this way remains active until the delegated stake drops below the required minimum As both these checks are done between epochs, it is possible for a validator to be demoted first from a consensus forming (Tendermint) validator to an ersatz validator, and then from an ersatz validator to a pending validator. @@ -107,9 +107,9 @@ In the case where a node is removed due reduced delegation, or due to not meetin Note that this could become obsolete if a future version of the protocol implements threshold signatures or another method that allows all validators to approve Ethereum actions. -## Ersatz validators +## Ersatz/Standby validators -In addition to the normal validators, there is an additional set of Ersatz validators as defined by the corresponding network parameter. These are validators that do not contribute to the chain, but are on standby to jump in if a normal validator drops off. The network will have +In addition to the normal validators, there is an additional set of Ersatz validators (also referred to as Standby Validators) as defined by the corresponding network parameter. These are validators that do not contribute to the chain, but are on standby to jump in if a normal validator drops off. The network will have `n' := ceil(network.validators.multipleOfTendermintValidators x network.validators.tendermint.number)` From 240e05b402d847d3ba00eb5d912968068eac62ff Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Thu, 2 Mar 2023 11:58:56 +0000 Subject: [PATCH 087/103] fix: More validator join/leave test cases involving checkpoints. (#1601) * fix: More validator join/leave test cases involving checkpoints. * fix: spelling error * fix: Update AC codes to not be duplicates. --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0069-VCBS-validators_chosen_by_stake.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index a7033bf3f..de4003ffa 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -506,7 +506,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Verify that all Validators round it the same way, and that there are three Ersatz validators 1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069) -1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070) +1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070). Restart from checkpoint ((0069-VCBS-080)), all validator nodes are still correct. 1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072) ### Announce Node @@ -543,6 +543,14 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Restart the network starting only 3 of the validators. - Restore from the checkpoint. - Verify the network is not able to produce blocks. +1. Checkpoints store validator changes (0069-VCBS-079): + - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). + - Stop and relegate one of the original validators (v1) such that v6 is promoted to tendermint validator, and v7 is promoted to ersatz. + - Restart v1 and announce to pending. + - Take a checkpoint. + - Restart the network + - Verify that v2-v6 are tendermint validators, v7 is ersatz and v1 is pending. + - Verify that all stakes and delegations are correct for each node. ### Multisig update From 0c3c7c4c0ade6f4df0ac5b4fc0bbcce56d5cc7aa Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 2 Mar 2023 20:46:38 +0000 Subject: [PATCH 088/103] feat: update make file and add approabtion to CI (#1605) * feat: update make file and add approabtion to CI * chore: add more checks and fix errors * fix: checkout PR branch * fix: get branch * fix: approbation errors --- .github/workflows/quality_check.yml | 15 +++++++++++++++ makefile | 6 +++--- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 4 ++-- protocol/0069-VCBS-validators_chosen_by_stake.md | 14 +++++++------- 4 files changed, 27 insertions(+), 12 deletions(-) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index ed4d24487..d90c2e85a 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -51,3 +51,18 @@ jobs: files: . config_file: .github/workflows/config/markdownlint.json ignore_path: .github/workflows/config/markdownlintignore + + checkcodes: + name: "Approbation" + runs-on: ubuntu-latest + steps: + - name: "Check out" + uses: actions/checkout@v3 + + - name: "Run Check AC codes" + run: | + npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + + - name: "Run Check file names" + run: | + npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" diff --git a/makefile b/makefile index 47682edc2..1cafcf49f 100644 --- a/makefile +++ b/makefile @@ -7,13 +7,13 @@ all: spellcheck markdownlint names codes references links clean .PHONY: names names: @$(MAKE) clone-sources - npx @vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" # Count how many Acceptance Criteria each specification has .PHONY: codes codes: @$(MAKE) clone-sources - npx @vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" TEMP=./.build .PHONY:clone-sources @@ -44,7 +44,7 @@ clone-sources: references: @$(MAKE) clone-sources - cd $(TEMP); npx -y @vegaprotocol/approbation@latest check-references --specs="../*protocol*/*.{md,ipynb}" --tests="./**/*.{js,py,feature}" --categories="../protocol/categories.json" --show-branches --show-mystery --verbose --show-files + cd $(TEMP); npx -y github:vegaprotocol/approbation@latest check-references --specs="../*protocol*/*.{md,ipynb}" --tests="./**/*.{js,py,feature}" --categories="../protocol/categories.json" --show-branches --show-mystery --verbose --show-files # Imperfect, but useful - hence not included in ALL .PHONY: links diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index cf6f7ae81..ded7ad547 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -275,8 +275,8 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e - An LP joining a market that is below the target stake with a higher fee bid than the current fee: their fee is used (0042-LIQF-019) - An LP joining a market that is below the target stake with a lower fee bid than the current fee: fee doesn't change (0042-LIQF-020) -- An LP joining a market that is above the target stake with a sufficiently large commitment to push ALL higher bids above the target stake and a lower fee bid than the current fee: their fee is used (0042-LIQF-021) -- An LP joining a market that is above the target stake with a commitment not large enough to push any higher bids above the target stake, and a lower fee bid than the current fee: the fee doesn't change (0042-LIQF-022) +- An LP joining a market that is above the target stake with a sufficiently large commitment to push ALL higher bids above the target stake and a lower fee bid than the current fee: their fee is used (0042-LIQF-029) +- An LP joining a market that is above the target stake with a commitment not large enough to push any higher bids above the target stake, and a lower fee bid than the current fee: the fee doesn't change (0042-LIQF-030) - An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a lower fee bid than the current fee: the fee changes to the other lower bid (0042-LIQF-023) - An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a higher fee bid than the current fee: the fee doesn't change (0042-LIQF-024) - An LP leaves a market that is above target stake when their fee bid is currently being used: fee changes to fee bid by the LP who takes their place in the bidding order (0042-LIQF-025) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 2326256c8..475fb212a 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -577,22 +577,22 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Re-Issuing Signature Bundles by non Validators 1. Submit two `IssueSignature` requests from the same Vega-Key (but for different bundles) for the same block. Verify that only one of the requests is executed, but both pass consensus. (Note: This AC may need replacement with the new Tendermint API). Repeat this test for in the next epoch and verify that the result is the same. -(0069-VCBS-069) +(0069-VCBS-081) 1. Submit two `IssueSignature` requests from the same Vega Key (but for different bundles) so that they are proposed for different blocks. Verify that the second one does not make it through consensus, but gets rejected earlier. Repeat this rest in the next epoch and verify that the result is the same. -(0069-VCBS-070) +(0069-VCBS-082) 1. Submit two `IssueSignature` requests for the same bundle from different Vega keys, in a way that they end up in the same block. Verify that both get executed. -(0069-VCBS-071) +(0069-VCBS-083) 1. Submit two `IssueSignature` requests for the same bundle from different Vega keys in different blocks. Verify that both get executed. -(0069-VCBS-072) +(0069-VCBS-084) 1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 `IssueSignature` requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one `IssueSignature` request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. -(0069-VCBS-073) +(0069-VCBS-085) 1. Issue a request from a Vega key with a wrong signature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. -(0069-VCBS-074) +(0069-VCBS-086) 1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. -(0069-VCBS-075) +(0069-VCBS-087) From 11c2ca20be976e634e76d64c7655445e14c8294f Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Mon, 6 Mar 2023 11:15:36 -0800 Subject: [PATCH 089/103] Update 0011-NP-CLIE-client-interaction-tests.md Made the wallet-overlaid tests easier to implement. --- non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index 39d3512cb..634633c1d 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -21,9 +21,8 @@ This specification contains a set of tests/acceptance criteria that clients (wal - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-007) 1. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` number of transactions when tied to a block higher than the one in which the change happened. In case of excess transactions (i.e. greater than `spam.pow.numberofTxPerBlock`), transactions should not be sent and returns an appropriate error message OR reprocesses the transactions. (0011-NP-CLIE-008) -1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10. Send significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` (about 100 is a good number) transactions at the same time, and keep sending transactions at a rate of more than 20 in the time a block is processed for at least 10 more blocks. Assure that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error. (0011-NP-CLIE-009) -1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client reprocesses the transactions or removes the transactions to not exceed the transactions-per-block limit and hence not get banned.(0011-NP-CLIE-010) -1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least 10 minutes. Assure that the client reprocesses the transactions or removes the transactions to not exceed the transactions-per-block limit and hence not get banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-011) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, SpamPoWNumberOfTxPerBlock to 2, and spam.pow.increaseDifficulty to 0. Halt the chain to stop new blocks from being generated. Send 400 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks' through the wallet. After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 100 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain. (0011-NP-CLIE-009) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, SpamPoWNumberOfTxPerBlock to 2, and spam.pow.increaseDifficulty to 1. Halt the chain to stop new blocks from being generated. Send 100 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks' through the wallet. Verify that the wallet does not become unresponsive (this might happen if it tries to perform a proof of work with massively increased difficulty). After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 20 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain.(0011-NP-CLIE-010) 1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same proposal at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-012) 1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-013) 1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-014) From 7a788164d817724a10ed6c99dffb70edfa0ba10a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 7 Mar 2023 09:51:26 +0000 Subject: [PATCH 090/103] feat: fix typo in 0042 --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index ded7ad547..4a7d927fb 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -281,7 +281,7 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e - An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a higher fee bid than the current fee: the fee doesn't change (0042-LIQF-024) - An LP leaves a market that is above target stake when their fee bid is currently being used: fee changes to fee bid by the LP who takes their place in the bidding order (0042-LIQF-025) - An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size changes the LP that meets the target stake: fee changes to fee bid by the LP that is now at the place in the bid order to provide the target stake (0042-LIQF-026) -- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size doesn't the LP that meets the target stake: fee doesn't change (0042-LIQF-027) +- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size doesn't change the LP that meets the target stake: fee doesn't change (0042-LIQF-027) - An LP leaves a market that is above target stake when their fee bid is higher than the one currently being used: fee doesn't change (0042-LIQF-028) ### API From e354d8a02235099a9bf3227d64ae1fe06498cf32 Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 7 Mar 2023 12:20:12 +0000 Subject: [PATCH 091/103] fix: spelling errors --- non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index 634633c1d..d06d66443 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -21,8 +21,8 @@ This specification contains a set of tests/acceptance criteria that clients (wal - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-007) 1. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` number of transactions when tied to a block higher than the one in which the change happened. In case of excess transactions (i.e. greater than `spam.pow.numberofTxPerBlock`), transactions should not be sent and returns an appropriate error message OR reprocesses the transactions. (0011-NP-CLIE-008) -1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, SpamPoWNumberOfTxPerBlock to 2, and spam.pow.increaseDifficulty to 0. Halt the chain to stop new blocks from being generated. Send 400 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks' through the wallet. After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 100 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain. (0011-NP-CLIE-009) -1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, SpamPoWNumberOfTxPerBlock to 2, and spam.pow.increaseDifficulty to 1. Halt the chain to stop new blocks from being generated. Send 100 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks' through the wallet. Verify that the wallet does not become unresponsive (this might happen if it tries to perform a proof of work with massively increased difficulty). After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 20 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain.(0011-NP-CLIE-010) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, `SpamPoWNumberOfTxPerBlock` to 2, and `spam.pow.increaseDifficulty` to 0. Halt the chain to stop new blocks from being generated. Send 400 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` through the wallet. After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 100 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain. (0011-NP-CLIE-009) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, `SpamPoWNumberOfTxPerBlock` to 2, and `spam.pow.increaseDifficulty` to 1. Halt the chain to stop new blocks from being generated. Send 100 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` through the wallet. Verify that the wallet does not become unresponsive (this might happen if it tries to perform a proof of work with massively increased difficulty). After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 20 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain.(0011-NP-CLIE-010) 1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same proposal at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-012) 1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-013) 1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-014) From 91df5df23e075c7f1c595749797c1b644349602c Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Wed, 8 Mar 2023 11:02:19 +0000 Subject: [PATCH 092/103] Update 0004-AMND-amends.md (#1606) * Update 0004-AMND-amends.md * Update 0004-AMND-amends.md * Update 0004-AMND-amends.md * Update 0004-AMND-amends.md * Update 0004-AMND-amends.md --- protocol/0004-AMND-amends.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index a6f999cd9..6a162c945 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -22,6 +22,7 @@ - Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017) - Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018) - Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019) +- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029) For a party with no position on a given market: From add89fa80d88e0afff8741e47e4c504be1fc80d5 Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Wed, 8 Mar 2023 11:08:10 +0000 Subject: [PATCH 093/103] fix: Relabel existing PLUP mainnet case to reflect the fact that it is only valid once PLUP-compatible versions are deployed. Add a new case to cover what is worth testing now, namely, that our best guess is that mainnet data is upgradable in future. (#1603) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0075-PLUP-protocol_upgrades.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index 0fd167b83..3054b8612 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -183,7 +183,8 @@ For the purposes of protocol upgrade each validator that participates in consens ### Mainnet -- (0075-PLUP-033) Check that we can protocol upgrade a system which has been restarted from mainnet snapshots with current mainnet version, to next intended release version. +- (0075-COSMICELEVATOR-033) Check that we can protocol upgrade a system which has been restarted from mainnet snapshots with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. +- (0075-PLUP-046) Check that we can protocol upgrade a system which has been restarted from latest mainnet checkpoint with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. ### Overwriting transactions From b723d50939f74ea77942de5e5cd37fb0e544a4f0 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Thu, 9 Mar 2023 05:00:46 -0800 Subject: [PATCH 094/103] Update 0069-VCBS-validators_chosen_by_stake.md --- protocol/0069-VCBS-validators_chosen_by_stake.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 475fb212a..34c448bbe 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -446,6 +446,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators + - Verify that one validator is replaced the following epoch, one in the epoch after 1. `Ownstake` scenario7 (0069-VCBS-078) -Verify that 2 validators are replaced, one in each epoch From b1d4b45009e538465ef65714f97658a083e32125 Mon Sep 17 00:00:00 2001 From: MuthuVega Date: Thu, 9 Mar 2023 22:16:38 +0530 Subject: [PATCH 095/103] chore: Amend acceptance criteria to cosmic elevator --- non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index d06d66443..522726ed9 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -21,8 +21,8 @@ This specification contains a set of tests/acceptance criteria that clients (wal - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-007) 1. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` number of transactions when tied to a block higher than the one in which the change happened. In case of excess transactions (i.e. greater than `spam.pow.numberofTxPerBlock`), transactions should not be sent and returns an appropriate error message OR reprocesses the transactions. (0011-NP-CLIE-008) -1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, `SpamPoWNumberOfTxPerBlock` to 2, and `spam.pow.increaseDifficulty` to 0. Halt the chain to stop new blocks from being generated. Send 400 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` through the wallet. After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 100 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain. (0011-NP-CLIE-009) -1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, `SpamPoWNumberOfTxPerBlock` to 2, and `spam.pow.increaseDifficulty` to 1. Halt the chain to stop new blocks from being generated. Send 100 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` through the wallet. Verify that the wallet does not become unresponsive (this might happen if it tries to perform a proof of work with massively increased difficulty). After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 20 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain.(0011-NP-CLIE-010) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, `SpamPoWNumberOfTxPerBlock` to 2, and `spam.pow.increaseDifficulty` to 0. Halt the chain to stop new blocks from being generated. Send 400 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` through the wallet. After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 100 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain. (0011-COSMICELEVATOR-009) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10, `SpamPoWNumberOfTxPerBlock` to 2, and `spam.pow.increaseDifficulty` to 1. Halt the chain to stop new blocks from being generated. Send 100 transactions (i.e., significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` through the wallet. Verify that the wallet does not become unresponsive (this might happen if it tries to perform a proof of work with massively increased difficulty). After that, allow the chain to resume, and keep sending transactions at a rate of more than 4 in the time a block is processed for at least 20 more blocks. Verify that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error for transactions that are not sent through the chain.(0011-COSMICELEVATOR-010) 1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same proposal at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-012) 1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-013) 1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-014) From e8ab6d6f773353f7f6729e01554db9c328eb54b4 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Fri, 10 Mar 2023 02:48:10 -0800 Subject: [PATCH 096/103] Create multis user update --- protocol/XXXX-MSUP-Multisig_Update.md | 73 +++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 protocol/XXXX-MSUP-Multisig_Update.md diff --git a/protocol/XXXX-MSUP-Multisig_Update.md b/protocol/XXXX-MSUP-Multisig_Update.md new file mode 100644 index 000000000..359fc3fed --- /dev/null +++ b/protocol/XXXX-MSUP-Multisig_Update.md @@ -0,0 +1,73 @@ +Purpose: + +In case control of the bridge is lost (e.g., too many validators cease operating at the same time), allow for a tokenholder vote to restore the functionality + +Properties +- Only unvested tokens are allowed to vote +- We have a decaying voting threshold - the required votes to change the validator set is lowered if the bridge isn't used. +- tokens need to be locked to be allowed to vote, and then cannot be sold unless unlocked (which invalidates the vote) + + +Variables + max_threshold: The maximum threshold required for a valid vote + min_threshold: The minimum threshold required for a valid vote + decay_rate: how fast the + + +Bridge contract: + +last_update(): Allows another contract to query the last Ethereum block when + the multisig was used successfully +replace_hash(h) Allows the voting contract (and that contract only) to replace + the hash value defining the validator set + + +Voting Contract + +Data structures: +- voting table: an array (hash, votes) defining all the votes a hash got +- user_votes: an array (key, hash1, hash2, ...) defining all the hashes a key voted for +- user_weight an array (key, number_of_tokens) defining how many tokens a user locked. + +lock_tokens: Allows an Ethereum key to lock all itstokens into the voting contract, provided it has tokens, and they are not already locked to either the vesting contract or the voting contract. This initialises + + If the key already has tokens locked, abort + set user_votes (key) to [] + set user_weight(key) to the amount of tokens locked + +unlock_tokens: Allows a key to unlock its tokens. This clears all its votes. + If the key has no tokens locked, abort + for each hash in user_votes(key), substract user_)weight(key) + if a hash now has 0 votes, delete that hash + delete user_votes(key) + delete user_weight(key) + +vote(hash): Allows a key to vote for a specific hash. What this does: + - Verify that that key hasn't voted for that hash before. If it has, abort. + - If the hash doesn't exist in the voting table, create + voting_table (hash, votes), where votes = 0 + - Set voting_table (hash) += user_weight(key) + - Add hash to user_votes(key). + +Evaluate(hash) + - if votes(hash,votes) > max( min_threshold, max_threshold- (current_block - bridge.last_update())*decay_rate, then + call bridge.replace_hash(hash) + set voting_table to [] + set user_votes to [] + + + + + +Comment: Keys cannot lock a part of their tokens; allowing that would cause code complexity, as locking additional tokens would require weight updates, etc. If you want to use partial tokens, move them to a separate ETH key first. + +A successfull change deletes all votes in the system. If you don't like it, vote again. This carries a slight risk, but avoids issues if we have two proposals that both have a chance to get the majority. + +Option: Allow only one hash; if a new hash is voted for, the old one is deleted. + + + + + - If the hash doesn't exist in the voting table, create + voting_table (hash, votes), where votes = 0 + From 3248cbd9660cd613118dc855fa7016f352e0af19 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Fri, 10 Mar 2023 05:25:50 -0800 Subject: [PATCH 097/103] Update XXXX-MSUP-Multisig_Update.md --- protocol/XXXX-MSUP-Multisig_Update.md | 56 +++++++++++++++------------ 1 file changed, 31 insertions(+), 25 deletions(-) diff --git a/protocol/XXXX-MSUP-Multisig_Update.md b/protocol/XXXX-MSUP-Multisig_Update.md index 359fc3fed..219638ccc 100644 --- a/protocol/XXXX-MSUP-Multisig_Update.md +++ b/protocol/XXXX-MSUP-Multisig_Update.md @@ -1,55 +1,61 @@ -Purpose: +*Purpose: -In case control of the bridge is lost (e.g., too many validators cease operating at the same time), allow for a tokenholder vote to restore the functionality +In case control of the bridge is lost (e.g., too many validators cease operating at the same time), allow for a tokenholder vote to restore the functionality by replacing the hash representing the validator identities in the bridge. -Properties + +**Properties: - Only unvested tokens are allowed to vote - We have a decaying voting threshold - the required votes to change the validator set is lowered if the bridge isn't used. -- tokens need to be locked to be allowed to vote, and then cannot be sold unless unlocked (which invalidates the vote) +- Tokens need to be locked to be allowed to vote, and then cannot be sold unless unlocked (which invalidates the vote) -Variables - max_threshold: The maximum threshold required for a valid vote - min_threshold: The minimum threshold required for a valid vote - decay_rate: how fast the +**Variables: + max_threshold: The maximum threshold required for a valid vote (unit: number of tokens) + min_threshold: The minimum threshold required for a valid vote (unit: number of tokens) + decay_rate: how fast the threshoild decays over time while the bridge is not accessed (unit: numbeer of tokens/Ethereum block) -Bridge contract: +**Bridge contract: +Functions: last_update(): Allows another contract to query the last Ethereum block when the multisig was used successfully replace_hash(h) Allows the voting contract (and that contract only) to replace the hash value defining the validator set -Voting Contract +**Voting Contract: Data structures: -- voting table: an array (hash, votes) defining all the votes a hash got -- user_votes: an array (key, hash1, hash2, ...) defining all the hashes a key voted for -- user_weight an array (key, number_of_tokens) defining how many tokens a user locked. - -lock_tokens: Allows an Ethereum key to lock all itstokens into the voting contract, provided it has tokens, and they are not already locked to either the vesting contract or the voting contract. This initialises - - If the key already has tokens locked, abort - set user_votes (key) to [] +- voting_table: an array (hash, votes) defining all the votes a hash got (keyed by the hash) +- user_votes: an array (key, hash1, hash2, ...) defining all the hashes a key voted for (keyed by the users Ethereum key) +- user_weight an array (key, number_of_tokens) defining how many tokens a user locked (keyed by the users Ethereum key) + +Functions: +lock_tokens(): Allows an Ethereum key to lock all itstokens into the voting contract, provided it has tokens, and they are not already locked to either the vesting contract or the voting contract. This initialises the votes to 0. + Flow: + if the key already has tokens locked, abort // If you had tokens locked, then transfer new tokens to that + // account, then try to lock them, then you're just strange. + // We want to keep things simple and not accomondate that. + set user_votes (key) to [] // i.e., no votes issued. set user_weight(key) to the amount of tokens locked unlock_tokens: Allows a key to unlock its tokens. This clears all its votes. - If the key has no tokens locked, abort - for each hash in user_votes(key), substract user_)weight(key) - if a hash now has 0 votes, delete that hash + Flow: + if the key has no tokens locked, abort + for each hash in user_votes(key), substract user_weight(key) + if a hash now has 0 votes, delete that hash from voting_table delete user_votes(key) delete user_weight(key) vote(hash): Allows a key to vote for a specific hash. What this does: - Verify that that key hasn't voted for that hash before. If it has, abort. - - If the hash doesn't exist in the voting table, create + - if the hash doesn't exist in the voting table, create voting_table (hash, votes), where votes = 0 - - Set voting_table (hash) += user_weight(key) - - Add hash to user_votes(key). + - set voting_table (hash) += user_weight(key) + - add hash to user_votes(key). -Evaluate(hash) +evaluate(hash): Test if there are enough votes for a hash to execute: - if votes(hash,votes) > max( min_threshold, max_threshold- (current_block - bridge.last_update())*decay_rate, then call bridge.replace_hash(hash) set voting_table to [] From a2776c0fbefeac67fab7d8f588dedacfb6a0dfb2 Mon Sep 17 00:00:00 2001 From: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Date: Fri, 10 Mar 2023 11:35:08 -0800 Subject: [PATCH 098/103] Update XXXX-MSUP-Multisig_Update.md --- protocol/XXXX-MSUP-Multisig_Update.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/protocol/XXXX-MSUP-Multisig_Update.md b/protocol/XXXX-MSUP-Multisig_Update.md index 219638ccc..91318be65 100644 --- a/protocol/XXXX-MSUP-Multisig_Update.md +++ b/protocol/XXXX-MSUP-Multisig_Update.md @@ -28,7 +28,7 @@ replace_hash(h) Allows the voting contract (and that contract only) to replace Data structures: - voting_table: an array (hash, votes) defining all the votes a hash got (keyed by the hash) -- user_votes: an array (key, hash1, hash2, ...) defining all the hashes a key voted for (keyed by the users Ethereum key) +- user_vote: an array (key, hash) defines the hash a key voted for (keyed by the users Ethereum key) - user_weight an array (key, number_of_tokens) defining how many tokens a user locked (keyed by the users Ethereum key) Functions: @@ -37,29 +37,31 @@ lock_tokens(): Allows an Ethereum key to lock all itstokens into the voting cont if the key already has tokens locked, abort // If you had tokens locked, then transfer new tokens to that // account, then try to lock them, then you're just strange. // We want to keep things simple and not accomondate that. - set user_votes (key) to [] // i.e., no votes issued. + set user_vote (key) to NIL // i.e., no votes issued. set user_weight(key) to the amount of tokens locked unlock_tokens: Allows a key to unlock its tokens. This clears all its votes. Flow: if the key has no tokens locked, abort - for each hash in user_votes(key), substract user_weight(key) - if a hash now has 0 votes, delete that hash from voting_table - delete user_votes(key) - delete user_weight(key) + for the hash this user voted for, delete the vote: voting_table(user_votes(key) -= user_weight(key) + if the hash now has 0 votes, remove that hash from voting_table + remove user_vote(key) + remove user_weight(key) vote(hash): Allows a key to vote for a specific hash. What this does: - - Verify that that key hasn't voted for that hash before. If it has, abort. + - If the key has voted already, delete that vote: voting_table(user_votes(key) -= user_weight(key) + if the hash now has 0 votes, remove that hash from voting_table - if the hash doesn't exist in the voting table, create - voting_table (hash, votes), where votes = 0 + voting_table (hash, votes), where votes = 0 - set voting_table (hash) += user_weight(key) - add hash to user_votes(key). evaluate(hash): Test if there are enough votes for a hash to execute: + - if hash == NIL, abort // don't count the empty votes - if votes(hash,votes) > max( min_threshold, max_threshold- (current_block - bridge.last_update())*decay_rate, then call bridge.replace_hash(hash) set voting_table to [] - set user_votes to [] + set user_vote to [] @@ -69,7 +71,6 @@ Comment: Keys cannot lock a part of their tokens; allowing that would cause code A successfull change deletes all votes in the system. If you don't like it, vote again. This carries a slight risk, but avoids issues if we have two proposals that both have a chance to get the majority. -Option: Allow only one hash; if a new hash is voted for, the old one is deleted. From bac0d37adfdb21c00b41f60a572eb4f44b462e4e Mon Sep 17 00:00:00 2001 From: C0deMunk33 Date: Mon, 13 Mar 2023 08:37:37 -0700 Subject: [PATCH 099/103] updated based on PoC implementation --- protocol/XXXX-MSUP-Multisig_Update.md | 110 ++++++++++++-------------- 1 file changed, 50 insertions(+), 60 deletions(-) diff --git a/protocol/XXXX-MSUP-Multisig_Update.md b/protocol/XXXX-MSUP-Multisig_Update.md index 91318be65..c1b696fa9 100644 --- a/protocol/XXXX-MSUP-Multisig_Update.md +++ b/protocol/XXXX-MSUP-Multisig_Update.md @@ -1,80 +1,70 @@ -*Purpose: +*Multisig Token Recovery: -In case control of the bridge is lost (e.g., too many validators cease operating at the same time), allow for a tokenholder vote to restore the functionality by replacing the hash representing the validator identities in the bridge. +In case control of the bridge is lost (e.g., too many validators cease operating at the same time), this allows for a tokenholder vote to restore the functionality by replacing the signer set hash, comprised of validator addresses and vote weights, on the Multisig Control smart contract. **Properties: - Only unvested tokens are allowed to vote - We have a decaying voting threshold - the required votes to change the validator set is lowered if the bridge isn't used. -- Tokens need to be locked to be allowed to vote, and then cannot be sold unless unlocked (which invalidates the vote) +- Tokens need to be deposited into the vote smart contract in order to be counted. VEGA tokens that are voting on a recovery proposal cannot be sold unless withdrawn from the vote contract, decrementing the vote count of a supported proposal by the amount removed. +- Outstanding proposals are invalidated once a proposal is successful +- Votes for valid proposals can be counted at any time and immediately update the multisig control signer set hash +- All-or-nothing all of a user's deposited VEGA tokens count towards only 1 proposal at a time, and the entire amount is counted +- Proposers must have VEGA deposited into voting smart contract +- Any proposal whose vote count drops to zero is deleted **Variables: max_threshold: The maximum threshold required for a valid vote (unit: number of tokens) min_threshold: The minimum threshold required for a valid vote (unit: number of tokens) - decay_rate: how fast the threshoild decays over time while the bridge is not accessed (unit: numbeer of tokens/Ethereum block) + decay_rate: how fast the threshold decays over time while the bridge is not accessed (unit: number of tokens/Ethereum block) + - -**Bridge contract: +**Multisig Control smart contract: Functions: -last_update(): Allows another contract to query the last Ethereum block when +last_transaction(): Allows another contract to query the last Ethereum timestamp when the multisig was used successfully -replace_hash(h) Allows the voting contract (and that contract only) to replace - the hash value defining the validator set - +emergency_recovery(h): Allows the voting contract (and that contract only) to replace + the hash value defining the validator set and weights -**Voting Contract: +**Token Recovery smart contract: Data structures: -- voting_table: an array (hash, votes) defining all the votes a hash got (keyed by the hash) -- user_vote: an array (key, hash) defines the hash a key voted for (keyed by the users Ethereum key) -- user_weight an array (key, number_of_tokens) defining how many tokens a user locked (keyed by the users Ethereum key) +- Proposal: Struct containing creation time, IPFS hash of the proposal document, the current vote count, and the new signer set hash should the proposal be successful +- User: Struct containing values for deposited VEGA token amount, and the ID of the proposal that the user currently supports, all keyed on user's Ethereum address Functions: -lock_tokens(): Allows an Ethereum key to lock all itstokens into the voting contract, provided it has tokens, and they are not already locked to either the vesting contract or the voting contract. This initialises the votes to 0. - Flow: - if the key already has tokens locked, abort // If you had tokens locked, then transfer new tokens to that - // account, then try to lock them, then you're just strange. - // We want to keep things simple and not accomondate that. - set user_vote (key) to NIL // i.e., no votes issued. - set user_weight(key) to the amount of tokens locked - -unlock_tokens: Allows a key to unlock its tokens. This clears all its votes. - Flow: - if the key has no tokens locked, abort - for the hash this user voted for, delete the vote: voting_table(user_votes(key) -= user_weight(key) - if the hash now has 0 votes, remove that hash from voting_table - remove user_vote(key) - remove user_weight(key) - -vote(hash): Allows a key to vote for a specific hash. What this does: - - If the key has voted already, delete that vote: voting_table(user_votes(key) -= user_weight(key) - if the hash now has 0 votes, remove that hash from voting_table - - if the hash doesn't exist in the voting table, create - voting_table (hash, votes), where votes = 0 - - set voting_table (hash) += user_weight(key) - - add hash to user_votes(key). - -evaluate(hash): Test if there are enough votes for a hash to execute: - - if hash == NIL, abort // don't count the empty votes - - if votes(hash,votes) > max( min_threshold, max_threshold- (current_block - bridge.last_update())*decay_rate, then - call bridge.replace_hash(hash) - set voting_table to [] - set user_vote to [] - - - - - -Comment: Keys cannot lock a part of their tokens; allowing that would cause code complexity, as locking additional tokens would require weight updates, etc. If you want to use partial tokens, move them to a separate ETH key first. - -A successfull change deletes all votes in the system. If you don't like it, vote again. This carries a slight risk, but avoids issues if we have two proposals that both have a chance to get the majority. - - - - - - - If the hash doesn't exist in the voting table, create - voting_table (hash, votes), where votes = 0 - +current_threshold(): +- The current calculated threshold based on the amount of time since the last successful multisig control transaction. + +propose_recovery(string memory ipfs_hash, bytes32 new_signer_set_hash): +- Creates a new proposal +- User must have previously deposited VEGA +- Emits Proposal_Created event containing assigned proposal_id + +deposit(uint256 amount): +- Deposits amount of tokens +- Updates user's vote count +- Updates vote count of user's selected proposal + +withdraw(uint256 amount): +- Removes amount of tokens from contract and transfers them to user +- Updates user's vote count +- Updates vote count of user's selected proposal +- Deletes proposal if vote count goes to zero + +set_vote(uint256 proposal_id): +- Puts user's entire vote count towards the selected proposal +- Updates user's selected proposal +- Updates votes of user's previously selected proposal +- Deletes previously selected proposal if votes drop to zero +- Updates votes of users newly selected proposal + +execute_proposal(uint256 vote_id): +- Counts current votes on proposal +- Updates singer set hash via `emergency_recovery(hash)` on Multisig_Control smart contract +- Invalidates all other outstanding proposals + +Events: +Proposal_Created(uint256 indexed proposal_id, uint256 timestamp, string ipfs_hash, bytes32 new_signer_set_hash) \ No newline at end of file From 32e62fce0b9efe6dc72ec947c71399f767708d5a Mon Sep 17 00:00:00 2001 From: C0deMunk33 Date: Mon, 13 Mar 2023 08:49:13 -0700 Subject: [PATCH 100/103] updated formatting --- protocol/XXXX-MSUP-Multisig_Update.md | 107 ++++++++++++++------------ 1 file changed, 56 insertions(+), 51 deletions(-) diff --git a/protocol/XXXX-MSUP-Multisig_Update.md b/protocol/XXXX-MSUP-Multisig_Update.md index c1b696fa9..f36c6ac21 100644 --- a/protocol/XXXX-MSUP-Multisig_Update.md +++ b/protocol/XXXX-MSUP-Multisig_Update.md @@ -1,9 +1,9 @@ -*Multisig Token Recovery: +# Multisig Token Recovery: In case control of the bridge is lost (e.g., too many validators cease operating at the same time), this allows for a tokenholder vote to restore the functionality by replacing the signer set hash, comprised of validator addresses and vote weights, on the Multisig Control smart contract. -**Properties: +## Properties: - Only unvested tokens are allowed to vote - We have a decaying voting threshold - the required votes to change the validator set is lowered if the bridge isn't used. - Tokens need to be deposited into the vote smart contract in order to be counted. VEGA tokens that are voting on a recovery proposal cannot be sold unless withdrawn from the vote contract, decrementing the vote count of a supported proposal by the amount removed. @@ -14,57 +14,62 @@ In case control of the bridge is lost (e.g., too many validators cease operating - Any proposal whose vote count drops to zero is deleted -**Variables: - max_threshold: The maximum threshold required for a valid vote (unit: number of tokens) - min_threshold: The minimum threshold required for a valid vote (unit: number of tokens) - decay_rate: how fast the threshold decays over time while the bridge is not accessed (unit: number of tokens/Ethereum block) - +## Parameters: +These parameters are set at contract deployment and cannot be changed. If there needs to be an update, it needs to be redeployed and Vega needs to recognize the new contract and update it on the multisig contract with a multisig transaction. -**Multisig Control smart contract: +- `max_threshold`: The maximum threshold required for a valid vote (unit: number of tokens) +- `min_threshold`: The minimum threshold required for a valid vote (unit: number of tokens) +- `decay_rate`: how fast the threshold decays over time while the bridge is not accessed (unit: number of tokens/Ethereum block) +- `multisig_address`: address of the Multisig Control smart contract +- `voting_token_address`: the address of VEGA token + +## Multisig Control smart contract: +To enable this token recovery, any multisig smart contract will need to implement the following functions: -Functions: -last_transaction(): Allows another contract to query the last Ethereum timestamp when +### Functions: +- `last_transaction()`: Allows another contract to query the last Ethereum timestamp when the multisig was used successfully -emergency_recovery(h): Allows the voting contract (and that contract only) to replace +- `emergency_recovery(h)`: Allows the voting contract (and that contract only) to replace the hash value defining the validator set and weights -**Token Recovery smart contract: - -Data structures: -- Proposal: Struct containing creation time, IPFS hash of the proposal document, the current vote count, and the new signer set hash should the proposal be successful -- User: Struct containing values for deposited VEGA token amount, and the ID of the proposal that the user currently supports, all keyed on user's Ethereum address - -Functions: -current_threshold(): -- The current calculated threshold based on the amount of time since the last successful multisig control transaction. - -propose_recovery(string memory ipfs_hash, bytes32 new_signer_set_hash): -- Creates a new proposal -- User must have previously deposited VEGA -- Emits Proposal_Created event containing assigned proposal_id - -deposit(uint256 amount): -- Deposits amount of tokens -- Updates user's vote count -- Updates vote count of user's selected proposal - -withdraw(uint256 amount): -- Removes amount of tokens from contract and transfers them to user -- Updates user's vote count -- Updates vote count of user's selected proposal -- Deletes proposal if vote count goes to zero - -set_vote(uint256 proposal_id): -- Puts user's entire vote count towards the selected proposal -- Updates user's selected proposal -- Updates votes of user's previously selected proposal -- Deletes previously selected proposal if votes drop to zero -- Updates votes of users newly selected proposal - -execute_proposal(uint256 vote_id): -- Counts current votes on proposal -- Updates singer set hash via `emergency_recovery(hash)` on Multisig_Control smart contract -- Invalidates all other outstanding proposals - -Events: -Proposal_Created(uint256 indexed proposal_id, uint256 timestamp, string ipfs_hash, bytes32 new_signer_set_hash) \ No newline at end of file +## Token Recovery smart contract: + +### Data structures: +- `Proposal`: Struct containing creation time, IPFS hash of the proposal document, the current vote count, and the new signer set hash should the proposal be successful +- `User`: Struct containing values for deposited VEGA token amount, and the ID of the proposal that the user currently supports, all keyed on user's Ethereum address + +### Functions: + +- `current_threshold()`: + - The current calculated threshold based on the amount of time since the last successful multisig control transaction. + +- `propose_recovery(string memory ipfs_hash, bytes32 new_signer_set_hash)`: + - Creates a new proposal + - User must have previously deposited VEGA + - Emits Proposal_Created event containing assigned proposal_id + +- `deposit(uint256 amount)`: + - Deposits amount of tokens + - Updates user's vote count + - Updates vote count of user's selected proposal + +- `withdraw(uint256 amount)`: + - Removes amount of tokens from contract and transfers them to user + - Updates user's vote count + - Updates vote count of user's selected proposal + - Deletes proposal if vote count goes to zero + +- `set_vote(uint256 proposal_id)`: + - Puts user's entire vote count towards the selected proposal + - Updates user's selected proposal + - Updates votes of user's previously selected proposal + - Deletes previously selected proposal if votes drop to zero + - Updates votes of users newly selected proposal + +- `execute_proposal(uint256 vote_id)`: + - Counts current votes on proposal + - Updates singer set hash via `emergency_recovery(hash)` on Multisig_Control smart contract + - Invalidates all other outstanding proposals + +### Events: +- `Proposal_Created(uint256 indexed proposal_id, uint256 timestamp, string ipfs_hash, bytes32 new_signer_set_hash)` \ No newline at end of file From acb39c8631d9a1887694aefceefae9ed6e54ef66 Mon Sep 17 00:00:00 2001 From: C0deMunk33 Date: Mon, 13 Mar 2023 11:01:41 -0700 Subject: [PATCH 101/103] staking --- protocol/XXXX-MSUP-Multisig_Update.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/protocol/XXXX-MSUP-Multisig_Update.md b/protocol/XXXX-MSUP-Multisig_Update.md index f36c6ac21..831edf823 100644 --- a/protocol/XXXX-MSUP-Multisig_Update.md +++ b/protocol/XXXX-MSUP-Multisig_Update.md @@ -4,7 +4,7 @@ In case control of the bridge is lost (e.g., too many validators cease operating ## Properties: -- Only unvested tokens are allowed to vote +- Only VEGA tokens held in a user's Ethereum wallet can be deposited for a vote. - We have a decaying voting threshold - the required votes to change the validator set is lowered if the bridge isn't used. - Tokens need to be deposited into the vote smart contract in order to be counted. VEGA tokens that are voting on a recovery proposal cannot be sold unless withdrawn from the vote contract, decrementing the vote count of a supported proposal by the amount removed. - Outstanding proposals are invalidated once a proposal is successful @@ -12,7 +12,7 @@ In case control of the bridge is lost (e.g., too many validators cease operating - All-or-nothing all of a user's deposited VEGA tokens count towards only 1 proposal at a time, and the entire amount is counted - Proposers must have VEGA deposited into voting smart contract - Any proposal whose vote count drops to zero is deleted - +- Once proposal goes through, the Token Recovery smart contract becomes the new Staking Bridge to ensure continuation of Vega network without more ETH transactions ## Parameters: These parameters are set at contract deployment and cannot be changed. If there needs to be an update, it needs to be redeployed and Vega needs to recognize the new contract and update it on the multisig contract with a multisig transaction. @@ -23,6 +23,9 @@ These parameters are set at contract deployment and cannot be changed. If there - `multisig_address`: address of the Multisig Control smart contract - `voting_token_address`: the address of VEGA token +## Recovery as Staking Bridge +The Recovery/Vote contract will implement all of the IStake interface in order to allow tokens used for a vote to also be used to stake/delegate VEGA and ensure the continuation of Vega network. + ## Multisig Control smart contract: To enable this token recovery, any multisig smart contract will need to implement the following functions: @@ -72,4 +75,5 @@ To enable this token recovery, any multisig smart contract will need to implemen - Invalidates all other outstanding proposals ### Events: -- `Proposal_Created(uint256 indexed proposal_id, uint256 timestamp, string ipfs_hash, bytes32 new_signer_set_hash)` \ No newline at end of file +- `Proposal_Created(uint256 indexed proposal_id, uint256 timestamp, string ipfs_hash, bytes32 new_signer_set_hash)` + From b2512151ed63e03adf2f00fe9151fb835fcd3992 Mon Sep 17 00:00:00 2001 From: C0deMunk33 Date: Mon, 13 Mar 2023 11:12:54 -0700 Subject: [PATCH 102/103] recovery process --- protocol/XXXX-MSUP-Multisig_Update.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/protocol/XXXX-MSUP-Multisig_Update.md b/protocol/XXXX-MSUP-Multisig_Update.md index 831edf823..6c80c37d8 100644 --- a/protocol/XXXX-MSUP-Multisig_Update.md +++ b/protocol/XXXX-MSUP-Multisig_Update.md @@ -26,6 +26,17 @@ These parameters are set at contract deployment and cannot be changed. If there ## Recovery as Staking Bridge The Recovery/Vote contract will implement all of the IStake interface in order to allow tokens used for a vote to also be used to stake/delegate VEGA and ensure the continuation of Vega network. +## Recovery Process +* Proposer deposits VEGA into the recovery contract +* Proposer makes a proposal and uploads it to IPFS +* Proposer coordinates with Validators and creates a signer set hash that will update the bridge's signer set +* Proposer calls `create_proposal` which emits the `Proposal_Created` event +* Proposer coordinates the community to vote on their proposal +* Users pull their VEGA off staking bridges and out of vesting (where possible) and deposit them into the Token Recover contract +* Users run `set_vote` with the `proposal_id` emitted from the `Proposal_Created` event +* Once the threshold is reached (either through numbers or threshold decay), a user runs `execute_proposal` which automatically updates the signer set hash +* Vega sees the signer set updated and network is resumed + ## Multisig Control smart contract: To enable this token recovery, any multisig smart contract will need to implement the following functions: @@ -36,7 +47,6 @@ To enable this token recovery, any multisig smart contract will need to implemen the hash value defining the validator set and weights ## Token Recovery smart contract: - ### Data structures: - `Proposal`: Struct containing creation time, IPFS hash of the proposal document, the current vote count, and the new signer set hash should the proposal be successful - `User`: Struct containing values for deposited VEGA token amount, and the ID of the proposal that the user currently supports, all keyed on user's Ethereum address From 5c61b38487efbe9cb2fcf0e1406d5fda5f6eab5a Mon Sep 17 00:00:00 2001 From: C0deMunk33 Date: Mon, 13 Mar 2023 11:13:59 -0700 Subject: [PATCH 103/103] recovery process --- protocol/XXXX-MSUP-Multisig_Update.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/XXXX-MSUP-Multisig_Update.md b/protocol/XXXX-MSUP-Multisig_Update.md index 6c80c37d8..f34a00ca0 100644 --- a/protocol/XXXX-MSUP-Multisig_Update.md +++ b/protocol/XXXX-MSUP-Multisig_Update.md @@ -36,6 +36,7 @@ The Recovery/Vote contract will implement all of the IStake interface in order t * Users run `set_vote` with the `proposal_id` emitted from the `Proposal_Created` event * Once the threshold is reached (either through numbers or threshold decay), a user runs `execute_proposal` which automatically updates the signer set hash * Vega sees the signer set updated and network is resumed +* Since votes are also credited as stake, users can begin to delegate. ## Multisig Control smart contract: To enable this token recovery, any multisig smart contract will need to implement the following functions: