V God Blog: Cüzdanları ve Diğer Uygulama Durumlarını Anlamak Layer2 Katmanlar Arası Okuma

Yazar: Vitalik Buterin; Derleyen: Bulu dedi

Ethereum'un kurucusu Vitalik Buterin, Üç Geçiş makalesinde "ana ağ (bundan sonra L1 olarak anılacaktır) + katman 2 çapraz zincir (bundan sonra çapraz L2 olarak anılacaktır)" konusunu açıkça detaylandırmıştır. destek"" "Cüzdan güvenliği" ve "gizlilik", ekosistem yığınının gerekli işlevleri olarak önemli değerlerdir. Bunlar yalnızca bazı ek bileşenler olmamalı ve ayrı bir cüzdan ilgili işlevleri sağlar.

Vitalik Buterin, bu makalenin önemli bir teknik konuya odaklanacağını belirtti: L1 verilerinin L2'den nasıl daha kolay okunacağı veya L2 verilerinin L1'den nasıl daha kolay okunacağı veya L2 verilerinin bir L2'den nasıl daha kolay okunacağı Başka bir L2'den verilerin nasıl okunacağı . **

Vitalik Buterin, yukarıdaki sorunları çözmenin anahtarının, varlıkların ve anahtar depolarının ayrılmasının nasıl gerçekleştirileceği konusunda yattığına dikkat çekti. Bu teknoloji, ölçeklendirme dışında L1 ve L2 arasındaki varlıkların hareketliliği gibi alanlarda da çok değerli kullanım durumlarına sahiptir.

**Bunu yapmanın amacı nedir? **

L2 yaygın hale geldiğinde, kullanıcılar birden çok L2'de ve muhtemelen L1'de varlıklara sahip olabilecekler.

Akıllı sözleşme cüzdanları yaygınlaştığında, artık yaygın olan "anahtarlar" artık kullanılmayacaktır.

Bu iki şey aynı anda gerçekleştiğinde, kullanıcıların farklı hesapların anahtarlarını değiştirmek için çok sayıda işlem gerektirmeyen bir yönteme ihtiyacı olacaktır.

Özellikle, "karşı olgusal" ("varsayımsal adresler" olarak da bilinir) adreslerle başa çıkmak için bir yola ihtiyacımız var: zincir üzerinde henüz herhangi bir şekilde "kayıtlı" olmayan, ancak yine de varlıkları güvenli bir şekilde alması ve tutması gereken adresler. .

Aslında, hepimiz adreslerin bu "karşı olgusal ayarına" güveniyoruz: Bir kullanıcı Ethereum'u ilk kez kullandığında, kullanıcı bir ETH adresi oluşturabilir ve diğerleri, blok zincirine kaydolmak zorunda kalmadan bu hesaba ödeme yapabilir. adres (ancak işlem ücretlerini ödemeniz gerekecek, bu nedenle bir miktar ETH tutmanız gerekiyor).

Harici hesaplar (EOA) için, aslında tüm adresler "karşı olgusal ayar" adresinden başlar.

Büyük ölçüde, yalnızca belirli bir hash doldurmayla eşleşen akıllı sözleşme kodu tarafından oluşturulabilen bir ETH adresine sahip olmanızı sağlayan CREATE2 sayesinde, akıllı sözleşme cüzdanlarıyla "karşı olgusal olarak ayarlanmış" adresler hala mümkündür.

△ EIP-1014 (CREATE2) adres hesaplama algoritması.

Ancak, akıllı sözleşme cüzdanlarının piyasaya sürülmesi yeni zorlukları da beraberinde getiriyor: **Erişim anahtarları değişebilir. **Bu değişiklik, adresin yalnızca cüzdanın ilk doğrulama anahtarını içerebilen initcode'un hash değeri olması ve mevcut doğrulama anahtarının cüzdanın deposunda saklanması, ancak depolama kaydının olmamasıdır. otomatik olarak diğer L2'ye aktarılır.

Bir kullanıcının birçok L2'de adresi varsa yalnızca Varlığın Ayrılması ve Anahtar Depolama Mimarisi kullanıcıların anahtarlarını değiştirmesine yardımcı olabilir.

Bu bölünmüş mimarinin yapısı, her kullanıcının (i) tüm cüzdanlar için doğrulama anahtarlarını ve anahtar değiştirme kurallarını depolayan bir "anahtar depolama sözleşmesine" (L1 veya belirli bir L2 zincirinde) ve (ii) "Cüzdan sözleşmelerine" sahip olmasıdır. " çapraz zincir okumaları yoluyla doğrulama anahtarları alan L1 ve birçok L2 zincirinde.

