*Orijinal Başlığı İletin：Eclipse'in Canonical Ethereum Köprüsü ve Kanıtlama Sistemini Keşfetmek

Kanonik Köprümüze Genel Bir Bakış

Eclipse üç katmandan oluşmaktadır:

1. Yürütme: SVM işlem yürütmesi için Solana Labs istemcisinin(v1.17) bir çatalı
2. Uzlaşma: Eclipse'in çatal-seçim kuralını tanımlayan kanonik köprümüz, sahtekarlık kanıtlarının da sunulacağı Ethereum'da mevcuttur
3. Veri Kullanılabilirliği: Eclipse, dolandırıcılık kanıtları üretmek için gerekli verileri Celestia'da veri blobları olarak yayınlar

Aşağıdaki şemada bu modüllerin nasıl etkileşimde bulunduğu gösterilmektedir:

Bu makalenin geri kalanı, diyagramda gösterildiği gibi Eclipse'in Ethereum köprüsüne odaklanacaktır. Blobstream, Celestia'nın doğrulayıcı seti tarafından imzalanan tasdiknameleri Ethereum'a ileterek Eclipse'in bir grup slotuna ait verilerin doğru şekilde yayınlandığını onaylayacaktır. Bu, Eclipse köprüsünün Celestia'dan gelen imzalı veri köklerine karşı sahtekarlık kanıtları için sağlanan verileri doğrulamasına olanak tanır. Bu bölümün geri kalanında, hangi süreçlerden geçildiğini özetleyeceğiz:

1. fonlar köprümüz üzerinden yatırılır,
2. Eclipse'in bloklarından oluşan veri yığınları Celestia'da yayınlanmaktadır,
3. köprü üzerinden para çekme işlemleri gerçekleştirilir ve
4. dolandırıcılık kanıtları en kötü durum senaryolarında üretilir.

Eclipse'in Yerel Ethereum Köprüsü Üzerinden Para Yatırma

Bir kullanıcı yerel Ethereum köprüsü aracılığıyla Eclipse'e para yatırdığında akış aşağıdaki gibi özetlenir:

1. Bir kullanıcı Eclipse'in Ethereum'daki Deposit Bridge sözleşmesini çağırıyor
2. Eclipse'in SVM yürütücüsü [1] içinden, aktarıcı [2] kullanıcının depozito ve hedef adresini gözlemler
3. Daha sonra, aktarıcı, bir kullanıcının depozitosunu ilgili hedef adrese aktarmaktan sorumlu olan SVM köprü programını çağırır
4. Aktarıcı, para yatırma işlemini bir zk-light istemcisi aracılığıyla doğrular (uygulanacak)
5. Son olarak, sonraki para yatırma sonrası transfer işlemini içeren blok tamamlanır ve bir Solana Geyser Eklentisiaracılığıyla yayınlanır

Aşağıdaki diyagram, yukarıda açıklanan para yatırma akışı sırasında Ethereum, Celestia ve SVM Yürütücüsü arasındaki etkileşimleri göstermektedir:

Eclipse'in Yuvalarını Celestia'da Veri Blobları Olarak Yayınlama

Eclipse'in yuvalarının veri blobları olarak Celestia'ya yayınlanması için akış aşağıda özetlenmiştir:

1. SVM yürütücüsü her bir Eclipse yuvasını Geyser aracılığıyla mesaj kuyruğuna yayınlar
2. SVM yürütücüsü, Eclipse'in yuvalarını veri bloblarıolarak Celestia'ya gönderir
3. Celestia doğrulayıcı seti, Eclipse'in zincirindeki bir işlemin veri köküne dahil olduğunu kanıtlamak için kullanılabilecek, gönderilen veri bloblarına taahhütler üretir
4. Her bir Celestia blok başlığında bulunan veri kökleri, Blobstream aracılığıyla Eclipse'in Ethereum üzerindeki köprü sözleşmesine aktarılır

Celestia 'nın aşağıdaki diyagramı, belirli bir Celestia bloğundaki verilerin taahhüdünün blok başlığında nasıl saklandığını açıklamaktadır:

Eclipse'in Ethereum Köprüsüne Sahtekarlık Kanıtlarının Çekilmesi ve Gönderilmesi

