O zamanlar "Ethereum 2.0" olarak bilinen şeyin erken tarihinde, mümkün olduğunca az şeyle kendi başına inşa etmeye çalışan ve bu tür işlerin neredeyse tamamını kullanıcılara bırakan temiz, basit ve estetik açıdan hoş bir protokol oluşturmak için güçlü bir istek vardı. İdeal olarak, protokol yalnızca bir sanal makinedir ve bir öbeğin doğrulanması yalnızca bir sanal makine çağrısıdır.
"Durum geçiş işlevi" (öbeği işleyen işlev) yalnızca tek bir VM çağrısı olacaktır ve diğer tüm mantık sözleşme aracılığıyla gerçekleşecektir: bazı sistem düzeyinde sözleşmeler, ancak çoğunlukla kullanıcı tarafından sağlanan sözleşmeler. Bu modelin çok iyi bir özelliği, tüm bir hard fork'un bile, zincir dışı veya zincir içi yönetişim tarafından onaylanacak ve daha sonra yükseltilmiş ayrıcalıklarla çalışacak bir blok işlemci sözleşmesi için tek bir işlem olarak tanımlanabilmesidir.
2015'teki bu tartışmalar özellikle ele aldığımız iki alan için geçerlidir: hesap soyutlama ve ölçeklendirme. Ölçeklendirme söz konusu olduğunda, fikir, yukarıdaki grafiğin doğal bir uzantısı gibi hissettiren maksimum bir soyutlama ölçeklendirme biçimi oluşturmaya çalışmaktır. Sözleşmeler, çoğu Ethereum düğümü tarafından depolanmayan verileri çağırabilir ve protokol bunu algılar ve çağrıyı bir tür çok genel genişletilmiş bilgi işlem işleviyle çözer. Sanal makinenin bakış açısından, çağrı ayrı bir alt sisteme gider ve bir süre sonra sihirli bir şekilde doğru yanıtı döndürür.
Bu düşünce tarzını kısaca araştırdık, ancak her türlü blok zinciri ölçeklendirmesinin mümkün olduğunu doğrulamaya çok fazla odaklandığımız için çabucak pes ettik. Daha sonra görecek olsak da, veri kullanılabilirliği örneklemesi ve ZK-EVM'nin birleşimi, Ethereum ölçeklendirmesi için olası bir geleceğin aslında bu vizyona çok yakın göründüğü anlamına geliyor! Öte yandan, hesap soyutlaması için, en başından beri bir tür uygulamanın mümkün olduğunu biliyorduk, bu nedenle araştırma hemen "ticaret sadece bir çağrıdır" saf başlangıç noktasına mümkün olduğunca yakın bir şeyi gerçeğe dönüştürmeye çalışmaya başladı.
İşlemin gerçekleştirilmesi ile gönderen adresinden gerçek temel EVM çağrısının yapılması arasında, çok sayıda ortak kod ve bundan sonra daha fazla ortak kod vardır. Bu kodu mümkün olduğunca sıfıra nasıl yaklaştırırız?
Buradaki ana kodlardan biri, işlemin doğru nonce ve imzaya sahip olup olmadığını kontrol etmekten sorumlu olan validate_transaction(state, tx)'dir. En başından beri, hesap soyutlamanın pratik amacı, kullanıcıların sosyal kurtarma ve çoklu imza cüzdanları gibi özellikleri daha kolay kullanabilmeleri için temel artımsız ve ECDSA doğrulamasını kendi doğrulama mantıklarıyla değiştirmelerine izin vermekti. Bu nedenle, apply_transaction'ı basit bir EVM çağrısı olarak yeniden tasarlamanın bir yolunu bulmak, yalnızca "kodu temiz hale getirmek uğruna temiz kod" görevi değildir; Bunun yerine, mantığı kullanıcının hesap koduna taşımak ve kullanıcıya ihtiyaç duyduğu esnekliği sağlamakla ilgilidir.
Bununla birlikte, uygula_transaction mümkün olduğunca az sabit mantık içermesi konusunda ısrar etmek, birçok zorluk yaratır. En eski hesap soyutlama önerilerinden biri olan EIP-86'ya bir göz atabiliriz.
EIP-86 olduğu gibi dahil edilirse, Ethereum yığınının diğer bölümlerinin karmaşıklığını büyük ölçüde artırma pahasına EVM'nin karmaşıklığını azaltacak ve aynı hash numarasına sahip aynı işlemin zincirde birden çok kez görünebilmesi gibi tamamen yeni garip kategorilerin getirilmesi dışında, esasen aynı kodun başka bir yere yazılmasını gerektirecektir.
Hesap soyutlamada birden çok geçersiz kılma sorunu. Zincir üzerinde yer alan bir işlem, mempool'daki diğer binlerce işlemi geçersiz kılabilir, bu da mempool'un ucuza taşmasını kolaylaştırır.
O zamandan beri, hesap soyutlaması aşamalar halinde gelişti. EIP-86 daha sonra EIP-208 ve sonunda pratik EIP-2938 oldu.
Bununla birlikte, EIP-2938 minimalist olmaktan başka bir şey değildir. İçeriği şunları içerir:
· Yeni işlem türleri
· Üç yeni ticaret kapsamı için global değişkenler
· Gaz fiyatı ve gaz limiti kontrollerini işlemek, EVM olarak kesme noktaları gerçekleştirmek ve ETH'yi tek seferlik bir ücret karşılığında geçici olarak depolamak için çok hantal PAYgas işlem kodu dahil olmak üzere iki yeni işlem kodu
· İşlem doğrulama aşamasında yasaklanmış işlem kodlarının bir listesi de dahil olmak üzere karmaşık bir dizi madencilik ve yeniden yayınlama stratejisi
Ethereum çekirdek geliştiricilerini (Ethereum istemcilerini optimize etmeye ve birleştirmeyi uygulamaya odaklanan) dahil etmeden hesap soyutlamasını uygulamak için, EIP-2938 sonunda tamamen protokol dışı ERC-4337 olarak yeniden tasarlandı.
Bu bir ERC olduğu için hard fork gerektirmez ve teknik olarak "Ethereum protokolünün dışında" bulunur. Öyle...... Sorun çözüldü mü? Durumun böyle olmadığı ortaya çıktı. ERC-4337'nin mevcut orta vadeli yol haritası, ERC-4337'nin çoğunu bir dizi protokol özelliğine dönüştürmeyi içeriyor ve bu, bu yolun neden düşünülmesi gerektiğine dair yararlı bir yol gösterici örnek.
Paket ERC-4337
ERC-4337'yi protokole geri getirmek için tartışılan birkaç temel neden var:
Gaz verimliliği: EVM içinde yapılan herhangi bir işlem, depolama yuvaları gibi gaz açısından pahalı özellikler kullanılırken verimsizlikler de dahil olmak üzere bir miktar sanal makine yüküne neden olur. Şu anda, bu ek verimsizlikler en az 20.000 gaz veya daha fazlasına tekabül ediyor. Bu bileşenleri bir protokole koymak, bu sorunları ortadan kaldırmanın en kolay yoludur.
Kod hatası riski: ERC-4337 "giriş noktası sözleşmesinde" yeterince korkutucu bir hata varsa, tüm ERC-4337 uyumlu cüzdanlar tüm fonlarının kuruduğunu görebilir. Sözleşmeleri protokol içi işlevsellikle değiştirmek, hard fork'lar yoluyla kod hatalarını düzeltmek için örtük bir yükümlülük oluşturur ve böylece kullanıcıların fonlarının kuruma riskini ortadan kaldırır.
txt.origin gibi EVM işlem kodları için destek. ERC-4337'nin kendisi, txt.origin'in bir dizi kullanıcı eylemini bir işlemde paketleyen bir "paketleyicinin" adresini döndürmesine neden olur. Yerel hesap soyutlaması, txt.origin'in işlemi gönderen gerçek hesaba işaret etmesini sağlayarak bu sorunu çözer ve EOA ile aynı şekilde çalışmasını sağlar.
Sansüre dayanıklı: Teklif veren/oluşturucu ayrımının zorluklarından biri, bireysel işlemleri gözden geçirmenin daha kolay hale gelmesidir. Bu sorun, Ethereum protokolünün tek bir işlemi tanıyabildiği, teklif sahibinin hemen hemen her durumda sonraki iki yuvaya dahil edilmesi gereken işlemlerin bir listesini belirlemesine izin verdiği bir dünyada büyük ölçüde hafifletilebilir. Bununla birlikte, protokolün dışındaki ERC-4337, "kullanıcı işlemlerini" tek bir işlemde kapsülleyerek kullanıcı işlemlerini Ethereum protokolüne opak hale getirir; Bu nedenle, Ethereum protokolü tarafından sağlanan dahil etme listesi, ERC-4337 kullanıcı işlemlerine sansür direnci sağlayamayacaktır. ERC-4337'yi kapsüllemek ve kullanıcı eylemini "uygun" bir işlem türü haline getirmek bu sorunu çözecektir.
Mevcut haliyle, ERC-4337'nin "temel" bir Ethereum işleminden çok daha pahalı olduğunu belirtmekte fayda var: işlem maliyeti 21.000 gaz, ERC-4337 ise yaklaşık 42.000 gaza mal oluyor.
Teorik olarak, EVM gaz maliyet sistemini, anlaşma içi maliyet ve depolamaya protokol dışı erişim maliyeti eşleşene kadar ayarlamak mümkün olmalıdır; Diğer depolama düzenleme işlemleri daha ucuz olduğunda, ETH'yi 9000 gazdan transfer etmek için hiçbir neden yoktur. Aslında, yaklaşmakta olan Verkle ağacı dönüşümüyle ilgili iki EIP aslında tam da bunu yapmaya çalışıyor. Ancak bunu yapsak bile, EVM ne kadar verimli olursa olsun, kapsüllenmiş protokol işlevselliğinin kaçınılmaz olarak EVM kodundan çok daha ucuz olmasının bariz bir nedeni vardır: kapsüllenmiş kodun ön yükleme için gaz ödemesine gerek yoktur.
Tamamen işlevsel ERC-4337 cüzdanı büyüktür ve onu derleyen ve zincire koyan uygulama yaklaşık 12.800 bayt alır. Elbette, bu kodu bir kez dağıtabilir ve her bir cüzdanın onu aramasına izin vermek için DELEGATECALL'u kullanabilirsiniz, ancak yine de onu kullanan her bloktaki koda erişmeniz gerekir. Verkle ağacı gaz maliyeti EIP'ye göre, 12.800 bayt 413 parça oluşturacaktır ve bu parçalara erişmek, tanık dalının 2 katını (toplam 3.800 gaz) _cost ve tanık yığınının 413 katını (toplam 82.600 gaz) ödemeyi gerektirecektir_cost. Ve bu, 0.6.0 sürümünde zincirde 23.689 bayt (Verkle ağacı EIP kurallarına göre yüklenecek yaklaşık 158.700 gaz) olan ERC-4337 giriş noktasının kendisinden bahsetmeye bile başlamıyor.
Bu, soruna yol açar: Bu kodlara gerçekten erişmenin gaz maliyeti, işlem boyunca bir şekilde amorti edilmelidir. ERC-4337 tarafından kullanılan mevcut yaklaşım çok iyi değil: paketteki ilk işlem tek seferlik bir depolama/kod okuma maliyeti tüketiyor ve bu da onu diğer işlemlerden çok daha pahalı hale getiriyor. Protokol içi kapsülleme, bu genel paylaşılan kitaplıkların protokolün bir parçası olmasına ve herkes tarafından ücretsiz olarak erişilebilir olmasına olanak tanır.
Bu örnekten ne öğrenebiliriz ve ambalaj ne zaman daha yaygın olacak? **
Bu örnekte, protokolde hesap soyutlama yönünü kapsüllemek için bazı farklı gerekçeler görüyoruz.
"Karmaşıklığı uç noktaya iten" pazar temelli yaklaşımlar, sabit maliyetler yüksek olduğunda büyük olasılıkla başarısız olur. Aslında, uzun vadeli hesap soyutlama yol haritası, her bloğun çok fazla sabit maliyeti var gibi görünüyor. Standartlaştırılmış cüzdan kodlarını yüklemek için 244, 100 gaz bir şeydir; Ancak toplama, ZK-SNARK doğrulamasına yüz binlerce gazın yanı sıra zincir kanıtı doğrulamasının zincir üstü maliyetini de ekleyebilir. Çok fazla piyasa verimsizliği getirmeden kullanıcılardan bu maliyetler için ücret almanın bir yolu yoktur ve bu özelliklerden bazılarını herkesin ücretsiz olarak erişebileceği protokol özelliklerine dönüştürmek bu sorunu iyi bir şekilde çözer.
Kod hatalarına topluluk çapında yanıtlar. Bazı kod parçacıkları tüm kullanıcılar veya çok geniş bir kullanıcı kitlesi tarafından kullanılıyorsa, ortaya çıkan hataları düzeltmek için blok zinciri topluluğunun bir hard fork'un sorumluluğunu üstlenmesi genellikle daha mantıklıdır. ERC-4337, büyük miktarda küresel olarak paylaşılan kodu tanıtır ve bir hard fork yoluyla koddaki hataları düzeltmek, uzun vadede kullanıcıların çok fazla ETH kaybetmesine neden olmaktan şüphesiz daha mantıklıdır.
Bazen, protokolün işlevselliğinden doğrudan yararlanarak daha güçlü bir form elde edilebilir. Buradaki anahtar örnek, dahil etme listesi gibi protokol içi sansür önleme özelliğidir: protokol içindeki dahil etme listesi, protokol dışındaki yöntemden daha iyi sansür direncini garanti edebilir ve kullanıcı düzeyindeki işlemlerin protokol içindeki dahil etme listesinden gerçekten yararlanabilmesi için, tek bir kullanıcı düzeyindeki işlemin protokol tarafından "okunabilir" olması gerekir. Daha az bilinen bir başka örnek, BLS'nin protokol ve ağ düzeyinde uygulanması gereken bir "toplama" mekanizmasını desteklediğinden, BLS'yi kapsüllemek lehine terk edilen stake anahtar hesabını soyutlayan 2017 dönemi Ethereum proof-of-stake tasarımıdır, bu da çok sayıda imzanın işlenmesini daha verimli hale getirebilir.
Ancak, protokol içi hesap soyutlamasının kapsüllenmesinin bile mevcut duruma kıyasla hala büyük bir "kapsülleme" olduğunu hatırlamak önemlidir. Bugün, üst düzey Ethereum işlemleri yalnızca tek bir secp 256k1 eliptik eğri imzası ile doğrulanan harici olarak sahip olunan hesaplardan (EOA'lar) başlatılabilir. Hesap soyutlaması bunu ortadan kaldırır ve doğrulama kriterlerini tanımlamayı kullanıcıya bırakır. Bu nedenle, hesap soyutlamayla ilgili bu hikayede, kapsüllemeye karşı en büyük argümanı da görüyoruz: farklı kullanıcıların ihtiyaçlarını karşılama esnekliği.
Son zamanlarda kapsüllenmiş olarak kabul edilen diğer birkaç özellik örneğine bakarak bu hikayeyi daha da detaylandıralım. Şunlara özellikle dikkat edeceğiz: ZK-EVM, teklif veren-oluşturucu ayrımı, özel mempool'lar, likidite stake etme ve yeni ön derleme.
ZK-EVM Paketi
Dikkatimizi Ethereum protokolünün başka bir potansiyel kapsülleme hedefine çevirelim: ZK-EVM. Şu anda, ZK-SNARK'ta benzer Ethereum bloklarının yürütülmesini doğrulamak için oldukça benzer kod yazmak zorunda olan çok sayıda ZK toplamamız var. Oldukça çeşitli bağımsız uygulamalar ekosistemi vardır: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth ve çok daha fazlası.
EVM ZK-rollup alanındaki son bir tartışma, ZK kodundaki olası hataların nasıl ele alınacağıyla ilgilidir. Şu anda, çalışan tüm bu sistemler, hata durumunda kanıtlama sistemini kontrol eden bir tür "Güvenlik Konseyi" mekanizmasına sahiptir. Geçen yıl, projeleri sertifikasyon sistemine ve Güvenlik Konseyi'ne olan güven düzeylerini netleştirmeye ve zaman içinde kuruluş üzerindeki yetkilerini kademeli olarak azaltmaya teşvik etmek için standart bir çerçeve oluşturmaya çalıştım.
Orta vadede, toplamalar birden fazla kanıtlama sistemine dayanabilir ve Güvenlik Konseyi yalnızca iki farklı kanıtlama sisteminin birbirinden ayrıldığı aşırı durumlarda yetkiye sahip olacaktır.
Ancak, bazı işlerin gereksiz hissettirdiğine dair bir his var. Zaten Ethereum temel katmanına sahibiz, bir EVM'ye sahip ve uygulamadaki hataları ele almak için zaten çalışan bir mekanizmamız var: bir hata varsa, istemci bunu düzeltmek için güncelleyecek ve ardından zincir çalışmaya devam edecek. Buggy istemcisinin bakış açısından, kesinleşen bloklar artık onaylanmayacak gibi görünüyor, ancak en azından kullanıcıların para kaybettiğini görmeyeceğiz. Benzer şekilde, rollup'lar yalnızca EVM'ye eşdeğer rollerini sürdürmek istiyorlarsa, Ethereum temel katmanına yükseltmeleri eşleştirmek için dahili ZK-EVM kurallarını sürekli olarak değiştirmek için kendi yönetişimlerini uygulamaları gerekir, bu yanlış geliyor çünkü sonuçta ne zaman ve hangi yeni kurallara göre yükseltme yapacağını bilen Ethereum temel katmanının üzerine inşa edilmiştir.
Bu L2 ZK-EVM'ler temel olarak Ethereum ile tamamen aynı EVM'leri kullandığından, bir şekilde "EVM'nin ZK'da yürütülmesini doğrulamayı" protokol işlevine dahil edebilir ve temel katman EVM uygulamasının kendisinde yaptığımız gibi, Ethereum'un sosyal fikir birliğini uygulayarak hatalar ve yükseltmeler gibi istisnaları ele alabilir miyiz?
Bu önemli ve zorlu bir konudur.
Yerel ZK-EVM'de veri kullanılabilirliği hakkında olası bir tartışma konusu, durum bilgisidir. ZK-EVM'lerin "tanık" verileri taşıması gerekmeseydi, veri verimlilikleri çok daha yüksek olurdu. Yani, belirli bir veri parçası daha önceki bir blokta zaten okunmuş veya yazılmışsa, kanıtlayıcının ona erişimi olduğunu ve tekrar kullanılabilir hale getirmesi gerekmediğini varsayabiliriz. Bu sadece depolamayı ve kodu yeniden yüklememekle ilgili değil; Durum bilgisi olan sıkıştırmanın, bir toplama verileri doğru şekilde sıkıştırırsa, durum bilgisi olmayan sıkıştırmaya kıyasla 3 kata kadar veri tasarrufu sağlayabileceği ortaya çıktı.
Bu, ZK-EVM ön derlemesi için iki seçeneğimiz olduğu anlamına gelir:
Ön derleme, tüm verilerin aynı yığında bulunmasını gerektirir. Bu, kanıtlayıcının durum bilgisiz olabileceği anlamına gelir, ancak aynı zamanda bu önceden derlenmiş ZK toplamasını kullanmanın özel kodla toplamayı kullanmaktan çok daha pahalı olduğu anlamına gelir.
Ön derleme, işaretçinin daha önce yürütülen, kullanılan veya oluşturulan verileri göstermesini sağlar. Bu, ZK-rollup'ı neredeyse en uygun hale getirir, ancak daha karmaşıktır ve kanıtlayıcı tarafından saklanması gereken yeni bir durum sunar.
Bundan ne öğrenebiliriz? ZK-EVM doğrulamasını bir şekilde kapsüllemek için iyi bir neden var: rollup zaten kendi özel sürümünü oluşturuyor ve Ethereum, EVM'yi yürütmek için çoklu uygulamalarını ve zincir dışı sosyal fikir birliğini L1'e ağırlık vermeye istekli, ki bu yanlış geliyor, ancak L2'nin tam olarak aynı işi yapması, Güvenlik Konseyi'ni içeren karmaşık araçlar uygulamalıdır. Ancak öte yandan, ayrıntılarda büyük bir sorun var: ZK-EVM'nin maliyet ve fayda açısından farklılık gösteren farklı versiyonları var. Durumlu ve vatansız arasındaki ayrım yalnızca yüzeyi çizer; Diğer sistemler tarafından kanıtlanmış özel kodlar olan "neredeyse EVM"yi desteklemeye çalışmak, daha fazla tasarım alanı ortaya çıkarabilir. Bu nedenle ZK-EVM'nin kapsüllenmesi hem umut hem de zorluklar sunar.
Sarmalayıcı ve Oluşturucu Ayrımı (ePBS)
MEV'in yükselişi, blok üretimini büyük ölçekli bir ekonomik faaliyet haline getirdi ve karmaşık katılımcılar, işlemlerin mempool'unu gözlemleyen ve bunları içeren varsayılan algoritmadan daha fazla gelir sağlayan bloklar üretebildi. Şimdiye kadar, Ethereum topluluğu bu sorunu, düzenli doğrulayıcıların ("teklif verenler") blok yapımını uzman katılımcılara ("inşaatçılar") dış kaynak sağlamasına izin veren MEV-Boost gibi bir protokol dışı teklif veren-oluşturucu ayırma şeması kullanarak çözmeye çalıştı.
Bununla birlikte, MEV-Boost, röle adı verilen yeni bir katılımcı sınıfında güven varsayımlarında bulunur. Son iki yılda, "kapsüllenmiş PBS" oluşturmak için birçok teklif yapıldı. Bunun faydaları nelerdir? Bu durumda cevap basit: Doğrudan protokol özellikleriyle oluşturulan PBS, bunlar olmadan oluşturulan PBS'den daha güçlüdür (daha zayıf güven varsayımlarına sahip olma anlamında). Bu, kapsülleme protokolündeki fiyat kahinlerinde olduğu duruma benzer - ancak bu durumda da güçlü bir muhalefet vardır.
Özel Bellek Havuzunu Kapsülleme
Bir kullanıcı bir işlem gönderdiğinde, zincire dahil edilmeden önce bile hemen herkese açık ve herkes tarafından görülebilir. Bu, birçok uygulamanın kullanıcılarını önleyici işlemler gibi ekonomik saldırılara karşı savunmasız bırakır.
Son zamanlarda, kullanıcıların işlemlerini geri döndürülemez bir şekilde bir bloğa kabul edilene kadar şifreleyen "özel mempools" (veya "şifreli mempools") oluşturmaya adanmış bir dizi proje olmuştur.
Ancak sorun, bu tür şemaların özel bir şifreleme türü gerektirmesidir: kullanıcıların sisteme su basmasını ve önce şifresini çözmesini önlemek için, işlem gerçekten geri döndürülemez bir şekilde kabul edildikten sonra şifrelemenin şifresinin otomatik olarak çözülmesi gerekir.
Bu şifreleme biçimini elde etmek için çeşitli ödünleşim teknikleri vardır. Jon Charbonneau bir keresinde bunu çok iyi ifade etti:
Flashbots Protect gibi merkezi operatörleri şifreleyin.
belirli bir sıralı hesaplama adımından sonra herkes tarafından şifresi çözülebilen ve paralelleştirilemeyen zaman kilidi şifrelemesi;
Eşik şifrelemesi, verilerin şifresini çözmek için dürüst bir çoğunluk komitesine güvenmek. Özel öneriler için Kapalı İşaret Zinciri Konsepti'ne bakın.
SGX gibi güvenilir donanımlar.
Ne yazık ki, her şifrelemenin farklı zayıf yönleri vardır. Her çözüm için, ona güvenmeye istekli bir kullanıcı alt kümesi olsa da, çözümlerin hiçbiri Katman 1 tarafından gerçekten kabul edilecek kadar güvenilir değildir. Bu nedenle, en azından gecikme şifrelemesi mükemmelleştirilene veya başka bir teknolojik atılım yapılana kadar, birçok uygulama çözümünün ortaya çıktığı kadar değerli bir özellik olsa bile, Katman 1'de gelişmiş ticaret önleme işlevini kapsüllemek zor bir teklif gibi görünüyor.
Kapsüllenmiş likidite staking
Ethereum DeFi kullanıcıları için ortak bir ihtiyaç, ETH'lerini aynı anda stake etmek için ve diğer uygulamalarda teminat olarak kullanabilme yeteneğidir. Diğer bir yaygın ihtiyaç da kolaylık sağlamaktır: kullanıcılar, bir düğüm çalıştırmanın ve onu her zaman çevrimiçi tutmanın karmaşıklığı olmadan stake edebilmek (ve çevrimiçi stake anahtarlarını koruyabilmek) ister.
Şimdiye kadar, bu ihtiyaçların her ikisini de karşılayan en basit stake etme "arayüzü" sadece bir ERC 20 tokenidir: ETH'nizi "ETH stake etmeye" dönüştürün, tutun ve geri dönüştürün. Aslında, Lido ve Rocket Pool gibi likidite stake sağlayıcıları bunu yapmaya başladı bile. Bununla birlikte, likidite staking'in iş başında bazı doğal merkezileştirme mekanizmaları vardır: insanlar doğal olarak ETH'yi stake etmenin en büyük versiyonuna girerler çünkü bu en tanıdık ve likit olanıdır.
ETH stake etmenin her sürümü, temel düğüm operatörünün kim olabileceğini belirlemek için bir mekanizma gerektirir. Sınırsız olamaz, çünkü o zaman saldırganlar katılır ve kullanıcının fonlarıyla saldırıyı güçlendirir. Şu anda ilk ikisi, bir DAO beyaz liste düğüm operatörüne sahip olan Lido ve herkesin 8 ETH yatırılan bir düğüm çalıştırmasına izin veren Rocket Pool'dur. İki yöntemin farklı riskleri vardır: Roket Havuzu yaklaşımı, saldırganların ağ üzerinde %51 saldırı gerçekleştirmesine olanak tanır ve kullanıcıları maliyetin çoğunu ödemeye zorlar; DAO yaklaşımına gelince, belirli bir staking tokeni baskın hale gelirse, tüm Ethereum doğrulayıcılarının önemli bir bölümünü kontrol eden tek, potansiyel olarak saldırıya uğrayabilir bir yönetişim aracı ile sonuçlanır. Elbette, Lido gibi protokollerin zaten önlemleri vardır, ancak bir savunma katmanı yeterli olmayabilir.
Kısa vadede, bir seçenek, ekosistem katılımcılarını tek bir şirketten kaynaklanan sistemik risk olasılığını azaltmak için çok çeşitli likidite stake sağlayıcıları kullanmaya teşvik etmektir. Bununla birlikte, uzun vadede, bu istikrarsız bir dengedir ve sorunları çözmek için ahlaki baskıya çok fazla güvenmek tehlikelidir. Doğal bir soru ortaya çıkıyor: Likidite staking'i daha az merkezi hale getirmek için protokolde bir tür işlevselliği kapsüllemek mantıklı mı?
Buradaki kilit soru şudur: Ne tür bir protokol içi işlevsellik? Basitçe protokol içi değiştirilebilir bir "ETH stake etme" tokeni oluşturmanın sorunu, düğümleri kimin çalıştıracağını seçmek için ya kapsüllenmiş Ethereum çapında bir yönetişime sahip olması ya da açık olmasıdır, ancak bu onu saldırganlar için bir araca dönüştürür.
İlginç bir fikir, Dankrad Feist'in likidite stake maksimizasyonu hakkındaki makalesidir. İlk olarak, mermiyi ısıralım ve Ethereum'a %51 oranında saldırılırsa, saldırı ETH'sinin yalnızca %5'ine el konulabilir. Bu makul bir değiş tokuştur; Şu anda 26 milyondan fazla ETH stake edildiğinden, özellikle daha düşük bir maliyetle kaç tane "model dışı" saldırının yapılabileceği göz önüne alındığında, saldırı maliyetinin üçte biri (yaklaşık 8 milyon ETH) aşırıdır. Aslında, Süper Komisyon'un tek yuvalı kesinliği uygulama önerisinde de benzer ödünleşimler araştırılmıştır.
Saldırı ETH'sinin yalnızca %5'ine el konulduğunu kabul edersek, stake edilen ETH'nin %90'ından fazlası müsadereden etkilenmeyecektir, bu nedenle protokol içinde değiştirilebilir likidite stake tokenleri olarak kullanılabilir ve daha sonra diğer uygulamalar tarafından kullanılabilirler.
Yol ilginç. Ama yine de şu soruyu bırakıyor: tam olarak ne kapsüllenmiş? Rocket Pool çok benzer şekilde çalışır: her düğüm operatörü bir miktar fon sağlar ve likidite stake edenler geri kalanını sağlar. Maksimum cezayı 2 ETH ile sınırlamak için bazı sabitleri ayarlayabiliriz ve Rocket Pool'un mevcut rETH'si risksiz hale gelecektir.
Basit protokol ayarlamaları ile başka akıllı şeyler de yapabiliriz. Örneğin, diyelim ki iki stake "katmanı" olan bir sistem istiyoruz: düğüm operatörleri (yüksek teminat gereksinimleri) ve mevduat sahipleri (minimum teminat gereksinimleri yoktur ve istedikleri zaman katılabilir ve ayrılabilirler), ancak yine de dahil edilmesi gereken işlemlerin bir listesini önermek (sansüre dayanıklı nedenlerle), etkin olmayan sızıntılar sırasında çatal seçimini kontrol etmek veya blok imzalamayı zorunlu kılmak gibi rastgele örneklenmiş bir mevduat komitesi oluşturarak düğüm operatörlerinin merkezileşmesini önlemek istiyoruz. Bu, her doğrulayıcının (i) normal bir stake anahtarı ve (ii) ikincil bir stake anahtarı çıkarmak için her yuvada çağrılabilecek bir ETH adresi sağlamasını gerektirecek şekilde protokolü değiştirerek protokolden esasen ayrılacak şekilde başarılabilir. Protokol her iki anahtara da güç verecektir, ancak her yuvada ikinci anahtarı seçme mekanizması stake havuzu protokolüne bırakılabilir. Bazı özellikleri doğrudan kapsüllemek daha iyi olabilir, ancak bu "bazı şeyleri dahil et ve diğer her şeyi kullanıcıya bırak" tasarım alanının var olduğunu belirtmekte fayda var.
Daha fazla ön derleme kapsülleyin
Önceden derlenmiş (veya "önceden derlenmiş sözleşmeler"), mantığı EVM akıllı sözleşme kodu yerine istemci kodunda yerel olarak uygulanan karmaşık kriptografik işlemleri uygulayan Ethereum sözleşmeleridir. Ön kodlama, Ethereum geliştirmenin başlangıcında benimsenen bir uzlaşmaydı: bir sanal makinenin ek yükü çok karmaşık ve son derece uzmanlaşmış bir kod için çok büyük olduğundan, yerel kodda daha hızlı hale getirmek için önemli uygulamalar için değerli olan bazı önemli işlemleri uygulayabilirdik. Bugün, bu temel olarak bazı özel hash fonksiyonlarını ve eliptik eğri işlemlerini içerir.
Şu anda, temel Ethereum hesapları için secp 256 K1'den biraz farklı bir eliptik eğri olan secp 256 R1 için ön derleme eklemek için bir baskı var, çünkü güvenilir donanım modülleri tarafından iyi bir şekilde destekleniyor, bu nedenle yaygın kullanımı cüzdan güvenliğini artırabilir. Son yıllarda topluluk, BLS-12-377, BW 6-761, genelleştirilmiş eşleştirme ve diğer özellikler için ön derlemelerin eklenmesi için de baskı yaptı.
Daha önceden derlenmiş dosyalar için bu isteklerin karşı argümanı, daha önce eklenen ön derlemelerin çoğunun (örneğin RIPEMD ve BLAKE) beklenenden çok daha azını kullanması ve onlardan öğrenmemiz gerektiğidir. Belirli işlemler için daha fazla ön derleme eklemek yerine, belki de EVM uygulamalarının çok çeşitli kod sınıflarını daha düşük bir maliyetle yürütmesini sağlayacak EVM-MAX ve hareketsiz ancak her zaman kurtarılabilir SIMD önerileri gibi fikirlere dayalı daha yumuşak bir yaklaşıma odaklanmalıyız. Belki de nadiren kullanılan mevcut ön derleme bile kaldırılabilir ve aynı işlevin EVM kodunun (kaçınılmaz olarak daha az verimli) bir uygulamasıyla değiştirilebilir. Bununla birlikte, hızlandırmak için yeterince değerli olan belirli şifreleme işlemlerinin olması hala mümkündür, bu nedenle bunları önceden derlenmiş olarak eklemek mantıklıdır.
Bütün bunlardan ne öğrendik?
Mümkün olduğunca az kapsülleme arzusu anlaşılabilir ve iyidir; Unix'in, kullanıcıların farklı ihtiyaçlarına kolayca uyarlanabilen ve yazılım şişkinliğinin lanetinden kaçınabilen minimalist yazılım yaratma felsefi geleneğinden türemiştir. Bununla birlikte, blok zinciri kişisel bir bilgi işlem işletim sistemi değil, sosyal bir sistemdir. Bu, protokoldeki belirli işlevleri kapsüllemenin mantıklı olduğu anlamına gelir.
Çoğu durumda, bu diğer örnekler hesap soyutlamasında gördüğümüze benzer. Ama aynı zamanda bazı yeni dersler de öğrendik:
Kapsülleme, yığının başka bir yerinde merkezileştirme riskinden kaçınmaya yardımcı olabilir:
Çoğu zaman, temel protokolü minimum ve basit tutmak, karmaşıklığı ekosistemin bazı protokollerinin ötesine iter. Unix felsefi bakış açısından, bu iyidir. Bununla birlikte, bazen yüksek sabit maliyetler nedeniyle protokol dışı ekosistemlerin merkezileşme riski vardır. Kapsülleme bazen fiili merkezileşmeyi azaltabilir.
Çok fazla içerik kapsüllemek, protokol üzerindeki güven ve yönetişim yükünü aşırı genişletebilir:
Bu, "Ethereum konsensüsünü aşırı yüklemeyin" konulu önceki bir makalenin konusudur: belirli bir işlevi kapsüllemek güven modelini zayıflatırsa ve Ethereum'u bir bütün olarak daha "öznel" hale getirirse, Ethereum'un güvenilir tarafsızlığını zayıflatır. Bu durumlarda, belirli bir özelliği Ethereum'un üzerinde bir mekanizma olarak sunmak, onu Ethereum'un kendisine tanıtmaya çalışmaktan daha iyidir. Burada, şifrelenmiş bellek havuzları en iyi örnektir ve en azından gecikme şifrelemesi iyileşene kadar kapsüllenmesi biraz zor olabilir.
Çok fazla kapsülleme, protokolü aşırı karmaşık hale getirebilir:
Protokol karmaşıklığı, protokole çok fazla özellik eklenerek artırılabilen sistemik bir risktir. Ön derleme en iyi örnektir.
Uzun vadede, kullanıcı ihtiyaçları tahmin edilemez olduğu için kapsülleme işlevi geri tepebilir:
Birçok kişinin önemli bulduğu ve birçok kullanıcı tarafından kullanılacak bir özellik, muhtemelen pratikte düzenli olarak kullanılmıyor.
Ek olarak, likidite staking, ZK-EVM ve önceden derlenmiş vakalar bir orta yol olasılığını göstermektedir: minimum uygulanabilir koruma. Protokollerin tüm işlevi kapsüllemesi gerekmez, ancak temel zorlukları ele alan belirli parçalar içerebilir, bu da işlevin çok paranoyak veya çok dar olmadan uygulanmasını kolaylaştırır. Buna örnek olarak şunlar verilebilir:
Tam bir likidite rehin sistemini kapsüllemek yerine, güvene dayalı olmayan likidite rehinini daha uygulanabilir hale getirmek için stake cezası kurallarını değiştirmek daha iyidir;
Daha fazla ön derleyiciyi kapsüllemek yerine, daha geniş bir çalışma kategorisi yelpazesi için verimli bir şekilde uygulamayı kolaylaştırmak için EVM-MAX ve/veya SIMD'yi kapsülleyin;
EVM doğrulaması, tüm toplama kavramını kapsüllemek yerine basitçe kapsüllenebilir.
Önceki grafiği aşağıdaki gibi genişletebiliriz:
Bazen bir şeyi sarmak mantıklıdır ve nadiren kullanılan ön derlemeyi kaldırmak buna bir örnektir. Daha önce de belirtildiği gibi, bir bütün olarak hesap soyutlaması da önemli bir kapsülleme biçimidir. Mevcut kullanıcılar için geriye dönük uyumluluğu desteklemek istiyorsak, mekanizma aslında önceden derlenmiş kapsüllemeye çarpıcı bir şekilde benzeyebilir: tekliflerden biri, EOA'nın hesaplarını aynı (veya daha iyi) işlevselliğe sahip sözleşmelere dönüştürmesine izin verecek olan EIP-5003'tür.
Hangi özelliklerin protokole dahil edilmesi ve hangilerinin ekosistemin diğer katmanlarına bırakılması gerektiği karmaşık bir değiş tokuştur. Kullanıcı ihtiyaçlarını, mevcut fikirleri ve teknoloji paketlerini anlamamız gelişmeye devam ettikçe bu değiş tokuşun zaman içinde gelişmeye devam etmesi bekleniyor.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Vitalik Buterin: Ethereum daha fazla özellik içermeli mi?
Protokol minimalizminin erken felsefeleri
O zamanlar "Ethereum 2.0" olarak bilinen şeyin erken tarihinde, mümkün olduğunca az şeyle kendi başına inşa etmeye çalışan ve bu tür işlerin neredeyse tamamını kullanıcılara bırakan temiz, basit ve estetik açıdan hoş bir protokol oluşturmak için güçlü bir istek vardı. İdeal olarak, protokol yalnızca bir sanal makinedir ve bir öbeğin doğrulanması yalnızca bir sanal makine çağrısıdır.
"Durum geçiş işlevi" (öbeği işleyen işlev) yalnızca tek bir VM çağrısı olacaktır ve diğer tüm mantık sözleşme aracılığıyla gerçekleşecektir: bazı sistem düzeyinde sözleşmeler, ancak çoğunlukla kullanıcı tarafından sağlanan sözleşmeler. Bu modelin çok iyi bir özelliği, tüm bir hard fork'un bile, zincir dışı veya zincir içi yönetişim tarafından onaylanacak ve daha sonra yükseltilmiş ayrıcalıklarla çalışacak bir blok işlemci sözleşmesi için tek bir işlem olarak tanımlanabilmesidir.
2015'teki bu tartışmalar özellikle ele aldığımız iki alan için geçerlidir: hesap soyutlama ve ölçeklendirme. Ölçeklendirme söz konusu olduğunda, fikir, yukarıdaki grafiğin doğal bir uzantısı gibi hissettiren maksimum bir soyutlama ölçeklendirme biçimi oluşturmaya çalışmaktır. Sözleşmeler, çoğu Ethereum düğümü tarafından depolanmayan verileri çağırabilir ve protokol bunu algılar ve çağrıyı bir tür çok genel genişletilmiş bilgi işlem işleviyle çözer. Sanal makinenin bakış açısından, çağrı ayrı bir alt sisteme gider ve bir süre sonra sihirli bir şekilde doğru yanıtı döndürür.
Bu düşünce tarzını kısaca araştırdık, ancak her türlü blok zinciri ölçeklendirmesinin mümkün olduğunu doğrulamaya çok fazla odaklandığımız için çabucak pes ettik. Daha sonra görecek olsak da, veri kullanılabilirliği örneklemesi ve ZK-EVM'nin birleşimi, Ethereum ölçeklendirmesi için olası bir geleceğin aslında bu vizyona çok yakın göründüğü anlamına geliyor! Öte yandan, hesap soyutlaması için, en başından beri bir tür uygulamanın mümkün olduğunu biliyorduk, bu nedenle araştırma hemen "ticaret sadece bir çağrıdır" saf başlangıç noktasına mümkün olduğunca yakın bir şeyi gerçeğe dönüştürmeye çalışmaya başladı.
İşlemin gerçekleştirilmesi ile gönderen adresinden gerçek temel EVM çağrısının yapılması arasında, çok sayıda ortak kod ve bundan sonra daha fazla ortak kod vardır. Bu kodu mümkün olduğunca sıfıra nasıl yaklaştırırız?
Buradaki ana kodlardan biri, işlemin doğru nonce ve imzaya sahip olup olmadığını kontrol etmekten sorumlu olan validate_transaction(state, tx)'dir. En başından beri, hesap soyutlamanın pratik amacı, kullanıcıların sosyal kurtarma ve çoklu imza cüzdanları gibi özellikleri daha kolay kullanabilmeleri için temel artımsız ve ECDSA doğrulamasını kendi doğrulama mantıklarıyla değiştirmelerine izin vermekti. Bu nedenle, apply_transaction'ı basit bir EVM çağrısı olarak yeniden tasarlamanın bir yolunu bulmak, yalnızca "kodu temiz hale getirmek uğruna temiz kod" görevi değildir; Bunun yerine, mantığı kullanıcının hesap koduna taşımak ve kullanıcıya ihtiyaç duyduğu esnekliği sağlamakla ilgilidir.
Bununla birlikte, uygula_transaction mümkün olduğunca az sabit mantık içermesi konusunda ısrar etmek, birçok zorluk yaratır. En eski hesap soyutlama önerilerinden biri olan EIP-86'ya bir göz atabiliriz.
EIP-86 olduğu gibi dahil edilirse, Ethereum yığınının diğer bölümlerinin karmaşıklığını büyük ölçüde artırma pahasına EVM'nin karmaşıklığını azaltacak ve aynı hash numarasına sahip aynı işlemin zincirde birden çok kez görünebilmesi gibi tamamen yeni garip kategorilerin getirilmesi dışında, esasen aynı kodun başka bir yere yazılmasını gerektirecektir.
Hesap soyutlamada birden çok geçersiz kılma sorunu. Zincir üzerinde yer alan bir işlem, mempool'daki diğer binlerce işlemi geçersiz kılabilir, bu da mempool'un ucuza taşmasını kolaylaştırır.
O zamandan beri, hesap soyutlaması aşamalar halinde gelişti. EIP-86 daha sonra EIP-208 ve sonunda pratik EIP-2938 oldu.
Bununla birlikte, EIP-2938 minimalist olmaktan başka bir şey değildir. İçeriği şunları içerir:
· Yeni işlem türleri
· Üç yeni ticaret kapsamı için global değişkenler
· Gaz fiyatı ve gaz limiti kontrollerini işlemek, EVM olarak kesme noktaları gerçekleştirmek ve ETH'yi tek seferlik bir ücret karşılığında geçici olarak depolamak için çok hantal PAYgas işlem kodu dahil olmak üzere iki yeni işlem kodu
· İşlem doğrulama aşamasında yasaklanmış işlem kodlarının bir listesi de dahil olmak üzere karmaşık bir dizi madencilik ve yeniden yayınlama stratejisi
Ethereum çekirdek geliştiricilerini (Ethereum istemcilerini optimize etmeye ve birleştirmeyi uygulamaya odaklanan) dahil etmeden hesap soyutlamasını uygulamak için, EIP-2938 sonunda tamamen protokol dışı ERC-4337 olarak yeniden tasarlandı.
Bu bir ERC olduğu için hard fork gerektirmez ve teknik olarak "Ethereum protokolünün dışında" bulunur. Öyle...... Sorun çözüldü mü? Durumun böyle olmadığı ortaya çıktı. ERC-4337'nin mevcut orta vadeli yol haritası, ERC-4337'nin çoğunu bir dizi protokol özelliğine dönüştürmeyi içeriyor ve bu, bu yolun neden düşünülmesi gerektiğine dair yararlı bir yol gösterici örnek.
Paket ERC-4337
ERC-4337'yi protokole geri getirmek için tartışılan birkaç temel neden var:
Gaz verimliliği: EVM içinde yapılan herhangi bir işlem, depolama yuvaları gibi gaz açısından pahalı özellikler kullanılırken verimsizlikler de dahil olmak üzere bir miktar sanal makine yüküne neden olur. Şu anda, bu ek verimsizlikler en az 20.000 gaz veya daha fazlasına tekabül ediyor. Bu bileşenleri bir protokole koymak, bu sorunları ortadan kaldırmanın en kolay yoludur.
Kod hatası riski: ERC-4337 "giriş noktası sözleşmesinde" yeterince korkutucu bir hata varsa, tüm ERC-4337 uyumlu cüzdanlar tüm fonlarının kuruduğunu görebilir. Sözleşmeleri protokol içi işlevsellikle değiştirmek, hard fork'lar yoluyla kod hatalarını düzeltmek için örtük bir yükümlülük oluşturur ve böylece kullanıcıların fonlarının kuruma riskini ortadan kaldırır.
txt.origin gibi EVM işlem kodları için destek. ERC-4337'nin kendisi, txt.origin'in bir dizi kullanıcı eylemini bir işlemde paketleyen bir "paketleyicinin" adresini döndürmesine neden olur. Yerel hesap soyutlaması, txt.origin'in işlemi gönderen gerçek hesaba işaret etmesini sağlayarak bu sorunu çözer ve EOA ile aynı şekilde çalışmasını sağlar.
Sansüre dayanıklı: Teklif veren/oluşturucu ayrımının zorluklarından biri, bireysel işlemleri gözden geçirmenin daha kolay hale gelmesidir. Bu sorun, Ethereum protokolünün tek bir işlemi tanıyabildiği, teklif sahibinin hemen hemen her durumda sonraki iki yuvaya dahil edilmesi gereken işlemlerin bir listesini belirlemesine izin verdiği bir dünyada büyük ölçüde hafifletilebilir. Bununla birlikte, protokolün dışındaki ERC-4337, "kullanıcı işlemlerini" tek bir işlemde kapsülleyerek kullanıcı işlemlerini Ethereum protokolüne opak hale getirir; Bu nedenle, Ethereum protokolü tarafından sağlanan dahil etme listesi, ERC-4337 kullanıcı işlemlerine sansür direnci sağlayamayacaktır. ERC-4337'yi kapsüllemek ve kullanıcı eylemini "uygun" bir işlem türü haline getirmek bu sorunu çözecektir.
Mevcut haliyle, ERC-4337'nin "temel" bir Ethereum işleminden çok daha pahalı olduğunu belirtmekte fayda var: işlem maliyeti 21.000 gaz, ERC-4337 ise yaklaşık 42.000 gaza mal oluyor.
Teorik olarak, EVM gaz maliyet sistemini, anlaşma içi maliyet ve depolamaya protokol dışı erişim maliyeti eşleşene kadar ayarlamak mümkün olmalıdır; Diğer depolama düzenleme işlemleri daha ucuz olduğunda, ETH'yi 9000 gazdan transfer etmek için hiçbir neden yoktur. Aslında, yaklaşmakta olan Verkle ağacı dönüşümüyle ilgili iki EIP aslında tam da bunu yapmaya çalışıyor. Ancak bunu yapsak bile, EVM ne kadar verimli olursa olsun, kapsüllenmiş protokol işlevselliğinin kaçınılmaz olarak EVM kodundan çok daha ucuz olmasının bariz bir nedeni vardır: kapsüllenmiş kodun ön yükleme için gaz ödemesine gerek yoktur.
Tamamen işlevsel ERC-4337 cüzdanı büyüktür ve onu derleyen ve zincire koyan uygulama yaklaşık 12.800 bayt alır. Elbette, bu kodu bir kez dağıtabilir ve her bir cüzdanın onu aramasına izin vermek için DELEGATECALL'u kullanabilirsiniz, ancak yine de onu kullanan her bloktaki koda erişmeniz gerekir. Verkle ağacı gaz maliyeti EIP'ye göre, 12.800 bayt 413 parça oluşturacaktır ve bu parçalara erişmek, tanık dalının 2 katını (toplam 3.800 gaz) _cost ve tanık yığınının 413 katını (toplam 82.600 gaz) ödemeyi gerektirecektir_cost. Ve bu, 0.6.0 sürümünde zincirde 23.689 bayt (Verkle ağacı EIP kurallarına göre yüklenecek yaklaşık 158.700 gaz) olan ERC-4337 giriş noktasının kendisinden bahsetmeye bile başlamıyor.
Bu, soruna yol açar: Bu kodlara gerçekten erişmenin gaz maliyeti, işlem boyunca bir şekilde amorti edilmelidir. ERC-4337 tarafından kullanılan mevcut yaklaşım çok iyi değil: paketteki ilk işlem tek seferlik bir depolama/kod okuma maliyeti tüketiyor ve bu da onu diğer işlemlerden çok daha pahalı hale getiriyor. Protokol içi kapsülleme, bu genel paylaşılan kitaplıkların protokolün bir parçası olmasına ve herkes tarafından ücretsiz olarak erişilebilir olmasına olanak tanır.
Bu örnekten ne öğrenebiliriz ve ambalaj ne zaman daha yaygın olacak? **
Bu örnekte, protokolde hesap soyutlama yönünü kapsüllemek için bazı farklı gerekçeler görüyoruz.
"Karmaşıklığı uç noktaya iten" pazar temelli yaklaşımlar, sabit maliyetler yüksek olduğunda büyük olasılıkla başarısız olur. Aslında, uzun vadeli hesap soyutlama yol haritası, her bloğun çok fazla sabit maliyeti var gibi görünüyor. Standartlaştırılmış cüzdan kodlarını yüklemek için 244, 100 gaz bir şeydir; Ancak toplama, ZK-SNARK doğrulamasına yüz binlerce gazın yanı sıra zincir kanıtı doğrulamasının zincir üstü maliyetini de ekleyebilir. Çok fazla piyasa verimsizliği getirmeden kullanıcılardan bu maliyetler için ücret almanın bir yolu yoktur ve bu özelliklerden bazılarını herkesin ücretsiz olarak erişebileceği protokol özelliklerine dönüştürmek bu sorunu iyi bir şekilde çözer.
Kod hatalarına topluluk çapında yanıtlar. Bazı kod parçacıkları tüm kullanıcılar veya çok geniş bir kullanıcı kitlesi tarafından kullanılıyorsa, ortaya çıkan hataları düzeltmek için blok zinciri topluluğunun bir hard fork'un sorumluluğunu üstlenmesi genellikle daha mantıklıdır. ERC-4337, büyük miktarda küresel olarak paylaşılan kodu tanıtır ve bir hard fork yoluyla koddaki hataları düzeltmek, uzun vadede kullanıcıların çok fazla ETH kaybetmesine neden olmaktan şüphesiz daha mantıklıdır.
Bazen, protokolün işlevselliğinden doğrudan yararlanarak daha güçlü bir form elde edilebilir. Buradaki anahtar örnek, dahil etme listesi gibi protokol içi sansür önleme özelliğidir: protokol içindeki dahil etme listesi, protokol dışındaki yöntemden daha iyi sansür direncini garanti edebilir ve kullanıcı düzeyindeki işlemlerin protokol içindeki dahil etme listesinden gerçekten yararlanabilmesi için, tek bir kullanıcı düzeyindeki işlemin protokol tarafından "okunabilir" olması gerekir. Daha az bilinen bir başka örnek, BLS'nin protokol ve ağ düzeyinde uygulanması gereken bir "toplama" mekanizmasını desteklediğinden, BLS'yi kapsüllemek lehine terk edilen stake anahtar hesabını soyutlayan 2017 dönemi Ethereum proof-of-stake tasarımıdır, bu da çok sayıda imzanın işlenmesini daha verimli hale getirebilir.
Ancak, protokol içi hesap soyutlamasının kapsüllenmesinin bile mevcut duruma kıyasla hala büyük bir "kapsülleme" olduğunu hatırlamak önemlidir. Bugün, üst düzey Ethereum işlemleri yalnızca tek bir secp 256k1 eliptik eğri imzası ile doğrulanan harici olarak sahip olunan hesaplardan (EOA'lar) başlatılabilir. Hesap soyutlaması bunu ortadan kaldırır ve doğrulama kriterlerini tanımlamayı kullanıcıya bırakır. Bu nedenle, hesap soyutlamayla ilgili bu hikayede, kapsüllemeye karşı en büyük argümanı da görüyoruz: farklı kullanıcıların ihtiyaçlarını karşılama esnekliği.
Son zamanlarda kapsüllenmiş olarak kabul edilen diğer birkaç özellik örneğine bakarak bu hikayeyi daha da detaylandıralım. Şunlara özellikle dikkat edeceğiz: ZK-EVM, teklif veren-oluşturucu ayrımı, özel mempool'lar, likidite stake etme ve yeni ön derleme.
ZK-EVM Paketi
Dikkatimizi Ethereum protokolünün başka bir potansiyel kapsülleme hedefine çevirelim: ZK-EVM. Şu anda, ZK-SNARK'ta benzer Ethereum bloklarının yürütülmesini doğrulamak için oldukça benzer kod yazmak zorunda olan çok sayıda ZK toplamamız var. Oldukça çeşitli bağımsız uygulamalar ekosistemi vardır: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth ve çok daha fazlası.
EVM ZK-rollup alanındaki son bir tartışma, ZK kodundaki olası hataların nasıl ele alınacağıyla ilgilidir. Şu anda, çalışan tüm bu sistemler, hata durumunda kanıtlama sistemini kontrol eden bir tür "Güvenlik Konseyi" mekanizmasına sahiptir. Geçen yıl, projeleri sertifikasyon sistemine ve Güvenlik Konseyi'ne olan güven düzeylerini netleştirmeye ve zaman içinde kuruluş üzerindeki yetkilerini kademeli olarak azaltmaya teşvik etmek için standart bir çerçeve oluşturmaya çalıştım.
Orta vadede, toplamalar birden fazla kanıtlama sistemine dayanabilir ve Güvenlik Konseyi yalnızca iki farklı kanıtlama sisteminin birbirinden ayrıldığı aşırı durumlarda yetkiye sahip olacaktır.
Ancak, bazı işlerin gereksiz hissettirdiğine dair bir his var. Zaten Ethereum temel katmanına sahibiz, bir EVM'ye sahip ve uygulamadaki hataları ele almak için zaten çalışan bir mekanizmamız var: bir hata varsa, istemci bunu düzeltmek için güncelleyecek ve ardından zincir çalışmaya devam edecek. Buggy istemcisinin bakış açısından, kesinleşen bloklar artık onaylanmayacak gibi görünüyor, ancak en azından kullanıcıların para kaybettiğini görmeyeceğiz. Benzer şekilde, rollup'lar yalnızca EVM'ye eşdeğer rollerini sürdürmek istiyorlarsa, Ethereum temel katmanına yükseltmeleri eşleştirmek için dahili ZK-EVM kurallarını sürekli olarak değiştirmek için kendi yönetişimlerini uygulamaları gerekir, bu yanlış geliyor çünkü sonuçta ne zaman ve hangi yeni kurallara göre yükseltme yapacağını bilen Ethereum temel katmanının üzerine inşa edilmiştir.
Bu L2 ZK-EVM'ler temel olarak Ethereum ile tamamen aynı EVM'leri kullandığından, bir şekilde "EVM'nin ZK'da yürütülmesini doğrulamayı" protokol işlevine dahil edebilir ve temel katman EVM uygulamasının kendisinde yaptığımız gibi, Ethereum'un sosyal fikir birliğini uygulayarak hatalar ve yükseltmeler gibi istisnaları ele alabilir miyiz?
Bu önemli ve zorlu bir konudur.
Yerel ZK-EVM'de veri kullanılabilirliği hakkında olası bir tartışma konusu, durum bilgisidir. ZK-EVM'lerin "tanık" verileri taşıması gerekmeseydi, veri verimlilikleri çok daha yüksek olurdu. Yani, belirli bir veri parçası daha önceki bir blokta zaten okunmuş veya yazılmışsa, kanıtlayıcının ona erişimi olduğunu ve tekrar kullanılabilir hale getirmesi gerekmediğini varsayabiliriz. Bu sadece depolamayı ve kodu yeniden yüklememekle ilgili değil; Durum bilgisi olan sıkıştırmanın, bir toplama verileri doğru şekilde sıkıştırırsa, durum bilgisi olmayan sıkıştırmaya kıyasla 3 kata kadar veri tasarrufu sağlayabileceği ortaya çıktı.
Bu, ZK-EVM ön derlemesi için iki seçeneğimiz olduğu anlamına gelir:
Ön derleme, tüm verilerin aynı yığında bulunmasını gerektirir. Bu, kanıtlayıcının durum bilgisiz olabileceği anlamına gelir, ancak aynı zamanda bu önceden derlenmiş ZK toplamasını kullanmanın özel kodla toplamayı kullanmaktan çok daha pahalı olduğu anlamına gelir.
Ön derleme, işaretçinin daha önce yürütülen, kullanılan veya oluşturulan verileri göstermesini sağlar. Bu, ZK-rollup'ı neredeyse en uygun hale getirir, ancak daha karmaşıktır ve kanıtlayıcı tarafından saklanması gereken yeni bir durum sunar.
Bundan ne öğrenebiliriz? ZK-EVM doğrulamasını bir şekilde kapsüllemek için iyi bir neden var: rollup zaten kendi özel sürümünü oluşturuyor ve Ethereum, EVM'yi yürütmek için çoklu uygulamalarını ve zincir dışı sosyal fikir birliğini L1'e ağırlık vermeye istekli, ki bu yanlış geliyor, ancak L2'nin tam olarak aynı işi yapması, Güvenlik Konseyi'ni içeren karmaşık araçlar uygulamalıdır. Ancak öte yandan, ayrıntılarda büyük bir sorun var: ZK-EVM'nin maliyet ve fayda açısından farklılık gösteren farklı versiyonları var. Durumlu ve vatansız arasındaki ayrım yalnızca yüzeyi çizer; Diğer sistemler tarafından kanıtlanmış özel kodlar olan "neredeyse EVM"yi desteklemeye çalışmak, daha fazla tasarım alanı ortaya çıkarabilir. Bu nedenle ZK-EVM'nin kapsüllenmesi hem umut hem de zorluklar sunar.
Sarmalayıcı ve Oluşturucu Ayrımı (ePBS)
MEV'in yükselişi, blok üretimini büyük ölçekli bir ekonomik faaliyet haline getirdi ve karmaşık katılımcılar, işlemlerin mempool'unu gözlemleyen ve bunları içeren varsayılan algoritmadan daha fazla gelir sağlayan bloklar üretebildi. Şimdiye kadar, Ethereum topluluğu bu sorunu, düzenli doğrulayıcıların ("teklif verenler") blok yapımını uzman katılımcılara ("inşaatçılar") dış kaynak sağlamasına izin veren MEV-Boost gibi bir protokol dışı teklif veren-oluşturucu ayırma şeması kullanarak çözmeye çalıştı.
Bununla birlikte, MEV-Boost, röle adı verilen yeni bir katılımcı sınıfında güven varsayımlarında bulunur. Son iki yılda, "kapsüllenmiş PBS" oluşturmak için birçok teklif yapıldı. Bunun faydaları nelerdir? Bu durumda cevap basit: Doğrudan protokol özellikleriyle oluşturulan PBS, bunlar olmadan oluşturulan PBS'den daha güçlüdür (daha zayıf güven varsayımlarına sahip olma anlamında). Bu, kapsülleme protokolündeki fiyat kahinlerinde olduğu duruma benzer - ancak bu durumda da güçlü bir muhalefet vardır.
Özel Bellek Havuzunu Kapsülleme
Bir kullanıcı bir işlem gönderdiğinde, zincire dahil edilmeden önce bile hemen herkese açık ve herkes tarafından görülebilir. Bu, birçok uygulamanın kullanıcılarını önleyici işlemler gibi ekonomik saldırılara karşı savunmasız bırakır.
Son zamanlarda, kullanıcıların işlemlerini geri döndürülemez bir şekilde bir bloğa kabul edilene kadar şifreleyen "özel mempools" (veya "şifreli mempools") oluşturmaya adanmış bir dizi proje olmuştur.
Ancak sorun, bu tür şemaların özel bir şifreleme türü gerektirmesidir: kullanıcıların sisteme su basmasını ve önce şifresini çözmesini önlemek için, işlem gerçekten geri döndürülemez bir şekilde kabul edildikten sonra şifrelemenin şifresinin otomatik olarak çözülmesi gerekir.
Bu şifreleme biçimini elde etmek için çeşitli ödünleşim teknikleri vardır. Jon Charbonneau bir keresinde bunu çok iyi ifade etti:
Flashbots Protect gibi merkezi operatörleri şifreleyin.
belirli bir sıralı hesaplama adımından sonra herkes tarafından şifresi çözülebilen ve paralelleştirilemeyen zaman kilidi şifrelemesi;
Eşik şifrelemesi, verilerin şifresini çözmek için dürüst bir çoğunluk komitesine güvenmek. Özel öneriler için Kapalı İşaret Zinciri Konsepti'ne bakın.
SGX gibi güvenilir donanımlar.
Ne yazık ki, her şifrelemenin farklı zayıf yönleri vardır. Her çözüm için, ona güvenmeye istekli bir kullanıcı alt kümesi olsa da, çözümlerin hiçbiri Katman 1 tarafından gerçekten kabul edilecek kadar güvenilir değildir. Bu nedenle, en azından gecikme şifrelemesi mükemmelleştirilene veya başka bir teknolojik atılım yapılana kadar, birçok uygulama çözümünün ortaya çıktığı kadar değerli bir özellik olsa bile, Katman 1'de gelişmiş ticaret önleme işlevini kapsüllemek zor bir teklif gibi görünüyor.
Kapsüllenmiş likidite staking
Ethereum DeFi kullanıcıları için ortak bir ihtiyaç, ETH'lerini aynı anda stake etmek için ve diğer uygulamalarda teminat olarak kullanabilme yeteneğidir. Diğer bir yaygın ihtiyaç da kolaylık sağlamaktır: kullanıcılar, bir düğüm çalıştırmanın ve onu her zaman çevrimiçi tutmanın karmaşıklığı olmadan stake edebilmek (ve çevrimiçi stake anahtarlarını koruyabilmek) ister.
Şimdiye kadar, bu ihtiyaçların her ikisini de karşılayan en basit stake etme "arayüzü" sadece bir ERC 20 tokenidir: ETH'nizi "ETH stake etmeye" dönüştürün, tutun ve geri dönüştürün. Aslında, Lido ve Rocket Pool gibi likidite stake sağlayıcıları bunu yapmaya başladı bile. Bununla birlikte, likidite staking'in iş başında bazı doğal merkezileştirme mekanizmaları vardır: insanlar doğal olarak ETH'yi stake etmenin en büyük versiyonuna girerler çünkü bu en tanıdık ve likit olanıdır.
ETH stake etmenin her sürümü, temel düğüm operatörünün kim olabileceğini belirlemek için bir mekanizma gerektirir. Sınırsız olamaz, çünkü o zaman saldırganlar katılır ve kullanıcının fonlarıyla saldırıyı güçlendirir. Şu anda ilk ikisi, bir DAO beyaz liste düğüm operatörüne sahip olan Lido ve herkesin 8 ETH yatırılan bir düğüm çalıştırmasına izin veren Rocket Pool'dur. İki yöntemin farklı riskleri vardır: Roket Havuzu yaklaşımı, saldırganların ağ üzerinde %51 saldırı gerçekleştirmesine olanak tanır ve kullanıcıları maliyetin çoğunu ödemeye zorlar; DAO yaklaşımına gelince, belirli bir staking tokeni baskın hale gelirse, tüm Ethereum doğrulayıcılarının önemli bir bölümünü kontrol eden tek, potansiyel olarak saldırıya uğrayabilir bir yönetişim aracı ile sonuçlanır. Elbette, Lido gibi protokollerin zaten önlemleri vardır, ancak bir savunma katmanı yeterli olmayabilir.
Kısa vadede, bir seçenek, ekosistem katılımcılarını tek bir şirketten kaynaklanan sistemik risk olasılığını azaltmak için çok çeşitli likidite stake sağlayıcıları kullanmaya teşvik etmektir. Bununla birlikte, uzun vadede, bu istikrarsız bir dengedir ve sorunları çözmek için ahlaki baskıya çok fazla güvenmek tehlikelidir. Doğal bir soru ortaya çıkıyor: Likidite staking'i daha az merkezi hale getirmek için protokolde bir tür işlevselliği kapsüllemek mantıklı mı?
Buradaki kilit soru şudur: Ne tür bir protokol içi işlevsellik? Basitçe protokol içi değiştirilebilir bir "ETH stake etme" tokeni oluşturmanın sorunu, düğümleri kimin çalıştıracağını seçmek için ya kapsüllenmiş Ethereum çapında bir yönetişime sahip olması ya da açık olmasıdır, ancak bu onu saldırganlar için bir araca dönüştürür.
İlginç bir fikir, Dankrad Feist'in likidite stake maksimizasyonu hakkındaki makalesidir. İlk olarak, mermiyi ısıralım ve Ethereum'a %51 oranında saldırılırsa, saldırı ETH'sinin yalnızca %5'ine el konulabilir. Bu makul bir değiş tokuştur; Şu anda 26 milyondan fazla ETH stake edildiğinden, özellikle daha düşük bir maliyetle kaç tane "model dışı" saldırının yapılabileceği göz önüne alındığında, saldırı maliyetinin üçte biri (yaklaşık 8 milyon ETH) aşırıdır. Aslında, Süper Komisyon'un tek yuvalı kesinliği uygulama önerisinde de benzer ödünleşimler araştırılmıştır.
Saldırı ETH'sinin yalnızca %5'ine el konulduğunu kabul edersek, stake edilen ETH'nin %90'ından fazlası müsadereden etkilenmeyecektir, bu nedenle protokol içinde değiştirilebilir likidite stake tokenleri olarak kullanılabilir ve daha sonra diğer uygulamalar tarafından kullanılabilirler.
Yol ilginç. Ama yine de şu soruyu bırakıyor: tam olarak ne kapsüllenmiş? Rocket Pool çok benzer şekilde çalışır: her düğüm operatörü bir miktar fon sağlar ve likidite stake edenler geri kalanını sağlar. Maksimum cezayı 2 ETH ile sınırlamak için bazı sabitleri ayarlayabiliriz ve Rocket Pool'un mevcut rETH'si risksiz hale gelecektir.
Basit protokol ayarlamaları ile başka akıllı şeyler de yapabiliriz. Örneğin, diyelim ki iki stake "katmanı" olan bir sistem istiyoruz: düğüm operatörleri (yüksek teminat gereksinimleri) ve mevduat sahipleri (minimum teminat gereksinimleri yoktur ve istedikleri zaman katılabilir ve ayrılabilirler), ancak yine de dahil edilmesi gereken işlemlerin bir listesini önermek (sansüre dayanıklı nedenlerle), etkin olmayan sızıntılar sırasında çatal seçimini kontrol etmek veya blok imzalamayı zorunlu kılmak gibi rastgele örneklenmiş bir mevduat komitesi oluşturarak düğüm operatörlerinin merkezileşmesini önlemek istiyoruz. Bu, her doğrulayıcının (i) normal bir stake anahtarı ve (ii) ikincil bir stake anahtarı çıkarmak için her yuvada çağrılabilecek bir ETH adresi sağlamasını gerektirecek şekilde protokolü değiştirerek protokolden esasen ayrılacak şekilde başarılabilir. Protokol her iki anahtara da güç verecektir, ancak her yuvada ikinci anahtarı seçme mekanizması stake havuzu protokolüne bırakılabilir. Bazı özellikleri doğrudan kapsüllemek daha iyi olabilir, ancak bu "bazı şeyleri dahil et ve diğer her şeyi kullanıcıya bırak" tasarım alanının var olduğunu belirtmekte fayda var.
Daha fazla ön derleme kapsülleyin
Önceden derlenmiş (veya "önceden derlenmiş sözleşmeler"), mantığı EVM akıllı sözleşme kodu yerine istemci kodunda yerel olarak uygulanan karmaşık kriptografik işlemleri uygulayan Ethereum sözleşmeleridir. Ön kodlama, Ethereum geliştirmenin başlangıcında benimsenen bir uzlaşmaydı: bir sanal makinenin ek yükü çok karmaşık ve son derece uzmanlaşmış bir kod için çok büyük olduğundan, yerel kodda daha hızlı hale getirmek için önemli uygulamalar için değerli olan bazı önemli işlemleri uygulayabilirdik. Bugün, bu temel olarak bazı özel hash fonksiyonlarını ve eliptik eğri işlemlerini içerir.
Şu anda, temel Ethereum hesapları için secp 256 K1'den biraz farklı bir eliptik eğri olan secp 256 R1 için ön derleme eklemek için bir baskı var, çünkü güvenilir donanım modülleri tarafından iyi bir şekilde destekleniyor, bu nedenle yaygın kullanımı cüzdan güvenliğini artırabilir. Son yıllarda topluluk, BLS-12-377, BW 6-761, genelleştirilmiş eşleştirme ve diğer özellikler için ön derlemelerin eklenmesi için de baskı yaptı.
Daha önceden derlenmiş dosyalar için bu isteklerin karşı argümanı, daha önce eklenen ön derlemelerin çoğunun (örneğin RIPEMD ve BLAKE) beklenenden çok daha azını kullanması ve onlardan öğrenmemiz gerektiğidir. Belirli işlemler için daha fazla ön derleme eklemek yerine, belki de EVM uygulamalarının çok çeşitli kod sınıflarını daha düşük bir maliyetle yürütmesini sağlayacak EVM-MAX ve hareketsiz ancak her zaman kurtarılabilir SIMD önerileri gibi fikirlere dayalı daha yumuşak bir yaklaşıma odaklanmalıyız. Belki de nadiren kullanılan mevcut ön derleme bile kaldırılabilir ve aynı işlevin EVM kodunun (kaçınılmaz olarak daha az verimli) bir uygulamasıyla değiştirilebilir. Bununla birlikte, hızlandırmak için yeterince değerli olan belirli şifreleme işlemlerinin olması hala mümkündür, bu nedenle bunları önceden derlenmiş olarak eklemek mantıklıdır.
Bütün bunlardan ne öğrendik?
Mümkün olduğunca az kapsülleme arzusu anlaşılabilir ve iyidir; Unix'in, kullanıcıların farklı ihtiyaçlarına kolayca uyarlanabilen ve yazılım şişkinliğinin lanetinden kaçınabilen minimalist yazılım yaratma felsefi geleneğinden türemiştir. Bununla birlikte, blok zinciri kişisel bir bilgi işlem işletim sistemi değil, sosyal bir sistemdir. Bu, protokoldeki belirli işlevleri kapsüllemenin mantıklı olduğu anlamına gelir.
Çoğu durumda, bu diğer örnekler hesap soyutlamasında gördüğümüze benzer. Ama aynı zamanda bazı yeni dersler de öğrendik:
Kapsülleme, yığının başka bir yerinde merkezileştirme riskinden kaçınmaya yardımcı olabilir:
Çoğu zaman, temel protokolü minimum ve basit tutmak, karmaşıklığı ekosistemin bazı protokollerinin ötesine iter. Unix felsefi bakış açısından, bu iyidir. Bununla birlikte, bazen yüksek sabit maliyetler nedeniyle protokol dışı ekosistemlerin merkezileşme riski vardır. Kapsülleme bazen fiili merkezileşmeyi azaltabilir.
Çok fazla içerik kapsüllemek, protokol üzerindeki güven ve yönetişim yükünü aşırı genişletebilir:
Bu, "Ethereum konsensüsünü aşırı yüklemeyin" konulu önceki bir makalenin konusudur: belirli bir işlevi kapsüllemek güven modelini zayıflatırsa ve Ethereum'u bir bütün olarak daha "öznel" hale getirirse, Ethereum'un güvenilir tarafsızlığını zayıflatır. Bu durumlarda, belirli bir özelliği Ethereum'un üzerinde bir mekanizma olarak sunmak, onu Ethereum'un kendisine tanıtmaya çalışmaktan daha iyidir. Burada, şifrelenmiş bellek havuzları en iyi örnektir ve en azından gecikme şifrelemesi iyileşene kadar kapsüllenmesi biraz zor olabilir.
Çok fazla kapsülleme, protokolü aşırı karmaşık hale getirebilir:
Protokol karmaşıklığı, protokole çok fazla özellik eklenerek artırılabilen sistemik bir risktir. Ön derleme en iyi örnektir.
Uzun vadede, kullanıcı ihtiyaçları tahmin edilemez olduğu için kapsülleme işlevi geri tepebilir:
Birçok kişinin önemli bulduğu ve birçok kullanıcı tarafından kullanılacak bir özellik, muhtemelen pratikte düzenli olarak kullanılmıyor.
Ek olarak, likidite staking, ZK-EVM ve önceden derlenmiş vakalar bir orta yol olasılığını göstermektedir: minimum uygulanabilir koruma. Protokollerin tüm işlevi kapsüllemesi gerekmez, ancak temel zorlukları ele alan belirli parçalar içerebilir, bu da işlevin çok paranoyak veya çok dar olmadan uygulanmasını kolaylaştırır. Buna örnek olarak şunlar verilebilir:
Tam bir likidite rehin sistemini kapsüllemek yerine, güvene dayalı olmayan likidite rehinini daha uygulanabilir hale getirmek için stake cezası kurallarını değiştirmek daha iyidir;
Daha fazla ön derleyiciyi kapsüllemek yerine, daha geniş bir çalışma kategorisi yelpazesi için verimli bir şekilde uygulamayı kolaylaştırmak için EVM-MAX ve/veya SIMD'yi kapsülleyin;
EVM doğrulaması, tüm toplama kavramını kapsüllemek yerine basitçe kapsüllenebilir.
Önceki grafiği aşağıdaki gibi genişletebiliriz:
Bazen bir şeyi sarmak mantıklıdır ve nadiren kullanılan ön derlemeyi kaldırmak buna bir örnektir. Daha önce de belirtildiği gibi, bir bütün olarak hesap soyutlaması da önemli bir kapsülleme biçimidir. Mevcut kullanıcılar için geriye dönük uyumluluğu desteklemek istiyorsak, mekanizma aslında önceden derlenmiş kapsüllemeye çarpıcı bir şekilde benzeyebilir: tekliflerden biri, EOA'nın hesaplarını aynı (veya daha iyi) işlevselliğe sahip sözleşmelere dönüştürmesine izin verecek olan EIP-5003'tür.
Hangi özelliklerin protokole dahil edilmesi ve hangilerinin ekosistemin diğer katmanlarına bırakılması gerektiği karmaşık bir değiş tokuştur. Kullanıcı ihtiyaçlarını, mevcut fikirleri ve teknoloji paketlerini anlamamız gelişmeye devam ettikçe bu değiş tokuşun zaman içinde gelişmeye devam etmesi bekleniyor.