@BabylonLabs_io Я продолжаю возвращаться к тому, как сформулировано условие скашивания в Babylon. Подпишите два конфликтующих блока на одной и той же высоте своим ключом EOTS — и сама математика раскрывает ваш приватный ключ. Это не требует проверки комитетом, решения голосованием и вообще ничего: криптография просто срабатывает.

Под всем этим скрывается кое-что более интересное, чем сам механизм. Сейчас существует рынок сторонних key-менеджеров, созданный специально, чтобы этого не происходило, потому что у протокола нет способа отделить оператора, который схитрил, от того, у кого клиентское ПО просто дало сбой. Заявление «без доверия, без комитета» действительно на уровне протокола, но реальная безопасность в реальном мире теперь частично зависит от того, внедрил ли конкретный провайдер финальности одного из этих вендоров. Это частное бизнес-решение, а не то, что записано в цепочке.

Для тех, кто распределяет BTC через провайдера финальности, это переменная, которую вы сейчас не можете проверить. Принятие вендоров не раскрывается, не стандартизировано и не является частью какого-либо чек-листа due diligence, который я видел в обращении.

Криптографическая «чистота» должна была избавить от необходимости доверять чьим-то суждениям. Вместо этого она просто сдвинула эти суждения на один уровень ниже — в подбор вендоров, который никто не публикует.

У условия скашивания без комитета всё равно есть комитет — просто его роль решает рынок вендоров: кто будет покрыт.

Честный пробел здесь в том, что у меня нет также и чисел по внедрению, поэтому это структурное наблюдение, а не измеренный риск.
#baby $BABY $BLESS $HOME
Ваш провайдер финальности запускает защиту EOTS-ключей?