Colin fez uma nova proposta para alterar o processo das eleições na rede Nano, baseando-se nas discussões de Time-as-a-Currency ...
Colin fez uma nova proposta para alterar o processo das eleições na rede Nano, baseando-se nas discussões de Time-as-a-Currency (TaaC) e Proof of Stake for Quality of Service (PoS4QoS, ou P4Q).
Segue tradução:
__
Cronograma eleitoral e reforma de priorização
Eu adicionei um ramo: GitHub - nanocurrency/nano-node at election_scheduler 11, que é o início de um componente de agendador eleitoral que substituirá a forma como as eleições são iniciadas atualmente. Isso permitirá uma separação entre a decisão de quais eleições priorizar e a mecânica das eleições. Encapsular a priorização dessa forma facilita o processo de decisão de agendamento porque o site que solicita o início da eleição não precisa avaliar todas as outras considerações de agendamento.
As eleições são iniciadas no node pelas seguintes fontes:
- Blocos ao vivo fora da rede
- Dependentes confirmados - quando o bloco anterior, e em receber o bloco de envio no campo de link, são confirmados, o sucessor desse bloco anterior pode ser ativado se já estiver na ledger
- Maior dificuldade de bloqueio de reagendamento - quando trabalhos mais altos são publicados para um bloco existente e não confirmado na ledger que ainda não tem uma eleição
- Observação do voto sugerido - quando um % do peso de voto é visto para um bloco não confirmado na ledger que ainda não tem uma eleição
- Quando solicitado através do comando RPC block_confirm
Com o novo componente do programador em vigor, todas essas fontes alimentarão uma lista central de eleições elegíveis para que sua priorização possa ser mais precisamente comparada em todas as eleições. O objetivo desta abordagem é fornecer um melhor controle sobre quais eleições estão sendo iniciadas para que um gatilho em particular não domine os recursos. O resultado final deve ser um melhor alinhamento eleitoral em toda a rede.
Este ramo também contém o início de um cronograma de priorização eleitoral que iniciará as eleições com base em uma combinação do saldo da conta e na última vez que a conta teve atividade. A separação de contas em níveis de saldo impede o agendamento de fome de qualquer nível por qualquer outro nível.
A base para este projeto é a partir das propostas TaaC e PoS4QoS por @Rob com algumas modificações para suportar horários maleáveis e não confiáveis. Embora os cronogramas assinados deem mais rigor matemático ao algoritmo de agendamento, isso exigiria a alteração do conteúdo do bloco assinado, coordenando upgrades de rede, e levaria vários meses ou mais para implementar o que não se encaixa com as necessidades táticas atuais.
O programador iniciará as eleições para as contas de maior prioridade em cada nível de saldo de forma redonda e a prioridade dentro de cada nível é a ordem menos usada recentemente para a respectiva conta. Haverá 128 níveis de equilíbrio, um para cada bit no campo de equilíbrio, e os 0s principais no saldo determinarão o balde.
O novo programador considerará o seguinte:
- Contas agendadas prioritárias
- Dependentes confirmados
- Observação de votos sugerindo
- Quando solicitado através de block_confirm
- Resolução de fork - Esta separação permite que forks sejam separados de forma limpa em seu próprio nível de baixa prioridade.
Note-se que o novo esquema prioritário tem o potencial de remover os requisitos de PoW em grande ou inteiramente. Isso tornará as integrações da Nano muito mais simples do que são atualmente e diferencia a nano de todos os outros sistemas que veem as taxas como a única solução para o projeto de agendamento.
Como lembrete, este é um tema de discussão focado. Se o seu post for marcado como fora do tópico, por favor, certifique-se de que é específico e de natureza técnica para este design.
Link:
https://ift.tt/39kCKXX
(Feed generated with FetchRSS) Via ⋰·⋰ https://ift.tt/38G5s5h
Segue tradução:
__
Cronograma eleitoral e reforma de priorização
Eu adicionei um ramo: GitHub - nanocurrency/nano-node at election_scheduler 11, que é o início de um componente de agendador eleitoral que substituirá a forma como as eleições são iniciadas atualmente. Isso permitirá uma separação entre a decisão de quais eleições priorizar e a mecânica das eleições. Encapsular a priorização dessa forma facilita o processo de decisão de agendamento porque o site que solicita o início da eleição não precisa avaliar todas as outras considerações de agendamento.
As eleições são iniciadas no node pelas seguintes fontes:
- Blocos ao vivo fora da rede
- Dependentes confirmados - quando o bloco anterior, e em receber o bloco de envio no campo de link, são confirmados, o sucessor desse bloco anterior pode ser ativado se já estiver na ledger
- Maior dificuldade de bloqueio de reagendamento - quando trabalhos mais altos são publicados para um bloco existente e não confirmado na ledger que ainda não tem uma eleição
- Observação do voto sugerido - quando um % do peso de voto é visto para um bloco não confirmado na ledger que ainda não tem uma eleição
- Quando solicitado através do comando RPC block_confirm
Com o novo componente do programador em vigor, todas essas fontes alimentarão uma lista central de eleições elegíveis para que sua priorização possa ser mais precisamente comparada em todas as eleições. O objetivo desta abordagem é fornecer um melhor controle sobre quais eleições estão sendo iniciadas para que um gatilho em particular não domine os recursos. O resultado final deve ser um melhor alinhamento eleitoral em toda a rede.
Este ramo também contém o início de um cronograma de priorização eleitoral que iniciará as eleições com base em uma combinação do saldo da conta e na última vez que a conta teve atividade. A separação de contas em níveis de saldo impede o agendamento de fome de qualquer nível por qualquer outro nível.
A base para este projeto é a partir das propostas TaaC e PoS4QoS por @Rob com algumas modificações para suportar horários maleáveis e não confiáveis. Embora os cronogramas assinados deem mais rigor matemático ao algoritmo de agendamento, isso exigiria a alteração do conteúdo do bloco assinado, coordenando upgrades de rede, e levaria vários meses ou mais para implementar o que não se encaixa com as necessidades táticas atuais.
O programador iniciará as eleições para as contas de maior prioridade em cada nível de saldo de forma redonda e a prioridade dentro de cada nível é a ordem menos usada recentemente para a respectiva conta. Haverá 128 níveis de equilíbrio, um para cada bit no campo de equilíbrio, e os 0s principais no saldo determinarão o balde.
O novo programador considerará o seguinte:
- Contas agendadas prioritárias
- Dependentes confirmados
- Observação de votos sugerindo
- Quando solicitado através de block_confirm
- Resolução de fork - Esta separação permite que forks sejam separados de forma limpa em seu próprio nível de baixa prioridade.
Note-se que o novo esquema prioritário tem o potencial de remover os requisitos de PoW em grande ou inteiramente. Isso tornará as integrações da Nano muito mais simples do que são atualmente e diferencia a nano de todos os outros sistemas que veem as taxas como a única solução para o projeto de agendamento.
Como lembrete, este é um tema de discussão focado. Se o seu post for marcado como fora do tópico, por favor, certifique-se de que é específico e de natureza técnica para este design.
Link:
https://ift.tt/39kCKXX
(Feed generated with FetchRSS) Via ⋰·⋰ https://ift.tt/38G5s5h
Comentários
Postar um comentário