ethers.js – TypeScript библиотека для доступа к EVM блокчейнам. Я использую ее в своих проектах, и другими авторами по ней уже написаны хорошие статьи на хабре (основы, отправка транзакций). В текущей статье хочу поделиться опытом оптимизации запросов ethers js при работе с различными облачными провайдерами JSON-RPC (Alchemy, Infura) и self-hosted нодой. Расскажу о случаях, когда приложение может просто перестать работать, и что с этим делать. Приведу прикидки производительности.

В статье используется ethers.js версии 6.11, которая обратно не совместима с пятой версией из статей, приведенных выше, хотя различия довольно тривиальные и программы портируются легко.

Проблема

Нужно было реализовать фичу, которая выгружает в CSV балансы в USDT 0xc2132D05D31c914a87C6611C10748AEb04B58e8F на Полигоне некоторого количества кошельков (в тестовых данных было около 30ти). Первая реализация была примерно такая (wallets – кошельки для проверки):

const provider = new ethers.JsonRpcProvider(rpcUrl);
 
wallets.map(async (wallet) => {
  const contract = new ethers.Contract(
    "0xc2132D05D31c914a87C6611C10748AEb04B58e8F",
    abi,
    provider
  );
  const bal = await contract.balanceOf(wallet);

  console.log(`Wallet: ${wallet}, Balance: ${bal}`);
});

В качестве rpcUrl использовался бесплатный от Infura. В итоге получил зависание на 5 минут (!) и потом ошибку (сокращено для наглядности):

JsonRpcProvider failed to detect network and cannot start up; retry in 1s (perhaps the URL is wrong or the node is not started)

Error: exceeded maximum retry limit (request={ }, response={ }, error=null, code=SERVER_ERROR, version=6.6.7) at makeError

Сразу возникли 2 вопроса:

• Почему так долго?

• Почему появился retry limit на 30ти запросах?

Решение 1 – самостоятельный батчинг

Первой попыткой решения был батчинг запросов. Ethereum JSON-RPC поддерживает отправку нескольких Ethereum запросов в одном HTTP запросе. Так это выглядит через вызов curl – запрос баланса USDT на Полигоне двух кошельков 0x2066fc1cac710806c8ffcc8539ec69d6ce2ee489 и 0x5f4d4b6b59a88fd83aa754bdd12afc73f53830ec.

curl https://ethnode.mydomain.com \
  -X POST \
  -H "Content-Type: application/json" \
  -d '[
  {
    "jsonrpc": "2.0",
    "method": "eth_call",
    "params": [
      {
        "to": "0xc2132D05D31c914a87C6611C10748AEb04B58e8F",
        "data": "0x70a082310000000000000000000000002066fc1cac710806c8ffcc8539ec69d6ce2ee489"
      },
      "latest"
    ],
    "id": 1
  },
  {
    "jsonrpc": "2.0",
    "method": "eth_call",
    "params": [
      {
        "to": "0xc2132D05D31c914a87C6611C10748AEb04B58e8F",
        "data": "0x70a082310000000000000000000000005f4d4b6b59a88fd83aa754bdd12afc73f53830ec"
      },
      "latest"
    ],
    "id": 1
  }
]
'

В ethers.js это можно сделать так (некоторые детали и импорты опущены):

const createPayload = async (
  token: string,
  wallet: string,
  provider: ethers.JsonRpcProvider
) => {
  const contract = new ethers.Contract(token, abi, provider);
  const byContract = await contract.balanceOf.populateTransaction(wallet);

  return {
    method: "eth_call",
    id: 1,
    params: [byContract, "latest"],
    jsonrpc: "2.0",
  } as JsonRpcPayload;
};

const provider = new ethers.JsonRpcProvider(rpcUrl);

const payloads = await Promise.all(
  wallets.map(async (wallet) => {
    return {
      payload: createPayload(
        "0xc2132D05D31c914a87C6611C10748AEb04B58e8F",
        wallet,
        provider
      ),
      wallet: wallet,
    };
  })
);

const res = await provider._send(
  await Promise.all(payloads.map((p) => p.payload))
);

// print res

Используется функция JsonRpcProvider._send, которая принимает массив ethers.JsonRpcPayload и отправляет это в одном HTTP запросе. По сути, это то же самое, что вызов curl выше, просто создано программно.

contract.balanceOf.populateTransaction(wallet) – это удобный способ, чтобы сконструировать calldata, состоящая из сигнатуры функции balanceOf (0x70a08231) и адреса кошелька.

