EIP-8250 adalah proposal yang terlihat kecil di permukaan, tetapi menyentuh perdebatan besar tentang privasi dan ukuran state Ethereum. Intinya: untuk transaksi frame EIP-8141, proposal ini mengganti satu nonce pengirim yang berjalan linear dengan pasangan

(nonce_key, nonce_seq)

nonce_key == 0

[1]

Dalam bahasa sederhana, Ethereum tidak lagi hanya memberi satu antrean untuk semua transaksi frame dari satu pengirim. EIP-8250 membuka banyak “jalur” berbasis kunci. Itu penting karena beberapa protokol privasi dapat menempatkan banyak pengguna independen di balik satu alamat pengirim bersama; bila hanya ada satu nonce, satu transaksi yang tertunda bisa menahan transaksi lain yang sebenarnya tidak berkaitan ^[1][12].

Apa yang sebenarnya diubah EIP-8250?

Nonce adalah angka urut yang membantu mencegah transaksi lama dipakai ulang, atau dikenal sebagai perlindungan dari replay. Dalam konteks transaksi frame EIP-8141 saat ini, satu pengirim memakai satu nonce linear ^[1].

EIP-8250 memecahnya menjadi dua bagian:

• nonce_key: kunci yang memilih domain perlindungan replay.
• nonce_seq: nomor urut di dalam domain tersebut.

Diskusi di Ethereum Magicians menjelaskan bahwa key non-nol disimpan di kontrak sistem NONCE_MANAGER, dan transaksi pada key non-nol yang berbeda bersifat replay-independent ^[1]. Dengan kata lain, transaksi di jalur key A tidak harus menunggu antrean replay milik key B.

Namun, ini bukan berarti semua transaksi Ethereum tiba-tiba menjadi bebas urutan atau otomatis paralel. Ruang lingkupnya spesifik: EIP-8250 ditujukan untuk transaksi frame EIP-8141, sementara key 0 tetap menjaga perilaku nonce akun lama ^[1].

Mengapa satu nonce pengirim bisa menghambat protokol privasi?

Masalahnya paling terasa ketika banyak pengguna yang tidak saling terkait diarahkan melalui satu alamat pengirim bersama. ETH Daily menggambarkan EIP-8250 sebagai proposal yang sangat relevan untuk protokol privasi, karena protokol seperti itu dapat merutekan banyak pengguna independen melalui satu shared sender address ^[12].

Jika alamat bersama itu hanya memiliki satu nonce linear, maka satu transaksi frame yang lambat atau tertunda dapat menahan semua transaksi frame berikutnya dari pengirim yang sama ^[1][12]. Bagi sistem yang ingin melayani banyak alur pengguna, ini seperti semua kendaraan harus melewati satu loket, padahal tujuan dan penumpangnya berbeda.

Keyed nonces memecah antrean itu. Protokol privasi dapat menempatkan alur yang tidak berkaitan pada key berbeda, sehingga tidak semuanya berebut satu urutan nonce pengirim ^[1]. Yang perlu digarisbawahi: ini adalah peningkatan mekanisme replay protection terlebih dahulu, bukan sistem privasi yang berdiri sendiri.

Hubungannya dengan privasi: nullifier

Keyed nonces tidak otomatis menyembunyikan saldo, penerima, atau jumlah transaksi. Proposal privasi lain, EIP-8182, menggambarkan transfer ETH dan ERC-20 privat sebagai sistem yang melibatkan kontrak sistem, precompile untuk verifikasi bukti, notes, deposit, private transfer, dan withdrawal ^[9]. Artinya, privasi on-chain membutuhkan komponen kriptografi dan aturan transaksi yang lebih luas.

Kaitan EIP-8250 dengan penskalaan privasi lebih sempit, tetapi penting. Laporan seputar proposal ini sering memakai nullifier sebagai contoh utama data privasi yang terus bertambah dan tidak bisa dipangkas begitu saja setelah masuk sistem ^[3][4]. Dalam sistem privasi, catatan bergaya nullifier dipakai untuk memastikan state privat yang sudah dipakai tidak dapat digunakan ulang; karena harus tetap bisa dicek, catatan seperti ini dapat menjadi beban state jangka panjang ^[3][4].

