Starknet ve Madara uygulama zincirleri için paylaşılan sıralayıcılar

Giriş

Bugün, uygulama zincirleri için Madara'yı denemeye başlayan projeleri zaten görüyoruz. Pragma, Kakarot, Mangata Finance ve Dojo sadece birkaç örnektir. Çoklu zincirli geleceğe ve zk ölçeklendirmenin gücüne inandığımız sürece gelecekte bu projelerin çok daha fazlasını göreceğiz. Ancak uygulama zincirlerinin sayısının artması aynı zamanda şu soruları da gündeme getiriyor:

1. Ademi merkeziyetçilik
2. Şekillendirilebilirlik
3. Geliştirme deneyimi

Bu yazıda uygulama zincirinin çok olmasından dolayı ortaya çıkan sorunları açıklamaya çalışacağım ve aynı zamanda Madara ve Starknet için zarif ve optimal olduğunu düşündüğüm soruna olası bir çözüm ortaya koymaya çalışacağım. Uygulama zincirleri ve paylaşılan sıralama konusunda zaten bilgiliyseniz, "Bir dakika, Polkadot yeniden başlıyor" bölümüne atlamaktan çekinmeyin.

100 uygulama zincirinde ne olur?

Diyelim ki artık Ethereum'a yerleşen 100 farklı uygulama zincirinin olduğu bir gelecekteyiz. Bunun yol açacağı tüm sorunları ele alalım.

Parçalanmış ademi merkeziyet

Her uygulama zincirinin merkeziyetsizliği kendi başına çözmesi gerekecek. Artık uygulama zincirlerinin merkezi olmayan hale getirilmesi L1'lerinki kadar gerekli değil çünkü temel olarak güvenlik için L1'lere güveniyoruz. Ancak canlılığı sağlamak, sansüre karşı dayanıklılık sağlamak ve tekelci avantajlardan (örneğin yüksek ücretler) kaçınmak için hâlâ ademi merkeziyetçiliğe ihtiyacımız var. Ancak şunu da unutmamak gerekir ki, eğer her uygulama zinciri merkeziyetsizliği kendi yöntemiyle çözerse, bu durum çok hızlı bir şekilde doğrulayıcı kümelerinin parçalanmasına yol açacaktır. Her uygulama zincirinin yeni doğrulayıcıları bünyesine katmak için ekonomik teşvikler geliştirmesi gerekecek. Ayrıca doğrulayıcıların hangi istemcileri çalıştırma konusunda rahat olduklarını seçmeleri gerekir. Bunun, geliştiricilerin kendi uygulama zincirlerini başlatmaları (yalnızca bir işlem olan akıllı sözleşmeyi dağıtmak yerine) için yarattığı büyük giriş engelinden bahsetmiyorum bile.

Şekillendirilebilirlik

Şekillendirilebilirlik esas olarak uygulamalar arası etkileşim anlamına gelir. Ethereum veya Starknet'te bu sadece başka bir sözleşmenin çağrılması anlamına gelir ve diğer her şey protokolün kendisi tarafından gerçekleştirilir. Ancak uygulama zincirleri ile bu çok daha zor hale geliyor. Farklı uygulama zincirlerinin kendi blokları ve fikir birliği mekanizmaları vardır. Başka bir uygulama zinciriyle etkileşime girmeye çalıştığınızda, fikir birliği algoritmasını ve kesinlik garantilerini dikkatlice incelemeniz ve buna göre zincirler arası bir köprü (doğrudan zincire veya L1 aracılığıyla) kurmanız gerekir. Farklı tasarımlara sahip 10 uygulama zinciriyle etkileşime geçmek istiyorsanız bunu 10 farklı kez yaparsınız.

Geliştirme deneyimi

Merkezileşmeyi ve köprü kurmayı çözmek kolay değil. Eğer bu her uygulama zinciri için bir gereklilikse, sıradan akıllı sözleşme geliştiricilerinin kendi uygulama zincirini oluşturması çok zor olacaktır. Üstelik her uygulama zinciri bu sorunları kendi yöntemleriyle çözmeye çalışırken, yakında farklı zincirlerin farklı standartlar takip ettiğini ve ekosisteme katılmayı daha da zorlaştırdığını göreceğiz.

Paylaşılan Sıralayıcılar bunu çözebilir

Uygulama zinciri alanını takip ediyorsanız "paylaşılan sıralayıcılar" terimini duymuş olabilirsiniz. Yukarıda belirtilen sorunları çözmeyi amaçlayan, tüm zincirler için ortak bir doğrulayıcı kümesine sahip olma fikridir. Bu nasıl çalışır.

