Это машинный перевод. Оригинал на английском здесь: Update 13 April, 2023
Кто-нибудь в настроении для более глубокого погружения?
Пару недель назад @oetyng рассказал нам о дизайне платежной сети и о том, как это может работать отдельно.
Теперь, когда технологический стек Сети развивается такими темпами, которые мы не могли предвидеть даже две недели назад, мы предоставили себе свободу действий и гибкость, чтобы использовать различные возможности для запуска, будь то сеть только для платежей или вычеркивание. для полной сети передачи данных с самого начала.
Поэтому @oetyng пересматривает мир платежей, чтобы объяснить, как он интегрируется с хранилищем, кошельками и клиентскими API в новом упрощенном дизайне.
Сначала несколько слов о том, как формируется сеть, когда мы переходим от дизайна разделов к Kademlia. Kademlia требует, чтобы узлы разговаривали друг с другом по всей сети, а не только с узлами в своем разделе. Если бы они этого не сделали, таблица маршрутизации вскоре устарела бы и заполнилась мертвыми узлами, а сеть умерла бы из-за серьезного недопонимания. Проверка родителей DBC — это способ постоянно обеспечивать работоспособность узлов, а также выполнять жизненно важную функцию, поэтому мы можем удвоить это.
Транзакции по сети будут происходить очень быстро, но Safe не является базой данных и не подходит для быстрых изменений данных. Этот тип работы выполняется на стороне клиента, а результаты затем сохраняются/реплицируются в Safe. CRDT означает, что клиенты могут эффективно сотрудничать в режиме реального времени и бесконфликтно, а результаты этого сотрудничества могут храниться публично или конфиденциально в Safe для потомков. Переезд в Кадемлию проясняет это разделение труда.
Еще одним результатом изменения является то, что небольшие тестовые сети вряд ли будут стабильными. Новый дизайн, вероятно, потребует 2000 или более узлов для правильной работы. Это совсем не проблема, но, очевидно, изменит то, как мы запускаем тестовые сети.
Общий прогресс
По мере того, как мы приближаемся к возможности выпускать что-то для общественного потребления, Джим работает над позиционированием, дорожными картами и обменом сообщениями. Взгляните на его ветку Что такое запуск, если вы еще этого не сделали.
В преддверии этого дня @bzee изучает обход NAT и то, как мы можем его реализовать, а @bochaco готовит наши типы данных для интеграции в новую сетевую инфраструктуру, в том числе работает над API, чтобы разработчики могли приступить к работе с приложениями как можно скорее. так как у нас есть что-то стабильное. Bochaco также изучает сообщения об ошибках, пытаясь сделать их более конкретными и полезными.
Другая большая часть работы — это сортировка близких групп. Учитывая имя фрагмента данных (такое же, как и его XOR-адрес), клиент знает, какие k узлов запрашивать для его извлечения, но должны ли мы начать с 20 или что-то вроде 8? Больше означает, что больше узлов обновляют свои таблицы маршрутизации, но это также и больше сообщений. Как насчет того, когда мы храним DBC? Этим занимаются @roland и @qi_ma. @roland также пересматривает репликацию данных.
Конечно, нам нужно иметь возможность видеть, что происходит, и @Chriso провел рефакторинг реализации OpenSearch в репозитории тестовой сети, чтобы освободить место для настройки мониторинга.
И @oetying начинает объединять все это вместе. Больше от него ниже!
DBC, переводы и кошельки
Упрощение кода DBC
За последние пару недель код DBC подвергся давно необходимому упрощению. Было и больше документации, и небольшой пересмотр терминологии, согласование названий и концепций для меньшей когнитивной нагрузки.
Еще одна вещь, которую мы могли бы сделать сейчас, поскольку у нас больше нет секций и старейшин, — это удалить сетевую подпись DBC. Это само по себе является огромным упрощением. Что у нас есть сейчас, так это то, что перевод может быть создан полностью в автономном режиме, и все, что вам нужно сделать, это отправить части DBC, называемые * подписанные расходы * (это означает, что ключ, соответствующий идентификатору DBC, подписал расходы что DBC — значит, отправитель токенов подписал трату). Когда достаточное количество пиров в сети приняли эти подписанные траты, транзакция завершена и действительна.
Расходование DBC в сети (переводы или платежи данных)
Так, чтобы немного отступить.
Вместо того, чтобы просить старейшин секции подтвердить и подписать трату (то есть перевод или оплату данных), как это делалось ранее, теперь мы отправляем подписанные клиентом траты в закрытую группу идентификатора DBC для траты. (Мы называем это адресом. Таким образом, у чанков есть адрес, у регистров есть адрес, а у транзакций DBC есть адрес). Эта тесная группа уже упоминалась ранее. Сверстники близкой группы ничего не подписывают. Они просто проверяют расходы, каждый из которых действует независимо, и сохраняют их, если считают, что они действительны. Чтобы найти его действительным, нужно найти родителей таких расходов. Это означает поиск расходов, которые привели к созданию этого самого DBC, который сейчас тратится.
Если эти родительские расходы могут быть извлечены из их соответствующей близкой группы, это означает, что они действительны, поскольку сами подверглись t.его процесс назад, когда они были потрачены.
Конечно, есть и другие проверки, такие как слепые суммы, проверяющие входы и выходы, что ключи входных dbc подписали все правильно и так далее.
И когда все это подтверждено как действительное, одноранговый узел просто сохраняет подписанные расходы. И когда клиент должен проверить, действителен ли полученный им DBC, он просто просит сеть вернуть подписанные расходы, которые привели к созданию этого DBC. Если требуемое количество пиров его возвращает, то это факт.
Закрытые группы
Итак, тесная группа. Помните, что они находятся по близости к идентификатору DBC (или хешу данных). Их может быть 4, 8, 16 пиров и более. Мы начнем с числа и будем корректировать по мере продвижения. Но это еще не все. Мы можем добавить слои, хэшируя идентификатор/имя, и получить новый адрес, который детерминировано получается из первого. Теперь мы можем сохранить тот же элемент и в этой группе. И так можно продолжать, хешируя этот адрес снова и снова, и каждый раз иметь еще одну группу, содержащую элемент.
Это некоторые из рычагов, которые были упомянуты ранее. Мы начнем с простой группы, потому что сначала мы просто хотим запустить ее в тестовой сети.
Кошельки
Мы только что закончили первую простую реализацию кошелька, который хранит DBC и историю транзакций. Как и в случае с данными, первая итерация использует хранилище в оперативной памяти. Далее он будет хранить его локально на диске, а после этого мы займемся сетевым хранилищем. Хорошо то, что мы реализуем кошелек с простым интерфейсом, который можно использовать с любым из трех (или всех) вышеупомянутых носителей данных.
Что также было принято во внимание на этот раз, так это то, что всем пирам нужно будет иметь кошелек для своих вознаграждений. Но мы еще не совсем там, еще неделя или две для этого. (И да, теперь намного проще делать оценки времени.)
Комиссия за перевод
Они были описаны совсем недавно в обновлении, и там мало что изменилось. Платежи идут на ноды, а приоритетная очередь (ранее называвшаяся мемпулом) такая же.
Что мы, вероятно, рассмотрим чуть раньше, так это то, как тот же шаблон можно применить для платежей за передачу данных.
И это вы в курсе о ходе переводов и платежей на данный момент.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!