Nova_eth_20
422 Публикации
Nova_eth_20
129 подписок(и/а)
1.5K+ подписчиков(а)
450 понравилось
Посты
Все
Цитирования
#baby $BABY @BabylonLabs_io
Я сравнивал валидаторов для моей делегации BABY и почти пропустил «блокировку» (jailing) — стандартный космосовский шаблон, который есть у каждой цепочки: пропущенные блоки, временный таймаут, без ничего конкретного про Babylon. Потом я прочитал, что валидаторы на самом деле подписывают дважды, а не один раз.
Каждый валидатор Genesis в Babylon выполняет две отдельные задачи. Обычная подпись блоков CometBFT — стандартная работа любого валидатора в Cosmos — и вторая: BLS-голосование в конце каждого эпохи (epoch), когда подписи валидаторов агрегируются в чекпойнт, который ставится напрямую на Bitcoin с временной меткой. Вторая подпись — это и есть вся причина, почему люди называют эту цепочку «Bitcoin-secured».
Блокировки из-за простоя (downtime jailing) касаются только первой задачи — в рамках ее собственных условий, обычного контроля живучести (liveness), без ничего драматичного. То, что мне не удалось точно выяснить, — это взаимодействие: аккуратно ли блокировка, случившаяся посреди эпохи, тихо лишает весь BLS-вклад этой эпохи, или это имеет значение только если валидатор оставался активным в момент закрытия эпохи. В документации Babylon подтверждается, что две задачи разделены. Но нигде в том, что я нашёл, не расписан этот конкретный временной граничный момент.
В любом случае, у этих двух задач общий показатель аптайма. Валидатора, заблокированного из-за обычных пропущенных блоков — той же нормы, что работает на любой Cosmos-цепочке, — не защищает то, что он также может пропустить подпись, которая действительно закрепляется на Bitcoin именно в ту эпоху, и причина тут вообще не связана с «Bitcoin-secured».
Я не думаю, что это какая-то ошибка дизайна: нет аккуратного способа «заколоть» (jail) человека в одной роли и не в другой на том же ключе. То, что я раньше не разделил в голове, — что история простоя — это не только про пропущенные вознаграждения. Это грубый прокси того, насколько часто валидатор был реально на месте для подписи, которая делает правдой фразу «Bitcoin-secured».
Снова проверил историю блокировок в моём шортлисте. Два имени: по одной записи у каждого; обоим было больше года, и у обоих были долгие чистые промежутки после. Это не красный флаг. Просто не то же самое «нулевое» значение, которое я считал признаком идеального аптайма.
$BLESS
🤔 Что первое вы проверяете перед тем, как делегировать своему baby?
Я сравнивал валидаторов для моей делегации BABY и почти пропустил «блокировку» (jailing) — стандартный космосовский шаблон, который есть у каждой цепочки: пропущенные блоки, временный таймаут, без ничего конкретного про Babylon. Потом я прочитал, что валидаторы на самом деле подписывают дважды, а не один раз.
Каждый валидатор Genesis в Babylon выполняет две отдельные задачи. Обычная подпись блоков CometBFT — стандартная работа любого валидатора в Cosmos — и вторая: BLS-голосование в конце каждого эпохи (epoch), когда подписи валидаторов агрегируются в чекпойнт, который ставится напрямую на Bitcoin с временной меткой. Вторая подпись — это и есть вся причина, почему люди называют эту цепочку «Bitcoin-secured».
Блокировки из-за простоя (downtime jailing) касаются только первой задачи — в рамках ее собственных условий, обычного контроля живучести (liveness), без ничего драматичного. То, что мне не удалось точно выяснить, — это взаимодействие: аккуратно ли блокировка, случившаяся посреди эпохи, тихо лишает весь BLS-вклад этой эпохи, или это имеет значение только если валидатор оставался активным в момент закрытия эпохи. В документации Babylon подтверждается, что две задачи разделены. Но нигде в том, что я нашёл, не расписан этот конкретный временной граничный момент.
В любом случае, у этих двух задач общий показатель аптайма. Валидатора, заблокированного из-за обычных пропущенных блоков — той же нормы, что работает на любой Cosmos-цепочке, — не защищает то, что он также может пропустить подпись, которая действительно закрепляется на Bitcoin именно в ту эпоху, и причина тут вообще не связана с «Bitcoin-secured».
Я не думаю, что это какая-то ошибка дизайна: нет аккуратного способа «заколоть» (jail) человека в одной роли и не в другой на том же ключе. То, что я раньше не разделил в голове, — что история простоя — это не только про пропущенные вознаграждения. Это грубый прокси того, насколько часто валидатор был реально на месте для подписи, которая делает правдой фразу «Bitcoin-secured».
Снова проверил историю блокировок в моём шортлисте. Два имени: по одной записи у каждого; обоим было больше года, и у обоих были долгие чистые промежутки после. Это не красный флаг. Просто не то же самое «нулевое» значение, которое я считал признаком идеального аптайма.
$BLESS
🤔 Что первое вы проверяете перед тем, как делегировать своему baby?
Validator uptime 📈
34%
Jailing history 🚨
0%
Commission fees 💰
33%
Reputation & community 🌟
33%
3 проголосовали • Голосование закрыто
$CYS
Mù 穆涵
·
--
$BABY #baby @BabylonLabs_io
Я выбрал поставщика финальности, исходя из размера их делегирования BTC и истории доступности — тех цифр, которые отображаются на каждом дашборде. Позже я прочитал, что на самом деле обеспечивает работу этого поставщика изо дня в день, и оказалось, что это вообще не BTC.
Каждому поставщику финальности нужна отдельная операционная ключевая пара, пополненная BABY, малыми суммами: она используется для оплаты газа за отправку свежей случайности по повторяющемуся расписанию. Отправки голосований автоматически возмещаются — это подтверждают собственные документы операторов Babylon. Другие транзакции с этого же ключа, включая повторяющиеся коммиты случайности, требуют газа, который не возвращается. В документации это описано почти как мелочь: «добавьте минимум, держите работающим долго», одна фраза рядом с теми элементами безопасности, которые я и искал.
Пропустите пополнение — и поставщик не будет «тайно скомпрометирован»: их BTC-дeлегирование всё так же останется таким же большим и честным, как и вчера. Просто они больше не смогут продолжать участвовать, пока кто-то не заметит пустой кошелёк и не пополнит его. Поставщик может быть безупречным по всем метрикам, которые я проверял перед делегированием, и всё равно уйти в «тень» из‑за такой мелочи, как газовый ключ, о котором никто не вспомнил пополнить.
Дашборды делегирования показывают комиссию, размер делегирования, историю доступности. Ни один из них не показывает, комфортно ли профинансирован операционный ключ поставщика или он работает на «последнем дыхании», потому что эта цифра изначально не была предназначена для публичности.
Я не думаю, что это изъян проектирования: минимальный и отдельный от реальных активов поставщика размер операционного ключа — вполне разумный выбор безопасности, а не халатность. Что это означает для любого, кто делегирует: выбравшего поставщика по их BTC‑репутации вы получаете ещё и, тихо, услугу по напоминанию о покупке газа.
$HEI
Знали ли вы, что операционный ключ поставщика финальности может «высохнуть», даже если их BTC‑делегирование выглядит абсолютно здоровым?
Я выбрал поставщика финальности, исходя из размера их делегирования BTC и истории доступности — тех цифр, которые отображаются на каждом дашборде. Позже я прочитал, что на самом деле обеспечивает работу этого поставщика изо дня в день, и оказалось, что это вообще не BTC.
Каждому поставщику финальности нужна отдельная операционная ключевая пара, пополненная BABY, малыми суммами: она используется для оплаты газа за отправку свежей случайности по повторяющемуся расписанию. Отправки голосований автоматически возмещаются — это подтверждают собственные документы операторов Babylon. Другие транзакции с этого же ключа, включая повторяющиеся коммиты случайности, требуют газа, который не возвращается. В документации это описано почти как мелочь: «добавьте минимум, держите работающим долго», одна фраза рядом с теми элементами безопасности, которые я и искал.
Пропустите пополнение — и поставщик не будет «тайно скомпрометирован»: их BTC-дeлегирование всё так же останется таким же большим и честным, как и вчера. Просто они больше не смогут продолжать участвовать, пока кто-то не заметит пустой кошелёк и не пополнит его. Поставщик может быть безупречным по всем метрикам, которые я проверял перед делегированием, и всё равно уйти в «тень» из‑за такой мелочи, как газовый ключ, о котором никто не вспомнил пополнить.
Дашборды делегирования показывают комиссию, размер делегирования, историю доступности. Ни один из них не показывает, комфортно ли профинансирован операционный ключ поставщика или он работает на «последнем дыхании», потому что эта цифра изначально не была предназначена для публичности.
Я не думаю, что это изъян проектирования: минимальный и отдельный от реальных активов поставщика размер операционного ключа — вполне разумный выбор безопасности, а не халатность. Что это означает для любого, кто делегирует: выбравшего поставщика по их BTC‑репутации вы получаете ещё и, тихо, услугу по напоминанию о покупке газа.
$HEI
Знали ли вы, что операционный ключ поставщика финальности может «высохнуть», даже если их BTC‑делегирование выглядит абсолютно здоровым?
#baby @BabylonLabs_io
Вчера ночью наткнулся на подробный разбор срезов (slashing) в поисках точного числа штрафа для BTC. Нашёл: 0,1% от поставленного (staked) BTC за двойную подпись. Затем нашёл строку прямо рядом с этим — то, чего я изначально не искал: ранее полученные вознаграждения не подлежат изъятию (clawback).
Провайдера навсегда банят, сажают — без вариантов, никаких новых делегаций, никаких новых комиссий. Но любая комиссия, которую он уже успел собрать до нарушения, остаётся его. Штраф применяется вперёд с момента, когда его поймали. Он не откатывается назад на то, сколько времени он мог работать до этого.
Для совершенно нового провайдера эта разница почти не имеет значения: накапливать уже нечего. А вот для того, кто ведёт делегации год, зарабатывая комиссионную надбавку в каждом цикле вознаграждений всё это время — математика меняется. Один 0,1% срез затрагивает всех делегатов этому провайдеру пропорционально — и провайдера, и делегаторов. То, что не трогают, — это история комиссий, сколько бы он ни успел забрать на руки.
Я не знаю, сколько конкретный провайдер реально заработал за время своей работы — нигде публично этого не нашёл, поэтому не могу сказать, насколько этот разрыв тривиален или реален. Но то, что могу сказать: сдерживающий эффект (deterrent) специально сделали работающим только вперёд. Изъятие исторических вознаграждений означало бы заново открывать каждый прошлый цикл наград — а это отдельный беспорядок, который нужно проектировать и продумывать.
Бан навсегда и банкротство — два разных исхода, и собственный дизайн Babylon по slashing гарантирует только первый.
$CYS $BABY
Вчера ночью наткнулся на подробный разбор срезов (slashing) в поисках точного числа штрафа для BTC. Нашёл: 0,1% от поставленного (staked) BTC за двойную подпись. Затем нашёл строку прямо рядом с этим — то, чего я изначально не искал: ранее полученные вознаграждения не подлежат изъятию (clawback).
Провайдера навсегда банят, сажают — без вариантов, никаких новых делегаций, никаких новых комиссий. Но любая комиссия, которую он уже успел собрать до нарушения, остаётся его. Штраф применяется вперёд с момента, когда его поймали. Он не откатывается назад на то, сколько времени он мог работать до этого.
Для совершенно нового провайдера эта разница почти не имеет значения: накапливать уже нечего. А вот для того, кто ведёт делегации год, зарабатывая комиссионную надбавку в каждом цикле вознаграждений всё это время — математика меняется. Один 0,1% срез затрагивает всех делегатов этому провайдеру пропорционально — и провайдера, и делегаторов. То, что не трогают, — это история комиссий, сколько бы он ни успел забрать на руки.
Я не знаю, сколько конкретный провайдер реально заработал за время своей работы — нигде публично этого не нашёл, поэтому не могу сказать, насколько этот разрыв тривиален или реален. Но то, что могу сказать: сдерживающий эффект (deterrent) специально сделали работающим только вперёд. Изъятие исторических вознаграждений означало бы заново открывать каждый прошлый цикл наград — а это отдельный беспорядок, который нужно проектировать и продумывать.
Бан навсегда и банкротство — два разных исхода, и собственный дизайн Babylon по slashing гарантирует только первый.
$CYS $BABY
$BICO
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
Вчера вечером перед тем, как делегировать, я проверил комиссию провайдера финальности: 5% — выглядело разумно по сравнению с остальными в списке. Почти делегировал, исходя только из этого. А потом выяснил, что за ним на самом деле стоит регистрационная команда Babylon.
Каждый провайдер финальности при регистрации задаёт три числа, а не одно. Текущая ставка комиссии, максимальная ставка, выше которой он никогда не может подняться, и максимальная скорость изменения — насколько быстро ему разрешено расти по направлению к этому потолку. Те 5%, на которые я смотрел, никогда не были всей картиной: это был один снимок на шкале, и у него есть отдельный, более высокий стоп, встроенный с самого начала.
Ничто не мешает провайдеру зарегистрироваться с 5%, указав при этом максимальную ставку 50%, а затем поднимать её небольшими легальными шагами каждый период, пока делегаторы, пришедшие под 5%, не начнут зарабатывать под совсем другим числом. Правил не нарушено, «ковра» никто не прячет — просто потолок, который всё время был публичным.
Я пошёл искать, где именно этот потолок проявляется для делегатора, который решает, кого выбрать. Насколько я смог выяснить, в собственных документах по стейкингу Babylon и в API, которое питает панель управления, на этом этапе показывается ровно одно поле: commission. Больше — означает меньше вознаграждений, и на этом всё: ничего более детального, чем это. Не максимальная ставка, которая находится на один уровень ближе в данных собственной регистрации провайдера.
Я не думаю, что это механизм предательский. Лимит скорости изменения существует ровно затем, чтобы комиссия не могла скачнуть за одну ночь — и эта защита реальна. Не хватает другого: число, которое на самом деле ограничивает ваши будущие доходы, никогда не было заложено так, чтобы его показывали на экране, откуда вы принимаете решение. В документации не сказано, сколько активных провайдеров уже ушли от своей стартовой ставки, и насколько близки они сейчас к своему потолку, поэтому я не могу сказать, является ли это текущим риском или только теоретическим.
5%, которое вы видите, — это фотография. А потолок всегда был тем самым реальным соглашением.
Знаете ли вы, что комиссия вашего провайдера финальности может вырасти выше числа, которое вы видите сегодня? 📈
Вчера вечером перед тем, как делегировать, я проверил комиссию провайдера финальности: 5% — выглядело разумно по сравнению с остальными в списке. Почти делегировал, исходя только из этого. А потом выяснил, что за ним на самом деле стоит регистрационная команда Babylon.
Каждый провайдер финальности при регистрации задаёт три числа, а не одно. Текущая ставка комиссии, максимальная ставка, выше которой он никогда не может подняться, и максимальная скорость изменения — насколько быстро ему разрешено расти по направлению к этому потолку. Те 5%, на которые я смотрел, никогда не были всей картиной: это был один снимок на шкале, и у него есть отдельный, более высокий стоп, встроенный с самого начала.
Ничто не мешает провайдеру зарегистрироваться с 5%, указав при этом максимальную ставку 50%, а затем поднимать её небольшими легальными шагами каждый период, пока делегаторы, пришедшие под 5%, не начнут зарабатывать под совсем другим числом. Правил не нарушено, «ковра» никто не прячет — просто потолок, который всё время был публичным.
Я пошёл искать, где именно этот потолок проявляется для делегатора, который решает, кого выбрать. Насколько я смог выяснить, в собственных документах по стейкингу Babylon и в API, которое питает панель управления, на этом этапе показывается ровно одно поле: commission. Больше — означает меньше вознаграждений, и на этом всё: ничего более детального, чем это. Не максимальная ставка, которая находится на один уровень ближе в данных собственной регистрации провайдера.
Я не думаю, что это механизм предательский. Лимит скорости изменения существует ровно затем, чтобы комиссия не могла скачнуть за одну ночь — и эта защита реальна. Не хватает другого: число, которое на самом деле ограничивает ваши будущие доходы, никогда не было заложено так, чтобы его показывали на экране, откуда вы принимаете решение. В документации не сказано, сколько активных провайдеров уже ушли от своей стартовой ставки, и насколько близки они сейчас к своему потолку, поэтому я не могу сказать, является ли это текущим риском или только теоретическим.
5%, которое вы видите, — это фотография. А потолок всегда был тем самым реальным соглашением.
Знаете ли вы, что комиссия вашего провайдера финальности может вырасти выше числа, которое вы видите сегодня? 📈
#baby @BabylonLabs_io
Сейчас у меня BTC застейкан через Babylon, поэтому, когда прошлой ночью я нашёл слово «overflow» (переполнение), зарытое в старой документации Cap-3, я не воспринял его как историю. Я воспринял его как вопрос о моей собственной позиции: может ли это случиться со мной.
Во время фазы 1 стейкинг-транзакции, которые подтвердились после того, как лимит уже заполнился, всё равно фиксировали BTC в контракте точно так же, как и у всех остальных. Они просто не заработали ничего: ни очков, ни выделения. Возврат монет тоже не происходил автоматически; в документах прямо сказано: стейкинги с overflow нужно было анбондайтить и выводить, ждать приходилось так же, как для активной позиции — для стейка, который платил ноль, пока он всё время был заблокирован.
То, кто попадал в лимит, определялось не тем, когда кто-то нажал «стейк». Решало, в каком блоке Bitcoin фактически подтвердится транзакция — это число никто полностью не контролирует после того, как оно выходит из кошелька. Двое могли отправить транзакции с разницей в минуты и попасть в разном порядке — в зависимости от комиссий, перегрузки mempool или того, какой майнер нашёл следующий блок первым.
Лимиты фазы 1 уже исчезли, но механизм, породивший overflow, не уникален для этой фазы. Любой будущий раунд с лимитом, новый онбординг BSN с фиксированным распределением, интеграция с ограниченным числом слотов — всё это наследует ту же гонку в тот момент, когда используются подтверждения блоков вместо очереди. Ничего в этом изъяне дизайна не было исправлено. Просто со временем лимиты исчезли, и стало «не актуально».
Я не думаю, что исходный дизайн был несправедливым: жёсткий лимит требует отсечки, и подтверждение блока нельзя подделать так, как можно подделать временную метку. Меня больше всего цепляет другое: мой собственный BTC сейчас заблокирован — и его никогда не защищали ни навык, ни удачное время. Его пропустили в линию, проведённую майнерами, а не мной. И в следующий раз, когда эту линию будут проводить, это всё равно будет так.
$SKYAI $BICO $BABY
«Остановит ли тебя этот риск overflow от стейкинга в будущем раунде с лимитом?» 🎯
Сейчас у меня BTC застейкан через Babylon, поэтому, когда прошлой ночью я нашёл слово «overflow» (переполнение), зарытое в старой документации Cap-3, я не воспринял его как историю. Я воспринял его как вопрос о моей собственной позиции: может ли это случиться со мной.
Во время фазы 1 стейкинг-транзакции, которые подтвердились после того, как лимит уже заполнился, всё равно фиксировали BTC в контракте точно так же, как и у всех остальных. Они просто не заработали ничего: ни очков, ни выделения. Возврат монет тоже не происходил автоматически; в документах прямо сказано: стейкинги с overflow нужно было анбондайтить и выводить, ждать приходилось так же, как для активной позиции — для стейка, который платил ноль, пока он всё время был заблокирован.
То, кто попадал в лимит, определялось не тем, когда кто-то нажал «стейк». Решало, в каком блоке Bitcoin фактически подтвердится транзакция — это число никто полностью не контролирует после того, как оно выходит из кошелька. Двое могли отправить транзакции с разницей в минуты и попасть в разном порядке — в зависимости от комиссий, перегрузки mempool или того, какой майнер нашёл следующий блок первым.
Лимиты фазы 1 уже исчезли, но механизм, породивший overflow, не уникален для этой фазы. Любой будущий раунд с лимитом, новый онбординг BSN с фиксированным распределением, интеграция с ограниченным числом слотов — всё это наследует ту же гонку в тот момент, когда используются подтверждения блоков вместо очереди. Ничего в этом изъяне дизайна не было исправлено. Просто со временем лимиты исчезли, и стало «не актуально».
Я не думаю, что исходный дизайн был несправедливым: жёсткий лимит требует отсечки, и подтверждение блока нельзя подделать так, как можно подделать временную метку. Меня больше всего цепляет другое: мой собственный BTC сейчас заблокирован — и его никогда не защищали ни навык, ни удачное время. Его пропустили в линию, проведённую майнерами, а не мной. И в следующий раз, когда эту линию будут проводить, это всё равно будет так.
$SKYAI $BICO $BABY
«Остановит ли тебя этот риск overflow от стейкинга в будущем раунде с лимитом?» 🎯
😰 Yeah, dealbreaker
34%
😌 Nah, worth the risk
33%
🤔 Depends on the cap size
33%
🙈 Didn't know this existed
0%
3 проголосовали • Голосование закрыто
$BLESS
Mù 穆涵
·
--
$BABY $BLESS #baby
Я зафиксировал свой коэффициент со-стейкинга три недели назад — 20 000 BABY за BTC, рекомендованное самим Babylon соотношение. Вчера ночью я проверил свои награды. Они оказались меньше, чем число, которое я посчитал в тот день, когда стейкал.
Моя позиция не сдвинулась ни на йоту. Сдвинулось что-то другое.
Бонус со-стейкинга 2,35% — это не ставка. Это пул фиксированного размера, который пропорционально делится между каждым кошельком, участвующим в со-стейкинге прямо в тот момент. Babylon прямо говорит об этом в своей документации: больше со-стейкеров — меньше индивидуальные награды. Если попадёте в коэффициент идеально, ваша реальная доля всё равно будет зависеть от того, сколько других кошельков тоже попали в него — число, которое меняется без вашего участия и без того, чтобы вы трогали свою позицию.
Нет дашборда, отслеживающего это число в реальном времени. Вы можете видеть свой вес. Но вы не можете увидеть, как меняется общий вес пула под ним.
В отличие от других рисков Babylon, скрывающихся в недостающей инфраструктуре или сосредоточенных операторов, этот спрятан на виду — формула полностью публична. Не хватает только информации о том, кто ещё им пользуется.
На что стоит обратить внимание: эти 2,35% — не фундамент, а число из управления (governance). Оно существует лишь потому, что в прошлом сентябре предложение разрезало инфляцию Babylon на фиксированные части: 1% для стейкеров BTC, 2% для стейкеров BABY, 2,35% для со-стейкеров, а остальное разделили в других долях. Будущий голос может изменить размер этого среза точно так же, как это предложение создало его. Никто ещё не предлагал уменьшать — так что это место, за которым стоит следить, а не стол, за который вам гарантированно будет оставлено место.
В формуле есть и второй край. Допустимый вес ограничен меньшим из двух значений: вашим BABY, делённым на 20 000, или вашим BTC. Переборщите с коэффициентом — и лишний BABY принесёт только обычную ставку стейкинга. Не доберёте — и только часть вашего BTC получит усиление.
Связка BTC и BABY была задумана, чтобы укрепить эту связь, а общий пул — разумный способ её финансировать. Проблема не в дизайне. Проблема в том, что вы не можете увидеть, как меняется ваша доля, прежде чем это произойдёт.
Если вы попали в коэффициент ровно так же, как я, вы не получаете фиксированные 2,35%. Вы арендуете место за столом, который становится всё более многолюдным по собственному расписанию — людьми, которых вы никогда не увидите, когда они приходят.
Я зафиксировал свой коэффициент со-стейкинга три недели назад — 20 000 BABY за BTC, рекомендованное самим Babylon соотношение. Вчера ночью я проверил свои награды. Они оказались меньше, чем число, которое я посчитал в тот день, когда стейкал.
Моя позиция не сдвинулась ни на йоту. Сдвинулось что-то другое.
Бонус со-стейкинга 2,35% — это не ставка. Это пул фиксированного размера, который пропорционально делится между каждым кошельком, участвующим в со-стейкинге прямо в тот момент. Babylon прямо говорит об этом в своей документации: больше со-стейкеров — меньше индивидуальные награды. Если попадёте в коэффициент идеально, ваша реальная доля всё равно будет зависеть от того, сколько других кошельков тоже попали в него — число, которое меняется без вашего участия и без того, чтобы вы трогали свою позицию.
Нет дашборда, отслеживающего это число в реальном времени. Вы можете видеть свой вес. Но вы не можете увидеть, как меняется общий вес пула под ним.
В отличие от других рисков Babylon, скрывающихся в недостающей инфраструктуре или сосредоточенных операторов, этот спрятан на виду — формула полностью публична. Не хватает только информации о том, кто ещё им пользуется.
На что стоит обратить внимание: эти 2,35% — не фундамент, а число из управления (governance). Оно существует лишь потому, что в прошлом сентябре предложение разрезало инфляцию Babylon на фиксированные части: 1% для стейкеров BTC, 2% для стейкеров BABY, 2,35% для со-стейкеров, а остальное разделили в других долях. Будущий голос может изменить размер этого среза точно так же, как это предложение создало его. Никто ещё не предлагал уменьшать — так что это место, за которым стоит следить, а не стол, за который вам гарантированно будет оставлено место.
В формуле есть и второй край. Допустимый вес ограничен меньшим из двух значений: вашим BABY, делённым на 20 000, или вашим BTC. Переборщите с коэффициентом — и лишний BABY принесёт только обычную ставку стейкинга. Не доберёте — и только часть вашего BTC получит усиление.
Связка BTC и BABY была задумана, чтобы укрепить эту связь, а общий пул — разумный способ её финансировать. Проблема не в дизайне. Проблема в том, что вы не можете увидеть, как меняется ваша доля, прежде чем это произойдёт.
Если вы попали в коэффициент ровно так же, как я, вы не получаете фиксированные 2,35%. Вы арендуете место за столом, который становится всё более многолюдным по собственному расписанию — людьми, которых вы никогда не увидите, когда они приходят.
#baby $BABY @BabylonLabs_io
Сейчас половина моих BTC застейкана через Babylon. Я ни разу не задавался вопросом, что с ними происходит, если одновременно погаснет половина валидаторов, — пока прошлой ночью, читая тот кусок основополагающей статьи Babylon, который я пропустил.
Биткоин-чекпоинтинг повышает безопасность. Достаточно одного честного валидатора, который отправит доказательство в Bitcoin: этого достаточно, чтобы наказать лжецов и определить, какая история является реальной. Liveness — это отдельный вопрос: продолжает ли вообще цепочка производить блоки.
Вот то, чего Bitcoin не может коснуться. Никакой протокол proof-of-stake не гарантирует liveness, если враждебные валидаторы пересекли порог «половина активного набора». Не с Bitcoin «на прицепе», не с любым сервисом таймстемпинга — не если только данные каждого валидатора не будут публиковаться on-chain, а пропускной способности Bitcoin никогда не было рассчитано, чтобы нести такую нагрузку.
Доказательство неуязвимо к злому умыслу. Оно ничего не говорит о валидаторах, которые просто перестают появляться. В любом случае цепочка встанет — и Bitcoin не сможет сказать, что именно произошло.
«Защищено Bitcoin» звучит как одна гарантия. Это две. Bitcoin дает уверенность в том, какая история истинна. Он не покупает обещание, что цепочка продолжит двигаться, если разом исчезнет половина валидаторов — будь то простой, выход или атака, которую не успели вовремя заметить.
Комитет, которому нужен один честный подписант, релейер, которому нужно оставаться онлайн — это чинится тем, что появляется больше операторов. Этот предел доказывается математикой, а не нехваткой персонала. Наблюдение «пожестче» его не сдвигает.
Мои BTC в любом случае заблокированы. Bitcoin выдаст мне квитанцию на точный момент, когда цепочка умерла. Вернуть ей дыхание обратно — никогда не входило в рамки доказательства.
$BLESS $HOME
Если сегодня ночью половина валидаторов Babylon погаснет, что случится с твоими BTC?
Сейчас половина моих BTC застейкана через Babylon. Я ни разу не задавался вопросом, что с ними происходит, если одновременно погаснет половина валидаторов, — пока прошлой ночью, читая тот кусок основополагающей статьи Babylon, который я пропустил.
Биткоин-чекпоинтинг повышает безопасность. Достаточно одного честного валидатора, который отправит доказательство в Bitcoin: этого достаточно, чтобы наказать лжецов и определить, какая история является реальной. Liveness — это отдельный вопрос: продолжает ли вообще цепочка производить блоки.
Вот то, чего Bitcoin не может коснуться. Никакой протокол proof-of-stake не гарантирует liveness, если враждебные валидаторы пересекли порог «половина активного набора». Не с Bitcoin «на прицепе», не с любым сервисом таймстемпинга — не если только данные каждого валидатора не будут публиковаться on-chain, а пропускной способности Bitcoin никогда не было рассчитано, чтобы нести такую нагрузку.
Доказательство неуязвимо к злому умыслу. Оно ничего не говорит о валидаторах, которые просто перестают появляться. В любом случае цепочка встанет — и Bitcoin не сможет сказать, что именно произошло.
«Защищено Bitcoin» звучит как одна гарантия. Это две. Bitcoin дает уверенность в том, какая история истинна. Он не покупает обещание, что цепочка продолжит двигаться, если разом исчезнет половина валидаторов — будь то простой, выход или атака, которую не успели вовремя заметить.
Комитет, которому нужен один честный подписант, релейер, которому нужно оставаться онлайн — это чинится тем, что появляется больше операторов. Этот предел доказывается математикой, а не нехваткой персонала. Наблюдение «пожестче» его не сдвигает.
Мои BTC в любом случае заблокированы. Bitcoin выдаст мне квитанцию на точный момент, когда цепочка умерла. Вернуть ей дыхание обратно — никогда не входило в рамки доказательства.
$BLESS $HOME
Если сегодня ночью половина валидаторов Babylon погаснет, что случится с твоими BTC?
🔐 Safety's covered, I'm fine
33%
🛑 Liveness could still stall
0%
🧊 Frozen either way
0%
⚡ Didn't know
67%
3 проголосовали • Голосование закрыто
Проверено
@BabylonLabs_io $BABY #baby
Каждый раз, когда вы размораживаете (unbond) BTC из Babylon, между вашим биткоином и вашим кошельком стоят девять ключей. Шесть из них должны дать согласие, прежде чем вы получите свои средства обратно.
Один из этих девяти принадлежит Babylon Labs.
Предложение позиционируется как «без доверия» (trustless): никакого кастодиана, никакой компании, которая держит ваш BTC, — только Bitcoin Script, который принудительно соблюдает правила. И это действительно так: ни один ключ не может управлять вашими средствами в одиночку. Но размораживание — единственная дверь обратно к вашим монетам, пока не истекли 15 месяцев действия временной блокировки (timelock), и команда, построившая эту дверь, также держит один из ключей, чтобы открыть её.
Это не скандал. Остальные восемь ключей находятся у названных и заслуживающих доверия организаций, а комитет может только одобрять или отклонять стандартные транзакции — он никогда не был создан, чтобы кто-то мог похитить BTC. Тем не менее, если внимательно прочитать собственную документацию Babylon, вы обнаружите, что разработчик указан как один из подписантов в системе, которую он собрал, чтобы не требовать дополнительных подписантов.
Спросите стейкера Babylon, почему он переместил BTC в протокол, и слово «без доверия» (trustless) обычно будет первым, которое он произнесёт. Спросите, кто держит ключ №1, и многие не будут знать ответа: это Babylon Labs.
$IDOL
Меняет ли то, что разработчик держит один из ключей для размораживания, ваше представление о «без доверия» (trustless)?
Каждый раз, когда вы размораживаете (unbond) BTC из Babylon, между вашим биткоином и вашим кошельком стоят девять ключей. Шесть из них должны дать согласие, прежде чем вы получите свои средства обратно.
Один из этих девяти принадлежит Babylon Labs.
Предложение позиционируется как «без доверия» (trustless): никакого кастодиана, никакой компании, которая держит ваш BTC, — только Bitcoin Script, который принудительно соблюдает правила. И это действительно так: ни один ключ не может управлять вашими средствами в одиночку. Но размораживание — единственная дверь обратно к вашим монетам, пока не истекли 15 месяцев действия временной блокировки (timelock), и команда, построившая эту дверь, также держит один из ключей, чтобы открыть её.
Это не скандал. Остальные восемь ключей находятся у названных и заслуживающих доверия организаций, а комитет может только одобрять или отклонять стандартные транзакции — он никогда не был создан, чтобы кто-то мог похитить BTC. Тем не менее, если внимательно прочитать собственную документацию Babylon, вы обнаружите, что разработчик указан как один из подписантов в системе, которую он собрал, чтобы не требовать дополнительных подписантов.
Спросите стейкера Babylon, почему он переместил BTC в протокол, и слово «без доверия» (trustless) обычно будет первым, которое он произнесёт. Спросите, кто держит ключ №1, и многие не будут знать ответа: это Babylon Labs.
$IDOL
Меняет ли то, что разработчик держит один из ключей для размораживания, ваше представление о «без доверия» (trustless)?
🔑 No, still trustless
100%
🔒 Slightly concerning
0%
🚨 Yes, big issue
0%
❓ Didn't know this
0%
1 проголосовали • Голосование закрыто
2 часа ночи, всё ещё не сплю, читаю документацию Babylon о чекпойнтинге без всякой причины, кроме того что мне не удавалось уснуть. Одна строка остановила мою прокрутку: одного честного и живого бдительного (vigilante) участника в сети достаточно, чтобы гарантировать успешный и безопасный чекпойнтинг для Bitcoin.
Читать быстро — звучит так, будто децентрализация делает свою работу. Десятки независимых операторов, и достаточно чтобы один вел себя правильно.
Я вернулся к собственной академической статье Babylon за 2022 год, соавтором которой являются её основатели — той, что доказывает это утверждение как формальную теорему, а не как маркетинговую фразу. Доказательство верно при одном условии: существует один честный валидатор, активный в любой момент времени. В статье это сказано напрямую.
Вот что она не проговаривает. «Одного математически достаточно» и «один сейчас в сети» — это две разные гарантии. Только первая сопровождается доказательством.
Затем то же самое предложение появилось снова — на этот раз рядом с covenant emulator и IBC relayer, перечисленными как их собственные отдельные программы: безопасная работа требует по меньшей мере одного честного оператора для каждой указанной программы, иначе система поднимает тревогу. Не уверен, покрывает ли это все три одинаково, или же было написано с прицелом лишь на связку vigilante. В любом случае, численность не публикуется.
Babylon называет это добровольным — любой может запустить один. Да, и всё равно не сказано, сколько их сейчас, и сохраняется ли это число во время пика комиссий в Bitcoin, когда никто не хочет платить.
Есть причина, почему никто не публикует эту цифру. Если раскрыть, насколько тонок запас, это помогает атакующему больше, чем вам.
Если вы делаете стейкинг через Babylon прямо сейчас, то под вашу BTC заложено именно это предположение, которого вам не показывает ни одна панель: не «действительно ли работает математика», а «есть ли кто-то, кто прямо сейчас бодрствует и может это запустить — сегодня ночью и каждую ночь после».
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Вы бы сделали стейкинг, если бы число «одного честного оператора» неизвестно? 👀
Читать быстро — звучит так, будто децентрализация делает свою работу. Десятки независимых операторов, и достаточно чтобы один вел себя правильно.
Я вернулся к собственной академической статье Babylon за 2022 год, соавтором которой являются её основатели — той, что доказывает это утверждение как формальную теорему, а не как маркетинговую фразу. Доказательство верно при одном условии: существует один честный валидатор, активный в любой момент времени. В статье это сказано напрямую.
Вот что она не проговаривает. «Одного математически достаточно» и «один сейчас в сети» — это две разные гарантии. Только первая сопровождается доказательством.
Затем то же самое предложение появилось снова — на этот раз рядом с covenant emulator и IBC relayer, перечисленными как их собственные отдельные программы: безопасная работа требует по меньшей мере одного честного оператора для каждой указанной программы, иначе система поднимает тревогу. Не уверен, покрывает ли это все три одинаково, или же было написано с прицелом лишь на связку vigilante. В любом случае, численность не публикуется.
Babylon называет это добровольным — любой может запустить один. Да, и всё равно не сказано, сколько их сейчас, и сохраняется ли это число во время пика комиссий в Bitcoin, когда никто не хочет платить.
Есть причина, почему никто не публикует эту цифру. Если раскрыть, насколько тонок запас, это помогает атакующему больше, чем вам.
Если вы делаете стейкинг через Babylon прямо сейчас, то под вашу BTC заложено именно это предположение, которого вам не показывает ни одна панель: не «действительно ли работает математика», а «есть ли кто-то, кто прямо сейчас бодрствует и может это запустить — сегодня ночью и каждую ночь после».
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Вы бы сделали стейкинг, если бы число «одного честного оператора» неизвестно? 👀
✨ Yes, the math is enough
100%
🤌🏻I'd wnt live operator data
0%
⚠️ That’s a real concern
0%
❓ Didn’t know this
0%
1 проголосовали • Голосование закрыто
Проверено
#baby $BABY @BabylonLabs_io
Раньше я думал, что слэшинг — это способ Вавилона наказывать за нечестность. Но всё изменилось в 2 часа ночи, когда я листал независимый аудит безопасности реализации EOTS — документы такого рода никто не открывает без причины.
Механизм сам по себе элегантен. Провайдер финальности фиксирует некоторую случайность до того, как подписывать любой блок на заданной высоте. Подпиши один раз — ничего не происходит. Подпиши дважды, используя два разных сообщения, и математика схемы подписи Шнорра превращает ту же самую случайность в раскрытый закрытый ключ провайдера. Преднамеренное двойное подписание оказывается самонаказывающимся по конструкции — и на то есть причина: протокол может читать подписи, но не намерения, поэтому правило достаточно строгое, чтобы поймать атакующего, не может отличить атакующего от случайной ошибки.
Именно этот компромисс и отметили в аудите. Намеренная атака и честный фейловер (переключение) резервного узла, срабатывающий на той же высоте, дают ровно тот же паттерн подписи. Оба выглядят для EOTS одинаково. Оба сляшатся одинаково: тумбстоун, без восстановления.
Это не теория. Hex Trust — институциональный кастодиан, который запускает инфраструктуру провайдеров финальности в Babylon, — перечисляет конкретные меры предосторожности против ровно этого: не переиспользовать закрытый ключ между машинами, делать ручной фейловер вместо автоматического, потому что автоматический фейловер — это как раз то, что может привести к появлению двух живых подписантов для одного ключа одновременно.
Вот часть, где нет однозначного ответа. Нет стандарта публичного раскрытия того, какая именно схема фейловера используется провайдером. Можно проверить комиссию, аптайм, число делегаторов. Но не это — не до того, как ваш BTC уже будет заблокирован.
Делегирование никогда не было просто ставкой на то, что оператор не атакует. Это ещё и ставка на то, что их инфраструктура не устроит плохой день, пока ваш BTC заблокирован, причём на детали, которые протокол заранее делает непознаваемыми.
$KOMA
Раньше я думал, что слэшинг — это способ Вавилона наказывать за нечестность. Но всё изменилось в 2 часа ночи, когда я листал независимый аудит безопасности реализации EOTS — документы такого рода никто не открывает без причины.
Механизм сам по себе элегантен. Провайдер финальности фиксирует некоторую случайность до того, как подписывать любой блок на заданной высоте. Подпиши один раз — ничего не происходит. Подпиши дважды, используя два разных сообщения, и математика схемы подписи Шнорра превращает ту же самую случайность в раскрытый закрытый ключ провайдера. Преднамеренное двойное подписание оказывается самонаказывающимся по конструкции — и на то есть причина: протокол может читать подписи, но не намерения, поэтому правило достаточно строгое, чтобы поймать атакующего, не может отличить атакующего от случайной ошибки.
Именно этот компромисс и отметили в аудите. Намеренная атака и честный фейловер (переключение) резервного узла, срабатывающий на той же высоте, дают ровно тот же паттерн подписи. Оба выглядят для EOTS одинаково. Оба сляшатся одинаково: тумбстоун, без восстановления.
Это не теория. Hex Trust — институциональный кастодиан, который запускает инфраструктуру провайдеров финальности в Babylon, — перечисляет конкретные меры предосторожности против ровно этого: не переиспользовать закрытый ключ между машинами, делать ручной фейловер вместо автоматического, потому что автоматический фейловер — это как раз то, что может привести к появлению двух живых подписантов для одного ключа одновременно.
Вот часть, где нет однозначного ответа. Нет стандарта публичного раскрытия того, какая именно схема фейловера используется провайдером. Можно проверить комиссию, аптайм, число делегаторов. Но не это — не до того, как ваш BTC уже будет заблокирован.
Делегирование никогда не было просто ставкой на то, что оператор не атакует. Это ещё и ставка на то, что их инфраструктура не устроит плохой день, пока ваш BTC заблокирован, причём на детали, которые протокол заранее делает непознаваемыми.
$KOMA
Проверено
$BABY $UAI $COTI #baby @BabylonLabs_io
Сначала я решил, что комитет по оглашению условий (covenant) — это шаг начального «самозапуска», который Babylon уберёт, когда её собственная дорожная карта созреет, примерно так же, как большинство молодых протоколов обещают децентрализацию в собственные сроки. Но документация говорит о чём-то более тихом и странном.
Комитет существует потому, что у самого Bitcoin нет встроенного способа принудительно исполнять ковенанты: нет опкода, который может заставить UTXO тратить только по заранее согласованным правилам. Поэтому Babylon построил 6‑из‑9 multisig, чтобы смоделировать недостающую функцию: он отслеживает запросы на стейкинг, со-подписывает размандирование (unbonding) и слэшинг, подменяя собой возможность, которой Bitcoin Script пока просто не обладает. Эта часть — честная инженерия вокруг реального пробела, а предположение о доверии действительно легче, чем в обычном кастодиальном multisig: не «честность большинства», а экзистенциальная честность — достаточно одного порядочного подписанта, чтобы остановить кражу.
Меня остановило условие выхода. В собственной документации Babylon не говорится, что комитет прекращает работу, когда управление (governance) «созреет», или когда достигнут некий порог TVL, или когда будет готово какое-то внутреннее веховое событие. Там сказано, что комитет остаётся до тех пор, пока covenant‑функциональность не станет доступной в Bitcoin нативно — через такие опкоды, как OP-CAT или OP-CTV, которые Bitcoin Core не внедрил и у которых нет принятого обязательного срока для внедрения. Дата «выхода на пенсию» не указана в roadmap Babylon. Она спрятана внутри процесса управления другого протокола — у Babylon нет в нём голосов и нет возможности ускорить.
Так что доверие не исчезло, когда Babylon назвал это системой, защищённой Bitcoin. Оно сместилось на один уровень дальше: вместо multisig с определённым составом — на Bitcoin soft fork, который, возможно, выйдет в этом десятилетии, а возможно и нет. Шесть из девяти известных подписантов — это хотя бы предположение о доверии, которое можно назвать. Наблюдаемое обновление опкода без дедлайна — это предположение о доверии, на которое можно только надеяться.
Комитет по ковенантам остаётся, пока Bitcoin не добавит covenant‑опкоды. У Babylon нет временного контроля над этим.
Твой взгляд? 👀
Сначала я решил, что комитет по оглашению условий (covenant) — это шаг начального «самозапуска», который Babylon уберёт, когда её собственная дорожная карта созреет, примерно так же, как большинство молодых протоколов обещают децентрализацию в собственные сроки. Но документация говорит о чём-то более тихом и странном.
Комитет существует потому, что у самого Bitcoin нет встроенного способа принудительно исполнять ковенанты: нет опкода, который может заставить UTXO тратить только по заранее согласованным правилам. Поэтому Babylon построил 6‑из‑9 multisig, чтобы смоделировать недостающую функцию: он отслеживает запросы на стейкинг, со-подписывает размандирование (unbonding) и слэшинг, подменяя собой возможность, которой Bitcoin Script пока просто не обладает. Эта часть — честная инженерия вокруг реального пробела, а предположение о доверии действительно легче, чем в обычном кастодиальном multisig: не «честность большинства», а экзистенциальная честность — достаточно одного порядочного подписанта, чтобы остановить кражу.
Меня остановило условие выхода. В собственной документации Babylon не говорится, что комитет прекращает работу, когда управление (governance) «созреет», или когда достигнут некий порог TVL, или когда будет готово какое-то внутреннее веховое событие. Там сказано, что комитет остаётся до тех пор, пока covenant‑функциональность не станет доступной в Bitcoin нативно — через такие опкоды, как OP-CAT или OP-CTV, которые Bitcoin Core не внедрил и у которых нет принятого обязательного срока для внедрения. Дата «выхода на пенсию» не указана в roadmap Babylon. Она спрятана внутри процесса управления другого протокола — у Babylon нет в нём голосов и нет возможности ускорить.
Так что доверие не исчезло, когда Babylon назвал это системой, защищённой Bitcoin. Оно сместилось на один уровень дальше: вместо multisig с определённым составом — на Bitcoin soft fork, который, возможно, выйдет в этом десятилетии, а возможно и нет. Шесть из девяти известных подписантов — это хотя бы предположение о доверии, которое можно назвать. Наблюдаемое обновление опкода без дедлайна — это предположение о доверии, на которое можно только надеяться.
Комитет по ковенантам остаётся, пока Bitcoin не добавит covenant‑опкоды. У Babylon нет временного контроля над этим.
Твой взгляд? 👀
Safest for now ✅
25%
Uncomfortable, but fair 😕
0%
🚩 Real red flag
75%
Didn’t know this🥱
0%
4 проголосовали • Голосование закрыто
На прошлой неделе я выбирал финализирующего провайдера: смотрел на список примерно из 30 верифицированных названий и поймал себя на мысли, что сейчас нажму на то, у которого уже больше делегаторов. Та же рефлекторная реакция превратила большую часть стейкинга в Ethereum в историю про Lido.
Затем я на самом деле прочитал собственное руководство Babylon по стейкингу.
Там риск обозначен прямо: делегирование самым популярным провайдерам повышает риск централизации. Это не чья-то оценка критика — так говорится в их собственной документации.
➡ Примерно 30 провайдеров имеют в приложении верифицированную отметку.
➡ В этом списке нет ограничения, сколько делегаций может поглотить любой из них.
Отдать Babylon должное — они прямо сказали об этом вслух; большинство продуктов для стейкинга не предупреждают конечного пользователя до того, как он нажмёт.
Вот что осталось у меня в голове. Отметка нужна, чтобы сформировать доверие. Но если большинство стейкеров по умолчанию выбирают то верифицированное название, у которого уже больше всего делегаторов — тот самый сценарий, через который прошёл Ethereum, — то механизм, который должен строить доверие, становится способом сконцентрировать тот самый риск, о котором они предупреждают.
Я искал реальные цифры по доле делегаций: сколько суммарно контролируют топ-5 или топ-10 финализирующих провайдеров. Ничего публичного не нашёл. В одном из собственных описаний протокола криптобиржи это назвали «всё ещё требующим дальнейшего обсуждения» — открытая проблема, отмеченная сторонним источником, а не тем, что Babylon само зафиксировало в публичных материалах.
Я распределил свою делегацию между тремя меньшими провайдерами вместо одного большого. На этом масштабе это, скорее всего, ближе к символическому жесту, чем к реальному решению — и я это понимаю.
@BabylonLabs_io $BABY #baby $ON
«Вы бы намеренно делегировали меньшему провайдеру финализации?»
Затем я на самом деле прочитал собственное руководство Babylon по стейкингу.
Там риск обозначен прямо: делегирование самым популярным провайдерам повышает риск централизации. Это не чья-то оценка критика — так говорится в их собственной документации.
➡ Примерно 30 провайдеров имеют в приложении верифицированную отметку.
➡ В этом списке нет ограничения, сколько делегаций может поглотить любой из них.
Отдать Babylon должное — они прямо сказали об этом вслух; большинство продуктов для стейкинга не предупреждают конечного пользователя до того, как он нажмёт.
Вот что осталось у меня в голове. Отметка нужна, чтобы сформировать доверие. Но если большинство стейкеров по умолчанию выбирают то верифицированное название, у которого уже больше всего делегаторов — тот самый сценарий, через который прошёл Ethereum, — то механизм, который должен строить доверие, становится способом сконцентрировать тот самый риск, о котором они предупреждают.
Я искал реальные цифры по доле делегаций: сколько суммарно контролируют топ-5 или топ-10 финализирующих провайдеров. Ничего публичного не нашёл. В одном из собственных описаний протокола криптобиржи это назвали «всё ещё требующим дальнейшего обсуждения» — открытая проблема, отмеченная сторонним источником, а не тем, что Babylon само зафиксировало в публичных материалах.
Я распределил свою делегацию между тремя меньшими провайдерами вместо одного большого. На этом масштабе это, скорее всего, ближе к символическому жесту, чем к реальному решению — и я это понимаю.
@BabylonLabs_io $BABY #baby $ON
«Вы бы намеренно делегировали меньшему провайдеру финализации?»
🔀 Yes, spread it out
0%
🛡️ No, biggest is safest
0%
💰 Depends on commission
0%
🤷 Never thought about it
100%
1 проголосовали • Голосование закрыто
См. перевод
#baby @BabylonLabs_io
Almost put a small amount of BTC into a vault-backed lending position last week. Before I did, I wanted to know one thing: if the market moved fast against me, what actually decides when I get liquidated? That question is what sent me looking past the marketing and into Babylon's own site — for wherever the word "trustless" stops applying. It wasn't buried. It just doesn't survive translation into every headline built around that one word. ➡ Babylon's own Learn page says plainly that the real risk sits on the DeFi side, not in the vault itself, and gives liquidation in lending as the example. ➡ The whitepaper backs it up: liquidation needs a signature from a price oracle, treated as a separate dependency from the vault's core design. Give Babylon credit — they wrote this down themselves. Nobody had to dig it out of them. Here's the part that stuck with me, the part that actually changed how much I was about to deposit. "A price oracle" sounds abstract, until one report on this exact system named which networks actually hold that relationship with Babylon: Band Protocol and Pyth, the same general-purpose networks pricing dozens of other chains at the same time. Babylon's own materials don't name them directly, so treat that specific pairing as reported, not confirmed by Babylon itself. If one of those feeds is late or wrong during a fast move, my liquidation still fires exactly as coded. Correctly, acting on bad information. Bitcoin's base layer doesn't get a vote in that outcome. The vault does exactly what it promised. The oracle just hands it something false. That's not the vault failing. That's DeFi risk, wearing a trustless label, inheriting whatever outage history its actual price feed already carries from other chains I don't even use. I still made the deposit. Just smaller than I would have an hour earlier. Trustless describes what happens to your BTC. It was never a promise about what happens to your money once it leaves the vault.
$BROCCOLIF3B $ON $BABY
Almost put a small amount of BTC into a vault-backed lending position last week. Before I did, I wanted to know one thing: if the market moved fast against me, what actually decides when I get liquidated? That question is what sent me looking past the marketing and into Babylon's own site — for wherever the word "trustless" stops applying. It wasn't buried. It just doesn't survive translation into every headline built around that one word. ➡ Babylon's own Learn page says plainly that the real risk sits on the DeFi side, not in the vault itself, and gives liquidation in lending as the example. ➡ The whitepaper backs it up: liquidation needs a signature from a price oracle, treated as a separate dependency from the vault's core design. Give Babylon credit — they wrote this down themselves. Nobody had to dig it out of them. Here's the part that stuck with me, the part that actually changed how much I was about to deposit. "A price oracle" sounds abstract, until one report on this exact system named which networks actually hold that relationship with Babylon: Band Protocol and Pyth, the same general-purpose networks pricing dozens of other chains at the same time. Babylon's own materials don't name them directly, so treat that specific pairing as reported, not confirmed by Babylon itself. If one of those feeds is late or wrong during a fast move, my liquidation still fires exactly as coded. Correctly, acting on bad information. Bitcoin's base layer doesn't get a vote in that outcome. The vault does exactly what it promised. The oracle just hands it something false. That's not the vault failing. That's DeFi risk, wearing a trustless label, inheriting whatever outage history its actual price feed already carries from other chains I don't even use. I still made the deposit. Just smaller than I would have an hour earlier. Trustless describes what happens to your BTC. It was never a promise about what happens to your money once it leaves the vault.
$BROCCOLIF3B $ON $BABY
✅ Bitcoin security
0%
📈 Oracle accuracy
0%
⚖️ Both equally
0%
❓Depends on the protocol
0%
0 проголосовали • Голосование закрыто
Частичная правда
#baby $BABY @BabylonLabs_io
Почти на прошлой неделе внес небольшую сумму BTC в позицию кредитования с обеспечением в виде хранилища. Прежде чем сделать это, я хотел знать одну вещь: если рынок резко пойдет против меня, что именно определяет, когда меня ликвидируют?
Этим вопросом я задался и вышел за пределы маркетинга — прямо на сайт Babylon, туда, где слово «trustless» перестает применяться.
Это не было спрятано. Просто оно не выдерживает перевода на все заголовки, построенные вокруг одного этого слова.
➡ На странице Learn от Babylon прямо сказано: реальный риск находится на стороне DeFi, а не в самом хранилище, и в качестве примера приводится ликвидация при кредитовании.
➡ Белая книга это подтверждает: для ликвидации нужна подпись от ценового оракула, который рассматривается как отдельная зависимость от базового дизайна хранилища.
Заслуживает признания то, что Babylon это прописали сами. Никому не пришлось выкапывать это из них.
Вот та часть, которая застряла у меня в голове — та, которая реально повлияла на то, сколько я собирался внести. «Ценовой оракул» звучит абстрактно, пока один отчет по этой конкретной системе не назвал, какие сети на самом деле поддерживают эту взаимосвязь с Babylon: Band Protocol и Pyth — те же универсальные сети, которые в то же время оценивают десятки других цепочек. В материалах Babylon они напрямую не названы, так что считайте это зафиксированной в отчете связкой, а не подтвержденной самим Babylon.
Если один из этих фидов задержится или окажется неверным во время резкого движения, моя ликвидация все равно сработает ровно так, как это запрограммировано. Правильно — действуя на плохих данных. Базовый уровень Bitcoin не участвует в таком исходе. Хранилище делает ровно то, что обещало. Оракул просто подает ему ложь.
Это не провал хранилища. Это риск DeFi, который носит ярлык «trustless» и наследует любую историю простоев, которую уже несет реальный ценовой фид из других цепочек, которые я даже не использую.
Внес депозит. Просто меньше, чем сделал бы за час до этого.
Trustless описывает, что происходит с вашим BTC. Это никогда не было обещанием о том, что случится с вашими деньгами после того, как они покинут хранилище.
$EUL
Может ли trustless-хранилище все еще зависеть от оракулов?
Почти на прошлой неделе внес небольшую сумму BTC в позицию кредитования с обеспечением в виде хранилища. Прежде чем сделать это, я хотел знать одну вещь: если рынок резко пойдет против меня, что именно определяет, когда меня ликвидируют?
Этим вопросом я задался и вышел за пределы маркетинга — прямо на сайт Babylon, туда, где слово «trustless» перестает применяться.
Это не было спрятано. Просто оно не выдерживает перевода на все заголовки, построенные вокруг одного этого слова.
➡ На странице Learn от Babylon прямо сказано: реальный риск находится на стороне DeFi, а не в самом хранилище, и в качестве примера приводится ликвидация при кредитовании.
➡ Белая книга это подтверждает: для ликвидации нужна подпись от ценового оракула, который рассматривается как отдельная зависимость от базового дизайна хранилища.
Заслуживает признания то, что Babylon это прописали сами. Никому не пришлось выкапывать это из них.
Вот та часть, которая застряла у меня в голове — та, которая реально повлияла на то, сколько я собирался внести. «Ценовой оракул» звучит абстрактно, пока один отчет по этой конкретной системе не назвал, какие сети на самом деле поддерживают эту взаимосвязь с Babylon: Band Protocol и Pyth — те же универсальные сети, которые в то же время оценивают десятки других цепочек. В материалах Babylon они напрямую не названы, так что считайте это зафиксированной в отчете связкой, а не подтвержденной самим Babylon.
Если один из этих фидов задержится или окажется неверным во время резкого движения, моя ликвидация все равно сработает ровно так, как это запрограммировано. Правильно — действуя на плохих данных. Базовый уровень Bitcoin не участвует в таком исходе. Хранилище делает ровно то, что обещало. Оракул просто подает ему ложь.
Это не провал хранилища. Это риск DeFi, который носит ярлык «trustless» и наследует любую историю простоев, которую уже несет реальный ценовой фид из других цепочек, которые я даже не использую.
Внес депозит. Просто меньше, чем сделал бы за час до этого.
Trustless описывает, что происходит с вашим BTC. Это никогда не было обещанием о том, что случится с вашими деньгами после того, как они покинут хранилище.
$EUL
Может ли trustless-хранилище все еще зависеть от оракулов?
✅ Yes, already knew
0%
🤯 No,I asumed it covered both
0%
0 проголосовали • Голосование закрыто
⚡✨
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Прошлой ночью не мог уснуть, поэтому я открыл три отдельных черновика про Aave Temp Check у Babylon и держал их рядом — больше по привычке, чем по какой-то особой необходимости.
Одно слово не давало мне покоя.
Bitcoin.com, Cointribune и LiveBitcoinNews все описывают поток ликвидации TBV одинаково. Безразрешительный ликвидатор мгновенно обменивает захваченный сейф на WBTC с небольшой премией. Затем отдельная группа «разрешённых арбитражёров» покупает эту позицию и позже редимит реальный BTC — уже по собственному расписанию Bitcoin.
Отдаю Babylon должное за первую половину: безразрешительная ликвидационная проверка соответствует заявленному ровно так, как обещали.
Дальше начинается вторая половина — и именно там я пошёл смотреть глубже, чем дотягивается Aave-предложение. Августовский белый документ Babylon по Trustless Bitcoin Vaults вообще не говорит «разрешённый» — там сказано, что ликвидации идут через «whitelisted liquidators», которые следят за ценой и состоянием сейфа. Другое слово, но та же форма. Независимый аналитик, который переписывался с командой Babylon в X, поднял тот же момент прямо им: достаточно, чтобы эти whitelisted-участники вели себя корректно — и это уже допущение доверия, о котором маркетинг не упоминает.
Так что слово оказалось точным. Вопрос в другом: почему эта роль вообще должна быть ограничена, если сторона со свопом на WBTC — нет? Язык сценариев Bitcoin не может оценивать произвольное произвольное состояние внечейн. BitVM3 обходит это, заворачивая верификатор доказательства с нулевым разглашением в запутанную схему (garbled circuit), но всё равно кто-то должен сгенерировать и отправить это доказательство, чтобы запустить редемпшн. Сторона со свопом на WBTC легко допускает безразрешительность: любой ликвидатор с капиталом просто берёт сделку. Отправка доказательства — более сложная проблема, которую BitVM3 пока не решила.
Это не про то, является ли сейф бесдоверительным. Babylon не прятал whitelisting в своём собственном белом документе. Бесдоверительность здесь не исчезает. Просто она заканчивается на один шаг раньше, чем это признают большинство публикаций.
$EUL
Что определяет по-настоящему бесдоверительный BTC-сейф?
Прошлой ночью не мог уснуть, поэтому я открыл три отдельных черновика про Aave Temp Check у Babylon и держал их рядом — больше по привычке, чем по какой-то особой необходимости.
Одно слово не давало мне покоя.
Bitcoin.com, Cointribune и LiveBitcoinNews все описывают поток ликвидации TBV одинаково. Безразрешительный ликвидатор мгновенно обменивает захваченный сейф на WBTC с небольшой премией. Затем отдельная группа «разрешённых арбитражёров» покупает эту позицию и позже редимит реальный BTC — уже по собственному расписанию Bitcoin.
Отдаю Babylon должное за первую половину: безразрешительная ликвидационная проверка соответствует заявленному ровно так, как обещали.
Дальше начинается вторая половина — и именно там я пошёл смотреть глубже, чем дотягивается Aave-предложение. Августовский белый документ Babylon по Trustless Bitcoin Vaults вообще не говорит «разрешённый» — там сказано, что ликвидации идут через «whitelisted liquidators», которые следят за ценой и состоянием сейфа. Другое слово, но та же форма. Независимый аналитик, который переписывался с командой Babylon в X, поднял тот же момент прямо им: достаточно, чтобы эти whitelisted-участники вели себя корректно — и это уже допущение доверия, о котором маркетинг не упоминает.
Так что слово оказалось точным. Вопрос в другом: почему эта роль вообще должна быть ограничена, если сторона со свопом на WBTC — нет? Язык сценариев Bitcoin не может оценивать произвольное произвольное состояние внечейн. BitVM3 обходит это, заворачивая верификатор доказательства с нулевым разглашением в запутанную схему (garbled circuit), но всё равно кто-то должен сгенерировать и отправить это доказательство, чтобы запустить редемпшн. Сторона со свопом на WBTC легко допускает безразрешительность: любой ликвидатор с капиталом просто берёт сделку. Отправка доказательства — более сложная проблема, которую BitVM3 пока не решила.
Это не про то, является ли сейф бесдоверительным. Babylon не прятал whitelisting в своём собственном белом документе. Бесдоверительность здесь не исчезает. Просто она заканчивается на один шаг раньше, чем это признают большинство публикаций.
$EUL
Что определяет по-настоящему бесдоверительный BTC-сейф?
$EUL $CHILLGUY Goooo
и дай мне обратную связь
и дай мне обратную связь
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Прошлой ночью не мог уснуть, поэтому я открыл три отдельных черновика про Aave Temp Check у Babylon и держал их рядом — больше по привычке, чем по какой-то особой необходимости.
Одно слово не давало мне покоя.
Bitcoin.com, Cointribune и LiveBitcoinNews все описывают поток ликвидации TBV одинаково. Безразрешительный ликвидатор мгновенно обменивает захваченный сейф на WBTC с небольшой премией. Затем отдельная группа «разрешённых арбитражёров» покупает эту позицию и позже редимит реальный BTC — уже по собственному расписанию Bitcoin.
Отдаю Babylon должное за первую половину: безразрешительная ликвидационная проверка соответствует заявленному ровно так, как обещали.
Дальше начинается вторая половина — и именно там я пошёл смотреть глубже, чем дотягивается Aave-предложение. Августовский белый документ Babylon по Trustless Bitcoin Vaults вообще не говорит «разрешённый» — там сказано, что ликвидации идут через «whitelisted liquidators», которые следят за ценой и состоянием сейфа. Другое слово, но та же форма. Независимый аналитик, который переписывался с командой Babylon в X, поднял тот же момент прямо им: достаточно, чтобы эти whitelisted-участники вели себя корректно — и это уже допущение доверия, о котором маркетинг не упоминает.
Так что слово оказалось точным. Вопрос в другом: почему эта роль вообще должна быть ограничена, если сторона со свопом на WBTC — нет? Язык сценариев Bitcoin не может оценивать произвольное произвольное состояние внечейн. BitVM3 обходит это, заворачивая верификатор доказательства с нулевым разглашением в запутанную схему (garbled circuit), но всё равно кто-то должен сгенерировать и отправить это доказательство, чтобы запустить редемпшн. Сторона со свопом на WBTC легко допускает безразрешительность: любой ликвидатор с капиталом просто берёт сделку. Отправка доказательства — более сложная проблема, которую BitVM3 пока не решила.
Это не про то, является ли сейф бесдоверительным. Babylon не прятал whitelisting в своём собственном белом документе. Бесдоверительность здесь не исчезает. Просто она заканчивается на один шаг раньше, чем это признают большинство публикаций.
$EUL
Что определяет по-настоящему бесдоверительный BTC-сейф?
Прошлой ночью не мог уснуть, поэтому я открыл три отдельных черновика про Aave Temp Check у Babylon и держал их рядом — больше по привычке, чем по какой-то особой необходимости.
Одно слово не давало мне покоя.
Bitcoin.com, Cointribune и LiveBitcoinNews все описывают поток ликвидации TBV одинаково. Безразрешительный ликвидатор мгновенно обменивает захваченный сейф на WBTC с небольшой премией. Затем отдельная группа «разрешённых арбитражёров» покупает эту позицию и позже редимит реальный BTC — уже по собственному расписанию Bitcoin.
Отдаю Babylon должное за первую половину: безразрешительная ликвидационная проверка соответствует заявленному ровно так, как обещали.
Дальше начинается вторая половина — и именно там я пошёл смотреть глубже, чем дотягивается Aave-предложение. Августовский белый документ Babylon по Trustless Bitcoin Vaults вообще не говорит «разрешённый» — там сказано, что ликвидации идут через «whitelisted liquidators», которые следят за ценой и состоянием сейфа. Другое слово, но та же форма. Независимый аналитик, который переписывался с командой Babylon в X, поднял тот же момент прямо им: достаточно, чтобы эти whitelisted-участники вели себя корректно — и это уже допущение доверия, о котором маркетинг не упоминает.
Так что слово оказалось точным. Вопрос в другом: почему эта роль вообще должна быть ограничена, если сторона со свопом на WBTC — нет? Язык сценариев Bitcoin не может оценивать произвольное произвольное состояние внечейн. BitVM3 обходит это, заворачивая верификатор доказательства с нулевым разглашением в запутанную схему (garbled circuit), но всё равно кто-то должен сгенерировать и отправить это доказательство, чтобы запустить редемпшн. Сторона со свопом на WBTC легко допускает безразрешительность: любой ликвидатор с капиталом просто берёт сделку. Отправка доказательства — более сложная проблема, которую BitVM3 пока не решила.
Это не про то, является ли сейф бесдоверительным. Babylon не прятал whitelisting в своём собственном белом документе. Бесдоверительность здесь не исчезает. Просто она заканчивается на один шаг раньше, чем это признают большинство публикаций.
$EUL
Что определяет по-настоящему бесдоверительный BTC-сейф?
#baby $BABY @BabylonLabs_io
Прошлой ночью не мог уснуть, поэтому я открыл три отдельных черновика про Aave Temp Check у Babylon и держал их рядом — больше по привычке, чем по какой-то особой необходимости.
Одно слово не давало мне покоя.
Bitcoin.com, Cointribune и LiveBitcoinNews все описывают поток ликвидации TBV одинаково. Безразрешительный ликвидатор мгновенно обменивает захваченный сейф на WBTC с небольшой премией. Затем отдельная группа «разрешённых арбитражёров» покупает эту позицию и позже редимит реальный BTC — уже по собственному расписанию Bitcoin.
Отдаю Babylon должное за первую половину: безразрешительная ликвидационная проверка соответствует заявленному ровно так, как обещали.
Дальше начинается вторая половина — и именно там я пошёл смотреть глубже, чем дотягивается Aave-предложение. Августовский белый документ Babylon по Trustless Bitcoin Vaults вообще не говорит «разрешённый» — там сказано, что ликвидации идут через «whitelisted liquidators», которые следят за ценой и состоянием сейфа. Другое слово, но та же форма. Независимый аналитик, который переписывался с командой Babylon в X, поднял тот же момент прямо им: достаточно, чтобы эти whitelisted-участники вели себя корректно — и это уже допущение доверия, о котором маркетинг не упоминает.
Так что слово оказалось точным. Вопрос в другом: почему эта роль вообще должна быть ограничена, если сторона со свопом на WBTC — нет? Язык сценариев Bitcoin не может оценивать произвольное произвольное состояние внечейн. BitVM3 обходит это, заворачивая верификатор доказательства с нулевым разглашением в запутанную схему (garbled circuit), но всё равно кто-то должен сгенерировать и отправить это доказательство, чтобы запустить редемпшн. Сторона со свопом на WBTC легко допускает безразрешительность: любой ликвидатор с капиталом просто берёт сделку. Отправка доказательства — более сложная проблема, которую BitVM3 пока не решила.
Это не про то, является ли сейф бесдоверительным. Babylon не прятал whitelisting в своём собственном белом документе. Бесдоверительность здесь не исчезает. Просто она заканчивается на один шаг раньше, чем это признают большинство публикаций.
$EUL
Что определяет по-настоящему бесдоверительный BTC-сейф?
Прошлой ночью не мог уснуть, поэтому я открыл три отдельных черновика про Aave Temp Check у Babylon и держал их рядом — больше по привычке, чем по какой-то особой необходимости.
Одно слово не давало мне покоя.
Bitcoin.com, Cointribune и LiveBitcoinNews все описывают поток ликвидации TBV одинаково. Безразрешительный ликвидатор мгновенно обменивает захваченный сейф на WBTC с небольшой премией. Затем отдельная группа «разрешённых арбитражёров» покупает эту позицию и позже редимит реальный BTC — уже по собственному расписанию Bitcoin.
Отдаю Babylon должное за первую половину: безразрешительная ликвидационная проверка соответствует заявленному ровно так, как обещали.
Дальше начинается вторая половина — и именно там я пошёл смотреть глубже, чем дотягивается Aave-предложение. Августовский белый документ Babylon по Trustless Bitcoin Vaults вообще не говорит «разрешённый» — там сказано, что ликвидации идут через «whitelisted liquidators», которые следят за ценой и состоянием сейфа. Другое слово, но та же форма. Независимый аналитик, который переписывался с командой Babylon в X, поднял тот же момент прямо им: достаточно, чтобы эти whitelisted-участники вели себя корректно — и это уже допущение доверия, о котором маркетинг не упоминает.
Так что слово оказалось точным. Вопрос в другом: почему эта роль вообще должна быть ограничена, если сторона со свопом на WBTC — нет? Язык сценариев Bitcoin не может оценивать произвольное произвольное состояние внечейн. BitVM3 обходит это, заворачивая верификатор доказательства с нулевым разглашением в запутанную схему (garbled circuit), но всё равно кто-то должен сгенерировать и отправить это доказательство, чтобы запустить редемпшн. Сторона со свопом на WBTC легко допускает безразрешительность: любой ликвидатор с капиталом просто берёт сделку. Отправка доказательства — более сложная проблема, которую BitVM3 пока не решила.
Это не про то, является ли сейф бесдоверительным. Babylon не прятал whitelisting в своём собственном белом документе. Бесдоверительность здесь не исчезает. Просто она заканчивается на один шаг раньше, чем это признают большинство публикаций.
$EUL
Что определяет по-настоящему бесдоверительный BTC-сейф?
⚡ Permissionless liquidation
100%
🔓 Permissionless redemption
0%
🤔 Not sure yet
0%
⚖️ Both are equally important
0%
1 проголосовали • Голосование закрыто
См. перевод
join
英鸿³³₇
·
--
[Повтор] 🎙️ Поговорим о любви и ненависти на первичном рынке, а также о DCA в BNB на вторичном рынке
02 ч 17 мин 48 сек · Слушатели: 12.8k
$DEXE Goooooo 👉🏻
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
dва пула одного и того же актива, расположенные в нескольких кликах друг от друга, без какой-либо связи между ними до сих пор. Aave несёт примерно $5B в WBTC, которые почти не двигаются на стороне заимствований. Babylon удерживает $4B+ в стейкнутом BTC, не получая ничего сверх стейкинговых наград.
вот в чём реальный питч, похороненный в Temp Check Babylon — не «безусловный BTC», а сопоставление простаивающего предложения на одной платформе с простаивающим залогом на другой.
дизайн Aave по модели Hub-and-Spoke в V4 — это то, что делает возможным всё это без того, чтобы Babylon вообще прикасалась к ключевому пулу кредитования Aave. два новых Spoke разворачиваются как изолированные модули — Babylon владеет логикой обеспечения BTC, а главный Hub Aave остаётся нетронутым тем риском, который это вносит.
стоит отметить: это не общественная инициатива, которая проскочила незамеченной. основатель Aave публично поддержал её, отдельно указав на реализацию Spoke как на новый паттерн для V4 — не просто ещё один листинг актива.
пока ещё стадия Temp Check. ARFC и голосование в ончейне должны состояться, прежде чем любой BTC реально начнёт движение через это.
если по прошествии нескольких месяцев после прохождения управления оба пула всё ещё будут простаивать, проблема никогда не была в «трубах». это было аппетитом.
$DEXE
Что важнее всего, если это запустят?
dва пула одного и того же актива, расположенные в нескольких кликах друг от друга, без какой-либо связи между ними до сих пор. Aave несёт примерно $5B в WBTC, которые почти не двигаются на стороне заимствований. Babylon удерживает $4B+ в стейкнутом BTC, не получая ничего сверх стейкинговых наград.
вот в чём реальный питч, похороненный в Temp Check Babylon — не «безусловный BTC», а сопоставление простаивающего предложения на одной платформе с простаивающим залогом на другой.
дизайн Aave по модели Hub-and-Spoke в V4 — это то, что делает возможным всё это без того, чтобы Babylon вообще прикасалась к ключевому пулу кредитования Aave. два новых Spoke разворачиваются как изолированные модули — Babylon владеет логикой обеспечения BTC, а главный Hub Aave остаётся нетронутым тем риском, который это вносит.
стоит отметить: это не общественная инициатива, которая проскочила незамеченной. основатель Aave публично поддержал её, отдельно указав на реализацию Spoke как на новый паттерн для V4 — не просто ещё один листинг актива.
пока ещё стадия Temp Check. ARFC и голосование в ончейне должны состояться, прежде чем любой BTC реально начнёт движение через это.
если по прошествии нескольких месяцев после прохождения управления оба пула всё ещё будут простаивать, проблема никогда не была в «трубах». это было аппетитом.
$DEXE
Что важнее всего, если это запустят?
Частичная правда
#baby $BABY @BabylonLabs_io
Довелось прошлой ночью читать заметки о миграции Aave v3 в v4 — в основном от скуки — и одна строка из собственного vault paper Babylon’а запомнилась мне после того, как я закрыл вкладку: условия расходования для vault TBV, включая контракт назначения, фиксируются в тот момент, когда он создаётся; это буквально то, что делает его trustless. Никто не может перенаправить BTC позже без этого заранее согласованного пути. Что это тихо означает: если Aave когда-нибудь снова будет мигрировать контракты так, как только что сделала с v3 на v4, существующий vault не сможет “следовать” за изменениями — ему нужно будет разматываться по собственному таймлайну Bitcoin и пересоздаваться, указывая на новый destination, каждый раз, когда обновляется протокол назначения. Trustlessness здесь не бесплатна — её “платят” жёсткостью, и никто, похоже, не закладывает это в расчёты. Я не смог найти публичных деталей о том, планируют ли Babylon или Aave инструменты, которые сделают этот переход более плавным. Это не про то, насколько безопасно выглядит vault в день, когда вы его создаёте. Это про то, что произойдёт в тот день, когда должна измениться другая сторона.
$DEXE
Здесь в чём более крупный компромисс?
Довелось прошлой ночью читать заметки о миграции Aave v3 в v4 — в основном от скуки — и одна строка из собственного vault paper Babylon’а запомнилась мне после того, как я закрыл вкладку: условия расходования для vault TBV, включая контракт назначения, фиксируются в тот момент, когда он создаётся; это буквально то, что делает его trustless. Никто не может перенаправить BTC позже без этого заранее согласованного пути. Что это тихо означает: если Aave когда-нибудь снова будет мигрировать контракты так, как только что сделала с v3 на v4, существующий vault не сможет “следовать” за изменениями — ему нужно будет разматываться по собственному таймлайну Bitcoin и пересоздаваться, указывая на новый destination, каждый раз, когда обновляется протокол назначения. Trustlessness здесь не бесплатна — её “платят” жёсткостью, и никто, похоже, не закладывает это в расчёты. Я не смог найти публичных деталей о том, планируют ли Babylon или Aave инструменты, которые сделают этот переход более плавным. Это не про то, насколько безопасно выглядит vault в день, когда вы его создаёте. Это про то, что произойдёт в тот день, когда должна измениться другая сторона.
$DEXE
Здесь в чём более крупный компромисс?
🔒 Stronger security
33%
🔄 Easier upgrades
0%
⚖️ Need both
0%
🤔 Still researching
67%
6 проголосовали • Голосование закрыто
Войдите, чтобы посмотреть больше материала