凌晨两点，老陈扔过来一个链接：“Babylon，用比特币给PoS链当保安，你瞅瞅。”
我点开文档，盯着“Bitcoin-secured PoS”看了很久。“Babylon enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.” С помощью экономической безопасности биткоина в качестве внешнего защитного слоя, PoS-цепь делится с BTC своей окончательностью — идея правда красивая. Любой, кто писал протоколы консенсуса, увидев эту схему, вынужден признать: сейчас это самое агрессивное по безопасности испытание в этой нише.
Но когда я стал разбирать облегчённый клиент дальше, по спине пробежал холодок.
Цепь Babylon работает только с BTC light node: она не выполняет неполную синхронизацию полного реестра биткоина, а полагается на заголовки блоков и проверку скриптов UTXO. В отчёте аудита от Zellic прямо указано: если сеть Babylon из-за panic упадёт и после перезапуска будет восстановлена работа, btclightclient всё равно будет считать высоту, существовавшую до падения, последним актуальным состоянием. В это «окно тишины» злоумышленный майнинг-пул может опередить и подать заголовки блоков разветвлённой цепочки; облегчённый клиент временно примет форк за основную цепь — и операции стейкинга могут быть подтверждены в ошибочном форке. А когда в сети биткоина появляются осколочные блоки, происходят реорганизации и происходит откат глубоких блоков, облегчённый клиент не способен это распознать.
Ещё сильнее холодит меня EOTS. Это одноразовая подпись, которую можно «извлечь» в Babylon — используется для кроссчейн-доказательства наказания: “if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing”。 Звучит отлично, но аудит Zellic обнаружил: в eotsmanager функция GenerateRandomness при использовании SetByteSlice не проверяет возвращаемое значение — при переполнении по модулю порядка группы Secp256k1 nonce становится распределённым неравномерно. Хотя вероятность и низкая, но если переполнение всё-таки произойдёт, в связке с алгоритмом Hidden Number Problem можно восстановить приватный ключ EOTS. Ещё более губительно: GHSA-7mm3-vfg8-7rg6 — модуль x/finality не имеет разделения домена, и атакующий может переренести подпись PoP (replay) в MsgCommitPubRandList, внедрив недействительные обязательства PubRand.
Использовать окончательность биткоина как крепостной ров, но при этом облегчённый клиент не видит разветвления в биткоине — и при наказании полагаются на самописную криптографию, где генерация случайного числа EOTS даже не проверяет переполнения. Ты веришь в цепочку биткоина — или в этот код?
#baby $BABY @BabylonLabs_io
我点开文档，盯着“Bitcoin-secured PoS”看了很久。“Babylon enables native bitcoin staking directly on the Bitcoin blockchain without intermediaries.” С помощью экономической безопасности биткоина в качестве внешнего защитного слоя, PoS-цепь делится с BTC своей окончательностью — идея правда красивая. Любой, кто писал протоколы консенсуса, увидев эту схему, вынужден признать: сейчас это самое агрессивное по безопасности испытание в этой нише.
Но когда я стал разбирать облегчённый клиент дальше, по спине пробежал холодок.
Цепь Babylon работает только с BTC light node: она не выполняет неполную синхронизацию полного реестра биткоина, а полагается на заголовки блоков и проверку скриптов UTXO. В отчёте аудита от Zellic прямо указано: если сеть Babylon из-за panic упадёт и после перезапуска будет восстановлена работа, btclightclient всё равно будет считать высоту, существовавшую до падения, последним актуальным состоянием. В это «окно тишины» злоумышленный майнинг-пул может опередить и подать заголовки блоков разветвлённой цепочки; облегчённый клиент временно примет форк за основную цепь — и операции стейкинга могут быть подтверждены в ошибочном форке. А когда в сети биткоина появляются осколочные блоки, происходят реорганизации и происходит откат глубоких блоков, облегчённый клиент не способен это распознать.
Ещё сильнее холодит меня EOTS. Это одноразовая подпись, которую можно «извлечь» в Babylon — используется для кроссчейн-доказательства наказания: “if an FP signs two different blocks at the same height, the private key is exposed, leading to automatic slashing”。 Звучит отлично, но аудит Zellic обнаружил: в eotsmanager функция GenerateRandomness при использовании SetByteSlice не проверяет возвращаемое значение — при переполнении по модулю порядка группы Secp256k1 nonce становится распределённым неравномерно. Хотя вероятность и низкая, но если переполнение всё-таки произойдёт, в связке с алгоритмом Hidden Number Problem можно восстановить приватный ключ EOTS. Ещё более губительно: GHSA-7mm3-vfg8-7rg6 — модуль x/finality не имеет разделения домена, и атакующий может переренести подпись PoP (replay) в MsgCommitPubRandList, внедрив недействительные обязательства PubRand.
Использовать окончательность биткоина как крепостной ров, но при этом облегчённый клиент не видит разветвления в биткоине — и при наказании полагаются на самописную криптографию, где генерация случайного числа EOTS даже не проверяет переполнения. Ты веришь в цепочку биткоина — или в этот код?
#baby $BABY @BabylonLabs_io