Ethereum, protokolde daha fazla şeyin yer almasına razı olmalı mı?
Orijinal yazar: Vitalik Buterin
Odaily Planet Daily'nin Çevirmeni | Nian Yin Si Tang
*Geri bildirimleri ve değerlendirmeleri için Justin Drake, Tina Zhen ve Yoav Weiss'e özellikle teşekkür ederiz. *
Ethereum projesinin başlangıcından bu yana, çekirdek Ethereum'u olabildiğince basit hale getirmeye çalışmak ve bunun üzerine protokoller oluşturarak bunu mümkün olduğunca başarmak yönünde güçlü bir felsefe vardı. Blockchain alanında, "L1 üzerine inşa etme" ve "L2'ye odaklanma" tartışmasının genellikle öncelikle ölçeklendirmeyle ilgili olduğu düşünülür, ancak aslında birden fazla Ethereum kullanıcısının ihtiyaçlarının karşılanmasında benzer sorunlar vardır: dijital varlıkların değişimi, gizlilik , kullanıcı adları, gelişmiş şifreleme, hesap güvenliği, sansüre dayanıklılık, ileri düzeyde koruma ve daha fazlası. Bununla birlikte, son zamanlarda bu özelliklerin daha fazlasını temel Ethereum protokolüne dahil etmek için bazı ihtiyatlı girişimlerde bulunuldu.
Bu makale, minimal kapsüllemenin orijinal felsefesinin ardındaki bazı felsefi akıl yürütmelerin yanı sıra, bu fikirler hakkında bazı yeni düşünme biçimlerini de ele alacak. Amaç, belirli işlevleri kapsamanın dikkate alınmaya değer olabileceği olası hedefleri daha iyi belirlemek için bir çerçeve oluşturmaya başlamak olacaktır.
Protokol minimalizmine dair ilk felsefe
O zamanlar "Ethereum 2.0" olarak bilinen şeyin erken tarihinde, kendi üzerine mümkün olduğunca az şey inşa etmeye çalışan ve bu tür işlerin neredeyse tamamını kullanıcılara bırakan, temiz, basit ve güzel bir protokol oluşturma yönünde güçlü bir istek vardı. İdeal durumda protokol yalnızca bir sanal makinedir ve bir bloğun doğrulanması yalnızca bir sanal makine çağrısıdır.
Bu, Gavin Wood ve benim 2015'in başlarında Ethereum 2.0'ın neye benzeyeceği hakkında konuşurken çizdiğimiz beyaz tahta diyagramının yaklaşık bir yeniden inşasıdır.
"Durum geçiş işlevi" (bloğu işleyen işlev) yalnızca tek bir VM çağrısı olacaktır ve diğer tüm mantık sözleşmeler 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 güzel bir özelliği, tüm bir hard fork'un bile, zincir dışı veya zincir içi yönetişim tarafından onaylanacak ve ardından çalışma izni yükseltilecek olan blok işlemci sözleşmesine yönelik 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 durumunda amaç, yukarıdaki diyagramın doğal bir uzantısı gibi hissettiren maksimum soyut bir ölçeklendirme biçimi yaratmaya çalışmaktır. Sözleşmeler, çoğu Ethereum düğümü tarafından depolanmayan verileri çağırabilir ve protokol bunu tespit edecek ve çağrıyı çok genel bazı genişletilmiş bilgi işlem işlevleri aracılığıyla çözecektir. Sanal makinenin bakış açısından, çağrı ayrı bir alt sisteme gidecek ve bir süre sonra sihirli bir şekilde doğru yanıtı verecektir.
Bu fikri kısaca araştırdık ama hemen vazgeçtik çünkü her türlü blockchain ölçeklendirmesinin mümkün olduğunu kanıtlamaya fazlasıyla odaklanmıştık. Daha sonra göreceğimiz gibi, veri kullanılabilirliği örneklemesi ve ZK-EVM'nin birleşimi, Ethereum ölçeklendirmesinin olası geleceğinin aslında bu vizyona çok yakın göründüğü anlamına geliyor! Öte yandan, hesap soyutlamayla, bir tür uygulamanın mümkün olduğunu başından beri biliyorduk, bu nedenle araştırmalar, "bir işlem yalnızca bir çağrıdır" şeklindeki saf başlangıç noktasına mümkün olduğunca yakın bir şey yapmaya hemen başladı.
*İşlemin işlenmesi ile gönderen adresinden asıl EVM çağrısının yapılması arasında çok sayıda standart kod vardır ve bundan sonra daha fazla standart kod vardır. Bu kodu mümkün olduğunca sıfıra nasıl yaklaştırabiliriz? *
Buradaki ana kodlardan biri, işlemin nonce ve imzasının doğru olup olmadığını kontrol etmekten sorumlu olan validate_transaction(state, tx) kodudur. Hesap soyutlamanın en başından beri asıl amacı, kullanıcıların temel artımsız doğrulama ve ECDSA doğrulamasını kendi doğrulama mantığıyla değiştirmelerine olanak tanımak, böylece kullanıcıların sosyal kurtarma ve çoklu imza cüzdanları gibi özellikleri daha kolay kullanabilmelerini sağlamaktı. Dolayısıyla, application_transaction'ı basit bir EVM çağrısı halinde yeniden yapılandırmanın bir yolunu bulmak, yalnızca "kodu temizlemek adına kodu temiz yapma" görevi değildir; bunun yerine, mantığı kullanıcının hesap koduna taşımak ve kullanıcılara ihtiyaç duydukları esnekliği vermekle ilgilidir. ihtiyaç.
Ancak, application_transaction'ın mümkün olduğu kadar az sabit mantık içermesinde ısrar etmek birçok zorluğun ortaya çıkmasına neden oldu. En eski hesap soyutlama önerilerinden biri olan EIP-86'ya bakabiliriz.
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 bir bütünün tanıtılmasına ek olarak esasen aynı kodun başka bir yere yazılmasını gerektirecektir. yeni bir tuhaflık sınıfı Örneğin, aynı hash değerine sahip aynı işlem, çoklu geçersiz kılma sorununun yanı sıra zincirde birden çok kez görünebilir.
*Hesap soyutlamasında birden fazla geçersiz kılma sorunu. Zincir üzerinde yer alan bir işlem, bellek havuzundaki diğer binlerce işlemi geçersiz kılabilir ve bellek havuzunun ucuz bir şekilde doldurulmasını kolaylaştırabilir. *
O zamandan beri hesap soyutlaması aşamalar halinde gelişti. EIP-86 daha sonra EIP-208 oldu ve sonunda pratik EIP-2938 ortaya çıktı.
Ancak EIP-2938 minimalist olmaktan çok uzaktır. İçeriği şunları içerir:
Yeni işlem türü
Üç yeni işlem kapsamı global değişkeni
İki yeni işlem kodu, EVM yürütme kesme noktaları olarak gaz fiyatı ve gaz limiti kontrollerini yönetmek ve tek seferlik ödeme ücretleri için ETH'yi geçici olarak depolamak için kullanılan çok hantal PAYgas işlem kodu dahil
İşlem doğrulama aşamasında yasaklı işlem kodlarının bir listesini de içeren karmaşık bir dizi madencilik ve yeniden iletim stratejisi
Ethereum çekirdek geliştiricilerini (Ethereum istemcilerini optimize etmeye ve birleştirmeleri uygulamaya odaklanan) dahil etmeden hesap soyutlamayı başarma çabasıyla, EIP-2938 sonuçta tamamen protokol dışı olan ERC-4337 olarak yeniden tasarlandı.
ERC-4337. Tamamen EVM çağrılarına dayanıyor!
Bu bir ERC olduğu için hard fork gerektirmez ve teknik olarak "Ethereum protokolünün dışında" bulunur. Peki...sorun çözüldü mü? Durumun böyle olmadığı ortaya çıktı. ERC-4337'nin mevcut orta vadeli yol haritası aslında ERC-4337'nin büyük bölümlerinin bir dizi protokol özelliğine dönüştürülmesini içeriyor; bu, bu yolun neden dikkate alınması gerektiğine dair yararlı bir rehberlik örneğidir.
Paket ERC-4337
ERC-4337'nin nihai olarak protokole yeniden dahil edilmesinin tartışılan birkaç temel nedeni vardır:
gaz verimliliği: EVM içinde gerçekleştirilen herhangi bir işlem, depolama yuvaları gibi gaz açısından pahalı özelliklerin kullanılmasındaki verimsizlikler de dahil olmak üzere, belirli düzeyde sanal makine ek yüküne neden olur. Şu anda bu ek verimsizliklerin toplamı en az 20.000 gaza veya daha fazlasına ulaşıyor. Bu bileşenleri protokole koymak bu sorunları ortadan kaldırmanın en kolay yoludur.
Kod Hatası Riski: ERC-4337 "giriş noktası sözleşmesi" yeterince korkunç bir hataya sahipse, tüm ERC-4337 uyumlu cüzdanlar tüm fonlarının kuruduğunu görebilir. Sözleşmelerin protokol içi işlevlerle değiştirilmesi, kod hatalarının hard fork yoluyla düzeltilmesi yönünde örtülü bir yükümlülük oluşturur ve böylece kullanıcıların fonlarının tükenmesi riskini ortadan kaldırır.
Txt.origin gibi EVM işlem kodlarını destekler. ERC-4337'nin kendisi, txt.origin'in, bir dizi kullanıcı eylemini bir işlemde paketleyen bir "paketleyicinin" adresini döndürmesine neden oluyor. 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 davranmasını sağlar.
Sansüre Direnç: Teklif sahibi/inşaatçı ayrımının zorluklarından biri, bireysel işlemlerin incelenmesinin kolaylaşmasıdır. Ethereum protokolünün bireysel işlemleri tanımlayabildiği bir dünyada, bu sorun, teklif sahiplerinin hemen hemen her durumda sonraki iki yuvaya dahil edilmesi gereken işlemlerin bir listesini belirlemesine olanak tanıyan dahil etme listeleri ile büyük ölçüde hafifletilebilir. Bununla birlikte, protokolün dışındaki ERC-4337, "kullanıcı işlemlerini" tek bir işlemde kapsayarak kullanıcı işlemlerini Ethereum protokolüne karşı opak hale getirir; bu nedenle, Ethereum protokolü tarafından sağlanan dahil etme listesi, ERC-4337 kullanıcısına sansüre direnç sağlayamayacaktır. operasyonlar. ERC-4337'yi sarmalamak ve kullanıcı eylemini "uygun" bir işlem türü haline getirmek bu sorunu çözecektir.
Şu anki haliyle ERC-4337'nin "temel" Ethereum işlemlerinden önemli ölçüde daha pahalı olduğunu belirtmekte fayda var: bir işlemin maliyeti 21.000 gas, ERC-4337'nin maliyeti ise yaklaşık 42.000 gas.
Teorik olarak, EVM gaz maliyet sistemini, protokol içi maliyet ile protokol dışındaki depolamaya erişim maliyeti eşleşene kadar ayarlamak mümkün olmalıdır; diğer depolama düzenleme türleri kullanıldığında ETH'yi aktarmak için 9000 gaz harcamaya gerek yoktur. işlemler daha ucuzdur. Aslında yaklaşan 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şlevlerinin kaçınılmaz olarak EVM kodundan çok daha ucuz olmasının açık bir nedeni vardır: kapsüllenmiş kodun ön yükleme için gaz ödemesine gerek yoktur.
Tamamen işlevsel bir ERC-4337 cüzdanı büyüktür ve derlenen ve zincire eklenen uygulama yaklaşık 12.800 bayt yer kaplar. Elbette, bu kodu bir kez dağıtabilir ve her bir cüzdanın onu aramasına izin vermek için DELEGATECALL'ı kullanabilirsiniz, ancak yine de kullanıldığı her blokta koda erişmeniz gerekir. Verkle ağacı gaz maliyeti EIP kapsamında, 12.800 bayt 413 parça oluşturacaktır. Bu parçalara erişim, tanık dal maliyetinin 2 katı (toplam 3.800 gaz) ve tanık parça maliyetinin 413 katı (toplam 82.600) ödemeyi gerektirecektir. gaz). Bu, 0.6.0 sürümünde zincirde 23.689 bayta sahip olan (Verkle ağacı EIP kurallarına göre yüklenecek yaklaşık 158.700 gaz) ERC-4337 giriş noktasının kendisinden bahsetmeye bile başlamıyor.
Bu da bir soruna yol açıyor: Bu kodlara fiilen erişmenin gas maliyetinin işlemler genelinde bir şekilde amortismana tabi tutulması gerekiyor. ERC-4337 tarafından kullanılan mevcut yaklaşım pek iyi değil: Paketteki ilk işlem, tek seferlik depolama/kod okuma maliyeti tüketiyor ve bu da onu diğer işlemlere göre çok daha pahalı hale getiriyor. Protokol içi kapsülleme, bu halka açık paylaşılan kitaplıkların protokolün bir parçası olmasına ve herkesin serbestçe erişebilmesine olanak tanıyacaktır.
Bu örnekten ne öğrenebiliriz ve kapsülleme daha genel olarak ne zaman uygulanmalıdır?
Bu örnekte, hesap soyutlamalarının protokollerde kapsüllenmesine yönelik bazı farklı gerekçeler görüyoruz.
**"Karmaşıklığı en uç noktalara iten" pazar temelli yaklaşımların, sabit maliyetler yüksek olduğunda başarısız olma olasılığı yüksektir. **Aslında, uzun vadeli hesap soyutlama yol haritasının blok başına çok fazla sabit maliyeti var gibi görünüyor. Standartlaştırılmış cüzdan kodunu yüklemek için 244.100 gaz bir şeydir; ancak toplama, ZK-SNARK doğrulaması için yüz binlerce gazın yanı sıra kanıt doğrulamanın zincir içi maliyetini de ekleyebilir. Büyük pazar verimsizliklerine yol açmadan bu maliyetler için kullanıcılardan ücret almanın bir yolu yoktur ve bu özelliklerden bazılarını herkesin serbestçe erişebileceği protokol özelliklerine dönüştürmek bu sorunu çok iyi çözecektir.
**Kod hatalarına topluluk çapında yanıt. **Eğer bir kod parçası tüm kullanıcılar veya çok geniş bir kullanıcı kitlesi tarafından kullanılıyorsa, blockchain topluluğunun ortaya çıkan hataları düzeltmek için hard fork sorumluluğunu üstlenmesi genellikle daha mantıklı olur. ERC-4337, küresel olarak paylaşılan büyük miktarda kod getiriyor.Uzun vadede, kullanıcıların büyük miktarda ETH kaybetmesine neden olmaktansa, koddaki hataları hard fork yoluyla düzeltmek şüphesiz daha mantıklıdır.
**Bazen, bir protokolün daha güçlü bir biçimi doğrudan işlevselliğinden yararlanılarak uygulanabilir. **Buradaki en önemli örnek, protokol içindeki sansüre dirençli özelliklerdir, örneğin içerme listeleri: Protokol içi içerme listeleri, sansüre karşı direnci protokolün dışındaki yöntemlerden daha iyi garanti edebilir. Kullanıcı düzeyindeki işlemlerin protokol içi işlemlerden gerçekten yararlanabilmesi için Listeleri dahil etmek için, Bireysel kullanıcı düzeyindeki işlemlerin protokole göre "okunaklı" olması gerekir. Daha az bilinen bir başka örnek ise, 2017 dönemi Ethereum hisse senedi kanıtı tasarımının, hisse anahtarlarının hesap soyutlamasına sahip olmasıdır; bu, kapsüllenmiş BLS lehine terk edildi çünkü BLS, protokolde uygulanması gereken bir "toplama" mekanizmasını destekledi ve ağ düzeylerinde bu, çok sayıda imzanın işlenmesini daha verimli hale getirebilir.
Ancak, kapsülleme protokolündeki hesap soyutlamasının bile, mevcut durumla karşılaştırıldığında hala çok büyük bir "kapsülden çıkarma" olduğunu hatırlamak önemlidir. Bugün, üst düzey Ethereum işlemleri yalnızca tek bir secp 256k 1 eliptik eğri imzası kullanılarak doğrulanan harici sahipli hesaplardan (EOA) başlatılabilir. Hesap soyutlaması bunu ortadan kaldırır ve doğrulama koşullarını tanımlamayı kullanıcıya bırakır. Dolayısıyla hesap soyutlamayla ilgili bu hikayede kapsüllemeye karşı en büyük nedeni de görüyoruz: Farklı kullanıcıların ihtiyaçlarını karşılama esnekliği.
Yakın zamanda kapsüllenmesi düşünülen diğer birkaç özellik örneğine bakarak hikayeyi daha da detaylandıralım. Özellikle şunları inceleyeceğiz: ZK-EVM, teklif veren-oluşturucu ayrımı, özel hafıza havuzları, likidite staking ve yeni ön derleme.
Paket ZK-EVM
Dikkatimizi Ethereum protokolü için başka bir potansiyel kapsülleme hedefine çevirelim: ZK-EVM. Şu anda, ZK-SNARK'larda benzer Ethereum bloklarının yürütülmesini doğrulamak için hepsinin oldukça benzer kod yazması gereken çok sayıda ZK toplamamız var. Oldukça çeşitli bağımsız uygulamalar ekosistemi mevcuttur: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth ve çok daha fazlası.
EVM ZK toplama alanında yakın zamanda yaşanan bir tartışma, ZK kodunda ortaya çıkabilecek hatalarla nasıl başa çıkılacağıyla ilgilidir. Şu anda faaliyette olan bu sistemlerin tamamında, herhangi bir hata durumunda doğrulama sistemini kontrol eden bir tür "güvenlik konseyi" mekanizması bulunmaktadır. Geçtiğimiz yıl, projeleri tasdik sistemine ve Güvenlik Konseyi'ne ne kadar güvendiklerini netleştirmeye ve zamanla bu organizasyon üzerindeki yetkilerini kademeli olarak azaltmaya teşvik edecek standart bir çerçeve oluşturmaya çalıştım.
*Orta vadede, toplamanın birden fazla sertifikasyon sistemine dayanması muhtemeldir; Güvenlik Konseyi yalnızca iki farklı sertifikasyon sisteminin farklılaştığı aşırı durumlarda yetkiye sahiptir. *
Ancak bu çalışmaların bir kısmının gereksiz olduğu hissi var. Zaten bir Ethereum temel katmanımız var, bir EVM'si var ve uygulamadaki hatalarla başa çıkmak için zaten bir çalışma mekanizmamız var: bir hata varsa, istemci bunu düzeltmek için güncellenecek ve zincir çalışmaya devam edecek . Hatalı istemcinin bakış açısına göre, sonlandırılan 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, eğer toplamalar sadece EVM'nin eşdeğer rolünü sürdürmek istiyorlarsa, Ethereum temel katmanındaki 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ış hissettirir çünkü sonuçta onlar en üstte inşa edilmiştir. Ethereum temel katmanının kendisi ne zaman yükseltileceğini ve hangi yeni kurallara göre yapılacağını bilir.
Bu L2 ZK-EVM'ler temelde Ethereum ile tamamen aynı EVM'yi kullandığından, bir şekilde "ZK'de EVM yürütmesini doğrulama" özelliğini protokol işlevselliğine dahil edebilir miyiz ve Ethereum'un sosyal konsensüsünü (halihazırda yaptığımız gibi) hatalar ve yükseltmeler gibi uygulayarak istisnaları ele alabilir miyiz? temel katman EVM yürütmesinin kendisi?
Bu önemli ve zorlu bir konudur.
Yerel ZK-EVM'de veri kullanılabilirliğine ilişkin olası bir tartışma konusu durumsallıktır. ZK-EVM'ler "tanık" verilerini taşımaya ihtiyaç duymasaydı veri açısından çok daha verimli olurdu. Yani, eğer belirli bir veri parçası önceki bir blokta okunmuş veya yazılmışsa, kanıtlayıcının ona erişimi olduğunu ve onu tekrar kullanılabilir hale getirmek zorunda olmadığını basitçe varsayabiliriz. Sorun yalnızca depolamayı ve kodu yeniden yüklememekle ilgili değil; bir toplamanın verileri doğru şekilde sıkıştırması durumunda durum bilgisi olan sıkıştırmanın, 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:
**1.**Ön derleme tüm verilerin aynı blokta mevcut olmasını gerektirir. Bu, kanıtlayıcının durum bilgisi olmayan olabileceği anlamına gelir, ancak aynı zamanda bu önceden derlenmiş ZK toplamasını kullanmanın, özel kod toplamayı kullanmaktan çok daha pahalı olduğu anlamına da gelir.
**2.**Ön derleme, işaretçilerin önceki yürütmeler tarafından kullanılan veya oluşturulan verilere işaret etmesine olanak tanır. Bu, ZK toplamasını optimale yakın 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 özetlemek için iyi bir neden var: toplama zaten kendi özel sürümünü oluşturuyor ve Ethereum, çoklu uygulamalarının ve zincir dışı sosyal konsensüsün ağırlığıyla L1'de EVM'yi uygulamaya istekli. Yanlış, ancak L2'nin tamamen aynı işi yapması, Güvenlik Konseyi'nin de dahil olduğu karmaşık bir aygıtı uygulamaya koymak zorunda kalacaktı. Ancak bir yandan da detaylarda büyük bir sorun var: ZK-EVM'nin farklı versiyonları var ve bunların maliyet ve faydaları farklı. Durum bilgisi olan ve durum bilgisi olmayan arasındaki ayrım yalnızca yüzeyseldir; diğer sistemler tarafından kanıtlanmış "neredeyse EVM" özel kodunu destekleme girişimleri daha büyük bir tasarım alanını ortaya çıkarabilir. Bu nedenle ZK-EVM'nin ambalajlanması hem umut hem de zorluklar getirir.
Kapsülleme öneren ve oluşturucu ayrımı (ePBS)
MEV'nin yükselişi, karmaşık aktörlerin, yalnızca bir işlem hafızasını gözlemleyen ve bunları içeren varsayılan algoritmadan daha fazla gelir üreten bloklar üretebilmesiyle, blok üretimini geniş ölçekte ekonomik bir faaliyet haline getiriyor. Şimdiye kadar, Ethereum topluluğu bu sorunu MEV-Boost gibi protokol dışı teklif sahibi-inşacı ayırma şemalarını kullanarak çözmeye çalıştı. ").
Ancak MEV-Boost, röle adı verilen yeni bir aktör sınıfına güven varsayımlarında bulunur. Geçtiğimiz iki yılda "paketlenmiş PBS" oluşturmak için birçok teklif geldi. Bunu yapmanın faydaları nelerdir? Bu durumda cevap çok basit: Protokol özelliklerini doğrudan kullanarak oluşturulan bir PBS, bunları kullanmadan oluşturulan bir PBS'den daha güçlüdür (daha zayıf güven varsayımlarına sahip olmak anlamında). Bu, fiyat kehanetlerinin bir protokol içerisinde kapsüllenmesi durumuna benzer; ancak bu durumda güçlü itirazlar vardır.
Özel hafıza havuzunu kapsülleyin
Bir kullanıcı bir işlem gönderdiğinde, bu işlem, zincire dahil edilmeden önce bile anında herkese açık hale gelir ve herkes tarafından görülebilir. Bu, birçok uygulamanın kullanıcılarını önden çalıştırma gibi ekonomik saldırılara karşı savunmasız bırakıyor.
Son zamanlarda, kullanıcıların işlemlerini geri dönülemez bir şekilde bir bloğa kabul edilene kadar şifreleyen "özel bellek havuzları" (veya "kripto bellek havuzları") oluşturmaya adanmış bir dizi proje var.
Ancak sorun, böyle bir planın özel bir tür şifreleme gerektirmesidir: Kullanıcıların sistemi doldurmasını ve önce şifresini çözmesini önlemek için, işlem gerçekten geri döndürülemez şekilde kabul edildikten sonra şifrelemenin şifresinin otomatik olarak çözülmesi gerekir.
Bu şifreleme biçimini uygulamak için farklı değiş tokuşlara sahip çeşitli teknikler vardır. Jon Charbonneau bir keresinde bunu çok iyi tanımlamıştı:
Flaşbots Koruması gibi merkezi operatörler için şifreleme**. **
Zaman kilidi şifrelemesi, bu şifreleme formunun şifresi belirli sıralı hesaplama adımlarından sonra herkes tarafından çözülebilir ve paralelleştirilemez;
Eşik Şifreleme, verilerin şifresini çözme konusunda dürüst bir çoğunluk komitesine güvenin. Özel öneriler için kapalı işaret zinciri kavramına bakın.
Güvenilir Donanım, SGX gibi.
Ne yazık ki her şifreleme yönteminin farklı zayıf yönleri vardır. Her çözüm için ona güvenmeye istekli bir kullanıcı segmenti mevcut olsa da hiçbir çözüme Katman 1 tarafından gerçekten kabul edilecek kadar güvenilmez. **Dolayısıyla, en azından gecikmeli şifreleme mükemmelleştirilene veya başka bir teknolojik atılım yapılana kadar, ileriye dönük ticaret işlevselliğini Katman 1'e dahil etmek, birçok uygulamanın çözeceği kadar değerli bir özellik olsa bile, zor bir teklif gibi görünüyor planı ortaya çıktı.
Likidite staking'i kapsülleyin
Ethereum DeFi kullanıcılarının ortak ihtiyacı, ETH'lerini aynı anda staking ve diğer uygulamalarda teminat olarak kullanabilme yeteneğidir. Diğer bir yaygın talep ise sadece kolaylık sağlamak içindir: Kullanıcılar, bir düğümü çalıştırma ve onu her zaman çevrimiçi tutma karmaşıklığı olmadan stake yapabilmek (ve çevrimiçi stake anahtarlarını korumak) isterler.
Bu ihtiyaçların her ikisini de karşılayan açık ara en basit staking "ara yüzü" yalnızca bir ERC 20 tokenidir: ETH'nizi "staking ETH"ye dönüştürün, tutun ve sonra geri dönüştürün. Aslında Lido ve Rocket Pool gibi likidite staking sağlayıcıları bunu zaten yapıyor. Bununla birlikte, likidite stake etme konusunda bazı doğal merkezileştirme mekanizmaları vardır: İnsanlar doğal olarak ETH'nin en geniş versiyonunu stake etmeye yönelecektir çünkü en tanıdık ve likit olanıdır.
Stacked ETH'nin her versiyonunun, kimin temel düğüm operatörü olabileceğini belirlemek için bir mekanizmaya sahip olması gerekir. Sınırsız olamaz çünkü o zaman saldırganlar katılıp kullanıcı fonlarını saldırılarını genişletmek için kullanacaklardır. Şu anda ilk ikisi Lido ve Rocket Pool'dur; birincisi DAO beyaz listeye alınmış düğüm operatörlerine sahiptir ve ikincisi herkesin 8 ETH depozitoyla bir düğüm çalıştırmasına izin vermektedir. Bu iki yöntemin farklı riskleri vardır: Roket Havuzu yöntemi, bir saldırganın ağ üzerinde %51'lik bir saldırı yapmasına izin verir ve kullanıcıları maliyetlerin çoğunu ödemeye zorlar; DAO yönteminde ise, belirli bir stake edilmiş token baskın hale gelirse, bu durum saldırılara yol açacaktır. tek bir potansiyel olarak ele geçirilmiş yönetim aygıtı, tüm Ethereum doğrulayıcılarının büyük bir bölümünü kontrol eder. Lido gibi protokoller kendi takdirine göre koruma önlemleri uygulamıştır, ancak tek bir savunma katmanı yeterli olmayabilir.
Kısa vadede seçeneklerden biri, baskın bir oyuncunun sistemik risk oluşturma olasılığını azaltmak için ekosistem katılımcılarını çeşitli likidite staking sağlayıcıları kullanmaya teşvik etmektir. Ancak uzun vadede bu istikrarsız bir dengedir ve sorunları çözmek için ahlaki baskıya aşırı güvenmek tehlikelidir. Doğal bir soru ortaya çıkıyor: **Likidite stakingini daha az merkezi hale getirmek için protokolde bazı işlevleri kapsamak mantıklı mı? **
Buradaki anahtar soru şudur: ne tür bir protokol içi işlevsellik? Protokol içerisinde basitçe takas edilebilir bir "staking ETH" tokeni oluşturmanın bir sorunu, düğümleri kimin çalıştıracağını seçmek için ya Ethereum çapında kapsüllenmiş bir yönetişime sahip olması gerekmesi ya da açık uçlu olmasıdır, ancak bu onu Saldırganın kontrolüne dönüştürür. Aletler.
İlginç bir fikir, Dankrad Feist'in likidite stake etme maksimizasyonu hakkındaki makalesidir. Öncelikle mermiyi ısıralım: Ethereum %51 saldırısına maruz kalırsa, saldırıya uğrayan ETH'nin yalnızca %5'i kesilebilir. Bu makul bir değiş-tokuş; halihazırda 26 milyonun üzerinde ETH'nin bahis konusu olduğu göz önüne alındığında, bunun üçte birine (~8 milyon ETH) saldırmanın maliyeti çok yüksek, özellikle de aynı anda kaç tane "model dışı" saldırının yapılabileceği göz önüne alındığında. daha az maliyet. Aslına bakılırsa, Süper Komite'nin tek slot kesinliği uygulama teklifinde de benzer ödünleşimler araştırıldı.
Saldırı ETH'sinin yalnızca %5'inin kesildiğini kabul edersek, stake edilen ETH'nin %90'ından fazlası kesintiden etkilenmeyecektir, dolayısıyla bunlar protokol içerisinde değiştirilebilir likit staking tokenleri olarak kullanılabilir ve daha sonra diğer uygulamalar tarafından kullanılabilir.
Bu yol ilginç. Ancak yine de bir soru bırakıyor: Tam olarak kapsüllenmiş olan nedir? **Roket Havuzu da benzer şekilde çalışır: her düğüm operatörü bir miktar fon sağlar ve geri kalanını likidite stakerları sağlar. Maksimum kesme cezasını 2 ETH ile sınırlamak için bazı sabitleri kolayca ayarlayabiliriz ve Rocket Pool'un mevcut rETH'si risksiz hale gelecektir.
Basit protokol ayarlamalarıyla başka akıllıca şeyler de yapabiliriz. Örneğin, iki "kademeli" stake etme sistemine sahip bir sistem istediğimizi varsayalım: düğüm operatörleri (yüksek teminat gereklilikleri) ve mevduat sahipleri (minimum teminat gerekliliği yok, istedikleri zaman katılıp ayrılabilirler), ancak yine de Rastgele örneklenmiş bir sistem bağışlamak istiyoruz. mevduat sahibi komitesi, dahil edilmesi gereken işlemlerin bir listesini önermek (sansüre direnç nedeniyle), hareketsizlik sızıntıları sırasında çatal seçimini kontrol etmek veya bloklarda imza gerektirmek gibi düğüm operatörlerinin merkezileşmesini önleme yetkisine sahiptir. Bu, her doğrulayıcının (i) düzenli bir staking anahtarı sağlamasını ve (ii) her yuvada kullanılabilecek bir ETH adresinin çıktı olarak çağrılmasını gerektirecek şekilde protokolü değiştirerek esasen protokol dışına çıkan bir şekilde gerçekleştirilebilir. ikincil rehin anahtarı. Protokol her iki anahtarı da güçlendirecektir ancak her yuvadaki ikinci anahtarı seçme mekanizması stake havuzu protokolüne bırakılabilir. Bazı işlevleri doğrudan kapsamak daha iyi olabilir, ancak "bazı şeyleri dahil etme ve diğer şeyleri kullanıcıya bırakma" tasarım alanının mevcut olduğunu belirtmekte fayda var.
Daha fazla ön derlemeyi kapsülleyin
Önceden derlenmiş sözleşmeler (veya "önceden derlenmiş sözleşmeler"), EVM akıllı sözleşme kodu yerine müşteri kodunda yerel olarak uygulanan mantıkla karmaşık şifreleme işlemlerini uygulayan Ethereum sözleşmeleridir. Ön kodlama, Ethereum gelişiminin başlangıcından beri benimsenen bir uzlaşmadır: sanal bir makinenin yükü bazı çok karmaşık ve son derece uzmanlaşmış kodlar için çok büyük olduğundan, bazı önemli uygulamaları yerel kodda uygulayabiliriz. Bunları daha hızlı hale getirmek için kritik işlemlere değer verin. Günümüzde bu temel olarak bazı spesifik hash fonksiyonlarını ve eliptik eğri işlemlerini içermektedir.
Şu anda, temel ethereum hesapları için kullanılan secp 256 k 1'den biraz farklı bir eliptik eğri olan secp 256 r 1 için ön derleme eklemeye yönelik bir itme vardır ve güvenilir donanım modülleri tarafından iyi bir şekilde desteklendiğinden yaygın olarak kullanılmaktadır. Cüzdan güvenliğini artırmak için bunu kullanın. Son yıllarda topluluk, BLS-12-377, BW 6-761, genelleştirilmiş eşleştirme ve diğer özellikler için ön derleme ekleme konusunda da baskı yaptı.
Daha fazla ön derleyiciye yönelik bu çağrıların karşı argümanı, önceden eklenen ön derleyicilerin çoğunun (RIPEMD ve BLAKE gibi) beklenenden çok daha az kullanılmasıdır ve bundan ders almamız gerekir. Belirli işlemler için daha fazla ön derleme eklemek yerine, EVM uygulamalarının daha düşük maliyetle çalışmasını sağlayacak olan EVM-MAX ve Hazırda-Ama-Her Zaman-Sürdürülebilir SIMD teklifi gibi fikirlere dayanan daha yumuşak bir yaklaşıma odaklanmalıyız. geniş bir kod sınıfı yelpazesi. Belki mevcut az kullanılan ön derleme bile kaldırılabilir ve aynı işlevlerin (kaçınılmaz olarak daha az verimli) bir EVM kod uygulamasıyla değiştirilebilir. Bununla birlikte, hızlandırılacak kadar değerli olan belirli şifreleme işlemlerinin mevcut 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ğu kadar az şeyi kapsama arzusu anlaşılabilir ve iyidir; kullanıcıların farklı ihtiyaçlarına kolayca uyum sağlayabilen ve yazılım şişkinliğinin lanetinden kaçınabilen minimalist yazılım yaratmaya yönelik Unix'in felsefi geleneğinden kaynaklanmaktadır. Ancak blockchain kişisel bir bilgisayar işletim sistemi değil, sosyal bir sistemdir. Bu, protokolde belirli işlevleri kapsüllemenin anlamlı olduğu anlamına gelir.
Çoğu durumda, bu diğer örnekler hesap soyutlamasında gördüklerimize benzer. Ama aynı zamanda bazı yeni dersler de öğrendik:
Kapsüllenmiş işlevler, yığının diğer alanlarındaki merkezileştirme risklerinin önlenmesine yardımcı olabilir:
Çoğu zaman, temel protokolü minimum düzeyde ve basit tutmak, karmaşıklığı protokolün dışındaki bazı ekosistemlere iter. Unix felsefesi açısından bakıldığında bu gayet iyi. Bununla birlikte, bazen yüksek sabit maliyetler nedeniyle genellikle (ancak yalnızca bu değil) protokol dışı ekosistemin merkezileşme riski vardır. Kapsülleme bazen fiili merkezileşmeyi azaltabilir.
Çok fazla içeriğin kapsüllenmesi, protokolün güven ve yönetim yükünün aşırı artmasına neden olabilir:
Bu, "Ethereum Mutabakatını Aşırı Yüklemeyin" konulu önceki makalenin konusu: Eğer belirli bir özelliği kapsamak güven modelini zayıflatırsa ve Ethereum'u bir bütün olarak daha "öznel" hale getirirse, bu Ethereum'u zayıflatır. Bu durumlarda, Ethereum'un kendisine getirmeye çalışmak yerine, Ethereum'un üzerinde bir mekanizma olarak belirli işlevselliğe sahip olmak daha iyidir. Şifrelenmiş bellek havuzları buradaki en iyi örnektir; en azından gecikme şifrelemesi gelişene kadar kapsüllenmesi biraz zor olabilir.
Çok fazla içeriğin kapsüllenmesi protokolü aşırı karmaşık hale getirebilir:
Protokol karmaşıklığı, bir protokole çok fazla özellik eklenmesiyle artan sistemik bir risktir. Ön derleme bunun en iyi örneğidir.
Uzun vadede, kapsülleme işlevselliği, kullanıcı ihtiyaçlarının öngörülememesi nedeniyle verimsiz olabilir:
Pek çok kişinin önemli olduğunu düşündüğü ve pek çok kullanıcı tarafından kullanılacak olan bu özellik muhtemelen pratikte çok sık kullanılmıyor.
Ek olarak, likidite staking, ZK-EVM ve önceden derlenmiş örnekler bir orta yol olasılığını gösteriyor: minimum geçerli koruma. Protokolün tüm işlevselliği kapsaması gerekmez, ancak temel zorlukları ele alan belirli bölümleri içerebilir, bu da işlevselliğin çok paranoyak veya çok dar kapsamlı olmadan uygulanmasını kolaylaştırır. Örnekler şunları içerir:
Eksiksiz bir likidite staking sistemini kapsamak yerine, güvenilir likidite staking'i daha uygulanabilir hale getirmek için staking ceza kurallarını değiştirmek daha iyidir;
Daha fazla ön derleyiciyi kapsüllemek yerine, daha geniş bir işlem sınıfının verimli bir şekilde uygulanmasını kolaylaştırmak için EVM-MAX ve/veya SIMD'yi kapsüllemek daha iyidir;
Toplama konseptinin tamamını kapsamak yerine, EVM doğrulamasını basitçe kapsayabilir.
Önceki diyagramı şu şekilde genişletebiliriz:
Bazen bir şeyi kapsüllemek mantıklı olabilir ve nadiren kullanılan ön derleyicilerin kaldırılması buna bir örnektir. Bir bütün olarak hesap soyutlaması, daha önce de belirtildiği gibi, kapsülden çıkarmanın da önemli bir biçimidir. Mevcut kullanıcılar için geriye dönük uyumluluğu desteklemek istiyorsak, mekanizma aslında şaşırtıcı bir şekilde ön derlemeyi kaldıran mekanizmaya benzer olabilir: tekliflerden biri, EOA'ların hesaplarını aynı (veya daha iyi) fonksiyonel sözleşme.
Hangi özelliklerin protokole dahil edilmesi ve hangilerinin ekosistemin diğer katmanlarına bırakılması gerektiği karmaşık bir ödünleşimdir. Kullanıcı ihtiyaçlarına ilişkin anlayışımız ve mevcut fikir ve teknolojiler 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.
Buterin'in son uzun makalesi: Ethereum protokolü daha fazla işlevi kapsamalı mı?
Ethereum, protokolde daha fazla şeyin yer almasına razı olmalı mı?
Orijinal yazar: Vitalik Buterin
Odaily Planet Daily'nin Çevirmeni | Nian Yin Si Tang
*Geri bildirimleri ve değerlendirmeleri için Justin Drake, Tina Zhen ve Yoav Weiss'e özellikle teşekkür ederiz. *
Ethereum projesinin başlangıcından bu yana, çekirdek Ethereum'u olabildiğince basit hale getirmeye çalışmak ve bunun üzerine protokoller oluşturarak bunu mümkün olduğunca başarmak yönünde güçlü bir felsefe vardı. Blockchain alanında, "L1 üzerine inşa etme" ve "L2'ye odaklanma" tartışmasının genellikle öncelikle ölçeklendirmeyle ilgili olduğu düşünülür, ancak aslında birden fazla Ethereum kullanıcısının ihtiyaçlarının karşılanmasında benzer sorunlar vardır: dijital varlıkların değişimi, gizlilik , kullanıcı adları, gelişmiş şifreleme, hesap güvenliği, sansüre dayanıklılık, ileri düzeyde koruma ve daha fazlası. Bununla birlikte, son zamanlarda bu özelliklerin daha fazlasını temel Ethereum protokolüne dahil etmek için bazı ihtiyatlı girişimlerde bulunuldu.
Bu makale, minimal kapsüllemenin orijinal felsefesinin ardındaki bazı felsefi akıl yürütmelerin yanı sıra, bu fikirler hakkında bazı yeni düşünme biçimlerini de ele alacak. Amaç, belirli işlevleri kapsamanın dikkate alınmaya değer olabileceği olası hedefleri daha iyi belirlemek için bir çerçeve oluşturmaya başlamak olacaktır.
Protokol minimalizmine dair ilk felsefe
O zamanlar "Ethereum 2.0" olarak bilinen şeyin erken tarihinde, kendi üzerine mümkün olduğunca az şey inşa etmeye çalışan ve bu tür işlerin neredeyse tamamını kullanıcılara bırakan, temiz, basit ve güzel bir protokol oluşturma yönünde güçlü bir istek vardı. İdeal durumda protokol yalnızca bir sanal makinedir ve bir bloğun doğrulanması yalnızca bir sanal makine çağrısıdır.
Bu, Gavin Wood ve benim 2015'in başlarında Ethereum 2.0'ın neye benzeyeceği hakkında konuşurken çizdiğimiz beyaz tahta diyagramının yaklaşık bir yeniden inşasıdır.
"Durum geçiş işlevi" (bloğu işleyen işlev) yalnızca tek bir VM çağrısı olacaktır ve diğer tüm mantık sözleşmeler 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 güzel bir özelliği, tüm bir hard fork'un bile, zincir dışı veya zincir içi yönetişim tarafından onaylanacak ve ardından çalışma izni yükseltilecek olan blok işlemci sözleşmesine yönelik 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 durumunda amaç, yukarıdaki diyagramın doğal bir uzantısı gibi hissettiren maksimum soyut bir ölçeklendirme biçimi yaratmaya çalışmaktır. Sözleşmeler, çoğu Ethereum düğümü tarafından depolanmayan verileri çağırabilir ve protokol bunu tespit edecek ve çağrıyı çok genel bazı genişletilmiş bilgi işlem işlevleri aracılığıyla çözecektir. Sanal makinenin bakış açısından, çağrı ayrı bir alt sisteme gidecek ve bir süre sonra sihirli bir şekilde doğru yanıtı verecektir.
Bu fikri kısaca araştırdık ama hemen vazgeçtik çünkü her türlü blockchain ölçeklendirmesinin mümkün olduğunu kanıtlamaya fazlasıyla odaklanmıştık. Daha sonra göreceğimiz gibi, veri kullanılabilirliği örneklemesi ve ZK-EVM'nin birleşimi, Ethereum ölçeklendirmesinin olası geleceğinin aslında bu vizyona çok yakın göründüğü anlamına geliyor! Öte yandan, hesap soyutlamayla, bir tür uygulamanın mümkün olduğunu başından beri biliyorduk, bu nedenle araştırmalar, "bir işlem yalnızca bir çağrıdır" şeklindeki saf başlangıç noktasına mümkün olduğunca yakın bir şey yapmaya hemen başladı.
*İşlemin işlenmesi ile gönderen adresinden asıl EVM çağrısının yapılması arasında çok sayıda standart kod vardır ve bundan sonra daha fazla standart kod vardır. Bu kodu mümkün olduğunca sıfıra nasıl yaklaştırabiliriz? *
Buradaki ana kodlardan biri, işlemin nonce ve imzasının doğru olup olmadığını kontrol etmekten sorumlu olan validate_transaction(state, tx) kodudur. Hesap soyutlamanın en başından beri asıl amacı, kullanıcıların temel artımsız doğrulama ve ECDSA doğrulamasını kendi doğrulama mantığıyla değiştirmelerine olanak tanımak, böylece kullanıcıların sosyal kurtarma ve çoklu imza cüzdanları gibi özellikleri daha kolay kullanabilmelerini sağlamaktı. Dolayısıyla, application_transaction'ı basit bir EVM çağrısı halinde yeniden yapılandırmanın bir yolunu bulmak, yalnızca "kodu temizlemek adına kodu temiz yapma" görevi değildir; bunun yerine, mantığı kullanıcının hesap koduna taşımak ve kullanıcılara ihtiyaç duydukları esnekliği vermekle ilgilidir. ihtiyaç.
Ancak, application_transaction'ın mümkün olduğu kadar az sabit mantık içermesinde ısrar etmek birçok zorluğun ortaya çıkmasına neden oldu. En eski hesap soyutlama önerilerinden biri olan EIP-86'ya bakabiliriz.
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 bir bütünün tanıtılmasına ek olarak esasen aynı kodun başka bir yere yazılmasını gerektirecektir. yeni bir tuhaflık sınıfı Örneğin, aynı hash değerine sahip aynı işlem, çoklu geçersiz kılma sorununun yanı sıra zincirde birden çok kez görünebilir.
*Hesap soyutlamasında birden fazla geçersiz kılma sorunu. Zincir üzerinde yer alan bir işlem, bellek havuzundaki diğer binlerce işlemi geçersiz kılabilir ve bellek havuzunun ucuz bir şekilde doldurulmasını kolaylaştırabilir. *
O zamandan beri hesap soyutlaması aşamalar halinde gelişti. EIP-86 daha sonra EIP-208 oldu ve sonunda pratik EIP-2938 ortaya çıktı.
Ancak EIP-2938 minimalist olmaktan çok uzaktır. İçeriği şunları içerir:
Ethereum çekirdek geliştiricilerini (Ethereum istemcilerini optimize etmeye ve birleştirmeleri uygulamaya odaklanan) dahil etmeden hesap soyutlamayı başarma çabasıyla, EIP-2938 sonuçta tamamen protokol dışı olan ERC-4337 olarak yeniden tasarlandı.
ERC-4337. Tamamen EVM çağrılarına dayanıyor!
Bu bir ERC olduğu için hard fork gerektirmez ve teknik olarak "Ethereum protokolünün dışında" bulunur. Peki...sorun çözüldü mü? Durumun böyle olmadığı ortaya çıktı. ERC-4337'nin mevcut orta vadeli yol haritası aslında ERC-4337'nin büyük bölümlerinin bir dizi protokol özelliğine dönüştürülmesini içeriyor; bu, bu yolun neden dikkate alınması gerektiğine dair yararlı bir rehberlik örneğidir.
Paket ERC-4337
ERC-4337'nin nihai olarak protokole yeniden dahil edilmesinin tartışılan birkaç temel nedeni vardır:
Şu anki haliyle ERC-4337'nin "temel" Ethereum işlemlerinden önemli ölçüde daha pahalı olduğunu belirtmekte fayda var: bir işlemin maliyeti 21.000 gas, ERC-4337'nin maliyeti ise yaklaşık 42.000 gas.
Teorik olarak, EVM gaz maliyet sistemini, protokol içi maliyet ile protokol dışındaki depolamaya erişim maliyeti eşleşene kadar ayarlamak mümkün olmalıdır; diğer depolama düzenleme türleri kullanıldığında ETH'yi aktarmak için 9000 gaz harcamaya gerek yoktur. işlemler daha ucuzdur. Aslında yaklaşan 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şlevlerinin kaçınılmaz olarak EVM kodundan çok daha ucuz olmasının açık bir nedeni vardır: kapsüllenmiş kodun ön yükleme için gaz ödemesine gerek yoktur.
Tamamen işlevsel bir ERC-4337 cüzdanı büyüktür ve derlenen ve zincire eklenen uygulama yaklaşık 12.800 bayt yer kaplar. Elbette, bu kodu bir kez dağıtabilir ve her bir cüzdanın onu aramasına izin vermek için DELEGATECALL'ı kullanabilirsiniz, ancak yine de kullanıldığı her blokta koda erişmeniz gerekir. Verkle ağacı gaz maliyeti EIP kapsamında, 12.800 bayt 413 parça oluşturacaktır. Bu parçalara erişim, tanık dal maliyetinin 2 katı (toplam 3.800 gaz) ve tanık parça maliyetinin 413 katı (toplam 82.600) ödemeyi gerektirecektir. gaz). Bu, 0.6.0 sürümünde zincirde 23.689 bayta sahip olan (Verkle ağacı EIP kurallarına göre yüklenecek yaklaşık 158.700 gaz) ERC-4337 giriş noktasının kendisinden bahsetmeye bile başlamıyor.
Bu da bir soruna yol açıyor: Bu kodlara fiilen erişmenin gas maliyetinin işlemler genelinde bir şekilde amortismana tabi tutulması gerekiyor. ERC-4337 tarafından kullanılan mevcut yaklaşım pek iyi değil: Paketteki ilk işlem, tek seferlik depolama/kod okuma maliyeti tüketiyor ve bu da onu diğer işlemlere göre çok daha pahalı hale getiriyor. Protokol içi kapsülleme, bu halka açık paylaşılan kitaplıkların protokolün bir parçası olmasına ve herkesin serbestçe erişebilmesine olanak tanıyacaktır.
Bu örnekten ne öğrenebiliriz ve kapsülleme daha genel olarak ne zaman uygulanmalıdır?
Bu örnekte, hesap soyutlamalarının protokollerde kapsüllenmesine yönelik bazı farklı gerekçeler görüyoruz.
Ancak, kapsülleme protokolündeki hesap soyutlamasının bile, mevcut durumla karşılaştırıldığında hala çok büyük bir "kapsülden çıkarma" olduğunu hatırlamak önemlidir. Bugün, üst düzey Ethereum işlemleri yalnızca tek bir secp 256k 1 eliptik eğri imzası kullanılarak doğrulanan harici sahipli hesaplardan (EOA) başlatılabilir. Hesap soyutlaması bunu ortadan kaldırır ve doğrulama koşullarını tanımlamayı kullanıcıya bırakır. Dolayısıyla hesap soyutlamayla ilgili bu hikayede kapsüllemeye karşı en büyük nedeni de görüyoruz: Farklı kullanıcıların ihtiyaçlarını karşılama esnekliği.
Yakın zamanda kapsüllenmesi düşünülen diğer birkaç özellik örneğine bakarak hikayeyi daha da detaylandıralım. Özellikle şunları inceleyeceğiz: ZK-EVM, teklif veren-oluşturucu ayrımı, özel hafıza havuzları, likidite staking ve yeni ön derleme.
Paket ZK-EVM
Dikkatimizi Ethereum protokolü için başka bir potansiyel kapsülleme hedefine çevirelim: ZK-EVM. Şu anda, ZK-SNARK'larda benzer Ethereum bloklarının yürütülmesini doğrulamak için hepsinin oldukça benzer kod yazması gereken çok sayıda ZK toplamamız var. Oldukça çeşitli bağımsız uygulamalar ekosistemi mevcuttur: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth ve çok daha fazlası.
EVM ZK toplama alanında yakın zamanda yaşanan bir tartışma, ZK kodunda ortaya çıkabilecek hatalarla nasıl başa çıkılacağıyla ilgilidir. Şu anda faaliyette olan bu sistemlerin tamamında, herhangi bir hata durumunda doğrulama sistemini kontrol eden bir tür "güvenlik konseyi" mekanizması bulunmaktadır. Geçtiğimiz yıl, projeleri tasdik sistemine ve Güvenlik Konseyi'ne ne kadar güvendiklerini netleştirmeye ve zamanla bu organizasyon üzerindeki yetkilerini kademeli olarak azaltmaya teşvik edecek standart bir çerçeve oluşturmaya çalıştım.
*Orta vadede, toplamanın birden fazla sertifikasyon sistemine dayanması muhtemeldir; Güvenlik Konseyi yalnızca iki farklı sertifikasyon sisteminin farklılaştığı aşırı durumlarda yetkiye sahiptir. *
Ancak bu çalışmaların bir kısmının gereksiz olduğu hissi var. Zaten bir Ethereum temel katmanımız var, bir EVM'si var ve uygulamadaki hatalarla başa çıkmak için zaten bir çalışma mekanizmamız var: bir hata varsa, istemci bunu düzeltmek için güncellenecek ve zincir çalışmaya devam edecek . Hatalı istemcinin bakış açısına göre, sonlandırılan 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, eğer toplamalar sadece EVM'nin eşdeğer rolünü sürdürmek istiyorlarsa, Ethereum temel katmanındaki 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ış hissettirir çünkü sonuçta onlar en üstte inşa edilmiştir. Ethereum temel katmanının kendisi ne zaman yükseltileceğini ve hangi yeni kurallara göre yapılacağını bilir.
Bu L2 ZK-EVM'ler temelde Ethereum ile tamamen aynı EVM'yi kullandığından, bir şekilde "ZK'de EVM yürütmesini doğrulama" özelliğini protokol işlevselliğine dahil edebilir miyiz ve Ethereum'un sosyal konsensüsünü (halihazırda yaptığımız gibi) hatalar ve yükseltmeler gibi uygulayarak istisnaları ele alabilir miyiz? temel katman EVM yürütmesinin kendisi?
Bu önemli ve zorlu bir konudur.
Yerel ZK-EVM'de veri kullanılabilirliğine ilişkin olası bir tartışma konusu durumsallıktır. ZK-EVM'ler "tanık" verilerini taşımaya ihtiyaç duymasaydı veri açısından çok daha verimli olurdu. Yani, eğer belirli bir veri parçası önceki bir blokta okunmuş veya yazılmışsa, kanıtlayıcının ona erişimi olduğunu ve onu tekrar kullanılabilir hale getirmek zorunda olmadığını basitçe varsayabiliriz. Sorun yalnızca depolamayı ve kodu yeniden yüklememekle ilgili değil; bir toplamanın verileri doğru şekilde sıkıştırması durumunda durum bilgisi olan sıkıştırmanın, 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:
**1.**Ön derleme tüm verilerin aynı blokta mevcut olmasını gerektirir. Bu, kanıtlayıcının durum bilgisi olmayan olabileceği anlamına gelir, ancak aynı zamanda bu önceden derlenmiş ZK toplamasını kullanmanın, özel kod toplamayı kullanmaktan çok daha pahalı olduğu anlamına da gelir.
**2.**Ön derleme, işaretçilerin önceki yürütmeler tarafından kullanılan veya oluşturulan verilere işaret etmesine olanak tanır. Bu, ZK toplamasını optimale yakın 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 özetlemek için iyi bir neden var: toplama zaten kendi özel sürümünü oluşturuyor ve Ethereum, çoklu uygulamalarının ve zincir dışı sosyal konsensüsün ağırlığıyla L1'de EVM'yi uygulamaya istekli. Yanlış, ancak L2'nin tamamen aynı işi yapması, Güvenlik Konseyi'nin de dahil olduğu karmaşık bir aygıtı uygulamaya koymak zorunda kalacaktı. Ancak bir yandan da detaylarda büyük bir sorun var: ZK-EVM'nin farklı versiyonları var ve bunların maliyet ve faydaları farklı. Durum bilgisi olan ve durum bilgisi olmayan arasındaki ayrım yalnızca yüzeyseldir; diğer sistemler tarafından kanıtlanmış "neredeyse EVM" özel kodunu destekleme girişimleri daha büyük bir tasarım alanını ortaya çıkarabilir. Bu nedenle ZK-EVM'nin ambalajlanması hem umut hem de zorluklar getirir.
Kapsülleme öneren ve oluşturucu ayrımı (ePBS)
MEV'nin yükselişi, karmaşık aktörlerin, yalnızca bir işlem hafızasını gözlemleyen ve bunları içeren varsayılan algoritmadan daha fazla gelir üreten bloklar üretebilmesiyle, blok üretimini geniş ölçekte ekonomik bir faaliyet haline getiriyor. Şimdiye kadar, Ethereum topluluğu bu sorunu MEV-Boost gibi protokol dışı teklif sahibi-inşacı ayırma şemalarını kullanarak çözmeye çalıştı. ").
Ancak MEV-Boost, röle adı verilen yeni bir aktör sınıfına güven varsayımlarında bulunur. Geçtiğimiz iki yılda "paketlenmiş PBS" oluşturmak için birçok teklif geldi. Bunu yapmanın faydaları nelerdir? Bu durumda cevap çok basit: Protokol özelliklerini doğrudan kullanarak oluşturulan bir PBS, bunları kullanmadan oluşturulan bir PBS'den daha güçlüdür (daha zayıf güven varsayımlarına sahip olmak anlamında). Bu, fiyat kehanetlerinin bir protokol içerisinde kapsüllenmesi durumuna benzer; ancak bu durumda güçlü itirazlar vardır.
Özel hafıza havuzunu kapsülleyin
Bir kullanıcı bir işlem gönderdiğinde, bu işlem, zincire dahil edilmeden önce bile anında herkese açık hale gelir ve herkes tarafından görülebilir. Bu, birçok uygulamanın kullanıcılarını önden çalıştırma gibi ekonomik saldırılara karşı savunmasız bırakıyor.
Son zamanlarda, kullanıcıların işlemlerini geri dönülemez bir şekilde bir bloğa kabul edilene kadar şifreleyen "özel bellek havuzları" (veya "kripto bellek havuzları") oluşturmaya adanmış bir dizi proje var.
Ancak sorun, böyle bir planın özel bir tür şifreleme gerektirmesidir: Kullanıcıların sistemi doldurmasını ve önce şifresini çözmesini önlemek için, işlem gerçekten geri döndürülemez şekilde kabul edildikten sonra şifrelemenin şifresinin otomatik olarak çözülmesi gerekir.
Bu şifreleme biçimini uygulamak için farklı değiş tokuşlara sahip çeşitli teknikler vardır. Jon Charbonneau bir keresinde bunu çok iyi tanımlamıştı:
Ne yazık ki her şifreleme yönteminin farklı zayıf yönleri vardır. Her çözüm için ona güvenmeye istekli bir kullanıcı segmenti mevcut olsa da hiçbir çözüme Katman 1 tarafından gerçekten kabul edilecek kadar güvenilmez. **Dolayısıyla, en azından gecikmeli şifreleme mükemmelleştirilene veya başka bir teknolojik atılım yapılana kadar, ileriye dönük ticaret işlevselliğini Katman 1'e dahil etmek, birçok uygulamanın çözeceği kadar değerli bir özellik olsa bile, zor bir teklif gibi görünüyor planı ortaya çıktı.
Likidite staking'i kapsülleyin
Ethereum DeFi kullanıcılarının ortak ihtiyacı, ETH'lerini aynı anda staking ve diğer uygulamalarda teminat olarak kullanabilme yeteneğidir. Diğer bir yaygın talep ise sadece kolaylık sağlamak içindir: Kullanıcılar, bir düğümü çalıştırma ve onu her zaman çevrimiçi tutma karmaşıklığı olmadan stake yapabilmek (ve çevrimiçi stake anahtarlarını korumak) isterler.
Bu ihtiyaçların her ikisini de karşılayan açık ara en basit staking "ara yüzü" yalnızca bir ERC 20 tokenidir: ETH'nizi "staking ETH"ye dönüştürün, tutun ve sonra geri dönüştürün. Aslında Lido ve Rocket Pool gibi likidite staking sağlayıcıları bunu zaten yapıyor. Bununla birlikte, likidite stake etme konusunda bazı doğal merkezileştirme mekanizmaları vardır: İnsanlar doğal olarak ETH'nin en geniş versiyonunu stake etmeye yönelecektir çünkü en tanıdık ve likit olanıdır.
Stacked ETH'nin her versiyonunun, kimin temel düğüm operatörü olabileceğini belirlemek için bir mekanizmaya sahip olması gerekir. Sınırsız olamaz çünkü o zaman saldırganlar katılıp kullanıcı fonlarını saldırılarını genişletmek için kullanacaklardır. Şu anda ilk ikisi Lido ve Rocket Pool'dur; birincisi DAO beyaz listeye alınmış düğüm operatörlerine sahiptir ve ikincisi herkesin 8 ETH depozitoyla bir düğüm çalıştırmasına izin vermektedir. Bu iki yöntemin farklı riskleri vardır: Roket Havuzu yöntemi, bir saldırganın ağ üzerinde %51'lik bir saldırı yapmasına izin verir ve kullanıcıları maliyetlerin çoğunu ödemeye zorlar; DAO yönteminde ise, belirli bir stake edilmiş token baskın hale gelirse, bu durum saldırılara yol açacaktır. tek bir potansiyel olarak ele geçirilmiş yönetim aygıtı, tüm Ethereum doğrulayıcılarının büyük bir bölümünü kontrol eder. Lido gibi protokoller kendi takdirine göre koruma önlemleri uygulamıştır, ancak tek bir savunma katmanı yeterli olmayabilir.
Kısa vadede seçeneklerden biri, baskın bir oyuncunun sistemik risk oluşturma olasılığını azaltmak için ekosistem katılımcılarını çeşitli likidite staking sağlayıcıları kullanmaya teşvik etmektir. Ancak uzun vadede bu istikrarsız bir dengedir ve sorunları çözmek için ahlaki baskıya aşırı güvenmek tehlikelidir. Doğal bir soru ortaya çıkıyor: **Likidite stakingini daha az merkezi hale getirmek için protokolde bazı işlevleri kapsamak mantıklı mı? **
Buradaki anahtar soru şudur: ne tür bir protokol içi işlevsellik? Protokol içerisinde basitçe takas edilebilir bir "staking ETH" tokeni oluşturmanın bir sorunu, düğümleri kimin çalıştıracağını seçmek için ya Ethereum çapında kapsüllenmiş bir yönetişime sahip olması gerekmesi ya da açık uçlu olmasıdır, ancak bu onu Saldırganın kontrolüne dönüştürür. Aletler.
İlginç bir fikir, Dankrad Feist'in likidite stake etme maksimizasyonu hakkındaki makalesidir. Öncelikle mermiyi ısıralım: Ethereum %51 saldırısına maruz kalırsa, saldırıya uğrayan ETH'nin yalnızca %5'i kesilebilir. Bu makul bir değiş-tokuş; halihazırda 26 milyonun üzerinde ETH'nin bahis konusu olduğu göz önüne alındığında, bunun üçte birine (~8 milyon ETH) saldırmanın maliyeti çok yüksek, özellikle de aynı anda kaç tane "model dışı" saldırının yapılabileceği göz önüne alındığında. daha az maliyet. Aslına bakılırsa, Süper Komite'nin tek slot kesinliği uygulama teklifinde de benzer ödünleşimler araştırıldı.
Saldırı ETH'sinin yalnızca %5'inin kesildiğini kabul edersek, stake edilen ETH'nin %90'ından fazlası kesintiden etkilenmeyecektir, dolayısıyla bunlar protokol içerisinde değiştirilebilir likit staking tokenleri olarak kullanılabilir ve daha sonra diğer uygulamalar tarafından kullanılabilir.
Bu yol ilginç. Ancak yine de bir soru bırakıyor: Tam olarak kapsüllenmiş olan nedir? **Roket Havuzu da benzer şekilde çalışır: her düğüm operatörü bir miktar fon sağlar ve geri kalanını likidite stakerları sağlar. Maksimum kesme cezasını 2 ETH ile sınırlamak için bazı sabitleri kolayca ayarlayabiliriz ve Rocket Pool'un mevcut rETH'si risksiz hale gelecektir.
Basit protokol ayarlamalarıyla başka akıllıca şeyler de yapabiliriz. Örneğin, iki "kademeli" stake etme sistemine sahip bir sistem istediğimizi varsayalım: düğüm operatörleri (yüksek teminat gereklilikleri) ve mevduat sahipleri (minimum teminat gerekliliği yok, istedikleri zaman katılıp ayrılabilirler), ancak yine de Rastgele örneklenmiş bir sistem bağışlamak istiyoruz. mevduat sahibi komitesi, dahil edilmesi gereken işlemlerin bir listesini önermek (sansüre direnç nedeniyle), hareketsizlik sızıntıları sırasında çatal seçimini kontrol etmek veya bloklarda imza gerektirmek gibi düğüm operatörlerinin merkezileşmesini önleme yetkisine sahiptir. Bu, her doğrulayıcının (i) düzenli bir staking anahtarı sağlamasını ve (ii) her yuvada kullanılabilecek bir ETH adresinin çıktı olarak çağrılmasını gerektirecek şekilde protokolü değiştirerek esasen protokol dışına çıkan bir şekilde gerçekleştirilebilir. ikincil rehin anahtarı. Protokol her iki anahtarı da güçlendirecektir ancak her yuvadaki ikinci anahtarı seçme mekanizması stake havuzu protokolüne bırakılabilir. Bazı işlevleri doğrudan kapsamak daha iyi olabilir, ancak "bazı şeyleri dahil etme ve diğer şeyleri kullanıcıya bırakma" tasarım alanının mevcut olduğunu belirtmekte fayda var.
Daha fazla ön derlemeyi kapsülleyin
Önceden derlenmiş sözleşmeler (veya "önceden derlenmiş sözleşmeler"), EVM akıllı sözleşme kodu yerine müşteri kodunda yerel olarak uygulanan mantıkla karmaşık şifreleme işlemlerini uygulayan Ethereum sözleşmeleridir. Ön kodlama, Ethereum gelişiminin başlangıcından beri benimsenen bir uzlaşmadır: sanal bir makinenin yükü bazı çok karmaşık ve son derece uzmanlaşmış kodlar için çok büyük olduğundan, bazı önemli uygulamaları yerel kodda uygulayabiliriz. Bunları daha hızlı hale getirmek için kritik işlemlere değer verin. Günümüzde bu temel olarak bazı spesifik hash fonksiyonlarını ve eliptik eğri işlemlerini içermektedir.
Şu anda, temel ethereum hesapları için kullanılan secp 256 k 1'den biraz farklı bir eliptik eğri olan secp 256 r 1 için ön derleme eklemeye yönelik bir itme vardır ve güvenilir donanım modülleri tarafından iyi bir şekilde desteklendiğinden yaygın olarak kullanılmaktadır. Cüzdan güvenliğini artırmak için bunu kullanın. Son yıllarda topluluk, BLS-12-377, BW 6-761, genelleştirilmiş eşleştirme ve diğer özellikler için ön derleme ekleme konusunda da baskı yaptı.
Daha fazla ön derleyiciye yönelik bu çağrıların karşı argümanı, önceden eklenen ön derleyicilerin çoğunun (RIPEMD ve BLAKE gibi) beklenenden çok daha az kullanılmasıdır ve bundan ders almamız gerekir. Belirli işlemler için daha fazla ön derleme eklemek yerine, EVM uygulamalarının daha düşük maliyetle çalışmasını sağlayacak olan EVM-MAX ve Hazırda-Ama-Her Zaman-Sürdürülebilir SIMD teklifi gibi fikirlere dayanan daha yumuşak bir yaklaşıma odaklanmalıyız. geniş bir kod sınıfı yelpazesi. Belki mevcut az kullanılan ön derleme bile kaldırılabilir ve aynı işlevlerin (kaçınılmaz olarak daha az verimli) bir EVM kod uygulamasıyla değiştirilebilir. Bununla birlikte, hızlandırılacak kadar değerli olan belirli şifreleme işlemlerinin mevcut 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ğu kadar az şeyi kapsama arzusu anlaşılabilir ve iyidir; kullanıcıların farklı ihtiyaçlarına kolayca uyum sağlayabilen ve yazılım şişkinliğinin lanetinden kaçınabilen minimalist yazılım yaratmaya yönelik Unix'in felsefi geleneğinden kaynaklanmaktadır. Ancak blockchain kişisel bir bilgisayar işletim sistemi değil, sosyal bir sistemdir. Bu, protokolde belirli işlevleri kapsüllemenin anlamlı olduğu anlamına gelir.
Çoğu durumda, bu diğer örnekler hesap soyutlamasında gördüklerimize benzer. Ama aynı zamanda bazı yeni dersler de öğrendik:
Çoğu zaman, temel protokolü minimum düzeyde ve basit tutmak, karmaşıklığı protokolün dışındaki bazı ekosistemlere iter. Unix felsefesi açısından bakıldığında bu gayet iyi. Bununla birlikte, bazen yüksek sabit maliyetler nedeniyle genellikle (ancak yalnızca bu değil) protokol dışı ekosistemin merkezileşme riski vardır. Kapsülleme bazen fiili merkezileşmeyi azaltabilir.
Bu, "Ethereum Mutabakatını Aşırı Yüklemeyin" konulu önceki makalenin konusu: Eğer belirli bir özelliği kapsamak güven modelini zayıflatırsa ve Ethereum'u bir bütün olarak daha "öznel" hale getirirse, bu Ethereum'u zayıflatır. Bu durumlarda, Ethereum'un kendisine getirmeye çalışmak yerine, Ethereum'un üzerinde bir mekanizma olarak belirli işlevselliğe sahip olmak daha iyidir. Şifrelenmiş bellek havuzları buradaki en iyi örnektir; en azından gecikme şifrelemesi gelişene kadar kapsüllenmesi biraz zor olabilir.
Protokol karmaşıklığı, bir protokole çok fazla özellik eklenmesiyle artan sistemik bir risktir. Ön derleme bunun en iyi örneğidir.
Pek çok kişinin önemli olduğunu düşündüğü ve pek çok kullanıcı tarafından kullanılacak olan bu özellik muhtemelen pratikte çok sık kullanılmıyor.
Ek olarak, likidite staking, ZK-EVM ve önceden derlenmiş örnekler bir orta yol olasılığını gösteriyor: minimum geçerli koruma. Protokolün tüm işlevselliği kapsaması gerekmez, ancak temel zorlukları ele alan belirli bölümleri içerebilir, bu da işlevselliğin çok paranoyak veya çok dar kapsamlı olmadan uygulanmasını kolaylaştırır. Örnekler şunları içerir:
Önceki diyagramı şu şekilde genişletebiliriz:
Bazen bir şeyi kapsüllemek mantıklı olabilir ve nadiren kullanılan ön derleyicilerin kaldırılması buna bir örnektir. Bir bütün olarak hesap soyutlaması, daha önce de belirtildiği gibi, kapsülden çıkarmanın da önemli bir biçimidir. Mevcut kullanıcılar için geriye dönük uyumluluğu desteklemek istiyorsak, mekanizma aslında şaşırtıcı bir şekilde ön derlemeyi kaldıran mekanizmaya benzer olabilir: tekliflerden biri, EOA'ların hesaplarını aynı (veya daha iyi) fonksiyonel sözleşme.
Hangi özelliklerin protokole dahil edilmesi ve hangilerinin ekosistemin diğer katmanlarına bırakılması gerektiği karmaşık bir ödünleşimdir. Kullanıcı ihtiyaçlarına ilişkin anlayışımız ve mevcut fikir ve teknolojiler gelişmeye devam ettikçe, bu değiş tokuşun zaman içinde gelişmeye devam etmesi bekleniyor.