Вы здесь

Что такое ретранслятор транзакций и как он работает?

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

Что такое ретранслятор транзакций и как он работает?

Включение транзакции в блок может стать настоящей головной болью. Поскольку размер блоков ограничен, майнеры будут отдавать приоритет транзакциям с самой высокой ценой на газ.

Почему возникают такие ситуации и как ретранслятор транзакций может нам помочь?

Почему включение транзакций в блок вызывает сложности?

Для информации: очередность транзакций в сети Ethereum определяется порядковым номером транзакции, который называется «nonсe». Каждый счет в сети имеет свой nonce, который растет с каждой последующей транзакцией. Таким образом, первая транзакция, выполненная со счета, будет иметь nonce 1, а третья – nonce 3.

Транзакции должны исполняться в правильном порядке: третья транзакция, совершаемая со счета, не может быть включена в блок и исполнена до второй транзакции.

Если между несколькими счетами возникнет конкурентная борьба за право первым провести сделку, цена на газ резко увеличится. Представьте себе сценарий, если какой-то счет захочет отправить транзакцию с чересчур низкой ценой на газ, тогда такая транзакция «застрянет» в потоке более выгодных для майнеров транзакций.

Когда nonce, привязанный к счету, не растет, все транзакции по этому счету, инициируемые с момента инцидента, также зависают.

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

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

Эту задачу, о которой стало известно благодаря Cryptokitty и ICO, теперь приходится решать децентрализованным финансовым протоколам. К счастью, эти проблемы не являются постоянными для сети Ethereum.

Но когда они возникают, для приложения это серьезный баг.

Если смотреть на эту проблему глазами пользователя, то тут можно провести аналогию с чувством разочарования, которое испытываешь, когда на какой-нибудь сайте электронной коммерции не проходит платеж; а если смотреть глазами разработчика приложения, то, помимо технической поддержки, которую приходится оказывать, это еще сравнимо с потерей дохода.

Пользователи и разработчики «унаследовали» эту неразрешимую проблему еще со времен Ethereum 1.x. Это, вероятно, и стало причиной запятнанной репутации протокола. С другой стороны, эта проблема показала, что сообщество способно объединяться для поиска решений, как, например, в случае использования мета-транзакций.

Решение на базе мета-транзакций

Концепция мета-транзакций позволяет пользователям взаимодействовать с блокчейном только с помощью пары открытых/закрытых ключей.

Этот механизм часто используется для отправки транзакций без газа, то есть транзакции, отправленной со счета (EOA) без эфира.

Со стороны пользователя отправка мета-транзакции аналогична отправке стандартной транзакции (отправитель, получатель, стоимость ... и подпись) за исключением того, что вместо отправки ее непосредственно в блокчейн, он отправляет мета-транзакцию третьей стороне, которая в свою очередь решает вопрос с газом.

Эта третья сторона создает новую транзакцию, содержащую мета-транзакцию, и отправляет ее на прокси-сервер смарт-контракта (это также может быть прокси-функция в контракте).

Контракт проверяет действительность мета-транзакции (подпись) перед ее исполнением.

Этот механизм все больше используется приложениями для улучшения адаптивного опыта пользователей. Они могут выдавать газ своим пользователям (т.е. спонсировать их таким образом), при этом сохраняя преимущества децентрализованной системы (отсутствие коррупции, возможность отказа и т.д.).

Вы можете задаться вопросом: если приложение может ретранслировать транзакции самостоятельно для своих пользователей, тогда зачем и в каких случаях нам нужен ретранслятор?

Дилемма между «сделай это сам» или «купи решение» хорошо известна разработчикам, и ответ всегда зависит от контекста.

Pizza Hut по-прежнему сама доставляет свою пиццу, когда большинство ресторанов используют Uber Eats или Deliveroo.

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

Отправляйте свои мета-транзакции, об остальном позаботится ретранслятор!

Для этого и в дополнение к улучшению проходимости транзакций в блокчейне ретрансляторы могут облегчить проведение «безгазовых» транзакций.

Как ретранслятор влияет на успешное выполнение транзакции в блокчейне?

Как объяснялось выше, для каждого отдельно взятого счета все транзакции должны быть упорядочены и последовательно проверены. Например, если вы хотите отправить 3 транзакции, то транзакция № 3 будет оставаться в процессе ожидания, пока не будут обработаны номера 1 и 2. Количество отложенных транзакций на один счет ограничено узлом (например, в Geth ограничение по умолчанию составляет 64). Когда их количество переваливает за эту цифру, узел может в произвольном порядке удалять транзакции из очереди.

Чтобы обойти эти ограничения, ретранслятор может прибегнуть к отправке мета-транзакций с нескольких счетов. Действительно, если у вас три счета, то количество транзакций, которые могут быть отложены в узле, увеличивается с 64 до 192 при использовании Geth. Кроме того, когда транзакция зависает на одном из счетов, ретранслятор может переместить ее на один из двух оставшихся счетов и, таким образом, продолжить отправлять свои транзакции.

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

Действительно, некоторые приложения могут требовать отправки транзакций последовательно, а другие – одновременно. В зависимости от сферы использования и объема транзакций, в некоторых случаях может потребоваться оптимизация затрат на хранение системы защиты от атак воспроизведения, в то время как в других случаях такие сложные реализации могут и не потребоваться. Ретрансляторы позволяют разработчикам избавиться от этих комплексных проблем, предоставляя простые и готовые к использованию услуги.

