Основы шардинга

Начнем с самого простого подхода к шардингу. В этом подходе вместо запустив один blockchain, мы запустим несколько и вызовем каждый такой blockchain a «осколок». Каждый шард будет иметь свой собственный набор validator. Здесь и ниже мы используем общий термин «validator» для обозначения участников, которые проверяют транзакции и производить блоки либо путем майнинга, например, в Proof of Work, либо с помощью голосования на основе голосования. 1Этот раздел ранее был опубликован по адресу https://near.ai/shard1.. Если вы читали его раньше, перейти к следующему разделу.

механизм. А пока давайте предположим, что шарды никогда не общаются друг с другом. другое. Несмотря на свою простоту, эта схема достаточна для того, чтобы обозначить некоторые первоначальные основные проблемы шардинга. 1.1 Разделение валидаторов и цепочки маяков Допустим, система состоит из 10 шардов. Первая проблема заключается в том, что с каждым имеет свои собственные validator, каждый шард теперь в 10 раз менее безопасен, чем вся цепочка. Итак, если несегментированная цепочка с X validators решит провести хард-форк в сегментированную цепочку и разбивает X validator на 10 сегментов, каждый из которых теперь имеет только X/10 validator, и для повреждения одного фрагмента требуется только повреждение 5,1% (51% / 10) от общего количества validators (см. рисунок 1), Рисунок 1: Разделение validator на сегменты что подводит нас ко второму моменту: кто выбирает validators для каждого шарда? Контроль над 5,1% validators наносит ущерб только в том случае, если все эти 5,1% validators находятся в одном шарде. Если validator не могут выбрать, какой осколок они получат для проверки в, участник, контролирующий 5,1% validators, вряд ли получит все их validator в одном шарде, что значительно снижает их способность к компрометации система. Сегодня почти все конструкции шардинга основаны на некотором источнике случайности. назначьте validators осколкам. Случайность на blockchain сама по себе является очень сложной темой и выходит за рамки этого документа. А пока предположим, что есть некоторый источник случайности, который мы можем использовать. Мы рассмотрим задание validators в подробнее в разделе 2.1. Как случайность, так и присвоение validator требуют вычислений, которые не специфичный для любого конкретного шарда. Для этого расчета практически все существующие проекты имеют отдельный blockchain, которому поручено выполнять операции необходимые для обслуживания всей сети. Помимо генерации случайныхномера и присвоение осколкам validator, эти операции часто также включают получение обновлений от шардов и создание их снимков, обработку ставки и сокращение в системах Proof-of-Stake, а также ребалансировку шардов, когда это функция поддерживается. Такая цепочка называется цепочкой маяков в Ethereum, релейной цепочка в PolkaDot и концентратор Cosmos в Cosmos. В этом документе мы будем называть такую ​​цепочку Beacon-цепочкой. Существование цепочки Beacon подводит нас к следующей интересной теме: квадратичный шардинг. 1.2 Квадратичный шардинг Шардинг часто рекламируется как решение, которое бесконечно масштабируется в зависимости от числа узлов, участвующих в работе сети. Хотя теоретически возможно разработайте такое решение для шардинга, любое решение, имеющее концепцию маяка Chain не имеет бесконечной масштабируемости. Чтобы понять почему, обратите внимание, что Маяк цепочка должна выполнить некоторые бухгалтерские вычисления, например назначить validators осколки или блоки цепочки осколков моментальных снимков, пропорциональные количеству шардов в системе. Поскольку цепочка Beacon сама по себе представляет собой единый blockchain, с вычисление ограничено вычислительными возможностями узлов, управляющих им, количество осколков естественно ограничено. Однако структура сегментированной сети действительно обеспечивает мультипликативную влияние на любые улучшения его узлов. Рассмотрим случай, когда произвольный улучшена эффективность узлов в сети, что позволит им более быстрое время обработки транзакций. Если узлы, управляющие сетью, включая узлы в цепочке Beacon, станет в четыре раза быстрее, тогда каждый шард сможет обработать в четыре раза больше транзакций, а цепочка Beacon сможет поддерживать в 4 раза больше шардов. Пропускная способность системы увеличится в 4 × 4 = 16 — отсюда и название квадратичного шардинга. Трудно дать точную оценку количества осколков. жизнеспособна сегодня, но маловероятно, что в обозримом будущем пропускная способность потребности пользователей blockchain перерастут ограничения квадратичного сегментирования. Огромное количество узлов, необходимых для безопасной работы с таким объемом шардов. вероятно, на порядки превышает количество узлов, работающих на всех Сегодня blockchains вместе взятых. 1.3 Государственное шардинг До сих пор мы не очень хорошо определили, что именно является отделенным и неразделенным. когда сеть разделена на сегменты. В частности, узлы в blockchain выполняют три важные задачи: они не только 1) обрабатывают транзакции, но и также 2) ретранслировать проверенные транзакции и завершенные блоки на другие узлы и 3) хранить состояние и историю всей сетевой книги. Каждый из этих трёх задач предъявляет возрастающие требования к узлам, эксплуатирующим сеть:1. Необходимость обработки транзакций требует большей вычислительной мощности с увеличение количества обрабатываемых транзакций; 2. Необходимость ретрансляции транзакций и блоков требует увеличения пропускной способности сети с увеличением количества ретранслируемых транзакций; 3. Необходимость хранения данных требует большего объема памяти по мере роста штата. Важно отметить, что в отличие от вычислительной мощности и сети, требования к хранилищу растут, даже если скорость транзакций (количество обработанных транзакций) в секунду) остается постоянным. Из приведенного выше списка может показаться, что требования к хранению будут самый актуальный, поскольку он единственный, который со временем увеличивается даже если количество транзакций в секунду не изменится, но на практике Самым насущным требованием сегодня является вычислительная мощность. Все состояние Ethereum на момент написания этой статьи имеет размер 100 ГБ, которым легко управляет большинство узлов. Но количество транзакций, которые Ethereum может обработать, составляет около 20, заказы величина меньше, чем это необходимо для многих практических случаев использования. Zilliqa — самый известный проект, который занимается обработкой, а не хранением данных. Разделение обработки является более простой задачей, поскольку каждый узел имеет всю состояние, что означает, что контракты могут свободно вызывать другие контракты и читать любые данные. из blockchain. Для обеспечения обновлений необходимы некоторые тщательные инженерные разработки. из нескольких шардов, обновляющих одни и те же части состояния, не конфликтуют. В В этом отношении Zilliqa придерживается относительно упрощенного подхода2. Хотя было предложено сегментирование хранилища без сегментирования обработки, это крайне редко. Таким образом, на практике шардинг хранилища, или State Sharding, почти всегда подразумевает сегментирование обработки и сегментирование сети. Практически при государственном шардинге узлы в каждом шарде строят свои собственный blockchain, содержащий транзакции, затрагивающие только локальную часть глобальное состояние, назначенное этому осколку. Следовательно, validator в шарду нужно только хранить свою локальную часть глобального состояния и только выполнять, и, как таковые, только ретранслируют транзакции, которые затрагивают их часть состояния. Это раздел линейно снижает требования ко всем вычислительным мощностям, хранилищам и пропускной способности сети, но создает новые проблемы, такие как доступность данных и транзакции между сегментами, обе из которых мы рассмотрим ниже. 1,4 Межсегментные транзакции Модель сегментирования, которую мы описали до сих пор, не очень полезна, потому что, если отдельные осколки не могут общаться друг с другом, они не лучше, чем несколько независимые blockchains. Даже сегодня, когда шардинг недоступен, существует огромный спрос на совместимость между различными blockchain. Давайте пока рассмотрим только простые платежные транзакции, где каждый участник имеет счет ровно на одном шарде. Если вы хотите перевести деньги с 2Наш анализ их подхода можно найти здесь: https://medium.com/nearprotocol/. 8f9efae0ce3bодин аккаунт на другой в пределах одного шарда, транзакция может быть обработана полностью validator в этом осколке. Однако если Алиса, находящаяся на шарде

1 хочет отправить деньги Бобу, который находится на шарде #2, ни validators

