_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 16/05/2024._
Seguindo #ZconV o foco principal da ECC tem sido a manutenção de carteira + correção de bugs desde o lançamento da @zashi_app no iOS e Android.
A equipe está ativamente envolvida e trabalhando com @Binance para adicionar um método RPC necessário para que o zcashd verifique as conversões de endereços TEX.
Tem havido uma discussão sobre como funcionarão as taxas de câmbio verificáveis para a moeda em #Zashi.
O objetivo é evitar a dependência de cache intermediário em uma lightwalletd – não revelando informações além de ser resistente à manipulação da taxa de câmbio.
Alfredo então passou a atualização da @ZcashFoundation sobre o Zebra Node:
A versão Zebra 1.7.0 destaca principalmente os diretores e o regtest e o suporte testnet personalizado.
A data do fim do suporte foi revertida em 16 semanas a partir de 20 devido a preocupações que surgiram.
A equipe também está trabalhando em um tutorial de regtest para mostrar aos usuários como usar esse novo recurso do Zebra.
@upbqdn está atualmente trabalhando em um bug relatado por @aarnott no método gettreestate.
A refatoração significativa do construtor de transações Zcash Primitives foi liderada por @str4d
O objetivo é permitir que as dependências criptográficas do Sapling sejam extraíveis
Progresso em direção à integração para @brave que está implantando Transparent e Orchard ZEC em sua carteira
O desligamento do zcashd é uma nova seção que foi adicionada as Arborist Calls.
Discussão da ZF e ECC desde a última conferência foi sobre como funcionarão vários serviços, como digitalização e indexação. Enumerando também os diversos dados necessários para esses serviços para que a construção possa começar.
Por razões de segurança, mesmo quando a equipe estiver confiante de que a implementação do Rust está completa, eles aguardarão uma atualização de rede para a mudança. Semelhante ao que foi feito no passado para alternar as principais dependências criptográficas.
Zcash Shielded Assets foi o próximo tópico de discussão.
Os editores do ZIP têm se reunido regularmente com a equipe da qedit há muitos meses para trabalhar no design das especificações. As reuniões agora estão relacionadas à integração - determinando o processo de colocar o backlog de coisas nas bases de código.
A reunião de terça-feira concentrou-se no trabalho necessário para criptografia de notas, alterações nos gadgets halo2 e interação entre ZSAs e alterações nos memorandos para NU6.
Pode ser que o estilo ZIP-209 - com um requisito, qualquer um dos valores do pool protegido existente não possa ser negativo, necessário para ZSA.
Questão de como isso impacta a taxa de definição de um novo ativo versus a taxa de emissão de um ativo que já foi definido ou se deveria haver uma distinção.
Se a @Zcash introduzir uma nova pool shielded com um protocolo de pagamento pós-quântico, seria necessário isolá-lo do lado seguro pré-quântico.
Esse seria um ponto em que essas verificações teriam que ser aplicadas.
@conradoplg nos conduziu pela recente apresentação da demonstração do FROST feita na ZconV
A demonstração permite executar o FROST em diferentes máquinas e regiões geográficas usando um servidor para enviar mensagens entre os participantes.
Conrado e Natalie estão agora trabalhando em alguma preparação de refatoração para preparar a produção do servidor. Isso envolverá a adição de criptografia e autenticação.
@EliseHamdon @MassAdoptionOrg tem liderado os esforços na criação do livro My First Zcash!
@hhanh072 levantou uma ideia sobre como as chaves do pacote de memorandos são derivadas.
O rascunho inicial é substituir o campo de memorando no texto simples da nota por uma chave que pode descriptografar os dados do pacote de membros em outras partes da transação para compartilhar memorandos entre destinatários e entre as pools blindadas.
A pergunta de Hanh foi "em vez de incorporar a chave no texto simples, por que não derivá-la do segredo comum compartilhado?
Descriptografia de Teste = Digitalização com seu IVK, derivando um segredo compartilhado entre dados efêmeros fornecidos no tx pelo remetente e seus dados estáticos que estão em seu IVK.
A partir daí derivou-se uma chave simétrica para descriptografar o texto cifrado da nota. Se a descriptografia for bem-sucedida, a nota é para você
Não há razão para que você não possa derivar várias chaves desse segredo compartilhado.
Seria necessária uma mudança na função de derivação de chave - na verdade, essa abordagem foi usada no Sprout (pool protegido obsoleto).
Questões a considerar sobre o efeito nas transações:
- Ganhamos capacidades derivando chaves do KDF?
- Perdemos capacidades ao derivar chaves do KDF em vez de incorporá-las diretamente?
- Qual é o efeito na distinção das transações resultantes?
As conclusões iniciais tiradas foram que a abordagem original é mais simples, sendo a abordagem KDF desnecessariamente complexa, ao mesmo tempo que torna mais difícil fazer divulgações de pagamentos.
Para encerrar, @feministPLT acrescentou algumas palavras de sabedoria.
"O segredo do sucesso é ter um objetivo constante. O objetivo constante é a privacidade."
#zcash 🛡️
Para sugerir um tópico para a próxima reunião, envie um e-mail para arboristcall@zfnd.org 📨