Подавляющее большинство DeFi-продуктов по умолчанию придерживаются одной негласной нормы: результат, выводимый контрактом, считается окончательным вердиктом. После того как транзакция выполнена, не существует канала для последующего оспаривания или отмены. Если в смарт-контракте есть уязвимости, данные оракулов подделаны, а логика ликвидации работает некорректно, то потеря средств пользователей считается свершившимся фактом — исправительных механизмов нет. Все участники вынуждены пассивно принять последствия.
Архитектура TBV @BabylonLabs_io с введением механизма двусторонних доказательств и вызова (challenge) разрушает эту одностороннюю модель исполнения. Опираясь на систему доказательств BABE, операции, связанные с изменением прав собственности на BTC — такие как выкуп залога, расчеты при залоговой ликвидации и т.п. — больше не сводятся к одному подтверждению «и сразу в прод». Каждая операция снабжается криптографическим доказательством; участники сообщества имеют право инициировать вызов. Поддельные, просроченные или измененные доказательства, если по ним есть проблемы, будут непосредственно перехвачены базовыми скриптами Биткоина, что предотвратит аномальный вывод активов.
За этой задумкой стоят компромиссы. Добавление для BTC канала постпроверки неизбежно увеличит период ожидания транзакций и поднимет сложность всей системы, пожертвовав гибкостью операций с капиталом. Нетрудно заметить: проект выбирает прежде всего соблюсти базовую границу безопасности нативных активов Биткоина и не хочет упрощать пороги проверки ради скорости сделок. #baby
Но мощь дизайна на бумаге не равна надежности в реальности. Я не буду делать вывод, исходя лишь из концепции; ключевой фокус — на двух индикаторах. Во-первых, сможет ли система стабильно достигать целевого показателя успешного перехвата при аномальных доказательствах, сформированных злоумышленниками. Во-вторых, при высокочастотной торговле и в условиях экстремальной волатильности, когда одновременно возникает большое количество запросов на вызов, не произойдет ли «понижение режима» (degradation), и потребуется ли ручное вмешательство как подстраховка.
Если же окажется, что поддерживать работоспособность можно только при централизованной координации, тогда ценность криптографических вызовов существенно обесценивается. Многие протоколы нагромождают красивые механизмы безопасности, но в условиях экстремального давления порой незаметно ослабляют ограничения.
В конце концов, настоящему децентрализованному BTCFi не следует заставлять пользователей безусловно доверять однократному результату on-chain исполнения. Канал вызовов дает всем право исправлять ошибки. Но возникает новая проблема: постоянное включение механизма вызовов увеличивает эксплуатационные издержки. По мере роста масштаба экосистемы ослабят ли проектные команды со временем эту систему правил валидации? $BABY
Архитектура TBV @BabylonLabs_io с введением механизма двусторонних доказательств и вызова (challenge) разрушает эту одностороннюю модель исполнения. Опираясь на систему доказательств BABE, операции, связанные с изменением прав собственности на BTC — такие как выкуп залога, расчеты при залоговой ликвидации и т.п. — больше не сводятся к одному подтверждению «и сразу в прод». Каждая операция снабжается криптографическим доказательством; участники сообщества имеют право инициировать вызов. Поддельные, просроченные или измененные доказательства, если по ним есть проблемы, будут непосредственно перехвачены базовыми скриптами Биткоина, что предотвратит аномальный вывод активов.
За этой задумкой стоят компромиссы. Добавление для BTC канала постпроверки неизбежно увеличит период ожидания транзакций и поднимет сложность всей системы, пожертвовав гибкостью операций с капиталом. Нетрудно заметить: проект выбирает прежде всего соблюсти базовую границу безопасности нативных активов Биткоина и не хочет упрощать пороги проверки ради скорости сделок. #baby
Но мощь дизайна на бумаге не равна надежности в реальности. Я не буду делать вывод, исходя лишь из концепции; ключевой фокус — на двух индикаторах. Во-первых, сможет ли система стабильно достигать целевого показателя успешного перехвата при аномальных доказательствах, сформированных злоумышленниками. Во-вторых, при высокочастотной торговле и в условиях экстремальной волатильности, когда одновременно возникает большое количество запросов на вызов, не произойдет ли «понижение режима» (degradation), и потребуется ли ручное вмешательство как подстраховка.
Если же окажется, что поддерживать работоспособность можно только при централизованной координации, тогда ценность криптографических вызовов существенно обесценивается. Многие протоколы нагромождают красивые механизмы безопасности, но в условиях экстремального давления порой незаметно ослабляют ограничения.
В конце концов, настоящему децентрализованному BTCFi не следует заставлять пользователей безусловно доверять однократному результату on-chain исполнения. Канал вызовов дает всем право исправлять ошибки. Но возникает новая проблема: постоянное включение механизма вызовов увеличивает эксплуатационные издержки. По мере роста масштаба экосистемы ослабят ли проектные команды со временем эту систему правил валидации? $BABY