Допустим, у вас есть распределенная система хранения, такая как bittorrent или ipfs, и вы хотите отслеживать соотношение загрузки/выгрузки (или ответа/запроса) пиров. Однако вы не хотите использовать централизованный трекер и хранить все в одноранговой сети? Ты можешь оценить соотношение u/d безопасно распределенным способом, не перегружая систему?
Одна из моих мыслей заключалась в том, чтобы изменить HyperLogLog (HLL) с помощью комбинации этого ответа: Можно ли создать систему «доказательства загрузки» для отслеживания соотношения BitTorrent?.
В этой системе у всех есть пары открытого/закрытого ключей, и запрашивающие стороны включают подписанные токены для каждого Xmb данных (каждый токен предназначен для одного и того же объема данных). При каждом запросе к другому узлу обрабатывающий узел будет сохранять хэш токена в гиперлоглоге под идентификатором запрашивающей стороны и вместе с ответом будет возвращать новый подписанный токен ответа. Если обрабатывающий узел возвращает хороший ответ, запрашивающая сторона сохраняет токен ответа в гиперлоглоге под идентификатором поставщика.
Если у вас есть одноранговые узлы: p1, p2, p3, и вы хотите рассчитать соотношение сделанных запросов к запросам, предоставленным для p1, вы можете сделать что-то вроде:
- P2 и p3 объединяют гиперлоги токенов ответа от p1 в
холл_1
- p2 и p3 объединяют гиперлоги токенов запросов от p1 в
холл_2
Соотношение акций мощность (hll_1)/мощность (hll_2)
Чтобы сделать HLL «безопасными», для каждого HLL «бина», в котором подсчитываются конечные нули хэша, запишите токен и подпись, создавшие хэш с наибольшим числом нулей на бин. Таким образом, когда p2 и p3 объединяют свои HLL вместе, они могут подтвердить, что HLL друг от друга были созданы из подписанных токенов, и отклонить, если подписи не совпадают. P1 может просмотреть объединенные HLL и подтвердить, что они получены из подписанных им запросов. Это заставит каждый узел доказывать, что он видел токены, из которых состоит их HLL.
Атаки
P1 может проверить честность p2 и p3, проверив сообщаемые ими HLL. Если p2 или p3 занижают количество ответов (они получили ответ от p1, но решили не включать его в HLL) или завышают запросы (т. е. p2 мог получить запрос от p1, но не отправил ответ), P1 может просто заблокировать их от свою таблицу маршрутизации.
P1 и P2 или P3 могут вступить в сговор путем обмена токенами без выполнения работы, поэтому вам все равно потребуется какой-то центральный сервис для выпуска JWT для контроля членства в рое и поиска сговора.
Другой аспект атаки заключается в том, что запрашивающие могут потенциально фильтровать свои запросы и отправлять только запросы, которые не увеличивают HLL (т. е. убедитесь, что хэш токена не имеет завершающих нулей). Чтобы предотвратить это, каждый узел может добавить соль к токену, прежде чем он будет хеширован и вставлен в HLL. Это также предотвратило бы повторное использование токена.
Сжатие с потерями
Кажется, что с HyperLogLogs вам нужно будет хранить столько подписей, сколько у вас есть корзин, чтобы проверять очень большие объемы (миллиарды) запросов с разумной степенью точности. Эти подписи в HLL заняли бы много места, но гораздо меньше места, чем хранение каждого запроса!
Вы можете объединить большое количество HLL, используя DHT, например kademlia, для выбора узлов для отправки HLL, чтобы рой мог сообщать информацию о конкретном узле в общее место.
Я уверен, что упустил что-то фундаментальное в том, почему это не сработает или как это улучшить. Работает ли эта схема или есть более простой способ?
