Hesap Soyutlama ve Yerel Hesap Soyutlama

Basit bir ifadeyle, ERC-4337'deki Hesap Soyutlaması, blok zincirinde isteğe bağlı bir altyapıdır. Evlat edinip edinmemeyi siz seçebilirsiniz. Kabul edildikten sonra, multisig, ERC-20 tokenleri ile gaz ücreti ödeme, sosyal kurtarma ve daha fazlası gibi Sözleşme Hesaplarına (CA) benzer işlevler sağlar. Stackup gibi birçok hizmet sağlayıcı bu altyapı üzerinde çalışıyor. Ancak, bu altyapı aşağıdaki nedenlerden dolayı yaygın olarak benimsenmemiştir:

• Paketçi sorunu: Doğrulamaya yalnızca paketçiler katılır, bu da paketçilere aşırı güvenilmesine yol açar.
• Paketleyiciler için yetersiz kar: Bunun başlıca nedeni, gaz ücretlerinden tasarruf etmek için daha fazla DApp'in Hesap Soyutlama altyapısını seçmesini gerektiren küçük ölçektir.
• Paketleyicilerin yoğunlaşması: Paketleyiciler birkaç tedarikçide (Alchemy, Pimlico, Stackup) yoğunlaşarak merkezileşme riskleri oluşturmaktadır.
• Elde tutma oranı: Airdrop'lar dışında, Hesap Soyutlama hizmetleri için kullanıcı elde tutma oranı çok düşüktür.

Birçok Katman 2 çözümü, daha düşük gaz ücretleri için Hesap Soyutlamasını doğrudan yerel zincir üzerinde kullanır. Bu, Yerel Hesap Soyutlaması olarak bilinir. Ancak bu yaklaşımın, bu özelliği istemeyen kullanıcıların vazgeçememesi, zincirler arası yeteneklerin sınırlı olması ve genel olarak esneklik eksikliği gibi başka sorunları da vardır.

Bu makalede, EOA ve CA arasındaki ayrım (basit bir ifadeyle, Metamask EOA'dır, sözleşmeler CA'dır) ve bundler 'lar (Hesap Soyutlama ekosisteminde, kullanıcılar UserOperation'ları düğüm doğrulayıcılara/Mempool'a göndermek yerine paketleme ve zincir üzerinde işleme için bundler'lara gönderir) gibi bazı terimlerden bahsedilmektedir. Ayrıntılı açıklamalar için yukarıda belirtilen iki makalenin bağlantılarına tıklayabilir ve Gate Learn ile ilgili daha önce yayınlanmış makalelere başvurabilirsiniz.

RIP-7560 nedir?

RIP-7560, hesap soyutlama için bir iyileştirme önerisidir (EIP-2938/ERC-4337). Yeni işlem türü "AA_TX_TYPE "nin tanıtılması, işlem doğrulama ve yürütme aşamalarında paket satıcısı (blok oluşturucu / düğüm doğrulayıcı) dışındaki rolleri içerir. Artık paketleme ve zincir üzerinde gönderim için yalnızca paket satıcısına bağlı değildir, böylece daha önce bahsedilen merkezileştirme sorunlarını ele alır. Ayrıca RIP-7560, gelecekteki kullanıcılar için daha fazla uygunluk sağlamak üzere standartlaştırılmış tasarım sağlar. Bu makalede, RIP-7560 teklifi ile geliştirilen standartlar daha ayrıntılı olarak ele alınacak ve dile getirilen endişelere değinilecektir.

En Köklü Değişim

Bu bir mutabakat katmanı protokol değişikliğidir \
Hesap soyutlaması için en erken teklif aslında Eylül 2020'de EIP-2938'de yapılmıştır. Sonunda topluluk tarafından kabul edildi ve Ethereum üzerinde konuşlandırıldı. ERC-4337'nin nihayetinde 2938 yerine kabul edilmesinin nedeni, 4337'nin fikir birliği katmanında değişiklik gerektirmemesi ve topluluğun kabul etmesini nispeten daha kolay hale getirmesidir.

ERC-4337'den farklı olarak RIP-7560 teklifi, özellikle mutabakat katmanı protokol seviyesinde daha büyük değişiklikler içerecektir (RIP ön eki, bunun Toplama teknolojisini geliştirmek için daha düşük seviyeli bir teklif olduğunu gösterir). Buna karşılık gelen fayda, doğrudan L2 yerel zincirinin altyapısına güvenmekten kaçınma yeteneğidir.

