Сокращение latency и расширение канала (цель - 500Mbit/s на receive) при использовании tor'а для доступа к onion-сайтам, идеально - с сохранением производительности оригинального клиента. Будет работать на Ubuntu 18.04. Исходная версия для правок - 0.4.x. Источник запросов - libcurl. Тор написан на C, если что.

Я лично вижу такой вариант:
1. Поднять тор-ноду на сервере с тор-клиентом (до которой будет 0 latency и канал которой = канал клиента, т.е. по максимуму). Ограничить доступ к ней для всех других пользователей тора (каким-то образом... Возможно, не листить её для directory adversary?), чтобы они не отнимали канал. Разрешить там 1-hop (нужны правки исходников).
2. Разрешить 1-hop circuit'ы в тор-клиенте (нужны правки исходников), указать ноду из п.1 как guard, EnforceDistinctSubnets 0, NumEntryGuards 1
Это мой план. В торе я разбираюсь так себе, поэтому он может быть далеко не полным - или, напротив, фантастическим (у меня есть сомнения по поводу необходимости разрешения single-hop, от onion-сайта тоже же есть хопы, которые нельзя никак обойти\минимизировать (?), т.е. цельный сёркит будет уже не 1-hop, а 4-hop например; ну идея с нодой и клиентом на одном серве может быть неосуществима, наверное). Предлагайте своё ТЗ, которое закрыло бы мою потребность.

Имейте ввиду, что тор очень плохо поддерживает несколько ядер (NumCPU), так что лучше считать что один процесс = одно ядро. Это может означать необходимость нескольких клиентов (что просто), и, возможно, нескольких нод (которые все будут на одном сервере, но коммуницировать по разным IP, например). Сколько после ваших правок будет потреблять нода и клиент - я не знаю.

От вас мне понадобятся исходники с правками (+конфиг?), которые я по
вашей инструкции скомпилирую и разверну уже на своём сервере, где буду тестировать
уже с реальной нагрузкой.
Предпочтительный способ оплаты - любая крипта (но можно конвертировать на эпс\карту), предпочтительная рабочая связь - телеграм.