İlk ilkelerden hesap soyutlaması

Ethereum üzerinde hiç öz saklamalı bir cüzdan kullandıysanız, farkında olun ya da olmayın, harici sahipli bir hesap — bir EOA — kullandınız. Hesap soyutlaması konuşması, bir EOA'nın ne olduğunu, tasarımının zincir üstünde yapabileceğiniz her şeyi neden kısıtladığını ve ERC-4337 hesap soyutlamasının bu kısıtları temel protokole dokunmadan nasıl aştığını anlamakla başlar. Bu yazı, sizi özgün kısıtlardan SSP'nin EVM zincirlerinde 2/2 multisig'ini çalıştırmak için hesap soyutlamasını nasıl kullandığına kadar götüren bir serinin giriş noktasıdır.

Bu, temel ve kavramsal parçadır. ERC-4337 standardının kendisine odaklanan bir anlatım için, bu yazıyla birlikte Hesap soyutlaması (ERC-4337) nedir? yazısını okuyun; burada standardın neden var olduğuna dair sezgiyi inşa ediyoruz.

Ethereum'un size verdiği hesap

Ethereum'da iki tür hesap vardır. Sözleşme hesapları kodla yönetilir. EOA'lar — çoğu insanın kullandığı sıradan cüzdanlar — tek bir özel anahtarla yönetilir. O anahtara sahip olan kişi, hesaptan herhangi bir işlemi yetkilendirebilir ve protokol tam olarak tek bir şeyi doğrular: işlemin, adresi denetleyen anahtarın ürettiği, secp256k1 eğrisi üzerinde geçerli bir ECDSA imzası taşıdığını.

O tek kural zariftir ve aynı zamanda aşağıda ele alınan her kısıtın kaynağıdır. Bir işlemin geçerliliği protokole sabitlenmiştir. Hesap sahibi olarak siz, "geçerli"nin ne anlama geldiğine karar veremezsiniz. Protokol karar verir ve yalnızca tek bir anahtarın tek bir imza şemasını denetlemeyi bilir.

Bu tasarımın kökten getirdikleri

Dört kısıt, doğrudan tek anahtar, tek imza modelinden doğar:

• Tek anahtar tek bir hata noktasıdır. Anahtarı kaybedin, fonlar gider. Sızdırın, saldırgan her şeye sahip olur. Protokol düzeyinde ikinci bir faktör, eş imzalayan ya da hırsızlığı engelleyebilecek bir politika yoktur.
• Özel doğrulama mantığı yok. Bir EOA "iki imza iste" diyemez, ya da "bu küçük ödemeye otomatik izin ver ama bir eşiğin üstünde ek onay iste" diyemez, ya da "bu anahtar yalnızca hafta içi harcasın" diyemez. Hesabın mantığı yoktur. Bir imza denetimi vardır.
• Gönderen, gas için ETH tutmak zorundadır. Her EOA işlemi kendi gas'ını ETH ile öder. Yalnızca bir ERC-20 jetonu olup hiç ETH'si olmayan yeni bir kullanıcı, ücreti ödeyemediği için o jetonu hareket ettiremez. Ücreti ödeyen ile işlemi gönderen aynı hesap olmaya zorlanır.
• Tohum kelime grubu (seed phrase) deneyimi affetmez. Anahtar hesabın kendisi olduğu için, başlangıç bir tohum kelime grubunu yazıp onu sonsuza dek korumak demektir. Bu kelime grubunu içermeyen bir kurtarma yolu yoktur ve tek bir hata kalıcıdır.

Bunlar hata değildir. Doğrulamanın hesapta değil de protokolde yaşamasının sonuçlarıdır.

Temel fikir: hesabı programlanabilir yapmak

Hesap soyutlaması, o doğrulama mantığını protokolden çıkarıp hesabın kendisine taşıma fikridir. Ağın "bir işlem, tek bir doğru ECDSA imzası varsa geçerlidir" diye sabitlemesi yerine, fonlarınızı tutan bir sözleşme olan bir smart account, neyin geçerli işlem sayılacağına kendisi karar verir.

Hesap programlanabilir bir sözleşme olduğunda, dört kısıt birer tasarım tercihine dönüşür:

• Tek imza yerine iki imza isteyebilir; multisig'in protokolün yerel desteği olmadan tam olarak böyle mümkün olur.
• Kurtarma kuralları uygulayabilir, böylece kaybolan bir anahtar artık hikâyenin sonu olmaz.
• Başkasının gas ödemesine izin vererek ücreti ödeyeni gönderenden ayırabilir.
• Birkaç eylemi — örneğin onaylama ve takas — tek bir atomik işlemde toplayabilir.

Hesap edilgen bir anahtar çifti olmaktan çıkar ve sizin denetlediğiniz programlanabilir bir mantığa dönüşür.

ERC-4337 bunu bir hard fork olmadan nasıl sunar

Zor kısım, Ethereum'un işlemleri nasıl doğruladığını değiştirmenin normalde temel protokolü değiştirmek anlamına gelmesidir — yavaş, tartışmalı, ağ çapında bir yükseltme. ERC-4337 bunu tamamen aşar. Hesap soyutlamasını, hiçbir uzlaşı değişikliği gerektirmeden, mevcut ağın üzerinde bir katman olarak sunar.

