So you’re saying that your team have independently set up and successfully run an Internet Computer subnet both across VMs in the cloud, and also machines locally.
What do you think the value offering for Utopia is if this is such an achievable feat?
You’re the only team I have ever heard of, outside of DFINITY, who claim to have done this. Huge amounts of work went into this in DFINITY.
Yet I’ve never seen anyone in your team review a single ICOS proposal. I do not believe a single ICOS release has ever been run (outside of DFINITY’s offices) before it actually gets deployed to mainnet. Reviewers confirm the build hash and review the code, precisely because what you’re claiming to have done hasn’t been feasible.
Would you like us to give a tutorial on it? It’s not in our mandate to review ICOS releases, the only one we did was when one of those bricked our canisters and several others, but we don’t have scope for this.
Maybe you could find those ‘lab notes’ and publish them then. As mentioned, even reviewers don’t run the ICOS release before it’s deployed. If you’ve got the answer it would be a great help to the governance of the network
What do you think our lab notes would show you or not show you? Why not just ask a straight question of the specific problem you are having exactly, and honestly we have had enough with this slithering either engage productively with clear questions and polite asks and we will probably help you
Of course it’s relevant. It’s an extremely strong claim made by the team behind the proposed SNS that is to be closed source until funds are with those with lofty claims. It was also given as a reason (by the team) as to why they should be able to launch a closed source SNS.
This claim deserves interrogation (many of them do actually but this is the first one I think is particularly easy to challenge).
If it is true, then it would be very easy to address the questions above.
Even though your questions were outside of the repo scope, verifying work done in the repo is relatively easy to those competent in it.
However, since this will help you in governance and lessen your dependency, we have passed your questions to the team with the request that they spin it on bare metal as well and share the process how it went issues, libs, network etc and maybe give you an ai skill file for it
ICP is not a rocket science, if you know how it works, you can replicate it.
Can Menese have option to make swap pools in that protocol? I do like ICPSwap, but when core founder sold lot of tokens, they might look for exit, it makes future unclear for ICPSwap. As we have small projects, we need option to migrate to somewhere when SHTF. This is why DEFI cant grow, future is unclear on every project.
We do have the primitives for it, like our own AMM or the CLMM the runs cloak it was originally designed for this. If there is need in the community we can open source the CLMM repo either add to it this sns for the community or we can even launch it separately and airdrop most of its tokens(without sale). It’s possible and we do want primitives like this out in the public because it can support our shielded ledger tokens. That being said, the multi dex could be also suited for this, the CLMM is going through its 3rd security review before release it should be out in August from 7th-10th
See when you put that way, you get us excited we love getting places where no else has. Here is an active subnet carrying the NNS(it’s just four nodes we spun up for educational purposes), you can query the subnet and confirm the build vis a vis DFINITY’s commits and hashes. Obviously this is for RnD purposes we can’t build our critical infrastructure without understanding how the chain works.
Funny thing is, this was the most trivial part in our work really, kinda shows both our competence and commitment to the tech I mean it kinda of also shows the review process can use this and probably can avoid our canisters outage which had lasted for hours until we diagnosed the release error root cause.
If we have enough time outside developing our infra we might help the reviews. Now we are okay if you or those interested want us to deliver a tutorial on how do it(maybe end of next week one of our engineers can walk you through it), docs have some issues and obviously you need some engineering know how to go around this. The subnet will be up for a couple of days, maybe 36 hours then we have to shut it down. When we are in office next week, if time allows could use our own in house infra for this but it’s the same process really.
Query any of the four nodes; they answer independently and must agree:
Thanks for putting together a demonstration @MeneseProtocol.
Just to clarify, you’re claiming that this is a subnet actively running the ICOS on 4 nodes that you yourselves manage (not a cloud engine)? An you’ve directly used Setup OS to install Host OS, which has also successfully booted the Guest OS, and these nodes are now successfully processing blocks and reaching consensus?
You’re also running your own instance of the NNS which has registered that subnet?
This specific subnet yes has all of the above(blocks, DKG, canister behaviour) plus installed an NNS, we don’t have long running subnet, we just spin them up for RnD purposes like our experiments around increasing signing outputs using GPU or FHE-GPU or in deterministic inference. But yes this is for all intents and purposes a subnet outside of the traditional system..actually correction from the team: the process does not have setup OS we use a different method on bare metal
I wasn’t aware that this could be done without a lot of difficultly. Maybe the licensing aspect has always been the main blocker to reproducing the IC.
If this is exactly as you say, it would be a huge benefit to the IC to independently run new ICOS releases before the NNS adopts them (confirm that it runs and your canisters continue to function under whatever test conditions are relevant to you).
I think that would really be one of the best things for NNS governance and ICP decentralisation that I’ve seen before.
It is definitely not straight forward, but we would be happy to support in this, perhaps the community can maintain a test subnet for testing purposes.
It took us a few hours and a few sanity checks when our canisters went down and trying the latest release and testing it was the clue we got, so would definitely help in terms of resilience.
We will prepare full documentation on how to do it and organize a small tutorial for anyone interested Wednesday-Thursday
Very much appreciated, looking forwards to it. Been a long time since we ran a replica in a VM with bunch of flags for hardware checks and it was a pain to set it up even with the help of Dfinity team, lot’s have changed since then even prior to any testing and rewrites for CE.
Genuinely interested in this will keep an eye out.
Yes that’s why we had to go around Setup OS but we have now several tools for it, and we isolated vendors that community members can sign up easily without KYC and spin up nodes with those tools(it can be done cheaply)
We do have a subnet running right now that we would want people to help us test out maybe it’s a GPU infused subnet, this subnet is being tested for canisters to hold weights and each 2 nodes can verify each other…it can be 3 or 4 but we sought a subnet can run maybe two ai model open source(the choice of 2 is primarily about cost and return to those running the nodes)..having you guys run experimental nodes(with GPU) would make our infrastructure handling easier as well. No promises here we are still testing it out we did reach 131k limit
Awesome stuff. My scepticism may have been unfounded.
I’m looking forward to seeing this, thanks.
I thought a little more, and given that I’ve been granted access to your review repo, if I’m eventually able to verify the build for each of the canisters you will be decentralising in the SNS launch, and can then also run a frontier model against the repo (and attack vectors or centralised dependencies aren’t detected), then I’ll gladly reconsider voting to support your SNS launch - under the expectation that the source code would be released publicly after a successful launch.
