Satu kesan positif daripada pemikiran terperinci terkini mengenai format transaksi—bukan sahaja 8141, tetapi juga perbincangan “masa depan keadaan” seperti UTXO, PBT, nonces berkey, dan mempool STARK rekursif—ialah kita kini mempunyai pemahaman yang jauh lebih jelas mengenai bagaimana transaksi mempunyai “tindakan” dan “ketergantungan”, dan kita boleh rekabentuk untuk mengoptimumkan kedua-duanya secara berasingan. Sebuah tindakan ialah kesan yang dimiliki oleh transaksi. Sebuah ketergantungan ialah fakta mengenai transaksi dan/atau keadaan yang mesti benar supaya transaksi itu sah. Contohnya: tanda tangan ialah ketergantungan, bukti Merkle bagi UTXO ialah ketergantungan, ZK-SNARK (atau STARK) ialah ketergantungan, panggilan yang menghantar ETH ialah tindakan. Ketergantungan boleh diproses secara selari. Ketergantungan yang melibatkan keadaan boleh dipertimbangkan oleh mempool, terutamanya jika keadaan spesifik yang diakses dinyatakan secara statik. Ketergantungan yang tulen (tiada panggilan keadaan dibenarkan) boleh diproses sekali sahaja pada lapisan mempool dan tidak perlu diproses lagi—dan bahkan boleh digantikan dengan STARK yang mengesahkannya, membolehkan bukan sahaja pelaksanaan tetapi juga data dihilangkan. Secara prinsip, ketergantungan dan tindakan semuanya boleh diungkapkan sebagai panggilan (jika perlu, panggilan ke precompile). Ini akan menjadikan format transaksi itu sendiri sangat ringkas dan minimalis (senarai panggilan, flag untuk jenis setiap panggilan—contohnya, ketergantungan akan menjadi panggilan statik atau tulen, serta asal, nonce, dsb) dan membolehkan kompatibiliti silang maksimum walaupun rantai EVM yang berbeza mempunyai ciri yang berbeza. Pada era Ethereum 2015, pemikiran secara eksplisit mengenai perbezaan ini tidak terlalu penting: pelaksanaan ialah pelaksanaan, terdapat sedikit transaksi sehingga kita boleh memprosesnya secara siri, dan akaun ECDSA satu-kunci cukup baik untuk semua orang. Strategi penskalaan semasa Ethereum, bagaimanapun, memerlukan kita melangkau paradigma itu. Ethereum disukai oleh ramai pembangun kerana model pelaksanaan dan keadaannya sangat dinamik dan fleksibel. Tetapi dinamik dan fleksibel bukanlah mesra penskalaan. Untungnya, >90% aktiviti Ethereum mengikut volum tidak memerlukan apa-apa yang dinamik dan fleksibel. Oleh itu, kita memerlukan kontrak, akaun, dan transaksi untuk lebih eksplisit menentukan apa yang dinamik dan fleksibel serta apa yang lebih boleh dianalisis secara statik tetapi lebih terhad, dan perkara-perkara yang lebih boleh dianalisis secara statik akan mendapat kos gas paling rendah dan dengan itu berskala paling tinggi. Secara efektif, belajar daripada terbaik kedua-dua model Ethereum era 2015 dan model seperti Bitcoin (ingat: Bitcoin telah mempunyai apa yang saya sebut sebagai abstraksi akaun sejak permulaannya), dan membuat campuran keduanya (sebenarnya, spektrum penuh antara keduanya) tersedia, dengan kos gas yang sesuai dengan tahap penskalaan yang terlibat. Jenis keadaan baru, mempool STARK rekursif, nonces berkey, dsb semuanya bergerak ke arah ini. Semua ini berkaitan dengan jenis transaksi, kerana jenis transaksi generik ialah lapisan antaramuka yang sangat semula jadi di atasnya semua ini boleh dilaksanakan, dan pemikiran semasa mengenai jenis transaksi EIP-8141 sedang bergerak tepat ke arah ini—yang mesra kepada generalisasi masa depan sebegini. Oleh itu, dalam pengertian itu, 8141 yang dilaksanakan dengan baik bukan sahaja merupakan puncak kepada 10 tahun kerja abstraksi akaun, tetapi juga persiapan bagi beberapa tahun ke depan dalam penskalaan hiper yang mesra kepada desentralisasi.