Jump to content
Tatiana Polivoda

Что такое проблема оракулов в блокчейн?

Recommended Posts

Проблема оракулов в блокчейн — одно из самых важных препятствий, если смарт-контракты построенные на базе сетей, таких как Ethereum, хотят достичь повсеместного применения в различных рынках и индустриях.

Смарт-контракты представляют огромный потенциал преобразить то, как независимые структуры вступают в контрактные обязательства и производят платежи. Отдельно от индустрии смарт-контрактов, мы имеем огромную традиционную цифровую экономику, состоящую из множества устройств, связанных с помощью интернета, и производящих вычисления онлайн. Производный продукт такой цифровой инфраструктуры — постоянно увеличивающийся объем данных и API, который дает представление о том как все в нашем мире работает; например, результаты поиска, выдающие самые популярные темы, или сенсоры IoT (Internet of Things или Интернет Вещей) предлагающие наиболее распространенные модели трафика.

Смарт-контракты построенные на блокчейн и традиционные базы данных и API имеют огромный потенциал для объединения в гибридные смарт-контракты и создания новой архитектуры для автоматизации баз данных. Но как связать эти два мира? В этом и заключается “Проблема оракулов” — главная тема этой статьи.

Статья разделена на пять частей:

Проблема оракулов

Задача оракула

Почему блокчейны, такие как Ethereum, не предлагают собственных, нативных решений для оракулов

Риски централизованных оракулов, связанные с безопасностью

Chainlink - стандарт для безопасных и надежных децентрализованных сетей оракулов

Проблема оракулов

Проблема оракулов состоит в одном простом ограничении — блокчейны не могут получать или выдавать данные из внешних экосистем в качестве встроенного функционала. Таким образом получается, что блокчейны — это изолированные сети, в принципе как компьютер без интернета. Именно эта изоляция и делает блокчейн невероятно безопасной и надежной, т.к. сеть только требует консенсус на основе самого базового набора однозначных вопросов (правда/ложь), используя базу данных которая уже зарегистрирована в леджере. Примеры таких вопросов: подписал ли владелец публичного ключа транзакцию с соответстующим секретным ключом, имеет ли данный публичный адрес достаточно средств для запрашиваемой транзакции, и достоверен ли данный тип транзакции для конкретного смарт-контракта? Такой узкий фокус консенсуса объясняет почему смарт-контракты часто называют детерминированными — они строго исполняют поставленные перед ними задачи, и с гораздо более высокой точностью чем традиционные системы.

И тем не менее, для реализации более 90% своего потенциала, смарт-контрактам необходимо иметь связь с внешним миром. Например, финансовым смарт-контрактам необходима информация с рынков для проведения платежей, страховым смарт-контрактам нужен доступ к IoT (интернет вещей) и сети данных для определения размеров выплат, и подавляющее большинство смарт-контрактов будут осуществлять платежи в фиате и традиционными методами. Ни один из этих аспектов не присутствует в блокчейне по умолчанию, и ни один из вышеупомянутых традиционных сервисов не предлагает прямой доступ к своим данным.

Bridging the connection between the blockchain (on-chain) and the outside world (off-chain) requires an additional and separate piece of infrastructure known as an oracle.

Связь между блокчейном (on-chain) и внешним миром (off-chain) требует дополнительных и невзаимосвязанных между собой элементов инфраструктуры, известных как оракулы.

Что делают оракулы блокчейна?

Оракул в блокчейне — это защищенный элемент middleware (промежуточного программного обеспечения), который обеспечивает связь между различными блокчейнами и любой внешней, оффчейн системой, включая поставщиков данных, сетевые API, корпоративные бэкенды, облачные провайдеры, электронные подписи, платежные системы, другие блокчейны, и т.д. Оракулы берут на себя многие ключевые функции:

Слушать — отлеживать блокчейн на предмет входящих запросов на внешние данные (оффчейн) от пользователей или смарт-контрактов.

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

Форматировать — переводить данные полученные из внешних API в формат блокчейна (input/входящее значение) и/или создавать данные в блокчейне, совместимые с внешним API (output/полученный результат)

Подтверждать — создавать криптографическое доказательство качества оракула, с помощью комбинации подписи данных, подписи транзакции на блокчейне, подписей TLS (Transport Layer Security/протокол защиты транспортного уровня), TEE подтверждений (Trusted Execution Environment/Безопасная Среда Исполнения), или доказательств с нулевым разглашением (zero-knowledge proof).

Вычислять — Производить безопасные оффцейн вычисления для смарт-контрактов, например вычисление среднего значения от множественных источников, или генерирование доказуемо случайного значения (verifiable random number) для игровых приложений.

Транслировать — подписывать и транслировать транзакцию в блокчейне для отправки данных и любого сопроводительного подтверждения on-chain, для последующего использования смарт-контрактом.

