Orijinal yazar: Faust, geek web3

2023'teki Yazıt Yazından günümüze kadar, Bitcoin Layer 2 her zaman tüm Web3'ün öne çıkan konusu olmuştur. Her ne kadar bu alanın yükselişi Ethereum Layer 2'den çok daha geç olsa da, POW'un benzersiz cazibesi ve spot ETF'lerin sorunsuz uygulanmasıyla "menkul kıymetleştirme" riski konusunda endişelenmesine gerek olmayan Bitcoin, Layer 2 haline geldi. Bu türev yolu sadece altı ay içinde on milyarlarca dolar değerinde sermayenin ilgisini çekti.

Bitcoin Layer 2 parkurunda milyarlarca dolarlık TVL'ye sahip olan Merlin, şüphesiz en büyük hacme ve en çok takipçiye sahip olan isim. Açıkça bahis teşvikleri ve hatırı sayılır getirilerle Merlin, birkaç ay içinde neredeyse aniden ayağa kalktı ve Blast'ı geride bırakan bir ekolojik efsane yarattı. Merlin giderek daha popüler hale geldikçe, teknik çözümleriyle ilgili tartışmalar da giderek daha fazla insanı endişelendiren bir konu haline geldi.

Bu makalede Geek Web3, Merlin Chain teknik çözümüne odaklanacak ve yayınlanan belgelerini ve protokol tasarım fikirlerini yorumlayacaktır. Daha fazla kişinin Merlin'in genel iş akışını anlamasına ve Cognition'ın herkesin güvenlik modelini daha net anlamasına izin vermeye kararlıyız. Bu "baş Bitcoin Katman 2"nin nasıl daha sezgisel bir şekilde çalıştığını anlamak için.

Merlin'in merkezi olmayan oracle ağı: açık zincir dışı bir DAC komitesi

İster Ethereum Layer 2 ister Bitcoin Layer 2 olsun, tüm Layer 2 için DA ve veri yayın maliyetleri çözülmesi gereken en önemli konuların başında geliyor. Bitcoin ağının kendisinde birçok sorun olduğundan ve doğal olarak büyük veri akışını desteklemediğinden, bu değerli DA alanının nasıl kullanılacağı, Katman 2 proje taraflarının hayal gücünü test eden zor bir sorun haline geldi.

Bir sonuç açıktır: Eğer Katman 2 "doğrudan" işlenmemiş işlem verilerini Bitcoin bloğuna yayınlarsa, ne yüksek verim ne de düşük işlem ücretleri elde edecektir. En yaygın çözümler ya veri boyutunu yüksek sıkıştırma yoluyla mümkün olduğunca küçük sıkıştırıp ardından Bitcoin bloğuna yüklemek ya da verileri doğrudan Bitcoin zinciri altında yayınlamaktır.

İlk fikri benimseyen Katman 2 arasında en ünlüsü muhtemelen Citrea'dır. Katman 2'nin durum değişikliklerini belirli bir süre boyunca dağıtmayı (durum farkı), yani birden fazla hesaptaki durum değişikliği sonuçlarını birlikte dağıtmayı planlıyorlar. karşılık gelen ZK sertifikalarıyla birlikte Bitcoin zincirine yüklenir. Bu durumda herkes Bitcoin ana ağından state diff ve ZKP’yi indirebilir ve ardından Citrea durumundaki değişiklikleri izleyebilir. Bu yöntem zincirdeki veri boyutunu %90'dan fazla sıkıştırabilir.

Bu, veri boyutunu büyük ölçüde sıkıştırabilse de, darboğaz hala açıktır. Çok sayıda hesabın durumu kısa sürede değişirse, Katman 2'nin bu hesaplardaki tüm değişiklikleri özetlemesi ve Bitcoin zincirine yüklemesi gerekir. Nihai veri yayınlama maliyeti çok düşük tutulamaz. Bu birçok Ethereum'da geçerlidir. zincirler Bu ZK Toplamasında görülebilir.

Birçok Bitcoin Layer 2 basitçe ikinci yolu seçer: Bitcoin zinciri altındaki DA çözümünü doğrudan kullanın, ya kendiniz bir DA katmanı oluşturun ya da Celestia, EigenDA, vb. kullanın. B^Square, BitLayer ve bu makalenin kahramanı Merlin, bu zincir dışı DA genişletme çözümünü kullanıyor.