на шарде №1 (они не смогут пополнить счет Боба), ни validator на шард №2 (списать со счета Алисы они не смогут) может обработать весь транзакция. Существует два семейства подходов к межсегментным транзакциям: • Синхронный: всякий раз, когда необходимо выполнить транзакцию между сегментами, блоки в нескольких осколках, которые содержат переход состояния, связанный с Все транзакции производятся одновременно, и validator нескольких шардов совместно выполняют такие транзакции.3 • Асинхронный: транзакция между сегментами, которая затрагивает несколько сегментов. выполняется в этих сегментах асинхронно, при этом сегмент «Кредит» выполняется свою половину, как только у него будет достаточно доказательств того, что «Дебетовый» осколок выполнил свою часть. Этот подход имеет тенденцию быть более распространенным из-за его простота и удобство координации. Сегодня эта система предлагается в Cosmos, Ethereum Serenity, Near, Kadena и других. Проблема с этим подход заключается в том, что если блоки создаются независимо, существует ненулевая вероятность того, что один из нескольких блоков окажется осиротевшим, что делает сделка применена лишь частично. Рассмотрим рисунок 2, на котором изображены два шарды, оба из которых столкнулись с форком, и транзакция между шардами что было записано в блоках А и Х’ соответственно. Если цепи A-B и V’-X’-Y’-Z’ становятся каноническими в соответствующих осколках, сделка полностью завершена. Если A’-B’-C’-D’ и V-X станут каноническими, тогда транзакция полностью прекращается, что приемлемо. Но если для Например, A-B и V-X становятся каноническими, затем одна часть транзакции завершается, а другая отменяется, что приводит к сбою атомарности. Мы во второй части будет рассмотрено, как эта проблема решается в предлагаемых протоколах, при освещении изменений в правилах выбора форка и консенсусе. алгоритмы, предложенные для сегментированных протоколов. Обратите внимание, что связь между цепочками полезна за пределами сегментированных blockchains. тоже. Взаимодействие между цепочками — сложная проблема, которую решают многие проекты. пытаются решить. В сегментированных blockchain проблема несколько проще, поскольку структура блоков и консенсус одинаковы во всех шардах, и есть цепочка маяков, которую можно использовать для координации. Однако в сегментированном blockchain все шардчейны одинаковы, тогда как в глобальной экосистеме blockchains есть множество разных blockchain с разными целевыми вариантами использования, децентрализацией и гарантии конфиденциальности. Построение системы, в которой набор цепей имеет разные свойства, но использовать достаточно похожий консенсус и структуру блоков, а также иметь общую цепочку маяков, что может создать экосистему гетерогенных blockchain, которые имеют 3The большинство подробный предложение известный чтобы тот авторы из это документ есть Объединить Блоки, описал здесь: https://ethresear.ch/t/ слияние блоков и синхронное выполнение между состояниями сегментов / 1240Рисунок 2: Асинхронные транзакции между сегментами рабочая подсистема взаимодействия. Такая система вряд ли будет поддерживать ротацию validator, поэтому необходимо принять некоторые дополнительные меры для обеспечения безопасности. оба Cosmos и PolkaDot являются такими системами4. 1,5 Вредоносное поведение В этом разделе мы рассмотрим, какое состязательное поведение может привести к вредоносным validators. упражнения, если им удастся повредить осколок. Мы рассмотрим классические подходы чтобы избежать повреждения осколков в разделе 2.1. 1.5.1 Вредоносные форки Набор вредоносных validator может попытаться создать форк. Обратите внимание, что это не так имеет значение, является ли основной консенсус BFT или нет, искажая достаточное число из validators всегда позволит создать вилку. Значительно более вероятно, что будет повреждено более 50% одного шарда, чем более 50% всей сети (мы будем углубимся в эти вероятности в разделе 2.1). Как обсуждалось в разделе 1.4, Транзакции между сегментами включают определенные изменения состояния в нескольких сегментах, и соответствующие блоки в таких шардах, которые применяют такие изменения состояния, должны либо все будут финализированы (т.е. появятся в выбранных цепочках в соответствующих им местах). шарды), либо все станут сиротами (т.е. не появятся в выбранных цепочках на соответствующих шардах). Поскольку обычно вероятность повреждения осколков 4Обратитесь к этой статье Заки Маниана из Cosmos: https://forum.cosmos.network/. t/polkadot-vs-cosmos/1397/2 и этот твит-шторм от первого автора этого документа: https://twitter.com/AlexSkidanov/status/1129511266660126720 для подробного сравнения из двух

не является незначительным, мы не можем предполагать, что форков не произойдет, даже если среди шардов validator был достигнут византийский консенсус или было много блоков. производится поверх блока с изменением состояния. Эта проблема имеет несколько решений, наиболее распространенным из которых является случайный перекрестное связывание последнего блока шардчейна с маяковой цепочкой. Вилка правило выбора в цепочках шардов затем изменяется, чтобы всегда отдавать предпочтение той цепочке, которая перекрестными ссылками и применять правило выбора форка, специфичное для сегмента, только для блоков, которые были опубликовано с момента последней перекрестной ссылки. 1.5.2 Утверждение недействительных блоков Набор validator может попытаться создать блок, который неправильно применяет функцию перехода состояния. Например, начиная с состояния, в котором Алиса имеет 10 token, а у Боба 0 token, блок может содержать транзакцию, которая отправляет 10 token от Алисы Бобу, но в конечном итоге оказывается в состоянии, в котором Алиса 0 tokens, а у Боба 1000 tokens, как показано на рисунке 3. Рисунок 3: Пример недопустимого блока В классическом нешардинговом blockchain такая атака невозможна, так как все участник сети проверяет все блоки, а блок с таким недопустимый переход состояния будет отклонен обоими другими производителями блоков, и участники сети, не создающие блоки. Даже если злонамеренный validator продолжают создавать блоки поверх такого недействительного блока быстрее, чем честные validators строят правильную цепочку, таким образом получая цепочку с невалидной если блок длиннее, это не имеет значения, поскольку каждый участник, использующий blockchain для любых целей проверяет все блоки и отбрасывает все блоки. построен поверх недействительного блока. На рисунке 4 показаны пять validator, три из которых вредоносные. Они создал недопустимый блок A’, а затем продолжил создавать новые блоки сверху этого. Два честных validators отбросили A’ как недействительный и начали строить сверхуРисунок 4: Попытка создать недопустимый блок в несегментированном blockchain. последнего известного им действующего блока, создавая форк. Поскольку их меньше validators в честном развилке, их цепочка короче. Однако в классическом несегментированном blockchain каждый участник, использующий blockchain для каких-либо целей, отвечает за проверку всех полученных блоков и пересчет состояния. Таким образом, любой человек, проявляющий интерес к blockchain, заметит, что A’ недействителен, и поэтому также немедленно отбрасываем B’, C’ и D’ как таковые, принимая цепочка A-B как текущая самая длинная действительная цепочка. Однако в сегментированном blockchain ни один участник не может проверить все транзакции на всех сегментах, поэтому у них должен быть какой-то способ подтвердить это ни при каких обстоятельствах. точка в истории любого фрагмента blockchain, ни один недопустимый блок не был включен. Обратите внимание, что в отличие от форков, перекрестная привязка к цепочке Beacon не является достаточным решением, поскольку цепочка Beacon не имеет возможности проверять блоки. Он может только подтвердить, что достаточное количество __PH_0006____ в этом сегменте подписал блок (и тем самым подтвердил его правильность). Мы обсудим решения этой проблемы в разделе 2.2 ниже.

Государственная достоверность и доступность данных

Основная идея сегментированных blockchain заключается в том, что большинство участников, работающих или использование сети не может проверить блоки во всех сегментах. Таким образом, всякий раз, когда любому участнику необходимо взаимодействовать с конкретным шардом, который он обычно не может загрузите и проверьте всю историю осколка. Однако аспект секционирования при шардинге открывает значительный потенциал. проблема: без скачивания и проверки всей истории конкретного шард участник не обязательно может быть уверен, что состояние, с которым 5Данный раздел, за исключением подраздела 2.5.3, ранее был опубликован по адресу https://near.ai/. осколок2. Если вы читали это раньше, перейдите к следующему разделу.

они взаимодействуют, является результатом некоторой допустимой последовательности блоков, и эта последовательность блоков действительно является канонической цепочкой в шарде. Проблема, которой нет существуют в несегментированном blockchain. Сначала мы представим простое решение этой проблемы, которое было предложено по множеству протоколов, а затем проанализировать, как это решение может сломаться и что были предприняты попытки решить эту проблему. 2.1 Ротация валидаторов Наивное решение проблемы валидности состояния показано на рисунке 5: скажем, мы предположим, что что вся система имеет порядка тысяч validator, из которых не более 20% являются вредоносными или потерпят неудачу по другим причинам (например, из-за невозможности онлайн для создания блока). Тогда, если мы выберем 200 validators, вероятность более 1 3 для практических целей можно принять равным нулю. Рисунок 5: Выборка validators 1 3 – важный порог. Существует семейство консенсусных протоколов, называемое BFT протоколы консенсуса, которые гарантируют, что до тех пор, пока меньше 1 3 из участники терпят неудачу либо из-за сбоя, либо из-за действий, нарушающих правила. протокол, консенсус будет достигнут. При этом предположении о честном validator проценте, если текущий набор validators в шарде предоставляют нам некоторый блок, предполагает наивное решение что блок действителен и что он построен на основе того, что считали validators каноническую цепочку для этого шарда, когда они начали проверять. validators изучил каноническую цепочку из предыдущего набора validators, которые тем же предположение, построенное на вершине блока, который был главой канонической цепочки до этого. По индукции вся цепочка действительна, и поскольку ни один набор validators в любой момент создаются вилки, наивное решение также уверено, что текущий Chain — единственная цепочка в шарде. См. рисунок 6 для визуализации.

