Знакомство с Laconic Stack

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

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

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

Сейчас на Ethereum есть все эти данные, и вам, как разработчику Dapp, нужна только крошечная их часть. Но чтобы проверить эту часть, вам нужно (помимо нескольких других вещей) содержать архивный узел - это непомерно дорого для большинства разработчиков. Для решения этой проблемы появились централизованные сервисы, такие как (Infura, The Graph и Alchemy), на которые в настоящее время приходится большинство (если не большая часть) Dapp-запросов к Ethereum.

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

Архитектура такого решения требует множества движущихся частей; они были разработаны основными участниками Ethereum и Cosmos за последние 5 лет. В этом посте мы расскажем вам о различных компонентах стека Laconic.

Существует три различных способа участия в сети Laconic: Удостоверяющие участники, Поставщики услуг и Разработчики Dapp. Чтобы описать обязанности и преимущества каждой роли, мы должны начать с технических аспектов стека Laconic.

Давайте посмотрим на следующую схему core stack:

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

Два репозитория в верхней части также являются основными точками входа для большинства разработчиков. `stack-orchestrator` - это инструмент командной строки для, ну, оркестровки стека. Он использует docker-compose для развертывания заданной коллекции объединенных в сеть контейнеров docker, что избавляет от необходимости самостоятельно настраивать множество сервисов. Каждый пользователь Laconic Stack в какой-то момент - если не регулярно - будет использовать stack orchestrator.

Репо `watchers-ts` содержит публично доступные Watchers и код для их генерации. Watchers - это TypeScript, который генерируется на основе одного или нескольких смарт-контрактов Solidity. Разработчики Dapp могут участвовать в Laconic Network, либо 1) написав собственный watcher для своего Dapp, либо 2) написав общеполезный watcher и опубликовав его в Laconic Registry, получая таким образом плату за каждый раз, когда он используется. Мы вернемся к наблюдателям позже.

Внизу слева находится репозиторий `laconicd`, и он действительно является "дном" стека. Он создан на основе Cosmos SDK и содержит пользовательские модули, специфичные для работы Laconic Network (например, форк Ethermint/Evmos, аукцион, служба имен). Вполне вероятно, что в будущем появится публичная тестовая сеть, однако, поскольку Laconic Network является разрешенным набором валидаторов, только валидаторы-участники, официально присоединившиеся к Laconic Network, будут включены в основную сеть. То, что набор валидаторов является разрешенным, не запрещает никому запускать полноценный узел, и поставщики услуг или другие лица могут сделать это по разным причинам.

`laconic-sdk` - это библиотека для облегчения общения с `laconicd`. Она используется как в `laconic-registry-cli`, так и в `laconic-console`. Если `laconic-registry-cli` - это инструмент командной строки, то `laconic-console` - это пользовательский интерфейс для записи и чтения записей в сети Laconic. Эти инструменты общего назначения полезны для широкого спектра случаев использования во всем стеке.

Ключевой целью Laconic Network является предоставление точных, поддающихся проверке данных из блокчейна Ethereum. Сравнение с существующими решениями - это тема для другого поста, однако в настоящее время не существует сервиса, который бы недорого предоставлял доказательства того, что предоставляемые данные верны. Решение Laconic (одно из) заключается в том, что называется "statediffing" - часть стека, управляемая валидаторами участников и, вероятно, поставщиками услуг.

Он начинается с поддерживаемого форка `go-ethereum (geth)`, в который добавлен сервис определения состояния в режиме реального времени. Statediffing дает четкое представление о состоянии между любыми заданными блокчейнами. Это позволяет Laconic минимизировать объем вычислений, необходимых для предоставления доказательств. Три дополнительных "вспомогательных" сервиса выполняют различные задачи, необходимые для получения полной картины состояния в соответствии с требованиями приложения. Вместе они составляют узел полного индекса (FIN).

Сервис `eth-statediff-service` предоставляет исторические данные о состоянии, а сервис `eth-statediff-fill-service` использует исторические данные о состоянии для заполнения пробелов в statediff при необходимости. Наконец, `ipld-eth-state-snapshot` загружает полное состояние на определенной высоте блока, что помогает загрузить систему.

О statediffing можно написать еще много, однако здесь важно отметить, что каждый сервис независимо записывает данные в `ipld-eth-db`. Последняя служит в качестве ведра для данных о состоянии, которые были проиндексированы в IPLD. Вместо того чтобы напрямую обращаться к этой базе данных, `ipld-eth-server` предоставляет наблюдателям уровень API, позволяющий легко запрашивать соответствующие фрагменты данных из состояния Ethereum. Кроме того, `ipld-eth-server` воспроизводит родные интерфейсы Ethereum JSON RPC поверх базы данных `ipld-eth-db`.

И вот мы вернулись к Наблюдателям. Как уже говорилось ранее, они генерируются из одного или нескольких смарт-контрактов Solidity и настраиваются для запроса определенных частей данных, относящихся к Dapp. Watchers позволяют легко запрашивать необходимые данные из Ethereum и - по пути - получать доказательства, чтобы генерировать доказательства того, что ваши данные верны. Это контрастирует с существующими решениями для разработчиков Dapp, которые в настоящее время вынуждены полагаться на централизованных провайдеров, не предоставляющих доказательств для генерации доказательств.

Web3 находится (все еще!) в самом начале своего развития, и, как и в начале развития SQL, разработчикам Dapp для создания своего Dapp требуются углубленные знания сложных структур данных. Watchers упрощают эту задачу, открывая конечную точку GraphQL - решение, знакомое на порядок большему числу разработчиков, чем прямой запрос к блокчейну Ethereum.

Laconic создает набор инструментов для решения основных проблем Web3. Сегодня мы представили обзор основных компонентов стека Laconic. Разработчикам, интересующимся Laconic, стоит начать с `stack-orchestrator`, чтобы получить представление о работе различных частей стека, затем посмотреть `watcher-ts`, чтобы поэкспериментировать с различными наблюдателями и перейти к созданию собственных.