Честно говоря, я остановился на примере из белой книги Babylon, который показался слишком «чистым», чтобы быть реальным решением.

Заёмщик блокирует BTC, чтобы взять заём у кредитора в Ethereum. Согласно белой книге, обе стороны заранее подписывают набор транзакций Bitcoin, заранее определяя, в какой момент каждая сторона может потребовать средства.
Я ожидал, что на этом всё закончится и вопрос будет считаться решённым. Нет. Следующая строка говорит, что такой подход с пред-подписанием работает только для одного конкретного триггерного события и не может быть обобщён на произвольные условия DeFi.

И именно эта деталь меня зацепила. Механизм, который должен доказывать бездоверительность, сразу, своими же словами, заявляет, что он покрывает только один конкретный тип события и его нельзя «растянуть», чтобы он справлялся с любыми произвольными условиями.

Вот почему BitVM3 вообще существует в этой архитектуре. В том же документе сказано, что он обобщает эту идею, чтобы работать с любым доказательством состояния вне цепочки, а не только с одним жёстко заданным триггером, при этом убирая необходимость, чтобы контрагент оставался онлайн.

Я некоторое время переваривал порядок изложения в этом объяснении. Большинство версий TBV сразу ведут к готовому механизму. В белой книге показана простая версия, объясняется, где она упирается в предел, а затем вводится реальное исправление.

Большинство обзоров сразу переходят к BitVM3. Почти никто не упоминает, что сначала пришлось оставить позади. Для меня этот порядок всё ещё кажется самой честной частью дизайна.

@BabylonLabs_io #baby $BABY