revise: Trust in canisters page (#3978)

* Update trust-in-canisters.mdx

* Update trust-in-canisters.mdx

* Update trust-in-canisters.mdx

* Update docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx

Co-authored-by: Lara Schmid <73884086+LaraAS@users.noreply.github.com>

* Update docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx

Co-authored-by: Lara Schmid <73884086+LaraAS@users.noreply.github.com>

* Update trust-in-canisters.mdx

---------

Co-authored-by: Lara Schmid <73884086+LaraAS@users.noreply.github.com>

docs/developer-docs/smart-contracts/overview/trust-in-canisters.mdx

@@ -8,8 +8,6 @@ import { MarkdownChipRow } from "/src/components/Chip/MarkdownChipRow";
 
 <MarkdownChipRow labels={["Concept"]} />
 
-
-
 Applications that provide DeFi or other valuable transactions, such as the ability to transfer assets, require that users trust the application to act honestly and reliably. How can one ensure that it is safe to entrust assets to a canister?
 
 Users must have confidence that:
@@ -30,32 +28,31 @@ Additionally, developers can utilize the [canister history](/docs/current/develo
 
 Canister smart contracts are deployed and managed by controllers. A controller's level of decentralization can range from being managed by a single person or team of people up to being managed by the NNS, an SNS, or another kind of onchain DAO. Among other capabilities, the controllers can change the code for the canisters that they control because the canister code is **mutable**. The controllers have complete control over the assets, like ICP tokens or bitcoins, held by the canister they manage. This feature brings canisters closer to typical software and makes them suitable for a broad range of applications where software logic can be changed on an as-needed basis.
 
-For critical applications like those used in DeFi, centralized mutability can be dangerous. The controller could change a benign canister into a canister that steals assets. Below are some options available to developers on how to verifiably decentralize the control of a canister's mutations.
+For critical applications like those used in DeFi, centralized mutability can be dangerous. The controller could change a benign canister into a canister that steals assets. 
 
 :::info
 Canister controllers, if not voluntarily decentralized, have complete control over the user assets held by the canister, such as any ICP tokens or bitcoin held by the canister on the user's behalf. The controller, if malicious, can steal these assets. In other words, as a user, if you interact with a canister that deals with your assets, inspect the canister to know how it handles them. If you determine that the canister is storing assets in its subaccounts, ensure that the canister controller is decentralized.
 :::
 
-## Sole control by the Network Nervous System (NNS)
+## Black hole canisters
+
+A similar effect can also be achieved by setting the controller of a canister to be itself. In this case, however, you need to carefully verify that the canister cannot somehow submit a request to upgrade itself, e.g., by issuing a reinstall request. Here, code inspection and reproducible builds are crucial.
+
+Finally, a somewhat more useful solution is to pass control of the canister to a so-called [“black hole” canister](https://github.com/ninegua/ic-blackhole). This canister has only itself as a controller but allows third parties to obtain useful information about the canisters the black hole controls, such as the available cycles balance of a black-holed canister. An instance of a black hole canister is [e3mmv-5qaaa-aaaah-aadma-cai](https://icscan.io/canister/e3mmv-5qaaa-aaaah-aadma-cai) which is [thoroughly documented](https://github.com/ninegua/ic-blackhole). Note that the repository linked here mentions canister immutability, but this is a red herring. 
 
-The simplest option is to remove a canister's controller. Without a controller, the canister can only be mutated by the NNS via NNS proposal, assuming the integrity of the platform is maintained.
+## Verifying a canister's controllers
 
 A user can verify the list of controllers for a canister using [`dfx canister info`](/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#dfx-canister-info):
 
 ```
-dfx canister info ryjl3-tyaaa-aaaaa-aaaba-cai --network ic
+dfx canister info <canister-id> --network ic
 ```
 
-This will return the list of controllers for the canister with principal `ryjl3-tyaaa-aaaaa-aaaba-cai` (in this example, the ledger canister).
-
-A user can also obtain the list of controllers of another canister via a [`read_state` request](/references/ic-interface-spec.md/#http-read-state) to get the relevant [canister information](/references/ic-interface-spec.md#state-tree-canister-information), which includes the list of controllers. A canister cannot obtain this information.
-
-A similar effect can also be achieved by setting the controller of a canister to be itself. In this case, however, you need to carefully verify that the canister cannot somehow submit a request to upgrade itself, e.g., by issuing a reinstall request. Here, code inspection and reproducible builds are crucial.
+A user can also obtain the list of a canister's controllers via a [`read_state` request](/references/ic-interface-spec.md/#http-read-state) to get the relevant [canister information](/references/ic-interface-spec.md#state-tree-canister-information), which includes the list of controllers. A canister cannot obtain this information.
 
-Finally, a somewhat more useful solution is to pass control of the canister to a so-called [“black hole” canister](https://github.com/ninegua/ic-blackhole). This canister has only itself as a controller but allows third parties to obtain useful information about the canisters the black hole controls, such as the available cycles balance of a black-holed canister. An instance of a black hole canister is [e3mmv-5qaaa-aaaah-aadma-cai](https://icscan.io/canister/e3mmv-5qaaa-aaaah-aadma-cai) which is [thoroughly documented](https://github.com/ninegua/ic-blackhole). Note that the repository linked here mentions canister immutability, but this is red herring. The NNS is still capable of making changes to a canister that is controlled by a 'black holed' canister, or the black hole canister itself.
+If a canister does not have any controllers, it cannot be changed and is thus immutable. It can only be uninstalled by the NNS via NNS proposal, assuming the integrity of the platform is maintained.
 
-## Sole control by NNS and other governance
+## Control by distributed governance
 
-A more complex but powerful approach is to set the sole controller of the canister to a distributed governance mechanism. In this scenario, the NNS still has ultimate control over the canister even though it is not explicitly in the controller list.
+A more complex but powerful approach is to give control over the canister to a decentralized autonomous organization (DAO). It is possible to hand the control over to an [SNS DAO that is built into the platform](/docs/current/developer-docs/daos/sns/overview) or to build a custom governance. The advantage of the latter is that the governance of the canister can be tailored specifically to the canister or project that the canister is a part of. One can imagine different levels of complexity and control that such a governance mechanism may implement. In both cases, the trust requirements are moved to the DAO controlling the canister, where all of the considerations regarding code inspection and reproducibility apply.
 
-The advantage of using another form of governance, such as an SNS, is that the governance of the canister can be tailored specifically to the canister or project that the canister is a part of. One can imagine different levels of complexity and control that such a governance mechanism may implement. An example is the [SNS feature](/docs/current/developer-docs/daos/sns/overview) which allows developers to set the controller of their canister(s) to some governing canister. Using an SNS, the trust requirements are moved to the SNS controlling the canister, where all of the considerations regarding code inspection and reproducibility apply.