#dusk Na hora de revisar os dados de interações na cadeia esta semana, quase fui enganado por uma regra de design da base. Normalmente a gente sempre acha que, uma vez que os dados estão empacotados, é só esperar alguns níveis de bloco e pronto, fica garantido. Falando a verdade, eu mesmo operava antes com essa ideia bem superficial. Mas ontem à noite eu me aprofundei nas regras de Dusk de Rolling Finality e só então percebi que essa espera grosseira guiada pela intuição esconde variáveis. $DUSK

Essa rede fragmenta o estado de um jeito bem minucioso. Existe uma configuração extremamente “pegadinha”: mesmo que o bloco saia corretamente, se antes de chegar ao consenso ele passar por rodadas travadas — ou seja, com iterações de falha prévias — o sistema só coloca, no máximo, uma etiqueta de aceitação inicial. Esse estado é como um temporário; em teoria, a qualquer momento pode ser substituído por algum candidato melhor ranqueado. Para “ficar efetivo” de vez, a regra é muito mais exigente do que parece. $BTC

Essa conta não é apenas esperar alguns blocos fixos e acabou. Ela precisa esperar por duas vezes o número de falhas. Suponha que a frente travou duas vezes; então mais tarde você tem que aguentar quatro novos blocos de forma forçada até efetivar. Ou seja, duas transferências que pertencem ao mesmo grupo de transações que já foram incluídas na cadeia: uma saiu diretamente, e a outra saiu aos trancos e barrancos. A força de resistência à reversão no nível de base simplesmente não é na mesma escala; a “fragilidade” se abre de forma bem evidente em camadas. $ETH

Do ponto de vista de uma instituição que faz liquidação DvP, essa lógica de proteção dinâmica é realmente rigorosa, mas isso também significa que o tempo de confirmação vira uma espécie de “caixa surpresa”. Para jogadores comuns fazendo pequenos valores e transações frequentes, alguns segundos de exposição ao risco realmente não são tão problemáticos. Mas para grandes valores, lidar com esse tipo de mecanismo exige ser mais conservador. Como tudo tem dois lados: com a segurança no máximo, o ritmo de eficiência esperado naturalmente precisa ser ajustado. @Dusk

Agora, quando eu monto transferências de alto valor, eu não fico observando um número fixo de confirmações. Eu simplesmente viro o nó e consulto diretamente aquele valor específico de n; mesmo que demore um pouco mais, o objetivo é garantir que passou pela fase frágil. Sinceramente, entender um pouco o funcionamento da camada de base realmente evita várias armadilhas ocultas. No seu dia a dia, quando vocês fazem transferências de grandes valores, em qual etapa vocês ficam mais preocupados?