Дебати про RBF – питання стимулів та індивідуального вибору

На превеликий подив, біткоїнери затято сперечаються про запропоновані зміни, які будуть включені в наступну версію Bitcoin Core. Заміна транзакції новою із підвищенням комісії (англ. replace-by-fee або RBF) – це особливість політики мемпулу, яка була запропонована у 2015 році, щоб дати користувачам інструмент для боротьби зі швидкими стрибками комісій, які призводять до того, що їхні транзакції не підтверджуються у мемпулі протягом тривалого часу.

Очевидно, що це буде проблемою для будь-якого використання Біткоїна, якщо обсяг транзакцій в середньому буде постійно перевищувати кількість транзакцій, які можуть бути оброблені в блокчейні, тому якщо ви думаєте, що це ніколи не відбудеться, це необхідна функціональність в мережі.

Заміна транзакцій була фактично включена та можлива у вихідній версії програмного забезпечення до зникнення Сатоші Накамото. Зрештою, він відключив цю функцію, тому що те, як він її спочатку реалізував, створило вектор для атак типу «відмова в обслуговуванні» проти вузлів. Вона дозволила замінити будь-яку транзакцію без сплати вищої комісії, що, по суті, дозволило б користувачам відправити транзакцію, а потім розпочати трансляцію необмеженої кількості замін до мережі. Це, очевидно, дозволило б спамити вузли величезними обсягами даних, які потребують підтвердження роботи, і непомірно збільшило вартість роботи вузла.

За минулі роки було обговорено кілька різних пропозицій щодо оновленої та безпечнішої схеми заміни. Ми швидко пройдемося всіма ними.

Full RBF

Найпростіший варіант RBF. Будь-яка транзакція може бути замінена, якщо транзакція, що заміщає, має вищу комісію, ніж та, яку вона замінює. Таким чином, всі транзакції можна замінити, але вимога сплачувати вищу комісію щоразу, коли ви замінюєте транзакцію, запобігає нескінченному спаму нових версій транзакцій, які перевантажують вузли.

First-seen-safe RBF

Це має дозволити заміну всіх транзакцій у мемпулі з одним особливим застереженням; виходи оригінальної транзакції також повинні використовуватися для замінної транзакції, у тому числі змінений вихід. Це, як і раніше, вимагає збільшення комісії для заміни транзакції, але вимога використовувати ті ж виходи означає, що вам потрібно додати новий вхід і другий змінений вихід, тому що жоден з вихідних виходів не може бути змінено. Це призводить до більших транзакцій, які повинні мати більшу загальну суму комісій, щоб гарантувати, що при заміні оплачується вища комісія.

Відкладений RBF

Була пропозиція дозволити заміну будь-якої транзакції в мемпулі, але тільки після того, як пройде певна кількість блоків, відколи нода побачила вихідну транзакцію. Суть у тому, що це дозволить швидше замінювати та підтверджувати транзакції, що зависли в середовищі з високою комісією, але тимчасова затримка в тому, коли вона може бути замінена, запобігає спробам подвійного витрачання без підтвердження.

Opt-in RBF

Реалізовано у 2016 році, як визначено в BIP 125. Транзакції можуть бути замінені тільки в тому випадку, якщо транзакцію, яка погоджується на заміну, певним чином помітили або якщо один із їхніх попередників зробив це у випадку ланцюжка непідтверджених транзакцій, щоб люди, які отримують кошти, знали, чи буде непідтверджена транзакція замінена у мемпулі.

Велика суперечність полягає в тому, що в наступному випуску Core, 0.24, буде запроваджено повну RBF у політиці мемпулу. Що це означає? Це дасть користувачам можливість змінити свою локальну політику мемпулу з opt-in RBF на full RBF; за замовчуванням ця опція буде вимкнена (вузли будуть використовувати full RBF). То чому ж люди проти цієї зміни? Компанії, які приймають транзакції з нульовим підтвердженням, залежать від переважної більшості мемпулів вузлів, що відмовляються замінити транзакції, які не вибрали RBF для транзакції. Вони роблять це тактично з'єднуючи свій вузол з великою кількістю інших вузлів, розкиданих всією мережею. Це дозволяє їм дуже швидко виявляти в мережі транзакцію з подвійною тратою, тому що це потрібно зробити майже відразу, якщо транзакція не позначена як RBF, щоб мати добрі шанси дійти до майнерів. Також варто відзначити, що бізнес у мережі не може зробити це без успішної атаки на мережу. Ці бізнеси стверджують, що повна RBF «ламає» їхню бізнес-модель використання RBF. Дехто навіть критикував розробників Core за те, що вони «нав'язують» зміни, які негативно впливають на бізнес.

