Güvenli Zincirler Arası İş Birliği İçin Paylaşılan Güvenliğin Kullanımı

Blockchain köprülerine yapılan saldırılar milyarlarca dolarlık kayıplara yol açtığından, zincirler arası güvenlik hakkındaki tartışmaların sıklıkla yoğun tartışmalara yol açması şaşırtıcı değildir. Ancak daha pragmatik bir yaklaşım benimsemeye inanıyoruz; bu yaklaşım, güvenli birlikte çalışabilirlik sorununu ilk prensiplerden analiz etmeyi ve zincirler arası uygulamalar ve kullanıcıları için güvenlik garantilerini artıracak mekanizmalar tasarlamayı içerir.

Bu makalede, paylaşımlı güvenlik kavramını inceleyeceğiz ve paylaşımlı güvenlik tasarımlarının (Lagrange Eyalet Komiteleri gibi) birlikte çalışabilirlik protokolleri için anlamlı güvenlik özelliklerini başlatmanın maliyetini nasıl azaltabileceğini açıklayacağız. Zincirler arası iletişim protokolleri için paylaşımlı güvenliğe odaklanırken, herhangi bir merkezi olmayan uygulama (kullanım durumundan bağımsız olarak) aşırı operasyonel yük oluşturmadan yeterli merkezsizleştirme ve güven en aza indirme elde etmek için bu yeni teknolojiyi kullanabilir.

Paylaşımlı güvenliğe gayriresmi bir giriş

"Paylaşımlı güvenlik", bir protokolün harici bir kaynaktan türettiği güvenliği ifade eder. Paylaşımlı bir güvenlik şemasında, bir protokoldeki katılımcılar tarafından bir araya getirilen kaynaklar (örneğin, sermaye veya hesaplama gücü) başka bir protokol için ekonomik güvenlik oluşturmak amacıyla kullanılır. Paylaşımlı güvenlik, her ağın kendi güvenliğinden sorumlu olduğu standart modelden farklıdır.

Örneğin Bitcoin ve Ethereum gibi halka açık blok zincirleri, canlılığı garanti altına almak ve aynı anda düşmanca saldırıların (örneğin Sybil saldırıları , uzun menzilli saldırılar , tutulma saldırıları , zaman haydut saldırıları ve rüşvet saldırıları ) maliyetini artırmak için fikir birliği algoritmalarını İş Kanıtı veya Hisse Kanıtı gibi Sybil direnç mekanizmalarıyla birleştirir.

Paylaşımlı güvenlik şemaları farklı şekilde çalışsa da hedefler genellikle iki amaç etrafında döner:

• Ek risk (risk istifleme) yaratmadan veya ek güvenlik varsayımları getirmeden blok zinciri ağlarında sermaye verimliliğini artırmak.
• Blok zinciri ağlarının (özellikle yeni protokollerin) geçersiz durum geçişlerine, yeniden düzenlemelere, sansüre karşı dirençlere ve bir protokolün canlılığına ve güvenliğine yönelik diğer saldırılara karşı savunma kapasitesinin iyileştirilmesi.

Paylaşılan güvenlik tam olarak yeni bir kavram değil; örneğin, birleştirme madenciliği 2011'de tanıtıldı ve madencilerin Nakamoto konsensüsünü uygulayan iki (veya daha fazla) farklı PoW zincirinde bloklar oluşturmak için aynı kriptografik İş Kanıtı'nı (PoW) kullanmasını sağladı. Bu, yerel token'ları madencilerden önemli ilgi görecek kadar değer kazanmamış olan daha yeni PoW tabanlı protokollerin (Namecoin ve Rootstock gibi), Bitcoin ağını güvence altına almaya adanmış hesaplama kaynaklarını yeniden kullanarak yeni protokoldeki blokların zorluğunu artırarak güvenliği paylaşmasına olanak sağladı.

Bununla birlikte, birleştirme madenciliğinin hesap verebilir güvenliğin eksikliği nedeniyle merkezi olmayan ağlar için zayıf bir ekonomik güvenlik biçimi sağladığı düşünülmektedir. Akademik literatürde hesap verebilir güvenlik, bir protokolün protokol kurallarını (kanıtlanabilir şekilde) ihlal eden düğümleri tespit etme ve kötü niyetli davranışları cezalandırma yeteneğini yansıtır. Örneğin, Hisse İspatı tabanlı protokoller, düğümlerin konsensüse katılmadan önce teminatı kilitlemesini (protokolün yerel belirtecini hisseleyerek) gerektirir ve bir doğrulayıcının kötü davranışına dair kanıt ortaya çıkarsa bu teminatı yok edebilir/dondurabilir ("eğik çizgi").

Birleştirme madenciliği durumunda, birleştirme madenciliği yapılan zincirde geçersiz blokları bilerek kabul eden düğümler güvenilir bir şekilde tespit edilemez. Dahası, söz konusu düğümleri cezalandırmak imkansızdır (tanımlamak mümkün olsa bile) çünkü bu, madencilik donanımını yakmak veya yok etmek gibi sert önlemler gerektirir. Birleştirme madenciliği yapılan zincirin belirtecinin güvenliğine yönelik saldırılar nedeniyle değer kaybetme tehdidi Bizans davranışını caydırmak için yeterli görünse de, kötü niyetli madencilerin kaybedecekleri daha az şey vardır çünkü orijinal zincirin (örn. Bitcoin) değeri etkilenme olasılığı düşüktür.

Paylaşılan güvenliğin modern kavramları yalnızca hesap verebilir güvenliği içerecek şekilde evrimleşmekle kalmadı, aynı zamanda paylaşılan güvenliğin temeli olarak farklı bir yatırım birimi olan sermayeyi kullanmaya da yöneldi. Bu tasarımda, üzerine inşa edilen diğer PoS protokolleri için güvenlik sağlayan bir temel protokol vardır; düğümler, ikincil ağın güvenliğini sağlamaya katılmadan önce önce birincil ağa katılır (ağın yerel token'ını hisse olarak kilitleyerek).

Bu tasarım farklı biçimlerde olabilir:

• Doğrulayıcılar birincil ağda ve ikincil ağda aynı anda yer alırlar
• Doğrulayıcıların bir alt kümesi (birincil ağdan) ikincil ağı doğrulamak ve güvence altına almak için rastgele örneklenir
• İkincil ağ, birincil ağda birleştirilmiş bağımsız bir doğrulayıcı kümesi tarafından güvence altına alınır
• Birincil ağdaki doğrulayıcılar, yatırılan sermayeyi ikincil ağdaki doğrulayıcılara yeniden devreder

Uygulama ayrıntılarından bağımsız olarak, yukarıda açıklanan paylaşımlı güvenlik şemaları için kritik ayrıntı, temel protokolün ikincil ağda kötü niyetli davranan doğrulayıcıları cezalandırma araçlarına sahip olması gerektiğidir. İkincil ağı güvence altına alan daha az sermaye olduğundan, kötü niyetli bir süper çoğunluğun protokolü ele geçirmesi olasılığı gerçek bir endişe kaynağıdır.

Çözüm, bir veya daha fazla dürüst katılımcının (azınlığı oluşturan) bir anlaşmazlık başlatarak ve protokol ihlal eden davranışın kanıtını temel katmana yayınlayarak çoğunluğu sorumlu tutabilmesini sağlamaktır. Temel protokol (bir "yargıç" olarak hareket ederek) bu kanıtı kabul ederse, dürüst olmayan taraflar birincil ağda teminatı (bir teminat olarak) keserek cezalandırılabilir. Önemlisi, temel katmanın anlaşmazlıkları çözmeden önce yalnızca sağlanan kanıtı doğrulaması gerekir ve ek bir fikir birliği yürütmesi gerekmez; bu da koordinasyon yükünü azaltır.

Daha incelikli nokta, kesme mekanizmalarının etkili olması için kötü davranışın bir tarafa atfedilebilmesi gerektiğidir. PoS tabanlı ağlarda, doğrulayıcıların fikir birliği protokolü içinde benzersiz bir kriptografik kimlik görevi gören bir genel-özel anahtar çifti oluşturması gerekir. Blok önermek veya blokların geçerliliğini doğrulamak gibi rutin görevler sırasında, bir doğrulayıcı blok verilerini özel anahtarıyla imzalar ve bu da onu etkin bir şekilde bu seçeneğe bağlar.

Bu, protokolün güvenliğine veya canlılığına (veya bazı durumlarda her ikisine) bir saldırı olarak yorumlanabilecek farklı eylemler için bir doğrulayıcıyı kesmeyi mümkün kılar:

• Aynı dönemde iki çelişkili bloğun imzalanması (resmi olarak "tereddüt" olarak bilinir)
• Geçersiz bir bloğun imzalanması (bir teklif veya tasdik sırasında)
• Bir veya daha fazla işlemi sansürleme
• Bir bloğun verilerinin bazı veya tüm bölümlerini gizleme

İlk iki suç aynı şekilde tespit edilebilirken (bir doğrulayıcının imzasından genel anahtarını kurtararak), son ikisi dahil etme listeleri ve silme kodları gibi diğer mekanizmalar gerektirir. Her durumda, kriptografinin kullanımı, bir protokoldeki belirli istenen güvenlik özelliklerini (sansüre karşı direnç ve işlemlerin geçerliliği gibi) düşürebilecek kötü niyetli davranışların güvenilir bir şekilde tespit edilmesini ve cezalandırılmasını sağlar. Bu, merkezi olmayan ağları güvence altına almak için kriptografik mekanizmaları ekonomik teşviklerle birleştirmeyi içeren "kriptoekonomik güvenlik"in anlamı hakkında biraz bağlam sağlar.

Bu fikri, Ethereum'un güvenliğini paylaşan yeni bir PoS blok zinciri örneğini kullanarak açıklayabilir ve birleştirme madenciliğine benzetebiliriz. Oyuncak protokolümüzün şu özellikleri vardır (bunun örnek amaçlı kullanılan aşırı basitleştirilmiş bir örnek olduğunu unutmayın):

• Düğüm operatörlerinin, PoS ağında doğrulayıcı olarak kaydolmadan önce Ethereum akıllı sözleşmesinde teminat olarak belirli miktarda ETH tokeni yatırmaları gerekir
• Dönemler boyunca, PoS protokolündeki blok önerenler, blok başlıklarının karma değerlerini (doğrulayıcıların imzalarını içerir) akıllı bir sözleşmede saklayarak Ethereum'a gönderir
• Güvenlik, dolandırıcılık kanıtlarına dayanır; ana zincir (Ethereum) durum geçişlerini doğrulamaz, ancak belirli bir durum geçişinin geçersiz olduğunu gösteren bir karşı örneği doğrulayabilir
• Belirli bir durum geçişi bir veya daha fazla tarafça itiraz edilirse, zincir üstü bir kesme mekanizması etkinleştirilir

Şimdi, ikincil ağdaki kötü niyetli düğümlerin çoğunluğunun köprü sözleşmesinde yatırılan fonları çalmak için geçersiz bir bloğu sonlandırmak için işbirliği yaptığını varsayalım. Bu senaryoda, dürüst bir doğrulayıcı, dolandırıcılık kanıtı yayınlayarak ve protokol ihlal eden doğrulayıcıları belirleyerek Ethereum'daki zincir üstü kesme mekanizmasını tetikler. Protokol kuralları bir doğrulayıcının tüm hissesini kesmeye izin veriyorsa, PoS zincirini bozmanın maliyeti doğrulayıcıların çoğunluğu tarafından yatırılan miktarla orantılıdır.

Bu örnek, hesap verebilir güvenliğin paylaşılan güvenlik tasarımlarının temelini nasıl oluşturduğunu ve daha küçük ağların, önemli ekonomik güvenliği başlatmış ve daha yüksek düzeyde merkeziyetsizlik ve güvensizlikle övünen daha büyük protokoller tarafından güvence altına alınmasına nasıl olanak sağladığını göstermektedir. Ayrıca, Hisse Kanıtı mekaniğinin, birleştirme madenciliğine (ekonomik güvenliğin temeli olarak hesaplama gücünü kullanan) kıyasla daha güçlü güvenlik kavramlarına sahip paylaşılan güvenlik tasarımlarına yol açtığını da görebiliriz.

Ayrıca, "önyükleme sorununu" (yeni bir blok zinciri protokolünün, token'ı yeterli değer elde etmediği için düşük ekonomik güvenliğe sahip olduğu) hafifletmek için başka bir ağın token'ını stake için kullanan yeni bir protokol fikrini ortaya koyar. Önyükleme sorunu, donanım yatırımını ekonomik güvenlik birimi olarak kullanan birleştirme madenciliği gibi yaklaşımlarla çözülebilirken, bu tür paylaşımlı güvenlik belirli nedenlerden dolayı en uygun değildir (bazılarını daha önce tanımladık):

• Sermaye yatırımı—node doğrulama için kötü niyetli davranışlara önemli maliyetler yüklemesi beklenen— zımnidir ve ekonomik güvenlik için kullanılması zordur. PoW birleştirme madenciliği durumunda sermaye yatırımını açık hale getirmek, muhtemelen kötü niyetli davranışlar olması durumunda madencilik donanımını imha etmek gibi sert bir önlem gerektirir ki bu gerçek dünya durumlarında gerçekçi değildir ve kullanılması zordur.
• Birleştirme madenciliği (veya konsensüse katılımın altyapı çalıştırmaya bağlı olduğu herhangi bir paylaşımlı güvenlik tasarımı) ölçeklenmesi zordur. Örneğin, bir madencinin yatırım getirisi azalmaya başlamadan önce aynı anda kaç PoW zincirini birleştirebileceğine dair bir üst sınır vardır.

Buna karşılık, sermaye yatırımını bir yatırım birimi olarak kullanan PoS tabanlı paylaşımlı güvenlik şemaları, yeni ağların etkin ve verimli bir şekilde başlatılması sorununu çözmek için yararlı olan belirli özelliklere sahiptir:

• Sermaye yatırımı açıktır (pay sahipleri teminat gereksinimlerini karşılamak için token satın almak için sermaye yatırır) ve güçlü ve somut ekonomik güvenlik garantileri için kaldıraç olarak kullanılabilir. Örneğin, bir protokolün 0,9 ETH değerinde işlem güvence altına alan 1 ETH değerinde hisseye sahip olduğunda, 0,9 ETH değerinde işlem güvence altına alan 0,9 ETH değerinde hisseye sahip olduğundan daha güvenli olma olasılığının daha yüksek olduğunu görselleştirmek kolaydır.
• Konsensüse katılım "saf" sermaye yatırımına bağlı olduğundan, ekonomik güvenliği ölçeklendirmek ve doğrulayıcıların aşırı koordinasyon yükü olmadan (özellikle donanım gereksinimleri düşük olduğunda) birden fazla protokolü güvence altına almasını sağlamak daha kolaydır.

Bununla birlikte, her yaklaşımın dezavantajları olacaktır ve paylaşımlı güvenlik-paylaşım yoluyla bir istisna değildir; örneğin, teminat doğrulayıcılarının bir PoS protokolüne ne kadar teminat koyması gerektiğini belirlemek çözülmesi zor bir sorundur. Bunu, önceki paragraftaki şu ifadeyi dikkate alarak bağlamına oturtacağız: " Bir protokolün 0,9 ETH değerinde işlem güvence altına alan 1 ETH değerinde paya sahip olması durumunda, 0,9 ETH değerinde işlem güvence altına alan 0,9 ETH değerinde paya sahip olması durumundan daha güvenli olma olasılığının daha yüksek olduğunu görselleştirmek kolaydır. "

Bu ifade makul görünse de, daha derin bir analiz, optimum tahvil gereksinimini seçmenin zorluğunu ortaya koymaktadır:

• Doğrulayıcılardan 0,9 ETH değerinde varlığı güvence altına almak için 1 ETH talep edilmesi sermaye verimliliğini azaltır ve aşırı teminatlandırmaya neden olur.
• 1 ETH değerindeki stake ile 2 ETH değerindeki işlemleri güvence altına almak, PoS blok zincirindeki ekonomik bant genişliğini (veya "kaldıracı") azaltır ve yetersiz teminatlandırmaya neden olur.

İdeal bir senaryoda, bir protokol tasarımcısı 1 ETH değerinde işlem güvence altına alan 1 ETH'lik hisseye sahip olmayı tercih eder. Ancak bu tür dengelere gerçek dünya koşullarında farklı nedenlerle ulaşmak zordur; örneğin, birim zaman başına güvence altına alınacak sermaye miktarı (blok/dönem başına işlemlerin marjinal değerinin bir fonksiyonu) dinamiktir. Bu, bir PoS sisteminde ideal tahvili belirlemeyi çok zor bir mekanizma sorunu ve hisse tabanlı paylaşımlı güvenlik şemaları için önemli bir husus haline getirir, örneğin yeniden bahis (bir sonraki bölümde tartışacağız).

Yeniden kazıklama ve kontrol noktası oluşturmadan paylaşılan güvenlik

Yeniden bahis

Yeniden bahis, geleneksel finans alanında bir borç verenin varlıkları (önceden bir borçlu tarafından teminat olarak rehin edilmiş) yeni bir krediyi güvence altına almak için teminat olarak kullandığı bir uygulama olan repothecation'a dayanır. Burada, yeni karşı taraf orijinal teminat varlığına ilişkin hakları üstlenir, böylece yeni krediyi alan kuruluş geri ödemede temerrüde düşerse, fonları geri almak için varlığı açık artırmayla satabilir.

Doğru bir şekilde uygulandığında, repothecation faydalı olabilir. Başlangıç olarak, aksi takdirde hareketsiz kalacak olan varlıkları yeniden kullanarak kâr getiren faaliyetler için kısa vadeli finansman sağlayarak daha yüksek sermaye verimliliği ve likidite sağlar. Kredi çekmenin kârı, repothecation edilen teminatın değerini aşarsa, ilgili tüm taraflar (ilk borçlu, borç veren ve borç verenin borç vereni) faydalanır.

Yeniden ipotek büyük bir risk içerir (uygulamanın TradFi kurumları arasında büyük ölçüde gözden düşmesinin nedenlerinden biri), özellikle de tasfiye gerçekleştiğinde varlıklarına ilişkin haklarını kaybedebilecek orijinal borçlu için. Teminatı yeniden kullanan borç veren de risk taşır, özellikle de yeni bir karşı taraf kredi temerrütleri nedeniyle yatırılan teminata el koyduktan sonra borçlulara geri ödeme yapması gerekiyorsa.

Diğer risk, daha önce kısaca açıkladığımız ve aşırı teminatlandırma ile yetersiz teminatlandırma arasındaki denge etrafında dönen bir risktir. Daha önce vurgulanan örnekte, Banka B (John'un bankası) aşırı kaldıraçlı bir pozisyona girerse (John'un teminatının değerinden daha fazla borç alırsa) ve bir zarara uğrarsa, Banka B'den aldığı krediyi geri ödemek (veya John'un varlıklarını iade etmek) zorlaşır. Banka B, Banka A'dan (John'un bankası) John'un teminatının değerinden daha az borçlanmasını isteyerek bu uç duruma karşı koruma sağlayabilir; ancak bu, Banka A için sermaye verimsizliğini artırır ve ilk etapta John'un teminatını yeniden ipotek ettirmekten elde edilen kazançları azaltır.

