Gloria Zhao — розробниця Bitcoin Core й авторка BIP 331 та BIP 431. Вона зосереджується на mempool, локальному сховищі непідтверджених транзакцій кожного вузла, і правилах їх прийняття та передавання. Ці малопомітні частини програми визначають, про які платежі вузол дізнається й повідомить іншим. Їх розробка потребує написання коду, уважної перевірки та пошуку захисту від зловживань.
Gloria Zhao приєдналася до Brink 4 січня 2021 року як перша стипендіатка. У 2022 році вона стала супроводжувачкою Bitcoin Core — однією з людей, відповідальних за його вихідний код і процес розробки. Це робота над конкретною програмою, а не призначення керівницею Bitcoin. Перелік випускників Brink, перевірений під час цієї ревізії, називає її колишньою супроводжувачкою. Тому біографію варто читати з урахуванням дат: стаття про давнє призначення не доводить, яку посаду людина обіймає сьогодні. [1] [2]
Якісний код потребує погляду інших людей. Zhao працювала з Bitcoin Core PR Review Club, де нові учасники вчаться читати запропоновані зміни й розглядати їхні наслідки. PR, або pull request, — це запит на включення зміни до проєкту. Клуб допомагає зрозуміти, яку проблему вона розв’язує та як її перевіряти; його головна мета — не домогтися злиття конкретного PR. Обговорення слугує навчанню й підготовці, а не автоматичному схваленню коду чи випуску. [2] [3]
Mempool не є спільною чергою для всієї мережі. Кожен вузол вирішує, які непідтверджені транзакції приймати й передавати, зважаючи, наприклад, на комісії та захист від перевантаження. Це локальна політика. Вона відрізняється від правил консенсусу, за якими перевіряють дійсність блоків. Zhao підписала заяву розробників від 6 червня 2025 року, що наголошує на виборі програми користувачем. Розробник може запропонувати іншу політику, але ні його підпис, ні права супроводу репозиторію не переписують програми на всіх чужих вузлах. [4]
Транзакція може витрачати кошти з іншої транзакції, ще не підтвердженої. Попередню називають батьківською, а залежну від неї — дочірньою. BIP 331 авторства Zhao пропонує 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. BIP 431 авторства Zhao описує підхід як інформаційний документ зі статусом 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.