Одна з позитивних наслідків всієї останньої детальної роботи над форматами транзакцій — не лише 8141, але й обговорень «майбутнього стану», наприклад, UTXO, PBT, ключових nonce, а також рекурсивного STARK mempool — полягає в тому, що ми отримали значно більш чітке розуміння того, як транзакції мають «дії» та «залежності», і ми можемо інженерно оптимізувати ці дві складові окремо. Дія — це ефект, який має транзакція. Залежність — це факт про транзакцію і/або стан, який повинен бути істинним, щоб транзакція була дійсною. Наприклад: підпис — це залежність, доказ Меркла UTXO — це залежність, ZK-SNARK (або STARK) — це залежність, виклик, що надсилає ETH — це дія. Залежності можна обробляти паралельно. Залежності, що стосуються стану, можна аналізувати за допомогою mempool, особливо якщо конкретний стан, до якого звертаються, статично оголошений. Залежності, що є чистими (без дозволу викликів стану), можна обробити один раз на рівні mempool і ніколи більше не потребувати повторної обробки — і навіть потенційно замінити їх STARK, що їх перевіряє, дозволяючи не лише виконання, але й дані виключити. За принципом, залежності та дії можна виразити як виклики (якщо потрібно — до пре-компайлів). Це зробило б сам формат транзакції дуже мінімалістичним (список викликів, прапорці для типу кожного виклику, наприклад: залежності будуть статичними або чистими викликами, а також origin, nonce тощо) і забезпечило б максимальну крос-сумісність, навіть якщо різні EVM-ланцюги мають різні функції. У Ethereum 2015 року явне розуміння цих відмінностей не було дуже важливим: виконання було виконанням, транзакцій було достатньо мало, щоб обробляти їх усі послідовно, а аккаунти з одним ключем ECDSA були достатніми для всіх. Проте поточна стратегія масштабування Ethereum вимагає вийти за межі цього патерну. Ethereum коштує багатьом розробникам саме тому, що модель виконання та стану дуже динамічна й гнучка. Але динамічність і гнучкість не сприяють масштабуванню. На щастя, >90% активності Ethereum за обсягом не вимагає нічого динамічного чи гнучкого. Тож ми вимагаємо, щоб контракти, аккаунти та транзакції явно вказували, що є динамічним і гнучким, а що — більш статично аналізованим, але обмеженим; і речі, що більш статично аналізуються, отримують найнижчу вартість газу і таким чином масштабуються найкраще. Ефективно — ми вивчаємо найкраще з обох моделей: Ethereum 2015 року та більш Bitcoin-подібної моделі (нагадування: Bitcoin мав те, що я називаю абстракцією аккаунтів з самого початку), і надаємо суміш обох (насправді — повний спектр між ними), з вартостями газу, відповідними рівню масштабування. Нові типи стану, рекурсивний STARK mempool, ключові nonce тощо — все це йде у цьому напрямку. Це все пов’язано з типами транзакцій, бо універсальний тип транзакції є дуже природним інтерфейсним шаром, на якому можна реалізувати все це. Поточне мислення щодо типу транзакції EIP-8141 йде саме у цьому напрямку — дружньому до таких майбутніх узагальнень. Отже, у цьому сенсі добре реалізований 8141 — це не лише підсумок 10 років роботи над абстракцією аккаунтів, а й підготовка до наступних кроків в напрямку відповідального гипер-масштабування з урахуванням децентралізації.