Gloria Zhao는 Bitcoin Core 개발자이자 BIP 331과 BIP 431의 저자입니다. 각 노드가 미확인 거래를 보관하는 로컬 저장 공간인 mempool과 거래를 받아들이고 전달하는 규칙에 집중합니다. 눈에 잘 띄지 않는 이 부분이 노드가 어떤 결제를 알고 다른 노드에 알리는지 결정합니다. 개발에는 코드 작성뿐 아니라 세심한 검토와 악용을 막는 방법도 필요합니다.
Gloria Zhao는 2021년 1월 4일 Brink의 첫 펠로로 합류했습니다. 2022년에는 Bitcoin Core 유지관리자가 되어 소스 코드와 개발 절차를 돌보는 역할을 맡았습니다. 특정 소프트웨어를 관리하는 일이지 Bitcoin 전체의 지도자로 임명된 것은 아닙니다. 이번 개정 때 확인한 Brink의 이전 참여자 소개는 그녀를 전 유지관리자로 설명합니다. 따라서 이력을 읽을 때는 날짜를 살펴야 합니다. 과거의 임명 기사가 현재도 같은 직책을 맡고 있음을 입증하지는 않습니다. [1] [2]
좋은 코드도 다른 사람의 검토가 필요합니다. Zhao는 Bitcoin Core PR Review Club에 참여해 새 기여자가 제안된 변경 사항을 읽고 그 영향을 살펴보도록 도왔습니다. PR, 즉 pull request는 변경 사항을 프로젝트에 반영해 달라는 요청입니다. 이 모임에서는 어떤 문제를 해결하려는지, 어떻게 검토할지를 배우며, 특정 PR의 병합 자체가 주된 목적은 아닙니다. 토론은 학습과 준비 과정이지 코드나 배포 버전을 자동으로 승인하는 절차가 아닙니다. [2] [3]
Mempool은 전체 네트워크가 공유하는 하나의 대기열이 아닙니다. 각 노드는 수수료와 과부하 방지 등을 고려해 어떤 미확인 거래를 받아들이고 전달할지 결정합니다. 이는 로컬 정책으로, 블록의 유효성을 검증하는 합의 규칙과는 다릅니다. Zhao는 사용자의 소프트웨어 선택을 강조하는 2025년 6월 6일 개발자 성명에 서명했습니다. 개발자는 다른 정책을 제안할 수 있지만, 서명이나 저장소 관리 권한이 다른 사람의 노드에 있는 프로그램을 일괄적으로 바꾸지는 않습니다. [4]
거래는 아직 확인되지 않은 다른 거래의 자금을 사용할 수 있습니다. 먼저 발생한 거래를 부모, 여기에 의존하는 거래를 자식이라고 부릅니다. Zhao의 BIP 331은 관련 거래를 묶어서 전달하는 Package Relay를 제안합니다. 노드는 sendpackages로 지원 여부를 협의하고, 필요한 선행 거래의 정보를 먼저 얻은 뒤 실제 거래 데이터를 받게 됩니다. 빠진 연결 고리를 하나씩 찾아다니는 일을 줄이려는 것입니다. 문서는 Draft, 즉 초안 상태이며, 문서가 있다는 사실이 네트워크 전체에 완전히 도입됐다는 뜻은 아닙니다. [5]
수수료가 너무 낮은 미확인 결제를 받았다고 해 봅시다. 그 출력을 사용할 수 있다면 더 높은 수수료를 붙인 후속 거래를 만들 수 있습니다. 이것이 CPFP, Child Pays for Parent입니다. 채굴자는 자식의 수수료를 받으려면 부모도 포함해야 하므로 둘을 함께 평가할 수 있습니다. 하지만 부모를 모르는 노드는 보통 자식만 따로 받아들일 수 없습니다. BIP 331은 이런 전달 장애를 다룹니다. 수수료를 높여도 유효한 서명과 입력을 대신할 수는 없으며, 정해진 시점까지 확인된다는 보장도 없습니다. [5]
Bitcoin Core 28.0은 부모 하나와 자식 하나로 제한되는 1P1C 절차를 도입했습니다. 노드 사이의 직접 교환인 기존 P2P 통신을 이용해 적합한 거래를 짝지어 함께 평가할 수 있었습니다. 분명한 개선이지만 BIP 331의 완전한 도입은 아닙니다. 배포 설명은 이 네트워크 절차가 미확인 부모가 여러 개인 자식을 지원하지 않으며, 공격 상황에서는 아직 신뢰성이 부족하다고 명시합니다. 전달에 의존하는 지갑을 만들 때는 특정 버전의 제한된 기능과 더 넓은 제안을 구분해야 합니다. [5] [6]
공격자는 mempool의 제한을 악용해 거래 교체나 수수료 인상을 어렵게 만들 수 있습니다. 이를 pinning이라고 합니다. TRUC 정책은 확인 전 거래 사이의 의존 관계를 제한해 수용이나 교체 여부를 판단하기 쉽게 만듭니다. Bitcoin Core 28.0은 nVersion=3인 거래에 이 정책을 도입했습니다. Zhao의 BIP 431은 이를 Draft 상태의 정보 제공 문서로 설명합니다. 미확인 선행·후속 거래를 제한하면 도움이 되지만, 보호 효과는 다른 노드의 정책 채택에도 달려 있습니다. 모든 pinning을 막거나 제때 블록에 포함된다는 보장은 아닙니다. [6] [7]
애플리케이션은 submitpackage로 자체 노드에 패키지를 제출할 수 있습니다. Bitcoin Core 28.0 문서에 따르면, 노드와 통신하는 RPC 인터페이스의 이 명령은 합의 규칙과 mempool 정책을 모두 검사합니다. 패키지의 다른 부분이 실패해도 검사를 통과한 거래는 받아들여질 수 있습니다. 따라서 오류가 전체 결과를 취소하지는 않을 수 있습니다. 종합 메시지인 package_msg와 개별 tx-results를 함께 읽어야 합니다. 로컬 노드에서 성공하더라도 패키지가 전체 네트워크에 전달됐거나 거래가 블록에 포함됐음을 입증하지는 않습니다. [8]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Mike Hearn, Mempool, Package Relay. 다음 항목에서도 이 글을 참조합니다 Package Relay, Mike Hearn, Sergio Demian Lerner.