Рисунок 6: blockchain, где каждый блок завершается консенсусом BFT. Это простое решение не сработает, если мы предположим, что validators могут быть повреждаются адаптивно, что не является необоснованным предположением6. Адаптивно повреждение одного шарда в системе с 1000 шардами обходится значительно дешевле. чем развращать всю систему. Таким образом, безопасность протокола снижается линейно с увеличением количества шардов. Чтобы быть уверенным в достоверности блок, мы должны знать, что в любой момент истории ни один шард в системе не большинство validator в сговоре; с адаптивными противниками у нас больше нет такая уверенность. Как мы обсуждали в разделе 1.5, вступившие в сговор validator могут осуществлять два основных вредоносных действия: создание разветвлений и создание недействительных блоков. Вредоносные форки могут быть устранены путем присоединения блоков к цепочке Beacon, которая обычно спроектирована так, чтобы обеспечить значительно более высокий уровень безопасности, чем цепочки осколков. Однако создание недействительных блоков является значительно более сложной задачей. сложная проблема, требующая решения. 2.2 Государственная действительность Рассмотрим рисунок 7, на котором шард №1 поврежден и злоумышленник создает недействительный блок B. Предположим, в этом блоке B было отчеканено 1000 token из тонких air за счет Алисы. Затем злоумышленник создает действительный блок C (в ощущение, что транзакции в C применяются правильно) поверх B, что запутывает недействительный блок B и инициирует межшардовую транзакцию с шардом №2, которая переводит эти 1000 __PH_0006__s на счет Боба. С этого момента неправильно созданные token находятся на полностью допустимом в остальном blockchain в осколке №2. Вот несколько простых способов решения этой проблемы: 6Читать это статья для детали на как адаптивный коррупция может быть нес выход: https://medium.com/nearprotocol/d859adb464c8. Для больше детали на адаптивный коррупция, читать https://github.com/ethereum/wiki/wiki/Sharding-FAQ# какие-модели-безопасности-мы-действуемРисунок 7: Межшардовая транзакция из цепочки с недействительным блоком 1. Для validator шарда №2 для проверки блока, из которого была выполнена транзакция. инициируется. Это не сработает даже в примере выше, так как блок C представляется вполне верным. 2. Для validator в шарде №2 для проверки большого количества блоков, предшествующих блоку, из которого инициируется транзакция. Естественно, для любое количество блоков N, проверенное принимающим шардом, вредоносный validators могут создавать N+1 действительных блоков поверх недействительного блока, который они произведено. Многообещающей идеей решения этой проблемы было бы объединение шардов в неориентированный граф, в котором каждый шард связан с несколькими другими шардами, и разрешать только межшардовые транзакции между соседними шардами (например, так Шардинг Влада Замфира по существу работает7, и аналогичная идея используется в методе Кадены. Цепная паутина [1]). Если необходима межшардовая транзакция между шардами, которые не соседи, такая транзакция маршрутизируется через несколько сегментов. В этом дизайне Ожидается, что validator в каждом сегменте будет проверять оба блока в их сегменте. а также все блоки во всех соседних шардах. Рассмотрим рисунок ниже с 10 шардами, каждый из которых имеет по четыре соседа, и никакие два шарда не требуют больше чем два прыжка для связи между сегментами, показанной на рисунке 8. Шард №2 проверяет не только свой собственный blockchain, но и blockchain все соседи, включая Осколок №1. Итак, если злоумышленник на Осколке №1 пытается создать недопустимый блок B, а затем построить блок C поверх него и инициировать межшардовую транзакцию, такая межшардовая транзакция не пройдет поскольку Шард №2 подтвердит всю историю Шарда №1, которая заставит его идентифицировать недействительный блок B. 7Подробнее о дизайне читайте здесь: https://medium.com/nearprotocol/37e538177ed9

Рисунок 8: Недействительная межсегментная транзакция в системе, похожей на цепную сеть, которая будет быть обнаруженным Хотя повреждение одного осколка больше не является жизнеспособной атакой, повреждение несколько осколков остаются проблемой. На рисунке 9 противник портит оба Шарда №1 и шард №2 успешно выполняют межсегментную транзакцию с шардом №3. со средствами из невалидного блока Б: Рисунок 9: Недействительная межсегментная транзакция в системе, похожей на цепную сеть, которая будет не быть обнаруженным Шард №3 проверяет все блоки в Шарде №2, но не в Шарде №1, и не имеет возможности обнаружить вредоносный блок. Есть два основных направления правильного решения государственной действительности: рыбаки

и криптографические доказательства вычислений. 2.3 Рыбак Идея первого подхода заключается в следующем: всякий раз, когда заголовок блока передается между цепочками для любых целей (например, сшивание с цепочке маяков или транзакции между шардами), существует период времени, в течение которого который любой честный validator может предоставить доказательство того, что блок недействителен. Там представляют собой различные конструкции, которые позволяют очень кратко доказать, что блоки недействителен, поэтому накладные расходы на связь для принимающих узлов намного меньше чем получение полного блока. При таком подходе до тех пор, пока в сети есть хотя бы один честный validator осколок, система безопасна. Рисунок 10: Рыбак Это доминирующий подход (помимо притворства, что проблемы не существует) среди предлагаемых сегодня протоколов. Однако этот подход имеет два основные недостатки: 1. Период проверки должен быть достаточно длительным для честного validator. распознать, что блок был создан, загрузить его, полностью проверить и подготовить вызов, если блок недействителен. Введение такого периода позволит значительно замедляют межсегментные транзакции. 2. Существование протокола вызова создает новый вектор атак. когда злонамеренные узлы спамят недействительными вызовами. Очевидное решение Чтобы решить эту проблему, нужно заставить претендентов внести некоторую сумму tokens, которая возвращаются, если вызов действителен. Это лишь частичное решение, так как оно злоумышленнику все равно может быть выгодно рассылать спам по системе (и сжигать депозиты) с недействительными проблемами, например, для предотвращения действительноговызов от честного validator прохождения. Эти атаки называемые «Атаки скорби». См. раздел 3.7.2, чтобы узнать, как обойти последний пункт. 2.4 Краткие неинтерактивные аргументы знаний Второе решение проблемы повреждения нескольких сегментов — использовать какие-то криптографические конструкции, позволяющие доказать, что определенное вычисление (например, как вычисление блока из набора транзакций) было проведено корректно. Такие конструкции существуют, напр. zk-SNARKs, zk-STARKs и некоторые другие, а некоторые сегодня активно используются в протоколах blockchain для частных платежей, в первую очередь ZCash. Основная проблема с такими примитивами заключается в том, что они известны своей медленностью вычислений. Например. Протокол Coda, использующий zk-SNARK специально для того, чтобы доказать, что все блоки в blockchain действительны, сказано в одном интервью, что для создания доказательства может потребоваться 30 секунд на одну транзакцию (сейчас это число, вероятно, меньше). Интересно, что доказательство не обязательно должно быть вычислено доверенной стороной, поскольку доказательство не только подтверждает достоверность вычислений, для которых оно построено, но и достоверность самого доказательства. Таким образом, вычисление таких доказательств можно разделить среди набора участников со значительно меньшей избыточностью, чем было бы необходимо выполнить некоторые ненадежные вычисления. Это также позволяет участникам которые вычисляют zk-SNARK для работы на специальном оборудовании без снижения децентрализация системы. Проблемы zk-SNARK, помимо производительности, заключаются в следующем: 1. Зависимость от менее исследованных и менее проверенных временем криптографических примитивов; 2. «Токсичные отходы» — zk-SNARK зависят от доверенной установки, в которой группа людей выполняет некоторые вычисления, а затем отбрасывает промежуточные значения этого вычисления. Если все участники процедуры вступили в сговор и сохраняйте промежуточные значения, могут быть созданы фальшивые доказательства; 3. Дополнительная сложность, вносимая в конструкцию системы; 4. zk-SNARK работают только для подмножества возможных вычислений, поэтому протокол с полным по Тьюрингу языком smart contract невозможно было бы использовать SNARK для подтверждения достоверности цепочки. 2,5 Доступность данных Вторая проблема, которую мы затронем, — доступность данных. Обычно узлы эксплуатирующие конкретный blockchain, разделены на две группы: полные узлы, те, которые загружают каждый полный блок и проверяют каждую транзакцию, и Light Узлы, которые загружают только заголовки блоков и используют доказательства Меркла для частей. состояния и транзакций, в которых они заинтересованы, как показано на рисунке 11.

