Вчера ночью я не спал всю ночь, выверяя эти детали расчётов. Дизайн BabylonLabs Trustless Bitcoin Vaults в этой части оказался не таким, как я изначально понимал. Большинство думает, что при комбинированном залоге/кредитовании (мульти-вайлет) клиринг работает как пропорциональное списание понемногу из каждого хранилища: вроде бы возились бы “всем понемногу”, но на самом деле это не так. Протокол формирует список хранилищ, принадлежащих вкладчикам, и при клиринге начинает списывать с начала этого списка отрезок «префикса» (prefix), пока списание не покроет ровно ту сумму, которую нужно погасить, а не разносит нагрузку равномерно по всем хранилищам. Это означает, что хранилища, стоящие в начале списка, несут больший риск: если вы последовательно добавили несколько хранилищ в один и тот же кредитный/заёмный позиции, то, скорее всего, первой под клиринг попадёт самая ранняя партия. Если провести аналогию, это похоже на списание запасов по принципу FIFO, а не на усреднённое распределение. Конкретно по какому правилу делается сортировка — по времени внесения или по ID хранилища — в документации не прописано, я не нашёл чёткого определения.
#baby
Когда я сам смотрю на этот механизм, в операционном плане я буду стараться избегать слишком большого числа маленьких хранилищ, чтобы собрать одну позицию: лучше иметь несколько крупных хранилищ, привязанных к позиции. Причина — чем длиннее цепочка, тем хуже предсказуемо, какое место в очереди/списке у тебя окажется. Ограничение в том, что я это также не проверял экспериментально на реальном порядке исполнения во время клиринга.
@BabylonLabs_io
По поводу дальнейшего движения $BABY : моё мнение такое — детали этого базового механизма в краткосрочной перспективе сложно напрямую заложить в цену. Это больше похоже на «медицинский отчёт/чек-ап» для последующих институциональных участников, чтобы они могли лучше оценить, насколько система устойчива к тому, чтобы её «вскрывали по цифрам». Чем лучше механизм выдерживает придирчивую проверку формулировок, тем ниже порог для входа больших денег — это медленная переменная, а не катализатор, который сразу отражается на свечах. Я не буду делать ребалансирование только потому, что понял эту деталь: скорее запишу это как заметку и пересмотрю позже, когда появятся данные по мейннету и число подключившихся участников. Вы, когда собираете позиции из множества хранилищ, специально контролируете их количество?
#baby $BABY $ETH
#baby
Когда я сам смотрю на этот механизм, в операционном плане я буду стараться избегать слишком большого числа маленьких хранилищ, чтобы собрать одну позицию: лучше иметь несколько крупных хранилищ, привязанных к позиции. Причина — чем длиннее цепочка, тем хуже предсказуемо, какое место в очереди/списке у тебя окажется. Ограничение в том, что я это также не проверял экспериментально на реальном порядке исполнения во время клиринга.
@BabylonLabs_io
По поводу дальнейшего движения $BABY : моё мнение такое — детали этого базового механизма в краткосрочной перспективе сложно напрямую заложить в цену. Это больше похоже на «медицинский отчёт/чек-ап» для последующих институциональных участников, чтобы они могли лучше оценить, насколько система устойчива к тому, чтобы её «вскрывали по цифрам». Чем лучше механизм выдерживает придирчивую проверку формулировок, тем ниже порог для входа больших денег — это медленная переменная, а не катализатор, который сразу отражается на свечах. Я не буду делать ребалансирование только потому, что понял эту деталь: скорее запишу это как заметку и пересмотрю позже, когда появятся данные по мейннету и число подключившихся участников. Вы, когда собираете позиции из множества хранилищ, специально контролируете их количество?
#baby $BABY $ETH