AWS та Ripple досліджують моніторинг xrpl за допомогою генеративного ШІ Amazon Bedrock

Ripple та Amazon Web Services співпрацюють у сфері передового моніторингу xrpl за допомогою Amazon Bedrock, прагнучи зменшити час аналізу мережі з кількох днів до хвилин.

Ripple та AWS орієнтовані на швидше отримання інсайтів щодо операцій XRPL

Amazon Web Services і Ripple досліджують, як Amazon Bedrock та його можливості генеративного штучного інтелекту можуть покращити моніторинг та аналіз XRP Ledger, згідно з інформацією, знайомою з ініціативою. Партнери прагнуть застосувати AI до системних логів леджеру, щоб скоротити час, необхідний для розслідування проблем у мережі та операційних аномалій.

Деякі внутрішні оцінки інженерів AWS свідчать, що процеси, які раніше займали кілька днів, тепер можна завершити всього за 2-3 хвилини. Більше того, автоматизований огляд логів може звільнити команди платформи для зосередження на розробці функцій замість рутинних виправлень. Однак, цей підхід залежить від надійних каналів даних та точного тлумачення складних логів.

Децентралізована архітектура XRPL та складність логів

XRPL — це децентралізований блокчейн рівня-1, підтримуваний глобальною мережею незалежних операторів вузлів. Система працює з 2012 року і написана мовою C++, що забезпечує високу продуктивність, але створює складні та часто криптичні системні логи. Водночас, така швидкісна архітектура збільшує обсяг і складність операційних даних.

Згідно з документами Ripple, XRPL працює більш ніж на 900 вузлах, розподілених між університетами, блокчейн-інституціями, провайдерами гаманців і фінансовими компаніями. Ця децентралізована структура підвищує стійкість, безпеку та масштабованість. Водночас, вона значно ускладнює реальний огляд того, як мережа поводиться в режимі реального часу, особливо під час регіональних інцидентів або рідкісних крайніх випадків протоколу.

Масштаб проблем із логуванням у XRP Ledger

Кожен вузол XRPL генерує від 30 до 50 гігабайт логів, що в сумі дає приблизно 2-2,5 петабайт даних по всій мережі. При виникненні інцидентів інженерам потрібно вручну переглядати ці файли, щоб виявити аномалії та простежити їх до внутрішнього коду C++. Крім того, необхідна координація між командами, коли залучені внутрішні компоненти протоколу.

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

Реальні інциденти підкреслюють необхідність автоматизації

За словами технічних фахівців AWS, які виступали на недавній конференції, підрізання підводного кабелю в Червоному морі колись вплинуло на зв’язок деяких операторів вузлів у регіоні Азіатсько-Тихоокеанського регіону. Команда платформи Ripple повинна була збирати логи з affected-операторів і обробляти десятки гігабайт даних для кожного вузла, перш ніж можна було почати аналіз. Втім, ручне сортування таких обсягів уповільнює вирішення інцидентів.

Архітектор рішень Vijay Rajagopal з AWS зазначив, що керована платформа, яка хостить агентів штучного інтелекту, відомих як Amazon Bedrock, може аналізувати великі набори даних. Застосування цих моделей до логів XRP Ledger автоматизує розпізнавання шаблонів і поведінковий аналіз, скорочуючи час, який зараз витрачається на ручний огляд. Більше того, такі інструменти можуть стандартизувати реагування на інциденти між різними операторами.

Amazon Bedrock як інтерпретативний шар для логів XRPL

Раджагопал описав Amazon Bedrock як інтерпретативний шар між сирими системними логами та операторами. Він може сканувати криптичні записи рядок за рядком, тоді як інженери запитують моделі AI, що розуміють структуру та очікувану поведінку системи XRPL. Цей підхід є ключовим у баченні партнерів щодо більш розумного моніторингу xrpl у масштабі.

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

Пайплайн для інгестії логів на базі AWS Lambda

Раджагопал описав покроковий процес, починаючи з сирих логів, створених валідаторами, хабами та клієнтськими обробниками XRPL. Логи спочатку передаються у Amazon S3 через спеціальний робочий процес, побудований із інструментів GitHub і AWS Systems Manager. Водночас цей дизайн централізує дані від різних операторів вузлів.

Коли дані потрапляють у S3, тригери подій активують функції AWS Lambda, які оглядають кожен файл, щоб визначити байтові діапазони для окремих сегментів, узгоджені з межами лог-рядків і заздалегідь визначеними розмірами сегментів. Отримані сегменти потім надсилаються у Amazon SQS для розподілу обробки у масштабі та забезпечення паралельної обробки великих обсягів.

Окрема функція обробки логів Lambda отримує лише релевантні сегменти з S3 на основі метаданих сегментів, які вона отримує. Вона витягує лог-рядки та відповідні метадані перед передачею їх у Amazon CloudWatch, де записи можна індексувати та аналізувати. Водночас точність на цьому етапі є критичною, оскільки подальше мислення AI залежить від правильного сегментування.

Зв’язок логів, коду та стандартів для глибшого аналізу

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

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

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

Наслідки для AI-орієнтованої спостережливості блокчейна

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

Якщо pipeline на базі Bedrock від Amazon забезпечить обіцяний час розслідування 2-3 хвилини, це може змінити підхід до управління надійністю великих блокчейн-мереж. Більше того, повторюваний пайплайн із S3, Lambda, SQS, CloudWatch і EventBridge пропонує шаблон, який інші протоколи можуть адаптувати для власних потреб аналізу логів і операційної розвідки.

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