Geek Web3'ün bir önceki makalesi olan "B^2 teknolojisi yol haritasının yeni versiyonunun analizi: Bitcoin zinciri altında DA gerekliliği ve doğrulama katmanı" başlıklı yazımızda, B^2'nin Celestia'yı doğrudan taklit ederek DA zinciri altında bir destek oluşturduğundan bahsetmiştik. veri örnekleme fonksiyonuna sahip ağın adı B^2 Hub'dır. İşlem verileri veya durum farkı gibi "DA verileri" Bitcoin zinciri altında saklanır ve Bitcoin ana ağına yalnızca datahash/merkle kökü yüklenir.

Bu aslında Bitcoin'e güvenilmez bir ilan tahtası gibi davranır: Herkes Bitcoin zincirindeki veri karmalarını okuyabilir. Zincir dışındaki veri sağlayıcıdan DA verisini aldıktan sonra bunun zincirdeki datahash'e yani hash (data 1) == datahash 1'e karşılık gelip gelmediğini kontrol edebilirsiniz. . İkisi arasında bir yazışma varsa bu, zincir dışı veri sağlayıcının size verdiği verilerin doğru olduğu anlamına gelir.

Yukarıdaki süreç, zincir dışı düğümler 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ış veri sağlamasını önleyebilir. Ancak burada çok önemli bir kötü senaryo var: Eğer verinin kaynağı - Sıralayıcı, veri karmasına karşılık gelen verileri hiç göndermiyorsa, yalnızca veri karmasını Bitcoin zincirine gönderiyorsa ve herhangi birinin bunu yapmasını önlemek için ilgili verileri kasıtlı olarak saklıyorsa. Okuyun, şu anda ne yapmalıyım?

Benzer senaryolar aşağıdakileri içerir ancak bunlarla sınırlı değildir: yalnızca ZK-Proof ve StateRoot'un serbest bırakılması, ancak karşılık gelen DA verilerinin (durum farkı veya İşlem verileri) serbest bırakılması. Her ne kadar insanlar ZKProof'u doğrulayabilir ve Prev_Stateroot'tan New_Stateroot'a kadar olan hesaplama sürecinin geçerli olduğunu doğrulayabilir, ancak Ancak hangi hesapların durumunun değiştiğini bilmiyorum. Bu durumda kullanıcının varlıkları güvende olsa da herkes ağın gerçek durumundan hiçbir şekilde emin olamaz. Şu anda Layer'da hangi işlemlerin paketlendiğini ve hangi sözleşme durumunun güncellendiğini bilmiyorlar. 2 temel olarak kapatmaya eşdeğerdir.

Bu aslında "veri saklamadır". Ethereum Vakfı'ndan Dankrad, Ağustos 2023'te benzer bir konuyu Twitter'da kısaca tartışmıştı. Elbette esas olarak "DAC" denilen bir şeyi hedef alıyordu.

Zincir dışı DA çözümlerini benimseyen çoğu Ethereum Katman 2, genellikle bir komite oluşturmak için özel izinlere sahip birkaç düğüm kurar; tam adı Veri Kullanılabilirliği Komitesi'dir (DAC). Bu DAC komitesi bir garantör görevi görüyor ve dış dünyaya Sequencer'ın gerçekten de tam DA verilerini (işlem verileri veya durum farkı) zincir dışı yayınladığını iddia ediyor. Daha sonra DAC düğümleri toplu olarak bir çoklu imza oluşturur. Çoklu imza, eşik gereksinimlerini (2/4 gibi) karşıladığı sürece, Katman 1'deki ilgili sözleşmeler, DAC komitesinin denetimini dürüstçe geçmiş olacaktır. DA'nın zincir dışı verilerinin tamamını yayınladı.

Ethereum Layer 2'nin DAC komitesi temel olarak POA modelini takip eder ve yalnızca KYC'yi veya resmi atamayı geçen birkaç düğümün DAC komitesine katılmasına izin verir, bu da DAC'yi "merkezileştirme" ve "ittifak zinciri" ile eşanlamlı hale getirir. Ayrıca DAC modunu benimseyen bazı Ethereum Layer 2'de sıralayıcı, DA verilerini yalnızca DAC üye düğümlerine gönderir ve neredeyse hiçbir zaman verileri başka yerlere yüklemez. DA verilerini elde etmek isteyen herkesin DAC komitesinden izin alması gerekir, böyle bir durum söz konusu değildir. ittifak zincirinden temel farkı.

