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

Подведение итогов

То, что мы создали здесь, является более или менее полной архитектурой ERC-4337! Есть некоторые различия в деталях, например, в названиях и аргументах некоторых методов, но нет ничего, что я бы счел архитектурным различием.

Отличия данного цикла постов от ERC-4337

Несмотря на то, что общая архитектура account abstraction у нас уже есть, умные люди, стоящие за ERC-4337, придумали некоторые вещи, которые несколько отличаются от того, что мы описали выше.

Давайте рассмотрим некоторые из них!

1. Временные диапазоны валидации

Выше я довольно нечетко описал тип возвращаемы данных validateOp кошелька и validatePaymasterOp от paymaster. В ERC-4337 есть хороший способ использовать это.

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

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

Таким образом, ERC-4337 дает validateOp возвращаемое значение, которое кошелек может использовать для выбора временного диапазона:

contract Wallet {
  function validateOp(UserOperation op, uint256 requiredPayment)
    returns (uint256 sigTimeRange);
  // ...
}

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

Еще одно замечание из ERC-4337: кошельки должны возвращать значение sentinel из validateOp, и не делать этого в случае неудачи валидации, что помогает при оценке газа, поскольку eth_estimateGas не сообщает, сколько газа было использовано в транзакции, которая откатывается.

2. Произвольные вызовы для кошельков и фабрик

Ранее мы разбирали, что интерфейс нашего кошелька:

contract Wallet {
    function validateOp(UserOperation op, uint256 requiredPayment);
    function executeOp(UserOperation op);
  }

В ERC-4337 у кошельков на самом деле нет метода с именем executeOp.

Вместо этого у пользовательской операции есть поле CallData:

struct UserOperation {
    // ...
    bytes callData;
  }

Эти данные передаются кошельку в качестве данных вызова.

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

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

Аналогично, в ERC-4337 фабричные контракты фактически не имеют метода deployContract. Они тоже получают произвольные данные для вызова, в данном случае из поля initCode операции.

3. Компактные данные для paymasters и фабрик

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

struct UserOperation {
    // ...
    address paymaster;
    bytes paymasterData;
  }

В ERC-4337 они объединены в одно поле в качестве оптимизации, где первые 20 байт поля - это адрес paymaster, а остальные - данные:

struct UserOperation {
    // ...
    address paymaster;
    bytes paymasterData;
  }

То же самое касается фабрик и отправляемых им данных: если мы использовали два поля factory и factoryData, то ERC-4337 объединяет их в одно поле initCode.

Ну, вот собственно и все! За 20 постов мы перевели 4 прекрасные статьи от Alchemy! А завтра посмотрим видео от Патрика на эту тему!

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