На самом деле довольно сложно обстоят дела с использованием /24 сетей

На самом деле довольно сложно обстоят дела с использованием /24 сетей
Ранее сам же Storj рекомендовал использовать сторонний сервис для переадресации портов.
К слову тот же проект SIA как то раз столкнулся с DOS атакой, как результат они же рекомендовали использовать VPS, да это о другом но все же.

Ну а касаемо 1ip один узел, ну такое вот у меня есть 1500TB как мне все это привязать на 1ip? Это сколько лет уйдет на заполнение всего этого?

Считаю что концепция /24 сетей не жизнеспособна, не лучше ли ориентироваться по той же геолокации?

Может вместо того что бы операторы оплачивали VPS направить эти средства на дополнительные каналы? Источники Бесперебойного питания и так далее?

Ну и опять же, предположим мой оператор связи может мне предоставить адреса /24 посредством vlan или eoip, или может предложить поднять у себя виртуальную машину и опять же использовать vlan или eoip? Это будет считаться как обход правил или нет? или вам надо один провод провайдера 1 адрес? Концепция бредовая

1 Like

Правило /24 используется для предотвращения размещения кусочков одного сегмента в той же физической локации: один провайдер, один или несколько серверов с публичными адресами из той же /24 подсети, один источник питания, может даже без ИБП, одно здание, один датацентр, и т.д.
Возможно оно менее эффективно, чем что-то ещё, но это самый простой способ противостояния Sybil attack: нельзя допустить, чтобы один участник децентрализованной сети контроллировал большую часть сегментов клиентских данных, делая их “заложниками” с вредительской целью. Обход правила не бесплатный, поэтому если расходы превышают доходы или риск обнаружения, это помогает предотвратить такую атаку.

Мы используем не только этот фильтр, но ещё и правило choice of n, которое дополнительно учитывает success score узла, это позволяет выбирать самые быстрые узлы для клиентских загрузок (этот показатель динамический). Это также помогает избегать выбора узлов, оператор которых решил обойти правило /24. Потому что использование VPN обычно увеличивает время ответа, автоматически снижая показатель успеха, и этот узел будет выбираться реже и реже. Пока ещё не 100% решение, но лучше, чем просто /24 и уж точно лучше, чем без /24.
Я видел изменение, которое теперь позволит выбирать из сети /25, так что это тоже поможет увеличить косты на отдельные IP и позволит не рисковать данными клиентов, помещая их всех в одну локацию.

в этом и цель - сделать обман нецелеесообразным, либо технически (чего бы мне хотелось больше всего), либо экономически.
Есть ещё более простой способ - порезать выплаты ещё сильнее, чтобы обманщику стало не выгодно покупать отдельные адреса для одной той же самой локации. Мне бы не хотелось такого развития событий, но это наипростейший способ. Только вот ударит он по всем операторам, а не только по самым хитрым.

Одна локация - один узел. Или много узлов, но некоррелированные: если ваш мегасервер выключится, клиентские данные останутся доступны, потому что есть другие узлы с кусочками этого же сегмента и их будет достаточно, чтобы восстановить потерянное.
Правило /24 просто один из способов, потому что обычно провайдеры располагают адресами чаще всего из этого диапазона для каждой физической локации, куда заходит их провод. И запрос дополнительного адреса из другой /24 подсети ваш провайдер вряд ли предоставит бесплатно, снижая ваш доход. Может быть до точки убыточности. И никакой геолокации не надо, тем более она не 100% надёжна, см. Missing Payouts Because Node Is in a "Sanctioned Country"?

Концепция безопасного хранения данных клиентов? Ну, тогда вам, скорее всего, не сюда, а в Chia или filecoin.
Первые не хранят данные клиентов, только цифровой бесполезный мусор, а вторые не заботятся о надёжности - файлы могут пропасть и пропадают, даже если вы платите.

Eto pravelo uzhe ispolzuetsja tozhe na US1 i EU1 tozhe?

Я думаю, что да. На Saltlake это показало высокую эффективность и увеличение пропускной способности сети. Мы постоянно работаем над улучшением производительности для клиентов.
Пока что аналог не используется для скачивания, но если возникнет потребность у клиентов скачивать ещё быстрее - тогда, я думаю, оно будет использовано и для скачиваний.