Enable Canisters to Hold ICP

I feel like this problem (Canister unable to transfer ICP) has been blown out of proportion. ICP, after all, is just an application run by a canister on the NNS subnet. Anyone, I mean literally anyone, can build a canister to issue tokens, like the ICP. Developers don’t have to be held back by DFINITY foundation. For example, Wrapped ICP already exists, why don’t we see more utilization of that?

The only difference between a canister based token X and ICP, in my opinion, is that ICP is already traded on major exchanges and has a value in the market. So why aren’t we working on to bringing value to some token X?

  1. Build a bridge between IC and some other chain, and bring other chain’s token over. For example Wrapped ETH, or Wrapped ERC-20.
  2. Work on the adoption of Wrapped ICP.
  3. Create a new token X for every ICP burned (to cycles). This creates an exchange between X and cycles.

Any of these 3 options will work, and do not need the blessing from DFINITY foundation. The only native token to IC is cycle. ICP is only for NNS governance, and I’m feeling perfectly fine if we can ignore it. My question to the community is, can we?

2 Likes

Although we have a better way to wrap Ethereum token into ICP without bridge. But this is really a temporary good method. After all, the integration with bitcoin and Ethereum takes a lot of time .

If I read you correctly, Origyn has already tokens on IC. The issue is that community does not know what the actual issues were while testing this feature. Would it be applicable to other tokens (i.e. OGY) already on IC.

As you mentioned, ICP is already trading on the market. Certain use cases depend on the liquidity of the token and also it’s market cap.

Additionally it is much more important to learn from lessons; so that we try not to repeat them in the future (i.e. for Threshold Signatures, BTC and ETH integration etc)

2 Likes

Yeah I’d be curious what token standard they adopted, or whether they rolled with their own.

There are a lot of tricky issues with implementing a secure token canister… that’s why it’s probably safer for the community to agree on a token interface that everyone can then use and interoperate with, like how Ethereum did it.

Hopefully DFINITY can chime in at some point… see this.

2 Likes

We had trouble getting one of our testnests to work, and the vague “a few weeks” was due to not having a good estimate of the time involved to get it up and running. Based on my latest information I’m hoping it will be shorter.

4 Likes

We have made the preparatory proposal 30232. This proposal does not enable canisters to transfer ICP. The proposal tweaks the ledger to improve safety. In this proposal the ledger will be upgraded so that only whitelisted canisters (all residing on the NNS subnet) can receive transfer notifications from the ledger. This is to ensure the ledger will not get into a situation where it is waiting forever for a notify-reply from an outside canister. We are also updating the archiving mechanism to keep blocks in the ledger until the archiving canister has confirmed receipt. Finally, we are updating some dependencies in the ledger canister. The main proposal to enable canisters to transfer ICP will follow later.

16 Likes

Expect a new interpretation, icp will usher in a new beginning. For how whitelist containers are assigned, perhaps a big question is, who gets priority access to the test?

3 Likes

Is proposal 30232 means proposal 20588 invalid ?

1 Like

It’s the weekend now, how about the progress?

We will submit the proposal to allow canisters to transfer ICP on Monday November 22, 2021 at 15:00 UTC.

This proposal implements community motion 20588 to enable all principals including canisters to transfer ICP.
To vote YES means you agree to adopt the proposal.
To vote NO means you disagree with or want to delay the proposal.

Voting: The IC uses a wait-for-quiet mechanism such that if there is a stable preference for adoption or rejection and a 3% threshold of votes is met the vote can be decided after 24 hours. If no stable preference appears, wait-for-quiet keeps extending the deadline up to a maximum of 48 hours. The DFINITY Foundation will abstain from early voting to let the broader community’s preference be expressed.

Performance: During testing we saw around 7 seconds latency in ICP transfers.

Integrity: We are not aware of any ways to do a Wasm jailbreak or otherwise break the integrity of ICP on canisters. We believe that without mitigation there would be high risk of a Wasm jailbreak within a 12 months period as in the past there has been a bug of the sort that could potentially assist an attacker (the IC never used the affected version). We are implementing sandboxing of canisters to guard against Wasm jailbreaks with an ETA at the end of December.

