Как мы масштабировали мета-транзакции в Origin

Майк Шульц

Введение

Несколько недель назад Ник представил концепцию мета-транзакций. Вкратце, мета-транзакции - это то, как мы спонсируем комиссию за транзакции Ethereum для наших пользователей. Ключевым компонентом потока мета-транзакций является наш ретранслятор, который отправляет транзакции от имени наших пользователей в прокси-контракты.

Ретранслятор отправляет транзакции от имени наших пользователей маркетплейс DApp

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

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

Решение

Нам нужна была абстракция учетной записи, которая позволила бы ретранслятору обрабатывать транзакции одновременно. Знакомьтесь с Purse, составляющая нашего ретранслятора с открытым исходным кодом, которая обеспечивает уровень абстракции для моментального запуска транзакций в эфир (Ха). Наш ретранслятор может принимать множество транзакций ({to: "Alice's proxy", value: 0, data: 0x1234}), и передавать в Purse одновременно с обратным вызовом, когда транзакция будет завершена, затем кошелек сделает все остальное.

// "Look at my simple interface!" - Purse

const result = await purse.sendTx({

to: proxy,

value: 0,

data: '0x01'

},

(receipt) => {

if (!receipt.status) {

console.error('Oh no!')

}

})

console.log('tx hash: ', result.txHash)

Поскольку прокси-контракты следят только за тем, чтобы транзакция была подписана владельцем, а не за тем, какая учетная запись фактически отправляет транзакцию, вы можете отправить ее из любой доступной учетной записи. Purse был разработан, чтобы работать с любым количеством учетных записей. Вы можете выполнять транзакции с 1 или 1000 отправителями. Он использует «стандартизированный» этап реализации многоуровневого детерминированного кошелька (см. обсуждение ERC 84) для создания учетных записей по мере необходимости из одной мнемонической фазы BIP39. Это обеспечило гибкость, которая была необходима для масштабирования.

Purse является составной частью ретранслятора

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

Несмотря на то, что мы можем запускать несколько транзакций одновременно, это должно быть в пределах ограниченного объема транзакций нашего провайдера JSON-RPC. Мы не можем просто отправить миллион транзакций с одного аккаунта одновременно. go-Ethereum назначает по умолчанию 16 транзакций для каждой учетной записи, а Parity использует более усложненную логическую схему, чтобы решить, когда чистить память ожидающих транзакций. Для этого мы просто добавили произвольный лимит, который мы можем корректировать по своему усмотрению. Проще и надежнее масштабировать с большим количеством учетных записей, чем углубляться в ожидающие транзакции.

Еще одной целью Purse было упростить и автоматизировать процесс финансирования дочерних учетных записей. Дочерние учетные записи необходимо финансировать, чтобы они могли оплачивать расходы на газ при отправке транзакций в сеть Ethereum. Мы не хотели вручную отправлять Ether на все вторичные аккаунты. Это был бы сложный для нашей команды и потенциально подверженный ошибкам процесс. Purse берет средства на один основной счет и финансирует все дочерние счета без какого-либо ручного вмешательства. По сути, Purse отслеживает дочерние счета и автоматически их пополняет, когда это необходимо.

Трудности

Одной из самых больших трудностей было решать проблемы с ненадежностью провайдеров JSON-RPC. Даже у лучших провайдеров иногда возникают проблемы, которые могут (и наносят) нанести вред ретранслятору или привести Purse в неблагоприятное состояние. Нам нужно было обрабатывать пропущенные транзакции, 500 ошибок, сбои в подключении соединения и даже ошибки в Purse. Нашей первой задачей было создать надежный мониторинг и регистрирование, на которые мы могли бы положиться при обнаружении любой проблемы. Мы регистрировали сведения о транзакциях и их состояние в PostgresDB и оснащали код измерительные метриками, зарегистрированными в Prometheus. Затем мы создали набор информационных панелей в Grafana, а также бизнес-панель, используя Metabase, чтобы мы могли наглядно видеть поведение системы. Это позволило нам быстро обнаруживать и диагностировать ошибки в случаях неполадки, когда мы запускали Purse в производство.

Попытка получить выгодные цены на газ также была проблемой. Для помощи в устранении ошибок и ценами на газ, мы внедрили нашего собственного провайдера web3.js, @ origin / web3-provider, созданного на web3-provider-engine, но это может быть темой для другой статьи. Устранение ошибок JSON-RPC было систематически недостатком, но безопасность совершенствуется.

Отслеживание одноразовых номеров также требует особого внимания. Особенно, когда Kubernetes модуль может быть разрушен и воссоздан в любую минуту. Purse фиксирует одноразовый номер в памяти, в Redis, и в крайнем случае может обращаться к провайдеру JSON-RPC, если остальные дадут сбой.

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

Текущее состояние

После бета-версии, Purse теперь является стабильной составной частью платформы Origin. На момент написания этой статьи наш ретранслятор обработал более 9 000 транзакций, в среднем по 4 запроса на пользователя, создал более 2500 прокси контрактов, 213 листингов, потребил 1 069 786 764 газа и сэкономил нашим пользователям почти 11 Ether сетевых сборов.

Будущее

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

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

Если вы хотите принять участие в улучшении платформы Origin Protocol, присоединяйтесь к нам и скажите hi в разделе #engineering в Discord. Мы ищем талантливых участников, которые помогут нам в достижении нашей миссии по созданию открытой исходной и действительно одноранговой торговой платформы для всех!

Узнайте больше про Origin:

● Покупайте и продавайте на мобильном телефоне: originprotocol.com/mobile

● И в Интернете: shoporigin.com

● Узнайте больше на нашем сайте: originprotocol.com

● VK: vk.com/originprotocol

Спасибо Колману Мэйхеру.