Проектирование некоррелированности: Глубокое погружение в архитектуру DVT и Charon
Привет всем. Представляю перевод свежайшей статьи от CTO @Oisín Kyne (OBOL NETWORK) Оригинал читай тут.
Минимизация корреляции жизненно важна при разработке DVT, так как Ethereum Proof of Stake разработан таким образом, чтобы жестко пресекать корреляционное поведение. При разработке Obol мы сделали тщательный выбор, чтобы создать архитектуру с минимальным контролем доверия и отсутствием корреляции.
Я беспокоился о децентрализации доказательств доли еще с тех пор, когда на Devcon 4 была представлена оригинальная спецификация проекта serenity. Сегодня я хочу поговорить о том, как Charon, клиент промежуточного ПО распределенного валидатора Obol, спроектирован таким образом, что позволит ему увеличить набор валидаторов Ethereum на порядок без введения корреляционного поведения в валидаторы, которые используют эту технологию.
Во-первых, что такого важного в корреляции?
Спецификация доказательства доли Ethereum разработана таким образом, чтобы поощрять децентрализацию, сильно наказывая централизацию. Существуют механизмы, предназначенные для наказания коррелированной бездеятельности, и механизмы, максимально наказывающие коррелированное злонамеренное поведение. Чем больше людей не в сети, когда вы не в сети, тем хуже наказание за ваше бездействие (особенно если >33% сети не в сети). Аналогично, если ваш валидатор считается атакующим сеть, вы будете удалены, и штраф за удаление растет в зависимости от того, сколько других валидаторов будут удалены в последующие три недели после вашего удаления. Если бы ваш валидатор был единственным, который был бы уничтожен за этот период, он потерял бы, возможно, 2 эфира. Если произойдет массовое сокращение, вы можете потерять весь эфир вашего валидатора.
Итак, теперь, когда мы понимаем, каковы здесь ставки 😏, давайте рассмотрим некоторые хорошие (и плохие) идеи для архитектуры распределенного клиента валидатора, который стремится сделать сеть более безопасной, более устойчивой и менее коррелированной, чем сеть была бы без него.
Терминология
Для тех, кто только знакомится с Charon и DVT в целом, хотелось бы кратко остановиться на нескольких терминах:
⚫Распределенный валидатор: Один пакет из 32 эфиров, представленный открытым ключом BLS, управляемый несколькими закрытыми ключами в тандеме.
⚫Кластер распределенного валидатора: Набор узлов Ethereum (включая Charon), соединенных вместе для работы одного или нескольких распределенных валидаторов.
⚫Middleware (промежуточное программное обеспечение): Программное обеспечение, которое находится между двумя другими независимыми частями программного обеспечения и перехватывает линию связи между ними. Charon находится между клиентом валидатора и HTTP Beacon API на клиенте консенсуса.
Закрытые ключи
С чего еще можно начать обсуждение архитектуры распределенных валидаторов, как не с закрытых ключей. В кластере распределенных валидаторов задействованы два типа закрытых ключей:
Пара открытый/закрытый ключ SECP256K1 используется для идентификации клиента Charon. Таким образом, Charon тесно взаимодействует с существующими сетевыми стеками eth1 и eth2, используя записи узлов Ethereum (ENRs) и протокол обнаружения discv5 для поиска нужных пиров в Интернете, независимо от того, где они оказываются.
2. Доли пороговых ключей BLS12-381. Это закрытые ключи BLS, которые подписывают обязанности, как это делает обычный валидатор Ethereum, но с изюминкой. Несколько закрытых ключей генерируются таким образом, что вместе они представляют определенный закрытый ключ. Важно отметить, что не все закрытые ключи необходимы для создания действительной подписи для соответствующего открытого ключа. Считайте это мультисиговым кошельком для закрытого ключа валидатора.
При создании нового кластера распределенных валидаторов каждый оператор генерирует закрытый ключ (1) для своего клиента Charon, а затем с помощью панели запуска распределенных валидаторов подготавливает церемонию генерации распределенных ключей для создания закрытых ключей распределенных валидаторов (2).
После определения условий кластера, добавления всех операторов и их аутентификации через панель запуска операторы передают своим клиентам Charon созданный файл определения кластера, и начинается процесс DKG. Каждый клиент Charon находит друг друга в Интернете, устанавливает безопасную и зашифрованную линию связи, а затем создает эти закрытые ключи BLS таким образом, что ни один клиент никогда не контролирует и не знает, что представляет собой полный закрытый ключ. После завершения работы каждый клиент Charon записывает свои закрытые ключи на диск в широко распространенном формате EIP-2335 keystore. В рамках этого процесса закрытые ключи используются для создания депозитных данных для активации валидатора в выбранной сети. Это единственный случай, когда Charon имеет возможность подписывать личные ключи распределенного валидатора. После завершения процесса DKG закрытые ключи валидатора импортируются в выбранный оператором клиент валидатора.
Можно (но неразумно) поручить доверенному лицу (например, потенциальному клиенту) самостоятельно создать полный закрытый ключ, разделить закрытый ключ на доли, зашифровать доли закрытого ключа закрытым ключом каждого клиента оператора и выложить зашифрованные закрытые ключи в цепочку для всеобщего обозрения. Это наш первый корреляционный риск, и он связан с ущербом, который может быть нанесен, если оператор потеряет закрытый ключ своего клиента. В Charon ничего особенного не происходит, узел может начать действовать византийским образом, что не является серьезной проблемой, поскольку кластер устойчив к византийским сбоям. В альтернативной архитектуре злоумышленник может ретроспективно расшифровать (и опубликовать) все доли закрытых ключей валидаторов BLS, сидящих на цепочке, которые были отправлены этому скомпрометированному оператору. Это делает все распределенные валидаторы, частью которых был этот оператор, менее безопасными.
Промежуточное ПО
После создания распределенного кластера валидаторов следующим решением при проектировании архитектуры является снижение риска корреляционного слэшинга любой ценой. Charon стремится достичь этого, не имея возможности сделать что-то, что можно слэшировать. Charon не хранит закрытые ключи валидатора и не имеет возможности подписывать произвольные данные. Вместо этого Charon - это промежуточное программное обеспечение, которое находится между существующими клиентами консенсуса и клиентами валидаторов и перехватывает данные, проходящие между ними. Все, что делают клиенты Charon, это:
💨Приходят к консенсусу между собой относительно того, что должно быть представлено для подписания их подключенным клиентам валидаторов.
💨Собирают возвращенные подписи и объединяют их в общую подпись, которая рассылается по всей сети.
Мы считаем, что архитектура, основанная на промежуточном программном обеспечении, гораздо более безопасна и минимизирует доверие, чем альтернатива, которая заключается в реализации распределенного клиента валидатора как полноценного клиента валидатора с хранением закрытых ключей и возможностью подписывать произвольные данные. Если, например, рассмотреть наихудшие сценарии, а именно: Charon будет взломан в результате атаки на цепочку поставок, атаки с удаленным выполнением кода или команда Obol станет плохими игроками и решит выпустить вредоносный релиз, Charon не сможет нанести большой ущерб как промежуточное ПО. Если скомпрометированный клиент Charon предложит валидатору подписать потенциальный двойной голос или голос окружения, клиент валидатора проверит свою базу данных анти-слешинга, увидит, что он уже подписал что-то противоречащее, и просто откажется возвращать подпись. Charon может предложить валидатору подписать недействительный блок, но цепочка отвергнет это и просто сочтет валидатора оффлайн, что гораздо лучше, чем быть слэшером.
Как промежуточное ПО, Charon получает преимущество в том, что все существующие клиенты валидаторов являются отказоустойчивыми, чтобы дважды проверить, что ничего не случилось. Несколько реализаций, работающих вместе для валидации, делают вероятность непреднамеренного слэшинга исчезающе малой. Распределенные валидаторы, реализованные как полноценный клиент валидатора, способный подписывать произвольные данные без надзора второй программной реализации, имеют гораздо больший риск вызвать корреляционный слэшинг, на мой взгляд.
Коммуникация
По мере продвижения вниз по степени серьезности угрозы от компрометации ключа, риска слэшинга и риска коррелированного бездействия, следующим архитектурным решением, на которое следует обратить внимание, будет способ связи клиентов Charon друг с другом. Руководствуясь принципом не делать валидаторы более коррелированными, когда вы стремитесь сделать их менее коррелированными, мы решили свести к минимуму общую сетевую инфраструктуру между распределенными кластерами валидаторов.
Вместо того, чтобы каждый клиент Charon подключался к одной общей сети рассылки слухов, каждый кластер полностью изолирован от других. Клиенты Charon в кластере устанавливают прямые TCP-соединения со своими коллегами. Этот подход требует больше первоначальных настроек, чем подключение к общедоступной сети сплетен, поскольку вам нужно убедиться, что ваш узел Charon может быть доступен в общедоступном Интернете напрямую, но, по моему мнению, в долгосрочной перспективе это того стоит.
❗Прямые TCP-соединения надежны, сообщения не теряются, как это происходит в сети распространения слухов.
❗Прямые TCP-соединения намного быстрее, чем сигнатура, скачущая по сети через несколько хопов, прежде чем попасть к вам. Это повышает рентабельность валидатора.
❗Вашему клиенту не отправляются сообщения, не предназначенные для него.
❗Нет единого центрального сетевого уровня, при выходе из строя которого каждый отдельный распределенный валидатор переходит в автономный режим при корреляционном отключении.
❗Если вы запускаете кластер в облачной инфраструктуре провайдера, то использование их частной сети между центрами обработки данных обеспечивает высокую скорость, пропускную способность и субсидирование затрат. Использование их сети на выходе в публичный интернет для протокола сплетен влечет за собой дополнительные расходы на облако для более медленной сети с меньшей пропускной способностью.
В настоящее время Obol имеет только одну часть общей сетевой инфраструктуры, и это загрузочный узел discv5, позволяющий узлам Charon находить друг друга. Для сообщества стейкхолдеров, заботящихся о безопасности, имеет смысл самостоятельно разместить свой собственный bootnode, чтобы разорвать единственную общую связь между кластерами Charon. Мы упростили эту процедуру, и уже несколько участников тестовой сети Athena сделали такой выбор.
Версионность
И последнее, но не менее важное: выполнение тяжелой работы по отсоединению кластеров друг от друга открывает еще один способ обеспечить отсутствие корреляционных сбоев, и это касается обновления программного обеспечения. Обновление ПО - это всегда страшно и рискованно, тем более в распределенной системе. Если у вас каждый клиент использует одну и ту же шину сообщений; если вы выпустите новую версию, которая изменит способ структурирования сообщений, старые версии программного обеспечения не будут знать, что делать с этими сообщениями. Чтобы обойти эту проблему, вам нужно установить время (или номер слота), когда новый протокол станет активным, и вы сообщаете всем пользователям вашего ПО по каналам связи, что они должны установить последнюю версию вашего ПО до этого времени, иначе их узлы перейдут в автономный режим. Как только это время наступает, каждый распределенный валидатор одновременно переходит на новый протокол. Мне едва ли нужно подчеркивать, насколько это корректно, если что-то пойдет не так, это будет плохо для всех. Даже если ничего не пойдет не так, если люди не обновились вовремя, они будут вынуждены уйти в оффлайн.
Иногда, например, когда вы запускаете блокчейн L1 с несколькими независимыми клиентскими реализациями, выбор согласованного момента для обновления является единственным возможным решением для распространения изменений, однако в Obol, поскольку каждый кластер независим друг от друга, в сочетании с тем, что эти кластеры обладают византийской отказоустойчивостью, становится возможным позволить каждому кластеру обновить протокол до последней версии в свое удовольствие, когда они будут к этому готовы. Мы встраиваем в клиентов Charon функцию плавного обновления версий таким образом, что они периодически приходят к консенсусу друг с другом относительно последней версии протокола, которую они все используют, и как только все работают с последним программным обеспечением, кластер понимает: "Эй, мы все сейчас говорим на версии n+1, давайте использовать ее со следующей эпохи и далее". Это снижает риск корреляции, связанный с развертыванием изменений, кластеры могут обновляться по одному, а по мере укрепления уверенности в стабильности нового релиза все кластеры могут обновляться не синхронно.
Вывод
Я начал эту заметку с того, что уже четыре года размышляю над архитектурой доказательства доли Ethereum. Надеюсь, к концу этой статьи вы убедитесь, что Obol серьезно относится к важности безопасного внедрения DVT в экосистему. Я также надеюсь, что после этой статьи вы будете лучше понимать компромиссы, которые могут быть сделаны при проектировании распределенных валидаторов. Я твердо убежден, что архитектура с минимизацией доверия, без опеки и корреляции - это гораздо более здоровый способ внедрения валидации высокой доступности в пространство, чем пользовательский клиент валидатора с общим сетевым уровнем.
Благодарю за внимание.
2 notes
·
View notes
Кстати.
Только что решил войти в ТГ, вот он очень помог разработчикам инфу "отправить".
А это почему я решил сразу разработчикам? Блин, если честно, то на самом деле, по идее должна быть хотя бы какая то почта, что бы информацию куда либо отправлять, есть технические ответы, но в виде "вопрос-ответ". Можно нечто подобное тикетов открывать, а вот скриншот послать я не нашел.
По этому, по скриншо у на странице где обитают разработчики есть такая ссылка:
Андрюша, если в будущем твой техно криминальчик будет раскрываться, то ты только по этому от 15 лет себе с сестрой заслужил, по законодательству даже этой страны. Подвиги своего сотоварища по коллективной агрессии хочешь повторить. Только у артема я тогда забрал заявление.
Ну а раз так, то добавлю здесь ссылку хотя бы на Google Drive.
Вот теперь криптовалютным вкладчикам нужно знать, это один из примеров, что вам реально нехер тут вкладывать, а если хотите в крипту вкладывать, почитайте об этом. За такие вещи мало бошку оторвать. Я надеюсь если тут будет война, мусоров в первую очередь будут реально по их же мотивам просто резать как конченых фашистских подонков, по полной программе, и вот таких конченых подонков, как Мельниченок Андрей, и его сестра. И еще раз повторюсь, гляньте тут ниже ролики по украине. Ну а если будет, и их накроет, и часть их завезут покзательно в Международный Уголовный Суд, хорошо если всех, живыми. И поставят нормальное мвд, за которым строгая ответственность, и за ответственность, они сидели в строго дисциплинарных учреждениях. Зи это освещалось, что бы мрази обсираясь каждый день ходили на работу, и защищали от агрессии, а не совершали с подельниками. Да, андрюшка, солдат? А им сроки от 10 до 30 лет, за курирование ведение, и покрывательство бытовой смертоносной агрессии как минимум, вот это было бы хорошо. А то мусорки, присягу принимают и сразу в мусорки. Да пупсики? А военнобязанную ответсвенность теряют мусорки. Ты черт мусорской чем от солдата отличаешься? По уставу призывному, к которому присягаешь? 🤔 А, "-я когда уставу присягаю, шапку короля надеваю", вероятно. "-я делаю что хочу, используя должностные обязанности", да пупсики? Так это вот кому на#уй по голове мало постучали хорошенечко. А с Discord так вообще "у нас тут широкое поле".
Хм. Почему это да, пупсиков которые порочат форму совергая коррупцию исполняя доложностнве обязанности, увольняют, а не как нужно то в дизбаты на хорошие сроки не сажают? Солдатов можно, а этих пупсиков нет? Хм 🤔. Вероятно если бы прокуратура и дизбат работали как нужно, и их сажали, то Шуневич красавиц так бы и не догулялся, и еще и смотрите до Международного Уголовного Суда, как больше языкастых людей с головой появится доедет, вот с такими Андрюшками.
0 notes