Chainlink: децентрализованная сеть Oracle

Аннотация

В этом техническом документе мы формулируем видение развития Chainlink за пределами его первоначальной концепции, изложенной в оригинальном техническом документе Chainlink. Мы предвидим все более расширяющаяся роль сетей oracle, в которой они дополняют и улучшают существующие и новые blockchain, обеспечивая быструю, надежную и универсальная связь с сохранением конфиденциальности и автономные вычисления для smart contractс. Основой нашего плана является то, что мы называем децентрализованными сетями Oracle, или Для краткости DONs. DON — это сеть, поддерживаемая комитетом Chainlink. узлы. Он поддерживает любую из неограниченного диапазона oracle функций, выбранных для размещение комитетом. Таким образом, DON действует как мощный уровень абстракции, предлагая интерфейсы для smart contracts с обширными оффчейн-ресурсами и высокоэффективными эффективные, но децентрализованные вычислительные ресурсы вне сети внутри самого DON. Используя DONs в качестве трамплина, Chainlink планирует сосредоточиться на достижениях в семи ключевые направления: • Гибридные smart contracts: предложение мощной общей структуры для расширения существующих возможностей smart contract путем безопасного создания цепочки. и автономные вычислительные ресурсы в то, что мы называем гибридными smart contract. • Абстрагирование сложности: предоставление разработчикам и пользователям простых функциональность устраняет необходимость знакомства со сложными базовыми протоколы и границы системы. • Масштабирование: обеспечение того, чтобы службы oracle обеспечивали требуемые задержки и пропускную способность. востребованы высокопроизводительными децентрализованными системами. • Конфиденциальность: создание систем нового поколения, объединяющих blockchains’ врожденная прозрачность с новой надежной защитой конфиденциальности для чувствительных данные. • Справедливость заказов для транзакций: поддержка последовательности транзакций разными способами. которые являются справедливыми для конечных пользователей и предотвращают опережающие и другие атаки со стороны боты и майнеры-эксплуататоры. • Минимизация доверия: создание высоконадежного уровня поддержки smart contracts и другие oracle-зависимые системы посредством децентрализации, сильной привязки к высокозащищенным blockchains, криптографическим технологии и криптоэкономические гарантии. • Криптоэкономическая безопасность, основанная на стимулах: тщательное проектирование и активное развертывание механизмов, которые гарантируют, что узлы в DONs имеют сильные экономические стимулы вести себя надежно и правильно, даже перед лицом хорошо обеспеченных ресурсами противников. Представляем предварительные и текущие инновации сообщества Chainlink. в каждой из этих областей, давая картину расширяющегося и все более мощные возможности, запланированные для сети Chainlink.

Введение

Блокчейн oracle сегодня часто рассматривается как децентрализованный сервис с одной целью: для пересылки данных из ресурсов вне сети на blockchains. Хотя это короткий шаг, от пересылки данных до их обработки, хранения или двунаправленной передачи. Это наблюдение оправдывает гораздо более широкое представление о функциональности oracles. И тоже выполнять растущие и все более многогранные требования к обслуживанию smart contracts технологии, основанные на сетях oracle. Короче говоря, oracle может и понадобится быть двунаправленным интерфейсом общего назначения с поддержкой вычислений между ончейн- и офчейн-системами. Роль оракулов в экосистеме blockchain заключается в улучшении производительность, функциональность и совместимость smart contract, чтобы они могли принести новые модели доверия и прозрачности во множество отраслей. Эта трансформация произойдет за счет более широкого использования гибридных smart contracts, которые объединяют Особые свойства blockchains с уникальными возможностями автономных систем, таких как oracle сетей и тем самым достичь гораздо большего охвата и мощности, чем ончейн-системы. в изоляции. В этом техническом документе мы формулируем видение того, что мы называем Chainlink 2.0, развитием Chainlink за пределами его первоначальной концепции, изложенной в исходном Chainlink техническом документе [98]. Мы прогнозируем возрастающую роль сетей oracle, в которых они дополняют и улучшают существующие и новые blockchain, обеспечивая быстрое, надежное и сохраняющее конфиденциальность универсальное соединение и вычисления для гибридных smart contractс. Мы считаем, что сети oracle даже превратятся в коммунальные услуги. для экспорта данных высокой степени целостности blockchain в системы за пределами blockchain экосистема. Сегодня узлы Chainlink, управляемые разнообразным набором объектов, объединяются в сети oracle для передачи данных на smart contract в так называемых отчетах. Мы можем просмотреть такие oracle узлов как комитет, аналогичный таковому в классическом консенсусе blockchain [72], но с целью поддержки существующих blockchain, а не предоставления автономной функциональности. С проверяемыми случайными функциями (VRF) и отчетами вне цепочки (OCR), Chainlink уже развивается в сторону универсальной структуры и инфраструктуры для предоставления вычислительных ресурсов, необходимых smart contract для расширенный функционал. Основой нашего плана для Chainlink 2.0 является то, что мы называем децентрализованным Oracle. Сети, или сокращенно DONs. Поскольку мы ввели термин «сеть oracle» в оригинальный Chainlink технический документ [98], oracle имеют еще более богатую функциональность и широта применения. В данной статье мы предлагаем новое определение этого термина, согласно нашему будущему видению экосистемы Chainlink. С этой точки зрения DON представляет собой сеть поддерживается комитетом из Chainlink узлов. Основанный на консенсусном протоколе, он поддерживает любую из неограниченного диапазона функций oracle, выбранных для развертывания комитет. Таким образом, DON действует как уровень абстракции blockchain, предоставляя интерфейсы. для отключения ресурсов как для smart contracts, так и для других систем. Он также обеспечивает доступ к высокоэффективным, но децентрализованным вычислительным ресурсам вне цепочки. В общем, DON поддерживает операции в основной цепочке. Его цель – обеспечить безопасное и гибкоеble гибридные smart contracts, которые сочетают в себе вычисления внутри и вне цепочки с подключение к внешним ресурсам. Подчеркнем, что даже при использовании комитетов в DONs, сам Chainlink остается по своей сути неразрешимым. DONs выступают в качестве основы несанкционированного доступа. структуру, в которой узлы могут объединяться для реализации пользовательских сетей oracle с свои собственные режимы включения узлов, которые могут быть разрешенными или неразрешенными. Взяв за основу DONs, мы планируем в Chainlink 2.0 сосредоточиться на достижениях в семи Ключевые области: гибридные smart contracts, абстрагирование сложности, масштабирование, конфиденциальность, справедливость порядка транзакций, минимизация доверия и основанная на стимулах (криптоэкономическая) безопасность. Во введении к этой статье мы представляем обзор децентрализованных систем. Oracle Networks в разделе 1.1, а затем наши семь ключевых областей инноваций в разделе 1.2. Мы описываем организацию остальной части этой статьи в разделе 1.3. 1.1 Децентрализованные сети Oracle Децентрализованные сети Oracle предназначены для улучшения и расширения возможностей из smart contracts в целевой blockchain или основной цепочке с помощью функций, которые не доступен изначально. Они делают это, предоставляя три основных ресурса, найденных в вычислительные системы: сети, хранение и вычисления. DON призван предложить эти ресурсы с высокими характеристиками конфиденциальности, целостности и доступности1, поскольку а также ответственность. DON формируются комитетами узлов oracle, которые сотрудничают для выполнения определенного работу или решите установить долгосрочные отношения, чтобы предоставлять постоянные услуги клиентам. DON разработаны независимо от blockchain. Они обещают служить мощный и гибкий инструмент для разработчиков приложений, позволяющий создавать автономную поддержку свои smart contract в любой поддерживаемой основной цепочке. Два типа функций реализуют возможности DON: исполняемые файлы и адаптеры. Исполняемые файлы — это программы, которые выполняются непрерывно и децентрализованно на компьютере DON. Хотя они не хранят активы основной цепи напрямую, у них есть важные преимущества, в том числе высокая производительность и способность выполнять конфиденциальные операции. расчет. Исполняемые файлы запускаются автономно на DON и работают детерминированно. операции. Они работают совместно с адаптерами, которые связывают DON с внешними ресурсами. и может вызываться исполняемыми файлами. Адаптеры, какими мы их представляем для DONs, представляют собой обобщение внешних адаптеров в Chainlink сегодня. Хотя существующие адаптеры обычно данные извлекаются только из источников данных, адаптеры могут работать в двунаправленном режиме; в DONs, они могут дополнительно использовать совместные вычисления узлов DON для достижения дополнительные функции, такие как шифрование отчетов для сохранения конфиденциальности исполняемый файл. Чтобы дать представление об основных операциях DON, на рис. 1 концептуально показано, как DON можно использовать для отправки отчетов на blockchain и, таким образом, реализовать традиционную существующую функциональность oracle. Однако DONs могут предоставлять множество дополнительных функций, помимо 1 «ЦРУ-триада» информационной безопасности [123, с. 26, §2.3.5].Существующие сети Chainlink. Например, в общей структуре рис. 1: исполняемый файл может записывать полученные данные о ценах активов на DON, используя эти данные для вычислить, например, скользящее среднее значение для своих отчетов. Рисунок 1. Концептуальный рисунок, показывающий в качестве примера, как децентрализованная сеть Oracle может реализовать базовую функциональность oracle, т. е. передавать данные вне цепочки в контракт. Ан исполняемый файл использует адаптеры для извлечения данных вне цепочки, на которых он вычисляет, отправляя выходные данные через другой адаптер к цели blockchain. (Адаптеры инициируются кодом в DON, представленный маленькими синими прямоугольниками; стрелки показывают направление потока данных для этого конкретный пример.) Исполняемый файл может дополнительно читать и записывать в локальный DON. хранилище для хранения состояния и/или связи с другими исполняемыми файлами. Гибкие сети, вычисления и хранение в DON, представленные здесь, открывают множество новых возможностей. приложения. Основным преимуществом DON является их способность запускать новые службы blockchain. DONс являются средством, с помощью которого существующие сети oracle могут быстро поддерживать сервисные приложения. сегодня для этого потребуется создание специально построенных сетей. Мы даем ряд примеры таких приложений в разделе 4. В разделе 3 мы предоставим более подробную информацию о DON, описывая их возможности в с точки зрения интерфейса, который они представляют разработчикам и пользователям. 1.2 Семь ключевых целей дизайна Здесь мы кратко рассмотрим семь ключевых направлений, перечисленных выше, для эволюции Chainlink, а именно:Гибридные smart contracts: Центральное место в нашем видении Chainlink занимает идея безопасного объединение ончейн и офчейн компонентов в smart contracts. Мы ссылаемся на контракты реализуя эту идею в виде гибридных smart contract или гибридных контрактов.2 Блокчейны играют и будут продолжать играть две критически важные роли в децентрализованном обслуживании. экосистемы: они оба являются локусами, где представлена собственность на криптовалюту. и надежные якоря для децентрализованных услуг. Поэтому смарт-контракты должны быть представлены или исполнены в цепочке, но их возможности в цепочке строго ограничены. Чисто Код ончейн-контракта медленный, дорогой и изолированный, неспособный извлечь выгоду из реального мира. данные и различные функциональные возможности, которые по своей сути недостижимы в цепочке, включая различные формы конфиденциальных вычислений, безопасную генерацию (псевдо)случайности против майнерских / validator манипуляций и т. д. Поэтому, чтобы smart contracts полностью реализовали свой потенциал, требуется smart contracts. быть спроектирован с двумя частями: частью цепочки (которую мы обычно обозначаем SC) и часть вне цепочки, исполняемый файл, работающий на DON (который мы обычно обозначаем как исполнительный). Цель состоит в том, чтобы достичь безопасного сочетания функциональных возможностей сети с помощью множество офчейн-сервисов, которые стремятся предоставить DONs. Вместе две части составить гибридный договор. Концептуально эту идею мы представляем на рис. 2. Уже сегодня Chainlink сервисы3, такие как каналы данных и VRF, позволяют сделать невозможное другим способом smart contract приложений, от DeFi до справедливо сгенерированных NFT и децентрализованного страхования, как первые шаги на пути к более общей структуре. В качестве услуг Chainlink расширяться и становиться более производительными в соответствии с нашим видением, изложенным в этом техническом документе, а также будет ли мощь систем smart contract во всех blockchain. Остальные шесть наших ключевых направлений в этом документе можно рассматривать как действие в сфере обслуживания. первого, всеобъемлющего гибридного контракта. Эти фокусы включают удаление видимых сложности из-за гибридных контрактов, создавая дополнительные офчейн-сервисы, которые позволяют создание все более эффективных гибридных контрактов и, в случае минимизации доверия, усиление свойств безопасности, достигаемых гибридными контрактами. Мы оставляем идею гибридных контрактов, подразумеваемых на протяжении большей части статьи, но любая комбинация Логику MAINCHAIN с DON можно рассматривать как гибридный контракт. Абстрагируем сложность: DON предназначены для использования децентрализованных системы удобны для разработчиков и пользователей за счет абстрагирования часто сложных механизмов за мощным и гибким набором услуг DONs. Существующие услуги Chainlink уже есть эта функция. Например, потоки данных в Chainlink сегодня представляют собой интерфейсы цепочки, которые не требуют от разработчиков интересоваться деталями уровня протокола, такими как средства, с помощью которых OCR обеспечивает согласованную отчетность между 2Идея составления контрактов ончейн/оффчейн возникала ранее в различных ограниченных формы, например системы уровня 2, blockchains [80] на базе TEE и т. д. Наша цель — поддержать и обобщить эти подходы и гарантировать, что они могут включать доступ к данным вне цепочки и другие ключевые oracle услуги. 3Chainlink услуги включают в себя множество децентрализованных услуг и функций, доступных через сеть. Их предлагают многочисленные операторы узлов, входящие в различные сети oracle. по всей экосистеме.Рисунок 2. Концептуальная схема, показывающая состав контракта внутри и вне цепочки. А гибрид smart contract 3⃝состоит из двух взаимодополняющих компонентов: цепочки компонент SC 1⃝, резидентный на blockchain, и исполнительный компонент оффчейна 2⃝, который выполняется на DON. DON также служит мостом между двумя компонентами. как соединение гибридного контракта с ресурсами вне сети, такими как веб-сервисы и другие blockchains, децентрализованное хранилище и т. д. децентрализованный набор узлов. DONs идут на шаг дальше в том смысле, что они расширяют диапазон сервисов, для которых Chainlink может предложить разработчикам уровень абстракции с сопровождающие оптимизированные интерфейсы для сервисов высокого уровня. В разделе 4 мы представляем несколько примеров применения, которые подчеркивают этот подход. Мы предполагаем, что предприятия, например, будут использовать DONs как форму безопасного промежуточного программного обеспечения для подключить свои устаревшие системы к blockchain. (См. раздел 4.2.) Такое использование DON абстрагирует сложность общей динамики blockchain (комиссии, реорганизации и т. д.). Это также абстрагирует особенности конкретных blockchain, тем самым позволяя предприятиям подключать свои существующие системы к постоянно расширяющемуся набору систем blockchain без потребность в специализированных знаниях в этих системах или, в более общем плане, в разработке децентрализованных систем. В конечном счете, наша цель — повысить степень абстракции, достигнутую Chainlink. вплоть до реализации того, что мы называем децентрализованным метаслоем. Такой слой абстрагировало бы различие между цепочкой и оффчейном для всех классов разработчиков. и пользователей DApps, что позволяет беспрепятственно создавать и использовать децентрализованные сервисы.Чтобы упростить процесс разработки, разработчики могли указать функциональность DApp на метауровне как виртуальное приложение в единой модели машины. Они могли бы затем используйте компилятор децентрализованного метаслоя для автоматического создания экземпляра DApp как набор взаимодействующих децентрализованных функций, охватывающий blockchains, DONs и внешние услуги. (Одним из этих внешних сервисов может быть корпоративная система, что делает метауровень полезным для приложений, использующих устаревшие корпоративные системы.) Такие компиляция сродни тому, как современные компиляторы и комплекты средств разработки программного обеспечения (SDK) поддерживать программистов широкого профиля в использовании всего потенциала гетерогенного оборудования. архитектуры, состоящие из процессора общего назначения и специализированного оборудования, такого как графические процессоры, ускорители машинного обучения или доверенные анклавы. Рис. 3 представляет эту идею на концептуальном уровне. Гибридные smart contract — это первый шаг на пути к этому видению и к концепции, которую мы называем метаконтрактами. Метаконтракты — это приложения, написанные на децентрализованной метаслой и неявно охватывают логику внутри цепочки (smart contracts), а также вычисления и связь вне цепочки между различными blockchain и существующими вне цепочки услуги. Учитывая необходимость поддержки языка и компилятора, новых моделей безопасности и концептуальное и техническое согласование разрозненных технологий, однако реализация создания настоящего децентрализованного метаслоя — это амбициозная цель, к которой мы стремимся на протяжении длительного времени. временной горизонт. Тем не менее, это полезная идеальная модель, о которой следует помнить при чтении. эта статья, здесь не подробно описана, но мы планируем сосредоточиться на ней в нашей будущей работе над Chainlink. Масштабирование: Целью первостепенной важности в наших развивающихся проектах является обеспечение возможности Сеть Chainlink для удовлетворения растущих потребностей в масштабировании экосистемы blockchain. Поскольку перегрузка сети становится постоянной проблемой в существующих blockchains [86], в использование вступают новые и более производительные конструкции blockchain, например, [103, 120, 203], а также дополнительные технологии масштабирования уровня 2, например, [5, 12, 121, 141, 169, 186, 187]. Сервисы Oracle должны обеспечивать задержки и пропускную способность. которые отвечают требованиям производительности этих систем при минимизации внутрисетевых комиссий. (например, стоимость газа) как для контрактных операторов, так и для обычных пользователей. С DONs, Chainlink Функциональность призвана пойти дальше и обеспечить достаточно высокую производительность для чисто веб-систем. DON получают большую часть своего прироста производительности за счет использования быстрых, комитетных или не требующих разрешения протоколов консенсуса, которые они комбинируют с blockchain. они поддерживают. Мы ожидаем, что множество DON с разными конфигурациями будут работать параллельно; различные DApps и пользователи могут находить компромиссы в базовых консенсусных решениях в соответствии с требованиями их применения. DONs фактически можно рассматривать как технологии уровня 2. Мы ожидаем, что среди другие службы, DONs будут поддерживать инфраструктуру выполнения транзакций (TEF), которая облегчает эффективную интеграцию DON и, следовательно, oracle с другими высокопроизводительными системы уровня 2, например rollups, системы, которые объединяют транзакции вне цепочки для достижения улучшения производительности. Мы представляем TEF в разделе 6.

Рисунок 3: Концептуальная фигура, показывающая идеальную реализацию децентрализованного метаслоя. Для простота разработки, разработчик указывает децентрализованное приложение, выделенное розовым, как виртуальное применение в единой модели машины. Компилятор децентрализованного метаслоя автоматически генерирует соответствующие взаимодействующие функции: smart contracts (обозначаемые SC), логика (обозначенная exec) на DONs, адаптеры, подключающиеся к целевым внешним службам, и т. д., как показано желтым цветом. На рис. 4 концептуально показано, как DON улучшает масштабирование blockchain (smart contract). концентрируя обработку транзакций и oracle-отчетов вне цепочки, а не на цепь. Этот сдвиг в основном месте вычислений снижает задержку транзакций и комиссий при одновременном повышении пропускной способности транзакций. Конфиденциальность: Блокчейны обеспечивают беспрецедентную прозрачность smart contract и реализуемых ими приложений. Но существует основное противоречие между прозрачностью и конфиденциальностью. Сегодня, например, децентрализованные обменные транзакции пользователейРисунок 4. Концептуальный рисунок, показывающий, как децентрализованные сети Oracle улучшают масштабирование blockchain smart contracts. Рисунок А ⃝показывает обычный oracle архитектура. Транзакции отправляются непосредственно в blockchain, как и отчеты oracle. Таким образом, blockchain, выделенный желтым цветом, является основным местом обработки транзакций. На рисунке B⃝ показано использование DON для поддержки контрактов на blockchain. А DON исполняемые процессы обрабатывают транзакции вместе с данными из внешних систем и пересылают их результаты — например, объединенные транзакции или изменения состояния контракта в результате эффектов транзакций — в blockchain. Таким образом, DON, выделенный желтым цветом, является основным место обработки транзакций. действия записываются в цепочке, что позволяет легко отслеживать поведение обмена, а также сделать финансовые транзакции пользователей общедоступными. Аналогично, данные передаются на интеллектуальные контракты остаются в цепочке. Это делает такие данные удобными для проверки, но действует как является препятствием для поставщиков данных, желающих предоставить smart contract конфиденциальные или собственные данные. Мы считаем, что сети oracle будут играть ключевую роль в стимулировании следующего поколения системы, которые сочетают в себе природную прозрачность blockchains с новой защитой конфиденциальности. В этой статье мы покажем, как они это сделают, используя три основных подхода: • Адаптеры, сохраняющие конфиденциальность: две технологии с запланированным развертыванием. в сетях Chainlink, DECO [234] и Town Crier [233], включите узлы oracle для извлекать данные из автономных систем способами, обеспечивающими защиту конфиденциальности и данных пользователей. конфиденциальность. Они сыграют ключевую роль в разработке адаптеров для DONs. (Подробную информацию об этих двух технологиях см. в разделе 3.6.2.) • Конфиденциальные вычисления: DONs могут просто скрыть свои вычисления от доверия blockchains. Используя безопасные многосторонние вычисления и/или доверенные среды выполнения, также возможна более строгая конфиденциальность, в которой узлы DON вычислять данные, которые они сами не видят.

• Поддержка конфиденциальных систем уровня 2: TEF предназначен для поддержки различных систем уровня 2, многие из которых используют доказательства с нулевым разглашением для обеспечения различные формы конфиденциальности транзакций. Мы обсудим эти подходы в разделе 3 (дополнительную информацию см. в разделе 6, приложении B.1 и приложении B.2). На рис. 5 представлено концептуальное представление того, как конфиденциальные данные могут передаваться из внешних источников на smart contract с помощью адаптеров, сохраняющих конфиденциальность, и конфиденциальные вычисления в DON. Рисунок 5. Концептуальная схема операций по сохранению конфиденциальности в DON на конфиденциальные данные (выделены желтым цветом). Конфиденциальные исходные данные (черные кружки) в сети серверов извлекается в DON с помощью адаптеров, сохраняющих конфиденциальность (синие линии с двойной стрелкой). DON получает производные данные (полые кружки) от этих адаптеров: результат применения функции или, например, раскрытия секрета к конфиденциальному источнику данные. Исполняемый файл на DON может применять конфиденциальные вычисления к производным данным. для создания отчета (двойной круг), который он отправляет через адаптер на blockchain. Мы считаем, что мощные инструменты для работы с конфиденциальными данными откроют целый мир спектр приложений. Среди них частные децентрализованные (и централизованные) финансы, децентрализованная идентичность, кредитное онлайн-кредитование, а также более эффективные и удобные для пользователя протоколы «знай своего клиента» и аккредитации, о которых мы поговорим в разделе 4. Справедливость заказов для транзакций: Сегодняшние дизайны blockchain имеют немного грязного секрет полишинеля: они эфемерно централизованы. Майнеры и validators могут заказать транс-действия, как бы они ни выбрали. Пользователи также могут манипулировать порядком транзакций, как является функцией сетевой платы, которую они платят (например, цены на газ в Ethereum), а некоторым степени, используя преимущества быстрых сетевых подключений. Подобные манипуляции могут, например, Например, возьмем форму опережающего действия, при котором стратегический игрок, такой как шахтер, наблюдает за транзакцией пользователя и вставляет свою собственную эксплуатирующую транзакцию в более раннюю позицию в том же блоке — фактически крадет деньги у пользователя, используя предварительную информацию о транзакции пользователя. Например, бот может разместить заказ на покупку. перед пользователем. Затем он может воспользоваться ростом цен на активы, вызванным торговля пользователя. Опережающее выступление некоторых ботов, наносящее вред обычным пользователям — аналогично высокочастотному торговля на Уолл-стрит — уже широко распространена и хорошо документирована [90], что связано с такие атаки, как резервное выполнение [159] и автоматическое копирование транзакций [195]. Недавно даже появились предложения по систематизации эксплуатации ордеров майнерами [110]. Технологии уровня 2, такие как rollups, не решают проблему, а лишь рецентрализуют заказывая, передавая его в руки сущности, создающей rollup. Одна из наших целей — внедрить в Chainlink сервис под названием Fair Sequencing. Услуги (ФСС) [137]. FSS помогает дизайнерам smart contract обеспечить справедливый заказ своих проектов. транзакций и избегать опережающих, обратных и связанных с ними атак на пользовательские транзакции, а также другие типы транзакций, такие как передача отчетов oracle. ФСС позволяет DON реализовать такие идеи, как строгое, временное понятие справедливости порядка, представленное в [144]. В качестве дополнительной выгоды FSS может также снизить нагрузку на сеть пользователей. сборы (например, расходы на газ). Вкратце, в FSS транзакции проходят через DON, а не распространяются непосредственно на целевой объект smart contract. DON заказывает транзакции, а затем пересылает их. их к контракту. Рисунок 6: Пример преимуществ FSS. Рис. А ⃝показано, как майнер, эксплуатирующий свою централизованное право распоряжаться транзакциями, может поменять пару транзакций: транзакция 1⃝ поступает до 2⃝, но вместо этого майнер размещает его после 2⃝. Напротив, на рис. B⃝ показано как DON децентрализует процесс заказа между узлами DON. Если кворум честные узлы получают 1⃝перед 2⃝, FSS заставляет 1⃝появляться перед 2⃝в цепочке — предотвращение изменения порядка майнеров путем прикрепления порядковых номеров, предусмотренных контрактом. На рис. 6 сравнивается стандартный майнинг с FSS. Он показывает, как при стандартном майнингепроцесс заказа транзакций централизован у майнера и, следовательно, подлежит манипуляции, такие как изменение порядка пары транзакций относительно их прибытия раз. Напротив, в FSS процесс децентрализован между узлами DON. Предполагая кворум честных узлов, FSS помогает применять такие политики, как временное упорядочение транзакций, уменьшая возможности для манипулирования со стороны майнеров и других лиц. Кроме того, поскольку пользователям не нужно конкурировать за льготный заказ на основе цены на газ, они могут платить относительно низкие цены на газ (в то время как транзакции из DON можно группировать для экономии газа). Минимизация доверия: Наша общая цель при разработке DONs состоит в том, чтобы облегчить надежный уровень поддержки для smart contracts и других oracle-зависимых систем посредством децентрализации, криптографических инструментов и криптоэкономических гарантий. DON сам по себе децентрализован, и пользователи могут выбирать любой доступный DON, который поддерживает основную цепочку, в которой они хотят работать, или создает дополнительные DON с комитетами узлов, которым они доверяют. Однако для некоторых приложений, особенно smart contracts, Chainlink пользователи могут отдайте предпочтение модели доверия, которая рассматривает основную цепочку, поддерживаемую DON, как более надежную. чем сам DON. Для таких пользователей мы уже имеем или планируем включить в архитектура сети Chainlink ряд механизмов, обеспечивающих контракты в основной цепочке для усиления гарантий безопасности, предоставляемых DONs, в то время как на в то же время также обеспечивается защита от возможности повреждения источников данных. например веб-серверы, с которых DON получает данные. Мы описываем эти механизмы в разделе 7. Они подразделяются на пять основных заголовков: • Аутентификация источника данных: инструменты, позволяющие поставщикам данных ставить цифровую подпись. свои данные и тем самым укрепить цепочку сохранности между источником и полагающийся договор. • DON отчеты меньшинства: флаги, выдаваемые меньшинством узлов DON, которые наблюдает должностные преступления большинства в DON. • Ограждения: логика главной цепи обнаруживает аномальные условия и приостанавливает работу. или останавливает выполнение контракта (или требует других мер по исправлению ситуации). • Управление с минимальным доверием: использование обновлений, выпускаемых постепенно, для облегчения проверки сообщества, а также децентрализованное экстренное вмешательство для быстрого реагирование на системные сбои. • Децентрализованная аутентификация объекта: использование инфраструктуры открытых ключей (PKI) для идентифицировать объекты в сети Chainlink. На рис. 7 представлена ​​концептуальная схема наших целей по минимизации доверия. Стимулирующая (криптоэкономическая) безопасность: Децентрализация формирования отчетов по узлам oracle помогает обеспечить безопасность даже в случае повреждения некоторых узлов.

Рисунок 7: Концептуальное изображение цели Chainlink по минимизации доверия, которая заключается в свести к минимуму потребность пользователей в правильном поведении DON и источников данных, таких как Интернет. серверы. Желтые блики на рисунке обозначают локусы минимизации доверия: DON и отдельные или меньшие наборы веб-серверов. Розовые блики обозначают компоненты системы. которые по предположению заслуживают большого доверия: контракты на blockchain и большинство веб-серверов, то есть веб-серверов в совокупности. Не менее важно, однако, обеспечить, чтобы узлы имели финансовый стимул вести себя правильно. Стейкинг, т. е. требование от узлов предоставить депозиты LINK и слэшинг. (конфискация) этих депозитов в случае ненадлежащего поведения сыграет ключевую роль в Chainlink. Это важная система стимулирования, которая уже использовалась в ряде blockchains, например, [81, 103, 120, 204]. Однако размещение в Chainlink сильно отличается от staking в автономном режиме. blockchainс. Ставка на blockchains направлена ​​на предотвращение атак на консенсус. У него есть другая цель в Chainlink: обеспечить своевременную доставку правильных отчетов oracle. Хорошо спроектированная система staking для сети oracle должна отражать такие атаки, как взяточничество. невыгодно противнику, даже если целью является smart contract с высоким денежная стоимость. В этой статье мы представляем общий подход к staking в Chainlink с тремя ключевыми инновации:1. Мощная состязательная модель, охватывающая атаки, упущенные из виду в существующих подходы. Одним из примеров является то, что мы называем предполагаемым взяточничеством. Это форма взяточничество, которое определяет, какие узлы получают взятки на условной основе, например, заранее предлагает гарантированные взятки узлам, которые выбирает механизм staking в случайным образом для определенных ролей (например, инициирование вынесения решения по отчету). 2. Суперлинейное воздействие staking, неформально означающее, что для успеха противник должен иметь бюджет B, превышающий совокупные вклады всех oracle. узлы. Точнее, мы имеем в виду, что в зависимости от n \(B(n) ≫\)dn в сеть из n oracle узлов, каждый с фиксированной суммой депозита $d (более формально, \(B(n) is asymptotically larger in n than \)дн). На рис. 8 представлено концептуальное представление это свойство. 3. Система неявных стимулов (IIF), модель стимулирования, которую мы разработали для охватывать эмпирически измеримые стимулы помимо явно депонированных staking средства, включая возможности будущих комиссий узлов. IIF расширяет понятие ставка выходит за рамки явных депозитов узлов. Рис. 8. Концептуальная диаграмма, изображающая суперлинейное масштабирование в Chainlink staking. взятка $B(n), требуемая противником, растет в n быстрее, чем совокупные депозиты $dn всех узлов oracle. Мы показываем, как IIF и суперлинейное воздействие staking вместе вызывают то, что мы назвать благотворный цикл экономической безопасности для сетей oracle. Когда приходят новые пользователи

системы, увеличивая потенциальные будущие доходы от запуска узлов Chainlink, предельные издержки экономической безопасности падают для нынешних и будущих пользователей. В режиме эластичный спрос, это снижение затрат стимулирует дополнительных пользователей использовать сети, постоянно поддерживая внедрение в непрерывном благотворном цикле. Примечание. Хотя в этом документе излагаются важные элементы нашего видения развития Chainlink, он носит неформальный характер и включает несколько подробных технических характеристик. Мы планируем выпускать технические документы, посвященные дополнительным функциям и подходам по мере их развития. Кроме того, важно подчеркнуть, что многие элементы представленного видения здесь (улучшения масштабирования, технологии конфиденциальности, ФСС и т. д.) могут и будут развернут в предварительной форме еще до того, как расширенные DON станут базовой функцией Chainlink. 1.3 Организация данного документа Мы представляем нашу модель безопасности и обозначения в разделе 2 и обрисовываем децентрализованную систему безопасности. Oracle Network API в разделе 3. В разделе 4 мы представляем ряд примеров приложения, для которых DONs предоставляют привлекательную платформу развертывания. Читатели могут изучите большинство ключевых концепций статьи, дочитав ее до этого момента. Оставшаяся часть документа содержит дополнительную информацию. Мы описываем справедливую последовательность Службы (FSS) в разделе 5 и структура выполнения транзакций (TEF) в разделе 6. Мы описываем наш подход к минимизации доверия в разделе 7. Мы рассматриваем некоторые важные требования DON к развертыванию, а именно постепенное развертывание функций, динамическое членство в реестре и подотчетность в Разделе 8. Наконец, в Разделе 9 мы приводим обзор нашего развивающегося подхода к разработке стимулов. Подведем итоги в разделе 10. Чтобы помочь читателям, которые ограниченно знакомы с концепциями этой статьи, мы предоставить глоссарий в Приложении A. Мы представляем дополнительную информацию об интерфейсе DON. и функциональность в Приложении B, а примеры адаптеров представлены в Приложении C. В приложении D мы описываем криптографический примитив для источника данных с минимизированным доверием. аутентификацию, называемую функциональными сигнатурами, и представить новый вариант, называемый дискретными функциональными сигнатурами. Мы обсуждаем некоторые соображения, имеющие отношение к комитету. выбор для DONs в Приложении F.