Dari sudut pandang itu, EIP-8250 bukan protokol zero-knowledge privacy. Ia lebih tepat dipahami sebagai cara native di level protokol untuk mengelola banyak urutan sekali pakai yang independen. Itu sebabnya sejumlah komentator mengaitkannya dengan penyimpanan nullifier khusus dan desain state yang lebih terarah ^[1][4][10].

Perdebatan state scaling di balik proposal ini

Vitalik Buterin dan sejumlah ringkasan sekunder menempatkan keyed nonces sebagai kemungkinan langkah awal menuju special-purpose state: alih-alih memasukkan semua beban kerja ke state Ethereum yang sepenuhnya dinamis, jenis data tertentu bisa mendapatkan penyimpanan yang dioptimalkan sesuai pola aksesnya ^[4][5][10].

Contoh tekanan skalanya adalah nullifier untuk transaksi privat. Beberapa laporan mengulang skenario: jika transaksi privat on-chain berjalan pada 2.000 transaksi per detik selama delapan tahun, hasilnya sekitar 500 miliar nullifier ^[2][5][7]. Angka ini sebaiknya dibaca sebagai ilustrasi skala, bukan bukti bahwa peta jalan tersebut sudah aktif, karena mekanisme EIP-8250 sendiri masih dijelaskan dalam diskusi Ethereum Magicians yang terhubung ke pull request EIP ^[1].

Sebagian laporan juga menyebut dedicated nullifier store, dengan teknik seperti sharding dan Bloom filters, sebagai cara agar data bervolume tinggi lebih mudah dikelola node dibandingkan jika semuanya dimasukkan ke state dinamis umum ^[2][14]. Gagasan besarnya: untuk beban kerja yang sempit dan polanya dapat diprediksi, struktur penyimpanan khusus mungkin lebih mudah diskalakan sambil tetap menjaga tujuan desentralisasi ^[5][10].

Apa yang bisa diperbaiki oleh keyed nonces?

• Throughput untuk alamat bersama. Jika protokol privasi merutekan banyak pengguna melalui satu pengirim, key yang berbeda dapat mengurangi risiko alur transaksi yang tidak berkaitan harus menunggu satu nonce pengirim ^[1][12].
• Isolasi replay. EIP-8250 secara eksplisit membuat transaksi pada key non-nol yang berbeda menjadi replay-independent ^[1].
• Dukungan protokol yang lebih rapi untuk privasi. Sejumlah laporan menggambarkan keyed nonces sebagai penguatan dukungan privasi di level protokol, bukan membiarkan semua pola replay atau nullifier-like ditangani sepenuhnya oleh kontrak aplikasi ^[4][5].
• Arah menuju state khusus. Perdebatan yang lebih luas adalah apakah Ethereum dapat memakai penyimpanan khusus untuk beban kerja tertentu, alih-alih memperlakukan semua state sebagai satu wadah serbaguna ^[4][10].

Yang tidak dilakukan EIP-8250

• Tidak mengganti semua nonce Ethereum. EIP-8250 dibatasi untuk transaksi frame EIP-8141, dengan

  nonce_key == 0

  tetap mengacu pada nonce akun lama ^[1].
• Tidak membuat transaksi otomatis privat. Transfer privat membutuhkan komponen lain seperti notes, verifikasi bukti, deposit, aturan transfer, dan aturan withdrawal, seperti yang digambarkan EIP-8182 ^[9].
• Tidak menjamin Ethereum akan menyimpan 500 miliar catatan. Angka 500 miliar berasal dari skenario 2.000 TPS selama delapan tahun yang dipakai untuk menjelaskan tantangan penskalaan nullifier ^[2][5][7].
• Belum menjadi perilaku protokol yang aktif. Mekanismenya masih dijelaskan dalam diskusi Ethereum Magicians yang terkait dengan pull request EIP, sehingga detail implementasi dan waktunya masih dapat berubah ^[1].

Kesimpulan

EIP-8250 paling tepat dibaca sebagai peningkatan replay protection yang punya dampak samping penting bagi penskalaan privasi. Mekanismenya sederhana: pecah urutan nonce transaksi frame menjadi banyak jalur berbasis key. Janji yang lebih besar ada di level arsitektur: jika Ethereum bisa memberi struktur protokol khusus untuk beban kerja sempit tetapi bervolume tinggi, sistem privasi berpotensi tumbuh tanpa memaksa setiap catatan yang tidak bisa dipangkas masuk ke state serbaguna ^[1][4][5].