Aynı artılar ve eksiler kümesi restaking için de geçerlidir. Daha ileri gitmeden önce önemli bir ayrıntıyı açıklığa kavuşturmak önemlidir: restaker'ın payı her zaman önce temel protokolden geçer. Örneğin, Ethereum'daki bir restaker, yerel restaking veya likit restaking kullanılmasına bağlı olarak Beacon Chain sözleşmesine 32 ETH yatırmak veya staking hizmeti tarafından işletilen bir doğrulayıcıya ETH devretmek zorunda kalacaktır.

Ethereum'da yeniden hisse senedi alımı yüksek düzeyde aşağıdakileri içerir:

#1: Yeniden hisse alma protokolüne hisseli ETH'ye ilişkin sahiplik haklarının (veya bir talebin) verilmesi

Yerel yeniden bahiste, bir doğrulayıcının çekim adresini yeniden bahis protokolü tarafından yönetilen akıllı bir sözleşmeye değiştirmesi gerekir. Bu nedenle, fonlar Beacon Chain'den çıktıktan sonra doğrudan doğrulayıcıya gitmek yerine, bahis doğrulayıcıya ulaşmadan önce yeniden bahis protokolünden geçer (bunun neden böyle olduğunu yakında göreceğiz).

Ayrıca, stake edilmiş ETH'nin değiştirilebilir temsillerini (türevlerini) restaking protokolünün akıllı sözleşmelerine yatırmak da mümkündür (likit restaking). "Likit stake edilmiş token'lar" olarak adlandırılan bu token'lar, staking-as-service operatörleri (örn. RocketPool, Lido, Coinbase, vb.) tarafından verilir ve bir doğrulayıcı tarafından stake edilmiş ETH'nin bir kısmına ilişkin bir hak iddiasını temsil eder (ödüllerden elde edilen getiri dahil) ve yerel ETH token'ları için 1:1 oranında kullanılabilir.

#2: Yeniden bahis protokolü tarafından uygulanan ek kesme koşullarını seçme

Bir yeniden bahis protokolü genellikle çeşitli merkezi olmayan ağların ve uygulamaların ekonomik güvenlik için bağlanabileceği bir "ara yazılım" işlevi görür. Bunlar genellikle bir dizi tarafça bir tür doğrulama gerektiren protokolleri içerir (örneğin, bir oracle ağı) ancak yerel belirteci, Hisse Kanıtı ayarında kullanılmak üzere yeterli değere sahip değildir.

Sıfırdan yeni bir doğrulayıcı seti oluşturmak yerine, bu tür uygulamalar bir restaching protokolü aracılığıyla mevcut doğrulayıcıların hizmetlerinden yararlanabilir. Hizmetler, bir doğrulayıcının yeniden ipotek edilen teminatında benzersiz kesme koşulları belirleyebilir; restaching protokolü artık doğrulayıcının çekilmesini kontrol ettiğinden, bunu uygulayabilir; bu da ekonomik güvenliğe yönelik engeli azaltır.

Önemli bir not: AVS kesme koşulları, Ethereum'un Beacon Chain konsensüsü tarafından uygulanan kesme koşullarından bağımsızdır, bu nedenle bir doğrulayıcının ETH hissesi, Ethereum'un kendisinde kesilebilir bir suç işlememiş olsa bile kesilebilir. Bu, "risk istifleme" olarak tanımladığımız şeye yol açabilir: daha yüksek sermaye verimliliği karşılığında, birincil ağ aksi takdirde alacağından daha fazla risk devralır. (Risk istiflemenin, daha sonra göreceğimiz gibi, çekirdek EigenLayer protokolünün kendisi için de etkileri vardır.)

#3: Ek ödüller almak

Yeniden stake etme, önemli bir risk almayı gerektirir (örneğin, yeniden stake edilen bir doğrulayıcı, zincir üstü slash mekanizmasındaki bir hata nedeniyle yanlışlıkla kesilebilir). Ancak, yeniden ipotek etme TradFi'de likiditenin kilidini açtığı gibi, yeniden stake etme de PoS ekosistemlerinde sermaye verimliliğini artırabilir ve stake edenler için ortalamanın üzerinde getiri sağlayabilir.

Bu, güvenlik için yeniden bahisli sermaye kullanan hizmetlerin, doğrulayıcıları hizmetleri için ödüllendirmeleri gerektiği gerçeğine dayanmaktadır. Örneğin, bir oracle ağına katılan yeniden bahisli bir doğrulayıcı, oracle güncellemelerini doğrulamak için ücret alacaktır; ödeme, oracle'ın hizmetlerine güvenen diğer üçüncü taraf uygulamalardan gelir. Doğrulayıcılar hala Beacon Chain'den ödüller alırken, yeniden bahis, yeni bir ekosisteme taze sermayeyi yeniden dağıtmak zorunda kalmadan birden fazla PoS protokolünden gelir elde etmeyi sağlar.

Bu örnekte Ethereum resttake'ine odaklansak da, diğer Proof of Stake protokolleri de benzer hedeflere ulaşmak için resttake'in varyantlarını uyguladı (yeni protokoller/uygulamalar başlatmanın maliyetini düşürmek, sermaye verimliliğini artırmak ve ekonomik güvenliği ölçeklendirmek). Aslında, bir sonraki bölüm, diğer ekosistemlerdeki resttake'i vurgulamadan önce EigenLayer'ı—Ethereum'un önde gelen resttake protokolü—tartışıyor:

Öz Katman

EigenLayer, Ethereum'un ekonomik güvenliğini yeni dağıtılmış uygulamaları, ağları ve protokolleri (toplu olarak "Aktif Olarak Doğrulanmış Hizmetler" veya kısaca AVS'ler olarak tanımlanmaktadır) güvence altına almak için oluşturulmuş bir yeniden bahis protokolüdür. Ethereum'da yeniden bahis örneğini açıklayan önceki bölümü okuduysanız, EigenLayer'ın işlemlerini zaten üst düzeyde anlamışsınızdır; ancak bağlam için biraz daha ayrıntı ekleyeceğiz.

ETH'yi yeniden stake ettikten sonra (bir doğrulayıcıyla ilişkili çekilme kimlik bilgilerini EigenLayer tarafından kontrol edilen akıllı sözleşmelere yönlendirerek), bir doğrulayıcının çalıştırmak istediği AVS tarafından belirtilen görevleri gerçekleştirmesi gerekir. Örneğin, bir AVS bir yan zincir ise, yeniden stake edilen doğrulayıcı, işlemleri yürütmek ve blokları doğrulamak için yan zincir için istemci yazılımını çalıştırmalı ve bu görevleri doğru şekilde gerçekleştirdiği için ödüller kazanmalıdır. Daha genel olarak, görevler AVS'nin doğasına bağlı olarak değişebilir:

