Bagaimana Bukti Validitas Transaksi Bekerja dalam EIP-8361?

EIP-8361 memungkinkan transaksi frame EIP-8141 mengirimkan STARK ringkas bersama payload peer-to-peer, sehingga node bisa memverifikasi bahwa prefiks validasi menyetujui transaksi berdasarkan asumsi status yang dideklarasikan. Node tidak lagi perlu mengeksekusi mekanisme yang sama berulang kali, cukup memeriksa satu bukti, dependensi, dan kondisi status terkait, yang dapat menurunkan biaya verifikasi untuk logika akun kompleks. Bagian berikut menelusuri cara transaksi valid memperoleh bukti, bagaimana node mendeteksi transaksi basi atau curang, alasan bukti merujuk status valid sebelumnya tanpa menjadi Merkle root, serta mengapa bukti dihapus setelah transaksi masuk blok.

Penjelasan ini membedakan EIP-8361 dari dua tipe utama keamanan rollup: bukti ZK, yang memastikan kebenaran sebelum diterima, dan bukti kecurangan, yang membutuhkan proses tantangan untuk membuktikan transisi tidak valid. Penjelasan juga memperjelas batasan terkait tanda tangan ECDSA, keamanan kuantum, risiko komputer kuantum, dan peran proposal ini yang lebih sempit dibanding solusi penskalaan. Ulasan teknis ini ditujukan untuk tim dompet, pengembang client, operator prover, dan pengguna yang menilai potensi transaksi dengan bukti dalam meningkatkan validasi Ethereum, sementara EIP-8361 masih berupa proposal jaringan draft, belum menjadi aturan konsensus.

Poin Penting

• EIP-8361 memungkinkan transaksi frame EIP-8141 membawa bukti admission sebagai metadata transportasi off-chain.
• Prover off-chain mengeksekusi prefiks validasi atas asumsi yang dideklarasikan dan menghasilkan STARK yang terikat pada transaksi, pembayar, dependensi, dan kondisi validitas.
• Node penerima melakukan pemeriksaan stateless, memverifikasi bukti dan dependensi, serta membandingkan asumsi dengan status Ethereum saat ini.
• Bukti valid memungkinkan admission ke mempool tanpa mengulang simulasi prefiks validasi penuh.
• Bukti tidak menentukan validitas blok, tidak mengubah eksekusi, dan tidak menjadi bagian dari status permanen Ethereum. Bukti dibuang setelah inclusion atau penghapusan dari mempool.

Apa Itu Bukti Validitas Transaksi EIP-8361?

EIP-8361 mengusulkan metode admission untuk transaksi yang dibuat dengan EIP-8141. Tujuannya spesifik: membuat transaksi yang mahal secara komputasi cukup murah untuk diverifikasi node sebelum diteruskan ke mempool publik.

Transaksi frame EIP-8141 dapat mengandung logika pemrograman yang menentukan otorisasi pengirim, siapa pembayar eksekusi, dan apakah kondisi tertentu terpenuhi. Logika ini berada di prefiks validasi yang dijalankan sebelum frame eksekusi transaksi.

Pada admission simulasi biasa, setiap node penerima harus mengeksekusi prefiks untuk memutuskan apakah transaksi masuk mempool. EIP-8361 menawarkan opsi lain: prover mengeksekusi prefiks sekali secara off-chain dan membuat bukti kriptografi yang menunjukkan hasil akhir APPROVE dan pembayar yang jelas.

Transaksi dan bukti dikirim bersama. Node memverifikasi bukti, bukan membangun ulang seluruh proses validasi.

Kerangka kerja EIP-8361 berfokus pada admission mempool berbukti, sementara proses validasi mempool EIP-8361 menentukan bagaimana node memutuskan menerima, mempertahankan, memarkir, atau menghapus transaksi.

Per 6 Agustus 2026, EIP-8361 diajukan dalam draft pull request #12075 sebagai proposal Networking pada Standards Track. Proposal ini tidak memperkenalkan tipe transaksi baru atau mengubah konsensus Ethereum secara langsung.

Bagaimana Cara Kerja Bukti Kriptografi EIP-8361?

Bukti menegaskan pernyataan spesifik, tidak mengklaim setiap hasil eksekusi di masa depan sudah diketahui.

