Перевод Кластер критической децентрализации 36c3 - Разбиение блокчейна или шардинг

Тема в разделе "Журналы о Monero", создана пользователем Mr. Pickles, 14 июн 2021.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    938
    Симпатии:
    244
    Аннтотация

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


    Стенограмма выступления

    Диего: И у нас на очереди выступление, посвящённое разбиению блокчейна на части (шардингу). Может, я как-то неправильно произнёс твоё имя? Не мог бы ты повторить?

    Ченг: Ченг Вонг.

    Диего: Я ничего не напутал, но изначально неправильно услышал, как оно произносится на самом деле. Итак, мы поговорим о разбиении блокчейна на части. И если вам интересно, что такое разбиение блокчейна, что это вообще такое: просто какое-то громкое словосочетание, больше чем просто громкое словосочетание, что-то действительно значимое для Ченга — он ответит на все эти вопросы. И прежде чем продолжить и занять своё место, я передам микрофон ему. Давайте поаплодируем Ченгу.

    Ченг: Спасибо за вступление. Итак, сначала немного о себе, о своём образовании. Сначала я занимался теорией чисел и вопросом организации вычислений на суперкомпьютерах, а потом попал в криптопространство. Сейчас моя работа сосредоточена на проекте, связанном с разбиением блокчейна, который называется Alephium. Перед нами стоит задача по созданию децентрализованного «лёгкого» блокчейна с возможностью очень быстрого проведения транзакций. В рамках этого выступления я кратко расскажу о других исследованиях, которые проводились другими проектами, такими как Ethereum 2.0, например, а также некоторыми другими похожими проектами, а также освящу основные проблемы. А после я объясню, как наш проект позволяет решить все имеющиеся в данной области проблемы.

    Здесь показан отдельный блокчейн, Bitcoin или Ethereum, и нам бы хотелось улучшить скорость проведения транзакций. Вероятно, все вы слышали о дилемме масштабируемости, согласно которой, если вы хотите масштабировать блокчейн, вам в некоторой мере придётся пожертвовать одним из трёх параметров. Таким образом, если заглянуть чуть глубже, для решения этой задачи достижения компромисса нам требуется учесть гораздо больше параметров.

    Здесь представлена более научная модель анализа блокчейна. Как правило, мы рассматриваем блокчейн в качестве системы репликации машины состояний. В случае с репликацией машины состояний существует три пути использования данных и реализации консенсуса. С точки зрения данных существует множество ограничений, и нам приходится делать некоторые допуски в отношении пропускной способности сети, и топология сети в данном случае также играет важную роль: будет ли это p2p сеть или же она будет чуть более централизованной и в неё будут входит узлы самых различных типов. Итак, когда речь идёт о реализации блокчейна, прежде всего, нам необходимо установить дерево: в случае Bitcoin это дерево организации UTXO, а в случае Ethereum — дерево Меркла. И уже тут появляются ограничения. Прежде всего, ограничение, связанное с вводом/выводом, далее следует модель безопасности, то есть выполняются ли команды последовательно или же поддерживается параллельное выполнение команд. Третье ограничение касается консенсуса, поскольку нам приходится моделировать, делать допуски в отношении сети: некоторые проекты предполагают наличие синхронизированной сети, другие — частично синхронизированной и так далее. А что касается модели безопасности, то тут всё зависит от того, какое количество мощности хеширования отводится на часть разбитого блокчейна (шард). И самой важной составляющей является консенсус, компромисс между производительностью и безопасностью. Мы не можем одновременно обеспечить и то и другое, поэтому приходится идти на компромисс. По сути, масштабирование блокчейна — довольно сложная тема, и мы уже были свидетелями множества предложений. Как правило, когда мы слышим заявления вроде: «Мы можем обеспечить производительность до миллиона транзакций в секунду» - никто не говорит о том, какими параметрами придётся пожертвовать при этом и какие допуски сделать.

    И здесь приводятся некоторые способы масштабирования блокчейна. Для начала возьмём централизованный обмен. Это определённо должно повысить пропускную способность транзакций, но в этом случае сильно страдает модель безопасности. То же относится и к большому размеру блоков. Увеличение размера блоков немного улучшило бы ситуацию, например, в случае с Bitcoin, но пришлось бы вводить некоторые допуски, связанные с пропускной способностью сети, а также с тем, является ли сеть синхронизированной или нет, влияет ли это на задержку, а также с рядом других аспектов, в которые я не буду углубляться. Но шардинг на данный момент считается одним из самых перспективных способов масштабирования блокчейна за счёт обеспечения параллельной обработки данных, выполнения и обеспечения консенсуса одновременно. И мы хотим достичь этого с минимальными потерями, минимально жертвуя другими параметрами, путём минимальных допусков в отношении сети, с минимальным ущербом для модели безопасности, например, мы хотим, чтобы она сохранилась в том же виде. Если мы создаём блокчейн, мы хотим, чтобы он оставался децентрализованным, мы хотим, чтобы он по-прежнему работал честно и никто не имел бы преимущества с точки зрения вычислительной мощности. Как-то так.

    Итак, возможность шардинга исследуется уже в течение нескольких лет. Все, кто интересовался этой темой, большинство таких людей, должно быть, заметили, что дела идут не совсем хорошо. Особенно в случае с Ethereum 2.0, где работа очень сильно запаздывает. Сейчас я собираюсь коротко рассказать о популярных методах, лежащих в основе Ethereum 2.0, а также некоторых похожих проектов, и о том, как они развиваются.

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

    Идея, популярный метод состоит в использовании доказательства PoS и выборки валидаторов. То есть у нас есть координирующий блокчейн (Beacon Chain), ряд валидаторов, и мы используем алгоритм для случайного распределения этих валидаторов между различными шардами. И здесь появляется первый допуск, связанный с данным подходом. Как можно увидеть, у нас имеется очень большой набор валидаторов, и при этом мы допускаем, что подавляющее большинство узлов являются честными. Но такой допуск касается уже не только большинства. Если мы хотим, чтобы в каждом шарде поддерживался достаточный уровень безопасности, нам необходимо, чтобы 70 или даже 80 процентов валидаторов были честными. Безусловно, это зависит от количества валидаторов. То есть если количество будет недостаточным, то это будет небезопасно. Например, когда вы начинаете проект, у вас имеется всего 200 валидаторов, и этого количества никогда не будет достаточно, чтобы обеспечить должный уровень безопасности. Я не буду приводить доказательства, но это, по сути, один из допусков, который не сохранится в краткосрочной перспективе, поскольку будет введён сервис «ставок», и большинство пользователей предпочтёт не заниматься всем самостоятельно, а будет полагаться на этот сервис, что также сделает этот допуск сомнительным.

    И существует ещё одна критическая проблема, связанная с безопасностью. Речь идёт о так называемом «адаптивном злоумышленнике». То есть, когда вы распределяете валидаторов случайным образом между двумя разными шардами, вы можете «подкупить» этих валидаторов с целью проведения атаки. Это вполне осуществимо. Если вы можете мотивировать валидаторов с помощью смарт-контрактов, например, этот процесс можно автоматизировать. То есть на практике это вполне реально, и вот простой пример: у вас есть сотня шардов и 50% токенов являются «залогом» друг для друга, и нужно всего лишь 0,5 процентов, чтобы провести атаку. Так что это тоже представляет собой проблему.

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

    Существуют способы решения этой проблемы, и одним из решений являются клиенты без сохранения состояний. Такие клиенты довольно хорошо решают эту проблему, но их применение на данный момент не является практичными. В сообществе Bitcoin проводится множество исследований, но все они пока неприменимы на практике. И с годами всё станет только запутанней, поскольку в случае с маленькими контрактами всё всегда сложнее. В Ethereum также проводят исследования с использованием своих доказательств, но они также предполагают некоторые издержки, так как их размер довольно велик. Так что будем ли мы использовать клиенты без сохранения состояний в ближайшем будущем — это открытый вопрос.

    Теперь давайте предположим, что выборка валидаторов на предыдущем этапе была приемлемой. Затем, допустим, мы захотим провести транзакцию между шардами. Как нам это сделать? В рамках данной модели, в соответствии с существующим подходом, люди, как правило, используют так называемый «протокол двухфазного обязательства». То есть в шарде A есть Элис, которая хочет перевести деньги Бобу, который находится в шарде B, и для этого ей сначала необходимо создать «расписку». И она создаёт транзакцию, чтобы сказать: «У меня есть токен на такую-то сумму, и я хочу отправить его Бобу в шард B». И как только в шарде A по этой транзакции будет получено обязательство, Боб в шарде B сможет воспользоваться доказательством по такой расписке, чтобы получить деньги. Таким образом, в данном случае нам требуется две фазы или две транзакции, но на практике всё сложнее из-за комиссий и различных аспектов безопасности. В данном случае я рассматриваю только зависимости между транзакциями, поскольку транзакция в шарде B, где находится Боб, зависит от транзакции Элис, находящейся в шарде A. Но может случиться так, что шарды окажутся разветвлёнными, и тогда из-за наличия форков зависимости станут сложнее в связи с путями проведения транзакций, и нам следует очень внимательно отнестись к решению этой проблемы. При наличии тысячи и двадцати четырёх шардов граф зависимостей будет очень хаотичным, и будет очень сложно считать правильные зависимости.

    Есть способы решения этой проблемы, но они не идеальны. Первый заключается в том, чтобы построить шард, как направленный ациклический граф. Например, всякий раз, когда вы будете получать средства, вы станете проверять данные не только вашего шарда, но также и данные соседнего шарда. Так можно проверить, что транзакция прошла правильно с обеих сторон. Данный метод был впервые предложен Владом, но с ним связан ряд вопросов, поскольку, скажем, если вы проводите транзакцию из A в B и в C, то участник из шарда C не сможет проверить оригинальную транзакцию в A, поскольку шард A не является соседним для C. Таким образом, решается часть проблемы, но не вся проблема полностью. Кроме того, возможность обработки зависит от полноты алгоритма, системы, возможности реализации форков, и в случае с PoS я настроен весьма скептически.

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

    Ещё одна проблема заключается в доступности данных. В рамках существующей архитектуры Ethereum 2.0 и других подобных архитектур шардинг не предусмотрен. Такие архитектуры всегда опираются на основной блокчейн. А в основном блокчейне не обозначаются блоки из других шардов. Загружается только заголовок блока из другого шарда. В этом случае возможен конфликт между валидаторами и шардом, в результате которого будет создан один и тот же блок, но координирующему блокчейну при этом будет раскрыт только заголовок блока. То есть в нём будут присутствовать все обязательства, но валидаторы никогда не раскроют полного блока. Это сделает блок недоступным, что вызовет сбой всей системы.

    Итак, нами был рассмотрен целый ряд проблем, связанных с существующим подходом. Я называю данный проект «методом доказательства PoS плюс метод выборки». И одной из проблем такого подхода является возможность описания всего в одном предложении.

    По сути, это переход от подхода, который можно обозначить как «не доверяй, но проверяй», к подходу «не проверяй, но доверяй». В случае Bitcoin и Ethereum мы проводим валидацию всех блоков, чтобы знать, если что-то пойдёт не так, и в этом случае мы не отклоняем блок сразу же. При использовании подхода «PoS плюс метод выборки» дело обстоит уже иначе: вы даёте валидаторам шанс, вы допускаете, что в каждом шарде не более трети блоков будут вредоносными. И вы доверяете валидаторам процесс верификации. И в конечном счёте каждый узел становится «лёгким» или не требующим доверия узлом. Но на сегодняшний день, как мне кажется, такие лёгкие узлы пока являются недостаточно зрелыми с точки зрения безопасности. То есть я не хочу сказать, что данный подход является в корне неверным, но он ещё находится на стадии исследования, и остаётся нерешённым целый ряд открытых вопросов.

    Теперь мне бы хотелось показать вам, как мы собираемся реализовать процесс шардинга на практике. Нами предлагается новый алгоритм под названием BlockFlow. Это и есть наш подход к шардингу. Прежде всего, мне бы хотелось отметить несколько моментов. Во-первых, мы по-прежнему придерживаемся подхода «не доверяй, но проверяй». Я думаю, что это критически важно с точки зрения поддержания высокого уровня безопасности. Мы используем модель PoLW и UTXO. Это обеспечивает лёгкость нашего решения. Этот момент я поясню позже. Для проведения транзакции в рамках нашей системы требуется всего один шаг. Как я уже говорил, в существующих исследованиях используется протокол двухфазного обязательства, что влияет на пользовательский опыт. У нас имеется законченное решение для реализации шардинга. Это уже не исследования, мы работали над ним в течение долгого времени, и у нас уже есть альфа-система, и сейчас мы находимся на этапе испытаний.

    Теперь давайте посмотрим, как мы это делаем. Сначала мы используем модель UTXO. Прежде всего, мы делим адреса на G групп. Так как транзакции могут проводиться между любыми двумя из этих групп, мы имеем G × G возможных типов групп транзакций. Так, например, на левом графике у нас имеется девять типов транзакций: от A к B, от A к C, от A к A и так далее. Мы строим блокчейн для каждого из этих типов. Таким образом, у нас получается G × G блокчейнов.

    И вот что хорошо в данном виде разложения: прежде всего, если вы захотите провести транзакцию из группы B в группу A, мы подготовим транзакцию, как мы это делаем в случае с Bitcoin, мы опубликуем в блокчейне обязательство, соответствующее переводу из A в B, и всё готово. Нет никакой необходимости во втором этапе. Затем, что касается группы B, нам не нужно проводить транзакций между A и C, а также C и A, поскольку они не имеют отношения к группе B. Таким образом, объём данных, сохраняемых одним узлом, сокращается примерно на 1/G.

    Но на самом деле основной проблемой являются зависимости между данными шардов, и здесь очень трудно выработать консенсус. Это, как в случае с системой реализации форков. Нами был предложен алгоритм под названием BlockFlow, позволяющий разрешить проблему форков и достичь консенсуса. Я не стану вдаваться в детали, а приведу довольно концептуальное описание. Каждый новый блок выбирает специальные хеши, которые играют роль зависимостей, следующих определённым правилам. Во-первых, это гарантирует отсутствие недействительных зависимостей, поскольку если одна транзакция зависит от форков в другом шарде, она будет недействительной. Поэтому мы используем такие зависимости. А во-вторых, необходимо, чтобы такой выбор зависимостей был достаточно эффективным, так как в противном случае можно просто выбирать последний хеш во всех остальных шардах. Но и этот подход недостаточно эффективен и имеет свои недостатки. Поскольку у нас имеется такая определённая структура данных зависимостей, каждый блок может определять уникальную последовательность блоков, сеть, показанную слева, сеть из последовательности блоков. Таким образом, каждый блок использует эти зависимости, чтобы обозначить принадлежность к последовательности блоков. А затем при помощи значения алгоритма PoW мы определяем наилучшую последовательность. Теперь узлы должны проводить валидацию зависимостей и транзакций. Валидация зависимостей — это нечто новое, что может быть реализовано как в Bitcoin, так и в Ethereum.

    Но каковы издержки? Издержки заключаются в том, что, прежде всего, нам необходимо некоторое время для вычислений, использования некоторого алгоритма для вычисления структуры данных зависимостей. А валидация происходит быстро, гораздо быстрее, чем вычисление, насколько я помню, 2 секунды при G = 32. И даже при том, что 2 секунды — это всё же много, всё равно это довольно быстро. Также нам требуется больше пространства для этих зависимостей. По сути, это несколько хешей, и мы просто можем включить их в блок. Для клиента это не проблема, а для полного узла наличие таких зависимостей вообще не имеет никакого значения.

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

    И последний момент — репликация, которая по-прежнему соответствует подходу «не доверяй, но проверяй». Метод «PoS плюс выборка валидаторов» не вызывает никаких проблем. Нам не нужно доверять кому-то с точки зрения валидации. Только самим себе. В некоторых случаях, как вариант, вы можете связаться со своими друзьями и создать вместе с ними свой собственный реестр, реализовав форк. Я думаю, что это более приемлемо, чем случайный выбор валидаторов. Но, повторю, это вариант, и вы можете использовать очень маленькие кластеры, так как на ранних этапах, когда рыночная капитализация ещё очень и очень низкая, кластер может поддерживаться даже одним узлом, если ваш компьютер достаточно мощный. Или вы можете разбить всё на множество лёгких кластеров и создать очень-очень дешёвый узел, купив оборудование на Amazon.

    Также мы можем провести аналогию между этим подходом и моделью вычислений. Все мы знаем, что модель вычислений заключается в переходе от последовательных вычислений к параллельному построению, по сути, модулированию, и далее к распределённым вычислениям — у вас есть ряд компьютеров, и каждый из них может параллельно выполнять работу, выполнять параллельные вычисления. И в нашем случае мы имеем один блокчейн, Bitcoin или Ethereum, и есть некий блокчейн на базе DAG. На самом деле большинство технических проектов разрабатываются ненадлежащим образом, а BlockFlow, как показано, представляет собой распределённый блокчейн на базе DAG, так что во многом напоминает модель распределённых вычислений. И это как бы позволяет нам опираться на исторические примеры, даёт нам уверенность. Так что это имеет смысл.

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

    Диего: Большое спасибо, Ченг. У нас не осталось времени на вопросы, но вы сможете задать их ему вне сцены, он останется здесь для этого. А мы переходим к следующему выступлению, посвящённому атомным свопам Monero-Bitcoin. Это сочетание, атомные свопы, у всех на слуху, и все любят повторять его. Сейчас в течение пары минут мы настроим всё так, чтобы работало. Да, иногда что-то выходит из строя. Даже интересно, не бывает C3 без того, чтобы хоть что-то не вышло из строя. Но мы вернёмся вскоре.

    ---

    Источник: Critical Decentralisation Cluster 36c3 - Blockchain Sharding (Cheng Wang)

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.