Perlindungan Replay Nonce

Apa Itu Perlindungan Replay Nonce?

Perlindungan Replay Nonce adalah metode keamanan yang mencegah transaksi kripto, pesan, permit, otorisasi, atau tindakan smart contract yang valid digunakan lebih dari sekali.Nonce adalah angka atau nilai unik yang dimaksudkan untuk digunakan hanya satu kali dalam konteks tertentu.Perlindungan replay berarti setelah tindakan yang ditandatangani digunakan, jaringan, wallet, kontrak, atau aplikasi akan menolak tindakan bertanda tangan yang sama jika seseorang mengirimkannya lagi.Dalam dunia kripto, Perlindungan Replay Nonce sangat penting karena tanda tangan digital dapat disalin dengan sempurna.Jika pengguna menandatangani transaksi atau pesan dan sistem tidak melacak apakah tindakan tersebut sudah digunakan, penyerang mungkin dapat mengirim ulang tanda tangan yang sama untuk mengulangi tindakan tersebut.Tindakan berulang itu dapat mentransfer dana lagi, menyetujui penggunaan token lagi, menjalankan pemanggilan smart contract lagi, memberikan suara lagi, mengklaim reward lagi, atau memicu otorisasi lagi.

Dokumentasi akun Ethereum menjelaskan bahwa akun Ethereum memiliki kolom nonce dan hanya satu transaksi dengan nonce tertentu yang dapat dieksekusi untuk setiap akun.

Dokumentasi yang sama menyatakan bahwa hal ini melindungi dari serangan replay, ketika transaksi bertanda tangan disiarkan berulang kali dan dieksekusi kembali.Karena itu, Perlindungan Replay Nonce merupakan salah satu lapisan keamanan dasar yang membuat tanda tangan blockchain dapat digunakan untuk mengelola nilai nyata.

Poin Penting tentang Perlindungan Replay Nonce

• Perlindungan Replay Nonce mencegah tindakan kripto bertanda tangan yang sama diterima lebih dari sekali.
• Nonce dapat berupa nonce berurutan, acak, spesifik domain, spesifik akun, spesifik kontrak, atau berbasis jalur.
• Externally owned account Ethereum menggunakan nonce transaksi berurutan untuk menghentikan eksekusi transaksi berulang.
• EIP-155 memasukkan chain ID ke dalam data transaksi yang ditandatangani untuk mengurangi risiko replay lintas chain.
• Data bertipe EIP-712 tetap memerlukan perlindungan replay di tingkat aplikasi karena tanda tangan bertipe dapat dikirimkan lebih dari sekali jika kontrak tidak menolak pengulangan.
• Permit ERC-2612 menggunakan nonce pemilik dan batas waktu untuk mencegah tanda tangan persetujuan token digunakan kembali tanpa batas waktu.
• ERC-3009 menggunakan nonce acak 32-byte dan status otorisasi untuk menghentikan transfer bertanda tangan yang berulang.
• Akun smart contract ERC-4337 menggunakan desain nonce yang lebih fleksibel untuk abstraksi akun dan alur kerja paralel.
• Perlindungan replay juga sebaiknya mengikat tanda tangan ke chain, kontrak, fungsi, pengguna, batas waktu, dan tindakan yang dimaksud secara tepat.
• Desain nonce yang lemah dapat menyebabkan double spending, persetujuan berulang, transaksi macet, kerugian akibat pencurian tanda tangan, meta-transaksi gagal, dan serangan replay lintas chain.

Mengapa Serangan Replay Penting di Dunia Kripto

Serangan replay terjadi ketika seseorang mengambil tindakan bertanda tangan yang valid dan mengirimkannya lagi di tempat yang masih menerimanya.Tanda tangan kripto tidak seperti tanda tangan tulisan tangan di atas kertas karena tanda tangan digital dapat disalin dan disiarkan ulang dengan persis.Jika transaksi bertanda tangan valid satu kali dan protokol tidak menandainya sebagai telah digunakan, transaksi yang sama mungkin dapat digunakan lagi.Hal ini berbahaya karena blockchain sering memperlakukan tanda tangan valid sebagai otorisasi.Transfer yang diputar ulang dapat memindahkan dana lagi.Persetujuan yang diputar ulang dapat memperbarui izin penggunaan.Klaim yang diputar ulang dapat menguras pool reward.Voting governance yang diputar ulang dapat mendistorsi keputusan jika kontrak tidak melacak status voting.Pesan bridge yang diputar ulang dapat mencetak atau melepaskan aset secara keliru.Perlindungan Replay Nonce mengubah tanda tangan yang dapat digunakan kembali menjadi otorisasi sekali pakai.

Cara Nonce Mencegah Replay

Nonce mencegah replay dengan membuat setiap tindakan bertanda tangan unik dan dapat dilacak.Saat pengguna menandatangani tindakan, nonce disertakan dalam data yang ditandatangani.Saat tindakan dieksekusi, protokol memeriksa apakah nonce valid dan belum digunakan.Jika pemeriksaan berhasil, tindakan dieksekusi dan nonce digunakan, dinaikkan nilainya, atau ditandai sebagai sudah terpakai.Jika seseorang mencoba mengirimkan tindakan bertanda tangan yang sama lagi, pemeriksaan nonce akan gagal.Tanda tangannya mungkin tetap valid secara matematis, tetapi sistem menolaknya karena nonce sudah digunakan.Perbedaan ini penting.Validitas tanda tangan membuktikan bahwa pengguna mengotorisasi sebuah pesan.Kebaruan nonce membuktikan bahwa otorisasi tersebut belum digunakan.Sistem yang aman membutuhkan keduanya.

Nonce Berurutan

Nonce berurutan adalah pencacah yang bertambah setelah setiap tindakan diterima.Externally owned account Ethereum menggunakan model ini untuk transaksi biasa.Jika akun memiliki nonce 10, transaksi valid berikutnya dari akun itu biasanya memerlukan nonce 10.Setelah transaksi tersebut dimasukkan ke blockchain, transaksi valid berikutnya memerlukan nonce 11.Hal ini mencegah dua transaksi berbeda dengan nonce akun yang sama dieksekusi sekaligus.Nonce berurutan juga menciptakan urutan karena nonce yang lebih tinggi biasanya tidak dapat diproses sebelum nonce sebelumnya terisi.Nonce berurutan sederhana dan efektif untuk transaksi akun biasa.Namun, nonce ini dapat merepotkan meta-transaksi, alur kerja batch, beberapa perangkat, sesi otomatis, dan sistem abstraksi akun.Karena itulah beberapa desain baru menggunakan nonce acak, jalur nonce, atau pemetaan nonce spesifik aplikasi.

Nonce Acak

Nonce acak adalah nilai unik yang dibuat secara acak, bukan dengan menghitung naik.Nonce acak umum digunakan dalam otorisasi bertanda tangan dan sistem meta-transaksi yang tidak memerlukan urutan transaksi yang ketat.ERC-3009 menggunakan nonce 32-byte yang dibuat secara acak dan unik untuk alamat pemberi otorisasi.

