#baby $BABY пакетно заходить в Bitcoin — кажется, что это просто объединение нескольких транзакций в одну; в TBV это больше похоже на тест возможностей управления состояниями.
Я наткнулся на параметр «maxHtlcOutputCount» на странице настроек — и только тогда заметил, что в текущем публичном тестнете одна пакетная транзакция Pre-PegIn может содержать максимум 10 HTLC-выходов. Несколько Vault могут использовать одну и ту же Bitcoin-транзакцию, но каждый выход сохраняет собственное состояние Vault и условия выхода. Для тех, кто открывает только один Vault, это ограничение далеко не критично; для тех, кто последовательно создает несколько закладок, оно напрямую определяет стоимость входа и ритм операций.
Проблемы всплывут после подтверждения. Пользователь не может просто смотреть на один transaction hash — нужно отдельно подтверждать ACK, активацию и заемное (可借) состояние каждого Vault. Если, например, комиссии внезапно вырастут или какой-то из выходов не будет завершен вовремя, эффективность от пакетной организации не превратится автоматически в синхронный пользовательский опыт: оператору придется обработать набор состояний, а пользователю — нести затраты на ожидание и принятие решений. Экономия на организационных транзакционных расходах может снова «утечь» через интерфейс и поддержку.
Вот почему при анализе пакетного дизайна TBV я больше всего обращаю внимание именно на это. Он оптимизирует «как за один раз отправить», но не устраняет для пользователя различия в управлении между несколькими Vault. После @BabylonLabs_io , если в открытом доступе появятся повторные попытки провалившихся пакетных Pre-PegIn и изменения состояний одиночного Vault, станет гораздо легче понять, снижает ли это издержки использования или просто переносит сложность на пользователя. Нарратив TBV для $BABY в итоге должен выдержать такие детальные расспросы.
Я наткнулся на параметр «maxHtlcOutputCount» на странице настроек — и только тогда заметил, что в текущем публичном тестнете одна пакетная транзакция Pre-PegIn может содержать максимум 10 HTLC-выходов. Несколько Vault могут использовать одну и ту же Bitcoin-транзакцию, но каждый выход сохраняет собственное состояние Vault и условия выхода. Для тех, кто открывает только один Vault, это ограничение далеко не критично; для тех, кто последовательно создает несколько закладок, оно напрямую определяет стоимость входа и ритм операций.
Проблемы всплывут после подтверждения. Пользователь не может просто смотреть на один transaction hash — нужно отдельно подтверждать ACK, активацию и заемное (可借) состояние каждого Vault. Если, например, комиссии внезапно вырастут или какой-то из выходов не будет завершен вовремя, эффективность от пакетной организации не превратится автоматически в синхронный пользовательский опыт: оператору придется обработать набор состояний, а пользователю — нести затраты на ожидание и принятие решений. Экономия на организационных транзакционных расходах может снова «утечь» через интерфейс и поддержку.
Вот почему при анализе пакетного дизайна TBV я больше всего обращаю внимание именно на это. Он оптимизирует «как за один раз отправить», но не устраняет для пользователя различия в управлении между несколькими Vault. После @BabylonLabs_io , если в открытом доступе появятся повторные попытки провалившихся пакетных Pre-PegIn и изменения состояний одиночного Vault, станет гораздо легче понять, снижает ли это издержки использования или просто переносит сложность на пользователя. Нарратив TBV для $BABY в итоге должен выдержать такие детальные расспросы.