We have just submitted proposal 142743 to create a new confidential subnet! This follows our first SEV-enabled subnet, which has been running smoothly and securely for almost six months now.
We considered whether to transition an existing subnet. However, we propose to create a brand-new subnet instead to ensure maximum security as this allows to start with a completely fresh state. Transitioning an existing subnet would mean carrying over old, non-confidential state, which could compromise the strict security guarantees we want to achieve.
If this is running the Mulitdex would it have threshold curves signing enabled? Would it have a key like key_3 or something or we still have two the test and fiduciary?
The proposal states:
“Initially, it is intended to host the upcoming MULTI/DEX, which benefits from the stronger security and confidentiality properties that this environment provides.”
does this mean it will be authorized only not open to public ?
why not just use the 1st existing one with only 1.1 GB state and 40 something canisters basically low to no usage so far ?
Thanks for creating a post for this proposal @rbirkner
I see that the proposed subnet type is “application”. Wouldn’t “verified application” be more appropriate as a subnet that is intended to run one specific product. I think that’s exactly what “verified application” subnets are supposed to be (whether or not some of them haven’t entirely kept to this definition). I’d expect it to be the right type in this scenario.
Given that this isn’t going to be a “system” subnet, and the cycles for its canisters will therefore need funding, presumably DFINITY will be responsible for funding the cycles?
Once the core components of Jupiter Faucet are blackholed, I wonder if DFINITY would consider making use of this to ensure MULTI/DEX is perpetually funded with cycles, permanently. This is Jupiter Faucet’s core principle, such that users are no longer dependent on any maintainer keeping a product topped up (as though it were on a “system” subnet, but with the benefit of ICP burn).
Will it be authorized? Why application and not verified application?
Initially, there will be one authorized principal to install the MULTI/DEX. However, in the longterm, the subnet will see more applications and will not be dedicated to the MULTI/DEX.
*Why not use the existing SEV subnet (re2t4)
In general, there should/will be more SEV subnets. We have the code, the tech and also the confidence since the first one has been running without issues for almost 6 months. To get more SEV subnets, there are two ways: (1) replace all nodes in an existing subnet with SEV-enabled nodes, and (2) create a new subnet with only SEV-enabled nodes. For security reasons, it is better to create a new subnet without any “baggage” from the old times. This will of course not work for subnets that already have a lot of canisters and state. Soon subnet deletion will go live, which will allow to delete existing unused subnets and, potentially, “replace” them with SEV subnets.
DFINITY will be responsible for funding the cycles
Exactly, MULTI/DEX will be launched in play mode and DFINITY will be providing for the cycles consumed by the canister.
This will require a Set Authorized Subnets proposal, and given that today is already Thursday and Dfinity did not vote yet on this, I think it’s safe to assume it will be a Monday launch at earliest.
Looking forward to the subnet deletion option.