Hi tnpxu, thanks for the reminder to give an update.
Our security reviews found a risk of subnet congestion. This could impact smart contracts, e.g., if a canister is supposed to transfer ICP before a deadline but cannot do it due to congestion. We are in parallel debating whether it is enough of a concern to be a blocker and also working on mitigations. I’d not want to commit to a concrete deadline, but I’m guessing in the order or weeks, not months.
15 Likes
I thought this thread would be interested in the update about project scope and design on the Sandboxing project tread: Security Sandboxing (Community Consideration) - #3 by diegop
3 Likes
Hi Jens, any update on this? Thanks!
would be great to have news on this as it is vital update in order to get ICP NFT projects onto the same playing filed as those on other chains
What features are you looking for? I’ve integrated ICP with my NFT auction. Code is at GitHub - aramakme/aramakme_nft_auction: This is the canister that runs behind the scenes and holds the NFT distribution licenses Project is at https://hwqwz-ryaaa-aaaai-aasoa-cai.raw.ic0.app/ Fell free to dm.
primarily auction functionality, I don’t think you can submit bids on NFT’s right now as canisters would need to hold the ICP that has been bid
I got around that by using a reverse auction. Because the price starts high and decays to low, no one has to pay until the price is where they want it be…so the ICP can go directly to an account. This is not as good if you are a market place taking a cut, but this is decentraland and we’re supposed to be cutting out middlemen anyway. Artists can use it to get paid directly and not have to worry about split cuts and waiting on payouts.
There are other creative solutions. If you have to do a split cut you can just do two transactions before transferring…if you do the UI right the user won’t really know…well…maybe with plug they will. You just need to confirm the transactions with the ledger canister before taking action.
1 Like
Really you want multiple people to bid on a sale and and for people to see the bids, this also gives you a floor price for average bids. The dutch auction is more like a buy it now option , its a great option if there is no other way to do it.
Hi everybody, we want to hold back on this feature with a new ETA of January.
There are two security reasons: subnet congestion could affect availability and we have after internal discussions become more wary about the risk of Wasm jailbreak. The latter concern is addressed by the Canister Sandboxing feature but unfortunately incurs a delay.
10 Likes
Sounds wise to me. How will subnet congestion be addressed by January?
4 Likes
Holding this back might indeed be wise but the community has voted on it and those security risks were known about before the proposal was put in place for a vote. The proposal people voted on even said:
Some of the mitigations, e.g., sandboxing of canisters will take time to develop and will not be ready before this proposal. We do not consider the mitigations and additional security features as blocking the proposal. But we consider the ability for canisters to transfer ICP to be in an experimental phase. We encourage experimentation with small amounts of ICP but discourage large amounts of ICP.
So this delay is just ignoring the proposal that won 99.98% of the vote? I’m not trying to be antagonistic here, just concerned NNS votes can just be ignored.
11 Likes
That is a very good point
2 Likes
It’s important I accept responsibility here: I made the call and told @JensGroth that his project being blocked by canister sandboxing did not go against the intent of the NNS proposal which in my mind was “we trust this team/plan to execute this project”. Jens did ask me if I thought this would go against the proposal so I do want to make sure i emphasize that he and the team take this very seriously.
Did I make the wrong call? Possibly. I am always willing to accept responsibility and iterate.
I do not want to over-talk, but I do want to characterize that because I saw the intent of the NNS proposal to be about trusting the particular team of experts to design and build the plan.
As all plans change as they make contact with reality, I saw the blocking delay as “still within the scope of the original plan”. If the change had been “we decided to NOT hold ICP”, I think that would go against the intent of the plan. When said experts went from “we think the risk is manageable” to “we no longer think the risk is manageable”, I thought that showed intellectual honesty.
So lay it on me. I am here, and I am learning. Fwiw, I think this is a good opportunity for community norms to emerge.
So what do folks think?
-
Did I make the wrong or right call? both are very possible.
-
Is the problem in the intent I understood or communicated of the NNS proposal? Very possible.
-
Do we need another NNS proposal to change the plan? Not unreasonable.
-
Do we need to better encapsulate the possible ranges of the plan and what is acceptable changes or delays?
11 Likes
We are all learning as a community. That is the good part. There is nothing wrong in admitting that we were wrong (“we now think that risk is not manageable”). This is the point of having an vested community. that is, at times, quite vociferous. So, IMO, I think you made the correct call.
That said, we cannot ignore NNS votes. I believe that we should create another proposal to negate the original vote (and see if it passes). There might be projects that might be dependent on canisters holding ICP…so we will see. In the future, have this as the explicit plan in case of severe adverse findings as opposed to individuals calling the shots.
As a general rule, there are “unknown unknowns” that will creep up in any project. So we should be ready to tackle this at every step. This is in contrast of writing papers/participating in 50 different conferences (the development philosophy of another chain which shall not be named) and then taking years to develop even a semblance of “smart contract”.
Specific to this proposal, it could have been worded differently because we knew about the risks (“known-unknowns”). In that case, the action might have been the same; with a forewarning in that proposal…“if we find, upon further investigations, that such risks become unmanageable, then we will…”
7 Likes
I agree with this approach and I am in favor of holding another vote. It would be nice to have a formal record of this change.
2 Likes
I don’t think you’re wrong for addressing a security concern.
Does this go against the proposal? That depends. Did Dfinity discover some new information that changes the original risk assessment; or did someone just decide they were no longer comfortable accepting the risk? I think the latter would be considered outside the scope of the proposal.
However, since Dfinity is the team building this feature, I think it is completely acceptable for you to raise a concern and request a new vote after providing your rationale.
Definitely. We need a record of the change
I don’t think so. I think this proposal was unique (so far) because it included a statement about risk acceptance. If it wasn’t for that statement I don’t think anyone would have a problem with the delay.
6 Likes
I’d concur that if security concerns have shifted a vote to amend should take place.
That being said, this going to say a lot about this community. We have a wide range of folks varying from technologists to opportunists and a bunch along different vectors. The challenge with democracy is that you get a lot of uninformed people weighing in. The liquid part of the NNS can fix some of that but I don’t think it is out of line in suggesting that that component is basically not organized and not to be relied on yet.
Basically, I don’t think we can trust the risk profile of the community on this just yet. The devs that need this don’t have a lot of ICP(yet) and the folks that do have a bunch of ICP probably don’t understand what is at risk technically. In a well-informed and mature ecosystem, you can probably trust the “market of ideas” to make the right choice…not sure we are there yet.
Will be interesting to see what happens.
10 Likes
I don’t agree. This ommunity may not be full of IC developers but that does not mean they lack the competency to assess risk.
If the developer organizations believe that the security risk is to great they should present their case to the community. Cycle_DAO already started doing this NNS Proposal: Enabling Canisters to hold ICP | cycle_dao
I don’t think it’s fair to pick and choose when we are going to listen to the community. That’s not how this governance system is supposed to work.
2 Likes
I don’t disagree. This 100% is on the emerging institutions to provide information in a digestible format.
I’m not saying we pick and choose. I’m saying we addressed any organizational risks head on. They are as real and valid as the technical risks.
2 Likes