Account abstraction (ERC-4337). Часть 19

Переходим к заключительной части статей от Alchemy, которые разберем в течение этих двух дней. И сегодня мы поговорим о совокупности подписей (Aggregate signatures).

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

Разве не было бы здорово проверять множество операций одновременно с помощью одной подписи вместо многих?

Для этого используется концепция из криптографии - агрегированные подписи.

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

Частым примером схемы подписи, поддерживающей агрегирование, является BLS.

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

Введение в агрегаторы

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

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

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

Схема агрегации определяется тем, как она объединяет несколько подписей в одну и как она проверяет объединенную подпись, поэтому агрегатор раскрывает эти две функции как методы:

contract Aggregator {
    function aggregateSignatures(UserOperation[] ops)
      returns (bytes aggregatedSignature);
  
    function validateSignatures(UserOperation[] ops, bytes signature);
  }

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

Если кошелек хочет участвовать в агрегации, он предоставляет метод для выбора агрегатора:

contract Wallet {
    // ...
  
    function getAggregator() returns (address);
  }

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

Такая группа может выглядеть следующим образом:

struct UserOpsPerAggregator {
    UserOperation[] ops;
    address aggregator;
    bytes combinedSignature;
  }

P.S. Если бандлер знает о конкретном агрегаторе, то он может оптимизировать работу, жестко закодировав (hardcode) собственную версию алгоритма агрегации подписей, вместо того чтобы запускать aggregateSignatures.

Вспомните, что у нашего контракта есть метод handleOps, который принимает список агрегаторов.

Мы создадим новый метод, handleAggregatedOps, который будет делать то же самое, но будет принимать операции, сгруппированные по агрегаторам:

contract EntryPoint {
  function handleOps(UserOperation[] ops);

  function handleAggregatedOps(UserOpsPerAggregator[] ops);

  // ...
}

Новый метод, handleAggregatedOps, работает в основном так же, как и handleOps. Единственное отличие заключается в шаге проверки.

Если handleOps выполняет проверку путем вызова метода validateOp каждого кошелька, то handleAggregatedOps вместо этого вызывает метод validateSignatures агрегатора для объединенной подписи каждой группы, используя агрегатор этой группы.

Но здесь есть одна проблема, которая нам уже хорошо знакома.