Di dunia blockchain, pengguna sering perlu memberikan izin (izin) yang memungkinkan kontrak pintar menghabiskan token atas nama mereka. Misalnya, ketika menggunakan pertukaran terdesentralisasi (DEX) untuk menukar token, pengguna harus terlebih dahulu memberi wewenang kepada kontrak pertukaran untuk mentransfer jumlah token tertentu dari dompet mereka. Di bawah tradisional ERC-20standar, proses ini memerlukan dua transaksi on-chain yang terpisah: satu untuk persetujuan dan yang lain untuk transfer token yang sebenarnya. Proses dua langkah ini tidak hanya merepotkan tetapi juga menimbulkan biaya gas tambahan. Untuk meningkatkan pengalaman pengguna dan keamanan, komunitas Ethereum memperkenalkan mekanisme otorisasi berbasis tanda tangan,Izin (seperti EIP-2612), dan kemudian mengembangkan versi lanjutan yang disebut Permit2. Mekanisme baru ini memungkinkan pengguna untuk memberikan persetujuan token melalui tanda tangan off-chain, menghindari kebutuhan untuk transaksi on-chain tambahan.

Dalam artikel ini, kami akan memulai dengan dasar-dasar dengan menjelaskan bagaimana persetujuan ERC-20 tradisional bekerja dan batasan-batasannya. Kemudian, kami akan membahas bagaimana Permit dan Permit2 berfungsi, menyoroti keuntungan dan kompromi mereka, dan membahas bagaimana mereka meningkatkan efisiensi dan keamanan. Kami juga akan mengeksplorasi potensi risiko keamanan, terutama serangan phishing yang melibatkan tanda tangan jahat, dan memberikan tips untuk tetap aman. Apakah Anda baru mengenal blockchain atau baru memulai perjalanan investasi kripto Anda, panduan ini bertujuan untuk membantu Anda memahami inovasi teknis penting ini.

Dasar-dasar Model Otorisasi ERC-20

Sebelum masuk ke Permit, mari kita pertama-tama melihat bagaimana model otorisasi token ERC-20 tradisional bekerja, dan batasan yang ditimbulkannya.

Bagaimana Persetujuan ERC-20 Tradisional Bekerja

ERC-20 adalah standar untuk token di Ethereum. Ini mendefinisikan fungsi seperti approve dan transferFrom, yang bersama-sama memungkinkan otorisasi token. Otorisasi di sini berarti bahwa pemegang token (pemilik) memungkinkan akun lain, biasanya kontrak pintar (pengeluar), untuk mentransfer sejumlah token atas nama mereka. Proses dasarnya berjalan seperti ini:

1. Pemegang token memanggil fungsi approve (penerima, jumlah) dari kontrak token. Ini mencatat kuota dalam pemetaan internal kontrak, biasanya diekspresikan sebagai kuota[pemilik][penerima] = jumlah. Sebagai contoh, jika pengguna A memberi otorisasi kepada kontrak Uniswap untuk menghabiskan hingga 100 token, kontrak akan menyimpan kuota[A][Uniswap] = 100. Langkah ini memerlukan transaksi on-chain dan biaya gas yang dibayarkan oleh A.
2. DeleGate.io Transfer (transferFrom): Kemudian, ketika Uniswap (atau aplikasi lain) perlu mengeluarkan token atas nama A, ia memanggil transferFrom(A, B, jumlah) pada kontrak token. Kontrak memeriksa apakah izin[A][Uniswap] cukup. Jika iya, kontrak mentransfer jumlah yang ditentukan dari A ke B dan mengurangi jumlah tersebut dari izin.

Keterbatasan dan Tantangan dari Model Persetujuan

Model dua langkah di atas memungkinkan pengguna untuk memberi izin kepada kontrak untuk mengelola dana mereka, tanpa pernah membagikan kunci privat mereka. Namun, pendekatan tradisional ini juga datang dengan beberapa masalah praktis:

Diperlukan dua transaksi, pengalaman pengguna yang buruk
Setiap kali seorang pengguna ingin menggunakan token baru pada dApp, mereka harus terlebih dahulu mengirim transaksi persetujuan terpisah sebelum mereka benar-benar dapat melakukan tindakan yang diinginkan (seperti pertukaran atau staking). Ini berarti dompet mereka akan meminta konfirmasi dua kali dan menagih biaya Gas tambahan. Bagi pemula, langkah tambahan ini bisa membingungkan dan merepotkan.

Manajemen persetujuan yang terfragmentasi
Ketika pengguna berinteraksi dengan beberapa dAppsMenggunakan token yang sama (misalnya, melakukan perdagangan di Uniswap dan kemudian mendepositokannya ke protokol DeFi yang berbeda), setiap dApp memerlukan persetujuan terpisah, meskipun itu adalah token yang sama di dompet yang sama. Hal ini mengakibatkan persetujuan yang berulang, membuang waktu dan gas.

