Обновление Safe Network 🇷🇺 25 ноября 2021 г

Это машинный перевод. Оригинал на английском здесь: Update 25 November 2021

Мы все согласились с тем, что эта неделя будет хорошим временем, чтобы посмотреть, что Safe предлагает в плане распределенного консенсуса. На самом деле, некоторые из нас думали, что это дрянная идея, но подавляющее большинство проголосовало за продвижение вперед, и это все, что имеет значение :stuck_out_tongue_winking_eye: . Итак, на этой неделе мы объясним, как Safe устраняет разрыв между блокчейном и протоколами, лежащими в основе распределенных баз данных, таких как Cassandra и AWS DynamoDB.

Общий прогресс

@ChrisO выполнил задачу непрерывного выпуска sn и sn_api в репозитории safe_network. Это означает, что мы вернулись в то место, где мы можем свободно объединять коммиты и быть уверенными в следующем выпуске. После этого @chrisO переходит к изучению интерфейса командной строки и его стабилизации, прежде чем включать его в выпуски.

Дэвид Русу собирал демо по кольцевым подписям и Сейфу. Ожидайте обновления в ближайшее время (предупреждение: это будет «тяжело по математике»). :Бегущий мужчина:

@qi_ma, @yogesh и @lionel.faber провели рефакторинг ящика DKG и safe_network (наш главный источник проблем, так как более старые рекламные акции заканчиваются раньше, чем семь), чтобы уменьшить количество сообщений, которые будут транслироваться, и увеличить стабильность запуска и разбиения раздела. Работа там продолжается, но мы определенно решаем основные проблемы.

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

Распределенный консенсус и как Safe ликвидирует разрыв

Ядро Safe Network и то, что делает его уникально полезным для самых разных целей, - это то, как он достигает соглашения между распределенными узлами, которое может быть ненадежным.

В 1980-х годах децентрализованное соглашение без ссылки на центрального оракула считалось невозможным, но затем пришел Лесли Лэмпорт, чтобы доказать, что все ошибаются. Фактически, он на самом деле пытался доказать, что на самом деле невозможно обеспечить последовательность и отказоустойчивость, но затем он наткнулся на ответ, который заключался в продвижении временных лидеров и обеспечении общесистемного порядка операций.

В результате получился алгоритм Paxos, за который Лэмпорт в конечном итоге получил премию Тьюринга. Paxos гарантирует возможную согласованность в распределенной сети, где некоторые машины могут быть ненадежными. Это означает, что в сетях можно избежать единой точки отказа - любой узел, даже лидер, может выйти из строя, а система по-прежнему будет работать.

Paxos оказался чрезвычайно успешным и породил сотни подражателей и вариантов. Он в основном используется для надежной репликации данных между распределенными машинами и является основой для облачных баз данных, таких как AWS DynamoDB и Google Chubby.

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

Поскольку распределенные сети асинхронны, порядок поддерживается путем присвоения каждой операции числового идентификатора и увеличения идентификаторов с течением времени. В случае конфликта из-за обещания, как правило, выигрывает самый новый (самый высокий идентификатор).

В Paxos всегда есть ведущий узел. В случае фиксации лидер добавляет каждую операцию в свой журнал и просит другие серверы сделать то же самое. Получив ответ от большинства серверов в своем кластере, он фиксирует изменение.

Новый лидер избирается, когда текущий не отвечает в течение определенного времени. Когда это происходит, любой узел может выдвинуть себя вперед. Чтобы стать лидером, новый кандидат должен получить большинство голосов. Затем он должен обновить свои журналы путем синхронизации с другими узлами. Узлы для голосования отправляют свои журналы со своими голосами, чтобы упростить эту задачу, но для обновления может потребоваться много времени, в течение которого кластер неактивен, что может быть проблематичным.

Raft (2014), основанный на Paxos (или, точнее, Multi-Paxos, обновленная версия), упрощает процесс голосования и другие операции, но по сути является модификацией Paxos. Raft теперь обогнал Paxos с точки зрения проектной активности.

Пока все хорошо, но хотя Paxos / Raft являются элегантными решениями для распределенного консенсуса, их реализация требует множества дополнений, если они должны работать по плану.

Cloudflare основан на Raft, и в 2020 году он серьезно отключился из-за того, что процесс выборов лидера зашел в тупик.без петли. Чтобы гарантировать живучесть, также необходимы оптимизации PreVote и CheckQuorum, а также многие другие. Теперь не все так просто.

Расширение функциональности Paxos и Raft и других вариантов делает их сложными, что в технологической индустрии означает, что они становятся проприетарными. Если только Amazon знает, как надежно настроить DynamoDB, Amazon не собирается в спешке раскрывать этот секрет.

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

Введите Сатоши.

В византийских отказоустойчивых (BFT) децентрализованных алгоритмах преобладает блокчейн, который решил эту сложную проблему благодаря гению Сатоши. Блокчейны очень упорядочены и BFT. Но полный порядок важен, и он блокирует или замедляет множественный доступ и параллелизм. Блокчейны - это не системы общего назначения, а системы, разработанные специально для обмена ценностями. Блокчейны не могут заменить Paxos и его производные, потому что они оптимизированы для защиты и обмена транзакциями, а не операций с данными.

Отойдите в сторону, Сатоши, Safe Network уже здесь

Сейф - другой. Он устраняет разрыв между транзакциями с постоянным хранением в блокчейнах и распределенным управлением данными в Paxos и Raft.

Данные хранятся вечно без тяжелого PoW.

Нет общего лидера, которого можно атаковать, даже временного (например, победителя PoW в блокчейне). Вместо этого подотчетность распределяется между квалифицированным большинством секций, которые состоят из постоянно меняющихся (но согласованных) групп.

Затем возникает проблема отказоустойчивости. Paxos и Raft используют концепцию «отказоустойчивости» (CFT). Но публичные сети требуют византийской отказоустойчивости. Разница кажется незначительной, но это не так. Отказоустойчивость при сбоях определяет количество узлов, которые могут выйти из строя между операциями обслуживания, тогда как византийская отказоустойчивость - это количество узлов, которые могут выйти из строя в любой момент времени. CFT можно вычислить, BFT - нет.

Safe - это BFT, и он разработан, чтобы быть готовым к реальным условиям, когда что-то выходит из строя и бродят недоброжелатели. Возраст узла гарантирует, что византийские узлы быстро лишатся власти. Напротив, Paxos / Raft легко атакуются, продвигая лидера, который не отвечает или отвечает слишком быстро. Они также в некоторой степени полагаются на тактовые частоты сервера для управления консенсусом. Они кажутся простыми (как и сети Kademlia), но для их работы требуется множество предварительных условий, включая надежное оборудование и программное обеспечение, отсутствие прохождения NAT и т. Д.

Сейф полностью децентрализован. AE, BRB и CRDT отменяют требование согласования в масштабе всей сети для достижения согласованности, и нет необходимости в полном порядке. Даже Amazon признает, что для больших распределенных систем игра - это конечная согласованность, а не полный порядок (скорость света - жесткий предел). Попытки добиться полного порядка в массовом масштабе неизбежно приводят к низкой производительности.

Итак, Safe пересекает множество границ: возможный сильный параллелизм в общедоступной сети, BFT общего назначения и постоянные данные.


Полезные ссылки

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

Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!