@Dusk da esteira de transmissão central do sistema, economiza esforço e ainda entrega o interruptor
Na documentação oficial, a camada EVM do Dusk é impulsionada por um único sequenciador. Isso é o mesmo tipo de “esqueleto” que os centralized sequencers daqueles L2 da Ethereum. Uma única esteira central organiza todas as transações em fila; os desenvolvedores não precisam construir trilhos próprios. Mas, se essa esteira para, não se move nem uma caixa na loja inteira. Os L2 da Ethereum trocaram o sequenciamento por barateamento; o Dusk segue o mesmo caminho. Barato e frágil frequentemente são vendidos juntos. Os desenvolvedores, buscando praticidade, acabam entregando o seu ponto vital. Ao escolher o mesmo esqueleto, o Dusk também aceitou o mesmo custo.
Para custódia institucional, essa esteira significa que a ordem de liquidação fica a critério da parte do Dusk. Meu padrão é simples: de que forma o dinheiro será ordenado e quem tem permissão para apertar o botão de pausa devem estar registrados em regras verificáveis, e não escondidos nas luzes indicadoras de alguma máquina. No contrato de custódia, precisa ficar claro quem é responsável por interrupções e quem antecipa no resgate do cliente. Se as regras não estiverem claras, na prática não há responsabilidade. Se um resgate travar, quem entra em pânico primeiro é a pessoa — não a máquina.
As regras de custódia da ESMA justamente estão investigando isso: quem controla os ativos do cliente e quem responde quando ocorre uma interrupção. O consenso da mainnet do Dusk dá a finalização das transações, mas o “interruptor de ordenação” na camada EVM ainda fica nas mãos do projeto. O que o custodiante quer é uma garantia que possa ser escrita no contrato, e não um manual que promete finalização, mas não consegue controlar a ordenação. O revisor quer responsabilidades e obrigações, não palavras. Por mais alto que empilhem o vocabulário, isso não preenche o buraco onde faltam responsabilidades. A finalização pode controlar o razão contábil, mas não controla esse fio de energia. A regulação quer responsabilidade assinada, não um diagrama de arquitetura bonito.
Assim, a compatibilidade com EVM economiza o esforço de engenharia que o Dusk evita; na outra ponta, há a transferência de soberania sobre a ordenação. Eu prefiro escrever esse interruptor de ordenação na lista de due diligence do custodiante, em vez de confiar apenas nas promessas do whitepaper. Mesmo com um consenso da mainnet bem estável, ele não cobre esse interruptor de ordenação — o risco está onde o interruptor estiver na mão. Mesmo que as palavras do whitepaper estejam bem firmes, não dá para cobrir a diferença de uma camada que separa o modo manual. Quando a ESMA observa a cadeia de custódia e pergunta quem fica com a paralisação, você tem uma garantia no contrato, ou fica com o disjuntor de esteira nas mãos de outra pessoa? Quando a luz apaga, quem você chama? $BTC $ETH #dusk $DUSK @Dusk
Na documentação oficial, a camada EVM do Dusk é impulsionada por um único sequenciador. Isso é o mesmo tipo de “esqueleto” que os centralized sequencers daqueles L2 da Ethereum. Uma única esteira central organiza todas as transações em fila; os desenvolvedores não precisam construir trilhos próprios. Mas, se essa esteira para, não se move nem uma caixa na loja inteira. Os L2 da Ethereum trocaram o sequenciamento por barateamento; o Dusk segue o mesmo caminho. Barato e frágil frequentemente são vendidos juntos. Os desenvolvedores, buscando praticidade, acabam entregando o seu ponto vital. Ao escolher o mesmo esqueleto, o Dusk também aceitou o mesmo custo.
Para custódia institucional, essa esteira significa que a ordem de liquidação fica a critério da parte do Dusk. Meu padrão é simples: de que forma o dinheiro será ordenado e quem tem permissão para apertar o botão de pausa devem estar registrados em regras verificáveis, e não escondidos nas luzes indicadoras de alguma máquina. No contrato de custódia, precisa ficar claro quem é responsável por interrupções e quem antecipa no resgate do cliente. Se as regras não estiverem claras, na prática não há responsabilidade. Se um resgate travar, quem entra em pânico primeiro é a pessoa — não a máquina.
As regras de custódia da ESMA justamente estão investigando isso: quem controla os ativos do cliente e quem responde quando ocorre uma interrupção. O consenso da mainnet do Dusk dá a finalização das transações, mas o “interruptor de ordenação” na camada EVM ainda fica nas mãos do projeto. O que o custodiante quer é uma garantia que possa ser escrita no contrato, e não um manual que promete finalização, mas não consegue controlar a ordenação. O revisor quer responsabilidades e obrigações, não palavras. Por mais alto que empilhem o vocabulário, isso não preenche o buraco onde faltam responsabilidades. A finalização pode controlar o razão contábil, mas não controla esse fio de energia. A regulação quer responsabilidade assinada, não um diagrama de arquitetura bonito.
Assim, a compatibilidade com EVM economiza o esforço de engenharia que o Dusk evita; na outra ponta, há a transferência de soberania sobre a ordenação. Eu prefiro escrever esse interruptor de ordenação na lista de due diligence do custodiante, em vez de confiar apenas nas promessas do whitepaper. Mesmo com um consenso da mainnet bem estável, ele não cobre esse interruptor de ordenação — o risco está onde o interruptor estiver na mão. Mesmo que as palavras do whitepaper estejam bem firmes, não dá para cobrir a diferença de uma camada que separa o modo manual. Quando a ESMA observa a cadeia de custódia e pergunta quem fica com a paralisação, você tem uma garantia no contrato, ou fica com o disjuntor de esteira nas mãos de outra pessoa? Quando a luz apaga, quem você chama? $BTC $ETH #dusk $DUSK @Dusk