Re: Использование blockchain Bitcoin для обнаружения P2P?
Вот ссылка на красивее версию этого: https://gist.github.com/paulkernfeld/7126c1307fd46561df9c
Предисловие: Blockchain хранения Политика
---------------------------
Вопрос о том, следует ли протокол Биткойна быть использован для хранения данных [спорный] (https://github.com/bitcoin/bitcoin/pull/5286), И я приношу свои извинения всем, кто думает, что этот пост в плохом вкусе. Если вы не возражаете, я хотел бы ограничить это особое обсуждение технических достоинств Веспуччи, а не моральных достоинств.
Vespucci
========
Веспуччи предлагаемый протокол, который использует blockchain Bitcoin децентрализованного открытия приложения.
Проблема
===========
Для того, чтобы приложения, чтобы присоединиться к сети P2P, приложение должно каким-то образом найти IP-адрес одного или нескольких коллег, чтобы подключиться. Это называется самонастройки, и это может быть трудно. клиенты BitTorrent и Bitcoin часто включают в себя постоянные адреса "бутстраповские узлы," долгоживущий серверные узлы. Это решение работает только тогда, когда эти долгоживущие узлы серверов остаются вверх, что создает потенциальную точку отказа. Таким образом, этот протокол предназначен для обнаружения приложений со следующими требованиями:
1. Применение P2P необходимо загрузить глобальный список пиров, когда он впервые открыл.
2. Любой должен иметь возможность регистрировать самозагрузку сверстников для открытия.
3. производительность чтения, то есть время, чтобы читать сверстникам и присоединиться к сети, очень важно.
4. Производительность записи, то есть время, чтобы зарегистрировать новый узел, очень важна.
5. Возможность открыть сеть Bitcoin предполагается.
Протокол
============
Адреса коллег будут сохранены с использованием [OP_RETURN] (https://en.bitcoin.it/wiki/OP_RETURN) транзакций выходов. Для того, чтобы обнаружить пэр для приложения, она будет выглядеть через blockchain, возвращая соответствующие операции приложению.
Что хранится?
---------------
Данные толкнул после того, как OP_RETURN будет состоять из:
1. Два байта, `V0` в ASCII, идентифицирующий сообщение как принадлежащее к протоколу Веспуччи.
2. Несколько дополнительных байтов, идентифицирующих приложение.
3. нулевых байт, чтобы отметить конец идентификатора приложения.
4. Список сжатых адресов.
Поскольку Blockchain является общим ресурсом, мы хотим быть уверены, чтобы использовать его с умом. Мы можем использовать пространство эффективно за счет сжатия адресов и позволяет несколько адресов, которые будут группироваться в одной транзакции.
Адреса
---------
Несжатые адреса будут нуль общих идентификаторов URI. Это позволяет нам поддерживать IP-адрес, а также имена хостов.
`Схема: [// [пользователь: пароль @] хост [: порт]] [? Запрос] [/] путь [# фрагмент]`
Информация о включении или не включать в себя:
* Мы, наверное, не нужно хранить `scheme` (например,` `http` или magnet`), потому что информация, вероятно, можно судить по применению.
* Это не имеет большого смысла включать `` user` и password` в Bitcoin, публично-видимую магазин!
* Параметр `поле host` всегда будет заполняться
* Параметр `port`,` path`, `query` и` fragment` поля могут быть заселены
компрессия
-----------
Для того, чтобы сжать URL, мы хотим использовать небольшие струны сжимающей библиотеку специально обучен по данным URL вида. [Сохо] (http://ed-von-schleck.github.io/shoco/) Позволяет пользователям делать [именно это] (http://ed-von-schleck.github.io/shoco/#generating-compression-models).
заказ Look
==========
Blockchain Bitcoin является лог-структурированного хранилищем данных, оптимизированный для большой производительности записи, но не предназначена для чтения. Blockchain в настоящее время растет примерно на 25 Гб / год, и не индексируется только по времени. Это представляет дилемму: P2P-приложение, которое уже пять лет придется искать через 125 Гб данных при поиске по линейному закону, даже в том маловероятном случае, если предельный размер блока не увеличивается. Это очень много данных, чтобы просмотреть только, чтобы получить несколько адресов! Итак, как мы можем превратить записи оптимизированной blockchain в открытии магазина чтения оптимизировано?
Чтобы решить эту проблему, мы смотрим через блоки в порядке, который максимизирует производительность операций чтения в то время как в значительной степени ущерба для производительности записи. Алгоритм будет выглядеть следующим образом:
* Без потери общности, маркировать первый блок, который нас интересует блок 0. Этикетка последующих блоков [высоты] (http://bitcoin.stackexchange.com/questions/18561/definition-of-blockchain-height) Заказ: 1, 2, 3, ...
* Определить текущую максимальную высоту блока, как `M`.
1. Установить число `k` таким образом, что` К: = потолок (log2 (М)) `.
2. Посмотрите на все не смотрел, в блоках, где номер блока `B` кратна` 2 ^ k`, в порядке убывания.
3. Если `K > 0`, установите `K: = K - 1 '. В противном случае ( `K = 0 '), мы смотрели на все блоки.
Это также можно рассматривать в качестве высоты блока записи в двоичной системе и подсчет количества нулей в конце. Пример:
Код:
Блоки: 0 1 2 3 4 5 6 7 8 9 10 11 12 13
Двоичные: 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101
Конечные нули: 0 1 4 0 2 0 1 0 3 0 1 0 2 0
Порядок Смотри: 0 8 12 4 10 6 2 13 11 9 7 5 3 1
Так же, как при выборе номера портов, приложения должны попытаться избежать синхронизации начальных высот блоков, чтобы избежать скученности на важных блоках. Для того, чтобы оптимизировать дальше, приложения могут перестать смотреть на определенном значении `k`. Например, если мы только посмотрим, пока `K = 10`, минимальное время записи составляет неделю, а приложение гарантированно никогда не придется смотреть через более чем 1/1024 от blockchain, который будет 25 МБ / год в настоящее время ,
Защита от спама
---------------
вопросы
======
интерференция протокол
---------------------
Вполне возможно, что не-Веспуччи сообщения может начинаться с префикса Веспуччи и приложений, либо случайно или по злобе. Учитывая это, клиенты Веспуччи должны терпеть:
* Искаженные адреса
* Адрес, указывающий на вредоносные узлы бутстраповских
* [Decompression атаки] (https://en.wikipedia.org/wiki/Zip_bomb), Воспользовавшись протоколом сжатия
Связанных с работой
============
[Blockname] (https://github.com/telehash/blockname) Является подобным проектом, Bitcoin blockchain кэша DNS. Blockname пытается решить несколько сложнее проблема, что создания 1: отображение 1 от доменного имени по адресу сервера. В Веспуччах, каждое приложение может возвращать набор адресов.
