Paymaster staking
В предыдущих постах мы описывали ситуацию, где кошелек возвращал деньги за газ. Бандлер использовал симуляцию, чтобы попытаться избежать выполнения операций, которые не прошли проверку, так как это означало, что кошелек не заплатит, и в итоге он окажется "на крючке" с потраченными деньгами.
Здесь возникает та же проблема:
Бандлер хочет избежать отправки операций, которые не прошли проверку paymaster, потому что paymaster не заплатит, и бандлер снова окажется в минусе.
Сначала кажется, что мы можем наложить на validatePaymasterOp те же ограничения, что и на validateOp (т. е. он может обращаться только к хранилищу кошелька и своему собственному связанному хранилищу и не может использовать запрещенные опкоды), и тогда бандлер может просто симулировать validatePaymasterOp для пользовательской операции в то же время, когда он симулирует validateOp кошелька.
Но здесь есть одна загвоздка.
Из-за ограничения на хранение, согласно которому валидатор кошелька может обращаться только к связанному с ним хранилищу, мы знали, что валидации нескольких операций в пачке не могут мешать друг другу, если они происходят из разных кошельков, поскольку они обращаются к очень небольшому общему хранилищу.
Но хранилище paymaster'а является общим для всех операций в пакете, которые используют этот paymaster.
Это означает, что действия одного validatePaymasterOp потенциально могут привести к сбою проверки для множества других операций в пакете, использующих этот же paymaster.
Вредоносный paymaster может использовать это для DoS-атаки на систему.
Чтобы предотвратить это, мы ввели систему репутации.
Мы заставим бандлер отслеживать, как часто paymaster не проходил валидацию в последнее время, и наказывать тех, которые имели множество проблем, путём запрета операций.
Такая система может не сработать, в случае если вредоносный paymaster просто создаст множество своих копий (атака Sybil). Именно поэтому мы потребуем, чтобы paymaster ставили на кон свой Эфир. Таким образом, наличие нескольких аккаунтов не принесет ему выгоды.
Давайте добавим новые методы для работы со стейкингом:
contract EntryPoint {
// ...
function addStake() payable;
function unlockStake();
function withdrawStake(address payable destination);
}Как только сделан депозит Эфира, он не может быть снят до тех пор, пока не пройдет некоторая задержка (delay) после вызова unlockStake.
Эти новые методы отличаются от ранее рассмотренных функций deposit и withdrawTo, которые используются кошельками и paymaster'ами для пополнения ETH, и могут быть использованы для оплаты газа или немедленно сняты в любой момент.
Существует исключений из правил:
Если paymaster обращается только к связанному с кошельком хранилищу, а не к своему собственному, то ему не нужно делать ставку (stake ETH), потому что в этом случае, хранилища, к которым обращаются несколько операторов в связке, не будут пересекаться друг с другом.
Кроме того, каждый бандлер отслеживает репутацию локально, поэтому код бандлера может реализовать свою собственную логику репутации, если он считает, что может сделать работу лучше и не создаст проблем для других бандлеров.
P.S. В отличие от многих других схем ставок (stake ETH), здесь ставки никогда не снижаются. Они существуют просто как способ заставить потенциального злоумышленника заблокировать очень большую сумму капитала для проведения масштабной атаки.
#accountabstraction