Standar ERC-3009 mendefinisikan fungsi status otorisasi dan event yang mencatat apakah nonce otorisasi telah digunakan atau dibatalkan.

Model ini memungkinkan beberapa otorisasi bertanda tangan yang independen tersedia secara bersamaan.Model ini menghindari masalah ketika satu nonce berurutan yang masih tertunda menghalangi otorisasi berikutnya.Komprominya adalah kontrak harus menyimpan atau memeriksa nonce acak yang telah digunakan agar otorisasi yang sama tidak dapat diulang.Nonce acak membutuhkan keacakan yang kuat.Jika nonce dapat diprediksi atau tidak sengaja digunakan ulang, perlindungan replay dapat melemah.

Nonce Akun

Nonce akun melindungi transaksi yang berasal dari akun yang sama.Untuk externally owned account, nonce membantu membuat setiap transaksi unik dan mengatur urutan transaksi.Jika pengguna mengirim dua transaksi dengan nonce akun yang sama, menurut aturan normal hanya satu yang dapat dimasukkan.Transaksi lainnya dapat ditolak, diganti, atau tetap tidak valid, bergantung pada jaringan dan aturan biaya.Karena itulah wallet melacak nonce akun berikutnya dengan cermat.Jika wallet menggunakan nonce yang terlalu rendah, nonce tersebut mungkin sudah digunakan dan transaksi akan gagal.Jika wallet menggunakan nonce yang terlalu tinggi, transaksi mungkin menunggu hingga nonce sebelumnya yang belum terisi dikonfirmasi.Jika pengguna menyiarkan transaksi pengganti dengan nonce yang sama dan biaya lebih tinggi, transaksi pengganti dapat menggantikan transaksi sebelumnya yang tertunda, bergantung pada kebijakan node.Nonce akun melindungi dari replay, tetapi juga menimbulkan masalah praktis dalam pengelolaan transaksi.Pengguna mengalami masalah tersebut sebagai transaksi macet, antrean tertunda, transaksi pengganti, atau upaya pembatalan.

Perlindungan Replay dengan Chain ID

Perlindungan replay dengan chain ID mencegah transaksi yang ditandatangani untuk satu chain agar tidak valid di chain lain yang menggunakan format transaksi serupa.Hal ini menjadi sangat penting setelah terjadinya pemisahan chain dan berkembangnya jaringan yang kompatibel dengan EVM.

EIP-155 menambahkan chain ID ke dalam data transaksi Ethereum yang ditandatangani.

Tujuannya adalah membuat transaksi valid untuk satu chain dan tidak valid untuk chain lain dengan chain ID berbeda.Tanpa perlindungan ini, transaksi yang disiarkan di satu chain berpotensi disalin dan dikirimkan ke chain lain jika akun, nonce, dan format transaksinya cocok.Perlindungan replay dengan chain ID berbeda dari perlindungan replay nonce akun.Nonce akun mencegah pengulangan transaksi yang sama di chain yang sama.Chain ID membantu mencegah penggunaan transaksi bertanda tangan yang sama di chain lain.Perlindungan replay yang kuat biasanya membutuhkan keduanya.

Pemisahan Domain

Pemisahan domain berarti mengikat tanda tangan ke konteks penandatanganan tertentu.Konteks tersebut dapat mencakup chain ID, alamat kontrak, nama protokol, versi, jenis fungsi, alamat pengguna, nonce, dan batas waktu.

EIP-712 mendefinisikan penandatanganan data terstruktur bertipe dan mencakup kolom domain seperti name, version, chainId, dan verifyingContract.

Pemisahan domain membantu mencegah tanda tangan yang ditujukan untuk satu aplikasi diterima oleh aplikasi lain.Contohnya, pengguna mungkin bermaksud menandatangani pesan untuk satu kontrak di satu chain.Jika tanda tangan tidak menyertakan chain dan kontrak verifikasi, kontrak atau chain lain dapat menafsirkannya sebagai tanda tangan yang valid.Hal ini menimbulkan risiko replay karena tanda tangan yang sama dapat berpindah konteks.Nonce mencegah penggunaan berulang di dalam satu konteks.Pemisahan domain membantu mencegah penggunaan dalam konteks yang salah.Kedua kontrol tersebut diperlukan untuk tanda tangan off-chain yang aman.

Perlindungan Replay Nonce pada Pesan EIP-712

EIP-712 membuat pesan lebih mudah dipahami oleh wallet dan pengguna, tetapi tidak otomatis membuat setiap pesan bertanda tangan hanya dapat digunakan sekali.Bagian keamanan EIP-712 memperingatkan bahwa aplikasi harus menangani pesan bertanda tangan yang sama muncul dua kali dengan benar.Artinya, kontrak atau aplikasi harus menolak pesan bertanda tangan yang berulang atau membuat tindakan berulang tersebut tidak berdampak.Pesan bertipe dapat menyertakan nonce, tetapi nonce itu harus diperiksa dan digunakan oleh kontrak penerima.Pesan bertipe dapat menyertakan batas waktu, tetapi batas waktu tersebut harus diterapkan on-chain.Pesan bertipe dapat menyertakan kontrak verifikasi, tetapi kontrak harus memverifikasi pemisah domain dengan benar.Data bertipe meningkatkan kejelasan, tetapi tidak dengan sendirinya memberikan keamanan terhadap replay.Keamanan replay berasal dari desain secara menyeluruh.Alur EIP-712 yang aman menggabungkan pemisahan domain, pelacakan nonce, validasi tanda tangan, pengikatan tindakan, dan pemeriksaan batas waktu.Menghilangkan salah satu unsur tersebut dapat menimbulkan risiko replay.

Perlindungan Replay Nonce pada Permit ERC-2612

Permit ERC-2612 memungkinkan pemilik token menyetujui penggunaan token dengan pesan bertanda tangan, bukan transaksi persetujuan on-chain langsung.Fitur ini meningkatkan pengalaman pengguna karena pihak lain dapat mengirimkan permit bertanda tangan atas nama pemilik.

Standar ERC-2612 mewajibkan fungsi nonces dan menyatakan bahwa permit harus menaikkan nonce pemilik jika permit berhasil.

Standar tersebut juga menyebutkan bahwa pemetaan nonces disediakan untuk perlindungan replay.Hal ini mencegah tanda tangan permit yang sama digunakan berulang kali.ERC-2612 juga menyertakan parameter batas waktu.Batas waktu membatasi durasi validitas permit bertanda tangan.Hal ini penting karena relayer yang menerima permit dapat memilih kapan akan mengirimkannya sebelum masa berlakunya habis.Batas waktu yang singkat dapat mengurangi risiko tanda tangan lama digunakan kemudian.Permit tanpa penanganan nonce dan batas waktu yang baik dapat menimbulkan risiko serius terkait persetujuan token.

Perlindungan Replay Nonce pada ERC-3009

