Ох Babylon: узел, многие думают, что для запуска Vigilante (стража) обязательно нужна машина с полным нодом Bitcoin, иначе “не поиграть”. Сначала я тоже так считал. Потом заглянул в официальную документацию и выяснил, что слой стража на самом деле можно запускать в режиме лёгкого клиента — он экономит место на диске, но с само-проверкой всё хуже.
Модуль BTC Light Client в Babylon не хранит полную историю блоков — он синхронизирует только цепочку заголовков блоков. Лёгкий клиент при помощи SPV (Simplified Payment Verification, упрощённая проверка платежей) валидирует Merkle-ветку, чтобы подтвердить текущую высоту в основной сети и то, что цепочка header’ов непрерывна. Страж выполняет две задачи: следит, нет ли у Finality Provider блока с конфликтом двойной подписи; если обнаруживает злонамеренность, то поднимает решение через EOTS — восстанавливает приватный ключ по двум подписям, собирает его и транслирует штрафную транзакцию. Восстановление приватного ключа — это чистые вычисления криптографии, оно не зависит от истории полного нода, поэтому с этим справится и лёгкий клиент. Но он не может независимо проверить, что конкретный UTXO действительно “заперт” в скрипт Babylon — для этого нужен либо полный нод, либо индексатор; лёгкий клиент доверяет только цепочке header’ов.
В гайде по установке Vigilante в официальной документации говорится, что нужно “a synced Bitcoin full node”. Но на практике: запускал стража, подключая Bitcoin Core в light-режиме (prune=1), проходило тестирование; после того как я закинул 0.05 BTC на testnet, страж один раз сообщал FP skip подпись — и ничего не пропустил.
Если в основной сети произойдёт глубокий реорганиз (>>6 блоков), лёгкий клиент может кратковременно неверно определить позицию по временным меткам, тогда как полный нод это заметит раньше. Что он экономит: диск (примерно 80MB/год). Цена: когда источник header’ов будет загрязнён, вас тоже может увести в сторону. Если вы запускаете стража в одиночку, лёгкого клиента обычно достаточно, при условии, что вы доверяете выбранному источнику header’ов. Параноики же запускают полный нод плюс индексатор — там само-проверяется всё.
Это не выбор “или то, или другое”, а компромисс между стоимостью и степенью самоуправления.
#baby $BABY @BabylonLabs_io
Модуль BTC Light Client в Babylon не хранит полную историю блоков — он синхронизирует только цепочку заголовков блоков. Лёгкий клиент при помощи SPV (Simplified Payment Verification, упрощённая проверка платежей) валидирует Merkle-ветку, чтобы подтвердить текущую высоту в основной сети и то, что цепочка header’ов непрерывна. Страж выполняет две задачи: следит, нет ли у Finality Provider блока с конфликтом двойной подписи; если обнаруживает злонамеренность, то поднимает решение через EOTS — восстанавливает приватный ключ по двум подписям, собирает его и транслирует штрафную транзакцию. Восстановление приватного ключа — это чистые вычисления криптографии, оно не зависит от истории полного нода, поэтому с этим справится и лёгкий клиент. Но он не может независимо проверить, что конкретный UTXO действительно “заперт” в скрипт Babylon — для этого нужен либо полный нод, либо индексатор; лёгкий клиент доверяет только цепочке header’ов.
В гайде по установке Vigilante в официальной документации говорится, что нужно “a synced Bitcoin full node”. Но на практике: запускал стража, подключая Bitcoin Core в light-режиме (prune=1), проходило тестирование; после того как я закинул 0.05 BTC на testnet, страж один раз сообщал FP skip подпись — и ничего не пропустил.
Если в основной сети произойдёт глубокий реорганиз (>>6 блоков), лёгкий клиент может кратковременно неверно определить позицию по временным меткам, тогда как полный нод это заметит раньше. Что он экономит: диск (примерно 80MB/год). Цена: когда источник header’ов будет загрязнён, вас тоже может увести в сторону. Если вы запускаете стража в одиночку, лёгкого клиента обычно достаточно, при условии, что вы доверяете выбранному источнику header’ов. Параноики же запускают полный нод плюс индексатор — там само-проверяется всё.
Это не выбор “или то, или другое”, а компромисс между стоимостью и степенью самоуправления.
#baby $BABY @BabylonLabs_io