Apa Itu EIP-8361? Penjelasan Validity Proofs Ethereum

EIP-8361 secara khusus menangani proof-carrying admission untuk transaksi frame EIP-8141. Proposal ini tidak mengganti eksekusi Ethereum, tidak memperkenalkan jenis transaksi baru, tidak melakukan deployment smart contract, tidak menyediakan privasi transaksi, tidak mengubah imbalan validator, dan tidak menetapkan periode implementasi 18 bulan. Fokus utamanya adalah mengurangi komputasi berulang selama validasi transaksi, sambil tetap menjaga perlindungan terhadap transaksi tidak valid atau yang memakan sumber daya secara berlebihan.

Bagian berikut menjelaskan cara kerja proses proof-carrying, apa yang diverifikasi node, perbedaan EIP-8361 dari rollup validity proofs dan simulasi transaksi, serta keterbatasan teknis yang masih belum terselesaikan.

Poin Utama

• EIP-8361 menstandarkan data bukti validitas transaksi untuk propagasi peer-to-peer. Transaksi frame dapat membawa STARK yang membuktikan validation prefix-nya mencapai status yang disetujui.

• Node memverifikasi bukti, bukan mengulang logika otorisasi yang mahal. Pemisahan antara pembuktian dan verifikasi ini mengurangi komputasi berulang di seluruh node Ethereum.

• Bukti tetap di luar konsensus. Bukti dikirim bersama transaksi, digunakan untuk admission ke mempool, dan dibuang jika tidak lagi diperlukan.

• Desain mendukung validasi smart account yang kompleks. Contohnya multisignature, sistem tanda tangan alternatif, paymaster, dan otorisasi berbasis proof.

• EIP-8361 masih berupa draft. Belum menjadi upgrade aktif dan tidak boleh disamakan dengan EIP-7701, EIP-7702, rollup validity proofs, atau proposal staking-reward lainnya.

Apa Itu EIP-8361?

EIP-8361, berjudul Transaction Validity Proofs, mengusulkan mekanisme jaringan di mana transaksi Ethereum dapat dikirim bersama bukti kriptografi bahwa logika validasinya menyetujui transaksi tersebut. Draft ini merupakan pelengkap jaringan untuk perubahan protokol yang diusulkan EIP-8141, yang mendefinisikan transaksi frame dan tahap validasi yang dapat diprogram.

Ethereum Improvement Proposal adalah dokumen desain teknis yang menggambarkan standar, fitur protokol, antarmuka, atau proses potensial untuk Ethereum. Publikasi sebagai EIP tidak otomatis berarti proposal telah diterima atau diimplementasikan. EIP-8361 masih berupa draft yang spesifikasi, dependensi, dan statusnya dapat berubah.

Proposal ini menjawab pertanyaan berikut:

Bagaimana node dapat menerima transaksi yang otorisasinya mahal tanpa mengharuskan setiap peer mengulang komputasi mahal tersebut?

Dalam EIP-8361, prover menjalankan logika validasi transaksi secara off-chain dan menghasilkan STARK. Node penerima memverifikasi bukti tersebut, memeriksa asumsi yang dideklarasikan terhadap state Ethereum saat ini, dan memutuskan apakah transaksi masuk ke public mempool.

Transaksi tetap harus valid menurut aturan eksekusi Ethereum saat akhirnya masuk ke blok. Bukti hanya mendukung kebijakan admission, tidak menggantikan eksekusi protokol atau validasi konsensus.

Mengapa Validasi Transaksi Ethereum yang Kompleks Sulit

Akun eksternal konvensional (EOA) dikendalikan melalui private key dan public key terkait. Akun mengotorisasi transaksi dengan tanda tangan ECDSA, sementara transaksi menentukan field seperti nonce pengirim, alamat tujuan, nilai, chain ID, gas limit, dan harga gas atau parameter biaya EIP-1559.