Hiç şüphe yok ki DAC merkezi olmayan bir yapıya sahip olmalıdır. Katman 2'nin DA verilerini doğrudan Katman 1'e yüklemesine gerek yoktur, ancak birkaç kişinin kötülük yapmak için komplo kurmasını önlemek için DAC komitesinin erişim hakları dış dünyaya açık olmalıdır. (DAC'ın kötü sahnelerine ilişkin bir tartışma için lütfen Dankrad'ın Twitter'daki önceki açıklamalarına bakın)

Celestia tarafından daha önce önerilen BlobStream, esasen merkezi DAC'nin yerine Celestia'yı kullanmaktır. Ethereum L2'nin sıralayıcısı, Celestia düğümlerinin 2/3'ü bunun için imza atarsa, Katman Ethereum 2'ye konuşlandırılabilir. münhasır sözleşme, ayırıcının DA verilerini doğru bir şekilde yayınladığını varsayar ve bu da aslında Celestia düğümünün garantör olarak hareket etmesine olanak tanır. Celestia'nın yüzlerce Validator node'una sahip olduğunu düşünürsek bu büyük DAC'ın nispeten merkezi olmayan bir yapıya sahip olduğunu düşünebiliriz.

Merlin tarafından benimsenen DA çözümü aslında Celestia'nın BlobStream'ine nispeten yakın; her ikisi de DAC'ye POS biçiminde erişim açarak onu daha merkezi olmayan hale getiriyor. Yeterli sayıda varlığı stake ettiği sürece herkes bir DAC düğümü çalıştırabilir. Merlin'in belgelerinde yukarıda adı geçen DAC düğümüne Oracle adı veriliyor ve esnek bir rehin mekanizması uygulamak için BTC, MERL ve hatta BRC-20 tokenlerinin varlık rehinlerini destekleyeceği ve ayrıca Lido'ya benzer proxy rehinlerini de destekleyeceği belirtiliyor. (Oracle'ın POS rehin sözleşmesi temelde Merlin'in temel anlatılarından biridir ve sağlanan rehin faiz oranları nispeten yüksektir)

Burada Merlin'in iş akışını kısaca açıklıyoruz (aşağıdaki resim):

• Sıralayıcı çok sayıda işlem talebi aldıktan sonra bunları toplar ve Prover düğümüne ve Oracle düğümüne (merkezi olmayan DAC) aktarılan bir veri kümesi (veri kümesi) oluşturur.

• Merlin'in Prover düğümü merkezi değildir ve Lumoz'un Prover'ını bir Hizmet hizmeti olarak kullanır. Birden fazla veri kümesi alındıktan sonra Prover madencilik havuzu karşılık gelen sıfır bilgi kanıtlarını üretecek. Daha sonra ZKP, doğrulama için Oracle düğümüne gönderilecek.

• Oracle düğümleri, Lmuoz'un ZK madencilik havuzu tarafından gönderilen ZK Kanıtının, Sequencer tarafından gönderilen Toplu veriye karşılık gelip gelmediğini doğrulayacak. İkisi eşleşebiliyorsa ve başka hatalar içermiyorsa doğrulama başarılı olur. Bu işlem sırasında, merkezi olmayan Oracle düğümleri, eşik imzaları aracılığıyla çoklu imzalar üretecek ve sıralayıcının DA verilerini tamamen gönderdiğini ve karşılık gelen ZKP'nin geçerli olduğunu ve Oracle düğümlerinin doğrulamasını geçtiğini dış dünyaya ilan edecek.

• Sıralayıcı, Oracle düğümlerinden çoklu imza sonuçlarını toplar. İmza sayısı eşik gereksinimlerini karşıladığında imza bilgileri, DA verilerinin (veri kümesi) veri karmalarıyla birlikte Bitcoin zincirine gönderilir ve dışarıya aktarılır. Okumak ve onaylamak için dünya.

Oracle düğümü, ZK Kanıtını doğrulama hesaplama sürecinde özel işlemler gerçekleştirir, bir Taahhüt taahhüdü oluşturur ve bunu Bitcoin zincirine göndererek herkesin "taahhüt"e itiraz etmesine olanak tanır. Buradaki süreç temelde bitVM'nin sahtekarlığa karşı koruma protokolüyle aynıdır. Mücadele başarılı olursa, Taahhüdü veren Oracle düğümü mali olarak cezalandırılacaktır. Elbette Oracle'ın Bitcoin zincirinde yayınlamak istediği veriler aynı zamanda mevcut Katman 2 durumunun (StateRoot) karma değerini ve dışarıdan tespit için Bitcoin zincirinde yayınlanması gereken ZKP'nin kendisini de içeriyor.

Burada detaylandırılması gereken birkaç detay var. Öncelikle Merlin yol haritasında Oracle'ın gelecekte DA verilerini Celestia'ya yedekleyeceği belirtiliyor. Bu sayede Oracle düğümleri, Veri kalıcılığına ihtiyaç duymadan yerel geçmiş verilerini düzgün bir şekilde ortadan kaldırabiliyor. yerel olarak. Aynı zamanda, Oracle Network tarafından oluşturulan Taahhüt aslında bir Merkle Ağacının köküdür. Taahhüde karşılık gelen veri setinin tamamını herkese açık hale getirmek için kökün dış dünyaya açıklanması yeterli değildir. üçüncü taraf DA platformu Bu platform Celestia veya EigenDA veya diğer DA katmanları olabilir.

Güvenlik modeli analizi: İyimser ZKRollup+Cobo'nun MPC hizmeti

Yukarıda Merlin'in iş akışını kısaca anlattık, sanırım herkes zaten temel yapısına hakim oldu. Merlin ve B^Square, BitLayer ve Citrea'nın temelde aynı güvenlik modelini (iyimser ZK-Rollup) izlediğini görmek zor değil.

Bu kelimeyi ilk kez okuduğunda birçok Ethereum meraklısı kendini tuhaf hissedebilir. "İyimser ZK-Rollup" nedir? Ethereum topluluğunun algısına göre, ZK Rollup'ın "teorik modeli" tamamen kriptografik hesaplamaların güvenilirliğine dayanmaktadır ve güven varsayımlarının dahil edilmesini gerektirmez. "İyimser" kelimesi tam olarak güven varsayımını ortaya koymaktadır, bu da insanların çoğu anlamına gelir. Bu arada, Rollup'ın hatasız ve güvenilir olduğu konusunda iyimser olun. Bir hata oluştuğunda, Toplama operatörü dolandırıcılık kanıtı yoluyla cezalandırılabilir. Bu, OP Toplama olarak da bilinen Optimistic Toplama adının kökenidir.

Rollup'ın temelindeki Ethereum ekosistemi için iyimser ZK-Rollup biraz sıradan olabilir, ancak Bitcoin Layer 2'nin mevcut durumuyla tamamen uyumludur. Teknik kısıtlamalar nedeniyle, Bitcoin zinciri ZK Proof'u tamamen doğrulayamıyor ve özel koşullar altında ZKP'nin hesaplama sürecinin yalnızca belirli bir adımını doğrulayabiliyor. ZKP'nin off-chain doğrulama sürecinde belli bir hesaplama adımında hata olduğuna dikkat çekilip, sahtekarlık kanıtı yoluyla buna itiraz ediliyor. Elbette bu, Ethereum tarzı ZK Rollup ile karşılaştırılamaz ancak zaten bu kapsamdadır. Bitcoin Layer 2'nin erişimi. En güvenilir ve emniyetli güvenlik modeli.

Yukarıdaki iyimser ZK-Toplama şeması altında, Katman 2 ağında meydan okumaları başlatma yetkisine sahip N kişi olduğunu varsayarsak, bu N meydan okuyanlardan 1'i dürüst ve güvenilir olduğu sürece, hatalar herhangi bir zamanda tespit edilebilir ve sahtekarlık yapılabilir. Kanıtlar başlatılabilir. Katman 2 durum geçişleri güvenlidir. Elbette, daha yüksek tamamlanma derecesine sahip iyimser Toplamanın, para çekme köprüsünün aynı zamanda sahtekarlığa karşı koruma protokolü tarafından korunmasını sağlaması gerekir. Şu anda neredeyse tüm Bitcoin Layer 2 bu önermeyi başaramıyor ve çoklu imzaya/MPC'ye güvenmeye ihtiyaç duyuyor. Peki nasıl seçilmelidir? Çoklu imza/MPC çözümü, Katman 2 güvenliğiyle yakından ilgili bir konu haline geldi.

Merlin, sıcak ve soğuk cüzdan izolasyonu gibi önlemleri benimseyerek köprüleme çözümü için Cobo'nun MPC hizmetini seçti. Köprüleme varlıkları Cobo ve Merlin Chain tarafından ortaklaşa yönetiliyor. Herhangi bir para çekme davranışı, Cobo ve Merlin Chain'in MPC katılımcılarının bunu ortaklaşa ele almasını gerektiriyor. Esas olarak kurumun kredi onayı aracılığıyla para çekme köprüsünün güvenilirliği sağlanmaktadır. Tabii ki, bu sadece bu aşamada geçici bir önlemdir, proje yavaş yavaş geliştikçe, çekilme köprüsünün yerini BitVM ve sahtekarlığa dayanıklı protokolün tanıtılmasıyla 1/N güven varsayımına sahip bir "iyimser köprü" alabilir. Büyük olması daha zor olacaktır (şu anda neredeyse tüm resmi Katman 2 köprüleri çoklu imzaya dayanmaktadır).

Genel olarak Merlin'in, BitVM ve sahtekarlığa dayanıklı protokoller sunarak DAC izinlerini açarak DA sorununu çözmek için POS tabanlı DAC, BitVM tabanlı iyimser ZK-Rollup ve Cobo tabanlı MPC varlık saklama çözümünü tanıttığını söyleyebiliriz; durum geçişinin güvenliği; tanınmış varlık saklama platformu Cobo'nun MPC hizmetini sunarak para çekme köprüsünün güvenilirliğini sağlayın.

Lumoz'a dayalı iki adımlı doğrulama ZKP gönderim şeması

Daha önce Merlin'in güvenlik modelini çözdük ve iyimser ZK toplaması konseptini tanıttık. Merlin'in teknoloji yol haritasında merkezi olmayan Prover'dan da bahsediliyor. Hepimizin bildiği gibi Prover, ZK-Rollup mimarisinde temel bir roldür. Sequencer tarafından yayımlanan Batch için ZKProof'un oluşturulmasından sorumludur. Sıfır bilgi kanıtını oluşturma süreci, donanım kaynaklarını çok tüketir ve çok çetrefilli bir sorundur. .

ZK kanıtlarının oluşturulmasını hızlandırmak için görevleri paralelleştirmek ve bölmek en temel işlemdir. Paralelleştirme olarak adlandırılan şey aslında ZK kanıt oluşturma görevinin sırasıyla farklı Kanıtlayıcılar tarafından tamamlanan farklı parçalara bölünmesi anlamına gelir. Son olarak Toplayıcı birden fazla Kanıtı bir bütün halinde birleştirir.

ZK kanıtı oluşturma sürecini hızlandırmak için Merlin, Lumoz'un Prover'ını bir hizmet çözümü olarak benimseyecek; bu çözüm aslında çok sayıda donanım cihazını bir madencilik havuzu oluşturmak için bir araya getiriyor ve daha sonra bilgi işlem görevlerini farklı cihazlara tahsis ediyor ve gerekli verileri dağıtıyor. karşılık gelen Teşvikler, POW madenciliğine biraz benzer.

Bu merkezi olmayan Prover çözümünde, genellikle önden çalışan saldırı olarak bilinen bir tür saldırı senaryosu vardır: Bir toplayıcının (Toplayıcı) ZKP'yi kurduğunu ve ödülleri almak için ZKP'yi gönderdiğini varsayalım. Diğer toplayıcılar ZKP'nin içeriğini gördükten sonra, bu ZKP'nin ilk önce kendileri tarafından oluşturulduğunu iddia ederek aynı içeriği ondan önce yayınladılar. Bu durum nasıl çözülür?

Belki de herkesin aklına gelen en içgüdüsel çözüm, her Toplayıcıya belirlenmiş bir görev numarası atamaktır. Örneğin, yalnızca Toplayıcı A, görev 1'i alabilir ve diğerleri, görev 1'i tamamlasalar bile ödül alamazlar. Ancak bu yaklaşımın bir sorunu var, o da tek nokta risklerine karşı koyamaması. Toplayıcı A'nın performans hatası varsa veya bağlantısı kesilirse, görev 1 takılıp kalacak ve tamamlanamayacaktır. Üstelik görevlerin tek bir kuruluşa dağıtıldığı bu yöntem, rekabetçi bir teşvik mekanizması yoluyla üretim verimliliğini artıramaz ve iyi bir yaklaşım değildir.

Polygon zkEVM bir zamanlar bir blogda Verimlilik Kanıtı adı verilen bir yöntem önermişti; bu yöntem, farklı Toplayıcılar arasındaki rekabeti teşvik etmek için rekabetçi araçların kullanılması gerektiğine ve teşviklerin ilk gelen ilk alır esasına göre tahsis edilmesi gerektiğine işaret ediyordu. ilk - Kanıt, Toplayıcının zincire gönderilmesiyle ödüllendirilebilir. Elbette MEV'in önden gitme sorununun nasıl çözüleceğine değinmedi.

Lumoz, iki adımlı doğrulama ZK kanıtı gönderme yöntemini benimser. Bir Toplayıcı, bir ZK kanıtı oluşturduktan sonra, tüm içeriği göndermesine gerek kalmaz, yalnızca ZKP karmasını yayınlar. Başka bir deyişle, karmayı (ZKP+Toplayıcı Adresi) yayınlar. ). Bu sayede başkaları hash değerini görse bile karşılık gelen ZKP içeriğini bilemez ve doğrudan ileriye atlayamaz;

