API3 (API3) - децентрализованные API для Web 3.0

API3 создает децентрализованные API-интерфейсы на основе блокчейнов с управлением DAO и измеримой безопасностью.

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

Создавая API3, мы стремимся к тому, чтобы концепция API сделала следующий шаг в эволюции, чтобы соответствовать неизбежно строгим требованиям к децентрализации Web 3.0 без использования сторонних посредников. Это будет достигаться с помощью dAPI - полностью децентрализованных API-интерфейсов с поддержкой блокчейнов, - которые будут настраиваться, управляться, застраховываться и монетизироваться в масштабе с помощью API3 DAO.

Что такое API3 (API3)

Мы наблюдаем рождение децентрализованных приложений, способных взаимодействовать с реальным миром, что сразу же отражается в получаемой ими ценности. Наиболее ярким примером этого феномена является недавний всплеск стоимости, связанный с DeFi (децентрализованное финансирование), при этом по состоянию на январь 2021 года общая стоимость различных приложений составила более 20 миллиардов долларов. Приложение DeFi обычно требует, чтобы цены на активы передавались на платформу смарт-контрактов через поток данных. Этот поток данных облегчает взаимодействие приложения с реальным миром, в конечном итоге позволяя ему предоставлять значимые услуги, такие как обмен производными финансовыми инструментами и кредитование. Сейчас происходит не только рост DeFi, но и рост децентрализованных приложений, которые могут осмысленно взаимодействовать с реальным миром, а DeFi - это только верхушка айсберга.

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

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

DAPI - это безопасное и экономичное решение для децентрализованного предоставления традиционных услуг API для смарт-контрактов. Он состоит из следующих элементов:

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

API3 - это совместная попытка масштабного создания, управления и монетизации dAPI. Чтобы достичь этого полностью децентрализованным способом, стимулы участников будут согласованы с помощью утилит управления, безопасности и сбора стоимости токена API3. Проект будет иметь полностью открытую и прямую модель управления, в которой любой владелец токена API3 сможет делать ставки, чтобы получить права прямого голосования в API3 DAO. Кроме того, стейкеры получат часть дохода от dAPI.

Один из фундаментальных недостатков существующих решений Oracle - это попытка установить и поддерживать паразитную связь с источниками данных, которая не может создать устойчивую экосистему. Напротив, мы начинаем с признания того, что поставщики API являются двигателем этого проекта. Следовательно, они не будут абстрагироваться, а скорее будут приписываться и компенсироваться, чтобы их интересы полностью соответствовали интересам более широкой экосистемы API3. Мы уже были свидетелями стремления провайдеров API стимулировать внедрение своих сервисов децентрализованными приложениями путем предоставления бесплатных вызовов тестовой сети для их платных API и денежных призов за хакатоны. Дальнейшее развитие этого сотрудничества будет одним из основных источников силы API3.

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

Чтобы устранить эти проблемы и обеспечить дальнейшее участие поставщиков API в экосистеме, потоки данных API3 будут состоять из первых сторонних оракулов, управляемых поставщиками API. Это станет возможным благодаря Airnode, полностью бессерверному узлу оракула, который не требует ноу-хау, обслуживания или ухода со стороны поставщика API. Полученные в результате dAPI будут экономичными и защищенными от атак промежуточного уровня третьих сторон.

В случае неисправности пользователь dAPI сможет потребовать компенсацию до предварительно согласованной суммы из пула ставок. Kleros, протокол разрешения споров в сети, будет использоваться для принятия решения о выплате компенсации на основании представленных доказательств. Это будет стимулировать участников к активному участию в управлении, чтобы гарантировать прозрачность управления dAPI и минимизировать риски безопасности. Успешное управление - получение дохода от dAPI и избежание ошибок, которые приведут к выплате страховых возмещений - будет вознаграждено токенами API3, которые создадут цикл положительной обратной связи, который будет постоянно улучшать управление.

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

Этот пул ставок используется в качестве залога для услуги страхования в сети, которая предоставляет пользователям dAPI количественно измеримый уровень безопасности. API3 улучшает существующие решения Oracle с точки зрения децентрализации, рентабельности, безопасности, прозрачности и потенциала роста экосистемы.

Проблема подключения API

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

