Son zamanlarda işlem formatları hakkında yapılan detaylı düşünmelerin (sadece 8141 değil, aynı zamanda "durumun geleceği" tartışmaları da dahil olmak üzere UTXO'lar, PBT, anahtarlanmış nonceler ve özyinelemeli STARK mempool gibi) olumlu bir sonucu, işlemlerin "eylemler" ve "bağımlılıklar" nasıl sahip olduğunu çok daha açık bir şekilde anlamamız ve bu ikisini ayrı ayrı optimize etmek için mühendislik yapabilmemizdir. Bir eylem, bir işlemin sahip olduğu bir etkidir. Bir bağımlılık, işlemin ve/veya durumun geçerli olabilmesi için doğru olması gereken bir gerçektir. Örneğin: bir imza bir bağımlılıktır, bir UTXO'nun Merkle kanıtı bir bağımlılıktır, bir ZK-SNARK (veya STARK) bir bağımlılıktır, ETH gönderen bir çağrı bir eylemdir. Bağımlılıklar paralel olarak işlenebilir. Durumla ilgili bağımlılıklar, özellikle erişilen belirli durum statik olarak bildirilmişse, mempool tarafından analiz edilebilir. Saf (durum çağrısı izin verilmeyen) bağımlılıklar, mempool katmanında yalnızca bir kez işlenebilir ve daha sonra asla tekrar işlenmeye gerek kalmaz - hatta bunlar, yalnızca yürütme değil aynı zamanda verinin de atlanmasını mümkün kılan onları doğrulayan bir STARK ile değiştirilebilir. Prensip olarak, bağımlılıklar ve eylemler tümü çağrılar olarak ifade edilebilir (gerekirse önceden derlenmişlere çağrılar). Bu, işlem formatını kendisini çok basit ve minimalist hale getirir (bir çağrı listesi, her çağrının türü için bayraklar - örneğin bağımlılıklar statik veya saf çağrılar olacak - ve köken, nonce vb.) ve farklı EVM zincirlerinin farklı özelliklere sahip olsa bile maksimum çapraz uyumluluğu sağlar. 2015 yıllarındaki Ethereum'da bu farklılıklar üzerinde açıkça düşünmek çok önemli değildi: yürütme yürütme idi, işlemler o kadar azdı ki hepsini sıralı olarak işleyebiliyorduk ve tek anahtarlı ECDSA hesapları herkes için yeterliydi. Ancak Ethereum'un şu anki ölçeklendirme stratejisi, bu paradigmadan aşmak gerektiriyor. Ethereum, birçok geliştirici tarafından çok dinamik ve esnek olan yürütme ve durum modeli nedeniyle seviliyor. Ancak dinamik ve esnek olmak ölçeklendirme için dostça değildir. Ne var ki, Ethereum'un hacim açısından >%90'ı dinamik ve esnek bir şey gerektirmiyor. Bu nedenle, sözleşmelerin, hesapların ve işlemlerin neyin dinamik ve esnek olduğunu, neyin daha statik olarak analiz edilebilir ancak daha kısıtlayıcı olduğunu açıkça belirtmesini gerektiriyor; ve daha statik olarak analiz edilebilir şeyler en düşük gaz maliyetine sahip olacak ve böylece en çok ölçeklenecek. Temelde, 2015-era Ethereum modelinin en iyi yönlerinden ve daha Bitcoin benzeri bir modelden (hatırlatma: Bitcoin, benim dediğim gibi hesap soyutlamasına baştan beri sahiptir) ders almak ve ikisinin bir karışımını (gerçekten, ikisi arasındaki tam spektrumu) mevcut hale getirmek, bu süreçteki ölçeklendirme düzeyine uygun gaz maliyetleriyle. Yeni durum türleri, özyinelemeli STARK mempool, anahtarlanmış nonceler vb. tümü bu yönde ilerliyor. Bunların tümü işlem türleriyle ilgilidir, çünkü genel amaçlı bir işlem türü, bunların tümünün uygulanabileceği çok doğal bir arayüz katmanıdır ve EIP-8141 işlem türü etrafındaki şu anki düşünceler tam olarak bu yönde ilerliyor; bu tür gelecekteki genelleştirmelere dostça. Bu açıdan bakıldığında, iyi yapılmış 8141 sadece 10 yıllık hesap soyutlama çalışmasının bir sonucu değil, aynı zamanda önümüzdeki birkaç yıl için sorumlu, merkeziyetsizlik dostu hiper-ölçeklendirme için de bir hazırlıktır.