Demek turuncu hap aldınız ve şimdi BTC tutuyorsunuz. Aferin sana, geç olması hiç olmamasından iyidir.
Sonra, bu sektörün kutsal atasözünü duydunuz: ne anahtarlarınız, ne de coin'leriniz. Çeşitli CEX halılarının ve hack'lerinin dehşetiyle birleşince, sonunda bitcoinlerinizi kendiniz saklamaya karar verdiniz.
Tebrikler, artık kendi finansal kaderinizden siz sorumlusunuz. Yaşasın, değil mi?
Bitcoin'de işlem yapmanın aptalca maliyetli olduğunu, Ethereum'un kötü şöhretli yüksek gaz ücretlerini utandıracak kadar pahalı olduğunu fark ediyorsunuz. Çünkü o lanet balinaların aksine, harcayacak 1 milyon dolar değerinde bitcoininiz yok - ana zincirde yaptığınız her işlem sizi zorlayacak.
Şimdi ne olacak? Elbette daha iyi bir yolu olmalı.
Yuvadan ayrılmak
Bitcoin'i (BTC, kripto para birimi) Bitcoin'in (ana zincir, blok zinciri) dışında tuttuğunuzda, ana zincirin güvenlik ve korumasına sahip olmayacaksınız, bu nedenle hangi zincir veya katmanda olursanız olun güven varsayımlarını ve (varsa) sahip olduğunuz BTC temsili belirtecini devralmanızı gerektirecektir.
Ne yazık ki bu, şimdilik yapmanız gereken iBitnevitable değiş tokuşudur.
Bu makale, piyasada bulunan çeşitli ölçeklendirme yaklaşımları ve köprüleri hakkında genel bir bakış sunmanın yanı sıra, her biri için katlanmanız gereken güven fedakarlıklarını özetlemeyi amaçlayacaktır. Buna ek olarak, her birinin eksikliklerini ve neden hala ana zincirinin güvenliğinden ve korumasından kullanıcıları önemli ölçüde ödün vermeden BTC'yi "ihraç edebilen" uygun bir Bitcoin ölçeklendirme çözümü olmadığını ortaya koyacağız.
Bitcoin ve ana zincir terimleri baştan sona birbirlerinin yerine kullanılacaktır. Hadi başlayalım.
Yıldırım Ağı
Ocak 2018'de başlatılan Lightning Network, Bitcoin'i ölçeklendirmek için yapılan en erken girişimlerden birini sunmaktadır. Lightning Network, özünde bir ödeme kanalları ağından oluşmakta olup, her bir ödeme kanalı temelde Bitcoin'deki iki taraf arasında 2'ye 2 çoklu sözleşme ( HTLC'lerden yararlanan) niteliğindedir.
Lightning Network'ün çalışmasını sağlayan şey, bitcoinlerinizi göndermek istediğiniz eşle bağlantıyı sürdüren birden fazla ödeme kanalının bulunmasıdır. Bu nedenle, Bob ile doğrudan bir bağlantınız olmasa bile, Alice ile bir bağlantınız olduğu sürece (Bob ile bir bağlantısı olan), Lightning düğümünüzden ödeme başlatabilir ve Alice aracılığıyla Bob'a ödeme yapabilirsiniz.
Teorik olarak, karşı tarafınız en az bir ortak eş paylaştığı sürece (yeterli likiditeye sahip) herkesle işlem yapabilirsiniz. Dolayısıyla, Lightning Network'teki "ağ".
tldr
Bob Alice ile bir ödeme kanalı açmak istediğinde, anahtarlarını birleştirerek kanalın adresi olarak işlev görecek 2'ye 2 multisig sözleşmesi oluştururlar. Ardından, Bob iki işlem yayınlar: taahhüt işlemi (Alice yanıt vermezse fonlarını fonlama cüzdanına geri harcamak için) ve fonlama işlemi (Bob bitcoinlerini 2-of-2 multisig'e yatırır). Aynı şekilde Alice de taahhüt işlemini ve fonlama işlemini yayınlar. Herhangi biri ödeme kanalına para yatırmadan önce ilk taahhüt işleminin her iki tarafça da imzalanmasının önemli olduğunu unutmayın. Bu, taraflardan birinin çevrimdışı olması durumunda fonların multisig'de sıkışıp kalmamasını sağlamak içindir.
Ödeme kanalı kurulduktan sonra, Bob ve Alice multisig içindeki bitcoinleri istedikleri kadar ve uygun gördükleri şekilde harcamakta özgürdür. Fonları "gönderdiğinizde", aslında diğer tarafla sahip olduğunuz paylaşılan taahhüt işlemini en son bakiye durumunu yansıtacak şekilde güncellersiniz ve önceki taahhüdü geçersiz kılarsınız. Taahhüt işlemi, ödeme kanalı hala canlı iken asla zincir üzerinde gönderilmez ve yalnızca Bob ve Alice tarafından bilinir. Taahhüt işlemi yalnızca ödeme kanalı kapatıldığında yayınlanır.
Bob bir kanalı kapatmak (ve bitcoinlerini ana zincire geri almak) istediğinde, bunu yapmanın iki yolu vardır: Alice ile işbirliği yaparak ya da işbirliği yapmadan (diğer bir deyişle zorla kapatma). İşbirliğine dayalı kapatmada (mutlu yol), hem Bob hem de Alice multisig'deki bakiye payları üzerinde anlaşır ve her ikisi de fonları derhal kendi cüzdanlarına geri harcayan yeni bir işlem imzalar.
Ancak, kapatmaya zorlama senaryosunda (mutsuz yol), Bob ya da Alice kapatma işlemini işbirliği içinde imzalamak için uygun olmayabilir ya da isteksiz olabilir. Bu durumda, kapatmaya zorlamayı başlatan taraf bakiyesini bir tahkim sözleşmesine harcayacak ve eşinin CSV gecikmesi (diğer adıyla anlaşmazlık süresi) içinde buna itiraz etmesine izin verecektir. Bu tarafın "hile" yapmaya kalkışması (daha eski bir taahhüt işlemi yayınlaması) durumunda, eşleri sadece en son taahhüt işlemini yayınlar ve hile yapan tarafın fonlarını tahkim sözleşmesinden kendileri için talep eder.
[lightning.engineering] resimli: Bob'un başarısız 8 BTC'lik zorla kapatma iddiası
Örnek vermek gerekirse, Bob ve Alice'in "gerçek" bakiyelerinin sırasıyla 4 BTC ve 6 BTC olduğunu varsayalım (ödeme kanalında toplam 10 bitcoin bulunmaktadır). Bob zorla kapatmayı başlatır ve ödeme kanalında 8 BTC'si olduğunu iddia ederse (daha eski bir taahhüt işlemi yayınlayarak), Alice en son taahhüt işlemini yayınlayabilir ve Bob'un 8 BTC'sini tahkim sözleşmesinden talep edebilir. Bu, Bob için caydırıcı bir unsur olacak ve tarafların bir Lightning kanalı açarken birbirlerine güvenmelerine gerek kalmamasını sağlayacaktır.
düğümünüz değil, paralarınız değil.
Lightning Network ile ilgili olan şey, kendi Lightning düğümünüzü çalıştırmadığınız sürece kendi kendinize saklama yapamamanızdır. Aksi takdirde, ağı kullanmak için BTC'nizi güvenilir bir Lightning düğümüne yatırmanız gerekir; burada bitcoinleriniz kendi iç defterlerinin bir parçasını oluşturur ve sizin adınıza işlem yaparlar. Yatırdığınız parayı tutan Lightning düğümü hata verirse, BTC'niz de onlarla birlikte kaçar ve hiçbir başvurunuz olmaz. Bu temelde bitcoinlerinizi güvenilir bir CEX'e yatırmaktan daha kötüdür - yani, en azından Binance veya Coinbase ile işlem yapıyorsunuz!
Kendi Lightning düğümünüzü çalıştırmaya karar verirseniz, eşlerinizden gelen kanal ihlallerini izlemek için sürekli çevrimiçi olmanız gerekir. İhlalleri izlemenize yardımcı olması için Watchtower düğümlerini atayabilseniz de (sizin adınıza hileli zorla kapatmalara itiraz etmek için ödeme kanalında yaptığınız her işlemde oluşturulan taahhütlerinizi saklayacaklardır), esasen merkezi varlıklara güvenmeye geri dönersiniz. Yine, bitcoinlerinizi korumak için rastgele bir gözetleme kulesi şirketi yerine Binance veya Coinbase'e de güvenebilirsiniz!
[Sam Aiken] resimli: LN gözetleme kulesi iş başında
Yukarıdakiler sizi caydırmak için yeterli değilmiş gibi, kendi Lightning node'unuzu çalıştırıyorsanız, kendi node'unuzun likiditesini eşlerinize göre manuel olarak yönetmeniz gerekir. Örneğin, bir ödeme kanalının toplamda yalnızca 10 BTC'si varsa, tarafların birbirleri arasında tutabilecekleri maksimum bakiye 10 BTC'dir. Bununla birlikte, birden fazla eşle bağlantınız olabileceği gerçeğine rağmen (birçok farklı tarafa ödeme yapmanız muhtemel olduğundan) - doğrudan bağlantınız olmayan biriyle işlem yapmak istiyorsanız, hem sizinle hem de karşı tarafınızla bağlantısı olan ve ayrıca ödemeyi yönlendirmek için yeterli likiditeye sahip diğer Lightning düğümlerine güvenmeniz gerekir. Artık likidite yönetiminin ortalama bir node işletmecisi için neden çok zahmetli olduğunu anlayabilirsiniz.
Bu nedenle, çoğu Lightning düğümü bunu basitçe ortadan kaldırır ve ödemeleri yönlendirmeye adanmış iyi sermayeli Lightning düğümleri (büyük olasılıkla büyük kurumlar tarafından işletilen) olan yönlendirme düğümlerine bağlanır. Lightning düğümleri arasında bir aracı kanal olarak yer alırlar ve ağ genelinde ödemelerin yarı eşleştiricisi olarak hareket ederler. Sonuç olarak, ağ bu konuda merkezileşme eğilimindedir - bu yazının yazıldığı sırada, ilk 10 Lightning düğümü ağın tüm kapasitesinin >%75'ini oluşturmaktadır!
[LnRouter.app] kapasiteye göre filtrelenmiş aktif Lightning Düğümleri
ACINQ tarafından geliştirilen Phoenix Wallet, ortalama bir kullanıcı için Lightning Network'te kendi kendini saklamayı basitleştirme girişimidir. Cüzdan uygulamasını indirdiğinizde, telefonunuz otomatik olarak kendi Lightning düğümünüz haline gelir. Likidite yönetimini ve ödeme yönlendirmesini basitleştirmek için Lightning düğümünüz ACINQ düğümüne bağlanacak ve ACINQ'yu gelen ve giden ödemeleriniz için bir yönlendirici olarak kullanacaktır.
Bununla birlikte, yine de periyodik olarak çevrimiçi olmanız ve ihlalleri izlemeniz gerekir - aksi takdirde, hala ACINQ'nun insafına kalırsınız. Her ne kadar olası olmasa da, ACINQ'nun kanalınızı eski bir taahhütle kapatmaya çalıştığını varsayarsak, buna itiraz etmek için çevrimiçi olmanız ve doğru en son taahhüdü sunmanız gerekir. Aksi takdirde, fonlarınızı ACINQ'ya kaybedersiniz.
Sonuç
Lightning Network, node çalıştıranlar için tasarlanmıştır. Ancak gerçek dünyada, herkesin kendi node'unu çalıştırması gerekmez - bu gerçekçi veya pratik değildir.
Ne yazık ki, Lightning Network hiçbir zaman ortalama bir inek olmayan BTC sahibi için tasarlanmamıştır. Yalnızca kendi kendinizin velayeti altında kalmak için bir node çalıştırmanız gerektiği gerçeği, kesinlikle bir ödeme ağı olma konusundaki kısıtlayıcı kullanım durumuyla birleştiğinde (DeFi gibi daha zengin kullanım durumlarının kilidini yerel olarak açmak için programlanamaz), protokolü kendi node'unu çalıştıran gerçek Bitcoiner'ın sınırlarına indirgiyor.
Düğümünüz değil, paralarınız değil. Ve ortalama bir kullanıcı için ideal değildir.
Statechains
Bir konsept olarak Statechains, Lightning'in ödeme kanallarından büyük ölçüde ödünç alır; her ikisi de, sonunda Bitcoin'de kapanışında "kapatılacak" sınırsız zincir dışı işlemlere olanak tanır.
tldr
Lightning kanallarının (2'ye 2 multisig olan) aksine, bir statechain'in UTXO yatırma adresi, hem kendileri hem de UTXO'nun mevcut sahibi için anahtar payları oluşturan güvenilir bir varlık olan operatör tarafından tamamen zincir dışı olarak oluşturulur. Bir statechain başlatmak isteyen UTXO sahibi, ilgili açık anahtarın hem ilk sahibinden hem de operatörün anahtar paylarından oluşturulduğu bir adres oluşturmak için operatörle (güvenilir varlık) işbirliği yapar. Buradan, sahip UTXO (veya bitcoinler) ile statechain'i fonlar, ardından (operatörün işbirliği ile) bir yedek işlem oluşturur, bu işlem sahibinin UTXO'sunu süresi dolduğunda tek taraflı olarak geri talep etmesine olanak tanıyan bir zaman kilididir.
[Nik/Coinmonks] Statechains iş başında: UTXO sahipliğinin Alice'ten Bob'a aktarılması
Mevcut mal sahibi UTXO'nun mülkiyetini yeni bir mal sahibine devretmek isterse, operatör sadece aynı depozito adresine karşılık gelen anahtar paylarını yeniden oluşturacak ve eski mal sahibiyle olan anahtar payını silecektir. Ardından, yeni sahip (operatörün işbirliğiyle) ancak daha kısa bir zaman kilidiyle yedek bir işlem oluşturur. Bir durum zinciri her el değiştirdiğinde, operatör önceki anahtar payını siler ve yeni sahibin önceki sahibinden daha kısa bir zaman kilidine sahip olacak yedek işlemini imzalar, yani zaman kilidi daha fazla kısaltılamayana kadar (bu da yeni sahip için yeni bir durum zinciri oluşturulmasını gerektirir).
Bu şekilde, eski sahip yeni sahibin yerine tek taraflı olarak statechain'den fon çekemez. Çünkü durum zincirinden işbirliği içinde çıkmak için (anında para çekme), eski sahibin operatörün çıkış işlemini birlikte imzalamasına ihtiyacı vardır (operatör, işlemi birlikte imzalayabilecek önceki anahtar paylaşımını sildiği için artık bunu yapamaz), aksi takdirde eski sahibin yedek işlemini göndermeden önce zaman kilidinin sona ermesini beklemesi gerekir. Bununla birlikte, yeni sahip durum zincirinden çıkmak istediğinde operatör çevrimdışı olsa bile, yedek işlemi daha kısa bir zaman kilidine sahip olduğundan, her zaman yedek işlemini gönderebilir ve eski sahibinden önce fonları talep edebilir.
operatöre güveniyoruz
Sanki yeterince açık değilmiş gibi, operatör durum zincirleri için tek başarısızlık noktasıdır. Yeni sahiplerin, operatörün önceki anahtar paylarını gerçekten sildiğine ve önceki sahip için işbirliği yaparak fon talep etmeyeceğine güvenmesi gerekir. Operatörün sunucusu temelde bir web2 kapalı kutusu olduğundan, yeni sahibin operatörün önceki anahtar paylaşımının silindiğini doğrulamasının bir yolu yoktur (yani operatörün kendisi olmadıkça).
Bir statechain projesi olan Mercury Layer, bu güven faktörünü ortadan kaldırmayı amaçlamaktadır. Schnorr'un körleştirilmiş bir varyantını kullanan Mercury operatörü, Bitcoin zincirinin kendisinden haberdar değildir. Dolayısıyla, operatörün hangi para yatırma adresi için ortak imza attığı, yedekleme işlemlerinin ayrıntıları ya da ürettikleri imzalar hakkında hiçbir fikri yoktur. Aynı operatörün birden fazla durum zincirini yönettiğini varsayarsak, Mercury kendisine gelen her ortak imza talebini, imzanın neyi mümkün kılacağı hakkında hiçbir bilgisi olmadan körlemesine imzalayacaktır. Bu, operatörün seçici gizli anlaşmasını önler ve kötü niyetli olmak için hiçbir teşvikleri olmadığından (kör imzalama nedeniyle neyin risk altında olduğunu bilmezler) anahtar oluşturma ve imzalama işlemlerinin kendi sunucularında doğru yapılmasını sağlar.
[Ruben Somsen] operatör kör mesajları imzalıyor - bunların Bitcoin işlemleri mi yoksa tamamen başka bir şey mi olduğunu bilmiyor.
Ancak Mercury'nin çabalarına rağmen, statechain'ler temelde ciddi ölçüde sınırlı kalmaktadır. Durum zincirleri özünde Lightning Network gibi UTXO transferlerini kolaylaştırmak yerine sadece bir adres sahipliği transfer protokolü olduğundan, yalnızca durum zincirine yatırdığınız BTC miktarını "gönderebilirsiniz". Ayrıca, operatörün çevrimdışı olması durumunda, tüm "gönderimler" durdurulacak ve paranızı bir yedekleme işlemi yoluyla Bitcoin'e geri talep edebilmeniz için uzun zaman kilidinizin sona ermesini beklemeniz gerekecektir.
Sonuç
Durum zincirleri, UTXO'ların Bitcoin'in maliyeti ve sınırlamaları üzerinden aktarılması için akıllıca bir "hack" sunsa da, farklı miktarlardaki büyük ölçekli yüksek frekanslı UTXO transferleri için uygun değildir. Bu bağlamda, durum zincirleri Lightning Network'ten bile daha kısıtlayıcıdır - yalnızca durum zincirini finanse ettiğiniz UTXO'yu tam olarak aktarabilmenin yanı sıra, ödemeler dışında daha zengin kullanım durumlarının (örneğin DeFi) kilidini açmanızı engelleyen aynı programlanabilirlik eksikliğiyle de mücadele etmeniz gerekir.
Her şey söylendiğinde ve yapıldığında, statechains tam olarak budur - "hacky" güven minimize edilmiş adres sahipliği transfer protokolü. Yani, en azından Lightning düğüm koşucuları için gerçekten çalışıyor!
Statechains - geliştiriciler için eğlenceli, diğer herkes için o kadar da eğlenceli değil.
Saklama BTC'si
Saklama amaçlı BTC çözümleri (OG'ler tarafından "bitbank" olarak adlandırılır), "gerçek" Bitcoin kullanıcıları için ideolojik bir tokat olmasına rağmen, ortalama bir kullanıcının bitcoinlerini ucuz, hızlı ve makul ölçüde güvenli bir şekilde işlemesi için en güvenli (ve aynı zamanda en uygun) yollardan biri olmaya devam etmektedir.
Güvenilir BTC emanetçileri çoğunlukla en eski kripto kurumları arasında yer alır ve sektörde ve hatta TradFi'de büyük saygı görür.
tldr
Oldukça açıklayıcı olan saklama amaçlı BTC çözümleri, genellikle mevduat sahipleri tarafından kendilerine yatırılan tüm bitcoinler için bir saklama görevlisi olarak hareket edecek kadar güvenilen saygın kuruluşları içerir. Daha sonra, farklı zincirlerde (ve ortamlarda) temsili tokenlar basarlar ve her bir birim, emanetçi tarafından yedekte tutulan bitcoin miktarı ile 1:1 oranında desteklenir (teoride).
Bitcoin'den daha ucuz ve daha hızlı bir zincir üzerinde yaşadıklarından, BTC'yi temsil eden bu tokenlar (ör. wBTC, cbBTC, vb.) sahiplerinin DeFi'de kullanmasına, BTC cinsinden getiri elde etmesine ve birbirleriyle çok daha hızlı ve daha ucuz bir yürütme ortamında işlem yapmasına olanak tanır.
güvendiğimiz emanetçiye
[BitGo] BitGo: wBTC'nin güvenilir emanetçisi
Saklama amaçlı BTC çözümlerinin kullanıcıları, ellerinde tuttukları BTC temsili token'ın saklayıcısına tam güven duymalıdır. Farklı saklama kuruluşları, sahibinin bakış açısına göre farklı seviyelerde risk taşıyacaktır.
Örneğin, bir kullanıcı tarihsel geçmişe, borsa likiditesine ve OG'liğe değer veren biriyse BitGo'nun wBTC'sini kullanmaya daha meyilli olacaktır. Aynı şekilde, spektrumun diğer tarafındaki insanlar, açık düzenlemelere, şeffaflığa ve Amerikan yargı sürecine ve hukukun üstünlüğüne saygıya daha fazla önem veren biriyse Coinbase'in cbBTC'sini tutmayı tercih edebilir. Bu, bir kişinin seçtiği sabit coin için Tether'in USDT'si veya Circle'ın USDC'si arasında karar verme konusundaki düşüncelerine benzer - ya da sadece ikisini de tutarsınız!
Sonuç
Saklama amaçlı BTC çözümleri halihazırda, aksi takdirde kendi kendini saklayamayacak olan BTC kullanıcıları için faydalı bir köprü görevi görse de, en iyi ihtimalle geçici bir çözüm olarak kalmaktadır.
wBTC tuttuğunuzda, BitGo'ya tıpkı bir CEX'e para yatırdığınızda ona güvendiğiniz gibi güvenmiş olursunuz. Aynı durum Coinbase'in cbBTC'si, Binance'in BBTC'si ve diğer birçok BTC saklama kuruluşu için de geçerlidir.
Gevşek bir güvenlik önlemi ve güçlü Lazarus ile bir karşılaşma (umarım olmaz) ve Kim'in nükleer silahlarını finanse etmek için bitcoinleriniz gider!
Federated BTC
wBTC'yi hayal edin, ancak yalnızca BitGo'nun emanetçi olması yerine Wintermute, ChorusOne ve diğer kurumların da partiye katıldığını ve krallığın anahtarlarını verdiğini düşünün.
Bir bekçiden daha iyi ne olabilir ki? Bir sürü!
tldr
Federe BTC köprüleri esasen kolektif bir saklama BTC köprüsüdür. Bunlar, aralarında tutulan yatırılmış bitcoinler üzerindeki işlemleri yetkilendirmek için çoğunluğun gerekli olduğu bir imzalayıcı seti oluşturan birden fazla saygın kuruluşu içerir.
Buradaki fikir, saklama amaçlı BTC çözümlerinde mevcut olan tek hata noktası riskini ortadan kaldırmaktır. Tıpkı birikimlerinizin büyük kısmını kendiniz saklamak için EOA yerine multisig cüzdan kullanmanız gibi, buradaki fikir de imzalama ayrıcalıklarını birden fazla güvenilir kuruluşa yayarak her bir imzalayan kişiye daha az güvenebilmenizdir.
Bu nedenle, federe bir BTC kurulumunu tehlikeye atmak (ve içinde depolanan bitcoinleri çalmak) için, saldırganın imzalayan kümesinin bir parçası olan varlıkların çoğunu tehlikeye atması gerekir. Coinbase'i tehlikeye atmak zordur. Ancak Coinbase, OKX, Wintermute ve Fireblocks'u fark edilmeden tehlikeye atmak, herhangi bir potansiyel saldırgan için oldukça iddialı bir girişimdir.
multisigs ve MPC'ler
Basitleştirmek gerekirse, federe bir BTC kurulumunda imzalama ayrıcalıklarını dağıtmanın başlıca iki yolu vardır - multisig (çoklu imza) ve/veya MPC (çok partili hesaplama) yapıları aracılığıyla. Her biri için uygulama detaylarına girmeyeceğim ( çok fazla), ancak ana fikir multisig'de "paylaşılan" adresin zincir üzerinde üretildiği ve her imzalayanın tam bağımsız bir özel anahtara sahip olduğudur. Bu, paylaşılan adresten bir işlem imzalayanlar tarafından toplu olarak imzalandığında, imzanın zincir üzerinde kaydedildiği anlamına gelir.
MPC ile "paylaşılan" adres zincir dışında oluşturulur ve her imzalayan kısmi bir anahtar payına sahiptir. Zincir üzerindeki bir işlemi imzalarken, imzalayanlar anahtar paylarını birleştirerek ortaklaşa bir imza hesaplar. Blok zincirinin perspektifinden bakıldığında, imza tek bir imzacıdan gelen standart bir imza gibi görünürken, aslında MPC yapısının bir parçası olan imzacı seti tarafından zincir dışında toplu olarak oluşturulur.
Elbette, her bir yaklaşım arasında nüanslar ve ödünleşimler vardır. Bunları detaylandırmak bu makalenin kapsamının çok dışında olsa da, detaylara dalmak isteyen bir inek olmanız durumunda Fireblocks'un bu MPC vs. Multi-sig primerini okumanızı tavsiye ederim.
federasyona güveni̇yoruz
Teorik olarak, tüm bunlar kulağa çok güvenli geliyor. Her birinin kendi itibarı söz konusu olan en iyi kripto kurumlarına sahipsiniz ve federasyon BTC köprüsünü ortaklaşa koruyorsunuz. Ne yanlış gidebilir ki?
Gördüğünüz gibi, daha az güven, hiç güven olmaması anlamına gelmez. Federe bir BTC köprüsünde imzalayıcı seçimi büyük önem taşır. Federasyonun yeterli sayıda imzalayan içermesi, güvenli bir çoğunluk eşiğine sahip olması (en az üçte iki) ve coğrafi olarak yeterince dağılmış olması gerekir. Her bir imzacının korumaya istekli oldukları yeterince iyi bir itibara sahip olması ve federe köprünün başarısı üzerinde çıkar sahibi olması gerektiğinden bahsetmiyorum bile.
Benim için, şu anda canlı olan en az bir federe BTC köprüsünde imzacı olan kurumlar arasında, dürüst olmak gerekirse, hayat birikimlerime güvenebileceğim sadece bir avuç var. Umarım güvenilir Coinbase'e sahipsinizdir - sonra muhtemelen Galaxy, Wintermute ve Fireblocks. Geri kalanların hepsinin başarısız kurumlar olduğunu söylemiyorum, ancak onlara hayatım boyunca biriktirdiğim paranın %100'ünü emanet etmek başka bir mesele.
Kısacası, federasyonunuzda 15 imzalayıcı olmasının bir faydası yoktur, bunlardan 10'u iyi güvenlik uygulamaları uygulamıyor veya hatta düpedüz kabataslaktır. Sorun şu ki, bırakın 50 imzacıyı, mükemmel opsec ile üstün itibara sahip 15 imzacı bulmak, söylemek yapmaktan daha kolaydır.
Herkes saygın ve güvenli olduğunu iddia ettiğinde? Voila, sadece birkaçı gerçekten öyle!
Bununla birlikte, benim görüşüme göre federe BTC köprüleri, BTC'yi Bitcoin ana zincirinin dışındaki diğer zincirlere (veya katmanlara) "ihraç etmenin" en iyi yolu olmaya devam etmektedir. Cypherpunk'ların mezarlarında yuvarlanmalarını bekleyin, ancak dikkatle seçilmiş kaliteli imzalayıcılardan oluşan bir federasyon, çoğu durumda mevcut koşullarda mümkün olan herhangi bir izinsiz alternatiften daha güvenli olacaktır.
Sonuçta, bugün gördüğünüz çoğu BTC temsilinin çoğunlukla imzalayanların federasyonuna dayanmasının bir nedeni var. SolvBTC, pumpBTC, Lombard'ın LBTC'si, Stacks'ın sBTC'si, Avalanche'ın BTC.b'si, Bitlayer'ın WBTC'si, Liquid'in L-BTC'si, Merlin'in MBTC'si - bunların hepsi, her birinin sırasıyla küratörlüğünü yaptığı imzalayanlar federasyonuna güvenmenizi gerektirir. Ancak gerçekten saygın imzacılar bulmak zor olduğundan, aynı imzacının iki veya daha fazla köprü kurulumunun bir parçası olduğu federasyonlar arasında birden fazla imzacı çakışması örneği bulduğunuzda şaşırmayın. Örneğin, Cobo solvBTC, pumpBTC ve Merlin'in MBTC'sinde imzacıdır. Ya da Chorus.one, hem Lombard'ın LBTC'si hem de Stacks'ın sBTC'si için imzalayıcıdır.
Bir federasyon içindeki iki imzalayanın aslında aynı daha geniş ekosistemin veya varlığın parçası olduğu durumlar bile vardır. Örneğin, Avalanche'ın BTC.b'si 8 imzacı federasyonunun bir parçası olarak Avascan ve Ava Labs'ı içermektedir. 8'de 5 çoğunluk eşiğini (gerekli minimum) varsayarsak, saldırgana rüşvet vermek ya da uzlaşmak (ve BTC.b köprüsünün güvenliğini ciddi şekilde tehdit etmek) için "yalnızca" 3 imzalayıcı kalır.
Lombard LBTC
Bazı projeler imzalayıcı opsec'in öneminin farkına varmış ve bu saldırı vektörünü en aza indirmek için adımlar atmıştır. Örneğin Lombard, Konsorsiyumlarının (imzalayıcı seti) Cubist tarafından HSM mühürlü Nitro enklavları kullanılarak inşa edilen gözetim dışı bir anahtar yönetim platformu olan CubeSigner'ı çalıştırmasını zorunlu kılarak güvenlik için çok katmanlı bir yaklaşım kullanmaktadır. Uygulamada, CubeSigner anahtarların adres üretiminden işlem imzalamaya kadar güvenli donanımda kalmasını sağlar - Cubist veya imzalayanların kendileri dahil hiç kimse, dışarıdan saldırganların anahtarları çıkarması bir yana, anahtarları göremez.
Ancak, tıpkı evinizdeki Ledger donanım cüzdanlarının bütünlüğü ve bozulmamışlığı konusunda Ledger'a güvendiğiniz gibi, Lombard'ın LBTC sahiplerinin de Konsorsiyum imzalayıcıları tarafından çalıştırılan CubeSigner örneklerinin bütünlüğü ve bozulmamışlığı konusunda Cubist'e güvenmeleri gerekecektir - aksi takdirde, her bir Konsorsiyum imzalayıcısının kendi opsec'lerini berbat etmemesine güvenmeye geri döneriz.
[Resimli: Lombard LBTC mimarisi
Buna ek olarak, bu durum, ne kadar düşük ihtimalli görünse de, olası imzalayıcı gizli anlaşması riskine rağmen geçerlidir. Basit gerçek şu ki, Lombard Konsorsiyumu'nun imzacılarının çoğunluğu gizli anlaşma yaparsa, Konsorsiyum'un adreslerinde tutulan BTC'yi tehlikeye atabilir ve kullanıcı fonlarını çalabilirler.
Sonuç
Bir sektör olarak, bugün sahip olduğumuz BTC temsilciliklerinin seçimiyle yetinirsek kendimize kötülük etmiş oluruz. Sert ama söylenmesi gereken bir şey var: BTC ile güvene dayalı olmayan bir şekilde işlem yapabilecek olanlar yalnızca ana zincir işlem ücretlerini ödeyecek cebi olan birkaç balina ise Bitcoin'in (ve aslında tüm bu sektörün) bir anlamı yoktur. BTC'nin kitleler için güvenilmez sağlam para olduğu fikri, çoğu insan için BTC'yi biriktirmenin, harcamanın ve işlem yapmanın tek gerçekçi yolu, devlet yetkisi altındaki yanılabilir insanlar tarafından yönetilen varlıklara güvenmelerini gerektirdiğinde ortadan kalkacaktır.
Federe BTC köprüleri gerçekten de insanların BTC'yi hızlı ve ucuz bir şekilde tutmalarının ve işlem yapmalarının önünü açarken, mevcut diğer alternatiflere kıyasla nispeten güvenli olmaya devam etmektedir. Ancak bunlar hiçbir zaman Bitcoin ölçeklendirmesi için son oyun olarak tasarlanmadı, daha ziyade bir amaca yönelik bir araç olarak tasarlandı.
Şimdiye kadar yeterince iyi, ancak kesinlikle sektörün (ve pazarın) umutsuzca ihtiyaç duyduğu kutsal kâse çözümü değil.
Anaç rBTC
[Rootstock] Rootstock: Bitcoin'in OG ölçeklendirme çözümlerinden biri
Ocak 2018'de başlatılan Rootstock, ilk ve en uzun ömürlü Bitcoin yan zinciridir. Konsensüs için birleştirme madenciliğinden yararlanır ve rBTC'nin Rootstock'taki gaz ücretlerini ödemek için de kullanıldığı iki yönlü bir federe BTC köprüsü kullanır.
İşin püf noktası? Rootstock'un federe BTC köprüsü, güvenli olması için dürüst bir çoğunluk varsayımı gerektirmez!
Şimdi dikkatinizi çektiğime göre, konuya girelim.
birleştirme-madencilik
Rootstock zinciri mutabakata varmak için birleştirme-madenleme yöntemini kullanır. PoS zincirlerinin (stake setine göre stake ettiğiniz varlıkların oranının oylama gücünüzü temsil ettiği) aksine, birleştirme madenciliği zincirleri Bitcoin madenciliği için halihazırda kullanılmakta olan hashrate kapasitesini Rootstock zincirini doğrulamak için genişleterek kullanmayı amaçlamaktadır. Bu, Bitcoin madencilerinin aynı altyapı ve enerji tüketimiyle hem Bitcoin hem de Rootstock'u aynı anda güvence altına almalarına ve aynı harcamayla her iki ağdan da madencilik ödülleri kazanmalarına olanak tanır. Eğer PoS'a daha aşinaysanız, birleştirme madenciliği yeniden stake etmeye benzer - aynı kaynak (örneğin ETH) hem yerel PoS zincirini (sıvı stake platformları aracılığıyla) hem de harici PoS ağlarını (seçtiğiniz ağları güvence altına almak için LST'nizi yeniden stake ederek) aynı anda güvence altına almak için kullanılır.
[Alexei Zamyatin] resimli: merge-mining
Bu yazı yazılırken, Bitcoin madencilerinin ~%80'i Rootstock'un birleştirme-madencilik sürecine katılmayı tercih etti - bir Rootstock bloğunun her PoW'u artık Bitcoin'in hash gücünün ~%80'ini miras alacak!
Zincir üzerinde daha yüksek iş hacmi sağlamak için Rootstock blokları Bitcoin bloklarından daha hızlı kazılacak şekilde tasarlanmıştır (dolayısıyla Bitcoin'den daha düşük bir zorluk derecesine sahiptir). Bugün itibariyle, Rootstock'un ortalama blok süresi, Bitcoin'in 10 dakikalık ortalama blok süresine kıyasla yaklaşık 25 saniye civarındadır.
tldr
BTC'yi zincire bağlamak için Rootstock, donanımsal bir değişiklikle birlikte gelen özel bir tür federe BTC kurulumunu hayata geçirdi. Pegnatorilerin (imzalayanlar) Rootstock'un PowHSM adı verilen donanım güvenlik modülünü çalıştırmaları gerekmektedir. PowHSM, federasyonun multisig şemasının bir parçası olan imzalayanın anahtarını saklamaktan sorumlu, kurcalamaya karşı korumalı bir cihazdır. Lombard'ın CubeSigner uygulamasına benzer şekilde PowHSM, anahtarların üretimden imzalamaya kadar güvenli donanımda kalmasını sağlamak için tasarlanmıştır - Rootstock veya imzalayanların kendileri bile hiç kimse, dışarıdan saldırganların anahtarları çıkarması bir yana, anahtarları göremez.
Rootstock'taki Bridge sözleşmesi Bitcoin SPV'yi çalıştırarak Rootstock'tan Bitcoin'i güvene dayalı olmayan bir şekilde görmesini sağlar. Peg-in işlemleri için pegnatories, Bridge'i bilgilendirmeden önce kullanıcının Bitcoin'deki BTC depozitosunun 100 onay biriktirmesini bekler, böylece kullanıcının BTC depozitosunun doğrulanması üzerine (Bitcoin SPV aracılığıyla) kullanıcıya rBTC basar.
Peg-out işlemleri için, Köprü ilk olarak peg-out talebini kabul edecektir. 4000 blok onayından sonra (Rootstock'ta), Köprü, pegnatorilerin imzalaması için bu talebe karşılık gelen Bitcoin peg-out işlemini oluşturur. Ardından her PowHSM bu komutu alır ( Powpeg, yani Rootstock tam düğümleri aracılığıyla) ve işlemi imzalaması için pegnatory'yi tetikler. Pegnatorilerin çoğunluğu işlemi imzaladığında, Rootstock'un Bitcoin multisig'i ilgili BTC miktarını para çeken kullanıcının Bitcoin adresine gönderecektir.
gizli anlaşmalar lanetlensin
Rootstock'un federe BTC köprü uygulamasını diğerlerinden ayıran şey, köprüsünün güvenli kalması için imzalayan kümesinden dürüst bir çoğunluk güven varsayımına ihtiyaç duymamasıdır. Başka bir deyişle, Rootstock'un pegnatorilerinin çoğunluğu işbirliği yapsa bile, köprüyü tehlikeye atamaz ve kullanıcı fonlarını çalamazlar.
Bu nasıl mümkün olabilir? Bunun nedeni, Rootstock'un işlem üretimini işlem imzalamadan ayırabilmesi ve Powpeg'e bağlı HSM-güvenli imzalama ile eşleştirebilmesidir.
Örnek vermek gerekirse, tipik bir multisig ya da MPC yapısında, imzalayanlar işlemleri oluşturur ve imzalar. Örnek olarak Lombard'ı ele alırsak, bir kullanıcı ilk olarak zincir üzerinde bir Lombard köprü sözleşmesi ile etkileşime geçerek bir peg-out talebi göndermelidir. Lombard'ın imzalayıcılarından biri bunu alır, ardından Konsorsiyuma imzalanması için teklif etmeden önce kullanıcının talebini bir Bitcoin işlemi olarak oluşturur. Çoğunluğun onayı üzerine, Lombard'ın Bitcoin multisig'i ilgili BTC miktarını para çeken kullanıcıya serbest bırakacaktır. Bunun, küçük (önemsiz) varyasyonlar dışında, tüm federe BTC köprülerinde temsili olmasını bekleyin.
Devamında, Lombard imzalayıcısının, kullanıcının peg-out'unu kolaylaştıran Bitcoin işlemini oluşturan kişi olduğuna dikkat edin. İmzalayanların çoğunluğunun gizli anlaşması durumunda, imzalayan (çoğunluğun onayıyla) çoğunluğun onayı için Konsorsiyuma hileli bir işlem önerebilecektir. Bu nedenle federe BTC köprüleri neredeyse her zaman dürüst bir çoğunluk güvenlik varsayımını ima etmiştir - yani Rootstock'a kadar!
[IOV Labs] resimli: Rootstock'un Powpeg mimarisi
Rootstock, pegnatorilerin bir kullanıcının peg-out talebine karşılık gelen Bitcoin işlemleri üretmemesi açısından benzersizdir. Bunun nedeni, Rootstock'taki Köprü sözleşmesinin kullanıcı için Bitcoin işlemini oluşturması ve bunun da zincirin birleştirme-madencilik sürecine katılmayı tercih eden Bitcoin madencileri tarafından onaylanmasıdır. Pegnatoriler işlem üretiminde hiçbir rol oynamaz - onların rolü yalnızca Powpeg'e bağlanan ve alındığında önceden oluşturulmuş işlemi "otomatik olarak" imzalayacak olan PowHSM'yi çalıştırmaktır.
Görselleştirmek için, bir takas yapmak üzere Uniswap arayüzünü ziyaret ettiğinizi düşünün. İlk olarak, cüzdanınız (yani Metamask) yapmak istediğiniz şeye göre işlem verileri oluşturacak (örneğin "USDC için X ETH takas et") ve daha sonra imzalamanız için donanım cüzdanınızda (yani Ledger) açılacaktır. Bu senaryoda, Uniswap arayüzüne tıklayan kişi para çeken kullanıcıya, işlem verilerini üreten cüzdan Rootstock'taki Köprü sözleşmesine ve donanım cüzdanındaki fiziksel düğmelere basan kişi de alınan işlemi imzalayan pegnatory-run PowHSM'ye benzer.
güvendiğimiz donanımda.
Rootstock blok zincirinin şu anda Bitcoin'in hash gücünün %80'i ile birleştirilmiş durumda olduğunu hatırlayın. Bu nedenle, Bitcoin'in hash gücünün >%40'ına sahip olarak ve bunu en az 4000 Rootstock bloğu (~28 saat) boyunca sürdürerek zor yolu denemek ve rBTC köprüsünü tehlikeye atmak istemiyorsanız, olası bir saldırgan olarak bunun yerine Rootstock'un PowHSM uygulamasının bütünlüğünü hedef almanız daha iyi olacaktır. Tıpkı Lombard'ın imzalayan opsec riskini ortadan kaldırma konusunda Cubist'e güvendiğiniz gibi, kullanıcının da Rootstock Labs'a, pegnatory tarafından işletilen PowHSM'de Rootstock, potansiyel bir saldırgan ve hatta pegnatory'lerin kendileri tarafından istismar edilebilecek herhangi bir hata veya gizli arka kapı bulunmadığı konusunda güvenmesi gerekir.
Rootstock'un savunmasına göre, PowHSM ürün yazılımını açık kaynaklı hale getirerek kullanıcıların kendilerine duyması gereken güven miktarını azaltmak için adımlar atmışlardır. Bununla birlikte, aygıt yazılımının kendisi Ledger Nano S veya Intel SGX üzerinde uygulandığından, kullanıcıların Ledger veya Intel'e (üreticiler olarak) Secure Element çipinin gerçekten güvenli olduğu ve cihazlarına gizli kanallar, taraflı rastgele sayı üreteçleri veya herhangi bir arka kapı eklemeyecekleri konusunda güvenmeleri gerekmektedir.
Sonuç
Derinlemesine savunmadan (diğer bir deyişle katmanlı güvenlik) yararlanan Rootstock, başka hiç kimsenin yapmadığı bir şeyi başardı - kullanıcı tarafından yatırılan fonların güvenliği için dürüst bir çoğunluk varsayımı gerektirmeyen federe bir BTC köprüsü uyguladı.
Ancak yine de daha az güven, hiç güvenmemek anlamına gelmez. Rootstock'un 12 üyeli pegnatory setinin yapısına hala güvenmeniz gerekir, tıpkı diğer federe köprü kurulumlarının imzalayıcı setlerine güvendiğiniz gibi. Yine de Rootstock'un durumunda, pegnatory'lerin işlem verilerini kurcalama yetkisi olmadığından (sadece PowHSM'yi çalıştırırlar), dürüst çoğunluk gizli anlaşması riskini ortadan kaldırırsınız ve pegnatory'lere "sadece" canlılık için güvenirsiniz. Yine de, pegnatorielerin çoğunluğunun çevrimdışı olması durumunda, fonlarınızın Rootstock'un Bitcoin multisig'inde sıkışıp kalma riskiyle karşı karşıya kalırsınız.
Ayrıca, Rootstock'un PowHSM uygulamasının güvenliğine de güvenmeniz gerekir. Bu, PowHSM'lerdeki ürün yazılımı kurulumlarının düzgün yapıldığına güvenmeyi ve ayrıca cihazlarının bütünlüğü konusunda Ledger ve/veya Intel'e güvenmeyi içerir.
[Rootstock] büyük resim: Rootstock'un federe iki yönlü peg'i ve Bitcoin ana zinciri
Rootstock'un rBTC köprüsü, mevcut federe BTC köprülerine kıyasla gerçekten de büyük bir gelişme, ancak gerçek şu ki, kullanıcının hala yığının belirli kısımlarına bir miktar güven duymasını gerektiriyor. Rootstock'un federe köprü kurulumunun sağladığı güvenliğin, piyasadaki token ve temsillerin %99'u için zaten fazlasıyla yeterli olduğunu inkar etmeyecek olsam da, konu BTC olduğunda konuyu dağıtacağım - güven minimize edilmiş bir köprü yalnızca tercih edilmekle kalmaz, aynı zamanda bir ön koşuldur.
Rootstock (bana göre) yalnızca en iyi federe BTC köprüsü uygulamasına değil, aynı zamanda şu anda çalışır durumda olan en iyi genel BTC köprüsüne sahip olduğu ve tasarımıyla güvenlik ve sermaye verimliliği ihtiyacını zarif bir şekilde dengelediği için çok sayıda çiçeği hak ediyor.
Ancak iş henüz bitmedi.
Teminatlı BTC
Lightning'in yanı sıra, teminatlandırılmış BTC köprüleri, BTC'yi ölçeklenebilir bir zincire veya katmana gerçekten izinsiz bir şekilde "ihraç etmenin" bilinen birkaç yolundan birini temsil etmektedir.
İtibar söz konusu değildir, güvenilir kuruluşlara gerek yoktur. Herkesin katılımına açık, ancak güvenin en aza indirildiği şekilde tasarlanmıştır, kullanıcıların kimseye güvenmesi gerekmez.
Burada nakit tam anlamıyla kraldır.
tldr
Fikir basit: teminatlandırılmış BTC köprüsüne yatırılan her 1 $ değerinde BTC için, onu destekleyen en az 1 $ değerinde başka varlık olacaktır.
Peki ya uygulama? O kadar da değil!
Küçük farklılıklar olsa da, teminatlandırılmış BTC köprülerini temel olarak iki uygulama türüne ayırabiliriz: CDP tarzı köprüler ve hisse ağırlıklı köprüler.
Interlay iBTC
CDP, MakerDAO tarafından popüler hale getirilen ve çoğunlukla Liquity'nin LUSD'si ve MakerDAO'nun DAI'si gibi merkezi olmayan stabilcoin projelerinde bulunan teminatlandırılmış borç pozisyonu anlamına gelir. Bir borç tokenı (diğer adıyla LUSD veya DAI) basmak için, kullanıcıların pozisyonun izin verilen maksimum borcunun değerini aşan teminat (yani wBTC, ETH) yatırması gerekir. Teminatlandırma oranı, teminat varlığının algılanan oynaklığına ve riskine bağlı olacaktır - güvenli "mavi çip" varlıkları daha düşük bir oran getirme eğiliminde olurken, uzun kuyruklu varlıklar algılanan risklerini telafi etmek için daha yüksek bir teminat oranı gerektirecektir. Teminatlandırma oranının belirli bir eşiğin (örneğin %110) altına düşmesi halinde, kasalar tasfiye sürecine girecek ve pozisyon sahipleri teminatlarının tamamını kaybetme riskiyle karşı karşıya kalacaktır.
Interlay'in iBTC'si, köprülenen her 1 $ değerindeki BTC'nin hedef zincirde >1 $ değerinde teminatla desteklenmesi gereken CDP tarzı BTC köprü uygulamasının bir örneğidir. iBTC basmak için, kasacılar ana zincire BTC yatırmadan önce Interlay'e teminat yatırmalıdır. Basılabilecek iBTC miktarı, kasacının Interlay'deki teminat değerine karşılık gelir: kilitli teminat 160 $ değerindeyse, kasacılar Interlay'de yalnızca 100 $ değerinde iBTC basabilir(%160 CR). Kasa sahibinin teminat değeri tasfiye oranının altına düşerse, herkes teminatını primli olarak (%110) geri almak için iBTC basabilir, bu da tasfiye memurları tasfiye primi elde etme şansı için kasaları sürekli izleyeceğinden sistemin sağlıklı kalmasını sağlar.
[Interlay] resimli: Interlay iBTC
Kullanıcılar iBTC'yi BTC karşılığında Bitcoin'de kullanmak için önce bir vaulter'a talepte bulunur, vaulter da ilgili BTC tutarını Bitcoin kasasından kullanıcıya göndererek para çekme işlemini gerçekleştirir. Kasanın çevrimdışı olması ya da BTC'yi kullanmayı reddetmesi halinde, kullanıcı kasanın iBTC kullanımının değeriyle orantılı teminatını ve ayrıca bir miktar "başarısız kullanım" ödülünü talep edebilir. Bu şekilde, kasacılar Interlay'de kilitli teminatları ile kullanıcıya prim ödeme riskine girmemek için kullanıcı için BTC'yi kurtarmaya teşvik edilir.
Eşik tBTC
Öte yandan, hisse ağırlıklı köprüler temelde federe BTC köprüleridir, ancak imzalayıcı setini yalnızca seçilmiş birkaç güvenilir varlıkla sınırlamak yerine, herkes varlıklarını köprüye yatırarak (ve köprü için imzalayıcı olarak çalışmak üzere gerekli yazılımı çalıştırarak) imzalayıcı olarak katılabilir. İmzalama ayrıcalıkları, her bir köprünün uygulama detaylarına bağlı olarak multisig ve/veya MPC aracılığıyla dağıtılır.
Şimdi tartışmasız en önde gelen hisse ağırlıklı BTC köprü uygulaması olan Threshold'un tBTC'sine bir göz atalım. Threshold, köprüsünün her biri 100 imzalayıcıdan oluşan Bitcoin yatırma adresini oluşturmak için MPC'den yararlanır. İmzalayanlar rastgele bir süreçle (S ıralama Havuzu aracılığıyla) seçilir; burada bir pay sahibinin imzalayan olarak seçilme olasılığı, imzalayan kümesine göre yatırdığı $T'nin yüzdesine eşittir - 10 $T yatırdıysanız ve imzalayan kümesinde toplam 800 $T yatırıldıysa, bu Bitcoin yatırma adresi için imzalayan olarak seçilme şansınız %1,25 olacaktır. Bir Bitcoin yatırma adresi için 100 imzalayan olduğunu varsayarsak, node'unuzun setten en az 1 imzalayan oluşturmasını bekleyebilirsiniz. Ayrıca, cüzdan oluşturma ve imzalama için Threshold ECDSA algoritmasını kullandığından, Threshold'un Bitcoin yatırma adreslerinden fonları taşımak için 100 imzalayıcıdan 51'inin işbirliği yapması gerekir.
[Chaos Labs] resimli: Eşik tBTC
Köprü, her 14 günde bir, Threshold'un mevcut stake bileşimine dayalı olarak kullanıcı BTC depozitoları için yeni bir Bitcoin depozito adresi oluşturacaktır. Yeni stake edenlerin Threshold'un gelecekteki Bitcoin yatırma adreslerini imzalamasına izin vermenin yanı sıra, bu aynı zamanda ileriye dönük güvenliği de sağlar: Threshold'un stake bileşimini bozuk bir çoğunluk oluştursa bile, bu yalnızca o noktadan sonra üretilen yeni Bitcoin yatırma adreslerini tehlikeye atacaktır. Başka bir deyişle, bozuk çoğunluk stake kompozisyonunu ele geçirmeden önce BTC'nizi köprülemek (ve tBTC basmak) için Threshold'u kullandıysanız, BTC'niz o sırada güvenli olan dürüst çoğunluk imzalayıcı seti tarafından kontrol edilen Bitcoin yatırma adresinde güvenli bir şekilde saklanmaya devam edecektir.
iBTC - güvendiğimiz teminat
Her iki köprü modeli de (CDP tarzı ve hisse ağırlıklı) tasarımlarında kapalı bir ayrıcalıklı varlıklar kümesi dayatmaz. İmzalayanın kimliği ya da itibarı burada önemli değildir - köprü güvenliği açısından önemli olan tek şey sistemde kilitli olan teminattır.
Interlay'in CDP tarzı köprüsü söz konusu olduğunda, kullanıcılar her bir iBTC'yi destekleyen teminata güvenmek zorundadır. Çöp girerse çöp çıkar - eğer köprü teminat olarak sahte varlıkları kabul ederse, eksik teminatlandırma riskiyle karşı karşıya kalacaktır: tasfiye memurları, karşılığında aldıkları teminatın likit bir piyasası ya da etkin bir fiyat keşfi yoksa, kasaları tasfiye etmek için motive olmayabilirler. Konuya açıklık getirmek için, bir tasfiye memuru olduğunuzu hayal edin ve kendinize şu soruyu sorun: Zincir içi likiditesi zayıf olan ve saatlik %20 fiyat dalgalanmalarına maruz kalan bir memecoin için %10 prim ödeyerek bir kasayı tasfiye etmeye istekli misiniz?
Bu, maruz kalmanız gereken oracle riskine rağmen - bir kullanıcı olarak, Interlay'deki teminat varlıklarının fiyat akışlarını sağlayan oracle ağına güvenmeniz kaçınılmazdır. Oracle'lar aynı şekilde inşa edilmemiştir - bazıları fiyat kaynakları için oldukça büyük bir örnekleme sahipken ve sağlam güvenlik uygulamaları uygularken, diğerleri biraz daha şüpheli olabilir. Aslında, en zayıf halkanın genellikle CDP'nin teminatı ya da akıllı sözleşmelerinin uygulanması yerine oracle olduğu ortaya çıkmıştır!
tBTC - staker'lara güveniyoruz
Doğal olarak, hisse ağırlıklı bir köprü olması nedeniyle, tBTC sahiplerinin Threshold'un $T stake bileşiminin merkezi olmadığına ve tek bir kuruluşun veya koalisyonun şu anda veya gelecekte stake edilen $T'nin %51'inden fazlasını oluşturamayacağına güvenmeleri gerekecektir.
Threshold'un ileriye dönük güvenliği, hasarı yalnızca (stake bileşimi) tehlikeye girme noktasından sonra gelecekteki BTC mevduatlarıyla sınırlayacak olsa da, bunun gerçekten ne zaman gerçekleştiğinden tam olarak emin olamazsınız. Saldırgan, stake edilmiş $T bakiyelerini birden fazla adrese bölebilir, bu da bakiyelerinin birden fazla tarafın elindeymiş gibi görünmesine neden olurken aslında aynı varlık tarafından kontrol edilirler. Bu durum, Threshold'un temel imza algoritmasının hatalı davranan imzalayanları tespit edememesiyle (en azından tBTC v1'de) daha da karmaşık hale geliyor ve bu da olası saldırganların imzalayanlar kümesine yavaşça sızarken ve (sonunda) bir stake çoğunluğu oluştururken tespit edilmeden kalmasına olanak tanıyor. Görünüşe göre yukarıdakiler Threshold için yeterince endişe vericidir, öyle ki köprüyü yalnızca incelenmiş saygın kuruluşların imzalayıcı olmasına izin verilen izinli bir imzalayıcı seti ile başlatmaya karar vermişlerdir - Threshold'u en azından mevcut haliyle yarı federe bir BTC köprüsü haline getirmektedir!
Ancak tartışma adına, köprünün izinsiz hale getirildiğini varsayalım - $T token milyarlarca piyasa değerine ulaşmıştır ve herhangi bir saldırganın köprünün stake bileşiminin %51'ine kadar $T biriktirmesi pek olası olmayacaktır. Bu "oyun sonu" durumunda bile, köprü hala kapasite tarafından kısıtlanmaktadır: kullanıcı BTC depozitoları, yalnızca imzalayan setin, toplu olarak kontrol ettikleri tüm Bitcoin yatırılan adreslerdeki kullanıcı fonlarını çalmaktan kazanabileceklerinden daha fazla stake edilmiş teminatta kaybetmeye devam etmesi durumunda ekonomik olarak güvenli kabul edilir.
Yukarıdakileri ölçmek için, Threshold'a toplam 10 milyon $ değerinde T yatırılan bir senaryo hayal edelim. Ayrıca basitlik adına, imzalayan setinin baştan sona değişmediğini varsayalım. İmza için 100'de 51'e ihtiyacınız olduğundan, köprünün ekonomik güvenliğinin 5,1 milyon dolar değerinde olduğunu söyleyebilirsiniz - bu, Threshold'un haydut imza sahiplerini kesmesi için mevcut olan maksimum teminat değeridir. Şimdi bunun nereye gittiğini görebilirsiniz - teorik olarak, kontrol edilen Bitcoin yatırma adreslerindeki kullanıcı BTC yatırmalarının toplamı 5.1 milyon dolardan fazla bir değere ulaştığında, imzalayanların gizli anlaşma yapması ve kullanıcı fonlarını hortumlaması karlı hale gelecektir. Her ne kadar pratikte imzalayan seti birden fazla Bitcoin yatırma adresinde sabitlenmeyecek olsa da (yeni ve eski imzalayanlara uyum sağlamak için), bunun arkasındaki oyun teorisi hala geçerli: imzalayan setinin hileli bir çoğunluğu, kontrol edilen Bitcoin yatırma adreslerindeki kullanıcı BTC mevduatlarının değerinin kaybedecekleri teminattan daha fazla olması koşuluyla köprüyü tehlikeye atabilir.
Sonuç
Lightning dışında, yalnızca teminatlandırılmış BTC köprüleri gerçekten izinsiz olduklarını iddia edebilir. Ne yazık ki, bu köprüler de köprünün dışında var olan bir dizi muamma ve örtük güven varsayımı taşımaktadır.
CDP tarzı köprülerin güvenliği, temelde köprüyü desteklemek için kabul ettikleri teminat yapısıyla iç içedir. Eğer köprü kendini yalnızca yüksek kaliteli varlıklarla (yani ETH) sınırlarsa, söz konusu varlıkları çekmek için getiri konusunda diğer DeFi protokolleriyle rekabet etmesi gerekecektir: ETH sahibi, diğer protokollerde daha yüksek getiri elde edebilecekken neden size para yatırsın?
CDP-style bridges are also highly capital-inefficient — in the case of Interlay, at least $1.6 worth of collateral is needed in order to mint $1 worth of iBTC. You can only lower the collateralization ratio down to a certain threshold: set it too low (<110%), and you’re staring at a barrel of failed liquidations and the risk of the bridge failing due to being straddled by bad debt.
Bir de oracle güvenliği meselesi var. İlk etapta düzenli tasfiyelerin mümkün olabilmesi için CDP tarzı köprüler, oracle kaynaklı sağlam ve doğru fiyat beslemelerine dayanır. Bu da varsayılan olarak kullanıcıların köprünün oracle ağına ya da sağlayıcısına da güvenmesi gerektiği anlamına gelir.
Hisse ağırlıklı köprülerde ise hisse dağılımı belirleyici unsurdur - ne de olsa köprünün yeni Bitcoin yatırma adresleri oluşturulurken kimin imzalayan kümesinin bir parçası olacağını belirlerler. Kullanıcılar, stake token'ın sahiplik dağılımının, tek bir varlık ya da koalisyonun çoğunluğu elde edemeyeceği şekilde yeterince merkezi olmadığına güvenmelidir - şimdi ve gelecekte.
Buna ek olarak, hisse ağırlıklı köprüler temelde kapasite kısıtlıdır (CDP tarzı köprülerden çok daha iyi olsa da) - yalnızca imzalayan kümesinden potansiyel bir haydut çoğunluğun toplam stake edilmiş teminat değerine kadar kullanıcı BTC depozitolarını ekonomik olarak güvence altına alabilir. Bu da köprünün çoklu para yatırma adreslerinde ne kadar BTC'nin güvenli bir şekilde saklanabileceğini sınırlar - hiçbir koşulda bu adreslerdeki kullanıcı BTC para yatırma işlemlerinin toplam değeri, bunları kontrol eden imzalayan çoğunluğun toplam stake edilmiş teminat değerini aşmamalıdır.
Temsiller eşit değildir
Ana zincirden çıkmak kendi nüanslarıyla birlikte gelir. Bitcoin dışındaki BTC temsilciliklerinin hiçbir zaman BTC'yi ana zincirde tutmak kadar güvenli olmayacağı doğrudur, ancak bazen zulanız için bu kadar güvenliğe ihtiyacınız olmayabilir. Buradaki herkes milyoner değil, biliyorsunuz!
Yukarıda tartışılan BTC ölçeklendirme katmanlarının ve köprülerinin çoğunun öngörülebilir gelecekte makul ölçüde güvenli kalacağına inanmakla birlikte, kendi kendini emanet eden bir BTC hodler olarak, en azından bugün piyasada sahip olduğunuz seçeneklerin farkında olmanızın önemli olduğunu düşünüyorum. Umarım bu makale sayesinde, ortalama bir BTC hodler'ı, farklı kendi kendine emanet ortamlarında gezinirken var olan güven ödünleşimleri hakkında artık daha iyi bilgi sahibi olur.
Serinin bir sonraki makalesinde, Bitcoin'de programların iyimser bir şekilde çalıştırılmasına olanak tanıyan bir hesaplama paradigması olan BitVM'in oyunun kurallarını değiştiren keşfini inceleyeceğiz. Bu, hesaplamanın çoğunu zincir dışında gerçekleştirdiği ve bu nedenle Bitcoin'in sınırlamaları tarafından engellenmediği anlamına gelir. Bununla birlikte, herhangi biri sonuçla aynı fikirde değilse, Bitcoin'de zincir üzerinde bir anlaşmazlık yaratabilir. Herhangi bir hile varsa, hileyi yapan kişi ortaya çıkarılır ve cezalandırılır. İlk adım olarak bu, Bitcoin'den harici ölçeklendirme katmanlarına ilk kez güven minimize edilmiş BTC köprülerinin kurulmasını sağlayacaktır. Gelecekte BitVM, işlem verilerinin Bitcoin blok zincirinde saklandığı gerçek Bitcoin toplamalarını bile mümkün kılabilir.
BOB'un Hibrit Zinciri, Bitcoin'in güvenliğinin ve EVM'nin son teknoloji araçlarının güçlü yanlarını birleştirerek her iki dünyanın en iyilerini miras alıyor. Dünyanın ilk pratik BitVM uygulamasına öncülük eden BOB, güvenli ve ucuz bitcoin işlemlerinin ve DeFi'nin evi olacak - Bitcoin dışında yerel Bitcoin'i görün!
Kulağa gerçek olamayacak kadar iyi mi geliyor? Bitcoin DeFi'ye açılan kapı olan BOB'un Hibrit Zincirini derinlemesine inceleyeceğimiz 2. Bölüm için bizi izlemeye devam edin.
Bahsetmeye değer bir şeyi atladığımı düşünüyorsanız, lütfen bana X/Twitter üzerinden ulaşın - öneri ve geri bildirimlere her zaman açığım. Ayrıca, bu makaleyi yararlı bulduysanız, burada yeniden yayınlar ve beğeniler çok takdir edilir!