Availability: In our security analysis we looked at the deterministic replicated state and identified some general risks, which I have earlier referred to as ‘congestion’. The impact of those could be e.g. be a delay in a canister transferring ICP or a user input not being delivered to a canister smart contract. We have mitigated the highest priority concern, which was that inter-canister messages were prioritized over external ingress messages and hence flooding a subnet with inter-canister messages could cause a DoS of external users, by implementing a round-robin schedule between different types of senders. We have a mitigation for the second highest priority which we expect to roll out in a few weeks, and a mitigation for the third highest priority in the works. The risk with lowest priority is not yet resolved. Given we have found several risks it is reasonable to assume that additional unknown risks affecting availability exist.

28 Likes

I am not sure about how this categorization of “high risk” in Integrity came from. I think that the reasoning must be made transparent because of attribution, in part, to a bug (see below).

The bug, in question, specifically refers to “a potential sandbox escape in a Wasm program”. Not sure about how sand-boxing,as a mitigation strategy, would solve that.

2 Likes

Thanks for the update.

A couple questions:

  1. Can you explain where the 7s latency comes from? Regular update calls are advertised to complete in <2s, so I’m curious what the source of the remaining 5s is.

  2. Is the prioritization of inter-canister messages over external ingress messages a universal problem across all subnets, or does it only affect the ICP canister and/or the NNS subnet?

  3. You mentioned a couple other bugs, including a “second highest priority”, a “third highest priority”, etc. Can you briefly describe what they are?

  4. This would be a perfect use case for a fully open sourced IC codebase, as suggested by this post. If this proposal is indeed high risk, I think it would probably be best if we all could take a look at the PR before voting.

Thanks!

4 Likes

The bug, in question, specifically refers to “a potential sandbox escape in a Wasm program”. Not sure about how sand-boxing,as a mitigation strategy, would solve that.

Yes, I should clarify there are two layers of sandboxing we are talking about. WebAssembly provides sandboxing to ensure the code cannot be modified and that data is contained within allocated memory. The risk we want to mitigate is jailbreak from this Wasm sandbox.

Sandboxing of canisters is another layer. The idea is to use process isolation. Each canister will run in its own process. So even if malicious canister code manages to break out of the Wasm sandbox, it is still only affecting its own isolated process, i.e., captured within the canister sandbox.

We have a thread for discussing canister sandboxing here.

5 Likes
  1. Can you explain where the 7s latency comes from? Regular update calls are advertised to complete in <2s, so I’m curious what the source of the remaining 5s is.

There are at least two rounds of consensus involved. A canister sends a transfer request to the ledger, which need to go through consensus on the NNS subnet to reach the ledger (and the NNS subnet runs at a slower speed than other subnets to prioritize stability). Then the response from the ledger needs to go through consensus on the canister’s subnet before the canister knows whether the transfer succeeded.

  1. Is the prioritization of inter-canister messages over external ingress messages a universal problem across all subnets, or does it only affect the ICP canister and/or the NNS subnet?

It affects all subnets.

  1. You mentioned a couple other bugs, including a “second highest priority”, a “third highest priority”, etc. Can you briefly describe what they are?

I’d prefer not to not discuss them until resolved. But generally: affecting availability, related to deterministic replicated message routing and execution, and not specific to ICP on canister.

  1. This would be a perfect use case for a fully open sourced IC codebase, as suggested by this post. If this proposal is indeed high risk, I think it would probably be best if we all could take a look at the PR before voting.

Totally agree. For ICP on canisters, note that the proposal only affects the ledger canister (open source) slightly; it upgrades the ledger canister by removing a condition that canisters transferring ICP must be whitelisted. We do not see much risk in the ledger upgrade by itself. The risk is whether there could be problems in the interaction between the ledger (open source) and the replica. But the replica (the platform itself on which the canisters run) does not change during the upgrade of the ledger canister.

3 Likes

Not sure that I completely follow your reply below.

However as i understand it, this high risk is perceived is from layer 1 risk, but the canister sandboxing is addressing a layer 2 risk. So currently there is no current mitigation for the layer 1 risk. Is this correct understanding?

1 Like

Perfect! So when should we expect to see the fully open source IC codebase?

1 Like

They’re addressing the same risk. The 2nd layer, process isolation, is a backup in case the 1st layer of defense, Wasm sandbox, fails to contain the attacker.

2 Likes

You can see the IC open source code here. The path to the ledger is here.

3 Likes

Is there a way to vote from inside NNS Dapp?

1 Like

When can we hold ICP in ordinary canister

2 Likes