Что делает компания / проект?

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

В протоколе есть четыре типа участников:

• Индексаторы: операторы узлов, которые ставят GRT для предоставления услуг индексирования и обработки запросов. Индексаторы получают плату за запросы и вознаграждение за свои услуги.
• Кураторы: разработчики подграфов, потребители данных или члены сообщества, которые сигнализируют индексаторам, какие API должны быть проиндексированы протоколом.
• Делегаторы: люди, которые хотели бы внести свой вклад в обеспечение безопасности сети, но не хотят самостоятельно запускать Graph Node.
• Потребители: конечные пользователи, которые запрашивают подграфы и платят сборы за запросы индексаторам, кураторам и делегаторам.

Проблемы и решения

Например, с популярным приложением CryptoKitties dApp относительно просто задать следующие вопросы:

♦Сколько CryptoKitties принадлежит конкретной учетной записи Ethereum?
♦Когда родился конкретный CryptoKitty?

Это связано с тем, что эти шаблоны чтения напрямую поддерживаются методами balanceOf и getKitty, предоставляемыми контрактом.

Однако на другие вопросы ответить сложнее:

♦Кто являются владельцами CryptoKitties, рожденных в период с января по февраль 2018 года?
♦Чтобы ответить на этот вопрос, вы должны обработать все Birth события, а затем вызвать ownerOfметод для каждого созданного CryptoKitty.

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

Сегодня Graph решает эту проблему с помощью размещенного сервиса, который индексирует данные блокчейна. Затем эти индексы («подграфы») можно запросить с помощью стандартного API GraphQL. В будущем размещенный сервис превратится в полностью децентрализованный протокол с теми же возможностями. Оба они поддерживаются реализацией Graph Node с открытым исходным кодом.

Особенности

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

После того, как вы написали манифест подграфа, вы используете Graph CLI, чтобы сохранить определение в IPFS и сообщить размещенной службе начать индексирование данных для этого подграфа.

Эта диаграмма дает более подробную информацию о потоке данных после развертывания манифеста подграфа, связанного с транзакциями Ethereum:

Поток следует за этими шагами:🙃

1. Децентрализованное приложение добавляет данные в Ethereum посредством транзакции смарт-контракта. 📑
2. Смарт-контракт генерирует одно или несколько событий при обработке транзакции. 🧾
3. Graph Node постоянно сканирует Ethereum на предмет новых блоков и данных для вашего подграфа, которые они могут содержать.📥
4. Узел графа находит события Ethereum для вашего подграфа в этих блоках и запускает предоставленные вами обработчики сопоставлений.            Сопоставление — это модуль WASM, который создает или обновляет объекты данных, которые Graph Node хранит в ответ на события Ethereum.📧
5. Децентрализованное приложение запрашивает у Graph Node данные, проиндексированные из блокчейна, используя конечную точку GraphQL этого узла . Узел Graph, в свою очередь, переводит запросы GraphQL в запросы для своего базового хранилища данных, чтобы получить эти данные, используя возможности индексации хранилища. 🔒
6. Децентрализованное приложение отображает эти данные в удобном пользовательском интерфейсе для конечных пользователей, который они используют для выполнения новых транзакций в Ethereum.📖
7. Цикл повторяется🔄

Глобальный API GraphQL

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

Graph Network

Graph Network — это основная инфраструктура для Web3 — необходимый компонент для доставки децентрализованных приложений с производительностью потребительского уровня.

Полная децентрализация

Миссия The Graph состоит в том, чтобы активировать интернет-приложения, которые полностью работают на общественной инфраструктуре.

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

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

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

Что такое сеть Graph

Сеть Graph децентрализует уровень запросов и API Web3, устраняя компромисс, с которым сегодня сталкиваются разработчики dApp: создавать ли высокопроизводительное приложение или создавать действительно децентрализованное приложение.

Сегодня разработчики могут запускать Graph Node в своей собственной инфраструктуре или использовать нашу размещенную службу . Разработчики создают и развертывают подграфы, в которых описывается, как получать и индексировать данные из источников данных Web3. Многие ведущие проекты Ethereum уже создали подграфы, в том числе: Uniswap, ENS, DAOstack, Synthetix, Moloch и другие. В сети Graph любой индексатор сможет делать ставки Graph Tokens (GRT), чтобы участвовать в сети и получать комиссионные, а также инфляционные вознаграждения за обслуживание запросов.

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

Роли протокола

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

Роли

1. Потребители. Потребители платят индексаторам за запросы. Обычно это конечные пользователи, но также могут быть веб-службы или промежуточное программное обеспечение, которое интегрируется с The Graph. 😉
2. Индексаторы. Индексаторы — это узловые операторы The Graph. Они заинтересованы в получении финансового вознаграждения. 💵
3. Кураторы. Кураторы используют GRT, чтобы указать, какие подграфы нужно индексировать. Как правило, это будут разработчики, но они также могут быть конечными пользователями, поддерживающими услугу, на которую они полагаются, или личность, которая имеет чисто финансовую мотивацию. 👍
4. Делегаторы. Делегаторы ставят на карту GRT от имени индексатора, чтобы заработать часть инфляционных вознаграждений и сборов, без необходимости лично запускать Graph Node. Они финансово мотивированы. 💰
5. Рыбаки. Рыбаки защищают сеть, проверяя точность ответов на запросы. Рыбаки альтруистически мотивированы, и по этой причине The Graph изначально будет предоставлять услуги рыбаков для сети. 🐟
6. Арбитры. Арбитры определяют, следует ли сокращать индексаторы во время разрешения споров. Они могут иметь финансовую или альтруистическую мотивацию.🤓