Selain itu, karena setiap dApp mengelola alokasinya sendiri secara independen, pengguna memiliki sedikit kontrol terpusat atas persetujuan mereka. Beberapa alat, seperti Revoke.cashdanDeBank, memungkinkan pengguna untuk melihat dan mengelola izin token, tetapi banyak pengguna tidak menyadarinya. Dan bahkan jika mereka menyadari, mencabut izin masih memerlukan transaksi on-chain, yang menambah biaya. Akibatnya, banyak persetujuan lama atau tidak terpakai hanya dilupakan.

Risiko persetujuan tanpa batas
Untuk menghindari transaksi persetujuan yang sering, banyak dApps menyarankan pengguna memberikan persetujuan tanpa batas, memungkinkan kontrak untuk menghabiskan seluruh saldo token pengguna, tanpa tanggal kedaluwarsa. Meskipun pendekatan ini menghemat usaha nantinya, itu memperkenalkan risiko keamanan yang serius: jika dApp atau kontrak diretas, seorang penyerang bisa menguras semua token yang disetujui.

Tantangan-tantangan ini mendorong para pengembang untuk mencari alternatif yang lebih baik. Idealnya, pengguna hanya perlu menandatangani sekali (lebih baik dilakukan di luar rantai dan bebas gas) untuk menyelesaikan baik persetujuan maupun tindakan. Persetujuan juga sebaiknya dibatasi cakupannya dan durasinya untuk meminimalkan risiko potensial. Inilah motivasi di balik pengenalan ERC-20 Permit.

Izin: Otorisasi Berbasis Tanda Tangan ERC-20 (EIP-2612)

Konsep Permit pertama kali diperkenalkan olehDAIkontrak stablecoin dan kemudian distandarisasi sebagai EIP-2612. Singkatnya, Permit memungkinkan pengguna untuk memberi otorisasi transfer token menggunakan tanda tangan off-chain, menghilangkan kebutuhan untuk mengirim transaksi approve on-chain terpisah. Mari kita telusuri lebih dekat bagaimana cara kerjanya dan fitur-fitur khasnya.

Bagaimana Permit Bekerja

Permit adalah mekanisme otorisasi berdasarkan tanda tangan digital. Di bawah standar EIP-2612, kontrak token ERC-20 yang mendukung Permit menambahkan fungsi yang disebut permit() yang terlihat seperti ini:

fungsi izinkan(
pemilik alamat, pengeluar alamat,
nilai uint256, batas waktu uint256,
uint8 v, bytes32 r, bytes32 s
) eksternal;

Di sini, pemilik, pengeluar, dan nilai menentukan siapa yang memberi izin, siapa yang menerima izin, dan jumlah yang diizinkan. batas waktu menunjukkan kapan tanda tangan kedaluwarsa. Parameter v, r, dan s membentuk ECDSAtanda tangan digital. Dengan menggunakan Permit, pengguna melewati persetujuan on-chain terpisah—mereka hanya perlu menandatangani pesan (tanpa membayar Gas) dan menyertakan tanda tangan ini bersama transaksi mereka untuk menyelesaikan otorisasi dalam satu langkah.

Alur Izin

Dibandingkan dengan persetujuan tradisional, Permit menghilangkan kebutuhan akan transaksi tambahan on-chain, menghemat waktu dan biaya Gas. Ini juga memungkinkan kontrol yang sangat halus atas persetujuan. Misalnya, pengguna bisa menandatangani Permit yang memungkinkan pengeluaran tepat 50 USDC, berlaku hanya selama 5 menit. Bahkan jika tanda tangan terungkap, itu menjadi tidak dapat digunakan setelah batas waktu, mengurangi risiko. Saat ini, banyak protokol DeFi, seperti pertukaran terdesentralisasi dan platform peminjaman, sudah mendukung Permit. Contoh terkenal termasuk Uniswap V2/V3token LP, DAI, danUSDC, yang telah menerapkan standar EIP-2612, memungkinkan persetujuan berbasis tanda tangan satu langkah.

Namun, keterbatasan terbesar dari Permit adalah bahwa itu harus diimplementasikan langsung dalam kontrak token. Jika pengembang token belum menambahkan metode permit() - artinya tidak mendukung EIP-2612 - maka Permit tidak dapat digunakan. Karena EIP-2612 hanya diperkenalkan pada tahun 2020, banyak token lama tidak menyertakannya, dan bahkan token baru pun tidak selalu mengadopsinya. Hal ini membatasi penerapan Permit: token yang tidak didukung masih memerlukan alur persetujuan tradisional.

Masalah lain adalah bahwa perangkat lunak dompet harus menangani dan menampilkan tanda tangan Izin dengan benar, yang biasanya diformat menggunakan EIP-712. Sebagian besar dompet utama sekarang mendukung ini, tetapi beberapa masih menampilkan data mentah daripada pesan yang dapat dibaca manusia, sehingga sulit bagi pengguna untuk memahami apa yang mereka tandatangani. Tanpa antarmuka yang jelas untuk EIP-2612, dompet mungkin menghambat pemahaman pengguna tentang persetujuan berbasis tanda tangan. Selain itu, dalam kasus implementasi paralel (seperti kontrak dengan alamat identik di rantai yang berbeda), tanda tangan dapat potensial digunakan kembali di lingkungan lain. Oleh karena itu, pengguna harus memverifikasi bahwa ID rantai dan alamat kontrak dalam tanda tangan mereka cocok dengan lingkungan saat ini untuk mencegah izin yang diberikan untuk token di Rantai A disalahgunakan oleh alamat kontrak identik di Rantai B.