ERC-3009 adalah pola otorisasi transfer bertanda tangan untuk token.Alih-alih menyetujui spender terlebih dahulu, pemegang token menandatangani otorisasi untuk transfer tertentu.Kontrak kemudian memeriksa tanda tangan, masa berlaku, dan nonce sebelum mengeksekusi transfer.ERC-3009 menggunakan pemetaan authorizationState untuk melacak apakah nonce telah digunakan.Standar tersebut menandai nonce sebagai sudah digunakan setelah otorisasi transfer berhasil.Hal ini mencegah transfer bertanda tangan yang sama dieksekusi lagi.ERC-3009 juga mendukung pembatalan otorisasi dalam sejumlah implementasi.Standar ini mencakup kolom validAfter dan validBefore untuk menentukan kapan otorisasi berlaku.Desain ini berguna untuk alur token tanpa gas atau yang menggunakan relayer.Desain ini juga menunjukkan bahwa perlindungan replay bukan sekadar pencacah.Otorisasi yang aman sebaiknya memiliki nonce unik, jangka waktu, penerima yang jelas, nilai yang pasti, dan domain yang benar.

Perlindungan Replay Nonce pada Akun Smart Contract ERC-4337

ERC-4337 menghadirkan abstraksi akun melalui UserOperation dan akun smart contract.

Standar ERC-4337 mendefinisikan nonce UserOperation sebagai parameter anti-replay.

Standar ini juga mensyaratkan agar tanda tangan bergantung pada chain ID dan alamat EntryPoint untuk mencegah replay lintas chain atau lintas EntryPoint.ERC-4337 menggunakan model nonce yang semi-abstrak.Nonce dapat diperlakukan sebagai gabungan key dan sequence.Hal ini memungkinkan akun smart contract mendukung beberapa jalur nonce.Contohnya, wallet dapat menggunakan satu jalur untuk transaksi biasa dan jalur lain untuk tindakan administratif.Hal ini membantu abstraksi akun mendukung alur kerja paralel tanpa menghilangkan perlindungan replay.Desain ini lebih fleksibel daripada satu nonce berurutan.Fleksibilitas tambahan ini juga berarti developer wallet harus mengelola jalur nonce dengan cermat.

Jalur Nonce

Jalur nonce adalah aliran nilai nonce yang independen.Alih-alih memaksa setiap tindakan dari satu akun mengikuti satu urutan, jalur nonce memungkinkan berbagai kategori tindakan berjalan secara terpisah.Fitur ini berguna untuk akun smart contract, session key, pembayaran otomatis, langganan, tindakan pemulihan, gerakan dalam game, dan wallet berbasis plugin.Contohnya, pengguna dapat memiliki satu jalur untuk pengeluaran harian dan jalur lain untuk operasi pemulihan.Transaksi di jalur pemulihan seharusnya tidak menghalangi transaksi di jalur pengeluaran harian.Jalur nonce dapat meningkatkan fleksibilitas dan pengalaman pengguna.Namun, jalur ini juga dapat menambah kompleksitas jika wallet tidak menampilkannya dengan jelas.Jika wallet menandatangani transaksi dengan jalur yang salah, tindakan tersebut mungkin gagal atau menimbulkan urutan yang tidak diharapkan.Jika kontrak tidak memvalidasi jalur dengan benar, perlindungan replay dapat menjadi tidak lengkap.Jalur nonce hanya efektif jika aturannya mudah dipahami.

Perlindungan Replay untuk Smart Contract

Smart contract sering memerlukan perlindungan replay nonce sendiri karena nonce akun biasa tidak melindungi setiap otorisasi di tingkat kontrak.Jika kontrak menerima tanda tangan, kontrak harus menentukan apakah tanda tangan tersebut sudah pernah digunakan.Contohnya, kontrak klaim airdrop dapat menggunakan pemetaan yang menandai pengguna sebagai sudah mengklaim.Kontrak governance dapat mencatat apakah pemilih sudah memberikan suara untuk suatu proposal.Kontrak permit dapat menyimpan nonce untuk setiap pemilik.Kontrak bridge dapat menyimpan ID pesan yang telah diproses.Escrow bergaya marketplace dapat menyimpan hash order yang telah terisi atau dibatalkan.Semua itu merupakan bentuk perlindungan replay.Struktur data yang digunakan dapat berbeda, tetapi tujuannya sama.Kontrak harus mencegah otorisasi yang sama menghasilkan perubahan status berulang.

Perlindungan Replay untuk Bridge

Bridge memerlukan perlindungan replay yang kuat karena memindahkan nilai atau pesan antar-chain.Pesan bridge dapat menyatakan bahwa aset telah dikunci di satu chain dan harus dicetak atau dilepaskan di chain lain.Jika pesan bridge yang sama dapat diproses dua kali, chain tujuan dapat melepaskan terlalu banyak aset.Perlindungan replay bridge sering menggunakan ID pesan, ID chain sumber, ID chain tujuan, alamat kontrak sumber, nomor urut, dan pemetaan pesan yang telah diproses.Kontrak tujuan sebaiknya menandai setiap pesan valid sebagai telah diproses.Kontrak tersebut harus menolak pesan yang sama jika dikirimkan lagi.Risiko replay lintas chain lebih tinggi karena chain dapat menggunakan format alamat, simbol token, dan antarmuka smart contract yang sama.Bridge harus mengikat setiap pesan ke chain sumber, chain tujuan, kontrak bridge, pengirim, penerima, jumlah, dan nonce yang dimaksud.Perlindungan replay bridge yang lemah dapat menyebabkan kesalahan pencetakan token, kehilangan dana, atau risiko likuiditas sistemik.

Perlindungan Replay untuk Meta-Transaksi

Meta-transaksi adalah instruksi pengguna bertanda tangan yang dikirimkan oleh pihak lain.Pengguna menandatangani instruksi secara off-chain, lalu relayer mengirimkan transaksi tersebut on-chain.Hal ini dapat memudahkan penggunaan aplikasi karena pengguna mungkin tidak perlu membayar gas secara langsung menggunakan aset native.Meta-transaksi memerlukan perlindungan replay nonce yang cermat.Jika instruksi bertanda tangan dapat dikirimkan lebih dari sekali, relayer atau penyerang dapat mengulangi tindakan tersebut.Nonce berurutan dapat menimbulkan masalah ketika pengguna menandatangani beberapa meta-transaksi di aplikasi berbeda pada waktu yang sama.Nonce acak atau ruang nonce per aplikasi dapat mengurangi benturan tersebut.Batas waktu dapat mengurangi bahaya instruksi bertanda tangan yang sudah lama.Pemisahan domain dapat mencegah tanda tangan meta-transaksi satu aplikasi digunakan di aplikasi lain.Keamanan meta-transaksi sama bergantungnya pada perlindungan replay seperti pada verifikasi tanda tangan.

Perlindungan Replay untuk Pesan Login Wallet