• Verilerin veri kullanılabilirliği ağında depolanması

• Zincirler arası bir köprü için para yatırma ve çekme işlemlerini onaylamak veya zincirler arası bir mesajlaşma protokolü için mesajları onaylamak

• Gizlilik odaklı bir uygulama veya korumalı ödeme ağı için sıfır bilgi kanıtlarının oluşturulması ve doğrulanması

• Blok başlıklarını depolamak ve doğrulamak ve zincirler arası birlikte çalışabilirlik protokolleri için röleleri/kahinleri çalıştırmak

  
  

Dikkatli okuyucular iki şeyi fark edecektir: (a) bir AVS tarafından belirtilen görevler oldukça keyfi olabilir (b) farklı AVS tarafından belirtilen görevler farklı yatırım ve çaba seviyeleri gerektirir. İkinci noktayı örneklemek için, blok başlıklarını bir çapraz zincir protokolünde depolamanın, bir veri kullanılabilirliği ağında veri depolama ve sağlama ile karşılaştırıldığında daha az disk/bellek alanı gerektireceğini hayal etmek mümkündür ( veri kullanılabilirliği örneklemesi gibi teknikler tek tek düğümlerdeki depolama yüklerini azaltsa bile).

Bu, EigenLayer'ın yeniden bahisli doğrulayıcıların AVS tarafından belirtilen görevlerin yürütülmesini, AVS'den kazanılan ödülleri doğrulayıcıyla paylaşan başka bir tarafa (bir operatöre) devretmesine izin vermesinin bir nedenidir. Bu yaklaşım, yeniden bahisli doğrulayıcılar için, operatörün AVS görevlerini doğru şekilde yerine getirememesi durumunda meydana gelebilecek olan kesme yükünün yeniden bahisli doğrulayıcı ve üçüncü taraf operatör arasında paylaşılma derecesine bağlı olarak değişen risk seviyelerine sahiptir.

Her AVS, bir EigenLayer restaker'ının hissesinin kesilebileceği bir dizi koşul belirtir. Örneğin, Proof of Space/Storage mekanizmalarını uygulayan bir veri kullanılabilirliği ağı, kararlaştırılan süre boyunca veri depolamayan operatörleri kesebilir. Kesme, operatörün EigenLayer içinde dondurulmasını tetikler (aktif olarak doğrulanmış bir veya daha fazla hizmete daha fazla katılımını engeller) ve doğrulayıcının ETH bakiyesinin sonunda azaltılmasını sağlar.

Kesme işleminin gerçekleşmesi için, suçun kanıtlanabilir olması gerekir; bu da temel protokolün (bu durumda Ethereum) anlaşmazlıkları çözmesine ve dürüst olmayan tarafı cezalandırmasına olanak tanır. Ethereum'un mevcut tasarımı, bir doğrulayıcının hissesinin %50'sine kadar kesmeye izin verir (16 ETH), bu da EigenLayer'a, bir operatörün görevleri yürütürken AVS tarafından belirtilen kuralları ihlal etmesi durumunda kalan %50'yi (16 ETH) kesme hakkı bırakır.

EigenLayer'ın kesme mekaniği ayrıca, yeniden bahis yapma konusunda ince bir riske işaret ediyor: bir hizmet tarafından kesilmek, bir doğrulayıcının EigenLayer akıllı sözleşmelerindeki ve Ethereum'un Beacon Zincirindeki genel bakiyesini azaltır. Ancak, önemli olan, belirli bir AVS'nin kesme mantığındaki bir hata nedeniyle kesmenin meydana gelmesi ve kanıtlanabilir bir suçtan kaynaklanmaması durumunda bir uç durum senaryosunun ortaya çıkmasıdır. Bu durumda, ana Ethereum zincirini doğrulamaktan elde edilen ödüllerin kaybı (AVS'yi doğrulamaktan elde edilen ödüllerden daha yüksek olduğu varsayılır) bir doğrulayıcının bakış açısından yeniden bahis yapmaktan elde edilen yatırım getirisini optimum olmayan hale getirir.

EigenLayer tarzı yeniden bahisle ilgili bir diğer risk, doğrulayıcının aşırı teminatlandırma ve yetersiz teminatlandırma riski ve risk istifleme kavramıyla ilgilidir. Önceki yeniden ipotek örneğinden, teminatı yeniden ipotek eden tarafın aynı anda ilk borçluya (teminatı yeni bir kredi almak için kullanılan) ve zincirdeki son borç verene (orijinal borçlu tarafından rehin verilen teminat üzerinde hak sahibi olan) borçlu olabileceğini görüyoruz.

EigenLayer gibi yeniden bahisli yapılarda da benzer bir dinamik ortaya çıkabilir; yeniden bahisli bir doğrulayıcı (kasıtlı veya bilinçli olarak) aynı anda Ethereum'un Beacon Chain'inde ve bir veya daha fazla AVS'de kesilebilir suçlar işlerse. İlk kesmenin nerede gerçekleştiğine bağlı olarak, diğer AVS'lerin kesilecek hissesi kalmamış olabilir; bu da EigenLayer tarafından güvence altına alınan uygulamalara risksiz bir saldırı yapılmasını etkili bir şekilde mümkün kılar.

EigenLayer ekibi bu saldırı vektörünü kabul etti (bkz. Ek B: EigenLayer whitepaper'ın Kriptoekonomik Risk Analizi) ve bu riski ele almak için birkaç adım attı. Bu, AVS'lerde staker alt teminatlandırmasını ve üst teminatlandırmasını değerlendirmek için resmi bir sezgisel yöntem sağlamayı ve lansmanda bir risk yönetimi panosu aracılığıyla AVS geliştiricilerine danışmanlık bilgisi sağlama planlarını belirtmeyi içerir.

Polkadot Parachain'ler

Çoğunlukla heterojen blok zincirleri arasında birlikte çalışabilirliği sağlamasıyla bilinse de Polkadot , paylaşımlı güvenliğe büyük ölçüde güvenir. Aslında paylaşımlı güvenlik, Polkadot ekosistemindeki farklı zincirlerin güven varsayımları getirmeden veya güvenlik riski oluşturmadan mesaj alışverişinde bulunabilmesinin nedenidir.

Polkadot'ta, doğrulayıcıların alt kümeleri (Relay Chain'de DOT token'ları stake etmiş olanlar) blokları ve her bir parachain'in derleyicisi tarafından üretilen ilişkili Geçerlilik Kanıtı'nı (PoV) doğrulamak için rastgele parachain'lere atanır (örneğin "alt zincirler"). Bir derleyici, bir parachain'in işlemlerini yürütmekten sorumlu düğümdür ve doğrulama için parachain'in doğrulayıcı grubuna gönderilen bir "para-blok" oluşturur.

Bir bloğun PoV'sini doğrulamak hesaplama açısından yoğun olduğundan, para-doğrulayıcılar (bir parachain'e atanan doğrulayıcılar için kullanılan ad) bu görev için ek ödüller alır. Para-doğrulayıcılar tarafından onaylanan bloklar (veya daha doğrusu, bu bloklara yönelik kriptografik taahhütler) Relay Chain'e (ana zincir) dahil edilmek üzere gönderilir. Bir parachain bloğu, kendisine atıfta bulunan bir blok, Relay Chain'deki kalan doğrulayıcıların çoğunluğu tarafından onaylanırsa kesin hale gelir.

Son nokta oldukça önemlidir: her parachain'deki doğrulayıcı sayısı düşük olduğundan (parça başına yaklaşık beş doğrulayıcı), bireysel parçaları bozmanın maliyeti düşüktür. Bu tür saldırılara karşı savunmak için Polkadot protokolü, parablokların rastgele seçilmiş başka bir düğüm grubu tarafından ikincil bir kontrolden geçmesini gerektirir.

Bir bloğun geçersiz veya kullanılamaz olduğu kanıtlanırsa (yani verilerin bir kısmı eksikse), dürüst düğümler, tüm Relay Chain doğrulayıcılarının itiraz edilen bloğu yeniden yürütmesini gerektiren ana Relay Chain'de bir anlaşmazlık başlatabilir. Anlaşmazlık, doğrulayıcıların ⅔'lük bir çoğunluğu anlaşmazlığın her iki tarafına da oy verdikten sonra sona erer ve yeniden yürütme, kesme iddiasını desteklerse, suçlu doğrulayıcılar zincirde kesilir.

Bu mekanizma, Polkadot protokolündeki tüm parachain'lerin, her bir parçada ayarlanan doğrulayıcının boyutundan bağımsız olarak aynı güvenlik seviyesini paylaşmasını sağlar. Dahası, parachain'ler güvenliği aynı kaynaktan alır (tüm para-bloklar Relay Chain tarafından onaylanır), uzak bir parçadan gelen mesajların geçerliliğine güvenebilirler (ikincisinin fikir birliği veya durumuyla ilgili ayrıntıları bilmeden).

Zincirler Arası Güvenlik

Zincirler arası güvenlik, Cosmos'un resttake'e cevabı olarak tanımlanmıştır ve Polkadot'un paylaşımlı güvenlik modeliyle benzerlik taşır. Polkadot'taki Relay Chain ve parachain'ler arasındaki ilişkiye benzer şekilde, Cosmos, birden fazla zincirin ("Cosmos Bölgeleri") bir ana zincire ("Cosmos Hub") bağlandığı ve ondan güvenlik türettiği bir hub-and-spoke modelini benimser. Mantık da Polkadot'un mantığına benzer: yeni zincirlerin sıfırdan güvenilir bir doğrulayıcı seti başlatmaya gerek kalmadan (oldukça zor bir görev) güvenli kalmasını sağlamak ve bunun yerine ekonomik güvenliği (tek bir katmanda bir araya getirilmiş) diğer zincirlerle paylaşmak.

Mevcut yinelemesinde, zincirler arası güvenlik, hem Cosmos Hub'ı hem de ona bağlı tüm tüketici zincirlerini doğrulamak için bir doğrulayıcı (ATOM token'ları stake etmiş) gerektirir. Bir tüketici zincirinde kötü niyetli bir şekilde hareket eden bir doğrulayıcı, sağlayıcı zincirindeki (bu durumda Cosmos Hub) hissesini kesme nedeniyle kaybetme riskiyle karşı karşıyadır.

Suçlu bir doğrulayıcıyı kesmek, genellikle sağlayıcı zinciri ile tüketici zinciri arasındaki IBC (Blok Zincirleri Arası İletişim) kanalı aracılığıyla kesilebilir davranışa dair kanıt içeren bir paketin iletilmesini gerektirir. Bu nedenle, zincirler arası güvenlik bir tür yeniden bahis olarak görülebilir; ayrıca, kritik bir hedefe ulaşır: Cosmos ekosisteminde uygulamaya özgü blok zincirlerini başlatmayı kolaylaştırır.

Daha önce, egemen blok zincirleri oluşturmaya çalışan projelerin, yeni kullanıcılara asgari güvenlik garantisi sağlamak için yerel bir token oluşturması ve yeterli sayıda doğrulayıcı çekmesi gerekiyordu. Ancak, zincirler arası güvenlik, Cosmos Hub'ın güvenliğinin (yazım sırasında ~2,5 milyar dolarlık hisse ile güvence altına alınmıştır) Cosmo'nun mevcut doğrulayıcı setinin boyutunu genişletmeye gerek kalmadan daha yeni, düşük değerli zincirleri güvence altına alacak şekilde ölçeklenebilmesini sağlar.

Not : Cosmos'un Zincirlerarası Güvenliğinin mevcut sürümü, tüketici zincirindeki kötü amaçlı kodun sahte slash paketlerinin iletilmesini tetiklemesi ve dürüst doğrulayıcıları kesmesi riski nedeniyle yalnızca tüketici zincirleri tarafından iletilen paketlere dayalı slashing'i devre dışı bırakır; bunun yerine, çift oylama (aynı yükseklikte iki bloğu imzalama) gibi suçlar, yönetim yoluyla sosyal slashing'e tabidir. Ancak, sosyal slashing'in de kendi riskleri vardır; bu, bir tüketici zincirinde çift imzalama için doğrulayıcıları kesme konusundaki son tartışmada görülmüştür (bu aynı zamanda paylaşılan güvenlik protokolleri oluşturmanın bazı karmaşıklıklarına da işaret eder) .

Mesh güvenliği, zincirler arası güvenliğe bir alternatiftir ve ikincisinin bazı eksikliklerini iyileştirmeyi amaçlar. Hem sağlayıcı hem de tüketici zincirleri için yazılım çalıştırmak yerine, sağlayıcı zincirinde stake edilmiş bir doğrulayıcı, stake'i tüketici zincirindeki bir doğrulayıcıya devredebilir. Bu, iki zinciri aynı anda doğrulama yükünü ortadan kaldırır (yönetim ve fikir birliğine katılım) ve yeniden stake edilmiş doğrulayıcılar için genel gideri azaltır (örneğin donanım gereksinimlerini azaltma).

