Eu costumava pensar que um limite de época em Dusk era, na maior parte, um evento de sincronização — uma época termina, outra começa.
Observando mais de perto, acho que esse enquadramento ignora uma restrição importante de sistemas.
Uma época muda o estado a partir do qual a elegibilidade do provedor é avaliada, enquanto o consenso ainda precisa operar dentro de uma quantidade limitada de computação. Isso faz com que o limite seja mais do que um marcador de calendário: é um ponto em que o estado de participação pode mudar sem permitir que o trabalho de consenso cresça indefinidamente.
A cadeia de engenharia que acho interessante é:
erupção de época → o estado de elegibilidade muda → o consenso avalia o novo estado → a computação permanece limitada.
Isso cria um equilíbrio sutil.
Se mudanças de stake ou de elegibilidade fossem permitidas afetar o consenso imediatamente e sem limites claros, os nós poderiam enfrentar transições de estado mais complexas. Se as mudanças forem restringidas por condições de época, o protocolo ganha um modelo de estado mais limpo, mas as mudanças de participação se tornam menos instantâneas.
O que me surpreendeu é que a segmentação do tempo e os limites computacionais podem resolver problemas diferentes enquanto se reforçam mutuamente.
Uma época responde quando o estado do consenso pode mudar.
Um processo de iteração limitado responde quanto trabalho o consenso está autorizado a realizar.
A questão em aberto é: à medida que o conjunto de provedores de uma rede muda com mais rapidez, como o comprimento da época deve equilibrar estabilidade de estado com responsividade?
@Dusk_Foundation $DUSK #dusk
Observando mais de perto, acho que esse enquadramento ignora uma restrição importante de sistemas.
Uma época muda o estado a partir do qual a elegibilidade do provedor é avaliada, enquanto o consenso ainda precisa operar dentro de uma quantidade limitada de computação. Isso faz com que o limite seja mais do que um marcador de calendário: é um ponto em que o estado de participação pode mudar sem permitir que o trabalho de consenso cresça indefinidamente.
A cadeia de engenharia que acho interessante é:
erupção de época → o estado de elegibilidade muda → o consenso avalia o novo estado → a computação permanece limitada.
Isso cria um equilíbrio sutil.
Se mudanças de stake ou de elegibilidade fossem permitidas afetar o consenso imediatamente e sem limites claros, os nós poderiam enfrentar transições de estado mais complexas. Se as mudanças forem restringidas por condições de época, o protocolo ganha um modelo de estado mais limpo, mas as mudanças de participação se tornam menos instantâneas.
O que me surpreendeu é que a segmentação do tempo e os limites computacionais podem resolver problemas diferentes enquanto se reforçam mutuamente.
Uma época responde quando o estado do consenso pode mudar.
Um processo de iteração limitado responde quanto trabalho o consenso está autorizado a realizar.
A questão em aberto é: à medida que o conjunto de provedores de uma rede muda com mais rapidez, como o comprimento da época deve equilibrar estabilidade de estado com responsividade?
@Dusk_Foundation $DUSK #dusk