Não leio mais a pausa da ponte de Dusk como uma simples história de inatividade quando vi uma falha na transferência de 8,91 milhões de DUSK 15m55s após o desligamento, enquanto o DuskDS continuava a produzir blocos.
O indicador fácil é zero downtime de protocolo. Útil, mas incompleto. Quatro transações de roubo removeram 10,91 milhões de DUSK, mas apenas 1,919 milhão, ou 17,6%, conseguiu atravessar para a BSC com sucesso. O disjuntor do circuito da ponte limitou a saída, não a violação original da carteira.
Essa separação importa. O DuskDS ainda podia liquidar transações nativas enquanto as rotas de liquidez externas estavam fechadas. Disponibilidade da camada base e disponibilidade do ecossistema não são a mesma coisa. Se carteiras, RPCs, exploradores ou toda ponte importante estiverem indisponíveis, DUSK está operacional para usuários ou apenas “vivo” para validadores?
Eu gostaria que Dusk publicasse cinco relógios separados: disponibilidade da cadeia, do RPC, do explorador, da carteira e da ponte, além de blocos produzidos, finalização mediana, rendimento (throughput), novas contas e atividade nativa versus atividade dependente da ponte durante a pausa. Sem essas séries, “não afetado” descreve consenso, não demanda.
Não haver fundos de usuários e nenhuma falha de protocolo é significativo. Ainda assim, o teste mais difícil é comportamental: a atividade nativa continuou quando as entradas pararam, e qual custo de oportunidade se acumulou em cada dia offline?
O incidente mostrou que a cadeia poderia sobreviver ao gateway. Ainda não mostrou que o ecossistema poderia ignorá-lo.
#dusk $DUSK @Dusk
O indicador fácil é zero downtime de protocolo. Útil, mas incompleto. Quatro transações de roubo removeram 10,91 milhões de DUSK, mas apenas 1,919 milhão, ou 17,6%, conseguiu atravessar para a BSC com sucesso. O disjuntor do circuito da ponte limitou a saída, não a violação original da carteira.
Essa separação importa. O DuskDS ainda podia liquidar transações nativas enquanto as rotas de liquidez externas estavam fechadas. Disponibilidade da camada base e disponibilidade do ecossistema não são a mesma coisa. Se carteiras, RPCs, exploradores ou toda ponte importante estiverem indisponíveis, DUSK está operacional para usuários ou apenas “vivo” para validadores?
Eu gostaria que Dusk publicasse cinco relógios separados: disponibilidade da cadeia, do RPC, do explorador, da carteira e da ponte, além de blocos produzidos, finalização mediana, rendimento (throughput), novas contas e atividade nativa versus atividade dependente da ponte durante a pausa. Sem essas séries, “não afetado” descreve consenso, não demanda.
Não haver fundos de usuários e nenhuma falha de protocolo é significativo. Ainda assim, o teste mais difícil é comportamental: a atividade nativa continuou quando as entradas pararam, e qual custo de oportunidade se acumulou em cada dia offline?
O incidente mostrou que a cadeia poderia sobreviver ao gateway. Ainda não mostrou que o ecossistema poderia ignorá-lo.
#dusk $DUSK @Dusk