Ночами пролистывая материалы про Babylon, я изначально хотел лишь уточнить границы полномочий распорядителя по расчетам. Но чем дальше читал, тем сильнее клонит в сон — и тем не менее меня внезапно «пробило» одной вещью: хранение средств и логика доверия — это совсем не одно и то же.
Сначала я думал, что во всей системе хранилища доверительная модель единая. Но оказалось, что в части депозитов требуется множество «одобрителей», а логика доверия для вывода и для расчетов — совершенно другая.
В блоке депозитов тебе нужно «просить людей». При создании хранилища в сети Ethereum ты отправляешь запрос Peg-In, прикрепляя секрет хэш-лок, известный только тебе. Затем в сети Bitcoin ты рассылаешь транзакцию Pre-PegIn и блокируешь BTC на адресе Taproot, связанном с этим хэш-локом. А дальше начинается самое неприятное: тебе нужно в офчейне вместе с Vault Provider и AVK собрать граф предварительно подписываемых транзакций — и каждый участник должен подписать. Только после того, как депозитчик раскрывает секрет хэш-лока, хранилище считается официально активированным.
А вывод и расчеты устроены иначе. Вывод идет по предварительно подписанному пути: при создании хранилища все допустимые траектории трат уже заранее полностью подготовлены и подписаны. Как только хранилище сгенерировано, никто не сможет подделать новый маршрут расходования. При выводе депозитчик просто использует ключи, с которыми создавалось хранилище, и сам транслирует транзакцию — без участия кого-либо еще.
Что касается расчетов, там условие срабатывания — когда health factor заемщика падает ниже 1.0. Есть два пути: permissioned и permissionless, но независимо от того, какой путь выбран, правила уже «зашиты» при создании хранилища, и расчетчику не нужно ни у кого спрашивать разрешения.
Одна фраза в документе заставила меня остановиться: «Trust is optional and removable». Депозиты требуют участия нескольких сторон, потому что хранилище еще не создано — отношения доверия все еще формируются: нужно, чтобы Vault Provider управлял настройкой, AVK делали совместную подпись, а Universal Challengers выступали свидетелями. Но как только хранилище создано и граф предварительно подписанных транзакций заморожен, тебе больше не нужно полагаться на каких-либо третьих лиц.
Провозился всю ночь — распорядитель по расчетам так и не был до конца разобран, зато я запутался (и одновременно многое понял) из‑за контраста в доверии между депозитами и выводами. Но потом пришло понимание — и стало казаться логичным: просить при депозите нужно потому, что доверие еще не сформировано; а для вывода и расчетов «никого не просят» потому, что доверие уже зафиксировано в коде. Как тебе эта идея — зависеть от людей в период сборки, а потом полагаться только на код? Тонко задумано или это лишнее? Поговорим в комментариях.
#BABY $BABY @BabylonLabs_io
Сначала я думал, что во всей системе хранилища доверительная модель единая. Но оказалось, что в части депозитов требуется множество «одобрителей», а логика доверия для вывода и для расчетов — совершенно другая.
В блоке депозитов тебе нужно «просить людей». При создании хранилища в сети Ethereum ты отправляешь запрос Peg-In, прикрепляя секрет хэш-лок, известный только тебе. Затем в сети Bitcoin ты рассылаешь транзакцию Pre-PegIn и блокируешь BTC на адресе Taproot, связанном с этим хэш-локом. А дальше начинается самое неприятное: тебе нужно в офчейне вместе с Vault Provider и AVK собрать граф предварительно подписываемых транзакций — и каждый участник должен подписать. Только после того, как депозитчик раскрывает секрет хэш-лока, хранилище считается официально активированным.
А вывод и расчеты устроены иначе. Вывод идет по предварительно подписанному пути: при создании хранилища все допустимые траектории трат уже заранее полностью подготовлены и подписаны. Как только хранилище сгенерировано, никто не сможет подделать новый маршрут расходования. При выводе депозитчик просто использует ключи, с которыми создавалось хранилище, и сам транслирует транзакцию — без участия кого-либо еще.
Что касается расчетов, там условие срабатывания — когда health factor заемщика падает ниже 1.0. Есть два пути: permissioned и permissionless, но независимо от того, какой путь выбран, правила уже «зашиты» при создании хранилища, и расчетчику не нужно ни у кого спрашивать разрешения.
Одна фраза в документе заставила меня остановиться: «Trust is optional and removable». Депозиты требуют участия нескольких сторон, потому что хранилище еще не создано — отношения доверия все еще формируются: нужно, чтобы Vault Provider управлял настройкой, AVK делали совместную подпись, а Universal Challengers выступали свидетелями. Но как только хранилище создано и граф предварительно подписанных транзакций заморожен, тебе больше не нужно полагаться на каких-либо третьих лиц.
Провозился всю ночь — распорядитель по расчетам так и не был до конца разобран, зато я запутался (и одновременно многое понял) из‑за контраста в доверии между депозитами и выводами. Но потом пришло понимание — и стало казаться логичным: просить при депозите нужно потому, что доверие еще не сформировано; а для вывода и расчетов «никого не просят» потому, что доверие уже зафиксировано в коде. Как тебе эта идея — зависеть от людей в период сборки, а потом полагаться только на код? Тонко задумано или это лишнее? Поговорим в комментариях.
#BABY $BABY @BabylonLabs_io