Paylaşılan Merkezi Olmayanlaştırma

Paylaşılan sıralayıcıların özü, her uygulama zinciri veya L2 için farklı bir doğrulayıcı grubuna sahip olmanıza gerek olmamasıdır. Bunun yerine, tüm zincirler için blokları sıralayan, gerçekten verimli ve merkezi olmayan bir doğrulayıcı kümesine sahip olabilirsiniz! 100 farklı uygulama zincirinden gelen işlemleri içeren blokları hayal edin. Her uygulama zinciri için yürütme motorlarını yönetebilmeniz gerektiğinden, bunun sıralayıcıyı gerçekten şişireceğini düşünüyor olabilirsiniz.

Ama yapmıyorsun!

Günümüzde hemen hemen her sıralayıcı merkezi olduğundan, sıralayıcının işlemleri toplayan, sipariş eden, yürüten ve sonuçları L1'e gönderen tek bir uygulama olduğu düşünülmektedir. Ancak bu işler birden fazla modüler bileşene ayrılabilir. Bu açıklama uğruna onları ikiye ayıracağım.

1. Sipariş motoru: İşlemlerin belirli bir sıraya göre sıralanmasından sorumludur. Bu sipariş, sipariş motoru tarafından kararlaştırıldıktan sonra takip edilmesi GEREKİR. Bu, L1'de bu emrin yerine getirilmesi ve L1 doğrulayıcılarının işlemlerin gerekli sırayla yürütülüp yürütülmediğini kontrol etmeye zorlanmasıyla gerçekleştirilir.
2. Toplama motoru: Toplama motoru temelde toplamanın yaptığı her şeydir; kullanıcılardan işlemleri toplamak, bunları yürütmek, kanıt oluşturmak ve L1'deki durumu güncellemek. İdeal olarak bu daha fazla bileşene ayrılabilir ancak bu yazı için bundan kaçınacağız.

Burada, sıralama motoru paylaşılan sıralayıcıdır ve toplama motoru temelde tüm toplama mantığıdır. Yani işlem yaşam döngüsü şöyle görünüyor

Paylaşılan sıralayıcılar temel olarak işlemleri toplamalar arasında sıralar ve bunları L1'e gönderir. Dolayısıyla, paylaşılan sıralayıcı setini merkezileştirerek, temel olarak o sıralayıcı setine bağlı tüm toplamaları merkezi olmayan hale getirmiş olursunuz! Paylaşılan sıralayıcıların çalışmasına ilişkin daha ayrıntılı bir fikir edinmek içinEspresso'nun bu harika<a href="https://hackmd.io/ @EspressoSystems /EspressoSequencer"> 17. makalesine de başvurabilirsiniz.

Şekillendirilebilirlik

Şekillendirilebilirliğin en önemli sorunlarından biri, diğer uygulama zincirinde işlemin ne zaman sonuçlandığını anlamak ve buna göre zincirinizde aksiyon almaktır. Ancak paylaşılan sıralayıcılarla, her iki oluşturulabilir toplama da blokları birbiriyle paylaşır. Dolayısıyla, bir işlem B toplamasında geri alınırsa bloğun tamamı geri alınır ve bu, A toplamasındaki işlemin de geri alınmasına neden olur.

Şimdi bunu söylemek kesinlikle yapmaktan daha kolay geliyor. Bunun için. Toplamalar arasındaki iletişimin verimli ve ölçeklenebilir olması gerekir. Paylaşılan sıralayıcıların, toplamaların nasıl iletişim kurabileceği, zincirler arası mesajların nasıl görünmesi gerektiği, toplama yükseltmeleriyle nasıl başa çıkılacağı vb. konularda uygun standartlar bulması gerekir. Bunlar çözülebilir sorunlar olsa da karmaşıktır ve çözülmesi kolay değildir.

Geliştirici deneyimi

Paylaşılan sıralayıcılar, merkeziyetsizlik yönünü soyutlayıp zincirler arası mesajlaşmayı kolaylaştırsa da, yine de her zincirin paylaşılan sıralayıcıyla uyumlu olması için takip etmesi gereken bazı standartlar vardır. Örneğin, tüm toplama işlemlerinin sıralayıcının anlayabileceği genel bir formata dönüştürülmesi gerekiyor. Benzer şekilde, ilgili işlemleri getirmek için sıralayıcıdan gelen blokların filtrelenmesi gerekir. Bunu çözmek için, paylaşılan sıralayıcıların standart kodu soyutlayan ve uygulama zinciri geliştiricilerine yalnızca iş mantığı kısmını gösteren toplama çerçeveleri veya SDK'lar bulacağını varsayıyorum.

