Неспособность остановить Payout ≠ возможность переписать направление BTC
В Trustless Bitcoin Vaults (TBV) Security Council легко ошибочно принять за структуру, которая владеет BTC через мультиподпись. Текущая публичная тестовая сеть использует 5 биткоин-публичных ключей и 3 из 5 как кворум; публичные ключи записываются в версионируемые офчейн-параметры протокола и используются для совместной подписи CouncilNoPayout. Он может предотвратить Payout конкретного Vault, но не может направить BTC на новый адрес, указанный Council.
Ограничения задаются заранее фиксированной Bitcoin-диаграммой расходов, которая закрепляется при создании Vault. Депозиторы заранее подписывают Payout и определяют законное место назначения: обычный выход или self-claim возвращает средства на адрес депозитора при соблюдении уже существующих условий; путь ликвидации ведёт на заранее уполномоченный адрес Application Vault Keeper. Ключи Council не входят в эту группу адресов-получателей, поэтому даже при достижении кворума есть только право блокировки, но нет права перенаправления активов.
Это отличается от No-Payout, который challenger транслирует в рамках нормального спора: тот опирается на то, что оспариваемый Claim оказался недействительным и не удаётся предоставить опровержение. CouncilNoPayout предназначен для крайних сбоев или особого восстановления, которые стандартный механизм не способен обработать. Пауза на стороне Ethereum — это ещё один уровень: она может приостановить действия приложения, но не может переписать уже существующие пути Pre-PegIn refund и WOTS self-claim.
CouncilNoPayout изменил мои критерии оценки: я больше не спрашиваю, есть ли в системе комитет, а спрашиваю, какие именно результаты он может заставить принять в отношении Bitcoin. Он может предотвратить расход — значит, всё ещё появляется риск доступности и задержки выхода; но если он не создаёт новые назначения, то самый плохой исход ограничивается блокировкой, а не перенаправлением активов. Если полномочия Council будут злоупотреблены, законные Payout всё равно могут быть заблокированы; если Council окажется недоступен, снизится и способность к экстренному восстановлению — нельзя записать такую конструкцию как дизайн с нулевым риском.
@BabylonLabs_io задаёт Security Council как переходное защитное обеспечение: цель — по мере зрелости протокола постепенно выводить из эксплуатации его полномочия. Действительно важнее смотреть не на то, существует ли мультиподпись, а на то, на какой стадии экстренные полномочия ограничиваются биткоин-путями расходов. $BTC $ETH
$BABY
#baby
В Trustless Bitcoin Vaults (TBV) Security Council легко ошибочно принять за структуру, которая владеет BTC через мультиподпись. Текущая публичная тестовая сеть использует 5 биткоин-публичных ключей и 3 из 5 как кворум; публичные ключи записываются в версионируемые офчейн-параметры протокола и используются для совместной подписи CouncilNoPayout. Он может предотвратить Payout конкретного Vault, но не может направить BTC на новый адрес, указанный Council.
Ограничения задаются заранее фиксированной Bitcoin-диаграммой расходов, которая закрепляется при создании Vault. Депозиторы заранее подписывают Payout и определяют законное место назначения: обычный выход или self-claim возвращает средства на адрес депозитора при соблюдении уже существующих условий; путь ликвидации ведёт на заранее уполномоченный адрес Application Vault Keeper. Ключи Council не входят в эту группу адресов-получателей, поэтому даже при достижении кворума есть только право блокировки, но нет права перенаправления активов.
Это отличается от No-Payout, который challenger транслирует в рамках нормального спора: тот опирается на то, что оспариваемый Claim оказался недействительным и не удаётся предоставить опровержение. CouncilNoPayout предназначен для крайних сбоев или особого восстановления, которые стандартный механизм не способен обработать. Пауза на стороне Ethereum — это ещё один уровень: она может приостановить действия приложения, но не может переписать уже существующие пути Pre-PegIn refund и WOTS self-claim.
CouncilNoPayout изменил мои критерии оценки: я больше не спрашиваю, есть ли в системе комитет, а спрашиваю, какие именно результаты он может заставить принять в отношении Bitcoin. Он может предотвратить расход — значит, всё ещё появляется риск доступности и задержки выхода; но если он не создаёт новые назначения, то самый плохой исход ограничивается блокировкой, а не перенаправлением активов. Если полномочия Council будут злоупотреблены, законные Payout всё равно могут быть заблокированы; если Council окажется недоступен, снизится и способность к экстренному восстановлению — нельзя записать такую конструкцию как дизайн с нулевым риском.
@BabylonLabs_io задаёт Security Council как переходное защитное обеспечение: цель — по мере зрелости протокола постепенно выводить из эксплуатации его полномочия. Действительно важнее смотреть не на то, существует ли мультиподпись, а на то, на какой стадии экстренные полномочия ограничиваются биткоин-путями расходов. $BTC $ETH
$BABY
#baby