Katman 2 dönemindeki Likidite insanları enayi yerine koymak sorunu araştırması

Ethereum'un Layer 2 merkezli genişleme çözümlerine geçişi ve RaaS gibi araçların yükselişi ile birlikte, birçok kamu zinciri hızla gelişiyor. Birçok kuruluş, farklı çıkarları temsil etmek ve daha yüksek bir değerleme aramak için kendi zincirlerini kurmayı umuyor. Ancak, birçok kamu zincirinin ortaya çıkması, ekosistem gelişiminin kamu zincirlerinin hızına ayak uydurmasını zorlaştırıyor ve bu da birçok projenin TGE sırasında değer kaybetmesine neden oluyor.

OP Stack sayesinde, bir işlem platformu kendi Base Katman 2'sini tanıttı, başka bir işlem platformu Ink'i yayınladı; ZK teknolojisi sayesinde, bir platform XLayer'ı tanıttı; Sony Soneium'u, LINE ise Kaia'yı piyasaya sürdü. Artık bir zincir inşa etmenin maliyet ve teknik engelleri büyük ölçüde azalmıştır, OP Stack temelinde bir zincir işletmenin maliyeti aylık yaklaşık 10,000 dolardır.

Gelecek, çoklu zincirlerin bir arada var olduğu bir dönem olacaktır. Bu Katman 2 zincirlerinin EVM uyumluluğunu seçerek birbirleriyle etkileşimde bulunmaları mümkün olsa da, arkasındaki Web2 varlıklarının çok sayıda aşağı akış uygulamasına sahip olması nedeniyle, aynı zincir üzerinde uygulama inşa edip uzlaşma sağlamakta zorlanacaklardır.

Mevcut çoklu zincir ekosistemi yeni bir meydan okumayı beraberinde getiriyor: Likidite ve durumun dağılması. Çoklu zincirlerin varlığı kaçınılmaz olduğundan, birbirleriyle çalışabilirlik keşfedilmesi ve çözülmesi gereken bir alan. Şu anda birçok likidite çözümü var, örneğin zincir soyutlaması, niyet, Temizleme İcrası, Yerel Çapraz Zincir, ZKSharding, ancak bunların temel özleri aynıdır.

Kullanmakta olduğumuz endüstride daha çok kabul gören Cake mimarisi ile yukarıdan aşağıya zincirler arası soyutlamanın temel bileşenlerini tanıtıyoruz:

Uygulama Katmanı (Application Layer)

Bu, kullanıcıların doğrudan etkileşimde bulunduğu katmandır ve likidite çözümlerinin en soyut katmanıdır çünkü likidite dönüşüm detaylarını tamamen gizler. Uygulama katmanında, kullanıcılar ön yüz arayüzü ile etkileşime girer ve temel likidite dönüşüm mekanizmalarını mutlaka anlamazlar.

İzin Katmanı (Permission Layer)

Uygulama katmanının altında bulunan kullanıcı, cüzdanını dApp'e bağlayarak ve teklif talep ederek işlem niyetini karşılar. Buradaki "niyet", kullanıcının beklediği nihai işlem sonucunu (yani çıktıyı) ifade eder, işlemle ilgili belirli bir yürütme yolu değil.

Hesap Yönetimi ve Soyutlama Katmanı (Key Management and Account Abstraction)

Çoklu zincir ortamının varlığı nedeniyle, her bir zincirin benzersiz hesap yapısını korumak için farklı zincirlere uyum sağlayan bir hesap yönetimi ve soyutlama sistemi gereklidir. Örneğin, SUI'nin nesne merkezli hesap sistemi EVM'den tamamen farklıdır. One Balance, bu alandaki temsilci projedir ve güvenilir bir hesap sistemi inşa etmiştir, zincirler arası konsensüs oluşturulmasına gerek kalmadan, mevcut hesap sistemleri arasında güvenilir taahhütler yeterlidir. Near Account, kullanıcılar için çoklu zincir hesap cüzdanları oluşturarak soyutlama yönetimini gerçekleştirir, bu da kullanıcı deneyimini büyük ölçüde optimize eder ve UX'in parçalanmasını azaltır. Ancak, likidite açısından esas olarak mevcut kamu zincirleri entegre edilmiştir.

