Hello @blagoj. Thanks for the thoughtful response!
Also what is your opinion on other attacks, for example getting to know validator’s phyisical IP addresses by other means and just DDoSing them periodically? For example (let’s ignore the practical feasibility for a second), if SSLE is in place, but we obtain the IP addresses of the solo beacon node validators (i.e home stakers) and DDoS them periodically we can do some damage to the network (the question comes down to what is the probability of having the IP addresses of the validators that should propose in the next X slots).
My main point is, are there any known edge cases where WHISK and SSLE do not help?
This is an interesting concern about potential sidesteps that an attacker can do. In particular, even with SSLE, an attacker can indeed enumerate and blind-DDoS the entire set of home stakers. Given the current network size, and assuming a strong adversary, this could even potentially be doable. Hopefully, as the network grows (it should grow, right?), this attack would become well out of reach.
Attacks like this highlight the importance of non-SSLE solutions for the short-term future. For example, if validators use separate IPs for attestations and proposals, then an adversary wouldn’t even know what’s the IP address to DoS.
The question here is, what is your opinion on practicality on consensus layer vs network layer changes?
If we can provide network level privacy, does SSLE and Whisk become obsolete?
As mentioned in the SASSAFRAS section above, networking solutions can get pretty hairy both in terms of design and implementation, but also in terms of security analysis. When it comes to networking and mixnet-like solutions we are also grinding against the four seconds interval of publishing a block, so as our networking becomes slower, the harder it becomes to satisfy that constraint. Finally, it can also be a challenge to encapsulate certain complexities of the networking stack as it grows and tries to satisfy more requirements.
It would be useful to hear from people more familiar with the networking stack of Ethereum on how they feel about SASSAFRAS-type solutions. Do you have any further insights on this, @blagoj?
What are the next phases of the Whisk proposal, what are the requirements for it to become part of the consensus layer specs (if of course this is desired)?
Reducing complexity is where it’s at right now. Ideally, SSLE would be a tiny gadget that provides security, and not a complicated beast.
We are currently still exploring the space and figuring out potential improvements to Whisk, but also researching potential alternative simpler designs.
We are also working on documenting and explaining the Whisk zero-knowledge proofs since they are one of the biggest sources of the complexity of this proposal, altho its fortunately well-encapsulated.
As we get increased confidence that Whisk is a good solution to the problem at hand, we will attempt to merge it as part of the consensus layer specs.
Cheers!