Com a V22 basicamente lançada, vale a pena destacar o que de fato irá acontecer com a rede, e o que está nos planos para futuras...
Com a V22 basicamente lançada, vale a pena destacar o que de fato irá acontecer com a rede, e o que está nos planos para futuras atualizações como a V23.
Destacando o resumo do Edgar Peixoto para a turma apressada:
"Resumindo, será removido o incentivo para fazer spam na rede, pois transações legítimas terão prioridade. Caso queira prejudicar a rede o spammer terá que gastar MUITO dinheiro.
Essa solução não é a perfeita, a ideal ou a melhor conhecida mas é boa o bastante para ser lançada o mais breve possível.
A v23 trará ainda mais melhorias que vai exigir mudanças na estrutura dos blocos (a principal razão pela qual essa mudança não vai estar presente na v22)."
Bônus: As transações legítimas que estão "emperradas" serão priorizadas e, provavelmente, confirmadas logo.
________
Versão completa:
Após as últimas semanas de problemas de rede, a comunidade está dividida entre "v22 vai corrigir spam!" por um lado, e outros com algum FUD sobre "v22 não vai corrigir spam!".
É algo meio "cinza" o momento que nos encontramos entre essas declarações, e é um pouco mais complicado, mas vamos em busca de uma explicação em uma espécie de ELI10 (ou 15).
O spam na rede da Nano tem muitas consequências e problemas, os maiss importantes:
- Problemas com o envio de transações. Isso afeta todos nós usuários, e também as exchanges.
- "Ledger bloat" - transações inúteis aumentam o banco de dados de transações nos nodes e aumentam o custo de execução dos nodes.
- Rede dessincronizada, porque os nodes leves não conseguem acompanhar os mais fortes, na largura de banda, memória e/ou cpu.
O principal culpado desses problemas no v21.3 (antecessor do v22), é que os nodes não estavam em qualquer sincronia sob spam pesado, sobre quais blocos deveriam estar votando na rede para confirmar. Isso aumentou a comunicação de rede e reduziu o CPS (confirmações por segundo). As transações foram votadas em ordem de chegada, e como o spammer tinha um monte de transações de poeira (dust), transações legítimas não poderiam realmente ser confirmadas.
Que solução traz o V22?
Em suma, ele remove o incentivo para spam da rede, porque sob "spam de baixo custo" transações legítimas têm prioridade, e para interromper a rede de qualquer forma significativa, o spammer perderia muito dinheiro.
A solução não é perfeita ou ideal, ou mesmo a melhor solução conhecida atualmente. Mas é bom o suficiente para ser liberada o mais rápido possível.
A próxima versão, v23, trará recursos ainda melhores, dos quais a maioria exige mudança de estrutura de bloco (a principal razão pela qual eles não estão em v22). E talvez tenhamos um v22.1 com alguns ajustes.
Detalhes:
Os blocos de entrada (transações), válidos/verificados, são alocados em 129 baldes, por saldo da conta após a transação https://ift.tt/3tOgL3b
Um bloco válido, tem que ter um bloco anterior confirmado. Portanto, se a conta enviar 2 blocos, sem esperar pela confirmação, o bloco 2 não é válido, até que o bloco 1 seja confirmado. E só depois disso, o bloco 2 é adicionado ao balde/fila.
Cada balde tem classificação separada, por account.modified_at (LRU - Menos Recentemente Usado). Assim, as contas, que não foram usadas recentemente, têm maior prioridade. Como a maioria dos usuários não envia transações a cada segundo, eles terão quase sempre prioridade sobre spam.
Confirmações globais de blocos - "eleições", ou seja, comunicação entre nós que blocos serão confirmados, acontece em Contêiner Eleitoral Ativo (AEC).
Os melhores blocos por prioridade, são escolhidos igualmente entre todos os baldes, até que o AEC esteja cheio. No lançamento do v22, o AEC deve ser de 50000 blocos grandes.
O AEC e a classificação prioritária garantem (principalmente), que todos os nodes estejam votando nos mesmos blocos, o que aumenta o CPS, e reduz a largura de banda necessária.
Se um bloco não for confirmado pela rede até 5 minutos (nodes não estão votando no mesmo bloco), ele é removido do AEC e colocado de volta ao balde.
Então isso foi um monte de coisas técnicas abstratas. Agora vamos rever algumas situações de exemplo.
1. um spam de conta com 1 nano, enviando milhares de 1 transações de 1 raw.
Como o bloco não pode ser votado antes que seu bloco anterior (pai) seja confirmado, esse spam só aumentará o tráfego da rede, mas não afetará os usuários em nenhum balde. PoW necessário para enviar o bloco, vai diminuir o envio e aumentar o custo para spammer.
2. milhares de 1 nano contas, enviando 1 transações de 1 raw.
Como o AEC armazenará 50000 blocos, e as confirmações são rápidas, o spammer teria que ter mais de 50000 contas paralelas, para encher seu balde e o AEC.
Isso atrasaria as confirmações naquele balde, mas transações legítimas nesse mesmo balde, teriam prioridade sobre o spam (LRU). Isso resultaria em aumento do tempo de confirmação naquele balde para segundos (em vez de frações de segundo). No pior caso possível, algo mais de 10 minutos, porque são 5 minutos de tempo limite para abrir espaço para o bloqueio de envio, e 5 minutos de intervalo para o bloco de recebimento, além de alguma rede diminuir a velocidade.
Custo para spammer - 50000+ nanos bloqueados em contas, e PoW. E isso só para spam um balde. E talvez um pouco mais lento outras transações, por causa do uso de CPU ou rede.
O que acontece com as transações de espera atuais?
A classificação prioritária da LRU e os baldes serão aplicados também em transações antigas,e como as transações legítimas terão melhor prioridade via LRU, e estarão em baldes diferentes do que as transações dos spammers, e devem começar a confirmar mais rapidamente. As transações de spam serão lentamente confirmadas com CPS mais baixos.
E depois da V22? (provavelmente algumas dessas características, talvez algumas novas)
"Backlog de bloco limitado (Bounded Block Backlog - BBB)" - isso ajuda diretamente com o inchaço da ledger e a capacidade da rede. Simplificando - se o spammer enviar muitas transações, elas são descartadas.
"Remoção de baldes" - Colin quer escrever uma única função prioritária, que seria ainda melhor classificar blocos e ajudar a sincronizar nódulos.
"Remoção do PoW" - PoW não é mais usado para prioridade, por isso há discussões se e como removê-lo.
"Timestamps assinados" - isso aumentaria ainda mais a prioridade das transações legítimas.
"Ledger Pruning" - na v22 a poda é experimental. Espera-se que a mesma seja considerada estável para a próxima versão, o que ajudará na adoção e integrações.
E muitos mais.
Via Reddit:
https://ift.tt/33KLdAz
(Feed generated with FetchRSS) Via ⋰·⋰ https://ift.tt/38G5s5h
Destacando o resumo do Edgar Peixoto para a turma apressada:
"Resumindo, será removido o incentivo para fazer spam na rede, pois transações legítimas terão prioridade. Caso queira prejudicar a rede o spammer terá que gastar MUITO dinheiro.
Essa solução não é a perfeita, a ideal ou a melhor conhecida mas é boa o bastante para ser lançada o mais breve possível.
A v23 trará ainda mais melhorias que vai exigir mudanças na estrutura dos blocos (a principal razão pela qual essa mudança não vai estar presente na v22)."
Bônus: As transações legítimas que estão "emperradas" serão priorizadas e, provavelmente, confirmadas logo.
________
Versão completa:
Após as últimas semanas de problemas de rede, a comunidade está dividida entre "v22 vai corrigir spam!" por um lado, e outros com algum FUD sobre "v22 não vai corrigir spam!".
É algo meio "cinza" o momento que nos encontramos entre essas declarações, e é um pouco mais complicado, mas vamos em busca de uma explicação em uma espécie de ELI10 (ou 15).
O spam na rede da Nano tem muitas consequências e problemas, os maiss importantes:
- Problemas com o envio de transações. Isso afeta todos nós usuários, e também as exchanges.
- "Ledger bloat" - transações inúteis aumentam o banco de dados de transações nos nodes e aumentam o custo de execução dos nodes.
- Rede dessincronizada, porque os nodes leves não conseguem acompanhar os mais fortes, na largura de banda, memória e/ou cpu.
O principal culpado desses problemas no v21.3 (antecessor do v22), é que os nodes não estavam em qualquer sincronia sob spam pesado, sobre quais blocos deveriam estar votando na rede para confirmar. Isso aumentou a comunicação de rede e reduziu o CPS (confirmações por segundo). As transações foram votadas em ordem de chegada, e como o spammer tinha um monte de transações de poeira (dust), transações legítimas não poderiam realmente ser confirmadas.
Que solução traz o V22?
Em suma, ele remove o incentivo para spam da rede, porque sob "spam de baixo custo" transações legítimas têm prioridade, e para interromper a rede de qualquer forma significativa, o spammer perderia muito dinheiro.
A solução não é perfeita ou ideal, ou mesmo a melhor solução conhecida atualmente. Mas é bom o suficiente para ser liberada o mais rápido possível.
A próxima versão, v23, trará recursos ainda melhores, dos quais a maioria exige mudança de estrutura de bloco (a principal razão pela qual eles não estão em v22). E talvez tenhamos um v22.1 com alguns ajustes.
Detalhes:
Os blocos de entrada (transações), válidos/verificados, são alocados em 129 baldes, por saldo da conta após a transação https://ift.tt/3tOgL3b
Um bloco válido, tem que ter um bloco anterior confirmado. Portanto, se a conta enviar 2 blocos, sem esperar pela confirmação, o bloco 2 não é válido, até que o bloco 1 seja confirmado. E só depois disso, o bloco 2 é adicionado ao balde/fila.
Cada balde tem classificação separada, por account.modified_at (LRU - Menos Recentemente Usado). Assim, as contas, que não foram usadas recentemente, têm maior prioridade. Como a maioria dos usuários não envia transações a cada segundo, eles terão quase sempre prioridade sobre spam.
Confirmações globais de blocos - "eleições", ou seja, comunicação entre nós que blocos serão confirmados, acontece em Contêiner Eleitoral Ativo (AEC).
Os melhores blocos por prioridade, são escolhidos igualmente entre todos os baldes, até que o AEC esteja cheio. No lançamento do v22, o AEC deve ser de 50000 blocos grandes.
O AEC e a classificação prioritária garantem (principalmente), que todos os nodes estejam votando nos mesmos blocos, o que aumenta o CPS, e reduz a largura de banda necessária.
Se um bloco não for confirmado pela rede até 5 minutos (nodes não estão votando no mesmo bloco), ele é removido do AEC e colocado de volta ao balde.
Então isso foi um monte de coisas técnicas abstratas. Agora vamos rever algumas situações de exemplo.
1. um spam de conta com 1 nano, enviando milhares de 1 transações de 1 raw.
Como o bloco não pode ser votado antes que seu bloco anterior (pai) seja confirmado, esse spam só aumentará o tráfego da rede, mas não afetará os usuários em nenhum balde. PoW necessário para enviar o bloco, vai diminuir o envio e aumentar o custo para spammer.
2. milhares de 1 nano contas, enviando 1 transações de 1 raw.
Como o AEC armazenará 50000 blocos, e as confirmações são rápidas, o spammer teria que ter mais de 50000 contas paralelas, para encher seu balde e o AEC.
Isso atrasaria as confirmações naquele balde, mas transações legítimas nesse mesmo balde, teriam prioridade sobre o spam (LRU). Isso resultaria em aumento do tempo de confirmação naquele balde para segundos (em vez de frações de segundo). No pior caso possível, algo mais de 10 minutos, porque são 5 minutos de tempo limite para abrir espaço para o bloqueio de envio, e 5 minutos de intervalo para o bloco de recebimento, além de alguma rede diminuir a velocidade.
Custo para spammer - 50000+ nanos bloqueados em contas, e PoW. E isso só para spam um balde. E talvez um pouco mais lento outras transações, por causa do uso de CPU ou rede.
O que acontece com as transações de espera atuais?
A classificação prioritária da LRU e os baldes serão aplicados também em transações antigas,e como as transações legítimas terão melhor prioridade via LRU, e estarão em baldes diferentes do que as transações dos spammers, e devem começar a confirmar mais rapidamente. As transações de spam serão lentamente confirmadas com CPS mais baixos.
E depois da V22? (provavelmente algumas dessas características, talvez algumas novas)
"Backlog de bloco limitado (Bounded Block Backlog - BBB)" - isso ajuda diretamente com o inchaço da ledger e a capacidade da rede. Simplificando - se o spammer enviar muitas transações, elas são descartadas.
"Remoção de baldes" - Colin quer escrever uma única função prioritária, que seria ainda melhor classificar blocos e ajudar a sincronizar nódulos.
"Remoção do PoW" - PoW não é mais usado para prioridade, por isso há discussões se e como removê-lo.
"Timestamps assinados" - isso aumentaria ainda mais a prioridade das transações legítimas.
"Ledger Pruning" - na v22 a poda é experimental. Espera-se que a mesma seja considerada estável para a próxima versão, o que ajudará na adoção e integrações.
E muitos mais.
Via Reddit:
https://ift.tt/33KLdAz
(Feed generated with FetchRSS) Via ⋰·⋰ https://ift.tt/38G5s5h
Comentários
Postar um comentário