O elevador do condomínio vive apresentando falhas. No grupo de moradores, alguém publicou um plano de reforma. No começo eu achava que, como havia muita gente votando, já dava para começar; depois percebi que ainda era necessário fazer cotações, avaliação, testes de obra e aceitação. A governança on-chain também pode ser fácil de ser entendida de forma apressada: uma proposta é publicada, o que apenas indica que a discussão ganhou um meio formal; o código da mainnet não muda automaticamente em seguida.
Dusk organiza as alterações de protocolo em DIP, ou seja, Dusk Improvement Proposal. O fluxo oficial começa com o Idea; quando a ideia toma forma, entra em Draft e recebe um número; em seguida, ao produzir um protótipo ou uma conquista técnica, vai para Feedback. Quando está perto de ser finalizado, passa para Staging. DIPs que envolvem código são primeiro colocados na testnet Nocturne; só depois de obter consenso é marcada como Active, e os resultados são incorporados ao ambiente de produção.#dusk
Gosto de um ponto desse conjunto de processos: mudanças no protocolo DUSK precisam deixar um registro completo. A proposta deve descrever motivação, especificações técnicas, trade-offs, compatibilidade com versões anteriores, testes, impactos de segurança e links de implementação. Uma proposta Stagnant que não tenha continuidade de desenvolvimento por meio ano ainda pode entrar em Dead. Mais tarde, ao revisitar uma atualização, a comunidade consegue rastrear quais riscos tinham sido discutidos na época, e não apenas ver anúncios de uma nova versão.
Mas “qualquer pessoa pode enviar” não permite concluir diretamente que “qualquer pessoa pode mudar as regras”. Editores de DIP participam da revisão, da numeração, da mesclagem e do acompanhamento da implementação; operadores de nós também precisam instalar o software que inclui a alteração. As explicações públicas atuais não trazem um conjunto de critérios de aprovação calculados por $DUSK de saldo, nem definem o “obter consenso” como um percentual claro. Eu não vou “embalar” uma discussão aberta como se a governança on-chain já estivesse concluída.
Ao acompanhar a atualização de @Dusk , vou checar separadamente quatro coisas: em que estado está o DIP, se o código de implementação é público, se os resultados da testnet Nocturne podem ser verificados novamente e quando a mainnet passa a adotar a mudança. Curtidas no grupo só indicam que a ideia é bem recebida; somente Active e implantação real mostram em que etapa o regulamento Dusk chegou.
Dusk organiza as alterações de protocolo em DIP, ou seja, Dusk Improvement Proposal. O fluxo oficial começa com o Idea; quando a ideia toma forma, entra em Draft e recebe um número; em seguida, ao produzir um protótipo ou uma conquista técnica, vai para Feedback. Quando está perto de ser finalizado, passa para Staging. DIPs que envolvem código são primeiro colocados na testnet Nocturne; só depois de obter consenso é marcada como Active, e os resultados são incorporados ao ambiente de produção.#dusk
Gosto de um ponto desse conjunto de processos: mudanças no protocolo DUSK precisam deixar um registro completo. A proposta deve descrever motivação, especificações técnicas, trade-offs, compatibilidade com versões anteriores, testes, impactos de segurança e links de implementação. Uma proposta Stagnant que não tenha continuidade de desenvolvimento por meio ano ainda pode entrar em Dead. Mais tarde, ao revisitar uma atualização, a comunidade consegue rastrear quais riscos tinham sido discutidos na época, e não apenas ver anúncios de uma nova versão.
Mas “qualquer pessoa pode enviar” não permite concluir diretamente que “qualquer pessoa pode mudar as regras”. Editores de DIP participam da revisão, da numeração, da mesclagem e do acompanhamento da implementação; operadores de nós também precisam instalar o software que inclui a alteração. As explicações públicas atuais não trazem um conjunto de critérios de aprovação calculados por $DUSK de saldo, nem definem o “obter consenso” como um percentual claro. Eu não vou “embalar” uma discussão aberta como se a governança on-chain já estivesse concluída.
Ao acompanhar a atualização de @Dusk , vou checar separadamente quatro coisas: em que estado está o DIP, se o código de implementação é público, se os resultados da testnet Nocturne podem ser verificados novamente e quando a mainnet passa a adotar a mudança. Curtidas no grupo só indicam que a ideia é bem recebida; somente Active e implantação real mostram em que etapa o regulamento Dusk chegou.
