SOL voltou acima de US$ 100, mas a parte interessante não é o movimento de 4,7%.
No gráfico de 1H, a estrutura melhorou significativamente.
O preço está sustentando acima da MM de 25 (US$ 98,34) e da MM de 99 (US$ 96,97), enquanto a MM de curto prazo (7 MA) fica por volta de US$ 101,23. Isso coloca a tendência firmemente no lado de alta por enquanto.
Mas há um problema.
Agora, o SOL está se aproximando da área de resistência de US$ 102,46–US$ 103,08. A rejeição anterior veio quase exatamente dessa zona.
O movimento atual também merece alguma cautela. O preço subiu, mas o volume está em torno de 134K SOL, versus aproximadamente 170K na média do volume do período 10. Até agora, a tentativa de rompimento não tem confirmação de volume acima do comum.
Meus níveis:
US$ 103,08: nível principal de rompimento
US$ 102,46: resistência imediata
US$ 99,97: primeiro suporte
US$ 98,34: MM de 25 e suporte-chave no curto prazo
US$ 96,97: MM de 99 e suporte mais profundo da tendência
Se o SOL fechar de forma convincente acima de US$ 103, com volume mais forte, a faixa recente pode estar se transformando em uma nova perna de alta.
Se houver rejeição novamente, eu observaria primeiro US$ 100 e depois US$ 98,34. Perder o segundo enfraqueceria consideravelmente a estrutura atual.
O cenário é de alta, mas US$ 103 é onde o SOL precisa provar isso.
Você trataria isso como um setup de rompimento ou como mais uma rejeição prestes a acontecer?
#dusk $DUSK @Dusk Eu pensei que criptografar uma transação significava esconder tudo: remetente, destinatário, valor, tudo. Acabei descobrindo que o mais novo motor de privacidade da Dusk só esconde uma dessas coisas.
Quando eu olhei para o Hedger pela primeira vez, literalmente achei que criptografia homomórfica era a ferramenta de privacidade mais forte que eles tinham. O que ela realmente deixa exposto é a parte mais interessante.
Veja por quê. o Hedger roda na DuskeVM, que é totalmente compatível com a EVM, então desenvolvedores de Ethereum podem levar seus contratos Solidity sem alterações. Essa compatibilidade vem de manter o modelo baseado em conta, o mesmo que o Ethereum usa. Cada conta tem um endereço visível, o que cria um modelo de privacidade diferente do da arquitetura nativa UTXO da Dusk.
Assim, o Hedger criptografa o que acontece dentro dessa visibilidade. Ele usa criptografia homomórfica construída sobre ElGamal em curvas elípticas, o que significa que a rede pode calcular sobre valores criptografados sem nunca descriptografá-los, além de provas de conhecimento zero para confirmar que essas computações foram feitas corretamente. saldos e valores de transferência permanecem criptografados de ponta a ponta. a geração das provas acontece no cliente, em menos de dois segundos.
O que eu não esperava é que isso não forneça anonimato completo. a própria Dusk explica que o modelo EVM baseado em contas limita o nível de anonimato que o Hedger consegue oferecer, ao contrário do modelo Phoenix blindado, que usa uma arquitetura de transação diferente.
A mesma configuração que torna o Hedger rápido, fácil de adotar e compatível com as ferramentas existentes do ecossistema Ethereum é exatamente o que cria esse trade-off de privacidade.
Ainda não sei como os desenvolvedores devem saber qual camada realmente se encaixa no caso de uso deles: a DuskeVM com Hedger ou a DuskVM nativa com Phoenix, quando ambas são descritas pela mesma palavra — privacidade — mas entregam dois modelos de privacidade genuinamente diferentes.
#dusk $DUSK @Dusk Achei que o maior diferencial de uma cadeia de privacidade aparece exatamente quando algo dá errado. A Dusk teve um incidente de verdade, e a privacidade não foi o que impediu isso.
Quando olhei para isso pela primeira vez, pensei apenas que a história seria sobre o que foi explorado. A parte mais interessante acabou sendo o que aconteceu logo depois.
Eis por quê. Em 16 de agosto, a equipe da Dusk identificou uma atividade incomum em uma carteira que eles gerenciam para operações de bridge. A resposta não foi algo que o protocolo detectou ou tratou automaticamente. Uma pessoa percebeu, e uma pessoa agiu.
Então é isto que realmente aconteceu. A equipe desativou e reciclou os endereços ligados àquela carteira. Eles pausaram os serviços de bridge completamente, não apenas a parte afetada. Implementaram uma blocklist para que os fundos não pudessem se mover para endereços já conhecidos por serem ruins. E contataram a Binance diretamente assim que perceberam que parte do fluxo tocou aquela plataforma.
O que me chamou atenção é que nenhuma dessas ações veio da própria camada de privacidade. Todas essas decisões partiram de pessoas com autoridade para desligar algo, fazendo isso rapidamente.
O que torna a tecnologia de privacidade da Dusk genuinamente impressionante é que as transações permanecem privadas para pessoas de fora que olham de dentro. O que realmente protegeu os usuários aqui foi o oposto disso: uma equipe que podia ver o que estava acontecendo e tinha autoridade para intervir no momento em que algo parecia errado.
Até agora, eles estão dizendo que nenhum fundo de usuários foi afetado, mas o bridge continuou fechado enquanto a revisão segue, então é aí que as coisas estão, não onde elas finalmente chegaram.
Para uma cadeia que está avançando com força em direção ao território institucional e de ativos do mundo real, eu não sei qual delas acaba importando mais para as pessoas que eles estão tentando conquistar: a privacidade que protege a atividade de transações, ou os controles centralizados que apenas provaram que conseguem interromper o dano antes que ele se espalhe.
Eu pensei que, quando uma blockchain aceita um bloco, pronto: é permanente, acabou, não há mais movimento. acontece que o dusk trata aceitação e finalidade como duas coisas completamente separadas, e um bloco pode ficar entre elas por algum tempo.
Quando eu olhei para isso pela primeira vez, achei que aceitar significava que o bloco já estava travado naquele momento. a diferença real entre essas duas palavras era mais interessante.
Um bloco só ganha finalidade instantânea em dois casos específicos. ou ele cai na iteração zero, bem em cima de um bloco que já estava final, ou ele cai em uma iteração posterior e todas as iterações anteriores expiram, sem que nada seja produzido. fora desses dois casos, um bloco aceito ainda não é final. ele apenas fica lá, aguardando.
Então o dusk criou um segundo caminho para tudo o que não se qualifica. ele chama isso de finalidade em rolagem. a rede caminha para trás, a partir do bloco aceito mais recente, até o último bloco que realmente era final, somando o peso de stake por trás de cada timeout e do certificado de vitória ao longo do caminho. quando esse peso de stake ultrapassa dois terços do total, o bloco em que ele aterrissa é marcado como final. depois disso.
O que tornou esse ponto mais difícil para mim é que, aqui, a finalidade não é uma propriedade que o bloco conquista no momento em que é feito. ela é atribuída para trás, mais tarde, quando o peso da rede suficiente se alinha atrás dele. o mesmo mecanismo de fallback que permite ao dusk se recuperar quando uma rodada trava é exatamente o que mantém um bloco recém-aceito preso em um limbo, ainda não seguro para tratar como permanente.
Ainda não sei quanto tempo, na prática, essa janela de limbo costuma durar, nem com que frequência duas versões concorrentes de um bloco acabam parecendo válidas para diferentes partes da rede antes que a finalidade em rolagem resolva isso.
Achei que uma prova de conhecimento zero ou verifica tudo ou não verifica nada. nenhuma confiança parcial. descobri que o próprio código de provas do Dusk deixou quatro números completamente sem verificação, e isso foi suficiente para criar dinheiro a partir de uma prova inválida.
quando eu olhei isso pela primeira vez, eu literalmente pensei que uma prova forjada exigiria quebrar criptografia real. a falha real era bem mais simples do que isso.
é por isso. cada transação protegida (shielded) do Dusk carrega uma prova, e essa prova precisa convencer a rede de coisas como propriedade, saldos corretos e entradas válidas. quase todo número dentro dessa prova fica bloqueado, amarrado a um compromisso confiável para que o provador não consiga simplesmente mentir sobre isso. mas quatro números específicos, ligados à forma como a lógica da transação é verificada, nunca foram restringidos dessa maneira. eles existiam na prova, foram usados na matemática final, mas ninguém nunca os verificou em relação aos valores que deveriam representar.
assim, um provador malicioso poderia resolver diretamente os valores ausentes. uma divisão. é só isso. pesquisadores de segurança demonstraram o problema contra um nó do Dusk, criando 2000 DUSK do nada e enviando 1337 para uma carteira normal por meio de uma transação comum. o nó aceitou ambos como válidos.
o que deixou isso ainda mais difícil para mim é que o código do Dusk já havia passado por três auditorias separadas antes de isso ser descoberto.
a mesma concepção que torna as provas de conhecimento zero poderosas — confiar em um único veredito final em vez de você mesmo rechecá-lo de cada afirmação — foi exatamente o que permitiu que quatro números não restringidos ficassem escondidos à vista por tanto tempo.
a correção foi aplicada no Dusk em um dia após serem notificados, mas um bug quase idêntico foi descoberto de forma independente no sistema de provas de outro time na mesma época. se duas implementações não relacionadas lançaram o mesmo ponto cego, não sei quantos outros ainda estão lá, sem serem encontrados.
Dessa vez, percebi algo diferente: uma votação de comitê funciona como a maioria das votações. um membro, uma voz, todos contam igual depois de serem escolhidos. não é assim que isso funciona.
Quando olhei para isso pela primeira vez, pensei que 64 assentos significavam 64 provisionadores diferentes em cada rodada. o motivo real de ter sido construído assim atingiu mais.
Eis por quê. Dusk divide cada comitê em 64 créditos, não em 64 pessoas. a seleção distribui esses créditos conforme o peso do stake. um provisionador com stake suficiente pode se afastar segurando vários créditos no mesmo comitê. não é a contagem de pessoas que decide sua voz; é quanto você colocou.
O sistema de recompensas espelha isso exatamente. as recompensas dos eleitores são divididas em 64 cotas, uma cota por crédito que você recebeu, e não uma divisão fixa só por aparecer. o quórum é o mesmo: o peso decide, não quem está sentado na sala.
A Dusk não está escondendo isso. eles construíram de propósito, vinculando o poder de voto ao stake em risco, e não a quantos nós alguém consegue criar.
O que impede alguém de explorar isso com um milhar de nós pequenos é exatamente a mesma ponderação de stake que permite que um provisionador com stake elevado detenha seis assentos no mesmo comitê.
Ainda não encontrei um limite documentado de quantos créditos um provisionador pode manter em um único comitê. nada do que encontrei até agora especifica um. para uma cadeia que se apresenta a instituições em termos de confiança, não é uma questão pequena deixar isso em aberto.
A parte interessante não é que o stake afeta o poder de voto. isso é explícito.
A questão real é quanta concentração o sistema de 64 créditos permite na prática.
@Dusk $DUSK #dusk Eu pensei que um blockchain ou finaliza um bloco, ou não avança de forma alguma. Afinal, a Dusk construiu um terceiro estado inteiro entre essas duas possibilidades — um que só aparece depois que a rede falha na mesma rodada dezesseis vezes seguidas.
Quando eu olhei isso pela primeira vez, literalmente pensei que o tempo de espera crescente após cada rodada falhada fosse apenas um mecanismo de paciência, algo para suavizar nós lentos. O motivo real de existir é mais interessante.
Eis por quê. Cada rodada falhada faz a próxima tentativa esperar dois segundos a mais, começando em sete e chegando ao máximo em quarenta. Isso foi feito para pequenos soluços: um voto lento aqui, uma assinatura perdida ali. Mas nada nesse desenho impede a rede de falhar repetidas vezes por um motivo genuinamente ruim, e uma cadeia que simplesmente fica ali esperando para sempre é um resultado pior do que quase qualquer bloco único ruim.
Então a Dusk foi construída com uma estrutura rígida em torno de quanto tempo uma rodada é autorizada a “lutar”. Dezesseis tentativas falhadas em sequência e o sistema cai no que eles chamam de modo de emergência. Cinquenta tentativas é o teto absoluto para qualquer rodada. E há um slot específico, a iteração 255, reservado apenas para blocos de emergência.
O que deixou isso mais interessante para mim é que a Dusk não tentou esconder o quanto uma rodada falhando ainda pode parecer normal. Ela apenas traçou uma linha rígida para quando a contagem do “normal” deixa de valer.
O que torna esse consenso paciente também é exatamente o que permite que ele pareça bem por um longo período enquanto, na verdade, está preso. A Dusk não encurtou essa janela; só construiu um muro no fim dela.
Eu ainda não sei o que muda de fato quando o modo de emergência é acionado. Será que o mesmo comitê continua votando do mesmo jeito? Quando um bloco é finalizado ali, ele carrega a mesma garantia de um bloco de uma rodada “limpa”? Para uma cadeia construída ao redor de liquidação institucional, isso não é algo que eu gostaria de deixar em aberto.