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) :
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.
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.
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.
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
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.
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.
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.
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)
Are we saying that the rollout plan is to be extended until the end of sandboxing? I.e. even if the vote passes, it is unlikely to have the code updated by the Week of September 27, 2021 (as per the timeline above)?
I understand you probably realise this, but isn’t the issue that some party over a long period of time, say 12 months, could find the owners of node providers and bribe them to run a different consensus mechanism. By shuffling you mitigate this long-term threat? Thanks.