Varlık ve anahtar depolama ayırma mimarisini uygulamanın iki yolu vardır:

Hafif sürüm (yani yalnızca güncellenmiş anahtarları kontrol eder): Her cüzdan, doğrulama anahtarını yerel olarak saklar ve anahtar deposunun mevcut durumunun zincirler arası kanıtını kontrol etmek ve yerel depolamayı güncellemek için çağrılabilir bir işlev içerir Kimlik doğrulama eşleştirmek için anahtar. Anahtar deposundan geçerli kimlik doğrulama anahtarını almak için bu işlevin çağrılması, cüzdanı bir L2'de ilk kez kullanırken gereklidir.

• **Avantajlar: **Zincirler arası kanıtların kullanımı daha ihtiyatlıdır ve çok pahalı ağ işletim maliyetleri olmayacaktır. Tüm varlıklar yalnızca geçerli anahtarla kullanılabilir, bu nedenle güvenlik yine de garanti edilir.
• **Dezavantajlar: **Doğrulama anahtarını değiştirmeniz gerekir, on-chain anahtar değişimi anahtar deposunda ve başlatılan her cüzdanda yapılmalıdır ve çok fazla Gas Ücreti tüketebilir.

Tam sürüm (yani her işlem kontrol edilir): Her işlem, anahtar deposundaki geçerli anahtarı gösteren zincirler arası bir kanıt gerektirir.

• Avantajlar: Sistem karmaşıklığı düşüktür ve anahtar deposu hızla güncellenir.
• **Dezavantajlar: **Tek bir işlemin ağ işletim ücreti yüksektir ve ERC-4337 ile uyumlu olmak kolay değildir. ERC-4337 şu anda doğrulama sırasında sözleşmeler arasında değiştirilebilir nesnelerin okunmasını desteklememektedir.

**Çapraz zincir kanıtı nedir? **

Zincirler arası ispatların karmaşıklığını göstermek için, bu teknik prensibi göstermek ve açıklamak için en karmaşık uygulama senaryolarından birini seçtik.Bu karmaşık uygulama senaryosu şu şekildedir: anahtar bir L2'de depolanır ve cüzdan açıktır. başka bir L2. M-cüzdandaki anahtar deposu L1'deyse, bu tasarımın sadece yarısına ihtiyaç vardır.

Anahtar deposunun Linea'da ve cüzdanın Kakarot'ta olduğunu varsayalım. M-cüzdan anahtarının eksiksiz sertifikalandırma sürecinin şunları içermesi gerekir:

• Kakarot tarafından bilinen mevcut Ethereum durum kökü verildiğinde, mevcut Linea durum kökünün kanıtı.
• Geçerli Linea durum kökü verildiğinde, anahtar deposundaki geçerli anahtarın kanıtı.

Burada iki temel zorlu uygulama sorusu vardır: "Ne tür bir kanıt kullanılması gerekiyor? (Bu bir Merkle kanıtı mı? Veya başka bir şey mi?)" ve "L2 en yakın L1 durum kökünü nasıl öğrenir?" veya "L1 Nasıl L2'nin durum kökünü öğrenmek için?"

Öyleyse, her iki durumda da, bir tarafta bir olayın meydana gelmesi ile diğer tarafın kanıt sunabilmesi arasındaki gecikme ne kadardır?

**Bizim için hangi ispat şemaları mevcuttur? **

Aralarından seçim yapabileceğiniz beş ana yöntem vardır:

• Merkle kanıtı
• Genel ZK-SNARK'lar
• Özel amaçlı sertifika (örneğin, KZG kullanarak)
• Hem altyapı çalışması hem de maliyet dikkate alındığında KZG ve ZK-SNARK'lar arasında Verkle kanıtı
• kanıt yok, doğrudan durum okumasına dayanıyor

Gerekli altyapı çalışmaları ve kullanıcı maliyetleri açısından kabaca şu şekilde sıralanabilir:

"Toplama", her blokta kullanıcılar tarafından sağlanan tüm kanıtları tek bir büyük meta kanıtta bir araya getirerek birleştirme anlamına gelir. Bu, SNARK'lar ve KZG için çalışır, ancak Merkle çatalları için çalışmaz.