В результате того, что компании используют API для монетизации своих данных и услуг, концепция API вышла за рамки своего первоначального значения. Этот термин больше не относится к технической реализации интерфейса, а к полноценному продукту, который включает в себя предоставляемую им услугу. Глобальные предприятия, предоставляющие API, в среднем получают 25% доходов своей организации от API. Такие компании, как Sales force, Expedia и eBay сообщают, что большую часть своих доходов получают через API, и мы находимся на пороге полностью ориентированных на API бизнес-моделей. Ожидается, что это движение подорвет даже такие укоренившиеся отрасли, как банковское дело.

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

Проблема Oracle: неверное толкование, не зависящее от источника

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

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

Проблема оракула некорректна, поскольку даже ее название предполагает невозможное решение. Можно было бы подойти к проблеме перехода из точки A в точку B как к «проблеме телепортации». Тем не менее, первое поколение решений пыталось реализовать этот буквальный оракул, задавая вопрос и используя краудсорсинг его ответа, что дает время решения, измеряемое днями, и экстремальные затраты на газ из-за количества транзакций, которые необходимо совершить, т.е. не идеально подходит для таких случаев, как DeFi или рынки прогнозов. Следует отметить, что такой подход действительно подходит, если предоставляемая информация является субъективной. Хорошим примером может служить разрешение судебного спора.

Решения второго поколения сузили их область действия, чтобы охватить только фактическую информацию, доступ к которой можно получить программно, и в конечном итоге столкнулись с «проблемой совместимости». В этих решениях узел оракула, интегрированный в две произвольные системы (блокчейн и API, два блокчейна и т. д.), Действует как автоматизированный посредник между ними. Использование нескольких из этих узлов оракула и определение результата с помощью заранее определенных правил консенсуса обеспечивает гарантии безопасности, которые дополняют базовую технологию цепочки блоков. Эти решения более быстрые и менее дорогие по сравнению с краудсорсинговыми оракулами и, следовательно, жизнеспособны для большего числа сценариев использования, однако они страдают от того, что они разрабатываются с учетом чрезмерного обобщения рассматриваемой проблемы.

Проблема Oracle - это проблема трех тел: источника данных, оракула и потребителя данных в цепочке. 

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

Решение для взаимодействия, не зависящее от источника, приводит к следующим последствиям:

  • Промежуточный уровень небезопасных и дорогих сторонних оракулов, который мог быть заменен оракулами, управляемыми поставщиком API;
  • Экосистема, питающая посредников, ищущих ренты, при этом исключающая фактические источники данных;
  • Беспорядочная обработка данных, полученных из разных источников, в потоке данных.

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

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

Децентрализованные API

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

Рассматриваемая проблема, по сути, заключается в том, что децентрализованные приложения не могут получать услуги от традиционных поставщиков API децентрализованным образом. Действительно, сегодня в основном решения для обеспечения совместимости используются для доставки цен на активы, выбранных из API централизованного обмена в приложения DeFi, и новые варианты использования, такие как рынки прогнозирования и параметрическое страхование, предъявляют аналогичные требования. Следовательно, дальнейшее уточнение определения проблемы как таковой позволит нам прийти к следующему поколению реальных решений для взаимодействия.

Это новое определение проблемы подразумевает, что децентрализованные приложения требуют, чтобы в блокчейн доставлялись определенные сервисы веб-API, и это должно быть сделано полностью децентрализованным, экономичным и безопасным способом. Определение требований позволяет нам разработать полный продукт, который оптимально их удовлетворяет: децентрализованные API-интерфейсы, или для краткости dAPI, представляют собой сети оракулов первой стороны, управляемых поставщиком API и управляемыми децентрализованно. Напротив, децентрализованные решения взаимодействия состоят из оракульной сети сторонних посредников, управляемых централизованным объектом, что обусловлено их недостаточно конкретным определением проблемы. 

