Yazar: Lisa A., Taiko Labs; çeviri: Jinse Finance xiaozou
Bu makale, güven olmadan zincirler arası iletişime odaklanarak, farklı L2 zincirler arası mesajlaşma yöntemlerini toplama perspektifinden tartışacaktır. Doğrudan durum okuma yaklaşımına, hafif istemci yaklaşımına ve depolama kanıtına kısaca bakacağız. Ayrıca kanıt toplama mekanizmasını, güvenilir üçüncü taraf zincirler arası mesaj iletimini ve temel ZK çapraz zincir çözümlerini de ele alacağız. Son olarak, bugün farklı L2'lerin zincirler arası mesajlaşmayı nasıl uyguladığına bakalım.
1. Zincirler arası mesajlaşmaya giriş
Zincirler arası iletişim için tüm tarafların (L2, L3 vb.) en son Ethereum durum köküne doğrudan erişimi olmalıdır.
Tüm yatırma katmanları, L2'ye bir yatırma mesajı olarak iletilecek olan L1 durum köküne erişmek için kullanılabilen "yerleşik" bir çapraz zincir mekanizmasına sahiptir.
1**.1** Durum köküne iki tür erişim
Tip 1: Durum kökünü doğrudan okuyun - opcode veya önceden derlenmiş olarak yapılabilir. Ancak, şu ana kadar uygulanmadı, bu nedenle kanıt gerekmez.
Brecht Devos, durumu doğrudan okumanın olası bir yolunu bir araştırma makalesinde açıklıyor: "…hedef zincirde doğrudan akıllı sözleşme çağırabilen önceden derlenmiş bir sözleşmeyi açığa çıkarabiliriz. Bu, doğrudan kaynak zincirinde önceden derlenmiştir Başka bir zincirin akıllı sözleşme kodunu ekler ve yürütür. • Bu, akıllı sözleşmelerin her zaman mevcut en son duruma verimli ve kolayca kanıtlanabilir bir şekilde erişmesini sağlıyor.”
· Ayrıca Optimism'in RFP'sinde "Uzak Statik Çağırma Kavram Kanıtı"nda da açıklanmıştır.
Tip 2: Kanıt Oluşturma - yani bir blok zinciri hakkında bir ifadenin başka bir blok zincirinde kanıtlanması.
"Kanıtlı zincirler arası mesajlaşma"nın iki yaklaşımı vardır:
· Güvensiz zincirler arası iletişim — yani güvenilir üçüncü taraf olmaması (ör. hafif istemciler veya depolama kanıtı kullanımı). Güvenilir olmayan yaklaşım, hem üçüncü taraf kanıt üretimi için hem de zincirler arası iletişim katılımcılarının kendilerinin kanıt oluşturması için kullanılabilir.
Kanıtlar, zincirler arası işlemleri sağlamak için farklı toplamalar arasında paylaşılır. Bu makalede pek tartışılmayan bu yaklaşım, şu anda araştırma ve keşif aşamasındadır ve potansiyel olarak yaygın olarak uygulanabilir bir çözüm olarak görülmemektedir.
1**.2** "Kanıtlı Zincirler Arası Mesajlaşma" yöntemi
1.2.1Hafif istemci zincirler arası mesajlaşma
B zincirindeki verileri kanıtlayın
B zincirinin tam düğümünden Merkle kanıt verileri elde edin (belirli tarihsel durumlar için depolama kanıtı gerekiyorsa arşiv arşivleme düğümü);
Doğrulamak istediğimiz durumu içeren B zinciri bloğuna karşılık gelen blok başlığını ve kanıtlama verilerini, çağrı verisi olarak A zincirindeki kanıtlayıcı sözleşmesine gönderin;
Prover sözleşmesi, blok başlığı verilerine dayalı olarak blok karma değerini hesaplar, A zincirindeki hafif istemci akıllı sözleşmesini sorgular (B zincirinin blok karma değerini izler) ve karma değerinin geçerli olup olmadığını kontrol eder;
Kanıt verileri, blok başlığındaki bytes32 durum köküne göre doğrulanır.
1**.2.2** Saklama kanıtı
Proof of Storage iki "iş akışı" seçeneğine sahiptir:
· Depolama kanıtı oluşturun → zincir üzerinde kullanın
Bir kuruluşun birden çok kanıt koleksiyonunu tek bir kanıtta (hem saklama kanıtı hem de zk kanıtı) paketlemesi mümkündür. Bu isteğe bağlı bir optimizasyon adımıdır ve henüz ele alınmamıştır.
Depolama kanıtı "iş akışı"nın üç ana aşamasına bir göz atalım: depolama kanıtı oluşturma, zk kanıtı oluşturma ve bunu zincirde kullanma.
(1) Depolama Kanıtı Oluşturun
· Depolama kanıtı, belirli bilgilerin blok zincirinde var olduğunu ve doğru olduğunu kanıtlamak için gizli bir taahhüt kullanmamıza izin verir;
Depolama kanıtı, 1979'da Merkle ağaçlarının ortaya çıkışından bu yana kripto alanının bir parçası olmuştur. Bununla birlikte, vanilya saklama kanıtları genellikle oldukça büyüktür. Modern yenilik, zincir üzerinde doğrulanabilen kısa ve öz kanıtlar oluşturmak için depolama kanıtı ile kanıtlanabilir hesaplamayı birleştirmede yatmaktadır.
Bir Depolama Kanıtı oluşturmak için, bir Merkle ağacında belirli bir veri bloğu ve bununla ilişkili Merkle veya Verkle yolu sağlanmalıdır. Yol, aynı karma algoritmasını kullanarak kök sağlamayı yeniden oluşturmak için gereken kardeş sağlamalardan oluşur.
Bir Depolama Kanıtı'nı doğrulamak için alıcı, sağlanan verileri ve kök karmasını yeniden hesaplamak için Merkle veya Verkle yolunu kullanabilir. Yeniden hesaplanan kök sağlama, bilinen bir kök sağlamayla eşleşirse, alıcı, verilerin gerçek olduğundan ve gönderilen veri kümesinin bir parçası olduğundan emin olabilir.
(2) ZKP Oluşturun (Sıfır Bilgi Kanıtı)
Bununla birlikte, Ethereum tipi bir Depolama Kanıtı yaklaşık 4 kb'dir - kanıt doğrulaması çok pahalı olacağından, Depolama Kanıtı'nın tamamını hedef zincire göndermek için oldukça büyüktür. Bu nedenle, sıkıştırma için ZKP'yi (örneğin, ZK-SNARK) kullanmak mantıklıdır, bu da ispatı daha küçük ve doğrulamayı daha ucuz hale getirebilir.
(3)A****rollZKP
ZKP'leri kazandıktan sonra, hedef zincirdeki kullanıcılar kazandıkları kanıtları açabilirler (ör. blok başlıkları veya blok hash'leri yoluyla geçmiş duruma erişim).
Açma şu şekilde yapılabilir:
Zincir üzerinde birikim: Provalardan blok başlıklarını yeniden oluşturma sürecinin tamamı doğrudan blok zincirinde gerçekleştirilir. Dezavantajları: yüksek gaz ücreti, bilgi işlem kaynaklarını tüketir; avantajları: ek kanıt süresi yok, düşük gecikme, çünkü blok zinciri dışında kanıtlar oluşturmaya gerek yok.
Zincir üzerinde sıkıştırma: Verilerden fazla veya gereksiz bilgileri kaldırın veya alan verimliliği için optimize edilmiş veri yapılarını kullanın. Sıkıştırılmış veriler blok zincirine gönderilir ve gerektiğinde sıkıştırılmış veriler açılabilir. Eksileri: Verileri sıkıştırmak ve açmak, ek hesaplama anlamına gelebilir, ancak bu gecikme önemsiz olabilir. Kullanılan sıkıştırma algoritması, verilerin güvenliği üzerinde olumsuz bir etkiye sahip olabilir; avantaj: veri maliyetlerini azaltır.
Zincir dışı depolama: Verileri zincir dışında depolayın ve talep üzerine belirli veri bloklarını zincire koyun. Bu, herhangi bir nedenle büyük miktarda veri depolaması gereken çözümler için geçerlidir (örneğin, genesis bloğundan Ethereum arşiv düğümleri). Eksileri: Zincir üstü sıkıştırma ile aynı; Artıları: Veri maliyetlerini daha da azaltır.
1**.2.3** Güvenilir Üçüncü Taraf
Eksiksiz bir zincirler arası çözüm, güvenilir üçüncü taraflarla (oracle, merkezi köprüler vb.) çapraz mesajlaşma çözümlerini de içermelidir.
1**.2.4** "Evrensel" İspat Sistemi
Paylaşılan bir toplama kanıtı platformu mekanizması söz konusu olduğunda, mesajlaşma, toplama platformu içinde yerleşen blok hash'leri alınarak hızlandırılabilir ve buradaki anlaşma, mesajlaşmayı da yönetir (ancak toplama platformunda bir sorun varsa) ne yapalım?).
1**.2.5 ZK****çapraz zincir mesajlaşmanın bazı bilinmeyen sorunları**
Zincirler arası mesajlaşma, güvenilir bir üçüncü şahıs (tek bir varlık veya birden çok varlık olabilir) olmadan uygulanabilir mi? Zincirler arası mesaj iletimi için verimli bir mekanizma nedir? Genel olarak, Ethereum L2 (L1'in blok hash'lerine doğrudan erişim ile) ve Ethereum'un kendisi için, bir zincirin hafif bir istemci vb. çalıştırabilmesi, güvenilir olmayan zincirler arası mesajlaşma için yeterlidir.
Zincirler arası kanıt üretimi için kullanılan ZK devresi uygun şekilde ölçeklenmiş mi? Bazı durumlarda, özellikle konsensüs katmanı (çapraz zincir işlemler için doğrulanması gereken) çok büyük olduğunda, ZK çapraz zincir mesaj iletimi için kullanılan devre, toplama ve zincir üstü depolamadan çok daha büyük olabilir ve hesaplama yükü de çok büyük. Muhtemelen bu sorun daha merkezi bir yaklaşımla aşılabilir.
2**、Çapraz zincir mesajlaşma çözümü örneği**
· Su****ccinct Labs kaynak zincirinden hedef zincir mutabakat katmanına mutabakatı doğrulamak için hafif bir istemci kullanır. Buradaki fikir, düğümlerin nihai blok zinciri durumunun blok başlıklarını senkronize edebilmesini sağlamak için hafif bir istemci protokolünün var olmasıdır. ZKP fikir birliği kanıtları oluşturmak için kullanılır.
· La****grange Labs, etkileşimli olmayan bir zincirler arası durum kanıtı oluşturur. Lagrange, durum kökünü oluşturmaktan ağın sorumlu olduğunu kanıtlar. Her Lagrange düğümü, belirli bir zincirin durumunu kanıtlayan bir parçanın özel anahtarının bir bölümünü içerir. Her durum kökü, belirli bir zincirin belirli bir zamanda durumunu doğrulamak için kullanılabilen eşik imzalı bir Verkle köküdür. Durum kökü tamamen geneldir ve zincirdeki herhangi bir sözleşmenin veya cüzdanın mevcut durumunu kanıtlamak için durum kanıtında kullanılabilir.
· O****rodotus, akıllı sözleşmeler sağlamak ve diğer Ethereum katmanlarının zincirindeki verilere eşzamanlı olarak erişmek için ZKP depolama kanıtını kullanır. Doğrulama için, Ethereum toplamaları arasında blok karmalarını senkronize etmek için yerel L1<>L2 mesajlaşmasını kullanır.
=nil; Foundation (Mina, L1), Mina durumunun geçerliliğini doğrulamak için Ethereum üzerindeki akıllı sözleşmelere izin verir. Ethereum'da doğrulaması ucuz olan özel amaçlı durum kanıtı oluşturun (Ethereum'da yerel Mina kanıtları pahalıdır). Varsayımsal olarak (gelecekte) uygulamalar, zincirler arası işlemlerin geçerliliğini kontrol etmek için doğrudan Mina'nın kanıt oluşturma aracını kullanabilir. =nil; Vakfın ayrıca, kullanıcıların/projelerin öncelikli olarak güvene dayalı olmayan veri erişimine izin veren SNARK kanıtlarını satın alabileceği/satabileceği bir Kanıt Pazarı vardır.
Axiom: Axiom şimdiye kadar defter için bir ZKP oluşturmuşsa - belirli bir blok için bir ZKP oluşturması gerekmez - bu ZKP'yi zincire aktarabilir (geçici olarak) veya hatta erişim sağlar. bu ZKP'dir.
3. L2 zincirler arası mesajlaşma
*Sorumluluk Reddi: Zincirler arası mesajlaşma, L2'nin çoğu için hala gelişmektedir. Aşağıdaki tüm analizler açık kaynak bilgilerine dayanmaktadır. Bununla birlikte, makalede bahsedilen çözümler keşif ve test aşamasında olabilir ve toplama, sonunda başka yöntemler benimseyebilir. *
**(1)**Taiko
Taiko, her zincir için blok karmalarını saklar. Her bir zincir çifti için, birbirinin hash'lerini depolayan iki akıllı sözleşme kullanır. L2←→L1 örneğinde, Taiko üzerinde her L2 bloğu oluşturulduğunda, L1 üzerindeki çevresel blokların hash değerleri TaikoL2 sözleşmesinde saklanır. Ayrıca L1←→L2 durumunda çalışma modu aynıdır.
Hedef zincirde saklanan en son bilinen Merkle kökü, TaikoL1/TaikoL2 sözleşmesinde getCrossChainBlockHash(0) çağrılarak elde edilebilir ve doğrulanacak değer/mesaj alınır. Bilinen en son Merkle kökünün kardeş karması, "kaynak zincirinde" standart bir RPC kullanılarak eth_getProof isteği çağrılarak elde edilebilir.
Ardından, "hedef zincir" üzerindeki bir listede saklanan bilinen en son blok sağlamalarına göre doğrulanmaları için göndermeniz yeterlidir. Doğrulayıcı, Merkle kökünü yeniden hesaplamak için bir değer (Merkle ağacındaki bir yaprak) ve kardeş sağlamaları alacak ve hedef zincirin blok sağlamaları listesinde depolanan kökle eşleşip eşleşmediğini kontrol edecektir.
**(2)**Starknet
Starknet, güvenilir çapraz zincir mesajlaşma için Depolama Kanıtı kullanır.
L2→L1 Mesajlaşma Protokolü
· Bir Starknet işleminin yürütülmesi sırasında, Starknet üzerindeki bir sözleşme L2→L1 mesajı gönderir.
Mesaj parametreleri (alıcı sözleşmesini ve L1'deki ilgili verileri içerir) daha sonra ilgili durum güncellemesine (ana depolama ağacı) eklenir.
· L1'de bir olay düzenleyin (mesaj parametrelerini saklayın).
L1'deki alıcı adresleri, mesaj parametrelerini yeniden sağlayarak bir L1 işleminin parçası olarak mesaja erişebilir ve mesajı kullanabilir.
· Zincirler arası mesajlar, gövde ağacında saklanır.
L2 → L1
L1 → L2
**(3)**İyimserlik
L1 ve L2 arasındaki iletişim, "haberciler" adı verilen iki özel akıllı sözleşme ile gerçekleştirilir.
· İyimserlik (L2) to Ethereum (L1) işlemleri için, durum kökü yazıldıktan sonra L1 üzerindeki mesajın Merkle ispatını sağlamak gerekir. Bu ispat işlemi L1 zincirinin bir parçası haline geldikten sonra, hata sorgulama dönemi başlar. Bu bekleme süresinden sonra, herhangi bir kullanıcı Ethereum üzerinde ikinci bir işlemi tetikleyerek, hedef L1 sözleşmesine bir mesaj göndererek işlemi "sonlandırabilir".
· Zincirler arası mesajlar, gövde ağacında saklanır.
(4)Ar****bitrum
Yeniden denenebilir biletler, Arbitrum'un L1'den L2'ye mesajlaşma, yani L2'de yürütülecek mesajları başlatan L1 işlemleri oluşturmak için kullandığı kanonik yöntemdir. Bir Yeniden Denenebilir, L1'de sabit bir ücret karşılığında gönderilebilir (yalnızca çağrı verisi boyutuna bağlı olarak). Ana durum ağacı, akıllı sözleşmelerdeki özel veri biçimlerinin zincirler arası iletişimi için kullanılır. L1'de yeniden denenebilir bir bilet göndermek, L2'deki yürütmeden ayrılabilir/asenkrondur. Yeniden denenebilir öğeler, zincirler arası işlemler arasında atomiklik sağlar. L1 işlem talebi başarılı bir şekilde gönderilirse (yani geri alma olmadan), L2'de Yeniden Denenebilir yürütme, sonunda başarılı olacağına dair güçlü bir garantiye sahiptir.
Arbitrum'un iki gövdesi vardır: Nitro zinciri, Ethereum'un bir Merkle ağacı olan durum ağacı biçiminde tutulur. Onaylama Ağacı, Ethereum'da "iddia" yoluyla onaylanan Arbitrum zincirinin durumunu saklar. Tahkim zincirini ilerleten kurallar deterministiktir. Bu, bir zincirin durumu ve bazı yeni girdi değerleri verildiğinde yalnızca bir geçerli çıktı olduğu anlamına gelir. Bu nedenle, kanıt ağacı birden çok yaprak içeriyorsa, en fazla bir yaprak geçerli bir zincir durumunu temsil edebilir.
Arbitrum'un Giden Kutusu sistemi, L2'den L1'e herhangi bir sözleşme çağrısına izin verir, yani L2'den bir mesaj başlatılır ve sonunda L1'de yürütülür. L2'den L1'e mesajların ("giden mesajlar" olarak da bilinir) Arbitrum'un L1'den L2'ye mesajlarıyla (Tekrar Denenebilir) pek çok ortak noktası vardır, ancak bazı dikkate değer farklılıklar vardır. Bir Arbitrum zincirinin L2 durumunun bir kısmı, yani her bir RBlock'ta tasdik edilen kısım, zincirin geçmişindeki tüm L2'den L1'e kadar olan mesajların Merkle köküdür. Kanıtlanmış RBlock onaylandıktan sonra (genellikle kanıttan yaklaşık bir hafta sonra), Merkle kökü Giden Kutusu sözleşmesine dahil edilir ve L1'de yayınlanır. Giden Kutusu sözleşmesi, kullanıcıların mesajlarını yürütmesine izin verir.
**(5)**Poligon zkEVM
· Bu zkEVM'nin Köprü SC'si, iletişim veya varlık işlemine katılan her ağ için Çıkış Ağacı adı verilen özel bir Merkle ağacı kullanır.
Merkle köklerini kullanır (ayrı bir durum ağacında), github'da bir köprü mimarisi şeması bulunabilir.
zkEVM Bridge SC'nin konuşlandırılması, Ethereum 2.0 para yatırma sözleşmesine dayalı olarak birkaç değişiklik yaptı. Örneğin, özel olarak tasarlanmış bir yalnızca ek Merkle ağacı kullanır, ancak Ethereum 2.0 para yatırma sözleşmesiyle aynı mantığı kullanır. Diğer farklılıklar, temel karmalar ve yaprak düğümlerle ilgilidir.
Polygon zkEVM Bridge akıllı sözleşmesinin ana özelliği, Global Exit Tree'nin kökünün doğruluk durumunun ana kaynağı olduğu Exit Tree ve global Exit Tree'nin kullanılmasıdır. Bu nedenle, L1 ve L2'nin iki farklı global çıkış kök yöneticisi vardır ve Bridge SC'nin ayrı bir mantığı vardır.
(6)S****kaydır
· Ethereum ve Scroll üzerinde konuşlandırılan köprü sözleşmeleri, kullanıcıların L1 ve L2 arasında keyfi mesajlar iletmesine izin verir. Bu mesajlaşma protokolünün yanı sıra, kullanıcıların ERC-20 varlıklarını L1 ve L2 arasında köprülemesine olanak tanıyan güvenilir olmayan bir köprüleme protokolü de oluşturduk. Bir kullanıcı, Ethereum'dan Scroll'a bir mesaj veya para göndermek için Bridge sözleşmesindeki sendMessage işlemini çağırır. Röleciler bu işlemi L1'de indeksleyecek ve L2 bloklarına dahil edilmesi için sipariş verene gönderecektir. L2 köprü sözleşmesinde, Scroll back'ten Ethereum'a mesaj gönderme süreci benzerdir.
· Zincirler arası mesajlar normal mesaj sıralarında saklanır. Sipariş veren, bu sıradan zincirler arası mesajları alır ve bunları normal işlemler olarak zincire ekler.
**(7)**zksync Çağı
*Sorumluluk Reddi: Bu bölümdeki içerik, bağımsız bir ZK süper zinciri oluşturmak için modüler bir çerçeve olan ZK Stack üzerindeki zincirler arası mesajlaşmadan farklı olabilecek yalnızca zksync Era ile ilgilidir. *
· Her işlem paketinde tek bir L2->L1 mesajı bulunur.
· İşlemleri doğrudan L2'den L1'e göndermek mümkün değildir. Ancak, zkSync Era'dan Ethereum'a istediğiniz uzunlukta mesaj gönderebilir ve ardından L1 akıllı sözleşmesini kullanarak alınan mesajları Ethereum'da işleyebilirsiniz. zkSync Era, mesajın L1'e başarılı bir şekilde gönderilip gönderilmediğini belirten bir boolean parametresi döndürecek bir istek kanıtlama işlevine sahiptir. Ethereum'u gözlemleyerek veya zksync-web3 API'sinin zks_getL2ToL1LogProof yöntemini kullanarak mesajda yer alan Merkle kanıtını alın.
· L1→L2 için zkSync Era akıllı sözleşmesi, gönderenin Ethereum L1 üzerinde bir işlem talep etmesine ve verileri zkSync Era L2'ye iletmesine olanak tanır.
· Köprü sözleşmesi:
4. Sonuç
Zincirler arası iletişim, blok zincirinin toplu olarak benimsenmesi için "sahip olunması gereken" uygulamaların ayrılmaz bir parçasıdır (örneğin, Vitalik makalesinde açıklanan zincirler arası sosyal kurtarma cüzdanı). Şu anda kullanımda olan zincirler arası çözümlerin çoğu, geri çekme işlevini kapsayacak şekilde L1←→L2 için tasarlanmıştır. Bu çözümler daha fazla blok zincirine genişletilebilir. Ancak aynı zamanda, hiç kanıt olmadan "doğrudan okuma durumu" veya güven olmadan "depolama kanıtı" gibi daha gelişmiş zincirler arası iletişim çözümleri uygulanabilir. Çoğu L2 için zincirler arası iletişimde iyileştirme için hala alan vardır.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Toplama perspektifinden zincirler arası iletişimi keşfedin
Yazar: Lisa A., Taiko Labs; çeviri: Jinse Finance xiaozou
Bu makale, güven olmadan zincirler arası iletişime odaklanarak, farklı L2 zincirler arası mesajlaşma yöntemlerini toplama perspektifinden tartışacaktır. Doğrudan durum okuma yaklaşımına, hafif istemci yaklaşımına ve depolama kanıtına kısaca bakacağız. Ayrıca kanıt toplama mekanizmasını, güvenilir üçüncü taraf zincirler arası mesaj iletimini ve temel ZK çapraz zincir çözümlerini de ele alacağız. Son olarak, bugün farklı L2'lerin zincirler arası mesajlaşmayı nasıl uyguladığına bakalım.
1. Zincirler arası mesajlaşmaya giriş
Zincirler arası iletişim için tüm tarafların (L2, L3 vb.) en son Ethereum durum köküne doğrudan erişimi olmalıdır.
Tüm yatırma katmanları, L2'ye bir yatırma mesajı olarak iletilecek olan L1 durum köküne erişmek için kullanılabilen "yerleşik" bir çapraz zincir mekanizmasına sahiptir.
1**.1** Durum köküne iki tür erişim
Tip 1: Durum kökünü doğrudan okuyun - opcode veya önceden derlenmiş olarak yapılabilir. Ancak, şu ana kadar uygulanmadı, bu nedenle kanıt gerekmez.
Brecht Devos, durumu doğrudan okumanın olası bir yolunu bir araştırma makalesinde açıklıyor: "…hedef zincirde doğrudan akıllı sözleşme çağırabilen önceden derlenmiş bir sözleşmeyi açığa çıkarabiliriz. Bu, doğrudan kaynak zincirinde önceden derlenmiştir Başka bir zincirin akıllı sözleşme kodunu ekler ve yürütür. • Bu, akıllı sözleşmelerin her zaman mevcut en son duruma verimli ve kolayca kanıtlanabilir bir şekilde erişmesini sağlıyor.”
· Ayrıca Optimism'in RFP'sinde "Uzak Statik Çağırma Kavram Kanıtı"nda da açıklanmıştır.
Tip 2: Kanıt Oluşturma - yani bir blok zinciri hakkında bir ifadenin başka bir blok zincirinde kanıtlanması.
"Kanıtlı zincirler arası mesajlaşma"nın iki yaklaşımı vardır:
· Güvensiz zincirler arası iletişim — yani güvenilir üçüncü taraf olmaması (ör. hafif istemciler veya depolama kanıtı kullanımı). Güvenilir olmayan yaklaşım, hem üçüncü taraf kanıt üretimi için hem de zincirler arası iletişim katılımcılarının kendilerinin kanıt oluşturması için kullanılabilir.
Kanıtlar, zincirler arası işlemleri sağlamak için farklı toplamalar arasında paylaşılır. Bu makalede pek tartışılmayan bu yaklaşım, şu anda araştırma ve keşif aşamasındadır ve potansiyel olarak yaygın olarak uygulanabilir bir çözüm olarak görülmemektedir.
1**.2** "Kanıtlı Zincirler Arası Mesajlaşma" yöntemi
1.2.1 Hafif istemci zincirler arası mesajlaşma
B zincirindeki verileri kanıtlayın
B zincirinin tam düğümünden Merkle kanıt verileri elde edin (belirli tarihsel durumlar için depolama kanıtı gerekiyorsa arşiv arşivleme düğümü);
Doğrulamak istediğimiz durumu içeren B zinciri bloğuna karşılık gelen blok başlığını ve kanıtlama verilerini, çağrı verisi olarak A zincirindeki kanıtlayıcı sözleşmesine gönderin;
Prover sözleşmesi, blok başlığı verilerine dayalı olarak blok karma değerini hesaplar, A zincirindeki hafif istemci akıllı sözleşmesini sorgular (B zincirinin blok karma değerini izler) ve karma değerinin geçerli olup olmadığını kontrol eder;
Kanıt verileri, blok başlığındaki bytes32 durum köküne göre doğrulanır.
1**.2.2** Saklama kanıtı
Proof of Storage iki "iş akışı" seçeneğine sahiptir:
· Depolama kanıtı oluşturun → zincir üzerinde kullanın
· Depolama kanıtı oluştur → zk kanıtı oluştur → zincirde kullan
Bir kuruluşun birden çok kanıt koleksiyonunu tek bir kanıtta (hem saklama kanıtı hem de zk kanıtı) paketlemesi mümkündür. Bu isteğe bağlı bir optimizasyon adımıdır ve henüz ele alınmamıştır.
Depolama kanıtı "iş akışı"nın üç ana aşamasına bir göz atalım: depolama kanıtı oluşturma, zk kanıtı oluşturma ve bunu zincirde kullanma.
(1) Depolama Kanıtı Oluşturun
· Depolama kanıtı, belirli bilgilerin blok zincirinde var olduğunu ve doğru olduğunu kanıtlamak için gizli bir taahhüt kullanmamıza izin verir;
Depolama kanıtı, 1979'da Merkle ağaçlarının ortaya çıkışından bu yana kripto alanının bir parçası olmuştur. Bununla birlikte, vanilya saklama kanıtları genellikle oldukça büyüktür. Modern yenilik, zincir üzerinde doğrulanabilen kısa ve öz kanıtlar oluşturmak için depolama kanıtı ile kanıtlanabilir hesaplamayı birleştirmede yatmaktadır.
Bir Depolama Kanıtı oluşturmak için, bir Merkle ağacında belirli bir veri bloğu ve bununla ilişkili Merkle veya Verkle yolu sağlanmalıdır. Yol, aynı karma algoritmasını kullanarak kök sağlamayı yeniden oluşturmak için gereken kardeş sağlamalardan oluşur.
Bir Depolama Kanıtı'nı doğrulamak için alıcı, sağlanan verileri ve kök karmasını yeniden hesaplamak için Merkle veya Verkle yolunu kullanabilir. Yeniden hesaplanan kök sağlama, bilinen bir kök sağlamayla eşleşirse, alıcı, verilerin gerçek olduğundan ve gönderilen veri kümesinin bir parçası olduğundan emin olabilir.
(2) ZKP Oluşturun (Sıfır Bilgi Kanıtı)
Bununla birlikte, Ethereum tipi bir Depolama Kanıtı yaklaşık 4 kb'dir - kanıt doğrulaması çok pahalı olacağından, Depolama Kanıtı'nın tamamını hedef zincire göndermek için oldukça büyüktür. Bu nedenle, sıkıştırma için ZKP'yi (örneğin, ZK-SNARK) kullanmak mantıklıdır, bu da ispatı daha küçük ve doğrulamayı daha ucuz hale getirebilir.
(3)A****roll ZKP
ZKP'leri kazandıktan sonra, hedef zincirdeki kullanıcılar kazandıkları kanıtları açabilirler (ör. blok başlıkları veya blok hash'leri yoluyla geçmiş duruma erişim).
Açma şu şekilde yapılabilir:
Zincir üzerinde birikim: Provalardan blok başlıklarını yeniden oluşturma sürecinin tamamı doğrudan blok zincirinde gerçekleştirilir. Dezavantajları: yüksek gaz ücreti, bilgi işlem kaynaklarını tüketir; avantajları: ek kanıt süresi yok, düşük gecikme, çünkü blok zinciri dışında kanıtlar oluşturmaya gerek yok.
Zincir üzerinde sıkıştırma: Verilerden fazla veya gereksiz bilgileri kaldırın veya alan verimliliği için optimize edilmiş veri yapılarını kullanın. Sıkıştırılmış veriler blok zincirine gönderilir ve gerektiğinde sıkıştırılmış veriler açılabilir. Eksileri: Verileri sıkıştırmak ve açmak, ek hesaplama anlamına gelebilir, ancak bu gecikme önemsiz olabilir. Kullanılan sıkıştırma algoritması, verilerin güvenliği üzerinde olumsuz bir etkiye sahip olabilir; avantaj: veri maliyetlerini azaltır.
Zincir dışı depolama: Verileri zincir dışında depolayın ve talep üzerine belirli veri bloklarını zincire koyun. Bu, herhangi bir nedenle büyük miktarda veri depolaması gereken çözümler için geçerlidir (örneğin, genesis bloğundan Ethereum arşiv düğümleri). Eksileri: Zincir üstü sıkıştırma ile aynı; Artıları: Veri maliyetlerini daha da azaltır.
1**.2.3** Güvenilir Üçüncü Taraf
Eksiksiz bir zincirler arası çözüm, güvenilir üçüncü taraflarla (oracle, merkezi köprüler vb.) çapraz mesajlaşma çözümlerini de içermelidir.
1**.2.4** "Evrensel" İspat Sistemi
Paylaşılan bir toplama kanıtı platformu mekanizması söz konusu olduğunda, mesajlaşma, toplama platformu içinde yerleşen blok hash'leri alınarak hızlandırılabilir ve buradaki anlaşma, mesajlaşmayı da yönetir (ancak toplama platformunda bir sorun varsa) ne yapalım?).
1**.2.5 ZK****çapraz zincir mesajlaşmanın bazı bilinmeyen sorunları**
Zincirler arası mesajlaşma, güvenilir bir üçüncü şahıs (tek bir varlık veya birden çok varlık olabilir) olmadan uygulanabilir mi? Zincirler arası mesaj iletimi için verimli bir mekanizma nedir? Genel olarak, Ethereum L2 (L1'in blok hash'lerine doğrudan erişim ile) ve Ethereum'un kendisi için, bir zincirin hafif bir istemci vb. çalıştırabilmesi, güvenilir olmayan zincirler arası mesajlaşma için yeterlidir.
Zincirler arası kanıt üretimi için kullanılan ZK devresi uygun şekilde ölçeklenmiş mi? Bazı durumlarda, özellikle konsensüs katmanı (çapraz zincir işlemler için doğrulanması gereken) çok büyük olduğunda, ZK çapraz zincir mesaj iletimi için kullanılan devre, toplama ve zincir üstü depolamadan çok daha büyük olabilir ve hesaplama yükü de çok büyük. Muhtemelen bu sorun daha merkezi bir yaklaşımla aşılabilir.
2**、Çapraz zincir mesajlaşma çözümü örneği**
· Su****ccinct Labs kaynak zincirinden hedef zincir mutabakat katmanına mutabakatı doğrulamak için hafif bir istemci kullanır. Buradaki fikir, düğümlerin nihai blok zinciri durumunun blok başlıklarını senkronize edebilmesini sağlamak için hafif bir istemci protokolünün var olmasıdır. ZKP fikir birliği kanıtları oluşturmak için kullanılır.
· La****grange Labs, etkileşimli olmayan bir zincirler arası durum kanıtı oluşturur. Lagrange, durum kökünü oluşturmaktan ağın sorumlu olduğunu kanıtlar. Her Lagrange düğümü, belirli bir zincirin durumunu kanıtlayan bir parçanın özel anahtarının bir bölümünü içerir. Her durum kökü, belirli bir zincirin belirli bir zamanda durumunu doğrulamak için kullanılabilen eşik imzalı bir Verkle köküdür. Durum kökü tamamen geneldir ve zincirdeki herhangi bir sözleşmenin veya cüzdanın mevcut durumunu kanıtlamak için durum kanıtında kullanılabilir.
· O****rodotus, akıllı sözleşmeler sağlamak ve diğer Ethereum katmanlarının zincirindeki verilere eşzamanlı olarak erişmek için ZKP depolama kanıtını kullanır. Doğrulama için, Ethereum toplamaları arasında blok karmalarını senkronize etmek için yerel L1<>L2 mesajlaşmasını kullanır.
=nil; Foundation (Mina, L1), Mina durumunun geçerliliğini doğrulamak için Ethereum üzerindeki akıllı sözleşmelere izin verir. Ethereum'da doğrulaması ucuz olan özel amaçlı durum kanıtı oluşturun (Ethereum'da yerel Mina kanıtları pahalıdır). Varsayımsal olarak (gelecekte) uygulamalar, zincirler arası işlemlerin geçerliliğini kontrol etmek için doğrudan Mina'nın kanıt oluşturma aracını kullanabilir. =nil; Vakfın ayrıca, kullanıcıların/projelerin öncelikli olarak güvene dayalı olmayan veri erişimine izin veren SNARK kanıtlarını satın alabileceği/satabileceği bir Kanıt Pazarı vardır.
Axiom: Axiom şimdiye kadar defter için bir ZKP oluşturmuşsa - belirli bir blok için bir ZKP oluşturması gerekmez - bu ZKP'yi zincire aktarabilir (geçici olarak) veya hatta erişim sağlar. bu ZKP'dir.
3. L2 zincirler arası mesajlaşma
*Sorumluluk Reddi: Zincirler arası mesajlaşma, L2'nin çoğu için hala gelişmektedir. Aşağıdaki tüm analizler açık kaynak bilgilerine dayanmaktadır. Bununla birlikte, makalede bahsedilen çözümler keşif ve test aşamasında olabilir ve toplama, sonunda başka yöntemler benimseyebilir. *
**(1)**Taiko
Taiko, her zincir için blok karmalarını saklar. Her bir zincir çifti için, birbirinin hash'lerini depolayan iki akıllı sözleşme kullanır. L2←→L1 örneğinde, Taiko üzerinde her L2 bloğu oluşturulduğunda, L1 üzerindeki çevresel blokların hash değerleri TaikoL2 sözleşmesinde saklanır. Ayrıca L1←→L2 durumunda çalışma modu aynıdır.
Hedef zincirde saklanan en son bilinen Merkle kökü, TaikoL1/TaikoL2 sözleşmesinde getCrossChainBlockHash(0) çağrılarak elde edilebilir ve doğrulanacak değer/mesaj alınır. Bilinen en son Merkle kökünün kardeş karması, "kaynak zincirinde" standart bir RPC kullanılarak eth_getProof isteği çağrılarak elde edilebilir.
Ardından, "hedef zincir" üzerindeki bir listede saklanan bilinen en son blok sağlamalarına göre doğrulanmaları için göndermeniz yeterlidir. Doğrulayıcı, Merkle kökünü yeniden hesaplamak için bir değer (Merkle ağacındaki bir yaprak) ve kardeş sağlamaları alacak ve hedef zincirin blok sağlamaları listesinde depolanan kökle eşleşip eşleşmediğini kontrol edecektir.
**(2)**Starknet
Starknet, güvenilir çapraz zincir mesajlaşma için Depolama Kanıtı kullanır.
L2→L1 Mesajlaşma Protokolü
· Bir Starknet işleminin yürütülmesi sırasında, Starknet üzerindeki bir sözleşme L2→L1 mesajı gönderir.
Mesaj parametreleri (alıcı sözleşmesini ve L1'deki ilgili verileri içerir) daha sonra ilgili durum güncellemesine (ana depolama ağacı) eklenir.
· L2 mesajları, akıllı sözleşmenin L1'inde saklanır.
· L1'de bir olay düzenleyin (mesaj parametrelerini saklayın).
L1'deki alıcı adresleri, mesaj parametrelerini yeniden sağlayarak bir L1 işleminin parçası olarak mesaja erişebilir ve mesajı kullanabilir.
· Zincirler arası mesajlar, gövde ağacında saklanır.
L2 → L1
L1 → L2
**(3)**İyimserlik
L1 ve L2 arasındaki iletişim, "haberciler" adı verilen iki özel akıllı sözleşme ile gerçekleştirilir.
· İyimserlik (L2) to Ethereum (L1) işlemleri için, durum kökü yazıldıktan sonra L1 üzerindeki mesajın Merkle ispatını sağlamak gerekir. Bu ispat işlemi L1 zincirinin bir parçası haline geldikten sonra, hata sorgulama dönemi başlar. Bu bekleme süresinden sonra, herhangi bir kullanıcı Ethereum üzerinde ikinci bir işlemi tetikleyerek, hedef L1 sözleşmesine bir mesaj göndererek işlemi "sonlandırabilir".
· Zincirler arası mesajlar, gövde ağacında saklanır.
(4)Ar****bitrum
Yeniden denenebilir biletler, Arbitrum'un L1'den L2'ye mesajlaşma, yani L2'de yürütülecek mesajları başlatan L1 işlemleri oluşturmak için kullandığı kanonik yöntemdir. Bir Yeniden Denenebilir, L1'de sabit bir ücret karşılığında gönderilebilir (yalnızca çağrı verisi boyutuna bağlı olarak). Ana durum ağacı, akıllı sözleşmelerdeki özel veri biçimlerinin zincirler arası iletişimi için kullanılır. L1'de yeniden denenebilir bir bilet göndermek, L2'deki yürütmeden ayrılabilir/asenkrondur. Yeniden denenebilir öğeler, zincirler arası işlemler arasında atomiklik sağlar. L1 işlem talebi başarılı bir şekilde gönderilirse (yani geri alma olmadan), L2'de Yeniden Denenebilir yürütme, sonunda başarılı olacağına dair güçlü bir garantiye sahiptir.
Arbitrum'un iki gövdesi vardır: Nitro zinciri, Ethereum'un bir Merkle ağacı olan durum ağacı biçiminde tutulur. Onaylama Ağacı, Ethereum'da "iddia" yoluyla onaylanan Arbitrum zincirinin durumunu saklar. Tahkim zincirini ilerleten kurallar deterministiktir. Bu, bir zincirin durumu ve bazı yeni girdi değerleri verildiğinde yalnızca bir geçerli çıktı olduğu anlamına gelir. Bu nedenle, kanıt ağacı birden çok yaprak içeriyorsa, en fazla bir yaprak geçerli bir zincir durumunu temsil edebilir.
Arbitrum'un Giden Kutusu sistemi, L2'den L1'e herhangi bir sözleşme çağrısına izin verir, yani L2'den bir mesaj başlatılır ve sonunda L1'de yürütülür. L2'den L1'e mesajların ("giden mesajlar" olarak da bilinir) Arbitrum'un L1'den L2'ye mesajlarıyla (Tekrar Denenebilir) pek çok ortak noktası vardır, ancak bazı dikkate değer farklılıklar vardır. Bir Arbitrum zincirinin L2 durumunun bir kısmı, yani her bir RBlock'ta tasdik edilen kısım, zincirin geçmişindeki tüm L2'den L1'e kadar olan mesajların Merkle köküdür. Kanıtlanmış RBlock onaylandıktan sonra (genellikle kanıttan yaklaşık bir hafta sonra), Merkle kökü Giden Kutusu sözleşmesine dahil edilir ve L1'de yayınlanır. Giden Kutusu sözleşmesi, kullanıcıların mesajlarını yürütmesine izin verir.
**(5)**Poligon zkEVM
· Bu zkEVM'nin Köprü SC'si, iletişim veya varlık işlemine katılan her ağ için Çıkış Ağacı adı verilen özel bir Merkle ağacı kullanır.
Merkle köklerini kullanır (ayrı bir durum ağacında), github'da bir köprü mimarisi şeması bulunabilir.
zkEVM Bridge SC'nin konuşlandırılması, Ethereum 2.0 para yatırma sözleşmesine dayalı olarak birkaç değişiklik yaptı. Örneğin, özel olarak tasarlanmış bir yalnızca ek Merkle ağacı kullanır, ancak Ethereum 2.0 para yatırma sözleşmesiyle aynı mantığı kullanır. Diğer farklılıklar, temel karmalar ve yaprak düğümlerle ilgilidir.
Polygon zkEVM Bridge akıllı sözleşmesinin ana özelliği, Global Exit Tree'nin kökünün doğruluk durumunun ana kaynağı olduğu Exit Tree ve global Exit Tree'nin kullanılmasıdır. Bu nedenle, L1 ve L2'nin iki farklı global çıkış kök yöneticisi vardır ve Bridge SC'nin ayrı bir mantığı vardır.
(6)S****kaydır
· Ethereum ve Scroll üzerinde konuşlandırılan köprü sözleşmeleri, kullanıcıların L1 ve L2 arasında keyfi mesajlar iletmesine izin verir. Bu mesajlaşma protokolünün yanı sıra, kullanıcıların ERC-20 varlıklarını L1 ve L2 arasında köprülemesine olanak tanıyan güvenilir olmayan bir köprüleme protokolü de oluşturduk. Bir kullanıcı, Ethereum'dan Scroll'a bir mesaj veya para göndermek için Bridge sözleşmesindeki sendMessage işlemini çağırır. Röleciler bu işlemi L1'de indeksleyecek ve L2 bloklarına dahil edilmesi için sipariş verene gönderecektir. L2 köprü sözleşmesinde, Scroll back'ten Ethereum'a mesaj gönderme süreci benzerdir.
· Zincirler arası mesajlar normal mesaj sıralarında saklanır. Sipariş veren, bu sıradan zincirler arası mesajları alır ve bunları normal işlemler olarak zincire ekler.
**(7)**zksync Çağı
*Sorumluluk Reddi: Bu bölümdeki içerik, bağımsız bir ZK süper zinciri oluşturmak için modüler bir çerçeve olan ZK Stack üzerindeki zincirler arası mesajlaşmadan farklı olabilecek yalnızca zksync Era ile ilgilidir. *
· Her işlem paketinde tek bir L2->L1 mesajı bulunur.
· İşlemleri doğrudan L2'den L1'e göndermek mümkün değildir. Ancak, zkSync Era'dan Ethereum'a istediğiniz uzunlukta mesaj gönderebilir ve ardından L1 akıllı sözleşmesini kullanarak alınan mesajları Ethereum'da işleyebilirsiniz. zkSync Era, mesajın L1'e başarılı bir şekilde gönderilip gönderilmediğini belirten bir boolean parametresi döndürecek bir istek kanıtlama işlevine sahiptir. Ethereum'u gözlemleyerek veya zksync-web3 API'sinin zks_getL2ToL1LogProof yöntemini kullanarak mesajda yer alan Merkle kanıtını alın.
· L1→L2 için zkSync Era akıllı sözleşmesi, gönderenin Ethereum L1 üzerinde bir işlem talep etmesine ve verileri zkSync Era L2'ye iletmesine olanak tanır.
· Köprü sözleşmesi:
4. Sonuç
Zincirler arası iletişim, blok zincirinin toplu olarak benimsenmesi için "sahip olunması gereken" uygulamaların ayrılmaz bir parçasıdır (örneğin, Vitalik makalesinde açıklanan zincirler arası sosyal kurtarma cüzdanı). Şu anda kullanımda olan zincirler arası çözümlerin çoğu, geri çekme işlevini kapsayacak şekilde L1←→L2 için tasarlanmıştır. Bu çözümler daha fazla blok zincirine genişletilebilir. Ancak aynı zamanda, hiç kanıt olmadan "doğrudan okuma durumu" veya güven olmadan "depolama kanıtı" gibi daha gelişmiş zincirler arası iletişim çözümleri uygulanabilir. Çoğu L2 için zincirler arası iletişimde iyileştirme için hala alan vardır.