Banyak aplikasi kripto meminta pengguna menandatangani pesan untuk membuktikan kepemilikan wallet.Hal ini umum digunakan untuk login, menghubungkan akun, memperbarui profil, dan autentikasi off-chain.Tanda tangan login sebaiknya menyertakan nonce atau tantangan yang dibuat oleh server.Server sebaiknya menandai tantangan tersebut sebagai sudah digunakan setelah login berhasil.Jika memungkinkan, pesan juga sebaiknya menyertakan domain, chain, waktu penerbitan, waktu kedaluwarsa, dan tindakan yang dimaksud.Jika pesan login tidak menyertakan tantangan baru, penyerang dapat memutar ulang tanda tangan lama untuk menyamar sebagai pengguna.Jika pesan login tidak menyertakan domain yang benar, tanda tangan dari satu situs web dapat digunakan di situs web lain.Login wallet sering kali berlangsung off-chain, tetapi perlindungan replay tetap penting.Tanda tangan yang membuktikan kepemilikan wallet tidak boleh menjadi kata sandi permanen yang dapat digunakan kembali.Tanda tangan login paling aman bersifat spesifik, baru, terbatas, dan mudah dipahami.

Perlindungan Replay untuk Governance

Sistem governance membutuhkan perlindungan replay karena suara dan delegasi tidak seharusnya dihitung lebih dari yang dimaksudkan.Kontrak voting dapat menyimpan status apakah suatu alamat sudah memberikan suara untuk proposal tertentu.Kontrak delegasi melalui tanda tangan dapat menggunakan nonce agar tanda tangan delegasi yang sama tidak dapat digunakan berulang kali.Sistem eksekusi proposal dapat menandai proposal sebagai telah dieksekusi setelah eksekusi berhasil.Perlindungan replay juga penting antar-chain jika keputusan governance diterapkan di beberapa jaringan.Pesan governance yang ditandatangani untuk satu chain tidak seharusnya otomatis dieksekusi di chain lain, kecuali memang dimaksudkan demikian.Kegagalan perlindungan replay governance dapat berdampak serius karena dapat mengubah parameter protokol, memindahkan dana treasury, meng-upgrade kontrak, atau mengubah kontrol risiko.Kontrak governance yang baik menggunakan ID proposal, chain ID, alamat kontrak, periode voting, nonce, dan status eksekusi dengan cermat.Suara hanya seharusnya dapat digunakan kembali jika sistem memang mengizinkan perubahan suara sebelum batas waktu.Meski demikian, aturan penghitungan akhir harus jelas.

Perlindungan Replay untuk Airdrop dan Klaim

Kontrak klaim airdrop dan reward sering menggunakan perlindungan replay agar pengguna tidak dapat mengklaim lebih dari sekali.Sistem klaim sederhana dapat menyimpan pemetaan klaim untuk setiap alamat yang memenuhi syarat.Airdrop Merkle dapat memverifikasi proof pengguna, kemudian menandai alamat atau indeks klaim sebagai telah digunakan.Klaim reward berbasis tanda tangan dapat menyertakan nonce, ID klaim, ID kampanye, batas waktu, dan alamat pengguna.Tanpa perlindungan replay, proof klaim yang valid dapat digunakan kembali hingga pool terkuras.Perlindungan replay juga sebaiknya mempertimbangkan pemisahan kampanye.Tanda tangan klaim untuk Kampanye A tidak boleh berlaku untuk Kampanye B.Klaim di satu chain tidak boleh berlaku di chain lain, kecuali memang dirancang demikian.Klaim untuk satu token tidak boleh mengotorisasi token lain.Desain klaim yang baik mengikat proof ke pengguna, kampanye, chain, token, jumlah, dan nonce yang benar.

Perlindungan Replay dan Batas Waktu

Batas waktu adalah batas masa berlaku suatu otorisasi bertanda tangan.Batas waktu tidak menggantikan nonce, tetapi mengurangi rentang waktu ketika tanda tangan yang dicuri atau tertunda dapat digunakan.Permit ERC-2612 menggunakan kolom batas waktu.ERC-3009 menggunakan kolom validAfter dan validBefore.UserOperation ERC-4337 dapat menyertakan rentang validitas melalui data validasi.Batas waktu sangat berguna ketika pengguna memberikan tanda tangan kepada relayer atau aplikasi yang dapat memilih kapan tanda tangan tersebut dikirimkan.Tanpa batas waktu, otorisasi bertanda tangan lama mungkin tetap dapat digunakan jauh lebih lama daripada yang diperkirakan pengguna.Dengan batas waktu, tanda tangan menjadi tidak valid setelah waktu yang ditentukan.Batas waktu yang singkat dapat meningkatkan keamanan, tetapi berpotensi meningkatkan kegagalan transaksi saat jaringan padat.Batas waktu terbaik bergantung pada nilai, risiko, urgensi, dan perkiraan waktu settlement tindakan tersebut.

Perlindungan Replay dan Idempotensi

Idempotensi berarti pengulangan tindakan yang sama memberikan hasil akhir yang sama seperti ketika tindakan itu dilakukan sekali.EIP-712 menyebutkan bahwa aplikasi sebaiknya menolak pesan bertanda tangan yang berulang atau membuat tindakan yang diotorisasi bersifat idempoten.Contohnya, menetapkan nama profil pengguna ke nilai yang sama dua kali mungkin tidak berbahaya.Mentransfer 100 token dua kali bukan tindakan yang tidak berbahaya.Menyetujui spender dua kali mungkin berbahaya atau tidak, bergantung pada jumlah dan allowance saat ini.Voting governance dua kali dapat merugikan jika kedua suara dihitung.Mengklaim reward dua kali merugikan jika pengguna menerima reward ganda.Perancang sebaiknya menentukan apakah eksekusi berulang harus ditolak atau dibuat tidak berbahaya.Sebagian besar tindakan yang memindahkan nilai sebaiknya menolak eksekusi berulang.Idempotensi dapat berguna untuk pembaruan status berisiko rendah, tetapi tidak boleh digunakan sembarangan untuk tindakan finansial.

Perlindungan Replay dan Pengikatan Tanda Tangan

Tanda tangan sebaiknya terikat pada tindakan persis yang dimaksudkan pengguna.Artinya, pesan bertanda tangan sebaiknya mencakup penerima, jumlah, token, kontrak, chain ID, tujuan fungsi, nonce, batas waktu, dan parameter penting lainnya.Jika tanda tangan hanya mengotorisasi sesuatu secara samar, penyerang mungkin dapat menggunakannya kembali dalam konteks yang lebih luas.Jika tanda tangan hanya mengesahkan suatu angka tanpa alamat token, angka tersebut dapat ditafsirkan untuk token yang salah.Jika tanda tangan hanya mengesahkan tujuan tanpa chain ID, tanda tangan tersebut dapat diputar ulang di chain lain.Jika tanda tangan hanya mengesahkan alamat pengguna tanpa alamat kontrak, kontrak lain dapat menerimanya.Perlindungan replay paling kuat ketika tanda tangan memiliki cakupan yang sempit.Tanda tangan dengan cakupan sempit menyatakan secara persis apa yang diizinkan dan tidak lebih dari itu.Tanda tangan dengan cakupan luas membuka peluang replay, penyalahgunaan, dan kebingungan pengguna.Wallet sebaiknya menampilkan detail ini dengan jelas sebelum pengguna menandatangani.