Aslında, "toplama" yalnızca çözümün çok sayıda kullanıcısı olduğunda değerlidir. ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍Y

**Merkle ispatları nasıl çalışır? **

Bu problem çok basittir ve bir önceki bölümdeki şema ile doğrudan takip edilebilir. Her "kanıt" (bir L2'nin başka bir L2 olduğunun kanıtlandığını varsayarsak, ki bu en zor uygulama senaryosudur) şunları içerecektir:

Doğrulayan bir Merkle çatalı, L2 tarafından bilinen Ethereum'un en son durum kökü olan L2 anahtar deposunun durum kökünü tutar. L2 anahtar deposunu tutan durum kökleri, bilinen adreslerde (L2'yi temsil eden L1 sözleşmeleri) bilinen depolama yuvalarında depolanır, böylece yollar sabit kodlanabilir.

L2 anahtar deposunu tutan durum köküne göre geçerli doğrulama anahtarını onaylayan bir Merkle şubesi. Ayrıca, kimlik doğrulama anahtarları bilinen adreslerdeki bilinen yuvalarda saklanır, böylece yollar sabit kodlanabilir.

Bununla birlikte, Ethereum'daki durum kanıtları karmaşıktır, ancak bunları doğrulamak için kullanılabilecek kitaplıklar vardır ve bu kitaplıkları kullanıyorsanız, mekanizma çok karmaşık değildir.

Ancak, daha büyük zorluk maliyettir. **Merkle'nin çok uzun olduğu kanıtlandı ve Patricia ağacı gerekenden 3,9 kat daha uzundu - işlem başına 21.000 Gaz Ücreti olan mevcut taban fiyattan çok daha yüksek.

Bununla birlikte, ispat L2'de doğrulanırsa, tutarsızlık daha da kötüleşir. L2 içindeki hesaplama ucuzdur çünkü hesaplama zincir dışında ve L1'den daha az düğüm içeren bir ekosistemde yapılır.

L1 Gaz Ücreti maliyeti ile L2 Gaz Ücreti maliyeti arasındaki karşılaştırmaya bakarak bunun ne anlama geldiğini hesaplayabiliriz:

Şu anda, nispeten basit bir gönderme işlemi ise, L1 ağındaki maliyet L2'nin maliyetinin yaklaşık 15~25 katıdır ve Token değişiminin maliyeti L2'nin maliyetinin yaklaşık 20~50 katıdır.

Basit gönderme işlemi büyük miktarda veriye sahiptir ve değişim işlemi daha yüksek bilgi işlem gücü gerektirir, bu nedenle değişim işlemi, L1 hesaplaması ve L2 hesaplaması maliyetine yaklaşmak için daha iyi bir kıyaslamadır.

Yukarıdakileri bir araya getirdiğimizde, L1 hesaplama maliyeti ile L2 hesaplama maliyeti arasında 30x'lik bir maliyet oranı varsayarsak, bu, Merkle kanıtlarını L2'ye koymanın maliyetinin yaklaşık elli normal işleme eşdeğer olabileceğini ima ediyor gibi görünüyor.

Tabii ki, bir ikili Merkle ağacı kullanmak maliyeti yaklaşık 4 kat azaltacaktır, ancak o zaman bile maliyet çoğu durumda hala engelleyici olacaktır ve eğer Ethereum'un mevcut hexa durum ağacıyla uyumluluktan vazgeçmeye istekli olsaydık, Daha iyi seçenekler arayacak.

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

ZK-SNARK'ların kullanımını kavramsal olarak anlamak da kolaydır: yukarıdaki diyagramda Merkle kanıtlarını, bu Merkle kanıtlarının varlığını kanıtlayan ZK-SNARK'larla değiştirmeniz yeterlidir. Bir ZK-SNARK'ın hesaplama miktarı yaklaşık 400.000 Gaz Ücreti, yaklaşık 400 bayttır; temel bir işlem 21.000 Gaz Ücreti ve 100 bayt gerektirir.

Bu nedenle, hesaplama açısından ZK-SNARK'ın maliyeti mevcut temel işlem maliyetinin 19 katı, veri açısından ZK-SNARK'ın maliyeti mevcut temel işlem maliyetinin 4 katı ve gelecekteki maliyetin 16 katıdır. temel işlem maliyeti.

