Читая @BabylonLabs_io техническую спецификацию, скрипт стейкинга Bitcoin использует OP_CHECKMULTISIGVERIFY, чтобы обеспечить требование к кворуму валидаторов. Но в этом есть тонкость: сам скрипт не кодирует условия слэшинга — он лишь проверяет, что требуемое количество валидаторов подписало.
Это означает, что блокировка в Bitcoin по своей структуре проста: либо пользователь выводит средства после анбандлинга, хм.. либо валидаторский набор подписывает транзакцию на слэшинг. Фактическая логика слэшинга — что считается неправомерным поведением, сколько именно будет списано, какие валидаторы подписывают — полностью вынесена на off-chain, обеспечивается Babylon Genesis chain, а не скриптом Bitcoin.
Итак, слой Bitcoin предоставляет криптографическую окончательность для блокировки, но условия этой блокировки определяются состоянием цепочки Babylon. Если цепочка Babylon говорит: "валидатор X совершил неправомерные действия, слэшните их делегаторов", то кворум валидаторов подписывает транзакцию на слэшинг, и Bitcoin выполняет её. Но у Bitcoin нет способа независимо проверить, что слэшинг был обоснован.
Это меняет модель доверия: Bitcoin гарантирует, что UTXO нельзя потратить без подписи кворума, хм.. но он не гарантирует, что кворум использует подпись честно. Безопасность переносится из proof-of-work Bitcoin в консенсус валидаторов Babylon. «Нативная» часть действительно есть, но «без доверия» опирается на те же допущения, что и любая PoS-цепь: что набор валидаторов честен и экономически согласован.
По сравнению с чистым мостом на базе Ethereum Babylon уменьшает площадь для эксплойтов — нет токена-обёртки, нет риска минта — но не устраняет зависимость от валидаторов. Скрипт блокировки — это просто инструмент; цепочка Babylon — судья.
Если валидаторский набор будет скомпрометирован, предлагает ли скрипт Bitcoin какую-либо защиту помимо блокировки, к которой атакующие уже контролируют ключ?
#baby $BABY