Tıpkı EigenLayer'da olduğu gibi (bir Ethereum doğrulayıcısının bir operatörün kendi adına bir veya daha fazla ikincil protokolü (AVS) doğrulayabilmesi gibi), bir temsilci doğrulayıcının tüketici zincirini doğrulayan herhangi bir hisse koyması gerekmez. Temsilci doğrulayıcı görevlerini doğru şekilde yerine getiremezse (örneğin, kesinti yaşama veya geçersiz bloklar oluşturma/oylama), delege eden protokolün kurallarına göre tüketici zincirinde kesilir.

Mesh güvenliği, tüketici zincirlerinin birden fazla sağlayıcı zincirinden güvenlik kiralamasına (Cosmos Hub ile sınırlı kalmak yerine) ve doğrulayıcıların hisseyi hangi zincirlere devredeceklerini seçmelerine izin verdiği için zincirler arası güvenlikten de farklıdır. İkinci özellik ICS v2 dağıtımının bir parçası olarak planlanırken, ilkinin uygulanması pek olası değildir (ancak daha ikna edici olduğu söylenebilir).

Ethereum'un Senkronizasyon Komitesi

Ethereum'un Sync Komitesi, sonlandırılmış Beacon blok başlıklarını imzalamaktan sorumlu 512 doğrulayıcıdan oluşan bir gruptur. Her 256 dönemde (yaklaşık 27 saatte bir) yeni bir Sync Komitesi yeniden oluşturulur ve üyeler Beacon Chain'in mevcut doğrulayıcı setinden seçilir. Üyelerin Sync Komitesi'ne katılırken düzenli doğrulayıcı görevlerini (tasdik ve blok teklifleri dahil) sürdürmeleri beklenir.

Sync Komitesi ilk olarak Beacon Chain'in Altair çatallanması sırasında hafif istemcilerin yeni blokları doğrulayabilmesini (tam doğrulayıcı setini bilmeden) ve Ethereum'un durumundaki değişiklikleri izleyebilmesini sağlamak için uygulandı. Sync Komitesi'ne katılmak, Beacon Chain konsensüsüne katılmaktan daha fazla çaba gerektirdiğinden, üyeler küçük bir ödül alırlar (Beacon zinciri görevlerini tamamlamanın düzenli ödüllerine ek olarak).

Ancak, geçersiz blok başlıklarını imzalayan üyeler, Beacon Chain'in aksine, kesme işlemine tabi tutulmazlar. Ethereum'un çekirdek geliştiricileri, kötü niyetli Sync Komitesi üyelerini kesmenin daha fazla karmaşıklık getireceğini söyleyerek bu tasarımı savunurken, diğerleri ⅔ süper çoğunluğu oluşturan Sync Komitesi üyeleri arasındaki işbirliğinin zorluğuna (hafif istemcileri kötü bir blok başlığını kabul etmeye kandırmak için gereken) işaret etti.

Ancak, çapraz zincir iletişim protokolleri gibi yüksek değerli uygulamalar Ethereum'un durumunu izlemek için hafif istemcilere güvendiğinden, geçersiz blok başlıklarını imzalamak için Senkronizasyon Komitelerini kesme konusu yeniden ilgi çekti (bkz. Nimbus istemci ekibinin devam eden bir teklifi ). Uygulanırsa, kesme, Senkronizasyon Komitesine katılımı, doğrulayıcıların ek kesme koşullarını seçtiği ve blok başlıklarını imzalama ikincil hizmeti için ekstra ödüller aldığı bir tür yeniden bahis haline getirecektir.

Örnek vermek gerekirse, bir doğrulayıcı, Beacon Chain'in konsensüsüne katılırken dürüst davransa bile, Sync Komitesi'ndeyken protokol kurallarını ihlal ederse, maksimum bakiyesine kadar kesilebilir. Sync Komitesi'ni ayrıca Polkadot'un parachain sistemi ve daha büyük blok zinciri ağı içindeki bir alt protokolü doğrulamak için düğümlerin bir alt kümesini rastgele örnekleyen diğer paylaşımlı güvenlik biçimleriyle karşılaştırabiliriz (örneğin, Lagrange Durum Komiteleri, Avalanche'ın Alt Ağları ve Algorand'ın Durum Kanıtları protokolü).

Kontrol noktası oluşturma

Kontrol noktasına dayalı paylaşımlı güvenlik şemaları genellikle güvenlik tüketen bir zincirin, güvenlik sağlayan zincire aralıklarla en son durumuna ilişkin kriptografik taahhütler göndermesini içerir. Örneğin, bir blok önereninin, sonlandırılmadan önce en yeni blok başlığının karmasını ana zincire göndermesi gerekebilir.

Bu taahhütler "kontrol noktaları" olarak tanımlanır çünkü ana zincir, çocuk zincirinin o noktaya kadar olan geçmişinin geri döndürülemezliğini garanti eder. Başka bir deyişle, ana zincir, çocuk zincirinin (kanonik) bir zaman sıralamasını garanti eder ve uygular, onu blokları yeniden düzenleme ve çakışan bir çatal oluşturma girişimlerine karşı korur (örneğin eski işlemleri geri almak ve çift harcama yapmak).

Ana zincir, özellikle blok başlıklarının belirli bir bloğu kimin onayladığı/ürettiği hakkında bilgi içerdiği durumlarda, çocuk zincirinin geçerliliğini de garanti edebilir. Bir bloğun geçersiz olduğu ortaya çıkarsa, dürüst bir düğüm ana zincirde bir meydan okuma başlatabilir (ana zincir anlaşmazlığı tahkim ederek) ve çocuk zincirinin durumunun geri alınmasını tetikleyebilir.

Ayrıca, doğrulayıcı hisselerini yönetme mekanizması (akıllı sözleşme gibi) ana zincirde uygulanırsa, zincir üzerinde geçerli bir dolandırıcılık kanıtı kabul edildikten sonra protokol ihlal eden doğrulayıcıları keserek hesap verebilir güvenliği sağlamak mümkün hale gelir. Ana zincirin, alt zincirin kanonik geçmişini garanti etmesi burada önemlidir çünkü bu, düğümlerin kötü niyetli davranışın kanıtını gizlemek için geçmişi yeniden yazmasını (blokları kaldırarak) önler.

Commit sidechain'ler (Polygon PoS), optimium'lar (Arbitrum Nova/Metis), rollup'lar ve Babylon gibi kontrol noktası protokolleriyle entegre edilmiş zincirler bu paylaşımlı güvenlik biçimini uygular. Her durumda, bir protokol ekonomik güvenliğini, bir yerleşim katmanı (blokları sonlandırmaktan sorumlu) olarak kullanarak harici bir blok zincirinden alır. Bağlam için, Polygon PoS ve Arbitrum Nova/Metis başlıkları Ethereum'daki bir zincir içi sözleşmede depolarken, Babylon başlıkları bağlı Cosmos Bölgelerinden Bitcoin'e aktarır.

Katman 2 (L2) toplamaları benzer bir mekanizmayı kullanır (blok köklerini Katman 1 blok zincirine gönderme), ancak önemli bir fark vardır: Bir toplamanın bloklarını yeniden oluşturmak için gereken veriler aynı zamanda yerleşim katmanında da yayınlanır. Bu, yerleşim katmanının toplamanın güvenliğini (sonunda) tamamen garanti ettiği anlamına gelir. Buna karşılık, bir commit yan zincirinin veya iyimser zincirin durumunu yeniden oluşturmak için gereken veriler, özellikle kötü amaçlı bir sıralayıcı veya doğrulayıcı kümesinin veri saklama saldırıları gerçekleştirmesi durumunda, kullanılamayabilir.

Zincirler arası birlikte çalışabilirlik protokolleri için paylaşılan güvenlik

Paylaşımlı güvenliğin anlamı ve evrimi hakkında kapsamlı bir arka plan sağladıktan sonra, artık paylaşımlı güvenlik tasarımlarında yeni ufuklara dalabiliriz. Bu tür araştırma alanlarından biri, blok zincirleri arasında mesajlaşma ve köprüleme konusundaki mevcut yaklaşımları, birleştirilmiş (ekonomik) güvenliğin faydalarından yararlanarak geliştirmeyi amaçlayan çapraz zincir protokolleri için paylaşımlı güvenliktir .

Bu tanım okuyucunun aklında şu tür sorular uyandırabilir:

• Neden açıkça birlikte çalışabilirlik protokollerine odaklanılıyor?

• Paylaşımlı güvenlik teknolojisiyle entegre olan bir birlikte çalışabilirlik protokolü hangi faydaları sağlar?

  
  

Lagrange Labs, Lagrange State Committees'i oluşturuyor; bu, zincirler arası durumların güven açısından en aza indirilmiş kanıtlarına erişim gerektiren protokoller için paylaşılan bir güvenlik çözümü. (State Committees, Lagrange'ın ZK Big Data kanıt sistemini ve EigenLayer'ın resttake altyapısını birleştirerek zincirler arası birlikte çalışabilirlik protokolleri için paylaşılan bir güvenlik bölgesi oluşturuyor.) Bu nedenle, önceki soruların her birini ayrı ayrı incelemek ve bu süreçte köprüleme, dizinleme ve mesajlaşma uygulamalarını State Committee altyapısıyla entegre etme konusunda bir dava açmak zorundayız.

Çalışabilirlik protokollerine ilişkin kısa bir giriş

Modüler Blok Zincirleri İçin İş Birliği: Lagrange Tezi'nde , iş birliği protokollerinin silolanmış blok zincirlerini birbirine bağlamak ve blok zinciri uygulamaları (ve kullanıcıları) için likidite ve durum parçalanmasıyla ilgili sorunları azaltmak için çok önemli olduğunu açıkladık. Bu makalede belirtilen bazı önemli örnekler şunlardır:

• Kilitleme ve basma veya yakma ve basma mekanizmalarını uygulayan ve bir varlığın yerel bir blok zincirinden (yayınlandığı yer) yerel olmayan bir blok zincirinde kullanılmak üzere aktarılmasına izin veren köprüler

• Kullanıcıların tek bir gerçeklik kaynağını paylaşmayan ve birbirlerinin durumlarını doğrulayamayan blok zincirleri arasında güvenli bir şekilde bilgi iletmesine (veri paketleri aracılığıyla) olanak tanıyan mesajlaşma protokolleri

  
  

Ayrıca farklı blok zinciri birlikte çalışabilirlik çözümlerinin değerini vurguladık. Örneğin, köprüler kullanıcıların farklı ekosistemler arasında sorunsuz bir şekilde hareket etmesini, daha fazla uygulamaya maruz kalmasını ve varlıkların verimliliğini artırmasını (diğer blok zincirlerinde bulunan getiri üreten fırsatlardan yararlanarak) sağlar. Mesajlaşma protokolleri ayrıca çeşitli alanlar arasında bilgi (örneğin pozisyonlar ve borç profilleri) aktarımına dayanan zincirler arası borç verme, zincirler arası arbitraj ve zincirler arası ve zincirler arası marjlama gibi daha gelişmiş kullanım durumlarının kilidini açar.

Farklı amaçlar için tasarlanmış olsa da, tüm farklı birlikte çalışabilirlik çözümleri bazı temel özellikleri paylaşır. En önemlisi, kullanıcı veya bir uygulama tarafından sağlanan, zincirler arası bir işlem/operasyonda yer alan blok zinciri(ler) hakkında bazı bilgilerin doğru olduğunu doğrulamak için bir mekanizmadır. Bu, genellikle belirli bir durumun (ör. akıllı sözleşmenin depolamasında saklanan değerler, bir hesabın bakiyesi veya en son sonlandırılan blok) var olduğu veya bir işlemin farklı bir zincirde gerçekleştiği iddiasıdır.

Ethereum ile NEAR arasındaki bir köprü örneğini ele alalım; köprü operatörünün, bir kullanıcı bir varlığı (örneğin DAI) köprülediğinde her bir zincirin durumu hakkında aşağıdaki bilgileri doğrulaması gerekecektir:

• Kullanıcının NEAR adresine nearDAI token'larını basmadan önce, köprü operatörü söz konusu kullanıcının Ethereum'daki köprü sözleşmesine DAI yatırdığına dair kanıta ihtiyaç duyar
• Orijinal DAI mevduatını serbest bırakmadan önce (NEAR'dan Ethereum'a köprüleme yaparken), köprü operatörü söz konusu kullanıcının NEAR'da nearDAI token'larını yaktığına ve gerekli "yakma kanıtı" makbuzunu NEAR'daki köprünün sözleşmesine gönderdiğine dair kanıta ihtiyaç duyar

Yukarıda belirtilen zincirler arasındaki bir mesajlaşma protokolünün benzer, ancak biraz farklı gereksinimleri olacaktır. Bir Ethereum kullanıcısı bir zincirler arası işlemin yürütülmesini talep ederse ("NEAR'da X sözleşmesini çağır"), protokol mesaj talebinin başlangıçta Ethereum'a yerleştirildiğini doğrulamalıdır (genellikle bir zincir üstü sözleşmeyi çağırarak).