Perlindungan Replay dan Phishing

Perlindungan Replay Nonce tidak dapat sepenuhnya melindungi pengguna dari phishing.Jika pengguna menandatangani pesan berbahaya dengan nonce yang valid, penyerang mungkin dapat menggunakannya satu kali.Nonce dapat mencegah penggunaan berulang, tetapi penggunaan pertama tetap dapat merugikan.Contohnya, situs phishing dapat meminta pengguna menandatangani permit yang memberikan persetujuan penggunaan token.Permit tersebut mungkin menyertakan nonce dan batas waktu yang valid.Setelah dikirimkan, penyerang tetap dapat menggunakan otorisasi valid tersebut satu kali.Perlindungan replay mencegah duplikasi, bukan niat jahat.Pengguna tetap harus memeriksa hal yang ditandatangani.Wallet tetap harus menampilkan peringatan yang jelas dan mudah dipahami.Kontrak tetap harus membatasi kewenangan tanda tangan untuk tindakan tertentu.

Perlindungan Replay dan Front-Running

Front-running terjadi ketika pihak lain melihat transaksi atau tanda tangan lalu mengirimkan transaksinya sendiri lebih dulu.Perlindungan Replay Nonce dapat membatasi kerugian dengan membuat tanda tangan hanya dapat digunakan sekali.Namun, perlindungan ini tidak selalu mencegah pelaku front-running menjadi pihak pertama yang menggunakan tanda tangan tersebut.ERC-2612 menyebutkan bahwa pihak lain dapat melakukan front-running terhadap pemanggilan permit sebelum pihak yang dimaksud mengirimkannya, meskipun dampak persetujuan akhirnya dapat sama bagi penanda tangan.ERC-3009 menyertakan receiveWithAuthorization untuk mengurangi masalah front-running tertentu dengan memastikan penerima sesuai dengan pihak yang memanggil.Hal ini menunjukkan bahwa perlindungan replay dan perlindungan front-running saling terkait, tetapi berbeda.Nonce mencegah eksekusi berulang.Kontrol front-running menentukan siapa yang boleh mengirimkan atau memperoleh manfaat dari eksekusi pertama.Tanda tangan bernilai tinggi sebaiknya menyertakan pengikatan penerima, batas waktu, dan maksud yang spesifik terhadap fungsi.Perancang tidak seharusnya menganggap pemeriksaan nonce saja dapat mengatasi semua serangan mempool.

Perlindungan Replay dan Penggunaan Ulang Antar-Kontrak

Replay antar-kontrak terjadi ketika tanda tangan yang ditujukan untuk satu kontrak diterima oleh kontrak lain.Hal ini dapat terjadi jika data bertanda tangan tidak menyertakan alamat kontrak verifikasi.Pemisahan domain EIP-712 membantu mengurangi risiko ini dengan menyertakan verifyingContract di dalam domain.ERC-2612 merekomendasikan pemisah domain yang unik untuk kontrak dan chain.Replay antar-kontrak juga dapat terjadi ketika beberapa kontrak menggunakan skema tanda tangan yang sama, tetapi tidak menyertakan domain spesifik kontrak.Contohnya, dua kontrak token dapat menerima pesan mirip permit yang sama jika data bertanda tangan terlalu umum.Pengguna mungkin bermaksud menyetujui satu token, tetapi tanda tangan yang sama dapat ditafsirkan oleh token lain.Karena itulah pengikatan alamat kontrak sangat penting.Tanda tangan valid tidak boleh berpindah bebas antar-kontrak.Tanda tangan tersebut seharusnya hanya berlaku untuk satu domain verifikasi tertentu.

Perlindungan Replay dan Penggunaan Ulang Lintas Chain

Replay lintas chain terjadi ketika transaksi atau pesan bertanda tangan yang ditujukan untuk satu chain diterima di chain lain.EIP-155 mengurangi risiko ini untuk transaksi bergaya Ethereum dengan menambahkan chain ID ke hash transaksi yang ditandatangani.Data bertipe EIP-712 juga mendukung chainId di domain penandatanganan.Replay lintas chain masih dapat terjadi pada pesan tingkat aplikasi jika data bertanda tangan tidak menyertakan chain ID.Contohnya, tanda tangan bridge, DAO, permit token, atau login sebaiknya menyebutkan chain yang dimaksud jika konteks chain penting.Chain ID sangat penting untuk jaringan yang kompatibel dengan EVM karena alamat dan bytecode kontrak dapat terlihat serupa di berbagai chain.Pengguna dapat mengendalikan alamat yang sama di beberapa chain.Kontrak dapat di-deploy pada alamat yang sama di beberapa chain melalui deployment deterministik.Tanpa pengikatan chain, tanda tangan dapat dengan mudah digunakan di berbagai konteks secara berbahaya.Desain yang aman menyatakan chain secara eksplisit.

Perlindungan Replay dan Penggantian Transaksi

Penggantian transaksi adalah saat pengguna menyiarkan transaksi baru dengan nonce akun yang sama dan biaya lebih tinggi untuk menggantikan transaksi tertunda.Hal ini bukan serangan replay.Ini merupakan teknik pengelolaan transaksi yang lazim dalam banyak alur kerja bergaya Ethereum.Intinya, hanya satu transaksi dengan nonce tersebut yang pada akhirnya dapat dieksekusi.Pengguna dapat mengganti transaksi lambat dengan versi yang lebih cepat.Pengguna dapat mengirim transaksi tanpa nilai kepada dirinya sendiri dengan nonce yang sama untuk membatalkan transaksi tertunda.Transaksi pengganti harus mengikuti aturan kenaikan biaya jaringan agar diterima oleh node.Perlindungan Replay Nonce membuat penggantian transaksi dapat dilakukan.Nonce memaksa jaringan memilih satu transaksi untuk slot tersebut.Pengguna perlu berhati-hati karena mengganti nonce yang salah dapat membatalkan atau menggantikan tindakan yang masih ingin dilakukan.

Perlindungan Replay dan Transaksi Macet

Transaksi dapat macet jika transaksi dengan biaya rendah tetap tertunda.Jika transaksi tersebut menggunakan nonce berikutnya yang diwajibkan, transaksi berikutnya dari akun yang sama juga dapat tertahan di belakangnya.Ini merupakan dampak samping nonce berurutan.Dalam urutan transaksi biasa, akun tidak dapat melewati nonce yang belum terisi.Pengguna mungkin perlu mempercepat atau membatalkan transaksi macet dengan mengirimkan transaksi pengganti yang menggunakan nonce sama.Wallet biasanya mengelola hal ini secara otomatis, tetapi pengaturan nonce manual dapat membingungkan.Jika pengguna menetapkan nonce terlalu tinggi, transaksi mungkin tidak dikonfirmasi sampai nonce sebelumnya terisi.Jika pengguna menetapkan nonce terlalu rendah, transaksi mungkin gagal karena nonce tersebut sudah digunakan.Perlindungan Replay Nonce melindungi akun, tetapi juga memerlukan pengurutan yang cermat.Pengguna tingkat lanjut sebaiknya memahami status nonce sebelum mengubah nonce transaksi secara manual.

