Difference between revisions of "SNS decentralization swap trust"
From Internet Computer Wiki
Lara.schmid (talk | contribs) |
Lara.schmid (talk | contribs) |
||
| Line 24: | Line 24: | ||
* '''Verify the SNS canisters’ configurations.''' Each SNS can be set up with custom configurations. It is important to verify these configurations as they influence, for example, who controls the dapp during the SNS launch and can still upgrade it, as well as who can get how many voting power after the SNS launch. They also determine the rules of the DAO that you will be a member of after participating, for example under which conditions you can vote and how much voting rewards it will get. | * '''Verify the SNS canisters’ configurations.''' Each SNS can be set up with custom configurations. It is important to verify these configurations as they influence, for example, who controls the dapp during the SNS launch and can still upgrade it, as well as who can get how many voting power after the SNS launch. They also determine the rules of the DAO that you will be a member of after participating, for example under which conditions you can vote and how much voting rewards it will get. | ||
| − | == Verify the SNS sale parameters & the initial token distribution before | + | == Verify the SNS sale parameters & the initial token distribution before participating in the decentralization sale == |
=== Why? === | === Why? === | ||
As already explained, it is important to verify the SNS canister’s configurations. | As already explained, it is important to verify the SNS canister’s configurations. | ||
| − | The sale parameters can be seen as part of these configurations. They are mentioned explicitly here because they are fundamental for the SNS launch and because are set by the proposal that starts the SNS sale (while other configurations are set when the SNS canisters are first installed). | + | The sale parameters can be seen as part of these configurations. They are mentioned explicitly here because they are fundamental for the SNS launch and because they are set by the proposal that starts the SNS sale (while other configurations are set when the SNS canisters are first installed). |
=== Background === | === Background === | ||
| Line 35: | Line 35: | ||
=== Verification === | === Verification === | ||
| − | * In the SNS’s initialization and in the NNS proposal that starts the SNS decentralization sale, it is defined how '''many tokens are given to developers, kept in the SNS treasury, given out as airdrops, and sold in the decentralization sale.''' It is also defined how much the [[Community Fund]] is asked to | + | * In the SNS’s initialization and in the NNS proposal that starts the SNS decentralization sale, it is defined how '''many tokens are given to developers, kept in the SNS treasury, given out as airdrops, and sold in the decentralization sale.''' It is also defined how much the [[Community Fund]] is asked to spend in the decentralization sale. Verifying these numbers is important to understand the initial token distribution and who can have how much voting power after the sale. This also determines who you have to trust wrt 51% attacks. |
* For example, if less tokens are sold in the sale than what is needed to get 50% of the voting power, it is harder for an outside attacker to get 51% of the voting power. | * For example, if less tokens are sold in the sale than what is needed to get 50% of the voting power, it is harder for an outside attacker to get 51% of the voting power. | ||
* For example, if the developers or other initial investors get a large portion of the initial tokens, it is easier for them than for others to get 51% of the voting power by also participating in the sale. Therefore, depending on the settings, it might be required to trust those initial investors. | * For example, if the developers or other initial investors get a large portion of the initial tokens, it is easier for them than for others to get 51% of the voting power by also participating in the sale. Therefore, depending on the settings, it might be required to trust those initial investors. | ||
* The SNS sale has '''parameters that influence how many tokens one principal can get and how many principals have to participate in the sale for it to be successful'''. You can verify those parameters in the sale’s settings. Even though this will not help verifying that no sybil attacks occurred, it might still be useful to verify them. | * The SNS sale has '''parameters that influence how many tokens one principal can get and how many principals have to participate in the sale for it to be successful'''. You can verify those parameters in the sale’s settings. Even though this will not help verifying that no sybil attacks occurred, it might still be useful to verify them. | ||
| − | == Verify the dapp canisters == | + | == Verify the dapp canisters before participating. You need to trust the dapp developers not to change the dapp canisters maliciously after that.== |
=== Why? === | === Why? === | ||
| − | + | Before participating in the sale, it is important to verify the dapp canisters as this is the project that you will partially own after a successful launch. Note that some of the above verification steps can be done once before sale participation and remove the need for trusting the developers. In contrast, this is not true for the dapp canisters. | |
| + | The developers still control and can upgrade the dapp canisters during the SNS launch, including while the sale is ongoing. Therefore, the dapp canisters should be verified before participation but nevertheless you trust the developers that they don’t change the canisters maliciously after you participated and before the SNS is launched and under decentralized control. During this time, you can at best confirm that things didn’t change, but you cannot take back your participation anymore. | ||
| + | After the SNS is launched, the trust in the developers can be replaced with trust in the decentralized SNS community. | ||
=== Background === | === Background === | ||
The dapp that is being decentralized in the [[SNS launch]] might consist of multiple canisters. | The dapp that is being decentralized in the [[SNS launch]] might consist of multiple canisters. | ||
This might also include an asset canister that serves the asset that you see when you interact with the dapp’s frontend. | This might also include an asset canister that serves the asset that you see when you interact with the dapp’s frontend. | ||
| − | |||
=== Verification === | === Verification === | ||
| − | * '''Verify all canister’s controllers.''' The dapp canisters should be controlled by the SNS root canister or by other dapp canister that is in turn controlled by SNS root (this can also be over a longer chain of control that leads to only the SNS root at the top). This ensures that the dapp canister cannot be changed in a malicious way. If you do not check this, you trust the dapp developers that they correctly handed over the dapp to the SNS. | + | * ''' Verify all canister’s controllers before participating and trust the developers not to change them after that.''' The dapp canisters should be controlled by the SNS root canister or by other dapp canister that is in turn controlled by SNS root (this can also be over a longer chain of control that leads to only the SNS root at the top). This ensures that the dapp canister cannot be changed in a malicious way. If you do not check this, you trust the dapp developers that they correctly handed over the dapp to the SNS. |
| − | * '''Verify the | + | * '''Verify the app canisters’ WASMs before participating in the decentralization sale and trust the developers not to change them maliciously after that.''' To make sure that the dapp canisters are trustworthy you should verify the code that they run. Otherwise you trust the dapp developers with this fact. Some things to watch out for are to verify that the canisters do not have any “backdoors”, for example methods that can be called from the outside, maybe just by some defined principals that would then have centralized control over this method call. For some privileged methods that should only be invoked by an SNS proposal, you should verify that the code enforces that these methods can only be called by the SNS governance canister. Verify that there are no changes to the dapp canisters that are governed by SNS root during the decentralization sale. During the decentralization sale, the developers can still upgrade the dapp canisters, and add or remove new canisters to their dapp. This means that either you have to verify that the dapp canisters are not upgraded and changed anymore after you verified their code or you trust the developers that they only make secure changes. |
* '''Verify that the dapp canisters have a clean state.''' Most dapp canisters will be deployed by a centralized party and then just handed over to an SNS. Even if these canisters’ control is handed over to an SNS DAO, they might still contain malicious state that is preserved over upgrades. Therefore, to fully trust a canister you would also have to convince yourself that after it is handed over to the SNS DAO its state has been cleaned up. Alternatively, you trust all the previous controllers of the dapp canisters (e.g., the original developers). | * '''Verify that the dapp canisters have a clean state.''' Most dapp canisters will be deployed by a centralized party and then just handed over to an SNS. Even if these canisters’ control is handed over to an SNS DAO, they might still contain malicious state that is preserved over upgrades. Therefore, to fully trust a canister you would also have to convince yourself that after it is handed over to the SNS DAO its state has been cleaned up. Alternatively, you trust all the previous controllers of the dapp canisters (e.g., the original developers). | ||
* '''Verify the asset canister.''' The asset canister has a list of principals who can update assets. Once the asset canister is handed over to an SNS DAO, it should be configured such that this list of privileged principals can only be changed by SNS proposal. You should verify that this is the case. You should also understand which people own the privileged principals and you have to trust them not to upload malicious assets. | * '''Verify the asset canister.''' The asset canister has a list of principals who can update assets. Once the asset canister is handed over to an SNS DAO, it should be configured such that this list of privileged principals can only be changed by SNS proposal. You should verify that this is the case. You should also understand which people own the privileged principals and you have to trust them not to upload malicious assets. | ||
Revision as of 10:28, 1 March 2023
If you participate in an SNS decentralization sale of an SNS launch to get a share of the SNS DAO’s voting power, you should convince yourself that the dapp that is decentralizedand the SNS DAO are trustworthy. As this is also in the dapp developer’s interest, they should provide all information that allows you to verify their dapp and the SNS configurations. If you cannot or do not want to verify everything yourself, but still decide to participate in the SNS decentralization sale, you should be aware that you are implicitly trusting the NNS community and the developers that offer their dapp for decentralization that they have verified and did not maliciously set up the SNS, respectively. Also, note that the developers can upgrade and thus change the dapp canisters after you have participated in the sale but before the SNS is fully launched. Therefore you need to trust them after you have participated and before the SNS launch is successfully finished. Finally, at all times you trust the NNS community in that they fully control the ICP.
This page describes how to minimize trust requirements through verification. It also describes what needs to be trusted when various parts are not verified. It does so on a high level, as the detailed required steps depend on the dapp that is being decentralized. You can find more detailed information on how to verify the SNS decentralization sale proposal that is needed to start an SNS decentralization sale on a separate wiki page.
Verify the SNS canisters before participating in the decentralization sale
Why?
You should make sure that you are in fact interacting with a real SNS and that the SNS canisters run trustworthy code, as otherwise they could steal the tokens that you sent to the SNS sale.
Background
All SNS canisters run on a dedicated SNS subnet. The only canister that can install an SNS is an NNS canister called SNS-W. It will only install SNS canisters with code (WASMs) that have been pre-approved by the NNS. Also, it will always set the controllers of the canisters in a predefined way so that the SNS canisters control each other except for the SNS sale which is controlled by the NNS. SNS canisters can be upgraded during the SNS launch, but at all times the SNS canisters can only be upgraded to version that are pre-approved by the NNS. The NNS frontend dapp launchpad only displays real SNSs that are installed on the SNS subnet.
Verification
- Verify that the canisters that you interact with are indeed SNS canisters. This is one of the most important things to verify, as otherwise you could send your tokens to canisters that are not trusted and might steal your tokens.
- Verify the SNS canisters’ controllers. As mentioned, the SNS canisters will be set up with predefined controllers. If you don’t verify this, then you trust the NNS in that the SNS-W code initialized the SNS correctly and in that the SNS canisters’ code (that has been approved by the NNS) do not allow changing controllership after initialization.
- Verify the SNS canisters’ WASMs. As mentioned, the SNS canisters are installed with and can only be upgraded to WASMs that have been pre-approved by the NNS. If you don’t verify the SNS canisters’ WASMs you trust the NNS community that they only approved trustworthy WASMs. Note that in general, you must trust the NNS community because the NNS community can update the platform. Specific to the SNS, the NNS community can also approve new SNS WASMs.
- Verify the SNS canisters’ configurations. Each SNS can be set up with custom configurations. It is important to verify these configurations as they influence, for example, who controls the dapp during the SNS launch and can still upgrade it, as well as who can get how many voting power after the SNS launch. They also determine the rules of the DAO that you will be a member of after participating, for example under which conditions you can vote and how much voting rewards it will get.
Verify the SNS sale parameters & the initial token distribution before participating in the decentralization sale
Why?
As already explained, it is important to verify the SNS canister’s configurations. The sale parameters can be seen as part of these configurations. They are mentioned explicitly here because they are fundamental for the SNS launch and because they are set by the proposal that starts the SNS sale (while other configurations are set when the SNS canisters are first installed).
Background
If a single party gets more than 51% of the voting power after the SNS launch, they have full control over the dapp. This means, in particular, that they can change the dapp’s content or steal the ICP in the SNS’s treasury. There is no sybil resistance in an SNS decentralization sale. This means that a single party can participate in the sale with multiple principals and get more voting power than it appears. Therefore it is impossible to verify that a 51% does not occur. Nevertheless, it is possible to make some other checks that would make this harder or less likely.
Verification
- In the SNS’s initialization and in the NNS proposal that starts the SNS decentralization sale, it is defined how many tokens are given to developers, kept in the SNS treasury, given out as airdrops, and sold in the decentralization sale. It is also defined how much the Community Fund is asked to spend in the decentralization sale. Verifying these numbers is important to understand the initial token distribution and who can have how much voting power after the sale. This also determines who you have to trust wrt 51% attacks.
- For example, if less tokens are sold in the sale than what is needed to get 50% of the voting power, it is harder for an outside attacker to get 51% of the voting power.
- For example, if the developers or other initial investors get a large portion of the initial tokens, it is easier for them than for others to get 51% of the voting power by also participating in the sale. Therefore, depending on the settings, it might be required to trust those initial investors.
- The SNS sale has parameters that influence how many tokens one principal can get and how many principals have to participate in the sale for it to be successful. You can verify those parameters in the sale’s settings. Even though this will not help verifying that no sybil attacks occurred, it might still be useful to verify them.
Verify the dapp canisters before participating. You need to trust the dapp developers not to change the dapp canisters maliciously after that.
Why?
Before participating in the sale, it is important to verify the dapp canisters as this is the project that you will partially own after a successful launch. Note that some of the above verification steps can be done once before sale participation and remove the need for trusting the developers. In contrast, this is not true for the dapp canisters. The developers still control and can upgrade the dapp canisters during the SNS launch, including while the sale is ongoing. Therefore, the dapp canisters should be verified before participation but nevertheless you trust the developers that they don’t change the canisters maliciously after you participated and before the SNS is launched and under decentralized control. During this time, you can at best confirm that things didn’t change, but you cannot take back your participation anymore. After the SNS is launched, the trust in the developers can be replaced with trust in the decentralized SNS community.
Background
The dapp that is being decentralized in the SNS launch might consist of multiple canisters. This might also include an asset canister that serves the asset that you see when you interact with the dapp’s frontend.
Verification
- Verify all canister’s controllers before participating and trust the developers not to change them after that. The dapp canisters should be controlled by the SNS root canister or by other dapp canister that is in turn controlled by SNS root (this can also be over a longer chain of control that leads to only the SNS root at the top). This ensures that the dapp canister cannot be changed in a malicious way. If you do not check this, you trust the dapp developers that they correctly handed over the dapp to the SNS.
- Verify the app canisters’ WASMs before participating in the decentralization sale and trust the developers not to change them maliciously after that. To make sure that the dapp canisters are trustworthy you should verify the code that they run. Otherwise you trust the dapp developers with this fact. Some things to watch out for are to verify that the canisters do not have any “backdoors”, for example methods that can be called from the outside, maybe just by some defined principals that would then have centralized control over this method call. For some privileged methods that should only be invoked by an SNS proposal, you should verify that the code enforces that these methods can only be called by the SNS governance canister. Verify that there are no changes to the dapp canisters that are governed by SNS root during the decentralization sale. During the decentralization sale, the developers can still upgrade the dapp canisters, and add or remove new canisters to their dapp. This means that either you have to verify that the dapp canisters are not upgraded and changed anymore after you verified their code or you trust the developers that they only make secure changes.
- Verify that the dapp canisters have a clean state. Most dapp canisters will be deployed by a centralized party and then just handed over to an SNS. Even if these canisters’ control is handed over to an SNS DAO, they might still contain malicious state that is preserved over upgrades. Therefore, to fully trust a canister you would also have to convince yourself that after it is handed over to the SNS DAO its state has been cleaned up. Alternatively, you trust all the previous controllers of the dapp canisters (e.g., the original developers).
- Verify the asset canister. The asset canister has a list of principals who can update assets. Once the asset canister is handed over to an SNS DAO, it should be configured such that this list of privileged principals can only be changed by SNS proposal. You should verify that this is the case. You should also understand which people own the privileged principals and you have to trust them not to upload malicious assets.