Token onayları: vermeye devam ettiğiniz izinler

Bir DeFi uygulamasıyla her etkileşime girdiğinizde — bir DEX'te swap, bir borç verme piyasasına yatırım, bir ERC-20'yi köprülemek — neredeyse kesinlikle bir token onayı verdiniz. Çoğu kullanıcı bunları saniyeler içinde imzalar ve unutur. Oysa o tek approve işlemi, Ethereum'da yaptığınız en sonuç doğuran şeylerden biridir: bir smart contract'a tokenlarınızı hareket ettirmek için kalıcı bir izin verir, çoğu zaman ek bir onay olmadan. Bu rehber, token onayının ne olduğunu, dApp'lerin neden istediğini, sınırsız allowance'ların risklerini ve SSP üzerinden onay imzaladığınızda bütün bunların ne anlama geldiğini anlatıyor.

Onaylar neden var

ERC-20 tokenları, ETH gibi cüzdanınızın "içinde" saklanmaz. Bir ERC-20 token sözleşmesi bir defterdir: adreslerden bakiyelere bir eşleme. 1.000 USDC tuttuğunuzda, zincirde gerçekte var olan şey USDC sözleşmesinde adresinizin 1.000 birim sahibi olduğunu söyleyen bir satırdır.

Bakiye token sözleşmesinin içinde yaşadığı için sadece o sözleşme onu hareket ettirebilir. Bir arkadaşınıza USDC gönderdiğinizde, cüzdanınız doğrudan tokenın transfer fonksiyonunu çağırır.

Ancak farklı bir sözleşmenin (router) bir swap için adresinizden USDC çekmesi gereken bir DEX, token sözleşmesinin içine uzanıp bakiyenizi alamaz. ERC-20 bunu iki adımlı bir delegasyon deseniyle çözer:

1. Siz, token sözleşmesinde approve(spender, amount) çağırırsınız. Bu bir allowance belirler: spender'ın tokenlarınızdan amount kadarını hareket ettirmeye yetkili olduğunu söyleyen bir kayıt.
2. Spender daha sonra token sözleşmesinde transferFrom(yourAddress, destination, amount) çağırır. Sözleşme allowance'ı kontrol eder, azaltır ve tokenları hareket ettirir.

Onay bir anahtardır. O olmadan router, USDC'lerinize hiç dokunamaz.

Aslında ne veriyorsunuz

approve(spender, amount) ifadesini sözlük anlamıyla okuyun. ERC-20 sözleşmesine şunu söylüyorsunuz: "bu adres, ben değiştirene kadar, herhangi bir zamanda, herhangi bir sayıda işlemde tokenlarımdan bu kadarına kadar çekebilir."

Bundan birkaç sonuç çıkar:

• Kalıcı izin, tek seferlik bir eylem değil. Bir kez verildikten sonra, allowance harcanana ya da iptal edilene kadar spender tokenları çekmek için yeniden imzanıza ihtiyaç duymaz.
• Token başına. DEX router'ını USDC için onaylamak, DAI'nize dokunmasına izin vermez; DAI için ayrı bir onay gerekir.
• Spender başına. Farklı bir sözleşme — aynı dApp'ten bile olsa — kendi allowance'ına sahiptir.
• Süresi dolmaz. ERC-20'nin yerleşik bir son tarihi yoktur. 2023'te ayarlanmış bir allowance, kullanılmadıkça veya iptal edilmedikçe 2026'da hâlâ aktiftir.

Herhangi bir allowance'ı etherscan gibi bir blok gezgininde, token sözleşmesinin allowance(owner, spender) view fonksiyonunu okuyarak inceleyebilirsiniz.

Sınırsız allowance deseni

Eğer onaylar tutar bazlıysa, neredeyse her DEX neden tam o anda swap ettiğiniz miktar yerine devasa bir sayı — genellikle 2^256 - 1, "unlimited" veya MaxUint256 olarak gösterilen — istiyor?

