Solana щойно вирішила свою найбільшу проблему з даними, каже генеральний директор Helius

Helius повідомляє, що вони переробили спосіб зберігання та отримання історичних даних Solana, представивши новий архівний бекенд та метод RPC, який об'єднує сьогоднішні багатовикликові робочі процеси в один запит.

Генеральний директор Мерт Мумтаз охарактеризував зміну в масштабних термінах: "сьогодні Solana змінюється назавжди... ми вирішили найбільшу проблему даних/RPC, яка існує", - написав він, стверджуючи, що статус-кво - історичні запити до Google Bigtable - був "повільним", "дорогим" та "негнучким".

Що це означає для Solana

Мумтаз підкреслив практичну проблему, яку знає кожен розробник індексатора або гаманця Solana: отримання "першої транзакції для адреси Solana без нескінченного циклу" та витягування "останніх 100 транзакцій для адреси" вимагають ланцюжка викликів і обходів, які можуть розростися до "тисяч викликів RPC". "Більше ні", - сказав Мумтаз.

В основі випуску лежить ексклюзивний метод RPC від Helius, getTransactionsForAddress, підтримуваний розподіленим архівним шаром зберігання, який, за твердженням компанії, є "в 1000 разів швидшим, гнучкішим і масштабованішим". Функціонально метод об'єднує сьогоднішній поширений двоетапний шаблон - getSignaturesForAddress для перерахування підписів, а потім getTransaction для наповнення деталей - в один виклик, який може повертати повністю декодовані транзакції з двонаправленим часовим упорядкуванням та фільтрами діапазону за слотом або часовою міткою.

Документація Helius пояснює, що це дозволяє здійснювати зворотний пошук без зворотного обходу та підтримує пагінацію, налаштовану для великих, активних акаунтів. Компанія також підкреслює, що це не є основним доповненням до RPC Solana; це власне розширення, доступне на вузлах Helius, вартістю 100 кредитів за запит для планів Developer і вище. Заяви про продуктивність охоплюють як новий метод, так і старі кінцеві точки, при цьому Helius стверджує, що getBlock, getTransaction і getSignaturesForAddress тепер "у 10 разів швидші", тоді як архівна система під капотом забезпечує заголовні покращення пропускної здатності для історичних запитів.

Формулювання чітко спрямоване на усунення стрибків затримки, пов'язаних з Bigtable, і зменшення кількості викликів у "100 разів" разом із "в 10 разів меншою затримкою" та "в 1000 разів меншою кількістю коду". Ці твердження відповідають поширеним скаргам розробників, задокументованим на форумах Solana, щодо повільного історичного наповнення на завантажених адресах, але жорсткі цифри тут - це власні тести Helius.

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

Запуск відбувся в той самий день, коли перший спотовий ETF Solana у США вийшов на NYSE - BSOL від Bitwise. За словами старшого аналітика ETF Bloomberg Еріка Балчунаса, BSOL зафіксував обсяг у 56 мільйонів доларів у перший день. "56 мільйонів доларів BSOL - це НАЙБІЛЬШЕ серед усіх запусків цього року... Більше, ніж XRPR, SSK, Ives та $MNU. І що дивовижно, він був засіяний з 220 мільйонами доларів. Він міг би інвестувати посівні кошти в перший день, що призвело б до приблизно 280 мільйонів доларів, що було б навіть більше, ніж дебют ETHA. У будь-якому випадку сильний старт", - написав Балчунас.

Ще один макрофон: Western Union оголосив про плани запровадити стейблкоїн, забезпечений доларом, USDPT, на Solana, випущений Anchorage Digital Bank, з доступністю, запланованою на першу половину 2026 року.

На момент публікації SOL торгувався за ціною 195 доларів.