Zcash Foundation - Atualizações de Engenharia | Sprint 20
Esse artigo refere-se as últimas atualizações de engenharia da Zcash Foundation para o Sprint 20 (24 de Setembro - 7 de Outubro) envolvendo seus principais desenvolvimentos no ZEBRA, FROST & DevOps.
Durante este sprint, a equipe continuou a trabalhar para adicionar funcionalidade ao modo zebra regtest trabalhando em um recurso solicitado pelo usuário para tornar o intervalo do halving configurável para redes personalizadas e regtests.
A equipe descobriu um problema de incompatibilidade entre o zcashd e o zebra que estava causando o travamento da testnet e trabalhos foram iniciados para adicionar a autenticação ao servidor RPC do zebra usando autenticação baseada em cookie.
Também deram continuidade a adição de suporte para transações órfãs (orp transactions) para garantir que o Zebra possa suportar transações o endereço TEX.
Finalmente, para dar suporte ao novo node e uma wallet stack que permitirá o desligamento do zcashd, a equipe começou a trabalhar adição dos outpoint spent & nullifier que uma carteira de substituta do zcashd precisará no Zebra.
No projeto FROST Demo, a ZF continuou trabalhando para adicionar suporte ao frost-client ao fluxo de trabalho do revendedor confiável e permitir a leitura e a gravação no arquivo de configuração em vez de ter que especificar manualmente um arquivo JSON.
Para este sprint, o foco principal foi na integração das partes do participante e do coordenador da demo no frost-client para que seja possível usar o frost-server com a ajuda dos arquivos de configuração. Isso é necessário para adicionar criptografia e autenticação às comunicações entre o frost-client e o frost-server.
Também estão sendo revisadas algumas contribuições externas de bas-vindas para dar suporte a outros protocolos baseados em FROST e casos de uso de contratos inteligentes na implementação de referência do FROST.
O trabalho de DevOps neste sprint incluiu uma refatoração de como foi implementado os cached states da ZF para poder selecionar o tipo de disco em cache a ser usado (tip ou checkpoint), a preferência de origem do git para o estado em cache (ramificação principal, ramificação PR, qualquer ramificação) e a rede.
Isso também permite a implantação de nós sem estados em cache (habilitando o comportamento anterior), pois espera-se que alguns testes sejam feitos sem um estado em cache anexado.
Também foi corrido um bug relacionado na CI da equipe, em que alguns testes estavam falhando por não encontrar um disco em cache, embora não fosse necessário.
Por fim, iniciou-se uma analise para ver se é possível habilitar o Github Enterprise como uma organização sem fins lucrativos, para aproveitar o GitHub Advanced Security para a Zcash Foundation.