2023'teki yazıtların yazından günümüze, Bitcoin Katman 2 her zaman tüm Web3'ün en önemli özelliği olmuştur. Bu alanın yükseliş Ethereum'daki Katman 2'dan çok daha geç olmasına rağmen, POW'un benzersiz cazibesi ve Spot ETF'nin yumuşak inişi ile "menkul kıymetleştirme" riskini dikkate almayan Bitcoin, sadece yarım yılda Katman 2'nin türev yolu için on milyarlarca dolarlık sermayenin dikkatini çekti.
Bitcoin Katman 2 parçada TVL milyar dolarlara sahip olan Merlin şüphesiz en büyük hacim ve en long takipçiye sahip olanı. Net stake teşvikleri ve makul bir getiri ile Merlin neredeyse birkaç ay içinde ortaya çıktı ve Blast'ı aşan ekolojik bir efsane yarattı. Merlin'in artan popülaritesi ile teknik çözümlerinin tartışılması giderek daha long bir konu haline geldi.
Bu makalede Geek Web3, Merlin Chain'in teknik çözümlerine odaklanacak, yayınlanmış belgelerini ve protokol tasarım fikirlerini yorumlayacak ve daha fazla long kişinin Merlin'in genel iş akışını anlamasını ve güvenlik modelini daha net bir şekilde anlamasını sağlamaya kararlıyız, böylece herkes bu "kafa Bitcoin Katman 2" nasıl çalıştığını daha sezgisel bir şekilde anlayabilir.
Merlin'in decentralized oracle ağı: açık bir off-chain DAC konseyi
İster Ethereum Katman 2 ister Bitcoin Katman 2 olsun, tüm Layer 2'ler için DA ve veri yayınlama maliyetleri çözülmesi gereken en önemli sorunlardan biridir. Doğası gereği büyük veri çıkışına destek olmayan Bitcoin ağının kendisinin en uzun sorunları nedeniyle, bu DA şortlarının nasıl kullanılacağı, Katman 2 projelerin hayal gücünü test etmek için zor bir sorun haline geldi.
Bir sonuç açıktır: Katman 2, işlenmemiş işlem verilerini "doğrudan" Bitcoin Blok yayınlarsa, yüksek verim veya düşük ücretler elde edemeyecektir. En popüler çözüm, veri boyutunu yüksek sıkıştırma yoluyla mümkün olduğunca küçük sıkıştırmak ve Bitcoin Blok yüklemek veya verileri doğrudan Bitcoin off-chain üzerinde yayınlamaktır. **
Muhtemelen ilk yaklaşımı benimseyen Katman 2 Katmanlarının en bilineni, belirli bir süre boyunca Katman 2 durum farkını, yani long hesap'daki durum değişikliğinin sonuçlarını, karşılık gelen ZK kanıtlarıyla birlikte Bitcoin on-chain yüklemeyi amaçlayan Citrea'dır. Bu durumda, herkes Citrea durum değişikliğinin sonuçlarını izlemek için Bitcoin Ana Ağ durum farkını ve ZKP'yi indirebilir. Bu yöntem, zincirdeki verilerin boyutunu %90'dan fazla azaltabilir.
Bu, verilerin boyutunu büyük ölçüde azaltabilse de, darboğaz hala önemlidir. short bir süre içinde çok sayıda hesap durumu değişikliği meydana gelirse, Katman 2 bu hesap tüm değişikliklerini özetlemesi ve Bitcoin on-chain yüklemesi gerekir ve son veri yayınlama maliyeti çok düşük tutulamaz, bu da çok long Ethereum ZK Rollup'ında görülebilir.
İkinci yolu kullanmak çok long Bitcoin Katman 2: doğrudan Bitcoin off-chain DA çözümünü kullanın, ya kendi başına bir DA katmanı oluşturun ya da Celestia, EigenDA, vb. kullanın. B^Square, BitLayer ve bu makalenin kahramanı Merlin, bu off-chain DA ölçeklendirme şemasını takip ediyor.
Geek web3'ün bir önceki makalesinde - "B^2 Teknoloji Yol Haritasının Yeni Sürümünü Analiz Etme: Bitcoin off-chain DA ve Doğrulama Katmanının Gerekliliği", **B^2'nin doğrudan Celestia'yı taklit ettiğinden ve off-chain B^2 Hub adlı veri örnekleme işlevini destekleyen bir DA ağı oluşturduğundan bahsetmiştik. İşlem verileri veya durum farkı gibi "DA verileri" Bitcoin off-chain saklanır ve Bitcoin Ana Ağ yalnızca datahash/merkle kökü yüklenir. **
Gerçekten Bitcoin Güvenilmez bir bülten tahtası olarak ele alıyor: herkes Bitcoin on-chain'den veri karması okuyabilir. off-chain veri sağlayıcısından DA verisi aldığınızda on-chain datahash yani hash(data1) == datahash1 ?'ye karşılık gelip gelmediğini kontrol edebilirsiniz. İkisi arasında bir yazışma varsa, off-chain altındaki veri sağlayıcının size doğru verileri verdiği anlamına gelir.
Yukarıdaki işlem, off-chain Düğüm tarafından size sağlanan verilerin Katman 1'deki belirli "ipuçları" ile ilişkilendirilmesini sağlayarak DA katmanının kötü niyetli olarak yanlış veriler sağlamasını önleyebilir. Ancak burada çok önemli bir pin senaryosu var: Ya verilerin kaynağı olan Sequencer, veri karmasının karşılık gelen verilerini hiç göndermezse, ancak yalnızca veri karmasını Bitcoin on-chain gönderirse, ancak ilgili verileri okumak için kasıtlı olarak herkesten saklarsa?
Benzer senaryolar arasında, bunlarla sınırlı olmamak üzere, yalnızca ZK-Proof ve StateRoot'u yayınlamak, ancak karşılık gelen DA verilerini (durum farkı veya işlem verileri) yayınlamamak yer alır, ancak insanlar ZKProof hesaplama işleminin geçerli olduğunu doğrulayabilir ve Prev_Stateroot'den New_Stateroot'a kadar olan hesaplama sürecinin geçerli olduğundan emin olabilirler, ancak hangi hesap durumunun (durumunun) değiştiğini bilmezler. Bu durumda, kullanıcının varlıkları güvende olsa da, ağın gerçek durumunu hiçbir şekilde belirleyemezsiniz ve zincirde hangi işlemlerin paketlendiğini ve hangi sözleşmelerin güncellendiğini bilemezsiniz.
Bu aslında "veri stopaj" ve Ethereum Vakfı'ndan Dankrad, Ağustos 2023'te Twitter'da benzer bir konuyu kısaca tartıştı, elbette esas olarak "DAC" adı verilen bir şeye uzun fitilli mum.
off-chain DA çözümlerini benimseyen en uzun Ethereum Layer2, genellikle Veri Kullanılabilirliği Komitesi'nin (DAC) tam adı olan bir komite oluşturmak için özel izinlere sahip birkaç düğüm kurar. Bu DAC komitesi, Sequencer'ın tüm DA verilerini (işlem verileri veya durum farkı) off-chain yayınladığını iddia ederek garantör olarak hareket eder. Daha sonra DAC Düğüm toplu olarak bir long'cu oluşturur long en uzun eşik gereksinimlerini (2/4 gibi) karşılar, Katman 1'deki ilgili sözleşme temerrüde düşer ve Sequencer, DAC komitesinin denetimini geçti ve tüm DA verilerini off-chain doğru bir şekilde yayınladı.
DAC Ethereum Katman 2 komitesi temel olarak POA modelini takip eder ve yalnızca birkaç KYC veya resmi olarak belirlenmiş düğümün DAC komitesine katılmasına izin verir, bu da DAC'yi "merkezi" ve "konsorsiyum blok zinciri" ile eşanlamlı kılar. Ek olarak, DAC modelini benimseyen bazı Ethereum Katman 2 sıralayıcı, DA verilerini yalnızca DAC üyesi Düğümlere gönderir ve neredeyse hiçbir zaman başka bir yere veri yüklemez ve DA verilerini elde etmek isteyen herkes, Konsorsiyum Blockchain'den temelde farklı olmayan DAC komitesinin iznini almalıdır.
Hiç şüphe yok ki DAC Merkeziyetsizlik olmalı ve Katman 2 DA verilerini doğrudan Katman 1'e yükleyemez, ancak DAC komitesinin erişim yetkisi, birkaç kişinin kötülük yapmak için gizli anlaşma yapmasını önlemek için dış dünyaya açık olmalıdır. (DAC'ın yaramazlık senaryosunun bir tartışması için lütfen Dankrad'ın Twitter'daki önceki açıklamasına bakın)
**Daha önce Celestia tarafından önerilen BlobStream, esasen merkezi DAC'yi Celestia ile değiştirmektir, **Ethereum L2 sıralayıcı, DA verilerini Celestia'ya yayınlayabilir on-chain, Celestia düğümünün 2/3'ü imzalarsa, Ethereum'de dağıtılan Layer2 özel sözleşmesi, sıralayıcının DA verilerini doğru bir şekilde yayınladığına inanır, bu da aslında Celestia'nın Düğüm bir garantör olarak hareket etmesine izin vermektir. Celestia'nın yüzlerce doğrulayıcı düğümü olduğunu düşünürsek, bu büyük DAC'nin nispeten merkeziyetsizlik olduğunu düşünebiliriz.
**Merlin tarafından kullanılan DA çözümü aslında Celestia'nın BlobStream'ine yakındır, bu da DAC'nin erişim haklarını ademi merkeziyetçilik eğilimi göstermesi için POS biçiminde açar. Herkes, yeterli varlığa Stake olduğu kadar long bir DAC Düğüm çalıştırabilir. Merlin'in belgelerinde, yukarıdaki DAC Düğüm Oracle olarak anılıyor ve BTC, MERL ve hatta BRC-20 Token'larının varlık staking'inin destekleneceği ve esnek bir staking mekanizmasının yanı sıra Lido'ya benzer proxy staking'in sağlanacağı belirtiliyor. (Oracle Makine'ın POS Stake protokol temelde Merlin'in bir sonraki temel anlatılarından biridir ve sağlanan Stake Faiz Oranı nispeten yüksektir)
İşte Merlin'in iş akışının kısa bir açıklaması (aşağıdaki resim):
Çok sayıda işlem isteği aldıktan sonra, sıralayıcı bunları toplar ve Prover Düğüm ve Oracle Düğüm'a (Merkeziyetsizlik DAC) iletilen bir veri grubu oluşturur.
Merlin'in Prover Düğüm, lumoz'un Prover'ını Hizmet olarak kullanan Merkeziyetsizlik. En uzun veri gruplarını aldıktan sonra, Prover madencilik havuzu ilgili zk-SNARKs oluşturacak ve ardından ZKP, doğrulama için Oracle Düğüm gönderilecektir.
Oracle Düğüm, Lmuoz'un ZK Mining Havuzu tarafından gönderilen ZK Kanıtının, Sequencer tarafından gönderilen veri Toplu İşlemine karşılık gelip gelmediğini doğrulayacaktır. İkisi karşılık gelebiliyorsa ve başka hata yoksa, doğrulanır. Bu süreçte, Merkeziyetsizlik Oracle Düğümleri, eşik imzaları aracılığıyla long'cu imzalar oluşturacak ve harici olarak bildirecektir - sıralayıcı tamamen DA verilerini yaymıştır ve Oracle Düğüm'nin doğrulamasını geçen ilgili ZKP geçerlidir.
Sıralayıcı, Oracle Düğüm'den long imza sonuçlarını toplar ve imza sayısı eşik gereksinimlerini karşıladığında, imza bilgilerini DA veri partisinin bir veri karması ile Bitcoin on-chain gönderir ve okuması ve onaylaması için dış dünyaya teslim eder.
Oracle Düğüm ZK Proof'u doğrulamak, bir Taahhüt taahhüdü oluşturmak, bunu Bitcoin on-chain göndermek ve herkesin "bağlılığa" itiraz etmesine izin vermek için hesaplama sürecinin özel olarak işlenmesini sağlar ve bu süreçteki süreç temelde bitVM'nin dolandırıcılık kanıtı protokol ile aynıdır. Sorgulama başarılı olursa, Taahhüdü yayınlayan Oracle Düğüm mali olarak cezalandırılacaktır. Elbette, Oracle'ın mevcut Katman 2 durumunun hash - StateRoot ve ZKP'nin kendisi de dahil olmak üzere Bitcoin on-chain yayınlamak istediği veriler, dış dünyanın algılaması için Bitcoin on-chain yayınlanmalıdır.
Hala detaylandırılması gereken birkaç ayrıntı var, her şeyden önce, Merlin'in yol haritası, gelecekte Oracle'ın DA verilerini Celestia'ya yedekleyeceğinden, böylece Oracle Düğüm'in yerel geçmiş verileri düzgün bir şekilde ortadan kaldırabileceğinden ve verileri sonsuza kadar yerel olarak tutmasına gerek kalmayacağından bahsediyor. Aynı zamanda, Oracle Network tarafından oluşturulan Taahhüt aslında bir Merkle Ağacı köküdür ve kökü dış dünyaya ifşa etmek yeterli değildir, ancak Taahhüt'e karşılık gelen tüm veri kümelerini ifşa etmek için Celestia, EigenDA veya diğer DA katmanları olabilen üçüncü taraf bir DA platformu bulmak gerekir.
Güvenlik Modeli Analizi: İyimser ZKRollup+Cobo'nun MPC Hizmeti
Yukarıda Merlin'in iş akışını kısaca anlattık ve temel yapısını zaten iyi anladığınıza inanıyorum. Merlin'in temelde B^Square, BitLayer ve Citrea ile aynı güvenlik modelini izlediğini görmek zor değil - iyimser ZK-Rollup.
Bu kelimenin ilk okunması birçok long Ethereum meraklısını tuhaf hissettirebilir, "iyimser ZK-Rollup" nedir? Ethereum topluluğunun bilişinde, ZK Rollup'ın "teorik modeli" tamamen Kriptografi hesaplamalarının güvenilirliğine dayanmaktadır ve güven varsayımları getirmeye gerek yoktur ve iyimserlik kelimesi tam olarak güven varsayımlarını ortaya koyar, bu da insanların Rollup'ların çok sayıda long olduklarında yanlış ve güvenilir olmadığı konusunda iyimser olmaları gerektiği anlamına gelir. Ve bir hata olduğunda, Rollup operatörü, OP Rollup olarak da bilinen Optimistic Rollup adının kökeni olan dolandırıcılık kanıtı tarafından cezalandırılabilir.
Rollup'ın ana üssünün Ethereum ekosistemi için, iyimser ZK-Rollup biraz sıra dışı olabilir, ancak bu, Bitcoin Katman 2'in mevcut durumuyla tam olarak uyumludur. Teknik sınırlamalar nedeniyle, Bitcoin on-chain ZK Proof'u tam olarak doğrulayamaz, özel koşullar altında ZKP hesaplama sürecinin yalnızca belirli bir adımını doğrulayabilir, bu öncül altında, Bitcoin on-chain aslında sadece destek dolandırıcılık kanıtı protokol olabilir, insanlar off-chain doğrulama sürecinde ZKP'nin olduğuna işaret edebilir, belirli bir hesaplama adımında bir hata vardır ve meydan okumanın dolandırıcılık kanıtı yolu aracılığıyla, elbette, bu Ethereum tarzı ZK Rollup ile karşılaştırılamaz, ancak Bitcoin zaten en güvenilir ve En sağlam güvenlik modeli.
Yukarıdaki iyimser ZK-Rollup şemasına göre, Katman 2 ağında N yetkili meydan okuyucu olduğunu varsayarsak, bu N meydan okuyucudan en long 1'i dürüst ve güvenilirdir ve hataları tespit edebilir ve herhangi bir zamanda dolandırıcılık kanıtı başlatabilir, Katman 2 durum geçişi güvenlidir. Tabii ki, nispeten yüksek bir tamamlanma derecesine sahip iyimser rollups, para çekme köprülerinin de dolandırıcılık kanıtı protokol tarafından korunmasını sağlamalıdır ve şu anda neredeyse tüm Bitcoin Katman 2 bu önermeye ulaşamıyor ve long imzaya/MPC güvenmeye ihtiyaç duyuyor, bu nedenle long imza/MPC çözümünün nasıl seçileceği, Katman 2 güvenliği ile yakından ilgili bir sorun haline geldi.
Merlin, soğuk ve sıcak cüzdan izolasyonu, köprü varlıklarının Cobo ve Merlin Chain tarafından ortaklaşa yönetilmesi ve herhangi bir para çekme işleminin Cobo ve Merlin Chain'in MPC katılımcıları tarafından ortaklaşa ele alınması gibi önlemleri kullanarak köprü planında Cobo'nun MPC hizmetini seçti ve esasen kurumun kredi onayı yoluyla para çekme köprü güvenilirliğini sağladı. Tabii ki, bu sadece bu aşamada geçici bir önlemdir ve projenin kademeli olarak iyileştirilmesiyle, geri çekilme köprü, BitVM ve dolandırıcılık kanıtı protokol'yi tanıtarak 1/N güven varsayımının "iyimser köprü" ile değiştirilebilir, ancak inmesi daha zor olacaktır (şu anda, neredeyse tüm Layer2 resmi köprüleri long işarete dayanmaktadır).
Genel olarak, Merlin'in POS tabanlı bir DAC, BitVM'ye dayalı iyimser bir ZK-Rollup ve Cobo'ya dayalı bir MPC varlık saklama çözümü sunduğunu, DAC izinlerini açarak DA sorununu çözdüğünü, BitVM ve dolandırıcılık kanıtı protokol'yi tanıtarak durum geçişinin güvenliğini sağladığını ve tanınmış varlık saklama platformu Cobo'nun MPC hizmetini tanıtarak para çekme köprü güvenilirliğini sağladığını söyleyebiliriz.
Lumoz tabanlı iki adımlı doğrulama ZKP gönderim şeması
Daha önce, Merlin'in güvenlik modelini taradık ve iyimser ZK-rollup kavramını tanıttık. Merlin'in teknoloji yol haritasında Merkeziyetsizlik Prover da tartışılıyor. Hepimizin bildiği gibi, Prover, Sequencer tarafından piyasaya sürülen partiler için ZKProof'ların oluşturulmasından sorumlu olan ZK-Rollup mimarisinde temel bir roldür ve zk-SNARKs oluşturma süreci çok donanım kaynağı yoğun ve çok zor bir sorundur.
ZK ispatlarının oluşturulmasını hızlandırmak için görevi paralelleştirmek en temel işlemlerden biridir. **Sözde paralelleştirme aslında ZK kanıt oluşturma görevini farklı Kanıtlayıcılar tarafından ayrı ayrı tamamlanan farklı parçalara bölmek ve son olarak Toplayıcı toplayıcı en uzun Kanıtı bir bütün halinde toplamaktır.
ZK kanıtlarının üretim sürecini hızlandırmak emir Merlin, Lumoz'un Prover'ını bir hizmet çözümü olarak kullanacak, bu da aslında bir madencilik havuzu oluşturmak için çok sayıda donanım cihazını bir araya getirmek ve ardından farklı cihazlara bilgi işlem görevleri atamak ve POW madenciliğine benzer şekilde karşılık gelen teşvikleri atamak.
Bu Merkeziyetsizlik Prover şemasında, genellikle önden çalışan saldırılar olarak bilinen bir saldırı senaryoları sınıfı vardır: Bir toplayıcı Toplayıcının bir ZKP oluşturduğunu ve bir ödül alma umuduyla ZKP'yi gönderdiğini varsayalım. Diğer toplayıcılar ZKP'nin içeriğini gördükten sonra, bu ZKP'nin kendi kocaları tarafından yapıldığını iddia ederek aynı içeriği önüne koymak için acele ettiler, bu durum nasıl çözülür?
Akla gelebilecek en içgüdüsel çözümlerden biri, her Toplayıcıya belirli bir görev numarası atamaktır, örneğin, yalnızca Toplayıcı A görev 1'i alabilir ve diğer herkes görev 1'i tamamlasa bile ödül alamaz. Ancak bu yaklaşımla ilgili sorunlardan biri, tek bir risk noktasına karşı koruma sağlamamasıdır. Toplayıcı A'nın bir performans hatası varsa veya bağlantısı kesilirse, Görev 1 takılır ve tamamlanamaz. Ayrıca, görevleri tek bir kuruluşa atama uygulaması, rekabetçi teşviklerle üretkenliği artırmanın iyi bir yolu değildir.
Polygon zkEVM, bir blog yazısında, farklı Toplayıcıların birbirleriyle rekabetçi bir şekilde rekabet etmeleri için teşvik edilmesi gerektiğini ve teşviklerin ilk gelene ilk hizmet esasına göre dağıtılması gerektiğini ve zincire ZK-Kanıtı gönderen ilk Toplayıcıların ödül alabileceğini belirten Proof of efficiency adlı bir yöntem önerdi. Tabii ki, MEV önden koşma sorununun nasıl çözüleceğinden bahsetmedi.
Lumoz, iki adımlı bir doğrulama ZK kanıtı gönderme yöntemi kullanır, bir Toplayıcı bir ZK kanıtı oluşturduktan sonra, içeriğin tamamını göndermesine gerek yoktur, ancak yalnızca ZKP'nin hash yayınlar, başka bir deyişle, hash yayınlar (ZKP+Toplayıcı Adres). Bu şekilde, diğerleri hash değerini görseler bile, ilgili ZKP içeriğini bilmezler ve doğrudan aceleye getiremezler;
Birisi tüm hash kopyalayıp önce yayınlarsa, bunun bir anlamı yoktur, çünkü hash belirli bir toplayıcı X'in Adres içerir ve toplayıcı A önce hash yayınlasa bile, hash orijinal görüntüsü ortaya çıktığında, herkes içinde bulunan toplayıcı Adres A değil X olduğunu görecektir.
Bu iki adımlı doğrulama ZKP gönderim şeması sayesinde, Merlin (Lumoz), ZKP gönderim sürecindeki önden çalışan sorunu çözebilir ve ardından son derece rekabetçi zk-SNARKs oluşturma teşvikleri gerçekleştirebilir, böylece ZKP'nin üretim hızını artırabilir.
Merlin's Phantom: en uzun zincir birlikte çalışabilirliği
Merlin'in teknik yol haritasına göre, Merlin ve diğer EVM zincirleri arasında birlikte çalışabilirliği de destek edecekler ve uygulama yolu temelde önceki Zetachain fikri ile aynı, Merlin kaynak zincir olarak kullanılıyorsa ve diğer EVM zincirleri hedef zincir olarak kullanılıyorsa, Merlin Düğüm kullanıcı tarafından yapılan cross-chain birlikte çalışabilirlik talebini algıladığında, hedef on-chain üzerinde sonraki iş akışını tetikleyecektir.
Örneğin, Merlin ağı tarafından kontrol edilen bir EOA hesap Polygon üzerinde konuşlandırılabilir, ** Bir kullanıcı Merlin Chain'de bir cross-chain birlikte çalışabilirlik talimatı yayınladığında, Merlin ağı önce içeriğini ayrıştırır ve hedef on-chain üzerinde yürütülen bir işlem verisi oluşturur ve ardından Oracle Ağı MPC işlemdeki imza işleme, işlemin dijital imzasını oluşturur. Merlin'in Relayer'ı Düğüm daha sonra işlemi ** Polygon'da serbest bırakır ve Merlin'in EOA'daki varlıkları aracılığıyla sonraki işlemleri hedef on-chain hesap tamamlar.
Kullanıcının ihtiyaç duyduğu işlem tamamlandığında, ilgili varlık doğrudan kullanıcının hedef on-chain üzerindeki adresine iletilecek ve teorik olarak doğrudan Merlin Zincirine de geçebilecektir. Bu çözümün bazı bariz avantajları vardır: geleneksel varlık cross-chain ve Cross chain köprüleri sözleşmeleri tarafından üretilen ücretlerin aşınmasını ve yıpranmasını önleyebilir ve cross-chain operasyonlarının güvenliğini sağlamak için doğrudan Merlin'in Oracle Ağı tarafından garanti edilir ve long'cu harici altyapıya güvenmeye gerek kalmaz. Kullanıcılar Merlin Chain'e güvendiği long, bu tür cross-chain birlikte çalışabilirliği varsayılan olarak kullanmakta bir sorun yoktur.
Özet
Bu yazıda, daha fazla long kişinin Merlin'in genel iş akışını anlamasına ve güvenlik modelini daha net bir şekilde anlamasına yardımcı olduğuna inanılan Merlin Chain'in genel teknik çözümünün kısa bir açıklamasını veriyoruz. Mevcut Bitcoin ekolojisini tüm hızıyla göz önünde bulundurarak, bu tür teknik bilim popülerleştirme davranışının değerli olduğuna ve genel halk tarafından ihtiyaç duyulduğuna inanıyoruz, Gelecekte Merlin ve bitLayer, B^Square ve diğer projeler üzerinde long vadeli takip gerçekleştireceğiz ve teknik çözümlerinin daha derinlemesine bir analizini yapacağız, bu yüzden bizi izlemeye devam edin!
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.
Merlin'in çalışma mekanizmasının teknik yorumu
Yazar: Faust, geek web3
2023'teki yazıtların yazından günümüze, Bitcoin Katman 2 her zaman tüm Web3'ün en önemli özelliği olmuştur. Bu alanın yükseliş Ethereum'daki Katman 2'dan çok daha geç olmasına rağmen, POW'un benzersiz cazibesi ve Spot ETF'nin yumuşak inişi ile "menkul kıymetleştirme" riskini dikkate almayan Bitcoin, sadece yarım yılda Katman 2'nin türev yolu için on milyarlarca dolarlık sermayenin dikkatini çekti.
Bitcoin Katman 2 parçada TVL milyar dolarlara sahip olan Merlin şüphesiz en büyük hacim ve en long takipçiye sahip olanı. Net stake teşvikleri ve makul bir getiri ile Merlin neredeyse birkaç ay içinde ortaya çıktı ve Blast'ı aşan ekolojik bir efsane yarattı. Merlin'in artan popülaritesi ile teknik çözümlerinin tartışılması giderek daha long bir konu haline geldi.
Bu makalede Geek Web3, Merlin Chain'in teknik çözümlerine odaklanacak, yayınlanmış belgelerini ve protokol tasarım fikirlerini yorumlayacak ve daha fazla long kişinin Merlin'in genel iş akışını anlamasını ve güvenlik modelini daha net bir şekilde anlamasını sağlamaya kararlıyız, böylece herkes bu "kafa Bitcoin Katman 2" nasıl çalıştığını daha sezgisel bir şekilde anlayabilir.
Merlin'in decentralized oracle ağı: açık bir off-chain DAC konseyi
İster Ethereum Katman 2 ister Bitcoin Katman 2 olsun, tüm Layer 2'ler için DA ve veri yayınlama maliyetleri çözülmesi gereken en önemli sorunlardan biridir. Doğası gereği büyük veri çıkışına destek olmayan Bitcoin ağının kendisinin en uzun sorunları nedeniyle, bu DA şortlarının nasıl kullanılacağı, Katman 2 projelerin hayal gücünü test etmek için zor bir sorun haline geldi.
Bir sonuç açıktır: Katman 2, işlenmemiş işlem verilerini "doğrudan" Bitcoin Blok yayınlarsa, yüksek verim veya düşük ücretler elde edemeyecektir. En popüler çözüm, veri boyutunu yüksek sıkıştırma yoluyla mümkün olduğunca küçük sıkıştırmak ve Bitcoin Blok yüklemek veya verileri doğrudan Bitcoin off-chain üzerinde yayınlamaktır. **
Muhtemelen ilk yaklaşımı benimseyen Katman 2 Katmanlarının en bilineni, belirli bir süre boyunca Katman 2 durum farkını, yani long hesap'daki durum değişikliğinin sonuçlarını, karşılık gelen ZK kanıtlarıyla birlikte Bitcoin on-chain yüklemeyi amaçlayan Citrea'dır. Bu durumda, herkes Citrea durum değişikliğinin sonuçlarını izlemek için Bitcoin Ana Ağ durum farkını ve ZKP'yi indirebilir. Bu yöntem, zincirdeki verilerin boyutunu %90'dan fazla azaltabilir.
Bu, verilerin boyutunu büyük ölçüde azaltabilse de, darboğaz hala önemlidir. short bir süre içinde çok sayıda hesap durumu değişikliği meydana gelirse, Katman 2 bu hesap tüm değişikliklerini özetlemesi ve Bitcoin on-chain yüklemesi gerekir ve son veri yayınlama maliyeti çok düşük tutulamaz, bu da çok long Ethereum ZK Rollup'ında görülebilir.
İkinci yolu kullanmak çok long Bitcoin Katman 2: doğrudan Bitcoin off-chain DA çözümünü kullanın, ya kendi başına bir DA katmanı oluşturun ya da Celestia, EigenDA, vb. kullanın. B^Square, BitLayer ve bu makalenin kahramanı Merlin, bu off-chain DA ölçeklendirme şemasını takip ediyor.
Geek web3'ün bir önceki makalesinde - "B^2 Teknoloji Yol Haritasının Yeni Sürümünü Analiz Etme: Bitcoin off-chain DA ve Doğrulama Katmanının Gerekliliği", **B^2'nin doğrudan Celestia'yı taklit ettiğinden ve off-chain B^2 Hub adlı veri örnekleme işlevini destekleyen bir DA ağı oluşturduğundan bahsetmiştik. İşlem verileri veya durum farkı gibi "DA verileri" Bitcoin off-chain saklanır ve Bitcoin Ana Ağ yalnızca datahash/merkle kökü yüklenir. **
Gerçekten Bitcoin Güvenilmez bir bülten tahtası olarak ele alıyor: herkes Bitcoin on-chain'den veri karması okuyabilir. off-chain veri sağlayıcısından DA verisi aldığınızda on-chain datahash yani hash(data1) == datahash1 ?'ye karşılık gelip gelmediğini kontrol edebilirsiniz. İkisi arasında bir yazışma varsa, off-chain altındaki veri sağlayıcının size doğru verileri verdiği anlamına gelir.
Yukarıdaki işlem, off-chain Düğüm tarafından size sağlanan verilerin Katman 1'deki belirli "ipuçları" ile ilişkilendirilmesini sağlayarak DA katmanının kötü niyetli olarak yanlış veriler sağlamasını önleyebilir. Ancak burada çok önemli bir pin senaryosu var: Ya verilerin kaynağı olan Sequencer, veri karmasının karşılık gelen verilerini hiç göndermezse, ancak yalnızca veri karmasını Bitcoin on-chain gönderirse, ancak ilgili verileri okumak için kasıtlı olarak herkesten saklarsa?
Benzer senaryolar arasında, bunlarla sınırlı olmamak üzere, yalnızca ZK-Proof ve StateRoot'u yayınlamak, ancak karşılık gelen DA verilerini (durum farkı veya işlem verileri) yayınlamamak yer alır, ancak insanlar ZKProof hesaplama işleminin geçerli olduğunu doğrulayabilir ve Prev_Stateroot'den New_Stateroot'a kadar olan hesaplama sürecinin geçerli olduğundan emin olabilirler, ancak hangi hesap durumunun (durumunun) değiştiğini bilmezler. Bu durumda, kullanıcının varlıkları güvende olsa da, ağın gerçek durumunu hiçbir şekilde belirleyemezsiniz ve zincirde hangi işlemlerin paketlendiğini ve hangi sözleşmelerin güncellendiğini bilemezsiniz.
Bu aslında "veri stopaj" ve Ethereum Vakfı'ndan Dankrad, Ağustos 2023'te Twitter'da benzer bir konuyu kısaca tartıştı, elbette esas olarak "DAC" adı verilen bir şeye uzun fitilli mum.
off-chain DA çözümlerini benimseyen en uzun Ethereum Layer2, genellikle Veri Kullanılabilirliği Komitesi'nin (DAC) tam adı olan bir komite oluşturmak için özel izinlere sahip birkaç düğüm kurar. Bu DAC komitesi, Sequencer'ın tüm DA verilerini (işlem verileri veya durum farkı) off-chain yayınladığını iddia ederek garantör olarak hareket eder. Daha sonra DAC Düğüm toplu olarak bir long'cu oluşturur long en uzun eşik gereksinimlerini (2/4 gibi) karşılar, Katman 1'deki ilgili sözleşme temerrüde düşer ve Sequencer, DAC komitesinin denetimini geçti ve tüm DA verilerini off-chain doğru bir şekilde yayınladı.
DAC Ethereum Katman 2 komitesi temel olarak POA modelini takip eder ve yalnızca birkaç KYC veya resmi olarak belirlenmiş düğümün DAC komitesine katılmasına izin verir, bu da DAC'yi "merkezi" ve "konsorsiyum blok zinciri" ile eşanlamlı kılar. Ek olarak, DAC modelini benimseyen bazı Ethereum Katman 2 sıralayıcı, DA verilerini yalnızca DAC üyesi Düğümlere gönderir ve neredeyse hiçbir zaman başka bir yere veri yüklemez ve DA verilerini elde etmek isteyen herkes, Konsorsiyum Blockchain'den temelde farklı olmayan DAC komitesinin iznini almalıdır.
Hiç şüphe yok ki DAC Merkeziyetsizlik olmalı ve Katman 2 DA verilerini doğrudan Katman 1'e yükleyemez, ancak DAC komitesinin erişim yetkisi, birkaç kişinin kötülük yapmak için gizli anlaşma yapmasını önlemek için dış dünyaya açık olmalıdır. (DAC'ın yaramazlık senaryosunun bir tartışması için lütfen Dankrad'ın Twitter'daki önceki açıklamasına bakın)
**Daha önce Celestia tarafından önerilen BlobStream, esasen merkezi DAC'yi Celestia ile değiştirmektir, **Ethereum L2 sıralayıcı, DA verilerini Celestia'ya yayınlayabilir on-chain, Celestia düğümünün 2/3'ü imzalarsa, Ethereum'de dağıtılan Layer2 özel sözleşmesi, sıralayıcının DA verilerini doğru bir şekilde yayınladığına inanır, bu da aslında Celestia'nın Düğüm bir garantör olarak hareket etmesine izin vermektir. Celestia'nın yüzlerce doğrulayıcı düğümü olduğunu düşünürsek, bu büyük DAC'nin nispeten merkeziyetsizlik olduğunu düşünebiliriz.
**Merlin tarafından kullanılan DA çözümü aslında Celestia'nın BlobStream'ine yakındır, bu da DAC'nin erişim haklarını ademi merkeziyetçilik eğilimi göstermesi için POS biçiminde açar. Herkes, yeterli varlığa Stake olduğu kadar long bir DAC Düğüm çalıştırabilir. Merlin'in belgelerinde, yukarıdaki DAC Düğüm Oracle olarak anılıyor ve BTC, MERL ve hatta BRC-20 Token'larının varlık staking'inin destekleneceği ve esnek bir staking mekanizmasının yanı sıra Lido'ya benzer proxy staking'in sağlanacağı belirtiliyor. (Oracle Makine'ın POS Stake protokol temelde Merlin'in bir sonraki temel anlatılarından biridir ve sağlanan Stake Faiz Oranı nispeten yüksektir)
İşte Merlin'in iş akışının kısa bir açıklaması (aşağıdaki resim):
Oracle Düğüm ZK Proof'u doğrulamak, bir Taahhüt taahhüdü oluşturmak, bunu Bitcoin on-chain göndermek ve herkesin "bağlılığa" itiraz etmesine izin vermek için hesaplama sürecinin özel olarak işlenmesini sağlar ve bu süreçteki süreç temelde bitVM'nin dolandırıcılık kanıtı protokol ile aynıdır. Sorgulama başarılı olursa, Taahhüdü yayınlayan Oracle Düğüm mali olarak cezalandırılacaktır. Elbette, Oracle'ın mevcut Katman 2 durumunun hash - StateRoot ve ZKP'nin kendisi de dahil olmak üzere Bitcoin on-chain yayınlamak istediği veriler, dış dünyanın algılaması için Bitcoin on-chain yayınlanmalıdır.
Hala detaylandırılması gereken birkaç ayrıntı var, her şeyden önce, Merlin'in yol haritası, gelecekte Oracle'ın DA verilerini Celestia'ya yedekleyeceğinden, böylece Oracle Düğüm'in yerel geçmiş verileri düzgün bir şekilde ortadan kaldırabileceğinden ve verileri sonsuza kadar yerel olarak tutmasına gerek kalmayacağından bahsediyor. Aynı zamanda, Oracle Network tarafından oluşturulan Taahhüt aslında bir Merkle Ağacı köküdür ve kökü dış dünyaya ifşa etmek yeterli değildir, ancak Taahhüt'e karşılık gelen tüm veri kümelerini ifşa etmek için Celestia, EigenDA veya diğer DA katmanları olabilen üçüncü taraf bir DA platformu bulmak gerekir.
Güvenlik Modeli Analizi: İyimser ZKRollup+Cobo'nun MPC Hizmeti
Yukarıda Merlin'in iş akışını kısaca anlattık ve temel yapısını zaten iyi anladığınıza inanıyorum. Merlin'in temelde B^Square, BitLayer ve Citrea ile aynı güvenlik modelini izlediğini görmek zor değil - iyimser ZK-Rollup.
Bu kelimenin ilk okunması birçok long Ethereum meraklısını tuhaf hissettirebilir, "iyimser ZK-Rollup" nedir? Ethereum topluluğunun bilişinde, ZK Rollup'ın "teorik modeli" tamamen Kriptografi hesaplamalarının güvenilirliğine dayanmaktadır ve güven varsayımları getirmeye gerek yoktur ve iyimserlik kelimesi tam olarak güven varsayımlarını ortaya koyar, bu da insanların Rollup'ların çok sayıda long olduklarında yanlış ve güvenilir olmadığı konusunda iyimser olmaları gerektiği anlamına gelir. Ve bir hata olduğunda, Rollup operatörü, OP Rollup olarak da bilinen Optimistic Rollup adının kökeni olan dolandırıcılık kanıtı tarafından cezalandırılabilir.
Rollup'ın ana üssünün Ethereum ekosistemi için, iyimser ZK-Rollup biraz sıra dışı olabilir, ancak bu, Bitcoin Katman 2'in mevcut durumuyla tam olarak uyumludur. Teknik sınırlamalar nedeniyle, Bitcoin on-chain ZK Proof'u tam olarak doğrulayamaz, özel koşullar altında ZKP hesaplama sürecinin yalnızca belirli bir adımını doğrulayabilir, bu öncül altında, Bitcoin on-chain aslında sadece destek dolandırıcılık kanıtı protokol olabilir, insanlar off-chain doğrulama sürecinde ZKP'nin olduğuna işaret edebilir, belirli bir hesaplama adımında bir hata vardır ve meydan okumanın dolandırıcılık kanıtı yolu aracılığıyla, elbette, bu Ethereum tarzı ZK Rollup ile karşılaştırılamaz, ancak Bitcoin zaten en güvenilir ve En sağlam güvenlik modeli.
Yukarıdaki iyimser ZK-Rollup şemasına göre, Katman 2 ağında N yetkili meydan okuyucu olduğunu varsayarsak, bu N meydan okuyucudan en long 1'i dürüst ve güvenilirdir ve hataları tespit edebilir ve herhangi bir zamanda dolandırıcılık kanıtı başlatabilir, Katman 2 durum geçişi güvenlidir. Tabii ki, nispeten yüksek bir tamamlanma derecesine sahip iyimser rollups, para çekme köprülerinin de dolandırıcılık kanıtı protokol tarafından korunmasını sağlamalıdır ve şu anda neredeyse tüm Bitcoin Katman 2 bu önermeye ulaşamıyor ve long imzaya/MPC güvenmeye ihtiyaç duyuyor, bu nedenle long imza/MPC çözümünün nasıl seçileceği, Katman 2 güvenliği ile yakından ilgili bir sorun haline geldi.
Merlin, soğuk ve sıcak cüzdan izolasyonu, köprü varlıklarının Cobo ve Merlin Chain tarafından ortaklaşa yönetilmesi ve herhangi bir para çekme işleminin Cobo ve Merlin Chain'in MPC katılımcıları tarafından ortaklaşa ele alınması gibi önlemleri kullanarak köprü planında Cobo'nun MPC hizmetini seçti ve esasen kurumun kredi onayı yoluyla para çekme köprü güvenilirliğini sağladı. Tabii ki, bu sadece bu aşamada geçici bir önlemdir ve projenin kademeli olarak iyileştirilmesiyle, geri çekilme köprü, BitVM ve dolandırıcılık kanıtı protokol'yi tanıtarak 1/N güven varsayımının "iyimser köprü" ile değiştirilebilir, ancak inmesi daha zor olacaktır (şu anda, neredeyse tüm Layer2 resmi köprüleri long işarete dayanmaktadır).
Genel olarak, Merlin'in POS tabanlı bir DAC, BitVM'ye dayalı iyimser bir ZK-Rollup ve Cobo'ya dayalı bir MPC varlık saklama çözümü sunduğunu, DAC izinlerini açarak DA sorununu çözdüğünü, BitVM ve dolandırıcılık kanıtı protokol'yi tanıtarak durum geçişinin güvenliğini sağladığını ve tanınmış varlık saklama platformu Cobo'nun MPC hizmetini tanıtarak para çekme köprü güvenilirliğini sağladığını söyleyebiliriz.
Lumoz tabanlı iki adımlı doğrulama ZKP gönderim şeması
Daha önce, Merlin'in güvenlik modelini taradık ve iyimser ZK-rollup kavramını tanıttık. Merlin'in teknoloji yol haritasında Merkeziyetsizlik Prover da tartışılıyor. Hepimizin bildiği gibi, Prover, Sequencer tarafından piyasaya sürülen partiler için ZKProof'ların oluşturulmasından sorumlu olan ZK-Rollup mimarisinde temel bir roldür ve zk-SNARKs oluşturma süreci çok donanım kaynağı yoğun ve çok zor bir sorundur.
ZK ispatlarının oluşturulmasını hızlandırmak için görevi paralelleştirmek en temel işlemlerden biridir. **Sözde paralelleştirme aslında ZK kanıt oluşturma görevini farklı Kanıtlayıcılar tarafından ayrı ayrı tamamlanan farklı parçalara bölmek ve son olarak Toplayıcı toplayıcı en uzun Kanıtı bir bütün halinde toplamaktır.
ZK kanıtlarının üretim sürecini hızlandırmak emir Merlin, Lumoz'un Prover'ını bir hizmet çözümü olarak kullanacak, bu da aslında bir madencilik havuzu oluşturmak için çok sayıda donanım cihazını bir araya getirmek ve ardından farklı cihazlara bilgi işlem görevleri atamak ve POW madenciliğine benzer şekilde karşılık gelen teşvikleri atamak.
Bu Merkeziyetsizlik Prover şemasında, genellikle önden çalışan saldırılar olarak bilinen bir saldırı senaryoları sınıfı vardır: Bir toplayıcı Toplayıcının bir ZKP oluşturduğunu ve bir ödül alma umuduyla ZKP'yi gönderdiğini varsayalım. Diğer toplayıcılar ZKP'nin içeriğini gördükten sonra, bu ZKP'nin kendi kocaları tarafından yapıldığını iddia ederek aynı içeriği önüne koymak için acele ettiler, bu durum nasıl çözülür?
Akla gelebilecek en içgüdüsel çözümlerden biri, her Toplayıcıya belirli bir görev numarası atamaktır, örneğin, yalnızca Toplayıcı A görev 1'i alabilir ve diğer herkes görev 1'i tamamlasa bile ödül alamaz. Ancak bu yaklaşımla ilgili sorunlardan biri, tek bir risk noktasına karşı koruma sağlamamasıdır. Toplayıcı A'nın bir performans hatası varsa veya bağlantısı kesilirse, Görev 1 takılır ve tamamlanamaz. Ayrıca, görevleri tek bir kuruluşa atama uygulaması, rekabetçi teşviklerle üretkenliği artırmanın iyi bir yolu değildir.
Polygon zkEVM, bir blog yazısında, farklı Toplayıcıların birbirleriyle rekabetçi bir şekilde rekabet etmeleri için teşvik edilmesi gerektiğini ve teşviklerin ilk gelene ilk hizmet esasına göre dağıtılması gerektiğini ve zincire ZK-Kanıtı gönderen ilk Toplayıcıların ödül alabileceğini belirten Proof of efficiency adlı bir yöntem önerdi. Tabii ki, MEV önden koşma sorununun nasıl çözüleceğinden bahsetmedi.
Lumoz, iki adımlı bir doğrulama ZK kanıtı gönderme yöntemi kullanır, bir Toplayıcı bir ZK kanıtı oluşturduktan sonra, içeriğin tamamını göndermesine gerek yoktur, ancak yalnızca ZKP'nin hash yayınlar, başka bir deyişle, hash yayınlar (ZKP+Toplayıcı Adres). Bu şekilde, diğerleri hash değerini görseler bile, ilgili ZKP içeriğini bilmezler ve doğrudan aceleye getiremezler;
Birisi tüm hash kopyalayıp önce yayınlarsa, bunun bir anlamı yoktur, çünkü hash belirli bir toplayıcı X'in Adres içerir ve toplayıcı A önce hash yayınlasa bile, hash orijinal görüntüsü ortaya çıktığında, herkes içinde bulunan toplayıcı Adres A değil X olduğunu görecektir.
Bu iki adımlı doğrulama ZKP gönderim şeması sayesinde, Merlin (Lumoz), ZKP gönderim sürecindeki önden çalışan sorunu çözebilir ve ardından son derece rekabetçi zk-SNARKs oluşturma teşvikleri gerçekleştirebilir, böylece ZKP'nin üretim hızını artırabilir.
Merlin's Phantom: en uzun zincir birlikte çalışabilirliği
Merlin'in teknik yol haritasına göre, Merlin ve diğer EVM zincirleri arasında birlikte çalışabilirliği de destek edecekler ve uygulama yolu temelde önceki Zetachain fikri ile aynı, Merlin kaynak zincir olarak kullanılıyorsa ve diğer EVM zincirleri hedef zincir olarak kullanılıyorsa, Merlin Düğüm kullanıcı tarafından yapılan cross-chain birlikte çalışabilirlik talebini algıladığında, hedef on-chain üzerinde sonraki iş akışını tetikleyecektir.
Örneğin, Merlin ağı tarafından kontrol edilen bir EOA hesap Polygon üzerinde konuşlandırılabilir, ** Bir kullanıcı Merlin Chain'de bir cross-chain birlikte çalışabilirlik talimatı yayınladığında, Merlin ağı önce içeriğini ayrıştırır ve hedef on-chain üzerinde yürütülen bir işlem verisi oluşturur ve ardından Oracle Ağı MPC işlemdeki imza işleme, işlemin dijital imzasını oluşturur. Merlin'in Relayer'ı Düğüm daha sonra işlemi ** Polygon'da serbest bırakır ve Merlin'in EOA'daki varlıkları aracılığıyla sonraki işlemleri hedef on-chain hesap tamamlar.
Kullanıcının ihtiyaç duyduğu işlem tamamlandığında, ilgili varlık doğrudan kullanıcının hedef on-chain üzerindeki adresine iletilecek ve teorik olarak doğrudan Merlin Zincirine de geçebilecektir. Bu çözümün bazı bariz avantajları vardır: geleneksel varlık cross-chain ve Cross chain köprüleri sözleşmeleri tarafından üretilen ücretlerin aşınmasını ve yıpranmasını önleyebilir ve cross-chain operasyonlarının güvenliğini sağlamak için doğrudan Merlin'in Oracle Ağı tarafından garanti edilir ve long'cu harici altyapıya güvenmeye gerek kalmaz. Kullanıcılar Merlin Chain'e güvendiği long, bu tür cross-chain birlikte çalışabilirliği varsayılan olarak kullanmakta bir sorun yoktur.
Özet
Bu yazıda, daha fazla long kişinin Merlin'in genel iş akışını anlamasına ve güvenlik modelini daha net bir şekilde anlamasına yardımcı olduğuna inanılan Merlin Chain'in genel teknik çözümünün kısa bir açıklamasını veriyoruz. Mevcut Bitcoin ekolojisini tüm hızıyla göz önünde bulundurarak, bu tür teknik bilim popülerleştirme davranışının değerli olduğuna ve genel halk tarafından ihtiyaç duyulduğuna inanıyoruz, Gelecekte Merlin ve bitLayer, B^Square ve diğer projeler üzerinde long vadeli takip gerçekleştireceğiz ve teknik çözümlerinin daha derinlemesine bir analizini yapacağız, bu yüzden bizi izlemeye devam edin!