Pada intinya, Permit secara signifikan meningkatkan efisiensi dan fleksibilitas persetujuan ERC-20, menandai tonggak penting dalam mekanisme persetujuan tanpa gas. Namun, ini bukan solusi yang sempurna: ini memerlukan dukungan tingkat token, dan memperkenalkan risiko baru. Selanjutnya, kami akan memeriksa bagaimana Permit2 Uniswap membangun dan memperluas landasan yang diletakkan oleh Permit.

Permit2: Kontrak Manajemen Otorisasi Universal

Seiring mekanisme Izin semakin populer, sebuah tantangan baru muncul: bagaimana memperluas kenyamanan otorisasi berbasis tanda tangan ke token yang tidak mendukung Izin? Untuk mengatasi isu ini dan mengoptimalkan pengalaman otorisasi di berbagai skenario, tim Uniswap memperkenalkan Permit2 pada tahun 2022. Berbeda dengan fitur khusus token, Permit2 adalah kontrak pintar manajemen otorisasi mandiri. Ini bertindak sebagai perantara untuk otorisasi token, menyediakan fungsionalitas izin yang terpadu dan ditingkatkan. Mari kita analisis prinsip dan fitur dari Permit2.

Bagaimana Permit2 Bekerja

Permit2 berfungsi sebagai layanan relay otorisasi. Konsep intinya sederhana: pengguna memberikan persetujuan satu kali ke kontrak Permit2, yang kemudian mengelola sub-otorisasi berikutnya ke berbagai aplikasi. Beginilah cara kerjanya:

1. Otorisasi Izin Satu Kali Permit2: Pengguna menyetujui Permit2 untuk setiap token menggunakan metode tradisional approve(Permit2, max_amount). Jumlah besar atau tak terbatas disarankan karena ini adalah persetujuan utama. Setelah selesai, kontrak Permit2 mendapatkan kemampuan untuk memanggil transferFrom atas nama pengguna untuk token tersebut. Ini memerlukan transaksi di rantai tetapi hanya perlu dilakukan sekali.
2. Tanda Tangan Off-chain untuk Sub-otorisasi: Ketika pengguna ingin berinteraksi dengan DApp (misalnya, menggunakan Uniswap Universal Router untuk pertukaran multi-token), mereka menandatangani pesan otorisasi off-chain mengikuti spesifikasi Permit2. Tanda tangan ini mencakup rincian seperti token yang diizinkan, jumlah, pengeluar target (seperti kontrak DApp tertentu), dan waktu kedaluwarsa.
3. Permintaan Transfer DApp Menggunakan Tanda Tangan: Ketika sebuah DApp menerima tanda tangan pengguna dan perlu menggunakan token, daripada memanggil kontrak token secara langsung, DApp tersebut memanggil fungsi-fungsi Permit2 (seperti permitTransferFrom). Fungsi ini memverifikasi data tanda tangan pengguna dan mengonfirmasi bahwa operasi berada dalam izin yang diberikan (token, jumlah, batas waktu). Setelah verifikasi, Permit2 menggunakan persetujuan utamanya untuk memanggil transferFrom, memindahkan token dari pengguna ke penerima yang ditentukan. Titik penting: Kontrak Permit2 itu sendiri bertindak sebagai pengeluar, menggunakan otoritasnya sendiri untuk mentransfer token, dengan langkah verifikasi tanda tangan tambahan.
4. Penyelesaian Operasi: Setelah Permit2 berhasil mengeksekusi transferFrom, dana akan berpindah dengan lancar dari pengguna ke DApp atau alamat yang ditentukan. Dari sudut pandang pengguna, mereka hanya perlu memberikan tanda tangan dalam transaksi, sementara kontrak menangani semua tindakan selanjutnya.

Alur otorisasi Permit2 mudah: pengguna hanya perlu memberikan persetujuan maksimum kepada Permit2 sekali per token. Setelah itu, saat berinteraksi dengan aplikasi (seperti Uniswap Universal Router atau protokol lain), mereka hanya perlu menyertakan tanda tangan Permit2 dalam transaksi mereka untuk menyelesaikan otorisasi dan transfer, tanpa persetujuan tambahan di rantai. Kontrak Permit2 memverifikasi tanda tangan dan mengeksekusi transfer menggunakan persetujuan masternya. (Sumber:Memperkenalkan Permit2 & Universal Router)