Output/полученный результат (необязательная функция) — отправлять данные внешней системе после исполнения смарт-контракта, например передача платежных поручений традиционной системе платежей или инициирование действий от киберфизических систем (cyber-physical system).

Для выполнения вышеперечисленных функций, система оракулов оперирует одновременно on-chain и off-chain. Компонент on-chain используется для коммуникации в блокчейне (чтобы “слушать запросы”), транслировать данные, отправлять подтверждения, извлекать данные on-chain, производить вычисления в блокчейне. Компонент off-chain предназначен для обработки запросов, извлечения и форматирования внешних данных, отправки данных блокчейна во внешние системы, и для осуществления вычислений оффчейн — для большего масштабирования, конфиденциальности, безопасности, и других дополнительных возможностей смарт-контрактов.

 

 

Почему блокчейны не могут решить проблему оракулов

Блокчейны — невероятно безопасны и надежны благодаря нескольким принципам. Как мы описали выше, блокчейн требует консенсус по очень базовым однозначным вопросам (правда/ложь), используя данные, которые уже хранятся в его леджере. Леджер верен по умолчанию, потому что он использует децентрализацию для подтверждения каждой единицы информации, используя все ноды (node) сети. Блокчейн также использует децентрализацию чтобы поддерживать целостность и неприкосновенность своего консенсуса (PoW — доказательство выполнения работы, PoS — доказательство доли владения, и др), гарантируя таким образом, что изменение правил протокола возможно только если подавляющее большинство сети выразит свое согласие (например, 51%). Все эти свойства обеспечивают значительные гарантии вычислительного и информационного детерминизма, особенно в самых децентрализованных и устойчивых к атакам Сибиллы (Sybil attacks) сетях.

И тем не менее, блокчейны не очень хорошо подходят там, где требуется суб’ективность или необходимы внешние данные, которые не обязательно могут быть доступны каждому узлу (node) сети. Например, простой вопрос вроде “Какая сейчас рыночная стоимость биткоина?” или “Какая погода сейчас в Нью-Йорке” может вызвать широкий спектр разных ответов, которые будут отличаться в зависимости от источника данных и времени запроса информации. Таким образом встает следующий вопрос — что есть верный ответ и как подтвердить что он верный?

Наличие суб’ективности на базовом уровне (base layer) блокчейна открывает ящик Пандоры с самыми различными рисками — безопасность, надежность, управление (governance), угрожая таким образом ценности и целесообразности собственно блокчейна.

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

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

Другая серьезная проблема — это масштабирование. Добавление в сеть нового источника информации или коррекция существующего метода аггрегации требуют огромного усилия для координирования и управления коммуникацией с каждой нодой для дальнейшего одобрения и обновления их программ. Нагрузка от управления увеличивает разногласия в сети, замедляет развитие основных элементов блокчейна (например, PoS или sharding/шардинг), и затрудняет дальнейшие инновации и развитие оракулов. Разумеется, чем сложнее базовый уровень блокчейна, тем больше риска для всех приложений его использующих. Даже те приложения, которые не используют оракулы или не вовлечены в конфликтующие запросы данных, могут все равно попасть под перекрестный огонь и возможно даже временно прервать работу, если, например, вся сеть остановится из-за проблемы с оракулом.

По этим и многим другим причинам, оракулы не интегрированы в базовый уровень ни одного из главных блокчейнов, а оперируют как отдельные сети. Это позволяет блокчейнам понизить риск атак и сохранить их детерминизм, фокусируясь на главном — консенсусе. Это также дает оракулам необходимую гибкость для сбора информации из сложного и суб’ективного внешнего мира без лишних зависимостей и ограничений, которые могли бы стать угрозой для других приложений блокчейна.

Оракулы централизованных блокчейнов несут значительные риски

Весь смысл смарт-контрактов заключается достижении их однозначного исполнения с помощью технологии, а не вероятного исполнения человеком. Чтобы этого достичь, блокчейн не должен иметь единую точку отказа (SPOF/single point of failure) — и это свойство должно распространяться на оракулы, если мы хотим чтобы детерминизм смарт-контрактов поддерживался на протяжении полного цикла (end-to-end). Зачем переводить многомиллионный стандартный контракт на смарт-контракт на полностью децентрализованном блокчейне, если один централизованный оракул способен контролировать ввод информации, предопределяя таким образом результат исполнения контракта?

 

 

Неважно, будет ли это команда разработчиков, ответственная за оракул, или сторонний централизованный сервис — любой из сценариев дает одной структуре чрезмерную власть управлять контрактом посредством управления оракулом. Даже если централизованные оракулы работают с наилучшими намерениями, они все равно находятся под угрозой многочисленных централизованных проблем, таких как простои, DDOS-атаки, взломы, случайные ошибки, и все они ставят своих пользователей под угрозу.