Модель безопасности и цели

Децентрализованная сеть Oracle — это отдельная распределенная система, которая, как мы ожидаем, будет первоначально реализовываться обычно (хотя и не обязательно) комитетом на базе комитета. протокол консенсуса и выполняется набором узлов oracle. DON предназначен в первую очередь расширить возможности smart contract в основной цепочке с помощью отчетов oracle и другие услуги, но он может предоставлять те же вспомогательные услуги другим системам, отличным от blockchain, и поэтому не обязательно должен быть связан с конкретной основной цепочкой.

Поэтому модель и свойства, которые мы рассматриваем, в значительной степени независимы от использования конкретные применения DON. 2.1 Текущая архитектурная модель Важно подчеркнуть, что Chainlink сегодня представляет собой не монолитный сервис, а скорее не требующая разрешения структура, в которой можно запускать отдельные, независимые сети из oracle узлов [77]. Сети имеют разнородные наборы операторов узлов и конструкции. Они также могут различаться по видам предоставляемых услуг, что может включают, например, потоки данных, подтверждение резервов, проверяемую случайность и т. д. Другое различия могут включать степень децентрализации, размер сети с точки зрения поддерживаемое заблокированное значение и различные параметры уровня обслуживания, такие как частота передачи данных. и точность. Модель Chainlink без разрешений способствует развитию экосистемы, в которой Поставщики услуг специализируются на услугах, которые они лучше всего могут предоставить обществу. Это модель, вероятно, приведет к снижению затрат для пользователей и более высокому качеству обслуживания, чем модель который требует, чтобы все узлы и сети предоставляли полный спектр услуг, подход которые могут легко перерасти в общесистемное внедрение услуг, представляющих наименее общий знаменатель ресурсов, доступных узлам. По мере того как Chainlink развивается в сторону проектов на основе DON в Chainlink 2.0, мы продолжаем поддерживать модель не требующей разрешения открытой структуры, принимая во внимание цель предоставление пользователям широкого выбора услуг, которые во всем мире приводят к наилучшему совпадению с особыми требованиями к применению. 2.2 Консенсусные предположения Мы используем термин «децентрализованная сеть Oracle», чтобы охватить полную функциональность описываемая нами система oracle: как структура данных, которую поддерживают узлы oracle, так и основной API, наложенный поверх него. Мы используем термин «регистр» (строчная буква), обозначаемый буквой L, для обозначения базовых данных. структура, поддерживаемая DON и используемая для поддержки конкретных услуг, которые он предоставляет. Мы подчеркиваем, что наша структура DON не рассматривает L как автономную систему, такую как a blockchain: его целью является поддержка blockchain и других систем. Блокчейны — это, конечно, это один из способов создания надежного реестра, но есть и другие. Мы ожидаем DONs во многих случаях для реализации своих базовых реестров с использованием Byzantine Fault Tolerant (BFT), которые значительно предшествуют blockchain, таким как Bitcoin [174]. Мы используем Для удобства в статье введите обозначения и свойства BFT, хотя мы подчеркните, что DON могут быть реализованы с использованием протоколов консенсуса без разрешения. Концептуально реестр L представляет собой доску объявлений, на которой данные упорядочены линейно. Мы рассматриваем реестр в целом как имеющий несколько ключевых свойств, обычно приписываемых ему. blockchains [115]. Регистр – это: • Только добавление: Добавленные данные невозможно удалить или изменить.• Общественный: Любой может прочитать его содержимое, которое не меняется во времени. просмотр всех пользователей.4 • Доступен: авторизованные авторы всегда могут записать в реестр и прочитать его. кем-либо своевременно. Альтернативные свойства возможны в реестре для DON, если они реализованы комитет. Например, доступ к записи в реестр может быть ограничен определенными пользователями, как может иметь доступ на чтение для некоторых приложений, т. е. реестр не обязательно должен быть общедоступным, как определено выше. Аналогично, правила реестра могут разрешать изменение или редактирование данных. Мы не Однако подробно рассмотрим такие варианты в этой статье. Модульная конструкция DONs может поддерживать любые современные BFT. протоколы, например Hotstuff[231]. Точный выбор будет зависеть от предположений о доверии и характеристики сети среди узлов oracle. DON в принципе может альтернативно использовать высокопроизводительный blockchain без разрешений для своего реестра в роли поддержки одинаково масштабируемая система уровня 2 или blockchain. Аналогичным образом возможна и гибридизация: DON в принципе может состоять из узлов, которые являются validator в существующем blockchain, например, в системах Proof-of-Stake, в которых комитеты выбираются для выполнения транзакции, например, [8, 81, 120, 146, 204]. Этот конкретный режим работы требует, чтобы узлы работают двойного назначения, т. е. работают как узлы blockchain и DON. узлы. (См. раздел 8.2, где обсуждаются методы обеспечения непрерывности изменения комитетов и Приложение F, где приведены некоторые предостережения относительно случайного выбора комитетов.) На практике в современных алгоритмах BFT узлы подписывают сообщения в реестре цифровой подписью. Для удобства мы предполагаем, что L имеет связанный с ним открытый ключ pkL и что его содержимое подписаны соответствующим секретным ключом. Это общее обозначение применимо даже тогда, когда данные на L подписываются с использованием пороговых подписей.5 Пороговые подписи удобны, поскольку они обеспечивают постоянную идентификацию для DON даже при изменении членства в узлы, на которых он работает. (См. Приложение B.1.3.) Таким образом, мы предполагаем, что skL имеет общий секрет. (k, n)-пороговым образом для некоторого параметра безопасности k, например, k = 2f + 1 и n = 3f + 1, где f — количество потенциально неисправных узлов. (Выбирая k в этом Таким образом, мы гарантируем, что неисправные узлы не смогут ни изучить skL, ни смонтировать отказ в обслуживании. атака, препятствующая его использованию.) Сообщение на L принимает форму M = (m, z), где m — строка, а z — уникальная строка. порядковый индексный номер. Там, где это применимо, мы пишем сообщения в виде m = ⟨Тип сообщения: полезная нагрузка⟩. Тип сообщения MessageType — это синтаксический сахар, указывающий функцию конкретного сообщения. 4В случаях, когда blockchain без окончательности реализует реестр, несогласованность обычно абстрагируется. проигнорировав недостаточно глубокие блоки или «обрезая» [115]. 5На практике некоторые базы кода, например, LibraBFT [205], вариант Hotstuff, в настоящее время мультиподписи, а не пороговые подписи, в обмен на снижение сложности связи для более простая инженерия. За дополнительную плату узлы oracle могут добавлять к сообщениям пороговые подписи. записываются в L, даже если протокол консенсуса, используемый для L, их не использует.2.3 Обозначения Обозначим набор из n oracle узлов, управляющих реестром, через O = {Oi}n. я = 1. Такой набор узлов часто называют комитетом. Для простоты будем считать, что множество oracles, реализующие функциональность DON, т. е. службы поверх L, идентичны с что сохраняет L, но они могут быть различны. Мы обозначим pki открытый ключ игроку Oi, и лыжите соответствующий приватный ключ. Для большинства алгоритмов BFT требуется как минимум n = 3f + 1 узлов, где f — количество узлов. потенциально неисправные узлы; остальные узлы честны в том смысле, что они следуют Протокол точно такой, как указано. Мы называем комитет О честным, если он соответствует этому требованию. требование, т. е. имеет более 2/3 доли честных узлов. Если иное Как указано выше, мы предполагаем, что O честен (и является статической моделью коррупции). Мы используем пкО/ skO взаимозаменяемо с pkL/skL, в зависимости от контекста. Обозначим через σ = Sigpk[m] подпись сообщения m относительно pk, т. е. используя соответствующий закрытый ключ ск. Пусть Verify(pk, σ, m) → {false, true} обозначает соответствующий алгоритм проверки подписи. (Мы оставляем генерацию ключей неявной на протяжении всей статьи.) Мы используем обозначение S для обозначения источника данных и S для обозначения полного набора источники нс в данном контексте. Мы обозначаем MAINCHAIN включенный смарт-контракт. blockchain поддерживается DON. Мы используем термин «полагающийся контракт» для обозначения любого умного контракта. контракт на MAINCHAIN, который взаимодействует с DON, и используйте обозначение SC для обозначим такой договор. Обычно мы предполагаем, что DON поддерживает одну основную цепочку MAINCHAIN, хотя он может поддерживать несколько таких цепочек, как мы показываем в примерах в разделе 4. DON может и обычно будет поддерживать несколько зависимых контрактов на MAINCHAIN. (Как как отмечалось выше, DON альтернативно может поддерживать службы, отличные от blockchain.) 2.4 Примечание о моделях доверия Как отмечалось выше, DON могут быть построены на основе протоколов консенсуса на основе комитетов, и мы ожидайте, что они будут обычно использовать такие протоколы. Существует много веских аргументов в пользу того, что одна из двух альтернатив, основанная на комитете или не требующая разрешения blockchain, обеспечивает более сильная безопасность, чем другая. Важно признать, что безопасность комитетов по сравнению с несанкционированными децентрализованные системы несоизмеримы. Компрометация PoW или PoS blockchain Атака 51% требует, чтобы противник получил большинство ресурсов эфемерно и потенциально анонимно, например, арендуя hash мощность в системе PoW. такой На практике атаки уже затронули несколько blockchain [200, 34]. Напротив, компрометация системы, основанной на комитетах, означает повреждение порогового числа (обычно одной трети) ее узлов, при этом узлы могут быть общеизвестны, хорошо обеспечены ресурсами, и заслуживающие доверия субъекты. С другой стороны, системы на основе комитетов (а также «гибридные» системы без разрешения) системы, поддерживающие комитеты) могут поддерживать больше функций, чем строго предусмотренобеспредметные системы. Это включает в себя способность сохранять постоянные секреты, такие как ключи подписи и/или шифрования — одна из возможностей в наших разработках. Мы подчеркиваем, что DON в принципе могут быть построены на базе комитетов или протокол консенсуса без разрешений, и развертыватели DON могут в конечном итоге принять решение любой подход. Укрепление моделей доверия: Ключевой особенностью Chainlink сегодня является возможность пользователей выбирать узлы на основе децентрализованных записей их истории производительности, как обсуждалось. в разделе 3.6.4. Механизм staking и структура неявного стимулирования, которые мы представляем в разделе 9, вместе представляют собой широкомасштабный и строгий механизм проектирования. фреймворк, который предоставит пользователям значительно расширенные возможности для оценки безопасности DONs. Эта же структура позволит и самим DONs для обеспечения соблюдения различных требований безопасности на участвующих узлах и обеспечения работы в рамках моделей сильного доверия. Также возможно использовать инструменты, описанные в этом документе для DONs, для обеспечения соблюдения особых требований модели доверия, таких как соответствие нормативным требованиям. Для Например, используя методы, описанные в разделе 4.3, узлы могут предоставить доказательства характеристики узла-оператора, например, территория деятельности, которые можно использовать, чтобы помочь обеспечить соблюдение, например, статьи 3 Общего регламента защиты данных (GDPR) («Территориальный охват») [105]. В противном случае такое соблюдение может быть затруднено. встречаются в децентрализованных системах [45]. Кроме того, в разделе 7 мы обсуждаем планы по повышению устойчивости DONs. посредством механизмов минимизации доверия в основных цепочках, которые они поддерживают.

Децентрализованный сетевой интерфейс Oracle и Ca-

возможности Здесь мы кратко описываем возможности DONs с точки зрения простого, но мощного интерфейс, который они призваны реализовать. Приложения на DON состоят из исполняемых файлов и адаптеров. Исполняемый файл — это программа, основная логика которой представляет собой детерминированную программу, аналогичную smart contract. Исполняемый файл также имеет ряд сопутствующих инициаторов — программ, вызывающих вход. точки в логике исполняемого файла, когда происходят заранее определенные события, например, в определенное время (как задание cron), когда цена пересекает пороговое значение и т. д. — очень похоже на Keepers (см. раздел 3.6.3). Адаптеры предоставляют интерфейсы для ресурсов вне цепочки и могут вызываться либо инициаторы, либо основная логика в исполняемых файлах. Поскольку их поведение может зависеть от этого внешних ресурсов инициаторы и адаптеры могут вести себя недетерминировано. Мы описываем интерфейс разработчика DON и функционирование исполняемых файлов и адаптеры с точки зрения трех ресурсов, которые обычно используются для характеристики вычислительных систем: сети, вычислений и хранения. Мы даем краткий обзор каждого из них ресурсы ниже и предоставьте более подробную информацию в Приложении B.

3.1 сеть Адаптеры — это интерфейсы, через которые исполняемые файлы, работающие на DON, могут отправлять и получать данные от офф-DON систем. Адаптеры можно рассматривать как обобщение адаптеры, используемые в Chainlink сегодня [20]. Адаптеры могут быть двунаправленными, т.е. не может просто извлекать, но и отправлять данные с DON на веб-сервер. Они также могут использовать распределенные протоколы, а также криптографические функции, такие как безопасная многосторонняя расчет. Рис. 9. Адаптеры, соединяющие DON, обозначенный DON1, с рядом различных ресурсов, включая еще один DON, обозначенный DON2, blockchain (основная цепочка) и его мемпул, внешнее хранилище, веб-сервер и устройства IoT (через веб-сервер). Показаны примеры внешних ресурсов, для которых можно создать адаптеры. на рис. 9. К ним относятся: • Блокчейны: адаптер может определить, как отправлять транзакции на blockchain и как читать из него блоки, отдельные транзакции или другое состояние. Адаптер также может быть определен для мемпула blockchain. (См. раздел 3.5.) • Веб-серверы: адаптеры могут определять API, через которые можно получать данные. с веб-серверов, включая устаревшие системы, специально не адаптированные для взаимодействие с DONs. Такие адаптеры также могут включать API для отправки данных. такие серверы. Веб-серверы, к которым подключается DON, могут служить шлюзами. к дополнительным ресурсам, таким как устройства Интернета вещей (IoT).• Внешнее хранилище: адаптер может определять методы чтения и записи в хранилище. сервисы за пределами DON, такие как децентрализованная файловая система [40, 188] или облачная хранилище. • Другие DON: адаптеры могут получать и передавать данные между DON. Мы ожидаем, что первоначальные развертывания DONs будут включать в себя набор строительных блоков. адаптеры для таких часто используемых внешних ресурсов и в дальнейшем позволят DON-специфичным адаптеры, которые будут опубликованы узлами DON. Как пишут адаптеры разработчики smart contract сегодня мы ожидаем, что они создадут еще более мощные адаптеры, используя эту передовую технологию. функциональность. Мы ожидаем, что в конечном итоге пользователи смогут создавать новые адаптеры в без разрешения. Некоторые адаптеры должны быть сконструированы таким образом, чтобы гарантировать постоянство и доступность внешних ресурсов, управляемых DON. Например, облачное хранилище может требуют обслуживания учетной записи облачных служб. Кроме того, DON может выполнять децентрализованное управление закрытыми ключами от имени пользователей (например, [160]) и/или исполняемые файлы. Следовательно, DON способен контролировать ресурсы, такие как криптовалюта, которые могут использоваться, например, для отправки транзакций по цели blockchain. Дополнительную информацию об адаптерах DON см. в Приложении B.1, а некоторые — в Приложении C. примеры адаптеров. 3.2 Вычисление Исполняемый файл — это базовая единица кода на DON. Исполняемый файл представляет собой пару exec = (логика, инициализация). Здесь логика представляет собой детерминированную программу с рядом обозначенных записей. точки (логика1, логика2,..., логикаℓ), а init — набор соответствующих инициаторов (инициал1, инит2,..., инит). Чтобы обеспечить полную проверяемость DON, логика исполняемого файла использует базовый регистр L для всех входов и выходов. Так, например, любой адаптер данные, служащие входными данными для исполняемого файла, должны быть сначала сохранены в L. Инициаторы: Инициаторы в Chainlink сегодня вызывают выполнение зависимых от событий заданий на Chainlink узлы [21]. Инициаторы в DONs действуют примерно таким же образом. Однако инициатор DON конкретно связан с исполняемым файлом. Инициатор может зависеть по внешнему событию или состоянию, по текущему времени или по предикату состояния DON. Учитывая свою зависимость от событий, инициаторы, конечно, могут вести себя недетерминировано. (как и адаптеры, конечно). Инициатор может выполняться внутри отдельных узлов DON. и поэтому не нужно полагаться на адаптер. (См. пример 1 ниже.) Инициаторы — важная особенность, отличающая исполняемые файлы от smart contract. Поскольку исполняемый файл может запускаться в ответ на инициатор, он может эффективно работать. автономно, как и, конечно, в расширении гибридного контракта, включающего исполняемый файл. Сегодня одной из форм инициаторов являются Chainlink Keepers, которые обеспечивают транзакцию.услуги автоматизации, инициирующие исполнение smart contract — например, ликвидацию кредитов с недостаточным обеспечением и исполнение сделок с лимитными ордерами — на основе отчетов oracle. Удобно, что инициаторы в DONs также можно рассматривать как способ указания соглашения об обслуживании, применимые к исполняемому файлу, поскольку они определяют обстоятельства, который DON должен назвать. Следующий пример иллюстрирует, как инициаторы работают внутри исполняемого файла: Пример 1 (Ценовой поток, вызванный отклонением). Для smart contract SC может потребоваться свежий данные ценового потока (см. раздел 3.6.3) всякий раз, когда происходит существенное изменение, например, 1%, в обменный курс между парой активов, например, ETH-USD. Чувствительная к волатильности цена каналы сегодня поддерживаются в Chainlink, но поучительно посмотреть, как их можно реализовано на DON с помощью исполняемого файла execfeed. Исполняемый файл execfeed поддерживает самую последнюю цену ETH-USD r на L в форме последовательности записей ⟨NewPrice : j, r⟩, где j — индекс, увеличенный на каждое обновление цен. Инициатор init1 заставляет каждый узел Oi отслеживать текущую цену ETH-USD для отклонения не менее 1% от последней сохраненной цены r с индексом j. После обнаружения такого отклонения, Oi записывает свое текущее представление ri о новой цене в L, используя запись вида ⟨PriceView: i, j + 1, ri⟩. Второй инициатор init2 срабатывает, когда по крайней мере k таких записей PriceView с новой ценой значения индекса j + 1, созданные разными узлами, накопились на L. Затем init2 вызывает логику точки входа2 для вычисления медианы ρ первых k свежих действительных значений PriceView и записывает свежее значение ⟨NewPrice : j + 1, ρ⟩ в L . (В оперативном режиме узлы могут по очереди выступать в качестве назначенных авторов.) Третий инициатор init3 отслеживает записи NewPrice на L. Всякий раз, когда появляется новый отчет ⟨NewPrice : там появляется j, r⟩, он вызывает логику точки входа3, которая отправляет (j, r) в SC с помощью адаптера. Как мы уже отмечали, исполняемый файл по своим возможностям аналогичен smart contract. Однако, помимо более высокой производительности, он отличается от типичного контракта основной цепи. двумя основными способами: 1. Конфиденциальность. Исполняемый файл может выполнять конфиденциальные вычисления, т. е. секретная программа может обрабатывать входные данные в виде открытого текста, а опубликованная программа может обрабатывать секретные входные данные или их комбинация. В простой модели секретные данные могут доступ к узлам DON, которые скрывают промежуточные результаты и раскрывают только обработанные и очищенные значения в MAINCHAIN. Также возможно скрыть конфиденциальные данные от самих DON: DON предназначены для поддержки таких подходов. как многосторонние вычисления, например [42, 157], и доверенные среды выполнения. (TEE) [84, 133, 152, 229] для этой цели.6 6Кроме того, также возможно сохранение секретности самих исполняемых файлов по отношению к узлам DON, хотя сегодня это практично только для нетривиальных исполняемых файлов, использующих TEE.2. Вспомогательная роль: исполняемый файл предназначен для поддержки smart contract на главном сервере. цепи, а не заменять их. Исполняемый файл имеет несколько ограничений, которые smart contract не: (a) Модель доверия: исполняемый файл работает в рамках модели доверия, определенной DON: Правильное выполнение зависит от честного поведения О. (Основной однако цепочка может обеспечить некоторую защиту от неправомерных действий DON, поскольку обсуждается в разделе 7.3.) (б) Доступ к активам: DON может контролировать учетную запись на blockchain — и, таким образом, управлять активами на нем через адаптер. Но DON не может авторитетно представляют активы, созданные в основной цепочке, например, Ether или ERC20 tokens, поскольку их родная сеть ведет авторитетную запись о своей собственности. (c) Жизненный цикл: DON могут быть намеренно установлены с ограниченным сроком службы, поскольку определяется внутрисетевыми соглашениями об уровне обслуживания между DONs и владельцами опирающихся контрактов. Блокчейны, напротив, призваны функционировать как постоянные архивные системы. См. Приложение B.2 для получения дополнительной информации о вычислении DON. 3.3 Хранение Как система, основанная на комитетах, DON может постоянно хранить умеренные объемы данных. на L по гораздо более низкой цене, чем несанкционированный blockchain. Кроме того, через адаптеры DON могут ссылаться на внешние децентрализованные системы для хранения данных, например Filecoin [85], и таким образом может подключать такие системы к smart contracts. Этот вариант особенно привлекательным для больших объемов данных как средство решения широко распространенной проблемы «раздувания» blockchain систем. Таким образом, DON могут хранить данные локально или внешне для использования в своих специально поддерживаемых службах. DON может дополнительно использовать такие данные конфиденциальным способом, вычисления с данными, которые: (1) секретно разделены между узлами DON или зашифрованы под ключ, управляемый узлами DON способами, подходящими для безопасных многосторонних вычислений или частичное или полностью гомоморфное шифрование; или (2) защищено с использованием доверенного выполнения окружающая среда. Мы ожидаем, что DONs примут простую модель управления памятью, общую для системы смарт-контрактов: исполняемый файл может записывать только в свою память. Исполняемые файлы однако может читать из памяти другие исполняемые файлы. Дополнительную информацию о хранилище DON см. в Приложении B.3. 3.4 Структура выполнения транзакций (TEF) DON предназначены для поддержки контрактов в основной цепочке MAINCHAIN (или в нескольких основных цепочках). Структура выполнения транзакций (TEF), подробно обсужденнаяв разделе 6 – это универсальный подход к эффективному исполнению контракта. SC через MAINCHAIN и DON. TEF предназначен для поддержки FSS и уровня 2. технологии — одновременно, при желании. Действительно, он, вероятно, будет служить основным транспортным средством. для использования FSS (по этой причине мы не обсуждаем FSS в этом разделе). Вкратце, в TEF исходный целевой контракт SC, спроектированный или разработанный для MAINCHAIN. реорганизован в гибридный контракт. Этот рефакторинг создает два взаимодействующих части гибридного контракта: контракт MAINCHAIN SCa, на который мы ссылаемся для ясности. в контексте TEF в качестве якорного контракта и исполняемого файла на DON. Контракт SCa хранит активы пользователей, выполняет авторитетные переходы между состояниями, а также обеспечивает ограждение (см. раздел 7.3) от сбоев в DON. Исполняемые исполнители упорядочивает транзакции и предоставляет для них связанные oracle данные. Он может объединять транзакции для SCa любым из нескольких способов, например, используя проверку достоверности или оптимистичные rollups, конфиденциальное исполнение DON и т. д. Мы планируем разработать инструменты, которые облегчат разработчикам разделение контракта. SC написан на языке высокого уровня на части логики MAINCHAIN и DON, SCa и соответственно, которые создают безопасно и эффективно. Использование TEF для интеграции высокопроизводительных схем транзакций с высокопроизводительными oracles является неотъемлемой частью нашего подхода к масштабированию oracle. 3,5 Услуги мемпула Важная функция прикладного уровня, которую мы намерены развернуть на DON в рамках поддержки. FSS и TEF являются службами мемпула (MS). MS можно рассматривать как адаптер, но с первоклассной поддержкой. MS обеспечивает поддержку обработки транзакций, совместимой с устаревшими версиями. В этом случае MS принимает из мемпула основной цепочки те транзакции, которые предназначены для целевого контракта SC на ГЛАВНОЙ ЦЕПИ. Затем MS передает эти транзакции исполняемому файлу на DON, где они обрабатываются нужным образом. Данные MS могут использоваться DON для составления транзакций, которые затем можно будет передать непосредственно в SC из DON или к другому контракту, который вызывает SC. Например, DON может пересылать транзакции. собираются через MS, или он может использовать данные MS для установки цен на газ для транзакций, которые он отправляет ГЛАВНАЯ ЦЕПЬ. Поскольку MS контролирует мемпул, MS может получать транзакции от пользователей, напрямую взаимодействующих с SC. Таким образом, пользователи могут продолжать генерировать свои транзакции, используя устаревшее программное обеспечение, то есть приложения, не знающие о существовании MS и сконфигурированных под MS. контракты. (В этом случае необходимо изменить SC, чтобы он игнорировал исходные транзакции и принимать только те, которые обрабатываются MS, чтобы избежать двойной обработки.) Для использования с целевым контрактом SC MS может использоваться с FSS и/или TEF.3.6 Шаги: существующие возможности Chainlink 3.6.1 Внесетевая отчетность (OCR) Отчеты вне цепочки (OCR) [60] — это механизм в Chainlink для агрегации отчетов oracle и их передачи в опорный контрактный SC. Недавно развернуто по цене Chainlink. кормовых сетей, это представляет собой первый шаг на пути к полноценным DONs. По своей сути OCR представляет собой протокол BFT, предназначенный для работы в частично синхронном режиме. сеть. Это обеспечивает живучесть и корректность при наличии f < n/3 произвольно. неисправные узлы, гарантирующие византийские свойства надежного вещания, но это не полный протокол консенсуса BFT. Узлы не ведут журналы сообщений, которые последовательным в смысле представления реестра, идентичного во всех их представлениях, и ведущий протокола может уклоняться от ответа, не нарушая безопасности. В настоящее время OCR предназначен для определенного типа сообщений: медианного агрегирования (не менее 2f +1) значений, сообщаемых участвующими узлами. Это обеспечивает ключевую гарантию отчеты, которые он выводит для SC, называемые аттестованными отчетами: медианное значение в аттестованном отчете. report равен или находится между значениями, сообщенными двумя честными узлами. Это свойство ключевое условие безопасности для OCR. Лидер может иметь некоторое влияние на медианное значение. значение в заверенном отчете, но только при условии соблюдения этого условия правильности. OCR может быть распространено на типы сообщений, которые агрегируют значения различными способами. Хотя сегодня цели жизнеспособности и корректности сети Chainlink не требуют Поскольку OCR является полноценным консенсусным протоколом, они требуют, чтобы OCR предоставлял некоторые дополнительные формы функциональности, отсутствующие в обычных протоколах BFT, в первую очередь: 1. Трансляция отчета вне сети по принципу «все или ничего»: OCR гарантирует, что заверенный отчет быстро становится доступным для всех честных узлов или ни для одного из них. Это справедливость свойство, которое помогает гарантировать, что честные узлы имеют возможность участвовать при заверенной передаче отчета. 2. Надежная передача: распознавание символов обеспечивает распознавание даже при наличии ошибочных или вредоносных сообщений. узлов, что все отчеты и сообщения OCR передаются в SC в течение определенного, заранее заданный интервал времени. Это свойство живости. 3. Минимизация доверия на основе контракта: SC отфильтровывает потенциально ошибочные отчеты, созданные OCR, например, если их сообщаемые значения значительно отклоняются от других недавно полученные. Это форма внепротокольного обеспечения корректности. Все три свойства будут играть естественную роль в DONs. Офчейн-трансляция по принципу «все или ничего» (DON) является важным строительным блоком криптоэкономических гарантий. вокруг надежной передачи, что, в свою очередь, является важным свойством адаптера. Доверие Минимизация в SC — это своего рода ограждение, как обсуждалось в разделе 7.3. OCR также обеспечивает основу для оперативного развертывания и доработки протоколов BFT в сетях oracle Chainlink и, таким образом, как отмечалось выше, открывает путь к полной функциональность DONs.3.6.2 ДЕКО и городской глашатай DECO [234] и Town Crier [233] — это пара связанных технологий, которые в настоящее время разрабатываются. разработано в сетях Chainlink. Большинство веб-серверов сегодня позволяют пользователям подключаться по защищенному каналу с использованием протокола. называется Transport Layer Security (TLS) [94]. (HTTPS указывает на вариант HTTP, который включен с помощью TLS, т. е. URL-адреса с префиксом «https» означают использование TLS для безопасности.) Однако у большинства серверов с поддержкой TLS есть заметное ограничение: они не подписывают цифровую подпись. данные. Следовательно, пользователь или проверяющий не может представить данные, которые он получает с сервера. третьей стороне или проверяющей стороне, например oracle или smart contract, таким образом, чтобы гарантировать достоверность данных. Даже если сервер подписывает данные цифровой подписью, остается проблема конфиденциальности. Испытатель может пожелать отредактировать или изменить конфиденциальные данные перед представлением их проверяющему. Верификатор. Однако цифровые подписи созданы специально для признания недействительными измененных данных. Таким образом, они не позволяют проверяющему вносить изменения, сохраняющие конфиденциальность. к данным. (Для более подробной информации см. раздел 7.1.) DECO и Town Crier предназначены для того, чтобы позволить испытателю получать данные из Интернета. сервер и представить его проверяющему лицу таким образом, чтобы обеспечить целостность и конфиденциальность. Обе системы сохраняют целостность в том смысле, что они гарантируют, что данные, представленные Доказывающее устройство проверяющему исходит аутентично с целевого сервера. Они поддерживают конфиденциальность в том смысле, что проверяющему разрешено редактировать или изменять данные (при этом все еще сохраняя целостность). Ключевой особенностью обеих систем является то, что они не требуют каких-либо модификаций целевой веб-сервер. Они могут работать с любым существующим сервером с поддержкой TLS. Фактически, они прозрачны для сервера. С точки зрения сервера Доказывающее устройство установление обычного соединения. Обе системы преследуют схожие цели, но различаются моделями доверия и реализациями, как мы сейчас кратко объясним. DECO фундаментально использует криптографические протоколы для достижения целостности. и свойства конфиденциальности. Устанавливая сеанс с целевым сервером с помощью DECO, Prover одновременно участвует в интерактивном протоколе с Верификатор. Этот протокол позволяет проверяющему доказать проверяющему, что он получил данный фрагмент данных D с сервера во время его текущего сеанса. Испытатель может в качестве альтернативы предоставьте проверяющему доказательство с нулевым разглашением некоторого свойства D и, таким образом, не раскрывать D напрямую. При типичном использовании DECO пользователь или отдельный узел может экспортировать данные D из частного сеанс с веб-сервером для всех узлов в DON. В результате полный DON может подтвердить подлинность D (или факта, полученного из D посредством доказательства с нулевым разглашением). В дополнение к примерам приложений, приведенным далее в статье, эта возможность может быть реализована. используется для усиления доступа к источнику данных с высокой степенью целостности с помощью DON. Даже если только один узел имеет прямой доступ к источнику данных — например, благодаря эксклюзивному соглашению с поставщиком данных — для всего DON остается возможность подтвердить правильностьотчеты, отправленные этим узлом. Town Crier полагается на использование доверенной среды выполнения (TEE), такой как Intel. СГХ. Коротко говоря, TEE функционирует как своего рода «черный ящик», который выполняет приложения в защищенный от несанкционированного доступа и конфиденциальный способ. В принципе, даже владелец хоста, на котором запущенный TEE не может ни (необнаружимо) изменить приложение, защищенное TEE, ни просмотреть состояние приложения, которое может включать секретные данные. Town Crier может реализовать все функции DECO и многое другое. DECO ограничивает взаимодействие Доказывающего с одним Верификатором. Напротив, Town Crier позволяет Доказывающее устройство для создания публично проверяемого доказательства на основе данных D, полученных с целевого сервера, то есть доказательство, которое любой, даже smart contract, может проверить напрямую. Городской глашатай может также безопасно получать и использовать секреты (например, учетные данные пользователя). Основным ограничением Town Crier является его зависимость от TEE. Производственные ТЭО имеют недавно было показано, что он имеет ряд серьезных уязвимостей, хотя технология находится в зачаточном состоянии и, несомненно, созреет. См. Приложения B.2.1 и B.2.2. дальнейшее обсуждение TEE. Несколько примеров применения DECO и Town Crier см. в разделах 4.3, 4.5. и 9.4.3 и Приложение C.1. 3.6.3 Существующие внутрисетевые Chainlink сервисы Сети Chainlink oracle предоставляют ряд основных услуг на множестве blockchains и другие децентрализованные системы сегодня. Дальнейшая эволюция, как описано в этом документе наделит существующие службы дополнительными возможностями и достичь. Три примера: Фиды данных: Сегодня большинство пользователей Chainlink, использующих smart contract, делают использование каналов данных. Это отчеты о текущей стоимости ключевых фрагментов данных в соответствии с авторитетным оффчейн источникам. Например, каналы цен — это каналы, сообщающие цены. активов — криптовалюты, сырьевые товары, форекс, индексы, акции и т. д. — согласно услуги обмена или агрегирования данных. Такие каналы сегодня уже помогают защитить миллиарды долларов внутрисетевой стоимости за счет их использования в системах DeFi, таких как Aave [147] и Синтетикс [208]. Другие примеры фидов данных Chainlink включают данные о погоде для параметрическое страхование урожая [75] и данные выборов [93], среди ряда других. Развертывание DONs и других технологий, описанных в этом документе, улучшит предоставление потоков данных в сетях Chainlink во многих отношениях, в том числе: • Масштабирование: OCR, а затем DONs, направлены на обеспечение возможности масштабирования сервисов Chainlink. существенно во многих blockchain, которые они поддерживают. Например, мы ожидаем что DONs поможет увеличить количество каналов данных, предоставляемых узлами с помощью Chainlink от 100 до 1000 и выше. Такое масштабирование поможет Chainlink экосистема достигает своей цели по предоставлению данных, имеющих отношение к smart contracts, в комплексном виде, одновременно удовлетворяя и предвидя существующие и будущие потребности.• Повышенная безопасность: сохраняя промежуточные отчеты, DONs сохраняет записи. поведения узлов для высокоточного мониторинга и измерения их производительности и точности, что обеспечивает прочное эмпирическое обоснование систем репутации. для узлов Chainlink. FSS и TEF позволят включать ценовые потоки с данными транзакций гибкими способами, которые предотвращают такие атаки, как опережающие действия. (Явное) staking укрепит существующую криптоэкономическую защиту безопасности. каналов данных. • Гибкость подачи данных: как blockchain-агностические системы (в более широком смысле, потребительско-независимые системы), DON могут облегчить предоставление потоков данных множеству доверяющих систем. Один DON может одновременно отправить данный канал в набор различных blockchain, что устраняет необходимость в сетях oracle для каждой цепочки и обеспечивая быстрое развертывание существующих каналов на новых blockchain и дополнительных каналы через обслуживаемые в настоящее время blockchain. • Конфиденциальность: возможность выполнять обобщенные вычисления в DON позволяет выполнять вычисления с конфиденциальными данными вне цепочки, избегая внутрицепных операций. экспозиция. Кроме того, используя DECO или Town Crier, можно добиться еще более строгая конфиденциальность, позволяющая создавать отчеты на основе данных, которые не доступен даже узлам DON. См. примеры в разделах 4.3 и 4.5. Верифицируемые случайные функции (VRF): Некоторым типам DApps требуется проверяемый источник случайных данных, чтобы обеспечить возможность проверки их собственной честной работы. Примером могут служить невзаимозаменяемые токены (NFTs). Редкость NFT функций в Aavegotchi [23] и Axie Infinity [35] определяется Chainlink VRF, как и распределение NFTs посредством розыгрышей билетов на Ether Cards [102]; широкий выбор игровые DApps, результаты которых рандомизированы; и нетрадиционные финансовые инструменты, например, сберегательные игры без потерь, такие как PoolTogether [89], в которых средства распределяются между случайные победители. Другие приложения blockchain и не blockchain также требуют безопасного источники случайности, включая выбор комитетов децентрализованной системы и проведение лотерей. Хотя блок hashes может служить источником непредсказуемой случайности, он уязвим для манипуляций со стороны состязательных майнеров (и в некоторой степени со стороны пользователей, отправляющих транзакции). Chainlink VRF [78] предлагает значительно более безопасную альтернативу. Ан oracle имеет связанную пару частного/открытого ключей (sk, pk), личный ключ которой хранится в автономном режиме, а открытый ключ pk публикуется. Чтобы вывести случайное значение, необходимо применяет sk к непредсказуемому начальному числу x, предоставленному зависимым контрактом (например, блоку hash и параметры, специфичные для DApp) с помощью функции F, что дает y = Fsk(x) вместе с доказательство правильности. (Информацию о VRF, доступном на Chainlink, см. в [180].) Что делает Верифицируемым VRF является тот факт, что, зная pk, можно проверить правильность доказательства и, следовательно, y. Следовательно, значение y непредсказуемо для злоумышленник, который не может предсказать x или изучить sk, и сервису невозможно манипулировать им.Chainlink VRF можно рассматривать как всего лишь одно из семейства приложений, предполагающих хранение закрытых ключей вне цепочки. В более общем плане DONs могут предлагать безопасные, децентрализованное хранение индивидуальных ключей для приложений и/или пользователей и объединение эту возможность с помощью обобщенных вычислений. Результатом является множество приложений, некоторые примеры которых мы приводим в этой статье, включая управление ключами для доказательства Резервы (см. раздел 4.1) и децентрализованные учетные данные пользователей (и другие цифровые активы) (см. раздел 4.3). Хранители: Chainlink Keepers [87] позволяют разработчикам писать код для децентрализованных выполнение заданий вне цепочки, как правило, для запуска выполнения зависимых __PH_0003__s. До появления Keepers разработчики обычно использовали такие офчейн-серверы. логику, создавая централизованные точки отказа (а также значительное дублирование усилий по разработке). Вместо этого Keepers предоставляют простую в использовании структуру для децентрализованный аутсорсинг этих операций, что позволяет сократить циклы разработки и надежная гарантия жизнеспособности и других свойств безопасности. Хранители могут поддержать любого широкого спектра триггерных целей, включая ценозависимую ликвидацию кредитов или выполнение финансовых транзакций, зависящее от времени инициирование аирдропов или платежей в системах с уборкой урожая и т.д. В рамках DON инициаторов можно рассматривать как обобщение Хранителей в нескольких смыслах. Инициаторы могут использовать адаптеры и, таким образом, могут использовать модульная библиотека интерфейсов к ончейн и оффчейн системам, позволяющая быстро разработка безопасного, сложного функционала. Инициаторы инициируют вычисления в исполняемые файлы, которые сами по себе предлагают полную универсальность DON, позволяя широко спектр децентрализованных услуг, которые мы представляем в этой статье для приложений внутри и снаружи сети. 3.6.4 Репутация узла / История производительности Существующая экосистема Chainlink изначально документирует историю производительности содействующие узлы в цепи. Эта функция привела к созданию коллекции ресурсов, ориентированных на репутацию, которые собирают, фильтруют и визуализируют данные о производительности отдельных пользователей. операторы узлов и каналы данных. Пользователи могут ссылаться на эти ресурсы, чтобы получать информацию. решения по выбору узлов и мониторингу работы существующих сетей. Подобные возможности помогут пользователям выбрать DONs. Например, сегодня открытые торговые площадки, такие как market.link, позволяют узлу операторы перечислить свои услуги oracle и подтвердить свою личность вне сети через такие сервисы, как Keybase [4], которые привязывают профиль узла в Chainlink к его существующие доменные имена владельца и учетные записи в социальных сетях. Кроме того, производительность инструменты аналитики, например, доступные на сайтах market.link и Reputation.link, позволяют пользователи могут просматривать статистику исторической производительности отдельных узлов, включая их средняя задержка ответа, отклонение значений в их отчетах от консенсусных значений передается по цепочке, генерируется доход, выполняются рабочие места и многое другое. Эти аналитические инструменты также позволяют пользователям отслеживать принятие различных сетей oracle другими пользователями, это форманеявное одобрение узлов, обеспечивающих безопасность таких сетей. В результате получается плоская «паутина доверия», в котором, используя определенные узлы, ценные децентрализованные приложения создают сигнал их доверия к тем узлам, которые другие пользователи могут наблюдать и учитывать в своих собственные решения по выбору узла. С появлением DONs (и первоначально с OCR) произошел сдвиг в обработке транзакций и контрактная деятельность в более общем смысле оффчейн. Децентрализованная модель узла записи производительность остается возможной внутри самого DON. Действительно, высокая производительность и емкость данных DONs позволяют создавать записи в мелкозернистом виде. способ, а также выполнять децентрализованные вычисления над этими записями, получая достоверные сводные данные, которые могут использоваться службами репутации и проверяться на контрольных точках. ГЛАВНАЯ ЦЕПЬ. Хотя в принципе DON может искажать поведение составляющих узлов, если большая часть узлов повреждена, мы отмечаем, что коллектив производительность самого DON при доставке данных в цепочке видна на MAINCHAIN и поэтому не может быть искажено. Кроме того, мы планируем изучить механизмы, которые стимулировать точные внутренние отчеты о поведении узлов в DON. Например, сообщая о подмножестве высокопроизводительных узлов, которые быстрее всего возвращают данные, способствующие в отчете, передаваемом по цепочке, DON создает стимул для узлов оспаривать неправильные отчеты: неправильное включение узлов в это подмножество означает неправильное исключение узлов это должно было быть включено и, следовательно, неправомерно наказывать их. Повторные неудачные отчеты со стороны DON также создадут стимул для честных узлов покинуть сеть. DON. Децентрализованное составление точных историй производительности и последующее способность пользователей определять высокопроизводительные узлы, а операторам узлов создавать Репутация — важная отличительная черта экосистемы Chainlink. Мы покажите в разделе 9, как мы можем рассуждать о них как о ключевом элементе строгого и расширенный взгляд на экономическую безопасность, обеспечиваемую DONs.