Melalui model ini, Permit2 memperluas konsep otorisasi berbasis tanda tangan EIP-2612 ke semua token ERC-20, terlepas dari apakah mereka menerapkan metode permit() itu sendiri. Selama pengguna awalnya mengotorisasi kontrak Permit2, mereka dapat menggunakan tanda tangan untuk operasi selanjutnya. Khususnya, Uniswap merancang Permit2 sebagai kontrak tanpa pemilik dan tidak dapat ditingkatkan yang diterapkan dengan alamat yang sama di seluruh mainnet Ethereum dan beberapa jaringan Layer 2. Ini berarti semua aplikasi benar-benar menggunakan instance Permit2 yang sama, mencapai fungsionalitas "setujui sekali, gunakan di mana-mana" yang sebenarnya.

Fitur Utama dari Permit2

Sebagai sistem otorisasi generasi berikutnya, Permit2 tidak hanya memungkinkan persetujuan berbasis tanda tangan untuk semua token tetapi juga menawarkan fitur tambahan untuk meningkatkan keamanan dan kegunaan. Berikut adalah fitur utamanya:

Kedaluwarsa Otomatis
Semua izin Permit2 dapat mencakup cap waktu untuk kedaluwarsa. Pengguna dapat menentukan kapan sub-izin mereka harus kedaluwarsa saat menandatangani. Setelah batas waktu berlalu, Permit2 akan menolak tanda tangan, bahkan jika persetujuan master masih aktif. Ini efektif mengatasi risiko persetujuan tak terbatas yang tidak digunakan.

Transfer Tanda Tangan Sekali Pakai
Permit2 menawarkan mode transfer tanda tangan langsung di mana pengguna dapat memberikan otorisasi transfer token tertentu ke penerima hanya dengan menggunakan tanda tangan, tanpa perlu mengatur izin terlebih dahulu. Ini sempurna untuk skenario pembayaran sekali pakai: pengguna dapat menandatangani pesan yang memberi otorisasi transfer 100 token ke alamat teman, dan teman atau perantara dapat mengeksekusi transfer menggunakan tanda tangan ini. Setelah digunakan, tanda tangan menjadi tidak valid, tidak meninggalkan izin yang mengendap.

Persetujuan dan Transfer Paket
Permit2 memprioritaskan efisiensi dengan memungkinkan pemrosesan batch dari beberapa persetujuan atau transfer. Pengguna dapat mengotorisasi jumlah yang berbeda dari beberapa token ke satu protokol dengan satu tanda tangan, atau melakukan transfer beberapa token dalam satu transaksi. Ini menghemat Gas dan mengurangi langkah-langkah untuk pengguna tingkat lanjut.

Pencabutan Paket
Selain persetujuan kelompok, pengguna dapat mencabut izin untuk beberapa token/aplikasi dalam satu transaksi. Hal ini membuat membersihkan persetujuan historis menjadi lebih nyaman.

Menyaksikan Data Tambahan
Permit2 mencakup antarmuka sepertipermitWitnessTransferFromyang memungkinkan data verifikasi tambahan disertakan dalam tanda tangan. Ini mendukung skenario yang lebih kompleks, seperti menyertakan rincian transaksi tertentu dalam tanda tangan order untuk mencegah penggunaan ulang tanda tangan dalam konteks yang berbeda.

Melalui fitur-fitur ini, Permit2 tidak hanya mereplikasi semua manfaat dari Permit tetapi juga meningkatkan fleksibilitas dan kontrol keamanan. Pencabutan otomatis dan transfer tanda tangan sekali pakai, khususnya, membuat otorisasi yang minimal menjadi norma, mengurangi risiko jangka panjang.

Singkatnya, Permit2 berfungsi sebagai perpanjangan dan peningkatan mekanisme Izin tradisional. Mari kita periksa perbedaan utama antara kedua pendekatan ini:

Adopsi dan Implementasi Ekosistem Permit2

Sejak Uniswap memperkenalkan Permit2, banyak proyek telah mengintegrasikan mekanisme ini, mempercepat standarisasi industri. Menurut data terbaru dari Dune AnalyticsPer April 2025, lebih dari 3,1 juta alamat Ethereum mainnet telah memberikan otorisasi ke kontrak Permit2, menunjukkan adopsi yang luas.

Status Ekosistem Permit2 dan Implementasinya. Sumber: Analisis Dune

Sebagai contoh, Uniswap telah mengintegrasikan Permit2 ke dalam Universal Router-nya, memungkinkan pertukaran multi-token dan NFT dalam satu transaksi. Melalui Universal Router, pengguna dapat menggabungkan beberapa operasi dalam satu transaksi, seperti pertukaran tiga token untuk dua token target dan pembelian NFT, dengan semua persyaratan otorisasi ditangani oleh tanda tangan Permit2. Ini secara signifikan menyederhanakan proses dan mengurangi biaya Gas total, memperlihatkan dampak langsung Permit2 dalam meningkatkan pengalaman pengguna.