Perlindungan Replay dan Session Key

Session key adalah kunci dengan penggunaan terbatas yang dapat mengotorisasi tindakan tertentu selama periode waktu tertentu.Session key berguna untuk game, langganan, strategi otomatis, dan wallet abstraksi akun.Session key memerlukan perlindungan replay nonce yang kuat karena dapat menandatangani banyak tindakan kecil.Otorisasi session key sebaiknya menyertakan batas seperti fungsi yang diizinkan, batas pengeluaran, kontrak tujuan, waktu kedaluwarsa, chain ID, dan aturan nonce.Tanpa perlindungan nonce, penyerang yang menangkap satu tanda tangan session key dapat memutar ulangnya berkali-kali.Tanpa batasan tindakan, session key dapat memiliki kewenangan yang terlalu luas.Jalur nonce dapat membantu memisahkan tindakan session key dari tindakan wallet utama.Hal ini dapat memperlancar pengalaman pengguna sekaligus mempertahankan keamanan replay.Session key sebaiknya mudah dicabut.Cakupannya juga sebaiknya cukup sempit untuk membatasi dampak jika terjadi replay.

Perlindungan Replay dan Wallet Multisig

Wallet multisig juga memerlukan perlindungan replay.Transaksi multisig sering memiliki nonce internal yang melacak tindakan wallet yang telah dieksekusi.Para penanda tangan menyetujui hash transaksi tertentu yang mencakup nonce wallet dan detail tindakan.Setelah multisig mengeksekusi transaksi, nonce bertambah atau hash transaksi ditandai sebagai sudah dieksekusi.Hal ini mencegah kelompok tanda tangan yang sama digunakan lagi untuk mengeksekusi tindakan yang sama dua kali.Perlindungan replay multisig sebaiknya mengikat tanda tangan ke alamat wallet, chain ID, alamat target, nilai, data, jenis operasi, dan nonce.Jika wallet multisig di-deploy di beberapa chain, perlindungan replay lintas chain menjadi sangat penting.Penanda tangan sebaiknya memastikan chain dan alamat wallet sebelum menyetujui.Tanda tangan multisig tidak otomatis aman hanya karena ditandatangani oleh beberapa orang.Payload yang ditandatangani tetap harus spesifik dan tahan replay.

Perlindungan Replay dan Oracle

Sistem oracle dapat menandatangani pembaruan harga, pengesahan data, laporan cadangan, hasil randomisasi, atau pesan cross-chain.Paket data bertanda tangan tersebut memerlukan perlindungan replay.Pembaruan harga yang sudah kedaluwarsa tidak boleh diterima selamanya.Hasil randomisasi tidak boleh digunakan kembali dalam ronde game yang berbeda.Pengesahan cadangan tidak boleh diputar ulang setelah kedaluwarsa.Jika relevan, pesan oracle sebaiknya menyertakan ID feed, ID ronde, timestamp, nomor urut, chain ID, dan kontrak tujuan.Kontrak sebaiknya menolak pesan oracle yang sudah kedaluwarsa atau sudah digunakan.Perlindungan replay sangat penting karena smart contract dapat bertindak secara otomatis berdasarkan data oracle.Jika data lama dapat diputar ulang, likuidasi, settlement, minting, penebusan, atau pembayaran dapat menjadi keliru.Kesegaran oracle dan kontrol nonce sama-sama merupakan bagian dari keamanan smart contract.Tanda tangan yang benar tidak cukup jika datanya sudah lama atau digunakan kembali.

Perlindungan Replay dan Persetujuan Token

Persetujuan token merupakan salah satu area paling sensitif terkait perlindungan replay.Persetujuan on-chain biasa menggunakan nonce akun pada transaksi dan memperbarui status allowance.Permit bertanda tangan menggunakan nonce tingkat kontrak dan batas waktu untuk mengotorisasi persetujuan tanpa transaksi langsung dari pemilik.Jika tanda tangan permit dapat diputar ulang, spender dapat memperoleh kembali allowance setelah pengguna mengira persetujuan tersebut sudah tidak berlaku.Jika permit tidak menyertakan spender, token, nilai, nonce, batas waktu, atau domain, tanda tangan dapat disalahgunakan.Pengguna sebaiknya memperlakukan persetujuan bertanda tangan sebagai otorisasi finansial yang serius.Wallet sebaiknya menampilkan spender, token, jumlah, batas waktu, dan aplikasi dengan jelas.Kontrak sebaiknya langsung menolak nonce permit yang sudah digunakan.Aplikasi sebaiknya menghindari permintaan persetujuan tanpa batas kecuali benar-benar diperlukan.Desain persetujuan yang tahan replay mengurangi salah satu jalur serangan pengurasan wallet yang paling umum.

Perlindungan Replay dan Upgrade Smart Contract

Kontrak yang dapat di-upgrade menimbulkan pertimbangan replay tambahan.Jika kontrak di-upgrade, tanda tangan lama mungkin tetap valid, kecuali versi domain, logika nonce, atau aturan validasinya berubah.EIP-712 menyertakan kolom version dalam domain penandatanganan untuk alasan ini.Upgrade kontrak besar sebaiknya mempertimbangkan apakah otorisasi lama tetap aman.Jika tanda tangan lama seharusnya tidak berlaku setelah upgrade, kontrak mungkin memerlukan versi domain baru atau metode untuk membatalkan nonce.Jika tanda tangan lama seharusnya tetap berlaku, upgrade harus mempertahankan status nonce dengan benar.Kegagalan memigrasikan status nonce dapat membuat tanda tangan lama dapat diputar ulang atau membuat tanda tangan valid tidak dapat digunakan.Rencana upgrade sebaiknya mencakup migrasi tanda tangan, perubahan domain, tata letak penyimpanan nonce, dan komunikasi kepada pengguna.Perlindungan replay bukan hanya persoalan saat deployment.Perlindungan ini harus tetap berfungsi setelah upgrade dan migrasi.

Perlindungan Replay dan Fork

