Yazar: Vitalik Buterin Derleme: Yöresel Blockchain
Üç vardiyayla ilgili önceki makalemde, L1 + çapraz L2 desteği, cüzdan güvenliği ve gizliliği ekosistem yığınının gerekli temel özellikleri olarak açıkça düşünmeye başlamanın değerli olmasının nedenlerinden bazılarını özetledim. tek bir cüzdan tarafından ayrı ayrı tasarlanabilen.
Bu gönderi, belirli bir alt problemin teknik yönlerine daha doğrudan odaklanacaktır, örneğin: L1'in L2'den, L2'nin L1'den veya L2'nin başka bir L2'den nasıl daha kolay okunacağı gibi. Bu sorunu ele almak, varlık/anahtar deposu ayırma mimarilerini etkinleştirmek için kritik öneme sahiptir, ancak diğer alanlarda da değerli kullanım örneklerine sahiptir; en önemlisi, varlıkların L1 ve L2 arasında taşınması gibi kullanım durumları dahil olmak üzere güvenilir çapraz L2 çağrı zincirlerini optimize eder.
Bu makale kataloğu
amaç nedir?
Çapraz zincir kanıtı neye benziyor?
Ne tür bir ispat şeması kullanabiliriz?
Merkle kanıtı
ZK SNARK'lar
Özel KZG sertifikası
Verkle ağaç kanıtı
polimerizasyon
doğrudan durum okuma
L2, en son Ethereum durum kökünü nasıl öğrenir?
L2 olmayan zincirlerdeki cüzdanlar
Gizlilik koruması
özetle
1. Hedef nedir?
L2 ana akım haline geldiğinde, kullanıcılar birden fazla L2'de ve muhtemelen L1'lerde de varlıklara sahip olacak. Akıllı sözleşme cüzdanları (multisig, sosyal kurtarma veya başka türlü) yaygın hale geldiğinde, belirli hesaplara erişmek için gereken anahtarlar zamanla değişecek ve eski anahtarların artık geçerli olması gerekmeyecek. Bu iki şey gerçekleştiğinde, kullanıcılar çok sayıda işlem yapmadan birçok farklı yerde bulunan birçok hesaba erişimi olan anahtarları değiştirmek için bir yola ihtiyaç duyacaktır.
Özellikle, karşı olgusal adreslerle başa çıkmak için bir yola ihtiyacımız var: zincir üzerinde herhangi bir şekilde "kayıtlı" olmayan ancak yine de güvenli bir şekilde fon alması ve tutması gereken adresler. Hepimiz karşı-olgusal adreslere güveniriz: Ethereum'u ilk kullandığınızda, birisinin size ödeme yapmak için kullanabileceği bir ETH adresini zincir üzerindeki adresi "kaydetmeden" oluşturabilirsiniz (bu, bir txfee ödemeyi gerektirir, yani zaten bir miktar ETH tutun).
EOA için, tüm adresler karşı olgusal bir adresle başlar. Akıllı sözleşme cüzdanlarında, yalnızca belirli bir hash ile eşleşen bir koda sahip bir akıllı sözleşme tarafından doldurulabilen bir ETH adresine sahip olmanızı sağlayan CREATE2 sayesinde, karşı olgusal adresler hala mümkündür.
EIP-1014 (CREATE2) Adres Hesaplama Algoritması
Bununla birlikte, akıllı sözleşme cüzdanları yeni bir zorluk getiriyor: anahtar değişikliklerine erişim olasılığı. Bu adres, başlangıç kodunun bir karmasıdır ve yalnızca cüzdanın ilk doğrulama anahtarını içerebilir. Mevcut doğrulama anahtarı, cüzdanın deposunda saklanacak, ancak bu depolama kaydı sihirli bir şekilde diğer L2'lere yayılmayacak.
Bir kullanıcının birçok L2'de, bulundukları L2 tarafından bilinmeyen adresler de dahil olmak üzere birçok adresi varsa (çünkü bunlar karşı olgusaldır), o zaman kullanıcıların anahtarlarını değiştirmelerine izin vermenin tek bir yolu var gibi görünüyor: bir varlık/anahtar deposu ayırma mimarisi. 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 deposu sözleşmesi" (ya L1'de ya da belirli bir L2'de) ve (ii) doğrulama anahtarları için zincirler boyunca okuyan "cüzdan sözleşmeleri" vardır.
Bunu başarmanın iki yolu vardır:
Hafif sürüm (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 olarak saklanan doğrulama anahtarı anahtarını eşleştirmek üzere güncellemek için çağrılabilen bir işlev içerir. M-cüzdan belirli bir L2'de ilk kez kullanıldığında, anahtar deposundan geçerli kimlik doğrulama anahtarını almak için bu işlev çağrılmalıdır.
-Artıları: Çapraz zincir kanıtları idareli kullanılır, bu nedenle zincirler arası kanıtların pahalı olup olmadığı önemli değildir. Tüm fonlar yalnızca geçerli anahtarla kullanılabilir, bu nedenle güvenli kalır.
Dezavantaj: Doğrulama anahtarını değiştirmek için, anahtar deposunda ve başlatılan her cüzdanda (karşı-olgusal bir cüzdan olmasa da) zincir üzerinde bir anahtar değişikliği yapmanız gerekir. Bu çok fazla gaza mal olabilir.
Ağır sürüm (her tx'i kontrol edin): Her işlem, anahtar deposundaki mevcut anahtarı gösteren zincirler arası bir kanıt gerektirir.
Artıları: daha az sistem karmaşıklığı, ucuz anahtar deposu güncellemeleri.
Eksileri: Tek tx pahalıdır, bu nedenle zincirler arası provaları çok daha ucuz hale getirmek için daha fazla mühendislik gerekir. Ayrıca, şu anda doğrulama sırasında sözleşmeler arasında değiştirilebilir nesnelerin okunmasını desteklemeyen ERC-4337 ile kolayca uyumlu değildir.
2. Çapraz zincir kanıtı neye benziyor?
Tüm karmaşıklığı göstermek için en zor durumu inceleyeceğiz: bir L2'de anahtar deposu, farklı bir L2'de cüzdan. M-cüzdandaki anahtar deposu L1'deyse, bu tasarımın yalnızca yarısı gerekir.
Anahtar deposunun Linea'da ve cüzdanın Kakarot'ta olduğunu varsayalım. M-cüzdan anahtarının tam kanıtı şunları içerir:
Kakarot tarafından bilinen mevcut Ethereum durum kökü göz önüne alındığında, mevcut Linea durum kökünün kanıtı
Mevcut Linea durum kökü verildiğinde, anahtar deposundaki mevcut anahtarın kanıtı
Burada iki ana zorlu uygulama sorunu vardır:
Ne tür kanıtlar kullanıyoruz? (Bu bir Merkel kanıtı mı? Başka bir şey mi?
L2 ilk olarak en yakın L1 (Ethereum) durum kökünü (veya göreceğimiz gibi muhtemelen tam L1 durumunu) nasıl öğrenir? Veya L1, L2 durum köklerini nasıl öğrenir?
Her iki durumda da, bir tarafta olanlarla diğer tarafta kanıtlanabilenler arasındaki gecikme ne kadardır?
3. Ne tür ispat şemaları kullanabiliriz?
Beş ana seçenek vardır:
-Merkle kanıtı
-Genel ZK-SNARK'lar
Özel kanıt (örn. KZG kullanarak)
-Verkle, altyapı iş yükü ve maliyet açısından KZG ve ZK-SNARK'lar arasında olduklarını gösteriyor.
Kanıt gerekmez, doğrudan durum okumaya dayanır
Gerekli altyapı çalışması ve kullanıcı maliyeti açısından kabaca şöyle sıralayabilirim:
"Toplama", her blokta kullanıcılar tarafından sağlanan tüm kanıtların, tüm kanıtları birleştiren büyük bir meta kanıtta toplanmasını ifade eder. Bu, SNARK ve KZG ile mümkündür, ancak Merkle çatalları ile mümkün değildir (Merkle çatallarını biraz birleştirebilirsiniz, ancak yalnızca log(blok başına txs)/log(toplam anahtar deposu sayısı) kazandırır, pratikte Muhtemelen %15-30'dur ortada, bu yüzden muhtemelen fiyatına değmez).
Toplama, yalnızca senaryo çok sayıda kullanıcıya sahip olduğunda faydalı olur, bu nedenle pratikte bir sürüm 1 uygulaması toplamayı atlayabilir ve sürüm 2'de uygulayabilir.
4. Merkle ispatları nasıl çalışacak?
Bu kolaydır: önceki bölümdeki şemayı takip etmeniz yeterlidir. Daha kesin olarak, her bir "kanıt" (bir L2'nin maksimum zorluğunu başka bir L2'ye kanıtlama durumunu varsayarsak) aşağıdakileri içerecektir:
L2 tarafından bilinen Ethereum'un en son durum kökü verildiğinde, anahtar deposunu tutan L2'nin durum kökünü onaylayan bir Merkle şubesi. Anahtar deposu, bilinen bir adresteki bilinen bir depolama yuvasında depolanan L2'nin durum kökünü tutar (L1'deki sözleşme L2'yi temsil eder), böylece ağaçtan geçen yol sabit kodlanabilir.
Anahtar deposunu tutan L2'nin durum kökü verildiğinde, geçerli doğrulama anahtarını onaylayan bir Merkle şubesi. Burada yine kimlik doğrulama anahtarı, bilinen bir adreste 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 kitaplıklar vardır ve bu kitaplıkları kullanırsanız, bu mekanizmanın uygulanması çok karmaşık değildir.
**Daha büyük sorun maliyettir. **Merkle ispatları çok uzun, ne yazık ki Patricia ağacı gerekenden ~3,9 kat daha uzun (kesin olarak: N nesneyi tutan bir ağaç için ideal bir Merkle ispatı 32 * log2(N) bayt uzunluğundadır ve Ethereum'un Patricia ağaçları çocuk başına 16 yaprak vardır ve bu ağaçların ispatı 32 * 15 * log16(N) ~= 125 * log2(N) bayt uzunluğundadır). Yaklaşık 250 milyon (~2²⁸) hesaba sahip bir durumda, bu, her bir kanıtı 125 * 28 = 3500 bayt veya yaklaşık 56.000 gas, artı ek kod çözme ve karmayı doğrulama maliyeti yapar.
İki kanıt birlikte, yaklaşık 100.000 ila 150.000 gas'a mal olur (işlem başına kullanılırsa, imza doğrulama hariç) - işlem başına 21.000 gas olan mevcut taban fiyattan çok daha yüksektir. 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 çok daha az düğüm içeren bir ekosistemde yapılır. Öte yandan, veriler L1'de yayınlanmalıdır. Yani karşılaştırma 21k gaza karşı 15k gaz değil; 21k L2 gazına karşı 100k L1 gazı.
L1 gaz maliyeti ile L2 gaz maliyeti arasındaki karşılaştırmaya bakarak bunun ne anlama geldiğini hesaplayabiliriz:
Şu anda L1, basit gönderme için L2'den 15-25 kat daha pahalı ve token takasları için 20-50 kat daha pahalı. Basit gönderme nispeten büyük miktarda veridir, ancak hesaplanan değişim miktarı çok daha fazladır. Bu nedenle takas, L2 hesaplamasına karşı L1 hesaplamasının yaklaşık maliyeti için daha iyi bir kıyaslamadır. Tüm bunları hesaba katarsak, L1 hesaplama maliyeti ile L2 hesaplama maliyeti arasında 30x'lik bir maliyet oranı varsayarsak, bu, L2'ye bir Merkle kanıtı koymanın maliyetinin 50 normal işleme eşdeğer olabileceğini ima ediyor gibi görünüyor.
Tabii ki, ikili Merkle ağaçlarını kullanmak maliyeti ~4 kat azaltır, ancak o zaman bile, çoğu durumda maliyet çok yüksektir - artık Ethereum'un mevcut altıgen durum ağacıyla uyumluluğu feda etmeye istekliysek, Bakıyoruz daha iyi seçenekler.
5. ZK-SNARK ispatı nasıl çalışacak?
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, hesaplama için yaklaşık 400 bayt alan ~400.000 GAS gerektirir (bununla karşılaştırıldığında: temel bir işlem 21.000 gas ve 100 bayt gerektirir; bu, gelecekteki Festivalde sıkıştırmadan sonra ~25 kelimeye düşürülebilir). Bu nedenle, hesaplama açısından, bir ZK-SNARK'ın maliyeti, günümüzün temel işleminin maliyetinin 19 katıdır ve veri açısından, bir ZK-SNARK'ın maliyeti, günümüzün temel işleminin maliyetinin 4 katıdır ve Gelecekte basit bir işlemin maliyetinin 16 katı.
Bu rakamlar, Merkel kanıtına göre büyük bir gelişme, ancak yine de oldukça pahalılar. Bunu geliştirmenin iki yolu vardır: (i) özel amaçlı KZG ispatları veya (ii) ERC-4337 toplamasına benzer ancak daha gelişmiş matematik kullanan toplama. İkisini de aynı anda okuyabiliriz.
6. Özel amaçlı KZG provaları nasıl çalışacak?
Uyarı, bu bölüm diğerlerinden daha matematikseldir. Bunun nedeni, genel amaçlı araçların ötesine geçmemiz ve bazı daha ucuz özel amaçlı araçlar üretmemizdir, bu nedenle daha fazla "kaputun altına" girmeliyiz. Derin matematik sana göre değilse, doğrudan bir sonraki bölüme atla.
İlk olarak, KZG taahhütlerinin nasıl çalıştığının bir özeti:
Verilerden türetilen bir polinomun KZG kanıtını kullanarak bir veri kümesini [D_1...D_n] temsil edebiliriz: özellikle, P polinomu, burada P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n.w burada "tek tip kök", bazı değerlendirme alanı boyutu N için wN = 1 değeri (bunun tümü sonlu alanlarda yapılır).
P'yi "taahhüt etmek" için eliptik bir eğri noktası com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk oluştururuz. Burada:
-G, eğri için üreteç noktasıdır
-Pi, P polinomunun i'inci katsayısıdır
-Si, güvenilir kurulumdaki i. noktadır
P(z) = a olduğunu kanıtlamak için, bir bölüm polinomu Q = (P - a) / (X - z) yaratırız ve bir taahhüt com(Q) yaratırız. Böyle bir polinom yaratmak 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 bağlılığı üzerinde eliptik bir eğri kontrolü yaparak Q * (X - z) = P - a denklemini kontrol ederiz: e(com(Q)'yu kontrol ederiz ), com( X - z)) ? = e(com(P) - com(a), com(1))
Bilinmesi gereken bazı temel özellikler şunları içerir:
kanıt sadece 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. Diyelim ki D_i'nin şu anda a olduğunu biliyoruz, onu b olarak ayarlamak istiyoruz ve D'ye yönelik mevcut taahhüt com(P)'dir. "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 müşteri tüm N taahhüdünü önceden hesaplayabilir ve Lagrange 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) (veya hash(com(L_i)) değerler kümesine bir KZG taahhüdü verebilirsiniz. birinin zincir üstü ağacı güncellerken, uygun com(L_i)'ye kendi doğruluğunun kanıtını sunması yeterlidir.
Yani bir miktar boyut sınırlamasıyla da olsa (aslında yüz milyonlarca yapılabilir olabilir) büyüyen listenin sonuna değerler eklemeye devam edebileceğimiz bir yapıya sahibiz. Bunu daha sonra (i) her bir L2'deki anahtar listesine yönelik taahhütleri, söz konusu L2'de depolanan ve L1'e yansıtılan ve (ii) Ethereum L1'de depolanan ve L2 anahtar taahhüt listesine yönelik taahhütleri yönetmek için veri yapımız olarak kullanırız. 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.
Bu nedenle, tam bir kanıt şunları gerektirir:
Anahtar deposu, L2'deki (48 bayt) en son com'u (anahtar listesi) tutar
-KZG, com(anahtar listesi)'nin com(değer in mirror_list) olduğunu kanıtlar, tüm anahtar listesi gönderme listelerine bağlılık (48 bayt)
-KZG, anahtarınızın com'da (anahtar listesi) olduğunu kanıtlar (48 bayt artı dizin için 4 bayt)
Aslında iki KZG provasını tek bir kanıtta birleştirmek mümkündür, dolayısıyla toplam boyutu yalnızca 100 bayt elde ederiz.
Bir inceliğe dikkat edin: anahtar listesi bir liste olduğundan ve durum gibi bir anahtar/değer haritası değil, 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, yalnızca anahtar yerine hash'i (anahtar deposunun adresi) depolayacaktır. belirli bir girişten bahsediyor.
Bu tekniğin avantajı, L2'de çok iyi performans göstermesidir. Veriler, ZK-SNARK'lardan ~4 kat ve Merkle kanıtlarından daha kısa olan 100 bayttır. Hesaplama maliyeti esas olarak bir çift çek veya yaklaşık 119.000 gazdır. L1'de, veriler hesaplamadan daha az önemlidir, bu nedenle ne yazık ki KZG'ler Merkle kanıtlarından biraz daha pahalıdır.
7. Verkle ağacı nasıl çalışacak?
Verkle ağaçları temelde KZG taahhütlerini (veya daha verimli olabilen ve daha basit şifreleme kullanan IPA taahhütlerini) bir araya getirmeyi içerir: 2⁴⁸ değerleri depolamak için, her birinin kendisi bir KZG Taahhüdü olan 2²⁴ değerlerden oluşan bir listeye KZG taahhüdü yaparsınız. 2²⁴ Değer. Verkle ağaçları, Ethereum durum ağaçları için kesinlikle dikkate alınır çünkü Verkle ağaçları, yalnızca listeleri değil, anahtar/değer eşlemelerini tutmak için de kullanılabilir (temelde, 2²⁵⁶ boyutunda bir ağaç oluşturabilirsiniz, ancak yalnızca onları gerçekten doldurmanız gerektiğinde ağaç).
Vicker ağacı neye benziyor? Aslında, her bir düğüme IPA tabanlı ağaçlar için 256 == 2⁸ ve KZG tabanlı ağaçlar için 2²⁴ genişlik verebilirsiniz.
Verkle ağaçlarındaki kanıtlar KZG'dekinden biraz daha uzundur; yüzlerce bayt uzunluğunda olabilirler. Özellikle birçok kanıtı tek bir kanıtta toplamaya çalışırsanız, bunları doğrulamak da zordur.
Aslında, Verkle ağaçları Merkle ağaçları gibi düşünülmelidir, ancak SNARKing olmadan daha uygulanabilir (düşük veri maliyeti nedeniyle) ve SNARKing daha ucuzdur (düşük ispat maliyeti nedeniyle).
Verkle ağaçlarının en büyük avantajı, veri yapılarını koordine edebilmeleridir: Verkle kanıtları doğrudan L1 veya L2 durumları için kullanılabilir, üst üste binme yapısı yoktur ve L1 ve L2 için tam olarak aynı mekanizmayı kullanır. Kuantum bilgisayarlar bir sorun haline geldiğinde veya Merkle dallanmasının yeterince verimli olduğu kanıtlandığında, Verkle ağaçları yerinde, uygun SNARK dostu karma işlevlere sahip ikili karma ağaçlarla değiştirilebilir.
8. Agregalar
N işlem yapan N kullanıcının (veya daha gerçekçi olarak N ERC-4337 UserOperations) N zincirler arası iddiayı kanıtlaması gerekiyorsa, bu kanıtları toplayarak çok para tasarrufu sağlayabiliriz: bu işlemleri bir blokta birleştirmek veya paketin oluşturucusu bloğa giren, tüm bu iddiaları aynı anda kanıtlayan bir kanıt oluşturabilir.
Bu şu anlamlara gelebilir:
N Merkle dalları için ZK-SNARK kanıtları
Bir KZG çoklu kanıt
Bir Verkle multi-proof (veya multi-proof ZK-SNARK)
Her üç durumda da, her kanıt sadece birkaç yüz bin gaz gerektirir. Oluşturucunun, o L2'deki kullanıcılar için her L2'de bunlardan birini yapması gerekir; bu nedenle, inşaat kolaylığı için, tüm planın, birden fazla ana L2 ticaretinde aynı blokta genellikle en az birkaç işlem olacak şekilde yeterince kullanılması gerekir. .
ZK-SNARK'lar kullanılırsa, ana marjinal maliyet sadece sözleşmeler arasında sayıların geçmesinin "iş mantığı"dır, bu nedenle her kullanıcının birkaç bin L2 gazına ihtiyacı olabilir. KZG multi-proof kullanılırsa, kanıtlayıcının blok içinde kullanılan L2'yi tutan her anahtar deposu için 48 gas eklemesi gerekir, bu nedenle şemanın kullanıcı başına marjinal maliyeti L2 başına olur (kullanıcı başına değil) ve ardından ~800 L1 gas Eklenir . Ancak bu maliyetler, kaçınılmaz olarak kullanıcı başına 10.000'den fazla L1 gazı ve yüzbinlerce L2 gazı içeren toplama olmaksızın çok daha düşüktür. Verkle ağaçları için, kullanıcı başına yaklaşık 100-200 bayt ekleyerek Verkle çoklu doğrulamalarını doğrudan kullanabilirsiniz veya Merkle çatallı ZK-SNARK'lara benzer bir maliyetle, ancak doğrulama maliyetleri olan Verkle çoklu doğrulamalarının ZK-SNARK'larını yapabilirsiniz. çok daha düşük.
Uygulama açısından bakıldığında, paketleyicilerin zincirler arası kanıtları ERC-4337 hesap soyutlama standardı aracılığıyla bir araya getirmesi daha iyidir. ERC-4337, inşaatçıların kullanıcı eylemlerinin bölümlerini özel bir şekilde bir araya getirmesi için zaten bir mekanizmaya sahiptir. BLS imza toplama için, dahil edilen diğer sıkıştırma biçimlerine bağlı olarak L2'deki gaz maliyetlerini 1,5 ila 3 kat azaltabilen bir uygulama bile vardır.
ERC-4337'nin erken bir sürümünde BLS toplu imzaları için iş akışını gösteren BLS cüzdan uygulama gönderisindeki diyagram. Zincirler arası provaları toplamaya yönelik iş akışı çok benzer görünebilir.
9. Doğrudan durum okuma
Ayrıca yalnızca L1'i okuyan L2 için mevcut olan (ve L2'yi okuyan L1 değil) son bir olasılık, L2'yi doğrudan L1'deki sözleşmelere 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 işlem kodları veya ön derleme ile yapılabilir ve çıktıyı döndürür, ancak bu çağrılar statik olduğundan, aslında herhangi bir L1 durumunu değiştiremezler. L2'nin, L1'in ödemeyi zaten işlediğini bilmesi gerekir, bu nedenle böyle bir şeyin uygulanmasını engelleyen hiçbir şey yoktur; bu çoğunlukla teknik bir uygulama zorluğudur (bkz: bu, L1'e yapılan statik çağrıları desteklemek için iyimser bir RFP'den).
Anahtar deposu L1'deyse ve L2, L1 statik çağrılarını entegre ediyorsa, hiçbir tasdik gerekmediğini unutmayın! Bununla birlikte, L2, L1 statik çağrılarını entegre etmiyorsa veya anahtar deposu L2'deyse (L1, kullanıcılar için biraz bile kullanamayacak kadar pahalı hale geldiğinde sonunda yapılması gerekebilir), o zaman kanıt gerekli olacaktır.
10. 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. Neyse ki, tüm L2'ler zaten en son L1 durumuna erişmek için bazı işlevlere sahiptir. Bunun nedeni, L1'den L2'ye mesajları, özellikle mevduatları işlemek için bu tür bir işlevselliğe ihtiyaç duymalarıdır.
Aslında, L2'nin bir para yatırma işlevi varsa, 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 L2'ye bir para yatırma mesajı olarak iletmesini sağlayın. . 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 L1'i oku" işlevselliğini tembel bir şekilde uygularsa, yalnızca son L1 durum kökünü okursa, gecikme tipik olarak 15 dakikadır, ancak aşırı hareketsizlik sızıntısı durumlarında (tolere etmeniz gereken), gecikme olabilir. haftalar.
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 iyileşebilmesi gerekir. Yazılım mühendisliği açısından bakıldığında, bu teknik olarak zordur, ancak en azından Optimistic'in yeteneği vardır.
L1 durum köklerini L2'ye getirmek için bir mevduat köprüsü kullanırsanız, basit ekonomi, mevduat güncellemeleri arasında uzun bir süre gerektirebilir: bir depozitin tam maliyeti 100.000 gas ise, 1800 $ ETH ve 200 gwei ücreti varsayalım, ve L1 kökleri L2'ye günde bir kez girerse, bu, sistemi sürdürmek için L başına günlük 236$ veya L2 başına yılda 13.148$'a mal olur. Bir saatlik gecikmenin maliyeti L2 başına yıllık 315.569$'dır. En iyi ihtimalle, sistemi diğer herkes için güncellemek ve güncel tutmak için para ödeyen, sabırsız, zengin bir kullanıcı akışı var. En kötü ihtimalle, bazı özgecil aktörler bunun bedelini kendileri ödemek zorunda kalacaklar.
"Oracles" (en azından bazı DeFi insanlarının "oracles" olarak adlandırdığı teknoloji) burada kabul edilebilir bir çözüm değildir: cüzdan anahtarı yönetimi, güvenlik açısından çok kritik, düşük seviyeli bir işlevdir, bu nedenle en fazla birkaç A çok basite bağlı olmalıdır, kriptografik güven gerektirmeyen düşük seviyeli altyapı.
Ayrıca ters yönde (L1s, L2 olarak okunur):
Optimistic Aggregation'da, durum köklerinin dolandırıcılık kanıtı gecikmeleri nedeniyle 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 - L1 iletişiminin güvenlik düzeyi mutlak olmalıdır: L2 doğrulayıcı setini devralarak yanlış bir L1 durum kökünü zorlamak bile mümkün değildir. 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.
Birçok DeFi kullanım durumu için, bazıları güvene dayalı olmayan zincirler arası işlemler için kabul edilemeyecek kadar yavaş; bu durumlar için gerçekten daha kusurlu güvenlik modellerine sahip daha hızlı köprülere ihtiyacınız var. Bununla birlikte, cüzdan anahtarlarının güncellenmesi durumunda, daha uzun gecikmeler daha kabul edilebilirdir: işlemleri saatlerce geciktirmek yerine, anahtar değişikliklerini ertelersiniz. Sadece eski anahtarı daha uzun süre saklamanız gerekiyor. Anahtarınızı çalındığı için değiştirirseniz, uzun süre bir güvenlik açığınız olur, ancak 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; da iyileşebilir. Anahtar deposu sözleşmeleri, hızlı bir şekilde L1'e bağlanabilmeleri için ana ağa veya ZK Toplamasının L2'sine yerleştirilmelidir.
L2 zincirinin blokları yalnızca önceki L2 bloklarına değil, aynı zamanda L1 bloklarına da bağlı olabilir. L1 böyle bir bağlantı üzerinden kurtarırsa, L2 de kurtarır. Parçalamanın daha önceki (Dank öncesi) sürümlerinin bu şekilde çalışması tasavvur edilmişti; kod için buraya bakın.
11. Başka bir zincirin Ethereum veya L2 cüzdanına kök salmış bir anahtar deposu tutması için Ethereum'a ne kadar bağlantıya ihtiyacı vardır?
Şaşırtıcı bir şekilde, o kadar çok değil. Aslında bir toplama olmasına bile gerek yok: L3 veya doğrulama ise, anahtar deposunu bir L1 veya ZK toplamasında tuttuğunuz sürece bir cüzdanı orada tutmakta sorun yoktur. Gerçekten ihtiyacınız olan şey, Ethereum durum köküne doğrudan erişime sahip zincir ve Ethereum yeniden düzenlenirse yeniden organize olmaya ve Ethereum hard fork yaparsa hard fork yapmaya istekli olmak için teknik ve sosyal bir taahhüttür.
İlginç bir araştırma sorusu, bir zincirin diğer birçok zincirle (örn. Ethereum ve Zcash) bu bağlantı biçimine ne ölçüde sahip olabileceğini belirlemektir. Bunu safça yapmak mümkündür: Ethereum veya Zcash yeniden organize olursa, zinciriniz yeniden organize olmayı kabul edebilir (ve Ethereum veya Zcash hard fork ise hard fork), ancak node operatörleriniz ve topluluğunuz genellikle iki kat teknolojik ve politik bağımlılığa sahiptir. Bu nedenle, bu teknik diğer bazı zincirlere bağlanmak için kullanılabilir, ancak daha yüksek bir maliyetle. ZK köprü tabanlı şemalar çekici teknik özelliklere sahiptir, ancak temel zayıflıkları, %51 saldırılarına veya hard fork'lara karşı dayanıklı olmamasıdır. Daha akıllı çözümler de olabilir.
12. Gizlilik koruması
İdeal olarak, mahremiyeti de korumak isteriz. Aynı anahtar deposu tarafından yönetilen çok sayıda cüzdanınız varsa, şunları sağlamak isteriz:
Bu cüzdanların hepsinin birbirine bağlı olup olmadığı net değil.
Sosyal Rehabilitasyon Velileri hangi adresi koruduklarını bilmiyorlar.
Bu bazı problemler yaratır:
Gizliliği korumadıkları için Merkle provalarını doğrudan kullanamayız.
KZG veya SNARK 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ı düz metindeki konumları öğrenmemeli, bunun yerine toplayıcı kör kanıtlar almalı ve bu kanıtları bir araya getirmenin bir yolunu bulmalıdır.
"Hafif sürüm" kullanamıyoruz (yalnızca zincirler arası provaları kullanarak anahtarları yenilemek), çünkü bu bir gizlilik sızıntısı yaratır: Güncelleme işlemi nedeniyle birçok cüzdan aynı anda güncellenirse, zaman alakalı olabilecek bilgileri sızdırır. bu cüzdanlar.
Bu nedenle, "ağır sürümü" (her işlemin zincirler arası kanıtı) kullanmak zorundayız.
SNARK'lar ile çözüm kavramsal olarak basittir: varsayılan olarak kanıtlar bilgi gizlidir ve toplayıcıların SNARK'ları kanıtlamak için yinelemeli SNARK'lar oluşturması gerekir.
Şu anda bu yaklaşımla ilgili temel zorluk, toplamanın toplayıcının şu anda çok yavaş olan özyinelemeli bir SNARK oluşturmasını gerektirmesidir.
KZG ile, bu çalışmayı (ayrıca bkz: Caulk makalesinde bu çalışmanın daha resmi bir versiyonu) dizin göstermeyen KZG ispatları üzerinde bir başlangıç noktası olarak kullanabiliriz. Bununla birlikte, kör delillerin toplanması, daha fazla dikkat gerektiren açık bir sorundur.
Ne yazık ki, L1'i doğrudan L2 içinden okumak gizliliği korumaz, ancak doğrudan okuma işlevini uygulamak hem gecikmeyi en aza indirmek hem de diğer uygulamalar için kullanışlı olması nedeniyle hala çok yararlıdır.
13. Özet
Zincirler arası bir sosyal kurtarma cüzdanına sahip olmak için en gerçekçi iş akışı, tek bir konumda bir anahtar deposu tutan bir cüzdan ve cüzdanın (i) kimlik doğrulama anahtarını yerel olarak güncellemek için anahtar deposunu okuduğu birçok konumda cüzdan bulunduran bir cüzdandır. görüntüleme veya (ii) her işlemi doğrulama sürecinde.
Bunu mümkün kılan kilit unsur zincirler arası kanıtlardır. Bu kanıtları optimize etmek için çalışmamız gerekiyor. ZK-SNARK'lar veya Verkle'nin ispatını bekleyen özel KZG çözümleri en iyi seçenekler gibi görünüyor.
Uzun vadede, maliyetleri en aza indirmek için bir toplama protokolü (paketleyicilerin, kullanıcılar tarafından gönderilen tüm kullanıcı eylemlerinin bir paketini oluşturmanın bir parçası olarak toplu kanıtlar oluşturduğu) gereklidir. Bu muhtemelen ERC-4337 ekosistemine entegre edilmelidir, ancak ERC-4337'de değişiklik yapılması gerekebilir.
L2 içinden L1 durumunu (veya en azından durum kökünü) okuma gecikmesini en aza indirmek için L2 optimize edilmelidir. L2'lerin L1 durumunu doğrudan okuması idealdir ve kanıt alanından tasarruf sağlar.
Cüzdanlar yalnızca L2'de olmakla kalmaz, cüzdanları Ethereum ile daha düşük düzeyde bağlantıya sahip sistemlere de koyabilirsiniz (L3, hatta Ethereum durum kökünü ve bağımsız çatal zincirlerini dahil etmeyi kabul edin).
Ancak, anahtar deposu L1'de veya yüksek güvenlikli ZK toplaması L2'de olmalıdır. L1'i kullanmak çok fazla karmaşıklıktan tasarruf sağlar, ancak bu bile uzun vadede çok pahalı olabilir, bu nedenle L2'de bir anahtar deposunun kullanılması gerekir.
Mahremiyeti korumak ekstra çalışma gerektirecek ve bazı seçimleri daha zor hale getirecektir. Ancak muhtemelen yine de gizliliği koruyan çözümlere dönmeliyiz, en azından bulduğumuz her şeyin gizliliği korumaya uyumlu olduğundan emin olmalıyız.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Buterin: Cüzdanlar ve diğer kullanım durumları için çapraz L2 okumalarına ilişkin içgörüler
Yazar: Vitalik Buterin Derleme: Yöresel Blockchain
Üç vardiyayla ilgili önceki makalemde, L1 + çapraz L2 desteği, cüzdan güvenliği ve gizliliği ekosistem yığınının gerekli temel özellikleri olarak açıkça düşünmeye başlamanın değerli olmasının nedenlerinden bazılarını özetledim. tek bir cüzdan tarafından ayrı ayrı tasarlanabilen.
Bu gönderi, belirli bir alt problemin teknik yönlerine daha doğrudan odaklanacaktır, örneğin: L1'in L2'den, L2'nin L1'den veya L2'nin başka bir L2'den nasıl daha kolay okunacağı gibi. Bu sorunu ele almak, varlık/anahtar deposu ayırma mimarilerini etkinleştirmek için kritik öneme sahiptir, ancak diğer alanlarda da değerli kullanım örneklerine sahiptir; en önemlisi, varlıkların L1 ve L2 arasında taşınması gibi kullanım durumları dahil olmak üzere güvenilir çapraz L2 çağrı zincirlerini optimize eder. Bu makale kataloğu amaç nedir? Çapraz zincir kanıtı neye benziyor? Ne tür bir ispat şeması kullanabiliriz? Merkle kanıtı ZK SNARK'lar Özel KZG sertifikası Verkle ağaç kanıtı polimerizasyon doğrudan durum okuma L2, en son Ethereum durum kökünü nasıl öğrenir? L2 olmayan zincirlerdeki cüzdanlar Gizlilik koruması özetle
1. Hedef nedir?
L2 ana akım haline geldiğinde, kullanıcılar birden fazla L2'de ve muhtemelen L1'lerde de varlıklara sahip olacak. Akıllı sözleşme cüzdanları (multisig, sosyal kurtarma veya başka türlü) yaygın hale geldiğinde, belirli hesaplara erişmek için gereken anahtarlar zamanla değişecek ve eski anahtarların artık geçerli olması gerekmeyecek. Bu iki şey gerçekleştiğinde, kullanıcılar çok sayıda işlem yapmadan birçok farklı yerde bulunan birçok hesaba erişimi olan anahtarları değiştirmek için bir yola ihtiyaç duyacaktır. Özellikle, karşı olgusal adreslerle başa çıkmak için bir yola ihtiyacımız var: zincir üzerinde herhangi bir şekilde "kayıtlı" olmayan ancak yine de güvenli bir şekilde fon alması ve tutması gereken adresler. Hepimiz karşı-olgusal adreslere güveniriz: Ethereum'u ilk kullandığınızda, birisinin size ödeme yapmak için kullanabileceği bir ETH adresini zincir üzerindeki adresi "kaydetmeden" oluşturabilirsiniz (bu, bir txfee ödemeyi gerektirir, yani zaten bir miktar ETH tutun). EOA için, tüm adresler karşı olgusal bir adresle başlar. Akıllı sözleşme cüzdanlarında, yalnızca belirli bir hash ile eşleşen bir koda sahip bir akıllı sözleşme tarafından doldurulabilen bir ETH adresine sahip olmanızı sağlayan CREATE2 sayesinde, karşı olgusal adresler hala mümkündür.
EIP-1014 (CREATE2) Adres Hesaplama Algoritması
Bununla birlikte, akıllı sözleşme cüzdanları yeni bir zorluk getiriyor: anahtar değişikliklerine erişim olasılığı. Bu adres, başlangıç kodunun bir karmasıdır ve yalnızca cüzdanın ilk doğrulama anahtarını içerebilir. Mevcut doğrulama anahtarı, cüzdanın deposunda saklanacak, ancak bu depolama kaydı sihirli bir şekilde diğer L2'lere yayılmayacak. Bir kullanıcının birçok L2'de, bulundukları L2 tarafından bilinmeyen adresler de dahil olmak üzere birçok adresi varsa (çünkü bunlar karşı olgusaldır), o zaman kullanıcıların anahtarlarını değiştirmelerine izin vermenin tek bir yolu var gibi görünüyor: bir varlık/anahtar deposu ayırma mimarisi. 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 deposu sözleşmesi" (ya L1'de ya da belirli bir L2'de) ve (ii) doğrulama anahtarları için zincirler boyunca okuyan "cüzdan sözleşmeleri" vardır.
Bunu başarmanın iki yolu vardır:
Hafif sürüm (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 olarak saklanan doğrulama anahtarı anahtarını eşleştirmek üzere güncellemek için çağrılabilen bir işlev içerir. M-cüzdan belirli bir L2'de ilk kez kullanıldığında, anahtar deposundan geçerli kimlik doğrulama anahtarını almak için bu işlev çağrılmalıdır. -Artıları: Çapraz zincir kanıtları idareli kullanılır, bu nedenle zincirler arası kanıtların pahalı olup olmadığı önemli değildir. Tüm fonlar yalnızca geçerli anahtarla kullanılabilir, bu nedenle güvenli kalır.
2. Çapraz zincir kanıtı neye benziyor?
Tüm karmaşıklığı göstermek için en zor durumu inceleyeceğiz: bir L2'de anahtar deposu, farklı bir L2'de cüzdan. M-cüzdandaki anahtar deposu L1'deyse, bu tasarımın yalnızca yarısı gerekir.
Anahtar deposunun Linea'da ve cüzdanın Kakarot'ta olduğunu varsayalım. M-cüzdan anahtarının tam kanıtı şunları içerir:
3. Ne tür ispat şemaları kullanabiliriz?
Beş ana seçenek vardır: -Merkle kanıtı -Genel ZK-SNARK'lar
"Toplama", her blokta kullanıcılar tarafından sağlanan tüm kanıtların, tüm kanıtları birleştiren büyük bir meta kanıtta toplanmasını ifade eder. Bu, SNARK ve KZG ile mümkündür, ancak Merkle çatalları ile mümkün değildir (Merkle çatallarını biraz birleştirebilirsiniz, ancak yalnızca log(blok başına txs)/log(toplam anahtar deposu sayısı) kazandırır, pratikte Muhtemelen %15-30'dur ortada, bu yüzden muhtemelen fiyatına değmez). Toplama, yalnızca senaryo çok sayıda kullanıcıya sahip olduğunda faydalı olur, bu nedenle pratikte bir sürüm 1 uygulaması toplamayı atlayabilir ve sürüm 2'de uygulayabilir.
4. Merkle ispatları nasıl çalışacak?
Bu kolaydır: önceki bölümdeki şemayı takip etmeniz yeterlidir. Daha kesin olarak, her bir "kanıt" (bir L2'nin maksimum zorluğunu başka bir L2'ye kanıtlama durumunu varsayarsak) aşağıdakileri içerecektir: L2 tarafından bilinen Ethereum'un en son durum kökü verildiğinde, anahtar deposunu tutan L2'nin durum kökünü onaylayan bir Merkle şubesi. Anahtar deposu, bilinen bir adresteki bilinen bir depolama yuvasında depolanan L2'nin durum kökünü tutar (L1'deki sözleşme L2'yi temsil eder), böylece ağaçtan geçen yol sabit kodlanabilir. Anahtar deposunu tutan L2'nin durum kökü verildiğinde, geçerli doğrulama anahtarını onaylayan bir Merkle şubesi. Burada yine kimlik doğrulama anahtarı, bilinen bir adreste 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 kitaplıklar vardır ve bu kitaplıkları kullanırsanız, bu mekanizmanın uygulanması çok karmaşık değildir. **Daha büyük sorun maliyettir. **Merkle ispatları çok uzun, ne yazık ki Patricia ağacı gerekenden ~3,9 kat daha uzun (kesin olarak: N nesneyi tutan bir ağaç için ideal bir Merkle ispatı 32 * log2(N) bayt uzunluğundadır ve Ethereum'un Patricia ağaçları çocuk başına 16 yaprak vardır ve bu ağaçların ispatı 32 * 15 * log16(N) ~= 125 * log2(N) bayt uzunluğundadır). Yaklaşık 250 milyon (~2²⁸) hesaba sahip bir durumda, bu, her bir kanıtı 125 * 28 = 3500 bayt veya yaklaşık 56.000 gas, artı ek kod çözme ve karmayı doğrulama maliyeti yapar. İki kanıt birlikte, yaklaşık 100.000 ila 150.000 gas'a mal olur (işlem başına kullanılırsa, imza doğrulama hariç) - işlem başına 21.000 gas olan mevcut taban fiyattan çok daha yüksektir. 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 çok daha az düğüm içeren bir ekosistemde yapılır. Öte yandan, veriler L1'de yayınlanmalıdır. Yani karşılaştırma 21k gaza karşı 15k gaz değil; 21k L2 gazına karşı 100k L1 gazı. L1 gaz maliyeti ile L2 gaz maliyeti arasındaki karşılaştırmaya bakarak bunun ne anlama geldiğini hesaplayabiliriz:
Şu anda L1, basit gönderme için L2'den 15-25 kat daha pahalı ve token takasları için 20-50 kat daha pahalı. Basit gönderme nispeten büyük miktarda veridir, ancak hesaplanan değişim miktarı çok daha fazladır. Bu nedenle takas, L2 hesaplamasına karşı L1 hesaplamasının yaklaşık maliyeti için daha iyi bir kıyaslamadır. Tüm bunları hesaba katarsak, L1 hesaplama maliyeti ile L2 hesaplama maliyeti arasında 30x'lik bir maliyet oranı varsayarsak, bu, L2'ye bir Merkle kanıtı koymanın maliyetinin 50 normal işleme eşdeğer olabileceğini ima ediyor gibi görünüyor. Tabii ki, ikili Merkle ağaçlarını kullanmak maliyeti ~4 kat azaltır, ancak o zaman bile, çoğu durumda maliyet çok yüksektir - artık Ethereum'un mevcut altıgen durum ağacıyla uyumluluğu feda etmeye istekliysek, Bakıyoruz daha iyi seçenekler.
5. ZK-SNARK ispatı nasıl çalışacak?
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, hesaplama için yaklaşık 400 bayt alan ~400.000 GAS gerektirir (bununla karşılaştırıldığında: temel bir işlem 21.000 gas ve 100 bayt gerektirir; bu, gelecekteki Festivalde sıkıştırmadan sonra ~25 kelimeye düşürülebilir). Bu nedenle, hesaplama açısından, bir ZK-SNARK'ın maliyeti, günümüzün temel işleminin maliyetinin 19 katıdır ve veri açısından, bir ZK-SNARK'ın maliyeti, günümüzün temel işleminin maliyetinin 4 katıdır ve Gelecekte basit bir işlemin maliyetinin 16 katı. Bu rakamlar, Merkel kanıtına göre büyük bir gelişme, ancak yine de oldukça pahalılar. Bunu geliştirmenin iki yolu vardır: (i) özel amaçlı KZG ispatları veya (ii) ERC-4337 toplamasına benzer ancak daha gelişmiş matematik kullanan toplama. İkisini de aynı anda okuyabiliriz.
6. Özel amaçlı KZG provaları nasıl çalışacak?
Uyarı, bu bölüm diğerlerinden daha matematikseldir. Bunun nedeni, genel amaçlı araçların ötesine geçmemiz ve bazı daha ucuz özel amaçlı araçlar üretmemizdir, bu nedenle daha fazla "kaputun altına" girmeliyiz. Derin matematik sana göre değilse, doğrudan bir sonraki bölüme atla. İlk olarak, KZG taahhütlerinin nasıl çalıştığının bir özeti: Verilerden türetilen bir polinomun KZG kanıtını kullanarak bir veri kümesini [D_1...D_n] temsil edebiliriz: özellikle, P polinomu, burada P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n.w burada "tek tip kök", bazı değerlendirme alanı boyutu N için wN = 1 değeri (bunun tümü sonlu alanlarda yapılır). P'yi "taahhüt etmek" için eliptik bir eğri noktası com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk oluştururuz. Burada: -G, eğri için üreteç noktasıdır -Pi, P polinomunun i'inci katsayısıdır -Si, güvenilir kurulumdaki i. noktadır P(z) = a olduğunu kanıtlamak için, bir bölüm polinomu Q = (P - a) / (X - z) yaratırız ve bir taahhüt com(Q) yaratırız. Böyle bir polinom yaratmak 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 bağlılığı üzerinde eliptik bir eğri kontrolü yaparak Q * (X - z) = P - a denklemini kontrol ederiz: e(com(Q)'yu kontrol ederiz ), com( X - z)) ? = e(com(P) - com(a), com(1)) Bilinmesi gereken bazı temel özellikler şunları içerir:
Bu nedenle, tam bir kanıt şunları gerektirir:
7. Verkle ağacı nasıl çalışacak?
Verkle ağaçları temelde KZG taahhütlerini (veya daha verimli olabilen ve daha basit şifreleme kullanan IPA taahhütlerini) bir araya getirmeyi içerir: 2⁴⁸ değerleri depolamak için, her birinin kendisi bir KZG Taahhüdü olan 2²⁴ değerlerden oluşan bir listeye KZG taahhüdü yaparsınız. 2²⁴ Değer. Verkle ağaçları, Ethereum durum ağaçları için kesinlikle dikkate alınır çünkü Verkle ağaçları, yalnızca listeleri değil, anahtar/değer eşlemelerini tutmak için de kullanılabilir (temelde, 2²⁵⁶ boyutunda bir ağaç oluşturabilirsiniz, ancak yalnızca onları gerçekten doldurmanız gerektiğinde ağaç).
Vicker ağacı neye benziyor? Aslında, her bir düğüme IPA tabanlı ağaçlar için 256 == 2⁸ ve KZG tabanlı ağaçlar için 2²⁴ genişlik verebilirsiniz. Verkle ağaçlarındaki kanıtlar KZG'dekinden biraz daha uzundur; yüzlerce bayt uzunluğunda olabilirler. Özellikle birçok kanıtı tek bir kanıtta toplamaya çalışırsanız, bunları doğrulamak da zordur. Aslında, Verkle ağaçları Merkle ağaçları gibi düşünülmelidir, ancak SNARKing olmadan daha uygulanabilir (düşük veri maliyeti nedeniyle) ve SNARKing daha ucuzdur (düşük ispat maliyeti nedeniyle). Verkle ağaçlarının en büyük avantajı, veri yapılarını koordine edebilmeleridir: Verkle kanıtları doğrudan L1 veya L2 durumları için kullanılabilir, üst üste binme yapısı yoktur ve L1 ve L2 için tam olarak aynı mekanizmayı kullanır. Kuantum bilgisayarlar bir sorun haline geldiğinde veya Merkle dallanmasının yeterince verimli olduğu kanıtlandığında, Verkle ağaçları yerinde, uygun SNARK dostu karma işlevlere sahip ikili karma ağaçlarla değiştirilebilir.
8. Agregalar
N işlem yapan N kullanıcının (veya daha gerçekçi olarak N ERC-4337 UserOperations) N zincirler arası iddiayı kanıtlaması gerekiyorsa, bu kanıtları toplayarak çok para tasarrufu sağlayabiliriz: bu işlemleri bir blokta birleştirmek veya paketin oluşturucusu bloğa giren, tüm bu iddiaları aynı anda kanıtlayan bir kanıt oluşturabilir. Bu şu anlamlara gelebilir:
ERC-4337'nin erken bir sürümünde BLS toplu imzaları için iş akışını gösteren BLS cüzdan uygulama gönderisindeki diyagram. Zincirler arası provaları toplamaya yönelik iş akışı çok benzer görünebilir.
9. Doğrudan durum okuma
Ayrıca yalnızca L1'i okuyan L2 için mevcut olan (ve L2'yi okuyan L1 değil) son bir olasılık, L2'yi doğrudan L1'deki sözleşmelere 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 işlem kodları veya ön derleme ile yapılabilir ve çıktıyı döndürür, ancak bu çağrılar statik olduğundan, aslında herhangi bir L1 durumunu değiştiremezler. L2'nin, L1'in ödemeyi zaten işlediğini bilmesi gerekir, bu nedenle böyle bir şeyin uygulanmasını engelleyen hiçbir şey yoktur; bu çoğunlukla teknik bir uygulama zorluğudur (bkz: bu, L1'e yapılan statik çağrıları desteklemek için iyimser bir RFP'den). Anahtar deposu L1'deyse ve L2, L1 statik çağrılarını entegre ediyorsa, hiçbir tasdik gerekmediğini unutmayın! Bununla birlikte, L2, L1 statik çağrılarını entegre etmiyorsa veya anahtar deposu L2'deyse (L1, kullanıcılar için biraz bile kullanamayacak kadar pahalı hale geldiğinde sonunda yapılması gerekebilir), o zaman kanıt gerekli olacaktır.
10. 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. Neyse ki, tüm L2'ler zaten en son L1 durumuna erişmek için bazı işlevlere sahiptir. Bunun nedeni, L1'den L2'ye mesajları, özellikle mevduatları işlemek için bu tür bir işlevselliğe ihtiyaç duymalarıdır. Aslında, L2'nin bir para yatırma işlevi varsa, 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 L2'ye bir para yatırma mesajı olarak iletmesini sağlayın. . 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 zincirinin blokları yalnızca önceki L2 bloklarına değil, aynı zamanda L1 bloklarına da bağlı olabilir. L1 böyle bir bağlantı üzerinden kurtarırsa, L2 de kurtarır. Parçalamanın daha önceki (Dank öncesi) sürümlerinin bu şekilde çalışması tasavvur edilmişti; kod için buraya bakın.
11. Başka bir zincirin Ethereum veya L2 cüzdanına kök salmış bir anahtar deposu tutması için Ethereum'a ne kadar bağlantıya ihtiyacı vardır?
Şaşırtıcı bir şekilde, o kadar çok değil. Aslında bir toplama olmasına bile gerek yok: L3 veya doğrulama ise, anahtar deposunu bir L1 veya ZK toplamasında tuttuğunuz sürece bir cüzdanı orada tutmakta sorun yoktur. Gerçekten ihtiyacınız olan şey, Ethereum durum köküne doğrudan erişime sahip zincir ve Ethereum yeniden düzenlenirse yeniden organize olmaya ve Ethereum hard fork yaparsa hard fork yapmaya istekli olmak için teknik ve sosyal bir taahhüttür. İlginç bir araştırma sorusu, bir zincirin diğer birçok zincirle (örn. Ethereum ve Zcash) bu bağlantı biçimine ne ölçüde sahip olabileceğini belirlemektir. Bunu safça yapmak mümkündür: Ethereum veya Zcash yeniden organize olursa, zinciriniz yeniden organize olmayı kabul edebilir (ve Ethereum veya Zcash hard fork ise hard fork), ancak node operatörleriniz ve topluluğunuz genellikle iki kat teknolojik ve politik bağımlılığa sahiptir. Bu nedenle, bu teknik diğer bazı zincirlere bağlanmak için kullanılabilir, ancak daha yüksek bir maliyetle. ZK köprü tabanlı şemalar çekici teknik özelliklere sahiptir, ancak temel zayıflıkları, %51 saldırılarına veya hard fork'lara karşı dayanıklı olmamasıdır. Daha akıllı çözümler de olabilir.
12. Gizlilik koruması
İdeal olarak, mahremiyeti de korumak isteriz. Aynı anahtar deposu tarafından yönetilen çok sayıda cüzdanınız varsa, şunları sağlamak isteriz:
Şu anda bu yaklaşımla ilgili temel zorluk, toplamanın toplayıcının şu anda çok yavaş olan özyinelemeli bir SNARK oluşturmasını gerektirmesidir. KZG ile, bu çalışmayı (ayrıca bkz: Caulk makalesinde bu çalışmanın daha resmi bir versiyonu) dizin göstermeyen KZG ispatları üzerinde bir başlangıç noktası olarak kullanabiliriz. Bununla birlikte, kör delillerin toplanması, daha fazla dikkat gerektiren açık bir sorundur. Ne yazık ki, L1'i doğrudan L2 içinden okumak gizliliği korumaz, ancak doğrudan okuma işlevini uygulamak hem gecikmeyi en aza indirmek hem de diğer uygulamalar için kullanışlı olması nedeniyle hala çok yararlıdır.
13. Özet
Zincirler arası bir sosyal kurtarma cüzdanına sahip olmak için en gerçekçi iş akışı, tek bir konumda bir anahtar deposu tutan bir cüzdan ve cüzdanın (i) kimlik doğrulama anahtarını yerel olarak güncellemek için anahtar deposunu okuduğu birçok konumda cüzdan bulunduran bir cüzdandır. görüntüleme veya (ii) her işlemi doğrulama sürecinde. Bunu mümkün kılan kilit unsur zincirler arası kanıtlardır. Bu kanıtları optimize etmek için çalışmamız gerekiyor. ZK-SNARK'lar veya Verkle'nin ispatını bekleyen özel KZG çözümleri en iyi seçenekler gibi görünüyor. Uzun vadede, maliyetleri en aza indirmek için bir toplama protokolü (paketleyicilerin, kullanıcılar tarafından gönderilen tüm kullanıcı eylemlerinin bir paketini oluşturmanın bir parçası olarak toplu kanıtlar oluşturduğu) gereklidir. Bu muhtemelen ERC-4337 ekosistemine entegre edilmelidir, ancak ERC-4337'de değişiklik yapılması gerekebilir. L2 içinden L1 durumunu (veya en azından durum kökünü) okuma gecikmesini en aza indirmek için L2 optimize edilmelidir. L2'lerin L1 durumunu doğrudan okuması idealdir ve kanıt alanından tasarruf sağlar. Cüzdanlar yalnızca L2'de olmakla kalmaz, cüzdanları Ethereum ile daha düşük düzeyde bağlantıya sahip sistemlere de koyabilirsiniz (L3, hatta Ethereum durum kökünü ve bağımsız çatal zincirlerini dahil etmeyi kabul edin). Ancak, anahtar deposu L1'de veya yüksek güvenlikli ZK toplaması L2'de olmalıdır. L1'i kullanmak çok fazla karmaşıklıktan tasarruf sağlar, ancak bu bile uzun vadede çok pahalı olabilir, bu nedenle L2'de bir anahtar deposunun kullanılması gerekir. Mahremiyeti korumak ekstra çalışma gerektirecek ve bazı seçimleri daha zor hale getirecektir. Ancak muhtemelen yine de gizliliği koruyan çözümlere dönmeliyiz, en azından bulduğumuz her şeyin gizliliği korumaya uyumlu olduğundan emin olmalıyız.