Is there any testing on this? Like the most ideal number to form a GROUP_SIZE?
There will be! But that will only make sense once Disjoint Groups and Data Chains are implemented. Probably the criterion won’t be just a number in the end. It will be more like: If the group has three very good nodes (have all the data, have been reliable for a long time, etc.) in each of the two halves, then it can be split.
So a GROUP is only as fast as the 62,5% fastest nodes of that GROUP. Is that right?
Yes, but that affects only the part of the message that needs to be sent in a secure way, i.e. usually just a tiny hash value. The message itself will still take only a single route, and that gives us the opportunity to optimise for speed later.
And it won’t affect Get requests for immutable data at all, for example, which are sent from a client directly to a group. For those, it’s enough if one group member responds, because the data can be verified with its hash alone.
Can I pick a faster node out of the routing table to PUT the data to the network?
The client can’t pick a route or an individual node for storage, and Put requests will need to be cryptographically verified. However, that verification will only be the hash, and the exact route the full message takes is something the network could potentially optimise by itself: The new group definition leaves a lot of freedom when choosing the route, as it determines only which group each step belongs to. We could then choose the fastest (least busy, most reliable, etc.) member of that group.
Couldn’t you perform a denial of service attack on all the members of the group pretty easily?
I don’t think the change in group definition makes a difference for denial of service attacks. If anything, it will make it easier to identify misbehaving (e.g. spamming) nodes and disconnect from them. Also keep in mind that nodes won’t just accept a connection from anyone, so an attacker can’t just - even if they know their IP addresses - connect to all members of a group.