Secara sederhana, prover harus membuktikan:

Prefiks validasi transaksi T, saat dievaluasi dengan asumsi dan dependensi yang dideklarasikan, mengikuti aturan trace EIP-8141 dan berakhir dengan APPROVE serta pembayar P, sesuai kondisi yang dideklarasikan.

Input publik mengikat bukti pada lima elemen:

Pengikatan ini memastikan bukti valid untuk satu transaksi tidak bisa dipakai pada transaksi lain dengan data, dependensi, kondisi, atau pembayar berbeda.

Private witness mencakup data yang dibutuhkan untuk mengevaluasi prefiks, termasuk isi daftar dependensi. Bukti menunjukkan kebenaran perhitungan tanpa memaksa semua node penerima mengulanginya.

EIP-8361 mengusulkan penggunaan ulang format bukti dan verifikasi ingress dari EIP-8288. STARK digunakan karena dapat merepresentasikan komputasi besar dengan bukti ringkas, tanpa memerlukan setiap verifier mereproduksi beban kerja asli.

Bagaimana Vektor Asumsi Digunakan dalam Validasi Transaksi?

Bukti kriptografi dapat menunjukkan perhitungan benar untuk input tertentu, namun node mempool tetap harus memeriksa apakah input tersebut cocok dengan status Ethereum saat ini.

EIP-8361 mengatasinya dengan vektor asumsi, A, yang mencantumkan setiap nilai status yang dibaca prefiks validasi. Entri meliputi alamat, storage key atau referensi saldo, tipe perbandingan, dan nilai.

Dua tipe perbandingan:

• EQ: status saat ini harus sama dengan nilai yang dideklarasikan dalam bukti.
• GEQ: status saat ini harus lebih besar atau sama dengan ambang yang dideklarasikan.

EQ cocok untuk code hash, nonce, atau storage branch yang berubah makna saat nilainya berubah. GEQ untuk syarat monoton, misal saldo paymaster minimal 0,2 ETH. Node menganggap bukti tetap berlaku selama saldo ≥ 0,2 ETH, tanpa perlu bukti baru setiap kali saldo naik di atas ambang.

Desain ini menghindari pengikatan bukti pada state root lengkap atau bukti Merkle besar untuk seluruh status. Sirkuit mengevaluasi prefiks validasi terhadap nilai deklarasi; node memeriksa nilai-nilai itu terhadap status saat ini.

Bagaimana Bukti Validitas Transaksi Bekerja di Bawah EIP-8361?

Proses validasi transaksi mengikuti urutan pemeriksaan:

1. Pemeriksaan stateless. Node memeriksa validitas intrinsik transaksi dan format dependensi/tanda tangan. Transaksi salah ditolak sebelum verifikasi bukti.
2. Verifikasi bukti admission. Node memverifikasi STARK dengan verification key. Jika gagal, validasi tidak terbukti.
3. Verifikasi dependensi eksternal. Bukti dapat mengasumsikan tanda tangan/dependensi valid. Node memverifikasi dan mencocokkan daftar dependensi dengan hash yang dikomitmenkan.
4. Periksa kondisi validitas. Node mengevaluasi kondisi deklarasi, seperti tenggat, slot/epoch, rentang kedaluwarsa, atau nonce.
5. Bandingkan asumsi dengan status live. Setiap EQ diuji kesamaannya, GEQ diuji terhadap ambang.
6. Admit transaksi. Jika semua sukses, node menerima dan menyebarkan transaksi tanpa simulasi prefiks validasi penuh.

Urutan ini mencegah bukti melewati pemeriksaan struktur, tanda tangan, status, atau waktu biasa. Ini hanya mengubah metode komputasi untuk keputusan admission, bukan syarat validitas transaksi.

Apa yang Terjadi Saat Status Ethereum Berubah?

Admission mempool tidak permanen karena status Ethereum terus berubah setelah transaksi masuk pool.

Dengan EIP-8361, node memeriksa ulang kondisi validitas dan vektor asumsi saat blok baru mengubah chain head. Node tidak perlu membuat ulang bukti, menjalankan prefiks validasi, atau memverifikasi bukti yang sama. Bukti yang telah diverifikasi tetap menjadi hasil cache fungsi validasi untuk input deklarasi.