Как ретранслятор облегчает осуществление безгазовых транзакций?

Если вы хотите внести изменение в смарт-контракт, или отправить транзакцию, или сделать что-либо в сети Ethereum, вам необходимо иметь на своем счету эфир. Это крайне усложняет пользователям жизнь и не способствует притоку новых юзеров. Ни о каком высоком коэффициенте конверсии не может быть и речи, пока от пользователей требуется покупка эфира, прежде чем они получат возможность использовать приложение.

Для устранения этого недостатка некоторые приложения предлагают своим пользователям просто-напросто платить за газ от их лица. Этот подход часто игнорируется разработчиками, так как он далек от философии протокола, которая заточена на обеспечение независимости в сети. В такой традиционной модели приложение рассматривает газ как стоимость инфраструктуры (аналогично потреблению тех же процессоров в системах AWS). Поскольку получение дохода, как правило, связано с использованием смарт-контрактов, эта модель в большинстве случаев экономически жизнеспособная.

Приложение и пользователи могут также договориться друг с другом в сети об автоматическом возмещении подразумеваемых расходов на газ. С появлением сервисов DeFi все больше пользователей владеют токенами без эфира. А некоторые системы позволяют своим пользователям оплачивать транзакции с помощью токена ERC20.

Приложение также может выдавать свои собственные токены пользователям при регистрации. Этот механизм сравним с распределением бесплатных купонов, которые могут быть использованы только в рамках соответствующих контрактов.

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

Как пользоваться ретранслятором?

В идеале все эти сервисы должны работать прозрачно для разработчика, то есть без изменения смарт-контрактов или кода приложения.

Услуги ретрансляции обычно предоставляются через классический веб-API. Они также могут быть доступны в качестве прокси-сервера перед «поставщиком web3» между приложением и узлом, чтобы облегчить их использование с такими библиотеками, как web3js.

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

На самом деле, функция ретранслятора довольно похожа на список ожидания узла, но она добавляет несколько существенных особенностей живым приложениям в Mainnet.

Есть ли стандарт для ретрансляторов?

Децентрализация, конфиденциальность, безопасность, простота и т.д. Выбор способа ретрансляции транзакции в Ethereum подразумевает под собой учет большого количества критериев, и, опять же, этот выбор во многом зависит от контекста.

Сеть GSN (Gas Station Network) является одной из наиболее заметных инициатив в этой области. Это решение позволило построить сеть децентрализованных ретрансляторов. При использовании ретрансляционного хаба игроки, готовые обрабатывать транзакции за комиссию, могут конкурировать друг с другом. GSN требует значительных интеграционных усилий. Это подходящее решение, когда использование ретрансляционной сети P2P является обязательным условием.
Чтобы понять, почему нет консенсуса относительно стандарта, давайте сравним два кошелька: MetaMask и Argent.xyz. Первый управляет идентификацией своих пользователей с помощью EOA, в то время как второй использует смарт-контракты.

Применение «ретрансляционного прокси» в транзакциях, отправленных из MetaMask, более сложный процесс, чем кажется на первый взгляд. Применение msg. sender в контрактах, используемых приложением, будет запрещено, поскольку он будет содержать адрес ретранслятора вместо публичного адреса пользователя.

С другой стороны, Argent.xyz использует контракт учетной записи, который должен быть развернут для каждого пользователя. Это дополнительная затрата для Argent.xyz, но проверка и ретрансляция транзакций выполняются непосредственно в этом контракте, без необходимости каких-либо изменений в целевых контрактах.

Контракты приложений также могут напрямую проверять и выполнять подпись мета-транзакций, реализуя две функции. Одну для защиты от атак воспроизведения, а другую для проверки и выполнения транзакции. Это решение имеет много преимуществ, но остается непригодным для уже развернутых контрактов.

Чтобы пойти дальше по различным философиям ретрансляции в сети Ethereum, @wighawag недавно предложил идею «минимального и расширяемого мета-экспедитора транзакций» #2585. Этот EIP показывает, насколько велика эта тема и насколько активны дебаты в сообществе.

Вывод

Приложения, требующие больших объемов транзакций, систематически платят слишком высокие сетевые комиссии, и даже это не мешает им вмешиваться, когда происходит зависание той или иной транзакции. Для небольших и только строящихся приложений создание и поддержание ретрансляционной инфраструктуры требует слишком больших инвестиций. PSPs (поставщики платежных услуг), такие как Paypal или Stripe, облегчили разработчикам прием платежей в Интернете. И даже если сеть Ethereum позволяет избавиться или ограничить полномочия третьих лиц, этот протокол должен обзавестись шлюзами для упрощения его использования. Мощность ретрансляторов «по замыслу» ограничена мета-транзакциями, поэтому они прекрасно справляются с текущими задачами разработчиков в Ethereum.

В Rockside.io мы восемь месяцев назад решили создать самый лучший ретранслятор в сети Ethereum. Мы уже обрабатываем сотни транзакций ежедневно для стартапов и крупных игроков, и поэтому мы знаем, что потребность реальна среди разработчиков. Растущее использование ретрансляторов также показывает, что отношения между компаниями и блокчейном развиваются. Мы перешли от желания понять к желанию реально использовать технологию.

Категория: 
Tutorial
1
Ваша оценка: Нет Средняя: 1 (1 оценка)
3999 / 0
Аватар пользователя Serg Demin
Публикацию добавил: Serg Demin
Дата публикации: ср, 07/22/2020 - 10:19

Что еще почитать:

Добавить комментарий