Сканер блоків (Blockchain explorer) своїми руками: небагато теорії

Минулої статті ми розглянули причини, з яких нам може знадобитися свій блокрозвідка. Зауважу, що список цей далеко не повний, але вважатимемо, що ми визначилися - нам потрібне своє джерело даних про транзакції та їх зв'язки з адресами.

Спробуймо визначити, що нам для цього знадобиться. Очевидно, нам знадобиться для початку копія бажаного блокчейну, причому ця копія має зберігати актуальність (синхронізуватись з відповідною мережею). Останнє натякає, що нам потрібно реалізувати повністю відповідний протокол (що очевидно буде надмірно і вкрай дорого) або - встановити відповідне програмне забезпечення, що раціонально. Для Ethereum це буде наприклад Geth (go-ethreum), bitcoind або btcd (реалізація на golang) для Bitcoin, або будь-яке відповідне програмне забезпечення. Головна умова – доступ до повного блокчейну (або тієї частини, яку ви хочете відстежувати). 

Для ясності давайте згадаємо, як повинна зберігатись інформація в блокчейн. Bitcoin та його нащадки (назвемо їх "класичними") використовують концепцію UTXO (Unspent Transaction Output). Результат транзакції можна назвати "виходом" (Out), І кожна транзакція за одним винятком має посилатися на "Вхід" ("In"). Таким чином кожна танзакція містить адресу-відправник і адерс одержувач у тій чи іншій формі (не зараз вдаватимемося в деталі, достатньо самого факту наявності такої інформації). Побічний ефект - з цієї інформації ми можемо так само побудувати дерево транзакцій, яке дозволить відстежувати кожен, хто пройшов мережею сатоші. 

Мережа Ethereum звертається з інформацією трохи інакше. Як я згадав у минулій статті, концепція Ethereum відрізняється, і зберігається інформація безпосередньо про баланс адрес. Однак інформація про транзакції, як і раніше, знаходиться в блоках і зберігається в мережі. Таким чином індексація транзакцій та їх взаємозв'язок з адресами, як і раніше, можлива. У цій статті я навмисно не стосуватимусь смартконтрактів та операцій з токенами (ERC20/ERC721/ERC1155) і так званих “Internal Transactions” - розгляд цієї теми вимагає окремої статті.

А що нам не доступно? Блокчейни, що використовують алгоритми "докази з нульовим розголошенням" ("Zero-knowledge proof"), такі як Monero і ZCash не можуть бути індексовані таким чином, що випливає з їхньої концепції. 

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

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

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

Відповідь перетинатиметься з поясненням, чому саме дисковий простір буде пляшковим шийкою. 

Для початку маленький приклад. Ті, хто розгортав node для Ethereum знають, що є кілька варіантів синхронізації. У документації розділ "Sync modes" згадані Full nodes та Light nodes. Останні нас не цікавлять, а ось Full nodes у свою чергу умовно поділені на Snap, Full та Archive. І ось тут починається цікаве, особливо якщо уважно розглянути ілюстрацію, хто власне з них хто. Snap-нода зберігає докладну інформацію про останніх 128 блоків та пару контрольних точок (checkpoint) у відносно недавньому минулому. Full нода, як випливає з ілюстрації зберігає контрольні точки (checkpoint) з деякою періодичністю майже до початку часів. Archive зберігає повну інформацію, за весь час існування Ethereum. Якщо поставити собі за мету і з'ясувати, який обсяг даних зберігає повна (Full) нода, то виявиться, що це близько 1Tb (на момент написання статті). Не вдаватимемося в механізми “реорганізації мережі” та інші хитрощі. Нам цікаво інше, обсяг даних, що зберігаються Archive нодою - вже близько 16Tb(!). Виходить, що нам не доступно більше 90% інформації про блокчейн?

Якщо поставити один нескладний експеримент - багато стає на свої місця. 

Скористаємося сервісом etherscan..io і знайдемо випадкову транзакцію "з початку часів", наприклад|0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba (приблизно за серпень 2015 року) і спробуємо отримати інформацію Monlo, Monaco, Consolas, "Courier New", monospace; font-size: 13px; background-color: rgb (245, 245, 245); Ми можемо отримати таку інформацію, так? 

Welcome to the Geth JavaScript console!

instance: Geth/v1.12.0-stable-e501b3b0/linux-amd64/go1.20.3
at block: 19122581 (Tue Jan 30 2024 23:24:11 GMT+0000 (UTC))
 datadir: /home/eth/ethereum
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

Щоб вийти, натисніть ctrl-d або тип виходу
> eth.getTransaction("0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba")

null

Ем… Тобто інформації про транзакцію немає? Не зовсім… Давайте спробуємо переглянути вміст блоку, в якому знаходиться транзакція, благо ми знаємо номер блоку:

> eth.getBlockByNumber(122546)
{
…
   hash: "0xc58aa38cf7df6050d3be43f1557d61e3a28e3f34d7818b1644e6a9972003e80a",
…
   number: "0x1deb2",
…
   transactions: ["0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba"],
…
}

Так ось вона, на місці! Якщо виконати eth.getBlockByNumber(122546, true) (додатковий параметр, що вказує запит на видачу всієї інформації про транзакції в блоці), то ми отримаємо і вміст транзакції, і, наприклад, дізнаємося, що відправником була адреса <0x5685620dce626248ccb7121e87fbc098fd5310bd New", monospace; font-size: 13px; background-color: rgb(245, 245, 245);">0x9b0a028eafdecde3afc0fd00b7937098388b7c8a, як і всю супутню інформацію. Чому ж ми не змогли отримати цю інформацію, запитуючи безпосередньо?

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

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

Щодо bitcoin - там є подібні механізми, але обсяг даних незрівнянно менший. На момент написання статті, обсяг блокчейн bitcoin залишає сміховинні 545Gb, так що проблем з ним буде значно менше..

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

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