Сразу же в глаза бросилось то, насколько узко очерчена область делегирования.
Чем дольше я в это вникал, тем больше ощущалось, что это вообще не похоже на просто дизайнерское решение.
Если точнее, это было похоже на то, от чего протокол не мог отказаться.
Предоставление кому-то права заимствования над вашим BTC обычно сопровождается негласным расширением полномочий.
В конечном итоге этот человек может получить доступ к большему числу активов, чем предполагалось.
Из-за этого я снова и снова возвращался к одному центральному вопросу.
Почему Trustless Bitcoin Vaults (TBV) отказывается позволять этому авторитету разрастаться постфактум?
Если присмотреться, ответ кажется в том, что TBV с самого начала рассматривает хранение и разрешения как отдельные вещи.
Это не то, что «включают» уже тогда, когда делегирование уже идет.
От этого у меня возникло любопытство относительно ключевого прорыва.
Возможно, реальная инновация здесь вовсе не в механизме делегирования.
Вместо этого — в решении убрать сам момент, когда область могла бы когда-либо расшириться.
Доказательство в нулевом разглашении состояния контракта обеспечивает это, разумеется.
Но по сути, для всех практических целей это похоже почти на второстепенный момент.
Становится ясно, как только вы замечаете, что именно здесь решается.
Это меньше про безопасное делегирование и больше про то, чтобы вопрос доверия стал неуместным еще до того, как он вообще мог бы возникнуть.
На данный момент полностью неясно другое: станет ли та же жесткость ограничением позже.
Если «починить» всё еще при создании, это может вызвать проблемы в тот момент, когда btc-ориентированным системам нужно будет эволюционировать после развертывания.
Со временем это противоречие, возможно, скажет больше о том, как проектировать в Bitcoin, чем о том, что сам TBV изначально собирался раскрыть.
$BABY #baby @BabylonLabs_io