Проста реальність така, що подвійні витрати були та будуть можливі, opt-in RBF або повна RBF нічого не змінить. Крім того, просте створення опції для зміни вашої власної локальної політики мемпулу (яка відключена за замовчуванням) аж ніяк не диктує зміни нікому, це можливість, надана користувачам, щоб зробити вибір для себе. Зрештою, коли справа доходить до того, які транзакції насправді будуть включені до наступного блоку, єдині мемпули, які мають значення – це мемпули майнерів. Мемпули окремих вузлів користувача – це не що інше, як послідовний ланцюжок зберігання пам'яті з кінцевою метою поширення всіх цих непідтверджених транзакцій серед майнерів, щоб в результаті вони могли бути включені в блок.

Політика мемпула використовується як свого роду м'який механізм безпеки для запобігання атакам типу «відмова в обслуговуванні» на вузли та захисту користувачів від «пострілу собі в ногу» складними транзакціями та сценаріями. Багато типів транзакцій дійсні на основі консенсусу, їм дозволено включатися до блоку, але вони не будуть ретранслюватись політикою мемпулу вузлів за умовчанням. Однак це ніяк не заважає певному користувачеві передати транзакцію, яка була б проігнорована вузлами в мережі безпосередньо майнеру.

У цьому суть справи. Все, що потрібно від майнерів, це налаштувати API для прямого надсилання їм транзакцій, які вже є у багатьох, і обмеження політик мемпулу в мережі не матимуть значення. Ви можете просто передати транзакцію безпосередньо майнерам та обійти всі правила, коли щось можна замінити у мемпулі інших вузлів. Подумайте про стимули – якщо є гроші, які можна заробити на майнінгу певного класу транзакцій, але мемпули в мережі не передають їх, щоб ви зробили як майнер? Просто прийміть їх прямо. Чим більше зменшується субсидія і зростають комісійні за транзакції у відсотках від доходів майнерів, тим більш неминучим стає те, що майнери просто безпосередньо прийматимуть заміни, які сплачують вищі комісії, якщо вузли в мережі не передаватимуть їх опосередковано. Це неминуче.

Ця зміна не змінює політику мемпулу за замовчуванням для Bitcoin Core, вона просто надає можливість окремому оператору вузла змінити свою локальну політику мемпулу, якщо вони цього забажають.

І я хотів би додати, що це вибір, який завжди був доступний, якщо користувачі вирішать змінити свій клієнт. Все, що це дає, це полегшує вибір, який завжди був доступний користувачам. Стимули неминуче призводять до того, що всі транзакції будуть замінні, якщо майнери діятимуть економічно раціонально – це неминуче. Єдине питання полягає в тому, чи програмне забезпечення має відображати ці стимули таким чином, щоб дозволити окремим користувачам самим вирішувати, яку політику використовувати для свого мемпулу, чи люди повинні просто сидіти і дозволяти розповсюдженню транзакцій централізуватися біля безпосереднього підпорядкування самим майнерам?

Кінцевий результат той самий, але очікування на те, що майнери перейдуть на пряме відправлення транзакцій, матиме дуже негативні наслідки. Це матиме наслідки для конфіденційності людей, які транслюють транзакції в мережу, і може мати дуже негативні наслідки для здатності користувачів вирішувати, яку комісію платити за транзакцію. Якщо більші частини незавершених транзакцій більше не будуть публічно транслюватися мережею, то користувачі мають неповне уявлення про те, з ким вони торгуються за включення в блок. Майнери можуть навіть брехати про розподіл комісій, щоб стимулювати користувачів платити більше, ніж вони повинні.

Єдиним реальним недоліком цієї опції є те, що повний RBF може не працювати послідовно, якщо тільки невелика частина мережі, зокрема майнери, вирішить увімкнути повний RBF. Проте з погляду переходу це нічим не відрізняється від переходу на SegWit. Протягом цього перехідного періоду неоновлені вузли не ретранслюватимуть транзакції SegWit, тому що вони не можуть їх перевірити. Тому протягом цього періоду спостерігалася та ж динаміка поширення, яка була непослідовною, доки не було оновлено достатньо користувачів. Але це не змінило того факту, що рішення про оновлення приймали окремі користувачі.

У результаті боротьба з full RBF – це заперечення реальності заохочень у мережі. Нікому нічого не диктується, параметр конфігурації просто надає окремим користувачам вибір, який можуть зробити самі. Я вважаю це дивним, що так багато людей одночасно ігнорують реальність стимулів, стверджуючи, що небезпечні засоби отримання платежів можуть бути захищені всупереч стимулам, як і дехто стверджує, що користувачам програмного забезпечення не слід надавати вибір у тому, як налаштувати власне програмне забезпечення.

Мій вузол, мої правила, чи не так?

Це гостьовий пост Шинобі, викладача-самоучки в Біткоїн-сфері та орієнтованого на технології ведучого подкастів про Біткоїн. Висловлені погляди є його власними і не обов’язково збігаються з точкою зору BTC Inc. або Bitcoin Magazine.