Децентрализованные услуги, предоставляемые децентрализованными

Сети Oracle Чтобы проиллюстрировать универсальность DON и то, как они обеспечивают множество новых сервисов, в этом разделе мы представляем пять примеров приложений на основе DON и описываем гибридные контракты, которые их реализуют: (1) «Доказательство резервов», форма межсетевого сервиса; (2) Взаимодействие с корпоративными/устаревшими системами, то есть создание промежуточного программного обеспечения. уровень абстракции, который облегчает разработку приложений blockchain с минимальными затратами. blockchain — конкретный код или специализация; (3) Децентрализованная идентификация, инструменты, позволяющие пользователям получать и управлять своими собственными документами, удостоверяющими личность и учетными данными; (4) Приоритетные каналы, сервис, который обеспечивает своевременное включение транзакций критической инфраструктуры (например, oracle отчеты) на blockchain; и (5) сохраняющий конфиденциальность DeFi, то есть финансовый smart contracts, которые скрывают конфиденциальные данные участвующих сторон. Здесь мы

используйте SC для обозначения части MAINCHAIN гибридного контракта и опишите DON компонент отдельно или в виде исполняемого файла exec. 4.1 Доказательство резервов Для многих приложений полезно передавать состояние между или между blockchain. А Популярное применение таких сервисов — накрутка криптовалют. Завернутые монеты такие поскольку WBTC [15] становятся популярным активом в децентрализованных финансах (DeFi). Они включает размещение «завернутого» резервного актива в его источнике blockchain MAINCHAIN(1) и создание соответствующего token в другом целевом объекте blockchain MAINCHAIN(2). Например, WBTC — это ERC20 token на Ethereum blockchain, который соответствует в BTC на Bitcoin blockchain. Поскольку контракты на MAINCHAIN(2) не имеют прямой видимости в MAINCHAIN(1), они должны явно или неявно полагаться на oracle, чтобы сообщать об отложениях обернутых актив в smart contract, создавая то, что иногда называют доказательством резервов. В Например, WBTC [15], хранитель BitGo хранит BTC и выпускает WBTC с Сеть Chainlink, предоставляющая доказательства резерва [76]. DON сам по себе может предоставить подтверждение резервов. Однако с DON это возможно. идти дальше. DON может управлять секретами и, используя соответствующие адаптеры, может совершать транзакции по любому желаемому blockchain. Следовательно, DON может действовать в качестве одного из множества хранителей — или даже как единственного децентрализованного хранителя — для завернутый актив. Таким образом, DON могут служить платформой для повышения безопасности существующие сервисы, использующие доказательства резервов. Например, предположим, что MAINCHAIN(1) — это Bitcoin, а MAINCHAIN(2) — Ethereum. В MAINCHAIN(2) контрактный SC выдает token, представляющие упакованные BTC. DON управляет адресом BTC addr(1) DON. Чтобы обернуть BTC, пользователь U отправляет X BTC из адрес(1) ты в адрес(1) DON вместе с адресом MAINCHAIN(2) addr(2) У. Мониторы DON адрес(1) DON через адаптер к MAINCHAIN(1). При наблюдении месторождения U, с достаточно высокой вероятностью подтверждения, он отправляет сообщение в SC через адаптер на ГЛАВНАЯ ЦЕПЬ(2). Это сообщение инструктирует SC создать X tokens для addr(2). У. Чтобы U выпустил X PH_0006__s, происходит обратное. Однако в MAINCHAIN(1) адрес(1) DON отправляет X BTC на адрес(1) U (или на другой адрес, если этого требует пользователь). Эти протоколы можно адаптировать, конечно, для работы с биржами, а не напрямую. с пользователями. 4.2 Взаимодействие с корпоративными/устаревшими системами DON могут служить мостами между blockchain, как в примере Доказательства. резервов, но другая цель состоит в том, чтобы они действовали как двунаправленные мосты между blockchains и устаревшие системы [176] или blockchain, такие как центральный банк цифровые валюты [30]. Предприятия сталкиваются с рядом проблем при подключении существующих систем и процессов в децентрализованные системы, включая:• Гибкость блокчейна. Системы блокчейна быстро меняются. Предприятие может столкнуться с быстрым появлением или ростом популярности blockchain, на которых контрагенты желают совершить операции, но для которых у предприятия нет поддержка существующей инфраструктуры. В целом, динамичность blockchains делает отдельным предприятиям трудно оставаться в курсе всей экосистемы. • Ресурсы для разработки, специфичные для блокчейна. Для многих организаций наем или развитие передовых blockchain специалистов является затруднительным, особенно с учетом вызов ловкости. • Управление закрытыми ключами. Управление закрытыми ключами для blockchain или криптовалют требует операционного опыта, отличного от опыта традиционной кибербезопасности. практики и недоступны для многих предприятий. • Конфиденциальность: предприятия опасаются раскрывать свою конфиденциальную и частную информацию. данные по цепочке. Чтобы решить первые три из этих трудностей, разработчики могут просто использовать DON в качестве безопасного промежуточного уровня, позволяющего корпоративным системам читать или записывать данные. blockchainс. DON может абстрагироваться от детальных технических соображений, таких как газовая динамика, реорганизация цепочки и т.д., как для разработчиков, так и для пользователей. Автор представляя оптимизированный интерфейс blockchain для корпоративных систем, DON может, таким образом, значительно упростить разработку корпоративных приложений, поддерживающих blockchain, снимая с предприятий нагрузку по приобретению или инкубированию ресурсов разработки, специфичных для blockchain. Такое использование DONs особенно привлекательно, поскольку оно позволяет корпоративным разработчикам создавать приложения со смарт-контрактами, которые в значительной степени не зависят от blockchain. В результате больше набор blockchain, для которых DON используется в качестве промежуточного программного обеспечения, увеличить набор blockchain, к которым корпоративные пользователи могут получить легкий доступ. Разработчики может переносить приложения с существующих blockchain на новые с минимальными модификациями. к своим собственным разработанным приложениям. Чтобы решить дополнительную проблему конфиденциальности, разработчики могут обратиться к инструменты, которые мы представляем в этой статье и планируем использовать для поддержки приложений DON. К ним относятся раздел 3.6.2 DECO и Town Crier, а также правила сохранения конфиденциальности. Модификации API, обсуждаемые в разделе 7.1.2, а также ряд подходов для конкретных приложений, описанных в оставшейся части этого раздела. Эти DON системы могут обеспечить высоконадежные онлайн-аттестации состояния корпоративной системы без раскрытия конфиденциальные исходные данные предприятия в цепочке. 4.3 Децентрализованная идентичность Децентрализованная идентификация — это общий термин, обозначающий идею о том, что пользователи должны иметь возможность получать и управлять своими собственными учетными данными, а не полагаться на третьих лиц так. Децентрализованные учетные данные — это подтверждения атрибутов или утверждений владельца.которые часто называют претензиями. Учетные данные подписываются цифровой подписью субъектами, часто называемыми эмитенты, которые могут авторитетно связывать претензии с пользователями. В большинстве предлагаемых схем претензии связаны с децентрализованным идентификатором (DID), универсальным идентификатором для данного пользователя. Учетные данные привязаны к открытому ключу, закрытый ключ которого имеет пользователь. Таким образом, пользователь может доказать владение заявкой, используя свой закрытый ключ. Какими бы дальновидными ни была децентрализованная идентичность, существующие и предлагаемые схемы, например, [14, 92, 129, 216], имеют три серьезных ограничения: • Отсутствие совместимости с предыдущими версиями. Существующие децентрализованные системы идентификации полагаются на сообщество органов власти, называемых эмитентами, для создания учетных данных DID. Потому что существующие веб-сервисы обычно не подписывают данные цифровой подписью, эмитенты должны быть запущены как системы специального назначения. Потому что нет стимула делать это без В результате экосистемы децентрализованной идентификации возникает проблема курицы и яйца. В другом Другими словами, неясно, как запустить экосистему эмитента. • Неработоспособное управление ключами. Децентрализованные системы идентификации требуют от пользователей управлять закрытыми ключами, как показал опыт работы с криптовалютой быть непосильным бременем. По оценкам, около 4 000 000 __PH_0005 были потеряны навсегда из-за сбоев управления ключами [194], и многие пользователи сохраняют свои криптоактивы с биржами [193], тем самым подрывая децентрализацию. • Отсутствие защиты от Сивиллы, обеспечивающей сохранение конфиденциальности. Основное требование безопасности таких приложений, как голосование, справедливое распределение token во время продаж token и т. д., заключается в том, что пользователи не смогут подтвердить несколько удостоверений личности. Существующие предложения по децентрализованной идентификации требуют от пользователей раскрытия своей реальной личности для достижения такой цели. Сопротивление Сивиллы, тем самым подрывая важные гарантии конфиденциальности. Эти проблемы можно решить, используя комбинацию комитета узлов. выполнение распределенных вычислений внутри DON и использование таких инструментов, как DECO или Town Crier, как показано в системе под названием CanDID [160]. DECO или Town Crier могут по замыслу превратить существующие веб-сервисы без изменений. на эмитентов учетных данных, сохраняющих конфиденциальность. Они позволяют DON экспортировать соответствующие данные для этой цели в учетные данные, скрывая при этом конфиденциальные данные, которые не должны появляются в учетных данных. Кроме того, чтобы облегчить восстановление ключей для пользователей, тем самым решая проблему управления ключами. Проблема, DON может позволить пользователям хранить закрытые ключи в секретной форме. Пользователи могут восстановить свои ключи, доказав узлам в DON — аналогично, используя Town Crier или DECO — возможность входа в учетные записи с набором заранее определенных веб-провайдеров (например, Твиттер, Гугл, Фейсбук). Преимущество использования Town Crier или DECO по сравнению с OAUTH — это конфиденциальность пользователя. Эти два инструмента позволяют пользователю избежать раскрытия информации DON. идентификатор веб-провайдера, из которого часто можно получить реальные идентификаторы. Наконец, чтобы обеспечить сопротивление Сивилле, как показано в [160], DON может выполнить преобразование уникальных реальных идентификаторов пользователей с сохранением конфиденциальности (например, номера социального страхования (SSN)) в идентификаторы в цепочке при регистрации пользователя.Таким образом, система может обнаруживать дублирующиеся регистрации без конфиденциальных данных, таких как SSN раскрываются отдельным узлам DON.7 DON может предоставлять любые из этих услуг от имени внешнего децентрализованного удостоверения. системы на защищенных или разрешенных blockchain, например, экземпляры Hyperledger Инди [129]. Пример приложения: KYC: Децентрализованная идентичность обещает стать средством оптимизировать требования к финансовым приложениям на blockchains, одновременно улучшая конфиденциальность. Две проблемы, которые он может помочь решить, — это обязательства по аккредитации и соблюдению требований в соответствии с правилами борьбы с отмыванием денег и правилами «знай своего клиента» (AML / KYC). Правила ПОД во многих странах требуют, чтобы финансовые учреждения (и другие предприятия) устанавливали и проверяли личности физических и юридических лиц, с которыми они совершают транзакции. KYC является одним из компонентов системы финансового учреждения. более широкая политика ПОД, которая, как правило, также включает в себя, среди прочего, мониторинг поведения пользователей и наблюдение за потоками средств. KYC обычно предполагает предоставление пользователю учетных данных в той или иной форме (например, вход в онлайн-форму, поднесение документа, удостоверяющего личность, перед лицом пользователя в видеосеансе и т. д.). Безопасное создание и представление децентрализованных учетных данных в принципе может быть выгодной альтернативой в нескольких отношениях, а именно: (1) Создание процесс KYC более эффективен для пользователей и финансовых учреждений, поскольку однажды если сертификат получен, его можно беспрепятственно представить в любое финансовое учреждение; (2) Сокращение мошенничества за счет уменьшения возможностей кражи личных данных путем компрометации. информации, позволяющей установить личность (PII), и подделки во время видеоверификации; и (3) Снижение риска компрометации личных данных в финансовых учреждениях, поскольку пользователи сохраняют контроль. своих собственных данных. Учитывая многомиллиардные штрафы, выплачиваемые финансовыми учреждениями за несоблюдение требований AML, а также то, что многие финансовые учреждения ежегодно тратят миллионы долларов на KYC, улучшения могут принести значительную экономию для финансовых учреждений. и, как следствие, для потребителей [196]. В то время как традиционный финансовый сектор работает медленно Чтобы внедрить новые инструменты обеспечения соответствия, DeFi системы все чаще используют их [43]. Пример применения: Кредиты с недостаточным обеспечением: Большинство DeFi приложений, которые Поддержка кредитования сегодня вытекает только из полностью обеспеченных кредитов. Это кредиты, выданные заемщикам, которые вносят криптовалютные активы, стоимость которых превышает стоимость кредитов. Недавно возник интерес к тому, что сообщество DeFi обычно называет кредитами с недостаточным обеспечением. Это, напротив, кредиты, по которым соответствующее обеспечение имеет стоимость, меньшую, чем основная сумма кредита. Недообеспеченные кредиты напоминают кредиты, часто предоставляемые традиционными финансовыми учреждениями. Вместо того, чтобы полагаться на внесенном залоге в качестве гарантии погашения кредита они вместо этого основывают кредитование решения по кредитным историям заемщиков. 7Это преобразование основано на распределенной псевдослучайной функции (PRF).Кредиты с недостаточным обеспечением представляют собой зарождающуюся, но растущую часть кредитного рынка DeFi. Они полагаются на механизмы, подобные тем, которые используются в традиционных финансовых системах. учреждения, такие как юридические контракты [91]. Обязательное условие для их роста. будет возможность предоставлять данные о кредитоспособности пользователей — ключевом факторе при принятии традиционных решений о кредитовании — в системы DeFi таким образом, чтобы обеспечить надежную целостность, т. е. гарантия корректности данных. Децентрализованная система идентификации с поддержкой DON позволит потенциальным заемщикам генерировать надежные учетные данные, подтверждающие их кредитоспособность, сохраняя при этом конфиденциальность чувствительной информации. В частности, заемщики могут создавать такие учетные данные, основанные на записях из авторитетных онлайн-источников, раскрывая при этом только данные, подтвержденные DON, без раскрытия других потенциально конфиденциальных данных. Для Например, заемщик может создать учетные данные, указывающие, что ее кредитный рейтинг с набора кредитных бюро превышает определенный порог (например, 750), не раскрывая ее точный счет или любые другие данные в ее записях. Кроме того, при желании такие учетные данные может быть сгенерировано анонимно, т. е. имя пользователя можно рассматривать как конфиденциальные данные и сам не доступен узлам oracle или ее децентрализованным учетным данным. Полномочия сам по себе может использоваться как в цепочке, так и в автономном режиме, в зависимости от приложения. Таким образом, заемщик может предоставить кредиторам важную информацию о своем кредите. истории с высокой достоверностью и без риска раскрытия ненужных, чувствительных данные. Заемщик также может предоставить ряд других документов, подтверждающих конфиденциальность. помогает принимать решения о кредитовании. Например, учетные данные могут подтвердить личность заемщика. владение активами (вне сети), как мы покажем в нашем следующем примере. Пример заявки: Аккредитация: Многие юрисдикции ограничивают класс инвесторов, которым могут быть проданы незарегистрированные ценные бумаги. Например, в США SEC Положение D предусматривает, что для получения аккредитации для таких инвестиционных возможностей необходимо человек должен обладать собственным капиталом в 1 миллион долларов, соответствовать определенным требованиям к минимальному доходу или иметь определенную профессиональную квалификацию [209, 210]. Текущая аккредитация процессы являются громоздкими и неэффективными, часто требующими аттестационного письма от бухгалтера или аналогичные доказательства. Децентрализованная система идентификации позволит пользователям генерировать учетные данные из существующие учетные записи онлайн-финансовых услуг, подтверждающие соответствие аккредитации нормативных актов, что способствует более эффективному и сохраняющему конфиденциальность процессу KYC.

Более того, свойства DECO и Town Crier, сохраняющие конфиденциальность, позволят этим учетные данные должны генерироваться с надежной гарантией целостности без прямого раскрытия подробностей финансового статуса пользователя. Например, пользователь может создать учетные данные доказав, что ее собственный капитал составляет не менее 1 миллиона долларов, не раскрывая никаких дополнительных сведений. информация о ее финансовом положении. 4.4 Приоритетные каналы Приоритетные каналы — это новый полезный сервис, который легко создать с помощью DON. Их

Цель состоит в том, чтобы своевременно доставлять избранные высокоприоритетные транзакции на MAINCHAIN. в периоды перегрузки сети. Приоритетные каналы можно рассматривать как форму фьючерсный контракт на пространстве блоков и, следовательно, как криптотовар, термин, придуманный как часть проекта «Чикаго» [61, 136]. Приоритетные каналы предназначены специально для майнеров для включения инфраструктурных сервисов, таких как oracle, функции управления контрактами и т. д., а не для обычных действий на уровне пользователя, таких как финансовые транзакции. Фактически, как задумано здесь, приоритетом канал, реализованный менее чем на 100% мощности майнинга в сети, может только обеспечить свободные ограничения на сроки доставки, предотвращая их использование для сильно зависящих от скорости такие цели, как опережение. Рисунок 10. Приоритетный канал — это гарантия майнера M или, в более общем смысле, набор майнеров M — пользователю U, что ее транзакция τ будет добыта в блоках D включения в мемпул. Контрактный SC может использовать мониторинг DON для обеспечения соблюдения условия обслуживания канала. Приоритетный канал принимает форму соглашения между майнером или группой майнеров. (или пулы майнинга) M, предоставляющий канал, и пользователь U, который платит комиссию за доступ. M согласен, что когда U отправляет транзакцию τ в мемпул (с любой ценой на газ,но заранее согласованный лимит газа), M поместит его в цепочку в следующих блоках D.8 Схематически идея изображена на рис. 10. Описание контракта приоритетного канала: Приоритетный канал может быть реализован как гибрид smart contract примерно следующим образом. Обозначим через SC логику в MAINCHAIN. и это на DON от exec. СК принимает депозит/долю \(d from M and an advance payment \)p от U.A. DON исполняемый файл exec контролирует мемпул, срабатывая при размещении транзакции пользователем U. Он отправляет сообщение об успехе в SC, если U отправляет транзакцию, которую M майнит в своевременный способ и сообщение об ошибке в случае сбоя службы. SC отправляет платеж $p в адрес M, получив сообщение об успехе, и отправляет все оставшиеся средства. включая $d, в U, если он получает сообщение об ошибке. В случае успешного завершения освобождает депозит $d М. Майнер М, конечно, может предоставлять приоритетные каналы одновременно нескольким пользователей и может открыть приоритетный канал с U для заранее оговоренного количества сообщений. 4,5 Сохранение конфиденциальности DeFi / Mixicles Сегодня приложения DeFi [1] практически не обеспечивают конфиденциальности для пользователей: все транзакции видны в цепочке. Различные подходы с нулевым разглашением, например, [149, 217], может обеспечить конфиденциальность транзакций, и TEF достаточно универсален, чтобы их поддерживать. Но эти подходы не являются всеобъемлющими и, например, обычно не скрывают актив, на котором основана сделка. Широкий набор вычислительных инструментов, которые мы в конечном итоге намерены поддерживать в DONs, будет обеспечить конфиденциальность различными способами, которые могут устранить такие пробелы, помогая дополнить гарантии конфиденциальности других систем. Например, Mixicles, инструмент сохранения конфиденциальности DeFi, предложенный исследователями Chainlink лаборатории [135], может скрывать тип актива, поддерживающего финансовый инструмент, и очень естественно вписывается в DON рамки. Миксикли легче всего объяснить с точки зрения их использования для реализации простого двоичного кода. вариант. Бинарный опцион — это финансовый инструмент, в котором два пользователя, которых мы будем см. здесь для согласованности с [135] в качестве игроков, сделайте ставку на событие с двумя возможными результаты, например, превысит ли актив целевую цену в заранее назначенное время или нет. Следующий пример иллюстрирует эту идею. Пример 2. Алиса и Боб являются участниками бинарного опциона, основанного на стоимости актива. называется «Пузырь Кэрол» (CBT). Алиса делает ставку на то, что рыночная цена CBT составит минимум 250 долларов США во время Т = полдень 21 июня 2025 года; Боб делает ставку на обратное. Каждый игрок вносит 100 ETH в заранее оговоренный срок. Игрок с выигрышной позицией получает 200 ETH (т. е. получает 100 ETH). 8D, конечно, должен быть достаточно большим, чтобы гарантировать, что M может соответствовать с высокой вероятностью. Для Например, если M контролирует 20% мощности майнинга в сети, он может выбрать D = 100, гарантируя вероятность отказа ≈2 × 10−10, т. е. менее одного на миллиард.Учитывая существующую сеть Chainlink oracle O, легко реализовать интеллектуальную контракт SC, который реализует соглашение в примере 2. Каждый из двух игроков вносит депозит 100 ETH в СЦ. Через некоторое время после T запрос q отправляется в O с запросом цены r CBT в момент времени T.O отправляет отчет об этой цене в SC. Затем SC отправляет деньги Алисе. если r ≥250, и Боб, если нет. Однако этот подход раскрывает r в цепочке, что упрощает задачу чтобы наблюдатель мог определить актив, лежащий в основе бинарного опциона. В терминологии Mixicles полезно концептуально подумать о результате. SC в терминах коммутатора, который передает двоичное значение, вычисленное как предикат переключатель (р). В нашем примере переключатель(r) = 0, если r ≥250; учитывая такой результат, Алиса побеждает. В противном случае switch(r) = 1, и Боб выигрывает. DON может реализовать базовый Mixicle как гибридный контракт, запустив исполняемый файл. exec, который вычисляет переключатель (r) и передает его по цепочке в SC. Мы показываем эту конструкцию на рис. 11. Рисунок 11: Схема базового Mixicle в примере 2. Чтобы обеспечить внутрисетевую секретность для отчет r и, следовательно, актив, лежащий в основе бинарного опциона, oracle отправляет в заключить контракт SC через переключатель Switch только двоичного значения (r). В Приложении C.3 мы указываем адаптер ConfSwitch, который позволяет легко добиться этого. гол в DON. Основная идея ConfSwitch довольно проста. Вместо того, чтобы отчитываться значение r, ConfSwitch сообщает только значение двоичного переключателя switch(r). СК может быть предназначен для осуществления правильного платежа только на основе переключателя (r) и отдельного переключателя (r) не раскрывает никакой информации о базовом активе — в нашем примере CBT. Кроме того, поместив зашифрованный текст в (q, r) в реестре, зашифрованном с помощью pkaud, открытого ключа В качестве аудитора адаптер ConfSwitch создает контрольный журнал, сохраняющий конфиденциальность. Базовый Mixicle, который мы выбрали для простоты описания, скрывает только актив и ставка на бинарный опцион в нашем примере. Полноценный Mixicle [135] может обеспечить две формы конфиденциальности. Оно скрывает от наблюдателей: (1) Какое событие произошло игроки делают ставки (т. е. на q и r), но также (2) какой игрок выиграл ставку. Поскольку Mixicles выполняются на MAINCHAIN, любому игроку потребуется ретранслировать переключите(r) с DON на MAINCHAIN, иначе можно создать исполняемый файл exec, который

запускается на выходе ConfSwitch и вызывает другой адаптер для отправки переключателя (r) в ГЛАВНАЯ ЦЕПЬ. Стоит также рассмотреть третий, тонкий тип конфиденциальности. В базовой реализации ConfSwitch O запускает адаптер на DON и таким образом изучает актив — в нашем примере CBT — и, следовательно, природу бинарного опциона. Как обсуждалось в Приложении C.3, однако, дополнительно можно использовать DECO или Town Crier для скрыть даже эту информацию от О. В этом случае О больше не узнает никакой информации. чем общественный наблюдатель ВС. Для получения более подробной информации о Mixicles мы отсылаем читателей по адресу [135].

