Node provider posts pseudonymously on this forum, asking innocently for help with technical issues, identifying himself as a node provider. Now anyone can contact him, just like it would be the case when node providers were publicly known.
Point is any node provider can be anonymous but doesn’t have to be. Any node provider can at any point make as much of his identity public as he chooses. Or make himself reachable. In other words anonymity of always optional. Hence, by definition, anonymity cannot provide any advantage against collusion.
Exactly. The threat is not honest node providers turning malicious after being contacted by some other malicious node provider. The threat is an attacker signing up as multiple node providers by using a bunch of strawman entities. And against threat non-anonymity is better. Because the more people can scrutinize the node provider applications the higher the chances to reveal the true identity behind them.
As you know, @victorshoup explained Threshold FHE on IC in yesterday’s R&D meeting. Is Threshold FHE scheme independent from the way that Gregory explained, FHE using vetKD for bootstrap?
Hello! Good news! The paper is finally online if you are interested to really go into the details
If you have questions, want explainers about anything in particular, or any other comments, let us know.
Some replies to earlier messages…
Hard to say. The design and integration of a full implementation is still being discussed.
However, the Crypto team is working on a canister interface that will allow to experiment with a test implementation. This should be ready soon™…
I have not looked too much into the details of drand. On the conceptual level they are similar. The most notable difference is that drand key shares are not encrypted. Also on the network / usage level they will be different. How far did you get with reading both? Happy to fill in any gaps.
Yes, @victorshoup’s work with Zama is independent. Rather than ‘bootstrapping’ into FHE, they are pushing the boundaries of FHE to allow it to happen onchain in a much more practical way. Very cool stuff.
We should seek to hide the network topology from the node operators, so that they don’t even know what subnet they are in. If they don’t know what subnet they are in currently, nor at any point in the future with node shuffling, it would become extremely difficult to collude with a small number of node operators in the same subnet.
Hey! That was a brief preview which we are wrapping up now. It should be ready soon, and we’ll organise a Community Conversation to talk through it in detail, show some of the use cases, and have some time for Q&A. The ‘mock’ canisters will be there as well for you to play around with.
Hi guys, we’ve picked a date and scheduled the second community conversation where we’ll recount some of the obstacles that vetKeys help to overcome, show the first demo, and preview an updated version of the encrypted notes dapp.
It will be on Zoom (recorded and uploaded to YouTube later) on July 11th at 17h30 CET.
I’m trying to play with this, I found a branch and this commit. The WASM code connected on the front-end and imitates the work of the code that will be implemented in the canister, but tpk is not used in crypto.js in any way on the front-end. I assume this is an unfinished version and should we expect commits before the demonstration?
Hi @rabbithole, it’s great to see your interest in already playing with this! Indeed, this is some preliminary and unfinished work. The intention is to have our demos ready and committed by the date of the community conversation (July 11). Hope to see you there!
I just watched the first community conversation and this looks to be exactly what I need to build out my use case. Thanks for working on this, and I’m excited to see, or maybe even contribute to, the second conversation. Looking forward to it too.
Looking at ZAMA’s announcement, it seems that fhEVM can perform threshold decryption with multiple validators and create anonymous ERC-20. fhEVM on IC already performs threshold signing with ChainKey, so wouldn’t it be possible to deploy EVM on IC if it is realized? Also, won’t we need fhWasm or zkfhWasm to do full-scale secret operations on GPUs, etc.?
Also, more to the point, fhEVM has only one private-public key pair, but I am guessing that there could be cases of high privacy data operations that require a private key for each user. Wouldn’t vetKey be a solution then?
@conorseed That’s great! Happy to hear if you what to share what use case you’re working on. In any case, see you next week for the next community conversation.
@dfisher and @hokosugi - thanks for the questions! I defer to @victorshoup for news on FHE. Re the last point, it would depend on details as usual, but indeed, whenever there’s a need to derive decryption keys on demand, it would be cool to see how vetKeys can be plugged in.
Hi all, just a little reminder that the Community Conversation Demo will start in a little over 24 hours from now.
Feel free to register here: Internet Computer Loading
Very cool project, I hope the current iteration goes beyond in browser encryption, as the first Motoko project did, which encrypted data in the browser cache.
Congratulations for the paper, I see the name of a Cryptographer friend there, bravo @gregory! And I see many names I recognize in the white paper, Victor S. is there too.
It is a powerful technology for sure. Looking forward to tomorrow’s discussion to know more about it. I only checked the Motoko example before, but this iteration seem much more ambitious.
@ais - dang! It was at 3:30am in my timezone and I slept right through my alarm Any chance it’ll be up on youtube quickly?
@conorseed That’s great! Happy to hear if you what to share what use case you’re working on. In any case, see you next week for the next community conversation.
Also happy to chat with you about this - maybe just not on a public forum. Is there a way I can reach out privately?
Any chance it’ll be up on youtube quickly?