Kegagalan EQ biasanya membatalkan bukti karena input pasti berubah. Node harus menghapus transaksi kecuali ada bukti baru atau transaksi memenuhi syarat admission simulasi.

Kegagalan GEQ dapat diparkir. Jika pembayar/paymaster menerima dana cukup, node dapat mengaktifkan ulang transaksi dengan memeriksa ambang lagi.

Pembedaan ini membuat vektor asumsi lebih dari sekadar komitmen Merkle satu status. Ia mendefinisikan perubahan status yang membatalkan approval dan perubahan yang tetap kompatibel.

Mengapa Bukti Dibuang Setelah Dimasukkan ke Blok?

Bukti EIP-8361 hanya diperlukan untuk admission dan propagasi mempool publik. Bukti ini bukan bukti otoritatif bahwa transaksi yang dimasukkan menghasilkan transisi status benar.

Setelah validator memasukkan transaksi ke blok, Ethereum memprosesnya melalui eksekusi protokol biasa. EVM menjalankan prefiks validasi dan frame sisanya sesuai status blok kanonik. Client konsensus menentukan validitas blok dengan aturan Ethereum.

Jadi, bukti admission:

• tidak masuk ke blok;
• tidak ditambahkan ke calldata transaksi;
• tidak muncul di receipt;
• tidak jadi bagian Merkle tree atau state root;
• tidak mengubah status on-chain permanen;
• tidak perlu disimpan setelah inclusion/penghapusan.

Pembuangan ini menghindari biaya calldata dan pertumbuhan status permanen untuk informasi yang sudah memenuhi tujuan jaringan. Transaksi tetap on-chain, namun bukti sementaranya tidak.

Sistem Bukti EIP-8361 vs. Bukti Validitas ZK-Rollup

EIP-8361 menggunakan teknologi bukti kriptografi, namun bukti admission-nya berbeda dengan bukti validitas ZK rollup.

ZK rollup biasanya memakai ZK-SNARK atau ZK-STARK untuk membuktikan kebenaran batch transaksi. Setelah bukti diterima kontrak Layer 1, rollup dapat memfinalisasi transisi status tanpa menunggu periode tantangan seperti pada optimistic rollup.

EIP-8361 tidak membuktikan batch L2, tidak mengizinkan penarikan rollup langsung, dan tidak menjamin L2 tidak pernah tidak valid. Buktinya adalah artefak jaringan sementara untuk validasi pra-inclusion.

Zero-knowledge proof dapat memverifikasi pernyataan tanpa mengungkap seluruh data witness, namun EIP-8361 bukan proposal privasi. "Bukti ringkas" dan "zero knowledge" berkaitan, namun tidak identik.

Penarikan Layer 2 ke Layer 1 bisa lebih cepat dengan bukti validitas karena ZK rollup tidak perlu periode tantangan fraud-proof. Waktu penarikan tetap tergantung pembuatan bukti, verifikasi Layer 1, aturan bridge, dan finalitas Ethereum. EIP-8361 tidak menyediakan mekanisme penarikan ini; buktinya mendukung admission mempool untuk transaksi frame EIP-8141 individual, bukan settlement batch transaksi Layer 2.

Bagaimana Bukti Kecurangan Bekerja di Optimistic Rollup?

Bukti kecurangan memakai mekanisme keamanan berbeda. Optimistic rollup menerima transisi status dan mengizinkan penantang membuktikan kecurangan selama periode sengketa. Tergantung implementasi, penyelesaian sengketa bisa memerlukan beberapa putaran atau bukti eksekusi terbatas.

EIP-8361 menetapkan pernyataan admission sebelum transaksi diterima di mempool. Tidak ada periode tantangan pasca-admission untuk membuktikan hasil prefiks curang.

Perbedaan utama: waktu dan lingkup.

• Bukti validitas membuktikan klaim sebelum diterima.
• Bukti kecurangan mengizinkan klaim optimistik kecuali ditantang.
• Bukti admission EIP-8361 untuk kebijakan mempool.
• Bukti kecurangan rollup untuk kebenaran transisi status L2.

Pertukaran teknis antara eksekusi EVM berulang dan verifikasi ringkas dibahas di EIP-8361 versus simulasi transaksi, termasuk biaya pembuatan bukti yang menggantikan simulasi node.