Pemeriksaan ini relatif mudah diprediksi. Node dapat memverifikasi tanda tangan, memastikan saldo cukup, memeriksa nonce, dan menolak transaksi yang salah format atau replay.

Smart account memperluas permukaan validasi. Selain satu private key, smart account dapat menggunakan:

• beberapa public key;

• batas pengeluaran;

• session key;

• kontrak delegasi;

• aturan paymaster;

• tanda tangan post-quantum;

• kondisi pemulihan;

• zero-knowledge proof;

• kode otorisasi khusus aplikasi.

Logika ini bisa berada di smart contract yang sudah di-deploy atau kontrak baru saat akun dibuat. Pembuatan dan deployment kontrak juga bisa memerlukan validasi terhadap factory, kode inisialisasi, atau alamat kontrak.

Node Ethereum tidak dapat menjalankan kode validasi tanpa batas untuk setiap transaksi tak terkonfirmasi yang diterima. Penyerang dapat mengirim transaksi palsu yang memanggil smart contract mahal, fungsi hash, pembacaan storage, atau sistem proof, tetapi tidak pernah mengotorisasi eksekusi. Meski tidak valid, verifikasi tetap mengonsumsi sumber daya node.

EIP-8361 transaction validity proofs memindahkan komputasi mahal ke prover, dengan verifikasi bukti tetap terbatas.

Cara Kerja Proof-Carrying Transactions EIP-8361

EIP-8361 menawarkan dua jalur untuk menerima transaksi frame EIP-8141:

1. Simulasi admission: node menjalankan validation prefix langsung.

2. Proof-carrying admission: node memverifikasi STARK yang membuktikan validation prefix disetujui.

Jalur kedua digunakan jika pemanggilan normal ke kode validasi melebihi batas verifikasi node.

1. Transaksi Mendefinisikan Logika Validasi

Transaksi frame EIP-8141 membagi pekerjaannya ke dalam frame berbeda. Beberapa frame menetapkan otorisasi, mengidentifikasi pembayar, atau menyiapkan eksekusi. Validation prefix dijalankan sebelum frame eksekusi normal.

Validation prefix dapat memanggil smart contract pengirim atau kontrak delegasi. Kontrak ini dapat memeriksa tanda tangan, izin, saldo, kondisi kedaluwarsa, atau aturan lain sebelum memanggil operasi APPROVE.

EIP-8141 berbeda dari transaksi konvensional yang hanya mengandalkan satu tanda tangan ECDSA. Model validasi yang dapat diprogram ini merupakan bagian dari gerakan Ethereum menuju native account abstraction. EIP-8141 juga menghindari ketergantungan pada authorization list EIP-7702 karena transaksi frame menargetkan fleksibilitas kriptografi yang lebih besar.

2. Prover Menjalankan Validation Prefix

Prover menjalankan validation prefix transaksi dengan input dan asumsi state yang dideklarasikan. Proses ini dapat mencakup verifikasi:

• tanda tangan sesuai public key;

• saldo akun pengirim mencukupi;

• saldo paymaster di atas batas minimum;

• slot storage kontrak berisi izin yang diharapkan;

• chain ID sesuai jaringan Ethereum;

• nonce mencegah replay attack;

• kode validasi berakhir dengan persetujuan.

Prover kemudian membuat STARK yang mengikat transaksi, dependensi, asumsi, pembayar, dan kondisi validitas.

3. Bukti Mendeklarasikan Asumsi State

Bukti kriptografi tidak berguna jika bergantung pada state yang telah berubah. EIP-8361 mengusulkan assumption vector yang mendeskripsikan fakta state selama pembuktian.

Kondisi kesetaraan menyatakan bahwa code hash, nonce, atau nilai storage kontrak harus sama persis dengan nilai yang dideklarasikan. Kondisi lebih besar atau sama menyatakan saldo akun harus di atas minimum.

Asumsi ini menghubungkan bukti ke state valid sebelumnya tanpa menyematkan seluruh state Ethereum. Jika blok baru mengubah data, node dapat memeriksa ulang assumption vector.

