Os desenvolvedores do Neo Core finalizam o escopo da v3.9, avançam nos testes e no trabalho de design do CryptoLib

Fonte: CryptoNewsNet Título Original: Os desenvolvedores do Neo Core finalizam o escopo da v3.9, avançam nos testes e no trabalho de design do CryptoLib Link Original: https://cryptonews.net/news/blockchain/32063611/ Na chamada mais recente do Neo Core, os desenvolvedores avançaram nos testes para as mudanças nas taxas de execução e na lista de permissões, refinaram os planos para suporte BLS compatível com Ethereum no contrato nativo CryptoLib e avaliaram um novo mecanismo de governança para lidar com fundos bloqueados. A reunião também explorou opções para garantir que os candidatos a validadores operem nós reais, incluindo designs baseados em staking e slashing.

Garantindo que os candidatos a validador operem nós reais

Os desenvolvedores abriram a discussão sobre como provar que os candidatos ao Conselho operam nós funcionais, um requisito no caminho para a redução das recompensas em GAS. Duas abordagens amplas estão em consideração: um esquema leve de prova de trabalho para candidatos e um modelo de staking e slashing em que os candidatos bloqueiam NEO e podem ser penalizados se falharem nos testes de disponibilidade dentro de um prazo definido.

Porque os nós de consenso já expõem a vivacidade através do comportamento de mudança de visão, os novos mecanismos são destinados à verificação de candidatos. Mais detalhes de design serão refinados na questão correspondente.

Progresso em direção ao Neo v3.9.0

Os desenvolvedores concordaram que o ramo v3.9.0 está quase completo. Foi discutida uma proposta para incluir suporte à assinatura de mensagens arbitrárias portado do Flamingo. Como a funcionalidade depende de um pedido de pull adicional e de uma especificação clara para a semântica de mensagens assinadas, pode ser agendada para uma versão posterior se a documentação não for finalizada a tempo.

Um item, NEP-25, não será enviado na v3.9.0. Mudanças planejadas para o padrão devem atrasar o desenvolvimento de um a dois meses, então os colaboradores concordaram em adiá para evitar atrasar o lançamento.

Testando alterações mescladas: taxas de execução e lista de permissões

As alterações no fator de taxa de execução e o suporte a transações gratuitas com base em whitelist já foram integrados na v3.9.0. Um problema dedicado irá definir uma lista de verificação de testes para estas funcionalidades antes da publicação dos binários finais.

Uma revisão mais ampla de múltiplos colaboradores foi encorajada, particularmente para solicitações de pull que toquem no comportamento a nível de protocolo. A intenção é reduzir o risco de comportamentos divergentes entre exploradores, carteiras e implementações alternativas de nós uma vez que a atualização seja implementada.

Repensando o suporte BLS compatível com Ethereum na CryptoLib

Os desenvolvedores também examinaram a proposta de adicionar aliases compatíveis com Ethereum para BLS12-381 no contrato nativo CryptoLib.

Foram identificadas duas preocupações principais. Novos métodos operam em arrays de bytes, enquanto a funcionalidade existente do CryptoLib expõe pontos BLS através de interfaces de interoperação com auxiliares de serialização dedicados. A serialização e deserialização repetidas para cada operação são ineficientes e inconsistentes com o design atual da API.

A direção preferida é alinhar o suporte BLS compatível com Ethereum ao estilo de interface estabelecido, adicionando métodos de serialização para o formato Ethereum enquanto executa operações em representações de pontos BLS internas. A compatibilidade com o formato de serialização do Ethereum é o principal requisito, não uma superfície de API espelhada. Os detalhes de implementação serão refinados tanto no nó C# quanto no neo-go para garantir um comportamento consistente.

Ferramenta de governança para fundos bloqueados

O grupo também revisou uma mudança de governança que permitiria ao Conselho Neo transferir fundos de contas bloqueadas após um período definido, exigindo 19 de 21 assinaturas.

O mecanismo destina-se a casos em que os fundos estão congelados em carteiras maliciosas ou comprometidas. Não se destina a recuperar ativos para usuários que perderam as chaves privadas e não conseguem provar a propriedade.

Uma votação determinará o período de bloqueio padrão, com opções como seis meses, um ano ou dois anos. Uma vez finalizado, espera-se que a funcionalidade forneça um processo mais claro para lidar com endereços sancionados.