Enable Canisters to Hold ICP

[diegop]

Update: we are on track to submit NNS motion proposal on Wednesday September 15, at 15:00 UTC.

[ohsalmeron]

does this mean the start of DeFi on the IC?

[diegop]

I think there is some emerging Defi apps on IC already, but I think it safe to say this would greatly accelerate it.

[diegop]

NNS motion proposal is live: https://dashboard.internetcomputer.org/proposal/20588

[lastmjs]

@JensGroth

but nonetheless we are planning sandboxing canisters in separate processes in the future to mitigate the potential risk.

How long would this take? How intense has security analysis of the execution layer been?

I am feeling hesitant that there are obvious improvements to security that could be made (multiple independent security audits, bug bounties, process sandboxing), but that won’t have been made before we open up this capability.

And considering the main reason for this limitation in the first place is security, perhaps we should proceed more carefully.

What if we waited until one or more of the following were done, or perhaps made these prerequisites to deploying the change?

• Internal analysis of security of multi-canister execution environment within a replica, with publication of that analysis
• Multiple independent analyses of the above, with publications
• Bug bounties focused on execution environment for a sufficient amount of time
• Process sandboxing implemented

I would not underestimate how quickly honeypots of ICP will start forming within canisters, and hacks will do no favors for those hacked nor for the Internet Computer nor for DFINITY.

[Ori]

Relevant in here too:

@roman-kashitsyn

One part of the initiative to allow canisters transfer ICPs is to provide a stable, properly designed Candid interface for ledger.

[lastmjs]

I think the most important thing for me to understand is how involved and especially how long process sandboxing of canisters will take. This is an obvious improvement to the security of the canister environment, and if it won’t take too long (I am not sure what too long would be), then I think we should wait until it is implemented before moving forward with anything that will allow canisters to control lots of monetary value. This includes the Bitcoin and Ethereum integrations.

[northman]

“Canister controllers are not ledgered.” - is the objective to build a money washer if ICP transactions are not recorded in a ledger? Also, if A pays for a service through a Canister - how does one know the transaction completed correctly if there is no transaction recorded? I think I am missing something here.

I also wonder about node operator security requirements. SEV has not et been implemented. Are their any integrity constraints placed on node operators (physical security, operational security, personnel, etc)? No ICP transaction on the ledger will impact the risk profile of a node operator - it now shifts.

[flyq]

Don’t Trust, Verify

If there is a place to verify the logic of the canister wasm, then the crooks are hard to succeed. So this risk is acceptable.

At the same time, I think this kind of infrastructure is needed:

Some possible requirements of ​Verified canister:

1. Open source
2. Its logic conforms to its Ricardo contract description

[jzxchiang]

I totally agree that a “canister verification” service is absolutely necessary in the near future, one that can verify that a canister is:

1. Autonomous (i.e. black hole controller)
2. Running wasm code that’s compiled from some published open source code

It’d be even better if this canister verification service was itself an open internet service, i.e. an autonomous canister.

I’m not too familiar with a Ricardian contract, but from wikipedia it seems that it needs to be legally binding and human readable. I’m not sure how much that applies here.

[nomeata]

@jzxchiang

I totally agree that a “canister verification” service is absolutely necessary in the near future

Note that the system already provides the building blocks, and anyone can build such a service now. Don’t just wait for DFINITY to build everything you want, there is only so much one org can do here! Better let them focus on features that can’t be done by others (system features), and have the community build the ecosystem. I’m happy to advise anyone who wants to build this.

[benny]

@nomeata

Note that the system already provides the building blocks, and anyone can build such a service now. Don’t just wait for DFINITY to build everything you want, there is only so much one org can do here! Better let them focus on features that can’t be done by others (system features), and have the community build the ecosystem. I’m happy to advise anyone who wants to build this.

The above comment needs to be stickied and immortalized.

I’ve gone through the 5 stages of IC since discovering it (sometimes bouncing between them) :

1. Curiosity
2. Excitement
3. Invested
4. Doubt
5. Acceptance

This is for you! It was made for you, the community! Dfinity provides the match, it’s up to YOU if you want to start a fire for warmth and cooking or go burn something down.

It’s laid out in the documentation. This is a democracy. If YOU don’t agree with something, YOU have to vote, and help educate others in order to make an educated vote. The capability to follow other neurons will become so powerful! There will be parties established. There will be easily accessible voting records. There will be revolutions!

I accept. I accept that Dfinity has provided a stage and it’s up to us to execute a successful performance.

Edit:
If it matters to anyone, I voted no due to the following. Your risk tolerance might be higher, so please understand how it impacts you.

I think it would be unfortunate for someone to create a defi dapp with the general population assuming it behaves like other blockchains. I believe the other features should exist (immutability assurance and WASM/source code validation) before being made available for public consumption.

One could also vote Yes at this time, and wait for the next proposal (which will include the code updates). That way, you have more time to evaluate the impact.

@JensGroth

In particular, providing the ability check that a canister is immutable and the ability to verify the code of a canister are necessary features to allow opting in to a similar trust model to existing “smart contracts” that predate the launch of the IC. However, it must be stressed that this is an opt-in. Even with these solutions in place, there is a risk that people will treat mutable canisters as immutable smart contracts and fall victim to a rug pull. We would be interested in feedback whether this is an acceptable risk.

[lastmjs]

If canisters can break out of the Wasm sandbox, then the logic verification doesn’t matter.

[lastmjs]

I echo that basically all functionality necessary for this seems to be available now. You can check the controller of a canister, you can retrieve the hash of its Wasm binary, and…well this is the part that might not exist and is where the service come in: developers need to publish source code and provide an easily reproducible build.

I agree this is probably more of an application layer concern for someone possibly outside of the Foundation to tackle.

[lastmjs]

I’m sorry to be spamming the forum, but if someone could give me some insight into how involved and especially how long canister sandboxing might take, that would be great. I am waiting to vote based greatly off of this information

[diegop]

This is a very valid question. Let me ping to see which engineers or researchers are working on this to give a proper “order of magnitude” estimate.

[lastmjs]

I’ve voted no on this proposal mostly to make a point about security. If there is an obvious vulnerability that could lead to catastrophe, and an obvious solution, I think the priority should be to patch that vulnerability.

I would like to see canister sandboxing per process before deploying these features.

The same sentiment is reflected in this proposal: Direct Integration with Bitcoin - #56 by lastmjs

[skilesare]

I’ll take this post as an opportunity to note that we could move quicker on some of this if we had a test net to deploy to.

I voted yes but generally agree with @lastmjs. You guys should put a canister out there with a bunch of icp in it and see what happens. And by a bunch I mean like $1M. You need something that is going to attract the bug. It would be well worth the lost value if someone kills it or steals it.

[JensGroth]

ICP transactions are recorded on the ledger as is done now. So you can still check that you have made a payment to a canister. What does not go onto the ledger is when the controller of a canister changes.

[JensGroth]

Wrt your suggestions:

• We’re currently conducting two internal security analysis efforts, and intend to make the implementation proposal only once they are complete

• We have been working with 3rd party companies to review security of all parts of the IC. We are considering whether parts related to ICP on canister should be a priority for the next round, but it takes time (weeks up to a few months) to slot in.

• We are working on a bug bounty program

• I’d guess sandboxing to take several months (meta: I’ll take the feedback from this thread as a vote to give it high priority)