Обзор развертывания Nexus Threefold
Добро пожаловать в еженедельный обзор этой недели.
Мы усердно работали над улучшением мобильного кошелька и последовательно выпускали новую бета-версию каждую неделю. Мы исправили множество проблем, и на этой неделе основное внимание уделяется тестированию на ненадежность. Одной из проблем, которую мы исправили, была ошибка в старых мобильных кошельках, из-за которой, если вы создавали новую учетную запись в автономном режиме, она не транслировалась и могла потеряться. Мы также позаботились о том, чтобы ваша история транзакций была актуальна для других узлов, когда вы ее обновляете, а ваш мобильный кошелек получает уведомления о транзакциях, совершенных на других устройствах. Мы тестируем новые сборки внутри компании, и мобильный кошелек очень близок к тому, чтобы быть готовым к выпуску. Есть еще несколько нерешенных ошибок, но мы работаем над их исправлением. Как только мы завершим внутреннее тестирование, мы выпустим новую общедоступную бета-версию, которую я опубликую, как обычно, в Твиттере, чтобы вы, ребята, могли продолжить тестирование.
Мы проводили некоторые тесты стабильности и заметили пару проблем. В частности, когда мы пытались обработать действительно большой Sigchain (мы говорим от 5 до 10 тысяч транзакций), система не очень хорошо с этим справлялась. Мы работаем над тем, чтобы это исправить.
Прежде чем мы продолжим работу над увеличением сложности мобильного кошелька, мы хотим убедиться, что устранены все ошибки. Итак, мы проведем последний набор тестов для финальной версии мобильного кошелька после того, как решим эти проблемы.
Таким образом, окончательная сборка мобильного кошелька будет включать базу данных более низкого уровня, которая была завершена с конца 2020 года. Первоначально она планировалась для версии 6.0, но теперь она включена в версию мобильного кошелька, чтобы обеспечить функциональность с постоянным временем. Это особенно важно для мобильного кошелька, поскольку он имеет меньшие хеш-карты. Без функции постоянного времени время синхронизации может замедляться со временем, поскольку требуется больше хэш-карт. Старая база данных более низкого уровня поддерживала определенный уровень постоянного времени, но поскольку требовалось больше хэш-карт, требовалось больше операций поиска на диске и итераций. При использовании базы данных с постоянным временем количество инструкций, необходимых для поиска любого ключа, сокращается в три раза.
На самом деле у меня есть действительно хорошая аналогия, чтобы объяснить, как это работает. Представьте, что у вас есть набор энциклопедий, таких как Encyclopedia Britannica, и вы хотите найти что-то конкретное, например Geronimo. При использовании хеш-карты сам ключ (в данном случае буква G) содержит информацию, необходимую для поиска подраздела, в котором перечислены Geronimo. Вы можете думать о буквах алфавита как о ключах в хэш-карте.
Таким образом, чтобы найти Geronimo, вы должны начать с открытия энциклопедии G, что похоже на поиск нужного сегмента в хэш-карте. Затем вы просматриваете индекс в этой энциклопедии, чтобы найти, где перечислены Geronimo, что похоже на поиск конкретного значения, связанного с ключом в хэш-карте.
В приведенном примере Geronimo указан на страницах 27 и 57, поэтому вы должны перейти на страницу 27, чтобы найти нужные вам данные, а затем использовать эту информацию для поиска остальной части блока. Вот как работает хеш-карта: она использует ключи для быстрого поиска определенных значений в большом наборе данных, что делает ее эффективным способом хранения и извлечения данных.
По сути, так работает база данных с постоянным временем. И вот как мы можем сделать это без поиска и обхода обычных баз данных. Вам придется искать в каком-то дереве, которое будет своего рода отдельным индексом, который примерно скажет вам, где находится эта конкретная вещь. Но каждый раз, когда вы поднимаетесь на уровень дерева, бинарного дерева поиска, вам фактически требуется еще один поиск по диску. Теперь на жестких дисках поиск диска может занять от пяти до десяти миллисекунд. Таким образом, это действительно ограничивает вашу пропускную способность каждый раз, когда вам приходится искать. Жесткие диски могут считываться довольно быстро линейно, но как только вам нужно изменить позицию, из которой вы читаете, это начинает замедляться.
Обычные механизмы баз данных, такие как LevelDB от Google, представляют собой дерево слияния, структурированное журналом, что по сути означает, что это двоичное дерево поиска в памяти, которое объединяет эти деревья вместе. Он предназначен для больших данных, и это здорово, но я заметил, что при сравнении его с базами данных более низкого уровня, такими как fstream или карты памяти, он имеет тенденцию значительно замедляться. Например, когда я пишу 10 миллионов ключей и пытаюсь прочитать самый первый ключ, он обычно оказывается похороненным, а с LevelDB, чем больше ключей вы добавляете, тем медленнее он работает, потому что нужно просеивать больше данных. Однако с базой данных более низкого уровня, независимо от того, читаете ли вы первый ключ или 10-миллионный ключ, это всегда постоянное время, около 150 000 с fstream. Если вы используете карты памяти, вы даже можете сохранить себе одну копию памяти, потому что она управляет кэшированием страниц и переходит непосредственно к страницам.
С помощью базы данных с постоянным временем, по сути, это ускорит синхронизацию, когда речь идет о чтении и записи, что также сэкономит много времени автономной работы. Это связано с тем, что каждый раз, когда вам нужно искать данные, для этого требуется электричество, и чем больше у вас операций, тем больше электричества вы потребляете. База данных постоянного времени будет включена в мобильный кошелек как своего рода пасхальное яйцо из обновления 6.0. Это практическое место, чтобы протестировать его, прежде чем запускать его в производство. Мы также сократили размер блока вдвое, что уменьшит размер цепочки в два раза, а время синхронизации должно удвоиться. С базой данных постоянного времени вы можете даже утроить время синхронизации, что поможет в ситуациях с низкой пропускной способностью и упростит синхронизацию со своими телефонами.
Если вы недавно обновили свой мобильный кошелек, возможно, вы заметили новый экран синхронизации, который появляется, когда ваш Sigchain синхронизируется и индексируется. Этот экран загрузки устраняет проблему, с которой сталкивались некоторые пользователи, когда они пытались загрузить свой кошелек, пока цепочка синхронизации все еще синхронизировалась. Этот процесс может занять некоторое время, особенно если у вас большой Sigchain. По сути, вы загружаете другой блокчейн и проверяете его с помощью доказательств Меркла в основной цепочке.
Тестирование прошло хорошо, и в настоящее время мы работаем над добавлением поддержки клиентского режима в кошельке для настольных ПК. Это означает, что если вы не делаете ставок, вы сможете запустить клиент и сэкономить много места на диске. Прямо сейчас клиентский режим занимает около гигабайта места, но мы надеемся сократить его до 500-600 мегабайт с окончательными версиями. Это также удвоит скорость синхронизации, так как вам не придется загружать все эти дополнительные данные.
Мы делаем все возможное, чтобы уменьшить требуемую пропускную способность, и изучаем различные алгоритмы сжатия, чтобы увидеть, сможем ли мы еще больше сжать данные блокчейна. Однако алгоритмы сжатия до сих пор не были очень эффективными, так как каждый байт в данных блокчейна в той или иной степени используется.
По сути, план состоит из трех этапов. Первый этап уже завершен, а второй этап — это хардфорк настольного кошелька, который включает в себя множество новых функций. Третий этап — это мобильный кошелек, над которым мы сейчас работаем.
Причина, по которой мы хотим выпустить мобильный кошелек после хард-форка, заключается в том, что в работе сети произойдут некоторые изменения, и мы хотим убедиться, что мобильный кошелек совместим с этими изменениями. Запуск ноды (что и делает мобильный кошелек) на телефоне довольно сложен, и мы никогда раньше этого не делали. Мы проверяем все эти смарт-контракты и управляем всем этим состоянием таким образом, что это на самом деле узел, поэтому нам нужно убедиться, что все работает гладко.
Когда на Nexus произойдет серьезное обновление сети (например, хардфорк 5.1), вам также потребуется обновить свой мобильный кошелек, потому что будут некоторые изменения в способе проверки. Клиентский режим по существу обрабатывает блоки, но с меньшим подмножеством транзакций, поэтому важно, чтобы все работало правильно.
Приятно видеть, что наша команда стабильно прогрессирует и регулярно выпускает новые сборки. Кендалл и Кристо отлично справляются со своей работой, и хотя в последнее время у меня не было много времени для работы над новой функцией, я сосредоточился на настройке мобильного кошелька. Я столкнулся с парой проблем с подтверждением кредита и ведением журнала Sigchain, которые нужно было исправить, но мы смогли решить их довольно быстро. На самом деле, нам даже пришлось переработать некоторые системы индексации в клиентском режиме, но это того стоило, потому что архитектура стала действительно солидной. Новая версия мобильного кошелька, кандидат 11, работает надежно, и сейчас мы оптимизируем ее, чтобы снизить расход заряда батареи на Android. Далее я сосредоточусь на создании новой функции, в частности на удаленном входе в систему и настройке нового API.
Итак, в последнее время Кесин усердно работает над наборами для тестирования, которые включают в себя такие вещи, как модульные тесты и регрессионные тесты. Эти тесты необходимы для обеспечения бесперебойной работы основного кода и правильной работы всех конкретных блоков кода. Я помню, как пригласил Кесина поделиться своими мыслями по этому поводу, и, возможно, он скоро присоединится к нам, если у него есть микрофон. Всегда приятно иметь кого-то, кто разбирается в наборах для тестирования, так как они играют решающую роль в процессе разработки.
Он проводил регрессионные и модульные тесты, чтобы убедиться, что все работает правильно. Он помогал с мелкими деталями, такими как обновление семантики API, документации и кодов ошибок. Это может показаться мелочью, но очень важно правильно продумать все эти детали. У меня не всегда было время, чтобы сосредоточиться на этих вещах, поэтому я очень ценю всю работу, которую он проделал. Судя по тому, что я видел, он проделал огромную работу, организовав все так, чтобы каждый тест можно было запускать отдельно.
Команда усердно работала над исправлением ошибок и тщательным тестированием. Уже было несколько циклов бета-тестирования, и, возможно, будет еще несколько, но даты выпуска должны быть объявлены в ближайшее время. Мы также работаем над некоторыми новыми функциями и пригласим Кесин, чтобы обсудить их в следующем еженедельном отчете. В целом, похоже, все идет хорошо, и мы сможем начать использовать эти новые функции очень скоро.
Спасибо за ваше терпение и следите за обновлениями!
Для краткой версии резюме посетите: https://link.medium.com/v1vcrctGGyb
Для записи резюме: https://twitter.com/i/spaces/1mrxmkZmargGy
Для получения дополнительной информации о Nexus посетите: https://www.nexus.io
