Voltei hoje às especificações da arquitetura técnica do @BabylonLabs_io para ver como as saídas de um vault realmente são executadas na Bitcoin L1 sem covenants nativos.
Vale a pena entender os mecanismos aqui. A Bitcoin ainda não tem covenants nativos (OP_COVENANT). Então como um Trustless Bitcoin Vault impõe timelocks e slashing sem uma VM de smart contract?
Ele se baseia em árvores de transações Taproot pré-assinadas construídas no exato momento em que você trava seu BTC.
Minha suposição inicial era que, quando o timelock expira ou uma condição de slashing é acionada, a transação simplesmente pousa de forma contínua na Bitcoin L1.
Não automaticamente.
Como essas transações são pré-assinadas com antecedência, as taxas dos mineradores (sat/vB) são estruturadas de acordo com os ambientes de fee no momento da criação do vault.
Se o mempool da Bitcoin L1 enfrentar um pico massivo de congestionamento durante uma queda forte do mercado—saltando de 15 sat/vB para 250+ sat/vB—uma transação pré-assinada de desoneração (unbonding) ou de slashing pode ficar travada no mempool a menos que mecanismos de aumento de fee como CPFP (Child-Pays-For-Parent) ou RBF sejam acionados ativamente.
A criptografia por trás dos caminhos de spend do EOTS e do script do Taproot é totalmente trustless e à prova de falhas.
Mas a execução na Bitcoin L1 está sempre a jusante da economia de taxas do mempool.
Se as taxas de gas na L1 dispararem durante um evento de liquidação no mercado, a garantia criptográfica ainda importa se a transação ficar enfileirada atrás de milhares de ordinals e transferências?
Esse é o detalhe entre validade criptográfica e prioridade no mempool.
Ao avaliar a arquitetura do $BABY vault, o que você considera o maior gargalo durante alta congestão na L1? #baby $BABY
Vale a pena entender os mecanismos aqui. A Bitcoin ainda não tem covenants nativos (OP_COVENANT). Então como um Trustless Bitcoin Vault impõe timelocks e slashing sem uma VM de smart contract?
Ele se baseia em árvores de transações Taproot pré-assinadas construídas no exato momento em que você trava seu BTC.
Minha suposição inicial era que, quando o timelock expira ou uma condição de slashing é acionada, a transação simplesmente pousa de forma contínua na Bitcoin L1.
Não automaticamente.
Como essas transações são pré-assinadas com antecedência, as taxas dos mineradores (sat/vB) são estruturadas de acordo com os ambientes de fee no momento da criação do vault.
Se o mempool da Bitcoin L1 enfrentar um pico massivo de congestionamento durante uma queda forte do mercado—saltando de 15 sat/vB para 250+ sat/vB—uma transação pré-assinada de desoneração (unbonding) ou de slashing pode ficar travada no mempool a menos que mecanismos de aumento de fee como CPFP (Child-Pays-For-Parent) ou RBF sejam acionados ativamente.
A criptografia por trás dos caminhos de spend do EOTS e do script do Taproot é totalmente trustless e à prova de falhas.
Mas a execução na Bitcoin L1 está sempre a jusante da economia de taxas do mempool.
Se as taxas de gas na L1 dispararem durante um evento de liquidação no mercado, a garantia criptográfica ainda importa se a transação ficar enfileirada atrás de milhares de ordinals e transferências?
Esse é o detalhe entre validade criptográfica e prioridade no mempool.
Ao avaliar a arquitetura do $BABY vault, o que você considera o maior gargalo durante alta congestão na L1? #baby $BABY