Eu fiz um bridge de um testnet DUSK para o DuskEVM na noite passada e implementei um contrato pequeno, quase só para observar uma transação atravessar o pipeline de ponta a ponta. Confirmou rápido. Naturalmente assumi que isso significava feito — a inclusão aparecendo, a transação sendo encerrada, e seguir em frente.
Turns out que aqui não é exatamente a mesma coisa, e essa lacuna importa mais do que parece. O DuskEVM funciona como um rollup: um sequenciador inclui sua transação primeiro em um bloco L2; depois, um processador (batcher) envia esses dados separadamente para o DuskDS; e só depois que os compromissos de estado e as provas de falha são conectados é que ele realmente liquida. A inclusão acontece em um relógio. A liquidação acontece em outro. Minha carteira mostrou confirmado no momento em que a primeira coisa aconteceu, não na segunda.
Me lembrou de uma compensação de cheques num balcão de banco. O caixa te entrega um recibo assim que ele recebe — parece que está pronto. O dinheiro de verdade não se move entre bancos até que ele compense nos bastidores, no cronograma próprio, independentemente do que o recibo diz.
Faz sentido por que o Dusk traça essa linha tão claramente, considerando para quem essa cadeia foi realmente construída. Um ambiente regulado que movimenta valores mobiliários reais não pode tratar "parece confirmado" e "está liquidado" como intercambiáveis — os documentos deixam explícito que qualquer coisa que mova valor entre o DuskEVM e o Dusk L1 deve verificar diretamente o status do protocolo ou da carteira, e não inferir finalização pelo tempo que passou.
Vale deixar claro que foi testnet — o timing do mainnet pode parecer diferente quando estiver totalmente em operação.
Ainda estou refletindo sobre isso — para uma cadeia mirando uma liquidação no nível de MTF, essa separação entre inclusão e liquidação é abstraída para o usuário final eventualmente, ou o mercado financeiro regulado realmente quer essa lacuna visível de propósito?
#dusk $DUSK @Dusk #DUSK
Turns out que aqui não é exatamente a mesma coisa, e essa lacuna importa mais do que parece. O DuskEVM funciona como um rollup: um sequenciador inclui sua transação primeiro em um bloco L2; depois, um processador (batcher) envia esses dados separadamente para o DuskDS; e só depois que os compromissos de estado e as provas de falha são conectados é que ele realmente liquida. A inclusão acontece em um relógio. A liquidação acontece em outro. Minha carteira mostrou confirmado no momento em que a primeira coisa aconteceu, não na segunda.
Me lembrou de uma compensação de cheques num balcão de banco. O caixa te entrega um recibo assim que ele recebe — parece que está pronto. O dinheiro de verdade não se move entre bancos até que ele compense nos bastidores, no cronograma próprio, independentemente do que o recibo diz.
Faz sentido por que o Dusk traça essa linha tão claramente, considerando para quem essa cadeia foi realmente construída. Um ambiente regulado que movimenta valores mobiliários reais não pode tratar "parece confirmado" e "está liquidado" como intercambiáveis — os documentos deixam explícito que qualquer coisa que mova valor entre o DuskEVM e o Dusk L1 deve verificar diretamente o status do protocolo ou da carteira, e não inferir finalização pelo tempo que passou.
Vale deixar claro que foi testnet — o timing do mainnet pode parecer diferente quando estiver totalmente em operação.
Ainda estou refletindo sobre isso — para uma cadeia mirando uma liquidação no nível de MTF, essa separação entre inclusão e liquidação é abstraída para o usuário final eventualmente, ou o mercado financeiro regulado realmente quer essa lacuna visível de propósito?
#dusk $DUSK @Dusk #DUSK