@Dusk_Foundation A Distância de Recuperação que Eu Realmente Acompanho em um Nó DUSK
Às 03:17, o nó voltou à caixa, mas ainda estava longe de ser útil. O Rusk foi instalado, a configuração estava onde eu esperava, e as chaves não foram tocadas. A parte irritante foi o estado. A rede continuou avançando enquanto esta máquina não avançava.
É aí que o fast-sync do DUSK se torna interessante para mim. Não porque ele faça com que blocos antigos desapareçam. Ele faz algo mais prático: substitui o estado local do Rusk e o banco de dados da cadeia por um estado publicado e, em seguida, deixa o nó continuar dali em direção ao topo ao vivo.
Comecei a pensar na lacuna como distância de recuperação. Se o snapshot está na altura S e a rede já está em T, então T menos S é o trabalho que ainda está à frente do nó. Um snapshot mais recente pode reduzir essa distância, mas não remove o restante do caminho de recuperação. Baixar é um relógio. Reiniciar, encontrar pares, avançar a altura e verificar que ele continua avançando são outros.
Há também uma aresta/limite estranho aqui. O fast-sync não recria índices de arquivo (archive indexes) anteriores ao snapshot, então “recuperado” significa coisas diferentes para um nó comum e para um serviço de arquivo.
O que eu quero observar em seguida não é o tamanho do snapshot. É como a distância de recuperação se comporta durante uma falha bagunçada, quando a rede continua em movimento enquanto o operador ainda está consertando as coisas.#dusk $DUSK
Às 03:17, o nó voltou à caixa, mas ainda estava longe de ser útil. O Rusk foi instalado, a configuração estava onde eu esperava, e as chaves não foram tocadas. A parte irritante foi o estado. A rede continuou avançando enquanto esta máquina não avançava.
É aí que o fast-sync do DUSK se torna interessante para mim. Não porque ele faça com que blocos antigos desapareçam. Ele faz algo mais prático: substitui o estado local do Rusk e o banco de dados da cadeia por um estado publicado e, em seguida, deixa o nó continuar dali em direção ao topo ao vivo.
Comecei a pensar na lacuna como distância de recuperação. Se o snapshot está na altura S e a rede já está em T, então T menos S é o trabalho que ainda está à frente do nó. Um snapshot mais recente pode reduzir essa distância, mas não remove o restante do caminho de recuperação. Baixar é um relógio. Reiniciar, encontrar pares, avançar a altura e verificar que ele continua avançando são outros.
Há também uma aresta/limite estranho aqui. O fast-sync não recria índices de arquivo (archive indexes) anteriores ao snapshot, então “recuperado” significa coisas diferentes para um nó comum e para um serviço de arquivo.
O que eu quero observar em seguida não é o tamanho do snapshot. É como a distância de recuperação se comporta durante uma falha bagunçada, quando a rede continua em movimento enquanto o operador ainda está consertando as coisas.#dusk $DUSK