#dusk Recentemente, estou fazendo uma revisão da arquitetura do gateway de fundos e descobri uma área cega de sincronização extremamente discreta. Muita gente acha que, ao varrer o nó e obter o sinal de confirmação na blockchain, já dá para adicionar saldo diretamente na conta do banco de dados, mas ignora a disputa crítica de atribuição e deduplicação. Na análise, o campo de observação é usado para ancorar a identidade do usuário, e o hash da transação é a linha de defesa para implementar o mecanismo de prevenção a reentrada. Se você fizer apenas correspondência por tags, é fácil inserir dinheiro na conta errada por conflitos de grafia; se fizer apenas deduplicação por hash, o programa fica diante do impasse insolúvel de não saber para quem deve ser destinado o dinheiro.@Dusk

Esta semana, enquanto testava o nó $DUSK , eu interrompi manualmente o processo de serviço, tentando reproduzir a reconstrução após uma falha catastrófica. Se o código avançar primeiro o checkpoint da verificação do bloco e, antes de efetivar o lançamento, travar, após reiniciar ele pulará aquele fluxo e gerará uma conta incorreta. Se a ordem for invertida, primeiro acrescentar o ativo e depois armazenar o progresso de leitura, ao reiniciar será inevitavelmente causada uma contagem duplicada fatal. Fica claro que a vinculação atômica entre varredura e lançamento é uma linha de sobrevivência.$BTC

Indo mais fundo, a aparente correspondência de entrada mapeia entidades lógicas completamente diferentes. O fluxo Moonlight publicamente transparente e a conversão Phoenix através de fronteiras de privacidade, vistos pela perspectiva do gateway, parecem apenas aumento de números, mas as regras de escuta dos eventos subjacentes são totalmente distintas. Um empacotamento grosseiro inevitavelmente causa uma tragédia de conciliação. Para avaliar se a rede é robusta, não basta ficar de olho na velocidade de produzir blocos; é preciso verificar se ela consegue fornecer evidências de recuperação por prova de conhecimento zero.$ETH

Acho que esse tipo de mecanismo de conciliação, embora seja trabalhoso, tem mesmo dois lados. Ele alonga o ciclo de integração técnica, eleva o custo de tentativa e erro e deixa muito doloroso para desenvolvedores acostumados a ajustar a interface. Porém, para instituições que fazem custódia, um sistema suave quando está tudo tranquilo pode ser enganoso. Depois de derrubar a energia do datacenter e ligar de novo, cada transação pode ser verificada retrospectivamente com precisão a partir da cadeia de evidências da árvore de Merkel—é essa a verdadeira muralha.

Quando vocês rodam nós no dia a dia ou executam scripts de interação, qual é o tipo de acidente causado por camada mais baixa que mais temem?