Tor uses multithreaded crypto already: depending on the speed of your processor, you can get up to 400 Mbps per instance (250 Mbps is typical).
Here i see a pending project: https://trac.torproject.org/projects/tor/ticket/1749 and plans about that: https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/Multithreaded... are stalled from years because of complex implementation (and the current possibility of running multiple daemon lower the priority, of course).
Maybe Tor uses multithread for some activity, but actually it's not a real/full multithread implementation from what i understand. Otherwise, what are the reason to run multiple daemon on the same server like a lot of people do with high-capacity 1gbit/s server does?
If i have a 10gbit/s unmetered port with a 24-core CPU, i'm forced to run multiple-daemons on multiple ip to use it at maximum. And the world see a lots of relay (within the same Family, of course). This is a wrong approach for me: - overhead OONION/Atlas. I know a guy that run over 30 relay on 3/4 physical machine (so for OONION/Atlas, 30 relay to track, collect stats and so on). - requirement to Tor relay volunteers to obtain many IP address to run high-capacity servers. - configuration issue, for example about running multiple-daemon with systemd.
so i'm thinking if can exists a better, easy solution. I just want to be constructive, i'm a open-source tools developer in my spare time.
These things will break:
- if multiple tor daemons update the same onion keys at the same time, the key files may get corrupted or the cross-certification may not refer to the keys being used. This would break all Tor instances for any circuits after a week or a month (depending on the tor version).
- your relays will place additional load on the directory authorities by uploading multiple identical descriptors
- if these descriptors ever get out of sync, they will replace each other, causing unpredictable behaviour
Because clients expect to access the same process with the same identity:
- your relay will not be usable as an HSDir
- your relay will not be usable as an Introduction Point
- your relay will not be usable as a Rendezvous Point
Honestly i don't know well this kind of details. It's the reason of this discussion with people like you. Maybe it's possibile to simply develop or patch specific options to obtain the objective to "made easy" an high-capacity server. Probably more easy than the works linked above about the Parallelizingcellcrypto. For example, "uploading multiple identical descriptors" maybe be simply avoided with an option that identify the 'master' daemon, other daemons simply skip the descriptors upload phase. Or some kind of syncronization channel between daemons, which currently do not communicate with each other.
Anyway, thanks for your feedback, i will study your details. Ciao! Fabrizio