Isang positibong epekto ng lahat ng bagong detalyadong pag-iisip tungkol sa mga format ng transaksyon – hindi lamang ang 8141, kundi pati na rin ang mga diskusyon tungkol sa “hinaharap ng estado” tulad ng UTXOs, PBT, keyed nonces, at recursive STARK mempool – ay ang mas malinaw na pag-unawa natin kung paano may “mga aksyon” at “mga depensiyang” ang mga transaksyon, at kaya nating i-engineer ang pag-optimize ng dalawa nang hiwalay. Ang isang aksyon ay isang epekto na mayroon ang isang transaksyon. Ang isang depensiyang ay isang katotohanan tungkol sa transaksyon at/o sa estado na dapat totoo upang maging wasto ang transaksyon. Halimbawa: ang isang signature ay isang depensiyang, ang isang Merkle proof ng isang UTXO ay isang depensiyang, ang isang ZK-SNARK (o STARK) ay isang depensiyang, ang isang call na nagpapadala ng ETH ay isang aksyon. Maaaring i-process nang paralelo ang mga depensiyang. Ang mga depensiyang na may kinalaman sa estado ay maaaring maipaliwanag ng isang mempool, lalo na kung ang partikular na estado na kinukuha ay statically na ipinahayag. Ang mga depensiyang na purong (hindi pinapayagan ang state calling) ay maaaring i-process nang isang beses lamang sa mempool layer at hindi na kailangan ulitin – at maaaring pati na rin palitan ng isang STARK na nag-verify sa kanila, na nagpapahintulot hindi lamang sa execution kundi pati na rin sa pag-elimina ng data. Sa prinsipyo, maaaring i-express lahat ng mga depensiyang at aksyon bilang mga call (kung kailangan, mga call sa precompiles). Ito ay gagawing sobrang simpleng at minimalist ang transaction format mismo (isang listahan ng mga call, mga flag para sa uri ng bawat call – halimbawa, ang mga depensiyang ay static o pure calls, at origin, nonce, atbp.) at nagpapahintulot sa pinakamataas na cross-compatibility kahit magkakaiba ang mga EVM chains sa kanilang mga feature. Sa Ethereum noong 2015, hindi gaanong mahalaga ang pag-iisip nang eksplisito tungkol sa mga pagkakaiba ito: ang execution ay execution lamang, masyadong kaunti ang mga transaksyon upang kailanganin nating i-process silang lahat nang serially, at ang single-key ECDSA accounts ay sapat na para sa lahat. Gayunpaman, ang kasalukuyang scaling strategy ng Ethereum ay nagsasailalim sa paglalabas sa paradigma na iyon. Mahal ng maraming developer ang Ethereum dahil ang execution at state model nito ay sobrang dinamiko at flexible. Ngunit ang dinamiko at flexible ay hindi kaaya-aya para sa scaling. Masasagot naman natin ito: higit sa 90% ng aktibidad ng Ethereum batay sa volume ay hindi nangangailangan ng anumang dinamiko o flexible. Kaya kailangan naming gawing eksplisito ng mga kontrata, account, at transaksyon kung ano ang dinamiko at flexible at kung ano ang mas statically-analyzable ngunit mas limitado; at ang mga bagay na mas statically-analyzable ay makakakuha ng pinakamababang gas cost, kaya sila ang pinakamalaking scale. Sa praktikal na pagkakaintindi, natututo tayo mula sa pinakamahusay na aspeto ng Ethereum noong 2015 at ng isang mas Bitcoin-like na modelo (paalala: mayroon nang tinatawag kong account abstraction ang Bitcoin mula sa simula), at ginagawa nating magkakasama ang pareho (totoo, buong spectrum sa pagitan nila), kasama ang tamang gas cost batay sa antas ng scale. Ang mga bagong uri ng estado, recursive STARK mempool, keyed nonces, atbp. lahat ay nagpapatuloy sa direksyong ito. Lahat ito ay may kaugnayan sa mga uri ng transaksyon, dahil ang isang general-purpose transaction type ay isang napaka-natural na interface layer kung saan maaaring i-implement lahat ito, at ang kasalukuyang pag-iisip tungkol sa EIP-8141 transaction type ay nagpapatuloy sa eksaktong direksyong ito na kaaya-aya para sa mga ganitong uri ng hinaharap na generalisasyon. Kaya sa ganitong kahulugan, ang 8141 na maayos na gawin ay hindi lamang isang kumpletong pagsasapulot ng 10 taon ng account abstraction work, kundi pati na rin isang paghahanda para sa susunod na ilang taon ng responsableng hyper-scaling na kaaya-aya para sa decentralization.