Selain itu, dengan implementasi sumber terbuka Permit2 di berbagai rantai, semakin banyak dompet dan alat DApp yang mulai mendukungnya. Alat keamanan seperti Revoke.cash telah memperbarui layanan mereka untuk memungkinkan pengguna melihat dan mencabut catatan izin Permit2. Matcha juga telah menerapkan modul SignatureTransfer Permit2, memungkinkan mekanisme "izin satu kali".

Meskipun kemajuan ini, adopsi luas Permit2 menghadapi tantangan. Di satu sisi, pengembang memerlukan waktu tambahan untuk integrasi: dibandingkan dengan menggunakan persetujuan ERC-20 langsung, mengimplementasikan Permit2 memerlukan penanganan logika tanda tangan, meningkatkan biaya pengembangan. Ini mungkin membuat tim-tim kecil enggan. Di sisi lain, pendidikan pengguna sangat penting: banyak DApps yang menggunakan Permit2 perlu mengajarkan pengguna tentang signifikansi tanda tangan. Saat ini, keuntungan bersatu Permit2 nampaknya lebih besar daripada titik gesekan ini, namun penetrasi pasar penuh masih akan memerlukan waktu.

Membandingkan Permit2 dengan Solusi Baru: Kunci Sesi dan ERC-4337

Selama 8 tahun terakhir, mekanisme otorisasi ERC-20 telah berkembang dari transaksi ganda hingga tanda tangan tanpa gas dan sekarang menjadi akun cerdas. Setiap kemajuan telah berusaha untuk mengoptimalkan keseimbangan antara pengalaman pengguna (mengurangi persyaratan transaksi dan tanda tangan) dan biaya gas. Berikut perbandingan dari teknologi ini:

Selain Permit2, dua solusi otorisasi yang sedang berkembang layak dicatat adalah Kunci Sesi danERC-4337 Abstraksi Akun, masing-masing menawarkan pendekatan yang berbeda terhadap masalah tersebut.

Kunci Sesi sangat unik, karena bukan model otorisasi yang ketat tetapi lebih merupakan mekanisme kunci sementara pada tingkat dompet atau akun. Alih-alih memodifikasi kontrak token, mereka memungkinkan dompet untuk menghasilkan kunci pribadi sementara yang terbatas waktu dan jumlahnya untuk operasi tertentu. Hal ini membuat mereka ideal untuk pembelian item game dan pembayaran mikro satu kali. Fokus mereka adalah mengurangi risiko otorisasi tunggal, dirancang khusus untuk interaksi pengguna sementara, berbeda dengan pendekatan modifikasi kontrak dari Permit/Permit2.

ERC-4337 mengambil pendekatan berbeda dengan menyematkan logika otorisasi langsung ke dalam akun cerdas, memungkinkan pengguna untuk menyesuaikan kondisi otorisasi dan mungkin melewati langkah persetujuan tradisional. Melalui mekanisme UserOperation dan Paymaster yang fleksibel, ini mencapai keamanan dan pengalaman pengguna yang ditingkatkan.

Mengamati tren masa depan, solusi-solusi berbeda ini kemungkinan besar akan hidup berdampingan. Dalam jangka pendek, Permit2 akan terus menjadi standar untuk DApps yang sedang muncul, meningkatkan pengalaman pengguna melalui otorisasi sekali pakai sambil mempromosikan pendidikan keamanan dan dukungan alat untuk mengurangi risiko phishing. Dalam jangka menengah, ketika ERC-4337 dan abstraksi akun menjadi lebih tersebar luas di Layer 2s dan mainnet, pengguna akan dapat lepas dari batasan persetujuan ERC-20 tradisional, mengelola otorisasi lebih tepat dan cerdas, yang berpotensi mengurangi kebutuhan akan Permit2.

Visi jangka panjang adalah menciptakan pengalaman otorisasi yang mulus dan intuitif seperti Web2, di mana pengguna cukup klik tombol dan semua persetujuan yang diperlukan terjadi secara otomatis di latar belakang, dengan petunjuk jelas muncul hanya dalam situasi berisiko tinggi. Mencapai visi ini akan memerlukan kolaborasi dan inovasi yang berkelanjutan di sepanjang protokol dasar, dompet, dan dApps. Permit2 merupakan langkah penting dalam perjalanan transisi ini, tetapi masih ada jalan panjang sebelum mencapai keadaan ideal. Sepanjang jalan, baik komunitas maupun pengembang harus mempertahankan pendekatan yang pragmatis, memahami sepenuhnya kelebihan dan keterbatasan dari setiap solusi dan bekerja sama untuk membangun lingkungan otorisasi yang lebih aman dan ramah pengguna.

Secara keseluruhan, Permit2 menawarkan solusi praktis yang dapat segera diimplementasikan, sementara teknologi seperti Kunci Sesi dan ERC-4337 menunjukkan perbaikan yang lebih mendasar dan jangka panjang dalam cara otorisasi ditangani.

Risiko Keamanan Otorisasi Berbasis Tanda Tangan

Seperti halnya dengan teknologi baru lainnya, Permit dan Permit2 tidak hanya memperkenalkan efisiensi baru tetapi juga risiko baru, terutama seputar serangan otorisasi berbasis tanda tangan.

