Як працюють акаунти Ethereum під капотом

Ethereum використовує два типи рахунків: рахунки, що належать зовнішнім особам (EOA), та рахунки контрактів. EOA контролюються приватними ключами і використовуються особами або додатками для підписання транзакцій. Ці рахунки мають просту структуру. Вони містять nonce, баланс та асоційований публічний ключ, але не мають внутрішнього коду. Коли користувач підписує транзакцію з EOA, Ethereum Virtual Machine (EVM) перевіряє підпис і знімає плату за газ перед виконанням транзакції. Рахунки контрактів, навпаки, контролюються кодом і не ініціюють дії самостійно. Вони лише відповідають на транзакції, ініційовані EOA. EVM обробляє логіку контрактів і зберігає стан, але контракт не може самостійно підписувати транзакції або ініціювати їх без зовнішнього вводу.

Ця архітектура обмежує функціональність рахунків в Ethereum. Оскільки вся активність повинна походити від EOAs, а кожна транзакція вимагає дійсного криптографічного підпису, такі розширені функції, як багатофакторна аутентифікація, соціальне відновлення та пакетні операції, вимагають складних обхідних рішень. Ці обмеження стали причиною виникнення концепції абстракції рахунків — щоб зробити всі рахунки програмованими та уніфікувати відмінність між діяльністю, контрольованою користувачем, і діяльністю, контрольованою контрактом.

Як абстракція рахунку змінює валідацію транзакцій, газ та доступ

Абстракція рахунку змінює шлях валідації транзакцій, дозволяючи самому рахунку визначати, як дії схвалюються та виконуються. Замість того, щоб вимагати підпис від конкретного приватного ключа, гаманець смарт-контракту може визначити свою власну логіку для аутентифікації. Ця логіка може включати підписи з пороговим значенням, перевірки апаратних пристроїв або правила для лімітів витрат та часових блокувань.

Однією з найзначніших змін, введених абстракцією облікових записів, є розділення оплати газу від відправника. Традиційно ініціатор транзакції повинен платити за газ в ETH. Завдяки абстракції облікових записів логіка валідації може дозволити третім сторонам — званим платниками — покривати газові збори від імені користувача. Це відкриває нові можливості, такі як спонсорування транзакцій для нових користувачів, можливість взаємодії з dApp без газу або сплата зборів у стейблкоїнах або корінних токенах проекту.

Крім того, абстракція облікового запису вводить можливість об'єднувати кілька операцій в один транзакцію. Наприклад, користувач може затвердити токен, виконати обмін і перевести кошти в одній дії, зменшуючи кількість підтверджень, що потрібні, і покращуючи досвід користувача. Ці вдосконалення значно зменшують тертя в взаємодії з dApp, забезпечуючи при цьому безпеку та композованість.

Вступ до ERC-4337 та "альтернативного мемпулу"

ERC-4337, завершений у 2023 році, є важливою віхою у розвитку Ethereum до абстракції облікових записів. На відміну від попередніх пропозицій, таких як EIP-2938, ERC-4337 не вимагає змін до консенсусного рівня Ethereum. Натомість він працює повністю в межах існуючого середовища смарт-контрактів, вводячи паралельний потік транзакцій за допомогою альтернативної мемпулу та специфічної архітектури контракту.

Згідно з ERC-4337, транзакції замінюються UserOperations — об'єктами даних, які описують бажані дії, але не подаються в традиційний мемпул. Ці UserOperations беруться спеціалізованими офчейн-акторами, відомими як бандлери. Бандлер агрегує кілька UserOperations в стандартну транзакцію Ethereum і подає її до блокчейну.

В мережі, синглтон-контракт під назвою EntryPoint перевіряє та обробляє ці згруповані операції. EntryPoint взаємодіє з розумними рахунками користувачів, які визначають власну логіку валідації та делегують виконання транзакцій після їх валідації. Для сплати комісій за газ рахунки можуть за бажанням взаємодіяти з платниками, які спонсорують витрати на виконання за умовами, зазначеними в коді.

Ця структура забезпечує децентралізований, бездозвільний спосіб підтримки абстракції облікових записів без зміни базового протоколу Ethereum. У результаті розробники можуть розгортати гаманці смарт-контрактів, які з точки зору користувача ведуть себе як EOA, але пропонують набагато більшу функціональність.

Підхід Solana: Нативна абстракція рахунку

Solana підходить до абстракції облікових записів принципово по-іншому, підтримуючи це на рівні протоколу. Облікові записи Solana не поділяються на EOA та облікові записи контрактів. Натомість усі облікові записи в Solana є загальними контейнерами для зберігання, які можуть зберігати дані, мати власника та взаємодіяти з програмами.

У моделі Solana валідація дій закладена безпосередньо в програми (смарт-контракти). Програмні похідні адреси (PDA) є ключовим елементом цієї системи. Це детерміновані адреси, що генеруються з насіння та програм, які не мають асоційованого приватного ключа. Натомість вони контролюються логікою програми і можуть виконувати дії, коли виконуються відповідні умови.

Завдяки цій рідній гнучкості Solana пропонує функції, такі як авторизація з багатьма підписами, делегування рахунків та оплату зборів третьою стороною без необхідності у зовнішніх стандартах або симульованих транзакційних потоках. Гаманці, такі як Phantom і Solflare, рано інтегрували ці можливості, демонструючи безшовний UX та програмований контроль за коштами. Це контрастує з Ethereum, де подібна функціональність залежить від накладок, таких як ERC-4337 та мережі бандлерів.