Cevap UX ve gas. Bir DEX her swap'ta işlem büyüklüğüne eşit yeni bir allowance isteseydi, her seferinde bir onay işlemi öder ve tek bir eylem gibi hissettiren şey için iki işlem onaylamak zorunda kalırdınız. Bir kez sınırsız bir allowance istemek, sonrasında işlem başına tek bir işlemle özgürce swap yapmanızı sağlar.

Gerçekten rahat. Aynı zamanda gerçekten daha riskli. Sınırsız bir allowance, spender sözleşmesinin o tokenın mevcut tüm bakiyenizi — ve gelecekteki herhangi bir bakiyeyi — siz başka bir şey imzalamadan herhangi bir anda boşaltma yetkisine sahip olduğu anlamına gelir.

İyi bilinen, denetlenmiş, değişmez bir sözleşme için pratik risk genellikle düşüktür. Yeni deploy edilmiş bir dApp, upgradeable bir proxy veya tanımadığınız bir sözleşme için sınırsız bir allowance, yapmak istediğiniz işlemden çok daha geniş bir yüzeydir.

Asıl risk: tokenlarınıza kalıcı bir anahtar

Onayların tehlikesi onay işleminin kendisinde değildir. Sonrasında olanlardadır. Birkaç senaryoyu düşünün:

• Spender sözleşmesinde bir hata var. Bir saldırgan transferFrom mantığını sömürür ve sıfırdan farklı allowance'a sahip her cüzdan boşaltılır.
• Spender sözleşmesi upgradeable. Upgrade anahtarlarını kontrol eden kişi, aktif allowance'ı olan herkesin tokenlarını çeken yeni bir mantık yayınlar.
• Kötü niyetli bir klonu onayladınız. Bir oltalama sitesi gerçek bir dApp'in URL'sini taklit etti ve onayladığınız sözleşme baştan beri saldırganın kontrolündeydi.
• Spender'ın imzalama anahtarları ele geçirildi. Resmi sözleşme iyi durumda; operatörün cüzdanı değil ve allowance'lar bir izinsiz girici tarafından kullanılıyor.

Her durumda boşaltma gerçekleştiğinde hiçbir şey imzalamıyorsunuz. Haftalar önce verdiğiniz onay, saldırganın ihtiyaç duyduğu tek yetkilendirmedir. "Sadece ihtiyacın olanı onayla, kullanmadığını iptal et" paranoya değildir; bu, daha önce iş yaptırdığınız her ustaya evinizin yedek anahtarlarını bırakmamakla aynı prensiptir.

Onaylar nasıl sessizce birikir

DeFi'da bir-iki yıl aktif olan bir cüzdan onlarca onay biriktirmiştir: her DEX, her aggregator, her borç verme piyasası yatırımı, her NFT marketplace, her köprü. Kullanıcılar neredeyse hiç iptal etmek için geri dönmez. Sonuç, çoğu sınırsız, çoğu kullanıcının artık etkileşime girmediği sözleşmelere verilmiş, uzun bir kalıcı izinler kuyruğudur.

Bu sessiz saldırı yüzeyidir. Tek bir işlemde görünmez; normal kullanımın birikimli tortusudur. Bu listeyi denetleyip budamak, öz-saklamadaki en etkili güvenlik alışkanlıklarından biridir — sonraki yazı bunu tam olarak nasıl yapacağınızı SSP'den token onaylarını iptal etmek içinde anlatıyor.

Daha yeni bir desen: EIP-2612 permit

ERC-20, modern DeFi'ın büyük bölümünden öncedir ve iki işlemli approve-sonra-swap dansının uzun süredir hantal olduğu kabul edilmektedir. EIP-2612, kabul eden tokenlar için bir alternatif tanıttı: zincire bir approve işlemi göndermek yerine, kullanıcı belirli bir spender'ı, miktarı ve son tarihi yetkilendiren zincir dışı bir mesaj (permit) imzalar. dApp bu imzayı swap ile birlikte tek bir işlemde gönderir.

permit gas açısından verimlidir, kapsamlıdır (açık bir miktar ve son kullanma tarihi taşır) ve son tarihi onu süresinin dolmasına zorladığı için arkada sallanan halde bırakmak daha zordur. Her ERC-20 desteklemez — USDC ve DAI destekler, daha eski tokenların çoğu desteklemez — ancak mevcut olduğunda, uzun ömürlü bir approve allowance'ından genellikle daha güvenlidir. Bununla birlikte, permit imzalarının kendisi de oltalanabilir: sizden "giriş yapmanızı" isteyen kötü niyetli bir site altına bir permit sıkıştırabilir. Neyi imzaladığınızı okuyun.