Dalam skema berbasis tanda tangan seperti Permit2 dan EIP-2612 Permit, desain kontrak inti mencakup beberapa lapisan perlindungan untuk menjaga terhadap penyalahgunaan dan serangan replay:

1. Perlindungan Replay Berbasis Nonce

Permit2 mempertahankan hitungan nonce terpisah untuk setiap tupel (pemilik, token, pemberi izin). Setiap kali pengguna menandatangani otorisasi baru, nonce yang sesuai akan ditambahkan. Jika seorang penyerang mencoba untuk menggunakan kembali tanda tangan lama, itu akan gagal karena kontrak memeriksa apakah nonce tersebut sudah digunakan.

2. Penegakan Batas Waktu

Setiap tanda tangan harus mencakup bidang tenggat waktu. Ketika kontrak memverifikasi tanda tangan, itu memastikan waktu blok saat ini kurang dari atau sama dengan tenggat waktu. Jika tanda tangan telah kedaluwarsa—bahkan jika itu sebaliknya valid—akan ditolak. Ini mencegah otorisasi yang berumur panjang dari dieksploitasi nantinya.

3. Kontrol Tunjangan Berbutir Halus

Tanda tangan Permit2 dapat menentukan tunjangan maksimum. Sebelum transfer token terjadi, kontrak memeriksa bahwa jumlah yang diminta berada dalam batas ini. Kontrak tidak secara otomatis menghabiskan jumlah penuh yang disetujui, memungkinkan pengguna untuk menggunakan tunjangan mereka di bagian dan mengurangi risiko eksploitasi penuh.

4. Mode Penggunaan Tunggal dan Batch

Selain persetujuan berbasis izin yang sedang berlangsung, Permit2 juga mendukung tanda tangan sekali pakai melalui SignatureTransfer. Tanda tangan ini hanya berlaku untuk satu transaksi saja dan menjadi tidak valid segera setelah dieksekusi. Ini ideal untuk pembayaran satu kali dan mencegah tanda tangan dari digunakan kembali atau dieksploitasi nantinya.

Proteksi berlapis ini membantu skema otorisasi gaya Izin meningkatkan pengalaman pengguna dan menghemat gas sambil juga meminimalkan risiko klasik seperti "serangan ulang", "otorisasi berlebihan", dan "validitas tanda tangan yang tidak pasti".

Namun, bahkan dengan perlindungan tingkat kontrak yang aman, rekayasa sosial (terutama phishing) tetap menjadi ancaman paling sulit untuk dibendung. Pada bagian berikutnya, kita akan melihat taktik phishing umum dan bagaimana para penyerang memperdaya pengguna untuk tanpa sadar menandatangani persetujuan berbahaya yang menyalahgunakan Permit2. Kami juga akan memberikan tips tentang bagaimana cara tetap aman.

Bagaimana Serangan Phising Tanda Tangan Terjadi?

Phising tanda tangan terjadi ketika penyerang menipu korban untuk menandatangani pesan-pesan tertentu untuk mendapatkan kontrol atas aset mereka. Sementara serangan tradisional mungkin melibatkan mengeksekusi kontrak atau transaksi berbahaya, dalam era Izin, satu otorisasi tanda tangan berbahaya sudah cukup untuk mengosongkan dana. Berikut adalah bagaimana serangan-serangan ini biasanya berkembang:

1. Korban mengklik versi palsu dari situs web DEX terkenal (situs phishing). Ketika pengguna mencoba berinteraksi, situs tersebut meminta tanda tangan dompet, mengklaim itu untuk 'konfirmasi login' atau tujuan lain yang tampak sah. Namun, permintaan ini sebenarnya adalah tanda tangan otorisasi Permit2, memberikan izin tanpa batas kepada kontrak penyerang untuk menarik USDC korban dengan periode validitas yang diperpanjang.
2. Korban, yang kurang waspada, menandatangani permintaan secara langsung. Pada titik ini, tidak ada gas yang dihabiskan dan tidak ada aktivitas on-chain yang terjadi, tidak meninggalkan jejak yang mencurigakan.
3. Setelah penyerang mendapatkan tanda tangan, mereka segera memanggil fungsi izin() dari kontrak Permit2 untuk mengirimkannya. Setelah kontrak Permit2 memvalidasi tanda tangan, itu mencatat otorisasi untuk kontrak penyerang di bawah alamat korban (setara dengan korban melakukan persetujuan, tetapi diselesaikan oleh penyerang). Operasi ini mungkin tetap tidak terperhatikan oleh korban karena dompet mereka tidak menunjukkan pengeluaran - hanya pemetaan izin token mereka yang diperbarui di blockchain.
4. Selanjutnya, penyerang segera memulai transaksi transferFrom(korban, alamat_penyerang, jumlah) dari alamat mereka, berhasil mentransfer USDC korban menggunakan izin Permit2 terbaru. Korban baru menyadari pencurian ketika sudah terlambat.

