Gloria Zhao é programadora Bitcoin Core e autora de BIP 331 e BIP 431. Dedica-se ao mempool, o conjunto local de transações não confirmadas de cada nó, e às regras para as aceitar e retransmitir. Estas partes pouco visíveis do software determinam que pagamentos um nó conhece e divulga. Desenvolvê-las exige programação, revisão cuidadosa e formas de impedir abusos.
Gloria Zhao entrou na Brink em 4 de janeiro de 2021 como primeira bolseira. Em 2022 tornou-se mantenedora de Bitcoin Core, uma das pessoas responsáveis pelo código-fonte e pelo processo de desenvolvimento. É trabalho num software concreto, não uma nomeação para liderar Bitcoin. A página de antigos participantes da Brink consultada nesta revisão descreve-a como antiga mantenedora. As datas importam, portanto, ao ler a sua biografia: um artigo sobre uma nomeação passada não demonstra a função que alguém ocupa hoje. [1] [2]
Um bom código precisa de ser examinado por outras pessoas. Zhao trabalhou no Bitcoin Core PR Review Club, onde novos colaboradores aprendem a ler alterações propostas e a analisar as suas consequências. Um PR, ou pull request, é um pedido para incorporar uma alteração no projeto. O clube ajuda a perceber que problema ela resolve e como a verificar; o objetivo principal não é conseguir a integração de um PR específico. A discussão serve a aprendizagem e a preparação, não a aprovação automática de código ou de uma versão. [2] [3]
O mempool não é uma fila única para toda a rede. Cada nó decide que transações não confirmadas aceita e retransmite, considerando, por exemplo, as taxas e a proteção contra sobrecarga. São políticas locais, distintas das regras de consenso que verificam a validade dos blocos. Zhao assinou a declaração dos programadores de 6 de junho de 2025 que salienta a escolha de software pelos utilizadores. Um programador pode propor outra política, mas nem uma assinatura nem permissões de manutenção reescrevem o programa nos nós de todas as outras pessoas. [4]
Uma transação pode gastar fundos de outra que ainda não foi confirmada. A anterior é a transação-pai; a que depende dela é a transação-filha. O BIP 331 de Zhao propõe Package Relay, a transmissão de transações relacionadas como um pacote. Os nós negociariam o suporte por sendpackages, obteriam primeiro informação sobre os antecessores necessários e depois os próprios dados das transações. Assim evitariam procurar, uma a uma, todas as ligações em falta. O documento tem estado Draft, ou seja, proposta; a sua existência não demonstra implementação completa do protocolo na rede. [5]
Imagine receber um pagamento não confirmado cuja taxa é demasiado baixa. Se puder gastar a sua saída, pode criar uma transação seguinte com uma taxa superior. É CPFP, Child Pays for Parent: para receber a taxa da filha, o minerador tem também de incluir a transação-pai, podendo avaliar ambas em conjunto. Porém, um nó que não conheça a transação-pai normalmente não pode aceitar a filha isoladamente. O BIP 331 trata desse obstáculo à retransmissão. Uma taxa superior não substitui assinaturas e entradas válidas nem garante confirmação até determinado prazo. [5]
Bitcoin Core 28.0 introduziu um procedimento limitado 1P1C: uma transação-pai e uma filha. Pela comunicação P2P existente, a troca direta entre nós, podia combinar transações adequadas e avaliá-las em conjunto. É uma melhoria concreta, mas não a implementação completa de BIP 331. As notas excluem expressamente, neste procedimento de rede, uma filha com várias transações-pai não confirmadas e alertam para a falta de fiabilidade sob ataque. Distinguir uma função limitada da proposta mais ampla importa ao criar uma carteira que depende da retransmissão. [5] [6]
Um atacante pode explorar limites do mempool para dificultar a substituição de uma transação ou o aumento da sua taxa. A isso chama-se pinning. A política TRUC limita as dependências entre transações até à confirmação, facilitando avaliar a sua aceitação ou substituição. Bitcoin Core 28.0 introduziu-a para transações com nVersion=3. O BIP 431 de Zhao descreve a abordagem num documento informativo com estado Draft. Limitar antecessores e descendentes não confirmados ajuda, mas a proteção também depende da adoção por outros nós. Não garante proteção contra todo o pinning nem inclusão atempada num bloco. [6] [7]
Uma aplicação pode entregar um pacote ao seu próprio nó com submitpackage. A documentação de Bitcoin Core 28.0 explica que este comando, disponível pela interface RPC de comunicação com o nó, verifica regras de consenso e política do mempool. As transações aprovadas podem ser aceites mesmo que outra parte do pacote falhe. Um erro, portanto, pode não anular todo o resultado. É preciso ler o resumo package_msg e cada tx-results. Mesmo o sucesso local não demonstra que o pacote chegou a toda a rede nem que as transações entraram num bloco. [8]
Para ter uma visão mais completa, leia este verbete junto com Mike Hearn, Mempool, Package Relay. Também há referências a este verbete em Package Relay, Mike Hearn, Sergio Demian Lerner.