От блокчейна до LLM: углубленная интерпретация эволюции и проблем технологии индексации данных.

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

Я начал углубленно изучать разработку блокчейна в 2022 году, и первая книга, которую я прочитал, была «Освоение Ethereum». Эта книга превосходна и дала мне глубокое понимание основ Ethereum и Blockchain. Однако с сегодняшней точки зрения некоторые методы разработки, описанные в книге, несколько устарели. Предварительные шаги включают в себя запуск ноды на личном ноутбуке, даже для кошелька dApp, требуя, чтобы легкая нода загружалась сама по себе. Это отражает модель поведения первых разработчиков и хакеров в экосистеме разработки блокчейнов в период с 2015 по 2018 год.

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

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

Появление поставщиков узлов

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

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

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

| Проект | Категория | Создан с | | --- | --- | --- | | Алхимия | Узлы | 2017 | |Инфура |Узлы |2016 | | СейчасУзлы | Узлы | 2019 | | Быстрые узлы | Узлы | 2017 | | якорь | узлы | 2017 | | Цепной стек | Узлы | 2018 |

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

Например, предположим, что я разработчик проекта NFT и хочу проводить транзакции NFT или отображать NFT. Затем мой внешний интерфейс должен считывать данные NFT в личной учетной записи EOA в режиме реального времени. NFT — это всего лишь стандартизированная форма токена. Владение NFT означает, что я владею токеном с уникальным идентификатором, сгенерированным контрактом NFT, а изображение NFT на самом деле является метаданными, которые могут быть данными SVG или ссылкой на изображение в IPFS. Хотя клиент Geth для Ethereum предоставляет инструкции по индексированию, для некоторых проектов с большими требованиями к интерфейсу нецелесообразно постоянно запрашивать Geth, а затем возвращаться к интерфейсу. Для некоторых функций, таких как аукцион заказов и агрегация транзакций NFT, они должны выполняться вне сети для сбора пользовательских инструкций, а затем отправлять эти инструкции в цепочку в соответствующее время.

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

**Как развивался индексатор данных? **

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

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

Я позаимствовал этот термин из фильма «Железный человек», и он кажется очень подходящим для описания ситуации большинства стартапов. Когда стартапы быстро растут (привлекают много пользователей), они часто сталкиваются с проблемами, потому что не предвидели их с самого начала. В фильме злодей никогда не ожидал, что его боевое снаряжение полетит в космос, потому что он не учёл «проблему обледенения». Точно так же для разработчиков многих проектов Web3 «проблема зависания» связана с растущим бременем массового принятия пользователями. Это оказывает сильное давление на серверную часть, поскольку количество пользователей резко возрастает. Есть также проблемы, связанные с самой цепочкой блоков, такие как проблемы с сетью или отключение узлов.

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

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

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

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

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

Эта модель похожа на ранние дни Интернета, когда платформы электронной коммерции и разработчики приложений предпочитали создавать свои собственные объекты IDC (Internet Data Center). Тем не менее, стоимость идет рука об руку со сложностью дизайна программы, поскольку запросы пользователей растут, а состояние сети блокчейна стремительно растет. Кроме того, такой подход препятствует быстрому расширению рынка. Некоторые высокопроизводительные общедоступные блокчейны требуют аппаратно-интенсивных операций с узлами, а синхронизация и очистка данных требуют человеческих ресурсов и временных затрат.

Если вы пытаетесь создать рынок NFT на основе блокчейна или крутую игру, разве не удивительно, что 65% членов вашей команды являются бэкэнд-инженерами и инженерами данных?

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

** Я считаю, что именно поэтому существуют индексаторы. **

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

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

Финансирование и строительство проектов слоя данных и индексного слоя в основном будут осуществляться в 2022 году. Я считаю, что деловая практика этих проектов уровня индексов и уровня данных тесно связана с проектированием лежащей в их основе архитектуры данных, особенно с проектированием систем OLAP (оперативной аналитической обработки). Выбор подходящего ядра ядра является ключом к оптимизации производительности индексного слоя, включая повышение скорости индексирования и обеспечение его стабильности. Обычно используемые движки включают Hive, Spark SQL, Presto, Kylin, Impala, Druid, ClickHouse и т. д. Среди них ClickHouse — мощная база данных, широко используемая в интернет-компаниях, которая была открыта в 2016 году и получила финансирование в размере 250 миллионов долларов США в 2021 году.

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

