О защищённости блокчейнов — часть 3

0

В первых двух частях этой серии мы изучили взаимодействие вероятностной природы распределённых блочных структур данных (DBDS — distributed block data structures) и способов изменения традиционного анализа систем с задачей византийских генералов (BFT — Byzantine Fault Tolerant) для DBDS. Цель этой серии публикаций — продемонстрировать, что существует небольшое количество базовых элементов безопасности, которые присущи большинству (если не всем) распределённым консенсусным алгоритмам и DBDS.

Сперва мы доказали наличие этих элементов во время рассмотрения кажущейся универсальности техник анализа DBDS и распределённых консенсусных протоколов, большая часть которых делает следующее: они устанавливают набор аксиом, создают среду для игры между честными игроками и противниками, затем создают границы вероятности победы противника в этой игре. Мы также узнали, что набор аксиом этих систем зачастую сводится к двум вещам:

  • Жизнеспособность: реестр продолжает расти и принимать новые транзакции или изменения состояний.
  • Постоянство/безопасность: честные транзакции в итоге попадают в реестр и не могут быть удалены (без колоссальных усилий) после того, как прошло достаточное количество времени.

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

  • [Часть 3] Avalanche как реализация консенсусного протокола Stellar
  • [Часть 4] Сокращение асинхронных моделей Биткойна, Ekiden от Oasis Labs и Zexe до уровня «идеального функционала»

Но какое отношение к безопасности блокчейнов имеет универсальная концепция анализа? Универсальная концепция для оценки безопасности хороша, но она не рассказывает нам о самой безопасности. Я хочу создать обобщённое понятие безопасности (например, выяснить, какие элементы безопасности являются общими для всех протоколов), чтобы создать лучшее понимание минимальных необходимых и достаточных условий для создания безопасного блокчейна. Более того, тот факт, что определённые протоколы могут быть дополнены элементами других протоколов, предполагает, что существует некая общая база для создания более специализированного протокола. Таким образом консенсусный протокол Stellar (Stellar Consensus Protocol — SCP), в отличие от других протоколов, о которых говорилось в предыдущих статьях, предлагает обобщённую концепцию в противопоставление конкретной реализации. Сначала я расскажу об этом протоколе подробнее и покажу примеры, доказывающие, что его обобщённая концепция подходит для разных консенсусных механизмов. Затем я рассмотрю Avalanche, опишу, как можно его реализовать в качестве примера SCP, и приведу численное доказательство. Стоит отметить, что Avalanche обладает более высоким уровнем безопасности, чем указано в его изначальной документации. В конце я рассмотрю идеальный функционал будущего и то, как вероятностные эквивалентности между машинами абстрактных состояний (например, эквивалентность между Avalanche и примером SCP) позволяют проводить комплексный анализ консенсуса и превращать слабые гарантии в сильные.

Консенсусный протокол Stellar был создан Дэвидом Мазьером, профессором Стэнфорда и главным научным сотрудником Stellar Development Foundation (организация поддерживает клиентский код сети Stellar). SCP внедрён в stellar-core, и, по моему мнению, это один из лучших существующих клиентских кодов блокчейна в экосистеме. Ранее Мазьер также создал Kademlia — одноранговую распределённую хеш-таблицу (и алгоритм ячеистых сетей) и ограничения компромиссов между безопасностью и жизнеспособностью систем BFT. Учитывая всё вышесказанное, неудивительно, что эта работа фокусируется на протоколе с гарантиями, похожими на BFT, с блокчейновой сложностью коммуникации. В частности, протокол пытается придерживаться и системы BFT с доступом только для определённых лиц, и инклюзивной блокчейн-системы. Это реализуется благодаря использованию не традиционных групп BFT, где каждый участник сообщается друг с другом, а ограниченных групп «доверенных узлов» для подтверждения. Пример проиллюстрирован ниже:

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

В традиционном BFT для того чтобы изменить транзакцию, нужно согласие по крайней мере 2/3 участников. На первом рисунке мы видим сеть из пяти узлов, которые сообщаются друг с другом по линиям. Для того чтобы каждый узел мог решить, добавлять транзакцию в локальную копию реестра или нет, ему нужно получить сообщение о подтверждении ото всех остальных узлов (например, по крайней мере от 2/3 узлов). Это значит, что для достижения консенсуса должен существовать сетевой путь от каждой пары узлов, а значит, стоимость обмена данными равна квадрату от количества узлов [0]. Вместо того, чтобы фокусироваться на явной коммуникационной сети, как в случае с протоколами BFT, SCP фокусируется на том, что Мазьер называет срезом кворума [1]. Срез кворума — это набор подгрупп узлов, которые должны прийти к соглашению, прежде чем занести транзакцию в локальный реестр. Важно, что эта подгруппа не должна быть большой (относительно количества узлов). Более того, один узел обычно участвует в нескольких срезах кворума, что показано в функции выбора кворума:

для узла N. Например, в нижней части рисунка мы видим, что для узла 1 существуют две подгруппы, с которыми он может прийти к соглашению: {1,3,5} и {1,2,5}. Согласно алгоритму протокола SCP, узел должен прийти к соглашению только с одним элементом из его среза кворума. Это значит, что узлу 1 нужно достичь соглашения с {1,3,5} или {1,2,5}, чтобы внести изменения в свой реестр. Идея заключается в том, что если размер подгрупп для достижения консенсуса сублинейный, то мы можем достичь косенсуса с субквадратной коммуникационной сложностью. Похоже на бесплатный сыр!

Прежде чем переходить к другим допущениям и ограничениям для выполнения SCP, посмотрим на то, как в этом случае работает традиционный протокол BFT (с подгруппой SCP). Допустим, что у нас есть протокол BFT с группой узлов N, где |N| = n. Для каждого элемента определим следующий набор подгрупп:

Эти наборы — самые маленькие наборы, с которыми n может прийти к соглашению BFT для добавления транзакции в локальную копию реестра. Затем любая функция выбора кворума Q_{BFT} должна следовать следующему ограничению:

Проще говоря, это значит, что для достижения консенсуса узлу n в N нужно прийти к соглашению с хотя бы 2n/3, для того чтобы добавить транзакцию в свой реестр.

Те, кто изучают теорию распределённых систем, с сомнением отнесутся к идее, что один узел должен согласиться с сублинейным числом людей для достижения консенсуса. Конечно, это не бесплатный сыр. Вместо того чтобы просчитывать количество узлов, необходимых для достижения консенсуса, SPC создает необходимые и достаточные условия с набором срезов кворума. Эти условия топологичны по своей природе и соотносятся со свойствами связанности срезов кворумов. Мы предоставим наглядный пример таких условий. Во-первых, давайте рассмотрим понятие кворума — набор узлов и срезов кворума, которые обладают свойством так называемого «транзитивного замыкания». В каком-то смысле это означает, что U — это самодостаточный набор. Узлам не нужна входящая информация от других узлов, чтобы достичь консенсуса. Пример проиллюстрирован ниже:

Оставьте ответ

Ваш электронный адрес не будет опубликован.