Рисунок 11: Дерево Меркла Теперь, если большинство полных узлов вступают в сговор, они могут создать блок, действительный или недействителен и отправляет его hash на легкие узлы, но никогда не раскрывает полное содержимое блока. Есть разные способы, которыми они могут извлечь из этого выгоду. Например, рассмотрим рисунок 12: Рисунок 12: Проблема с доступностью данных Есть три блока: предыдущий, A, создан честными validators; текущий B имеет в сговоре validators; и следующий, C, также будет произведен честными validators (blockchain изображен в правом нижнем углу). Вы торговец. validator текущего блока (B) получил блок A из предыдущих validators вычислил блок, в котором вы получаете деньги,и отправил вам заголовок этого блока с доказательством Меркла о состоянии, в котором у вас есть деньги (или подтверждение Merkle о действительной транзакции, которая отправляет деньги тебе). Уверенные, что транзакция завершена, вы предоставляете услугу. Однако validator никогда не передают полное содержимое блока B кто угодно. Таким образом, честные validator блока C не могут получить блок и вынуждены либо останавливать систему, либо строить на вершине А, лишая вас как торговец деньгами. Когда мы применяем тот же сценарий к сегментированию, определения полного и Легкий узел обычно применяется к каждому сегменту: validators в каждом сегменте загружается каждые блокировать в этом сегменте и проверять каждую транзакцию в этом сегменте, но другие узлы в системе, включая те, которые сохраняют состояние цепочек осколков моментальных снимков в цепочка маяков, загружайте только заголовки. Таким образом, validator в осколке фактически полные узлы для этого шарда, в то время как другие участники системы включая маяковую цепь, работают как легкие узлы. Чтобы подход рыбака, который мы обсуждали выше, работал, честные validators необходимо иметь возможность загружать блоки, связанные с цепочкой маяков. Если злонамеренные validators связали заголовок недопустимого блока (или использовали его для инициировать транзакцию между шардами), но никогда не распределял блок, честный validator не имеют возможности придумать испытание. Мы рассмотрим три подхода к решению этой проблемы, которые дополняют друг друга. 2.5.1 Доказательства содержания под стражей Самая неотложная проблема, которую необходимо решить, — доступен ли блок один раз. оно опубликовано. Одна из предложенных идей заключается в том, чтобы иметь так называемых нотариусов, которые чередуются. между шардами чаще, чем validators, единственная задача которых — загрузить заблокировать и подтвердить, что они смогли его скачать. Они могут быть ротируются чаще, потому что им не нужно загружать все состояние осколка, в отличие от validator, которых нельзя часто менять, поскольку они должен загружать состояние шардов каждый раз, когда они вращаются, как показано на рисунке 13. Проблема с этим наивным подходом в том, что позже невозможно доказать смог или не смог нотариус загрузить блок, поэтому нотариус могут всегда подтверждать, что они смогли загрузить блок без даже пытаясь его вернуть. Одним из решений этой проблемы является предоставление нотариусам некоторые доказательства или поставить некоторое количество tokens, подтверждающих, что блок был скачал. Одно из таких решений обсуждается здесь: https://ethresear.ch/t/. 1-битные депозитарные облигации, благоприятные для агрегации/2236. 2.5.2 Коды стирания Когда конкретный легкий узел получает hash блока, чтобы увеличить будучи уверенным в том, что блок доступен, он может попытаться загрузить несколько случайных кусочки блока. Это не полное решение, так как разве что легкие узлы коллективно загрузить весь блок, который могут выбрать производители вредоносных блоков

Рисунок 13: Валидаторам необходимо загрузить состояние, и поэтому их нельзя менять. часто удерживать части блока, которые не были загружены каким-либо легким узлом, тем самым делая блок недоступным. Одним из решений является использование конструкции под названием «Коды стирания», позволяющей восстановить весь блок, даже если доступна только некоторая часть блока, как показано на рисунке 14. Рисунок 14: Merkle tree построен на основе данных стирающего кодирования И Polkadot, и Ethereum Serenity используют эту идею, предоставить легким узлам возможность быть достаточно уверенными в доступности блоков. Подход Ethereum Serenity подробно описан в [2].2.5.3 Подход Polkadot к доступности данных В Polkadot, как и в большинстве сегментированных решений, каждый сегмент (называемый парачейном) передает свои блоки в цепочку маяков (называемую цепочкой реле). Скажем, есть 2f + 1. validators в цепи реле. Производители блоков парачейна, называемые средства сортировки, как только блок парачейна создан, вычисляют версию блока со стирающим кодом, состоящую из 2f +1 частей, так что любых f частей достаточно. реконструировать блок. Затем они раздают по одной части каждому validator на релейная цепь. Определенная цепочка ретрансляции validator будет только подписываться на цепочку ретрансляции. блокировать, если у них есть своя часть для каждого блока парачейна, снимок которого сделан в такой блок релейной цепи. Таким образом, если блок релейной цепи имеет сигнатуры от 2f + 1 validators, и до тех пор, пока не более f из них нарушили протокол, каждый Блок парачейна можно реконструировать, извлекая части из validators которые следуют протоколу. См. рисунок 15. Рисунок 15: Доступность данных Polkadot 2.5.4 Долгосрочная доступность данных Заметим, что все рассмотренные выше подходы свидетельствуют лишь о том, что блок вообще был опубликован и доступен сейчас. Блоки могут позже стать недоступными. по разным причинам: узлы отключаются от сети, узлы намеренно стирают историю данные и другие. Стоит упомянуть технический документ, посвященный этой проблеме, — Polyshard [3], который использует коды стирания, чтобы сделать блоки доступными для всех осколков, даже если их несколько. осколки полностью теряют свои данные. К сожалению, их специфический подход требует все шарды для скачивания блоков со всех остальных шардов, что непомерно дорого. Долгосрочная доступность не является столь острой проблемой: поскольку ни один участник Ожидается, что система будет способна проверять все цепочки во всех

сегментов, безопасность сегментированного протокола должна быть спроектирована таким образом, способ обеспечить безопасность системы, даже если некоторые старые блоки в некоторых шардах станут совершенно недоступен.

Nightshade

3.1 От цепочек осколков к чанкам осколков Модель шардинга с цепочками шардов и цепочкой маяков очень мощная, но имеет определенные сложности. В частности, необходимо выполнить правило выбора вилки. в каждой цепочке отдельно правило выбора форка в шардчейнах и маяке цепочка должна быть построена по-другому и протестирована отдельно. В Nightshade мы моделируем систему как единый blockchain, в котором каждый блок логически содержит все транзакции для всех шардов и изменяет целое состояние всех осколков. Однако физически ни один участник не загружает полное состояние или полный логический блок. Вместо этого каждый участник сети только поддерживает состояние, соответствующее шардам, для которых они проверяют транзакции, а список всех транзакций в блоке разбивается на физические куски, по одному куску на осколок. В идеальных условиях каждый блок содержит ровно один чанк на каждый шард. блок, что примерно соответствует модели с шардчейнами, в которых Цепочки осколков производят блоки с той же скоростью, что и цепочка маяков. Однако, из-за задержек в сети некоторые фрагменты могут отсутствовать, поэтому на практике каждый блок содержит один или ноль фрагментов на каждый сегмент. Подробную информацию о том, как производятся блоки. Рисунок 16: Модель с цепочками шардов слева и с одной цепочкой, имеющей блоки разделены на куски справа