Bu sayılar, Merkle kanıtlarına göre büyük bir gelişmeyi temsil ediyor, ancak yine de oldukça pahalı. Bu durumu iyileştirmenin iki yolu vardır: (i) özel amaçlı KZG kanıtları veya (ii) ERC-4337 toplamasına benzer birleştirme.

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

İlk olarak, KZG'nin vaatlerinin nasıl çalıştığının bir özeti:

*[D_1 ...D_n], polinom KZG ispatının türetildiği bir veri kümesini temsil eder. *

*Özellikle, P(w) = D_1, P(w²) = D_2 ... P(wⁿ) = D_n.w burada bazı değerlendirmeler için "tek biçimli kök" olan P polinomu Alan boyut N, değer wN = 1 (bunların tümü sonlu alanlarda yapılır). *

• P'yi "taahhüt etmek" için eliptik bir eğri noktası oluştururuz com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. Burada:*

G, eğrinin üreteç noktasıdır

Pi, P polinomunun i'inci katsayısıdır

Si, güvenilir ayardaki i. noktadır

*Ve P(z) = a olduğunu kanıtlamak için, bir Q = (P - a) / (X - z) bölüm polinomu yaratırız ve bir com(Q) taahhüdü yaratırız. Böyle bir polinom oluşturmak ancak P(z) gerçekten a'ya eşitse mümkündür. *

