Yazan: Alex Hook, Emmanuel Awosika

Derleyen: Glendon, Techub Haberleri

Bu rapor iki bölüme ayrılmıştır. Bölüm 1, çapraz zincirler alanında karşılaşılan, çapraz zincirler tokenlerinin değiştirilemezlik sorunu gibi zorlukları özetlemektedir ve mevcut ana çözümleri analiz etmektedir; Bölüm 2, egemen çapraz zinciri inceleyecektir; token standardı ERC-7281'i inceleyin ve kullanıcılar, geliştiriciler, altyapı sağlayıcıları ve Ethereum ekosistemindeki diğer katılımcılar için ERC-7281'i uygulamanın faydalarını ve potansiyel dezavantajlarını analiz edin.

Şu anda, çapraz zincir operasyonları, zincirler arası köprüler gibi blockchain birlikte çalışabilirlik yöntemlerinin doğasında olan sınırlamalar nedeniyle hala birçok zorlukla karşı karşıyadır. Örneğin, zincirler arası köprüler güvenlik risklerine sahip olabilir (bilgisayar korsanlarının gerçekleştirdiği zincirler arası saldırılar 2,5 milyar dolardan fazla kayba neden olmuştur) veya yavaş ve pahalı olmasının yanı sıra sınırlı işlevselliğe de sahip olabilirler. Üstelik yukarıdaki sorunlar aynı zincirler arası köprüde aynı anda mevcut olabilir.

Ek olarak, çapraz zincir alanında temel bir sorun vardır: Değiştirilebilir tokenlar (ERC-20 standart tokenları gibi) farklı zincirler arası protokoller aracılığıyla farklı zincirlere çapraz zincirlendiğinde, bu tokenlar yeri doldurulamaz hale gelecektir. dolayısıyla devredilebilir bir varlık olarak işlevselliğini kaybeder. Bu makalede, orijinal sözleşmesinin nerede mevcut olduğuna bakılmaksızın, bir tokenın zincirler arasında takas edilebilirliğini sağlamak için tasarlanmış bir çözümü inceleyeceğiz: Sovereign Çapraz Zincir Token Standardı ERC-7281.

ERC-7281 (xERC-20 olarak da bilinir), Ethereum'da değiştirilebilir tokenlar oluşturmaya yönelik bir standart olan ERC-20'nin bir uzantısıdır. ERC-7281, token veren kuruluş tarafından onaylanan birden fazla köprünün, ERC-20 tokenlarının standart token versiyonlarını uzak zincirlerde basmasına ve yakmasına izin vererek, ERC-20 tokenleri arasında köprüleme yapıldığında, kullanıcıların hedefte aldıklarını almalarını sağlar. tokenler farklı yollar/köprüler yoluyla zincirler üzerinden gönderilse bile, token (yani iki token 1:1 oranında değiştirilebilir).

Daha da önemlisi, ERC-7281'i benimseyen bir protokol, zincirler arası tokenlerin kontrolünü koruyabilir (zincirler arası tokenlerin durumunu kontrol eden mevcut köprünün aksine) ve basım işlemlerinin oranını sınırlayabilir, böylece zincirler arası köprü arızası riskini azaltabilir Risk.

USDC'yi örnek alırsak, teorik olarak farklı zincirlerdeki aynı ERC-20 tokenlarının birbirinin yerine kullanılamayacağını görebiliriz. Ethereum L2 ağlarında (Arbitrum, Base, Optimism gibi), popüler ERC-20 tokenlerini Ethereum L1'den bu zincirlere aktarmak için genellikle Canonical Bridge kullanılır. L1'den türetilen bu L2 token'larına genellikle "zincirler arası [token adını girin]" adı verilir.

USDC için ortak token sembolleri USDC.e, USDC.b vb.'dir. Her iki token da aynı kuruluş tarafından basılmış ve aynı fiyata sahip olmasına rağmen, teknik olarak farklıdırlar, değiştirilemez tokenlardır ve bu nedenle "birlikte çalışamazlar" - her ne kadar yerel USDC, çapraz geçiş için kullanılan Çember Zinciri Transfer Protokolü (CCTP) aracılığıyla değiştirilebilse de. zincir, ancak çapraz zincir USDC yalnızca standart bir köprü aracılığıyla L1'e çapraz zincir oluşturabilir.

USDC için ortak token sembolleri USDC.e, USDC.b vb.'dir. Her iki token da aynı kuruluş tarafından basılmış ve aynı fiyata sahip olmasına rağmen, teknik olarak farklıdırlar, değiştirilemez tokenlardır ve bu nedenle "birlikte çalışamazlar" - her ne kadar yerel USDC çapraz geçiş için Çember Zinciri Transfer Protokolü (CCTP) aracılığıyla değiştirilebilirse de. zincir, ancak çapraz zincir USDC yalnızca standart bir köprü aracılığıyla L1'e çapraz zincir oluşturabilir.

ERC-7281, bir token dağıtıcısının bunun için farklı zincirler arası kökenleri atayabileceği ve parametreleştirebileceği bir ERC-20 uzantısı sunarak bu sorunu çözer. Yukarıdaki örnekte Circle, standart zincirler arası köprülerin (Circle Mint, Circle CCTP ve diğer onaylı çapraz zincir köprüler gibi) kendi mantıklarına göre token basabilecek şekilde atandığı tüm L2'lere evrensel bir USDC tokeni dağıtabilir. . Dağıtıcılar, madencilerin saldırıya uğrama riskini en aza indirmek için, her madencinin belirli bir zaman diliminde basabileceği ve yok edebileceği jeton sayısını sınırlayabilir; daha güvenilir zincirler arası köprüler için (standart L2 çapraz zincirli Köprüler gibi), daha yüksek sınırlar olabilir merkezi fikir birliğine sahip köprüler için daha düşük sınırlar belirlenebilir.

Her ne kadar ERC-7281, çapraz zincirler arası takas edilebilir tokenlar için bir çözüm yaratmaya yönelik ilk girişim olmasa da, sağlayıcıya kilitlenme, token verenlerin egemenliğinin kaybı ve çapraz zincirlerde mevcut olan sorunları çözebilir. Zincir token yönlendirmeli akışlar Daha yüksek maliyetler, artan altyapı yükü ve artan zincirler arası arıza riskleri.

Değiştirilemez çapraz zincir tokenleri konusuna dalmadan önce, çapraz zincir tokenlarının neden var olduğunu anlamamız gerekir. Bu nedenle, çapraz zincir köprülerinin motivasyonlarını ve çalışma mekanizmalarını da anlamamız gerekir; çünkü çapraz zincir köprüler, tüccar, zincirler arası token versiyonlarını oluşturmaktan sorumlu taraftır.

Çapraz zincir mekanizması, blok zincirler arasında bilgi aktarmanın bir yoludur. Zincirler arası köprüler, salt parasal bilgiye ek olarak, diğer zincirlerdeki token döviz kurları ve akıllı sözleşme durumu gibi diğer yararlı bilgileri de iletebilir. Ancak varlıkların (tokenların) bir zincirden diğerine aktarılması, şu anda kullanıcılarla etkileşime giren köprüler için şüphesiz en yaygın kullanım durumudur.

Zincirler arası varlık transferlerini kolaylaştırmaya yönelik yöntemler değişiklik gösterir, ancak zincirler arası tokenlara yönelik iş akışı genellikle üç üst düzey modelden birini izler:

Kilit ve Nane Köprüsü

Yıkım ve Darphane Köprüsü

Atomik Takaslar

