Это машинный перевод. Оригинал на английском здесь: Update 22 September, 2022
На этой неделе нечего сообщать о техническом фронте, поэтому мы ограничимся общим отчетом о ходе работы, а не обычным глубоким погружением. Однако больше информации о команде, где мы рады приветствовать нового члена команды. Мостафа — опытный блокчейн-разработчик из Малайзии.
Добро пожаловать в команду, Мостафа!
Привет. Это Мостафа. Я инженер-программист. Рад встрече.
Однажды, когда я был студентом, я решил посетить древний храм огня (зданию более 2000 лет), который находился в дикой местности. Найти храм огня было непросто, поэтому я попросил местных жителей помочь мне. Интересно, что они назвали его «Дом дьявола», и когда я спросил их, почему, они сказали: «Поскольку люди не могут построить такую вещь, это должен быть дьявол». Это пришло мне в голову недавно, когда я прочитал историю о дьявольских мостах в Европе. Мосты, которые были построены много веков назад и функционируют до сих пор. Люди называют их дьявольскими мостами, потому что не могут поверить, что их построил человек, должно быть, это дьявол.
Никто не знает, кто построил мост дьявола или храм огня, но они все еще стоят. Давайте построим дьявольскую сеть!
Общий прогресс
Работа SectionTree завершена 
Напоминание от @roland, почему мы повторно реализовали некоторые части SectionTree…
SectionTree(ранееNetworkPrefixMap) — это структура данных, которая инкапсулирует наши текущие знания о сети. Его можно рассматривать как дерево, в котором каждый узел являетсяSectionKey, подписанным его родительскимSectionKey, за исключением корневого узла (genesis_key). Листья дерева также содержат SAP раздела, отбрасывая SAP не-листьев.Поскольку каждый «Клиент/узел» может иметь разное представление сети, «Дерево разделов» может сильно различаться между участниками. Кроме того, необходимо отправить части дерева («SectionTreeUpdate», которое связывает цепочку доказательств + SAP) всем, кто его запрашивает, и быть уверенным, что они не испортят свое дерево, пытаясь его обновить.
SecuredLinkedListранее использовался для построенияSectionTree, но у него было несколько проблем, которые приводили к неправильным вставкам, и он не был совместим с CRDT. Следовательно, он был повторно реализован как CRDT (в частности, «MerkleRegister»), а старый «SecuredLinkedList» был заменен новым «SectionsDAG». Теперь мы можем быть уверены, что он ведет себя так, как ожидалось, независимо от порядка или продолжительности обновления!
@roland теперь перешел к тестированию распределенной генерации ключей (DKG) с @anselme. Как объяснялось за последние пару недель, были проблемы с тем, что процесс DKG не всегда завершался. После интенсивного тестирования он выглядит довольно стабильно, и @anselme пишет документацию для процесса тестирования.
Заметка от Ансельма о грядущем DKG…
Грядущий DKG, более отказоустойчивый и без таймеров
Процесс DKG в настоящее время является активным процессом, использующим таймеры, которые в случае интенсивной сетевой активности часто дают сбой из-за тайм-аутов. Недавно мы работали над новым DKG, который не использует таймеры, вместо этого позволяет задерживать сообщения, а также поддерживает отбрасывание тяжелых пакетов. Когда узлы какое-то время не получают сообщений, они сплетничают о своих знаниях с другими в надежде на то, что они будут в курсе, или даже получать от них обновления, если отправленная информация устарела. Таким образом, в конечном итоге каждый узел достигнет завершения DKG.
Теперь в этой новой реализации мы также используем параллельные DKG. Теперь это гонка между DKG и набором кандидатов, который дойдет до конца, прежде чем остальные получат шанс стать новым набором старейшин. Некоторые сессии DKG могли забуксовать или закончиться с опозданием, но мы не считаем их провалами, они участвовали в гонке и просто проиграли. Мы хотим, чтобы следующий набор старейшин был как можно более надежным, поэтому выбор победителя в этой гонке DKG также является для нас способом выбрать лучшие узлы. В конце концов, после смены секции эти сессии DKG устаревают, и когда кандидаты понимают, что проиграли гонку, они знают, что могут остановиться.
Другой динамичный дуэт @bochaco и @chriso занимается отладкой тестов DBC. Они обнаружили сбой, из-за которого SAP (список текущих старейшин) по ошибке удаляется в процессе тестирования клиента, что дестабилизирует сеть.
Тем временем @bochaco продолжает работать над другим основным потоком активности, оптимизируя процессы обмена сообщениями и используя, где это возможно, отдельные потоки.
@joshuef и @davidrusu также работают над аспектами рационализации сообщений, Джош исследует возможность извлечения модуля comms из кода node, чтобы посмотреть, может ли это лучше подходить для многопоточности, в то время как Дэвид отделяет некоторые из код, используемый крейтами sn_node и network_knowledge, который, как мы надеемся, устранит некоторые из ошибок соединения узлов, которые мы наблюдали.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!