Yoav Weiss, Dan Finlay, Martin Koppelmann ve Arbitrum, Optimism, Polygon, Scroll ve SoulWallet ekiplerine geri bildirim ve inceleme için özel teşekkürler.

Üç Geçiş hakkındaki bu yazıda, L1 + çapraz L2 desteği, cüzdan güvenliği ve gizlilik konularının her birini ayrı ayrı cüzdanlar tarafından ayrı ayrı tasarlanabilecek eklentiler olarak inşa etmek yerine, ekosistem yığınının gerekli temel özellikleri olarak açıkça düşünmeye başlamanın neden değerli olduğuna dair bazı temel nedenleri özetledim.

Bu yazı, belirli bir alt problemin teknik yönlerine daha doğrudan odaklanacaktır: L2'den L1'i, L1'den L2'yi veya başka bir L2'den L2'yi okumanın nasıl daha kolay hale getirileceği. Bu sorunu çözmek, bir varlık / anahtar deposu ayırma mimarisini uygulamak için çok önemlidir, ancak aynı zamanda, L1 ve L2'ler arasında varlıkların taşınması gibi kullanım durumları da dahil olmak üzere, özellikle güvenilir çapraz L2 çağrılarını optimize etmek gibi diğer alanlarda da değerli kullanım durumları vardır.

Önerilen ön okumalar

• Üç GeçişÜzerine Yazı
• Safe ekibinden varlıkların birden fazla zincirde tutulmasınailişkin fikirler
• Neden sosyal kurtarma cüzdanlarınıngeniş çapta benimsenmesine ihtiyacımız var?
• ZK-SNARK'lar ve bazı gizlilik uygulamaları
• Dankrad KZG taahhütleri hakkında
• Verkle ağaçları

İçindekiler tablosu

• Amaç nedir?
• Çapraz zincir kanıtı neye benziyor?
• Ne tür kanıt şemaları kullanabiliriz?
  • Merkle kanıtları
  • ZK SNARKs
  • Özel amaçlı KZG provaları
  • Verkle ağacı kanıtları
  • Birleştirme
  • Doğrudan durum okuma
• L2 son Ethereum durum kökünü nasıl öğrenir?
• L2 olmayan zincirlerdeki cüzdanlar
• Mahremiyetin korunması
• Özet

Amaç nedir?

L2'ler daha yaygın hale geldiğinde, kullanıcılar birden fazla L2'de ve muhtemelen L1'de de varlıklara sahip olacaktır. Akıllı sözleşme cüzdanları (multisig, sosyal kurtarma veya başka türlü) yaygınlaştığında, bazı hesaplara erişmek için gereken anahtarlar zaman içinde değişecek ve eski anahtarların artık geçerli olmaması gerekecektir. Bunların her ikisi de gerçekleştiğinde, bir kullanıcının çok sayıda farklı yerde bulunan birçok hesaba erişim yetkisine sahip anahtarları, çok yüksek sayıda işlem yapmadan değiştirmenin bir yolunu bulması gerekecektir.

Özellikle, karşı olgusal adresleri ele almak için bir yola ihtiyacımız var: henüz zincir üzerinde herhangi bir şekilde "kaydedilmemiş", ancak yine de fonları alması ve güvenli bir şekilde tutması gereken adresler. Hepimiz karşı olgusal adreslere bağlıyız: Ethereum'u ilk kez kullandığınızda, adresi zincir üzerinde "kaydettirmeden" (bu da txfees ödemeyi ve dolayısıyla zaten bir miktar ETH tutmayı gerektirir) birinin size ödeme yapmak için kullanabileceği bir ETH adresi oluşturabilirsiniz.

EOA'lar ile tüm adresler karşı olgusal adresler olarak başlar. Akıllı sözleşme cüzdanlarında, büyük ölçüde CREATE2 sayesinde, yalnızca belirli bir hash ile eşleşen koda sahip bir akıllı sözleşme tarafından doldurulabilen bir ETH adresine sahip olmanızı sağlayan karşı olgusal adresler hala mümkündür.

EIP-1014 (CREATE2) adres hesaplama algoritması.

Ancak akıllı sözleşme cüzdanları yeni bir zorluğu da beraberinde getirmektedir: erişim anahtarlarının değişme olasılığı. Giriş kodunun bir hash'i olan adres, yalnızca cüzdanın ilk doğrulama anahtarını içerebilir. Mevcut doğrulama anahtarı cüzdanın depolama alanında saklanır, ancak bu depolama kaydı sihirli bir şekilde diğer L2'lere yayılmaz.

Bir kullanıcının birçok L2'de (karşı olgusal oldukları için) bulundukları L2'nin bilmediği adresler de dahil olmak üzere birçok adresi varsa, kullanıcıların anahtarlarını değiştirmelerine izin vermenin tek bir yolu var gibi görünüyor: varlık / anahtar deposu ayırma mimarisi. Her kullanıcının (i) tüm cüzdanlar için doğrulama anahtarını ve anahtarı değiştirme kurallarını saklayan bir "anahtar deposu sözleşmesi" (L1 veya belirli bir L2 üzerinde) ve (ii) doğrulama anahtarını almak için çapraz zinciri okuyan L1 ve birçok L2 üzerinde "cüzdan sözleşmeleri" vardır.

Bunu uygulamanın iki yolu vardır:

• Hafif sürüm (yalnızca anahtarları güncellemek için kontrol edin): her cüzdan doğrulama anahtarını yerel olarak saklar ve anahtar deposunun mevcut durumunun çapraz zincir kanıtını kontrol etmek ve yerel olarak saklanan doğrulama anahtarını eşleşecek şekilde güncellemek için çağrılabilen bir işlev içerir. Bir cüzdan belirli bir L2'de ilk kez kullanıldığında, anahtar deposundan geçerli doğrulama anahtarını almak için bu işlevin çağrılması zorunludur.
  • İyi tarafı: çapraz zincir kanıtlarını idareli kullanır, bu nedenle çapraz zincir kanıtları pahalıysa sorun olmaz. Tüm fonlar yalnızca mevcut anahtarlarla harcanabilir, bu nedenle hala güvenlidir.
  • Dezavantajı: Doğrulama anahtarını değiştirmek için, hem anahtar deposunda hem de halihazırda başlatılmış olan her cüzdanda (karşı olgusal olanlar olmasa da) zincir üzerinde bir anahtar değişikliği yapmanız gerekir. Bu çok fazla benzine mal olabilir.
• Ağır versiyon (her tx için kontrol): her işlem için o anda anahtar deposunda bulunan anahtarı gösteren bir çapraz zincir kanıtı gereklidir.
  • İyi tarafı: daha az sistemik karmaşıklık ve anahtar deposu güncellemesi ucuzdur.
  • Dezavantajı: TX başına pahalı, bu nedenle çapraz zincir kanıtlarını kabul edilebilir derecede ucuz hale getirmek için çok daha fazla mühendislik gerektirir. Ayrıca, şu anda doğrulama sırasında değiştirilebilir nesnelerin sözleşmeler arası okunmasını desteklemeyen ERC-4337 ile kolayca uyumlu değildir.

Çapraz zincir kanıtı neye benziyor?

Tüm karmaşıklığı göstermek için en zor durumu inceleyeceğiz: anahtar deposunun bir L2'de ve cüzdanın farklı bir L2'de olduğu durum. Anahtar deposu ya da cüzdan L1 üzerindeyse, bu tasarımın yalnızca yarısına ihtiyaç duyulur.

Anahtar deposunun Linea'da ve cüzdanın Kakarot'ta olduğunu varsayalım. Cüzdan anahtarlarının tam bir kanıtı şunlardan oluşur:

• Kakarot'un bildiği mevcut Ethereum durum kökü göz önüne alındığında, mevcut Linea durum kökünü kanıtlayan bir kanıt
• Geçerli Linea durum kökü göz önüne alındığında, anahtar deposundaki geçerli anahtarları kanıtlayan bir kanıt

Burada iki temel zor uygulama sorusu vardır:

1. Ne tür bir kanıt kullanıyoruz? (Merkle kanıtları mı? başka bir şey mi?)
2. L2 en son L1 (Ethereum) durum kökünü (ya da göreceğimiz gibi potansiyel olarak tüm L1 durumunu) ilk etapta nasıl öğrenir? Ve alternatif olarak, L1, L2 durum kökünü nasıl öğrenir?
   • Her iki durumda da, bir tarafta bir şeyin gerçekleşmesi ile bu şeyin diğer taraf için kanıtlanabilir olması arasındaki gecikmeler ne kadardır?

Ne tür kanıt şemaları kullanabiliriz?

Beş ana seçenek bulunmaktadır:

• Merkle kanıtları
• Genel amaçlı ZK-SNARK'lar
• Özel amaçlı kanıtlar (örn. KZG ile)
• Verkle kanıtları, hem altyapı iş yükü hem de maliyet açısından KZG ve ZK-SNARK'lar arasında bir yerdedir.
• Kanıt yok ve doğrudan devlet okumasına dayanıyor

Gereken altyapı çalışmaları ve kullanıcılar için maliyet açısından, bunları kabaca aşağıdaki gibi sıralıyorum:

"Toplama", her blokta kullanıcılar tarafından sağlanan tüm kanıtların, hepsini birleştiren büyük bir meta kanıtta toplanması fikrini ifade eder. Bu SNARK'lar ve KZG için mümkündür, ancak Merkle dalları için mümkün değildir ( Merkle dallarını biraz birleştirebilirsiniz, ancak bu size yalnızca log(blok başına txs) / log(toplam anahtar deposu sayısı), belki de pratikte %15-30 tasarruf sağlar, bu nedenle muhtemelen maliyete değmez).

Toplama işlemi ancak şema önemli sayıda kullanıcıya sahip olduğunda değerli hale gelir, bu nedenle gerçekçi olarak sürüm 1 uygulamasının toplamayı dışarıda bırakması ve bunu sürüm 2 için uygulaması uygundur.

Merkle kanıtları nasıl çalışır?

Bu basittir: önceki bölümdeki diyagramı doğrudan takip edin. Daha açık bir ifadeyle, her bir "kanıt" (bir L2'nin başka bir L2'ye kanıtlanmasının maksimum zorlukta olduğu varsayılırsa) şunları içerecektir:

• L2'nin bildiği en son Ethereum durum kökü göz önüne alındığında, anahtar deposu tutan L2'nin durum kökünü kanıtlayan bir Merkle dalı. Anahtar deposu tutan L2'nin durum kökü bilinen bir adresin bilinen bir depolama yuvasında saklanır (L2'yi temsil eden L1'deki sözleşme) ve böylece ağaçtaki yol sabit kodlanabilir.
• Anahtar deposu tutan L2'nin durum kökü göz önüne alındığında, mevcut doğrulama anahtarlarını kanıtlayan bir Merkle dalı. Burada bir kez daha doğrulama anahtarı bilinen bir adresin bilinen bir depolama yuvasında saklanır, böylece yol sabit kodlanabilir.

Ne yazık ki, Ethereum durum kanıtları karmaşıktır, ancak bunları doğrulamak için kütüphaneler vardır ve bu kütüphaneleri kullanırsanız, bu mekanizmanın uygulanması çok karmaşık değildir.

Daha büyük sorun ise maliyettir. Merkle kanıtları uzundur ve Patricia ağaçları ne yazık ki gerekenden ~3,9 kat daha uzundur (tam olarak: N nesne içeren bir ağaçta ideal bir Merkle kanıtı 32 log2(N) bayt uzunluğundadır ve Ethereum'un Patricia ağaçlarında çocuk başına 16 yaprak olduğundan, bu ağaçlar için kanıtlar 32 15 log16(N) ~= 125 log2(N) bayt uzunluğundadır). Kabaca 250 milyon (~2²⁸) hesabın olduğu bir durumda, bu her bir kanıtı 125 * 28 = 3500 bayt veya yaklaşık 56.000 gaz, artı hash'lerin kodunu çözmek ve doğrulamak için ekstra maliyet yapar.

İki kanıtın bir araya gelmesi yaklaşık 100.000 ila 150.000 gaza mal olacaktır (işlem başına kullanılıyorsa imza doğrulama dahil değildir) - işlem başına mevcut temel 21.000 gazdan önemli ölçüde daha fazla. Ancak kanıt L2 üzerinde doğrulanıyorsa eşitsizlik daha da kötüleşir. Bir L2 içindeki hesaplama ucuzdur, çünkü hesaplama zincir dışında ve L1'den çok daha az düğüme sahip bir ekosistemde yapılır. Öte yandan, verilerin L1'e gönderilmesi gerekmektedir. Dolayısıyla, karşılaştırma 21000 gaza karşı 150.000 gaz değil; 21.000 L2 gaza karşı 100.000 L1 gaz şeklindedir.

Bunun ne anlama geldiğini L1 gaz maliyetleri ile L2 gaz maliyetleri arasındaki karşılaştırmalara bakarak hesaplayabiliriz:

L1 şu anda basit gönderimler için L2'den yaklaşık 15-25 kat daha pahalı ve token takasları için 20-50 kat daha pahalı. Basit gönderimler nispeten veri ağırlıklıdır, ancak takaslar hesaplama açısından çok daha ağırdır. Bu nedenle, takaslar L1 hesaplama ile L2 hesaplama maliyetini yaklaşık olarak hesaplamak için daha iyi bir ölçüttür. Tüm bunlar dikkate alındığında, L1 hesaplama maliyeti ile L2 hesaplama maliyeti arasında 30x'lik bir maliyet oranı varsayarsak, bu, L2'ye bir Merkle kanıtı koymanın belki de elli normal işleme eşdeğer bir maliyete mal olacağı anlamına geliyor gibi görünüyor.

Elbette ikili bir Merkle ağacı kullanmak maliyetleri ~4 kat azaltabilir, ancak yine de maliyet çoğu durumda çok yüksek olacaktır - ve artık Ethereum'un mevcut onaltılı durum ağacıyla uyumlu olmama fedakarlığını yapmaya istekliysek, daha iyi seçenekler de arayabiliriz.

ZK-SNARK kanıtları nasıl çalışır?

Kavramsal olarak, ZK-SNARK'ların kullanımını anlamak da kolaydır: yukarıdaki diyagramdaki Merkle ispatlarını, bu Merkle ispatlarının var olduğunu kanıtlayan bir ZK-SNARK ile değiştirirsiniz. Bir ZK-SNARK ~400.000 hesaplama gazına ve yaklaşık 400 bayta mal olur (karşılaştırın: Temel bir işlem için 21.000 gaz ve 100 bayt, gelecekte sıkıştırma ile ~25 bayta düşürülebilir). Dolayısıyla, hesaplama açısından bakıldığında, bir ZK-SNARK bugün temel bir işlemin maliyetinin 19 katına, veri açısından bakıldığında ise bir ZK-SNARK bugün temel bir işlemin 4 katına ve gelecekte temel bir işlemin maliyetinin 16 katına mal olmaktadır.

Bu sayılar Merkle kanıtlarına göre büyük bir gelişmedir, ancak yine de oldukça pahalıdırlar. Bunu geliştirmenin iki yolu vardır: (i) özel amaçlı KZG kanıtları veya (ii) ERC-4337 toplamasına benzer ancak daha süslü matematik kullanan toplama. İkisine de bakabiliriz.

Özel amaçlı KZG kanıtları nasıl çalışır?

Uyarı, bu bölüm diğer bölümlere göre çok daha matematikseldir. Bunun nedeni, genel amaçlı araçların ötesine geçip daha ucuz olması için özel amaçlı bir şey inşa ediyor olmamızdır, bu nedenle "kaputun altına" çok daha fazla girmemiz gerekir. Derin matematikten hoşlanmıyorsanız, doğrudan bir sonraki bölüme geçin.

İlk olarak, KZG taahhütlerinin nasıl işlediğini özetleyelim:

• Bir veri kümesini [D_1 ... D_n] verilerden türetilen bir polinomun KZG ispatı ile temsil edebiliriz: özellikle, P(w) = D_1, P(w²) = D_2 ... P(wⁿ) = D_n olan P polinomu. w burada bir "birliğin kökü", bazı değerlendirme alanı boyutu N için wᴺ = 1 olan bir değerdir (bunların hepsi sonlu bir alanda yapılır).
• P'ye "bağlanmak" için, com(P) = P₀ G + P₁ S₁ + ... + Pₖ * Sₖ şeklinde bir eliptik eğri noktası oluştururuz. İşte:
  • G eğrinin jeneratör noktasıdır
  • Pᵢ, P polinomunun i'inci derece katsayısıdır.
  • Sᵢ güvenilir kurulumdaki i'inci noktadır
• P(z) = a olduğunu kanıtlamak için, Q = (P - a) / (X - z) bölüm polinomunu oluşturacağız ve buna com(Q) bağlılığını yaratacağız. Böyle bir polinom oluşturmak ancak P(z) gerçekten a'ya eşitse mümkündür.
• Bir ispatı doğrulamak için, com(Q) ispatı ve com(P) polinom taahhüdü üzerinde eliptik eğri kontrolü yaparak Q * (X - z) = P - a denklemini kontrol ederiz: e(com(Q), com(X - z)) ?= e(com(P) - com(a), com(1))

Anlaşılması önemli olan bazı temel özellikler şunlardır:

• Bir kanıt sadece 48 bayt olan com(Q) değeridir
• com(P₁) + com(P₂) = com(P₁ + P₂)
• Bu aynı zamanda mevcut bir taahhütte bir değeri "düzenleyebileceğiniz" anlamına gelir. D_i'nin şu anda a olduğunu bildiğimizi, onu b olarak ayarlamak istediğimizi ve D'ye yönelik mevcut taahhüdün com(P) olduğunu varsayalım. "P, ancak P(wⁱ) = b olacak ve başka hiçbir değerlendirme değişmeyecek" şeklinde bir taahhüt, o zaman com(new_P) = com(P) + (b-a) * com(Lᵢ) olarak belirlenir; burada Lᵢ, wⁱ noktasında 1'e ve diğer wʲ noktalarında 0'a eşit olan bir "Lagrange polinomu "dur.
• Bu güncellemeleri verimli bir şekilde gerçekleştirmek için, Lagrange polinomlarına (com(Lᵢ)) olan tüm N taahhütler önceden hesaplanabilir ve her istemci tarafından saklanabilir. Zincir üzerindeki bir sözleşmenin içinde tüm N taahhütleri saklamak çok fazla olabilir, bu nedenle bunun yerine com(L_i) (veya hash(com(L_i)) değerleri kümesine bir KZG taahhüdü verebilirsiniz, böylece birinin zincir üzerindeki ağacı güncellemesi gerektiğinde, doğruluğunun bir kanıtı ile uygun com(L_i)'yi sağlayabilir.

Dolayısıyla, belirli bir boyut sınırı olsa da (gerçekçi olmak gerekirse, yüz milyonlar uygun olabilir) sürekli büyüyen bir listenin sonuna değerler eklemeye devam edebileceğimiz bir yapıya sahibiz. Daha sonra bunu veri yapımız olarak (i) her L2'deki anahtar listesine bir taahhüt, bu L2'de saklanır ve L1'e yansıtılır ve (ii) Ethereum L1'de saklanan ve her L2'ye yansıtılan L2 anahtar taahhütleri listesine bir taahhüt yönetmek için kullanırız.

Taahhütlerin güncel tutulması ya çekirdek L2 mantığının bir parçası haline gelebilir ya da para yatırma ve çekme köprüleri aracılığıyla L2 çekirdek protokol değişiklikleri olmadan uygulanabilir.

Bu nedenle tam bir kanıt gerekmektedir:

• Anahtar deposu tutan L2'deki en son com (anahtar listesi) (48 bayt)
• com(anahtar liste)'nin com(mirror_list) içinde bir değer olduğuna dair KZG kanıtı, tüm anahtar liste bağlılıklarının listesine bağlılık (48 bayt)
• com(anahtar listesi) içindeki anahtarınızın KZG kanıtı (48 bayt, artı dizin için 4 bayt)

Aslında iki KZG kanıtını tek bir kanıtta birleştirmek mümkündür, böylece toplam boyut sadece 100 bayt olur.

Bir inceliğe dikkat edin: anahtar listesi bir liste olduğundan ve durum gibi bir anahtar/değer haritası olmadığından, anahtar listesinin konumları sırayla ataması gerekecektir. Anahtar taahhüt sözleşmesi, her bir anahtar deposunu bir ID ile eşleyen kendi dahili kayıt defterini içerecek ve her bir anahtar için, belirli bir girdinin hangi anahtar deposundan bahsettiğini diğer L2'lere açık bir şekilde iletmek için sadece anahtar yerine hash(anahtar, anahtar deposunun adresi) saklayacaktır.

Bu tekniğin iyi tarafı, L2 üzerinde çok iyi performans göstermesidir. Veri 100 bayttır, ZK-SNARK'tan ~4 kat daha kısa ve Merkle kanıtından çok daha kısadır. Hesaplama maliyeti büyük ölçüde bir boyut-2 eşleştirme kontrolü veya yaklaşık 119.000 gazdır. L1'de veri, hesaplamadan daha az önemlidir ve bu nedenle ne yazık ki KZG, Merkle ispatlarından biraz daha pahalıdır.

Verkle ağaçları nasıl çalışır?

Verkle ağaçları esasen KZG taahhütlerinin (veya daha verimli olabilen ve daha basit kriptografi kullanan IPA taahhütlerinin) üst üste yığılmasını içerir: 2⁴⁸ değeri saklamak için, her biri 2²⁴ değer için bir KZG taahhüdü olan 2²⁴ değerden oluşan bir listeye KZG taahhüdü verebilirsiniz. Verkle ağaçları <a href="https://notes.ethereum.org/@vbuterin/verkle_tree_eip"> güçlü bir şekilde Ethereum durum ağacı için düşünülmüştür, çünkü Verkle ağaçları sadece listeleri değil, anahtar-değer haritalarını tutmak için de kullanılabilir (temel olarak, 2²⁵⁶ boyutunda bir ağaç oluşturabilir, ancak boş olarak başlatabilir, yalnızca gerçekten doldurmanız gerektiğinde ağacın belirli bölümlerini doldurabilirsiniz).

Bir Verkle ağacı nasıl görünür? Pratikte, her düğüme IPA tabanlı ağaçlar için 256 == 2⁸ veya KZG tabanlı ağaçlar için 2²⁴ genişlik verebilirsiniz.

Verkle ağaçlarındaki kanıtlar KZG'den biraz daha uzundur; birkaç yüz bayt uzunluğunda olabilirler. Ayrıca, özellikle birçok kanıtı tek bir kanıtta toplamaya çalışırsanız, doğrulamaları da zordur.

Gerçekçi olmak gerekirse, Verkle ağaçları Merkle ağaçları gibi düşünülmelidir, ancak SNARKing olmadan daha uygulanabilir (daha düşük veri maliyetleri nedeniyle) ve SNARKing ile daha ucuzdur (daha düşük kanıtlayıcı maliyetleri nedeniyle).

Verkle ağaçlarının en büyük avantajı, veri yapılarını uyumlu hale getirme olasılığıdır: Verkle kanıtları, kaplama yapıları olmadan ve L1 ve L2 için tam olarak aynı mekanizma kullanılarak doğrudan L1 veya L2 durumu üzerinde kullanılabilir. Kuantum bilgisayarlar bir sorun haline geldiğinde veya Merkle dallarını kanıtlamak yeterince verimli hale geldiğinde, Verkle ağaçları, uygun bir SNARK dostu hash işlevine sahip ikili bir hash ağacı ile değiştirilebilir.

Birleştirme

N kullanıcı N çapraz zincir iddiasını kanıtlaması gereken N işlem (veya daha gerçekçi bir ifadeyle N ERC-4337 Kullanıcı İşlemi) yaparsa, bu kanıtları bir araya getirerek çok fazla gaz tasarrufu sağlayabiliriz: bu işlemleri bir blokta veya bir bloğa giren pakette birleştirecek olan oluşturucu, tüm bu iddiaları aynı anda kanıtlayan tek bir kanıt oluşturabilir.

Bu şu anlama gelebilir:

• N Merkle dalının ZK-SNARK kanıtı
• Bir KZG çoklu geçirmez
• Bir Verkle çok lu geçirmezlik (veya bir çoklu geçirmezliğin ZK-SNARK'ı)

Her üç durumda da kanıtların her biri yalnızca birkaç yüz bin gaza mal olacaktır. Oluşturucunun her L2'de o L2'deki kullanıcılar için bunlardan bir tane yapması gerekecektir; dolayısıyla, bunun oluşturulmasının yararlı olması için, bir bütün olarak planın, birden fazla ana L2'de aynı blok içinde en az birkaç işlem olacak kadar yeterli kullanıma sahip olması gerekir.

ZK-SNARK'lar kullanılırsa, ana marjinal maliyet sadece sözleşmeler arasında sayıları dolaştırmanın "iş mantığı", yani belki de kullanıcı başına birkaç bin L2 gazıdır. KZG çoklu kanıtlar kullanılırsa, kanıtlayıcının o blokta kullanılan her anahtar deposu tutan L2 için 48 gaz eklemesi gerekecektir, bu nedenle şemanın kullanıcı başına marjinal maliyeti, L2 başına (kullanıcı başına değil) ~800 L1 gazı daha ekleyecektir. Ancak bu maliyetler, kaçınılmaz olarak kullanıcı başına 10.000'den fazla L1 gazı ve yüz binlerce L2 gazı içeren toplulaştırma yapmama maliyetlerinden çok daha düşüktür. Verkle ağaçları için, kullanıcı başına yaklaşık 100-200 bayt ekleyerek doğrudan Verkle çoklu kanıtlarını kullanabilir veya Merkle dallarının ZK-SNARK'larına benzer maliyetlere sahip olan ancak kanıtlaması önemli ölçüde daha ucuz olan bir Verkle çoklu kanıtının ZK-SNARK'ını yapabilirsiniz.

Uygulama açısından bakıldığında, paketleyicilerin ERC-4337 hesap soyutlama standardı aracılığıyla zincirler arası kanıtları bir araya getirmesi muhtemelen en iyisidir. ERC-4337, oluşturucuların UserOperations'ın parçalarını özel yollarla bir araya getirmeleri için zaten bir mekanizmaya sahiptir. Hatta <a href="https://hackmd.io/@voltrevo/BJ0QBy3zi"> bunun BLS imza birleştirme için bir uygulaması bile vardır, bu da diğer sıkıştırma biçimlerinin dahil edilmesine bağlı olarak L2'deki gaz maliyetlerini 1,5 kat ila 3 kat azaltabilir.

<a href="https://hackmd.io/@voltrevo/BJ0QBy3zi"> BLS cüzdan uygulaması gönderisinden ERC-4337'nin önceki bir sürümünde BLS toplu imzalarının iş akışını gösteren diyagram. Zincirler arası kanıtları bir araya getirme iş akışı muhtemelen çok benzer görünecektir.

Doğrudan durum okuma

Son bir olasılık ve yalnızca L2'nin L1'i okuması (L1'in L2'yi okuması değil) için kullanılabilecek bir olasılık, L2'leri doğrudan L1'deki sözleşmelere statik çağrılar yapmalarına izin verecek şekilde değiştirmektir.

Bu, hedef adresi, gaz ve calldata'yı sağladığınız L1'e çağrılara izin veren bir işlem kodu veya ön derleme ile yapılabilir ve çıktıyı döndürür, ancak bu çağrılar statik çağrılar olduğu için aslında herhangi bir L1 durumunu değiştiremezler. L2'lerin depozitoları işlemek için zaten L1' den haberdar olması gerekir, bu nedenle böyle bir şeyin uygulanmasını engelleyen temel bir şey yoktur; esas olarak teknik bir uygulama zorluğudur (bkz: Optimism'den L1'e statik çağrıları desteklemek için bu RFP).

Anahtar deposu L1 üzerindeyse ve L2'ler L1 statik çağrı işlevselliğini entegre ediyorsa, hiçbir kanıt gerekmediğine dikkat edin! Ancak, L2'ler L1 statik çağrılarını entegre etmezse veya anahtar deposu L2 üzerindeyse (ki L1 kullanıcılar için biraz bile pahalı hale geldiğinde eninde sonunda öyle olması gerekebilir), o zaman kanıtlar gerekecektir.

L2 son Ethereum durum kökünü nasıl öğrenir?

Yukarıdaki tüm şemalar L2'nin ya son L1 durum köküne ya da son L1 durumunun tamamına erişmesini gerektirir. Neyse ki, tüm L2'ler zaten son L1 durumuna erişmek için bazı işlevlere sahiptir. Bunun nedeni, L1'den L2'ye gelen mesajları, özellikle de mevduatları işlemek için böyle bir işlevselliğe ihtiyaç duymalarıdır.

Gerçekten de bir L2'nin para yatırma özelliği varsa, L2'yi olduğu gibi L1 durum köklerini L2'deki bir sözleşmeye taşımak için kullanabilirsiniz: L1'deki bir sözleşmenin BLOCKHASH işlem kodunu çağırması ve bunu L2'ye para yatırma mesajı olarak iletmesi yeterlidir. Tam blok başlığı alınabilir ve L2 tarafında durum kökü çıkarılabilir. Bununla birlikte, her L2'nin son L1 durumunun tamamına veya son L1 durum köklerine doğrudan erişmek için açık bir yola sahip olması çok daha iyi olacaktır.

L2'lerin son L1 durum köklerini alma şeklini optimize etmenin temel zorluğu, aynı anda güvenlik ve düşük gecikme süresi elde etmektir:

• L2'ler "L1'in doğrudan okunması" işlevini tembel bir şekilde uygularsa, yalnızca sonlandırılmış L1 durum köklerini okursa, gecikme normalde 15 dakika olacaktır, ancak aşırı hareketsizlik sızıntıları durumunda (tolere etmeniz gereken), gecikme birkaç hafta olabilir.
• L2'ler kesinlikle çok daha yeni L1 durum köklerini okuyacak şekilde tasarlanabilir, ancak L1 geri dönebildiği için ( tek slot kesinliğinde bile, hareketsizlik sızıntıları sırasında geri dönüşler olabilir), L2'nin de geri dönebilmesi gerekir. Bu, yazılım mühendisliği açısından teknik olarak zordur, ancak en azından Optimism zaten bu yeteneğe sahiptir.
• L1 durum köklerini L2'ye getirmek için depozito köprüsünü kullanırsanız, basit ekonomik uygulanabilirlik, depozito güncellemeleri arasında uzun bir süre gerektirebilir: bir depozitonun tam maliyeti 100.000 gaz ise ve ETH'nin 1800 $ olduğunu ve ücretlerin 200 gwei olduğunu ve L1 köklerinin günde bir kez L2'ye getirildiğini varsayarsak, bu, sistemi sürdürmek için günde L2 başına 36 $ veya yılda L2 başına 13148 $ maliyet olacaktır. Bir saatlik gecikme ile bu rakam L2 başına yıllık 315.569 dolara çıkmaktadır. En iyi durumda, sabırsız zengin kullanıcılardan oluşan sürekli bir akış güncelleme ücretlerini karşılar ve sistemi diğer herkes için güncel tutar. En kötü durumda, fedakâr bir aktörün bunun bedelini kendisinin ödemesi gerekecektir.
• "Oracle "lar (en azından bazı tanımlayıcıların "oracle" olarak adlandırdığı türden teknolojiler) burada kabul edilebilir bir çözüm değildir: cüzdan anahtarı yönetimi güvenlik açısından son derece kritik bir alt düzey işlevdir ve bu nedenle en fazla birkaç adet çok basit, kriptografik olarak güvenilmez alt düzey altyapıya bağlı olmalıdır.

Ayrıca, ters yönde (L1'lerin L2 okuması):

• İyimser toparlamalarda, dolandırıcılık kanıtı gecikmesi nedeniyle devlet köklerinin L1'e ulaşması bir hafta sürer. ZK toparlamalarında, kanıtlama süreleri ve ekonomik sınırların bir kombinasyonu nedeniyle şimdilik birkaç saat sürüyor, ancak gelecekteki teknoloji bunu azaltacaktır.
• Ön onaylar (sıralayıcılardan, onaylayıcılardan vb.) L1'in L2 okuması için kabul edilebilir bir çözüm değildir. Cüzdan yönetimi güvenlik açısından çok kritik bir alt düzey işlevdir ve bu nedenle L2 -> L1 iletişiminin güvenlik düzeyi mutlak olmalıdır: L2 doğrulayıcı setini ele geçirerek yanlış bir L1 durum kökünü itmek bile mümkün olmamalıdır. L1'in güvenmesi gereken tek durum kökleri, L2'nin L1 üzerindeki durum kökü tutma sözleşmesi tarafından nihai olarak kabul edilen durum kökleridir.

Güvenilir olmayan zincirler arası işlemler için bu hızlardan bazıları birçok kullanım durumu için kabul edilemez derecede yavaştır; bu durumlar için daha kusurlu güvenlik modellerine sahip daha hızlı köprülere ihtiyacınız vardır. Ancak cüzdan anahtarlarının güncellenmesi gibi kullanım durumları için daha uzun gecikmeler daha kabul edilebilirdir: işlemleri saatlerce geciktirmiyorsunuz, anahtar değişikliklerini geciktiriyorsunuz. Sadece eski anahtarları daha uzun süre yanınızda tutmanız gerekecek. Anahtarlar çalındığı için anahtarları değiştiriyorsanız, önemli bir güvenlik açığı süreniz var demektir, ancak bu, örneğin cüzdanların dondurma işlevine sahip olmasıyla hafifletilebilir.

Sonuç olarak, gecikmeyi en aza indiren en iyi çözüm, L2'lerin L1 durum köklerini doğrudan okumayı en uygun şekilde uygulamasıdır; burada her L2 bloğu (veya durum kökü hesaplama günlüğü) en son L1 bloğuna bir işaretçi içerir, böylece L1 geri dönerse, L2 de geri dönebilir. Anahtar deposu sözleşmeleri ya ana ağa ya da ZK-rollup olan ve bu nedenle hızlı bir şekilde L1'e bağlanabilen L2'lere yerleştirilmelidir.

L2 zincirinin blokları sadece önceki L2 bloklarına değil, aynı zamanda bir L1 bloğuna da bağımlı olabilir. L1 böyle bir bağlantıdan geri dönerse, L2 de geri döner. Sharding'in daha önceki (Dank öncesi) bir versiyonunun da bu şekilde çalışmasının öngörüldüğünü belirtmek gerekir; kod için buraya bakın.

Anahtar depoları Ethereum veya bir L2 üzerinde bulunan cüzdanları tutmak için başka bir zincirin Ethereum ile ne kadar bağlantıya ihtiyacı vardır?

Şaşırtıcı bir şekilde, o kadar da değil. Aslında bir rollup olması bile gerekmez: eğer bir L3 veya bir validium ise, anahtar depolarını L1'de veya bir ZK rollup'ta tuttuğunuz sürece cüzdanları orada tutmanızda bir sakınca yoktur. İhtiyacınız olan şey, zincirin Ethereum durum köklerine doğrudan erişime sahip olması ve Ethereum reorgs yaparsa reorg, Ethereum hard forks yaparsa hard fork yapmaya istekli olmak için teknik ve sosyal bir taahhüttür.

İlginç bir araştırma sorunu, bir zincirin birden fazla başka zincirle bu tür bir bağlantıya sahip olmasının ne ölçüde mümkün olduğunu belirlemektir (örn. Ethereum ve Zcash). Bunu saf bir şekilde yapmak mümkündür: Ethereum ya da Zcash yeniden yapılanırsa zinciriniz de yeniden yapılanmayı (ve Ethereum ya da Zcash hard fork yaparsa hard fork yapmayı) kabul edebilir, ancak bu durumda düğüm operatörlerinizin ve daha genel olarak topluluğunuzun teknik ve politik bağımlılıkları iki katına çıkar. Dolayısıyla böyle bir teknik birkaç başka zincire bağlanmak için kullanılabilir, ancak artan bir maliyetle. ZK köprülerine dayalı şemalar çekici teknik özelliklere sahiptir, ancak %51 saldırılarına veya sert çatallara karşı dayanıklı olmamaları gibi önemli bir zayıflıkları vardır. Daha akıllıca çözümler olabilir.

Mahremiyetin korunması

İdeal olarak, mahremiyeti de korumak istiyoruz. Aynı anahtar deposu tarafından yönetilen çok sayıda cüzdanınız varsa, emin olmak isteriz:

• Bu cüzdanların hepsinin birbiriyle bağlantılı olduğu herkes tarafından bilinmiyor.
• Sosyal kurtarma görevlileri, korudukları adreslerin ne olduğunu öğrenmezler.

Bu durum birkaç sorun yaratmaktadır:

• Merkle kanıtlarını doğrudan kullanamayız çünkü bunlar gizliliği korumaz.
• KZG veya SNARKs kullanırsak, kanıtın doğrulama anahtarının konumunu açıklamadan doğrulama anahtarının körleştirilmiş bir versiyonunu sağlaması gerekir.
• Eğer toplama yöntemini kullanırsak, toplayıcı konumu düz metin olarak öğrenmemelidir; bunun yerine toplayıcı kör kanıtlar almalı ve bunları toplamanın bir yolunu bulmalıdır.
• "Hafif versiyonu" kullanamayız (çapraz zincir kanıtlarını yalnızca anahtarları güncellemek için kullanın), çünkü bu bir gizlilik sızıntısı yaratır: bir güncelleme prosedürü nedeniyle birçok cüzdan aynı anda güncellenirse, zamanlama bu cüzdanların muhtemelen ilişkili olduğu bilgisini sızdırır. Bu yüzden "ağır versiyonu" (her işlem için çapraz zincir kanıtları) kullanmak zorundayız.

SNARK'lar ile çözümler kavramsal olarak kolaydır: kanıtlar varsayılan olarak bilgi gizleyicidir ve toplayıcının SNARK'ları kanıtlamak için özyinelemeli bir SNARK üretmesi gerekir.

Bu yaklaşımın günümüzdeki temel zorluğu, toplamanın toplayıcının özyinelemeli bir SNARK oluşturmasını gerektirmesidir ve bu da şu anda oldukça yavaştır.

KZG ile <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof"> this kullanabiliriz. (ayrıca bakınız: Caulk makalesinde bu çalışmanın daha biçimselleştirilmiş bir versiyonu) indeks-açıklamalı olmayan KZG ispatları üzerine bir başlangıç noktası olarak. Bununla birlikte, kör kanıtların bir araya getirilmesi daha fazla dikkat gerektiren açık bir sorundur.

L1'i L2'nin içinden doğrudan okumak ne yazık ki gizliliği korumaz, ancak doğrudan okuma işlevselliğini uygulamak hem gecikmeyi en aza indirmek hem de diğer uygulamalar için faydası nedeniyle hala çok yararlıdır.

Özet

• Zincirler arası sosyal kurtarma cüzdanlarına sahip olmak için en gerçekçi iş akışı, bir anahtar deposunu tek bir konumda tutan bir cüzdan ve cüzdanın anahtar deposunu (i) doğrulama anahtarının yerel görünümünü güncellemek için veya (ii) her işlemi doğrulama işlemi sırasında okuduğu birçok konumdaki cüzdanlardır.
• Bunu mümkün kılmanın kilit bileşenlerinden biri de çapraz zincir kanıtlarıdır. Bu kanıtları sıkı bir şekilde optimize etmemiz gerekiyor. ZK-SNARK'lar, Verkle kanıtlarını beklemek ya da özel yapım bir KZG çözümü en iyi seçenekler gibi görünüyor.
• Uzun vadede, paketleyicilerin kullanıcılar tarafından gönderilen tüm Kullanıcı İşlemlerinin bir paketini oluşturmanın bir parçası olarak toplu kanıtlar ürettiği toplama protokolleri, maliyetleri en aza indirmek için gerekli olacaktır. Bu muhtemelen ERC-4337 ekosistemine entegre edilmelidir, ancak ERC-4337'de değişiklikler yapılması gerekecektir.
• L2'ler, L1 durumunu (veya en azından durum kökünü) L2 içinden okuma gecikmesini en aza indirecek şekilde optimize edilmelidir. L2'lerin doğrudan L1 durumunu okuması idealdir ve kanıt alanından tasarruf sağlayabilir.
• Cüzdanlar sadece L2'lerde değil; Ethereum ile daha düşük bağlantı seviyelerine sahip sistemlere de cüzdanlar koyabilirsiniz (L3'ler, hatta sadece Ethereum durum köklerini içermeyi kabul eden ve Ethereum reorgs veya hardfork olduğunda reorg veya hard fork yapan ayrı zincirler).
• Ancak, anahtar depoları ya L1 üzerinde ya da yüksek güvenlikli ZK-rollup L2 üzerinde olmalıdır. L1 üzerinde olmak çok fazla karmaşıklıktan kurtarır, ancak uzun vadede bu bile çok pahalı olabilir, bu nedenle L2 üzerinde anahtar depolarına ihtiyaç vardır.
• Mahremiyetin korunması ek çalışma gerektirecek ve bazı seçenekleri daha zor hale getirecektir. Bununla birlikte, muhtemelen yine de gizliliği koruyan çözümlere yönelmeli ve en azından önerdiğimiz her şeyin gizliliğin korunmasıyla ileriye dönük olarak uyumlu olduğundan emin olmalıyız.

Sorumluluk Reddi：

1. Bu makale[vitalik] adresinden yeniden basılmıştır, Tüm telif hakları orijinal yazar[Vitalik Buterin]'e aittir. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.