Dalam serangan ini, pengguna tidak pernah melakukan transaksi "transfer" atau "otorisasi" yang jelas, namun aset mereka menghilang secara misterius. Kuncinya terletak pada tanda tangan itu sendiri menjadi otorisasi. Penyerang dengan hati-hati menyamarkan permintaan tanda tangan agar muncul sebagai operasi normal, menurunkan kewaspadaan pengguna. Namun, setelah ditandatangani, itu seperti menyerahkan kunci aset Anda.

Lebih buruk lagi, beberapa penyerang menggunakan metode teknis untuk meningkatkan ketidakterlihatan. Misalnya, mereka menggunakan mekanisme CREATE2 dari Ethereum untuk menghasilkan alamat kontrak jahat yang unik untuk setiap korban. Hal ini membuat daftar hitam tradisional tidak efektif karena setiap serangan menggunakan alamat yang berbeda.

Kebanyakan insiden phishing crypto terbaru melibatkan otorisasi tanda tangan. Sebagai contoh, Scam Sniffer’s Statistikdari awal 2024 menunjukkan lebih dari $55 juta aset dicuri melalui phishing tanda tangan hanya dalam satu bulan. Sejak aktivasi Permit2, penyerang menjadi lebih agresif dalam menginduksi pengguna untuk menandatangani izin Permit/Permit2, yang mengakibatkan banyak korban dalam waktu singkat. Jelas, ketika otorisasi tanda tangan disalahgunakan, itu dapat menjadi sangat merusak dan sulit dideteksi.

Mengapa Risiko Phishing Berbasis Tanda Tangan Lebih Tinggi daripada Metode Tradisional?

Otorisasi jahat tradisional memerlukan pengguna untuk melaksanakan transaksi on-chain, di mana dompet umumnya menampilkan peringatan yang jelas seperti “Anda memberikan otorisasi kepada XXX untuk menggunakan token Anda” dan memerlukan biaya gas. Pengguna berpengalaman cenderung lebih berhati-hati tentang hal ini. Namun, permintaan tanda tangan dalam antarmuka dompet seringkali hanya dijelaskan sebagai “permintaan tanda tangan data” daripada tindakan keuangan, menyebabkan pengguna untuk menurunkan kewaspadaan mereka. Selain itu, karena tanda tangan tidak memerlukan biaya gas, para penyerang dapat meluncurkan upaya phishing dalam skala besar tanpa harus khawatir tentang biaya - mereka mendapatkan keuntungan bahkan dengan hanya beberapa percobaan berhasil.

Selain itu, dompet yang berbeda menampilkan pesan EIP-712 dengan berbagai cara. Beberapa dompet modern (seperti yang terbaruMetaMask ) mengurai dan menampilkan bidang dengan jelas, menampilkan pesan seperti "otorisasi kontrak untuk membelanjakan X jumlah token Anda." Namun, banyak dompet hanya menampilkan data heksadesimal atau deskripsi sederhana, sehingga sulit bagi pengguna rata-rata untuk memverifikasi keasliannya. Penyerang mengeksploitasi ini dengan menyematkan deskripsi yang menipu dalam pesan (seperti berpura-pura menjadi tanda tangan mint NFT) untuk mengelabui pengguna agar menandatangani.

Karena otorisasi tanda tangan tidak langsung memengaruhi aset, korban mungkin tidak segera mendeteksi ancaman tersebut. Penyerang dapat secara strategis mengatur waktu serangan mereka. Alih-alih mengeksekusi segera, mereka mungkin menunggu sampai dompet korban berisi lebih banyak aset atau sampai saat tertentu, yang mempersulit upaya pelacakan. Dengan tanda tangan yang memiliki masa berlaku yang diperpanjang, penyerang juga dapat mengeksploitasi pergerakan harga untuk memaksimalkan keuntungan mereka, secara efektif memberi mereka opsi perdagangan gratis. Risiko ini menjelaskan mengapa tanda tangan Izin biasanya memberlakukan tenggat waktu yang singkat.

Kemampuan Permit2 untuk mengotorisasi beberapa token dengan satu tanda tangan membuatnya sangat menantang bagi pengguna untuk memahami implikasinya sepenuhnya. Misalnya, situs web phishing mungkin meminta tanda tangan Permit2 sambil menyoroti izin hanya untuk satu atau dua token, namun diam-diam menyematkan otorisasi ekstensif untuk token tambahan dalam tanda tangan yang sama. Pengguna dapat dengan mudah mengabaikan izin tersembunyi ini jika dompet mereka tidak menampilkan semua detail dengan jelas. Selain itu, penyerang sering menggunakan nama kontrak yang menipu seperti "WalletGuard" dalam tanda tangan mereka, menutupi kontrak jahat yang dirancang untuk mencuri izin token.

Bagaimana Pengguna Dapat Melindungi Diri Mereka Dari Serangan Tanda Tangan?

