一只瓢虫

Do mesmo céu distante: no BSC, comemorando o Festival do Meio-Outono com o mundo
Este ano é o 4º Festival do Meio-Outono que passo com a cripto. Na primeira vez que comprei BNB, eu achava que cripto era apenas as altas e quedas na tela; depois que entrei na Binance, atravessei a BSC e fui além, percebi que era algo mais como uma rede sem fusos horários. O Festival do Meio-Outono fala de reunião; e na cadeia também há reunião — conectando pessoas de continentes diferentes, línguas diferentes e fusos horários diferentes no mesmo mercado.
Antes, as negociações tinham “diferença de horário”: a bolsa de Nova York fechava, Tóquio ainda nem tinha acordado, e investidores asiáticos muitas vezes precisavam ficar acordados até tarde. Hoje, a Binance e a BNB Chain fazem com que a regra de 7×24 horas deixe de ser só um slogan. Às três da manhã, concluí uma transferência na BSC: paguei o Gas com BNB, confirmei em poucos segundos. Na mesma hora, do outro lado do planeta, meus parceiros estavam acompanhando o mercado na Binance, participando do Launchpool e discutindo o ecossistema. A lua ilumina a mim e também a ele; os blocos, como um posto de mensageiros sob a luz lunar, acolhem participantes de diferentes regiões na mesma corrente.
Eu imagino o futuro: os mercados globais não serão mais ilhas separadas. Ações, ouro, títulos, RWA — tudo poderá ser negociado na cadeia 24/7. A Binance será aquele “porto financeiro global” que não fecha, e a BSC será a ponte entre ativos e usuários. Negócios sem diferença de horário não é apenas o gráfico que nunca para; é também a oportunidade de pessoas comuns participarem, juntas, das finanças globais. Independentemente do fuso horário em que você esteja, ao abrir a Binance e conectar à BSC, você consegue sincronizar com o mundo.
Do mesmo céu distante. Neste 4º Meio-Outono, olhei para cima na cadeia e não vi apenas a lua — vi incontáveis nós brilhando juntos. Que no próximo Meio-Outono ainda brindemos na BNB Chain e que a Binance testemunhe o mercado global pulsando em conjunto.
#币安中秋故事

Depois que o empréstimo com garantia de bStocks for disponibilizado, como aproveitar melhor as posições sem deixar de controlar os riscos? Por exemplo, ao usar os recursos emprestados para investir em outros ativos, há recomendações mais prudentes de dimensionamento das posições ou de hedge?

Uau, 333166 unidades de HYPE$HYPE

Uau, US$ 4,5 milhões para comprar $PONS e $CASHCAT

O BTC acabou de cair abaixo dos 78.000 dólares, mas ainda está em alta nas últimas 24 horas. Este mercado é mesmo difícil de entender 😂$BTC

Uau, BTC$BTC caiu abaixo de 78.000 dólares

Uau, US$1,04 milhão para comprar 20.31 milhões de MEME$MEME

Uma certa baleia sacou 1,1 milhão de USDT da Binance e, logo em seguida, comprou na baixa a um preço médio de US$ 0,1155, levando 9,53 milhões de $牛来. Será que vai sustentar o preço do 牛 diretamente?$USDC

Uau, 1100000 unidades de $USDC

Uau, cem milhões de dólares!$SOL

Cada rodada de consenso deve adicionar um novo bloco, mas o white paper diz que esta rodada não é concluída de uma vez; ela é dividida em várias iterações, e cada iteração é dividida em três etapas. A seção 3.2 do white paper chama essas três etapas de Proposal, Validation e Ratification。

Primeira etapa, Proposal. O algoritmo DS seleciona aleatoriamente um provisioner como gerador de blocos, responsável por gerar blocos candidatos e transmiti-los para toda a rede. Se um bloco candidato não for gerado ou recebido dentro do tempo limite especificado, esta etapa retorna NIL e segue diretamente para a próxima etapa — mas, com as mãos vazias, sem blocos candidatos, o que é votado depois? A resposta é não votar em vazio; em vez disso, vota-se em NoCandidate, que significa "nenhum bloco candidato pode ser verificado".$DUSK