Sahtekarlık kanıtları kullanan diğer L2'lere (Arbitrum, Fuel ve diğerleri) benzer şekilde, Eclipse'ten para çekme işlemleri, doğrulayıcıların geçersiz bir durum geçişi durumunda sahtekarlık kanıtları sunabilecekleri bir meydan okuma süresi gerektirir:

1. SVM yürütücüsü, düzenli bir tempoda, Eclipse'in slotlarının bir epokuna (önceden belirlenmiş sayıda parti) ilişkin bir taahhüdü teminatla birlikte Ethereum'a gönderir
2. Eclipse'in köprü sözleşmesi, gönderilen verilerin iyi biçimlendirilmiş olduğundan emin olmak için bazı temel kontroller gerçekleştirir (Sahtekarlık Kanıtı Tasarımı bölümünde açıklanmıştır)
3. Gönderilen toplu iş bu temel kontrolleri geçerse, toplu iş taahhüdünün geçersiz bir durum geçişi anlamına gelmesi durumunda doğrulayıcıların sahtekarlık kanıtlarını gönderebilecekleri önceden tanımlanmış bir pencere vardır
4. Bir doğrulayıcı başarılı bir sahtekarlık kanıtı gönderirse, uygulayıcının teminatını kazanır, gönderilen parti reddedilir ve Eclipse L2'nin kanonik durumu son geçerli parti taahhüdüne geri alınır. Burada, Eclipse'in yönetimi yeni bir yürütme görevlisi seçme yetkisine sahip olacaktır
5. Meydan okuma süresi başarılı bir dolandırıcılık kanıtı olmadan geçerse, uygulayıcı teminatını bir ödülle birlikte geri alır
6. Sonuç olarak, Eclipse köprü sözleşmesi artık sonlandırılmış partiye dahil olan tüm para çekme işlemlerini tamamlayacaktır

Sahtekarlığa Karşı Korumalı Tasarım

Bu son bölümde, Anatoly Yakovenko ve John Adler'den esinlenerek Eclipse'in dolandırıcılık kanıt sistemi tasarımını detaylandıracağız. Genel olarak, herhangi bir sahtekarlık kanıtı için, bir doğrulayıcı şunları yapmalıdır:

1. Geçersiz bir durum geçişi içeren bir işlemi tanımlama
2. Söz konusu işlemin girdilerini geçersiz durum geçişi ile sağlayın
3. Söz konusu işlemin verilen girdilerle yeniden yürütülmesinin zincir üzerinde taahhüt edilene eşit olmayan bir çıktı ile sonuçlandığını gösterin

Eclipse'in durumunda, (1) Celestia, Eclipse'in SVM yürütücüsünün gönderdiği blok yığınlarını merklize ederek Merkle tanıkları aracılığıyla işlem dahil etme kanıtlarına izin verir. (2) için, küresel durum ağacına bir Merkle kökü gönderen EVM tabanlı L2'lerin aksine, performans nedenleriyle Eclipse küresel durum ağacını işlem bazında güncellemez, ancak girdilerin doğruluğunu nasıl sağladığımızı aşağıda daha ayrıntılı olarak açıklayacağız. Son olarak, (3) durumunda, Eclipse'in doğrulayıcısı, EVM tabanlı L2'lerde yaygın olan etkileşimli doğrulama oyunu yaklaşımının aksine, belirli bir işlem için çıktı(lar)ın bir zk kanıtını oluşturur.

Tüm Eclipse işlemleri, bir girdi hesapları listesinin alınması, bir işlemin yürütülmesi ve sonuçta bir çıktı hesapları listesinin üretilmesi şeklinde gösterilebilir:

Dolandırıcılık kanıtı tasarımımız için kritik gözlem, işlemin yürütülmesi için her zaman herhangi bir S_InputAccount'un önceki bir işlemin S_OutputAccount'u olması gerektiğidir. Bu, küresel bir durum ağacına bir Merkle tanığı sağlamak yerine, belirli bir girdi hesabını üreten zincirdeki son işleme başvurmamızı sağlar. Tasarımımızın bir sonucu olarak, önceki işlemin geçerli olmaması veya giriş hesabının daha sonraki bir işlem tarafından zaten "harcanmış" olması gibi ek dolandırıcılık suçlama türleri sunuyoruz. Bu süreci aşağıda daha ayrıntılı olarak açıklıyoruz:

Celestia'ya Gönderilen İşlem Girdileri

1. İşlem verileri (sıralayıcı tarafından gönderilir)
2. Aşağıdakileri içeren işlem verileri (SVM yürütücüsü tarafından gönderilir):
   1. İşlem sayısı [3]
   2. İşlem verilerinin Celestia ad alanı konumu
   3. Her bir girdi için hesap karması [4], her bir girdide ortaya çıkan işlem sayısı ile
   4. Kullanılan sysvar 'ların listesi ve her birinin değeri, her biriyle sonuçlanan işlem sayısı (varsa) [5]
   5. İşlem başarılıysa işlem çıktısı; aksi takdirde işlemin başarısız olduğuna dair bir gösterge (ya ayrıştırma başarısız olduğu için ya da yürütülemediği için)

Ethereum Köprüsüne Gönderilen Toplu Taahhütler

Buna ek olarak, Celestia'ya gönderilen işlem verisi gruplarının taahhütleri Ethereum sözleşmesine aktarılır. Taahhütler şunlardan oluşmaktadır:

1. Toplu işe dahil edilen son işlemin işlem verilerinin Celestia ad alanı konumu
2. Dahil edilen tüm işlemlerin yürütme verilerinin [6] Celestia ad alanı konumu
3. Her biri ilişkili Eclipse işleminin işlem sayısıyla birlikte gelen para yatırma, para çekme ve geçersiz kılma işlemlerinin bir listesi

Geçersiz Parti için Kriterler

Yukarıda açıklandığı üzere, bir partinin hatalı olduğunun tespit edilebilmesinin birkaç yolu vardır:

1. Bağlantılı Celestia ad alanı konumlarından biri hatalı biçimlendirilmiş veya gerekli türdeki verilere işaret etmiyor
2. Celestia'da ilişkili yürütme verisi olmayan bir işlem var ve bunun iki nedeni olabilir:
   1. Toplu işteki en son işlem olması gereken işlemin ilişkili yürütme verileri yoktur.
      1. Böyle bir durumda, bir doğrulayıcı durumun böyle olduğunu doğrular ve Ethereum köprü sözleşmesi, yürütme verileri listesindeki en son girişin doğru işlem verilerine karşılık gelmediğini kontrol eder
   2. Farklı bir işlemin yürütme verileri eksik
      1. Doğrulayıcı, hatalı işlemin işlem verilerinin Celestia ad alanı konumunu ve başarılı bir şekilde yürütülen sırayla önceki ve sonraki işlemleri yayınlar. Bunu takiben, köprü sözleşmesi bu işlemin atlanıp atlanmadığını kontrol eder
3. Yürütme verileri hatalı olan bir işlem var, bunun nedeni aşağıdakiler olabilir:
   1. Bir hesap karması veya sysvar ile ilişkili işlem sayısı talep edilen çıktıyı üretmez.
      1. Bu durumda, bir doğrulayıcı, verilen işlem için yürütme verilerinin Celestia ad alanı konumunu ilgili sayıyla birlikte gönderir ve köprü sözleşmesi verilen değerin yanlış olup olmadığını kontrol eder.
   2. Bir hesap karması veya sysvar ile ilişkili işlem sayısı güncel değil
      1. Doğrulayıcı, söz konusu değeri değiştirerek daha yeni bir işlem için yürütme verilerinin Celestia ad alanı konumunu gönderir ve köprü sözleşmesi bunun gerçekten daha yeni olup olmadığını kontrol eder.
   3. İşlem çıktısı hatalı veya işlem listede olmayan bir girdi kullanıyor:
      1. Bu durumda, işlemin doğru yürütüldüğüne dair bir zk kanıtı veya işlemin listelenmemiş bir girdi kullandığına dair bir zk kanıtı gereklidir. Bu iki şekilde elde edilebilir:
         1. Doğrulayıcı kanıtı gönderir veya
         2. Bir doğrulayıcı, hileli olduğu iddia edilen işlemin dizinini yayınlar ve Eclipse köprü sözleşmesi bunu RISC Zero'nun Bonsai'sinden bir zk kanıtı istemek için kullanır
   4. Ethereum'dan N'den fazla parti önce para yatırılmış, ancak işlem listesinde (köprü sözleşmesine gönderilen parti taahhüdüne dahil) N geçmiş parti için karşılık gelen bir para yatırma işlemi yok. Alternatif olarak, işlem listesinde ilgili Ethereum para yatırma işlemi olmayan bir para yatırma işlemi vardır veya işlem mevcuttur ancak başka bir Eclipse partisine dahil edilmiştir
      1. Tüm bu durumlarda briç sözleşmesi bunun gerçekleştiğini tespit edebilir ve böyle bir partiyi geçersiz sayabilir
   5. İşlem listesinde karşılık gelen bir giriş olmadan gerçekleştirilen bir para yatırma veya çekme işlemi var
      1. Böyle bir durumda, bir doğrulayıcı verilen yürütme verilerinin Celestia ad alanı konumunu gönderir ve köprü sözleşmesi işlemi geçersiz olarak değerlendirmek için bu gerçeği kontrol eder
   6. İşlem listesinde, ilişkili Eclipse işlemi beklenen eylemi gerçekleştirmeyen veya işlem sayısı beklenen işlem sayısı aralığında olmayan bir para yatırma veya çekme işlemi var. Böyle bir durumda aşağıdakilerden biri gerçekleşecektir:
      1. Köprü bu durumu otomatik olarak belirleyecek ve ilgili partiyi reddedecektir
      2. Bir doğrulayıcı geçersiz durum geçişini fark eder ve hatalı işlemin kanıtını gönderir, bu kanıt daha sonra köprü sözleşmesi tarafından doğrulanır