3.2 Консенсус Сегодня в blockchains преобладают два подхода к консенсусу: самая длинная (или самая тяжелая) цепочка, в которой цепочка с наибольшим количеством работы или доли используемый для его построения, считается каноническим, а BFT, в котором для каждого блока несколько набор validator достигает консенсуса BFT. В предложенных недавно протоколах последний подход является более доминирующим. поскольку он обеспечивает немедленную завершенность, в то время как в самой длинной цепочке требуется больше блоков. будет построен поверх блока, чтобы обеспечить завершенность. Часто для значимого безопасность время, необходимое для построения достаточного количества блоков, берет на себя порядок часов. Использование консенсуса BFT для каждого блока также имеет недостатки, такие как: 1. BFT консенсус предполагает значительный объем общения. Пока последние достижения позволяют достичь консенсуса за линейное время по количеству участников (см., например, [4]), все равно заметные накладные расходы на блок; 2. Невозможно участие всех участников сети в BFT. консенсус для каждого блока, поэтому обычно только случайно выбранная подгруппа участников достигает консенсуса. В принципе, случайно выбранный набор может быть адаптивно повреждается, и теоретически может быть создан форк. Система либо необходимо смоделировать, чтобы быть готовым к такому событию, и, следовательно, по-прежнему иметь правило выбора вилки помимо консенсуса BFT или быть спроектировано так, чтобы закрывать вниз в таком случае. Стоит отметить, что некоторые конструкции, такие как Algorand [5], значительно снижают вероятность адаптивного повреждения. 3. Самое главное, система глохнет, если 1 3 или более из всех участников оффлайн. Таким образом, любой временный сбой в сети или ее раскол могут полностью остановить работу системы. В идеале система должна иметь возможность продолжать работать до тех пор, пока хотя бы половина участников онлайн (самый тяжелый протоколы на основе цепочки продолжают работать, даже если в сети менее половины участников, но желательность этого свойства более спорна внутри сообщества). Гибридная модель, в которой используется консенсус, является своего рода самым тяжелым цепочка, но некоторые блоки периодически дорабатываются с помощью гаджета окончательности BFT, сохраняя преимущества обеих моделей. Такие BFT гаджеты завершения Casper FFG [6] используется в Ethereum 2.0 8, Casper CBC (см. https://vitalik. ca/general/2018/12/05/cbc_casper.html) и ДЕДУШКА (см. https:// medium.com/polkadot-network/d08a24a021b5), используемый в Polkadot. Nightshade использует консенсус самой тяжелой цепи. В частности, когда блок производитель производит блок (см. раздел 3.3), он может собирать подписи от другие производители блоков и validator, подтверждающие предыдущий блок. См. раздел 3.8, где подробно описано, как агрегируется такое большое количество подписей. Вес 8. Также посмотрите сеанс с Джастином Дрейком, где представлен подробный обзор Casper. FFG и то, как он интегрирован с консенсусом по самой тяжелой цепи GHOST, здесь: https://www. youtube.com/watch?v=S262StTwkmoблока является тогда совокупной долей всех подписавших, чьи подписи включен в блок. Вес цепочки — это сумма весов блоков. Помимо консенсуса по самой тяжелой цепочке, мы используем гаджет окончательности, который использует аттестации для завершения блоков. Чтобы уменьшить сложность системы, мы используем гаджет окончательности, который никак не влияет на правило выбора вилки, и вместо этого только вводит дополнительные условия разрезания, например, когда блок завершено с помощью гаджета окончательности, форк невозможен, если не будет очень большого процента общая ставка сокращается. Casper CBC — такой гаджет окончательности, и мы в настоящее время модель с учетом Casper CBC. Мы также работаем над отдельным протоколом BFT под названием TxFlow. Во время при написании этого документа неясно, будет ли использоваться TxFlow вместо Casper ЦБК. Однако отметим, что выбор окончательного устройства во многом ортогонален остальной части конструкции. 3.3 Производство блоков В Nightshade есть две роли: производители блоков и validators. В любом точка, в которой система содержит w производителей блоков, w = 100 в наших моделях и wv validators, в нашей модели v = 100, wv = 10 000. Система Proof-of-Stake, это означает, что и производители блоков, и validator имеют некоторое количество внутренних валюта (именуемая «tokens») заблокирована на период времени, намного превышающий время, которое они тратят на выполнение своих обязанностей по построению и проверке цепочки. Как и во всех системах Proof of Stake, не все производители блоков и не все wv validator являются разными объектами, поскольку это невозможно обеспечить. Каждый однако производители блоков w и wv validator имеют отдельные ставка. Система содержит n шардов, в нашей модели n = 1000. Как упоминалось в раздел 3.1, в Nightshade нет цепочек сегментов, вместо этого все производители блоков и validator создают единый blockchain, который мы называем основная цепь. Состояние основной цепи разбито на n шардов, и каждый блок продюсер и validator в любой момент загрузили локально только часть состояние, которое соответствует некоторому подмножеству шардов, и только процесс и проверять транзакции, которые влияют на эти части состояния. Чтобы стать производителем блоков, участник сети блокирует какие-то крупные сумма tokens (ставка). Обслуживание сети осуществляется в эпохи, где эпоха – это период времени порядка дней. Участники с самыми большими ставками в начале определенной эпохи являются блоком продюсеры той эпохи. Каждый производитель блоков назначается шардам SW (скажем, sw = 40, что означает, что sww/n = 4 производителя блоков на шард). Блок продюсер загружает состояние шарда, которому он назначен, до начала эпохи запускается и на протяжении всей эпохи собирает транзакции, влияющие на этот шард, и применяет их к государству. Для каждого блока b в основной цепочке и для каждого шарда s существует один из назначил производителей блоков s, который отвечает за производство части b, связанной с к осколку. Часть b, связанная с шардом s, называется чанком и содержит список транзакций для шарда, которые будут включены в b, а также merkleкорень результирующего состояния. b в конечном итоге будет содержать только очень маленький заголовок чанк, а именно корень Меркла всех примененных транзакций (см. раздел 3.7.1 для получения точных деталей) и корень Меркле конечного состояния. В оставшейся части документа мы часто ссылаемся на производителя блоков. который отвечает за создание чанка в определенное время для определенного шарда в качестве производителя чанка. Производитель чанка всегда является одним из производителей блоков. Производители блоков и производители фрагментов вращают каждый блок в соответствии с по фиксированному графику. Производители блоков имеют заказ и неоднократно производят блоки в таком порядке. Например. если имеется 100 производителей блоков, первый блок производители отвечают за производство блоков 1, 101, 201 и т. д., второй — ответственный за производство 2, 102, 202 и т. д.). Поскольку производство кусков, в отличие от производства блоков, требует поддержания состояние, и для каждого шарда только производители блоков sww/n поддерживают состояние на каждый шард, соответственно, только те производители блоков sww/n вращаются для создания куски. Например. с константами, указанными выше, с четырьмя производителями блоков, назначенными каждый осколок, каждый производитель блоков будет создавать чанки каждые четыре блока. 3.4 Обеспечение доступности данных Чтобы обеспечить доступность данных, мы используем подход, аналогичный подходу Polkadot. описано в разделе 2.5.3. Как только производитель блоков создает чанк, он создает его версия со стирающим кодом с оптимальным (w, ⌊w/6 + 1⌋) блочным кодом кусок. Затем они отправляют один фрагмент фрагмента стирающего кода (мы называем такие фрагменты части фрагмента или только части) каждому производителю блока. Мы вычисляем дерево Меркла, которое содержит все части в виде листьев и заголовок каждого чанка содержит корень Меркла такого дерева. Детали отправляются на validator через сообщения onepart. Каждое такое сообщение содержит заголовок чанка, порядковый номер части и содержимое части. сообщение также содержит подпись производителя блока, создавшего чанк и путь Меркла, чтобы доказать, что часть соответствует заголовку и производится соответствующим производителем блоков. Как только производитель блоков получает блок основной цепи, он сначала проверяет, иметь одночастные сообщения для каждого фрагмента, включенного в блок. Если нет, то блок не обрабатывается до тех пор, пока не будут получены недостающие одночастные сообщения. Как только все одночастные сообщения получены, производитель блока извлекает оставшиеся части от одноранговых узлов и реконструирует фрагменты, для которых они хранятся государство. Производитель блока не обрабатывает блок основной цепи, если хотя бы один раз чанк, включенный в блок, у них нет соответствующего одночастного сообщения, или если хотя бы для одного шарда, для которого они поддерживают состояние, они не могут реконструировать весь кусок. Для того, чтобы конкретный чанк был доступен, достаточно, чтобы ⌊w/6⌋+1 блока продюсеры имеют свои роли и обслуживают их. Таким образом, до тех пор, пока количество злоумышленники не превышают ⌊w/3⌋нет цепочки, имеющей более половины блока производители, создающие его, могут иметь недоступные фрагменты.Рисунок 17: Каждый блок содержит один или ноль фрагментов на каждый сегмент, и каждый блок имеет стирающий код. Каждая часть фрагмента стирающего кода отправляется назначенному заблокировать производителя через специальное одночастное сообщение 3.4.1 Работа с ленивыми производителями блоков Если у производителя блока есть блок, для которого отсутствует одночастное сообщение, он может решить подписаться на него, потому что, если блок окажется в цепочке, он максимизирует вознаграждение для производителя блока. Риска для блока нет. производителя, так как впоследствии невозможно доказать, что у производителя блока не было одночастное сообщение. Чтобы решить эту проблему, мы заставляем каждого производителя чанка при создании чанка выберите цвет (красный или синий) для каждой части будущего закодированного фрагмента и сохраните битовая маска назначенного цвета в фрагменте перед его кодированием. Каждая часть сообщение затем содержит цвет, назначенный детали, и этот цвет используется, когда вычисление корня Меркле закодированных частей. Если производитель чанка отклоняется из протокола это легко доказывается, так как либо корень Меркле не будет соответствуют одночастным сообщениям или цветам одночастных сообщений, которые соответствующие корню Меркла, не будут соответствовать маске в чанк. Когда производитель блока подписывает блок, он включает битовую маску всех красные части они получили за чанки, включенные в блок. Публикация неправильная битовая маска — это поведение, допускающее косую черту. Если производитель блока не получил одночастное сообщение, у них нет возможности узнать цвет сообщения, и таким образом, они имеют 50% шанс быть порезанными, если попытаются вслепую подписать документ. блок. 3,5 Заявление о переходе состояния Производители чанка только выбирают, какие транзакции включать в чанк, но не применяйте переход состояния при создании фрагмента. Соответственно,

заголовок чанка содержит корень Меркла Меркелизованного состояния, как было раньше применяются транзакции в чане. Транзакции применяются только тогда, когда полный блок, включающий фрагмент, обрабатывается. Участник обрабатывает блок только в том случае, если 1. Предыдущий блок получен и обработан; 2. Для каждого фрагмента участник не поддерживает состояние, поскольку у него есть видел одночастное сообщение; 3. Для каждого фрагмента участник сохраняет состояние, поскольку у него есть полный кусок. После обработки блока для каждого шарда, по которому участник поддерживает состояние, они применяют транзакции и вычисляют новое состояние на момент применения транзакций, после чего они готовы производить чанки для следующего блока, если они назначены какому-либо шарду, поскольку у них есть Меркельский корень нового меркелизованного государства. 3.6 Межшардовые транзакции и квитанции Если транзакция должна затронуть более одного шарда, ее необходимо выполнить последовательно. выполняется в каждом шарде отдельно. Полная транзакция отправляется в первый шард затронуты, и как только транзакция будет включена в чанк такого шарда, и применяется после того, как чанк включен в блок, он генерирует так называемую квитанцию транзакция, которая направляется на следующий сегмент, в котором транзакция должна быть быть казнён. Если требуется больше шагов, выполнение транзакции поступления генерирует новую транзакцию получения и так далее. 3.6.1 Срок действия транзакции квитанции Желательно, чтобы транзакция получения применялась в блоке, который следует сразу за блоком, в котором она была сгенерирована. Операция прихода осуществляется только генерируется после того, как предыдущий блок был получен и применен производителями блоков которые поддерживают исходный шард, и должны быть известны к моменту создания чанк для следующего блока создается производителями блоков пункта назначения осколок. Таким образом, квитанция должна быть передана от исходного шарда к целевой осколок за короткий промежуток времени между этими двумя событиями. Пусть A — последний произведенный блок, содержащий транзакцию t, генерирующую квитанцию ​​r. Пусть B будет следующим созданным блоком (т.е. блоком, в котором A является его предыдущий блок), который мы хотим содержать r. Пусть t будет в шарде a, а r будет в осколок б. Срок действия квитанции, также изображенной на рисунке 18, следующий: Изготовление и хранение чеков. Цена за конверсию производителя чанка для шарда a получает блок A, применяет транзакцию t и генерирует квитанцию r. цена за конверсию затем сохраняет все такие полученные квитанции в своем внутреннем постоянном хранилище, проиндексированном по идентификатору исходного шарда.Раздача квитанций. Как только cpa будет готов создать чанк для шард a для блока B, они извлекают все квитанции, сгенерированные применением транзакций из блока A для шарда a, и включают их в чанк для фрагмента a в блоке B. Как только такой фрагмент сгенерирован, cpa создает его код стирания version и все соответствующие одночастные сообщения. cpa знает, какие производители блоков поддерживают полное состояние тех или иных шардов. Для конкретного производителя блоков bp cpa включает поступления, возникшие в результате применения транзакций в блоке А. для шарда a, в котором есть любой из шардов, которые bp считает местом назначения в одночастном сообщении, когда раздавали чанк для шарда a в блоке B (см. рисунок 17, на котором показаны квитанции, включенные в одночастное сообщение). Получение квитанций. Помните, что участники (как производители блоков, так и validators) не обрабатывают блоки, пока не получат одночастные сообщения. для каждого фрагмента, включенного в блок. Таким образом, к тому моменту, когда какой-либо конкретный участник применит блок B, у него будут все одночастные сообщения, соответствующие куски в B, и, таким образом, у них есть все входящие квитанции, содержащие фрагменты участник сохраняет состояние в качестве пункта назначения. При применении переход состояния для конкретного шарда, участник применяет обе расписки которые они собрали для шарда в onepart сообщениях, а также все транзакции, включенные в сам чанк. Рисунок 18: Срок действия транзакции получения 3.6.2 Обработка слишком большого количества квитанций Возможно, что количество квитанций, нацеленных на конкретный шард в конкретный блок слишком велик для обработки. Например, рассмотрим рисунок 19, каждая транзакция в каждом сегменте генерирует квитанцию, предназначенную для сегмента 1. К следующему блоку количество квитанций, которые должен обработать шард 1, равно сопоставимо с нагрузкой, которую все шарды вместе обрабатывали при обработке предыдущий блок.

Рисунок 19: Если все квитанции нацелены на один и тот же сегмент, этот сегмент может не иметь способность их обрабатывать Чтобы решить эту проблему, мы используем технику, аналогичную той, которая использовалась в QuarkChain 9. В частности, для каждого шарда последний блок B и последний шард внутри него блок, из которого были применены поступления, фиксируется. Когда новый осколок созданы, квитанция применяется в порядке очереди от оставшихся осколков в B, а затем в блоках, следующих за B, пока новый чанк не заполнится. В норме обстоятельствах при сбалансированной нагрузке это вообще приведет ко всем поступлениям применяется (и, таким образом, последний осколок последнего блока будет записан для каждый фрагмент), но в периоды, когда нагрузка не сбалансирована и определенный шард получает непропорционально много квитанций, эта техника позволяет им обрабатываться с соблюдением ограничений на количество включенных транзакций. Обратите внимание, что если такая несбалансированная нагрузка сохраняется в течение длительного времени, задержка от создание квитанции до тех пор, пока приложение не сможет продолжать расти бесконечно. Один способ решить эту проблему — отменить любую транзакцию, которая создает квитанцию, нацеленную на осколок, задержка обработки которого превышает некоторую константу (например, одну эпоху). Рассмотрим рисунок 20. К блоку B шард 4 не может обработать все поступления, поэтому он обрабатывает только получение квитанций до сегмента 3 в блоке A, и записывает это. В блок C включены поступления до 5-го шарда в блоке B, и затем к блоку D шард догоняет его, обрабатывая все оставшиеся поступления в блок Б и все поступления из блока С. 3,7 Проверка кусков Чанк, созданный для конкретного шарда (или блок шарда, созданный для конкретной цепочки шардов в модели с цепочками шардов), может быть проверен только 9См. эпизод с доской с QuarkChain здесь: https://www.youtube.com/watch?. v=opEtG6NM4x4, в котором, среди прочего, обсуждается подход к межшардовым транзакциям. вещиРисунок 20: Задержка обработки чеков участники, поддерживающие государство. Это могут быть производители блоков, validators, или просто внешние свидетели, которые загрузили состояние и проверили осколок в где они хранят активы. В этом документе мы предполагаем, что большинство участников не могут хранить состояние для значительной части осколков. Однако стоит упомянуть, что существуют сегментированные blockchain, разработанные с учетом предположения, что большинство участников имеют возможность хранить состояние и проверять большую часть осколки, такие как QuarkChain. Поскольку только часть участников имеет состояние для проверки шарда куски, можно адаптивно испортить только тех участников, у которых есть состояние и применить недопустимый переход между состояниями. Было предложено несколько схем шардинга, в которых каждые несколько раз отбирались validators. дней, а в течение суток любой блок в цепочке шардов, имеющий более 2/3 подписей validators, присвоенных такому шарду, учитывается немедленно окончательный. При таком подходе адаптивному противнику достаточно испортить только 2n/3+1. validator в цепочке сегментов, чтобы применить недопустимый переход состояния, который, хотя это, вероятно, трудно осуществить, уровень безопасности не является достаточным для общественного blockchain. Как обсуждалось в разделе 2.3, общий подход заключается в том, чтобы предоставить определенное окно времени после создания блока для любого участника, у которого есть состояние (независимо от того, является ли он это производитель блока, validator или внешний наблюдатель), чтобы оспорить его достоверность. Таких участников называют Рыбаками. Чтобы рыбак мог оспорить недействительный блок, необходимо убедиться, что такой блок доступен для их. Доступность данных в Nightshade обсуждается в разделе 3.4. В Nightshade после создания блока фрагменты не проверялись кто угодно, кроме фактического производителя фрагментов. В частности, производитель блоков, который предположил, что блок, естественно, не имеет состояния большинства осколков, ине смог проверить фрагменты. Когда создается следующий блок, он содержит подтверждения (см. раздел 3.2) нескольких производителей блоков и validator, но поскольку большинство производителей блоков и validator не поддерживают состояние для большинства шардов блок всего с одним недействительным чанком соберет значительно больше половины аттестаций и продолжит находиться в самом тяжелом состоянии. цепь. Для решения этой проблемы мы разрешаем любому участнику, поддерживающему состояние осколок для отправки запроса в цепочке для любого недопустимого фрагмента, созданного в этом осколок. 3.7.1 Проблема государственной действительности Как только участник обнаруживает, что конкретный фрагмент недействителен, ему необходимо предоставить доказательство того, что этот фрагмент недействителен. Поскольку большинство участников сети не поддерживают состояние шарда, в котором находится недействительный чанк доказательство должно содержать достаточную информацию, чтобы подтвердить, что блок недействителен без наличия гос. Мы устанавливаем ограничение Ls на количество состояний (в байтах), которое может хранить одна транзакция. может кумулятивно читать или писать. Любая транзакция, которая касается более Ls состояние считается недействительным. Помните из раздела 3.5, что чанк в конкретном блоке B содержатся только транзакции, которые необходимо применить, но не новый корень государства. Корнем состояния, включенным в фрагмент блока B, является состояние root перед применением таких транзакций, но после применения транзакций из последний фрагмент того же шарда перед блоком B. Злоумышленник, который желает применить недопустимый переход состояния, будет включать неправильный корень состояния в блоке B, который не соответствует корню состояния, полученному в результате применения транзакции в предыдущем фрагменте. Мы расширяем информацию, которую производитель чанка включает в чанк. Вместо того, чтобы просто включать состояние после применения всех транзакций, вместо этого включает корень состояния после применения каждого непрерывного набора транзакций, которые коллективно читать и записывать Ls байтов состояния. Благодаря этой информации для рыбаку, чтобы создать проблему, что переход между состояниями применяется неправильно. достаточно найти первый такой недопустимый корень состояния и включить только Ls байтов состояния, на которые влияют транзакции между последним корнем состояния (который был действительный) и текущий корень состояния с доказательствами Меркла. Тогда любой участник может проверить транзакции в сегменте и подтвердить, что чанк недействителен. Аналогично, если производитель чанка попытается включить транзакции, которые читают и записать более Ls байт состояния, для вызова достаточно включить первые Ls байтов, которых он касается с помощью доказательств Меркла, которых будет достаточно, чтобы применить транзакции и убедиться, что наступает момент, когда попытка производится чтение или запись содержимого за пределами Ls байт.

3.7.2 Рыбаки и быстрые транзакции между шардами Как обсуждалось в разделе 2.3, если мы предположим, что фрагменты шарда (или шард блоки в модели с цепочками осколков) могут быть недействительными и создавать проблемы период, это отрицательно влияет на завершенность и, следовательно, на межсегментную коммуникацию. В в частности, не может быть определен целевой сегмент любой межсегментной транзакции. исходный фрагмент или блок является окончательным до тех пор, пока период вызова не закончится (см. рисунок 21). Рисунок 21: Ожидание периода вызова перед применением квитанции Способ решения этой проблемы таким образом, чтобы транзакции между сегментами Instantenious означает, что осколок назначения не должен ждать периода вызова. после публикации транзакции исходного сегмента и примените транзакцию получения немедленно, но затем откатите целевой сегмент вместе с исходным шард, если позже исходный чанк или блок оказался недействительным (см. рис. 22). Это очень естественно относится к дизайну Nightshade, в котором осколок цепочки не являются независимыми, вместо этого все фрагменты шардов публикуются. вместе в одном блоке основной цепи. Если какой-либо фрагмент окажется недействительным, весь блок с этим чанком считается недействительным, а все блоки, построенные на самое верхнее. См. рисунок 23. Оба вышеупомянутых подхода обеспечивают атомарность, предполагая, что задача период достаточно длительный. Мы используем последний подход, поскольку обеспечение быстрых перекрестных транзакций в обычных обстоятельствах перевешивает неудобства целевой сегмент откатывается из-за недопустимого перехода состояния в одном из исходные осколки, что является крайне редким событием. 3.7.3 Скрытие validators Наличие проблем уже существенно снижает вероятность адаптивное повреждение, поскольку для завершения фрагмента с недопустимым постом перехода состоянияРисунок 22: Немедленное применение квитанций и откат пункта назначения цепочка, если в исходной цепочке был недопустимый блок Рисунок 23: Испытание рыбака в Nightshade период испытания, который необходим адаптивному противнику, чтобы развратить всех участников которые поддерживают состояние шарда, включая все validator. Оценить вероятность такого события чрезвычайно сложно, поскольку нет sharded blockchain существует достаточно долго, чтобы можно было предпринять попытку такой атаки. Мы утверждаем, что вероятность, хотя и чрезвычайно мала, все же достаточно велика. большой для системы, которая, как ожидается, будет выполнять многомиллионные транзакции и управлять финансовыми операциями по всему миру. Есть две основные причины такого убеждения: 1. Большинство validator цепей Proof-of-Stake и майнеров

Цепочки Proof-of-Work в первую очередь стимулируются финансовым потенциалом. Если адаптивный противник предлагает им больше денег, чем ожидаемая прибыль от честной работы, разумно ожидать, что многие validators примет предложение. 2. Многие организации профессионально проводят проверку цепочек Proof-of-Stake, и ожидается, что большой процент акций в любой цепочке будет от таких субъектов. Число таких объектов достаточно мало для адаптивного противника, чтобы узнать большинство из них лично и получить хорошее понимание своей склонности к развращению. Мы делаем еще один шаг вперед в снижении вероятности адаптивного повреждения, скрывая, какие validator назначены какому шарду. Идея в том, отдаленно похоже на то, как Algorand [5] скрывает validators. Очень важно отметить, что даже если validator скрыты, как в Algorand, или, как описано ниже, адаптивное повреждение теоретически все еще возможно. Пока адаптивный противник не знает участников, которые будут создавать или проверять блок или чанк, участники сами знают, что будут выполнять такую задачу и иметь криптографическое доказательство этого. Таким образом, противник может сообщать о своем намерении совершить коррупцию и платить любому участнику, который предоставит такое криптографическое доказательство. Однако отметим, что, поскольку противник не знать validator, которые назначены на шард, который они хотят повредить, они не имеют другого выбора, кроме как передать свое намерение испортить конкретный осколок все сообщество. В этот момент это экономически выгодно для любого честного участнику развернуть полный узел, который проверяет этот шард, поскольку существует высокая вероятность появления недействительного блока в этом осколке, что дает возможность создайте испытание и получите соответствующую награду. Чтобы не раскрывать validator, назначенные конкретному шарду, мы делаем следующее (см. рисунок 24): Использование VRF для получения задания. В начале каждой эпохи каждый validator использует VRF для получения битовой маски сегментов, которым назначен validator. Битовая маска каждого validator будет иметь биты Sw (определение см. в разделе 3.3). Sw). Затем validator извлекает состояние соответствующих фрагментов и в течение эпохи для каждого полученного блока проверяет соответствующие фрагменты к шардам, которым назначен validator. Подписывайтесь на блоки, а не на куски. Поскольку назначение сегментов скрыто, validator не может подписывать фрагменты. Вместо этого он всегда подписывает всю блокировать, таким образом не раскрывая, какие шарды он проверяет. В частности, когда validator получает блок и проверяет все фрагменты, он либо создает сообщение это свидетельствует о том, что все чанки во всех шардах, которым назначен validator, являются действительным (без указания каким-либо образом, что это за осколки), или сообщение, которое содержит доказательство недопустимого перехода состояния, если какой-либо фрагмент недействителен. См. раздел 3.8 содержит подробную информацию о том, как агрегируются такие сообщения, раздел 3.7.4 — подробности о том, как предотвратить использование validators в сообщениях от другие validator и раздел 3.7.5, где подробно описано, как вознаграждать и наказывать. validators, если действительно произойдет успешный вызов недопустимого перехода состояния.Рисунок 24: Сокрытие validator в Nightshade 3.7.4 Фиксация-Раскрытие Одна из распространенных проблем с validator заключается в том, что validator может пропустить загрузку состояния и фактическую проверку фрагментов и блоков, а вместо этого понаблюдайте за сетью, посмотрите, что отправляют другие validator, и повторите свои сообщения. validator, следующий такой стратегии, не дает никаких дополнительных безопасность сети, но получает вознаграждение. Обычное решение этой проблемы состоит в том, чтобы каждый validator предоставил доказательство. что они действительно проверили блок, например, предоставив уникальную трассировку применения перехода состояний, но такие доказательства значительно увеличивают стоимость проверки. Рисунок 25: Фиксация-раскрытие