Услуги честного секвенирования

Одна важная услуга, которую, как мы ожидаем, будут предлагать DONs, которая использует их сетевые, вычислительные и запоминающие возможности, называется Fair Sequencing Services (FSS). Хотя FSS можно рассматривать просто как приложение, реализованное в рамках DON, мы выделяем его как услугу, которая, по нашему мнению, будет пользоваться большим спросом во всем мире. blockchains, и мы ожидаем, что сеть Chainlink будет активно поддерживать. При выполнении в общедоступных сетях blockchain многие из современных приложений DeFi раскрывать информацию, которая может быть использована пользователями в своих целях, аналогично виды инсайдерских утечек и возможностей манипулирования, которые широко распространены в существующих рынки [64, 155]. Вместо этого FSS прокладывает путь к справедливой DeFi экосистеме. ФСС помогает разработчикам создавать DeFi контракты, защищенные от манипулирования рынком в результате утечки информации. Учитывая проблемы, которые мы подчеркиваем ниже, ФСС особенно привлекателен для услуг уровня 2 и вписывается в структуру таких услуг. которые мы обсуждаем в разделе 6. Задача: В существующих системах без разрешений транзакции полностью упорядочены. на усмотрение майнеров. В разрешенных сетях узлы validator могут оказывать та же самая сила. Это форма в значительной степени непризнанной эфемерной централизации в в противном случае децентрализованные системы. Майнер может (временно) подвергать цензуре транзакции для своих собственную выгоду [171] или переупорядочить их, чтобы максимизировать собственную выгоду. Это понятие называется извлекаемой ценностью (MEV) [90]. Термин MEV немного обманчив: он не относится к только для того, чтобы оценить то, что могут захватить майнеры: некоторые MEV могут быть захвачены обычными пользователями. Однако, поскольку майнеры обладают большей властью, чем обычные пользователи, MEV представляет собой верхнюю границу суммы ценности, которую любой субъект может получить посредством состязательного переупорядочения. и вставка дополнительных транзакций. Даже когда майнеры просто заказывают транзакции на основе платы (газ), без манипуляций, пользователи сами могут манипулировать ценами на газ чтобы получить преимущество своих транзакций перед менее сложными. Даян и др. [90] документировать и количественно определять способы, которыми боты (не майнеры) получают преимущество газовой динамики в способе, который вредит пользователям систем DeFi сегодня и как MEV даже угрожает стабильности базового уровня консенсуса в blockchain. Регулярно появляются и другие примеры манипулирования порядками транзакций, например, [50, 154].Новые методы обработки транзакций, такие как rollups, являются очень многообещающим подходом. к проблемам масштабирования высокопроизводительных blockchains. Однако они не затрагивают проблема МЭВ. Вместо этого они передают его сущности, которая генерирует rollup. Это объект, будь то оператор smart contract или пользователь, предоставляющий (zk-)rollup доказательство действительности, имеет право упорядочивать и вставлять транзакции. Другими словами, rollups замените MEV на REV: извлекаемая ценность. MEV влияет на предстоящие транзакции, отправленные в мемпул. но еще не зафиксированы в цепочке. Информация о таких сделках широко распространена. доступен в сети. Майнеры, validators и обычные участники сети могут поэтому используйте эти знания и создавайте зависимые транзакции. Кроме того, майнеры и validator могут влиять на порядок тех транзакций, которые они совершают. себя и использовать это в своих интересах. Проблема неправомерного влияния лидеров на порядок транзакций в условиях консенсуса протоколы известны в литературе с 1990-х годов [71, 190], но удовлетворительных результатов не получили. решения реализованы на практике на данный момент [97]. Основная причина заключается в том, что предлагаемые решения – по крайней мере, до недавнего времени – не могут быть легко интегрированы в общественную систему. blockchains, поскольку они полагаются на то, что содержимое транзакций остается секретным до тех пор, пока их порядок определен. Обзор услуг честного секвенирования (FSS): DONs предоставит инструменты для децентрализации порядка транзакций и реализации его в соответствии с политикой, указанной проверяющей организацией. создатель контракта, в идеале справедливый и не приносящий выгоды субъектам, желающим манипулировать порядком транзакций. В совокупности эти инструменты составляют FSS. ФСС включает в себя три компонента. Первое – это мониторинг транзакций. В ФСС, oracle узлы в O контролируют мемпул MAINCHAIN и (при желании) разрешают внесетевое представление транзакций через специализированный канал. Второе — это последовательность транзакций. Узлы в транзакциях порядка O для зависимого контракта в соответствии с политикой, определенной для этого контракта. Третий — проводка транзакций. После того, как транзакции упорядочены, узлы в O совместно отправляют транзакции в основная цепь. Потенциальные преимущества FSS включают в себя: • Справедливость заказов: FSS включает инструменты, помогающие разработчикам гарантировать, что транзакции входные данные для конкретного контракта упорядочены таким образом, чтобы не создавать несправедливых преимущество для хорошо обеспеченных ресурсами и/или технически подкованных пользователей. Политика заказа для этой цели можно указать. • Сокращение или устранение утечек информации: гарантируя, что участники сети не смогут использовать знания о предстоящих транзакциях, FSS может уменьшить или устранить такие атаки, как опережение, основанные на информации, доступной в сети до совершения транзакций. Предотвращение эксплуатации таких утечка гарантирует, что состязательные транзакции, которые зависят от исходных ожидающих транзакции не могут попасть в реестр до того, как будут зафиксированы исходные транзакции.• Снижение транзакционных издержек: устранение потребности игроков в скорости отправки свои транзакции на smart contract, FSS может значительно снизить стоимость обработки транзакций. • Порядок приоритетов: FSS может автоматически придавать критическим транзакциям особый приоритет. заказ. Например, чтобы предотвратить быстрые атаки на oracle. отчеты, например [79], FSS может вставить отчет oracle в поток транзакций задним числом. Основная цель FSS в DONs – предоставить авторам DeFi возможность реализовывать справедливые финансовые системы, то есть системы, которые не приносят пользы конкретным пользователям (или майнерам) над другими на основе скорости, инсайдерских знаний или способности выполнять технические манипуляция. Хотя четкое общее представление о справедливости является неуловимым, а идеальная справедливость в любой разумный смысл недостижим, FSS стремится предоставить разработчикам мощную набор инструментов, позволяющих применять политики, помогающие достичь целей проектирования DeFi. Мы отмечаем, что, хотя основная цель FSS — выступать в качестве справедливой службы секвенирования для ГЛАВНАЯ ЦЕПЬ, на которую нацелен DON, некоторые из тех же требований справедливости, что и FSS гарантии также могут быть подходящими для (децентрализованных) протоколов, которые выполняются между DON вечеринки. Таким образом, FSS можно рассматривать в более широком смысле как услугу, предоставляемую подмножеством узлов DON для справедливой последовательности не только транзакций, отправленных пользователями MAINCHAIN но также транзакции (т. е. сообщения), совместно используемые другими узлами DON. В этом разделе мы сосредоточимся в первую очередь на цели упорядочения транзакций MAINCHAIN. Организация раздела: В разделе 5.1 мы описываем два приложения высокого уровня, которые мотивируют разработку FSS: предотвращение предварительного запуска отчетов oracle и предотвращение опережающее выполнение пользовательских транзакций. Затем мы предоставим более подробную информацию о конструкции FSS. в разделе 5.2. В разделе 5.3 описаны примеры справедливых гарантий и средств заказа. чтобы достичь их. Наконец, в разделах 5.4 и 5.5 обсуждаются угрозы сетевого уровня для такие политики и средства их решения, соответственно, для сетевого флуда и Сибиллы. атаки. 5.1 Проблема опережающего движения Чтобы объяснить цели и структуру FSS, мы опишем две общие формы опережающего развития. атаки и ограничения существующих решений. Опережающее движение иллюстрирует класс атак с упорядочиванием транзакций: существует ряд связанных атак, таких как обратное выполнение и сэндвичирование (переднее и обратное выполнение) [237], которые мы не рассматриваем. здесь, но в решении которых также помогает ФСС. 5.1.1 Oracle на опережение Выполняя свою традиционную роль по предоставлению данных вне сети приложениям blockchain, oracles стать естественной мишенью для лобовых атак.Рассмотрим распространенный шаблон проектирования с использованием oracle для предоставления различных ценовых каналов. на внутрисетевую биржу: периодически (скажем, каждый час) oracle собирает данные о ценах на различные активы и отправляет их на контракт обмена. Эти транзакции ценовых данных представляют очевидные возможности арбитража: например, если в новейшем отчете oracle указаны гораздо более высокую цену за какой-либо актив, злоумышленник может заранее подготовить отчет oracle, чтобы скупайте активы и немедленно перепродавайте их после обработки отчета oracle. Лежачие полицейские и ретроактивное ценообразование: Естественным решением проблемы опережающего выполнения oracle является предоставление отчетам oracle особого приоритета над другими транзакциями. Для Например, отчеты oracle могут отправляться с высокой комиссией, чтобы побудить майнеров обрабатывать они в первую очередь. Но это не помешает опережению, если арбитражные возможности высоки. и при этом он не может предотвратить арбитраж со стороны самих майнеров. Поэтому некоторые биржи прибегли к внедрению более тяжелых «лежачих полицейских», таких как постановка пользовательских транзакций в очередь для нескольких блоков перед обработкой. их или задним числом корректировать цены при поступлении нового отчета oracle. Недостатками этих решений являются то, что они усложняют реализацию обмена, увеличивают требования к хранению и, следовательно, транзакционные издержки, а также нарушают работу пользователей, поскольку обмен активами подтверждается только по истечении значительного периода времени. Совмещение: Прежде чем перейти к FSS, мы обсудим контрейлерную перевозку, довольно простой и элегантное решение проблемы опережения oracle. Не применимо к адресу однако в других сценариях он опережает других. Короче говоря, вместо периодической отправки отчетов в ончейн-контракт, oracles публиковать подписанные отчеты, которые пользователи добавляют к своим транзакциям при покупке или продаже внутрисетевые активы. Затем биржа просто проверяет, что отчет действителен и актуален. (например, oracle может подписывать диапазон блоков, для которых отчет действителен) и извлекает соответствующая цена будет получена из него. Этот простой подход имеет ряд преимуществ перед вышеописанным «лежачим полицейским». подход: (1) Биржевой контракт не должен сохранять состояние ценовых потоков, которые должны привести к снижению транзакционных издержек; (2) Поскольку отчеты oracle публикуются в цепочке по мере необходимости, oracle могут генерировать более частые обновления (например, каждую минуту), тем самым минимизация арбитражных возможностей при предварительном составлении отчета9; (3) Транзакции могут быть проверены немедленно, поскольку они всегда включают в себя свежий поток цен. Однако этот подход не идеален. Во-первых, это комбинационное решение ставит обязанность пользователей биржи получать актуальные oracle отчеты и прикреплять их к своим транзакции. Во-вторых, хотя использование контрейлерных услуг сводит к минимуму арбитражные возможности, оно не может полностью предотвратить их, не влияя на работоспособность ончейн-контракта. Действительно, если Отчет oracle действителен до некоторого блока номер n, после чего транзакция отправляется в блокировку. n + 1 потребует нового действительного отчета. Из-за присущих задержек в распространении сообщает пользователям oracles, новый отчет, действительный для блока n + 1, будет иметь 9Арбитраж имеет смысл только в том случае, если используемая разница в ценах на активы превышает внешнюю разницу. комиссии, необходимые для покупки и продажи активов, например, взимаемые майнерами и биржей.быть опубликованным за какой-то период до того, как будет добыт блок n + 1, скажем, в блоке n -k, тем самым создание последовательности из k блоков, в которой существует краткосрочная возможность арбитража. Мы теперь опишите, как FSS обходит эти ограничения. Приоритизация отчетов oracle с помощью FSS: FSS может решить проблему oracle с опережением проблемы, опираясь на вышеупомянутое комбинационное решение, но добавляя дополнительные работа по дополнению транзакций отчетами oracle в децентрализованной сети Oracle. На высоком уровне узлы oracle собирают транзакции, предназначенные для внутрисетевого обмена. согласовать поток цен в реальном времени и опубликовать этот поток вместе с собранными транзакциями в контракте основной цепи. Концептуально этот подход можно рассматривать как «пакетная обработка транзакций с дополненными данными», где oracle гарантирует, что актуальная Ценовой поток всегда добавляется к транзакциям. Решения FSS могут быть реализованы прозрачно для пользователей биржи и с минимальные изменения в логике контракта, как мы описываем более подробно в разделе 5.2. Обеспечение свежие отчеты oracle всегда имеют приоритет над транзакциями пользователей — это лишь один пример политики заказов, которую FSS может принять и обеспечить соблюдение. Политика ФСБ по обеспечению порядка более общее описание справедливости представлено в разделе 5.3. 5.1.2 Оперативные пользовательские транзакции Теперь мы обратимся к опережающему запуску в общих приложениях, где описанный выше метод защиты не работает. В общих чертах проблему можно охватить с помощью следующего сценария: Злоумышленник видит некоторую пользовательскую транзакцию tx1, отправленную в сеть P2P, и внедряет свою собственную состязательную транзакцию tx2, так что tx2 обрабатывается до tx1 (например, путем оплаты более высокая комиссия за транзакцию). Например, такой вид опережения распространен среди боты, которые используют возможности арбитража в DeFi системах [90] и затронули пользователей различные децентрализованные приложения [101]. Установление справедливого порядка среди транзакций обработка на blockchain решает эту проблему. Более фундаментально, просмотр деталей tx1 иногда даже не нужен. знание о его простом существовании может позволить противнику опередить tx1 через свой завладеть tx2 и обмануть невиновного пользователя, создавшего tx1. Например, пользователь может известно, что он регулярно торгует определенным активом. Для предотвращения подобных атак необходимо меры по смягчению последствий, которые также позволяют избежать утечки метаданных [62]. Некоторые решения этой проблемы существуют, но они приводят к задержкам и проблемам с удобством использования. От сетевого заказа к окончательному заказу с FSS: Возможности для продвижения вперед возникают потому, что существующие системы не имеют механизмов, гарантирующих соблюдение порядка, в котором транзакции появляются в цепочке, соблюдая порядок событий и поток информации вне сети. Это представляет собой проблему, возникающую из-за недостатков в реализации приложений (например, торговых платформ) на blockchain. В идеале можно было бы убедитесь, что транзакции фиксируются на blockchain в том же порядке, в котором они были создается и отправляется в P2P-сеть blockchain. Но поскольку сеть blockchain

распределен, такой порядок не может быть зафиксирован. Поэтому ФСС вводит механизмы для защиты от нарушений справедливости, которые возникают только из-за распределенного природа сети blockchain. 5.2 Детали ФСС Рисунок 12: Мемпул ярмарки заказов с двумя разными путями транзакций: прямой и на основе мемпула. На рис. 12 представлена ​​общая схема ФСС. Для обеспечения справедливости DON, предоставляющий FSS, должен вмешиваться в поток транзакций при их входе в MAINCHAIN. Могут потребоваться корректировки клиентов, smart contract в MAINCHAIN ​​или того и другого. На высоком уровне обработку транзакций ФСС можно разбить на три этапы, описанные ниже: (1) Мониторинг транзакций; (2) Последовательность транзакций; и (3) Проводка транзакции. В зависимости от метода упорядочивания, используемого для упорядочивания транзакций, необходимы дополнительные шаги протокола, как описано в следующем разделе. 5.2.1 Обработка транзакций Мониторинг транзакций: Мы видим два разных подхода к мониторингу ФСС. пользовательские транзакции, предназначенные для конкретного smart contract, прямые и на основе мемпула: • Прямой: Прямой подход концептуально самый простой, но требует изменений в пользовательских клиентов, чтобы транзакции отправлялись непосредственно в децентрализованный Oracleузлам сети, а не узлам основной цепи. DON собирает пользовательские транзакции, предназначенные для конкретного smart contract SC, и упорядочивает их на основе о какой-то политике заказа. Затем DON отправляет заказанные транзакции в smart contract в основной цепочке. Некоторые механизмы упорядочивания также требуют прямого подхода, поскольку пользователь, создающий транзакцию, должен криптографически защитите его перед отправкой в ФСС. • На основе мемпула: для облегчения интеграции FSS с устаревшими клиентами, DON может использовать Mempool Services (MS) для мониторинга мемпула основной цепочки и сбора транзакции. Прямая передача, вероятно, будет предпочтительной реализацией для многих контрактов. и мы считаем, что во многих случаях это должно быть достаточно практично. Мы кратко обсудим, как существующие DApps могут быть минимально модифицированы для поддержки прямая передача, сохраняя при этом хороший пользовательский опыт. Описываем подходы используя Ethereum и MetaMask [6], поскольку на сегодняшний день это наиболее популярный выбор, но упомянутые методы должны распространяться на другие сети и кошельки. Недавний Ethereum Предложение по улучшению, «EIP-3085: Кошелек добавляет метод цепочки RPC Ethereum» [100], упростит выбор пользовательских цепочек Ethereum (с использованием идентификатора CHAIN ID, отличного от MAINCHAIN для предотвращения повторных атак) из MetaMask и других браузерных кошельков. После реализации этого предложения децентрализованное приложение, стремящееся использовать DON просто добавили бы один вызов метода в свой интерфейс, чтобы иметь возможность напрямую передавать транзакции к любому DON, предоставляющему API-интерфейс, совместимый с Ethereum. Тем временем, «EIP-712: Ethereum типизированные структурированные данные hash и подписание» [49] обеспечивает небольшое более сложная, но уже широко распространенная альтернатива, где пользователь DApp может использовать MetaMask для подписи структурированных данных, определяющих транзакцию DON. DApp может отправлять эти подписанные структурированные данные в DON. Наконец, отметим, что возможны и гибридные подходы. Например, наследие клиенты могут продолжать отправлять транзакции в мемпул основной цепочки, но это критично. транзакции (например, отчеты oracle) отправляются непосредственно на узлы DON (в частности, набор узлов, предоставляющих oracle отчеты, такие как обновления цен, и набор узлов обеспечение FSS может перекрываться или быть идентичным). Последовательность транзакций: Основная цель FSS — гарантировать, что пользовательские транзакции упорядочиваются в соответствии с заранее определенной политикой. Характер этой политики будет зависят от потребностей приложения и типов несправедливых транзакций, которые оно стремится предотвратить. Поскольку FSS на DON способен обрабатывать данные и поддерживать локальное состояние, они могут навязать произвольную политику последовательности, основанную на информации, которая доступен по адресу oracles. Конкретные политики заказа и их реализация обсуждаются далее в разделе 5.3.Проводка транзакции: После сбора и упорядочения пользовательских транзакций, полученных либо напрямую от пользователей, либо собранных из мемпула, DON отправляет эти транзакции в основную цепочку. Таким образом, взаимодействие DON с основной цепью остается подчиняется (потенциально несправедливому) упорядочению транзакций, регулируемому майнерами основной цепи. Чтобы воспользоваться преимуществами децентрализованного заказа транзакций, целевой умный Таким образом, контракт SC должен быть разработан так, чтобы относиться к DON как к «первосортному» гражданину. Мы выделяют два подхода: • Контракты только для DON: Самый простой вариант дизайна — сделать основную цепочку умной. контракт SC принимает только транзакции, обработанные DON. Это гарантирует, что smart contract обрабатывает транзакции в порядке, предложенном DON, но де-факто ограничивает smart contract работой в системе, основанной на комитетах (т. е. комитет DON теперь имеет постоянные полномочия определять упорядочивание и включение транзакций). • Контракты двойного класса. Предпочтительный, более детализированный дизайн предполагает умную основную цепочку. контракт SC принимает транзакции, исходящие как от DON, так и от устаревшего пользователей10, но создает традиционные «лежачие полицейские» для транзакций, которые не были обработаны DON. Например, транзакции из DON могут обрабатываться немедленно, тогда как устаревшие транзакции «буферизируются» smart contract для фиксированный период времени. Другие стандартные механизмы предотвращения опережающего движения такие как схемы фиксации-раскрытия или VDF [53], также могут быть применены к устаревшим транзакции. Это гарантирует, что транзакции, заказанные по DON, будут обработаны в приказ согласован, не давая DON нежелательной власти цензуры транзакции. Поскольку введение порядка транзакций со стороны FSS требует, чтобы транзакции агрегировались «вне цепочки», это решение естественным образом сочетается с другими методами агрегации, которые направлены на снижение затрат на обработку в цепочке. Например, после сбора и заказывая транзакции, DON может отправлять эти транзакции в основную цепочку как одна «пакетная транзакция» (например, rollup), тем самым уменьшая совокупную транзакцию плата. Обеспечение выполнения порядка транзакции: Независимо от того, используется ли только DON или двухклассовая конструкция, основная цепочка smart contract SC и DON должны быть разработаны совместно, чтобы гарантировать соблюдение порядка транзакций DON. Здесь мы также представляем себе разные варианты дизайна: • Порядковые номера: DON может добавлять порядковый номер к каждой транзакции и отправлять эти транзакции в мемпул основной цепочки. Главный 10Если мониторинг транзакций DON основан на мемпуле, устаревшие транзакции должны отличаться от транзакций DON, чтобы они не собирались DON, например, с помощью специального тега. встроено в транзакцию или путем указания конкретной цены на газ, например. В DON транзакциях есть газ цены ниже определенного порога.цепочка smart contract SC игнорирует транзакции, поступающие «вне очереди». Мы обратите внимание, что в этом случае майнеры основной цепи могут решить игнорировать DON упорядочивание транзакций, что приводит к сбою транзакций. Сохраняя (дорогое) состояние SC можно обеспечить правильный порядок транзакций, в некоторой степени аналогично тому, как TCP буферизует неупорядоченные пакеты до тех пор, пока недостающие пакеты не будут устранены. получил. • Транзакция nonces: для многих blockchain, и в частности для Ethereum, Приведенный выше подход к последовательной нумерации может использовать встроенную транзакцию nonces для обеспечить, чтобы основной блокчейн smart contract SC обрабатывал транзакции последовательно. Здесь узлы DON отправляют транзакции в основную цепочку через одну учетную запись основной цепочки, защищенную ключом, общим для узлов DON. Счет Транзакция nonce гарантирует, что транзакции будут обнаружены и обработаны в правильном порядке. • Объединение транзакций: DON может объединять несколько транзакций в rollup. (или в комплекте, похожем на rollup). Основная цепь smart contract должна быть предназначен для обработки таких совокупных транзакций. • Агрегированные транзакции с прокси-сервером основной цепочки. Здесь DON аналогичным образом объединяет транзакции в одну «метатранзакцию» для основной цепочки, но полагается на собственный прокси smart contract для распаковки транзакций и ретрансляции их в целевой контракт СК. Этот метод может быть полезен для совместимости с устаревшими версиями. Метатранзакции действуют как rollup, но отличаются тем, что состоят из несжатого список транзакций, опубликованных один раз в основной цепочке. Преимущество последней конструкции заключается в беспрепятственной поддержке пользовательских транзакций, которые сами проксируются через контракт основной цепи до достижения цели DON договор СК. Например, рассмотрим пользователя, который отправляет транзакцию на некоторый кошелек. контракт, который, в свою очередь, отправляет внутреннюю транзакцию в SC. Назначение последовательности номер такой транзакции будет сложным, если только контракт кошелька пользователя не специально разработан для пересылки порядкового номера с каждой внутренней транзакцией в СК. Аналогичным образом, такие внутренние транзакции нелегко объединить в метатранзакцию, которая отправляется непосредственно в SC. Мы обсуждаем дальнейшие соображения по проектированию такие прокси-транзакции ниже. 5.2.2 Атомарность транзакции До сих пор в нашем обсуждении неявно предполагалось, что транзакции взаимодействуют с одним внутрисетевой smart contract (например, пользователь отправляет запрос на покупку на биржу). Тем не менее, в в таких системах, как Ethereum, одна транзакция может состоять из нескольких внутренних транзакций, например, одна smart contract вызывает функцию в другом контракте. Ниже мы описать две стратегии высокого уровня для упорядочения «многоконтрактных» транзакций, в то время как сохранение атомарности транзакции (т.е. последовательности действий, предписанной все транзакции выполняются в правильном порядке или не выполняются вообще).Сильная атомарность: Самым простым решением является применение FSS, как описано выше, непосредственно ко всем «мультиконтрактным» сделкам. То есть пользователи отправляют свои транзакции в сеть, а FSS отслеживает, упорядочивает и отправляет эти транзакции в основная цепь. Этот подход технически прост, но имеет одно потенциальное ограничение: если пользователь транзакция взаимодействует с двумя контрактами SC1 и SC2, оба из которых хотят использовать справедливое услуг по упорядочению, то политика последовательности этих двух контрактов должна быть согласованной. То есть, учитывая две разные транзакции tx1 и tx2, каждая из которых взаимодействует с как для SC1, так и для SC2, не должно быть так, чтобы политика SC1 заказывала tx1 раньше tx2. тогда как политика SC2 предписывает противоположный порядок. Мы предполагаем, что для подавляющего большинства представляющих интерес сценариев политика последовательности, принятая в разных контрактах, будет последовательной. Например, и SC1, и SC2. может потребоваться, чтобы транзакции были упорядочены по приблизительному времени их прибытия в мемпул, и SC1 может также захотеть, чтобы определенные отчеты oracle всегда доставлялись первыми. Как последние транзакции отчета oracle не взаимодействуют с SC2, политики согласованы. Слабая атомарность: В полной мере FSS может применяться на уровне отдельных лиц. внутренние транзакции. Рассмотрим транзакции вида tx = { ˜txpre, ˜txSC, ˜txpost}, состоящие из некоторых начальных транзакция(и) ˜txpre, которая приводит к внутренней транзакции ˜txSC к SC, которая, в свою очередь, выдает внутреннюю транзакцию(и) ˜txpost. Политика секвенирования SC может определять, как внутренняя транзакция ˜txSC должна быть упорядочена относительно других отправленных транзакций в SC, но оставьте открытым порядок последовательности для ˜txpre и ˜txpost. Учитывая особенности обработки транзакций в таких системах, как Ethereum, разработка службы упорядочения, предназначенной для конкретных внутренних транзакций, является непростой задачей. При наличии специально разработанного контракта СК это может быть реализовано следующим образом: 1. Транзакция отправляется в сеть и обрабатывается (без какой-либо последовательности). в исполнении ФСС). Начальный ˜txpre выполняется и вызывает ˜txSC. 2. SC не выполняет ˜txSC и завершает работу. 3. FSS отслеживает внутренние транзакции в SC, определяет их последовательность и отправляет обратно. в SC (т. е. путем отправки транзакций ˜txSC непосредственно в SC). 4. SC обрабатывает транзакции ˜txSC, полученные от FSS, и выдает внутренние транзакции ˜txpost, которые являются результатом ˜txSC. При таком подходе транзакции не выполняются полностью атомарно (т. е. исходный транзакция tx разбивается на несколько транзакций в цепочке), но порядок внутренние транзакции сохраняются. Это решение влечет за собой ряд конструктивных ограничений. Например, ˜txpre не может предположим, что ˜txSC и ˜txpost будут выполнены. Более того, СК должен быть спроектирован таким образом, чтобы выполнять транзакции ˜txSC и ˜txpost от имени определенного пользователя, даже если они былиотправлено ФСС. По этим причинам более грубое решение «Сильная атомарность» выше, вероятно, предпочтительнее на практике. Для соблюдения более сложных зависимостей, включающих несколько транзакций и их соответствующие внутренние транзакции, планировщик транзакций FSS может содержать сложные функции, напоминающие те, которые можно найти в менеджерах транзакций реляционных систем. менеджеры баз данных. 5.3 Честная последовательность транзакций Здесь мы обсуждаем два понятия справедливости для последовательности транзакций и соответствующие реализации, которые могут быть реализованы FSS: справедливость заказов, основанная на политике налагаемые ФСС, и надежное сохранение причинно-следственной связи, что требует дополнительных криптографических методов в ФСС. Порядок-справедливость: Справедливость порядка — это понятие временной справедливости в протоколах консенсуса. это впервые было формально введено Келкаром и соавт. [144]. Келкар и др. целью достижения такой формы естественной политики, при которой транзакции упорядочены в зависимости от времени их первого получения DON (или P2P-сетью, в случае FSS на основе мемпула). Однако в децентрализованной системе все по-другому. узлы могут видеть, что транзакции приходят в другом порядке. Наведение общего порядка по всем транзакциям — это та самая проблема, которую решает протокол консенсуса, лежащий в основе ГЛАВНАЯ ЦЕПЬ. Келкар и др. [144] поэтому введем более слабое понятие, которое можно достигается с помощью децентрализованной сети Oracle, называемой «справедливостью порядка блоков». Он группирует транзакции, которые DON получил за определенный интервал времени, в «блокировать» и вставлять все транзакции блока одновременно и в одну и ту же позицию. (т. е. высоту) в MAINCHAIN. Таким образом, они упорядочены вместе и должны быть исполняемыми. параллельно, не создавая между ними никаких конфликтов. Грубо говоря, справедливость порядка утверждает, что если большая часть узлов видит транзакцию τ1 до τ2, то τ1 будет упорядочен перед τ2 или в том же блоке, что и τ2. Навязывая такую грубую Благодаря детализации порядка транзакций возможности опережающего выполнения и других атак, связанных с порядком, значительно сокращаются. Келкар и др. предложить семейство протоколов под названием Aequitas [144], которые адресуют различные модели развертывания, включая синхронные, частично синхронные и асинхронные сетевые настройки. Протоколы Aequitas накладывают значительные коммуникационные издержки по сравнению с базовым консенсусом BFT и поэтому не идеальны для практического использования. Однако мы считаем, что появятся практические варианты Aequitas, которые можно будет использовать. для упорядочения транзакций в FSS и других приложениях. Некоторые связанные схемы имеют уже были предложены, которые имеют меньше сопутствующего формализма и более слабые свойства, например, [36, 151, 236], но лучшая практическая производительность. Эти схемы могут поддерживаться в ФСС тоже. Также стоит отметить, что термин «справедливость» встречается и в другом месте в blockchain. литература с другим смыслом, а именно: справедливость в смысле возможности длямайнеров пропорционально выделенным им ресурсам [106, 181] или за validators в терминах равных возможностей [153]. Надежное сохранение причинно-следственной связи: Наиболее широко известный подход к предотвращению опережающего запуска и других нарушений порядка на распределенных платформах основан на криптографическом подходе. техники. Их общая особенность — скрывать сами данные транзакции, ожидая, пока порядок на уровне консенсуса был установлен и раскрыть данные транзакции позже для обработки. Это сохраняет причинно-следственную связь между транзакциями, которые выполнен blockchain. Соответствующие понятия безопасности и криптографические протоколы. были разработаны значительно до появления blockchains [71, 190]. Условия безопасности «входной причинности» [190] и «надежного сохранения причинности» [71, 97] формально требуют, чтобы никакая информация о транзакции не стала известна. до того, как будет определено положение этой транзакции в глобальном порядке. До этого момента противник не должен иметь возможности вывести какую-либо информацию в криптографическом виде. сильное чувство. Можно выделить четыре криптографических метода сохранения причинности: • Протоколы фиксации-раскрытия [29, 142, 145]: вместо объявления транзакции в открытом виде передается только криптографическое обязательство по транзакции. После заказа всех зафиксированных, но скрытых транзакций (в начале blockchain системах на самой MAINCHAIN, но здесь с помощью FSS), отправитель должен открыть коммит и раскрыть данные транзакции в течение заранее определенного интервала времени. Затем сеть проверяет, что открытие соответствует предыдущему обязательству. Истоки этого метода датируются до появления blockchains. Хотя этот подход особенно прост, он имеет значительные недостатки, и его нелегко использовать по двум причинам. Во-первых, поскольку на уровне протокола заказа существует только обязательство, семантика транзакции не могут быть подтверждены в ходе консенсуса. Дополнительный выезд к клиенту требуется. Однако более серьезно оценивается возможность того, что никакое отверстие не может когда-либо прибудут, что может быть равносильно атаке типа «отказ в обслуживании». Кроме того, это трудно определить, действительно ли открытие допустимо в последовательном, распределенном таким образом, потому что все участники должны договориться о том, прибыло ли открытие в время. • Протоколы фиксации-раскрытия с отложенным восстановлением [145]: одна проблема с Подход «фиксация-раскрытие» заключается в том, что клиент может совершить спекулятивную транзакцию и раскрыть ее позже только в том случае, если последующие транзакции сделают ее прибыльной. А недавний вариант подхода «фиксация-раскрытие» повышает устойчивость к этому своего рода неправильное поведение. В частности, протокол TEX [145] решает эту проблему. использование умного подхода, при котором зашифрованные транзакции включают ключ дешифрования можно получить путем вычисления проверяемой функции задержки (VDF) [53, 221]. Если клиент не сможет своевременно расшифровать свою транзакцию, другие в системе будут расшифровывать это от ее имени, решив криптографическую головоломку средней сложности.• Пороговое шифрование [71, 190]: этот метод использует то, что DON может выполнять порогово-криптографические операции. Предположим, что FSS поддерживает общедоступное шифрование. key pkO и oracles используют между собой соответствующий закрытый ключ. Затем клиенты шифруют транзакции под PkO и отправляют их в FSS. Приказы ФСС транзакции на DON, затем расшифровывает их и, наконец, внедряет в MAINCHAIN в фиксированном порядке. Таким образом, шифрование гарантирует, что упорядочение не на основе содержания транзакции, а на том, что сами данные доступны, когда необходимо. Этот метод был первоначально предложен Рейтером и Бирманом [190] и позже усовершенствован Качином и др. [71], где он был интегрирован с разрешенным консенсусом протокол. В более поздних работах изучалось использование пороговой криптографии в качестве механизм уровня консенсуса для общих сообщений [33, 97] и для общих вычислений с общими данными [41]. По сравнению с протоколами фиксации-раскрытия пороговое шифрование предотвращает простые атаки типа «отказ в обслуживании» (хотя требуется осторожность, учитывая вычислительные затраты на расшифровку). Это позволяет DON двигаться автономно, на своей скорости и без ждем дальнейших действий клиента. Транзакции могут быть подтверждены сразу после их расшифровки. Более того, клиенты шифруют все транзакции одним ключ для DON, и схема связи остается такой же, как и для других транзакции. Безопасное управление пороговым ключом и смена узлов в Однако О может создать дополнительные трудности. • Обязательный обмен секретом [97]: вместо шифрования данных транзакции в ключ, хранящийся в DON, клиент также может секретно передать его узлам в O. Используя гибридную, вычислительно безопасную схему совместного использования секретов, транзакция сначала шифруется с использованием симметричного шифра со случайным ключом. Распространяется только соответствующий симметричный ключ, а зашифрованный текст передается в DON. Клиент должен отправить одну долю ключа каждому узлу в O, используя отдельно зашифрованное сообщение. Остальные шаги протокола такие же, как и для порогового значения. шифрование, за исключением того, что данные транзакции расшифровываются с помощью симметричного алгоритм после восстановления ключа каждой транзакции из его долей. Этот метод не требует настройки или управления криптосистемой с открытым ключом. связанный с DON. Однако клиенты должны знать об узлах в O и общаться в безопасном контексте с каждым из них, что ставит дополнительная нагрузка на клиентов. Хотя криптографические методы обеспечивают полную защиту от информации просачиваясь из отправленных транзакций в сеть, они не скрывают метаданные. Для например, IP-адрес или Ethereum адрес отправителя по-прежнему может использоваться противник для выполнения опережающих и других атак. Различные улучшения конфиденциальности методы, развернутые на сетевом уровне, например, [52, 95, 107] или на уровне транзакций, например, [13, 65] потребуются для достижения этой цели. Влияние конкретного произведения метаданных, а именно, на какой контракт отправляется транзакция, можно (частично) скрытьпутем мультиплексирования множества контрактов на одном и том же DON. Криптографическое сокрытие транзакций сами по себе также не предотвращает приоритезацию транзакций поврежденными DON узлов в сговоре с отправителями транзакций. Надежная причинно-следственная связь, гарантированная криптографическими протоколами, дополняет гарантии справедливости порядка для любой политики, и мы намерены изучить комбинацию этих двух. методы, где это возможно. Если противник не может получить существенное преимущество от наблюдая метаданные, безопасные протоколы сохранения причинно-следственной связи могут использоваться наряду с также наивный подход к упорядочению. Например, узлы oracle могут записывать транзакции. в L, как только они их получат, без дублирования. Тогда транзакции будут упорядочены по их появлению на L и впоследствии расшифрованы. Мы также планируем рассмотреть возможность использования TEE как способа обеспечения справедливого порядка; для Например, Тессеракт [44] можно рассматривать как достижение формы причинного упорядочения, но один усилена способностью TEE обрабатывать транзакции в явной форме, в то время как сохраняя свою конфиденциальность. 5.4 Вопросы сетевого уровня До сих пор наше описание FSS в основном фокусировалось на проблеме обеспечения соблюдения того, что Окончательный порядок транзакций соответствует их наблюдаемому порядку в сети. В дальнейшем мы рассматриваем проблемы справедливости, которые могут возникнуть на самом сетевом уровне. Высокочастотные трейдеры на обычных электронных торговых площадках вкладывают значительные средства ресурсы для получения превосходной скорости сети [64], а трейдеры на криптовалютных биржах демонстрируют аналогичное поведение [90]. Скорость сети дает преимущество как в наблюдение за сделками других сторон и представление конкурирующих сделок. Одним из средств, примененных на практике и популяризированных в книге Flash Boys [155], является «лежачий полицейский», впервые представленный на бирже IEX [128], а затем и на других обменивает [179] (со смешанными результатами [19]). Этот механизм налагает задержку (350 микросекунд в IEX) на доступ к рынку с целью нейтрализации преимуществ в скорость. Эмпирические данные, например [128], подтверждает свою эффективность в сокращении определенных торговых операций. затраты для обычных инвесторов. FSS можно использовать просто для реализации асимметричного «лежачий полицейский» — тот, который задерживает входящие транзакции. Будиш, Крамтон и Шим [64] утверждают, что использование преимуществ скорости неизбежно на рынках с непрерывным временем, и приводят доводы в пользу структурного решения проблемы Форма рынков, основанных на пакетных аукционах. Но этот подход не получил широкого распространения на существующих торговых площадках. Обычные торговые системы централизованы и обычно принимают транзакции через одно сетевое соединение. В децентрализованной системе, напротив, можно наблюдать за распространением транзакций с нескольких точек зрения. Следовательно, в P2P-сети можно наблюдать такое поведение, как переполнение сети. Мы намерены изучить подходы к FSS на сетевом уровне, которые помогают разработчикам определять политику запрещая такое нежелательное поведение сети.5,5 Политика справедливости на уровне организации Справедливость порядка и надежная причинность направлены на обеспечение порядка в транзакциях, которые уважает время, когда они были созданы и впервые представлены в сети. Ограничением этого понятия справедливости является то, что оно не предотвращает нападения, в которых противник получает преимущество, наводняя систему множеством транзакций, стратегия, наблюдаемая в дикой природе как способ эффективного отслеживания транзакций в token продажах [159] и создать перегрузку, приводящую к ликвидации обеспеченных долговых позиций (CDP) [48]. Другими словами, справедливость порядка обеспечивает справедливость в отношении транзакций, а не игроков. Как показано в системе CanDID [160], можно использовать инструменты oracle, такие как DECO. или Town Crier в сочетании с комитетом узлов (например, DON) для достижения различные формы сопротивления Сивилле при сохранении конфиденциальности. Пользователи могут регистрировать личности и предоставить доказательства их уникальности, не раскрывая самих личностей. Учетные данные, устойчивые к Сивилле, предлагают возможный подход к усовершенствованию порядка транзакций. политики таким образом, чтобы ограничить возможности для наводнений. Например, Продажа token может разрешать только одну транзакцию для зарегистрированного пользователя, если регистрация требуется подтверждение уникальности национального идентификатора, например номера социального страхования. Такой подход не является надежным, но может оказаться полезной политикой для смягчения атак с перенасыщением транзакциями.