Mekanisme ini penting untuk EIP-8361 mempool validation: node tidak serta-merta mempercayai bukti lama hanya karena kriptografinya masih valid.

4. Node Memverifikasi STARK

Node penerima melakukan pemeriksaan struktural berbiaya rendah sebelum memverifikasi bukti. Node kemudian memverifikasi STARK dengan verification key yang ditentukan dan memeriksa dependensi serta asumsi terhadap state Ethereum saat ini.

Sistem proof modern dapat menghasilkan bukti yang lebih cepat diverifikasi daripada mengeksekusi ulang komputasi aslinya. Satu bukti dapat menggantikan simulasi berulang oleh banyak peer, mengurangi komputasi berulang di jaringan peer-to-peer.

Namun, pembuatan bukti tidak murah. Pembuatan STARK bisa membutuhkan pemrosesan, memori, dan perangkat lunak khusus yang signifikan. Proposal ini memindahkan komputasi, bukan menghilangkannya.

5. Transaksi Masuk ke Mempool

Jika verifikasi bukti dan pemeriksaan state berhasil, node dapat menerima dan mempropagasi transaksi tanpa menjalankan ulang validation prefix yang mahal.

Bukti tetap menjadi metadata peer-to-peer. Bukti tidak ditambahkan ke calldata transaksi, tidak disimpan oleh smart contract, tidak ditulis ke state akun, atau dimasukkan ke Merkle root blok.

Setelah transaksi masuk, Ethereum mengeksekusinya sesuai aturan protokol. Jika bukti menjadi usang atau transaksi dihapus, metadata jaringan dapat dibuang.

Apa yang Dibuktikan oleh EIP-8361 Validity Proof?

EIP-8361 validity proof adalah bukti kriptografi bahwa komputasi validasi tertentu dijalankan dengan benar berdasarkan asumsi yang dideklarasikan dan mencapai status persetujuan.

Bukti ini dapat menunjukkan bahwa logika validasi telah memeriksa tanda tangan valid, saldo mencukupi, nonce benar, pembayar diizinkan, atau otorisasi kontrak. Namun, bukti ini tidak selalu membuktikan setiap transisi state EVM berikutnya yang dihasilkan transaksi.

Pembedaan ini penting:

• EIP-8361 membuktikan validasi terkait admission.

• Rollup validity proof membuktikan satu atau lebih transisi state off-chain.

• Merkle proof membuktikan inklusi dalam struktur data terautentikasi.

• Zero-knowledge proof bisa menyembunyikan informasi, tetapi validitas saja tidak menjamin privasi.

Merkle proof dapat menunjukkan bahwa transaksi termasuk dalam batch, blok, atau state tree tertentu dengan menghubungkan leaf ke Merkle root yang diketahui. Dalam ZK rollup, Merkle proof dapat membuktikan akun pengirim dan penerima ada di state valid sebelumnya, dan saldo yang diperbarui menghasilkan state root baru.

EIP-8361 menggunakan STARK sebagai proof efisiensi kebenaran, tetapi bukan untuk eksekusi rahasia. Transaksi dan dependensinya tetap terlihat oleh node yang berpartisipasi.

EIP-8361 vs ZK-Rollup Validity Proofs

Solusi scaling Layer 2 menggunakan validity proof secara lebih luas. ZK rollup menjalankan batch transaksi off-chain dan mengirim proof ringkas ke smart contract verifier Ethereum. Proof ini menunjukkan batch mengubah state valid sebelumnya menjadi state baru yang benar sesuai aturan rollup.

Alih-alih mengeksekusi ulang setiap transaksi di Ethereum, contract verifier memeriksa proof dan public input. Ini mengurangi konsumsi sumber daya on-chain dan membagi biaya gas tetap ke banyak transaksi. Proof rekursif juga dapat menggabungkan beberapa proof menjadi satu.