Çözüm Katmanı (Solver Layer)

Bu katman, kullanıcıların işlem niyetlerini almak ve gerçekleştirmekle sorumludur. Solver rolü burada daha iyi bir kullanıcı deneyimi sunmak için rekabet eder; buna daha hızlı işlem süreleri ve yürütme hızları dahildir. Bu temele dayanarak, niyete dayalı projeler çeşitli niyet odaklı çözümler geliştirmiştir. Bu tür niyetlerin türevleri olan Predicate bileşeni, belirli kurallar altında kullanıcı niyetlerini gerçekleştirebilir.

Hesaplama Katmanı (Settlement Layer)

Bu, kullanıcı niyetlerini gerçekleştirmek için kullanılan ara katman olan çözüm katmanıdır. Likidite ve durum dağıtımı çözümlerinin temel bileşenleri şunları içerir:

• Oracle: Diğer zincirlerdeki durum bilgilerini almak için kullanılır.
• Köprüler: Zincirler arası bilgi ve likidite aktarımından sorumludur.
• Ön Onaylama (Pre-Confirmation): Zincirler arası onay süresini kısaltmak.
• Veri Erişilebilirliği (DA): Verilerin erişilebilirliğini sağlar.

Ayrıca, tüm çok zincirli sistemin verimli çalışmasını sağlamak için zincirler arası likidite, nihai onay (Finality), Katman 2 kanıtlama mekanizması gibi faktörlerin de dikkate alınması gerekmektedir.

Şu anda piyasada likidite ayrışmasını çözmek için birçok çözüm bulunmaktadır. Çok sayıda çözümü inceledikten sonra, esas olarak bu birkaç yöntem olduğunu keşfettik:

1. RaaS merkezli: OP Stack gibi Rollup çözümleri üzerinden, belirli bir ortak sıralayıcı ve çapraz zincir köprüsü ekleyerek OP Stack üzerinde inşa edilen Rollup'ların ortak likidite ve durumunu desteklemeyi amaçlamaktadır. Bu, likidite ve durum dağınıklığını daha yüksek bir düzeyde çözmeyi umuyor. Burada daha ayrıntılı bir şekilde, ayrı bir tasarım ortak sıralayıcı vardır; bu çözüm daha çok Katman 2 için tasarlanmıştır ve evrensel bir uygulamaya sahip değildir.

2. Hesap merkezli: Çoklu blok zinciri protokollerinde işlem imzalama ve yürütme için "zincir imzası" olarak adlandırılan bir teknoloji ile desteklenen, tüm zincirleri kapsayan bir hesap cüzdanı oluşturun. Bunun temel bileşeni, kullanıcıların çoklu zincir işlemleri için imza atmasını sağlamak üzere MPC ağıdır. Bu çözüm, UX parçalanma sorununu büyük ölçüde çözmesine rağmen, geliştiriciler için karmaşık bir arka uç uygulaması ile ilgilidir ve esasen likidite ve durum dağınıklığını çözmemektedir.

3. Zincir dışı niyet ağı etrafında: yani "Giriş" pasta şemamızdaki Çözücü Ağı, temel olarak kullanıcının niyeti Çözücü ağına göndermesidir, Çözücü bu rolü üstlenerek teklif yarışına girer, en iyi tamamlama süresi ve işlem fiyatını sağlar, bu Çözücüler AI Ajansı, CEX, Piyasa Yapıcı veya entegre protokolün kendisi olabilir. Niyetlerin teorik olarak herhangi bir zorlukta karmaşık çok zincirli işlemleri gerçekleştirebilmesi mümkün olsa da, uygulama açısından yeterli likidite Çözücülerin desteğine ihtiyaç vardır ve zincir dışı bazı taleplerle karşılaşıldığında, Çözücülerin dolandırıcılık yapma olasılığı vardır. Eğer dolandırıcılık kanıtı gibi yöntemler devreye alınırsa, Çözücü Ağı'nın uygulanabilirliği daha zor hale gelir ve Çözücü işletmenin eşiği de daha yüksek olur.

