SSP'nin Hesap Soyutlama Mimarisinin İçinde

SSP, 2-of-2 multisig etrafında kurulmuş, kendi kendine saklamalı bir cüzdandır. Bir anahtar SSP Wallet tarayıcı uzantısında, ikincisi SSP Key mobil uygulamasında durur ve her iki cihaz da onaylamadıkça hiçbir işlem nihai hâle gelmez. EVM zincirlerinde SSP bu güvenceyi ERC-4337 account abstraction ile sağlar: cüzdan, doğrulama mantığı iki anahtardan üretilen tek bir Schnorr toplam imzasını kabul eden bir smart account'tur. Bu yazı, o mimariyi baştan sona dolaşıyor — her bileşeni, tam imzalama akışını ve ürettiği güvenlik özelliğini.

account abstraction sizin için yeniyse, İlk ilkelerden hesap soyutlama ile odaklı ERC-4337 açıklamasından başlayın. Burada smart account ve UserOperation'ın kabaca ne olduğunu bildiğinizi varsayıyor ve SSP'nin bunları nasıl birbirine bağladığına odaklanıyoruz.

SSP'nin dayandığı parçalar

Akışı izlemeden önce bileşenleri ve her birinin ne yaptığını adlandırmak faydalı olur:

• smart account. EVM zincirlerinde SSP cüzdanınız tek bir anahtarla kontrol edilen bir EOA değildir. Bir ERC-4337 smart account'tur — fonlarınızı tutan ve kendi doğrulama mantığını içeren bir sözleşme. Bu mantık tasarımın kalbidir: bir işlemi yalnızca sağlanan imza, cüzdanın beklenen toplam anahtarıyla eşleştiğinde kabul eder.
• İki cihaz. Anahtar 1, SSP Wallet tarayıcı uzantısında durur. Anahtar 2, SSP Key mobil uygulamasında durur. Her cihaz bir pay tutar ve bir kısmi imza üretir. Hiçbir pay tek başına hiçbir şeyi yetkilendiremez.
• UserOperation. Uzantı, normal bir işlem yerine niyetinizi bir UserOperation olarak ifade eder — account'un ne yapması gerektiğini ve bunu yetkilendiren imzayı tarif eden yapılandırılmış bir nesne.
• bundler. Bir bundler, UserOperation'ı kendine ait mempool'dan alır, onu gerçek bir zincir üstü işleme paketler ve göndermek için temel katman gas'ını öder.
• EntryPoint. Denetimden geçmiş tek bir EntryPoint sözleşmesi, her ERC-4337 işleminin zincir üstü girişidir. Doğrulama mantığını çalıştırmak için sizin smart account'unuzu çağırır, ardından doğrulama geçerse yürütmeyi tetikler.

Bir paymaster isteğe bağlı olarak bir UserOperation için gas'ı üstlenebilir; bu kendi başına bir konudur ve Gas sponsorluğu ve paymaster'lar açıklanıyor yazısında ele alınır.

Tam imzalama akışı

EVM zincirinde SSP'den bir işlem gönderdiğinizde adım adım olan şudur:

  SSP Wallet extension (key 1)          SSP Key mobile app (key 2)
        |                                     |
        | 1. initiate tx                      |
        | 2. build UserOperation              |
        | 3. partial Schnorr sig  --- push -->| 4. approve
        |                                     | 5. partial Schnorr sig
        |                                     |
        |        6. aggregate (MuSig2 / secp256k1)
        |                v
        |        ONE Schnorr signature
        |                |
        v                v
  7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
                                                  |
                                          validate aggregate sig
                                                  |
                                         valid? --> execute call

Düz yazı olarak okunuşu:

1. Anahtar 1'i tutan SSP Wallet tarayıcı uzantısında bir işlem başlatırsınız.

2. Uzantı, eylemi tarif eden bir ERC-4337 UserOperation oluşturur.

3. Anahtar 1, o işlem üzerinde kısmi bir Schnorr imzası üretir.

4. İstek, onay için SSP Key mobil uygulamasına itilir (anahtar 2).

5. Anahtar 2, kendi kısmi imzasını üretir.

6. İki kısmi imza, secp256k1 üzerinde MuSig2 tarzında, tek bir Schnorr imzasına toplanır.

7. Artık o tek toplam imzayı taşıyan UserOperation, gönderilmeye hazırdır.

8. Bir bundler'a gider; o, onu bir işleme paketler ve gas'ı öder.

9. bundler onu EntryPoint sözleşmesine gönderir; sözleşme de SSP'nin smart account'unu çağırır. account, tek toplam imzayı cüzdanın beklenen toplam anahtarına karşı doğrular ve geçerliyse çağrıyı yürütür.

10. adıma ulaşmak için her iki cihaz da gereklidir; işte bunu gerçek bir 2-of-2 yapan şey budur. Kısmi imzalardan herhangi birini çıkarın, toplama sözleşmenin kabul edeceği bir imza üretemez.

Zincir neden yalnızca tek bir imza görür

SSP'nin tasarımını zarif kılan ayrıntı, 6. adımdaki toplamadır. Uzantı ve telefon, işleme her biri ayrı bir imza eklemez. İki kısmi Schnorr imzaları — MuSig2 tarzında, Ethereum'un zaten kullandığı aynı secp256k1 eğrisi üzerinde — tek bir Schnorr imzasında birleşir. smart account, beklenen tek bir toplam anahtara karşı bu tek imzayı denetler.