• İspatı doğrulamak için, com(Q) ispatı ve com(P) polinom taahhüdü üzerinde eliptik bir eğri kontrolü yaparak Q * (X - z) = P - a denklemini kontrol ederiz: e(com()'yi kontrol ederiz S), com (X - z)) ? = e(com(P) - com(a), com(1))*

Ayrıca bilinmesi gereken bazı temel özellikler şunları içerir:

Kanıt yalnızca 48 bayt olan com(Q) değeridir

com（P₁） + com（P₂） = com（P₁ + P₂）

*Bu aynı zamanda değeri mevcut bir sözleşmede "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 ve başka hiçbir değerlendirme değişikliği yok" sözünü verdikten sonra com(new_P) = com(P) + (ba)*com(Li) olarak ayarladık, burada Li "lag Langerian" polinom", wⁱ'da 1'e ve diğer wj noktalarında 0'a eşittir. *

• Bu güncellemeleri verimli bir şekilde gerçekleştirmek için, her istemci tüm N taahhüdünü önceden hesaplayabilir ve Lagrangian polinomuna (com(Li)) depolayabilir. Zincir üstü bir sözleşmede, tüm N taahhüdünü depolamak çok fazla olabilir, bu nedenle com(L_i) değerleri kümesine KZG taahhütleri verebilirsiniz, böylece birisinin zincir üzerindeki ağacı güncellemesi gerektiğinde, sadece Uygun com(L_i) adresine gönderin, doğruluğunun kanıtını sağlar. *

Yani, büyüyen listenin sonuna değer katan, ancak belirli bir boyut sınırı olan bir yapıya sahip olun. Ardından, bu yapıyı (i) o L2'de depolanan ve L1'e yansıtılan her bir L2'deki anahtarlar listesine yönelik taahhütler ve (ii) üzerinde Ethereum'da depolanan L2 anahtarlarına yönelik taahhütler listesine yönelik taahhütler için bir veri yapısı olarak kullanın. L1 ve her L2'ye yansıtılır.

Taahhütlerin güncel tutulması, çekirdek L2 mantığının bir parçası olabilir veya L2 çekirdek protokolünü değiştirmeden bir para yatırma ve çekme köprüsü aracılığıyla uygulanabilir.

Tam bir kanıt aşağıdakileri gerektirir:

1. Anahtar deposunun en son com'unu (anahtar listesi) L2'de saklayın.
2. Tüm anahtar listesi taahhütlerinin listesi olan com(mirror list) içindeki değer olarak com(keylist) ile KZG kanıtı.
3. Kullanıcı anahtarının KZG sertifikasını com'da (anahtar listesi) yapın.

Aslında, yukarıdaki iki KZG kanıtı, toplam boyutu yalnızca 100 bayt olan bir kanıtta birleştirilebilir.

Bir ayrıntıya dikkat edin: Bir anahtar listesi, durum gibi bir anahtar/değer haritası değil, bir liste olduğundan, anahtar listesine sırayla konumlar atanmalıdır. Anahtar taahhüdü sözleşmesi, her bir anahtar deposunu bir kimliğe eşleyen kendi dahili kayıt defterini içerecek ve her anahtar için, diğer L2'lere açıkça söylemek için yalnızca anahtar yerine hash'i (anahtar, anahtar deposunun adresi) depolayacaktır. belirli bir girişin başvurduğu anahtar deposu.

Bu tekniğin avantajı, L2'de çok iyi performans göstermesidir. ZK-SNARK'tan yaklaşık 4 kat daha kısa, Merkle'den çok daha kısa. Hesaplama maliyeti yaklaşık 119.000 Gaz Ücretidir.

L1'de bilgi işlem gücü verilerden daha önemlidir, bu nedenle KZG, Merkle kanıtından biraz daha pahalıdır.

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

Verkle ağaçları temelde KZG taahhüdlerinin birlikte istiflenmesini içerir: 2⁴⁸ değerleri depolamak için, her biri 2²⁴ değerlere yönelik bir KZG taahhüdü olan 2²⁴ değerlerden oluşan bir listeye bir KZG taahhüdü yapılabilir.

Verkle ağaçları, anahtar-değer haritalarını tutmak için kullanılabileceğinden, Ethereum durum ağaçları olarak kabul edilir.

Verkle ağaçlarındaki ispatlar KZG ispatlarından daha uzundur, yüzlerce bayt uzunluğunda olabilirler.

Aslında, Verkle ağaçları Merkle ağaçları gibi düşünülmelidir, ancak SNARKing olmadan daha uygundur, ancak SNARKing'in daha düşük kanıt maliyetine sahip olduğu gösterilmiştir.

Verkle ağaçlarının en büyük avantajı, veri yapılarını koordine edebilmeleridir: böylece doğrudan L1 veya L2 için kullanılabilirler, üst üste binme yapısı yoktur ve L1 ve L2 için tamamen aynı mekanizma kullanılır.

Kuantum bilgisayarlar bir sorun haline geldiğinde veya Merkle dalları yeterince verimli olduklarında, Verkle ağaçlarının daha fazla kullanımı olur.

polimerizasyon

N kullanıcı N işlem yaparsa ve N çapraz zincir iddiasını kanıtlaması gerekiyorsa, bu kanıtları toplayarak çok fazla Gaz Ücreti tasarrufu sağlayabiliriz, bu şu anlama gelebilir:

• N Merkle dallarının ZK-SNARK kanıtı
• Bir KZG çoklu sertifikası
• Verkle multi-proof (veya multi-proof ZK-SNARK)

Her üç durumda da, her kanıtın maliyeti yalnızca birkaç yüz bin Gaz Ücretidir.

Geliştiricilerin, o L2'nin kullanıcıları için her L2'de böyle bir kanıt yapması gerekir; bu nedenle, bu kanıtın yararlı olması için, tüm şemanın, genellikle En az birkaç işlem olacak kadar yeterli kullanıma sahip olması gerekir.

ZK-SNARK'ların kullanılması durumunda her kullanıcının binlerce L2 Gaz Ücreti harcaması gerekebilir. KZG multi-proof kullanılıyorsa, doğrulayıcının blokta kullanılan her bir anahtar deposunun L2'sine 48 Gaz Ücreti eklemesi gerekir.

Yine de, bu maliyetler, kaçınılmaz olarak kullanıcı başına 10.000'den fazla L1 gas ücretini ve yüzbinlerce L2 gas ücretini içeren toplama olmadan çok daha düşüktür.

Verkle ağacı için, kullanıcılar doğrudan Verkle multi-proof'u kullanabilir, her kullanıcı yaklaşık 100~200 bayt ekler veya bir Verkle multi-proof ZK-SNARK yapabilirsiniz, maliyeti Merkle şubesinin ZK-SNARK'ına benzer, ama kanıt Açıkçası ucuz görünüyor.

Uygulama açısından bakıldığında, paketleyicilerin zincirler arası kanıtları ERC-4337 hesap soyutlama standardı aracılığıyla toplamasına izin vermek en iyisi olabilir. ERC-4337'de, inşaatçıların Kullanıcı İşlemlerinin parçalarını özel bir şekilde bir araya getirmesi için zaten bir mekanizma vardır. BLS imza toplama için L2 Gaz Ücretini 1,5 ila 3 kat azaltabilen bir uygulama bile vardır.

Durumu doğrudan okuyun

Son bir olasılık ve yalnızca L1'i okuyan L2 için geçerli olan (L1'in L2'yi okuması yerine), L2'yi doğrudan L1'in sözleşmelerine statik çağrılar yapacak şekilde değiştirmektir.

Bu, hedef adresi, gazı ve çağrı verilerini sağladığınız L1'e çağrı yapılmasına izin veren bir işlem kodu veya ön derleme ile yapılabilir ve bu çağrılar statik olduğundan herhangi bir L1 durumunu fiilen değiştiremezler. L2'nin mevduatları işlemek için L1'de neler olup bittiğini bilmesi gerekir, bu nedenle bunun mümkün olmasını engelleyen temel hiçbir şey yoktur; bu çoğunlukla teknik bir uygulama zorluğudur.

Anahtar deposu L1'deyse ve L2, L1'in statik çağrı işlevselliğini içeriyorsa, hiçbir tasdik gerekmediğini unutmayın.

Ancak, L2, L1 statik çağrılarını içermiyorsa veya anahtar deposu L2'deyse, kanıt gereklidir.

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

Yukarıdaki şemaların tümü, L2'nin en yakın L1 durum köküne veya en yakın L1 durumunun tamamına erişmesini gerektirir.

Aslında, L2'nin bir yatırma işlevi varsa, o zaman L1 durum kökünü L2'deki bir sözleşmeye taşımak için bu L2'yi olduğu gibi kullanabilirsiniz: L1'deki sözleşmenin BLOCKHASH işlem kodunu çağırmasını ve bunu bir varlık olarak yatırmasını sağlayın Mesaj iletildi L2'ye. Tam blok başlığı, L2 tarafında alınabilir ve durum kökü çıkarılabilir.

Bununla birlikte, her L2'nin tercihen tam en son L1 durumuna veya en yakın L1 durum köküne doğrudan erişmenin açık bir yolu vardır.

L2'nin en son L1 durum kökünü alma şeklini optimize etmedeki ana zorluk, aynı anda güvenlik ve düşük gecikme süresi elde etmektir:

• L2, doğrudan okuma L1 işlevini uygulamakta yavaşsa, yalnızca son L1 durum kökünü okuyorsa, gecikme tipik olarak 15 dakikadır, ancak bazı aşırı durumlarda gecikme haftalarca olabilir.
• L2, kesinlikle güncellenmiş L1 durum köklerini okuyacak şekilde tasarlanabilir, ancak L1 kurtarılabileceğinden (bu, tek soket kesinliğinde bile etkin olmayan sızıntılar sırasında gerçekleşir), L2'nin de kurtarılabilmesi gerekir. Yazılım mühendisliği açısından bakıldığında, bu teknik olarak zordur.
• L1 durum köklerini L2'ye getirmek için bir köprü kullanılıyorsa, varlık güncellemeleri çok uzun zaman alır; en iyi durumda, güncellemeler için sürekli olarak ödeme yapan ve diğer herkes için sistemi güncel tutan kullanıcılar vardır.
• Yine de Oracles burada kabul edilebilir bir çözüm değildir: cüzdan anahtarı yönetimi, güvenlik açısından çok kritik olan düşük düzeyli bir işlevdir, bu nedenle en fazla birkaç basit, kriptografik açıdan güvenilir olmayan düşük düzeyli altyapıya dayanmalıdır.

Ayrıca ters yönde (L1, L2'yi okur):

• İyimser Toplama'da, dolandırıcılık kanıtı gecikmeleri nedeniyle durum kökünün L1'e ulaşması bir hafta sürer. ZK özetlerinde, doğrulama süresi ve ekonomik kısıtlamaların birleşimi nedeniyle artık saatler alıyor, ancak gelecekteki teknoloji bunu azaltacak.
• Ön onay (sıralayıcıdan, onaylayıcıdan vb.) L1'in L2'yi okuması için kabul edilebilir bir çözüm değildir. Cüzdan yönetimi, güvenlik açısından çok kritik, düşük seviyeli bir işlevdir, bu nedenle L2'den L1'e iletişim güvenlik seviyesi kesinlikle yüksek olmalıdır. L1'in güvenmesi gereken tek durum kökü, L2'nin L1'deki durum kökü tutma sözleşmesi tarafından nihai durum kökü olarak kabul edilen köktür.

Bazıları, birçok DeFi kullanım durumu için güvenilir olmayan zincirler arası işlemler için kabul edilemeyecek kadar yavaş. Bununla birlikte, cüzdan anahtarlarını güncelleme kullanım durumu için, daha uzun gecikmeler daha kabul edilebilir - çünkü işlemleri geciktirmek yerine anahtar değişikliklerini geciktiriyor.

Kullanıcıların yalnızca eski anahtarı daha uzun süre saklaması gerekir. Kullanıcı anahtarı çalındığı için değiştirirse, o zaman gerçekten de uzun bir güvenlik açığı vardır, ancak bu durum hafifletilebilir, örn. Dondurma işlevine sahip bir cüzdan aracılığıyla.

Nihayetinde, gecikmeyi en aza indirgeyen en iyi çözüm, L2'nin L1 durum kökünün doğrudan okumalarını en iyi şekilde uygulamasına sahip olmaktır; burada her L2 bloğu (veya durum kök hesaplama günlüğü), en son L1 bloğuna bir işaretçi içerir; bu nedenle, eğer L1 kurtarırsa ve L2 da iyileşebilir. Anahtar deposu sözleşmesi, hızlı bir şekilde L1'e taahhüt edilebilmesi için ana ağa veya ZK toplamasının L2'sine yerleştirilmelidir.

**Diğer zincirin, Ethereum veya L2 cüzdanında depolanan anahtar deposunu tutması için Ethereum ile ne kadar bağlantıya ihtiyacı var? **

Şaşırtıcı bir şekilde, o kadar çok değil. Aslında, bir Toplama olmasına bile gerek yok.

L3 veya validium ise, kullanıcılar anahtar depolamayı L1 veya ZK toplamasında sakladıkları sürece cüzdanları orada saklamakta sorun yoktur, gerçekten Ethereum'un durum köküne doğrudan erişime sahip olmaları gerekir ve cüzdanlarını depolamaya isteklidirler. Ethereum Refactoring yaparken, Ethereum hard fork yaptığında hard fork.

ZK köprü tabanlı şemalar çekici teknik özelliklere sahiptir, ancak %51 saldırılarına veya hard fork'lara karşı sağlam olmadıkları için önemli bir zayıflıkları vardır.

Gizlilik koruması

İdeal olarak, kullanıcılar aynı zamanda mahremiyet ister. Bir kullanıcının aynı anahtar deposu tarafından yönetilen birçok cüzdanı varsa, o zaman şunlardan emin olmak ister:

• Halkın bu cüzdanların hepsinin birbirine bağlı olduğunu bilmesini engelleyin.
• Sosyal kurtarma vasileri, vesayet oldukları adresin ne olduğunu bilmeyecekler.

Ancak bu bir sorun yaratır:

• Gizliliği korumadıkları için Merkle provalarını doğrudan kullanamıyoruz.
• KZG veya SNARK'ları kullanırsak kanıtın, doğrulama anahtarının konumunu açıklamadan doğrulama anahtarının gizli bir sürümünü sağlaması gerekir.
• Toplama kullanırsak, toplayıcının konumu açık bir şekilde bilmemesi gerekir; bunun yerine, toplayıcı kör kanıtlar almalı ve bu kanıtları bir araya getirmenin bir yolunu bulmalıdır.
• Bir "hafif sürüm" kullanamayız (yalnızca anahtarlar yeniden anahtarlanırken zincirler arası tasdik), çünkü bu bir gizlilik sızıntısına neden olur: güncelleyici nedeniyle birçok cüzdan aynı anda güncellenirse, bu cüzdanların zamanlaması ilgili bilgiler olabilir. Bu nedenle, "tam sürümü" (her işlemin zincirler arası kanıtı) kullanmalıyız.

SNARK'lar için çözüm kavramsal olarak basittir: ispatlar varsayılan olarak bilgi gizler ve toplayıcıların SNARK'ları kanıtlamak için yinelemeli SNARK'lar üretmesi gerekir.

Bu yaklaşımla ilgili mevcut ana zorluk, toplama işleminin, toplayıcının oldukça yavaş olan yinelemeli bir SNARK oluşturmasını gerektirmesidir.

KZG için, KZG ispatının işini ortaya çıkarmak için indekslememeyi kullanabiliriz. Ancak kör kümeleme, daha fazla dikkat gerektiren açık bir sorundur.

Bununla birlikte, L1'i doğrudan L2'nin içinden okumak gizliliği korumazken, bu doğrudan okuma işlevinin uygulanması yine de çok yararlı olacaktır - yalnızca gecikmeyi en aza indirmek için değil, daha birçok kullanım durumu için.