Arborist Call #86
Este artigo foca nas últimas atualizações de Pesquisa & Desenvolvimento da Zcash no dia 19/09/2024
Arborist Call é uma chamada quinzenal dedicada aos desenvolvimentos do protocolo Zcash. Nela, desenvolvedores da ECC, ZF e engenheiros de carteiras de terceiros como yWallet, Zingo, etc. se reúnem para repassar todo o progresso recente em seus projetos, respondendo dúvidas e comprovando transparência.
Este resumo está focado na última chamada ocorrida em 19/09/2024.
Abrindo a chamada, @FeministPLT passou as atualizações sobre o progresso da Electric Coin Co na Tesnet da NU6:
Após uma ativação nominal da testnet, houve alguns relatos de problemas de sincronização na mesma. A conectividade na rede testnet pode ser muito esparsa.
O node Zcashd tem problemas para se conectar a outros nodes, com alguns travados na sincronização pouco antes da ativação da NU6.
Uma nova versão do zcashd que tem uma longa reversão para o ponto do fork, podendo não ser o suficiente - exigirá mais investigação pela equipe.
Uma nova versão dos SDKs librustzcash foi lançada. Para a NU6, especificamente, a versão atual do librustzcash não oferece suporte a NU6, pois as alturas de ativação do testnet/mainnet não estão definidas, mas estão planejadas para serem incluídas na próxima versão das bibliotecas Rust.
Atualização de Engenharia da ZcashFoundation com @upbqn (Marek):
Como mencionado anteriormente, a equipe da ZF adicionou dois novos RPCs: ''Stop'' & ''Generate'', com atualizações adicionais para dependências e documentações
@mpguerra observou que o relatório de auditoria da @LeastAuthority sobre a NU6 foi recebido. Ele contém 2 descobertas classificadas como sugestões relacionadas à documentação e ao tratamento de erros.
Atualização de Engenharia da @ElectricCoinCo:
Um usuário notou um problema grande com o rastreamento de saldos da pool de valor da chain no zcashd 5.10.0, que suporta a NU6 na testnet.
Atualizações do SDK da carteira:
As novas mudanças no backend do Rust são relacionadas a como o progresso do scanning será exposto aos usuários, fornecendo mais utilidade e fidelidade ao que a sincronização acontece antes que uma carteira seja usada. Outro item em que está sendo trabalhado são as mudanças em como as confirmações são escolhidas.
Também houve alguns bugs da Zashi relacionados a versões mais antigas da API do Android que foram investigados e corrigidos, ou seja, a API 27.
Novas atualizações para @zashi_app serão lançadas em breve.
Há um rascunho no ZIP 315 que descreve algumas mudanças sobre como tornar as notas gastáveis mais rapidamente, mantendo a segurança apropriada. Aprofunde.
Atualização Zcash Shielded Assets por Vivek:
O trabalho no Orchard, librustzcash e os scripts de vetor de teste para o suporte de transações v6 estão todos concluídos.
@qeditzkp está atualmente trabalhando para avançar com as adições do Zebra para ZSAs em várias frentes.
ZSA ZIPs: A maioria dos problemas críticos que estavam nos problemas abertos no repositório ZIPs foram resolvidos.
Ainda há algum trabalho conectado ao comportamento recomendado da carteira necessário. Um roadmap está em mente com Pull Requests abertos no Halo2 e criptografia de notas Zcash aguardando feedback.
Aceitação de Swaps e Transações ZSA: ZIP-228 teve outra rodada de revisões antes do início da implementação.
A equipe ZSA entrou em contato com @LeastAuthority sobre uma auditoria do protocolo Orchard no ZSA. Essa auditoria começará em breve, atualizações a serem seguidas nas próximas semanas.
Anúncios Abertos:
@thecodebuffet (Pacu) anunciou a criação de painéis no GitHub para rastrear o progresso dos diferentes esforços de desenvolvimento Zcash, incluindo o desligamento do zcashd, suporte a carteira de hardware, suporte ao explorador de blocos:
@FeministPLT apareceu recentemente em um painel sobre privacidade no @tbc_munich argumentando contra o comprometimento com protocolos de vigilância e conformidade.
Desligamento do Zcashd e Arquitetura da Carteira CLI.
@ZingoLabs apresentou uma proposta de Grant para auxiliar no processo de desligamento do zcashd ajudando a construir uma carteira CLI.
Zcash Community Grants solicitou feedback sobre se há consenso entre os engenheiros da ZF & ECC de que esse é um caminho que vale a pena seguir.
@ZingoLabs removeu o componente da carteira CLI do grant. Agora ele se concentra especificamente no Zaino Work.
Zingo apresentou um diagrama de arquitetura. Inclui um serviço gRPC fightwallet.
Há alguma sobreposição entre a funcionalidade necessária para servir uma carteira CLI e a funcionalidade inerente a um servidor lightwallet.
Arquitetura de Carteira CLI com Arlo:
Zingo está projetando uma interface remota para o serviço de estado de leitura no Zebra com funcionalidade 1:1.
Qualquer carteira CLI seria capaz de usar o serviço de estado de leitura do Zebra diretamente ou separadamente, tendo o validador e a carteira executados em hardware diferente.
Arlo mencionoubastante o trabalho preliminar para habilitar um serviço gRPC lightwallet sobre o mixnet da @nymproject que foi feito.
O RPC lightwallet como ele existe atualmente não é suficiente para fornecer toda a funcionalidade que uma substituição de carteira zcashd precisa.
''Já sabemos que o lightwalletd é insuficiente e estamos tentando construir um sistema que seja resiliente a ambientes futuros'' - Zancas
Sobre o tópico se o Zainoindexer é uma biblioteca ou um progresso, Zancas observou uma preferência por um processo. Onde a biblioteca cria um único stakeholder.
A descentralização é muito desejável aqui.
A restrição de que provavelmente migraremos os grandes usuários atuais de carteiras zcashd será que tudo o que for fornecido aqui precisa ter alguma interface JSON RPC com alterações mínimas.
O desempenho das Carteiras Exchange que lidam com grandes números de endereços transparentes, moedas e notas blindadas é uma preocupação.
Uma solução seria usar endereços blindados para depósitos invés de escanear um número arbitrário de endereços usando apenas uma chave de visualização de entrada.
Feedback acionável por @str4d para Zaino:
1) Se novos índices forem necessários para um caso de uso, é fácil adicioná-los.
2) Quando o indexador quer ou precisa de informações, ele pode ser reiniciado por conta própria.
3) gRPCs front-end não expõem APIs de controle de um full node
Obrigado pela Leitura!
Anotações Completas.