Проблема с ценовыми потоками

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

  1. Ценовой поток, подаваемый 10 оракулами (например), не представляет 10 уникальных точек данных. Все оракулы вполне могут обслуживать данные от одного и того же поставщика API (и мы не будем в этом мудрее). Здесь отсутствует прозрачность - количество оракулов, обслуживающих поток данных, не соответствует более качественным и надежным данным, хотя поставщики таких каналов могут предполагать такие вещи.
  2. У оракулов есть стимул собирать дешевые и легкодоступные данные, потому что ничто не заставляет или не стимулирует их поступать иначе (поскольку, опять же, они никоим образом не обязаны сообщать о своих источниках). Это создает что-то вроде точки Шеллинга в отношении дешевых и легкодоступных данных. Кроме того, это затрудняет, если не делает невозможным размещение ставок в таких системах, потому что теперь высококачественные, тщательно отобранные источники данных становятся выбросами.
  3. Агрегирование без учета источников показывает то, что можно назвать статистической неграмотностью. Как уже упоминалось, поток данных, обслуживаемый x оракулами, не обязательно соответствует x уникальным источникам данных. Это особенно верно, когда количество оракулов увеличивается, потому что уникальные источники данных гораздо менее многочисленны и масштабируемы, чем узел оракула. Это означает, что метод агрегирования, не зависящий от источника данных, приводит к искажению агрегированный результат (так как очень маловероятно, что соотношение оракула и источника данных будет одинаковым для всех источников данных). Подмножество источников данных (вероятно, небольшое) оказывает непропорциональное влияние на окончательный совокупный результат. И, опять же, по причинам теории игр: это приводит к смещению совокупного результата в сторону более дешевых и легкодоступных источников данных.
  4. Давайте снова сузим наш пример до ценовых каналов. Еще одна проблема агрегирования, не зависящего от источника, - это невозможность правильно взвешенного и нормализованного агрегирования. Рассмотрим контракт на подачу цен (обслуживаемый данными из API агрегатора цен): ответы оракула происходят в разное время, цены представляют разные объемы торгов, и эти цены поступают от разных агрегаторов (конечно, с их собственными собственными методами агрегирования). Слепое вычисление среднего значения или медианы по этим точкам данных - это сравнение «яблок с апельсинами». То есть вы, по сути, вычисляете статистику для разных типов данных, но неявно обрабатываете их, как если бы они были одними и теми же - что явно плохо информировано среднестатистическим специалистом по данным.
  5. И я даже не дошел до юридических последствий агностицизма источников данных. Большинство условий обслуживания API запрещают перепродажу или несанкционированное распространение данных API, что ставит оператора узла Oracle, обслуживающего такие API, как нарушающего эти условия и подверженного широким источникам юридической ответственности, включая претензии со стороны поставщика API.

Протокол Airnode

Airnode - это полностью бессерверный узел оракула, который специально разработан для поставщиков API для работы со своими собственными оракулами. Он решает все проблемы, связанные с узлами Oracle.

  1. Для работы не требуется никаких специальных знаний. На самом деле, сложно даже говорить об операции, поскольку Airnode спроектирован так, чтобы полностью установить и забыть.
  2. Благодаря существующей полностью управляемой бессерверной технологии он не требует никакого повседневного обслуживания, такого как обновление операционной системы или мониторинг узла на время безотказной работы. Он разработан так, чтобы не иметь состояния, что делает его чрезвычайно устойчивым к любой проблеме, которая может вызвать постоянный простой и потребовать вмешательства оператора узла.
  3. Он основан на услугах, цена которых определяется по запросу, что означает, что оператор узла платит ровно столько, сколько используется его узел. Это позволяет любому поставщику API запускать оракул бесплатно и начинать платить только после того, как он начнет приносить доход.
  4. Оператору узла вообще не требуется обрабатывать криптовалюту. Его протокол разработан таким образом, что запрашивающая сторона покрывает все расходы на газ.

Один из способов увидеть Airnode - это облегченная оболочка веб-API, которая позволяет ему взаимодействовать с платформами смарт-контрактов без накладных расходов или трения с токенами оплаты. Что касается уровня участия, требуемого от поставщика API, использование Airnode можно сравнить с использованием шлюза API, который делает API доступным через Интернет, вместо того, чтобы управлять узлом цепочки блоков в качестве побочного бизнеса. Фактически, наша цель состоит в том, чтобы Airnode стал таким же повсеместным и приземленным для API, как использование шлюза API, который сделает огромное количество оракулов от первых разработчиков доступным для API3.

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