Запустив код выше с 30ю кошельками, получил ту же самую ошибку ("exceeded maximum retry limit") с зависанием на 5 минут. Путем сокращения количества кошельков было найдено ограничение в 10 JSON-RPC запросов в одном HTTP запросе на бесплатном плане Infura.

Решил попробовать сравнить с бесплатным Alchemy и self-hosted нодой эфира на Geth:

Также, когда отправлял на свою ноду большой батч (более 5200 запросов), получал HTTP 413 Request Entity Too Large.

Решение 2 – батчинг от ethers

Стало понятно, что разные провайдеры по-разному отправляют ошибки и на них по-разному реагирует ethers. Начал думать, как можно разобраться со всем этим безобразием. Ведь не хочется, чтобы программа зависла на 5 минут, а также не хотелось писать свой код, чтобы разбивать запросы на батчи или что-то подобное. Начал смотреть, есть ли что-то на эту тему в ethers. Тестировал на Infura, тк самые строгие лимиты.

Оказывается, по умолчанию ethers делает батчинг запросов через JsonRpcApiProviderOptions, которые можно указать третьим параметром при создании JsonRpcProvider. Интересные параметры это:

• batchStallTime – сколько времени (в мс) добавлять запросы в текущий батч (и потом отправлять его). По умолчанию 10 мс.

• batchMaxSize – максимальный размер батч запроса в байтах (по умолчанию 1 МБ).

• batchMaxCount – максимальное кол-во JSON-RPC запросов в одном HTTP батче (по умолчанию 100).

Думаю, вы уже догадались, что нужно сделать, чтобы Infura начала работать. batchMaxCount установить в 10 (макс число запросов в одном батче), и увеличить batchStallTime, чтобы реже бомбардировать сервер запросами. У меня получалось обработать 1000 кошельков с параметрами batchMaxCount: 10, batchStallTime от 100. Непредсказуемо, какое значение batchStallTime может вызвать throttling (429 код), нужно подбирать исходя из текущей ситуации / ноды, также оно зависит от других параллельных запросов. Время выполнения balanceOf на 1000 кошельков варьировалось от 2 до 60 секунд (немалый разбег!).

  const req = new ethers.FetchRequest(rpcUrl);

  req.timeout = 10000;
  req.setThrottleParams({
    maxAttempts: 12,
  });

  const provider = new ethers.JsonRpcProvider(req, undefined, {
    batchMaxCount: 10,
    batchStallTime: 100,
  });

  await Promise.all(
    wallets.map(async (wallet) => {
      const contract = new ethers.Contract(
        "0xc2132D05D31c914a87C6611C10748AEb04B58e8F",
        abi,
        provider
      );
      const bal = await contract.balanceOf(wallet);

      console.log(`Wallet: ${wallet}, Balance: ${bal}`);
    })
  );

Еще параметры, которые влияют на выполнение HTTP запросов, их можно менять через FetchRequest:

• timeout (в мс) - по истечению этого параметра запрос генерируется исключение. По умолчанию он 300 000 (5 минут).

• FetchThrottleParams

  • maxAttempts – максимальное количество попыток запроса к серверу в случае 429 ошибки (throttling) (по умолчанию 12). Если это 1, то HTTP запрос не повторяется в случае 429 ошибки. Интересно, что в ethers 6.11 был баг – этот параметр не учитывался, и только я полез сделать PR, как обнаружил, что на гитхабе это уже поправлено, и выйдет, видимо, в 6.12 :)

Думаю, стало понятно, почему в начале было зависание на примерно 5 минут и ошибки exceeded maximum retry limit. ethers пытался отправить батчи, получал 429, повторял еще раз, и так 12 раз с определенным backoff.

Выводы

Главный вывод – разные облачные сервисы имеют разные параметры (в платной версии будет то же самое), и, если вы разрабатываете серьезное приложение, нужно определиться с инфраструктурой и затачивать приложение под нее. Быстро менять поставщиков не получится, несмотря на, кажется, универсальный интерфейс и абстракцию в виде ethers.

То же самое относится к библиотеке, ethers постоянно дорабатывается, поэтому обновление до новой версии, даже минорной, имеет высокий шанс что-нибудь сломать. Лучше провести полное тестирование приложения, особенно там где интенсивный обмен данных с JSON RPC близко к лимитам.

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

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

Код на Github https://github.com/TechGeorgii/ethers.js-performance

Минутка PR. Веду тг‑канал Web3 разработчик. Пишу небольшие заметки (не часто) о задачах по блокчейну/крипте, которые решаю. Буду рад видеть среди подписчиков!