Резюме

- Все сетевое хранилище данных представляет собой карту вида хэша (данные) -> данные
- Это можно легко проверить (так коптит база данных не может произойти)
- Пусть каждый узел выбрать случайный, не уникальный идентификатор (скажем, 2 байта)
- Вершины магазин только данные, где хэш (данные) имеет те же MSB в качестве идентификатора клиента
- Узлы могут решить, сколько бит контролировать, сколько памяти
- Создание таблиц маршрутизации на основе клиентских идентификаторов

До тех пор, как число узлов достаточно, все записи будут храниться где-то и таблицы маршрутизации все запросы будут направляться.

Там должен быть способ, чтобы заметить, что записи отсутствуют.

Например, вы не можете доказать, что последний блок добавляется к цепи является недействительным, если оно содержит неизвестные транзакции.

Детали

Предполагается, что все узлы имеют всю цепочку заголовка блока. Это должно также включать в себя последние вилки, с некоторым обрезанием (скажем 1024 из головы дерева).

Блок заголовки поэтому специальные, вы просто отправить заголовок и добавляются в цепи, если она соответствует простым правилам.

База данных представляет собой карту с ключами "хэш (сообщение)" отображение в "сообщение",

Merkle узлы все должны быть сохранены доступным. В конечном счете, они должны быть сохранены с транзакциями, но должны быть получены непосредственно.

Каждый узел выбирает случайный идентификатор, который N бит длиной. Чем больше идентификатор, тем меньше данных узел претендующие иметь. 

Если верхний N битов ключа матча рекорд это узлы идентификаторов, то запись должна быть сохранена узлом. Это может добавить дополнительный бит к его идентификатору, если данные, хранящиеся превышает то, что он готов поддержать, а затем падение других записей.

Для простоты, я буду считать, что все узлы имеют 2 байта, как их идентификаторы, но это может быть сделано вообще.

Id Узел: 0x1200
Маска: 0xFF00

означает, что узел готов для хранения данных для всех идентификаторов вида 0x12xy (для любых х, у). До тех пор, как ненулевая часть идентификатора коротка, будет много узлов с одинаковым идентификатором.

Узел затем создает таблицу маршрутизации с записями на основе расстояния до других узлов. Это величина подписанной разницы между идентификаторами 2 узла. Таким образом, максимальная разница составляет 32576.

Сжатые таблицы маршрутизации может быть отправлены с 34 записями.

разность <= 0x8000
разность <= 0x6000
разность <= 0x4000
...
разность <= 0x0004
разность <= 0x0003
разность <= 0x0002
разность <= 0x0001 (ошибка округления)
разность <= 0x0001
разность <= 0x0000 (всегда равен нулю)

Эта таблица 34 записей. Конец таблицы может быть исключен, как только вы попали в ноль хмеля, а остальная часть таблицы гарантированно будут все нулями. Это может случиться, если узел решил использовать более короткий идентификатор. Это означает, что обновления таблиц принимать только 34 байта (или 68, если хмель > 255 хмеля необходимо поддерживать). Это, вероятно, проще всего сделать таблицу массив var_ints, но в основном будет байт на запись.

Таблица уменьшает в размере приблизительно на SQRT (2) каждый раз.

Когда узел получает обновления маршрутизации, он может обновить свою собственную таблицу.

Если один из его локальных диапазонов является подмножеством удаленного диапазона, то он может обновить локальный диапазон до мин (old_local_hops, remote_hops + 1)

Локальный узел может поддерживать локальное расстояние для всех идентификаторов, и будет обновлять каждый идентификатор записи по одному за раз.

Если это вызвало его собственный "вывод" таблица маршрутизации для изменения, то он может обновить его сосед.

Это позволяет запросы на данные, которые будут направляться в соответствующий узел.

При передаче данных, которые будут сохранены, приемник может проверить доказательства как полученные данные, и разорвать соединение, если доказательство является недопустимым. Враждебный узел с доказательством может держать повторную отправку данных (если он включен IP). Тем не менее, работает, что только пока данные не хранятся в сети.

Для клавиш, которые приводят к другим клавишам. Это ответственность узлов, которые хранят ключи, чтобы убедиться в следующем по клавишам, как правило, доступны.

Например, если узел хранится запись

ключ-хэш -> хэш (child1, child2)

Он должен убедиться, что child1 и ребенок 2 были доступны. Это должно быть сделано, когда записи добавляются в свою базу данных и периодически.

Если child1 или child2 отсутствует, то он пошлет недостающую передачу данных. Это включает в себя доказательство того, что ключ-хэш является действительным ключом. Принимающий узел будет затем попытаться получить сами эти данные, используя те же "недостающие данные" сообщение с уведомлением.

Если приемник не может отправить обратно данные, то его расстояние до этого клиент-идентификатора для данного удаленного узла должно быть установлено на 255 и таблице маршрутизации обновляется. Честные узлы должны немедленно реагировать с "неизвестный" чтобы ускорить процесс. Это позволит обновить все таблицы маршрутизации назад от фактического целевого узла достигнут.