Применение

Разработчики

Для разработчиков API-интерфейсы для создания подграфа останутся в основном такими же, как при использовании локального или размещенного узла Graph.

Одно заметное отличие заключается в том, как разработчики развертывают подграфы. Вместо развертывания на локальном или размещенном узле Graph, они развернут свой подграф в реестре, размещенном на Ethereum, и внесут долю GRT для управления этим подграфом. Это служит сигналом для индексаторов, что этот подграф следует проиндексировать.

Конечные пользователи

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

Механизм запросов позволяет пользователю безопасно запрашивать огромные объемы данных, хранящихся в The Graph, без необходимости лично выполнять работу по вычислению и хранению этих данных. Механизм запросов также действует как торговый механизм, принимая решения, например, с какими индексаторами вести дела или сколько платить, в зависимости от используемого dApp или предпочтений пользователя.

Чтобы система запросов обеспечивала удобство работы пользователей, ей необходимо будет автоматически подписывать транзакции микроплатежей от имени пользователей, а не запрашивать их для каждой транзакции, которую необходимо подписать. Мы работаем с несколькими командами государственных каналов, которые строят на Ethereum, чтобы убедиться, что кошельки и функциональность, которые они поставляют, соответствуют потребностям протоколов дозированного использования, таких как The Graph. А пока мы разместим шлюз, который позволит dApps субсидировать запросы от имени пользователей.

Индексаторы

Индексаторы смогут присоединиться к Graph, разместив GRT и запустив версию Graph Node .

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

Кураторы и делегаторы

Кураторы и делегаты будут курировать и делегировать через Graph Explorer . Когда мы запустим сеть, Graph Explorer будет полностью децентрализованным приложением, и для его использования потребуется браузер с поддержкой dApp и кошельком Ethereum.

Токен GRT

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

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

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

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

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

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

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

Поскольку мы ожидаем, что все рациональные индексаторы примут эквивалентное бюджетное решение, в равновесии мы должны ожидать, что индексаторы будут делать ставку на долю от общей ставки GRT, равную доле работы, которую они выполнили для сети .

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

Кратко:

GRT — это собственный токен служебной программы ERC-20 для The Graph и имеет следующие варианты использования:

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

Сигнализация куратора

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

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

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

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

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

Награда за инфляцию индексатора

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

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

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

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

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

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

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

Обозреватель графиков и служба имен графиков

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

Это одно из основных ценностных предложений The Graph — помочь разработчикам найти полезные данные для развития и упростить включение данных из различных базовых протоколов и децентрализованных источников данных в одно приложение.

В сети Graph Explorer Graph Explorer будет dApp, построенным на основе подграфа, который индексирует смарт-контракты Graph Protocol (мета, я знаю!), Включая Graph Name Service (GNS), реестр подграфов в цепочке.

Подграф определяется манифестом подграфа, который неизменен и хранится в IPFS. Неизменность важна для детерминированных и воспроизводимых запросов для проверки и разрешения споров. GNS выполняет столь необходимую роль, позволяя командам прикреплять имя к подграфу, которое затем может использоваться для указания на последовательные неизменяемые «версии» подграфа.

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

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

Повторное использование одних и тех же подграфов во многих dApps и других подграфах — одно из основных преимуществ, которые открывает The Graph. Сравните этот подход с текущим состоянием мира, когда каждое новое приложение развертывает свою собственную базу данных и серверы API, которые часто используются недостаточно.

Условные микроплатежи

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

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

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

1. Работа. Потребитель отправляет заблокированный микроплатеж с описанием выполняемой работы. Эта спецификация работы действует как блокировка микроплатежа.😌
2. Аттестация. Поставщик услуг отвечает запрошенным цифровым товаром или услугой вместе с подписанным свидетельством о том, что работа была выполнена правильно. 🙂
3. Проверка. Аттестация проверяется каким-либо методом проверки. За подтверждение работы, которая была выполнена неправильно, могут быть наложены штрафы, например, порез.🧐
4. Срок действия. Поставщик услуг должен либо получить подтверждение получения от потребителя, либо представить свою аттестацию в сети, чтобы получить свой микроплатеж до истечения срока действия заблокированного микроплатежа.🤗

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

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

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

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

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

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

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

Проверка

Чтобы конструкция WAVE Locks и размещение индексатора были значимыми, должен существовать эффективный механизм проверки, способный воспроизводить работу, выполняемую индексатором, выявлять ошибки и убирать нарушающие индексаторы.

На первом этапе The Graph Network это обрабатывается через процесс разрешения споров в цепочке, который решается через арбитраж.

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

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

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

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

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

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

Информация: botcoin.online

Дополнительно:

• The Graph: Экономика индексации Web3