Оценка пошлин для операций со сторонними блокчейнами


See Eng

Подсистема xchange, использующаяся веб-клиентом Universa, и другими подсистемами, содержит общие для всех этих предназначений механизмы для оценки пошлины (fee), необходимой для выполнения операций со сторонними блокчейнами. Ниже описаны механизмы и методики такой оценки.

Общие факторы при оценке пошлины

Приоритезирование транзакций на основе комиссии: проблемы и недостатки

К сожалению, многие внешние блокчейны (с архитектурой Bitcoin/Ethereum) обеспечивают приоритезацию транзакций на основании размера оплачиваемой автором транзакции комиссии. При выборе нодой транзакции (из списка уже предложенных сети для регистрации транзакций, но еще не зарегистрированных — обычно такой список называется pending pool-ом) ноды отдают предпочтение тем транзакциям, комиссия за которых (оплачиваемая в итоге ноде, принимающей решение по формированию блока), окажется выше.

С одной стороны, это приводит к более высоким прибылям ноды и конкуренции между транзакциями за право быть обслуженной нодой.

С другой, это вызывает большое количество проблем при работе с такими блокчейнами:

  1. Рыночная конкуренция за размер комиссий вызывает непредсказуемый рост комиссий (а значит, и итоговой пошлины), а следовательно – для пользователей сети траты на последующее её использование тоже становятся непредсказуемыми. При активном использовании в промышленности и бизнес-задачах это приводит к невозможности прогнозировать полные расходы на обслуживание заранее.

  2. Выбор нодами из нескольких транзакций в pending pool-е и в то же время публичная доступность этого pending pool-а приводит к тому, что участники сети могут создавать новые транзакции уже после того, как чья-то транзакция появилась в pending pool-е, но до того, как она будет зарегистрирована. Это приводит к возможности возникновения так называемого front-running-а, когда очередность операций (и их учёта в блокчейне) отличается от очерёдности их появления. Эффект фронт-раннинга приводит к понижению безопасности и надёжности во многих сценариях использования, а для некоторых задач полностью ликвидирует возможность применения таких блокчейнов (например, большинство регулирующих органов абсолютно запрещают использование front running-а на официальных регулируемых биржах, воспринимая его как крайний случай незаконного инсайдер-трейдинга).

По этим причинам в сети Universa Blockchain стоимость транзакций зависит исключительно от вычислительной сложности (и себестоимости) её выполнения, но не зависит от оплачиваемого пользователем желания приоритезировать её — а значит, транзакции разных пользователей будут равноправны между собой, и ни одной из них не получится обогнать другую, появившуюся в сети ранее, иначе чем случайно.

Общая схема расчёта полной пошлины

Но для взаимодействий с внешними блокчейнами учитывать их особенности всё-таки приходится даже при разработке систем и механизмов Universa.

В общем виде полный размер комиссии обычно рассчитывается по схеме:

TotalFee = Commission × Size

То есть, полный размер пошлины (TotalFee) вычисляется как произведение размера какой-то «комиссии» (Commission) на общий объём/размер/вычислительную сложность транзакции (Size). Терминология, используемая для компонентов этой формулы в разных блокчейнах, может различаться, но общая идея остаётся прежней: «размер» транзакции вычисляется в зависимости от её технических характеристик, а размер оплачиваемой комиссии, как правило, пользователь может регулировать самостоятельно, этим и влияя на шансы транзакции быть зарегистрированной.

Примеры используемой терминологии:

Universa:

  • Size – «вычислительная сложность» транзакции; соответствует количеству U, необходимому для её регистрации.
  • Commission1. Как уже упоминалось раньше, в сети Universa размер комиссии не влияет на скорость/вероятность регистрации транзакции.

Bitcoin:

  • Size – «размер» транзакции; обычно для расчёта платежа учитывается размер Bitcoin-транзакции в байтах. В зависимости от деталей транзакции и нюансов технической реализации, может значительно различаться.
  • Commission – обычно измеряется в satoshi/byte (где satoshi – это минимальная учётная единица, равная 0.00000001 BTC).