Zincirler arası işlemlerle ilgili iddiaları doğrulamanın basit bir yolu, söz konusu zincir için tam bir düğüm çalıştırmaktır. Her bloktan işlemleri indiren ve zincirin son durumunu senkronize etmeden önce yeniden yürüten tam düğümler, genellikle herhangi bir blok zincirindeki durum geçişlerini doğrulamanın en güvenilmez yoludur. Ancak, tam bir düğüm çalıştırmak hem zahmetli hem de gereksizdir; zahmetli çünkü tam düğümler yüksek donanım gereksinimleri gerektirir ve gereksizdir çünkü bir zincirler arası protokol yalnızca bazı işlem ve sözleşme kümeleriyle ilgili bilgilere ihtiyaç duyar.

Neyse ki, hafif istemciler tam bir düğümün çalıştırılmasını gerektirmeden olayları ve durum değişikliklerini izlemek için kolay/etkili bir yol sağlar. Hafif istemcinin tasarımına güvendiğimiz sürece, bir köprüde para yatırma/çekmelerin oluşumu ve bir mesajlaşma protokolünde mesaj isteklerinin/yürütmenin durumu gibi belirli bilgileri doğrulamak için blok başlıklarını indirebiliriz.

İki zincir arasında iletişimi etkinleştirmek için (bunlara zincir A ve zincir B diyeceğiz) bir birlikte çalışabilirlik protokolü, zincir B üzerinde zincir A'nın hafif bir istemcisini çalıştırır ve bu istemci zincir B'nin blok başlıklarını depolar (ve tam tersi). Bu, kaynak zincirdeki bir uygulamadan hedef zincirdeki başka bir uygulamaya kullanıcılar (veya herhangi bir üçüncü taraf) tarafından geçirilen çeşitli durum/depolama kanıtlarını (blok başlıkları, Merkle kanıtları, vb.) doğrulamasını sağlar. Hafif istemci, aşağıdaki resimde gösterildiği gibi iki blok zincirinin durumları hakkında bir bilgi kaynağı (bir "kahin") işlevi görür:

Ancak, zincirler arası durumların geçerliliğini doğrulamaya yönelik bu yaklaşım güven sorunuyla karşılaşır. Vitalik Buterin'in Güven Modelleri makalesi güvenin özlü bir tanımını sunar: " Güven, diğer insanların davranışları hakkında herhangi bir varsayımın kullanılmasıdır. " Makale ayrıca güvensizlik kavramını da tanımlar (bir uyarıyla):

Birçok blok zinciri uygulamasının en değerli özelliklerinden biri güvensizliktir: Uygulamanın, çıkarları değişip onları gelecekte beklenmedik bir şekilde hareket etmeye itebilecek olsa bile, belirli bir aktörün belirli bir şekilde hareket etmesine ihtiyaç duymadan beklenen şekilde çalışmaya devam edebilme yeteneği. Blok zinciri uygulamaları asla tamamen güvensiz değildir, ancak bazı uygulamalar güvensiz olmaya diğerlerinden çok daha yakındır. — Vitalik Buterin

Bağlamımızda (blok zinciri birlikte çalışabilirliği), iki veya daha fazla zincirin durumu birbirinden bağımsız olarak doğrulandığında güven kaçınılmaz hale gelir. Bob'un A zincirindeki uygulamasının Alice'in bir mesaj başlattığına dair bir kanıt aldığı bir senaryoyu ele alalım ("B zincirinde 5 ETH kilitle ve A zincirinde 5 Wrapped ETH (WETH) bas"). Mesaj kanıtı, Alice'in işleminin bir bloğa dahil edildiğini gösteren bir Merkle kanıtıdır ve Bob (B zinciri için zincir üstü hafif bir istemci çalıştırdığı için) kanıtı geçerli bir B zinciri bloğunun başlığından türetilen işlemlerin Merkle köküyle karşılaştırarak doğrulayabilir.

Ancak, bir blok bağlamında “geçerli” farklı anlamlara gelebilir: (a) “Blok başlığı, kaynak zincirinin doğrulayıcılarının çoğunluğu tarafından onaylanan bir bloğa aittir.” (b) “Blok başlığı, kaynak zincirinin işlem geçerlilik kurallarına göre işlemleri geçerli olan bir bloğa aittir.”

Bob, #1'i bir bloğun geçerliliğinin somut bir kanıtı olarak ele alabilir, ancak bu, kaynak zincirindeki doğrulayıcılar hakkındaki varsayımlara dayanmaktadır:

• “ A zincirindeki doğrulayıcıların çoğunluğu dürüsttür ve bir veya daha fazla geçersiz işlem içeren bir bloğu onaylamazlar. ”
• “ A zincirindeki doğrulayıcıların çoğunluğu ekonomik olarak rasyonel aktörlerdir ve geçersiz işlemlere sahip bir bloğu onaylamak için düşük teşviklere sahiptirler. ”

Burada, bu varsayımlardan herhangi birinin (veya her ikisinin) nerede bozulabileceğini görmek kolaydır; örneğin, hisse miktarı < zincir A üzerindeki işlem değeri (örneğin, hileli işlemler yoluyla bir köprüden çalınabilecek miktar) ise, doğrulayıcılar geçersiz bir bloğu sonlandırmak için teşvike sahiptir; bu, saldırıdan elde edilecek kârın maliyetlerden daha ağır basması anlamına gelse bile.

Genel olarak, zincirler arası durumları doğrulamak için her mekanizma güven varsayımlarına tabidir (bu güven varsayımlarından bazılarını ayrıntılı olarak tartışacağız). Temel amaç (ve bu, bu makale boyunca tekrarlanan bir temadır) çeşitli güven varsayımlarının birlikte çalışabilirliğe odaklanmış uygulamalar için büyük bir güvenlik riski oluşturmayacağı bir düzeye kadar zincirler arası iletişimdeki güveni en aza indirmektir.

Bu önemli bir hedeftir çünkü ortaya çıktığı üzere, farklı blok zincirlerini birbirine bağlamak için bir birlikte çalışabilirlik protokolü oluşturduğunuzda ve bölünmenin bir tarafında çalışan bir uygulama diğer tarafta keyfi bir olayın gerçekleştiğine dair yanlış bir iddiayı kabul ettiğinde, kötü şeyler -gerçekten kötü şeyler- olabilir. Örneğin, köprü istismarları, bir hatanın, bilgili bilgisayar korsanlarının var olmayan mesaj isteklerinin kanıtlarını (sahte) başarılı bir şekilde iletmesine ve kaynak zincirine teminat yatırmadan bir hedef zincirde belirteçler basmasına olanak tanıması nedeniyle gerçekleşmiştir.

Mevcut çapraz zincir güvenlik mekanizmalarının analizi

Protokol tasarımcıları o zamandan beri zincirler arası iletişimde bilgi doğrulama sorununa çözümler ürettiler; en yaygın olanı, zincirler arası bir işlemin varlığını/geçerliliğini doğrulamak için üçüncü bir tarafın kullanılmasıdır. Mantık basittir: A zincirindeki bir uygulama, B zincirinin durumunu doğrulayamayabilir, ancak bir grup insanın (güvendiğimiz veya bir mekanizma aracılığıyla dürüst olmasını beklediğimiz) B zincirinin durumuna atıfta bulunan bir bilgi parçasını (veya iddiayı) doğruladığını doğrulatabiliriz.

Buna "harici doğrulama" denir çünkü blok zincirinin dışındaki başka bir taraf zincir üstü olaylar için bir gerçeklik kaynağı olarak hareket eder ve (tipik olarak) kaynak zincirindeki blok başlıklarında imzaları yürüten bir veya daha fazla doğrulayıcıyı içerir. Hedef zincirdeki uygulama bu imzalanmış başlığı aldıktan sonra, bir kullanıcı tarafından sağlanan çeşitli durum kanıtlarını (bakiyeler, olaylar, para yatırma/çekme işlemleri vb.) buna karşı doğrulayabilir.

Belirli bir düzeyde hata toleransı oluşturmak için bazı birlikte çalışabilirlik protokolleri, geçerlilik için bir imzayı yürütmek üzere asgari sayıda özel anahtar gerektiren bir eşik imzalama şeması kullanır (çoklu imza ve çok taraflı (MPC) cüzdanlar yaygın örneklerdir). Ancak, birden fazla ( n'den k ) veya doğrulayıcının çapraz zincir durumlarını doğrulaması, özellikle küçük doğrulayıcı kümeleri için güvenlik için tam anlamıyla kesin bir çözüm değildir.

Örneğin, biri çoklu imzalı bir şemada yeterli sayıda imzalayanı tehlikeye atabilir ve zincirler arası bir köprüden hileli çekimleri yetkilendirebilir. Bir MPC kurulumu biraz daha güvenlidir (onay eşiği değiştirilebilir ve anahtar paylaşımları daha sık döndürülebilir), ancak yine de saldırılara karşı hassastır (özellikle bir tarafın anahtar paylaşımlarının çoğunu kontrol ettiği durumlarda).

Bahis

Birlikte çalışabilirlik protokolleri için güven varsayımlarını azaltmanın ve zincirler arası iletişimin güvenliğini artırmanın bir yolu, doğrulama görevlerini üstlenmeden önce harici doğrulayıcıların teminatı bir tahvil olarak paylaştırmasıdır. Paylaştırma, harici olarak doğrulanmış sistemler için güvenlik yaratır, özellikle de bir doğrulayıcı düğüm geçersiz bir blok başlığında bir imza yürütürse veya geçersiz bir zincirler arası işlemi onaylarsa tahvil teminatı kesilebilir).

Ancak bu yaklaşım bile, staking'in izinli veya izinsiz olmasına bağlı olarak sorunlarla gelir. İzinli bir sistem (doğrulayıcıların beyaz listeye alınması gereken) genellikle birkaç önceden onaylanmış kuruluşla sınırlıdır ve geliştirilmesi daha kolaydır; özellikle doğrulayıcıların herkes tarafından bilindiği ve itibarlarını korumak için dürüstçe hareket etme teşvikine sahip olduğu durumlarda kapsamlı teşvik tasarımına yatırım yapmaya gerek yoktur. Ayrıca, fikir birliğine varmak için gerekli olan iletişimin, kendilerini zaten tanıyan birkaç taraf arasında gerçekleşmesi nedeniyle verimlidir.

Elbette, tanımlanabilir katılımcılara sahip izinli bir sisteme sahip olmak, düşmanca saldırılar için kapıyı açar; örneğin, bir saldırgan bu doğrulayıcılardan bazılarını başarıyla taklit edebilir veya rüşvet verebilir ve böylece çoğunluk kontrolünü ele geçirebilir. Daha kötüsü, doğrulayıcıların gerçekte pay sahibi olmadığı (ve basitçe atandığı) bir Yetki Kanıtı (PoA) sistemi, sisteme saldırmanın maliyetini sıfıra indirir (örneğin, saldırganlar PoA doğrulayıcılarını sosyal mühendislik şemaları aracılığıyla tehlikeye atabilir ve sistemi ele geçirebilir).

İzinsiz bir hisse senedi sistemi, herhangi bir ilgili tarafın (doğru miktarda sermayeye sahip) zincirler arası işlemleri doğrulamaya başlamasına izin vererek bir sistemi bozmanın maliyetini artırır. Blok başlıklarını onaylamak için ≥ ⅔ çoğunluk gerektiren bir fikir birliği protokolüyle birleştirilirse, sistemi bozmanın maliyeti, sistemdeki doğrulayıcıların çoğunluğunu bozmak için gereken asgari miktara eşit olur. Ayrıca, kullanıcıların daha az güven varsayımı vardır (doğrulayıcılar azaltılabilir) ve dinamik bir doğrulayıcı kümesi, sosyal mühendislik gibi tekniklerle belirli düğümleri tehlikeye atmanın zorluğunu artırır.

Ne ters gidebilir ki? Aslında çok fazla. Başlangıç olarak, bir güvenlik olayı (birlikte çalışabilirlik protokolünün güvenliğini veya canlılığını bozan) meydana gelirse, sistemi güvence altına alan pay miktarı risk altındaki varlıkların toplam değerine eşit veya daha yüksek olmalıdır. Tersi doğruysa ( sistemi güvence altına alan toplam pay < risk altındaki toplam değer ), o zaman kesme tehdidi bile güvenliği garanti altına almada etkisiz hale gelir çünkü sistemi bozmanın kârı, onu bozmanın maliyetinden daha ağır basar.

Ayrıca, yukarıda belirtilen güvenlik özelliğini uygulamaya çalışmak, muhtemel doğrulayıcılar için daha yüksek bahis gereksinimleri belirlemeyi gerektirecektir. Bu da sermaye verimsizliği sorununu ortaya çıkarır; çünkü güvenlik, doğrulayıcı düğümlerin iki şeyi yapmasına dayanır:

• Doğrulama görevlerine katılmadan önce çok miktarda parayı önceden yatırmak (bahis olarak)

• Paranın uzun bir süre kullanılmadan bırakılması (güvenlik için, PoS protokolleri çekimlerde uzun gecikmeler uygular; bazıları haftalar veya aylar kadar uzun sürebilir; böylece bir doğrulayıcının kesintiye uğraması durumunda parayı kaybetmemek için derhal çekim yapmaya çalışması gibi uç durumlar önlenir)

  
  