DON Платформа выполнения транзакций

(DON-TEF) DONs обеспечит oracle и поддержку децентрализованных ресурсов для решений уровня 2 в рамках то, что мы называем децентрализованной структурой выполнения сетевых транзакций Oracle (DONTEF) или сокращенно TEF. Сегодня частота обновлений контрактов DeFi ограничена задержками основной цепи. например, средний интервал блока 10–15 секунд в Ethereum [104], а также стоимость передача больших объемов данных по цепочке и ограниченная пропускная способность вычислений/передачи — мотивирующие подходы масштабирования, такие как сегментирование [148, 158, 232] и выполнение уровня 2 [5, 12, 121, 141, 169, 186, 187]. Даже blockchain с гораздо более быстрым временем транзакции, например, [120], предложили стратегии масштабирования, включающие вычисления вне цепочки [168]. TEF предназначен для работы в качестве ресурса уровня 2 для любых таких систем уровня 1/MAINCHAIN. Используя TEF, DONs могут поддерживать более быстрые обновления в контракте MAINCHAIN, в то время как сохранение ключевых гарантий доверия, предоставляемых основной цепочкой. ТЭФ может поддержать любой из множества методов и парадигм выполнения уровня 2, включая rollups,11 оптимистичные rollups, Validium и т. д., а также модель порогового доверия, в которой DON узлы выполняют транзакции. TEF дополняет FSS и предназначен для его поддержки. Другими словами, любой приложение, работающее в TEF, может использовать FSS. 11Именно их часто называют «zk-rollups», это неправильное название, поскольку они не обязательно требуют доказательств с нулевым разглашением.

6.1 Обзор ТЭФ TEF — это шаблон проектирования для создания и реализации высокопроизводительного гибрида. smart contract СК. В соответствии с основной идеей гибридных smart contracts, TEF включает в себя разложение SC на две части: (1) То, что мы называем в контексте TEF якорем контракт SCa на MAINCHAIN и (2) логика DON предполагает, что мы вызываем исполняемый файл TEF. Мы используем здесь SC для обозначения логического контракта, реализуемого комбинацией SCa и ожидать. (Как отмечалось выше, мы планируем разработать инструменты компиляции для декомпозиции автоматически контракт SC на эти компоненты.) Исполняемый файл TEF exect — это механизм, обрабатывающий транзакции пользователей в SC. Это может выполняться высокопроизводительно, поскольку он работает на DON. Он имеет несколько функций: • Прием транзакций: exect получает или извлекает транзакции пользователей. Он может это сделать напрямую, т. е. посредством отправки транзакции на DON или через MAINCHAIN. мемпул с использованием MS. • Быстрое выполнение транзакций: exect обрабатывает транзакции с активами внутри СК. Это происходит локально, т. е. на DON. • Быстрый и недорогой доступ к oracle / адаптеру: exect имеет встроенный доступ к отчетам oracle. и другие данные адаптера, что приводит, например, к более быстрому, дешевому и точному активу. цены, чем исполнение MAINCHAIN. Более того, доступ к oracle вне сети снижает эксплуатационные расходы oracle и, следовательно, стоимость использования системы, избегая дорогое on-chain хранилище. • Синхронизация: exect периодически отправляет обновления из DON в MAINCHAIN, обновляя SCa. Якорный контракт — это передняя часть SC MAINCHAIN. Будучи компонентом SC с более высоким уровнем доверия, он служит нескольким целям: • Хранение активов: средства пользователей вносятся, хранятся и выводятся из SCa. • Проверка синхронизации: SCa может проверять правильность обновлений состояния при необходимости. синхронизируется, например, SNARK, прикрепленные к rollup. • Ограждения: SCa может включать положения по защите от коррупции или сбоев. в искл. (Более подробную информацию см. в разделе 7.) В TEF средства пользователей хранятся на MAINCHAIN, то есть DON сам по себе не является хранителем. В зависимости от выбора механизма синхронизации (см. ниже) пользователям может потребоваться доверять DON только для точных отчетов oracle и своевременной синхронизации с MAINCHAIN. Полученная модель доверия очень похожа на модель для DEX на основе книги заказов, например, [2], которые сегодня обычно включают в себя оффчейн-компонент для сопоставления заказов и ончейн-компонент для клиринга и расчетов.Используя словарь платежных систем, можно рассматривать exect как компонент SC отвечает за клиринг, а SCa занимается расчетами. Схематическое изображение см. на рис. 13. изображение ТЭФ. Рисунок 13: Схема TEF. В этом примере транзакции проходят через мемпул. MAINCHAIN через MS на DON. Преимущества ТЭФ: TEF имеет три основных преимущества: • Высокая производительность: SC унаследовал гораздо более высокую пропускную способность DON, чем MAINCHAIN. как для транзакций, так и для отчетов oracle. Кроме того, exect может обрабатывать транзакции быстрее и реагировать на отчеты oracle более своевременно, чем реализация только на MAINCHAIN. • Более низкие комиссии: процесс синхронизации требует меньше времени, чем обработка транзакций, и транзакции можно отправлять с DON на MAINCHAIN ​​пакетами. Следовательно, внутрисетевые комиссии за транзакцию (например, затраты на газ) при таком подходе намного ниже, чем для контракта, который работает только на MAINCHAIN. • Конфиденциальность: Механизмы конфиденциальности DON могут быть использованы для медведь на СЦ.

Ограничения ТЭФ: Одним из ограничений TEF является то, что он не поддерживает мгновенную Выводы, так как они происходят только на MAINCHAIN: При отправке запроса на вывод для SCa, пользователю может потребоваться дождаться exect, чтобы выполнить обновление состояния, включающее транзакция вывода средств до того, как она будет одобрена. Мы обсуждаем некоторые частичные средства правовой защиты, однако в разделе 6.2. Еще одним ограничением TEF является то, что он не поддерживает атомный состав DeFi. контракты на MAINCHAIN, в частности возможность маршрутизации активов через несколько DeFi контракты в рамках одной сделки. Однако TEF может поддержать такую атомарность среди Контракты DeFi выполняются на одном и том же DON. Мы также обсудим некоторые способы решения этой проблемы. задача в разделе 6.2. 6.2 Маршрутизация транзакций Транзакции для SC могут отправляться пользователями непосредственно на DON или маршрутизироваться через мемпул в MAINCHAIN (через FSS). Существует четыре различных типа транзакций, каждый из которых из которых требуется различное обращение: Внутриконтрактные сделки: Поскольку TEF позволяет избежать сложностей газовой динамики, он обеспечивает SC большую гибкость в обработке транзакций, чем это было бы возможно. доступен в контракте уровня 1. Например, в то время как транзакция мемпула в Ethereum может быть перезаписан новой транзакцией с более высокой ценой на газ, SC может считать транзакцию, которая работает с активами внутри SC, авторитетной, как только она станет видимой в мемпуле. Следовательно, SC не нужно ждать подтверждения транзакции. внутри блока, что приводит к значительному снижению задержки. Проксирование: Пользователь может пожелать отправить транзакцию τ в SC через контракт кошелька или другой контракт на MAINCHAIN. DON может имитировать выполнение τ на MAINCHAIN, чтобы определить, приведет ли это к последующей транзакции в SC. Если да, то τ можно упорядочить с другими транзакциями для SC, которые это делают. Есть несколько возможности того, как DON идентифицирует такие транзакции: (1) DON может имитировать все транзакции в мемпуле (дорогой подход); (2) Определенные контракты или типы контрактов, например кошельки, могут быть перечислены для мониторинга с помощью DON; или (3) Пользователи могут аннотировать транзакции для проверки DON. Ситуация усложняется, когда одна транзакция взаимодействует с двумя контракты, SC1 и SC2, оба из которых используют услуги справедливого упорядочения и имеют несовместимые политики заказа. DON может, например, последовательность τ в самое позднее время. это совместимо с обоими. Депозиты: Транзакция, передающая актив MAINCHAIN в SC, должна быть подтверждена в блоке, прежде чем SC сможет считать ее действительной. Когда он обнаруживает добычу транзакция, которая отправляет активы (например, эфир) в SCa, exect может мгновенно подтвердитьдепозит. Например, он может применить текущую цену, сообщаемую oracle, на DON к актив. Вывод средств: Как отмечалось выше, ограничением TEF является то, что снятие средств не всегда может быть выполнено мгновенно. В модели исполнения типа rollup снятие средств запрос должен быть упорядочен с другими транзакциями, т. е. объединен, чтобы быть безопасным. обработано. Однако существуют некоторые частичные средства устранения этого ограничения. Если DON может быстро вычислить подтверждение достоверности rollup вплоть до транзакции вывода средств, то наблюдение за транзакцией пользователя τ в exect мемпула может отправить транзакцию обновления состояния τ ′ для τ по более высокой цене газа, что является своего рода выгодным опережением. При условии, что τ не будет добыт до того, как τ ′ достигнет мемпула, τ ′ будет предшествовать τ, а τ приведет к утвержденному выводу средств. В варианте TEF, где DON используется для вычисления обновлений состояния (см. вариант пороговой подписи ниже), DON альтернативно может определять оффчейн следует ли утверждать τ, учитывая состояние SC при его выполнении. DON затем может отправить транзакцию τ ′, подтверждающую снятие τ, не выполняя при этом полного обновление состояния. Если этот подход невозможен или в случаях, когда он не увенчался успехом, инициируется DON. транзакция τ ′ может отправить средства пользователю в ответ на τ, так что пользователю не нужно инициировать дополнительную транзакцию. 6.3 Синхронизация Исполняемый файл TEF exect периодически отправляет обновления с DON в MAINCHAIN. обновление состояния SCa в процессе, который мы называем синхронизацией. Можно подумать о синхронизации как распространение транзакций уровня 2 на уровень 1, поэтому TEF может использовать любое число существующих методик для этой цели, в том числе rollups [5, 12, 16, 69], оптимистичный rollups [10, 11, 141], Validium [201] или базовое пороговое подписание, например пороговое BLS, Шнорра, или ECDSA [24, 54, 116, 202]. В принципе, доверенные среды выполнения также может подтвердить правильность изменений состояния, предлагая гораздо более производительную работу. альтернатива rollups, но с аппаратно-зависимой моделью доверия. (См., например, [80].) Ниже мы сравниваем эти параметры синхронизации по трем ключевым свойствам в ТЭФ: • Доступность данных: Где хранится состояние SC? Как минимум три варианта доступен в TEF: в MAINCHAIN, на DON или в стороннем хранилище. провайдеры, такие как IPFS. Они обеспечивают различные гарантии безопасности, доступности уровни и профили производительности. Короче говоря, сохранение состояния в MAINCHAIN позволяет внутрисетевая возможность аудита и исключает зависимость от какой-либо стороны в плане доступности состояния; с другой стороны, хранение состояния вне цепочки может снизить стоимость хранения и улучшить пропускная способность за счет доверия к поставщикам хранилищ (DON или третьим лицам) для доступность данных. Конечно, гибкие модели, сочетающие в себе эти возможности, также возможно. Требуемую форму предоставления данных мы указываем в таблице 1.• Гарантии правильности: как SCa проверяет правильность обновлений. подтолкнул exect? Это влияет на вычислительную нагрузку на exect и SCa, а также на задержка синхронизации (см. ниже). • Задержка. На задержку синхронизации влияют три фактора: (1) Затраченное время. for exect для создания транзакции синхронизации τsync; (2) Время, необходимое для τsync должно быть подтверждено на MAINCHAIN; и (3) Время, в течение которого τsync вступит в силу СКа. В TEF задержка особенно важна для вывода средств (но в меньшей степени для внутриконтрактные транзакции), поскольку снятие средств обязательно требует (по крайней мере частичная) синхронизация состояния. Синхронизация варианты Данные доступность Корректность гарантии Задержка Свернуть [5, 12, 16, 69] Ончейн Доказательства действительности Время, затраченное на создание доказательства действительности (например, минуты в существующих системах) Валидиум [201] Офчейн Доказательства действительности То же, что и выше Оптимистичный rollup [10, 11, 141] Ончейн Доказательства мошенничества Продолжительность испытания период (например, дни или недели) Пороговое подписание [24, 54, 116, 202] Гибкий Пороговые подписи от DON Мгновенный Доверенные среды выполнения [80] Гибкий Аппаратное обеспечение аттестации Мгновенный Таблица 1. Различные параметры синхронизации в TEF и их свойства. В таблице 1 суммированы эти свойства пяти основных вариантов синхронизации в TEF. (Примечание что мы не намерены сравнивать эти технологии с автономным масштабированием уровня 2. решения. Для этого мы отсылаем читателей, например, к [121].) Теперь мы обсудим каждый вариант синхронизации. Свертывания: rollup [69] — это протокол, в котором переход состояния, выполняемый Пакет транзакций вычисляется вне цепочки. Затем изменение состояния распространяется на MAINCHAIN. Для реализации rollups якорь smart contract SCa хранит компактное представление Rstate (например, корень Меркла) фактического состояния. Для синхронизации exect отправляет τsync = (Т, Р' состояние) в SCa, где T — набор транзакций, обработанных с момента последнегосинхронизация и R' состояние — это компактное представление нового состояния, рассчитанное путем применения транзакции в T в предыдущее состояние Rstate. Существует два популярных варианта, которые различаются тем, как SCa проверяет обновления состояния в τsync. Первые, (zk-)rollups, содержат краткий аргумент правильности, иногда называемый доказательство правильности перехода Rstate →R′ государство. Чтобы реализовать этот вариант, выполните вычисляет и отправляет доказательство достоверности (например, доказательство zk-SNARK) вместе с τsync, доказывая, что R' состояние является результатом применения T к текущему состоянию SCa. Якорь контракт принимает обновление состояния только после проверки доказательства. Оптимистические rollup не включают аргументы правильности, но имеют staking и Процедуры вызова, которые облегчают распределенную проверку переходов состояний. Для этого Вариант rollup, SCa предварительно принимает τsync, предполагая, что это правильно (отсюда и оптимизм) но τsync вступает в силу только после периода вызова, в течение которого любая сторона мониторинг MAINCHAIN может выявлять ошибочные обновления состояния и информировать SCa о необходимости принятия необходимые действия (например, откат состояния и наложение штрафа в случае необходимости). Оба варианта rollup обеспечивают доступность данных в цепочке, поскольку транзакции публикуются. on-chain, из которого можно построить полное состояние. Задержка zk-rollups составляет преобладает время, необходимое для создания доказательств достоверности, которое обычно находится на этапе порядка минут в существующих системах [16] и, вероятно, со временем будут улучшаться. С другой стороны, оптимистичные rollup имеют более высокую задержку (например, дни или недели). потому что период оспаривания должен быть достаточно длительным, чтобы доказательства мошенничества сработали. Значение медленного подтверждения является тонким и иногда специфичным для схемы, так что тщательный анализ выходит за рамки. Например, некоторые схемы предусматривают оплату транзакции как «доверительные финальные» [109] до подтверждения обновления состояния, поскольку обычный пользователь может проверить rollup гораздо быстрее, чем MAINCHAIN. Валидиум: Validium — это форма (zk-)rollup, которая делает данные доступными только вне сети. и не хранит все данные в MAINCHAIN. В частности, exect отправляет только новые состояние и доказательства, а не транзакции в SCa. При синхронизации в стиле Validium, кроме и DON, который его выполняет, являются единственными сторонами, которые сохраняют полное состояние и которые выполняют транзакции. Как и в случае с zk-rollups, задержка синхронизации зависит от достоверности. время генерации доказательства. Однако, в отличие от zk-rollups, синхронизация в стиле Validium снижает стоимость хранения и увеличивает пропускную способность. Пороговая подпись DON: Предполагая, что порог в DON узлов является честным, Простой и быстрый вариант синхронизации заключается в том, чтобы узлы DON коллективно подписывали новое состояние. Этот подход может поддерживать доступность данных как внутри, так и вне цепочки. Обратите внимание, что если пользователи доверяют DON для обновлений oracle, им не нужно больше доверять ему для принятия обновления состояния, так как они уже находятся в модели порогового доверия. Еще одно преимущество пороговое подписание имеет низкую задержку. Поддержка новых форматов подписей транзакций, таких как предложенный в EIP-2938 [70] и известный как абстракция учетной записи, составит пороговое значение подписание значительно проще реализовать, поскольку оно устранит необходимость в пороговом значении ECDSA, который использует значительно более сложные протоколы (например, [116, 117, 118]).чем альтернативы, такие как пороговые подписи Шнорра [202] или BLS [55]. Доверенные среды выполнения (TEE): TEE — это изолированные среды выполнения (обычно реализуемые аппаратно), целью которых является обеспечение надежной защиты. для программ, работающих внутри. Некоторые TEE (например, Intel SGX [84]) могут предоставлять доказательства, известные как аттестации, подтверждающие, что результат правильно вычислен специальной программой для конкретный вход12. Вариант синхронизации TEF на основе TEE может быть реализован с помощью замена доказательств в (zk-)rollups или Validium аттестациями TEE с использованием методов с [80]. По сравнению с доказательствами с нулевым разглашением, используемыми в rollups и Validium, TEE намного более производительный. По сравнению с подписанием порогов, TEE устраняют сложность создание пороговых подписей ECDSA, поскольку в принципе должен быть только один TEE участвует. Однако использование TEE вводит дополнительные предположения о доверии, зависящие от оборудования. Можно также объединить TEE с пороговой подписью для повышения устойчивости. от компрометации части случаев TEE, хотя эта защитная мера вновь усложняет создание пороговых подписей ECDSA. Дополнительная гибкость: Эти параметры синхронизации можно усовершенствовать, чтобы обеспечить большую гибкость следующими способами. • Гибкий запуск: приложение TEF может определять условия, при которых синхронизация срабатывает. Например, синхронизация может быть пакетной, например, происходить после каждые N транзакций, основанных на времени, например, каждые 10 блоков, или на основе событий, например, происходят всякий раз, когда целевые цены на активы значительно меняются. • Частичная синхронизация: это возможно, а в некоторых случаях желательно (например, с rollups, частичная синхронизация может уменьшить задержку) для обеспечения быстрой синхронизации небольших объемы состояния, полная синхронизация выполняется, возможно, только периодически. Например, Exect может одобрить запрос на вывод средств, обновив баланс пользователя в SCa. без обновления состояния MAINCHAIN иным образом. 6.4 реорганизации Реорганизации блокчейна в результате нестабильности сети или даже атак 51% может представлять угрозу целостности основной цепи. На практике противники использовали им организовать атаки двойного расходования [34]. Хотя такие атаки на крупные сети их сложно установить, но для некоторых цепочек [88] они все же возможны. Поскольку DON работает независимо от MAINCHAIN, он предлагает интересные возможности. возможность наблюдения и обеспечения некоторой защиты от реорганизаций, связанных с атаки. Например, DON может сообщить опорному контракту SC на MAINCHAIN ​​о существовании конкурирующего форка некоторой пороговой длины τ. DON может дополнительно 12Дополнительную информацию можно найти в Приложении B.2.1. Они не нужны для понимания.

предоставить доказательства (в рамках PoW или PoS) существования такого форка. контрактный SC может реализовать подходящие защитные действия, такие как приостановка дальнейшего выполнения транзакций на определенный период времени (например, чтобы разрешить биржам вносить в черный список двойное расходование). активы). Обратите внимание: хотя противник, проводящий атаку 51%, может попытаться подвергнуть цензуре сообщений от DON, контрмерой в SC является требование периодических отчетов от DON для обработки транзакций (т. е. контрольного сигнала) или для запроса нового отчета для подтвердить транзакцию на большую сумму. Хотя такие оповещения о разветвлении в принципе являются общей услугой, DON может предоставить для любой из ряда целей мы планируем включить их в TEF.

Минимизация доверия

Будучи децентрализованной системой с участием разнородного набора субъектов, Сеть Chainlink обеспечивает надежную защиту от сбоев как в работоспособности (доступности), так и в безопасности (целостность отчета). Однако большинство децентрализованных систем различаются по степень, в которой их составляющие компоненты сами по себе децентрализованы. Это справедливо даже для больших систем, где ограниченная децентрализация среди майнеров [32] и посредники [51] уже давно присутствуют. Целью любых усилий по децентрализации является минимизация доверия. неблагоприятные последствия системного повреждения или сбоя в сети Chainlink, даже если из-за вредоносного DON. Нашим руководящим принципом является принцип наименьших привилегий [197]. Системные компоненты и участники внутри системы должны иметь строго ограниченные привилегии. разрешать только успешное выполнение назначенных им ролей. Здесь мы излагаем несколько конкретных механизмов, которые Chainlink может использовать в своей работе. к все большей минимизации доверия. Мы характеризуем эти механизмы с точки зрения локусов, т.е. компонентов системы, в которых они укоренены, показаны на рис. 14. Мы обратиться к каждому локусу в соответствующем подразделе. 7.1 Аутентификация источника данных Текущие операционные модели для oracles ограничены тем фактом, что мало источников данных подписывают цифровую подпись для данных, которые они пропускают, во многом потому, что TLS изначально не подписывает данные. TLS использует цифровые подписи в своем протоколе «рукопожатия» (для установления общий ключ между сервером и клиентом). Таким образом, серверы с поддержкой HTTPS имеют сертификаты. на открытых ключах, которые в принципе могут служить для подписи данных, но обычно не используются эти сертификаты поддерживают подпись данных. Следовательно, безопасность DON, как в современных сетях oracle полагается на узлы oracle, добросовестно передающие данные из источник к контракту. Важным долгосрочным компонентом нашего видения минимизации доверия в Chainlink является более строгая аутентификация источника данных посредством поддержки инструментов и стандартов подписи данных. Подписание данных может помочь обеспечить гарантии сквозной целостности. В принципе, если контракт принимает в качестве входных данных часть данных D, подписанную непосредственно пользователем данных