Ethereum:

  • Size – «сложность транзакции», так называемый «газ» (“gas”), хотя более точным переводом являлось бы «бензин». Количество «газа» считается стандартным для переводов ETH (21000) и может значительно варьироваться для переводов ERC20.
  • Commission – «цена газа», обычно измеряется в Gwei (более точная формулировка — «Gwei за единицу газа»), где G – это приставка в системе СИ, обозначающая 1 000 000 000, а wei — минимальная учётная единица, равная 0.000000000000000001 ETH.

Bitcoin

Size: оценка размера транзакции

На размер транзакции Bitcoin оказывают значительное влияние как минимум два различных фактора: количество используемых «входов» (UTXO) транзакции и используемые механизмы транзакций сети Bitcoin (например, SegWit).

UTXO

В однопользовательских Bitcoin-кошельках, в которых в любой момент времени обычно создаётся и отправляется не больше одной транзакции, предсказать, какие именно «входы» (сответствующие каким именно «выходам», куда ранее были получены активы) будут использоваться в последующей транзакции, получается достаточно легко. Вполне возможно сначала оценить, сколько и каких входов будет использоваться в следующей транзакции и точно предсказать размер транзакции (для расчёта пошлины за неё).

В мнопользовательской высоконагруженной системе же (как в случае Universa) может одновременно создаваться много Bitcoin-транзакций, и между такой «предварительной » оценкой и запуском реальной транзакции в системе может случиться так, что уже было создано некоторое количество других Bitcoin-транзакций; что привело к изменению списка доступных UTXO и к изменению структуры транзакции, а значит, её величины: см. en.bitcoin.it/wiki/Maximumtransactionrate, en.bitcoin.it/wiki/Change.

Из-за того, что система вывода BTC может одновременно использоваться многочисленными пользователями, предсказание размера транзакции из точного становится вероятностным.

Для оценки размера транзакции в байтах часто используется формула:

in×180 + out×34 + 10

(где in и out — количество входов и выходов транзакции соответственно). Для 1 входа и 1 выхода это даёт нам нижнюю оценку размера транзакции в 224–225 байт, которая и используется в вычислениях. (Реальные транзакции, при большем количестве входов и выходов могут оказаться больше размером, следовательно, такая оценка будет даже занижена).

SegWit

В конце 2017–начале 2018 (уже после реализации поддержки Bitcoin в инфраструктуре Universa) в сети Bitcoin в качестве стандарта были финализированы изменения, добавляющие в протокол Bitcoin функциональность Segregated Witness, SegWit. Такая функциональность, с одной стороны, уменьшает размер транзакций, но с другой стороны, добавляет новые неочевидные особенности в функционирование Bitcoin:

  • Без использования SegWit-транзакций каждая транзакция содержит подписи, подтверждающие, что плательщик уже обладает переводимыми финансами. При использовании SegWit-транзакций от хранения таких подписей отказываются, что добавляет рисков и проблем при учёте, были ли биткойны фактически получены.
  • Описанная выше особенность – «отказ от хранения подписей, подтверждающих наличие денег» – приводит к возникновению эффекта malleability («пластичности») транзакций. Пропонентами технологии SegWit (в основном она продвигается в связи с тем, что позволяет «малой кровью» увеличить размер блока Bitcoin) эта особенность рекламируется как «положительный эффект» от введения SegWit – благодаря этому транзакция, использованная для «приёма денег», может быть незначительно изменена каким-то нодами, но, при возникновении malleability, всё равно будет учтена; с точки зрения безопасности возможность модифицировать транзакции без нужды переподписи их – неоправданный риск.
  • Ввиду того что SegWit-транзакции появились в протоколе Bitcoin достаточно поздно (конец 2017), в инфраструктуре Universa возникает необходимость обратной совместимости с транзакциями, адресами и кошельками, созданными до распространения SegWit.
  • Хотя считается, что технология SegWit обладает достаточной совместимостью (non-SegWit кошельки могут слать BTC на SegWit адреса; SegWit кошельки могут слать BTC на non-SegWit адреса), имеется значительный шанс того, что пользователи (особенно использующие устаревшие программные или даже аппаратные реализации кошельков) столкнутся с проблемами со «слишком новой технологией».

