Одним из положительных последствий недавнего детального анализа форматов транзакций — не только 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 обладал тем, что я называю абстракцией аккаунтов с самого начала), и создаем смесь обоих (на самом деле — весь спектр между ними), с соответствующей стоимостью газа для каждого уровня масштабируемости. Новые типы состояний, рекурсивный STARK-mempool, ключевые nonce и т.д. — всё это движется в этом направлении. Всё это связано с типами транзакций, поскольку общий тип транзакции является естественным интерфейсным слоем, на котором всё это может быть реализовано. Текущие размышления о типе транзакции EIP-8141 идут именно в этом направлении — совместимом с такими будущими обобщениями. Таким образом, хорошо реализованный 8141 — это не просто завершение 10 лет работы над абстракцией аккаунтов, но и подготовка к следующим годам ответственного гипер-масштабирования с учетом децентрализации.