Birisi hash'in tamamını kopyalayıp önce yayınlarsa bunun bir anlamı yoktur, çünkü hash belirli bir toplayıcı X'in adresini içerir. Toplayıcı A, hash'i ilk önce yayınlasa bile, hash'in orijinal görüntüsü ortaya çıktığında herkes bunu yayınlayacaktır. Ayrıca içerdiği toplayıcı adresinin A değil X olduğunu da görün.

Bu iki adımlı doğrulama ZKP gönderim şeması aracılığıyla Merlin (Lumoz), ZKP gönderim sürecinde mevcut olan önden çalışan sorunu çözebilir, böylece son derece rekabetçi sıfır bilgi kanıt oluşturma teşvikleri elde edebilir ve böylece ZKP oluşturma hızını artırabilir.

Merlin'in Hayaleti: Çok zincirli birlikte çalışabilirlik

Merlin'in teknik yol haritasına göre, Merlin ve diğer EVM zincirleri arasındaki birlikte çalışabilirliği de destekleyecekler. Uygulama yolu temel olarak önceki Zetachain fikriyle aynı olacak. Merlin düğümü Kullanıcı tarafından gönderilen zincirler arası birlikte çalışabilirlik talebini algıladıktan sonra, hedef zincirde sonraki iş akışı tetiklenecektir.