Herhangi bir taahhüt grubunun yanlış olduğu tespit edilirse, Eclipse köprü sözleşmesi köprüyü kanıtlanabilir şekilde doğru olan son grup taahhüdüne geri alacaktır. Dolandırıcılık durumunda bile işlemlerin asla zincirden çıkarılmadığını, bu nedenle yalnızca taahhüdün yeniden hesaplanması gerektiğini unutmayın.

Ayrılık Düşünceleri

Bu makale, Eclipse'in Ethereum üzerindeki güven minimize edilmiş köprüsü hakkında üst düzey bir rehber sunmayı ve dolandırıcılık kanıtı tasarımımızla ilgili bazı ayrıntıları açıklamayı amaçlamaktadır. L2'mizin modüler yapısı ve teknoloji yığınımızın yeni oluşu göz önüne alındığında, önümüzdeki haftalarda Eclipse'in çeşitli yönleri hakkında makaleler ve belgeler yayınlamaya devam edeceğiz.

Eclipse Testnet'e dahil olmak için lütfen buradaki talimatlarımızı izleyin. Testnet, köprü veya teknik sorularınız için bizimle Twitter veya Discord üzerinden iletişime geçebilirsiniz.

Dipnotlar

[1]: SVM işlemlerinin sonuçlarını hesaplayan ve nihai çıktıyı Eclipse'in yeni durumuna uygulayan düğüm

[2]: Ethereum ve Eclipse arasında zincir üzerindeki olayları aktaran bir operatör

[3]: Bunu sıralayıcının değil yürütücünün gönderdiğine dikkat edin. Sıralayıcı tarafından gönderilen verilere dahil edilmiş olsaydı, sıralayıcının bir sayımın üzerinden atlayabileceği ve yürütücünün işini doğru bir şekilde yapmasını imkansız hale getirecek bir karmaşıklık eklerdi. Bu durum sahtekarlığa karşı dayanıklı tasarımda telafi edilebilir, ancak bu ekstra karmaşıklık yaratacaktır. Sayımı yalnızca yürütücünün göndermesinin ikinci bir avantajı, istenirse işlem geçersiz kılmalarının Celestia'ya gönderilmesine izin vermeyi kolaylaştırmasıdır.

[4]: SVM hesapları benzersiz bir hash ile temsil edilebilir. Bu hash'in değiştirilmesinin tek yolu bir işlemdir.

[5]: Bunu aşırı miktarda hashing olmadan yapmak için, kullanılan her sysvar'ın hangi bölümlerine gerçekten erişildiğini görmek için yürütülen her programda bir izleme çalıştıracağız. Bu mümkündür, ancak Solana'nın BPF yorumlayıcısının değiştirilmesi gerekecektir.

[6]: Bu, gerçekleştirilemeyen işlem denemelerine ilişkin verileri içerir.

Sorumluluk Reddi：

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