Использование при экспорте BTC SegWit-транзакций могло бы понизить оценочный размер транзакций; но для снижения рисков (совместимости и безопасности) SegWit-транзакции в подобных сценариях на данный момент (ноябрь 2020) не используются. Такая позиция не является «перестраховкой» – согласно имеющейся информации, на ноябрь 2020-го года (через 3 года после появления SegWit в протоколе) количество SegWit-транзакций составляет меньше половины всех транзакций – 47%; более того, за последние полгода степень использования SegWit даже упала с уровня 55% до этих 47%.

Commission: оценка комиссии

Существует достаточно много сервисов и методов, пытающихся оценить и предсказать именно комиссию (обычно в единицах вида «сатоши за байт» или «сатоши за килобайт»), достаточную, чтобы транзакция была успешно зарегистрирована в блокчейне в течение какого-то срока. Общий обзор таких сервисов (и текущие значения комиссий, предлагаемые ими): b10c.me/blog/003-a-list-of-public-bitcoin-feerate-estimation-apis.

При анализе данных таких сервисов необходимо учитывать возможные нюансы в учёте единиц измерения и в представлении данных:

  • 1 satoshi = 0.00000001 BTC;
  • согласно требованиям международной системы единиц СИ (и ряда других стандартизирующих органов, например, IEEE), приставка «к-»/“k-” (кило-) обозначает «1000»; тем не менее, иногда в айти-среде она используется в качестве обозначения «1024». Организация JEDEC (стандартизирующая разработки в области оперативной памяти и устройств хранения) упоминает использование приставки «кило» как «1024» как одно из возможных, хотя и не рекомендуемых решений. В связи с такими неоднозначностями, в случае, если в API используется приставка «кило»/“k-”, может быть небходимо уточнить, какое конкретно числовое значение имеется в виду.
  • В некоторых API удельная комиссия измеряется не относительно байта (byte), а относительно «виртуального байта» (vByte). Для SegWit-транзакций 1 vByte = 4 bytes. Для не-SegWit-транзакций, использующихся в Universa, 1 vByte = 1 byte.

Для использования в задачах Universa выбрано одно из старейших публично доступных API оценок комиссий – API bitcoinfees.earn.com, для программного использования доступное по адресу bitcoinfees.earn.com/api/v1/fees/recommended в наиболее общем виде или на bitcoinfees.earn.com/api/v1/fees/list в подробном формате. Для операций Universa (в частности, чтобы после появления заявки на вывод фактическая транзакция прошла как можно быстрее) используется оценка комиссии fastestFee из API, соответствующая ожиданиям (с доверительным интервалом 90%), что транзакция попадёт в ближайший возможный блок (или непосредственно следующий после него, если, например, транзакция просто не успеет оказаться замеченной узлом, «замайнившим» следующий блок).