Örneğin, Merlin ağı tarafından kontrol edilen bir EOA hesabı Polygon'a dağıtılabilir. Kullanıcı, Merlin Zinciri üzerinde zincirler arası birlikte çalışabilirlik talimatı verdiğinde, Merlin ağı önce içeriğini ayrıştırır, hedefte yürütülecek bir işlem verisi oluşturur. Zincir ve ardından Oracle Network, işlem üzerinde MPC imza işlemeyi gerçekleştirir ve işlem için bir dijital imza oluşturur. Daha sonra Merlin'in Relayer düğümü, Polygon üzerindeki işlemi serbest bırakır ve sonraki işlemleri, hedef zincirdeki EOA hesabındaki Merlin'in varlıkları aracılığıyla tamamlar.

Kullanıcının talep ettiği işlem tamamlandığında ilgili varlıklar doğrudan kullanıcının hedef zincirdeki adresine iletilecektir. Teorik olarak doğrudan Merlin Chain'e de aktarılabilir. Bu çözümün bazı bariz faydaları vardır: geleneksel varlıklar çapraz zincirdeyken zincirler arası köprü sözleşmelerinin neden olduğu işlem ücretlerini ve aşınma ve yıpranmayı önleyebilir ve zincirler arası operasyonların güvenliği doğrudan Merlin'in Oracle Ağı tarafından garanti edilir ve dış altyapıya güvenmeye gerek yok. Kullanıcılar Merlin Chain'e güvendiği sürece bu tür zincirler arası birlikte çalışabilirlik davranışının sorun olmayacağı varsayılabilir.

Özetle

Bu yazımızda Merlin'in genel iş akışını daha fazla kişinin anlamasına ve güvenlik modelini daha net anlamasına olanak sağlayacağına inandığımız Merlin Chain'in genel teknik çözümünü kısaca yorumluyoruz. Mevcut Bitcoin ekosisteminin tüm hızıyla devam ettiği göz önüne alındığında, bu tür bir teknolojinin yaygınlaştırılmasının değerli olduğuna ve kamuoyunun ihtiyaç duyduğuna inanıyoruz. Merlin, bitLayer, B^Square ve diğer projelerin uzun vadeli takibini yapacağız. Gelecekte, teknik çözümlerin daha derinlemesine bir analizini sunacağız, bu yüzden bizi izlemeye devam edin!