EIP-8361, Validasi Akun Kompleks, dan Keamanan Pascakuantum

Akun programmable bisa memakai multi-tanda tangan, rotasi kunci, aturan recovery, skema tanda tangan non-standar, kandidat tanda tangan pascakuantum, kebijakan pengeluaran, atau pemeriksaan zero-knowledge berat gas. Beberapa logika ini valid namun terlalu mahal untuk disimulasikan semua node mempool.

EIP-8361 menjaga propagasi transaksi publik akun-akun ini dengan membuat validasi mahal bagi prover namun murah bagi verifier. Ini juga mengurangi tekanan memindahkan otorisasi kompleks ke fase eksekusi, yang berisiko menjadi transaksi revert yang tercatat publik dan berbayar.

Mekanisme ini tidak membuat semua smart contract aman atau sepenuhnya pascakuantum. STARK dapat menghindari beberapa asumsi sistem bukti kurva eliptik, namun transaksi tetap bergantung pada kunci publik, skema tanda tangan, implementasi client, kode dompet, atau verification key dengan properti keamanan terpisah.

Tanggung jawab pembuat transaksi, dompet, prover, dan client berbeda, sebagaimana dirangkum di dampak EIP-8361 untuk dompet, node, dan pengembang.

Misal, trader yang menilai pengaruh account-abstraction Ethereum pada sentimen pasar dapat membandingkan milestone proposal dengan grafik pasar ETH/USDT, meski aksi harga tidak mengonfirmasi implementasi atau adopsi draft EIP.

Risiko dan Batasan

EIP-8361 masih draft awal, sehingga format bukti, batasan, dependensi, terminologi, dan detail implementasi dapat berubah sebelum standarisasi.

Risiko teknis:

Konsentrasi pembuatan bukti: Pembuatan STARK memerlukan perangkat lunak khusus dan komputasi besar. Jika hanya sedikit layanan efisien, dompet bisa tergantung pada prover terpusat.

Tekanan denial-of-service: Verifikasi bukti lebih murah dari komputasi asli, tapi tetap ada biaya. Client perlu batas ukuran bukti, rate limit peer, dan atribusi kegagalan untuk mencegah serangan flood node dengan bukti tidak valid/besar.

Kelengkapan asumsi: Bukti hanya bermakna jika vektor asumsi memuat semua status yang dibaca prefiks validasi. Bug sirkuit/client yang menghilangkan dependensi bisa menyebabkan keputusan admission salah.

Status basi: Bukti bisa tetap benar kriptografi meski kondisi deklarasi tidak cocok status saat ini. Node harus terus memeriksa ulang A dan C selama transaksi di pool.

Tidak ada jaminan eksekusi: Admission mempool tidak menjamin inclusion blok atau eksekusi akhir sukses. Transaksi lain dapat mengubah nonce, saldo, kode, storage, atau status pengirim sebelum inclusion.

Kompleksitas implementasi: Client, dompet, dan sistem prover harus sepakat soal encoding bukti, verification key, penanganan dependensi, perilaku peer, dan aturan revalidasi. Implementasi tidak konsisten bisa memecah propagasi transaksi.

Apakah EIP-8361 Juga Proposal Tapered Issuance Burn?

Beberapa diskusi awal mengaitkan EIP-8361 dengan proposal kebijakan moneter Ethereum bernama Tapered Issuance Burn. Proposal itu kemudian jadi EIP-8363, sementara EIP-8361 adalah Transaction Validity Proofs dalam kategori networking. Keduanya tidak terkait: EIP-8361 untuk admission mempool berbukti, Tapered Issuance Burn mengubah ekonomi reward konsensus sesuai saldo staking aktif.

Kesimpulan

Bukti validitas transaksi EIP-8361 memindahkan beban validasi mahal dari setiap node penerima ke prover off-chain. STARK yang dihasilkan mengikat transaksi EIP-8141 pada hasil approval, pembayar, dependensi, kondisi, dan asumsi status, memungkinkan node memverifikasi klaim ringkas sebelum admission mempool.

