Ao revisar o design do Cofre de Bitcoin sem Confiança da Babylon, um detalhe continuava me incomodando: um cofre é criado para uma aplicação específica e não pode simplesmente ser redistribuído para outro lugar.
Eu costumava achar que a mobilidade de capital estava garantida enquanto eu ainda controlasse a garantia.
Mas essa suposição já não parecia tão óbvia.
Eu simulei uma posição concluída com:
Garantia nativa: 0.2864
Dívida restante: $0.00
Saída solicitada: 09:42:16
Prova de resgate pronta: 10:03:51
Período de contestação: ~72 horas
Ativação estimada em outro lugar: ~2 horas
Mesmo depois de a dívida ter sido totalmente quitada, mover a mesma garantia exigia uma saída completa e uma nova entrada:
Sacar → gerar prova → concluir o período de contestação → receber a garantia → criar um novo cofre → ativar novamente.
O tempo estimado de troca era de cerca de 74 horas.
A propriedade nunca mudou.
A aplicação original não conseguia redirecionar a garantia, e as regras de saque continuavam sob a posição que eu havia aceitado.
Mas o capital ainda ficava temporariamente vinculado àquela aplicação.
Essa distinção me fez pensar sobre o Lock-In de Aplicações.
A isoloção protege uma posição dos bugs, políticas e da lógica de liquidação de outra aplicação.
Mas isso também pode criar um custo de troca.
Na minha simulação, uma oportunidade alternativa oferecia melhores condições de empréstimo por apenas 48 horas.
A garantia estava segura, porém ela ficaria disponível aproximadamente 26 horas depois de a oportunidade ter encerrado.
Então propriedade e mobilidade não são a mesma coisa.
Meu feedback é que cada cofre deve exibir:
Vinculação atual à aplicação
Conclusão estimada da saída
Tempo mais cedo para redireciplo
Custo de troca esperado
Janela de oportunidade restante
A isolaçao protege o capital de contágio.
Portabilidade define se esse capital ainda pode competir.
Será que cofres específicos por aplicação poderiam eventualmente forçar protocolos a competirem não apenas nas condições de empréstimo, mas também em quão facilmente os usuários conseguem sair?
@BabylonLabs_io $BABY #baby
$KOMA $1000RATS
Eu costumava achar que a mobilidade de capital estava garantida enquanto eu ainda controlasse a garantia.
Mas essa suposição já não parecia tão óbvia.
Eu simulei uma posição concluída com:
Garantia nativa: 0.2864
Dívida restante: $0.00
Saída solicitada: 09:42:16
Prova de resgate pronta: 10:03:51
Período de contestação: ~72 horas
Ativação estimada em outro lugar: ~2 horas
Mesmo depois de a dívida ter sido totalmente quitada, mover a mesma garantia exigia uma saída completa e uma nova entrada:
Sacar → gerar prova → concluir o período de contestação → receber a garantia → criar um novo cofre → ativar novamente.
O tempo estimado de troca era de cerca de 74 horas.
A propriedade nunca mudou.
A aplicação original não conseguia redirecionar a garantia, e as regras de saque continuavam sob a posição que eu havia aceitado.
Mas o capital ainda ficava temporariamente vinculado àquela aplicação.
Essa distinção me fez pensar sobre o Lock-In de Aplicações.
A isoloção protege uma posição dos bugs, políticas e da lógica de liquidação de outra aplicação.
Mas isso também pode criar um custo de troca.
Na minha simulação, uma oportunidade alternativa oferecia melhores condições de empréstimo por apenas 48 horas.
A garantia estava segura, porém ela ficaria disponível aproximadamente 26 horas depois de a oportunidade ter encerrado.
Então propriedade e mobilidade não são a mesma coisa.
Meu feedback é que cada cofre deve exibir:
Vinculação atual à aplicação
Conclusão estimada da saída
Tempo mais cedo para redireciplo
Custo de troca esperado
Janela de oportunidade restante
A isolaçao protege o capital de contágio.
Portabilidade define se esse capital ainda pode competir.
Será que cofres específicos por aplicação poderiam eventualmente forçar protocolos a competirem não apenas nas condições de empréstimo, mas também em quão facilmente os usuários conseguem sair?
@BabylonLabs_io $BABY #baby
$KOMA $1000RATS