Validity proof mencegah ZK rollup menyelesaikan transisi state tidak valid, asalkan sistem proof, sirkuit, contract verifier, dan model data-availability-nya aman. Validity proof juga memungkinkan finalitas L2-ke-L1 lebih cepat dibanding sistem dengan dispute window.

EIP-8361 berbeda. Proposal ini tidak membuktikan batch komputasi, memperbarui L2 Merkle root, atau memicu penarikan. EIP-8361 membuktikan satu transaksi frame memenuhi persyaratan admission node.

EIP-8361 Validity Proofs vs Fraud Proofs

Optimistic rollup mengasumsikan update state valid kecuali ada tantangan. Fraud proof mengharuskan pengamat mendeteksi transisi yang disengketakan dan memberikan bukti selama periode tantangan. Klaim tidak valid dapat tetap diterima sementara hingga tantangan selesai.

Sistem validity proof mengambil pendekatan sebaliknya: komitmen state baru diterima hanya setelah verifier mengonfirmasi bukti eksekusi benar. Ini memungkinkan penarikan lebih cepat karena pengguna tidak perlu menunggu periode tantangan fraud proof.

Namun, menyebut validity proof selalu lebih aman dari fraud proof terlalu umum. Perbedaan kunci meliputi kompleksitas prover, keamanan verifier, data availability, trusted setup, asumsi tantangan, dan kematangan implementasi.

EIP-8361 sendiri bukan model keamanan rollup. Bukti EIP-8361 diperiksa sebelum admission mempool, sedangkan fraud proof dan validity proof rollup melindungi sistem scaling off-chain.

EIP-8361 vs EIP-7702 Account Delegation

EIP-7702 memungkinkan EOA menetapkan indikator delegasi di field kode sehingga pemanggilan ke akun menjalankan kode dari smart contract yang ditunjuk. EIP-7702 memperkenalkan transaksi tipe-4 dengan authorization_list.

Setiap tuple otorisasi mencakup:

• chain_id;

• alamat kontrak delegasi;

• nonce akun;

• field tanda tangan.

Otorisasi ditandatangani private key EOA. Penandatangan bisa berbeda dari tx.origin, dan satu transaksi dapat membawa otorisasi dari beberapa EOA. Setiap otorisasi dapat memperbarui indikator delegasi akun sebelum eksekusi transaksi normal.

Artinya, pengguna dapat mendelegasikan eksekusi ke smart contract dengan otorisasi bertanda tangan tanpa mengubah akun menjadi smart contract konvensional. Kode yang didelegasikan dapat mendukung batching, sponsorship gas, izin, atau perilaku smart account lainnya.

EIP-7702 juga menciptakan pertimbangan keamanan. Chain ID nol dapat membuat otorisasi berlaku lintas chain, sedangkan nonce dan field tanda tangan membatasi replay attack. Kode yang didelegasikan dapat memengaruhi asumsi tx.origin, transaksi pending, storage, dan saldo akun.

EIP-8361 tidak menggantikan atau memperluas authorization_list. Proposal ini membahas bagaimana node dapat menerima transaksi dengan logika validasi kompleks. Perbedaan utama antara EIP-8361 validity proof dan simulasi transaksi terkait komputasi mempool, bukan delegasi kode EOA.

EIP-8361 vs EIP-7701 Native Account Abstraction

EIP-7701 dibuat pada 1 Mei 2024 sebagai proposal native account abstraction. EIP-7701 membagi pemrosesan transaksi menjadi validasi, eksekusi, dan post-operation, serta mengusulkan jenis transaksi baru EIP-2718.

Desainnya menggunakan entry-point native protokol 0x7701, opcode berbasis peran, validasi sender dan paymaster terpisah, serta pembayaran gas yang dikontrol kontrak. Proposal ini tidak memerlukan alur ERC-4337 bundler untuk tipe transaksi native-nya.