Ingatlah bahwa menandatangani sama dengan memberikan persetujuan—jangan pernah biarkan ketiadaan biaya gas membuat Anda lengah. Ketika dompet Anda meminta tanda tangan, baca dengan seksama detail pesan tersebut. Pastikan situs web atau DApp yang meminta tanda tangan tersebut sah dan bahwa konten pesan sesuai dengan tindakan yang dimaksudkan. Misalnya, jika Anda hanya masuk ke situs web, tanda tangan harus berisi teks login yang dapat dibaca (seperti yang digunakan oleh sebagian besar DApps), bukan serangkaian alamat token dan angka.

Pastikan perangkat lunak dompet Anda mendukung tampilan data EIP-712. Dompet utama seperti MetaMask,TrustWalletdanLedger Livesedang meningkatkan pengalaman tampilan konten tanda tangan mereka. Sebagai contoh, MetaMask sekarang dapat mengurai pesan izin umum ke dalam bahasa yang mudah dimengerti. Jika dompet Anda hanya menampilkan data heksadesimal panjang saat menandatangani, pertimbangkan untuk beralih atau memperbarui. Pengguna dompet keras juga sebaiknya memperbarui firmware mereka untuk mendukung format baru, atau mereka mungkin tidak dapat melihat informasi dengan benar di layar.

Baik menggunakan tanda tangan Permit atau Permit2, biasanya Anda dapat mengatur parameter otorisasi. Jangan menandatangani jumlah yang tidak terbatas (nilai = 2^256-1) kecuali benar-benar diperlukan - sebaliknya, hanya otorisasi jumlah yang Anda butuhkan ditambah buffer kecil. Juga, jangan menetapkan batas waktu terlalu jauh ke depan. Dengan cara ini, bahkan jika tanda tangan Anda jatuh ke tangan yang salah, kerugian potensial terbatas, dan tanda tangan akan kadaluwarsa pada akhirnya.

Kembangkan kebiasaan untuk secara teratur memeriksa status otorisasi alamat Anda menggunakan alat seperti Revoke.cash, Etherscan Token Approval, atau fitur bawaan dompet Anda. Ini termasuk persetujuan tradisional dan izin Permit2. Jika Anda menemukan otorisasi yang mencurigakan atau tidak perlu, cabut segera. Untuk Permit2, perhatikan dua tingkat pencabutan: pertama, otorisasi master (persetujuan Anda untuk kontrak Permit2 itu sendiri, yang mungkin ingin Anda atur ke 0 saat tidak digunakan); kedua, sub-otorisasi (izin Permit2 ke berbagai DApps, yang biasanya otomatis kedaluwarsa tetapi bisa diakhiri lebih awal jika memiliki periode validitas yang panjang). Jika Anda mencurigai bahwa Anda telah menandatangani Permit yang mencurigakan, tindakan teraman adalah untuk segera menyesuaikan nonce: tandatangani izin baru ke pengeluar yang sama (bahkan dengan alokasi 0) untuk membatalkan tanda tangan lama yang berada dalam kepemilikan penyerang.

Selalu berhati-hati saat mengunjungi situs web yang tidak dikenal atau mengunduh aplikasi. Jangan mengklik tautan yang tidak dikenal, terutama 'penawaran promosi' atau 'acara mint' yang dibagikan melalui iklan media sosial atau pesan pribadi. Banyak upaya phishing terjadi melalui akun resmi palsu yang memposting tautan aktivitas penipuan, mengarah ke permintaan tanda tangan. Buatlah kebiasaan untuk langsung mengetik URL DApp resmi atau menggunakan bookmark untuk menghindari jebakan situs web palsu.

Sebagai kesimpulan, menemukan keseimbangan antara kenyamanan dan keamanan sangat penting. Sementara teknologi Permit nyaman, pengguna harus tetap waspada terhadap pencegahan risiko. Saat ekosistem semakin matang, produk dompet dan plugin browser sedang mengembangkan perlindungan terhadap phishing tanda tangan, seperti peringatan untuk tanda tangan yang melibatkan jumlah besar. Kami bertujuan untuk mengatasi serangan semacam itu melalui peningkatan teknis dan edukatif di masa depan.

Kesimpulan

Dari keterbatasan model otorisasi ERC-20 tradisional hingga lahirnya Permit, dan kemudian ke Permit2 inovatif Uniswap, kita telah menyaksikan upaya ekosistem Ethereum untuk meningkatkan pengalaman pengguna dan keamanan. Permit2 secara signifikan menyederhanakan proses otorisasi token melalui tanda tangan off-chain, mengurangi risiko persetujuan ulang dan izin tanpa batas, sambil memperkenalkan fitur-fitur berguna seperti mekanisme kadaluwarsa dan operasi kelompok. Namun, mekanisme baru ini datang dengan tanggung jawab baru—pengguna perlu meningkatkan kesadaran keamanan mereka, sementara dompet dan DApps harus bekerja sama untuk melindungi pengguna dari serangan tanda tangan. Melihat ke depan, dengan perkembangan teknologi lebih lanjut, seperti abstraksi akun, manajemen otorisasi token diharapkan menjadi lebih lancar dan aman.