Mekanizma birkaç parçaya dayanır:

• UserOperations. Normal bir işlem göndermek yerine, bir smart account niyetini bir UserOperation olarak ifade eder — hesabın ne yapmak istediğini ve nasıl doğrulanması gerektiğini açıklayan yapılandırılmış bir nesne.
• Alternatif bir mempool. UserOperations, sıradan işlemlerden ayrı, kendi mempool'unda yaşar.
• Bundlers. Bir bundler, o mempool'dan UserOperations toplar, onları bir araya paketler ve temel katman gas'ını ödeyerek gerçek bir işlem olarak zincire gönderir.
• EntryPoint sözleşmesi. Denetimden geçmiş tek bir EntryPoint sözleşmesi, zincir üstündeki darboğazdır. O hesabın kendi doğrulama mantığını çalıştırmak için her smart account'u çağırır, ardından doğrulama geçerse işlemi yürütür.
• Paymasters. İsteğe bağlı bir paymaster sözleşmesi, bir UserOperation'ın gas'ını üstlenmeyi kabul edebilir; gas'sız ve jetonla ödeme akışlarını mümkün kılan budur.

Bir araya geldiğinde bu, herhangi bir sözleşmenin kendi kurallarına göre doğrulanan, tümüyle programlanabilir bir hesap gibi davranmasını sağlar; altta yatan Ethereum protokolü ise olduğu gibi kalır. Standart EIP-4337'de tanımlanmıştır ve Ethereum'un kendi hesap soyutlaması yol haritası, daha geniş çabanın nereye gittiğini izler.

Bu, öz saklama kullanıcıları için neden önemli

Kendi anahtarlarını tutan biri için hesap soyutlaması soyut bir protokol ayrıntısı değildir — bir cüzdanın güvenle yapabileceklerini değiştirir:

• Yerel destek olmadan multisig. Bir smart account birden fazla imza isteyebilir, böylece bir cüzdan her transferi iki bağımsız cihazın onaylamasını gerektirebilir. SSP'nin dayandığı yapı taşı budur; daha ayrıntılı anlatımı Hesap soyutlaması yöntemiyle EVM Multisig yazısındadır.
• Kurtarma seçenekleri. Programlanabilir doğrulama, tek ve kırılgan bir tohum kelime grubuna çökmeyen kurtarma akışlarının kapısını açar.
• Gas sponsorluğu. Paymasters, ücretin gönderenden ayrılabilmesi demektir; başlangıçtaki en kötü sürtünmeyi yumuşatır.
• Toplama. Birkaç adım tek bir işlem olarak sonuçlanabilir; hem tıklamaları hem de yarı yolda başarısızlık riskini azaltır.

Tek anahtarlı bir EOA ile programlanabilir bir smart account arasındaki pratik fark, kendi ele alınışını hak edecek kadar büyüktür — bkz. EOA mı smart account mı: önemli farklar.

SSP nereye oturuyor

SSP, 2/2 multisig etrafında inşa edilmiş öz saklamalı bir cüzdandır. Bir anahtar SSP Wallet tarayıcı uzantısında yaşar; ikincisi SSP Key mobil uygulamasında yaşar. Her işlem uzantıda oluşturulur ve telefonda eş imzalanır, böylece hiçbir cihaz tek başına fonları hareket ettiremez.

EVM zincirlerinde SSP, bu 2/2'yi ERC-4337 kullanarak sunar. Cüzdan, doğrulama mantığı her iki anahtarı da gerektiren bir ERC-4337 smart account'tur ve iki kısmi imza — secp256k1 üzerinde MuSig2 tarzında — sözleşmenin zincir üstünde doğruladığı tek bir Schnorr toplanmış imzasında birleşir. SSP'nin smart contracts'ı 2025'te Halborn tarafından denetlenmiştir. Tam tasarım, SSP Hesap Soyutlaması Mimarisi yazısının konusudur.

Başka bir deyişle, yukarıda anlatılan soyut yetenek — kendi çok imzalı kuralını dayatan bir hesap — SSP'nin Ethereum, Polygon, Base ve diğer desteklenen EVM zincirlerinde çalışan bir cüzdana dönüştürdüğü şeyin ta kendisidir.

Bu serinin geri kalanı

Bu parça, sorunu ve temel fikri kurdu. Seri buradan itibaren bunun üzerine inşa eder:

1. İlk ilkelerden hesap soyutlaması — bu yazı: EOA'ların neden kısıtlayıcı olduğu ve hesap soyutlamasının ne anlama geldiği.
2. EOA mı smart account mı: önemli farklar — iki hesap modelinin doğrudan karşılaştırması.
3. SSP Hesap Soyutlaması Mimarisi — SSP'nin ERC-4337'yi bir 2/2 cüzdana nasıl bağladığı.
4. Gas sponsorluğu ve paymasters açıklandı — paymasters'ın ödeyeni gönderenden nasıl ayırdığı.
5. Ethereum dışı zincirlerde hesap soyutlaması — aynı fikrin Ethereum'un ötesine nasıl taşındığı.

Standardı tek başına istiyorsanız ERC-4337 anlatımı ile başlayın, sonra büyük resim için buraya geri dönün. Oradan itibaren hesap bir kısıt olmaktan çıkar ve etrafında programlama yapabileceğiniz bir şey olmaya başlar.