Fork chain dapat menimbulkan risiko replay jika kedua sisi fork menerima format transaksi dan status yang sama.Jika pengguna memiliki private key dan status akun yang sama di kedua chain, transaksi di satu fork dapat diputar ulang di fork lain, kecuali perlindungannya berbeda.Perlindungan chain ID EIP-155 dirancang untuk mengurangi risiko ini pada transaksi Ethereum.Namun, tanda tangan di tingkat aplikasi tetap memerlukan pengikatan chain.Permit, voting governance, pesan bridge, atau order off-chain yang ditandatangani sebelum atau sesudah fork dapat berperilaku tidak terduga jika konteks chain tidak jelas.Pengguna sebaiknya berhati-hati selama fork dan pemisahan chain.Wallet dan aplikasi sebaiknya memperbarui chain ID dan pemisah domain dengan benar.Kontrak sebaiknya menghindari penyimpanan chain ID dalam cache dengan cara yang menimbulkan risiko replay setelah pemisahan, kecuali desainnya dapat menanganinya dengan aman.Perlindungan replay fork merupakan persoalan protokol sekaligus aplikasi.Kedua lapisan tersebut perlu diperhatikan.

Manfaat Perlindungan Replay Nonce

Manfaat pertama adalah otorisasi sekali pakai.Tindakan bertanda tangan dapat digunakan sekali, lalu ditolak.Manfaat kedua adalah keunikan transaksi.Transaksi dari akun yang sama dapat dibedakan menggunakan nilai nonce.Manfaat ketiga adalah pengurutan.Nonce berurutan membantu menentukan urutan transaksi akun yang valid.Manfaat keempat adalah keamanan lintas chain jika dikombinasikan dengan chain ID.Tanda tangan dapat diikat ke jaringan yang dimaksud.Manfaat kelima adalah keamanan smart contract yang lebih baik.Kontrak dapat mencegah permit, klaim, suara, transfer, dan pesan bridge digunakan berulang kali.Manfaat keenam adalah pengalaman pengguna yang lebih aman.Wallet dapat mendeteksi tindakan tertunda, transaksi macet, dan transaksi pengganti dengan lebih andal.

Risiko dan Keterbatasan Perlindungan Replay Nonce

Keterbatasan pertama adalah perlindungan nonce tidak menghentikan penggunaan berbahaya pertama atas pesan bertanda tangan.Jika pengguna menandatangani otorisasi yang berbahaya, nonce hanya mencegah penggunaan berulang setelah eksekusi pertama.Keterbatasan kedua adalah kompleksitas pengelolaan transaksi.Nonce berurutan dapat menyebabkan transaksi macet dan antrean terblokir.Keterbatasan ketiga adalah biaya penyimpanan.Kontrak yang menyimpan nonce acak yang telah digunakan dapat meningkatkan penggunaan penyimpanan on-chain.Keterbatasan keempat adalah risiko implementasi.Pemeriksaan nonce yang terlewat dapat membuat tanda tangan bisa diputar ulang.Keterbatasan kelima adalah kompleksitas lintas domain.Nonce dapat melindungi satu kontrak, tetapi tidak melindungi kontrak atau chain lain.Keterbatasan keenam adalah risiko upgrade.Status nonce dapat terganggu selama migrasi kontrak jika tidak ditangani dengan cermat.

Kesalahan Umum dalam Perlindungan Replay Nonce

Salah satu kesalahan umum adalah memverifikasi tanda tangan tetapi tidak memeriksa nonce.Kesalahan lainnya adalah memeriksa nonce tetapi lupa menaikkannya atau menandainya sebagai sudah digunakan.Kesalahan ketiga adalah menggunakan satu nonce global untuk semua pengguna alih-alih nonce per pengguna.Kesalahan keempat adalah tidak menyertakan chain ID dalam data bertanda tangan.Kesalahan kelima adalah tidak menyertakan alamat kontrak verifikasi dalam data bertipe.Kesalahan keenam adalah menerima tanda tangan tanpa batas waktu.Kesalahan ketujuh adalah mengizinkan nonce yang sama digunakan untuk jenis tindakan berbeda.Kesalahan kedelapan adalah gagal memigrasikan penyimpanan nonce selama upgrade.Kesalahan kesembilan adalah menggunakan nonce acak yang dapat diprediksi.Kesalahan kesepuluh adalah menganggap EIP-712 otomatis mencegah semua serangan replay.

Praktik Terbaik bagi Developer

Sertakan nonce di setiap otorisasi off-chain yang dapat mengubah nilai atau status.Lacak nonce per penanda tangan, bukan secara global, kecuali desainnya jelas memerlukan urutan global.Naikkan nonce atau tandai sebagai sudah digunakan sebelum atau selama eksekusi dengan cara yang tidak dapat dilewati.Sertakan chain ID dalam domain bertanda tangan jika konteks chain penting.Sertakan alamat kontrak verifikasi dalam domain bertanda tangan.Sertakan maksud fungsi, penerima, jumlah, token, batas waktu, dan parameter terkait secara persis dalam pesan bertanda tangan.Gunakan batas waktu atau rentang validitas untuk tanda tangan yang dikirim melalui relayer.Pisahkan ruang nonce untuk alur kerja yang tidak terkait jika eksekusi paralel diperlukan.Hasilkan event ketika otorisasi digunakan atau dibatalkan.Uji upaya replay, tanda tangan lintas chain, upgrade kontrak, pembatalan, dan jalur eksekusi yang gagal sebelum deployment.

Praktik Terbaik untuk Wallet dan Aplikasi

Tampilkan chain, kontrak, spender, jumlah, batas waktu, konteks nonce, dan jenis tindakan kepada pengguna sebelum mereka menandatangani.Peringatkan pengguna ketika tanda tangan memberikan kewenangan penggunaan dana atau otorisasi jangka panjang.Gunakan tantangan login baru untuk autentikasi wallet.Tandai tantangan autentikasi sebagai sudah digunakan setelah login.Jangan meminta pengguna menandatangani pesan yang samar atau sulit dibaca.Gunakan data bertipe EIP-712 untuk penandatanganan terstruktur jika memungkinkan.Tangani nonce transaksi macet dengan opsi percepat dan batalkan yang jelas.Jangan menyembunyikan perilaku penggantian transaksi dari pengguna.Dukung jalur nonce abstraksi akun hanya jika antarmuka dapat menjelaskannya dengan aman.Lindungi pengguna agar tidak menandatangani permintaan lama, kedaluwarsa, atau untuk chain yang salah.

Praktik Terbaik bagi Pengguna

Baca notifikasi wallet sebelum menandatangani pesan atau transaksi apa pun.Periksa chain sebelum menandatangani.Periksa kontrak atau aplikasi yang meminta tanda tangan.Periksa token, spender, jumlah, dan batas waktu dalam persetujuan bergaya permit.Tolak tanda tangan yang samar, tanpa batas, atau tidak terkait dengan tindakan yang ingin Anda lakukan.Jangan menandatangani pesan login dari domain yang mencurigakan.Jangan menganggap nonce membuat tanda tangan berbahaya menjadi aman.Gunakan hardware wallet atau multisig untuk saldo besar jika memungkinkan.Cabut persetujuan token yang tidak diperlukan jika sesuai.Berhati-hatilah saat mengatur nonce secara manual, kecuali Anda memahami status transaksi tertunda.

Kapan Perlindungan Replay Nonce Paling Penting