Uygulama zincirlerinin paylaşılan sıralayıcılarla nasıl görüneceğine ilişkin bir diyagramı burada bulabilirsiniz

Durun, yine Polkadot'tan başka bir şey değil

Polkadot, çoklu zincirli gelecek üzerinde çalışmaya Ethereum'dan çok önce başlamıştı. Aslında üzerinde 5 yıldan fazla bir süredir çalışıyorlar ve eğer Polkadot'a aşina iseniz, yukarıdaki tasarımın Polkadot'un halihazırda yapmış olduğu pek çok şeyi temelde yeniden icat ettiğini fark etmiş olabilirsiniz!

Aktarma Zinciri (Paylaşılan Merkezi Olmayanlaştırma)

Röle zinciri temel olarak yukarıdaki sıra şemasındaki sıralama motoru + L1'dir. Röle zinciri

1. Tüm parachain'lerde işlemleri sipariş eder (toplamalar)
2. Doğru şekilde yürütülen işlemleri doğrular (zk doğrulaması yerine aslında durum farklarını doğrulamak için toplamanın yürütme kodunu yeniden çalıştırır)

Rölenin temelde yukarıda tartıştığımız paylaşımlı sıralayıcı olduğunu fark etmiş olabilirsiniz. Aktarma zincirinin de yürütmeyi doğrulaması gerektiği gerçeği dışında (Polkadot bir L1 olduğundan) bunu Ethereum'a bırakıyoruz.

XCM ve XCMP

Önceki bölümde, her zincirin diğer zincirlerle birlikte çalışmak için kendi yöntemlerini oluşturması halinde, kısa sürede tüm zincirlerde farklı standartlar ve formatlarla şişirileceğimizden bahsetmiştik. Etkileşim kurduğunuz her zincir için bu formatların tamamını takip etmeniz gerekecektir. Üstelik bir zincir güncellenirse ne olur gibi soruları da yanıtlamanız gerekecek. Ancak tüm zincirlerin uyması gereken standartlar getirilerek bu sorunlar zarif bir şekilde çözülebilir.

Tahmin edebileceğiniz gibi Polkadot bunu zaten yaptı. XCM mesajlaşma formatıdır ve XCMP, tüm alt tabaka zincirlerinin birbirleriyle iletişim kurmak için kullanabileceği mesajlaşma protokolüdür. Ayrıntılarına girmeyeceğim ama buradan okuyabilirsiniz 5.

Substrat ve Kümülüs

Substrat, Parity tarafından geliştirilen ve blockchain oluşturmak için kullanılabilecek bir çerçevedir. Polkadot'taki tüm parachain'ler substrat kullanırken, substrat aslında zincirden bağımsız bir şekilde inşa edilmiştir. Çerçeve, bir blockchain'in tüm ortak yönlerini özetler, böylece yalnızca uygulama mantığınıza odaklanabilirsiniz. Bildiğimiz gibi Madara, Polkadot, Polygon Avail ve diğer birçok proje gibi Substrate üzerine inşa edildi. Üstelik Cumulus, zincirinizi Polkadot'a bağlamanıza olanak tanıyan, Substrate'in üzerinde yer alan bir ara katman yazılımıdır.

Analojimize daha önce olduğu gibi devam edersek, Substrate ve Cumulus, uygulama zincirleri oluşturmanıza ve bunları paylaşılan sıralayıcılara bağlamanıza olanak tanıyan toplama çerçevelerinin alternatifleri olarak düşünülebilir.

Paylaşımlı Sıralayıcılar → Röle Zincirleri
Şekillendirilebilirlik → XCM ve XCMP
Toplama çerçeveleri/Yığınları → Substrat ve Kümülüs

Yani evet, her şey yeniden Polkadot'a benziyor! Bunun dışında Polkadot ve Parity, daha fazla özellik eklemek ve onu daha ölçeklenebilir hale getirmek için Substrate ve Polkadot'u geliştirmeye devam eden en deneyimli ve finanse edilen ekiplerden bazılarına sahiptir. Teknoloji zaten yıllardır savaşta test edildi ve kutudan çıktığı gibi tonlarca geliştirme aracına sahip.

Polkadot'u Ethereum'a mı yerleştireceksiniz?