Mekanisme ini bermanfaat saat smart account punya logika validasi sah yang melebihi batas simulasi praktis. Batas utamanya: bukti hanya berlaku untuk admission pada lapisan jaringan. Ethereum tetap mengeksekusi transaksi secara normal saat inclusion, dan bukti sementara dibuang karena tidak punya peran konsensus atau on-chain setelahnya.

FAQ

Bagaimana ZK rollup menggunakan bukti validitas?

ZK rollup memproses transaksi off-chain, mengelompokkan dalam batch, dan membuat bukti validitas untuk tiap batch. Bukti, biasanya dengan ZK-SNARK, ZK-STARK, atau komitmen polinomial, memungkinkan kontrak Ethereum memverifikasi transisi status tanpa memutar ulang setiap transaksi.

Apakah bukti validitas menjamin L2 tidak bisa menjadi tidak valid?

Bukti validitas mencegah verifier L1 menerima transisi status tidak valid jika sirkuit, kontrak verifier, kriptografi, dan implementasi benar. Tidak menghilangkan risiko kode buggy, ketersediaan data, bridge, sequencer, tata kelola, atau kontrol upgrade.

Mengapa penarikan ZK-rollup biasanya lebih cepat?

ZK rollup dapat memfinalisasi penarikan setelah bukti validitas diverifikasi, tanpa menunggu periode tantangan fraud-proof seperti pada optimistic rollup. Penarikan tetap tergantung pembuatan bukti, pengiriman batch, aturan bridge, dan finalitas Ethereum, jadi "langsung" tidak selalu berarti instan.

Apa perbedaan bukti validitas dan bukti kecurangan?

Bukti validitas membuktikan kebenaran transaksi sebelum transisi status diterima. Bukti kecurangan memakai model optimistik: transisi diterima sementara dan bisa ditantang kemudian; banyak optimistic rollup memakai periode tantangan sekitar tujuh hari, meski durasinya bervariasi.

Apakah zero-knowledge proof selalu menyembunyikan data transaksi?

Tidak. Zero-knowledge proof dapat memverifikasi pernyataan tanpa mengungkap private witness, namun privasi tergantung input mana yang disembunyikan. Banyak ZK rollup memakai ZK proof terutama untuk verifikasi transaksi skalabel, bukan transaksi sepenuhnya privat.

Apa perbedaan ZK-SNARK dan ZK-STARK?

ZK-SNARK menghasilkan bukti kecil dengan biaya verifikasi rendah, meski banyak desain butuh trusted setup. ZK-STARK tidak butuh trusted setup dan dianggap lebih tahan serangan komputer kuantum, namun ukuran buktinya biasanya lebih besar.

Apa yang diverifikasi oleh bukti Merkle?

Bukti Merkle mengonfirmasi data tertentu termasuk dalam dataset yang diwakili Merkle root tanpa mengungkap atau mengunduh seluruh dataset. Ia membuktikan inklusi atau eksklusi, bukan kebenaran batch transaksi atau transisi status.

Apakah bukti validitas mengurangi konsumsi sumber daya on-chain?

Ya, bukti dapat mengompresi komputasi off-chain besar menjadi satu bukti yang lebih murah diverifikasi on-chain daripada memutar ulang setiap transaksi. Penghematan aktual tergantung biaya verifikasi bukti, ukuran batch, penggunaan calldata/blob, dan implementasi rollup.

Apakah bukti validitas mengurangi risiko serangan 51%?

Tidak langsung. Bukti validitas melindungi kebenaran transisi status Layer 2, sementara serangan 51% terkait kontrol konsensus Ethereum dan pemilihan fork. Keduanya mengatasi risiko keamanan berbeda.

Apakah bukti EIP-8361 sama dengan bukti ZK-rollup?

Tidak. Bukti ZK-rollup memverifikasi batch transaksi Layer 2 dan mendukung finalitas status serta penarikan. Bukti EIP-8361 mendukung admission mempool untuk transaksi frame EIP-8141 individual, tidak masuk blok, dan dibuang setelah inclusion/penghapusan.

Penafian

Konten ini bersifat edukasi dan menjelaskan proposal Ethereum draft yang spesifikasinya serta status implementasinya dapat berubah. Konten ini tidak memberikan saran keuangan, keamanan, atau deployment perangkat lunak. Pengembang harus memverifikasi teks EIP terbaru dan persyaratan client sebelum membangun sistem produksi.