EIP-7701 telah ditarik karena digantikan oleh EIP-8141—bukan sekadar “Stagnant.” Spesifikasi yang dipublikasikan mencantumkan alasan penarikan. Klaim bahwa EIP-7701 memerlukan kontrak berformat EOF juga bukan bagian dari spesifikasi akhirnya.

EIP-8361 dibangun di atas model transaksi frame EIP-8141 yang lebih baru. Dalam hal ini, EIP-8361 mendukung jalur account abstraction protokol dengan memudahkan propagasi validasi yang dapat diprogram secara mahal.

EIP-2718 menyediakan envelope transaksi bertipe yang digunakan proposal seperti EIP-7701, EIP-7702, dan EIP-8141. Tipe transaksi menentukan bagaimana payload diinterpretasikan. Menyertakan tipe dalam data yang ditandatangani juga mengurangi risiko replay signature lintas tipe.

Dampak Praktis pada Wallet, Node, dan Developer

Pengembang wallet dapat menggunakan proof-carrying admission ketika otorisasi smart account terlalu mahal untuk simulasi mempool biasa. Wallet dapat meminta proof dari prover lokal, layanan wallet, atau jaringan proving terdistribusi sebelum mengirim transaksi.

Pengembang node perlu mengimplementasikan:

• transportasi proof antar peer-to-peer;

• verification key versi;

• batas ukuran proof;

• pemeriksaan asumsi dan dependensi;

• batas laju per-peer;

• penghapusan proof usang;

• fallback simulasi.

Pengembang smart contract dapat mempertahankan validasi aplikasi khusus tanpa mengharuskan seluruh node menanggung biayanya. Ini dapat mendukung tanda tangan post-quantum, kebijakan multi-key, paymaster kompleks, atau izin berbasis proof.

Dampak EIP-8361 pada wallet, node, dan developer bergantung pada latensi proving, adopsi client, interoperabilitas, dan spesifikasi akhir EIP-8141.

Sebagai contoh, trader yang menilai reaksi pasar di bursa seperti Gate terhadap upgrade Ethereum dapat membandingkan pengumuman jaringan dengan chart market ETH/USDT. Harga pasar, volume perdagangan, atau biaya gas tidak menentukan apakah draft EIP telah diterima atau diaktifkan secara teknis.

Pertimbangan dan Keterbatasan Keamanan

EIP-8361 memperkenalkan beberapa pertimbangan keamanan.

Pertama, soundness proof bergantung pada kebenaran sirkuit STARK dan verification key. Bug pada sirkuit bisa membuktikan pernyataan yang tidak sesuai aturan validasi.

Kedua, verifikasi proof tetap membutuhkan komputasi dan bandwidth. Penyerang dapat mengirim proof salah format atau terlalu besar, sehingga diperlukan pemeriksaan awal berbiaya rendah, batas ukuran, dan atribusi peer.

Ketiga, asumsi dapat menjadi usang. Proof valid yang dihasilkan terhadap saldo akun, nilai storage, code hash kontrak, atau nonce tertentu mungkin tidak lagi berlaku setelah blok baru mengubah state tersebut.

Keempat, kebijakan node yang tidak konsisten dapat menyebabkan fragmentasi propagasi transaksi. Client berbeda dapat memilih batas ukuran proof, batas validasi, atau default admission berbeda.

Kelima, pembuatan proof dapat menciptakan tekanan sentralisasi jika hanya sedikit layanan yang memiliki perangkat keras atau perangkat lunak teroptimasi.

EIP-8361 juga tidak menghapus biaya transaksi biasa. Jika transaksi dieksekusi di blok, pengirim atau pembayar tetap membayar biaya gas. Validity proof dapat mengurangi komputasi node off-chain yang berulang, tetapi tidak menghilangkan biaya gas Ethereum.

Apa yang Tidak Diusulkan oleh EIP-8361

Beberapa klaim yang diberikan merupakan bagian dari proposal lain dan tidak boleh dikaitkan dengan EIP-8361.