Тем не менее, построение индексации данных в сети по-прежнему окутано двумя темными облаками.

Два темных облака

Первое темное облако касается влияния стабильности сети блокчейна на стороне сервера. Хотя сеть блокчейна обладает высокой стабильностью, это не так во время передачи и обработки данных. Например, такие события, как реорганизации (reorgs) и откаты (rollbacks) блокчейна, могут создать проблемы для стабильности данных индексатора.

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

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

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

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

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

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

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

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

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

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

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

Итак, ** Есть ли другой способ? **

Поиск закономерностей

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

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

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

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

Прогресс и инновационное применение науки и техники всегда будут связаны некоторыми объективными принципами. Например, без базовой поддержки технологии шифрования на основе эллиптических кривых наша криптовалютная экосистема сегодня не может существовать. Точно так же практическое применение доказательств с нулевым разглашением было бы невозможно без важной исследовательской работы по доказательствам с нулевым разглашением, опубликованной Массачусетским технологическим институтом в 1985 году. Итак, мы видим интересную закономерность. ** Широкое применение и расширение поставщиков узловых услуг основано на быстром росте глобальных облачных сервисов и технологий виртуализации. ** В то же время, Развитие уровня данных в цепочке основано на активной разработке превосходной архитектуры баз данных с открытым исходным кодом и сервисов,** эти архитектуры являются решениями для данных, которые используются во многих продуктах бизнес-аналитики. полагаться в последние годы **. Это все технические предпосылки, которым должны соответствовать стартапы, чтобы достичь коммерческой жизнеспособности. Когда дело доходит до проектов Web3, те, которые используют передовую инфраструктуру, как правило, имеют преимущество перед теми, которые полагаются на устаревшие архитектуры. Ярким примером является сокращение доли рынка OpenSea из-за более быстрых и удобных для пользователя бирж NFT.

Кроме того, мы также можем видеть очевидную тенденцию: искусственный интеллект (ИИ) и технология LLM постепенно созрели и имеют возможность широкого применения.

**Поэтому возникает важный вопрос: как ИИ изменит структуру данных в цепочке? **

Гадание

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

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

На мой взгляд, первым шагом в решении этой проблемы является использование LLM и обработки естественного языка.

Мы можем создать более ориентированный на пользователя интерфейс «запроса данных» и использовать методы LLM. В существующих случаях пользователи должны использовать сложные языки запросов, такие как SQL или GraphQL, для извлечения соответствующих данных в цепочке из API или Studios. Однако, используя LLM, мы можем ввести более интуитивный и человеческий способ задавать вопросы. Таким образом, пользователи могут выражать свои вопросы на «естественном языке», а LLM переводит их в подходящие запросы и предоставляет пользователям нужные им ответы.

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

С более глобальной точки зрения, цель индексатора — предоставить пользователям точные данные. Как я подчеркивал ранее, потенциальная проблема с уровнем данных в цепочке заключается в том, что отдельные фрагменты данных разбросаны по разным базам данных индексаторов и изолированы друг от друга. Чтобы удовлетворить разнообразные потребности в данных, некоторые разработчики предпочитают интегрировать все данные в цепочке в базу данных, чтобы пользователи могли выбирать необходимую информацию из единого набора данных. Некоторые протоколы предпочитают включать только некоторые данные, например данные DeFi и данные NFT. Но проблема несовместимости стандартов данных все еще существует. Иногда разработчикам необходимо получать данные из нескольких источников и переформатировать их в своей собственной базе данных, что, несомненно, увеличивает их нагрузку на обслуживание. Кроме того, они не могут своевременно перейти к другому поставщику в случае возникновения проблемы с одним поставщиком данных.

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

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

Кроме того, способ агентского обслуживания (Агент) решает проблему несовместимости стандартов данных. Поскольку он был разработан с возможностью анализа и обработки необработанных данных в сети, он может адаптироваться к различным форматам данных и стандартам. В результате разработчикам не нужно переформатировать данные из разных источников, что снижает их нагрузку.

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

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

Chainbase поддерживает это видение и стремится воплотить его в жизнь.

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

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