SSP içinde bu ne anlama geliyor

SSP, öz-saklamalı bir 2-of-2 multisig cüzdandır: her zincir üstü işlem SSP tarayıcı uzantısı ve SSP Key mobil uygulaması tarafından birlikte imzalanır. Ethereum ve SSP'nin desteklediği EVM ağlarında (Polygon, Base, BNB Smart Chain, Avalanche) bu, Schnorr-toplamlı imzaya sahip bir ERC-4337 smart account olarak uygulanır — ancak uygulama katmanında bir onay diğer herhangi bir işlem gibi görünür.

Akılda tutulması gereken birkaç şey:

• Bir onay, 2-of-2'nizin birlikte imzalaması gereken bir işlemdir. Bir dApp approve istediğinde, SSP onu diğer herhangi bir tx gibi yüzeye çıkarır. Onaylamadan önce her iki cihazda spender adresini ve istenen miktarı görürsünüz.
• Bir kez verildikten sonra, spender hareket etmek için SSP'ye ihtiyaç duymaz. Multisig, onay anını korur, sonrasındaki kalıcı izni değil. Kötü niyetli bir sözleşmeye sınırsız allowance verirseniz, multisig sizi sonraki boşaltmadan kurtarmaz.
• Spender adresini izleyin. dApp'ler zaman zaman router'larını günceller; onay ekranındaki spender beklediğiniz sözleşmeyle uyuşmuyorsa durun ve doğrulayın.
• WalletConnect ile başlatılan onaylar aynı görünür. dApp ister sayfa içinde ister WalletConnect üzerinden istesin, akış ve riskler özdeştir.

Geliştirmeye değer alışkanlıklar

Birkaç somut uygulama, onay yüzeyini yönetilebilir tutar:

• Mümkün olan en küçük allowance'ı tercih edin. Bir dApp "tam miktar" ile "sınırsız" arasında seçim sunduğunda, düzenli olarak kullanmadığınız sözleşmeler için tam miktar daha güvenli bir varsayılandır.
• Sınırsız onayları taahhüt olarak görün. Bunları güvendiğiniz ve sık kullandığınız küçük bir sözleşme setine ayırın. Diğer her şey için kapsamı daraltın.
• Düzenli olarak denetleyin. Üç ayda bir, her zincirdeki aktif onaylarınızı listeleyin ve artık kullanmadıklarınızı iptal edin. revoke.cash gibi araçlar bunu rutin hale getirir.
• Tanımadığınız dApp'lere karşı temkinli olun. Denetim geçmişi olmayan yeni bir protokolün sınırsız allowance istemesi DeFi'daki en yüksek riskli kombinasyondur.
• Onay veren anahtarları koruyun. SSP'nin multisig'i çıtayı yükseltir, ancak standart hijyen yine de geçerlidir — bkz. seed cümlesi en iyi uygulamaları.

Akılda tutulacak zihinsel model

Bir token onayı bir tıklama değildir; bir anahtardır. Her biri siz çıkarana kadar kilitte kalır ve her biri sahibine henüz kazanmadığınız tokenları hareket ettirme yeteneği verir. Dikkatle kullanıldığında allowance'lar DeFi'ı çalıştıran tesisattır. Tek kullanımlık tıklamalar gibi muamele edilirse, üstlendiğinizi unuttuğunuz risklerin yavaş bir birikimine dönüşürler.

Verdiğiniz izni anlayın, dApp izin verdiğinde kapsamı daraltılmış verişleri tercih edin ve kalıcı onaylarınızı bir programa göre budayın. Daha derin protokol detayları için kanonik referans ethereum.org'daki ERC-20 standardı dokümantasyonu'dur. Ethereum'da SSP kullanmaya yeni mi başlıyorsunuz? SSP'de Ethereum rehberimiz temelleri ele alır.