Рисунок 14: Локусы механизмов минимизации доверия, обсуждаемых в этом разделе. 1⃝Данные источники предоставляют данные 2⃝DON, который передает функцию данных зависимому 3⃝smart contract. Кроме того, сеть DON или oracle включает в себя 4⃝узла. управление smart contracts на MAINCHAIN, например, для компенсирующих узлов, защиты рельсы и так далее. источник, то сеть oracle не сможет вмешаться в D. Различные обнадеживающие появились попытки обеспечить такое подписание данных, включая OpenID Connect, который предназначен в первую очередь для аутентификации пользователей [9], TLS-N, академический проект, направленный на расширить TLS [191], переназначив сертификаты TLS и расширения доказательств TLS [63]. Однако хотя OpenID Connect получил некоторое распространение, расширения TLS Evidence Extensions и TLS-N еще не получили широкого распространения. Еще одним потенциальным способом аутентификации источника данных является использование собственных средств издателей. Подписанные обмены HTTP (SXG) [230], которые они могут кэшировать в сетях доставки контента как часть протокола ускоренных мобильных страниц (AMP) [225]. Мобильный браузер Chrome отображает контент из SXG-файлов, кэшированных в AMP, как если бы они были получены из собственные сетевые домены их издателей вместо домена кэш-сервера. Этот стимул для брендинга в сочетании с относительной простотой его включения с использованием таких сервисов, как Real URL [83] от CloudFlare и amppackager [124] от Google, может привести к широкому распространению SXG в кэшированном новостном контенте, что позволит создать простой, защищенный от несанкционированного доступа файл. способ срабатывания Chainlink oracles при заслуживающих внимания событиях, о которых сообщается в действительных файлах SXG. Хотя SXG-файлы с кэшированием AMP от издателей новостей не будут полезны для высокоскоростных приложения, такие как отчеты о торговых данных, они могут быть безопасным источником пользовательских контракты, относящиеся к реальным событиям, таким как экстремальные погодные условия или результаты выборов. Мы считаем, что простое развертывание, зрелые инструменты и гибкость будут иметь жизненно важное значение для ускорение подписания источников данных. Разрешение поставщикам данных использовать узлы Chainlink в качестве аутентифицированный интерфейс API кажется многообещающим подходом. Мы намерены создатьвозможность работы узлов в этом режиме, с участием в сети или без него как полноценный oracle. Мы называем эту возможность аутентифицированным источником данных. (АДО). Используя узлы Chainlink с ADO, источники данных смогут получить выгоду. на основе опыта и инструментов, разработанных сообществом Chainlink по добавлению цифровых возможности подписи в существующем наборе API-интерфейсов вне цепочки. Если они решат бежать свои узлы как oracles, они могут дополнительно открыть потенциальные новые потоки доходов по той же модели, что и существующие поставщики данных, например Kraken [28], Kaiko [140] и другие, которые запускают узлы Chainlink для продажи данных API в цепочке. 7.1.1 Ограничения создания аутентифицированных данных Цифровая подпись источников данных, хотя и может помочь усилить аутентификацию, сама по себе недостаточна для достижения всех естественных целей безопасности или эксплуатационных целей oracle. сеть. Начнем с того, что данный фрагмент данных D должен быть передан надежно и своевременно. путь от источника данных до smart contract или другого потребителя данных. То есть даже в идеальная настройка, в которой все данные подписываются с использованием ключей, предварительно запрограммированных в зависимые контрактов, DON все равно потребуется для надежной передачи данных из источников к контрактам. Кроме того, в ряде случаев контракты или другие oracle-данные потребители хотят получить доступ к аутентифицированным выводам различных функций, вычисляемых исходные данные по двум основным причинам: • Конфиденциальность: API источника данных может предоставлять конфиденциальные или собственные данные. его необходимо отредактировать или очистить, прежде чем он станет общедоступным в цепочке. Однако любое изменение подписанных данных делало подпись недействительной. Поставь другой Кстати, наивный ADO и очистка данных несовместимы. Покажем в примере 3 как эти два процесса можно согласовать с помощью расширенной формы ADO. • Неисправности источников данных. Как ошибки, так и сбои могут повлиять на источники данных, а цифровые подписи не решают ни одной проблемы. С момента своего создания [98], Chainlink имеет уже включен механизм устранения таких ошибок: избыточность. Отчеты, выпускаемые сетями oracle, обычно представляют собой объединенные данные нескольких источники. Теперь мы обсуждаем схемы, которые изучаем в условиях ADO, чтобы повысить конфиденциальность исходных данных и безопасно объединить данные из нескольких источников. 7.1.2 Конфиденциальность Источники данных могут не предвидеть и не предоставлять полный спектр желаемых API. пользователями. В частности, пользователи могут захотеть получить доступ к предварительно обработанным данным, чтобы гарантировать конфиденциальность. Следующий пример иллюстрирует проблему.Пример 3. Алиса желает получить учетные данные децентрализованной идентификации (DID), указывающие что ей больше 18 лет (и, следовательно, она может, например, взять кредит). Делать поэтому ей необходимо доказать факт своего возраста органу, выдавшему удостоверения DID. Алиса надеется использовать данные Департамента транспортных средств своего штата (DMV). сайт для этой цели. DMV имеет запись о ее дате рождения и выдаст заверение А, подписанное цифровой подписью, следующего вида: A = {Имя: Алиса, дата рождения: 16.02.1999}. В этом примере свидетельства A может быть достаточно для Алисы, чтобы доказать DID. эмитенту учетных данных, что ей больше 18 лет. Но из-за этого происходит бесполезная утечка конфиденциальной информации: точная дата рождения. В идеале Алисе хотелось бы получить от DMV подпись на простое утверждение А' о том, что «Алисе больше 18 лет». Другими словами, она хочет, чтобы вывод функции G в дату ее рождения X, где (неформально) A′ = G(X) = True, если ТекущаяДата −X ≥18 лет; в противном случае G(X) = Ложь. Обобщая, Алиса хотела бы иметь возможность запрашивать у источника данных подписанный свидетельство А' формы: A' = {Имя: Алиса, Func:G(X), Результат: True}, где G(X) обозначает спецификацию функции G и ее входа(ов) X. Мы представляем себе что пользователь должен иметь возможность предоставить желаемый G(X) в качестве входных данных с ее запросом на соответствующее свидетельство A'. Обратите внимание, что подтверждение источника данных A' должно включать спецификацию G(X), чтобы убедитесь, что A' правильно интерпретируется. В приведенном выше примере G(X) определяет значение логического значения в A', и, таким образом, True означает предмет аттестации. возраст старше 18 лет. Мы говорим о гибких запросах, в которых пользователь может указать G(X) как о функциональных запросах. Чтобы поддерживать варианты использования, подобные приведенному в примере 3, а также те, которые связаны с запросами непосредственно из контрактов, мы намерены включить поддержку функциональных запросов, включающих простые функции G как часть ADO. 7.1.3 Объединение исходных данных Чтобы снизить затраты на цепочку, контракты обычно разрабатываются для использования объединенных данных. из нескольких источников, как показано в следующем примере. Пример 4 (Медианизация ценовых данных). Чтобы предоставить ценовой поток, т. е. стоимость одного актива (например, ETH) по отношению к другому (например, доллару США), сеть oracle обычно получать текущие цены из ряда источников, таких как биржи. Сеть oracle обычно отправляет зависимому контракту SC медиану этих значений. В среде с подписанием данных правильно функционирующая сеть oracle получает из источников данных S = {S1, . . . , SnS} последовательность значений V = {v1, v2, . . . , vnS} из nS-источники с сопровождающими специфичными для источника сигнатурами Σ = {σ1, σ2, . . . , σnS}. После проверяя подписи, он передает цену v = median(V ) в SC.К сожалению, для сети oracle не существует простого способа передать медианное значение. значение v в примере 4 для SC вместе с кратким доказательством σ∗ того, что v было правильно вычислено. над подписанными входами. Наивным подходом было бы закодировать в SC открытые ключи всех источников данных NS. Затем сеть oracle будет ретранслировать (V, Σ) и позволит SC вычислить медиану V . Однако это привело бы к доказательству σ размера O(nS), т. е. σ∗ не было бы кратким. Это также повлечет за собой высокие затраты на газ для SC, которому необходимо будет проверять все подписи в Σ. Использование SNARK, напротив, позволяет кратко доказать правильность объединения значений аутентифицированного источника. На практике это может быть осуществимо, но требует довольно высоких затрат. вычислительные затраты на прувер и довольно высокие затраты на газ в цепочке. Использование Town Crier тоже возможен, но требует использования TEE, что подходит не всем модели доверия пользователей. Полезной концепцией для решения общей проблемы подписания объединенных данных из источников является криптографический инструмент, известный как функциональные подписи [59, 132]. Коротко говоря, функциональные подписи позволяют подписывающему лицу делегировать возможность подписания, например делегат может подписывать сообщения только в диапазоне функции F, выбранной подписывающим лицом. В Приложении D мы покажем, как это функциональное ограничение может служить для ограничения диапазона значений отчета, выдаваемых DON, в зависимости от значений, подписанных источниками данных. Мы также вводим новый примитив, называемый дискретизированной функциональной сигнатурой, который включает в себя смягченные требования к точности, но потенциально гораздо более эффективен. чем такие подходы, как SNARK. Проблема объединения источников данных, включающая аутентификацию источника. выходных данных также применимо к агрегаторам данных, например, CoinCap, CoinMarketCap, CoinGecko, CryptoCompare и т. д., которые получают данные от множества бирж, которые они вес на основе объемов с использованием методологий, которые они в некоторых случаях обнародуют и в других случаях являются собственностью. Агрегатор, желающий опубликовать значение с аутентификация источника сталкивается с той же проблемой, что и набор узлов, агрегирующих исходные данные. 7.1.4 Обработка исходных данных Сложные smart contract, скорее всего, будут зависеть от пользовательской статистической статистики. первичные источники данных, такие как волатильность недавней истории цен на многие активы, или текст и фотографии из новостей о соответствующих событиях. Поскольку вычисления и пропускная способность относительно дешевы в DON, эта статистика… даже сложные модели машинного обучения со многими входными данными могут обрабатываться экономично, если любое выходное значение, предназначенное для blockchain, является достаточно кратким. Для задач с интенсивными вычислениями, где участники DON могут иметь разные просмотров сложных входных данных, могут потребоваться дополнительные раунды общения между участниками DON для достижения консенсуса по входным данным перед вычислением результата. Пока окончательное значение полностью определяется входными данными, как только будет достигнут консенсус по входным данным, каждый участник может просто вычислить значение и передать его другому.участников с их частичной подписью или отправить агрегатору. 7.2 DON Минимизация доверия Мы видим два основных способа минимизировать доверие к компонентам DON: клиенты аварийного восстановления и отчеты меньшинства. 7.2.1 Отказоустойчивые клиенты Состязательные модели в литературе по криптографии и распределенным системам обычно рассмотрим противника, способного повредить (т. е. скомпрометировать) подмножество узлов, например, менее одной трети для многих протоколов BFT. Однако обычно наблюдают, что если на всех узлах установлено идентичное программное обеспечение, злоумышленник, обнаруживший фатальную эксплойт, может в принципе компрометируют все узлы более или менее одновременно. Эта настройка часто называется программной монокультурой [47]. Для решения этой проблемы были выдвинуты различные предложения по автоматической диверсификации программного обеспечения и конфигураций программного обеспечения, например, [47, 113]. Как отмечено в [47], однако разнообразие программного обеспечения является сложной проблемой и требует тщательного рассмотрения. Например, диверсификация программного обеспечения может привести к худшему уровню безопасности, чем монокультура, если она увеличивает поверхность атаки системы и, следовательно, ее возможные векторы атаки, превышающие преимущества безопасности, которые он предлагает. Мы считаем, что поддержка надежных клиентов аварийного переключения, т. е. клиентов, к которым узлы может измениться перед лицом катастрофического события — это особенно привлекательная форма диверсификация программного обеспечения. Клиенты аварийного переключения не увеличивают количество потенциальных векторов атак, поскольку они не развертываются в качестве основного программного обеспечения. Они предлагают явные преимущества, однако, как вторая линия защиты. Мы намерены поддерживать отказоустойчивые клиенты в DONs, поскольку ключевое средство снижения их зависимости в плане безопасности от одного клиента. Chainlink уже имеет надежную систему резервных клиентов. Наш подход предполагает поддержание предыдущих, проверенных в бою версий клиента. Сегодня, например, узлы Chainlink с отчетами вне цепочки (OCR) в качестве основного клиента включают поддержку для предыдущей системы FluxMonitor Chainlink, если необходимо. Был в использовании некоторое время Со временем FluxMonitor прошел аудит безопасности и полевые испытания. Он обеспечивает то же самое функциональность как OCR, только за более высокую цену — затраты, которые возникают только по мере необходимости. 7.2.2 Отчеты меньшинства При достаточно большом наборе меньшинства Ominority (доля честных узлов, которые наблюдают за должностными преступлениями со стороны большинства) для них может быть полезно создать меньшинство. отчет. Это параллельный отчет или флаг, передаваемый зависимому контракту SC в сети. по всеобщему меньшинству. SC может использовать этот флаг в соответствии со своей собственной политикой, специфичной для контракта. Например, для контракта, в котором безопасность важнее, чем работоспособность или оперативность, отчет меньшинства может привести к тому, что контракт запросит дополнительные отчеты. от другого DON или активируйте автоматический выключатель (см. следующий раздел).Отчеты меньшинства могут сыграть важную роль, даже если большинство честно. потому что любая схема агрегирования отчетов, даже если она использует функциональные сигнатуры, должна работать пороговым образом, чтобы обеспечить устойчивость к oracle или сбою данных. В Другими словами, должна быть возможность составить действительный отчет на основе входных данных kS < nS __PH_0009__s, для некоторого порога kS. Это означает, что поврежденный DON имеет некоторые широта манипулирования значениями отчета путем выбора предпочтительных значений kS среди ns сообщил в V полный набор oracles, даже если все источники честны. Например, предположим, что nS = 10 и kS = 7 в системе, использующей функционал подпись для аутентификации вычисления медианы по V для цены ETH в долларах США. Предположим, что пять источников сообщают о цене \(500, while the other five report \)1000. Затем, усреднив 7 самых низких отчетов, DON может вывести допустимое значение v = 500 долларов США, и, усреднив наибольшую величину, он может вывести v = 1000 долларов. Улучшив протокол DON, чтобы все узлы знали, какие данные были доступны и какие данные использовались для построения отчета, узлы могут обнаружить и пометить статистически значимые тенденции отдавать предпочтение одному набору отчетов перед другим и производить в результате отчет меньшинства. 7.3 Ограждения Рельсы Наша модель доверия для DONs рассматривает MAINCHAIN как объект с более высоким уровнем безопасности и привилегиями. системе, чем DONs. (Хотя эта модель доверия не всегда верна, ее проще адаптировать полученный механизм к ситуациям, где DON имеет более высокий уровень безопасности платформа, чем наоборот.) Таким образом, естественная стратегия минимизации доверия предполагает реализацию механизмов мониторинга и отказоустойчивости в smart contracts — либо во внешнем интерфейсе MAINCHAIN. для DON или непосредственно в зависимом договоре SC. Мы называем эти механизмы ограждения и перечислим некоторые из наиболее важных здесь: • Автоматические выключатели: SC может приостановить или остановить обновление состояния в зависимости от характеристик самих обновлений состояния (например, большая разница между последовательными отчеты) или на основе других исходных данных. Например, автоматический выключатель может сработать случаи, когда отчеты oracle неправдоподобно меняются с течением времени. Автоматический выключатель может также быть сбиты с толку отчетом меньшинства. Таким образом, автоматические выключатели могут предотвратить DONs. от составления грубо ошибочных отчетов. Автоматические выключатели могут дать время для рассмотрения дополнительных мер. или тренировался. Одним из таких вмешательств являются аварийные люки. • Аварийные люки: при неблагоприятных обстоятельствах, выявленных группой хранителей, держателями token сообщества или другими органами попечителей, контракт может ссылаться на аварийное сооружение, которое иногда называют аварийным люком [163]. Аварийный люк заставляет SC каким-то образом завершить работу и/или завершить работу в ожидании и, возможно, будущие сделки. Например, он может вернуть хранящиеся средства пользователям [17]),может расторгнуть условия договора [162] или отменить ожидающие и/или будущие транзакции [173]. Аварийные люки можно использовать в контрактах любого типа, а не только тот, который опирается на DON, но они представляют интерес как потенциальный буфер против DON должностное преступление. • Аварийное переключение: в системах, где SC использует DON для основных услуг, SC может предоставить механизмы аварийного переключения, которые гарантируют продолжение обслуживания даже при отказе. в случае DON сбоя или ненадлежащего поведения. Например, в ТЭФ (раздел 6) якорный контракт SCa может предоставлять двойные интерфейсы, как внутри цепочки, так и внутри сети. Интерфейсы выполнения вне цепочки поддерживаются для определенных критических операций (например, вывод средств) или для обычных транзакций с подходящей задержкой, чтобы предотвратить опережающее выполнение транзакций DON. В случаях, когда источники данных подписывают данные, пользователи могут также предоставлять отчеты в SCa, если DON не может этого сделать. Доказательства мошенничества, предложенные для различных форм оптимистического rollup (см. раздел 6.3), схожи по своему характеру и дополняют механизмы, которые мы перечислили выше. Они также обеспечивают форму внутрисетевого мониторинга и защиты от потенциальных сбоев в компоненты системы вне цепочки. 7.4 Управление, минимизированное доверием Как и все децентрализованные системы, сеть Chainlink требует механизмов управления. корректировать параметры с течением времени, реагировать на чрезвычайные ситуации и направлять ее развитие. Некоторые из этих механизмов в настоящее время находятся в MAINCHAIN и могут продолжать работать. делайте это даже при развертывании DONs. Одним из примеров является механизм оплаты. для поставщиков узлов oracle (узлы DON). DON внешние контракты на MAINCHAIN содержат дополнительные механизмы, такие как ограждения, которые могут периодически подвергаться модификация. Мы предвидим два класса механизмов управления: эволюционные и чрезвычайные. Эволюционное управление: Многие модификации экосистемы Chainlink так, что их внедрение не является вопросом срочности: Улучшение производительности, улучшения функций, (несрочные) обновления безопасности и т. д. Поскольку Chainlink постепенно приближается к еще большему числу участников своего управления, мы ожидаем, что многие или большинство таких изменений должны быть ратифицированы сообществом конкретного DON, затронутого этими изменения. Тем временем и, возможно, в конечном итоге, в качестве параллельного механизма, мы считаем, что идея временных наименьших привилегий может быть полезным средством реализации эволюционного управления. Очень просто: идея заключается в том, чтобы изменения внедрялись постепенно, обеспечивая сообществу возможность ответить на них. Например, миграция на новый Контракт MAINCHAIN может быть ограничен, чтобы необходимо было развернуть новый контракт. не менее чем за тридцать дней до активации.Чрезвычайное управление: Эксплуатируемые или эксплуатируемые уязвимости в MAINCHAIN контракты или другие формы нарушений работоспособности или безопасности могут потребовать немедленного вмешательства во избежание катастрофических последствий. Нашим намерением является поддержка мультиподписи. механизм вмешательства, в котором для предотвращения должностных преступлений со стороны любой организации, подписанты будут рассредоточены по организациям. Обеспечение постоянной доступности подписывающих лиц и своевременный доступ к соответствующим инстанциям для получения разрешения на чрезвычайную ситуацию. изменения, очевидно, потребуют тщательного оперативного планирования и регулярного анализа. Эти проблемы аналогичны тем, которые возникают при тестировании других мер реагирования на инциденты кибербезопасности. возможности [134], с аналогичной необходимостью борьбы с распространенными проблемами, такими как снижение бдительности [223]. Управление DON отличается от управления многими децентрализованными системами своим потенциальная степень неоднородности. Каждый DON может иметь отдельные источники данных, исполняемые файлы, требования к уровню обслуживания, такие как время безотказной работы и пользователей. Сеть Chainlink Механизмы управления должны быть достаточно гибкими, чтобы приспособиться к таким изменениям в Операционные цели и параметры. Мы активно изучаем дизайнерские идеи и планируем опубликовать исследование по этой теме в будущем. 7,5 Инфраструктура открытых ключей С прогрессивной децентрализацией возникнет необходимость в четком выявлении участники сети, включая узлы DON. В частности, Chainlink требует сильного Инфраструктура открытых ключей (PKI). PKI — это система, которая связывает ключи с идентификаторами. Для Например, PKI поддерживает систему безопасных соединений Интернета (TLS): когда вы подключаетесь к веб-сайту через HTTPS (например, https://www.chainlinklabs.com) и в вашем браузере появится блокировка, это означает, что открытый ключ владельца домена был связан с этим владельцем органом власти, в частности, посредством цифровой подписи в так называемый сертификат. Иерархическая система центров сертификации (ЦС), чьи корневые центры верхнего уровня встроены в популярные браузеры, помогает гарантировать, что сертификаты выдаются только законным владельцам доменов. Мы ожидаем, что Chainlink в конечном итоге будет использовать децентрализованные службы имен. первоначально служба имен Ethereum (ENS) [22] в качестве основы для нашей PKI. Как как следует из названия, ENS аналогичен DNS, системе доменных имен, которая отображает (удобочитаемые) доменные имена на IP-адреса в Интернете. Однако вместо этого ENS сопоставляет удобочитаемые имена Ethereum с адресами blockchain. Потому что ЭНС работает на Ethereum blockchain, исключая компрометацию ключа и подделку его пространство имен в принципе так же сложно, как и подделать контракт, управляющий им. и/или базовый blockchain. (DNS, напротив, исторически был уязвим спуфингу, перехвату информации и другим атакам.) Мы зарегистрировали data.eth в ENS в основной сети Ethereum и намерены установить его как корневое пространство имен, в котором будут идентифицированы службы данных oracle и находятся другие Chainlink сетевые объекты. Домены в ENS иерархичны, то есть каждый домен может содержать ссылки. на другие имена под ним. Субдомены в ENS могут служить способом организации иделегировать доверие. Основная роль data.eth будет заключаться в том, чтобы служить внутрисетевой службой каталогов для каналы данных. Традиционно разработчики и пользователи oracles использовали источники вне цепочки. (например, веб-сайты, такие как docs.chain.link или data.chain.link, или социальные сети, такие как Twitter) для публикации и получения oracle адресов каналов данных (например, цены ETH-USD). корм). Используя заслуживающее доверия корневое пространство имен, такое как data.eth, вместо этого можно установить сопоставление eth-usd.data.eth, например, с адресом smart contract. сетевого агрегатора oracle для потока цен ETH-USD. Это бы создайте безопасный путь, чтобы каждый мог обращаться к blockchain как к источнику истины для этот поток данных этой пары цена/имя (ETH-USD). Следовательно, такое использование ENS реализует два преимущества, недоступных в источниках данных вне сети: • Надежная безопасность: все изменения и обновления домена записываются неизменяемо. и защищены криптографически, в отличие от текстовых адресов на веб-сайте, которые не пользоваться ни одним из этих двух свойств безопасности. • Автоматическое распространение по цепочке: обновления базового адреса smart contract канала данных могут вызывать уведомления, которые распространяются на зависимые интеллектуальные устройства. контракты и может, например, автоматически обновлять зависимые контракты с помощью новые адреса.13 Однако пространства имен, такие как ENS, не подтверждают автоматически законное право собственности. утвержденных имён. Так, например, если пространство имен включает запись ⟨ «Acme Oracle Node Co.», адрес ⟩, тогда пользователь получает уверенность в том, что адрес принадлежит истцу с именем Acme Oracle Node Co. Без дополнительных механизмов администрирования пространства имен однако она не получает уверенности в том, что имя принадлежит организации на законных основаниях. называется Acme Oracle Node Co. в значимом смысле реального мира. Наш подход к проверке имен, то есть к обеспечению их владения соответствующими законными объектами реального мира, опирается на несколько компонентов. Сегодня Chainlink лаборатории эффективно действует как центр сертификации для сети Chainlink. Пока Chainlink Лаборатория будет продолжаться для проверки имен наша PKI превратится в более децентрализованную модель двумя способами: • Модель сети доверия. Децентрализованный аналог иерархической PKI часто называют сетью доверия.14 Варианты предлагались с 1990-х годов. например, [98], и ряд исследователей заметили, что blockchain могут облегчить использование этой идеи, например, [227], записывая сертификаты в глобально согласованном виде. бухгалтерская книга. Мы изучаем варианты этой модели для проверки личности сущностей. в сети Chainlink более децентрализованным способом. 13Зависимый контракт может факультативно включать заранее определенную задержку, позволяющую провести проверку вручную. и вмешательство администраторов зависимых контрактов. 14Термин, придуманный Филом Циммерманом для PGP [238].• Связь с проверочными данными: сегодня значительный объем данных о производительности узла oracle виден в цепочке и, таким образом, архивно привязан к адресам узлов. Такие данные можно рассматривать как дополняющие идентификацию PKI, предоставляя исторические свидетельства ее (надежного) участия в сети. Кроме того, инструменты для децентрализованной идентификации на основе узлов DECO и Town Crier [160] включения для накопления учетных данных, полученных на основе реальных данных. В качестве одного из примеров: оператор узла может прикрепить к своему идентификатору PKI учетные данные, подтверждающие владение рейтинга Дана и Брэдстрита. Эти дополнительные формы валидации могут дополните staking для обеспечения безопасности сети. Узел oracle с установленной реальной идентичностью может рассматриваться как имеющий долю в системе, вытекающей из ее репутации. (См. раздел 4.3 и раздел 9.6.3.) Последним требованием к Chainlink PKI является безопасная начальная загрузка, т. е. публикация корневого имени сети Chainlink, в настоящее время data.eth (аналогично к жесткой прошивке доменов верхнего уровня в браузерах). Другими словами, как пользователи Chainlink определить, что data.eth действительно является доменом верхнего уровня, связанным с Chainlink проект? Решение этой проблемы для сети Chainlink многостороннее и может включать: • Добавление записи TXT [224] в запись нашего домена для Chain.link, которая определяет data.eth как корневой домен экосистемы Chainlink. (Chainlink таким образом неявно использует PKI для интернет-доменов для проверки своего корневого домена ENS.) • Ссылка на data.eth с существующего веб-сайта Chainlink, например, с https://docs.chain.link. (Еще одно неявное использование PKI для интернет-доменов.) • Распространение информации об использовании data.eth через различные документы, включая этот технический документ. • Публикация data.eth в наших социальных сетях, таких как Twitter, и блог Chainlink [18]. • Размещение большого количества LINK под контролем одного и того же адреса регистранта. как data.eth.

DON Рекомендации по развертыванию

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

8.1 Подход к развертыванию В этой статье изложена амбициозная концепция расширенной функциональности Chainlink, реализация потребует решения многих проблем на этом пути. Этот технический документ выявляет некоторые проблемы, но непредвиденные из них обязательно возникнут. Мы планируем реализовать элементы этого видения постепенно в течение продолжительный период времени. Мы ожидаем, что DON первоначально будут запущены с поддержка конкретных готовых компонентов, созданных совместно командами внутри Chainlink сообщество. Цель состоит в том, чтобы более широкое использование DONs, например, способность запускать произвольные исполняемые файлы, поддержка появится позже. Одной из причин такой осторожности является то, что композиция smart contract может иметь сложные, непреднамеренные и опасные побочные эффекты, как это произошло в недавних атаках на основе срочных кредитов. например показано [127, 189]. Аналогично состав smart contracts, адаптеров и исполняемые файлы потребуют особой осторожности. В наше первоначальное развертывание DONs мы планируем включить только предварительно созданный набор шаблонизированных исполняемых файлов и адаптеров. Это позволит изучить композиционную безопасность этих функций с использованием формальных методов [46, 170] и других подходов. Это будет также упростить ценообразование: цены на функциональность могут устанавливаться узлами DON на основе каждой функциональности, а не посредством обобщенного измерения, принятый подход. например, [156]. Мы также ожидаем, что сообщество Chainlink примет участие в создании дополнительных шаблонов, объединяющих различные адаптеры и исполняемые файлы во все более полезные децентрализованные сервисы, которыми могут управлять сотни, если не тысячи отдельных пользователей. DONс. Кроме того, этот подход может помочь предотвратить раздувание состояния, т. е. необходимость в DON. узлы, чтобы сохранить неработоспособное количество состояний в рабочей памяти. Эта проблема уже возникающие в неразрешенных blockchains, мотивирующие подходы, такие как «безгражданство клиентов» (см., например, [206]). Это может быть более острым в системах с более высокой пропускной способностью, что мотивирует подход, при котором DON развертывает только исполняемые файлы с оптимизированным размером состояния. По мере того как DON развивается и совершенствуется и включает в себя надежные защитные ограждения, как обсуждалось в разделе 7, криптоэкономические и основанные на репутации механизмы безопасности, как описано в разделе 9, а также другие функции, которые обеспечивают высокую степень уверенности для пользователей DON, мы также рассчитываем разработать структуру и инструменты для облегчения более широкого запуска и использования DONs от сообщества. В идеале эти инструменты позволят создать набор операторов узлов. объединиться в сеть oracle и запустить свои собственные DON в закрытой или методом самообслуживания, что означает, что они могут сделать это в одностороннем порядке. 8.2 Динамическое членство DON Набор узлов, на которых работает данный DON, может со временем меняться. Есть два подхода ключевому руководству skL при условии динамического членства в O. Первый — обновить доли skL, принадлежащие узлам, при изменении членства. сохраняя при этом pkL неизменным. Этот подход, исследованный в [41, 161, 198], имеет то достоинство, не требовать от проверяющих сторон обновления pkL.Классический метод совместного использования акций, представленный в [122], обеспечивает простой и эффективный способ реализации таких обновлений общих ресурсов. Это позволяет передать секрет между одним набором узлов O(1) и вторым, возможно, пересекающим один O(2). В этом подход, каждый узел O(1) я выполняет (k(2), n(2)) секретное разделение своей секретной доли между узлы в O(2) для n(2) = |O(2)| и желаемый (возможно, новый) порог k(2). Различные схемы совместного использования проверяемого секрета (VSS) [108] могут обеспечить защиту от злоумышленника, который активно повреждает узлы, т. е. вносит в протокол вредоносное поведение. Техники в [161] направлены на это, одновременно снижая сложность коммуникации и обеспечивая устойчивость к сбоям в предположениях криптографической стойкости. Второй подход заключается в обновлении ключа реестра pkL. Это имеет преимущество безопасность: компрометация старых акций pkL (т. е. бывших узлов комитета) не будет привести к компрометации текущего ключа. Однако обновления pkL имеют два недостатка: (1) Данные, зашифрованные с помощью pkL, необходимо повторно зашифровать во время обновления ключа и (2) Ключевые обновления необходимо распространять среди проверяющих сторон. Мы намерены изучить оба подхода, а также их гибридизацию. 8.3 DON Ответственность Как и в существующих сетях Chainlink oracle, DON будут включать в себя механизмы подотчетности, т. е. записи, мониторинга и обеспечения правильного поведения узлов. DON будут иметь гораздо более существенная емкость данных, чем у многих существующих blockchain без разрешений, особенно с учетом их способности подключаться к внешнему децентрализованному хранилищу. Следовательно, они смогут подробно записывать историю производительности узлов, что позволяет более детальные механизмы подотчетности. Например, вычисление вне цепочки цены на активы могут включать в себя входные данные, которые отбрасываются до отправки медианного результата. цепь. Эти промежуточные результаты можно записать в DON. Таким образом, неправильное поведение или снижение производительности отдельных узлов в DON можно исправить или наказать. DON более детально. Мы дополнительно обсудили подходы к построению ограждения в разделе 7.3, которые касаются влияния системных сбоев на конкретный контракт. Однако также важно иметь отказоустойчивые механизмы для самих DON, т. е. защита от системных, потенциально катастрофических DON сбоев, в частности сбои разветвления/двусмысленности и соглашения об уровне обслуживания (SLA), как мы сейчас объясним. Разветвление/эквивокация: При наличии достаточного количества неисправных узлов DON может разветвиться. или двусмысленным, создавая два различных, противоречивых блока или последовательности блоков в L. Однако, поскольку DON подписывает содержимое L цифровой подписью, можно использовать основная цепочка MAINCHAIN для предотвращения и/или наказания за двусмысленность. DON может периодически проверять состояние точки L в контракте аудита на MAINCHAIN. Если его будущее состояние отклоняется от состояния контрольной точки, пользователь/аудитор может предоставить доказательства. данного нарушения в договоре на проведение аудита. Такое доказательство может быть использовано для генерации оповещения. или оштрафовать DON узлов, убрав в контракте косую черту. Этот последний подход вводит проблема разработки стимулов аналогична проблеме для конкретных фидов oracle и может основываться на Наша работа описана в разделе 9.Обеспечение соблюдения соглашений об уровне обслуживания: Хотя DON не обязательно предназначены для работать бессрочно, важно, чтобы они придерживались соглашений об уровне обслуживания (SLA). со своими пользователями. Базовое соблюдение SLA возможно в основной цепочке. Например, Узлы DON могут взять на себя обязательство поддерживать DON до определенной даты или предоставить предварительное уведомление о прекращении обслуживания (например, уведомление за три месяца). Контракт на MAINCHAIN может обеспечить соблюдение базового криптоэкономического соглашения об уровне обслуживания. Например, договор SLA может сократить внесенные на счет DON средства, если контрольные точки не предоставляются с необходимой периодичностью. Пользователь может внести средства и оспорить DON чтобы доказать, что контрольная точка правильно представляет последовательность допустимых блоков (в некотором смысле аналог, напр. [141]). Конечно, производство блоков не равносильно транзакции. обработки, но договор SLA также может служить для обеспечения соблюдения последнего. Например, в совместимая с устаревшими версиями FSS, в которой транзакции извлекаются из мемпула (см. раздел 5.2), транзакции в конечном итоге извлекаются и помещаются в цепочку. Пользователь может доказать DON должностное преступление, предоставив в договор SLA транзакцию, которая был добыт, но не передан DON для обработки целевым контрактом в течение соответствующего интервала времени.15 Также возможно доказать существование и наказать более детальные SLA. сбои, в том числе ошибки в вычислениях с использованием исполняемых файлов (например, с помощью механизмов для доказательства правильности транзакций состояния вне сети, описанных в разделе 6.3) или невозможности запуска исполняемые файлы на основе инициаторов, видимых на DON, невозможность передачи данных на DON на MAINCHAIN своевременно и так далее.

Экономика и криптоэкономика

