Від блокчейну до LLM, поглиблене тлумачення еволюції та проблем технології індексування даних

З тих пір, як Сатоші Накамото вирішив вставити повідомлення в блок genesis, структура даних ланцюга Bitcoin зазнала ряд змін.

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

У 2017 році у нас не було жодного постачальника послуг вузлів. З точки зору попиту та пропозиції, їх основною функцією є проведення транзакцій через обмежену активність користувачів. Це означає, що самостійне обслуговування або розміщення повного вузла не є надто великим тягарем, оскільки запитів RPC небагато для обробки, а запити на передачу надходять рідко. Більшість перших користувачів Ethereum — технічні фанати. Ці ранні користувачі мають глибоке розуміння розробки блокчейнів і звикли безпосередньо підтримувати вузли Ethereum, створювати транзакції та керувати обліковими записами через командний рядок або інтегроване середовище розробки.

Таким чином, ми можемо помітити, що ранні проекти зазвичай мають дуже чистий UI/UX. Деякі з цих проектів навіть не мають інтерфейсу, а активність користувачів досить низька. Характеристики цих проектів в основному визначаються двома факторами: поведінкою користувача та структурою даних ланцюжка.

Розвиток постачальників вузлів

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

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

Однак самостійне розміщення вузлів проектними групами залишається проблемою для розробників невеликих проектів, що вимагає постійних інвестицій у технічне обслуговування та витрат на обладнання. Тому цей складний процес розміщення вузлів зазвичай довіряють компаніям, які спеціалізуються на обслуговуванні вузлів. Варто зазначити, що час масштабного будівництва та збору коштів цими компаніями збігається з тенденцією до зростання хмарних сервісів у технологічній індустрії Північної Америки.

| Проект | Категорія | Встановлено з | | --- | --- | --- | | Алхімія | Вузли | 2017 | |Інфура |Вузли |2016 | | NowNodes | Вузли | 2019 | | QuickNodes | Вузли | 2017 | | Якір | вузли | 2017 | | ChainStack | Вузли | 2018 |

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

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

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

**Як розвивався індексатор даних? **

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

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

Я запозичив цей термін із фільму «Залізна людина», і, здається, він дуже підходить для опису ситуації більшості стартапів. Коли стартапи швидко розвиваються (залучають багато користувачів), вони часто стикаються з проблемами, тому що вони не передбачили їх спочатку. У фільмі лиходій ніколи не очікував, що його бойове спорядження полетить у космос, тому що він не врахував «проблему обледеніння». Подібним чином для розробників багатьох проектів Web3 «проблема заморожування» пов’язана зі збільшенням тягаря масового впровадження користувачами. Це чинить великий тиск на сервер, оскільки кількість користувачів різко зростає. Існують також проблеми, пов’язані з самим блокчейном, наприклад проблеми з мережею або відключення вузлів.

У більшості випадків це проблема бекенда. Наприклад, у деяких ігрових протоколах блокчейну така ситуація не є рідкістю. Коли вони планували додати більше серверів і найняти більше інженерів з обробки даних для аналізу даних у ланцюжку, вони не передбачили такої кількості користувачів. Коли вони це зрозуміли, було вже пізно. І ці технічні проблеми не можна вирішити, просто додавши додаткових інженерів. Як я вже говорив раніше, ці міркування слід включити в план із самого початку.

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

У системі цього типу ви маєте повний контроль над своїми даними, що забезпечує краще керування та підвищену безпеку. Система обмежує запити на дзвінки, знижуючи ризик перевантаження та підвищуючи ефективність. Налаштування сумісні з інтерфейсом, забезпечуючи бездоганну інтеграцію та користувальницький досвід.

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

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

Ця модель схожа на перші дні Інтернету, коли платформи електронної комерції та розробники додатків вирішували будувати власні засоби IDC (Інтернет-центр обробки даних). Однак вартість іде рука об руку зі складністю дизайну програми, оскільки запити користувачів зростають і стан мережі блокчейнів вибухає. Крім того, такий підхід заважає швидкому розширенню ринку. Деякі високопродуктивні загальнодоступні блокчейни вимагають апаратно-інтенсивних операцій вузла, тоді як синхронізація та очищення даних споживає людські ресурси та витрати часу.