Polkadot'un çok zincirli geleceği inşa etmeye Ethereum'dan çok daha önce başladığı doğru olsa da, bugün itibariyle Ethereum'un en merkezi olmayan blok zinciri ve uygulamaların ve likiditenin çoğunun bulunduğu yer olduğu inkar edilemez. Peki ya tüm Polkadot teknolojisini Ethereum ekosistemine getirmenin bir yolu olsaydı?

Orada! Aslında bunu Madara ile zaten başlattık. Madara, herkesin Ethereum'un üzerinde kendi zk destekli L2/L3 çözümünü oluşturmasına olanak sağlamak için Substrate çerçevesini kullanıyor. Bundan sonra ihtiyacımız olan şey, paylaşımlı sıralayıcı biçimindeki Polkadot aktarma zinciridir. Yani temel olarak Polkadot aktarma zincirini yeniden kullanabilirsek ancak

1. Zk kanıtları aracılığıyla L1'de olduğu gibi doğrulama bölümünü kaldırın
2. İşlem sırasını L1'e kaydedin
3. Tendermint/HotStuff'ı desteklemek için düğümleri ve fikir birliği algoritmalarını optimize edin

Daha önce de belirtildiği gibi paylaşımlı sıralayıcılar alabiliriz. Açıkçası, bunu söylemek yapmaktan daha kolaydır. Ancak bu yolun sıralayıcıları, standartları ve çerçeveleri sıfırdan yeniden inşa etmekten daha pragmatik olduğuna inanıyorum. Polkadot, Ethereum için ödünç alabileceğimiz pek çok sorunu zincirden bağımsız bir şekilde çözmüştür. Bir yan ürün olarak şunu elde ederiz:

1. Substrate hakkında dünyayı geliştirmeye ve eğitmeye devam eden aktif geliştiricilerden oluşan bir grup
2. Aktif bir geliştirici araç seti ve güçlü bir topluluk
3. Birçok aktif parachain, isterlerse Ethereum'a da yerleşmeyi seçebilir (Astar'ın son zamanlarda Polygon CDK ile aynısını yaptığını gördük)

Çözüm

Bu yazıyı yazmanın ardındaki ana fikrim, Starknet ve Ethereum'un daha geniş ekosistemi arasında tartışmayı başlatmaktır. Paylaşılan sıralama modelinin yalnızca Starknet'in değil, aynı zamanda onun üzerine inşa etmeyi düşünen tüm uygulama zincirlerinin merkeziyetsizleştirilmesinde önemli bir rol oynayacağını düşünüyorum. Uygulama zinciri tezi ve zk ölçeklendirme konusunda kendimize güvendiğimiz sürece, paylaşılan sıralama modelinin kapsamlı bir analizi kaçınılmazdır. Üstelik Madara üretime doğru ilerlerken ve Starknet ademi merkeziyetçilik üzerinde çalışmaya başladığından bu konunun artık ele alınmasının önemli olduğunu düşünüyorum. Bu nedenle, bunu okuyan herkesin konu hakkında geri bildirimlerini/önerilerini bırakmalarını rica ediyorum. Düşüncelerinizi okumayı sabırsızlıkla bekliyorum!

Ek

Polkadot Cosmos'a Karşı

Polkadot'a benzeyen Cosmos, uzun yıllardır çok zincirli bir gelecek için çözümler üretiyor. Sonuç olarak Cosmos SDK ve IBC ile pek çok gelişme kaydetti ve ayrıca Cosmos ekosisteminin üzerine pek çok uygulama zincirinin kurulduğunu da görüyoruz. Dolayısıyla bu yaklaşım için Cosmos'u da dikkate almak adil olur. Bu konuyla ilgili kişisel görüşüm, Polkadot'un paylaşılan sıralayıcılar sorununu çözdüğü için daha alakalı olduğu, Cosmos'un ise her uygulama zincirinin kendi doğrulayıcı setini oluşturmasını gerektirdiği yönünde. Üstelik Substrate, geliştiricilerin konsensüs algoritmaları veya Polkadot ekosistemi hakkında hiçbir varsayım olmaksızın blok zincirler oluşturmasına olanak sağlamak için her zaman zincirden bağımsız bir şekilde oluşturulmuştur. Madara için Substrate'ı seçmemizin nedeni de budur. Ancak bununla birlikte Cosmos'taki deneyimim sınırlı ve bu konuda daha deneyimli kişilerden daha fazla bilgi almayı çok isterim! Ayrıca iki ağın karşılaştırması hakkında daha fazla bilgiyi buradabulabilirsiniz.

Yasal Uyarı:

1. Bu makale [starknet]'ten yeniden basılmıştır. Tüm telif hakları orijinal yazara [apoorvsadana] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.