Yukarıdaki yöntemlerden ilki (kilitleme ve basım) şu anda en yaygın olanıdır. Yerel tokenlar ile köprü tarafından basılan ilgili sarılmış tokenlar arasındaki değer eşitliği, kullanıcıların varlıkları "çapraz zincirleme" yapmasına ve tokenları orijinal olarak yayınlandıkları zincirden farklı bir zincirde kullanmalarına olanak tanır.

Ancak amaca dayalı zincirler arası köprüler gibi yeni tasarımlar oldukça popüler hale geldi. "Niyetler", sonuca ulaşmak için belirli adımların ana hatlarını çizmek yerine, kullanıcıların bir işlemin istenen sonucunu (100 USDC'yi 100 DAI ile değiştirin) ifade etmelerine olanak tanır. Niyetler, güçlü bir kullanıcı deneyiminin kilidini açma aracı haline geldi çünkü insanların zincir üzerindeki deneyimini büyük ölçüde basitleştiriyor ve özellikle zincir üzeri soyutlama çözümleriyle birleştirildiğinde kripto para birimlerinin kullanımını kolaylaştırıyor.

Çapraz zincir amacı, kullanıcıların zincirler arası köprülerin altında yatan karmaşıklıklar hakkında endişelenmeden zincirler arasında token aktarmalarına olanak tanır. Niyet temelli zincirler arası köprüde, kullanıcılar kaynak zincirine para yatırır ve hedef zincirde arzu ettikleri sonuçları (yani "niyetlerini") belirtirler. Doldurucular veya Çözücüler olarak adlandırılan profesyonel operatörler, istenen tokenleri hedef zincirdeki kullanıcılara önceden göndererek bunu başarabilirler. Operatör daha sonra kaynak zincirinde kilitlenen fonları tazminat olarak talep etmek için transferin gerçekleştiğini kanıtlar.

Bazı amaca dayalı çapraz zincir köprüler dahili olarak kilitleme ve döküm mekanizmalarını kullanır. Bu durumda, sarılmış tokenlar zincir köprü boyunca basılıyor ve bu tokenlar ya kullanıcının amacını karşılayan bir doldurucuya ya da doğrudan kullanıcıya (eğer herhangi bir doldurucu müdahale etmiyorsa) gönderiliyor. Bununla birlikte, amaca dayalı zincirler arası köprüler, çözücü ağları aracılığıyla ekstra bir verimlilik katmanı ekler, ancak yine de esas olarak geleneksel kilitle ve kullan köprüleriyle aynı ilkelere dayanırlar.

Sarılmış her tokenı (geleneksel bir zincirler arası köprü veya niyete dayalı zincirler arası köprü yoluyla oluşturulmuş olsun), zincirler arası köprü sağlayıcısı tarafından verilen ve belirli sayıda yerel tokenı piyasaya sürmeyi vaat eden bir "IOU" olarak düşünebiliriz. emanet sözleşmesinden. Bu sarılmış varlıkların değeri, zincirler arası köprü sağlayıcısının yerel zincirdeki emanet token sahiplerinden gelen para çekme taleplerini karşılama (algılanan) yeteneği ile doğrudan ilgilidir.

Yerel tokenleri kaynak zincirine kilitlemeye ve sarılmış tokenlarını hedef zincire basmaya yetkili olan çapraz zincir köprüler, toplam token arzının değişmeden kalmasını sağlar. Yerel tokenın bir birimi için, karşılık gelen sarılmış tokenın tam olarak bir birimi basılır ve bunun tersi de geçerlidir. Bir uygulama, sarılmış tokenleri bir değişim aracı olarak kabul ederse veya sarılmış varlıkları para birimi olarak kullanırsa, bu uygulamanın geliştiricileri ve kullanıcıları, sarılmış tokenların "gerçek" varlıklarının güvenliğini desteklemek için zincirler arası köprü sağlayıcısına yeterli güvene sahiptir.

Zincirler arası köprüler, zincirler arası tokenlar oluşturarak, uzak zincirlerdeki varlıkların sentetik versiyonlarıyla ticaret yapabilir; bu, hem geliştiricilerin hem de kullanıcıların zincirler arası birlikte çalışabilirliğin avantajlarından yararlanmasına olanak tanıyan güçlü bir özelliktir. Bu avantajlar arasında daha fazla likidite kazanmak, yeni kullanıcılar çekmek ve kullanıcılara esneklik sağlamak (kullanıcılar farklı zincirlerdeki uygulamalarla herhangi bir engel olmadan etkileşimde bulunabilir) yer alır.

Bunun pratikte nasıl çalıştığını ve hem geliştiriciler hem de kullanıcılar için neden önemli olduğunu daha iyi anlamak için, örnek olarak "BobDEX" adı verilen kurgusal bir merkezi olmayan borsayı ele alalım. Bu örnek, sarılmış bir tokenın zincirler arasında nasıl ölçeklenebileceğini gösterecek ve ortaya çıkabilecek faydaları ve potansiyel karmaşıklıkları vurgulayacaktır:

BobDEX, farklı varlıklar arasında güvenilir alışverişi sağlamayı amaçlayan, Bob tarafından Ethereum üzerinde oluşturulan bir otomatik piyasa yapıcı (AMM) borsasıdır. BobDEX'in hem bir yönetişim tokeni hem de likidite sağlayıcı (LP) ödül tokeni olan yerel bir token BOB'u vardır. İkinci durumda, BobDEX, LP'ye BOB tokenları ihraç eder; bu, havuza likidite sağlayan kullanıcılara, DEX kullanıcılarının havuzda depolanan varlıkları takas etmek için ödediği ücretlerin bir kısmını (yüzde olarak hesaplanan) alma hakkı verir.

Ancak BobDEX'in pazar payı önemli ölçüde arttıkça Ethereum'un L1 sınırlamaları onun daha fazla büyümesini engelledi. Örneğin, bazı kullanıcılar yüksek gaz ücretleri ve işlem gecikmeleri nedeniyle Ethereum'da BobDEX'i kullanmak istemiyor; benzer şekilde, diğer kullanıcılar BOB tokenlerine maruz kalmak istiyor ancak yerel BOB tokenlerini Ethereum'da tutmak istemiyorlar.

Bu sorunu çözmek için Bob, Arbitrum'da BobDEX'in bir sürümünü (düşük ücretli, yüksek verimli katman 2 toplaması) ve Arbitrum-Ethereum köprüsü (wBOB) aracılığıyla L2'de BOB tokeninin sarılmış token versiyonunu konuşlandırdı. Arbitrum'daki BobDEX, Ethereum'daki BobDEX ile aynıdır ancak LP ödülü ve yönetişim tokeni olarak wBOB'u (yerel BOB tokenı yerine) kullanır.

Arbitrum'da BobDEX ile etkileşimde bulunan kullanıcılar için (likidite sağlayıcıları gibi), uygulama token'ları (sarılmış BOB ve yerel BOB) arasındaki fark önemli değildir. Bunun nedeni, wBOB tokenlarının Arbitrum-Ethereum köprüsünde tutulan gerçek BOB tokenleri tarafından desteklenmesidir, böylece wBOB token sahipleri, köprü sözleşmesiyle etkileşime girerek Ethereum'daki yerel BOB ERC-20 tokenlerini kolayca kullanabilirler.

Bu durumun Bob ve kullanıcı için bir kazan-kazan olduğunu görebiliriz:

1. Bob, özellikle BobDEX'te işlem yaparken daha düşük gas ücretleri ve hızlı işlem onayı isteyen kullanıcılar olmak üzere daha fazla kullanıcının ilgisini çekebilir;

2. LP, Ethereum'un yüksek gas maliyeti ve uzun onay süresiyle uğraşmak zorunda kalmadan BobDEX'e likidite sağlayarak ödüller kazanabilir;

3. Yatırımcılar, Ethereum'daki BOB ERC-20 sözleşmesiyle etkileşime girmeden BOB token fiyatlarındaki değişikliklerden kar elde etmek için piyasadan wBOB tokenları satın alabilirler.

Bunun ötesinde, zincirler arası köprülerin faydaları, şekillendirilebilir inovasyonu geliştirmek ve köprü tokenlarının likiditesini artıran yeni kullanım durumlarının kilidini açmaktır. Örneğin Alice, Arbitrum'da "AliceLend" adında bir borç verme protokolü oluşturabilir; bu protokol, borçlunun wBOB'unu, wBOB'un faydasını genişletmek ve yeni bir borç verme piyasası oluşturmak için teminat olarak kabul eder.

AliceLend'e likidite sağlayan borç verenlere mevduatlara erişim garantisi verilir: Bir kullanıcı temerrüde düşerse AliceLend, borç verene geri ödeme yapmak için teminat olarak yatırılan wBOB tokenlerini otomatik olarak açık artırmaya çıkarır. Bu durumda, wBOB teminatını tasfiye eden alıcı, BobDEX'te LP rolünü üstlenecek ve wBOB tokenlerinin 1:1 oranında orijinal BOB tokenlarıyla değiştirilebileceğine dair aynı garantiyi verecektir.

Şu anda çapraz zincir köprüler, (önceden izole edilmiş) Ethereum L2'ler arasında birlikte çalışabilirliği sağlamak ve zincirler arası borç verme ve zincirler arası DEX gibi yeni uygulamaları kolaylaştırmak için geçerli bir çözüm sunmaktadır. Bununla birlikte, çapraz zincir köprü ekosistemi, çapraz zincir tokenlarının değiştirilemezliği sorunu gibi daha fazla büyümesini engelleyen sınırlamalarla karşı karşıyadır.

Yukarıda bahsedilen kilitleme ve basma köprüsünün zincirler arası iş akışı basit görünebilir ancak gerçekte düzgün çalışması için çok fazla mühendislik ve mekanizma tasarımı çalışması gerektirir.

Yukarıda bahsedilen kilitleme ve basma köprüsünün zincirler arası iş akışı basit görünebilir ancak gerçekte düzgün çalışması için çok fazla mühendislik ve mekanizma tasarımı çalışması gerektirir.

İlk zorluk, zincirler arası bir tokenın sarılmış token versiyonunun her zaman kaynak zincirinde kilitli olan yerel token tarafından desteklenmesini sağlamaktır. Bir saldırgan, kaynak zincirine yerel belirteçler bırakmadan uzak zincir üzerinde çapraz zincir belirteçleri basarsa, saldırgan, sarılmış belirteçleri ana zincirdeki yerel belirteçlerle değiştirerek (sahtekarlıkla basılmış) çapraz zincir belirteçlerini kullanılabilir hale getirebilir. Köprü protokolü. iflas eder ve meşru kullanıcıların (sarılmış tokenları basmadan önce zincirler arası köprü sözleşmesine para yatıran) mevduatlarını geri çekmelerini engeller.

İkinci zorluk ise daha inceliklidir ve çapraz zincir tokenlarının doğasından kaynaklanmaktadır: bir çapraz zincir köprü sağlayıcısı tarafından aynı uzak zincirde basılan aynı tokenın iki token versiyonu, 1:1 oranında birbirleriyle değiştirilemez. Bu bağlamda, tokenlerin zincirler arasında taşınmasıyla ilgili sorunları göstermek için farklı yollardan zincirler arasında token alışverişi yapmaya çalışan iki kullanıcı örneğini kullanabiliriz:

Bob neden 400 USDC'yi çekemiyor? Kendisi ve Alice, hedef zincirde aynı temel varlığın farklı paketlenmiş versiyonlarını aldıkları için, yukarıda belirtildiği gibi, farklı zincirlerde yayınlanan tokenlar uyumsuzdur, bu nedenle yerel olmayan zincirde yayınlanan yerel tokenlar token versiyonu aslında bir IOU'dur. Zincirler arası köprü anlaşması, kullanıcı tokenin yerel zincirine geri köprü kurmak istediğinde karşılık gelen miktarda yerel token (kalan miktara bağlı olarak) ödemeyi vaat ediyor.

Bu nedenle, her çapraz zincir tokeninin değeri, ana zincirde mevduat tutmaktan ve hedef zincirde sarılmış tokenları basmaktan sorumlu çapraz zincir köprü sağlayıcısına sabitlenir; Bob'un çapraz zincir köprü sağlayıcısı, Bob'a yalnızca 200 USDC ödeyebilir; depozitodan ödeyebileceği miktar; Alice'in 200 USDC'si, Bob'un zincirler arası köprü sağlayıcısı aracılığıyla geri çekilemiyor çünkü o, depozitoyu hiç almamış veya Alice'e bir "IOU" düzenlememiş. Alice, kilitli USDC'sini Ethereum'daki Arbitrum'dan çekmeli ve Bob'un kalan tokenlara erişebilmesi için onu Bob'un zincirler arası köprü sağlayıcısı aracılığıyla köprülemelidir.

Bob ve Alice'in ikilemi, zincirler arası köprülemeyle ilgili bir soruna işaret ediyor; bu, birden fazla rakip zincirler arası köprü sağlayıcısının, aynı temel varlığın birden fazla değiştirilemez token versiyonunu basması. Ayrıca aynı varlığa ait farklı ERC-20 tokenlerinin bir diğer sorunu da tek bir likidite havuzunda işlem görememesidir.

Yukarıdaki örneği kullanmaya devam edersek, zincirde axlUSDC ve USDC.e varsa ve bunları ETH ile değiştirmek istiyorsak, o zaman iki likidite havuzu kurmalıyız - ETH/axlUSDC ve ETH/USDC.e, bu da şu sorunu çözer: - "likidite parçalanması" sorunu olarak adlandırılır - yani aynı likidite havuzunda bulunabilecek işlem çiftlerinin farklı havuzlara bölünmesidir.

Yukarıdaki örneği kullanmaya devam edersek, zincirde axlUSDC ve USDC.e varsa ve bunları ETH ile değiştirmek istiyorsak, o zaman iki likidite havuzu kurmalıyız - ETH/axlUSDC ve ETH/USDC.e, bu da şu sorunu çözer: - "likidite parçalanması" sorunu olarak adlandırılır - yani aynı likidite havuzunda bulunabilecek işlem çiftlerinin farklı havuzlara bölünmesidir.

Bu sorunun çözümü, tokenın "standart" bir versiyonunu hedef zincirde dolaştırmaktır, böylece Bob ve Alice, kaynak zincirinin köprüsünden çekilmeden token alışverişinde bulunabilirler. Her zincirde standart bir tokena sahip olmak geliştiricilere de fayda sağlar çünkü kullanıcılar, token likiditesi ile ilgili sorunlarla uğraşmak zorunda kalmadan ekosistemler arasında hızlı bir şekilde geçiş yapabilirler.

Peki, bir tokenın standart versiyonunu kullanılmasının veya aktarılmasının beklendiği her zincire nasıl uygulayacağız?

Her zincir için standart bir token oluşturmak kolay değildir ve her birinin kendi artıları ve eksileri olan birçok seçenek vardır. Her zincir için standart tokenlar oluştururken, belirli bir tokenin değerinin arkasında IOU'nun (senet) varlığını doğrulamak için kime güvenilmesi gerektiğini sıklıkla düşünmemiz gerekir. Bir tokenin yaratıcısı olduğunuzu ve tokenin takas edilebilirlik sorunlarıyla karşılaşmadan farklı zincirlerde kullanılmasını ve aktarılabilmesini istediğinizi varsayarsak, 4 seçeneğiniz olacaktır:

1. Standart Toplama/Yan Zincir Köprüsü aracılığıyla standart tokenları basmak

2. Üçüncü taraf zincirler arası köprü sağlayıcıları aracılığıyla standart tokenları basmak

3. Token İhraççı Köprüsü aracılığıyla standart tokenları basmak

4. Doğrudan çoklu zincir düzenlemesi için atomik takasları kullanın

İlk üç seçenek, tokenların zincirler arası hareketini kolaylaştırmak için çeşitli zincirler arası köprü mekanizmalarına dayanır. Bununla birlikte, bir token yaratıcısı olarak, zincirler arası köprüleri tamamen atlamayı ve desteklenen her zincirde tokenları yerel olarak yayınlamayı da seçebilirsiniz. Bu yaklaşıma göre, sarılmış belirteçlere veya zincirler arası köprü altyapısına güvenmek yerine, her zincirde bağımsız ancak koordineli belirteç dağıtımlarını sürdürürsünüz; yani atomik takaslar, zincirler arasında güvenilir alışverişlere olanak tanır.

Ancak bu yaklaşım, zincirler arası likiditeyi korumak ve atomik takasları kolaylaştırmak için karmaşık bir altyapı gerektirir. Geçmişte, birden fazla yerel dağıtımı yönetmenin karmaşıklığı, esas olarak büyük teknik kaynaklara sahip büyük protokoller için uygun olan bu yaklaşımın kapsamını sınırlamıştır.

Standart toplama/yan zincir köprüsü aracılığıyla standart tokenları darp edin

Bir zincirin standart bir köprüsü varsa (tanınmışsa), zincir, yerel zincirden çapraz zincir oluşturmak isteyen kullanıcılara protokolünün çapraz zincir tokenlerini basma hakkını verebilir. Zincirin standart köprüsü aracılığıyla yapılan işlemler (para yatırma ve çekme) genellikle zincirin doğrulama seti tarafından doğrulanır; bu, ana zincirdeki mevduatların tüm basılmış token versiyonlarını güvenilir bir şekilde desteklediğine dair daha güçlü garantiler sağlar.

Standard Bridge, tokenin Standart Token versiyonunu basıyor olsa da, diğer token versiyonları hala mevcut olacaktır çünkü Standard Bridge'in genellikle kullanıcılara en iyi deneyimi sağlamasını engelleyen sınırlamaları vardır. Örneğin, Rollup'ın standart köprüsü aracılığıyla Arbitrum/Optimism'den Ethereum'a köprü kurmanın yedi günlük bir gecikmesi vardır çünkü işlemin bir doğrulayıcı tarafından doğrulanması gerekir (ve muhtemelen geçersizse bir sahtekarlık kanıtı yoluyla itiraz edilir), bundan sonra Rollup'ın ödeme katmanı (Ethereum) bir dizi işlemi halledin.

Verimlilik arayan Toplama kullanıcıları, bekleyen Toplama çıkışlarının sahipliğini üstlenebilecek ve kullanıcının istediği hedef zincirinde anında likidite sağlayabilecek diğer zincirler arası köprü sağlayıcılarını kullanmalıdır. Bu tür köprüler geleneksel kilitle ve nane modelini kullandığında, farklı protokoller tarafından yayınlanan birden fazla token sarmalayıcı token ile sonuçlanırız ve daha önce açıklanan aynı sorunlarla karşı karşıya kalırız.

Bağımsız doğrulayıcı kümelerine sahip yan zincirler daha düşük gecikmeye sahiptir çünkü para çekme işlemleri, yan zincirin fikir birliği protokolü, para çekme işlemini içeren bloğu onayladığı anda gerçekleştirilir. Polygon PoS köprüsü, yan zincirleri Ethereum Rollup ve Ethereum ana ağı da dahil olmak üzere farklı alanlara bağlayan standart bir köprü örneğidir.

Not: Ödeme için Ethereum kullanmayı planlayan Validium zincirini değil, orijinal Polygon PoS zincirini kastediyoruz. Polygon, harici doğrulayıcılar tarafından güvence altına alınan yan zincirlerden Ethereum konsensüsü ile güvence altına alınan Validium zincirine geçtiğinde L2 haline gelecektir.

Ne yazık ki, yan zincir köprüleri Rollup standart köprüleriyle ortak bir zayıflığa sahiptir: kullanıcılar yalnızca bir çift bağlı zincir arasında çapraz zincir oluşturabilir. Diğer blok zincirlerine çapraz zincir oluşturmak için standart köprüleri kullanamazlar. Basitçe söylemek gerekirse, şu anda Arbitrum'dan Optimism'e köprü oluşturmak için Arbitrum çapraz zincir köprüsünü kullanamazsınız veya Polygon'u Avalanche'a köprülemek için Polygon PoS çapraz zincir köprüsünü kullanamazsınız.

Likidite Köprüsü'nü kullanan standart tokenlar

Standart tokenleri aktarmak için Rollup'ın yerel köprüsüne güvenmek, zayıf likidite ve varlık transferlerinde gecikmeler gibi sorunları beraberinde getirir. Bu sorunları çözmek için bazı protokoller, hızlı para çekme işlemlerini ve zincirler arası düşük gecikmeyi kolaylaştırmak için likidite köprüleriyle çalışır.

Bu düzenleme kapsamında, yetkili bir likidite köprüsü, kaynak zincirindeki bir protokol tokeninin sarma tokenlerini basar ve daha sonra protokole ait bir likidite havuzu aracılığıyla sarma tokenlerini hedef zincirdeki o yerel tokenin standart tokenleri ile değiştirir.

Hedef zincirdeki standart tokenlar genellikle standart yan zincir/Toplama köprüsü tarafından basılan versiyonlardır, ancak istisnalar da mevcuttur (daha sonra tartışılacaktır). Örneğin, Optimism üzerindeki USDT için standart token, Optimism Bridge tarafından basılan opUSDT'dir.

Her likidite köprüsü, farklı likidite havuzlarında depolanan varlık çiftleri arasında takas gerçekleştiren otomatik piyasa yapıcıya (AMM) sahip bir DEX gibi çalışır. Likidite arzını teşvik etmek için AMM havuzu, takas ücretlerinin bir kısmını havuz sözleşmesinde kilitlenen standart token sahiplerine tahsis edecek.

Bu, Uniswap'in modeline benzer; tek belirgin fark, varlık çiftinin genellikle zincirler arası tokenlar ve standart tokenlar arasında bir likidite köprüsü çifti değişimi olmasıdır. Örneğin, kullanıcılar USDT'yi Hop aracılığıyla Optimism'e çapraz zincirledikten sonra, hUSDT'yi Optimism'deki huSDT:opUSDT havuzu aracılığıyla kullanmak zorunda kalacaklar.

Çapraz zincirin likidite köprüsü üzerinden iş akışı aşağıdaki gibidir:

1. Kaynak zincirindeki yerel belirteçleri kilitleyin

2. Hedef zincirdeki yerel tokenların zincirler arası tokenlarını darp edin

3. Zincirler arası tokenları AMM havuzu aracılığıyla hedef zincirdeki standart tokenlara dönüştürün

4. Kullanıcılara standart tokenlar gönderin

Süreç tüm likidite köprüleri (Across, Celer, Hop, Stargate, vb.) için benzerdir ancak birçok hareketli parçaya rağmen son kullanıcıya süreç basit bir işlem gibi görünür.

Çapraz zincir kaynak zincirine geri döndüğünde, kullanıcı standart tokenı imha edecek veya standart tokenı AMM aracılığıyla çapraz zincir tokenı ile değiştirecek, ardından tokenı imha edecek ve bir imha makbuzu sertifikası sağlayacaktır. Onaylandıktan sonra kullanıcılar orijinal olarak kilitlenmiş yerel tokenları geri çekebilirler. (Önceki operasyonda olduğu gibi, tokenlerin orijinal zincire geri taşınmasıyla ilgili sıkıcı ayrıntılar kullanıcıdan gizlenir ve tamamen çözücü tarafından yönetilir).

Çapraz zincir kaynak zincirine geri döndüğünde, kullanıcı standart tokenı imha edecek veya standart tokenı AMM aracılığıyla çapraz zincir tokenı ile değiştirecek, ardından tokenı imha edecek ve bir imha makbuzu sertifikası sağlayacaktır. Onaylandıktan sonra kullanıcılar orijinal olarak kilitlenmiş yerel tokenları geri çekebilirler. (Önceki operasyonda olduğu gibi, tokenlerin orijinal zincire geri taşınmasıyla ilgili sıkıcı ayrıntılar kullanıcıdan gizlenir ve tamamen çözücü tarafından yönetilir).

Likidite köprüsünün avantajı, Rollup çapraz zincir köprüsündeki gecikme problemini çözmesidir; örneğin Hop, "Bonders" adı verilen uzmanlaşmış kurumların L2'deki kullanıcı para çekme işlemlerinin geçerliliğini kanıtlamasına ve Rollup'ın L1 köprüsünden sorumluluğu üstlenmesine olanak tanır. Para çekme işleminin maliyeti. Her Bonder, L2 zinciri için tam bir düğüm çalıştıracak ve kullanıcının çıkış işleminin sonunda L1'de onaylanıp onaylanmayacağını belirleyebilecek, böylece kullanıcıların hileli para çekme işlemleri başlatması ve Bonder'ın zarara uğraması riski azaltılacak.

Likidite köprüleri, standart köprülerden farklı olarak kullanıcıların daha fazla zincir arasında geçiş yapmasına da olanak tanır. Örneğin Hop, kullanıcıların önce Ethereum'a çekilmeden Arbitrum ve Optimism arasında çapraz zincir oluşturmasına olanak tanıyor. Hızlı L2'den L1'e köprüleme gibi, hızlı L2'den L2'ye köprüleme de Bonder'ların para çekme işlemlerini onaylamak için kaynak L2 zinciri için tam bir düğüm çalıştırmasını ve ardından hedef L2 zincirindeki kullanıcılar için token basımı ücretini ön ödemesini gerektirir; bu da Toplama işlemini gerçekleştirir. daha şekillendirilebilir ve kullanıcı deneyimini önemli ölçüde artırır.

Elbette, likidite köprülerinin, zincirin standart köprüsünü kullanarak L2/L1 zincirleri üzerinde standart token basımının pratikliğini etkileyen bazı dezavantajları vardır.

Likidite Köprüsünün Dezavantajları

Kayma

Kayma, bir AMM ile etkileşime girildiğinde alınması beklenen token sayısı ile gerçekte alınan token sayısı arasındaki farkı ifade eder. Zincirler arası varlıklarda likidite eksikliği de kaymayı artırabilir; havuzda yeniden dengelenmeye yetecek kadar likidite yoksa, büyük işlemler fiyatları önemli ölçüde değiştirerek kullanıcıların daha yüksek fiyatlarla swap işlemleri gerçekleştirmesine neden olabilir. Teorik olarak, arbitrajcıların farklı varlık havuzları arasındaki fiyat farklılıklarını alım satım faaliyetleri yoluyla düzeltmeleri beklenir, ancak arbitraj işlemleri daha az alım satım faaliyeti veya daha düşük değere sahip tokenlar içerdiğinde bu mekanizma engellenebilir.

Ve bu aynı zamanda çapraz zincir uygulamaları geliştiren geliştiricileri de etkiler, çünkü kaymanın meydana geldiği uç durumları dikkate almaları gerekir; kullanıcılar, bir veya daha fazla hedef zincirde daha az sayıda token aldıkları için çapraz zinciri tamamlayamayabilirler.

Bununla mücadele etmek için, bir likidite köprüsünün hedef zincirdeki swapları kayma olmadan karşılamak için yeterli likiditeye sahip olup olmadığını bilmenin hiçbir yolu olmayan zincirler arası toplayıcılar gibi uygulamalar, maksimum kayma toleransını belirleme yöntemini benimsemiştir. Stratejiler kullanıcılara fiyat teklifi sunar. onlar için kabul edilebilir maksimum kayma aralığını önceden ayarlayarak. Bu, işlemlerin geri alınmasını engellerken, kullanıcılar köprünün AMM havuzundaki likiditeye bakılmaksızın her zaman zincirler arası tokenlerinin bir yüzdesini kaybedeceklerdir.

Likidite kısıtlamaları

Likidite köprüleri için temel zorluk, hedef zincirde yeterli likiditenin bulunması gerektiğidir. Token basımının doğrudan kilitli varlıklar tarafından desteklendiği geleneksel kilitleme ve naneden farklı olarak Liquidity Bridge, zincirler arası transferleri tamamlamak için AMM havuzundaki mevcut tokenlara güvenir. Likidite kritik bir eşiğin altına düştüğünde, tüm zincirler arası mekanizma aslında çalışmayı durdurabilir.

Likidite gereksinimi döngüsel bir bağımlılık yaratır: Köprünün güvenilir bir şekilde çalışması için büyük miktarda likidite gerekir, ancak likidite sağlayıcılarının ilgisini çekmek için köprünün sürekli kullanımının ve ücret üretiminin gösterilmesi gerekir. Bu tavuk-yumurta sorunu, daha az sıklıkla ticareti yapılan ve birden fazla zincirde yeterli likiditeyi sürdürmekte zorluk çekebilecek yeni tokenlar veya tokenler için özellikle ciddidir.

Teşvik uyumsuzluğu

Likidite köprüsünün rolü, kullanıcı açısından aşırı kaymaya neden olmadan zincirler arası tokenlardan hedef zincirdeki standart tokenlara geçişi kapsayabilmesidir; köprüyle etkileşime girmenin Gazı aynı zamanda değerini de belirler. bir likidite köprüsü. Bu nedenle, zincirler arası toplayıcılar ve token çıkaran proje ekipleri, likidite ve işlem maliyetlerine göre zincirler arası köprülere öncelik veriyor.

Bu, zincirler arası proje tokenleri veya zincirler arası token göndermek için çapraz zincir toplayıcıları kullanan kullanıcılar için daha iyi bir kullanıcı deneyimi sağlarken, likiditeye dayalı bir zincirler arası köprünün seçilmesi, LP teşviklerine dezavantajlı bir şekilde harcama yapmayı imkansız hale getirecektir. . Ayrıca, bunu yalnızca işlem ücretlerine dayandırmak, işletme maliyetlerini azaltmak için merkezi bir yaklaşım benimseyen ve zincirler arası işlemler için daha düşük ücretler talep edebilen zincirler arası köprüler lehine rekabeti önleyecektir. Her iki durumda da zincirler arası köprüler en önemli ölçüt olan güvenlik konusunda rekabet edemiyor.

Bu, zincirler arası proje tokenleri veya zincirler arası token göndermek için çapraz zincir toplayıcıları kullanan kullanıcılar için daha iyi bir kullanıcı deneyimi sağlarken, likiditeye dayalı bir zincirler arası köprünün seçilmesi, LP teşviklerine dezavantajlı bir şekilde harcama yapmayı imkansız hale getirecektir. . Ayrıca, bunu yalnızca işlem ücretlerine dayandırmak, işletme maliyetlerini azaltmak için merkezi bir yaklaşım benimseyen ve zincirler arası işlemler için daha düşük ücret talep edebilen zincirler arası köprüler lehine rekabeti önleyecektir. Her iki durumda da zincirler arası köprüler en önemli ölçüt olan güvenlik konusunda rekabet edemiyor.

Ek olarak, likidite köprüleri aynı zamanda daha az ticaret faaliyeti olan uzun kuyruklu varlıklar için de dezavantaj oluşturur (bu da onların likidite sağlayıcılarını çekme olasılıklarını azaltır). Uzun kuyruklu tokenleri (veya daha düşük çapraz zincir hacmine sahip yeni tokenları) ihraç edenlerin, ya AMM havuzları oluşturmaları ve LP'ler arasındaki ihraççı token takaslarının standart tokenleri ile yerel tokenleri (likidite köprüleri yoluyla çapraz zincir) kapsamak için likiditeyi yönlendirmeleri gerekecektir. veya LP'lerin varlığa likidite sağlamasına yönelik mali teşvikleri artırmak için zincirler arası köprü sağlayıcısıyla birlikte çalışmak.

Zincirler arası zayıf kullanıcı deneyimi

Likidite köprüleri, standart zincirler arası köprülere göre bir gelişmedir ancak kullanıcı deneyimi sorunları da vardır. Zincirler arası borsaların kaymasına ek olarak, köprünün hedef zincirdeki standart tokenlarla yapılan işlemleri karşılayacak yeterli likiditeye sahip olmaması nedeniyle kullanıcılar hedef zincirdeki zincirler arası işlemleri hemen tamamlayamayabilir. Bir kullanıcının token takas mesajı hedef zincire ulaştığında, köprünün varlık çiftinin ne kadar likit olacağını bilmesinin hiçbir yolu yoktur, dolayısıyla bu durum çoğunlukla kaçınılmazdır.

Bu durumda kullanıcının iki seçeneği vardır (ikisi de ideal değildir):

Çok zincirli DApp'ler, tek bir zincirler arası köprü seçerek, yani DApp'in dağıtıldığı her zincirde DApp belirtecinin standart belirteçlerini basarak, değiştirilemez çapraz zincir tokenları sorununu çözebilir. Standart köprülerin proje tokenlerini basması gibi, bu yaklaşım da küresel token arzının tutarlı kalmasını sağlamak için uzak zincirde basılan tokenlerin projenin ana zincirinde konuşlandırılan token sözleşmeleriyle eşlenmesini gerektirir. Zincirler arası köprü sağlayıcıları, tokenlerin basılmasını ve yakılmasını takip etmeli ve bu operasyonların ana zincirdeki token tedariği ile senkronize olmasını sağlamalıdır.

Bu temelde, zincirler arası tokenlerin değiştirilemez olması sorunu çözüldü; kullanıcılar onaylı bir zincirler arası köprü sağlayıcısı aracılığıyla çapraz zincirleme yaptıkları sürece, diğer çapraz zincirli tokenlarla her zaman 1'de çapraz zincirleme yapabilirler: 1 oran değişimi. Ayrıca bu yaklaşım, standart köprü modelindeki likidite bazlı çapraz zincir problemini de çözmektedir:

Şu anda, tek çapraz zincir köprü sağlayıcıları için token standartlarının bazı örnekleri arasında LayerZero'nun All-Chain Universal Token'ı (OFT), Axelar'ın Cross-Chain Token Service (ITS), Celer'in xAsset'i ve Multichain'in anyAsset'i yer alıyor. Bu örneklerin doğası gereği özel tokenlar olduğunu ve farklı zincirler arası köprü sağlayıcıları aracılığıyla gönderilen aynı tokenin çapraz zincirler tokenlarıyla uyumlu olmadığını belirtmekte fayda var; dolayısıyla bu ayrıntı aynı zamanda bu çapraz zincire de dikkat çekiyor. Zincir tokenlarının işlenmesiyle ilgili bazı sorunlar aşağıdaki gibidir:

Standart üçüncü taraf zincirler arası köprüleri kullanmanın dezavantajları

Sağlayıcı kilitleme

Bir veya daha fazla zincirde standart tokenlar oluşturmak için tek bir zincirler arası köprü sağlayıcısının seçilmesi, geliştiricileri sağlayıcıya kilitlenme riskine maruz bırakabilir. Her zincirler arası köprü sağlayıcısı, yalnızca kendi altyapısıyla (ve entegre ekosistem projeleriyle) uyumlu özel tokenlar oluşturduğundan, tek bir zincirler arası köprü sağlayıcısı, token verenleri belirli bir zincirler arası köprü hizmetine etkili bir şekilde kilitler ve başka bir çapraz zincire geçiş yapamaz. - gelecekte isteğe göre zincir köprü.

Zincirler arası köprü sağlayıcılarını değiştirmek mümkün olsa da, değiştirme maliyeti çoğu projenin bu yolu seçmesini engelleyecek kadar yüksektir.

Örneğin, bir geliştiricinin (ona Bob diyelim) Ethereum üzerinde bir token (BobToken) çıkardığını ve Optimism, Arbitrum ve Base üzerinde BobToken'in standart sürümünü basmak için LayerZero OFT'yi seçtiğini varsayalım. BobToken'in sabit arzı 1.000.000'dur ve LayerZero aracılığıyla basılan çapraz zincir tokenleri, dolaşımdaki toplam BobToken arzının %50'sini oluşturur.

İlk başta işler sorunsuz gitti, ta ki Bob, Axelar gibi zincirler arası hizmetler için rekabet ederek BobToken arasında köprü kurmaya karar verene kadar. Ancak Bob basitçe şunu söyleyemez: "BobToken'in Optimism, Base ve Arbitrum'daki standart tokenlarını basmak için Axelar ITS'ye geçmek istiyorum"; çünkü iki BobToken birbirinin yerine kullanılamayabilir (burada daha önce tanımladığımız sorunu yeniden ortaya koyuyoruz). Aynı zamanda, BobToken'in LayerZero sürümüyle entegre olan uygulamalar, BobToken'in Axelar sürümünü yedek olarak kabul edemeyebilir, bu da BobToken'in rakip tokenların bir arada bulunduğu çeşitli L2 zincirlerinde likidite dağılımına yol açacaktır.

Peki Bob'un bir dönüşüm uygulaması gerekiyorsa ne yapması gerekiyor?

Öncelikle Bob'un, çapraz zincir OFT tokenini yok eden ve Ethereum'daki BobToken'in kilidini açan LayerZero aracılığıyla basılan BobToken tokeninin paketini açmak için kullanıcıyı bir işlem göndermeye ikna etmesi gerekiyor. Kullanıcılar daha sonra Ethereum'da Axelar'ı kullanarak tokenlarını kilitleyebilir ve hedef zincirde BobToken'i (Ethereum'daki token sözleşmesi tedarikiyle eşlenen yeni standart token) alabilirler. Bu süreç DAO proje yönetimi ekibi için maliyetlidir ve önemli düzeyde koordinasyon ve operasyonel ek yük oluşturur; dolayısıyla orijinal sağlayıcıya bağlı kalmak genellikle en güvenli seçenektir.

Öte yandan, çapraz zincir köprü sağlayıcısının anlaşmanın şartlarına uymaması, sınırlı bir özellik paketine sahip olması, geniş ekosistem entegrasyonundan yoksun olması, zayıf bir kullanıcı deneyimine sahip olması vb. durumlarda Bob gibi geliştiricilerin de başı dertte olabilir. Satıcı kilidi, geliştiricilerin geçiş yapmasını önleyecektir. Bu süre zarfında çapraz zincir köprü sağlayıcısı, çapraz zincir BobToken'in kullanıcı oranını açık bir neden olmaksızın sınırlamak, zincirler arası ücretleri artırmak ve hatta zincirler arası işlemleri sansürlemek gibi keyfi şeyler de yapabilir.

Protokol egemenliğinin kaybı

Sağlayıcı kilitlenmesiyle ilgili yukarıdaki sonuç, standart üçüncü taraf zincirler arası köprülerin kullanılmasıyla ilgili başka bir sorunu vurgulamaktadır: token verenler, daha fazla kolaylık ve kullanıcı deneyimi iyileştirmeleri için standart zincirler arası tokenlerin kontrolünden fedakarlık etmektedir. Örneğin, Ethereum'daki BobToken tamamen Bob'un kontrolündedir çünkü temeldeki ERC-20 token sözleşmesini o kontrol etmektedir, ancak Optimism, Arbitrum ve Base'deki BobToken, bu alanlardaki varlıkların sahibi olan LayerZero tarafından kontrol edilmektedir. BobToken standart tokeni blockchain üzerinde serbest bırakılır.

Bob, LayerZero'nun standart tokenleri yerel tokenların orijinal tasarımıyla tutarlı tutmasını beklese de, bu her zaman böyle değildir. En kötü senaryoda BobToken, Ethereum'da BobToken'in İyimserlik konusunda olduğundan çok farklı davranabilir, çünkü zincirler arası köprü sağlayıcısı token sözleşmesinin tamamen farklı bir versiyonunu uygular - bu da protokol kullanıcılarına hedefler nedeniyle sorunlar getirir. protokol geliştiricileri ile zincirler arası köprü sağlayıcılarının çıkarları ve çıkarları farklılaşabilir.

Zincirler arası köprü arızası riski yüksektir

İlk çözümde, tokenlar her zincirin standart köprüsü aracılığıyla çapraz zincirlenir ve token verenin zincirler arası bir köprüyü etkileyen güvenlik açıklarından kaynaklanan riski o köprüyle sınırlıdır. Örneğin, bir bilgisayar korsanının bir likidite köprüsünü aşmayı başardığını ve teminat yatırmadan sınırsız sayıda sarılmış token bastığını varsayalım. Bu durumda, yalnızca likidite havuzundaki sarılmış varlığın maksimum kullanılabilir likiditesini çekebilir (örnek: Optimism'de Mint cUSDT → cUSDT'yi standart opUSDT ile değiştirin → opUSDT'yi hızlı çapraz zincir yoluyla Ethereum'a çekin → Ethereum Exchange'de yerel USDT pazarı).

Üçüncü taraf zincirler arası köprü modelinde, token veren için, ortağın çapraz zincir köprüsünü etkileyen bir güvenlik açığının neden olduğu risk, etkilenen köprü tarafından konuşlandırılan uzak zincirde saldırgan tarafından basılan toplam token miktarına eşdeğerdir. . Bu tamamen mümkündür çünkü bir zincirdeki standart tokenlar, diğer zincirlerde 1:1 oranında verilen standart tokenlarla değiştirilebilir. Örnekler aşağıdaki gibidir:

Bir saldırganın B zincirindeki üçüncü taraf zincirler arası köprüyü tehlikeye attığını ve teminat yatırmadan 1000 token (tokenlar başlangıçta A zincirinde yayınlanmıştı) bastığını varsayalım. Saldırganın B zincirindeki tokenleri ana zincir sözleşmesiyle eşlenmediğinden A zincirinden geri alınamaz. Bununla birlikte, zincirden C'ye çapraz olarak 1000 zincir B tokenını 1000 zincir C tokenıyla değiştirebilir. Bu standart çapraz zincir tokenlarının hepsinin uyumlu ve değiştirilebilir olduğunu, çünkü aynı Çapraz zincir köprü hizmetinden geldiklerini unutmayın. C Zinciri tokenleri ana zincir sözleşmesiyle eşleştirilir çünkü bunlar, tokenlarını Zincir A'ya (tokenin ana zinciri) kilitleyen kullanıcılar tarafından meşru bir şekilde basılmıştır; bu, bir saldırganın C Zinciri üzerindeki tokenları yok etmesine ve yerel token üzerindeki A Zincirini geri çekmesine olanak tanır. Saldırgan nihayet CEX'te token ticareti yaparak saldırıyı tamamlayabilir.

Hedef zincirdeki belirteçlerin özel işlevleri kayboluyor

Üçüncü taraf bir zincirler arası köprü kullanırken, token verenler genellikle oylama delegasyonu (ZK), yeniden temellendirme mekanizmaları (stETH, USDM), Transfer ücreti işlevleri gibi orijinal dağıtımlarında var olan özel işlevleri veya token davranışı uygulama yeteneklerini de kaybederler. , kara liste ve beyaz liste işlevleri (USDT, USDC), duraklatılabilir transferler ve özel basım kuralları veya izinleri vb. Bu ortak token işlevleri, zincirler arası köprü sağlayıcıları nedeniyle genellikle çıkarılır. Genellikle standartlaştırılmış ERC-20 kullanılır. Orijinal token uygulamasında mevcut olan özel işlevleri desteklemeyebilecek sözleşmeleri uygulayın.

Bu özelliklerin eksikliği, farklı zincirlerdeki tokenların işleyişinde tutarsızlıklara yol açacak ve bu da bu özel özelliklere dayanan entegre uygulamalara zarar verebilecektir. Zincirler arası tokenların standardizasyonunu teşvik etmek, zincirler arası köprü sağlayıcıları açısından işlemleri basitleştiriyor gibi görünse de aslında bu yaklaşım, tokenların orijinal işlevlerini zayıflatır ve ihraççıların bunları uygulamalarının kapsadığı alanlarda kullanmasını engelleyebilir. Çok zincirli ekosistemin tamamında token davranışının tutarlılığını koruyun.

Sınırlı desteklenen zincirler

Token ihraççıları, seçtikleri zincirler arası köprü sağlayıcının ağ kapsamına ve genişleme planlarına güveniyor. Zincirler arası köprü sağlayıcısı, token veren kuruluşun genişlemek istediği belirli blockchain ağını desteklemiyorsa ideal olmayan iki seçenekle karşı karşıya kalır:

Bu sınırlama, protokolün büyüme stratejisini ve gelişen zincirlere yeni kullanıcılar çekme yeteneğini ciddi şekilde etkileyebilir. Çapraz zincir köprü sağlayıcılarının popüler zincirleri desteklemeye öncelik verebileceğini ve token verenler için stratejik olabilecek daha küçük veya daha yeni ağları göz ardı edebileceğini unutmayın.

Bu sınırlama, protokolün büyüme stratejisini ve gelişen zincirlere yeni kullanıcılar çekme yeteneğini ciddi şekilde etkileyebilir. Çapraz zincir köprü sağlayıcılarının popüler zincirleri desteklemeye öncelik verebileceğini ve token verenler için stratejik olabilecek daha küçük veya daha yeni ağları göz ardı edebileceğini unutmayın.

Zincirler arası token adresleri tutarsız

Teknoloji yığınının özellikleri nedeniyle (CREATE2'yi desteklememek gibi) , üçüncü taraf zincirler arası köprü sağlayıcıları, her zincirde zincirler arası tokenleri dağıtmak için farklı adresler kullanabilir. Adres tutarlılığının olmaması da birçok kullanıcı deneyimine neden olmuştur. sorunlar:

Belirteç verme köprüsü aracılığıyla standart belirteçlerin ihracı

Yukarıda belirtilen çözümlere ek olarak, geliştiriciler projenin tokenlarının zincirler arası dağıtımı üzerinde maksimum kontrolü sürdürmek isterlerse, tokenlerin "güvenilir" olarak tanımlanan uzak zincirdeki standart token versiyonlarının verilmesini yönetebilirler. "herhangi bir token veren" çünkü her çapraz zincir token versiyonunun değeri, token'ın orijinal versiyonunun kaynak zincirde verilmesinden sorumlu protokol tarafından kilitlenen token değeriyle yakından bağlantılıdır.

Bu yaklaşımın işe yaraması için, token ihraççılarının, tokenlerin zincirler arasında basılmasını ve yakılmasını yönetmek için altyapı kurması gerekir (bu arada, standart bir haritalama yoluyla küresel arzın senkronize tutulmasını sağlar).

Token yaratıcıları tarafından yayınlanan standart (yerel) tokenlerin iyi bilinen örnekleri MakerDAO'nun Teleport'u ve Circle'ın Zincirler Arası Aktarım Protokolü'dür (CCTP) . Teleport, kullanıcıların standart DAI'yi Ethereum ve çeşitli Ethereum toplamaları arasında taşımasına olanak tanır. DAI bir zincirde yok edilir ve aynı anda hedef zincirde basılabilir. CCTP benzer şekilde çalışır ve yerel USDC'nin (Circle tarafından ihraç edilen) bir imha ve basım mekanizması aracılığıyla zincirler arası transferini sağlar. Her iki durumda da, token ihraççısı standart tokenlerin basılmasını ve yakılmasını kontrol eder.

Bu yaklaşım, protokole çapraz zincirler üzerinde tam kontrol sağlar. Aynı tokenin değiştirilemezliği sorununu en verimli şekilde çözer - tokenin yalnızca bir standart sürümü vardır (hedef zincirdeki ihraççı tarafından basılmıştır), bu da kullanıcıların ekosistemdeki herkesin aynı tokena sahip olmasını sağlar. jeton kullanırken deneyim.

Bu yaklaşımı kullanarak uygulamalar aynı ekosistemdeki resmi olmayan zincirler arası tokenlerin neden olduğu likidite parçalanma sorunlarını da ortadan kaldırabilir. Geliştiriciler ayrıca daha sağlam zincirler arası uygulamalar (örneğin, zincirler arası takaslar ve zincirler arası borç verme) oluşturabilirler çünkü standart token ihraççı köprüleri, zincirler arasında sermaye açısından verimli, kesintisiz ve güvenli token transferlerine olanak tanır.

Tabii ki, bu tür bir çözümün bazı dezavantajları da var. Bu model yalnızca standart tokenleri zincirler arasında dağıtmak için yeterli sermayeye sahip olanların yanı sıra gerekli altyapıyı (oracle, koruyucular vb.) koruma yüküne sahip olanlar için uygundur. zincirler arası basım ve imha projesi için. Aynı zamanda bu, zincirler arası varlıkların güvenliğinin protokolün güvenlik modeliyle yakından entegre edilmesi gibi ideal olmayan bazı etkileri de beraberinde getiriyor.

Nesnel olarak konuşursak, bu ilişki (protokol tokeninin zincirler arası versiyonu ile protokolün güvenliği arasındaki ilişki) dostudur çünkü standart token versiyonunu destekleyen yerel tokenın güvenliği zaten protokolün güvenliğine bağlıdır, böylece kullanıcılar ve harici geliştiriciler yeni güven varsayımları üstlenmeyeceklerdir. Bu özellikle Circle ve Maker (şimdi Sky) gibi ihraççılar tarafından işletilen stabilcoin köprüleri için geçerlidir - kullanıcılar zaten stabilcoin ihraççısının, stabilcoin'i fiat para birimiyle değiştirme maliyetini karşılamak için yeterli varlığa sahip olduğuna güveniyor ve bu nedenle stabilcoin köprüsüne güvenmiyor zor.

Bu aynı zamanda merkezi bir başarısızlık noktasını da temsil ediyor; token ihraççısının köprü altyapısı tehlikeye girerse, çok zincirli ekosistemde dolaşan tüm standart tokenların değeri tehdit altında olur. Bu aynı zamanda yalnızca merkezi saklayıcıların (USDC'deki Circle gibi) standart zincirler arası token yayınlamaya yönelik bu modeli gerçek anlamda uygulayabileceği anlamına gelir.

Bu aynı zamanda merkezi bir başarısızlık noktasını da temsil ediyor; token ihraççısının köprü altyapısı tehlikeye girerse, çok zincirli ekosistemde dolaşan tüm standart tokenların değeri tehdit altında olur. Bu aynı zamanda yalnızca merkezi saklayıcıların (USDC'deki Circle gibi) standart zincirler arası token yayınlamaya yönelik bu modeli gerçekten uygulayabileceği anlamına gelir.

Zincirler arası varlık değiştirilebilirliği, şüphesiz Rollup'ın birlikte çalışabilirliğinin önemli bir parçasıdır ve kullanıcıların farklı zincirler arasındaki varlık aktarımı deneyimini etkiler. Aynı zamanda, belirli kullanım durumları bu özelliğe bağlı olduğundan, tokenlerin zincirler arasında ve uzak zincirlerde değiştirilebilir kalma yeteneği de geliştirici davranışını etkileyecektir.

Değiştirilemez çapraz zincir token sorununu çözmek için endüstri, yerel (uygulanan) köprüler aracılığıyla standart token basmak, birden fazla zincirde standart token basmak için özel üçüncü taraf köprüler kullanmak ve aynı zamanda protokol kullanmak da dahil olmak üzere farklı çözümler önerdi. Tokenların hareketini kolaylaştırmak ve takas edilebilirliği korumak için sahip olunan köprüler.

Bu yaklaşımlar birçok spesifik sorunu çözse de hepsini çözemezler ve bunları zincirler arası varlıkların takas edilebilirliğini sağlamak için kullanmak, ideal olmayan bazı ödünleşimler yapmayı gerektirir. Peki daha iyi bir yol bulabilir miyiz? Cevap evet.

ERC-7281'in, protokollerin güvenlikten, egemenlikten veya kullanıcı deneyiminden ödün vermeden birden fazla zincirde standart belirteçleri verimli bir şekilde dağıtmasına olanak tanıyan zincirler arası varlık takası için yeni bir çözüm olduğuna inanıyoruz.

ERC-7281'in benzersiz tasarımı, birden fazla (beyaz listeye alınmış) çapraz zincir köprüsünün, desteklenen her zincirde protokol belirteçlerinin standart sürümlerini basmasına olanak tanırken, protokol geliştiricilerin her çapraz zincir köprüsü başına basım sınırlarını dinamik olarak ayarlamasına olanak tanır. Bu özellik, likidite parçalanması, teşvik tutarlılığı, kullanıcı deneyimi sorunları, zincirler arası köprü güvenliği ve zincirler arası tokenların özelleştirilebilirliği dahil olmak üzere, çok zincirli standart tokenlara yönelik tarihsel önerilerle ilgili birçok sorunu çözmektedir.

Bu nedenle, zincirler arası varlık değiştirilebilirliği raporunun bir sonraki bölümünde ERC-7281'i (xERC-20 olarak da bilinir) ayrıntılı olarak tanıtacağız, xERC-20'nin çok işlevliliğini diğer çok zincirli standartla karşılaştırarak analiz edeceğiz. token tasarımlarını zincirleme standart token yaklaşımını inceleyin ve xERC-20 token standardının geliştiricilere ve kullanıcılara nasıl fayda sağlayabileceğini inceleyin.

Devam edilecek.