Proposal 142743: Creating the second SEV-enabled Subnet

Hello everyone,

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.

Thanks a lot for your support. Happy voting!

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?

At the moment, there is no plan for the subnet to host another threshold signing key.

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.”

  1. does this mean it will be authorized only not open to public ?
  2. 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).

https://x.com/JupiterFaucet/status/2069836947653005478

Hello everybody

A few answers/comments to your posts @ZackDS and @Lorimer:

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.

Proposal #142743 — Zack | IC Hub-T

Vote: Adopted

Reason:
Creates the 2nd TEE-enabled Subnet on IC, initially to be used by MULTI/DEX.

Payload:

canister_cycles_cost_schedule:"Normal"
sev_enabled:true 
subnet_type:"application"

:white_check_mark:

All 7 nodes are GEN2 Healthy unassigned.

  • HongKong 7bleq has TEE active.
  • Seoul bi2ik has TEE active.
  • Melbourne oqbh3 has TEE active.
  • Gauteng 5jeex has TEE active.
  • Warszawa 476bb has TEE active.
  • San JosĂ© gfeqv has TEE active.
  • Navi Mumbai s3hb6 has TEE active.

:check_box_with_check:


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.

Hello everyone,

the proposal just passed and the second SEV-subnet has been created: x4jtx-5dnbo-v3exa-vzamo-teufh-qsiit-txx4g-mi76n-ckrfl-oc5a6-nae. The proposal to authorize the principal will follow shortly.

We have just submitted the proposal to authorize the principal to deploy MULTI/DEX:
https://forum.dfinity.org/t/multi-dex-the-worlds-most-advanced-defi/74316/7

What would be the latency of trades given the consensus?