Внимание – при сравнении оценки комиссии между сервисами необходимо учитывать:

  • Доверительный интервал ожидаемой оценки; например, оценка с доверительным интервалом 80% – «с вероятностью 80% транзакции с комиссией ниже указанной попадут в блок» – может быть занижено по отношению к оценке с доверительным интервалом 90%, но при этом имеет больше шансов, что такая комиссия по факту окажется недостаточной.
  • Оцениваемый срок, в течение которого транзакция попадёт в блокчейн; например, оценка с доверительным интервалом 90%, предполагающая попадание транзакции в блокчейн в течение 2 блоков (20 минут), наверняка будет ниже, чем оценка с таким же доверительным интервалом 90%, предполагающая попадание транзакции в блокчейн, но в течение 1 часа (6 блоков).
  • Здравый смысл и реальную ситуацию в mempool-е; на графиках состояния мемпула вроде bitcoinfees.earn.com/ можно видеть актуальную ситуацию с распределением мемпула и текущее количество неподтверждённых транзакций. К пример, при среднем количестве транзакций в блоке порядка 2000 (на ноябрь 2020),...
    • если мы выберем какой-то уровень A₁ комиссии satoshi/byte и увидим, что на данный момент в мемпуле меньше 2 000 транзакций с комиссией выше A₁ – вполне логично можно ожидать, что транзакция с комиссией A₁ попадёт в ближайший возможный блок;
    • если мы выберем какой-то уровень A₂ комиссии satoshi/byte и увидим, что на данный момент в мемпуле больше 20 000 транзакций с комиссией выше A₂ – можно было бы ожидать, что транзакция с комиссией A₂ попадёт в блокчейн в течение пары часов; но реально в течение этого времени в мемпуле появятся новые транзакции с более высокой комиссией, а значит, транзакция с A₂ будет зарегистрирована ещё позднее

Пошлина в сети Bitcoin: общий итог

Обобщая описанные выше причины, для оценки общей «пошлины» (fee) за транзакцию биткойна:

  • В качестве ожидаемой оценки размера транзакции берётся 225 байт (non-SegWit транзакция);
  • Для оценки комиссии за транзакцию используется API bitcoinfees.earn.com/api/v1/fees/recommended, в частности, значение fastestFee – соответствующее ожиданию, что транзакция с 90%-ным доверительным интервалом оценки попадёт в ближайший технически возможный блок (обычно – 5–15 минут).
  • Для компенсации рисков с некорректной (заниженной) оценкой размера транзакции и/или изменения комиссии, результат умножается на значение «риск-фактора», для Bitcoin в данный момент выбранное как 1.1.
  • Прочие сервисы с добавленной стоимостью (например, операции с гипертокенами/своп токенов) могут добавлять дополнительные комиссии, чтобы компенсировать свои собственные расходы.

Ethereum

Size: оценка количества «газа»

В сети Ethereum возможны различные операции, нуждающиеся в разном количестве «газа».

Самая простая ситуация – с переводами ETH. Любой перевод ETH требует фиксированного количества газа: 21 000.

Перевод любых ERC20-токенов — сложнее.

Каждая конкретно операция по переводу ERC20-токена представляет собой запуск кода (EVM-машины), выполняющего действия, запрограммированные для этого ERC20-токена. В зависимости от (существенно различающихся) реализаций, при этом могут выполняться разные действия (причём разные даже между несколькими последующими запусками операции перевода токена), и поэтому каждый запуск может требовать достаточно плохо предсказуемое количество «газа».

На самом деле, если планировать только «на одну операцию вперёд», то, как и в случае с Bitcoin, предсказать необходимое количество газа для единственной последующей операции возможно достаточно точно. Но в многопользовательском окружении, когда с одного и того же «кошелька» может сначала заказываться, а потом выполняться одновременно сразу много транзакций — между оценкой следующей транзакции и реальной транзакцией может пройти достаточно много времени, в течение которого уже могут случиться другие транзакции, которые повлияют на внутреннее состояние dApp-а токена, а значит, требуемое для следующей операции количество газа будет меняться.

В связи с этим, оценивать необходимое количество газа получается только эмпирически-статистическими методами, на основании истории выполнения операций transfer для токенов. Даже для токена UTNP, обладающего минимумом дополнительной бизнес-логики на уровне Ethereum, количество газа может значительно колебаться. Например:

Другие токены, обладающие более сложной бизнес-логикой и имеющие внутри себя более сложные алгоритмы, при каждом запуске могут выполнять ещё больше действий, а значит, требовать ещё больше «газа».

Чтобы «газа» хватило, даже несмотря на возможную неточность предсказания его количества для транзакций, для задач оценки будущей «пошлины» на данный момент (ноябрь 2020) требуемое количество газа принимается за 70 000.

Commission: оценка цены «газа»