Чтобы сеть Chainlink обеспечила надежную безопасность в рамках децентрализованной модели доверия, важно, чтобы узлы в совокупности демонстрировали правильное поведение, то есть они придерживались в большинстве случаев именно по протоколам DON. В этом разделе мы обсуждаем подходы помочь принудить к такому поведению посредством экономических стимулов, то есть криптоэкономических стимулы. Эти стимулы делятся на две категории: явные и неявные, реализуемые соответственно через staking и возможность будущих комиссий (FFO). Ставки: В размещении ставок в Chainlink, как и в других системах blockchain, участвуют участники сети, то есть узлы oracle, которые вносят заблокированные средства в форме LINK token. Эти средства, которые мы также называем долей или явной долей, являются явным стимулом. Они подлежат конфискации в случае отказа узла или должностного преступления. В контексте blockchain эту процедуру часто называют слэшингом. Однако размещение по узлам oracle в Chainlink принципиально отличается от staking. validators в запрещенных blockchains. Валидаторы могут вести себя неправильно, искажая или состязательно заказывая транзакции. Базовый протокол консенсуса в 15Поскольку пользователи могут заменять транзакции в мемпуле, необходимо позаботиться о том, чтобы обеспечить правильное соответствие между добытыми и отправленными DON транзакциями.Однако без разрешения blockchain используются строгие правила проверки блоков и криптографические примитивы, чтобы предотвратить validator от генерации недействительных блоков. Напротив, программная защита не может предотвратить создание мошеннической сети oracle недействительные отчеты. Причина в ключевом различии между двумя типами систем: проверка транзакций в blockchains является свойством внутренней согласованности, а корректность отчетов oracle по blockchain является свойством внешних, т. е. данных вне сети. Мы разработали предварительный механизм staking для сети Chainlink на основе по интерактивному протоколу между узлами oracle, которые могут использовать внешние данные. Это Механизм создает финансовые стимулы для правильного поведения, используя явные вознаграждения и штрафы (резкая мера). Поскольку механизм является экономичным, он предназначен для предотвращения коррупция со стороны противника, который использует финансовые ресурсы для повреждения узлов посредством взяточничество. (Такой противник носит очень общий характер и распространяется, например, на узлы, сотрудничающие извлечь пользу из их коллективного плохого поведения.) Разработанный нами механизм Chainlink staking обладает некоторыми мощными и новыми возможностями. функции.16 Основной такой особенностью является суперлинейное staking воздействие (в частности, квадратичное). Противник должен иметь ресурсы, значительно превышающие депонированные средства узлов в чтобы разрушить механизм. Наш механизм staking дополнительно обеспечивает защиту от более сильного противника, чем считалось ранее в аналогичных системах, а именно: противник, который может создавать взятки, обусловливающие будущее поведение узлов. Кроме того, мы обсудим, как Chainlink такие инструменты, как DECO, могут помочь укрепить нашу staking механизм, способствующий правильному вынесению решений в случае неправильного поведения узла. Возможность будущих комиссий (FFO): Несанкционированные blockchains — как PoW и разнообразие PoS — сегодня критически полагаются на то, что мы называем неявными стимулами. Это экономические стимулы для честного поведения, которые вытекают не из явного вознаграждения, а из от самого участия в платформе. Например, сообщество майнеров Bitcoin не заинтересовано в организации атаки 51% из-за риска подорвать доверие к Bitcoin, снижая его ценность и, как следствие, подрывая ценность их коллектива. капитальные вложения в горнодобывающую инфраструктуру [150]. Сеть Chainlink извлекает выгоду из аналогичного неявного стимула, который мы называем как возможность будущей платы (FFO). Узлы Oracle с хорошей историей производительности или репутация привлекает комиссию от пользователей. Неправильное поведение узла oracle ставит под угрозу будущее комиссий и, таким образом, наказывает узел альтернативными издержками с точки зрения потенциальных доход, полученный за счет участия в сети. По аналогии с явной ставкой, FFO можно рассматривать как форму скрытой заинтересованности, стимула к честному поведению, которое исходит из общей выгоды от поддержания доверия к платформе, на которой зависит бизнес операторов узлов, т. е. положительная производительность и репутация сеть. Этот стимул присущ сети Chainlink, но не выражен явно. протоколы. В Bitcoin поддержание стоимости операций по добыче полезных ископаемых, как указано выше. 16Описываемый здесь механизм staking в настоящее время предназначен только для обеспечения доставки правильных отчетов. по сетям oracle. Мы ожидаем, что в будущей работе мы расширим его, чтобы обеспечить правильное выполнение многих другие функции, которые предоставит DONs.аналогичным образом можно рассматривать как форму неявной ставки. Подчеркиваем, что FFO уже существует в Chainlink и помогает защитить сеть. сегодня. Нашим основным вкладом в дальнейшее развитие Chainlink будет принципиальный, эмпирически обоснованный подход к оценке неявных стимулов, таких как FFO, через то, что мы называем системой неявных стимулов (IIF). Чтобы оценить такие величины, как возможность будущих комиссий узлов, IIF будет постоянно опираться на комплексную данные о производительности и платежах, собранные сетью Chainlink. Такие оценки позволит параметризовать системы staking на основе IIF, что отражает стимулы узлов с большей точностью, чем текущие эвристические и/или статические модели. Итак, подведем итог: два основных экономических стимула для правильного узла oracle. поведение в развивающейся сети Chainlink будет: • Стейкинг (депонированная ставка) о Явный стимул • Возможность будущих комиссий (FFO) о Неявный стимул Эти две формы стимулирования дополняют друг друга. Узлы Oracle могут одновременно участвуйте в протоколе Chainlink staking, получайте постоянный доход от пользователей и коллективно извлекать выгоду из их постоянного хорошего поведения. Таким образом, оба стимула способствовать криптоэкономической безопасности, обеспечиваемой сетью oracle. Кроме того, эти два стимула могут усиливать и/или компенсировать друг друга. Например, новый оператор oracle без истории работы и потока доходов может сделать ставку большое количество ССЫЛОК как гарантия честного поведения, тем самым привлекая пользователей и сборы. И наоборот, устоявшийся оператор oracle с длинным, относительно безошибочным история производительности может взимать значительную плату с большой базы пользователей и, таким образом, полагаться на в большей степени влияет на FFO как на форму скрытого стимула. В общем, подход, который мы здесь рассматриваем, нацелен на определенное количество oracle-сети. ресурс для создания максимально возможных экономических стимулов в Chainlink для рационального агенты — то есть узлы, максимизирующие свою финансовую полезность — вести себя честно. Поставь другой Таким образом, цель состоит в том, чтобы максимизировать финансовые ресурсы, необходимые противнику для нападения. сеть успешно. Сформулировав протокол staking математически хорошо определяемую экономическую безопасность, а также используя IIF, мы стремимся измерить силу Стимулы Chainlink как можно точнее. Создатели полагающихся контрактов будут затем сможете с большой уверенностью определить, соответствует ли сеть oracle требуемые уровни криптоэкономической безопасности. Благотворный цикл экономической безопасности: Стимулы, которые мы обсуждаем в этом разделе, staking и FFO, имеют влияние, выходящее за рамки укрепления безопасности DONс. Они обещают создать то, что мы называем благотворным циклом экономической безопасности. Суперлинейное staking воздействие (и другие эффекты масштаба) приводят к снижению эксплуатационных расходов. стоимость по мере роста безопасности DON. Более низкая стоимость привлекает к DON дополнительных пользователей,повышение пошлин. Рост комиссий продолжает стимулировать рост сеть, которая увековечивает благотворный цикл. Мы считаем, что благотворный цикл экономической безопасности является лишь одним из примеров экономия масштаба и сетевой эффект, среди прочего, которые мы обсудим позже в этом разделе. Организация раздела: Стейкинг представляет собой заметные технические и концептуальные проблемы для мы разработали механизм с новыми функциями. Таким образом, ставка будет наше основное внимание в этом разделе. Мы даем обзор подхода staking, который мы представляем в этой статье, в разделе 9.1, а затем подробно обсуждаем его в разделах с 9.2 по 9.5. Представляем МКФ в разделе 9.6. Мы представляем сводный обзор сетевых стимулов Chainlink в разделе 9.7. В разделе 9.8 мы обсуждаем благотворный цикл экономической безопасности, который предлагаемый нами подход staking может принести в сети oracle. Наконец, мы кратко опишем другие потенциальные возможности. влияет на рост сети Chainlink в разделе 9.9. 9.1 Обзор ставок Как отмечалось выше, конструкция механизма staking, которую мы здесь представляем, включает интерактивный протокол между узлами oracle, позволяющий разрешать несоответствия в представление внешних данных. Целью стейкинга является обеспечение честного поведения рациональных узлов oracle. Таким образом, мы можем смоделировать атаку противника на протокол staking как взяточник: стратегия злоумышленника состоит в том, чтобы повредить узлы oracle, используя финансовые стимулы. Злоумышленник может в перспективе получить финансовые ресурсы от успешного взлома с отчетом oracle, например, предложить разделить полученную прибыль с поврежденными узлами. При разработке механизма staking мы преследуем одновременно две амбициозные цели: 1. Сопротивление сильному противнику. Механизм staking предназначен для защиты oracle сети против широкого класса противников, способных на сложные, стратегии условного подкупа, включая предполагаемое взяточничество, в рамках которого предлагаются взятки oracle лицам, личность которых устанавливается постфактум (например, предлагает взятки oracle выбраны случайным образом для оповещения с высоким приоритетом). В то время как другие конструкции oracle рассмотрели узкий набор атак без полных возможностей реалистичного противник, насколько нам известно, состязательный механизм, который мы вводим здесь впервые подробно рассмотрен широкий набор стратегий взяточничества и показано сопротивление в этой модели. Наша модель предполагает, что узлы, помимо атакующего, экономически рациональны (в отличие от честных), и мы предполагаем существование источник истины, который непомерно дорог для обычного использования, но доступен в случае разногласий (подробнее обсуждается ниже). 2. Достижение сверхлинейного воздействия staking: Наша цель — обеспечить, чтобы сеть oracle, состоящая из рациональных агентов, сообщала честно даже при наличии злоумышленника с суперлинейным бюджетомв общей ставке, внесенной всей сетью. В существующих системах staking, если каждый из n узлов ставит $d, злоумышленник может дать надежную взятку, требующую что узлы ведут себя нечестно в обмен на оплату чуть более \(d to each node, using a total budget of about \)дн. Это уже высокая планка, так как злоумышленник должен иметь ликвидный бюджет порядка совокупных депозитов все участники сети. Наша цель – еще более высокая степень экономической безопасности. чем это уже существенное препятствие. Мы стремимся разработать первую систему staking. который может обеспечить безопасность для обычного злоумышленника с суперлинейным бюджетом в n. Хотя практические соображения могут привести к меньшему воздействию, как мы обсудим ниже, наш предварительный проект обеспечивает состязательное требование к бюджету, превышающее $dn2/2, т. е. квадратичное по n масштабирование, что делает взяточничество практически непрактичным даже когда узлы ставят лишь умеренные суммы. Достижение этих двух целей требует инновационного сочетания системы стимулирования. и криптография. Ключевые идеи: Наш staking подход основан на идее, которую мы называем сторожевым приоритетом. Отчет, созданный сетью Chainlink oracle и отправленный проверяющему контракту. (например, о цене актива) агрегируется из отдельных отчетов, предоставленных участвующими узлами (например, путем взятия медианы). Обычно соглашение об уровне обслуживания (SLA). определяет допустимые границы отклонения для отчетов, т. е. насколько отчет узла может отклоняться от сводного отчета и насколько далеко следует разрешить совокупному отчету отклоняться от истинного значения и считаться правильным. В нашей системе staking для данного раунда отчетности каждый узел oracle может действовать как сторожевой таймер, который подает предупреждение, если считает, что сводный отчет неверен. В каждом отчетном раунде, каждому узлу oracle назначается общедоступный приоритет, который определяет порядок, в котором будет обрабатываться его предупреждение (если таковое имеется). Наш механизм нацелен на вознаграждение концентрация, а это означает, что сторожевой таймер с наивысшим приоритетом, поднявший тревогу, получает вся награда получена за счет конфискации депозитов неисправных узлов. Наша система staking включает два уровня: первый, уровень по умолчанию, и второй, стопорный ярус. Первый уровень — это сама сеть oracle, набор из n узлов. (Для простоты мы предполагаем, что n нечетно.) Если большинство узлов сообщают о неверных значениях, сторожевой таймер в Первый уровень сильно заинтересован в поднятии тревоги. Если возникает предупреждение, отчетность Решение сети затем передается на второй уровень — дорогостоящую систему максимальной надежности, которая может быть указана пользователем в соглашении об уровне обслуживания сети. Это может быть система, состоящая, например, только из узлов с сильными исторические оценки надежности или тот, который имеет на порядок больше oracles, чем первый ярус. Кроме того, как обсуждалось в разделе 9.4.3, DECO или Town Crier могут служить в качестве мощных инструментов, помогающих обеспечить эффективное и убедительное судебное решение на втором уровне. Таким образом, для простоты мы предполагаем, что эта система второго уровня дает правильный отчет. ценность. Хотя может показаться привлекательным просто полагаться на второй уровень для создания всех отчетов, Преимущество нашей конструкции заключается в том, что она последовательно обеспечивает свойства безопасности, присущиесистемы второго уровня, при этом в типичном случае оплачиваются только эксплуатационные расходы система первого уровня. Приоритет сторожевого таймера приводит к сверхлинейному воздействию staking следующим образом: если сеть первого уровня oracle выдает неверный результат и несколько сторожевых узлов предупреждение, механизм стимулирования staking вознаграждает сторожевого таймера с наивысшим приоритетом более $dn/2 было получено из депозитов (большинства) неправильно работающих узлов. таким образом, вся награда концентрируется в руках этого единственного сторожевого пса, который, следовательно, определяет минимум, который противник должен пообещать потенциальному сторожевому псу стимулировать его не предупреждать. Поскольку наш механизм гарантирует, что каждый oracle получит шанс действовать в качестве сторожевого пса, если сторожевые псы с более высоким приоритетом приняли взятки (и решил не предупреждать), поэтому противник должен предложить взятку в размере, превышающем $dn/2 для каждого узла, чтобы предотвратить появление каких-либо предупреждений. Поскольку имеется n узлов, то необходимый бюджет противника для успешной взятки составляет более 2/2 долларов США, что квадратичен по числу n узлов в сети. 9.2 Фон Наш подход к staking основан на исследованиях в области теории игр и механизмов. дизайн (MD) (ссылку на учебник см. [177]). Теория игр – это математически формализованное исследование стратегического взаимодействия. В этом контексте игра является моделью такого взаимодействие, обычно в реальном мире, которое кодифицирует набор действий, доступных участники игры, называемые игроками. В игре также определяются выигрыши, получаемые отдельными игроками — награды, которые зависят от выбранных игроком действий и действия других игроков. Пожалуй, самый известный пример игры, изучаемой в игре. теория – это «Дилемма заключённого» [178]. Теоретики игр обычно стремятся понять равновесие или равновесия (если таковые имеются), представленные в данной игре. Равновесие – это набор стратегий (по одной для каждого игрока), при котором ни один игрок не может получить более высокую выгоду за счет одностороннего отклонения от своей стратегии. Между тем, проектирование механизмов — это наука о разработке стимулов, позволяющих равновесие взаимодействия (и связанной с ним игры) обладает некоторым желательным свойством. MD можно рассматривать как обратную теорию игр: канонический вопрос в игре. Теория такова: «Каким будет равновесие при наличии стимулов и модели?» В МД, вместо этого возникает вопрос: «Какие стимулы приведут к игре с желаемым равновесием?» Типичная цель разработчика механизма — создать механизм, «совместимый со стимулами», то есть, чтобы участники механизма (например, аукциона или другой информации) система сбора информации [228]) стимулируются сообщать правду по какому-либо вопросу (например, как насколько они ценят тот или иной предмет). Аукцион Викри (вторичная цена), возможно, является самый известный механизм, совместимый со стимулами, при котором участники подают запечатанные заявки за предмет, и участник, предложивший самую высокую цену, выигрывает этот предмет, но платит вторую по величине цену [214]. Криптоэкономика – это предметно-ориентированная форма MD, в которой используются криптографические методы. методы создания желаемого равновесия в децентрализованных системах. Взяточничество и сговор создают серьезные проблемы во всей области медицины. Почти все механизмы нарушаются при наличии сговора, определяемого как побочные контракты.между сторонами, участвующими в механизме [125, 130]. Взяточничество, при котором внешняя сторона вводит в игру новые стимулы, представляет собой еще более серьезную проблему. чем сговор; сговор можно рассматривать как частный случай взяточничества среди диких животных. участники. Системы блокчейн часто можно представить как игры с денежными (криптовалютными) выигрышами. Простой пример — майнинг Proof-of-Work: у майнеров есть пространство действий. в котором они могут выбрать hashскорость добычи блоков. Выигрыш от майнинга — это гарантированное отрицательное вознаграждение (стоимость электроэнергии и оборудования) плюс стохастический доход. положительное вознаграждение (субсидия майнингу), которое зависит от количества других активных майнеров [106, 172] и комиссии за транзакции. Краудсорсинговые oracle, такие как SchellingCoin [68], являются еще одним примером: пространство действий представляет собой набор возможных отчетов, которые oracle может отправить, в то время как выплата — это вознаграждение, определенное механизмом oracle, например, оплата может зависеть о том, насколько отчет oracle близок к медиане других отчетов [26, 68, 119, 185]. Игры на блокчейне открывают широкие возможности для сговора и взяточничества; действительно, smart contracts могут даже способствовать таким атакам [96, 165]. Пожалуй, самый известный Атака со взяточничеством на краудсорсинговые oracles — это атака p-plus-epsilon [67]. Эта атака возникает в контексте механизма, подобного SchellingCoin, в котором игроки отправляют отчеты с логическими значениями (т. е. ложные или истинные) и получают вознаграждение p, если они согласны с представление большинства. При атаке p-plus-epsilon злоумышленник достоверно обещает: например, платить пользователям $p + ϵ за ложное голосование тогда и только тогда, когда мнение большинства верно. Результатом является равновесие, в котором все игроки заинтересованы сообщать ложные сведения. независимо от того, что делают другие игроки; следовательно, взяткодатель может побудить узлы через обещанную взятку сообщить ложь, фактически не уплатив взятку (!). Однако изучение других стратегий взяточничества в контексте oracle, особенно oracle, которые не являются краудсорсинговыми, ограничивалось довольно слабыми состязательными действиями. модели. Например, в рамках PoW исследователи изучили зависящие от результата результаты. взятки, то есть взятки выплачиваются только в том случае, если целевое сообщение успешно подвергается цензуре и не появляются в блоке независимо от действий отдельного майнера [96, 165]. В случае из oracles, однако, кроме атаки p-plus-epsilon, нам известны только работы в строго ограниченная модель взяточничества, при которой взяткодатель передает взятку при условии действие отдельного игрока, а не конечный результат. Здесь мы набросаем схемы механизмов сбора информации, которые остаются стимулирующими. совместимы даже в модели сильного состязания, как описано в следующем подразделе. 9.3 Допущения моделирования В этом подразделе мы объясним, как мы моделируем поведение и возможности игроков в наша система, в частности узлы первого уровня oracle, узлы второго уровня (решение) слой и противники.9.3.1 Модель стимулирования первого уровня: рациональные участники Многие blockchain системы полагаются на безопасность, предполагая некоторое количество честных участвующие узлы. Узлы считаются честными, даже если они следуют протоколу. когда это не в их финансовых интересах. Обычно системы Proof-of-Work для честности требуется большая часть мощности hash, для честности системы Proof-of-Stake обычно требуют 2/3 или более всей участвующей доли, и даже системы уровня 2, такие как Для арбитража [141] требуется хотя бы один честный участник. При моделировании нашего механизма staking мы делаем гораздо более слабое предположение. (Быть ясные, более слабые предположения означают более сильные свойства безопасности и поэтому предпочтительнее.) Мы предполагаем, что злоумышленник испортил, то есть контролирует, некоторые (меньшинство) доля узлов первого уровня oracle. Остальные узлы мы моделируем не как честных агентов, а как рациональные максимизаторы ожидаемой полезности. Эти узлы действуют исключительно в соответствии с корыстными финансовыми стимулами, выбирая действия, которые приводят к ожидаемому финансовому результату. выигрыш. Например, если узлу предлагается взятка, превышающая вознаграждение, полученное в результате честное поведение, он возьмет взятку. Примечание о состязательных узлах: В соответствии с общепринятым для в децентрализованных системах мы предполагаем, что все узлы рациональны, т.е. стремятся максимизировать чистый доход, а не контролироваться злонамеренным противником. Наши претензии, однако… в частности, суперлинейное или квадратичное staking воздействие — сохраняется асимптотически при условии что набор узлов, управляемых состязательно, не превышает (1/2 −c)n для некоторых положительных постоянный в. 9.3.2 Модель принятия решений второго уровня: правильность по предположению Напомним, что важная функция нашего механизма staking, помогающая обеспечить безопасность против рациональных узлов — это его система второго уровня. В предлагаемом нами механизме staking любой oracle может выдать предупреждение, указывающее, что он считает, что выходные данные механизма неверны. Оповещение приводит к высокому доверию система второго уровня активирует и сообщает правильный результат. Таким образом, ключевое моделирование Требованием нашего подхода является правильное вынесение решения, т. е. правильная отчетность со стороны система второго уровня. Наша модель staking предполагает систему второго уровня, которая действует как неподкупный и максимально надежный источник истины. Такая система, скорее всего, будет дорогой и медленной, и, следовательно, не подходит для использования в типичном случае. Однако в равновесном случае, т. е. когда система первого уровня работает правильно, система второго уровня не будет задействована. Вместо этого его существование повышает безопасность всей системы oracle, предоставляя высоконадежный стопор обратного хода. Использование высоконадежного и дорогостоящего уровня принятия решений напоминает процесс апелляции. в основе большинства судебных систем. Это также уже распространено в дизайне oracle. системы, например, [119, 185]. Кратко обсудим подходы к реализации второго эшелона. в нашем механизме в разделе 9.4.3.Наш протокол staking использует предполагаемое правильное решение системы второго уровня как реальную угрозу для обеспечения правильной отчетности узлов oracle. Протокол конфискует часть или всю долю узлов oracle, которые генерируют отчеты, идентифицированные систему второго уровня как неправильную. Таким образом, узлы Oracle удерживаются от неправильного поведения. в результате финансового штрафа. Этот подход по своей сути аналогичен тому, который используется в оптимистичные rollups, например, [141, 10]. 9.3.3 Состязательная модель Наш механизм staking предназначен для получения правдивой информации и обеспечения безопасности от широкого, четко определенного класса злоумышленников. Это улучшает предыдущие работы, которые либо опускают явную модель состязания, либо фокусируются на узких подклассах противников, например, противнике p-плюс-эпсилон, обсуждаемом выше. Наша цель — разработать staking механизм с формально доказанной безопасностью против всего спектра возможных противников. придется столкнуться на практике. Мы моделируем нашего противника как имеющего фиксированный (параметрируемый) бюджет, обозначаемый $Б. Злоумышленник может индивидуально и конфиденциально общаться с каждым oracle в сети и может тайно предложить любому лицу oracle гарантированную выплату взятки зависит от публично наблюдаемых результатов работы механизма. Результаты, определяющие взятки могут включать, например, сумму, сообщенную oracle, любые публичные сообщения отправленное любым oracle механизму (например, предупреждение), значения, сообщаемые другими oracles и значение, выводимое механизмом. Ни один механизм не может защитить от злоумышленника с неограниченными возможностями. Поэтому мы считаем некоторые виды поведения нереалистичными или выходящими за рамки рассмотрения. Мы предполагаем, что наш злоумышленник не может взломать стандартные криптографические примитивы и, как отмечалось выше, имеет фиксированный (если потенциально большой) бюджет $B. Далее мы предполагаем, что противник не контролирует связь в сети oracle, в частности, что она не может существенно задерживать трафик между узлами первого и/или второго уровня. (Может ли противник наблюдать такое общение, зависит от конкретного механизма, как мы объясним ниже.) Однако неформально, как отмечалось выше, мы предполагаем, что злоумышленник может: (1) Коррумпировать часть oracle узлов ((1/2 -c)-доля для некоторой константы c), т.е. полностью контролировать им, и (2) предлагать взятки любым желаемым узлам с гарантированным условием выплаты. на исходы, указанные противником, как описано выше. Хотя мы не предлагаем формальную модель или полную классификацию всех сил противника, широкий спектр возможностей взяточничества, описанный в этом документе, здесь приведены примеры видов взяточники, охваченные нашей моделью. Для простоты мы предполагаем, что oracles выдают логические значения. отчеты, правильное значение которых (w.l.o.g.) истинно, и конечный результат рассчитывается как совокупность этих отчетов, которая будет использоваться получателем smart contract. Взяткодателя цель состоит в том, чтобы конечный результат был неверным, т. е. ложным. • Безусловный взяткодатель: Взяткодатель предлагает взятку $b любому oracle, сообщившему ложь. • Вероятностный взяткодатель: Взяткодатель предлагает взятку $b с некоторой вероятностью q любому oracle. это сообщает ложь.• Взяткодатель, обусловленный ложным результатом: Взяткодатель предлагает взятку $b любому oracle, сообщившему ложный результат, при условии, что конечный результат окажется ложным. • Взяткодатель без предупреждения: Взяткодатель предлагает взятку $b любому oracle, который сообщает false, пока не будет выдано предупреждение. • Взяткодатель p-plus-epsilon: Взяткодатель предлагает взятку $b любому oracle, который сообщает ложную информацию как пока большинство oracle не сообщают ложных сведений. • Потенциальный взяткодатель: Взяткодатель предлагает взятку в размере b долларов заранее тому, кто будет выбран oracle. для рандомизированной роли и сообщает ложь. В предложенном нами протоколе staking все узлы действуют как потенциальные сторожевые псы, и мы можем показать, что рандомизация Приоритеты надзорных органов не способствуют возможному взяточничеству. Многие системы проверки работоспособности, proof-of-stake и разрешенные системы подвержены потенциальному взяточничество, однако, что показывает важность рассмотрения его в нашей враждебной борьбе. модель и обеспечение устойчивости наших протоколов staking к ней. См. Приложение E. для более подробной информации. 9.3.4 Насколько достаточно криптоэкономической безопасности? Рациональный противник будет тратить деньги на атаку системы только в том случае, если он сможет получить прибыль. превышает его расходы. Таким образом, для нашей состязательной модели и предлагаемого staking $B можно рассматривать как меру потенциальной прибыли, которую может получить противник. извлечь выгоду из использования smart contracts, повредив сеть oracle и вызвав ее для создания неправильного отчета или набора отчетов. При принятии решения о том, будет ли сеть oracle предлагает достаточную степень криптоэкономической безопасности для своих целей, пользователь должен оценить сеть с этой точки зрения. Мы ожидаем, что для вероятных противников в практических условиях $B обычно будет существенно меньше, чем общая сумма активов в доверительном управлении smart contracts. В большинстве случаев это противнику невозможно извлечь эти активы в их совокупности. 9.4 Механизм ставок: эскиз Здесь мы представляем основные идеи и общую структуру механизма staking, который мы в настоящее время рассматривают. Для простоты изложения мы опишем простой, но медленный процесс. (многораундовый) протокол в этом подразделе. Заметим, однако, что эта схема вполне практичный. Учитывая экономические гарантии, обеспечиваемые этим механизмом, т. е. штрафы и, как следствие, стимулы против неисправных узлов, многие пользователи могут захотеть принимайте отчеты оптимистично. Другими словами, такие пользователи могут принимать отчеты до потенциальное судебное решение второго уровня. Пользователи, не желающие оптимистично принимать отчеты, могут подождать, пока протокол выполнение прекращается, т. е. до тех пор, пока не произойдет потенциальная эскалация на второй уровень. Это, однако может существенно замедлить время подтверждения отчетов. Поэтому мы краткоРисунок 15: Схема схемы staking с оповещением. В этом примере 1⃝большинство узлов повреждены/подкуплены и выдают неправильное значение ˜r, а не правильное отчетное значение р. Сторожевой узел 2⃝ отправляет предупреждение комитету второго уровня, который 3⃝определяет и выдает правильное значение отчета r, что приводит к повреждению узлов конфисковывая свои депозиты — каждый $d передается сторожевому узлу 4⃝. обрисовать некоторые оптимизации, которые приводят к более быстрому (за один раунд), хотя и несколько большему комплексное проектирование в разделе 9.5. Напомним, что первый уровень нашего механизма staking состоит из базового oracle сама сеть. Основная структура нашего механизма, как описано выше, заключается в том, что в каждом раунде каждый узел может действовать как «сторожевой таймер» с некоторым приоритетом и, таким образом, иметь возможность поднять предупреждение, если механизм получает неправильный выходной сигнал ˜r, а не правильный один р. Это предупреждение приводит к разрешению второго уровня, которое, как мы предполагаем, приводит к правильному результату. отчет. Узлы с неправильными отчетами наказываются в том смысле, что их ставки разрезан и вручен сторожевым собакам. Эта базовая структура распространена в системах oracle, как, например, в [119, 185]. Ключевое нововведение в нашей конструкции, кратко упомянутое выше, заключается в том, что каждый узел уделил особое внимание при выборе потенциальных наблюдателей. То есть сторожевые псы предоставляются возможности для оповещения в приоритетной последовательности. Напомним, что если узел имеет наивысший приоритет для поднятия тревоги, он получает сокращенный депозит $d за каждое некорректное поведение узла, в общей сложности более \(dn/2 = \)d × n/2, поскольку неправильный отчет подразумевает большинство неисправных узлов. Следовательно, противник должен выплатить хотя бы эту награду подкупить произвольный узел. Таким образом, чтобы подкупить большинство узлов, противник должен заплатить крупная взятка большинству узлов, а именно строго более $dn2/2. Схематически показано, как работает оповещение и эскалация сторожевого таймера, на рис. 15.9.4.1 Дополнительные сведения о механизме Система противодействия взяточничеству, которую мы сейчас опишем более подробно, представляет собой упрощенную схему двухъярусную конструкцию, которую мы собираемся построить. Основное внимание мы уделим описанию сеть первого уровня (далее просто «сеть», если это ясно из контекста) вдоль со своим механизмом стимулирования и процедурой перехода на второй уровень. Рассмотрим сеть Chainlink, состоящую из n узлов oracle, которые отвечают за регулярно (например, раз в минуту), сообщая логическое значение (например, капитализация BTC превышает капитализацию ETH). В рамках механизма staking узлы должен внести два залога: залог $d, который может быть сокращен в случае разногласий. с большинством и сторожевым депозитом в размере $dw, подлежащим сокращению в случае неисправности эскалация. Мы предполагаем, что узлы не могут копировать материалы других узлов, например, посредством схемы фиксации-раскрытия, как описано в разделе 5.3. В каждом раунде сначала узлы зафиксировать свой отчет, и как только все узлы зафиксируют (или истечет тайм-аут), узлы раскрывают свои отчеты. Для каждого создаваемого отчета каждому узлу также назначается сторожевой приоритет от 1 до n, выбираемый случайным образом, причем 1 является высшим приоритетом. Этот приоритет позволяет концентрация вознаграждения в руках одного сторожевого пса. После того, как все отчеты станут публичными, наступает фаза оповещения. В течение последовательности из n (синхронных) раундов узел с приоритет i имеет возможность предупредить в раунде i. Рассмотрим возможные исходы работы механизма после выявления узлов. их отчеты. Опять же, предполагая двоичный отчет, предположим, что правильное значение равно true и неправильный — ложный. Предположим также, что механизм первого уровня выводит вывод значений большинства по узлам в качестве итогового отчета r. В этом механизме возможны три возможных результата: • Полное согласие. В лучшем случае узлы находятся в полном согласии: все узлы доступны и предоставили своевременный отчет с тем же значением r (либо истинное или ложь). В этом случае сети нужно только перенаправить r на соответствующие контракты. и вознаградить каждый узел фиксированной выплатой за раунд $p, которая намного меньше чем $d. • Частичное согласие: возможно, что некоторые узлы отключены или существуют разногласия по поводу того, какое значение является правильным, но большинство узлов сообщают истинное значение и только меньшинство сообщает ложь. Этот случай также прост. Значение большинства (true) вычисляется, в результате чего формируется правильный отчет r. Все узлы, сообщившие r, являются вознаграждены $p, в то время как oracles, которые сообщили неправильно, получили свои депозиты незначительно снижена, например, на 10 пенсов. • Оповещение: если сторожевой таймер считает, что выходные данные сети неверны, он публично запускает оповещение, передавая механизм в сеть второго уровня. Тогда возможны два результата: – Правильное предупреждение: если сеть второго уровня подтверждает, что выходные данныеРисунок 16. Увеличение затрат взяткодателей за счет концентрированных вознаграждений за оповещение. Подкуп противник должен подкупить каждый узел большей наградой, чем он может получить, предупредив (отображается красной полосой). Если вознаграждения за оповещения являются общими, то это вознаграждение может быть относительно маленький. Вознаграждения за концентрированные оповещения увеличивают вознаграждение, которое может получить любой отдельный узел. получить (высокая красная полоса). Следовательно, общая сумма выплаты противником за реальную взятку (серые области) намного больше при концентрированных, чем при общих вознаграждениях за оповещения. сеть первого уровня была неправильной, сторожевой узел, оповещающий о тревоге, получает вознаграждение состоит из всех сокращенных депозитов и, следовательно, превышает $dn/2. – Ошибочное предупреждение: если oracle второго и первого уровней согласны, эскалация считается неисправным, и узел оповещения теряет свой депозит в размере $dw. В случае оптимистического принятия отчетов сторожевые оповещения не вызывают любые изменения в исполнении полагающихся контрактов. Для контрактов, рассчитанных на ожидание потенциальный арбитраж со стороны комитета второго уровня, оповещения наблюдателя задерживаются, но не замораживать исполнение контракта. В контрактах также возможно указать аварийное переключение DON на периоды вынесения решения. 9.4.2 Влияние квадратичного стейкинга Возможность каждого узла действовать в качестве сторожевого таймера в сочетании со строгим приоритетом узла. обеспечение концентрированного вознаграждения позволяет механизму достигать квадратичного staking воздействие для каждого вида злоумышленника-подкупа, описанного в разделе 9.3.3. Напомним, что это конкретно в наших условиях означает, что для сети из n узлов, каждый из которых имеет депозит $d, успешный взяткодатель (любого из перечисленных выше типов) должен иметь бюджет, превышающий $дн2/2. Точнее, взяткодатель должен испортить как минимум (n+1)/2 узлов, поскольку взяткодатель должен испортить большинство из n узлов (по предположению, для нечетных n). Таким образом, сторожевой пес стоит на страже получите вознаграждение в размере $d(n + 1)/2. Следовательно, взяткодатель должен выплатить эту сумму каждомуузел, чтобы гарантировать, что ни один из них не действует как сторожевой таймер. Мы работаем над тем, чтобы формально показать, что если бюджет взяткодателя не превышает $d(n2 + n)/2, то идеальное равновесие в подыгре игры между взяточниками и oracles — другими словами, равновесие в любой момент во время игры – взяткодатель не дает взятку и каждый oracle честно сообщать о своих истинных значениях. Выше мы объяснили, как возможно, что успешный взяткодатель может потребовать бюджет значительно больше, чем сумма узловых депозитов. Чтобы проиллюстрировать это интуитивно понятный результат. На рис. 16 графически показано влияние вознаграждений за концентрированные оповещения. Как мы видим, если вознаграждение за предупреждение сторожевого пса, а именно депозиты подкупленных узлы, сообщающие ложь) — были разделены между всеми потенциальными оповещениями, общая сумма, любой отдельный узел оповещения, который мог ожидать, будет относительно небольшим, порядка $д. Взяткодатель, зная, что выплата на сумму более $d маловероятна, мог бы использовать условная взятка с ложным исходом, чтобы подкупить каждый из n узлов чуть более чем $d + ϵ. Как ни странно, на рис. 16 показано, что система, широко распределяющая вознаграждение, среди узлов, сигнализирующих об оповещении, гораздо слабее, чем тот, который концентрирует вознаграждение в в руках одного сторожевого пса. Пример параметров: Рассмотрим сеть (первого уровня) с n = 100 узлами, каждый из которых внесение \(d = \)20K. В эту сеть будет внесено в общей сложности 2 миллиона долларов, но быть защищен от взяточника с бюджетом \(100M = \)dn2/2. Увеличение количества oracles, конечно, более эффективно, чем увеличение $d, и может иметь драматический эффект: сеть с n = 300 узлами и депозитами \(d = \)20K будет защищена от взяточник с бюджетом до $900 млн. Обратите внимание, что система staking во многих случаях может защитить smart contract, представляющие большую ценность, чем предлагаемый уровень защиты от взяточничества. Это потому, что противник атака на эти контракты во многих случаях не может извлечь полную выгоду. Например, Контракт на основе Chainlink, обеспечивающий стоимость в 1 миллиард долларов США, может требовать только обеспечения от взяточник с ресурсами в 100 миллионов долларов, потому что такой противник может реально получить прибыль всего 10% от стоимости контракта. Примечание: Идея о том, что ценность сети может расти квадратично, выражена в широко известный закон Меткалфа [167, 235], который гласит, что ценность сети растет квадратично по числу связанных объектов. Однако закон Меткалфа возникает из-за роста числа потенциальных парных сетевых соединений, а это явление, отличное от того, которое лежит в основе квадратичного staking воздействия в нашем стимуле. механизм. 9.4.3 Реализация второго уровня Две эксплуатационные особенности облегчают реализацию второго уровня высокой надежности: (1) Вынесение решения второго уровня должно быть редким событием в сетях oracle и, следовательно, может быть значительно более затратным, чем нормальная эксплуатация первого уровня и (2) при условии, чтооптимистично принятые отчеты — или контракты, исполнение которых может ожидать арбитража — второй уровень не обязательно должен выполняться в реальном времени. Эти особенности приводят к появлению целого ряда варианты конфигурации второго уровня для удовлетворения требований конкретных DONs. В качестве примера подхода комитет второго уровня может состоять из узлов, выбранных DON (т. е. первого уровня) из самых долговечных и надежных узлов в Chainlink. сеть. Помимо значительного соответствующего опыта эксплуатации, операторы таких узлов имеют значительный неявный стимул в FFO, который мотивирует желание чтобы обеспечить высокую надежность сети Chainlink. Они также публично доступные истории производительности, которые обеспечивают прозрачность их надежности. Стоит отметить, что узлы второго уровня не обязательно должны быть участниками сети первого уровня. может выносить решения о неисправностях в нескольких сетях первого уровня. Узлы в данном DON могут заранее назначить и публично принять набор из n' таких узлы как составляющие комитет второго уровня для этого DON. Кроме того, DON узлы публикуют параметр k′ ≤n′, который определяет количество голосов второго уровня. требуется наказать узел первого уровня. Когда для данного отчета создается оповещение, члены второго уровня голосуют за правильность значений, предоставленных каждым узлов первого уровня. Любой узел первого уровня, получивший k' отрицательных голосов, теряет свой статус. депозиты на сторожевой узел. Из-за редкости вынесения судебного решения и возможности продления срока исполнения Как отмечалось выше, в отличие от первого уровня узлы второго уровня могут: 1. Получать высокую компенсацию за проведение судебного разбирательства. 2. Использовать дополнительные источники данных, помимо разнообразного набора, используемого первыми. 3. Полагаться на ручную и/или экспертную проверку и вмешательство, например, для выявления и согласовать ошибки в исходных данных и отличить честную ретрансляцию узла ошибочные данные и неправильно работающий узел. Мы подчеркиваем, что подход, который мы только что описали для выбора узлов второго уровня и политики, регулирующей вынесение решений, представляет собой лишь точку в большом проектное пространство возможных реализаций второго яруса. Наш механизм стимулирования предлагает полная гибкость в отношении реализации второго уровня. Таким образом, отдельные DON могут составляют и устанавливают правила для своих вторых уровней, отвечающие конкретным требованиям и ожидания участвующих узлов и пользователей. DECO и Town Crier как инструменты вынесения решения: Это важно для второго уровня. в нашем механизме, чтобы иметь возможность различать враждебные узлы первого уровня, которые намеренно создавать неверные отчеты и честные узлы первого уровня, которые непреднамеренно ретранслируйте данные, которые неверны в источнике. Только тогда второй уровень сможет реализовать сокращение, чтобы дестимулировать мошенничество, цель нашего механизма. ДЕКО и городской глашатай — это мощные инструменты, которые позволяют узлам второго уровня проводить это важное различие. надежно.Узлы второго уровня в некоторых случаях могут иметь возможность напрямую запрашивать используемый источник данных. узлом первого уровня или используйте раздел 7.1 ADO, чтобы проверить, является ли неправильный отчет возникло из-за неверного источника данных. Однако в других случаях узлы второго уровня могут отсутствовать. прямой доступ к источнику данных узла первого уровня. В таких случаях правильное решение будет кажутся невозможными или требуют полагаться на субъективное суждение. Предыдущий oracle системы разрешения споров полагались на неэффективные, увеличивающиеся раунды голосования для решения таких проблем. вызовы. Однако, используя DECO или Town Crier, узел первого уровня может доказать правильное поведение. к узлам второго уровня. (Подробную информацию об этих двух системах см. в разделе 3.6.2.) В частности, если узел второго уровня идентифицирует узел первого уровня как выдавший ошибочное значение отчета ˜r, узел первого уровня может использовать DECO или Town Crier для создания защищенных от несанкционированного доступа доказательств узлы второго уровня, которые правильно ретранслируют ˜r из источника (с поддержкой TLS). признан авторитетным DON. Крайне важно, что узел первого уровня может это сделать. без узлов второго уровня, требующих прямого доступа к источнику данных.17 Следовательно, правильное решение возможно в Chainlink для любого желаемого источника данных. 9.4.4 Неправильная отчетность о страховании Сильная устойчивость к взяточничеству, достигаемая с помощью нашего механизма staking, фундаментально опирается о сокращении средств, выделяемых оповещениям. Без денежного вознаграждения оповещения не имеют прямых стимулов отказываться от взяток. В результате, однако, сокращенные средства не доступен для компенсации пользователям, пострадавшим от неправильных отчетов, например, пользователям, которые теряют деньги когда неверные данные о цене передаются на smart contract. Предполагается, что неверные отчеты не представляют проблемы, если отчеты принимаются контракт только после потенциального судебного решения, т. е. действия второй инстанции. Как объяснено однако для достижения наилучших результатов контракты могут вместо этого полагаться на оптимистично относятся к механизму обеспечения правильной отчетности, а это означает, что они принимают отчеты до возможного вынесения судебного решения второго уровня. Действительно, такое оптимистичное поведение безопасно в нашей модели, предполагающей наличие рациональных противников, чьи бюджеты не превышают staking воздействие механизма. Пользователи, обеспокоенные маловероятным событием отказа механизма в результате: например, противники, обладающие огромными финансовыми ресурсами, могут захотеть использовать дополнительный уровень экономической безопасности в виде страхования от искажения информации. Мы знаем о несколько страховщиков уже намерены предлагать полисы такого типа, подкрепленные смарт-контрактами. для протоколов, защищенных Chainlink, в ближайшем будущем, в том числе с помощью инновационных механизмов, таких как DAOs, например, [7]. Наличие истории производительности для Chainlink узлы и другие данные об узлах, такие как суммы их долей, обеспечивают исключительно прочную основу для актуарной оценки риска, что позволяет определять ценовую политику. способами, которые недороги для держателей полисов, но устойчивы для страховщиков. 17С помощью Town Crier узлы первого уровня дополнительно могут локально генерировать аттестации. правильности отчетов, которые они выдают, и предоставляют эти подтверждения узлам второго уровня на по мере необходимости.Основные формы страхования от предоставления ложной информации могут быть реализованы надежным и эффективным способом с использованием smart contracts. Простой пример: параметрическое страхование. контрактные SCins могут автоматически компенсировать страхователям, если наш механизм стимулирования второй уровень идентифицирует ошибку в отчете, созданном на первом уровне. Пользователь U, желающий приобрести страховой полис, например создатель цели. договор SC, может подать запрос децентрализованному страховщику на сумму полиса миллион долларов по контракту. При утверждении U страховщик может установить постоянный (например, ежемесячный) премия в размере P в SCins. Пока U платит премию, ее полис остается активным. Если в SC произойдет сбой отчетности, результатом будет эмиссия пары (r1, r2) конфликтующих отчетов для SC, где r1 подписан первым уровнем нашего механизма и r2, соответствующий исправленный отчет, подписывается вторым уровнем. Если U предоставляет такую действительную пару (r1, r2) для SCins, контракт автоматически выплачивает ей миллион долларов при условии, что ее страховые взносы актуальны. 9,5 Однораундный вариант Протокол, описанный в предыдущем подразделе, требует, чтобы комитет второго уровня ждал n раундов, чтобы определить, подал ли сторожевой таймер предупреждение. Это Требование выполняется даже в оптимистическом случае, т. е. когда первый уровень функционирует. правильно. Для пользователей, не желающих принимать отчеты оптимистично, т.е. до потенциального вынесения судебного решения, задержка, связанная с таким подходом, будет недопустимой. По этой причине мы также изучаем альтернативные протоколы, требующие всего одного круглый. При таком подходе все узлы oracle отправляют секретные биты, указывающие, есть ли они хотят поднять тревогу. Затем комитет второго уровня проверяет эти значения в приоритетный порядок. В качестве грубого наброска такая схема может включать в себя следующее: шаги: 1. Отправка бита сторожевого таймера: каждый узел Oi секретно разделяет однобитовое значение сторожевого таймера. wi ∈{no alert, alert} среди узлов второго уровня для каждого генерируемого им отчета. 2. Анонимные подсказки. Любой узел oracle может отправить анонимную подсказку α в комитет второго уровня в том же раунде, в котором передаются биты сторожевого таймера. Этот наконечник α — это сообщение, указывающее, что для текущего отчета было создано предупреждение. 3. Проверка битов сторожевого таймера: комитет второго уровня выявляет сторожевой таймер узлов oracle. биты в порядке приоритета. Обратите внимание, что узлы не должны отправлять биты сторожевого таймера предупреждений, если они не предупреждают: в противном случае анализ трафика выявляет биты всех узлов. Протокол не показывает отсутствие предупреждения биты сторожевого таймера узлов с более высоким приоритетом, чем сторожевой таймер оповещения с наивысшим приоритетом. Обратите внимание: то, что обнаружено, идентично нашему протоколу n-раундов. Вознаграждения также распределяются идентично этой схеме, т. е. первый выявленный сторожевой таймер получает сокращенные депозиты узлов, представивших неверные отчеты.Использование анонимных подсказок позволяет комитету второго уровня оставаться неинтерактивным в тех случаях, когда не было подано никаких предупреждений, что снижает сложность коммуникации. в общем случае. Обратите внимание, что любой наблюдатель, который поднимает тревогу, имеет экономический стимул отправлять анонимную информацию: если информация не отправлена, вознаграждение не выплачивается никому. узел. Чтобы гарантировать, что отправитель Oi анонимной подсказки α не может быть идентифицирован с помощью злоумышленника на основе сетевых данных, анонимная подсказка может быть отправлена по анонимному канал, например, через Tor или, что более практично, через прокси через поставщика облачных услуг. Чтобы аутентифицировать подсказку как исходящую от O, Oi может подписать α, используя кольцевую подпись [39, 192]. В качестве альтернативы, чтобы предотвратить необъяснимые атаки типа «отказ в обслуживании» против комитета второго уровня со стороны вредоносного узла oracle, α может быть анонимным идентификатором с отзывная анонимность [73]. Этот протокол, хотя и практически достижим, имеет несколько сложную конструкцию. требования (которые мы изучаем пути снижения). Узлы первого уровня, например, должен напрямую взаимодействовать с узлами второго уровня, что требует ведения каталога. Необходимость в анонимных каналах и кольцевых подписях усложняет разработку. сложность схемы. Наконец, существует специальное требование доверия, которое кратко обсуждается. в примечании ниже. Поэтому мы также изучаем более простые схемы, которые все же достигают суперлинейное staking воздействие, но, возможно, меньше квадратичного, при котором, например, взяткодателю асимптотически необходимы ресурсы, по крайней мере, $n log n. Некоторые из схем ниже рассмотрение предполагает случайный выбор строгого подмножества узлов, которые будут действовать в качестве сторожевых таймеров, в этом случае предполагаемое взяточничество становится особенно мощным нападением. Примечание: Для обеспечения безопасности этого однораундового механизма staking требуется неиспользуемый каналы между oracle и узлами второго уровня — стандартное требование в системах, устойчивых к принуждению, например, голосовании [82, 138], и разумное на практике. Кроме того, однако, узел Oi, который стремится сотрудничать со взяткодателем, может построить передает свою тайну таким образом, чтобы показать взяткодателю, что она закодировала определенный ценность. Например, если Oi не знает, какие узлы контролирует взяткодатель, то Oi может представить акции с нулевой стоимостью всем членам комитета. Затем взяткодатель может проверить данные Ои. соответствие вероятностно. Чтобы избежать этой проблемы в любом однораундном протоколе, мы потребовать, чтобы Oi знал личность хотя бы одного честного узла второго уровня. С интерактивным протоколом, в котором каждый узел второго уровня добавляет рандомизацию фактор акций, лучшее, что может сделать взяткодатель, — это заставить Oi выбрать случайную сторожевой бит. 9,6 Система неявных стимулов (IIF) FFO — это форма неявного стимула за правильное поведение в сети Chainlink. Это выполняет такие же функции, как явная доля, то есть депозиты, поскольку помогает обеспечить экономическую безопасность для сеть. Другими словами, FFO следует включать в состав (эффективного) депозита. $d узла в сети.Вопрос в том, как измерить FFO и другие формы неявного стимулирования. в сети Chainlink? Система неявных стимулов (IIF) представляет собой набор принципы и методы, которые мы планируем разработать для этой цели. Блокчейн-системы обеспечивают множество форм беспрецедентной прозрачности и записи узлов с высоким уровнем доверия. Результаты, которые они создают, являются трамплином для нашего видения того, как будет работать IIF. Здесь мы очень кратко обрисуем идеи по ключевым элементам IIF. Сам IIF будет состоять из набора факторов, которые мы считаем важными при оценке неявные стимулы, а также механизмы публикации соответствующих данных в высоконадежной форме для использования аналитическими алгоритмами. Разные пользователи Chainlink могут хотят использовать IIF по-разному, например, придавая разное значение разным факторам. Мы ожидаем, что в сообществе появятся аналитические сервисы, которые помогут пользователям применять IIF. в соответствии с их индивидуальными предпочтениями в оценке рисков, и наша цель — облегчить такие услуги, обеспечивая им доступ к надежным и своевременным вспомогательным данным, как мы обсудим ниже (раздел 9.6.4). 9.6.1 Возможность будущих комиссий Узлы участвуют в экосистеме Chainlink, чтобы получать долю от комиссий, которые сети выплачивают за любую из различных услуг, которые мы описали в этой статье, от обычные данные передаются в расширенные службы, такие как децентрализованная идентификация, справедливая последовательность, и сохраняющий конфиденциальность DeFi. Плата за Chainlink расходы операторов узлов поддержки сети, например, за эксплуатацию серверов, приобретение необходимых лицензий на передачу данных и обслуживание международный персонал для обеспечения высокой продолжительности безотказной работы. FFO обозначает плату за услуги за вычетом расходов, что узел выиграет в будущем или проиграет, если продемонстрирует ошибочное поведение. FFO — это форма ставки, которая помогает защитить сеть. Полезной особенностью FFO является тот факт, что данные внутри цепочки (дополненные данными вне цепочки) data) создают запись истории узла с высоким уровнем доверия, что позволяет вычислять FFO. прозрачным, эмпирически обоснованным образом. Простой показатель FFO первого порядка может быть получен на основе средней чистой выручки компании. узла за определенный период времени (т. е. валовой доход минус операционные расходы). ФФО может затем рассчитывается, например, как чистая приведенная стоимость [114] совокупного будущего чистого дохода, другими словами, дисконтированная во времени стоимость всех будущих доходов. Однако доход узла может быть нестабильным, как показано, например, на рис. 17. Что еще более важно, доход узла может не соответствовать стационарному распределению. со временем. Следовательно, другие факторы, которые мы планируем изучить при оценке FFO, включают: • История производительности. История производительности оператора, включая правильность и своевременность его отчетов, а также время его бесперебойной работы, дает объективную информацию. пробный камень, позволяющий пользователям оценить его надежность. Таким образом, история производительности будет обеспечивают решающий фактор при выборе пользователями узлов oracle (или, с появлением из DONs, их выбор DONs). Хорошая история производительности, вероятно, коррелируют с высоким текущим доходом.18 18Важным исследовательским вопросом, который мы намерены решить, является выявление фальсифицированных объемов услуг.Рисунок 17. Доход, полученный узлами Chainlink на одном канале данных (ETH-USD) в течение представительная неделя в марте 2021 года. • Доступ к данным. Хотя oracle могут получать множество форм данных из открытых API, определенные формы данных или определенные высококачественные источники могут быть доступны только на на основе подписки или посредством договорных соглашений. Привилегированный доступ к определенным источники данных могут сыграть роль в создании стабильного потока доходов. • Участие DON: С появлением DONs появятся сообщества узлов. вместе для предоставления конкретных услуг. Мы ожидаем, что многие DON будут включать операторов на выборочной основе, устанавливая участие в авторитетных DONs в качестве привилегированное положение на рынке, которое помогает обеспечить постоянный источник дохода. • Межплатформенная деятельность: некоторые операторы узлов могут иметь хорошо зарекомендовавшее себя присутствие и репутацию в других контекстах, например, в качестве PoS validator или поставщики данных в контекстах, отличных от blockchain. Их эффективность в других системах (когда данные о них доступны в достоверной форме) может дать информацию для оценки. истории их выступлений. Аналогично, ошибочное поведение в сети Chainlink может поставить под угрозу доходы в этих других системах, отпугивая пользователей, т. е. FFO может распространяться на разные платформы. 9.6.2 Спекулятивный FFO Операторы узлов участвуют в сети Chainlink не только для получения дохода от операции, а создавать и позиционировать себя, чтобы воспользоваться новыми возможностями для выполнения рабочих мест. Другими словами, расходы oracle узлов сети также равны позитивное заявление о будущем DeFi и других приложений смарт-контрактов домены, а также новые приложения сетей oracle, не относящиеся к blockchain. Сегодня операторы узлов получают комиссию, доступную в существующих сетях Chainlink, и одновременно Это во многом аналогично фальшивым отзывам на интернет-сайтах, за исключением того, что проблема проще в oracle, поскольку у нас есть точная запись о том, были ли заказаны товары, т. е. отчеты, и доставлены — в отличие, например, от физических товаров, заказанных в интернет-магазинах. Другими словами, в oracle При настройке производительность может быть проверена, даже если достоверность клиента невозможна.создать репутацию, историю деятельности и операционный опыт, которые будут позиционировать им выгодно получать комиссионные, доступные в будущих сетях (при условии, конечно, о честном поведении). Узлы, работающие сегодня в экосистеме Chainlink, будут в этом смысле имеют преимущество перед новичками в получении дополнительных комиссионных Chainlink услуги становятся доступными. Это преимущество распространяется на новых операторов, а также технологические компании с устоявшейся репутацией; например, T-Systems, традиционная поставщик технологий (дочерняя компания Deutsche Telekom) и Kraken, крупная централизованная обменом, установили раннее присутствие в экосистеме Chainlink [28, 143]. Такое участие узлов oracle в будущих возможностях можно рассматривать само по себе. как своего рода спекулятивный FFO и, таким образом, представляет собой форму доли в Chainlink сеть. 9.6.3 Внешняя репутация IIF, как мы его описали, может работать в сети строго под псевдонимом. операторов, то есть без раскрытия вовлеченных людей или реальных объектов. Однако одним из потенциально важных факторов при выборе провайдеров пользователями является внешний фактор. репутация. Под внешней репутацией мы подразумеваем восприятие надежности, связанное с реальными личностями, а не с псевдонимами. Репутационный риск, связанный с Реальные идентичности можно рассматривать как форму скрытого стимула. Смотрим на репутацию через призму IIF, то есть в криптоэкономическом смысле, как средство установления межплатформенная деятельность, которая может быть включена в оценки FFO. Выгода от использования внешней репутации как фактора оценки FFO, в отличие от псевдонимной связи, заключается в том, что внешняя репутация связывает производительность не только с существующей деятельности оператора, но и будущей. Если, например, плохая репутация привязывается к отдельному человеку, оно может испортить будущие предприятия этого человека. Иными словами, внешняя репутация может охватывать более широкий спектр FFO, чем псевдонимная репутация. записи о производительности, как последствия должностных преступлений, причастных к лицу или установленных от компании сложнее сбежать, чем от компании, связанной с псевдонимной операцией. Chainlink совместим с децентрализованными технологиями идентификации (раздел 4.3), которые может оказать поддержку при использовании внешней репутации в IIF. Такие технологии может подтвердить и тем самым помочь обеспечить достоверность утверждений операторов в реальном мире. личности.19 9.6.4 Открытая аналитика IIF Как мы уже отмечали, IIF стремится предоставлять надежные данные и инструменты с открытым исходным кодом для неявно-стимулирующая аналитика. Цель состоит в том, чтобы дать возможность поставщикам услуг в сообществе разработать аналитику, адаптированную к потребностям оценки рисков различных частей Chainlink база пользователей. 19Децентрализованные учетные данные также могут, при желании, дополнять псевдонимы проверенными дополнительная информация. Например, оператор узла в принципе может использовать такие учетные данные для доказать, что это компания из списка Fortune 500, не раскрывая, какая именно.Значительный объем исторических данных о доходах и производительности узлов. находится в цепочке в неизменяемой форме с высоким уровнем доверия. Наша цель, однако, состоит в том, чтобы предоставить наиболее полные возможные данные, включая данные о поведении, которое видно только в выключенном состоянии. цепочке, например, отчетность вне цепочки (OCR) или активность DON. Такие данные потенциально могут быть объемным. Лучший способ его хранения и обеспечения его целостности, т. е. защиты от мы полагаем, что вмешательство будет осуществлено с помощью DONs с использованием обсуждаемых методов. в разделе 3.3. Некоторые стимулы поддаются прямому измерению, например staking. депозиты и базовый FFO. Другие, такие как спекулятивный FFO и репутация, труднее оценить. объективным образом, но мы считаем, что поддерживающие формы данных, в том числе исторический рост экосистемы Chainlink, показатели репутации в социальных сетях и т. д., может поддерживать аналитические модели IIF даже для этих трудно поддающихся количественной оценке элементов. Мы можем представить, что специальные DON возникают специально для мониторинга, проверки и записывать данные, относящиеся к записям производительности узлов вне сети, а также другие данные используемые в IIF, например, проверенная идентификационная информация. Эти DON могут предоставлять унифицированные, надежные данные IIF для любых поставщиков аналитики, обслуживающих сообщество Chainlink. Они также предоставят золотой рекорд, подтверждающий заявления поставщиков аналитики. независимо проверяемые сообществом. 9,7 Собираем все вместе: стимулы для операторов узлов Обобщая приведенные выше обсуждения явных и неявных стимулов для операторов узлов. обеспечивает целостное представление о том, как операторы узлов участвуют и получают от этого выгоду. сеть Chainlink. В качестве концептуального руководства мы можем выразить общую сумму активов, поставленных на карту, с помощью заданного Chainlink. оператор узла $S в грубой, стилизованной форме: \(S ≈\)D + \(F + \)FS + $R, где: • $D — это совокупность всех явно внесенных ставок во всех сетях, в которых участвует оператор; • $F — это чистая приведенная стоимость совокупности всех FFO во всех сетях в в которых участвует оператор; • $FS – чистая приведенная стоимость спекулятивного FFO оператора; и • $R — репутационный капитал оператора за пределами экосистемы Chainlink. это может быть поставлено под угрозу из-за выявленного неправильного поведения в его узлах oracle. Хотя это грубое равенство в значительной степени концептуально, оно показывает, что существует множество экономических факторов, благоприятствующих высокой надежности работы узлов Chainlink. Все эти факторы, кроме $D, присутствуют в сегодняшних сетях Chainlink.9,8 Благотворный цикл экономической безопасности Сочетание суперлинейного staking воздействия с представлением выплат комиссионных поскольку возможность будущих комиссий (FFO) в IIF может привести к тому, что мы называем благотворным циклом экономической безопасности в сети oracle. Это можно рассматривать как своего рода экономику. масштаба. По мере того как общая сумма, обеспеченная конкретной сетью, увеличивается, сумма дополнительная ставка, необходимая для добавления фиксированной суммы экономической безопасности, уменьшается, как и средняя стоимость на пользователя. Таким образом, с точки зрения комиссии пользователю дешевле присоединиться. уже существующей сети, чем добиться такого же роста сетевой экономики. безопасность путем создания новой сети. Важно отметить, что добавление каждого нового пользователя снижает стоимость услуги для всех предыдущих пользователей этой сети. Учитывая конкретную структуру комиссий (например, конкретную ставку доходности от поставленной суммы), если общая сумма комиссий, получаемых сетью, увеличивается, это стимулирует приток дополнительных сделайте ставку в сети, чтобы обеспечить ее более высокую скорость. В частности, если общая ставка отдельный узел, который может удерживаться в системе, ограничен, а затем при новых выплатах комиссионных войдут в систему, повысив ее FFO, число узлов n увеличится. Благодаря суперлинейное staking влияние нашей системы стимулирования, экономическая безопасность система будет расти быстрее, чем n, например, как n2 в механизме, который мы обрисовали в разделе 9.4. В результате средние затраты на экономическую безопасность, т. е. размер доли, вносящей вклад, доллар экономической безопасности — упадет. Таким образом, сеть может взимать плату со своих пользователей более низкие комиссии. Предполагая, что спрос на услуги oracle эластичен (краткое описание см., например, в [31]). объяснение), спрос вырастет, что приведет к появлению дополнительных комиссий и FFO. Проиллюстрируем это положение следующим примером. Пример 5. Поскольку экономическая безопасность сети oracle с нашим стимулом схема \(dn2 for stake \)dn, экономическая безопасность обеспечивается долларом доли является n и, следовательно, средняя стоимость доллара экономической безопасности, т. е. сумма ставки вклад в доллар экономической безопасности — равен 1/n. Рассмотрим сеть, в которой экономические стимулы полностью состоят из FFO, ограниченного по \(d ≤\)10K на узел. Предположим, что в сети n = 3 узла. Тогда средняя стоимость на доллар экономической безопасности составляет около $0,33. Предположим, что общий FFO сети превышает \(30K (e.g., to \)31K). Учитывая ограничение FFO на узел, сеть вырастает (как минимум) до n = 4. Теперь средняя стоимость на доллар экономической безопасности падает примерно до 0,25 доллара. Полный благотворный цикл экономической безопасности в сетях oracle мы схематически иллюстрируем на рис. 18. Мы подчеркиваем, что благотворный цикл экономической безопасности возникает из-за эффекта пользователей объединяют свои сборы. Именно их коллективный FFO работает в пользу более крупных размеры сети и, следовательно, большая коллективная безопасность. Мы также отмечаем, что благотворный цикл Экономическая безопасность способствует достижению DON финансовой устойчивости. Однажды созданные DON, отвечающие потребностям пользователей, должны вырасти до точки, в которой доходы от комиссий превышают эксплуатационные расходы для oracle узлов.

