Исследуя кроссчейн-архитектуру Babylon, я обнаружил, что они использовали вариант протокола IBC для state synchronization.
В частности, Babylon напрямую не модифицировали consensus layer биткоина, а построили над биткоином слой light client. Этот light client отвечает за прослушивание заголовков блоков биткоина, верификацию Merkle proof для транзакций checkpoint, а затем ретрансляцию результата в дочернюю PoS-сеть.
Преимущество такой схемы — модульность: биткоин не нужно менять, все адаптации выполняются на уровне протокола Babylon.
Но, на мой взгляд, главная техническая сложность — работа с вероятностной финальностью биткоина. Финальность биткоина вероятностна: после подтверждения блока теоретически всё ещё возможен reorg. В подходе Babylon это решается ожиданием определённого числа подтверждений (например, 6 блоков), прежде чем считать checkpoint финальным.
Выбор этого числа подтверждений — типичный компромисс между безопасностью и задержкой: чем больше подтверждений, тем выше безопасность, но тем дольше финализация.
Параметры, которые Babylon выбирает сейчас, выглядят довольно консервативными. Лично я считаю, что на ранней стадии это правильная стратегия — лучше медленнее, чем столкнуться с slash-событиями из‑за reorg.
Ещё один момент, который стоит отметить, — атомарность обмена cross-chain сообщениями. Babylon нужно обеспечить, чтобы два события — подтверждение checkpoint в биткоине и его исполнение в PoS-сети — были атомарными. Они используют вариант протокола two-phase commit: сначала prepare, затем commit; если сбой случается на любой стадии, выполняется rollback.
Такой дизайн в распределённых системах уже хорошо отработан, но при переносе в крипто-кроссчейн-сценарий нужно дополнительно учитывать гарантии liveness в условиях extreme.
$BABY #baby @BabylonLabs_io
В частности, Babylon напрямую не модифицировали consensus layer биткоина, а построили над биткоином слой light client. Этот light client отвечает за прослушивание заголовков блоков биткоина, верификацию Merkle proof для транзакций checkpoint, а затем ретрансляцию результата в дочернюю PoS-сеть.
Преимущество такой схемы — модульность: биткоин не нужно менять, все адаптации выполняются на уровне протокола Babylon.
Но, на мой взгляд, главная техническая сложность — работа с вероятностной финальностью биткоина. Финальность биткоина вероятностна: после подтверждения блока теоретически всё ещё возможен reorg. В подходе Babylon это решается ожиданием определённого числа подтверждений (например, 6 блоков), прежде чем считать checkpoint финальным.
Выбор этого числа подтверждений — типичный компромисс между безопасностью и задержкой: чем больше подтверждений, тем выше безопасность, но тем дольше финализация.
Параметры, которые Babylon выбирает сейчас, выглядят довольно консервативными. Лично я считаю, что на ранней стадии это правильная стратегия — лучше медленнее, чем столкнуться с slash-событиями из‑за reorg.
Ещё один момент, который стоит отметить, — атомарность обмена cross-chain сообщениями. Babylon нужно обеспечить, чтобы два события — подтверждение checkpoint в биткоине и его исполнение в PoS-сети — были атомарными. Они используют вариант протокола two-phase commit: сначала prepare, затем commit; если сбой случается на любой стадии, выполняется rollback.
Такой дизайн в распределённых системах уже хорошо отработан, но при переносе в крипто-кроссчейн-сценарий нужно дополнительно учитывать гарантии liveness в условиях extreme.
$BABY #baby @BabylonLabs_io