Hesap soyutlama, tüm Ethereum ekosisteminde kullanıcı ve geliştirici deneyimlerini iyileştirmeyi amaçlar. Zincir üstü deneyimleri kullanıcılar için daha erişilebilir ve eğlenceli hale getirmenin yanı sıra, geliştiricilerin Ethereum üzerinde daha güçlü şeyler yapabilmelerini ve kullanıcılara daha da anlamlı şekillerde hizmet edebilmelerini sağlar.

Hesap soyutlamaya yaklaşımlarımız şunlardır:

1. EOA geliştirme/programlanabilirlik: Bu, EOAların (Harici Sahipli Hesaplar) geçerlilik kurallarının yürütme mantık kısmını yeniden tanımlamalarını sağlayan protokol düzeyindeki değişiklikleri içerir. Geliştirme topluluğu içinde iyi bilindiği gibi, EOAlar genellikle son kullanıcılarla ilişkilendirilen hesaplardır. Bu nedenle, bu yaklaşımın içine düşen çözümler, bugün nasıl yönetilebileceğine kıyasla son kullanıcı hesaplarını hangi tür eylemleri yetkilendirebilecekleri konusunda daha fazla kontrolle donatacaktır.
2. EOA dönüştürme/göç: Bu yaklaşım, EOAların tamamen CA'lara (sözleşme hesaplarına) dönüştürülmesini amaçlayan önerileri içerir. Bu yaklaşımın temel fikri, sözleşme hesaplarının zaten akıllı hesaplar tarafından sunulan çoğu avantajı sunduğudur, bu yüzden artık işleri karmaşıklaştırmaya gerek olmamalıdır; herkes basitçe bir sözleşme hesabını (akıllı sözleşme cüzdanları aracılığıyla) ana hesapları olarak kullanmalıdır.

Bu yaklaşım, bir EOA'nın varlıklarını taşımadan bir CA'ya geçiş yapmasına izin veren mekanizmaları içerir.EIP 7377veEIP 5003(EIP 3074 ile birlikte düşünüldüğünde).

1. Akıllı Hesaplar: Bu öneri grubu, hem EOAs hem de CAs'nın kendi geçerlilik kurallarını tamamen yeniden tanımlamalarına izin vererek onları 'akıllı hesaplar' gibi davranmalarını sağlayan tasarımları içerir.

Protokol düzeyinde akıllı hesapların oluşturulması ve hesap soyutlama şemsiyesi altına alınması için daha önce çeşitli önerilerde bulunulmuştur; EIP-86veEIP-2938Ancak bunlar, daha sık alıntılananlardan bazılarıdır. Bununla birlikte, bu tasarımın getirdiği algılanan karmaşıklık ve Ethereum'un böyle bir karmaşıklığa hazır olmadığı yönündeki çoğunluk görüşü nedeniyle büyük bir tepki oldu.

The Merge'den sonra Vitalik'in konuyu yeniden gündeme getirmesinin ardından,ERC-4337Akıllı hesap standardının isteğe bağlı bir versiyonu olarak önerildi, MEV (Maksimum Çıkartılabilir Değer) için PBS (Öneren-Oluşturucu Ayrımı) altyapısına benzer. Bu şekilde, akıllı hesapların faydalarına erişmek isteyen kullanıcılar, hesap mantığını ve işlemlerin geçerlilik kurallarını Yapılandırmalar olarak adlandırılan yapılar içinde tanımlamak için ERC-4337 boru hattını kullanabilirler.

ERC 4337, enshrined smart hesapların dışındaki bir protokol alternatifi olarak, mevcut Ethereum'a akıllı hesapların faydalarını getirirken herhangi bir karmaşıklığı da içermiyor. Bununla birlikte, altyapının mevcut durumunda optimal olduğu anlamına gelmez çünkü kendi karmaşıklığı hala önemli bir başarısızlık noktasıdır.

Bu karmaşıklığı ele almak için, RIP 7560ERC 4337 altyapısının Ethereum ve L2'leri boyunca bir kutsal versiyonu olarak tasarlandı, böylece yeni bir kural seti tanımlamak yerine ağın sybil-direnç şemalarını devralır (ERC 4337 bununla yapar)ERC 7562).

Bu raporda, EOA programlanabilirliğini keşfetmeye odaklanacağız, bu çizgide çözümleri tanımlayan çeşitli EIP'leri değerlendireceğiz ve avantajları ve dezavantajları tartışacağız. Bu serinin 2. ve 3. bölümlerinde, Ethereum içinde araştırılan hesap soyutlama yaklaşımının kalan iki sınıfını ele alacağız.

Ethereum Hesapları ve İşlemleri Hakkında Temel Bilgiler

Soyutlanabilecek şeyleri aramak için, mevcut hesap tasarımının (biraz) tam bir resmine ihtiyacımız var. Bu bölüm, aslında Ethereum'daki hesapların ne olduğu ve işlemlerinin nasıl doğrulandığı ve gerçekleştirildiği konusunda bir tür revizyon olarak hizmet edecek.

Ethereum hesapları, bir ether (ETH) bakiyesine sahip olan ve Ethereum blokzincirinde işlem gönderme yeteneğine sahip varlıklardır. Bunlar, hesabın varlıklarını ve işlemlerini benzersiz bir işaretçi olarak görev yapan 42 karakterlik onaltılık bir "adres" olarak temsil edilir.

Bir adres, blok zincirinin durum ağacına bir anahtar olarak hareket eder. Bu trie'nin yaprak düğümleri, dört alana ayrılabilen hesap veri yapılarıdır:

1. nonce: Bir hesap tarafından başlatılan çıkış işlemlerinin sayısını göstermek için kullanılan lineer bir sayaç. Tekrar saldırılarını engellemede de kritik bir rol oynar.
2. bakiye: Bir hesaba ait olan ether (ETH) miktarı, wei cinsinden ifade edilir.
3. codeHash: Hesapta bulunan EVM-yürütülebilir kodun bir karma değeri. EVM (Ethereum Sanal Makinesi), basit 'gönderme' işlemlerinin ötesinde karmaşık durum geçişlerini ele alan Ethereum'un özel yürütme ortamıdır. Bir hesabın kod içeriği, Ethereum blok zincirinde belirli durum geçişlerini gerçekleştirmek için değiştirilemez şekilde programlanmıştır, EVM aracılığıyla.
4. storageHash: Bir hesabın depolama kökünün bir karmasıdır ve bir hesabın depolama içeriğini bir merkle patricia ağacının kök düğümünün 256 bitlik bir karması olarak temsil etmek için kullanılır. Basitçe söylemek gerekirse, bir hesabın kod içeriği ile ilişkili durum değişkeni verilerinin bir karmasıdır.

Bu dört alanın içeriği, bir hesabın türünü tanımlamak için kullanılır ve nihayetinde işlevselliğinin derecesini belirlemek için kullanılır. Bu nedenle, Ethereum hesaplarının iki türü vardır:

1. Dışarıdan Sahip Olunan Hesaplar (EOA'ler) - bunlar bir kriptografik anahtar çifti olarak başlatılır:

• Şifrelenebilir ve kanıtlanabilir rastgele 64 haneli bir özel anahtar ve onun tamamlayıcı karşıtı;
• ECDSA (Elliptic Curve Digital Signature Algorithm) kullanılarak özel anahtardan türetilen bir genel anahtar.

EOA'ların boş codeHash ve storageHash alanları vardır ve yalnızca özel anahtarlara sahip olan herkes tarafından kontrol edilebilirler. Adresleri, hesabın genel anahtarının keccak-256 karma işleminin son yirmi karakterine "0x" ön eklenerek elde edilebilir.

1. Sözleşme Hesapları (CA'lar) - sadece mevcut bir EOA tarafından oluşturulabilirler. EOA, yürütülebilir kod içeriğini EVM üzerinde dağıtarak bunları başlatır. Bu kod içeriği (codeHash olarak saklanır) EVM'de korunur ve hesabın mantığını ve etkileşimlerini tanımlayarak hesabın kontrolünden sorumludur.

İşlemleri tamamen çekmeye dayalıdır ve dağıtılmış kodun mantığına dayanır.

Bu hesaplar yalnızca kod içerikleri tarafından kontrol edilebildiğinden, özel anahtara ihtiyaçları yoktur ve yalnızca bir genel anahtarları vardır. Böylece, bir sözleşme hesabının kod içeriğini güncelleme/değiştirme yeteneğine sahip herhangi bir ajan, bakiyesine erişebilir.

Bir CA'nın adresi, oluşturucusunun adresinden ve kontratın dağıtılma noktasına kadar olan nonce'undan türetilir.

İşlemler

Hesapları Ethereum üzerinden işlem gönderme yeteneğine sahip varlıklar olarak tanımlamıştık. Bu nedenle hesapların temel amacının işlem göndermek ve almak olduğunu anlayabiliriz, blok zinciri ise işlem geçmişini kaydeden bir defter olarak işlev görür ve blok zinciri protokol spesifikasyonunda tanımlanan kurallara dayanarak işlemlerin hesap alanlarını nasıl değiştirdiğini açıklar.

Peki bu "işlemler" nedir?

İşlemler, ağın "durumu"nda bir değişikliğe yol açan bir hesaptan gönderilen işlemlerdir. Bunlar, hesaplardan kriptografik olarak imzalanmış talimatlar olup, yürütüldüğünde ağ genelinde bir durum güncellemesine neden olurlar.

İzin verilmemesi, yanlış teşviklerin maliyetiyle gelir; bunlarla başa çıkmak için, bu tür ortamlardaki etkileşimler için sıkı kurallar (veya geçerlilik kuralları) belirlenmelidir.

Bu bağlamda, işlemlerin geçerli ve yürütülebilir kabul edilmesi için belirli geçerlilik kurallarını izlemesi gerekir. Bu geçerlilik kurallarının çoğu, işlemi gönderen hesaba yerleştirilen kısıtlamalar aracılığıyla uygulanır ve hesabın türüne bağlı olarak değişir.

Hesaplar ve İşlem Geçerliliği

Ethereum'da, EOAlar kullanıcı dostu olacak şekilde optimize edilmiştir. Belirli bir şekilde işlem gönderme ve mükemmel bir şekilde otomatik çalışma yeteneklerine sahiptirler. Ayrıca yerel olarak da oluşturulabilirler, daha yaygın olan yöntem MetaMask, Rainbow, Rabby vb. gibi cüzdan sağlayıcılarının kullanılmasıdır.

Öte yandan, sözleşme hesapları yalnızca mantıklarına izin verilen işlemleri 'çağrıldığında' gönderebilir. Ayrıca, yalnızca durum depolaması için yeterli bakiyeye sahip bir EOA tarafından oluşturulabilirler.

Daha yüksek düzeyde bir açıklama, EOAların sadece bir denge tutabileceği, CA'ların ise hem bir denge hem de bu dengenin nasıl harcanacağını belirleyen mantığı tutabileceği şeklinde olabilir.

Bu özellikler, bir hesabın işlemlerinin uyması gereken kuralları tanımlayan aşağıdaki mantık parametrelerine bağlıdır:

1. Kimlik doğrulama mantığı - Bir hesabın bakiyesini ve/veya mantığını değiştirirken ağına kimlik kanıtlaması yaptığı şekilde kullanılır.
2. Yetkilendirme mantığı - Bir hesabın erişim politikasını tanımlamak için kullanılır, yani hesabın bakiyesine ve/veya mantığına erişebilen ve değişiklik yapabilen kişiler kimlerdir.
3. Nonce mantığı - bir hesaptan yapılan işlemlerin hangi sırayla gerçekleştirileceğini tanımlar.
4. Gaz ödeme mantığı - Bir işlemin gaz ücretini ödeme sorumluluğunu tanımlamak için kullanılır.
5. Yürütme mantığı - Bir hesabın hangi tür işlemleri gönderebileceğini veya bir işlemin nasıl yürütüleceğini tanımlamak için kullanılır.

Bu parametreler EOAlar için katı bir şekilde tasarlanmıştır.

• Kimlik doğrulama ve yetkilendirme, yani bir kullanıcının EOA'sından işlem göndermek isteyen bir kullanıcının hesabına erişmek için özel anahtarlarını kullanması gerektiği gibi, bir ECDSA tabanlı özel anahtar tarafından sağlanır ve bu şekilde hesabın bakiyesinde herhangi bir değişiklik yapma hakkına sahip olduklarını kanıtlarlar.
• Nonce mantığı, her bir hesap için benzersiz bir nonce'a sahip olan yalnızca bir işlemi ardışık olarak yürütmeye izin veren bir ardışık sayaç şemasını uygular.
• Gaz ödeme mantığı, işlemler için gaz ücretinin gönderen/ilk hesap tarafından ödenmesini belirtir.
• Yürütme mantığı, yalnızca Ethereum Adresli Hesaplar'ın (EOA) aşağıdaki işlem formlarını gönderebileceğini belirtir:

1. İki EOAs arasında düzenli transferler.
2. Sözleşme dağıtımı.
3. kontrat çağrıları, bir dağıtılmış kontrat hesabının mantığı hedef alır.

Daha genel olarak, EOAs'ın yürütme mantığı, geçerli bir imza için bir işlemle sınırlıdır.

Öte yandan, CA'ların bu parametreler etrafında daha fazla esnekliği var:

• Kimlik doğrulaması gerekli değildir, çünkü işlemleri sonuç olarak çekme tabanlıdır.
• CA'lar için yetkilendirme iki şekilde olabilir:

1. CAs içerik kodunu "çağırma" (veya akıllı sözleşmesini yürütme) yeteneği, hesabın akıllı sözleşmesinin mantığına ve değişmezliklerine bağlıdır.
2. CAs içerik koduna değişiklik yapabilme yeteneği, bu genellikle içerik kodunun yükseltilebilir olup olmadığına bağlıdır.

Çoğu pratik durumda, bu durumda kullanılan mantık, belirli hesaplardan (genellikle EOA'lar) M < N olan N geçerli imzanın M'inin gerektiği bir çok imza şemasıdır, böylece CA'nın mantığının değiştirilmesi geçerli olur.

• İşlem sıralama işlemi gevşek bir nonce tabanına dayanmaktadır. CA kendisi, çeşitli çağrıları olan birçok işlemi mümkün olduğunca gönderebilir, ancak her çağrılanda kendi yeteneklerine bağlı olarak sınırlıdır.
• Gaz ödemesi genellikle CA mantığını çağıran kişi tarafından ele alınır.
• CA'ların yürütme mantığı, çoklu çağrı işlemleri ve atomik işlemler gibi UX geliştirmelerine izin verecek şekilde daha çeşitlidir.

Bu özellikleri değerlendirdiğimizde, her hesap türünün özerklik ve programlanabilirlik arasında bir denge oluşturmak üzere tasarlandığını görüyoruz.

EOA'ler tam özerkliğe sahiptir, ancak sınırlı programlanabilirlikleri vardır; istedikleri zaman işlem yetkilendirebilir ve gönderebilirler, ancak bu işlemlerin geçerli sayılabilmesi için katı bir formata uymaları gerekir. CA'lar tam programlanabilirlik (yalnızca EVM'nin tasarımı tarafından sınırlı) ancak sınırlı özerkliğe sahiptir; işlemleri herhangi bir katı formata uymak zorunda değildir, ancak mantıkları öncelikle çağrıldığı için sadece gönderilebilirler.

Aşağıdaki alt bölümde, bu tasarım seçimlerinin sonuçlarını inceleyerek, bu seri boyunca tartışılan her EIP'nin teklifini tam olarak anlamak için şimdi çalışacağız.

Ethereum'ın hesap sorunu

Artık farklı hesapların işlevleri hakkında biraz kısa ve öz bilgiye sahip olduğumuza göre, satış noktalarını ve Ethereum'da hem kullanıcı hem de geliştirici deneyimine sundukları sorunları kolayca belirleyebiliriz.

Daha önce belirtildiği gibi, EOAlar, son kullanıcıları hedefleyen birinci sınıf hesaplar olarak tasarlanmıştır. Uygulamaların bunlarla kolayca etkileşim kurması için tasarlanmıştır, neredeyse hiçbir karmaşıklıkları yoktur ve tabii ki bir tane oluşturmak için bir maliyetleri yoktur. Ancak, basitliği, katı bir belirlenmişlik olarak tasarlandıkları için önemli bir yenilik kaybıyla birlikte gelir.

Onların etrafındaki endişelerden bazıları:

1. Kuantum saldırılara duyarlılık - Anahtar çiftleri tarafından kullanılan ECDSA imza şeması kuantum dirençli değil ve endüstriyel kuantum sistemlerinin 5 ila 10 yıl içinde başarılması iyimser bir zaman çizelgesi olduğundan, bu durum Ethereum ve uygulamaları için önemli bir tehdit oluşturuyor. Bu uygulamalar kriptografik kanıtlar ve güvenlik için ECDSA şemasına ağır şekilde bağımlıdır.
2. İfade eksikliği – EOA'ların geçerlilik kurallarının katı formatı, kullanıcıların işlem atomikliği ve toplu işlem ve işlem delegasyonu gibi özellikler aracılığıyla işlemlerini daha kısa ve öz bir şekilde ifade etme yeteneğini ortadan kaldırır.
3. Kendine yetebilirlik - Herkesin işlem sırasında "benzinim bitti" anları olmuştur. Bunun nedeni, EOAs'ın işlemleri için gazı kendilerinin yerleştirmesi gerektiği gerekliliğidir ve eğer ether (ETH) tek kabul edilebilir gaz para birimi olmasaydı, bu çok büyük bir talep olmazdı. Bu, hesap tabanlı durum makinelerinin (ve hatta UTXO tabanlı olanların) genel bir sorunu olsa da, Ethereum her zaman farklı olmayı amaçlamıştır.

Herkes her zaman ETH'yi elinde tutmak istemez (veya tutamaz) (yani şu fiyat hareketine bakın), bu nedenle uygulanabilir çözümler birden fazla gaz para birimine izin vermek olacaktır ("Para Birimi" bölümünde açıklandığı gibi çok zor, çok fazla değişmezi kırar burada), veya gaz ödemelerinin işlemin kaynağı olmayan başka bir hesap tarafından yerine getirilmesine izin vermek için kullanılır.

Hesap spektrumunun diğer ucunda, KAs geliştiricilere ve daha teknik bir kullanıcı tabanına yöneliktir. Akıllı sözleşmeler için araç olarak hizmet verirler (yani akıllı sözleşmeleri içeren mantığı veya kod içeriğini düşünüyoruz) ve EVM tarafından mümkün kılınan yeni işlem formatlarını uygulayabilirler.

Ancak, tüm bu özelliklere rağmen, bunlar otonomiye sahip olmadıkları için övülen ikinci sınıf hesaplardır. Dezavantajları şunlardır:

1. Toplamda otonomi eksikliği - CA'lar bir işlem başlatamaz, yalnızca çok belirli bir şekilde çağrıldıklarında işlemleri gönderebilirler.
2. Mantıksal hatalara karşı duyarlılık - Esneklik eksikliği genellikle değişmezlerin yanlış tanımlanmasına ve akıllı sözleşme saldırıları ve hack'ler nedeniyle milyarlarca dolarlık kayıplara yol açan diğer mantıklara yol açar. Bununla birlikte, bu neredeyse tamamen farklı bir konu olup burada kapsamımızın dışındadır.

Bu alt bölümde tanımlanan sorunlara yol açan tasarım seçeneklerini gözden geçirdikten sonra, şimdi önerilen çözümleri değerlendirebiliriz.

Hesap soyutlama zaman çizelgesi

Hesap soyutlama kavramı (en azından akıllı hesaplar aracılığıyla), Ethereum'un yol haritasının her zaman ayrılmaz bir parçası olmuştur. Efsane şudur ki, uygulama etrafındaki karmaşıklık Ethereum'un başlatılmasını daha da geciktirmeye tehdit etti ve bu yüzden farklı hesapların farklı işlevler sunmasıyla mevcut tasarımdan vazgeçildi. Ethereum'un Birleşme'ye odaklanmasıyla tekrar gecikti ve şimdi ağın bir sonraki büyük güncellemesi olan Pectra'nın temel bir parçası olarak tekrar gündeme geliyor. Bununla birlikte, karmaşıklığı hala onun tanınması önleyen önemli bir dezavantaj olarak kabul ediliyor, özellikle Ethereum'un rollup-odaklı bir yol haritasına dönmesiyle birlikte.

Gereksinimler artık ikiye katlanmış durumda:

1. Hesap standartları daha anlamlı olmalı, ancak özerklik kaybı olmadan. EOA ve CA standartları arasındaki farkı kapatan yeni bir standart.
2. Yeni standart, Ethereum ve L2 ekosistemleri arasında tamamen uyumlu kalırken, EOAs ve CAs arasındaki farkı kapatmalıdır.

Bu kavram, zincir soyutlama ve etkileşim bağlamında daha büyük bir rol oynar. Bununla birlikte, bu rapor boyunca kapsamımız, hesap soyutlamayı başarmak için yapılan teknik girişimlerle sınırlıdır.

Hesap soyutlama, EOAs ve CAs'ın en iyi özelliklerini birleştirerek yeni bir hesap standardı olan akıllı hesapları mümkün kılar. Akıllı hesaplar, herhangi bir hesabın geçerlilik kurallarını doğrulama mantığı ve yürütme mantığı olarak tam veya kısmi olarak ayırma imkanı sağlar; böylece hesaplar, sözleşme hesapları gibi EVM tarafından izin verildiği gibi kendi geçerlilik kurallarını tanımlayabilirken tamamen bağımsız olarak kalır.

Akıllı hesaplar ve akıllı sözleşme cüzdanları arasındaki farklarla ilgili genellikle karışıklık vardır, bu nedenle bu farkları açıkça aşağıda açıklayalım:

• Akıllı hesaplar, programlanabilirlik ve özerklik sağlamak amacıyla kavramsallaştırılmış Ethereum hesaplarıdır. Fikir şudur ki, EOAs ve CAs, kendi istedikleri şekilde ağ tarafından dayatılan geçerlilik kurallarını özel geçerlilik kuralları ile değiştirmelerine izin veren bir mekanizma (örneğin ERC 4337) kullanarak kolayca akıllı hesaplara dönüşebilir.
• Öte yandan, akıllı kontrat cüzdanları, sadece kontrat hesaplarına arayüz olarak hizmet eden cüzdan sağlayıcılarıdır (evet, bir cüzdan bir hesap değildir).

Akıllı sözleşme cüzdanlarının ticarileştirilmesi, daha az teknik kullanıcıların sunabilecekleri özelliklerden yararlanmalarına olanak tanıyarak CAs'nın daha geniş bir pazar tarafından benimsenmesini kolaylaştırdı. Ancak, hala CAs ile ilişkili tehlikelerle karşı karşıya kalmaktadırlar.

Konuşmaya geri dönersek; daha önce hesap işlemlerinin geçerlilik kurallarını tanımlamak için kullanılan parametreleri tartışmıştık:

• Kimlik doğrulama
• Yetkilendirme
• Nonce mantığı
• Gaz ödeme mantığı
• Yürütme mantığı

İlk dört parametrenin değerleri, bir hesabın doğrulama mantığı olarak ortaklaşa adlandırılabilir ve bu, bir işlemin yürütmesi başlamadan önce gerçekleşen kontrol işlemleridir.

Son parametre, işlemin nasıl yürütüleceğini tanımlar.

Girişte, mevcut AA manzarasının çeşitli önerilen tasarımlar için bir tür sınıflandırması şeklinde yüksek düzeyli bir genel bakışını sunduk. Şimdi Ethereum'un hesap problemine çözüm olarak önerilen çözümlerin ilk sınıfına odaklanacağız - EOA programlanabilirliği.

Programlanabilir EOA'lar

Ethereum'un en büyük çekiciliği, genç ancak canlı DeFi ekosistemi, temel likidite çekim alanı olan çeşitli merkezsizleştirilmiş uygulamaları içermesidir. Bu DApp'lerin çoğu EOA'ları hizmet etmek için optimize edilmiştir, bu nedenle CAs ve sonunda akıllı hesaplarla arayüz oluşturmak zordur. Akıllı sözleşme cüzdanları bu durumda CAs'a yardımcı olsa da, kendi sınırlamaları ve tamamen farklı bir UX ile birlikte gelirler.

Akıllı hesap standartına alışırken hem DApp'lerin hem de cüzdan sağlayıcılarının alıştığı bir geçici çözüm, onlara, doğrulama veya yürütme mantığı olsun, uygulanan kısıtlamaların çoğunu aşmalarını sağlayan geçici iyileştirmeler sağlamaktır.

Aşağıda, EOA programlanabilirliği için işlenebilir rotalar sağlayan üç önemli EIP'nin özelliklerini inceliyoruz; daha az bilinenEIP 5806, hırslı olan EIP 3074ve sonunda zaferle EIP 7702.

EIP-5806 aracılığıyla programlanabilirlik

Bu öneri, EOA standardına daha fazla işlevsellik getirmeyi amaçlamaktadır. Bu, EOA'nın bir kontrat hesabının mantıksal (akıllı kontratı) için delege çağrılar yapmasına izin vererek gerçekleştirilir. Bu etkili bir şekilde akıllı kontratın çağrı yapan EOA'nın bağlamında yürütülmesine neden olur, yani EOA doğrulama mantığı üzerinde kontrol sahibi olurken, yürütme mantığı ilgili CA'nın mantığı tarafından ele alınır.

Daha ileri gitmeden önce, Ethereum evrim hafızası yolculuğuna bir göz atalımEIP-7.

EIP-7, 0xf4/DELEgateCALL opcode'nin oluşturulmasını önerdi, bu opcode birincil bir hesaba ikincil bir hesabın mantığıyla mesaj çağrıları göndermek için kullanılırken, birincil hesabın [gönderen] ve [değer] alanlarının değerlerini korur.

Başka bir deyişle, birincil hesap, mesaj çağrısında belirtilen süre boyunca ikincil hesabın mantığını "miras alır" (veya tercih ederseniz ödünç alır), böylece sonuncusunun mantığı birincisinin bağlamında uygulanır.

Bu opcode, dApp geliştiricilerinin uygulama mantığını birden fazla akıllı sözleşmeye bölmelerine izin verirken, birbirlerine bağımlılığı korumalarını sağladı, böylece kod boyutu engellerini ve gaz engellerini kolayca atlayabildiler.

EIP-5806 özetlendi

Peki, delege çağrıları CA'ların birbirlerine bağımlı olmasına nasıl izin verir? EIP-5806, delege çağrı işlevselliğinin EOAlara da genişletilmesini önermek için EIP-7'yi bir ilham kaynağı olarak kullanıyor; yani, EOAların da CA'larla birbirlerine bağımlı olmalarına izin verelim, çünkü neden olmasın.

Özellikler

EIP 5806 yeni bir tanıtırEIP-2718-uyumluaşağıdaki gibi paketlenmiş işlem türü

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Bu işlemler, alıcının adresini temsil eden [to] alanının yalnızca 20 baytlık girişler olarak adresleri kabul edebileceği şekilde tasarlanmıştır, bu da gönderenin CREATE opcode'ini kullanmasını engeller.

RLP düzeninin her bir bileşeninin motivasyonu şöyledir:

• chainID: Geçerli zincirin 32 bayt ile dolgulanmış EIP-115 uyumlu tanımlayıcısı. Bu değer, orijinal zincirdeki işlemlerin benzer bir geçmişe ve daha az ekonomik güvenliğe sahip alternatif EVM zincirlerinde kolayca tekrarlanmaması için tekrar saldırı koruması sağlar.
• nonce: Her işlem için benzersiz bir tanımlayıcıdır ve tekrar oynatma saldırılarına karşı koruma sağlar.
• max_priority_fee_per_gas ve max_fee_per_gas: Bir EIP-5806 işlemi için sıralama ve dahil etme için ödenecek gaz ücreti değerleri.
• gas_limit: Tek bir 5806 türü işlemin tüketebileceği maksimum gaz miktarı.
• hedef: İşlem alıcısı
• veri: Yürütülebilir kod içeriği
• access_list: EIP-5806 işlemlerini koşullu olarak gerçekleştirmeye yetkilendirilmiş ajanlar.
• signature_y_parity, signature_r ve signature_s: mesaj üzerindeki secp256k1 imzasını temsil eden üç değerdir - keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

EIP-5806 işlemlerinin EIP-2718 zarflarına paketlenmesi, geriye dönük uyumluluğu büyük ölçüde sağlasa da, EOAs CA'larla eşdeğer değildir. Bu nedenle, bir EOA'nın delege çağrılarını kullanma şeklinde belirli kısıtlamalar tanımlanmalıdır, böylece değişmezlik bozulmaları önlenir.

Bu kısıtlamalar aşağıdaki opcode'lar hedef alınarak yapılmıştır:

• SSTORE/0x55: Bu opcode, bir hesabın bir değeri depolamasına izin verir. EIP-5806 işlemlerinde, hesap göçünün neden olabileceği olası sorunları önlemek amacıyla, EOAların delege çağrıları kullanarak depolama ayarlamasına/erişmesine izin verilmediği için kısıtlanmıştır.
• CREATE/0xF0, CREATE2/0xF5 ve SELFDESTRUCT/0xFF: Bu opcode'lar çağrıcıya yeni bir hesap oluşturma olanağı sağlar. Bunlara erişim, bir EOA'nın nonce'unun farklı bir yürütme çerçevesinde (bu durumda sözleşme oluşturma/yok etme) EIP-5806 işlemi gerçekleştirirken değiştirilmesini önlemek için kısıtlanmıştır, böylece işlemlerin ardışık nonce'lar taşıdığı beklentisinin geçersiz kılınmasını önlemek.

Potansiyel Uygulanabilirlik/Kullanım Alanları

EIP 5806'nın birincil uygulanabilirliği, EOA'lar için yürütme soyutlamasıdır. EOA'ların mantıklarına yapılan basit çağrıların ötesinde akıllı sözleşmelerle güvene dayalı olmayan bir şekilde etkileşime girmesine izin vermek, onlara aşağıdaki gibi özellikler sağlar:

• İşlemlerin koşullu yürütülmesi
• İşlem toplama
• Çoklu arama işlemleri (ör. onaylama ve arama)

Eleştiri

EIP-5806 tarafından önerilen değişiklikler, gerekli özelliklerin etkinleştirilmesine rağmen, pek yeni değil; varlığı çoğunlukla zaten işlevsel olan EIP-7'ye dayanmaktadır. Bu, kabul edilme potansiyel engellerin birçoğunu atlamasına izin verir.

Erken günlerinde dile getirilen önemli endişelerden biri, EOAların depolama alanına erişim ve değişiklik yapma potansiyel riskiydi, şu anda CA'ların yaptığı gibi. Bu, EOAların nasıl işlem yapacaklarıyla ilgili ağa yerleştirilmiş birçok değişmez kuralı ihlal eder ve bu nedenle önceki alt bölümde bahsedilen kısıtlamaların tanıtılmasıyla ele alınmıştır.

İkinci bir eleştiri (ki bu biraz iki ucu keskin bir kılıç gibidir), EIP-5806'nın basitliğidir; EIP-5806'yı kabul etmenin getirdiği ödüllerin maliyetine değmeyebileceği bir duygu var, çünkü sadece yürütme soyutlamasını mümkün kılıyor ve pek fazlasını yapmıyor. EIP-5806'ya katılan EOAlar için diğer her türlü geçerlilik kısıtlaması ağ tarafından belirlenmeye devam ediyor, bu da diğer biraz benzer EIP'lerin aksine, konunun alt bölümlerinde tartıştığımızı.

EIP-3074 aracılığıyla programlanabilirlik

EIP-3074, EOAların doğrulama mantığının çoğunu işlemlerin belirli formları için onların yetkilendirme mantığını üzerlerine yerleştirerek özel sözleşme hesaplarına, yani çağıranlara devretmelerine izin vermek için önerilmektedir.

Bu, erişim politikalarını bir çağırıcı sözleşmesine imzalayarak başarır; bu sözleşme daha sonra EOA'nın erişim politikasını tanımlamaktan sorumlu olur.

Bu EIP, EVM'ye iki yeni opcode eklenmesini önermektedir:

• [AUTH], ikinci [yetkililik] hesabı adına hareket etmek üzere bir bağlam değişkeni [yetkili] hesabını, sonuncusunun ECDSA imzasına dayanarak ayarlar.
• [AUTHCALL], [yetkili] hesaptan / olarak [yetkili] hesaba çağrı gönderen / uygulayan hesap soyutlaması.

Bu iki opcode, bir EOA'nın önceden kurulmuş bir CA'ya kontrol yetkisi devretmesine ve böylece bir sözleşme dağıtmak ve bununla ilişkili maliyetleri ve harici faktörleri karşılamak zorunda kalmadan onun aracılığıyla hareket etmesine olanak tanır.

Özellikler

EIP-3074, diğer işlem imzalama formatlarıyla çakışmaları önlemek için işlemlerin [MAGIC] imzalama formatını kullanmasına izin verir. [AUTHCALL] talimatlarının geçildiği etkin hesap, yalnızca tek bir işlem boyunca süregelen ve her yeni [AUTHCALL] için yeniden tanımlanması gereken bir bağlam değişkeni alanı olan [yetkilendirilmiş] olarak tanımlanır.

Her bir opcode'un karmaşıklıklarını ele almadan önce, EIP-3074 işlemine dahil olan varlıklar şunlardır:

• [authority]: Erişimi/denetimi genellikle bir sözleşme hesabı olan ikinci bir hesaba devreden birincil imzalama hesabı (EOA).
• [yetkili]: [AUTHCALL] talimatlarının yürütülmesi için iletilmesi gereken hesap. Başka bir deyişle, [yetki], [çağrıyı yapan] tarafından tanımlanan kısıtlamalar kullanılarak [AUTHCALL] mantığının yürütüldüğü hesaptır.
• [invoker]: [Yetkilendirilmiş] hesap ve [AUTHCALL] mantığı arasındaki etkileşimleri yönetmek için tasarlanmış bir yan sözleşme, özellikle ikincisinin sözleşme kodunun birincil mantığı gaz sponsorluğu olduğu durumlarda.

Invoker sözleşmeleri, [otorite] tarafından [COMMIT] değeri ile birlikte [AUTH] mesajları alır; bu değer, hesabın [yetkili]'nin [AUTHCALL] talimatlarının yürütülmesine yerleştirmek istediği kısıtlamaları tanımlar.

Bu nedenle, çağıranlar [yetkilendirilmiş] bir hesapta tanımlanan [sözleşme_kodu]nin kötü niyetli olmadığını ve bir [COMMIT] değeriyle birincil imzalayan hesap tarafından yerleştirilen koşulları karşılayabilme yeteneğine sahip olduğundan sorumludur.

[AUTH] opcode üç yığın eleman girişine sahiptir; veya daha basit bir ifadeyle — tek bir çıktıyı hesaplayan üç giriş tarafından tanımlanmıştır. Bu girişler:

1. yetki: imzayı oluşturan EOA adresi
2. ofset
3. uzunluk

Son iki giriş, 0 ila 97 arasındaki değiştirilebilir belleği tanımlamak için kullanılır, burada:

1. [memory(offset : offset+1)] - [yParity]
2. [bellek(ofset+1 : ofset+33] – [r]
3. [bellek(ofset+33 : ofset+65)] – [s]
4. [memory(offset+65 : offset+97)] – [COMMIT]

Değişkenler [yParity], [r] ve [s], secp256k1 eğrisindeki bir ECDSA imzası olan [magic] mesajı üzerinde toplu olarak yorumlanır.

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

nereye:

• [MAGIC], değişkenlerin birleşimi sonucunda oluşan bir ECDSA imzasıdır.
  • Benzer bir geçmişe ve daha az ekonomik güvenliğe sahip alternatif EVM zincirlerinde tekrar saldırısı koruması sağlamak için kullanılan mevcut zincirin EIP 115 uyumlu tanımlayıcısı olan [chainID].
  • [nonce], işlem imzalayıcısının adresinin mevcut nonce'u, 32 bayt'a soldan dolgulanmış.
  • [invokerAddress], [AUTH]'un yürütülmesi için mantığı içeren sözleşmenin adresidir.
• [COMMIT], çağıranın ön işleme mantığında ek işlem geçerlilik koşullarını belirlemek için kullanılan 32 byte'lık bir değerdir.

Hesaplanan imza geçerliyse ve imzalayanın adresi [yetkili] değerine eşitse [yetkili] alanı, [yetkili] tarafından sağlanan değere güncellenir. Bu gereksinimlerden herhangi biri karşılanmazsa [yetkilendirilmiş] alanı önceki durumunda veya ayarlanmamış bir değer olarak değişmeden kalır.

Bu opcode için gaz maliyeti, şunların toplamı olarak hesaplanır:

1. 3100 birim değerinde [ecrecover] ön derleme için sabit bir ücret ve keccak256 karma işlemi ve bazı ek mantık için ekstra ücret
2. [RETURN] işlem koduna benzer şekilde hesaplanan ve bellek, geçerli ayırmanın belirtilen aralığını (97 birim) aşacak şekilde genişletildiğinde uygulanan bir bellek genişletme ücreti
3. Bir sıcak [authority] için 100 birim sabit maliyet ve durum erişimi opcode'larının yanlış fiyatlandırması nedeniyle saldırıları önlemek için bir soğuk birimi 2600 birim

[AUTH], belleği değiştirmemek için uygulanır ve [authority]'nin değerini bir argüman olarak alır, böylece sağlanan imzadan değerini doğrulamak kolaydır.

The [AUTHCALL] opcode, tek bir yığın elemanı çıktısı hesaplamak için kullanılan yedi yığın elemanı girişi olan bir opcode'dur.

[CALL] opcode'ıyla aynı mantığa sahiptir; yani bir hesaba iletişim çağrıları göndermek ve sözleşmelerinde belirli mantığı tetiklemek için kullanılır. Mantıklarındaki tek sapma, [AUTHCALL]'un yürütme işlemine devam etmeden önce [CALLER]'ın değerini ayarlamak üzere tasarlanmış olmasıdır.

Bu nedenle, [AUTHCALL], [yetkili] tarafından [yetkili] içinde bağlama özgü davranışı tetiklemek için kullanılır ve mantıksal kontroller aşağıdaki gibi ilerler:

1. [authorized] değerini kontrol edin. Ayarlanmazsa, yürütme geçersiz sayılır ve çerçeveden hemen çıkılır. Bu, benzeri görülmemiş arızalar nedeniyle haksız ücretlerin önlenmesine yardımcı olur.
2. Yetkilinin amaçlanan davranışının gaz maliyetini kontrol eder.
3. [gaz] işleneninin EIP-150 uyumlu değerini kontrol eder.
4. [authority] bakiyesindeki toplam gaz maliyeti -[değer]- mevcutluğu kontrol ediliyor.
5. Yürütme, [değer]’in [yetkinin] hesabından düşülmesinden sonra gerçekleşir. Eğer [değer], bakiyelerinden büyükse, yürütme geçersiz kılınır.

[AUTHCALL] için gaz maliyeti şu şekilde hesaplanır: toplamın

• [warm_storage_read]'yi aramak için sabit bir maliyet
• Bellek genişletme ücreti [memory_expansion_fee]'dir; [CALL] opcode için gaz ücretine benzer şekilde hesaplanır.
• Dinamik bir maliyet [dynamic_gas]
• Alt çağrının yürütme maliyeti [subcall_gas]

[AUTHCALL] döndürülen verilere şu şekilde erişilir:

• [RETURNDATASIZE] - dönüş veri tamponunun boyutunu çıkış yığınına iter
• [RETURNDATACOPY] - dönüş veri tamponundaki veriyi belleğe kopyalar.

Teknoloji konuşmalarını daha az kullanarak her şeyi bir araya getirmek için; Ethereum işlemleri genellikle iki değer belirtir:

1. tx.origin - işlem için yetkilendirme sağlar.
2. msg.sender - gerçekte işlemin gerçekleştiği yer.

EOA'ların, daha önce belirtildiği gibi, yetkilendirme sıkı bir şekilde yürütmeye bağlıdır, yani; (tx.origin == msg.sender). Bu basit değişmez, bu raporun "Hesaplar ve İşlem Geçerliliği" alt bölümünde açıkladığımız çoğu soruna yol açar.

[YETKİ] [otorite] tarafından gönderilen mesajlar, [yetkilendirilmiş] olarak tx.origin işlevini dengelemesine ve aynı zamanda msg.sender olmasına olanak tanır. Ayrıca, bu ayrıcalığı [TAHSİS] değeri kullanarak kısıtlamalar belirlemesine olanak tanır.

[AUTHCALL], ardından [yetkilendirilmiş] bir sözleşmenin mantığına erişmesine izin verir, erişmek istediği sözleşmenin zararsız olduğundan emin olmak için bir [çağırıcıyı] aracı olarak kullanır. Yani, her [AUTHCALL] için, [yetkilendirilmiş], [COMMIT] için belirli bir [çağırıcı] belirtmelidir.

Potansiyel Uygulanabilirlik/Kullanım Durumları

EIP 3074 primarily allows EOAs to delegate their authorization logic to a different account, however its open design enables a lot more in different contexts.

Bir EOA'nın tüm doğrulama mantığı, gerektiğinde çağıran üzerine çeşitli kısıtlamalar/yenilikler uygulanarak soyutlanabilir, hedef mantığa dayalı olası tasarımların bazıları şunları içerir:

• Nonce mantığı: EIP-3074, EOAnın [AUTH] mesajı gönderdikten sonra nonce'unun dokunulmamış kalmasına izin verirken, her [AUTHCALL] için etkileşimde bulunduğu çağırıcının ne olduğuna bağlı olarak nonce'unu belirler. Bu şekilde, EOAlar için nonce paralelliği sağlar, böylece istedikleri kadar birbirinin üzerine binmeyen [AUTHCALL] gönderebilirler.
• Gaz ödeme mantığı: Belirtilen gibiEIP'de, çağıranlar gaz sponsorluğuna izin vermek için tasarlanabilir. Bu nedenle, bir kullanıcının [COMMIT] işlemi için gaz ücretleri, işlemin kaynağından veya kişisel bir hesap veya hizmet tabanlı bir röle (gaz sponsorluğu hizmetleri) gibi herhangi bir destekleyici hesaptan düşülebilir.

Ayrıca, yürütme mantığı sezgisel olarak soyutlanır; sonuçta çağırıcı (ki bu bir CA'dır), EOA adına işlem isteklerini yürütmekten sorumludur.

Eleştiriler

• Invoker Merkezileştirme

Alıntı yapmaYazarlardan biri: "Cüzdanların keyfi yürütücülere imza atmalarını beklemem". 3074 girişiminin en büyük sorunu, üzerindeki yeniliklerin izinli ve mülkiyetli işlem akışlarına çok kolay bir şekilde yöneleceğidir; tam olarak Ethereum'un MEV ve PBS pazarlarının mevcut sürümleri gibi.

Varsayılan olarak, çağıran sözleşmelerin daha kötü saldırıları önlemek için büyük ölçüde denetlenmesi gerekmektedir. Bu, sonuçta, yalnızca etkili figürler tarafından geliştirilen bir avuç çağıran sözleşmenin cüzdan geliştiricileri için varsayılan olarak kabul edildiği bir ekosisteme yol açacaktır. Dolayısıyla, sürekli olarak çağıran sözleşmeleri denetlemeyi ve desteklemeyi gerektiren sert merkezi olmayan yol ile kullanıcı güvenliği riskini almanın bir denge noktasına gelir; veya sadece kullanıcı güvenliği için daha iyi garanti sağlayan ve sözleşmenin güvenliği konusunda daha az denetim içeren kurumsal ve saygın kaynaklardan çağıran sözleşmeleri benimsemek.

Bu noktanın başka bir yönü, işlevsel ve güvenli bir çağırıcı tasarlamak, denetlemek ve pazarlamakla ilişkili maliyet fonksiyonudur. Daha küçük ekipler genellikle daha büyük kuruluşlar tarafından geride bırakılır -özellikle pazarlama önünde- zaten bazı yerleşik bir itibara sahip olsalar bile, ürünleri daha iyi olsa bile.

• İleri Uyumluluk Sorunları

EIP-3074, ECDSA imza şemasını sağlamlaştırır, çünkü yine de çağırıcı aracılığıyla tanıtılan yetkilendirme şemasından daha geçerli kabul edilir. Kuantum direncinin şu anda kesin bir sorun olmadığı ve ECDSA'nın bozulabilir olduğu bir gelecekte çok daha kötüsünün söz konusu olduğu yönünde tartışmalar olsa da; Ethereum'un biraz belirtilmeyen amacı, bu tür sorunların her zaman önünde olmaktır. UX'teki marjinal iyileştirmeler için potansiyel olarak kuantum ve sansür direncinden ödün vermek, yakın gelecekte en iyi seçenek olmayabilir.

İleri uyumluluk argümanının başka bir noktası, 3074'ün faydaları henüz değerlendirilirken, herhangi bir protokol değişikliği gerektirmeyen ERC-4337'nin büyük bir pazarı olduğudur, bu yüzden ekosistemlerin bölünmesini önlemek için onunla da uyumlu olmanız gerekmektedir.

Yerel hesap soyutlama yol haritasıyla bile, [AUTH] ve [AUTHCALL] işlev kodları sonunda EVM'de eskimiş hale gelecek, kullanıcı deneyimi iyileştirmesi için Ethereum'a büyük miktarda teknik borç yükleyecekler.

• ECDSA Şeması Geri Alınamazlık

Bir [AUTH] mesajı gönderdikten ve kontrolü devrettiğinizde, EOA'nın genellikle özel anahtar yetkilendirme şemasından kaçınması beklenir, çünkü bir "normal" işlem göndermek, devrettiği yetkilendirmeyi her çağırana iptal ettirir.

Bu nedenle, ECDSA şeması, ilişkili sözleşmelerin etkinleştirebileceği diğer herhangi bir yetkilendirme şemasına kesinlikle üstündür, bu da özel anahtarların kaybının hesabın varlıklarının tam bir kaybına yol açacağı anlamına gelir.

EIP-7702 üzerinden programlanabilirlik

Bu öneri başlangıçta EIP 3074'ün oldukça minimalistik bir varyasyonu olarak ortaya çıkmıştı vebile bileEIP 3074'e olan uyumsuzluğu ve zaten gelişmekte olan 4337 ekosistemine ve yerli hesap soyutlama önerisine yönelik endişeleri özellikle ele almak için doğmuş olan bir güncelleme olması bekleniyor.

Yaklaşımı, bir EOA'nın belirli işlemler için akıllı bir hesap gibi davranmasına izin veren yeni bir EIP 2718 uyumlu işlem türü olan –[SET_CODE_TX_TYPE]–'nin eklenmesidir.

Bu tasarım, yerel hesap soyutlama yol haritası ve mevcut girişimlerle uyumlu kalırken, EIP 5806 ile aynı özellikleri ve daha fazlasını mümkün kılar.

Özellikler

EIP-7702, bir EOA'nın bir sözleşmenin kod içeriğini [SET_CODE_TX_TYPE] 2718 uyumlu bir işlem aracılığıyla “ithal etmesine” olanak tanır:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Bu yük, EIP 5806'nın tamamen benzeridir, tek farkı bir “yetkilendirme listesi” tanıtmasıdır. Bu liste, format değerlerinin sıralı bir dizisidir:

[[chain_id, adres, nonce, y_parity, r, s], …]

burada her demet [address]' değerini tanımlar.

Devam etmeden önce, SET_CODE_TX_TYPE içinde yer alan taraflar:

• [authority]: EOA/temel imzalama hesabı
• [adres]: delegasyon yapılabilir kod içeren bir hesabın adresidir.

[Yetkilinin], [adresi] belirten bir SET_CODE_TX_TYPE imzaladığında, bir delege belirleyici oluşturulur. Bu, [yetkilinin] herhangi bir anki eylemlerinden kaynaklanan tüm kod alımı taleplerinin [adres]’in gözlemlenebilir koduna yönlendirilmesine neden olan bir “işaretçi programı”dır.

Her [chain_id, adres, nonce, y_parity, r, s] tanımlama grubu için, 7702 türü bir işlemin mantık akışı aşağıdaki gibidir:

1. [yetki]’s imzasının sağlanan hash'ten doğrulanması: yetki = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s)
2. Çapraz zincir tekrar saldırılarının önlenmesi ve diğer saldırı vektörleri zincirin kimliğinin doğrulanmasıyla.
3. [authority]'nin zaten kod içeriğine sahip olup olmadığı kontrol ediliyor.
4. Otoritenin nonce'unun demetteki nonce ile eşit olduğundan emin olmak için nonce kontrolü.
5. Eğer işlem [yetkilinin] ilk SET_CODE_TX_TYPE işlemi ise, PER_EMPTY_ACCOUNT_COST ücreti alınır. Bu ücretin değerinden daha az bakiyesi varsa, işlem iptal edilir.
6. Vekillik ataması gerçekleşir, burada [yetki] kodu bir [adres] işaretçisine ayarlanır.
7. İmzalayanın nonce değeri -[authority]- bir artırılır.
8. [yetki], erişilen adresler listesine eklenir, bu (basitleştirilmiş olarak), bunlar (adres) geri alınmış kapsamdan önceki durumlarına geri dönmelerine neden olan bir işlemin kapsamının geri alınması durumunda oluşturulan adresler kümesidir. Bu, şu şekilde tanımlanmıştır: EIP-2929tekrar kullanılabilir değerlerin önbelleğe alınmasını ve gereksiz ücretlerin önlenmesini sağlamak için.

Puh! Her şeyi bağlamak için; bu EIP, EOAs'ın bir sözleşmenin koduna bir işaretçi ayarlayarak, bu mantığı sonraki işlemlerinde kendi mantıkları olarak uygulamalarına izin verir. Bu şekilde, EIP 5806'dan daha kesin bir şekilde daha güçlüdür, çünkü EOAs'ın istedikleri sürece kod içeriğine sahip olmalarına izin verir (EIP 5806'nın sadece delegasyon çağrıları yapmalarına izin vermesi yerine).

Potansiyel Uygulanabilirlik/Kullanım Durumları

• Yürütme Soyutlama

EOA aktif olarak yürütmek istediği mantığı içerdiğinden artık bir soyutlama olmadığı tartışılabilir, ancak yine de söz konusu mantığın 'asıl sahibi' değildir. Ayrıca doğrudan mantık içermez, sadece hesaplama karmaşıklığını azaltmak için mantığa işaret eder. Bu nedenle, yürütme soyutlaması ile devam ediyoruz!

• Gaz Sponsorluğu

require(msg.sender == tx.origin) değişmezi kendi kendine sponsorluğa izin verecek şekilde bozulurken, EIP sponsorlu işlem sağlayıcılarının entegrasyonlarına izin vermeye devam eder. Bununla birlikte, uyarı, bu tür aktarıcıların yas tutma saldırılarını önlemek için itibar veya hisseye dayalı bir sisteme ihtiyaç duymasıdır.

• Koşullu Erişim Politikaları

EOA'lar yalnızca hesabın kodunun belirli bir bölümüne işaret edebilir, böylece yalnızca o bölümün mantığı bağlamlarında yürütülebilir.

Bu aynı zamanda "ayrıcalık yükseltmeyi" etkinleştirmeye devam eden alt anahtarların varlığını da sağlar, böylece belirli dAPP'ler yalnızca belirli koşullar altında bir hesabın bakiyesine erişebilir. Örneğin, ERC-20 tokenlerini harcamak için bir izin hayal edebilirsiniz, ancak ETH değil, günlük toplam bakiyenin %1'ine kadar harcama veya yalnızca belirli bir uygulamayla etkileşim kurma izni.

• Çapraz Zincir Akıllı Sözleşme Dağıtımı

Kısıtlamayan doğası nedeniyle, bir EIP-7702 işlemi, bir kullanıcının CREATE2 opcode'una erişmesine ve bu opcode'u kullanarak başka kısıtlayıcı parametreler olmaksızın (örneğin EIP-1559 ve EIP-4844 gibi) bir adrese bytecode dağıtmasına izin verebilir. Bu, adresin aynı bytecode ile birden fazla durum makinesi üzerinde kurtarılmasına ve kullanılmasına olanak tanır, ardından her bir zincirdeki hesabı, diğer bağlam değişken parametrelerini tanımlamaktan sorumlu olur.

Eleştiriler

• Geriye dönük uyumluluk eksikliği

EIP-7702 henüz çok yeni olmasına rağmen, bağımlılıkları ve potansiyel dezavantajları için çok sayıda prototip ve test yapılmıştır, ancak minimalist modeli ona farklı bağlamlarda birçok esneklik ve dolayısıyla kullanışlılık sağlar. Bununla birlikte, çok sayıda önceden belirlenmiş durumu bozar ve hemen geriye dönük uyumluluk sağlamaz.

Mantığından bazıları şunları içerir:

1. Orta işlem EOA nonce değişikliği: EIP-7702, tutarlılığı sağlamak için herhangi bir opcode'yi sınırlamaz. Bu, bir EOA'nın EIP-7702 işlemi gerçekleştirirken CREATE, CREATE2 ve SSTORE gibi opcode'leri uygulayabileceği anlamına gelir, bu da nonce'unun farklı bir bağlamda artırılmasına izin verir.
2. EIP-3607, EOAs ve CAs arasında bir "adres çakışması" potansiyel sonuçlarını azaltmak amacıyla uygulandı, bir hesabın 'codeHash' değerinin sıfır olmayan hesap öncüleri olmasına izin vermek: Bir adres çakışması, bir EOA adresinin 160-bit değerinin bir CA adresinin tamamen eşit olması durumunda meydana gelir.

Çoğu kullanıcı bir hesabın gerçek içeriğine (veya hatta bir hesap ile adres arasındaki farka) aşina değildir, bu yüzden adres çakışmalarına izin vermek, bir EOA'nın bir CA gibi kılık değiştirerek kullanıcı fonlarını uzun bir süre boyunca çekmesine ve sonunda hepsini çalmasına olanak tanır. EIP-3607, kod içeren hesapların kendi yetkilendirme mantığını kullanarak bakiyelerini harcamamasını stipüle ederek bunu ele almıştır. Ancak, EIP 7702, EOAların bazı programlanabilirlik kazandıktan sonra bile bağımsız kalmasını sağlamak için bu değişmezliği bozar.

• EIP-3074'ye benzerlik

Hesap kod içeriğinin yerine hesabın adresinin imzalanması, temel olarak 3074 şeması ile etkileyicilerle aynıdır. Farklı zincirlerde bir adresin farklı kod içeriği alabileceği için, çapraz zincir kod içeriği tutarlılığı konusunda kesin garanti sağlamaz. Bu, kod içeriği aynı mantığı içeren bir adresin başka bir zincirde yırtıcı veya açıkça kötü niyetli olabileceği anlamına gelir ve bu da kullanıcı fonlarının kaybına neden olabilir.

Sonuç

Mevcut şekliyle EOAs, EVM tarafından sunulan programlama özelliklerinden yararlanma imkanı vermediğinden büyük ölçüde sınırlıdır. Hesapların yükseltilmesi için çeşitli yöntemler olsa da, bu raporun başında belirttiğimiz gibi, seçilen çözüm güvenli ve güvenli öz-korunma prensiplerini korumalıdır. Ayrıca, EOA yükseltmeleri, kullanıcı deneyimini ve uygulama geliştiricilerini önemli ölçüde etkileyebileceğinden, tüm paydaşların sesi dikkate alınmalıdır.

EOA'ların kodu herhangi bir şekilde yürütmesine izin vermek, hesapların işlevselliğini çok büyük ölçüde artırır, ancak bu yeni ifade yeteneği anlamlı riskler ve olası beklenmedik durumlarla birlikte gelir. Bu takasları çözmek, Ethereum kullanıcıları için tartışmasız UX faydaları sunan bir yükseltmeyi sağlamak için önemlidir.

Ethereum'ın açık tartışma kültürü, hemen hemen her tasarımın her etkisinin konu uzmanları tarafından detaylı bir şekilde ele alındığı için bu tür yenilikler için harika bir test alanı haline getiriyor. Bu kapsamlı düşünce, düşmanlardan kötü niyetli eylemlerin risklerini azaltmaya yardımcı olmalıdır.

EIP-7702 şu anda EVM programlanabilirliğini EOAlara getirmeyi amaçlayan mekanizmaların gözdesidir, Pectra yükseltmesinde EIP 3074'ün yerini alması için işaretlendi. 3074'ün mekanizmasının açık tasarımını miras alırken saldırı yüzeyini / risklerini büyük ölçüde azaltır. Ayrıca, belirli opcode sınıflarına 3074'ün kısıtlamalarını önleyerek çok daha fazlasını olanaklı hale getirir.

Önerinin tasarımı üzerinde hala bazı iyileştirmeler yapılıyor olsa da, özellikle doğrudan Vitalik tarafından desteklenmesi nedeniyle, geliştiricilerden çok sayıda iyi niyet ve destek topladı.

Topluluk içinde, hesap soyutlama yaklaşımının bu, akıllı hesaplardan bile daha iyi olabileceği iddiaları bulunmaktadır. Bu yorum, bu yolun daha az değişiklik gerektirdiğini ve karmaşık olmadığını vurgulamaktadır ve EOAs'ın zaten yerleştirildiğini belirtmektedir. Bununla birlikte, Ethereum ağının her seviyesinde gelecekteki güvenlik kilometre taşı olan kuantum direncini hatırlamalıyız. Bu kuantum güvenliği, EOA yetkilendirmesi için ECDSA tabanlı imza şemalarının kullanılmasından dolayı mevcut hesap modeli çekirdeği ile gerçekleştirilemez.

Bu nedenle, EOA programlanabilirliği, akıllı hesapların bir adımı olarak görülmeli ve hedef değil. Bu, EOA'ları süper hale getirir ve daha iyi kullanıcı ve geliştirici deneyimi sağlarken, akıllı hesapların nihai hesap soyutlama hedefiyle uyumlu kalır.

Bir sonraki raporumuzda, hesap soyutlama yol haritasına ne kadar uyduklarını görmek için EOA göç planlarına derinlemesine dalacağız, takipte kalın!

Dikkat:

1. Bu makale [den yeniden basılmıştır2077.xyz], Tüm telif hakları orijinal yazarına aittir [zhev]. Bu yeniden basım hakkında itirazlar varsa, lütfen iletişime geçin. Gate Learnekip ve onlar derhal bununla ilgilenecek.
2. Sorumluluk Reddi: Bu makalede yer alan görüş ve düşünceler yalnızca yazarın görüşlerini yansıtmaktadır ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri, gate Learn ekibi tarafından yapılır. Belirtilmedikçe, çevrilen makalelerin kopyalanması, dağıtılması veya kopyalanması yasaktır.