4. Zincir üzerindeki Likidite ağına odaklanma: Bu yön, özellikle çapraz zincir likidite sorunlarını optimize etmeye yöneliktir, ancak diğer zincir üzerindeki durum dağılımı sorununu çözmemektedir. Temel amacı, tüm zincir likiditesini paylaşmak için uygulamaların inşa edileceği bir likidite katmanı oluşturmaktır.

5. Zincir üstü uygulamalara odaklanma: Bu tür uygulamalar, yüksek likidite uygulamaları oluşturmak için büyük MM veya üçüncü taraf uygulamalarını entegre ederek inşa edilir. Bu tür projeler, karmaşık çapraz zincir süreçlerini yönetmeyi gerektirir ve geliştiriciler için son derece yüksek gereksinimler vardır, bu nedenle hacker saldırıları gibi olayların meydana gelmesi de son derece kolaydır.

Likidite sorununu çözmek çok önemli bir konu. Finans dünyasında genellikle likidite her şeyi temsil eder. Eğer dağınık olan tüm zincir likiditesini bir araya getiren entegre bir likidite platformu oluşturulabilirse, çok büyük bir potansiyele sahip olacaktır ve biz de birçok farklı çözümü inceledik.

Yukarıdaki iki kategoride, pasta yapısına göre, Settlement Layer en atomik çözüm seviyesidir. Bu atomik çözümler üzerine inşa edilen daha soyut bir katman olan Solver Layer, Permission Layer ve Application Layer bulunmaktadır. Yukarıda listelenen, farklı yönlerden soyut veya Likidite çözümleri inşa eden çeşitli katmanlar, yukarı ve aşağı akış ilişkisi olarak anlaşılabilir. Ancak bu çözümler hala atomik çözüm seviyeleri değildir; tüm Likidite insanları enayi yerine koymak sorunları, birçok karmaşık türev probleminin ortaya çıkmasına yol açmaktadır. Bu nedenle, karşılıklı işlem yapabilirlik için çeşitli çözümler geliştirilmiştir. Ancak özünde bu bileşenlere bağımlı olunması gerekmektedir. Şimdi, birkaç tipik zincir soyutlama kavramı projesini tartışacağız ve her birinin Likidite insanları enayi yerine koymak sorununu kendi bakış açılarından nasıl çözdüklerine bakalım.

INFINIT, DeFi alanında bir RaaS hizmeti oluşturdu; bu hizmet, DeFi protokollerinin doğrudan inşa etmek için ihtiyaç duyduğu bileşenleri, örneğin Oracle, Havuz Tipi, IRM, Varlık vb. sağlamanın yanı sıra, hemen kullanılabilir Kaldıraçlı İşlem ve Getiri Stratejisi gibi bileşenler de sunmaktadır. Diğer uygulama inşa uçlarına eşdeğerdir, ancak nihai likidite Infinit'in likidite katmanında yer almaktadır. Ancak, şu anda temel çalışma prensiplerini henüz açıklamamıştır.

Khalani, üç temel bileşen inşa etmiştir: Intent uyum katmanı, Validity ve genel uzlaşma katmanı. Dış uygulamalar veya niyet katmanı, Khalani'ye niyet yayınlayabilir; ardından Khalani'nin Intent uyum katmanı, dış niyetleri protokol Solver'ın tanıyabileceği bir formata dönüştürebilir; kullanılan standart format ise Validity dilidir. Khalani düğümü, nihai sonuçları genel uzlaşma katmanına iletmek için çapraz zincir köprüleri, hızlı uzlaşma teknolojileri gibi yöntemleri kullanmaktan sorumludur.

