rav_pr

iSCSI в общем случае не будет работать через интернет, из-за задержек. Можно потюнить ожидаемые таймауты, и оно КАК-ТО будет работать, но тупить будет немилосердно, и всю систему может тормозить тоже. Рекомендации лучших собаководов -- iSCSI-трафик не должен маршрутизироваться.

1. 102кб. Размер файла подписи вроде может варьироваться, но несколько штук должно влезть
2. Да, носитель никак не привязан к человеку. Криптопро при подписи будет предлагать выбрать одну из подписей на носителе.

Модуль TUN/TAP, через которые работают все не-ядерные VPN, очень медленный из-за того, что у него есть только интерфейс получения и отправки пакетов по одному пакету за вызов. Большое количество переключений контекста между ядром и пользовательским уровнем очень затратны, что влечёт за собой неэффективное использование процессорного времени.

Это типичная известная проблема, которую можно решить в течение месяца, но которую не решили в течение двух десятилетий. Достаточно кому-нибудь взяться, внедрить современный (io_uring, например) или какой-то отдельный интерфейс для отправки и получения нескольких пакетов за один вызов, и скорость магически увеличится на порядок-два.

Оценить ускорение от уменьшения переключений контекста довольно просто, достаточно провести тестирование со значительно увеличенным MTU пакета. Вот какие цифры приводит проект slirp4netns.

Implementation |  MTU=1500  |  MTU=4000  |  MTU=16384  |  MTU=65520
---------------|------------|------------|-------------|------------
slirp4netns    | 1.07 Gbps  | 2.78 Gbps  |  4.55 Gbps  |  9.21 Gbps

Рискну предположить, дело в том, что для обработки блока с одним nonce требуется много операций хеширования. SHA-256 "ест" по 512 бит за раз, а размер блока около мегабайта. Плюс в BTC считается двухкратный хеш SHA-256(SHA-256(Data)).
Но даже с учётом всего этого цифры не сходятся где-то на 2-3 порядка.

UPD. Нашёл. Помимо nonce, в блок ещё входит timestamp. Его можно менять в довольно больших пределах, не нарушая валидности блока (он должен быть больше, чем медиана времени предыдущих 11 блоков и меньше, чем средне-сетевое время +2 часа). Прогнав весь диапазон nonce и не получив красивого хеша, майнер немного меняет timestamp и прогоняет весь диапазон nonce заново. А потом снова и снова, пока не попадёт.
Весь диапазон валидных timestamp почти 3 часа ~10^4 секунд. Теперь вроде сходится.