Perlindungan Replay Nonce paling penting ketika tanda tangan mengotorisasi perpindahan nilai.Perlindungan ini penting untuk transaksi blockchain biasa.Perlindungan ini penting untuk persetujuan permit.Perlindungan ini penting untuk transfer token tanpa gas.Perlindungan ini penting untuk pesan bridge.Perlindungan ini penting untuk voting dan delegasi governance.Perlindungan ini penting untuk klaim airdrop dan reward.Perlindungan ini penting untuk tantangan login wallet.Perlindungan ini penting untuk transaksi multisig dan UserOperation abstraksi akun.Perlindungan ini penting di mana pun tanda tangan yang disalin dapat menimbulkan dampak berulang atau tidak diinginkan.

Perlindungan Replay Nonce dalam Satu Kalimat

Perlindungan Replay Nonce adalah penggunaan nilai nonce yang unik, terlacak, dan terikat pada konteks untuk memastikan transaksi, pesan, atau otorisasi kripto bertanda tangan hanya dapat dieksekusi sekali di chain, kontrak, dan konteks aplikasi yang dimaksud.

FAQ

Apa arti Perlindungan Replay Nonce?

Perlindungan Replay Nonce berarti mencegah tindakan kripto bertanda tangan yang sama diterima lebih dari sekali dengan memeriksa dan menggunakan nonce unik.

Apa itu nonce dalam kripto?

Nonce adalah angka atau nilai unik yang digunakan satu kali dalam konteks tertentu untuk membuat transaksi, pesan, atau otorisasi menjadi unik.

Apa itu serangan replay?

Serangan replay terjadi ketika seseorang menyalin tindakan bertanda tangan yang valid dan mengirimkannya lagi untuk mengulangi atau menyalahgunakan otorisasi tersebut.

Bagaimana Ethereum menggunakan nonce?

Akun Ethereum menggunakan pencacah nonce agar hanya satu transaksi dengan nonce tertentu yang dapat dieksekusi untuk setiap akun.

Apa itu perlindungan replay dengan chain ID?

Perlindungan replay dengan chain ID mengikat transaksi atau pesan ke blockchain tertentu agar tidak mudah digunakan kembali di chain lain.

Apakah EIP-712 otomatis menghentikan serangan replay?

Tidak. EIP-712 menyusun data bertanda tangan, tetapi aplikasi tetap memerlukan pemeriksaan nonce, batas waktu, dan pemisahan domain yang benar.

Mengapa permit memerlukan nonce?

Permit memerlukan nonce agar persetujuan token bertanda tangan yang sama tidak dapat dikirimkan berulang kali.

Apa perbedaan nonce dan batas waktu?

Nonce membuat tanda tangan hanya dapat digunakan sekali, sedangkan batas waktu membatasi durasi validitas tanda tangan.

Bisakah perlindungan replay menghentikan phishing?

Tidak. Perlindungan replay dapat mencegah penggunaan berulang, tetapi tidak dapat menghentikan penggunaan berbahaya pertama jika pengguna menandatangani otorisasi yang berbahaya.

Apa yang terjadi jika nonce digunakan kembali?

Jika penanganan nonce berfungsi dengan benar, penggunaan kedua seharusnya gagal. Namun, jika sistem dirancang dengan buruk, penggunaan ulang nonce dapat menimbulkan masalah replay atau kegagalan transaksi.

Mengapa smart contract memerlukan pemeriksaan nonce sendiri?

Smart contract memerlukan pemeriksaan nonce karena nonce akun biasa tidak otomatis melindungi tanda tangan off-chain, permit, klaim, suara, atau pesan bridge.

Apa desain perlindungan replay yang paling aman?

Desain paling aman menggabungkan nonce per penanda tangan, chain ID, kontrak verifikasi, detail tindakan yang tepat, batas waktu, pelacakan status penggunaan, dan validasi tanda tangan yang cermat.

Kesimpulan

Perlindungan Replay Nonce merupakan salah satu fondasi keamanan mata uang kripto yang sering luput dari perhatian.Perlindungan ini memastikan tanda tangan valid tidak berubah menjadi cek kosong yang dapat digunakan berulang kali.Tanda tangan blockchain membuktikan bahwa private key menyetujui suatu pesan, tetapi tidak otomatis membuktikan bahwa persetujuan tersebut masih baru, belum digunakan, atau hanya berlaku untuk satu kali eksekusi.Nonce menambahkan lapisan kebaruan tersebut.Jika nonce diperiksa dan digunakan dengan benar, tindakan bertanda tangan yang sama tidak dapat dieksekusi lagi.Hal ini melindungi transaksi biasa, permit token, transfer tanpa gas, operasi akun smart contract, persetujuan multisig, pesan bridge, voting governance, tantangan login, klaim reward, dan banyak alur kerja kripto lainnya.Perlindungan replay modern lebih dari sekadar satu pencacah.Perlindungan ini sering menggabungkan nonce akun, nonce tingkat kontrak, ID otorisasi acak, chain ID, alamat kontrak verifikasi, batas waktu, rentang validitas, jalur nonce, dan pemetaan pesan yang telah diproses.Setiap lapisan menangani masalah replay yang berbeda.Nonce akun menghentikan transaksi berulang dari akun yang sama di chain yang sama.Chain ID mencegah transaksi disalin ke chain lain.Nonce kontrak mencegah pesan bertanda tangan digunakan kembali di dalam aplikasi.Batas waktu mencegah tanda tangan lama tetap valid selamanya.Pemisahan domain mencegah tanda tangan berpindah ke kontrak atau aplikasi yang salah.Jalur nonce memungkinkan akun smart contract mendukung alur kerja paralel tanpa kehilangan perlindungan replay.Risikonya serius jika kontrol ini tidak tersedia.Tanda tangan yang dapat diputar ulang dapat menguras dana, mengulangi persetujuan, menggandakan klaim, mengeksekusi pesan bridge dua kali, atau mendistorsi governance.Meskipun perlindungan nonce tersedia, pengguna tetap dapat dirugikan oleh phishing jika sekali saja menandatangani otorisasi berbahaya.Karena itu, perlindungan replay harus disertai notifikasi wallet yang jelas, cakupan tanda tangan yang sempit, desain kontrak yang kuat, dan perilaku pengguna yang cermat.Bagi developer, aturannya sederhana.Setiap tanda tangan yang dapat memindahkan nilai atau mengubah status penting memerlukan nonce, domain, dan aturan penggunaan yang jelas.Bagi wallet, aturannya adalah menunjukkan dengan tepat apa yang diotorisasi pengguna sebelum mereka menandatangani.Bagi pengguna, aturannya adalah memperlakukan setiap tanda tangan sebagai tindakan nyata, bukan konfirmasi yang tidak berbahaya.Perlindungan Replay Nonce tidak membuat kripto bebas risiko.Perlindungan ini membuat otorisasi bertanda tangan dapat digunakan secara praktis dengan memastikan satu persetujuan berarti satu penggunaan yang dimaksudkan, dalam satu konteks yang dimaksudkan, bukan jumlah replay tanpa batas di masa mendatang.