Eu comecei achando que um snapshot era só um pacote compactado: você empacota o estado do nó, e outra pessoa baixa, descompacta e pronto. Mas o jeito que a Dusk faz é completamente diferente.
O mecanismo central é o “snapshot assinado”. O snapshot em si é imutável, mas as tags (por exemplo, latest, daily) são variáveis. O bucket de armazenamento, o endpoint HTTP e o diretório local são apenas canais de transmissão; não são a raiz da confiança. O cliente é quem decide em quais fontes configuradas e em quais chaves de assinatura Ed25519 confiar.
Eu li essa frase duas vezes até entender o que ela queria dizer. Na primeira leitura, parecia não haver nada de especial. Mas depois que fechei a página, quanto mais eu pensava, mais estranho ficava: sem uma chave pública codificada no código, como a plataforma garante que o usuário baixou um snapshot realmente oficial? Foi só relendo com cuidado que percebi: a oficial é apenas “configurável como fonte”, não “confiada por padrão”.
A maioria das ferramentas de snapshot é “baixe e use”; por padrão, elas confiam no publicador. O design da Dusk é: a ferramenta em si não confia em ninguém; você decide em quem confiar as assinaturas. Você quer usar um snapshot oficial? Configure a chave pública oficial. Você quer usar seus próprios snapshots? Use suas próprias chaves para assiná-los. Nenhum nome de bucket, endpoint ou chave pública da Dusk é codificado de forma rígida no código.
Outro ponto em que senti que o design é bem cuidadoso é no tratamento do tempo de parada. No modo stopped-pack, o Rusk só para pelo tempo suficiente para criar um snapshot local verificado. O procedimento é: durante a parada, fazer apenas uma coisa — gerar o snapshot local. Upload, publicação e reconstrução de índices só acontecem depois que o nó reinicia. A janela de parada não tem relação com a velocidade da rede; só depende de E/S do disco local.
Os comandos suportados no v0.1.0, do empacotamento à validação, publicação e recuperação, são: pack, verify, publish, promote, list, restore, gc, rebuild-index, além do fluxo de orquestração com plan, watch e capture.
Depois de terminar a leitura da documentação, minha maior percepção é: essa ferramenta resolve não apenas “como fazer backup de um nó”, mas “como fazer backup e recuperação de nós sem confiar em ninguém”. Snapshot assinado + escolha autônoma das fontes de confiança pelo cliente — esse tipo de design vai muito além de simplesmente fornecer um link de download; e também se aproxima muito da lógica subjacente da “privacidade em conformidade” da Dusk — não depende de confiança; depende de verificação. #dusk $DUSK @Dusk
O mecanismo central é o “snapshot assinado”. O snapshot em si é imutável, mas as tags (por exemplo, latest, daily) são variáveis. O bucket de armazenamento, o endpoint HTTP e o diretório local são apenas canais de transmissão; não são a raiz da confiança. O cliente é quem decide em quais fontes configuradas e em quais chaves de assinatura Ed25519 confiar.
Eu li essa frase duas vezes até entender o que ela queria dizer. Na primeira leitura, parecia não haver nada de especial. Mas depois que fechei a página, quanto mais eu pensava, mais estranho ficava: sem uma chave pública codificada no código, como a plataforma garante que o usuário baixou um snapshot realmente oficial? Foi só relendo com cuidado que percebi: a oficial é apenas “configurável como fonte”, não “confiada por padrão”.
A maioria das ferramentas de snapshot é “baixe e use”; por padrão, elas confiam no publicador. O design da Dusk é: a ferramenta em si não confia em ninguém; você decide em quem confiar as assinaturas. Você quer usar um snapshot oficial? Configure a chave pública oficial. Você quer usar seus próprios snapshots? Use suas próprias chaves para assiná-los. Nenhum nome de bucket, endpoint ou chave pública da Dusk é codificado de forma rígida no código.
Outro ponto em que senti que o design é bem cuidadoso é no tratamento do tempo de parada. No modo stopped-pack, o Rusk só para pelo tempo suficiente para criar um snapshot local verificado. O procedimento é: durante a parada, fazer apenas uma coisa — gerar o snapshot local. Upload, publicação e reconstrução de índices só acontecem depois que o nó reinicia. A janela de parada não tem relação com a velocidade da rede; só depende de E/S do disco local.
Os comandos suportados no v0.1.0, do empacotamento à validação, publicação e recuperação, são: pack, verify, publish, promote, list, restore, gc, rebuild-index, além do fluxo de orquestração com plan, watch e capture.
Depois de terminar a leitura da documentação, minha maior percepção é: essa ferramenta resolve não apenas “como fazer backup de um nó”, mas “como fazer backup e recuperação de nós sem confiar em ninguém”. Snapshot assinado + escolha autônoma das fontes de confiança pelo cliente — esse tipo de design vai muito além de simplesmente fornecer um link de download; e também se aproxima muito da lógica subjacente da “privacidade em conformidade” da Dusk — não depende de confiança; depende de verificação. #dusk $DUSK @Dusk