Segunda etapa, Validation. O algoritmo DS seleciona aleatoriamente um conjunto de comitês de votação para validar o bloco candidato da etapa anterior. Se o bloco candidato for válido, vota-se Valid; se for inválido, vota-se Invalid; se não houver bloco candidato, vota-se em NoCandidate. O comitê de votação precisa de uma maioria absoluta de 2/3 para atingir um quorum. Se o quorum não for alcançado antes do tempo limite, retorna-se NoQuorum. A saída desta etapa é um ValidationResult, que inclui o tipo de voto que alcançou o quorum e a assinatura agregada de todos os votantes.@Dusk

Terceira etapa, Ratification. Seleciona-se então um novo conjunto de comitês de votação para confirmar o resultado do Validation. Se a etapa anterior alcançar um quorum de Valid, eles confirmam esse resultado; se a etapa anterior for NoQuorum ou falhar, eles votam em NoQuorum. Esta etapa garante que o resultado da validação não seja decidido apenas por uma minoria, mas reconhecido por um número maior de provisioners.

Se a Ratification retornar Success, o bloco candidato é aceito oficialmente como o novo bloco, e a rodada termina. Se retornar Fail ou unknown, entra-se na próxima iteração, selecionando novamente o gerador de blocos e votando novamente. O white paper diz que o número máximo de iterações é determinado por um parâmetro global, e a configuração atual é 50. Se 16 iterações consecutivas falharem, o protocolo entra em modo de emergência (ângulo 10）。

A lógica central do desenho em três etapas é o equilíbrio e controle mútuo — o gerador de blocos só pode gerar blocos candidatos, não pode votar; o comitê de validação só pode validar, não pode confirmar; e o comitê de confirmação só pode confirmar o resultado da validação, não pode revalidar. Nenhum papel, sozinho, pode decidir o destino de um bloco.#dusk

Quando a rede Dusk é iniciada, não basta apenas a máquina virtual Piecrust; ela também precisa implantar um conjunto de contratos gênese para lidar com as operações mais básicas. A seção 6.2 do whitepaper os chama de "genesis contracts"; são contratos inteligentes especiais implantados na inicialização da rede, responsáveis por funções centrais como verificação de transações, mecanismo de staking e distribuição inicial de tokens. O whitepaper destaca dois deles.

O primeiro é o transfer contract (contrato de transferência). Ele gerencia todas as transferências de DUSK e $DUSK também processa a dedução das taxas de gas. Se uma transação incluir a implantação ou chamada de um contrato inteligente, o transfer contract também assume esse processamento — ele verifica se a transação segue as regras de Moonlight ou Phoenix e então deduz a taxa de gas correspondente do saldo do remetente. O whitepaper o descreve como "o ponto de entrada para a blockchain Dusk"; todas as transações acabam passando por ele.

O segundo é o stake contract (contrato de staking). Ele gerencia todo o ciclo de vida do staking: verifica se o valor depositado pelo usuário atinge o limite mínimo de staking, bloqueia os tokens e registra o usuário como provisioner. Quanto mais DUSK em staking, maior a probabilidade de ser selecionado pelo algoritmo DS para participar do consenso. O contrato também trata das solicitações de unstaking — após o fim do período de bloqueio, o usuário pode recuperar os tokens, garantindo ao mesmo tempo que a distribuição de recompensas e as deduções de penalidades sejam executadas corretamente. O limite de 1000 DUSK mencionado no ângulo 1 e as recompensas e penalidades mencionadas no ângulo 9 são implementados concretamente por esse contrato. @Dusk

A seção 6.3 acrescenta mais dois "outros contratos". Um deles é o license contract (contrato de licença), que, com base no protocolo Citadel, gerencia a emissão e a verificação de licenças na rede, rastreando a propriedade, a validade e o tempo de expiração de cada licença, além de processar revogações ou renovações. O outro é o Zedger contracts, que instancia contratos inteligentes independentes para cada tipo de ativo mobiliário, oferecendo funções como cunhagem, queima, distribuição de dividendos e transferência forçada; é a implementação concreta do protocolo Zedger mencionado no ângulo 7.

A divisão de trabalho entre os quatro contratos é clara: o transfer contract cuida da circulação, o stake contract da participação no consenso, o license contract das permissões e o Zedger contracts dos ativos. Mas isso também significa que as funções centrais da Dusk dependem fortemente da correção desses quatro contratos — se qualquer um deles apresentar um bug, o impacto não se limita a um único aplicativo, mas afeta as operações básicas de toda a rede. #dusk

A seção 1.1 do Livro Branco "Trabalhos relacionados" na verdade só fez uma coisa: dizer ao leitor que Dusk não é quem quer que seja.

O Livro Branco divide as blockchains existentes em três categorias. A primeira é a de plataformas de contratos inteligentes generalistas, como Ethereum e Cardano; o problema delas é que a transparência não deixa dados financeiros sensíveis para onde se esconder — mesmo com soluções de camada 2 como zk-rollups, isso é apenas um remendo, não um design nativo. A segunda é a de blockchains de privacidade, como Zcash e Monero; nelas, a privacidade individual é levada ao extremo, mas faltam estruturas de conformidade, capacidade de auditoria e contratos inteligentes voltados a transações confidenciais. A terceira é a que a Dusk quer fazer: nenhuma das duas anteriores.

O que o Ethereum consegue fazer, a Dusk@Dusk não faz — ela não busca cobertura total do DeFi generalista, e sim se concentra em cenários financeiros regulamentados. O que Zcash e Monero conseguem fazer, a Dusk também faz — ela usa provas ZK para implementar a privacidade, mas sobre essa base adiciona interfaces de conformidade e capacidade de auditoria. O Livro Branco deixa isso bem claro: Zcash e Monero "falta das funções necessárias para integração com a indústria financeira regulamentada", incluindo quadros de conformidade, auditabilidade e a capacidade de contratos inteligentes para transações confidenciais.$DUSK

Não é uma frase do tipo "Dusk é melhor do que elas", e sim "o nicho escolhido pela Dusk é diferente". Ela escolheu um caminho mais estreito — fazer uma blockchain de privacidade com conformidade para instituições financeiras tradicionais, e não uma blockchain de privacidade para todos. O caminho fica mais estreito, o que significa que o público-alvo é bem definido; ao mesmo tempo, também significa que, se as instituições financeiras tradicionais não comprarem essa ideia, essa proposta não terá sentido.#dusk

Ao chegar ao capítulo 6, notei uma escolha-chave: o ambiente de execução de contratos inteligentes da Dusk é o Piecrust, baseado em WebAssembly, e não compatível com EVM. Em 2024, continuar sem compatibilidade com EVM é uma decisão que precisa ser explicada.$DUSK

O white paper diz que o Piecrust é uma implementação de uma máquina virtual WASM, escrita em Rust. Seu núcleo são dois componentes: a crate piecrust, que é responsável pela própria VM; e a piecrust-uplink, que é um kit de ferramentas de desenvolvimento, fornecendo a toolchain para compilar, implantar e testar contratos. O white paper destaca que o objetivo de design é ser compacto, seguro, modular e leve.

Mas o que realmente despertou meu interesse foi o desenho das host functions. Dusk@Dusk moveu das tarefas de verificação de provas ZK, verificação de assinaturas e cálculo de hash para o ambiente de host. O white paper lista funções host específicas: a função de hash oferece dois algoritmos, Blake2b e Poseidon; verify_plonk e verify_groth16_bn254 verificam, respectivamente, dois tipos de provas ZK, PlonK e Groth16; verify_schnorr e verify_bls verificam assinaturas, suportando tanto assinatura única quanto múltipla. Tudo isso roda no ambiente nativo, e não dentro do sandbox WASM.#dusk

Por que fazer isso? O white paper cita dados de pesquisa dizendo que rodar aplicações complexas em WASM é 45% a 255% mais lento do que em código nativo. Para uma cadeia que usa muitas provas ZK, essa diferença de desempenho é fatal. Se cada transação precisar validar uma prova PlonK dentro do WASM, só esse custo tornaria o atraso das transações inaceitável. Mover a validação para o ambiente de host equivale a contornar o obstáculo.

Mas fazer isso também tem custos. Não ser compatível com EVM significa que contratos inteligentes existentes no Ethereum não podem ser migrados diretamente para a Dusk; os desenvolvedores precisam reaprender a toolchain de desenvolvimento em WASM. A compatibilidade com EVM, na indústria, é um “cartão de segurança”, porque já há muitos desenvolvedores, ferramentas e bases de código. Ao abrir mão desse cartão, a Dusk mostra que tem um posicionamento claro para seu público-alvo — desenvolvedores institucionais voltados para cadeias de valores mobiliários e ativos do mundo real.

A toolchain fornecida pela piecrust-uplink, incluindo compilar contratos em módulos WASM, executá-los em ambientes controlados, e verificar correção e segurança, parece estar tentando compensar uma possível fraqueza na experiência do desenvolvedor. Mas se a toolchain é realmente boa ou não, o white paper não consegue responder; isso só pode ser avaliado depois que os desenvolvedores a usarem na prática.

我读到第5节的时候，发现Dusk在能源效率上做了很多功课，而且给了具体数据，这让我觉得他们确实认真考虑过这个问题。

先看共识层面。白皮书引用了以太坊转PoS后的数据，能耗降低了99.95%以上。但SA共识不只是PoS，它还是委员会制的PoS。白皮书说，确定性分配让区块生成和验证都不需要密集计算，因为谁干活是提前选好的，不是靠算力竞争。委员会只由被选中的那组provisioner参与，而不是全网一起验证，所以整体计算量更小。$DUSK

网络层面，Kadcast的数据更有意思。白皮书说，相比Gossip协议，Kadcast能减少25%到50%的带宽消耗。这不是猜的，是引用了研究数据。而且Kadcast还能降低10%到30%的孤儿块率——就是那些被广播出去但最终没被接受的块。在PoS网络里，少一个孤儿块，就意味着少了一轮白费的投票和验证工作。

加密操作层面，Dusk把ZK证明验证、签名验证、哈希计算这些重活从WASM虚拟机里搬到了宿主环境，用host functions来跑。白皮书引用了研究数据，说在WASM里执行复杂应用比原生代码慢45%到255%。把这个额外开销省掉，对一条大量使用ZK证明的链来说，省下来的计算量是相当可观的。#dusk

不过白皮书也诚实地说，这些能耗节省的具体数字还没有被量化。Kadcast的带宽节省数据来自其他网络，不是Dusk主网实测。这让我觉得他们写白皮书的时候，态度是严谨的，没有为了好看而编数据。

但反过来想，如果Dusk@Dusk 的SA共识真的把验证者数量降到很小的规模，那能耗确实会比以太坊的PoS还要低。以太坊PoS虽然不挖矿了，但全网有几十万验证者，每个人都要跑全节点验证。如果Dusk的验证工作由小规模的委员会来做，那单次验证的能耗确实会少很多。这个逻辑在理论上是成立的，但实际效果，还得等主网上线后拿数据说话。

Ao ler o white paper e chegar ao protocolo Zedger, senti uma espécie de “enfim chegaram”. Depois de tantos preparativos — de privacidade a conformidade, passando pelo modelo de dupla negociação —, o Zedger é a consolidação de todas essas ideias técnicas.$DUSK

O white paper diz que o Zedger é um protocolo para gerenciar valores mobiliários e ativos do mundo real, com suporte para cunhagem, queima, ações corporativas como distribuição de dividendos e, até mesmo, suporte para transferências forçadas. Esses recursos deixam claro que o público-alvo não são investidores individuais, e sim instituições que emitem valores mobiliários.

Eu prestei atenção especial ao recurso de “transferência forçada”. No Ethereum, seus ativos são seus — ninguém pode mexer. Mas, nos mercados financeiros do mundo real, um tribunal pode congelar ativos, o liquidante pode efetuar transferências forçadas e os órgãos reguladores podem exigir a recuperação. Ao embutir esse recurso, o Zedger mostra que a compreensão de conformidade regulatória não fica só no slogan; foi realmente projetada para atender às necessidades das instituições.@Dusk

Mas existe um equilíbrio muito sutil aqui. Se a funcionalidade de transferência forçada for abusada, não será conformidade — será centralização. O white paper diz que o Zedger usa provas ZK e capacidade de auditoria para garantir a legalidade, ao mesmo tempo em que protege a privacidade do usuário. Pelo que entendi, cada transferência forçada deve vir acompanhada de uma prova criptográfica de conformidade, provando que a operação é legal, mas sem necessidade de expor os detalhes da transação.

No entanto, a descrição do white paper sobre o Zedger ainda é relativamente genérica: não explica em detalhes quem detém a autoridade para transferir de forma forçada, como essa autoridade é distribuída e como prevenir o abuso. Se a autoridade ficar apenas com o emissor, então o sistema, na essência, é centralizado. Se a autoridade precisar ser acionada via governança on-chain ou por multisig, a segurança e o grau de descentralização seriam bem maiores.

Eu tenho a tendência de achar que a filosofia de design do Zedger está correta: fornece uma estrutura técnica clara para RWA e valores mobiliários. Mas o nível real de descentralização depende da implementação específica do controle de permissões. O white paper deixa aqui um espaço que vale a pena questionar.#dusk

Quando eu li a parte do consenso SA, a minha primeira reação foi procurar os parâmetros de tempo da finalização. O white paper diz “finalidade em poucos segundos”, mas não especifica exatamente quantos segundos. Essa imprecisão me deixou um pouco desconfortável, mas também me fez querer entender melhor a lógica por trás disso.

Vamos começar comparando. A finalidade do Bitcoin ($DUSK ) depende da probabilidade: com cerca de 6 confirmações de blocos, leva aproximadamente 1 hora. Quanto mais você espera, mais certo fica de que a transação não vai ser revertida. Já no Ethereum, a finalidade do PoS depende do protocolo Casper: são necessários dois epochs, o que equivale a aproximadamente 12,8 minutos. O Dusk diz que é só “alguns segundos” — mas por quê?

O ponto-chave está no seu mecanismo determinístico de alocação. O white paper afirma que, antes de cada rodada começar, o algoritmo DS já selecionou antecipadamente quem será o gerador de blocos e quem fará parte do comitê de votação. Esse “conhecimento prévio” significa que os votantes já estão preparados antes mesmo de o bloco ser gerado; não é preciso chamar alguém às pressas nem fazer o broadcast de toda a rede para chegar a um consenso. Assim, o custo de comunicação é bastante reduzido.

Eu desmontei o processo. Cada rodada inclui várias iterações, e cada iteração tem três fases: proposta, votação e confirmação. O comitê de votação é composto apenas pelos validadores selecionados, não por toda a rede ao mesmo tempo. A quantidade de nós que participa da votação é controlada dentro de uma faixa relativamente pequena, então o volume de comunicação do processo de votação é bem baixo; em poucas trocas de informação, @Dusk

Mas há um ponto que eu ainda não entendi. O white paper menciona “finalidade contínua/rolante” (rolling finality), mas não detalha o mecanismo. A minha interpretação é que isso pode significar que a finalidade não é travada de uma vez; em vez disso, conforme novos blocos vão sendo gerados, a probabilidade de que os blocos anteriores sejam finais vai aumentando gradualmente. Se for assim, “alguns segundos” poderia se referir à confirmação da primeira camada, e não à irreversibilidade final. #dusk

Além disso, notei que o white paper não fornece o número exato de segundos. “3 segundos” e “9 segundos” ambos são chamados de “alguns segundos”, mas no contexto financeiro a diferença é enorme. Eu ainda não consigo encontrar a resposta para essa questão diretamente no white paper; talvez seja necessário esperar pelos dados de testes reais após o lançamento da mainnet.

Quando eu lia o whitepaper, essa questão ficava girando na minha cabeça o tempo todo. A maior narrativa da Dusk é querer tudo: privacidade e conformidade — mas a experiência histórica me diz que, normalmente, esse tipo de promessa agrada a ninguém dos dois lados. #dusk

Vamos olhar para o lado oposto. Zcash e Monero levaram a privacidade ao extremo, mas os órgãos reguladores não aceitaram: as exchanges removeram os ativos, e a liquidez encolheu. Ethereum e Bitcoin não têm problema com conformidade, mas as transações são totalmente transparentes — instituições fazem uma transação grande, e o contraparte consegue ver tudo com clareza. A Dusk diz que encontrou uma terceira via, e eu desconfiei no começo. @Dusk

A proposta do whitepaper é um modelo de dupla transação com o protocolo Zedger. Moonlight é para cenários de conformidade, Phoenix para cenários de privacidade, e o Zedger garante que contratos inteligentes sejam executados em estado confidencial, mantendo ao mesmo tempo auditabilidade. Em teoria, essa arquitetura realmente poderia funcionar.

Mas, depois de terminar a leitura, identifiquei uma lacuna crucial. O whitepaper diz que os órgãos reguladores podem acessar os dados necessários, mas não explica como: por qual mecanismo eles são autorizados, quem gerencia as chaves, como as permissões são revogadas — não detalha nada disso. Numa privacidade auditável, o mais difícil não é fazer com que o regulador veja os dados, e sim garantir que apenas as pessoas autorizadas vejam os dados, e apenas durante o período de tempo autorizado.

Tentei raciocinar por esse ângulo. Se a Dusk usar um sistema de prova semelhante a zk-SNARK, com o regulador mantendo uma chave específica de auditoria, então $DUSK poderia verificar a conformidade da transação sem expor a privacidade do usuário — nesse caso, o esquema se sustentaria. Mas se a autoridade regulatória for abusada, ou se a chave vazar, o edifício da proteção de privacidade desaba.

Então minha conclusão é: a ideia de coexistência entre privacidade e conformidade faz sentido em princípio e, em termos de engenharia, também pode ser alcançada, mas o resultado real depende totalmente dos detalhes do desenho do mecanismo de controle de permissões. E como o whitepaper ainda não traz esses detalhes, só posso esperar que mais documentação técnica seja publicada para então avaliar. A resposta para essa questão não está no whitepaper — está no código da mainnet.

Quando li esta parte do Kadcast, fiquei o tempo todo comparando com o protocolo de gossip do Ethereum. A lógica do gossip é bem simples: você recebe uma mensagem e a encaminha para todos os vizinhos que você conhece; os vizinhos, por sua vez, encaminham para os vizinhos deles, até que toda a rede receba. Mas existe um problema: à medida que o número de nós cresce, a quantidade de reencaminhamentos repetidos aumenta de forma exponencial.

O Kadcast faz diferente. Ele se baseia em uma DHT do Kademlia e organiza os nós em camadas conforme a distância XOR. Em vez de encaminhar para todos os vizinhos, cada nó encaminha apenas para um conjunto selecionado de nós com distância XOR crescente. Eu li esse mecanismo duas vezes para entender o quão engenhoso ele é — ele cria um efeito cascata, e não uma inundação (flooding).

Por exemplo: o nó A envia uma mensagem, e ela só é encaminhada para alguns nós que estão mais próximos; esses nós encaminham para nós mais distantes. A quantidade de nós-alvo em cada camada é controlada, não é uma difusão sem limites. No whitepaper, eles dizem que isso reduz significativamente o número total de transmissões necessárias para a propagação na rede.

Então, qual é a relação desse design com o cenário financeiro $DUSK ? Pelo meu entendimento, o cenário financeiro é especialmente sensível a duas coisas: um é a latência e o outro é a largura de banda. Se uma transmissão de transação precisa de dezenas de segundos, ou até quinze segundos, para se espalhar por toda a rede, a finalização em nível de segundos não tem muito sentido. O Kadcast comprime ao máximo o tempo de propagação ao fazer a mensagem chegar a todos os nós com o menor número possível de reencaminhamentos, usando uma estrutura em árvore.

Há também um ponto que eu não tinha notado no começo: o whitepaper afirma que o Kadcast naturalmente confunde a origem da mensagem. Como os nós só se comunicam com pares selecionados e não fazem broadcasting para toda a rede, fica mais difícil para um atacante rastrear de qual nó uma transação se originou. Isso é um extra para a narrativa de privacidade do Dusk@Dusk .

Mas ainda tenho uma dúvida. O whitepaper compara gossip e Kadcast, porém só fornece uma descrição qualitativa, sem dados específicos sobre economia de largura de banda. Quanto foi economizado — 30% ou 90%? Sem esses dados, eu realmente não consigo avaliar o quanto a vantagem de eficiência é grande. Talvez essa ordem de grandeza precise ser respondida com dados reais de rede após o lançamento na mainnet. #dusk

Minha primeira reação ao ler o consenso SA foi: como é que o número 1000 DUSK foi definido. O whitepaper só mostra o resultado, não traz o processo de dedução. Então eu fui ao encontro dos seus parâmetros para chegar ao ponto de trás.

Ele define um epoch de 2160 blocos. Pelo ritmo atual de produção de blocos da Dusk, isso dá aproximadamente 6 horas por epoch. Depois, ele fornece uma fórmula de maturidade: M = 2 × epoch - (height mod epoch). Ou seja, se você fizer um staking de uma quantia em DUSK, precisa esperar algo próximo de meio epoch até completar um epoch inteiro para só então começar a trabalhar de verdade.

O interessante desse desenho é que ele alinha o tempo de efetivação de todo novo staking ao limite do epoch. Não é “vale assim que cair”, e sim que o grupo ativa em um mesmo ponto de início. Acho que o objetivo é fazer com que o algoritmo de sorteio determinístico do protocolo DS tenha um snapshot estável de um pool de stake. Se alguém pudesse entrar a qualquer momento, e a efetividade começasse imediatamente, o conjunto de candidatos a provisioner de cada bloco mudaria. Aí a alocação determinística fica difícil de realizar.

$DUSK

E quanto aos próprios 1000 DUSK? Eu calculei: se o limiar (threshold) fosse 100, a quantidade de provisioners iria explodir. A concorrência entre os 64 slots por epoch ficaria mais intensa. Porém, o volume de staking por nó seria muito baixo, e a segurança da rede poderia ser diluída. Se fosse 10000, a maioria dos pequenos investidores quase não entraria; os provisioners virariam um “jogo” dominado por poucos nós grandes, e a descentralização perde força.

@Dusk

Então esse número 1000 fica justamente no meio. Eu conferi os parâmetros de outras cadeias PoS: o limiar da Dusk não parece especialmente alto, mas também não é baixo. É como se estivesse dizendo: “não quero que você venha rodar um nó com qualquer troco; mas também não quero que você precise necessariamente ser um grande detentor para participar”.

#dusk

Mas ainda assim tenho uma questão que não ficou totalmente clara. O whitepaper não define uma faixa de meta para o número total de provisioners, nem diz em que proporção a disputa entre os 64 slots deve ficar para ser o melhor cenário. Sem esses dados, eu não consigo realmente avaliar se 1000 é um valor correto. Talvez a sua racionalidade só possa ser verificada com dados reais após o lançamento na mainnet.