Bunun üzerinde durmaya değer iki sonucu vardır:

• Zincir üstü iz küçük kalır. UserOperation iki değil, tek bir imza taşır. Saklanacak ya da dolaşılacak bir imzalayan listesi yoktur, imzalayan başına bir doğrulama döngüsü yoktur. Sözleşme, tek bir imzalayan için yapacağı doğrulama işinin aynısını yapar.
• Zincir, bunun multisig olduğunu anlayamaz. EntryPoint'e ulaşan şey sıradan, imzalanmış bir işlem gibi görünür. 2-of-2 dayatması, imzanın nasıl üretildiğinde — iki cihaz arasında — yatar, zincir üstünde görünür herhangi bir çok taraflı yapıda değil. Dışarıdan bir gözlemci için cüzdan, herhangi başka bir smart account gibi davranır.

SSP'nin yaklaşımı ile N ayrı imza yayımlayıp her birini doğrulayan saf bir multisig arasındaki fark işte budur. multisig'i EVM üzerinde bu şekilde yapmanın mekaniği, Hesap soyutlama tarzında EVM multisig yazısında daha ayrıntılı incelenir.

Her cihazın gerçekte neyi koruduğu

Güvenlik özelliği konusunda kesin olmaya değer, çünkü mimarinin bütün anlamı budur.

• Hiçbir anahtar tek başına fon hareket ettiremez. Uzantıdaki anahtar 1 bir UserOperation oluşturabilir ve kendi yarısını imzalayabilir, ama yarım bir imza, sözleşmenin kabul etmeyeceği bir şeye toplanır. Telefondaki anahtar 2 onaylayabilir ve kendi yarısını imzalayabilir, ama bir transferi tek başına ne başlatabilir ne de tamamlayabilir.
• Tek bir cihazın ele geçirilmesi yetmez. Tarayıcı uzantınızı tümüyle kontrol eden bir saldırgan bile yine de harcama yapamaz, çünkü telefon olmadan anahtar 2'nin kısmi imzasını üretemez. Tersi de geçerlidir. Tek anahtarlı bir EOA'nın atlatamayacağı tehdit modeli — sızdırılmış tek bir anahtar, toplam kayıp — burada geçerli değildir.
• Onay açıktır ve ikinci bir ekrandadır. 4. adım isteği SSP Key uygulamasına ittiği için, işlem toplanıp gönderilebilmeden önce onu fiziksel olarak ayrı bir cihazda görür ve onaylarsınız.

Bu, 2-of-2 multisig nedir? yazısında anlatılan aynı 2-of-2 özelliğidir; EVM zincirlerinde yerel bir multisig opcode'u yerine hesap soyutlama yoluyla gerçekleştirilir.

Faydalar, özetle

İplikleri bir araya getirince, mimari SSP kullanıcılarına başka türlü elde etmesi zor, belirli bir bileşim kazandırır:

• Desteklenen her EVM zincirinde multisig güvenliği. Aynı 2-of-2 tasarımı Ethereum, Polygon, Base, BNB Smart Chain ve Avalanche üzerinde çalışır, çünkü ERC-4337 zincire özgü bir özellik değil, sözleşme düzeyinde bir standarttır.
• Küçük bir zincir üstü iz. Tek bir toplam imza, smart account'un tek bir imzalayan gibi doğrulama yapması anlamına gelir ve doğrulamayı yalın tutar.
• Tek imzalayana benzer UX. Sizin tarafınızdan bu, bir komite kurmak değil, bir işlemi iki cihazda onaylamak gibi hissettirir. Yönetilecek ortak imzalayan adresleri ya da transfer başına yapılandırılacak ayrı bir multisig sözleşmesi yoktur.
• Protokol değişikliği gerekmez. Her şey ERC-4337 üzerinde gittiği için SSP, temel katman hesap soyutlamasının yayımlanmasını beklemeden tüm bunları elde eder.

Denetim üzerine bir not

Bir güvenlik mimarisi ancak incelendiği ölçüde güvenilirdir. SSP'nin smart contract'ları 2025'te Halborn tarafından denetlendi. Harici bir denetim hiçbir sistemi kusursuz yapmaz, ama yukarıda anlatılan 2-of-2 kuralını dayatan sözleşme mantığı için anlamlı bir güven sinyalidir.

Sonra nereye

Bu yazı SSP'nin hesap soyutlamasını baştan sona izledi. Çevresindeki standart ve kavramlarda daha derine inmek için:

• İlk ilkelerden hesap soyutlama — EOA'ların neden kısıtlayıcı olduğu ve hesap soyutlamanın ne anlama geldiği.
• Hesap soyutlama (ERC-4337) nedir? — standardın tek başına ele alınışı, UserOperation, bundler ve EntryPoint rolleri dahil.
• Gas sponsorluğu ve paymaster'lar açıklanıyor — bir paymaster'ın bir UserOperation için gas'ı nasıl üstlenebileceği.
• Hesap soyutlama tarzında EVM multisig — EVM üzerinde multisig mekaniği daha ayrıntılı.

Resmî şartname için EIP-4337'ye bakın; daha geniş çabaya gelince, Ethereum'un hesap soyutlama yol haritası nereye gittiğini izler. Çıkarım: SSP, programlanabilir bir account'un soyut vaadini somut bir 2-of-2 cüzdana dönüştürür; iki cihaz tek bir imza üretir ve zincir yalnızca geçerli bir işlem görür.