Даже самые уважаемые централизованные системы могут подвергнуться давлению, например когда стоимость контракта вырастает экспоненциально — это подвергнет их риску взяточничества, запугивания, давления со стороны регуляторов, и все что для этого требуется это лишь один нечестный инсайдер. Такая модель невозможна для масштабирования и не несовместима с идеей децентрализованной инфраструктуры как главного двигателя базопасной и надежной автоматизации.

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

Chainlink: Стандарт для безопасных и надежных оракулов

In order to bring determinism to the oracle layer, Chainlink has developed a network of decentralized oracle networks (DONs), with each DON involving a combination of multiple security techniques needed to service a particular use case.

Чтобы гарантировать детерминизм на уровне оракулов, Chainlink разработал систему децентрализованных сетей оракулов (DON/decentralized oracle network), где каждая сеть/DON включает в себя комбинацию многочисленных техник безопасности, необходимых для обслуживания определенного сценария/проекта.

Открытый код — технология с открытым кодом позволяет всему блокчейн сообществу независимо подтверждать безопасность и надежность исходного кода и функций Chainlink, а также предлагать как его улучшить.

Внешние Соединители (External Adapters) — инструменты для создания соединений с любыми оффчейн-ресурсами или API — позволяют нодам безопасно хранить API ключи и управлять логинами, что в свою очередь позволяет смарт-контрактам получать данные их любых внешних систем и API, включая те, которые защищены паролем или учетными данными.

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

Подпись данных — все ноды криптографически подписывают данные, которые они предоставляют для смарт-контрактов, что позволяет всем пользователям определять какие ноды отправили данные, видеть их историю, и таким образом определять качество их сервиса.

Соглашения об услугах — использование обязатальных соглашений ончейн между запрошивающим смарт-контрактом и провайдером оракула, которые излагают условия использования услуг оракула и штрафы/вознаграждения за качество предоставленной информации, обеспечивают пользователей гарантиями качества их запросов данных оффчейн.

Репутационные системы — поток подписанных ончейн данных в репутационные системы позволяет пользователям принимать осознанные решения о том, какие ноды предлагают наилучшее качество информации о себе, а какие нет. Такой информацией является широкий выбор метрик для оценки качества годы, например количество успешных запросов, список клиентов, которых обслуживает данная нода, среднее время обработки запроса, и так далее.

Сертификация — позволяет нодам увеличить свою безобасность и надежность с помощью всевозможных сертификатов качества, и таким образом предоставляет пользователям дополнительные гарантии, такие как KYC (Know Your Customer/знай своего клиента), геолокация ноды, отзывы о безопасности инфраструктуры ноды, и многие другие.

Advanced Cryptography and Hardware — providing flexibility for more advanced cryptography (like zero-knowledge proofs) and hardware (such as trusted execution environments) enables oracles to perform additional functions like proving the origin of data (e.g. specific data came from a specific server), keeping data confidential, performing off-chain computation, and more.

Передовая криптография и оборудование — продвинутая криптография (например, zero-knowledge proofs/доказательство с нулевым разглашением) и оборудование (например Trusted Execution Environment/Безопасная Среда Исполнения) позволяют оракулам выполнять дополнительные функции, например возможность доказывать происхождение полученных данных (к примеру, с какого сервера пришла определенная информация), при этом сохраняя конфиденциальность самой информации, выполняя оффчейн вычисления, и многое другое.

 

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

Присоединяйтесь к русскоязычному сообществу Chainlink в Телеграм

Официальные источники на английском: Twitter для новостей, уведомлений о новых статьях; Telegram или Reddit для основных вопросов, Discord — для детальных технических вопросов и дискуссий

рис 1.png

рис 2.png

Edited by Helber
3.11

Share this post


Link to post
Share on other sites

@Tatiana Polivoda , 

Нарушение 3.11 («крикливое» оформление или неприемлемый формат текста)

Запрещается писать сообщение сплошь (или большей частью) ЗАГЛАВНЫМИ БУКВАМИ, жирным шрифтом, курсивом, подчеркнутым шрифтом, 

увеличенным шрифтом, выделенным цветом  и т.п. 

А также злоупотреблять слишком крупным шрифтом в заголовках и избыточным количеством смайлов. Стандартный шрифт - 14.

При copy-paste (вставке текста с другого ресурса) внизу окна ненадолго появляется линк «Вставить в виде обычного текста». Настоятельно рекомендуется его использовать для приведения текста к приемлемому формату.
 

Исправил. Все ваши ссылки побились, а фото сместились в конец. Исправляйте в рамках правил, если хотите.

 

Если еще раз напишете шрифтом как для дома престарелых — не обижайтесь...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...