Bahsetmediğimiz bir diğer şey ise, dürüst olmayan davranışları engellemek ve protokolün token'ı için karmaşık staking işlevselliği tasarlamak için kriptoekonomik teşvikler hakkında akıl yürütmesi gereken geliştiricilerin üzerindeki yüktür. Ürün geliştirme ve topluluk katılımı gibi daha önemli faaliyetlerden dikkati uzaklaştırmasının yanı sıra, birlikte çalışabilirlik altyapısı oluşturan ekipler için geliştirme döngüsünün karmaşıklığına ve bilişsel yüküne de katkıda bulunur.

İyimser doğrulama

"İyimser doğrulama", zincirler arası güvenlik sorununa ilişkin başka bir yaklaşımdır: Güvenilir bir taraftan veya gruptan zincirler arası durumu onaylamasını istemek yerine, herkesin bunu yapmasına izin veriyoruz. En önemlisi, bir istemci birlikte çalışabilirlik uygulamasına (genellikle "relay" olarak adlandırılır) zincirler arası durumlar hakkında iddialarda bulunan tarafın, onaylanan durumun geçerli olduğuna dair kanıt sağlaması gerekmez. Bu, aktarıcıların dürüst davranacakları ve yalnızca zincirler arası durumlar hakkında geçerli iddialarda bulunacakları "iyimser" varsayımından kaynaklanır.

Ancak elbette, bir veya iki (veya daha fazla) aktarıcının hile yapmasını bekliyoruz, bu yüzden iyimser bir şekilde doğrulanmış sistemler aktarıcıların durum kanıtlarını göndermeden önce küçük bir teminat yatırmasını gerektirir. İşlemlerin yürütülmesi (bir aktarıcı tarafından bildirilen zincirler arası durumlara atıfta bulunanlar) da sistemi izleyen herkese itiraz süresi içinde geçersiz iddiaları itiraz etmek için yeterli zaman vermek için geciktirilir. Bir aktarıcının iddiasının geçersiz olduğu ortaya çıkarsa, yatırılan teminat kesilir (bir kısmı itiraz edene gider).

İyimser doğrulama, çoğunluk ( n'nin k'si ) veya çoğunluk ( n'nin m'si ) doğrulayıcıya güvenme sorununu, dürüstçe hareket etmesi için bir doğrulayıcıya ( n'nin 1'i ) güvenme sorununa dönüştürür. İyimser olarak doğrulanan protokollerin güvenli kalması için, işlemleri yeniden yürütmek ve gecikme süresi içinde hileli işlemlere karşı koymak için hile kanıtları oluşturmak için yeterli durum verisine sahip bir aktöre sahip olmak yeterlidir (bu nedenle 1 of n güvenlik varsayımı).

Bu, sistemin tek bir röle ile doğru bir şekilde çalışabilmesi nedeniyle genel giderleri azaltır (canlılığı sağlamak için iki veya daha fazlasına ihtiyacımız olabilir). Ayrıca güvenlik için gereken hisse miktarını azaltır ve daha hızlı bir hisse çözme süresi belirlemeyi teşvik eder (gecikme süresi geçtikten sonra teminatlı teminat çekilebilir).

Dahası, iyimser doğrulamaya dayalı birlikte çalışabilirlik protokolleri "altta yatan blok zincirinin güvenliğini devralmak" olarak tanımlanıyor; bu, altta yatan blok zinciri canlıysa ve dolandırıcılık kanıtlarını sansürlemiyorsa, kötü niyetli bir aktarıcının dürüst olmayan davranışlarla kurtulamayacağı fikrine dayanmaktadır. Dahası, protokole saldırmak, blok zincirinin kendisine saldırmayı gerektirir çünkü işlemleri uzun bir süre sansürlemek, ağdaki düğümlerin çoğunluğunu kontrol etmeyi gerektirir ve dolayısıyla pay/madencilik gücü.

Ancak iyimser doğrulamanın bile kendine özgü dezavantajları vardır. Örneğin, köprüleme işlemlerinin veya mesaj isteklerinin sonlandırılması ve yürütülmesinde gecikme uygulanması gecikmeyi artırır ve genel kullanıcı deneyimini düşürür. Bu tür zincirler arası güvenliğin ayrıca güvenlik açısından etkileri olan birkaç ince "tuzak" vardır, örneğin kötü niyetli bir tarafın geçerli işlemleri sorgulayarak dürüst aktarıcıları "üzüp" bir tür DDoS saldırısı gerçekleştirmesi olasılığı.

Sahtekarlık kanıtları (çoğunlukla) doğası gereği etkileşimli olduğundan, geçersiz bir meydan okuma dürüst aktarıcıların kaynakları israf etmesine neden olur; buna zincir üstü işlemler için gaz ücretlerine harcanan fonlar da dahildir. Sonuç olarak, dürüst aktarıcılar zincirler arası bilgileri aktarma teşvikini kaybedebilir ve bu da dürüst olmayan aktarıcıların zincirler arası bilgileri aktarması için bir fırsat yaratabilir. Meydan okuyanların asgari bir depozito yatırmasını zorunlu kılmak, kederlenmeyi önleyebilir, ancak yüksek bir asgari depozito dürüst gözlemcileri (sermayesi olmayanları) geçersiz durum güncellemelerine itiraz etmekten caydırabilir.

Bazı protokoller, meydan okumaları izin verilen bir gözlemci kümesiyle sınırlayarak bu sorunu aşar, ancak bu bizi bir sistemi güvence altına almak için küçük bir (güvenilir) katılımcı kümesine sahip olma orijinal sorununa geri götürür. Bu yaklaşım, gözlemci düğümleri arasındaki işbirliğine yönelik bariyeri azaltmak ve bir saldırganın sistemi izleyen düğümlerin çoğunu bozma şansını artırmak gibi birkaç beklenmeyen sonuç da üretebilir.

Kriptografik doğrulama

Zincirler arası birlikte çalışabilirlik protokollerini güvence altına almaya yönelik ele alacağımız son yaklaşım, kriptografik kanıtlar alanından gelir. Fikir basittir: Zincirler arası durumları doğrulamak için insanlara güvenmek yerine (önceki bölümlerde belirli durumlarda tehlikeli olduğu gösterilen), kriptografik doğrulama mekanizmalarını kullanabiliriz; böylece güven varsayımlarını en aza indirebiliriz.

Burada, bir veya daha fazla aktör, bir birlikte çalışabilirlik uygulaması içinde kullanılmak üzere bir zincirin (geçerli) durumunun SNARK (Öz Etkileşimsiz Bilgi Argümanı) kanıtlarını üretir. Bu kanıtlar doğrulanabilirdir : bir blok başlığından türetilen gibi bir zincirler arası durumun kriptografik kanıtını alabilir ve geçerliliğini onaylayabiliriz. Ayrıca etkileşimsizdirler : tek bir tarafça üretilen bir kanıt, iletişim kuracak kimse olmadan n farklı tarafça doğrulanabilir (etkileşimli dolandırıcılık kanıtlarının aksine). Bu şekilde tasarlanan birlikte çalışabilirlik protokolleri, altta yatan kanıt sistemi sağlam olduğu sürece (yani, bir saldırgan, ihmal edilebilir bir olasılık dışında, geçersiz iddialar için geçerli kanıtlar oluşturamaz) genellikle en düşük güven varsayımlarına sahiptir.

Bu tür protokoller, özellikle kriptografik kanıtların her bloğun bir zincirin fikir birliği protokolüne göre doğru olduğunu doğruladığı harici olarak doğrulanmış sistemlerden de farklıdır. Bu nedenle, bir saldırganın çapraz zincir durumunun kriptografik kanıtlarını kullanarak bir birlikte çalışabilirlik protokolünü bozmak için geçersiz blokları sonlandırmak için gereken kaynak zincirinin doğrulayıcı setinin büyük çoğunluğunu kontrol etmesi gerekir.

Bu yaklaşımın, daha önce tartışılan bazı zincirler arası güvenlik mekanizmalarıyla ilişkili bazı dezavantajları nasıl ortadan kaldırdığını görmek de kolaydır:

1. Sıfır sermaye verimsizliği : Zincirler arası durumları doğrulamak için zkSNARK'ların kullanımı, bir stake/bağlantı mekanizmasına olan ihtiyacı ve token'ları bir kilitleme süresine tabi tutmanın ilişkili verimsizliğini ortadan kaldırır. Benzer şekilde, aktarıcıların zincirler arası işlemler hakkında iddialarda bulunmadan önce bir bağ göndermeleri gerekmez (iyimser doğrulamanın aksine) çünkü eşlik eden kanıt iddiayı özlü bir şekilde doğrular.
2. Düşük gecikme : Bir gecikme süresi uygulamaya gerek kalmadan (zamanında dolandırıcılık kanıtlarını etkinleştirmek için) bir birlikte çalışabilirlik protokolü, onu güvence altına alan bir SNARK kanıtı doğrulandığında bir zincirler arası mesaj veya köprüleme işlemi yürütebilir. Bununla birlikte, kanıt oluşturma genellikle hesaplama yoğunluklu olduğundan, harici olarak doğrulanmış bir sistem, SNARK tabanlı bir birlikte çalışabilirlik protokolüne kıyasla daha verimli olabilir.

"Kriptografik olarak doğrulanmış" bir birlikte çalışabilirlik çözümünün güvenliğini değerlendirirken, zincirler arası durumlar hakkında hangi bilgilerin gerçekten kanıtlandığına ve doğrulandığına yakından bakmak önemlidir. Sıfır bilgi kanıtları, birçok protokolün protokollerinin altında yatan gerçek güven varsayımlarını gizlemek için tutunduğu bir moda sözcük haline geldi.

Örneğin, Ethereum doğrulayıcı kümesindeki tüm imzaları ( güncel rakamlara göre 925.000'den fazla doğrulayıcı ) bir zkSNARK devresinde doğrulamak pahalı olabileceğinden, bazı protokoller tarihsel olarak Ethereum'un durumunun kanıtlarını türetmek için başka yollar benimsemiştir. Bir örnek, blok başlıklarının Ethereum'un Senkronizasyon Komitesi'nin çoğunluğu tarafından imzalandığına dair bir kanıt üreten bir " Ethereum to X " köprüsüdür (burada X herhangi bir blok zinciri olabilir) (daha önce tanıttığımız).

Bu daha uygulanabilir bir yaklaşımdır (bir bloğu onaylayan binlerce doğrulayıcının açık anahtarlarını doğrulamaya kıyasla). Ancak daha önce açıklandığı gibi, Senkronizasyon Komitesindeki doğrulayıcılar yanlış blok başlıklarını imzalamak için kesilmezler; bu da Senkronizasyon Komitesi üyelerinin çoğunluğunun işbirliği yapma veya hafif istemcileri aldatmak için rüşvet alma ve bilgi için Senkronizasyon Komitesine güvenen köprülerin/mesajlaşma protokollerinin güvenliğini etkili bir şekilde tehlikeye atma olasılığını göz ardı edilemez hale getirir.

Ayrıca, Lagrange Eyalet Komiteleri'ni tanıtan orijinal makalede açıklandığı gibi, kötü niyetli Sync Komitesi'nin kesintiye uğramaya meyilli olduğu ideal bir dünyada, ekonomik güvenliğin maksimum kesintiye uğrayabilecek miktarda sınırlandırılacağını açıkladık. Bağlam için o gönderiden bazı alıntılar şunlardır:

Hafif istemci köprülerinin, ZK köprülerinin ve senkronizasyon komitesi kanıtlarının güvenliği, Ethereum hafif istemci senkronizasyon komitesinden gelen imzaların doğrulanmasına dayanır. Senkronizasyon komitesinin boyutu sabitlendiğinden, onu destekleyen ekonomik güvenlik de 27 saatlik bir pencerede sınırlandırılır. Slashing sonunda Ethereum senkronizasyon komiteleri için uygulandığında, ekonomik güvenlik aşağıdaki şekilde sınırlandırılacaktır:

• Sync Komitesinin ekonomik güvenliği = 512 düğüm * 32 Eth * 1650 USD/ETH = 27.033.600 ABD Doları
• Uzlaşma Eşiği Eşitleme Komitesi = 27.033.600 $ * 2/3 = 18.022.400 $

Hafif istemci köprüleri ve ZK hafif istemci köprüleri, zincirler arası birlikte çalışabilirlik için altın standart olarak düşünülürken, rastgele senkronizasyon komiteleriyle güvence altına alabilecekleri varlık miktarı ciddi şekilde sınırlıdır. Daha önce gösterildiği gibi, işbirliği yapan düğümlerin tüm Ethereum hafif istemci ve ZK hafif istemci köprülerini aynı anda tehlikeye atmak için yakması gereken teminat miktarı 18 milyon dolarla sınırlıdır.

Tüm hafif istemci ve ZK hafif istemci köprüleri tarafından güvence altına alınan tüm varlıkların toplam değerinin k miktarında olduğu bir durumu düşünün. k < 18 milyon dolar olduğunda, köprüler arasında güvence altına alınan tüm varlıklar güvenlidir, çünkü bir saldırı ekonomik olarak uygulanabilir değildir. k, k > 27 milyon dolar olacak şekilde büyüdüğünde, senkronizasyon komitesindeki bir grup kötü niyetli aktörün, güvence altına alınan varlıkları tehlikeye atmak için kötü niyetli blokları doğrulaması karlı hale gelir.

Çapraz zincir durumlarının kanıtlarını türetmek için rastgele senkronizasyon komitelerine güvenmek etrafındaki sorunlar hakkında daha fazla bağlam için, özellikle Ethereum'un hafif istemci köprülerinin sınırlamaları hakkındaki bölüm olmak üzere tüm makaleyi okumanızı öneririz. Ayrıca, Polyhedra Network'ün ZK devresinde tam Ethereum PoS konsensüsünü kanıtlama çabalarını takip etmenizi öneririz.

Lagrange Eyalet Komiteleri: Zincirler arası iletişim protokolleri için paylaşımlı güvenlik hizmeti

Bu makalenin girişinin büyük bir kısmı paylaşımlı güvenlik üzerine olduğundan, Lagrange Labs'da üzerinde çalıştığımız paylaşımlı bir güvenlik çözümünü tanıtmamız çok yerinde olur: Lagrange State Committees . Bu bölümde, Lagrange State Committee ağının iç işleyişini inceleyecek ve Lagrange'ın ZK Big Data yığınıyla bağlantısını ve zincirlerde ve zincirler arasında güvenli ve açıklayıcı durum erişimini sağlayan araçlar oluşturma amacını anlayacağız.

Lagrange Eyalet Komiteleri nelerdir?

Lagrange State Committee (LSC) ağı, Ethereum'da (örneğin Optimism, Arbitrum, Base ve Mantle) yerleşen iyimser toplamalar (ORU'lar) için basit ve etkili bir ZK hafif istemci protokolüdür. LSC'ler kavramsal olarak Ethereum'un Sync Committee'sine benzerdir ve aşırı güven varsayımları üstlenmeden iyimser bir toplamanın durumunu kullanmak isteyen köprüler ve zincirler arası mesaj katmanları gibi hafif istemci tabanlı uygulamaları destekler.