EIP-8361 tidak:

• menentukan periode transisi 18 bulan;

• menghapus staking yield floor;

• membatasi imbalan validator;

• memotong imbalan saat staking mendekati 50%;

• menciptakan ekuilibrium staking berbasis pasar;

• memperkenalkan authorization list EIP-7702;

• memperkenalkan native entry point EIP-7701;

• menciptakan jenis transaksi baru EIP-2718;

• menjamin privasi;

• menyelesaikan batch ZK-rollup;

• menggantikan fraud proof;

• mengesampingkan hak kontraktual atau hak terkait pengguna.

Bagian hak cipta draft dapat menyatakan bahwa hak cipta dan hak terkait dilepaskan di bawah CC0, seperti lazim pada EIP. Pemberitahuan hukum ini hanya berlaku untuk dokumen proposal, bukan dana pengguna, hak transaksi, atau izin smart contract.

Kesimpulan

EIP-8361 mengusulkan proof-carrying transaction admission untuk public mempool Ethereum. Prover menjalankan validation prefix EIP-8141 yang kompleks sekali, menghasilkan STARK, dan memungkinkan banyak node memverifikasi hasilnya tanpa mengulang komputasi mahal yang sama.

Kasus penggunaan terkuatnya adalah otorisasi yang dapat diprogram yang melebihi batas validasi mempool biasa, termasuk smart account lanjutan, sistem tanda tangan alternatif, paymaster, dan kontrak berbasis proof. Desain ini mengurangi komputasi node yang berulang, sambil menjaga asumsi state saat ini tetap terlihat dan dapat diperiksa ulang.

EIP-8361 tidak sama dengan settlement ZK-rollup, tantangan fraud proof, delegasi akun EIP-7702, atau desain EIP-7701 yang telah ditarik. Proposal ini masih berupa draft jaringan yang keamanan, ekonomi proving, interoperabilitas, dan dependensinya perlu dikembangkan sebelum potensi implementasi Ethereum.

FAQ

Apakah EIP-8361 menciptakan jenis transaksi baru?

Tidak. Proposal ini menerapkan proof-carrying admission pada transaksi frame EIP-8141. EIP-2718 menyediakan kerangka kerja transaksi bertipe secara umum, tetapi EIP-8361 tidak memperkenalkan envelope transaksi baru.

Apakah bukti EIP-8361 merupakan zero-knowledge proof?

Draft ini mengusulkan validity proof berbasis STARK, tetapi validitas tidak selalu berarti privasi. Bukti hanya menetapkan validasi yang benar di bawah asumsi yang dideklarasikan, bukan menyembunyikan seluruh data transaksi.

Bisakah satu proof mencakup beberapa transaksi?

Sistem proof dapat mengagregasi komputasi atau menggunakan proof rekursif, dan rollup dapat mengompresi beberapa proof transaksi menjadi satu proof. Desain EIP-8361 saat ini berfokus pada admission satu transaksi frame, bukan standarisasi agregasi batch transaksi.

Apakah EIP-8361 mengurangi biaya gas?

Tidak secara langsung. Proposal ini dapat mengurangi komputasi node off-chain yang berulang, tetapi transaksi yang dimasukkan tetap membayar gas eksekusi Ethereum.

Apa perbedaan EIP-8361 dengan EIP-7702?

EIP-7702 memungkinkan EOA mendelegasikan eksekusi kode melalui tuple otorisasi bertanda tangan. EIP-8361 mengusulkan cara berbasis proof bagi node untuk menerima transaksi dengan validasi yang mahal dan dapat diprogram.

Penafian

Konten ini bersifat edukasi dan menjelaskan proposal teknis draft, bukan upgrade Ethereum yang dijamin. Spesifikasi, rencana implementasi, asumsi keamanan, dan dukungan jaringan dapat berubah. Perkembangan protokol dan data pasar historis tidak memprediksi kinerja ETH di masa depan.