Аналогично различным API для оценки комиссии для Bitcoin, существуют и различные API/методики для оценки комиссии (цены «газа») для операций в сети Ethereum.

К примеру:

  • EthGasStation – предположительно, самый популярный и чаще всего используемый пользователями инструмент для оценки цены «газа». Предоставляет оценки цены «газа», необходимой как для максимально быстрой (trader-уровня) регистрации транзакции, обычно в течение 30 секунд, так и наоборот, минимально разумно допустимой, при которой транзакция в целом будет хотя бы зарегистрирована за разумное время (safe low).
  • eth.gasPrice/eth_gasPrice — реализована как часть WEB3-стандарта (и, обычно, узлов сети Ethereum) и предсказывает минимально достаточное количество «газа», чтобы транзакция хотя бы прошла, но без каких-либо ожиданий, что она пройдёт достаточно быстро. Обычно примерно соответствует уровню «safe low» других «оракулов предсказания» — «пройдёт, но не прямо сейчас, но вполне вероятно, что в течение ближайшего часа».
  • Etherscan gas tracker — сервис, реализованный как часть одного из самых известных Ethereum block explorer-ов. Тоже предоставляет оценки для комиссии с разным уровнем ожидаемой скорости регистрации — high, average, low.
  • Etherchain gas price oracle — аналогичный сервис от block explorer-а Etherchain.
  • Gas Now – аналогичный сервис, использующий для своих предсказаний статистику мемпула из майнинг-пула SparkPool.
  • Infura eth-gasPrice — часть API “облачного хостинга нод Ethereum” Infura; по сути, представляет доступ через публично доступное платное API к методу eth_gasPrice обычных узлов Ethereum.

Конечно, использование любых этих методов оценок транзакций не гарантирует попадание транзакции в блокчейн в ожидаемый срок. Тем не менее, точность предсказаний обеспечивает разумный баланс между расходами на комиссии и скоростью регистрации транзакций.

Для использования в задачах Universa выбрано комбинированное решение:

  1. Первая попытка оценки комиссии происходит с помощью API сервиса EthGasStation. При его доступности и отсутствии проблем, используется комиссия, которую сервис EthGasStation предоставляет для “FAST”-транзакций (с ожидаемой регистрацией в блокчейне в течение 2 минут).
  2. При возникновении каких-либо проблем с доступом к EthGasStation по API, используется fallback-алгоритм для самостоятельной оценки комиссии на основании данных из pending pool-а Ethereum.

Fallback-алгоритм оценки комиссий Ethereum

Самостоятельная оценка комиссий за транзакцию Ethereum (в случае надобности) происходит с помощью такого алгоритма:

  1. С помощью API txpool_content узлов сети Ethereum, рассматриваются все транзакции в pending-pool-е, которые имеют шанс попасть в следующие блоки.
  2. Из эмпирического расчёта, что в один блок обычно попадает примерно 130 транзакций, и один блок генерируется примерно раз в 15 секунд (4 блока в минуту), рассматриваются N наилучших транзакций в pending pool-е – т.е., кандидатов на попадание в блокчейн в течение ожидаемого времени. Комиссия берётся такой, чтобы минимально превосходить «худшие» транзакции из такого списка кандидатов. Константа N вычисляется следующим образом:
  • для “FAST”-транзакций (что и используется на практике для выбора комиссии): попадание в блокчейн в течение 2 минут; т.е. N = 2 × 130 × 4 = 1 040.
  • для “NORMAL”-транзакций: попадание в блокчейн в течение 5 минут; т.е. N = 5 × 130 × 4 = 2 600.
  • для “SLOW”-транзакций: попадание в блокчейн в течение 30 минут; т.е. N = 30 × 130 × 4 = 15 600.

То есть, в случае недоступности API EthGasStation,

  • выбираются 1 040 транзакций с минимальной комиссией,
  • находится минимальная комиссия из этих 1 040 транзакций,
  • комиссия для создаваемой транзакции выставляется чуть выше такой минимальной комиссии.