Yeni bir işlem türünün tanıtılması \
Yeni bir işlem türü tanıtıldı: "AA_TX_TYPE" olarak da bilinen dördüncü işlem türü (aslında eski EIP-2938'de önerilmişti). Sadece tipik bir CA'nın tüm işlevlerini desteklemekle kalmaz ( Visa'nın makalesinde bahsedilen gaz ücreti ödemesi ve yinelenen otomatik ödeme işlevleri gibi), aynı zamanda ERC-4337'den farklı olarak mevcut EOA'ların işlem göndermesine de izin verir. Bu da, bu teklifin daha geniş çapta benimsenmesini teşvik etmeyi amaçladığı anlamına gelmektedir.

İşlem Yürütme Mantığı

Bu teklif ERC-4337 standardı ile uyumludur ve daha fazla Gas gerektiren yürütme ve doğrulamayı ayıran işlem mantığını benimser. Ek olarak, belgelere göre, işlem yürütme ERC-4337 ile aynıdır; burada doğrulama aşamasındaki tüm adımlar geri döndürülmeden tamamlanmalıdır. Doğrulamadan sonra, çağrı verileri yürütülmek üzere hesaba gönderilecektir. Yürütmeden sonra, Paymaster işlem sonrası mantığı gerçekleştirebilir. Tüm yürütme süreci aşağıdaki şemada gösterilmiştir.

Yürütme Akış Şeması (Kaynak: RIP-7560 GitHub belgesi)

Teklife İlişkin Temel Endişeler

Yazar, Ethereum Magicians forumundaki tartışma sırasında aşağıdaki endişeleri dile getirdi: RIP-7560: Yerel Hesap Soyutlaması

Amaç tabanlı hesap soyutlama hizmetlerinin geliştirilmesini kısıtlayacak mı?

Amaç tabanlı hizmetlerdeki ana oyuncuların Uniswap V4 ve UniswapX olması beklenirken, UniswapX hesap soyutlama hizmetleri geliştirmeyi planlıyor. Buna ek olarak, ERC-7521 tarafından da benzer bir yön önerilmiştir. Topluluk tartışmalarına yanıt olarak, bu teklifin yazarlarından biri olan Yoav Weiss, RIP-7560 ile birlikte ERC-7562 adlı bir hesap soyutlama doğrulama kuralının da bulunduğunu belirtmiştir. Amaç sistem tasarımı, doğrulama kuralı ile değil, yalnızca RIP-7560 ile uyumlu hale getirilebilir. Ardından, ayrı bir amaç çözücü ağı kullanılabilir ve böylece amaç tasarımıyla çakışmadan RIP-7560'ın avantajlarından yararlanılabilir.

Geri Dönülemezlik Riski

Topluluktaki bazı kişiler bu önerinin "çıplak metale bir işletim sistemi yerleştirmeye çalışmak" ile benzer olup olmadığını ve önemli riskler oluşturup oluşturmadığını sorguladı. Yoav Weiss buna yanıt verdi: Bu öneri, çıplak metale bir işletim sistemi (ERC-4337 gibi) yerleştirmeyi seçen zincirler, yani yerel hesap soyutlamasını kullanmayı seçen L2 zincirleri içindir. Ethereum ekosisteminde yeterince seçenek vardır ve kullanıcılar yerel hesap soyutlamasını kullanmayan diğer L2 zincirlerini tercih edebilirler.

Karmaşıklık ve Maliyet Değerlendirmeleri

Teklifin karmaşıklığı ve bunun sonucunda ortaya çıkan yüksek maliyetlerle ilgili endişelere ilişkin olarak, yazarlardan Dror Tirosh, bunun hesap soyutlamasının doğasında olduğunu söyledi. Hesap soyutlaması, genel EVM kodunu kullanarak harici verileri doğrulamak istediğimiz gerçeğinden kaynaklanmaktadır. Bu karmaşıklığın ortadan kaldırılması, blok üreticilerini DoS saldırılarına maruz bırakabilir veya genel EVM kod kullanımının kaldırılmasını gerektirebilir ki bu da hesap soyutlama teknolojisinin geliştirilme amacını ortadan kaldırır.

Sonuç

Şu anda, en azından Stackup'ın kurucusu gibi hesap soyutlama altyapısı sağlayıcıları, mutabakat katmanındaki bu tür değişiklikleri memnuniyetle karşılamaktadır; bu da mevcut hesap soyutlama hizmetlerinin temel sorunlarının hala yaygın olduğunu göstermektedir. Gaz Ücretlerini azaltmak ve kullanıcı dostu CA benzeri özellikler sunmak için yeterli sayıda dApp bu çözümü benimsemezse, paket sağlayıcılar kâr elde edemeyecek ve kullanıcı tutma oranları asla yükselmeyecektir. Bununla birlikte, bu teklife dayalı olarak geliştirilen hizmetler, hesap soyutlamasını yerel olarak desteklemek için zincirdeki mevcut EOA'ları sorunsuz bir şekilde destekleyebilirse, nihai hedefe (kitlesel benimseme, hesap soyutlamasını destekleyen Metamask, vb.) daha yakın olacağız ve DApp'lerle etkileşimdeki kullanıcı deneyimi giderek gelişecektir.