Вместо этого мы сначала делаем validator фиксацией результата проверки (либо сообщение, подтверждающее достоверность фрагментов или доказательство недействительности перехода состояния), подождите определенный период и только потом покажите фактический результат проверки, как показано на рисунке 25. Период фиксации не пересекается с период раскрытия, и поэтому ленивый validator не может подражать честным validator. Более того, если нечестный validator передал сообщение, подтверждающее достоверность назначенных фрагментов, и по крайней мере один фрагмент был недействителен, как только он будет показано, что чанк недействителен, validator не может избежать косой черты, поскольку как мы покажем в разделе 3.7.5, единственный способ не порезаться в такой ситуации состоит в том, чтобы представить сообщение, содержащее доказательство недопустимого перехода состояния, которое соответствует коммиту. 3.7.5 Решение проблем Как обсуждалось выше, как только validator получает блок с недопустимым чанком, сначала они готовят доказательство недопустимого перехода состояний (см. раздел 3.7.1), затем возьмите на себя такое доказательство (см. 3.7.4) и через некоторое время раскройте проблему. После включения выявленного вызова в блок происходит следующее: 1. Все переходы состояний, произошедшие из блока, содержащего недействительный фрагмент до тех пор, пока не будет получен блок, в который включен обнаруженный вызов. аннулировано. Состояние перед блоком, включающим обнаруженную задачу считается таким же, как состояние до блока, который содержал недействительный фрагмент. 2. В течение определенного периода времени каждый validator должен раскрыть свою битовую маску. осколков, которые они проверяют. Поскольку битовая маска создается через VRF, если они были назначены шарду с недопустимым переходом состояния, они не могу не раскрыть этого. Любой validator, который не раскрывает битовую маску. предполагается, что он назначен сегменту. 3. Каждый validator, который по истечении этого периода оказывается назначенным сегменту, который действительно зафиксировал некоторый результат проверки для блока, содержащего неверный фрагмент, и это не выявило доказательства недопустимого перехода состояния это соответствует их коммиту. 4. Каждый validator получает новое назначение осколков, и назначается новая эпоха. начать через некоторое время, достаточное для того, чтобы все validators загрузили состояние, как показано на рисунке 26. Обратите внимание, что с того момента, как validator раскрывают назначенные им шарды до тех пор, пока не начнется новая эпоха, безопасность системы снижается, поскольку Назначение осколков раскрыто. Участникам сети необходимо его сохранить иметь в виду при использовании сети в течение такого периода. 3,8 Агрегация подписей Чтобы система с сотнями шардов работала безопасно, мы хотим иметь порядка 10 000 или более validators. Как обсуждалось в разделе 3.7, мы хотим, чтобы каждыйРисунок 26: Решение проблемы validator для публикации коммита к определенному сообщению и подписи в среднем один раз за блок. Даже если сообщения о фиксации были одинаковыми, объединение таких BLS-подпись и ее проверка были бы непомерно дорогими. Но естественно, сообщения фиксации и раскрытия не одинаковы для validator, и поэтому нам нужен какой-то способ агрегировать такие сообщения и подписи в способ, позволяющий провести быструю проверку позже. Конкретный подход, который мы используем, заключается в следующем: Валидаторы присоединяются к производителям блоков. Известны производители блоков за некоторое время до начала эпохи, так как им нужно некоторое время, чтобы загрузить состояние до начала эпохи, и в отличие от validators производители блоков не скрыто. Каждый производитель блоков имеет v validator слотов. Валидаторы отправляют оффчейн предложения производителям блоков, чтобы они были включены в качестве одного из их v validatorс. Если производитель блока желает включить validator, он отправляет транзакция, которая содержит первоначальный запрос вне цепочки от validator и подпись производителя блока, которая заставляет validator присоединиться к производителю блока. Обратите внимание, что validator, назначенные производителям блоков, не обязательно проверять те же фрагменты, для которых производитель блоков создает фрагменты. Если validator применяется для объединения нескольких производителей блоков, только транзакция из первый производитель блоков добьется успеха. Производители блоков собирают коммиты. Производитель блоков постоянно собирает сообщения о фиксации и раскрытии от validator. Как только накапливается определенное количество таких сообщений, производитель блока вычисляет коэффициент Меркла. дерево этих сообщений и отправляет каждому validator корень Меркла и merkle путь к их сообщению. validator проверяет путь и регистрируется. корень Меркеля. Затем производитель блока накапливает подпись BLS на корень Меркла из validators и публикует только корень Меркла и накопленная подпись. Производитель блока также подписывает действительность мультиподпись с использованием дешевой подписи ECDSA. Если мультиподпись не соответствует отправленному корню Меркла или битовой маске участвующих validator, это поведение, допускающее косую черту. При синхронизации цепочки участник может выбрать проверку всех подписей BLS из validator (что чрезвычайно дорого, поскольку включает в себя агрегирование открытых ключей validator) или толькоподписи ECDMA от производителей блоков и полагаются на тот факт, что Продюсер блока не подвергся сомнению и не был порезан. Использование внутрисетевых транзакций и доказательств Меркла для решения проблем. Это можно отметить, что нет смысла раскрывать сообщения от validators, если нет Обнаружен недопустимый переход состояния. Только те сообщения, которые содержат реальные доказательства недопустимого перехода состояния должны быть выявлены, и только для таких сообщений необходимо показать, что они соответствуют предыдущему коммиту. Сообщение должно раскрываться с двумя целями: 1. Фактически инициировать откат цепочки к моменту перед недопустимый переход состояния (см. раздел 3.7.5). 2. Чтобы доказать, что validator не пытался подтвердить действительность недействительный фрагмент. В любом случае нам необходимо решить две проблемы: 1. Фактический коммит не был включен в цепочку, только корень Меркла commit в совокупности с другими сообщениями. validator необходимо использовать путь Меркла, предоставленный производителем блока, и их первоначальная фиксация доказать, что они приняли вызов. 2. Возможно, что все validator, назначенные шарду с невалидным переход состояния назначается поврежденным производителям блоков, которые подвергают их цензуре. Чтобы обойти это, мы позволяем им отправлять свои откровения. как обычная транзакция в цепочке и в обход агрегации. Последнее допускается только для доказательств недопустимого перехода состояния, которые крайне редко и, следовательно, не должно приводить к спаму блоков. Последний вопрос, который необходимо решить, заключается в том, что производители блоков могут отказаться от участия в агрегировании сообщений или намеренно подвергать цензуре отдельные validator. Мы делаем это экономически невыгодным, делая блок вознаграждение производителя, пропорциональное количеству назначенных ему validators. Мы также обратите внимание, что поскольку производители блоков между эпохами во многом пересекаются (поскольку это всегда лучшие участники с самой высокой ставкой), validators могут в основном придерживаться работы с одними и теми же производителями блоков и тем самым снизить риск о том, что их назначили производителю блоков, который подвергал их цензуре в прошлом. 3,9 Цепочка снимков Поскольку блоки в основной цепочке производятся очень часто, загрузка полная история может очень быстро стать дорогой. Более того, поскольку каждый блок содержит BLS-подпись большого количества участников, просто агрегирование открытых ключей для проверки подписи может стать непомерно высоким к тому же дорого. Наконец, поскольку в обозримом будущем Ethereum 1.0, скорее всего, так и останется из наиболее часто используемых blockchain, имеющих смысловой способ передачи активов из

