Avaliar se uma cadeia pode ser realmente “colocada na prática” exige mais do que olhar o whitepaper — é preciso desmontá-la em alguns indicadores de engenharia e passar por cada um. @Dusk me fez querer abri-la para ver por dentro exatamente esses detalhes.
Primeiro, o modelo de conta. Ele mantém duas bases de dados ao mesmo tempo: uma pública e outra secreta. Como os fundos alternam entre as duas, isso significa que o mesmo ativo precisa ficar sendo trocado repetidamente entre dois modos de contabilização. Para um usuário comum, isso implica que cada operação precisa primeiro deixar claro de que lado ele está; o custo de aprendizado, naturalmente, fica bem maior do que em uma cadeia de livro único. $TUT
Depois, os nós. A camada mais baixa, responsável pelo processamento e armazenamento, concentra no próprio programa dos nós o consenso, a manutenção de estado e as interfaces com o exterior. Quanto mais pesado for o nó, mais fácil é que as experiências de sincronização e re-sincronização virem gargalos — mesmo que o log esteja rolando rápido, o usuário não consegue distinguir se está funcionando normalmente ou se é uma “roda-livre” anormal.
Em seguida, o desempenho de transferências confidenciais. Esse tipo de transferência precisa executar, localmente, uma grande quantidade de operações criptográficas: selecionar os “fragmentos” de saldo necessários, gerar endereços de troco que não revelem informações, calcular marcas anti-duplicação (anti-double-spending) e, por fim, colocar tudo dentro de uma prova gerada “na hora”. Uma única transferência já exige que o dispositivo trabalhe bastante. À medida que a quantidade de fragmentos aumenta e quando é necessário combiná-los para pagar, o tempo de espera só cresce em escala multiplicativa. Além disso, a carteira precisa varrer todos os fragmentos na cadeia, tentando decifrá-los um por um para identificar o saldo que é seu — e quando há muitos fragmentos, essa etapa também vira um fardo “invisível”.
A entrada no consenso também merece ser questionada. O mecanismo de comitê promete que serão poucas rodadas até ficar definido, mas os critérios para a entrada dos membros do comitê, os limiares de tamanho e se o grupo ficará ocupado a longo prazo por uma minoria — tudo isso determina se “abertura na superfície” e “possibilidade real de participar” são consistentes.
Por fim, a divulgação de identidade. A divulgação seletiva, em teoria, separa “provar que os requisitos foram atendidos” de “entregar informações específicas”. Mas, na conversa real com órgãos reguladores, o que eles geralmente querem são detalhes concretos — esse abismo não se preenche automaticamente apenas com criptografia.
Esses pontos, individualmente, talvez não sejam fatais. Mas, juntos, determinam o quão perto o Dusk está de ser “pronto para uso por usuários comuns”. A direção técnica pode ser muito nova, mas o outro lado das novidades — muitas vezes — ainda não é tão fácil e “na mão” quanto deveria. #dusk $DUSK
Primeiro, o modelo de conta. Ele mantém duas bases de dados ao mesmo tempo: uma pública e outra secreta. Como os fundos alternam entre as duas, isso significa que o mesmo ativo precisa ficar sendo trocado repetidamente entre dois modos de contabilização. Para um usuário comum, isso implica que cada operação precisa primeiro deixar claro de que lado ele está; o custo de aprendizado, naturalmente, fica bem maior do que em uma cadeia de livro único. $TUT
Depois, os nós. A camada mais baixa, responsável pelo processamento e armazenamento, concentra no próprio programa dos nós o consenso, a manutenção de estado e as interfaces com o exterior. Quanto mais pesado for o nó, mais fácil é que as experiências de sincronização e re-sincronização virem gargalos — mesmo que o log esteja rolando rápido, o usuário não consegue distinguir se está funcionando normalmente ou se é uma “roda-livre” anormal.
Em seguida, o desempenho de transferências confidenciais. Esse tipo de transferência precisa executar, localmente, uma grande quantidade de operações criptográficas: selecionar os “fragmentos” de saldo necessários, gerar endereços de troco que não revelem informações, calcular marcas anti-duplicação (anti-double-spending) e, por fim, colocar tudo dentro de uma prova gerada “na hora”. Uma única transferência já exige que o dispositivo trabalhe bastante. À medida que a quantidade de fragmentos aumenta e quando é necessário combiná-los para pagar, o tempo de espera só cresce em escala multiplicativa. Além disso, a carteira precisa varrer todos os fragmentos na cadeia, tentando decifrá-los um por um para identificar o saldo que é seu — e quando há muitos fragmentos, essa etapa também vira um fardo “invisível”.
A entrada no consenso também merece ser questionada. O mecanismo de comitê promete que serão poucas rodadas até ficar definido, mas os critérios para a entrada dos membros do comitê, os limiares de tamanho e se o grupo ficará ocupado a longo prazo por uma minoria — tudo isso determina se “abertura na superfície” e “possibilidade real de participar” são consistentes.
Por fim, a divulgação de identidade. A divulgação seletiva, em teoria, separa “provar que os requisitos foram atendidos” de “entregar informações específicas”. Mas, na conversa real com órgãos reguladores, o que eles geralmente querem são detalhes concretos — esse abismo não se preenche automaticamente apenas com criptografia.
Esses pontos, individualmente, talvez não sejam fatais. Mas, juntos, determinam o quão perto o Dusk está de ser “pronto para uso por usuários comuns”. A direção técnica pode ser muito nova, mas o outro lado das novidades — muitas vezes — ainda não é tão fácil e “na mão” quanto deveria. #dusk $DUSK