Lagrange State Committee, EigenLayer aracılığıyla Ethereum'da 32 ETH değerinde teminatı yeniden bahisleyen bir istemci düğümleri grubudur. Başka bir deyişle, bir Lagrange State Committee ağı bir AVS veya Aktif Olarak Doğrulanmış Hizmettir . Her Lagrange State Committee, ilişkili işlem grupları bir veri kullanılabilirliği (DA) katmanında sonlandırıldığında, belirli bir iyimser toplama için blokların kesinliğini onaylar. Bu onaylar daha sonra, uygulamaların belirli bir iyimser toplamanın durumu için bir gerçeklik kaynağı olarak ele alabileceği durum kanıtları oluşturmak için kullanılır.

Ethereum'un Sync Komitesi 512 düğümle sınırlıyken, her Lagrange State Committee ağı sınırsız bir düğüm kümesini destekler. Bu, ekonomik güvenliğin yapay olarak sınırlandırılmamasını ve iyimser bir roll-up'ın durumunu doğrulayan düğüm sayısının ölçeklenebilmesini sağlar, böylece Lagrange durumu kanıtlarının ardındaki ekonomik güvenliği dinamik olarak artırır.

Lagrange Eyalet Komitesi ağı nasıl çalışır?

Lagrange State Committee protokolünün iki temel bileşeni sıralayıcı ve istemci düğümleridir ("istemci düğümleri", Lagrange State Committee'ye kayıtlı doğrulayıcılar için kullanılan başka bir addır). Sıralayıcı, Lagrange State Committee ağındaki tasdikleri koordine etmekten ve durum kanıtları üreten kanıtlayıcılara tasdikleri sunmaktan sorumlu merkezi bir varlıktır. Sıralayıcı düğümü aslında farklı işlevlere sahip üç modülün birleşimidir: Sequencer , Consensus ve Governance .

Belirli aralıklarla, Sequencer modülü, bir DA katmanına yazılmış bir işlem grubunun yürütülmesinden kaynaklanan blokları toplamak için istemci düğümlerinden tasdikler ister. Bu rutini her iyimser toplama bloğu için yürütmek yerine, Aşağıda blok mesajındaki her bir öğenin kısa bir analizi verilmiştir:

(1). Block_header : Sonlandırılmış iyimser toplama (ORU) bloğunun başlığı. Buradaki "Sonuç", belirli bir DA katmanında sonlandırılmış işlem verilerinden toplama düğümleri tarafından türetilen bir blok anlamına gelir. Örneğin, son sonuç, Optimism/OP yığın toplamaları için güvenli L2 başlığı ve Arbitrum ve Arbitrum Orbit zincirleri için Ethereum eşdeğeri son sonuca sahip bir L2 bloğu tarafından tanımlanır. ( Bu makalede toplama son sonucu hakkında daha fazla bilgi edinin.)

(2). current_committee : Bir bloğu imzalamasına izin verilen istemci düğümleriyle ilişkili genel anahtar kümesine yönelik kriptografik bir taahhüt b. Bir istemci düğümünün, tüm etkin komite üyelerinin genel anahtarlarını temsil eden yapraklara sahip bir Merkle ağacı oluşturması ve Merkle ağacının kökünü BLS12–381 anahtarıyla imzalaması beklenir.

(3). next_committee : Bir sonraki bloğu imzalamaya izin verilen düğümlerle ilişkili genel anahtar kümesine yönelik kriptografik bir taahhüt (b+1). Bir durum komitesinden ayrılmak isteyen düğümler, onay süresinin sonunda, Devlet Komitesi AVS'deki operatörlerin kaydını ve kaydını silmeyi işleyen Ethereum üzerindeki Lagrange Service sözleşmesine bir işlem göndermelidir.

Her tasdik döneminin sonunda, operatörler bir sonraki tasdik dönemi başlamadan önce ayrılmayı veya katılmayı talep ederse komite düğümleri kümesi değiştirilebilir. İstemci düğümlerinin, Lagrange Hizmet Sözleşmesi'nden her komiteye kayıtlı geçerli düğüm kümesini alarak next_committee bir Merkle ağacını oluşturması beklenir.

ELI5: Devlet kanıtları nelerdir?

Bir durum kanıtı, bir blok zincirinin durumunun kriptografik kanıtıdır: bir kaynak zincirinden (zincir A) gelen bir blok başlığının kanıtı, hedef zincire kaynak zincirindeki bir durumun varlığını kanıtlamak için kullanılabilir, örneğin belirli bir işlem. Başka bir deyişle, bir durum kanıtı, kaynak zincirinin durumunun belirtilen bir blok yüksekliğindeki kanıtını temsil eder.

Önceki bir örneği kullanarak açıklamak gerekirse: Bob'un hedef zincirdeki (zincir B) uygulamasının Alice köprüleme işleminin varlığını doğrulamak için kullandığı kaynak zincirdeki (zincir A) blok başlığı bir durum kanıtıdır. Önceki blok ile geçerli blok arasındaki kaynak zincirin durumundaki değişikliklerin bir özetini temsil eder. Alice'in Merkle kanıtı, zincir A'nın blok başlığında saklanan işlem ağacı köküne karşı doğrulanırsa, Bob, durum kanıtı Alice'in mesaj isteğinin köken zincirde yürütülmesini doğruladığı için zincir B'deki (hedef zincir) köprüleme işlemini güvenle onaylayabilir.

Lagrange State Committee ağı, Ethereum tarafından güvence altına alınan iyimser toplamalar için durum kanıtları üretmek üzere tasarlanmıştır. Durum kanıtları, daha önce açıklanan tuple'daki ( block_header , prev_committee ve next_committee ) BL12–381 imzalarının, durum komitesindeki düğümlerin en az üçte ikisinden toplanmasıyla üretilir. Durum kanıtı daha sonra, belirli bir blok başlığını doğrulayan imzaların toplu ağırlığına dayalı bir SNARK devresi tarafından üretilir.

Onaylayanların mevcut ve sonraki durum komitelerine taahhütte bulunmalarını gerektiren yaklaşım, Ethereum Sync Committee protokolüne benzerdir ve benzer bir hedefe ulaşır: hafif istemcilerin iyimser bir toplama bloğu başlığının geçerliliğini verimli ve güvenli bir şekilde doğrulamasını sağlar. Her durum kanıtı, hangi düğümlerin bir sonraki bloğu imzalaması gerektiğini belirten bir dizi next_committee taahhüdü ile kriptografik olarak bağlantılıdır. Bu nedenle, onaylayan düğümler tarafından imzalanan blok nesnesinde aşağıdaki yinelemeli özellikleri kanıtlayan bir SNARK kanıtını doğrulamak yeterlidir:

• Eyalet komitesindeki n düğümün en az ⅔'ü b blok başlığını imzaladı.

• B bloğunun current_committee b-1 bloğunun next_committee ağacına eşittir.

• B-1 bloğu ya genesis bloğudur ya da bu üç koşul açısından geçerlidir.

  
  

Hızlı kesinlik ile güvenli iyimser toplama durumu gerektiren birlikte çalışabilirlik protokolleri ve diğer uygulamalar (örneğin, zincirler arası köprüler ve mesajlaşma protokolleri) Lagrange Durum Komitelerinden gelen durum kanıtlarını asgari güven varsayımlarıyla kullanabilir. Önemlisi, Lagrange Durum Komitesi ağı, kötü niyetli tanıkların kesin olarak kesilmesini ve tümevarımsal geçerlilik kanıtlarını uygulayarak durum kanıtlarının güvenliğini garanti edebilir.

Lagrange Eyalet Komitesi ağı ZK Büyük Veri Yığını ile nasıl etkileşim kuruyor?

Lagrange'ın ürün paketine ilişkin serinin ilk yazısında, ZK Büyük Veri Yığını'nın farklı bölümleri arasındaki ilişkiyi vurguladık: Lagrange Durum Komiteleri, Recproofs, zkMapReduce ve Lagrange Eş İşlemcisi. Bu bileşenlerin her biri, bir araya getirildiğinde, toplu olarak duruma güvenli, verimli erişim ve durum verilerinde ifade edici, dinamik hesaplama sağlar:

#1. Lagrange Eyalet Komitesi ağı, daha iyi performans için ZK Büyük Veri Yığını'nın diğer bileşenleriyle bütünleşir

Eyalet komiteleri için güncellenebilir toplu ortak anahtar (APK) kanıtları oluşturmak amacıyla Recproofs ve zkMapReduce kullanıyoruz. Bu sayede, yeni bir toplu imza oluşturulması gerektiğinde, imzalamayanların ortak anahtarlarını toplamayı kaldırma ve yeniden toplama gibi maliyetli ve zaman alıcı süreçlerden kaçınabiliyoruz.

Lagrange Eyalet Komiteleri'ndeki operatörlerin BLS genel anahtarlarının etkin bir şekilde toplanması AVS, eyalet komitesi düğümlerinden gelen tasdikleri doğrulamanın hesaplama maliyetini artırmadan AVS'de daha yüksek katılım oranlarına olanak tanır. Bu nedenle Lagrange Eyalet Komiteleri potansiyel olarak sınırsız bir düğüm kümesini destekleyebilir ve eyalet komitelerine daha fazla sermaye havuzlandığında süper doğrusal güvenlik sergileyebilir. Bu özellik hakkında daha fazla bilgiyi ZK Big Data ile EigenLayer'da programlanabilir güveni ölçeklendirme yazımızda bulabilirsiniz.

Lagrange Durum Komitelerini ZK Büyük Veri yığınıyla entegre etmek, Lagrange durum kanıtlarından yararlanan istemci uygulamaları için daha doğrudan faydalar da sağlar. Örneğin, Lagrange Eş İşlemcisinin zkMapReduce özelliğini kullanarak n iyimser toplama zincirinden gelen birden fazla durum kanıtını tek bir çok zincirli durum kanıtına birleştirebiliriz. Bu, tek bir zincir içi işlemin aynı anda birden fazla iyimser toplamanın durumunu doğruladığı ve istemci hizmetleri için doğrulama maliyetlerini azalttığı "iç içe doğrulama"ya olanak tanır.

#2: Lagrange Eş İşlemcisi, güvensiz zincir dışı hesaplamayı desteklemek için Lagrange Eyalet Komitesi ağıyla bütünleşir

Sonraki bir gönderide kapsamlı bir şekilde analiz edeceğimiz Lagrange Eş İşlemcisi, zincir dışı hesaplamalar gerçekleştirerek zincir üstü verilerde ucuz ve ölçeklenebilir hesaplamayı destekler. Lagrange Eyalet Komiteleri ile entegre olan zincirler arası birlikte çalışabilirlik protokolleri, çapraz zincir tekliflerini doğrulanabilir hesaplamayı içerecek şekilde genişletmeyi kolaylaştırmak için Lagrange Eş İşlemcisi ile de entegre olabilir.

Örneğin, çok zincirli bir kredi uygulaması oluşturan bir geliştirici, bir kullanıcı tarafından n farklı toplamada yatırılan teminatın toplamını hesaplamak isteyebilir. Dost canlısı geliştiricimiz, çapraz zincir protokolünün zaten dayandığı blok başlığı kaynağını kullanarak bu değeri hesaplamak için Lagrange Eş İşlemcisini kullanabilir.

Lagrange'ın Eyalet Komiteleri ağının iyimser toplamalarda birlikte çalışabilirlik açısından neden bir oyun değiştirici olduğu

İyimser rollup light istemcileri için paylaşımlı, süper doğrusal güvenlik

Şu anda, iyimser toplama zincirleri arasında köprülemeyi destekleyen birlikte çalışabilirlik protokolleri, kaynak zincirlerinin durumunu doğrulamaktan bağımsız olarak sorumludur. Bu birlikte çalışabilirlik protokollerinin güvenliği, bir blok başlığının doğru olduğunu doğrulama mekanizmasına bağlıdır.

Bazı zincirler arası iletişim protokolleri, yerel hisse senedi uygulayarak ve kaynak zincirlerinin blok başlıklarını onaylamadan önce bir dizi doğrulayıcıdan teminat bağlamasını isteyerek güven varsayımlarını azaltmaya çalışır. Ancak bu, her protokolün doğrulayıcı kümesinin bir alt kümesini ( n'nin k'si ) bozmanın maliyeti daha düşük olduğundan, farklı zincirler arası protokoller arasında ekonomik güvenliği parçalar.

Buna karşılık, Lagrange Eyalet Komiteleri, birden fazla çapraz zincir protokolünün, sınırsız bir boyuta ölçeklenebilen tek bir dinamik doğrulayıcı kümesinden güvenlik elde etmesine izin verir. Bu, her bir birlikte çalışabilirlik protokolünün çapraz zincir durumlarının doğruluğunu doğrulamaktan bağımsız olarak sorumlu olduğu statükoyu, birden fazla uygulamanın çapraz zincir durumunu tek bir kaynaktan tüketebildiği bir statükoya değiştirir.

Diğer hafif istemci protokollerinin aksine, Lagrange'ın State Committee ağı dinamik, sınırsız bir tasdik düğümleri kümesini destekler. Bu nedenle, her tasdiki güvence altına alan imzaların ekonomik ağırlığı, daha fazla hissenin state komitelerine toplanmasıyla dinamik olarak ölçeklenebilir; bu da güvenlikte süper doğrusal bir artışa olanak tanır ve entegre çapraz zincir protokollerine izole bir şekilde saldırmanın zorluğunu artırır.

Bu, Lagrange Eyalet Komitesi'ni etkili bir şekilde, herhangi bir çapraz zincir protokolünün (boyutundan bağımsız olarak) maksimum güvenlik için bağlanabileceği bir "paylaşılan güvenlik bölgesi" haline getirir; bu, Polkadot'taki Relay Chain ve Cosmos'taki Cosmos Hub'ın çoklu zincir ekosisteminde ikincil ağları nasıl güvence altına aldığına benzer. Ek olarak, EigenLayer'ın resttake ara yazılımıyla entegre olması, Lagrange Eyalet Komitesi ağının Ethereum'un ekonomik güvenliğini, keyfi sayıda alt akış çapraz zincir iletişim protokolünü güvence altına alacak şekilde genişletmesini sağlar.

Zincirler arası ürün geliştirme ekipleri için azaltılmış genel giderler

Günümüzde bir zincirler arası birlikte çalışabilirlik protokolü oluşturan bir geliştirici, destekledikleri her iyimser toplamanın durumunu doğrulamak için gözlemcileri bağımsız olarak çalıştırmak üzere bir altyapı geliştirmelidir. Entegre iyimser toplamaların sayısı arttıkça, her bir kaynak zincirinde güvenliği yönetmenin altyapı yükü artar.

Lagrange Durum Komitesi ile bütünleşmek, geliştiricinin güvenliğini dış kaynaklı hale getirmesine ve bunun yerine kaynaklarını ürün özelliklerini optimize etmeye odaklamasına olanak tanır. Bunu bağlama oturtmak için: Her Lagrange durum kanıtı, herhangi bir EVM uyumlu zincirde verimli bir şekilde doğrulanabilecek kadar hafiftir.

Mevcut birlikte çalışabilirlik protokolleri için ek güvenlik

Lagrange durum kanıtları, bunları bir veya daha fazla hedef zincire taşımak için kullanılan taşıma katmanına karşı duyarsızdır ve bu da birlikte çalışabilirlik uygulamalarının Lagrange durum kanıtlarını mevcut güvenlik mekanizmalarıyla sorunsuz bir şekilde istiflemesine olanak tanır. Örneğin, bağımsız bir doğrulayıcı kümesine sahip bir zincirler arası oracle veya zincirler arası mesajlaşma protokolü, iyimser toplamalardan gelen zincirler arası mesaj isteklerini iletmeden önce ek bir güvenlik önlemi olarak bir Lagrange durum kanıtını doğrulayabilir.

Ayrıca, mevcut bir birlikte çalışabilirlik protokolü—bir kez Lagrange State Committee ağıyla entegre edildiğinde—doğrulayıcıların izledikleri zincir sayısını artırmasını gerektirmeden iyimser toplamalar için destek ekleyebilir. Lagrange State Committee ağından gelen durum kanıtlarını kullanarak, doğrulayıcılar yalnızca toplamalar arasında mesaj isteklerini iletmek zorundadır. Hedef zincirdeki bir ağ geçidi sözleşmesi daha sonra bir Lagrange durum kanıtını doğrulayarak ileticilerin ilettiği mesajların varlığını doğrulayabilir.

Lagrange Eyalet Komitesi ağı diğer zincirler arası güvenlik mekanizmalarıyla karşılaştırıldığında nasıldır?

Lagrange Eyalet Komiteleri, çapraz zincir durum kanıtlarının güvenliğini artırmak için bonded staking/slashing, izinli doğrulama ve iyimser doğrulama mekanizmalarını (diğerlerinin yanı sıra) kullanan mevcut birlikte çalışabilirlik altyapısıyla olumlu bir şekilde karşılaştırılır. Aşağıda bazı karşılaştırmalar verilmiştir:

İzinsiz doğrulayıcılar tarafından harici doğrulama

Lagrange'ın yeniden bahis modeli, güvenlik için saf PoS bahisi uygulayan çapraz zincir güvenlik mekanizmalarındaki temel bir sorunu hafifletir: risk istifleme . Örneğin, doğrulayıcıların bağlanma süresi boyunca bir protokolün yerel token'ını satın almasını ve kilitlemesini gerektiren bir çapraz zincir protokolünü ele alalım. Çapraz zincir protokolünün yerel token'ının popülaritesi değiştikçe, varlığın fiyatının oynaklığı ağın toplam ekonomik güvenliğini etkiler.

Fiyat oynaklığı, Lagrange State Committee ağı için daha az sorun teşkil eder çünkü komite düğümlerinin güvenliği EigenLayer aracılığıyla yeniden bahis edilen teminata dayanır. Ayrıca, yeniden bahis edilen teminat, olası doğrulayıcılar için fırsat maliyetlerini düşürmüştür, bu da eyalet komitelerine daha fazla katılım ve birlikte çalışabilirlik protokolleri için daha yüksek düzeyde ekonomik güvenlik anlamına gelir. Kullanıcılar için bu, güvenliklerini bağımsız olarak başlatan birlikte çalışabilirlik protokollerine kıyasla daha düşük ücretler ve daha fazla güvenlik anlamına gelir.

Ayrıca, geleneksel Proof-of-Stake'te kullanılan konsensüs protokollerinin doğrulayıcı sayısına sınırlamalar getirdiğini (örneğin, Tendermint BFT katılımı 100-200 doğrulayıcıyla sınırlar) ve geleneksel PoS protokollerinin ekonomik güvenliği gerektiği kadar sık ölçeklemesini engellediğini de not ediyoruz. Tersine, Lagrange State Committee ağı, konsensüse katılan potansiyel olarak sınırsız bir düğüm kümesini destekleyen bir tasdik mekanizması kullanır. Bu, ağın tasdikçi sayısını dinamik olarak artırabilmesini ve dolayısıyla istemci uygulamaları için daha sağlam ekonomik güvenlik garantileri sağlayabilmesini sağlar.

İzinli doğrulayıcılar tarafından harici doğrulama

Yetki Kanıtı (PoA) tabanlı çapraz zincir protokolleri, izin verilen küçük bir düğüm kümesinden başlıkları engellemek için tasdiklere güvenir. Bu yaklaşımlar tarihsel olarak Ronin saldırısı (7 doğrulayıcıdan 5'i tehlikeye girdi) ve Harmony One köprü saldırısı (5 doğrulayıcıdan 2'si tehlikeye girdi) gibi yüksek profilli olaylarla güvensiz olduğu kanıtlanmıştır.

Lagrange State Committee ağı gibi izinsiz doğrulanmış bir sistem kullanmak, merkezi bir operatör veya doğrulayıcı set imzalama başlıklarına kıyasla verimliliği bir miktar azaltır. Ancak risk altındaki miktar göz önüne alındığında, bunu mantıklı bir takas olarak görüyoruz. İzinsiz doğrulanmış sistemler ayrıca, çoğunlukla izinli bir sistemde doğrulayıcıların çoğunu çalıştıran şirketler için saldırı yüzeyini azaltır.

Kanonik köprüleme

Lagrange State Committee ağı, iyimser toplamalardan zincirler arası mesaj göndermenin gecikmesini ortadan kaldırır. Her LSC, kullanıcıları meydan okuma penceresini beklemeden iyimser bir toplamadan köprü kurmak isteyen köprüler ve mesajlaşma protokolleri için bir "hızlı mod" görevi görür. İyimser toplamalar ayrıca L2 kullanıcıları için önemli bir UX sorun noktasını çözdüğü için LSC'nin hızlı kesinlik özelliğinden doğrudan yararlanır.

Bu garanti, şu gözlemden kaynaklanmaktadır: (a) kesme mekanizması, düşmanca eylemlerin maliyetini artırmak için tasarlanmıştır ve (b) bir LSC'deki işbirliği yapan düğümlerin kesilmesi, hisse senedinin çekilmesinde değişken zaman gecikmesi olduğundan zincir üzerinde yavaş modda gerçekleşebilir. Özetle, bir LSC'deki katılımcılar her zaman çapraz zincir durumlarını düzeltmeye dair onay verme teşvikine sahiptir; bu da çapraz zincir uygulamalarının bir LSC'den durum kanıtlarını hemen ve toplamanın kanonik köprüsü tarafından desteklenen asgari güven varsayımlarıyla kullanmasını sağlar.

Çözüm

Bu makale oldukça fazla alanı kapsıyor ve okumanın, inşaatçılar, yatırımcılar, meraklılar ve birlikte çalışabilirlik alanındaki kullanıcılar için eğitici (eğer değerli değilse) olduğunu umuyoruz. Bu makale boyunca, paylaşılan güvenliğin tanımını, güvenli protokoller tasarlamak için ne anlama geldiğini ve zincirler arası birlikte çalışabilirliğin paylaşılan güvenlik altyapısıyla entegre olmaktan nasıl faydalanabileceğini inceledik.

Ayrıca, zincirler arası iletişim protokollerini göz önünde bulundurarak tasarlanmış paylaşımlı güvenlik-hizmet-olarak çözümümüz olan Lagrange State Committees'i de inceledik. Lagrange State Committees, güvenli, güveni en aza indirilmiş ve verimli birlikte çalışabilirliği etkinleştirme vizyonumuzun bir parçasıdır ve geliştiricilerin kullanıcılar için güçlü zincirler arası uygulamalar oluşturmasını sağlayan daha büyük bir yığının parçası olacaktır.

Çoklu zincir geleceği kaçınılmazdır ve kullanıcıların önemli bir güvenlik kaybı yaşamadan bir zincirden 10.000'lerce zincire geçebilmesi önemlidir. Lagrange State Komiteleri (zincirler arası güvenlikteki diğer gelişmelerle birlikte) gibi çözümler bu hedef için kritik öneme sahiptir. Birlikte çalışabilirliğin her zamankinden daha fazla ilgi görmesiyle, zincirler arasında hareket etmenin güvenli ve verimli olduğu bir dünya, dünyanın dört bir yanındaki kripto kullanıcılarının ulaşabileceği bir mesafededir.

Teşekkürler

Emmanuel Awosika ( 2077 Research ), Omar Yehia ( Lagrange Labs ), Ismael Hishon-Rezaizadeh ( Lagrange Labs ) ve Amir Rezaizadeh ( Lagrange Labs ) bu makaleye katkıda bulundu. Emmanuel, bu makalenin yazılmasını desteklemek için Lagrange Labs ile sözleşme imzaladı.

Bu makalenin bir versiyonu daha önce burada yayınlanmıştı.