Требуется близко к Ethereum, и сегодня проверка подписей BLS для обеспечения Действие ближних блоков на стороне Ethereum невозможно. Каждый блок в основной цепочке Nightshade может опционально содержать блок Шнорра. мультиподпись в заголовке последнего блока, в котором был такой Шнорр мультиподпись. Мы называем такие блоки блоками моментальных снимков. Самый первый блок каждая эпоха должна быть блоком моментального снимка. Работая над такой мультиподписью, производители блоков также должны накопить подписи BLS validator. в последнем блоке моментальных снимков и агрегируем их так же, как описано в разделе раздел 3.8. Поскольку набор производителей блоков постоянен на протяжении всей эпохи, проверка достаточно только первых блоков снимков в каждой эпохе, предполагая, что ни в одном случае указывает на то, что большой процент производителей блоков и validators вступили в сговор и создали вилка. Первый блок эпохи должен содержать информацию, достаточную для вычисления производители блоков и validators для эпохи. Мы вызываем подцепь основной цепочки, которая содержит только снимок. блокирует цепочку снимков. Создание мультиподписи Шнорра — интерактивный процесс, но поскольку мы только нужно выполнять его нечасто, любой, даже самый неэффективный процесс будет достаточно. Мультиподписи Шнорра можно легко проверить на Ethereum, тем самым предоставляя важные примитивы для безопасного выполнения перекрестного blockchain общение. Для синхронизации с цепочкой Near достаточно скачать весь снимок блоков и подтвердите правильность подписей Шнорра (при необходимости также проверьте отдельные подписи BLS validator), а затем только синхронизируйте блоки основной цепочки из последнего блока моментального снимка.

Заключение

В этом документе мы обсудили подходы к созданию сегментированных blockchain и охватили две основные проблемы существующих подходов, а именно валидность состояния и доступность данных. Затем мы представили Nightshade, дизайн шардинга, который полномочия NEAR Протокола. Дизайн находится в стадии разработки, если у вас есть комментарии, вопросы или отзывы. в этом документе перейдите по адресу https://near.chat.