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 13/06/2024._
@nuttycom iniciou a chamada passando as atualizações principais de engenharia da ECC.
A equipe concluiu correções de bugs relacionados à forma como o saldo transparente no backend da carteira é representado.
@Str4d criou um protótipo para recuperar taxas de conversão de moeda usando a Tor no backend da carteira 🔥
O próximo passo é adicionar o suporte #Arti @torproject para habilitar um serviço no lado do node + mecanismo para descoberta de nodes compartíveis ao Tor, para que as carteiras possam enviar novas transações através do mesmo**.**
Um protótipo da lightwalletd em Rust estará esperançosamente visível em breve na integração @zingolabs + @nymproject!
Daira Emma notou que a transmissão de texto cifrado de notas pela Tor ajudará na futura escalabilidade da Zcash.
Conectar servidores lightwalletd ao Tor permitirá que outras partes das operações da carteira reduzam o vazamento de dados relacionado ao envio de transações 🛡️🧅
@FeministPLT tem trabalhado no suporte ZIP-320. Os bancos de dados atuais assumem que os UTXOs têm uma altura conhecida.
Para o 1º- 2º txs no ZIP-320, não tem altura conhecida porque ambos são simultâneos.
Isso exigiu mudanças complexas no banco de dados, esperadas para a próxima semana.
O ZIP-317 foi implantado com um número configurável de ações lógicas não pagas por bloco – padrão de 50. Esse pedaço específico de espaço de bloco é alvo do ataque SandBlasting, expulsando quaisquer carteiras que ainda não o implementaram…
Como já se passou um ano desde que o ZIP-317 foi implementado e implantado, o limite de ações não pagas pode ser definido como zero no zcashd.
Todas as carteiras agora têm taxas ZIP-317 em vigor. O plano é implementar a atualização na próxima versão do zcashd. Miners poderão ajustar o limite ☑️
Em seguida, Arya liderou a atualização da equipe Zebra.
Existem PRs abertos para a versão mais recente dos scripts Zcash no script zebra, permitindo diferentes versões de dependência da ECC do que no zcashd - útil para testar e executar o scanner Zebra em seu próprio processo.
Em seguida, passamos para o desligamento do zcashd
Esse trabalho envolve a criação de uma carteira CLI separada que usa o Zebra em vez do Zcashd.
A ECC tem trabalhado em componentes das caixas librustzcash relacionadas a @zashi_app que também são benéficos para esse processo.
@zashi_app e os SDKs móveis produzidos pela ECC são apenas armazenamento shielded.
Você pode receber de forma transparente, mas não pode gastar de forma transparente.
O próximo passo para construir o backend da carteira envolve a migração dos testes SQLite do Zcash Client para serem genéricos no backend da carteira.
A equipe FROST está trabalhando na funcionalidade de atualização de compartilhamentos e resolvendo problemas de serialização.
As alterações de API para o núcleo FROST e as caixas do conjunto de criptografia foram feitas e precisam de revisão. Um release candidate coletará feedback antes do lançamento 2.0.0 -rc0. O trabalho no servidor FROST será retomado.
Alfredo levantou a questão da prontidão do FROST multisig caso uma proposta de Fundo de Desenvolvimento o exigisse.
Usar a Multsig Transparent para inúmeras saídas diárias foi considerado impraticável.
FROST escala muito melhor! Mesmo para 1.000 participantes, leva menos de 1 segundo.
Hoje, se você tiver uma Multisig 2/3 e uma pessoa perder a chave, ela se tornará uma multisig 2/2.
Com a funcionalidade de reparo FROST, se uma pessoa perder sua chave, você poderá regenerá-la...
Com Nested FROST, cada organização pode ter um subconjunto de limites que permite os corpos principais para cada sinal!
@FeministPLT compartilhou novas notas explorando o espaço de design de propostas para um ‘Fundo de Desenvolvimento Diferido’
Esses representam fundos que foram temporariamente bloqueados para distribuição posterior. A motivação principal é resolver o problema de ter muitos UTXOs.
Isto também daria tempo à comunidade para decidir.
A abordagem atual do fluxo de financiamento é o canto superior esquerdo.
Eles hibridizam-se devido à forma como os resultados servem o duplo propósito de armazenar o fundo de desenvolvimento e permitir gastos.
O canto inferior esquerdo não é implementável.
Os editores do ZIP definirão na terça-feira um prazo para especificações de tudo o que entrará na NU6.
Sugestão feita por @nuttycom para reunião de editores de ZIP em 16/07 - todos os ZIPs destinados à inclusão na NU6 devem estar completos e no status proposto.
As restrições são quanto tempo leva para que as coisas sejam implementadas, os nodes implantados sejam ativos e os nodes que não suportam a atualização da rede sejam interrompidos no momento da ativação + sejam totalmente auditados..
Ideia compartilhada para o encontro do Discord para que as pessoas criem ZIPs capazes de atender aos requisitos de especificação necessários para alcançar um estado proposto.
Se você tiver uma proposta de Fundo de Desenvolvimento e desejar escrever um ZIP, mencione-a no fórum ou no discord de desenvolvimento Zcash R&D → #zips.
Qualquer pessoa que pretenda ou planeje apresentar um ZIP deverá estar presente nas próximas convocatórias da Arborist Call.
@nuttycom mencionando que ficaria feliz em fornecer feedback do editor pré-ZIP com relação às propostas de uma perspectiva técnica 🙌
Obrigado pela leitura!
Para sugerir um tópico para a próxima reunião, envie um e-mail para arboristcall@zfnd.org 📨