I edited above that both busy.org and steemit.com were DDoS attacked, but some other sites worked and services using nodes directly such as exchanges were up.
Are you telling me the design of these sites is loading data from the blockchain by way of passing through the centralized website instead of directly to the client via a WebSocket?
That does not make any sense!
The website for busy.org was loading just fine. It was the user data from the blockchain that was not working. Thus I logically concluded that the blockchain nodes which serve data were DDoSed.
Are you saying that there is centralized caching of the data? So that would be design flaw.
websockets connect to a web server (a websocket server is a web server, by definition).
Full nodes and servers, effectively same thing if we want them to be.
The point is having lots of them (and having asymmetrical costs[1] anti-DDoS in the design), so that access isnt centralized.
That is the point where it gets DDoSed. The static web content (javascript code, etc.) is much harder easier to serve up and harder to DDoS.
There's no 'centralized' caching of data in the sense that anyone can run their own web server and a node and it doesn't rely on any other.
From the users perspective that is centralization. The users client should be free to select any of a plurality of nodes to grab data from. And the list of nodes should be permissionless.
It is also possible to just run a client that doesn't rely on a remote web server for UI although unless you are also running a node you will be relying on a remote web server for the web socket and susceptible to DDoS. Some people have done the former and avoid all interruptions related to web servers and web services, although there isn't any user friendly way to do that (requires installing all of the front and back end software yourself).
Well if you make a popular client that does that, then the attackers will simply attack those full nodes as well. As I said, the only distinction between nodes which are webservers and those which are not, is a matter of choice of the designers of Steemit, busy.org, etc...
The Steem DPoS blockchain has never been down since some software bugs crashed it once or twice in the first few months.
Because afaik (I think perhaps you told me) the IP addresses of the DPoS delegate witnesses (i.e. the consensus block generating nodes) are a very tightly held secret amongst the whales. Then there are lots of whale controlled nodes on the perimeter to absorb the DDoS attacks. And the perimeter is what I assume we are talking about right now?
The point is that the system is not permissionless for nodes as is the case for proof-of-work. You depend on whales and their secrets. If whales start fighting each other or get attacked by a powerful entity personally, the system is not real-time resilient. It may or may not be resilient after there is a vote. It can actually go into complete stall (as all Byzantine agreement systems do, including Byteball) if no grouping has 51% of the voting power and the liveness threshold is not met. (I am aware that one can vote for more than one delegate witness at a time)
As Vitalik pointed out, the usage has been quite small. Scale and up then the fireworks are more likely, because the incentives to attack it will be much greater.
[1] Bandwidth attacks are asymmetrical in favor of verifying nodes because said nodes do not pay for incoming data. So I am referring to the cost of verifying the signatures, which in the case of elliptic curve cryptography is asymmetrically in favor of the attacker so it is better to turn this into a bandwidth attack (for the attacker to send more data at his cost than the cost of verifying the signature, but what if the attacker has botnets and does not pay hardly anything for bandwidth). And Hashcash-style proof-of-work as anti-DDoS is not viable because it is asymmetric in favor of the attacker versus the legitimate users. Throttling by IP may be ineffective as IPv6 is adopted. Fast signature verification becomes very important in the future (unless the economic size of the system dwarfs botnet bandwidth value) and DPoS centralization remains a separate problem.