Liquorice, bir merkezsiz uygulama olup, açık artırmaya dayalı fiyat keşfi ve tek taraflı likidite havuzları sağlar. Liquorice'in temel misyonu, profesyonel ticaret firmalarına etkin envanter yönetim araçları sunmak ve kullanım niyetiyle işlem gerçekleştirdiğinde ana DeFi protokollerine kolayca bağlanmaktır. Bu arada, Liquorice, borç verme işlemleri için bir borç verme piyasası yaratmıştır. Bu uygulama, işlemin kendisine daha fazla odaklanmaktadır.

Xion, Comet BFT konsensüs protokolü üzerine inşa edilmiştir. Kullanılan çapraz zincir iletişimi, Cosmos IBC'ye dayanmaktadır, bu nedenle diğer çapraz zincir köprülerden daha yerel ve güvenlidir.

=nil; Foundation, ZK teknolojisini kullanarak Ethereum ana ağını yatay olarak genişletmek için zkSharding çözümünü önerdi. Bu çözüm, parçalama ile işlem paralel işleme yapar ve ZKP üretir, ana parça ise verileri doğrular, Ethereum ile iletişim kurar ve tüm doğrulayıcılar arasında ağ durumunu senkronize eder. Ana parça ayrıca, yürütme parçalarında doğrulayıcıların ve hesapların dağılımını yönetir. Doğrulama komitesinin kullandığı konsensüs protokolü de Hotstuff'tır; bu, en son paralel yürütme projelerinde yaygındır. =nil; L2, protokole parçalar arası iletişimi başlangıçtan itibaren entegre etti.

Ethereum de bu çapraz zincir likidite sorununu çözmek için çalışıyor. Şu anda bazı önde gelen borsa platformları, ERC7683 standartını ilk olarak açıkça destekliyor. Bunun kullandığı da, niyet temelli çapraz zincir yöntemidir. Temel hedefi, çapraz L2 ve yan zincirler için genel bir standart oluşturarak, sipariş ve uzlaşma arayüzlerini standartlaştırmak ve kesintisiz çapraz zincir yürütmesini sağlamaktır. Bunun ana çekirdeği, bir Filler olarak adlandırılabilecek, zincir soyutlaması içindeki Solver rolüdür.

OP Stack, bilgi iletimi ve Sequencer merkeziyetsizliği sorunlarını bir kerede çözmek için tam bir çok Katman 2 çözümü tasarlayarak çalışır. OP Stack mimarisini kullandığınızda, otomatik olarak çapraz zincir sözleşmeleri dağıtılır ve sahte çapraz zincir bilgilerini iletmemek için bir Supervisor bulunur.

Karmaşık ve çok sayıda çözüm önerisi içeren bir alan olan çapraz zincir likidite sorunlarını çözmek oldukça zor bir meseledir. Layer2 çözümleri, Ethereum içindeki çapraz zincir mesajlarını, özellikle ERC-7683'ü kullanarak çözmekte ve ayrıca OP Stack gibi Layer2 çözümleri, paylaşılan Sequencer kullanarak bu sorunu çözmektedir. Layer2 bağlamının dışında, tüm Layer1'ler de likidite, durum ve kullanıcı deneyimi kopukluğu sorunlarıyla karşı karşıyadır; likiditeye özel uygulamalar etrafında dönen çözümler olduğu gibi, Solver Network'ün zincir dışı çözümleri ve NEAR gibi hesap merkezli çözümler de bulunmaktadır, ancak bu da Solver gibi zincir dışı bir role dayanmayı gerektirir.

Köprü akıcılığı, durum ve kullanıcı deneyiminin parçalanması, tüm blockchain endüstrisinin sorunudur. Bunu genel bir perspektiften ele alırsak, daha soyut ve zincir soyutlamasına benzer bir yöntemle yaklaşmak gerekir. Bu, gerçekten de şuna eşdeğerdir.