Рисунок 18: Схема благотворного цикла Chainlink staking. Повышение абонентской платы платежи в сеть oracle 1⃝вызывают ее рост, что приводит к росту ее экономической безопасность 2⃝. Этот сверхлинейный рост обеспечивает эффект масштаба в сетях Chainlink. 3⃝. В частности, это означает снижение средней стоимости экономической безопасности, т.е. экономическая безопасность в расчете на доллар, возникающая в результате выплат комиссий или других источников участия увеличивается. Снижение затрат, ложащихся на плечи пользователей, стимулирует рост спроса на oracle. услуги 4⃝. 9,9 Дополнительные факторы, способствующие росту сети Поскольку экосистема Chainlink продолжает расширяться, мы считаем, что ее привлекательность для пользователей и важность инфраструктуры для экономики blockchain будет возрастать. Значение, предоставляемое сетями oracle, является суперлинейным, то есть оно растет быстрее.чем размер самих сетей. Этот рост стоимости обусловлен как экономия на масштабе — более высокая эффективность затрат на пользователя по мере увеличения объемов услуг — и сетевой эффект — повышение полезности сети по мере более широкого внедрения пользователями DONs. Поскольку существующие smart contract продолжают видеть большую ценность и совершенно новые smart contract приложений стало возможным благодаря более децентрализованным службам, общее количество использование и совокупные сборы, выплачиваемые DONs, должны вырасти. Увеличение пулов сборов в превратиться в средства и стимул для создания еще более децентрализованных услуг, что приводит к созданию добродетельного цикла. Этот благотворный цикл решает важнейшую проблему курицы и яйца. проблема в гибридной экосистеме smart contract: инновационные функции smart contract часто требуются децентрализованные услуги, которых еще не существует (например, новые рынки DeFi часто требуются новые потоки данных), но для их существования необходим достаточный экономический спрос. Объединение комиссий различных smart contract за существующие DON будет сигнализировать о спросе на дополнительные децентрализованные услуги от растущей базы пользователей, что приводит к их созданию авторами DONs и постоянным внедрением новых и разнообразных гибридных smart contracts. Подводя итог, мы считаем, что рост сетевой безопасности, обусловленный добродетельными циклы в механизме Chainlink staking иллюстрируют более крупные модели роста, которые Сеть Chainlink может помочь создать ончейн-экономику для децентрализованных услуги.

Заключение

В этой статье мы изложили видение эволюции Chainlink. Основная тема в этом видении речь идет о способности сетей oracle предоставлять гораздо более широкий спектр услуг для smart contracts, чем просто доставка данных. Используя DON в качестве основы для децентрализованных сервисов будущего, Chainlink будет стремиться обеспечить производительную функциональность oracle с повышенной конфиденциальностью. Его сети oracle будут обеспечивать строгую минимизацию доверия. посредством комбинации принципиальных криптоэкономических механизмов, таких как staking и тщательно продуманные защитные ограждения и контроль уровня обслуживания в основных цепочках. DONs также поможет системам уровня 2 обеспечить гибкую и справедливую политику упорядочения транзакций, а также снизить затраты на газ для транзакций, маршрутизируемых мемпулом. Взятые вместе, все эти возможности ведут к созданию безопасных и богато функциональных гибридных интеллектуальных систем. контракты. Гибкость DONs улучшит существующие услуги Chainlink и приведет к появлению множество дополнительных smart contract функций и приложений. Среди них бесшовные подключение к широкому спектру автономных систем, децентрализованное создание личности из существующие данные, приоритетные каналы, которые помогут обеспечить своевременную доставку критически важных для инфраструктуры транзакции и инструменты, сохраняющие конфиденциальность DeFi. Видение, которое мы здесь изложили, амбициозно. В краткосрочной перспективе мы стремимся расширить возможности гибридные контракты для достижения целей, недоступных сегодня smart contracts, в то время как в долгосрочной перспективе мы стремимся реализовать децентрализованный метауровень. К счастью, мы можем рисовать о новых инструментах и идеях — от алгоритмов консенсуса до доказательства с нулевым разглашением системы — что сообщество развивается как результат быстро развивающихся исследований.

Аналогичным образом, мы рассчитываем уделить приоритетное внимание реализации идей, изложенных в этой статье, в ответ на это. потребностям сообщества пользователей Chainlink. Ждём следующего этапа в нашем стремлении расширить возможности smart contracts посредством универсального подключения и создать децентрализованные технологии как основа следующего поколения мировой финансовой системы. и правовые системы. Благодарности Спасибо Джулиану Альтерини и Шону Ли за визуализацию рисунков в этой статье.