Якщо ви намагаєтеся створити 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 є яскравим прикладом.

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

**Тому виникає важливе питання: як ШІ змінить структуру даних у ланцюжку? **

Ворожіння

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

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

На мій погляд, першим кроком у вирішенні цієї проблеми є використання LLM і обробки природної мови.

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

З точки зору розробників, штучний інтелект також може оптимізувати аналіз подій контракту в ланцюжку та декодування ABI. Наразі деталі багатьох контрактів DeFi вимагають від розробників їх ручного аналізу та декодування. Однак, якщо ввести штучний інтелект, ми можемо значно вдосконалити різні методи розбирання контрактів і швидко отримати відповідний ABI. У поєднанні з великою мовною моделлю (LLM) ця конфігурація може інтелектуально аналізувати сигнатури функцій і ефективно обробляти різні типи даних. Крім того, коли система поєднується з фреймворком обробки «потокових обчислень», вона може обробляти аналіз даних транзакцій у режимі реального часу для задоволення нагальних потреб користувачів.

З більш глобальної точки зору, мета індексатора полягає в тому, щоб надати користувачам точні дані. Як я вже підкреслював раніше, потенційна проблема з рівнем даних у ланцюжку полягає в тому, що окремі частини даних розкидані по різних базах даних індексатора та ізольовані одна від одної. Щоб задовольнити різноманітні потреби в даних, деякі розробники вирішують інтегрувати всі дані в ланцюжку в базу даних, щоб користувачі могли вибрати необхідну інформацію з одного набору даних. Деякі протоколи вирішують включати лише деякі дані, наприклад дані DeFi та дані NFT. Але проблема несумісних стандартів даних все ще існує. Іноді розробникам потрібно отримувати дані з кількох джерел і переформатувати їх у власній базі даних, що, безсумнівно, збільшує навантаження на обслуговування. Крім того, вони не можуть своєчасно перейти до іншого постачальника даних, якщо виникне проблема з одним постачальником даних.

Отже, як LLM і AI можуть вирішити цю проблему? LlamaIndex дав мені відкриття. Що, якщо розробникам не потрібен індексатор, а вони використовують розгорнуту проксі-службу (агент) для безпосереднього читання необроблених даних у ланцюжку? Цей агент поєднує в собі технології індексатора та LLM. З точки зору користувача, їм не потрібно нічого знати про API чи мову запитів, їм потрібно лише задавати запитання та отримувати миттєвий зворотний зв’язок.

Оснащений LLM і технологією штучного інтелекту, Agent розуміє та обробляє необроблені дані та перетворює їх у формат, зручний для розуміння користувачами. Це позбавляє користувачів від необхідності стикатися зі складними API або мовами запитів, і вони можуть просто задавати запитання природною мовою та отримувати відгуки в реальному часі. Ця функція підвищує доступність і зручність даних, залучаючи ширшу базу користувачів до доступу до даних у мережі.

Крім того, спосіб обслуговування агента (Agent) вирішує проблему несумісності стандарту даних. Оскільки він був розроблений із можливістю аналізу та обробки необроблених даних у мережі, він може адаптуватися до різних форматів даних і стандартів. Завдяки цьому розробникам не потрібно переформатувати дані з різних джерел, зменшуючи навантаження на них.

Звичайно, це лише припущення щодо майбутньої траєкторії розвитку даних у мережі. Але в технології часто саме ці сміливі ідеї та теорії є рушійною силою революційного прогресу. Ми повинні пам’ятати, що будь то винайдення колеса чи народження блокчейну, усі великі прориви починаються з чиєїсь припущення чи «божевільної» ідеї.

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

Chainbase підтримує це бачення та прагне втілити його в реальність.

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

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