Giriş

Kitlesel benimseme işleme kapasitesini artırmak için devam eden arayışta, Monad, Ethereum Sanal Makinesi (EVM) modelini optimize etmek için düşük seviye iyileştirmeler serisiyle öne çıkan bir öncü güç olarak ön plana çıkar: asenkron I/O, optimize edilmiş Patricia Trie, ertelenmiş yürütme ve Optimistik Eşzamanlılık Kontrolü gibi paralel işleme için [2]. Bu iyileştirmeler, Ethereum gibi platformlarda görülen yürütme engellerini ve etkisiz durum erişimini etkili bir şekilde ele alırken merkezi olmayanlığı feda etmemektedir.

Bu yazıda, Monad üzerinde sağlam bir Madenci Çıkarılabilir Değer Müzayede Altyapısı (MEVA) olası uygulamalarını keşfediyoruz. Ethereum'daki Flashbots ve Solana'daki Jito Network gibi mevcut yaklaşımlardan bazı taşınabilir, değerli dersleri de açıklıyoruz.

Birkaç temel düşünceyi vurgulamak istiyoruz:

1. MEV, herhangi bir blok zinciri ağına özgüdür. Kötü dışsallıklar ve hizalama eşleşmeleri ile dolu bir blok üretim sürecini önlemek için güçlü bir MEVA altyapısı hayati öneme sahiptir.
2. MEVA tasarımı, özellikle uzlaşma-yürütme aşamalarıyla ilgili olan bir zincirin temel mekanizmalarıyla derinden entegre edilmiştir. Gelecekteki geliştirmeler, bu faktörlerin evrimine ve ağın farklı stres seviyelerindeki performansına bağlı olacaktır.
3. Ethereum ve Solana'da görülen blok üretimi evrimindeki tarihsel eğilimler, Monad üzerinde MEVA tasarımına yol gösterebilir.
4. Monad gibi yüksek performanslı, ertelenmiş işlem blok zincirlerinde MEVA'nın olası blok oluşturma ve arama stratejileri, zaman kısıtlamaları nedeniyle yüksek frekanslı ticaret ile benzerlik gösterebilir.

Bu noktaları ele alarak, Monad'ın benzersiz mimarisine ve performans gereksinimlerine uygun bir MEVA altyapısı tasarlama sürecinde karşılaşılan zorluklar ve dikkate alınması gereken hususlar hakkında bilgi sağlamayı umuyoruz.

Ethereum'daki MEV Manzarası

Ethereum'un Konsensüs-İcra Sahnesi Altında MEVA

Ethereum'da uzlaşma önceden yürütme gerektirir. Düğümler bir blok üzerinde anlaştıklarında, hem bloktaki işlemlerin listesi hem de bloğun yürütüldükten sonraki sonradan durumu özetleyen Merkle kökü konusunda anlaşıyorlar. Bu nedenle, liderler önerilen bloktaki tüm işlemleri yayınlamadan önce yürütmelidir. Bu arada, doğrulama düğümleri oy kullanmadan önce işlemleri yürütmelidir.

Şekil 1: MEV-Boost'ta EL-CL ayrımı altında İnşaat Akışı.

Şekil 1, MEV-Boost'ta Birleştirici-Oluşturucu Ayrımı (PBS) için tipik bir oluşturucu iş akışını tasvir eder. Oluşturucular blokları oluşturmayı bitirir ve bunları bir röle'e gönderir, röle blokları bir Yürütme Katmanı (EL) istemcisine simülasyon ve geçerlilik kontrolleri için iletilir.

Çünkü yürütme, uzlaşma için ön koşuldur, bir yapımcı bir blok oluşturduğunda oluşturulan bloğu Yürütme Katmanı (YK) istemcisine iletmeli ve bloğun geçerliliğini kontrol etmek için bloğu simüle etmelidir. Uzlaşma-yürütme aşamasında olduğu gibi, simülasyon aşaması hem yapımcılar hem de arayıcılar için faydalar sağlar.

Yapımcının bakış açısı: Yapımcılar her bir işlemi simüle ederek bloğun değerini kendileri ve doğrulayıcılar için doğru bir şekilde tahmin edebilirler. Ayrıca işlemleri yeniden sıralayarak geri dönüşleri en aza indirgemek ve mempool ve paket işlemlerinden hem gaz ücretlerini hem de temel ipuçlarını maksimize etmek için deney yapabilirler. Hassas tahminleri, doğrulayıcılara daha yüksek tekliflerde bulunmalarına olanak tanır.

Arama perspektifi: Yapımcıların zincire ulaşmadan önce olası geri dönüş demetlerini eleyerek, araştırmacılar da garanti strateji yürütme görür, belirlenim ekler. Dahası, araştırmacılar ayrıca en son blok durumuna erişirler. Konsensüs katmanı (CL) yeni bir blok yaydığında, araştırmacılar o bloğun durumunu kârlı demetler oluşturmak için bir başlangıç noktası olarak kullanabilirler. Bu arada, şu anda yapımcılar tarafından sunulan daha fazla protokol dışı anlaşma veya özellikler için işaretler var, bu da araştırmacıların, to-be-landed bloklarına geri dönüş stratejileri eklemek için şimdiki blok oluşturulurken durum bilgisi elde etmelerine olanak tanır.

Ancak, PBS gelişimi blok oluşturmadaki merkezileşmede bir artış görmüştür, bu da firmaların arbitraj stratejilerini yürütmek için öncelik kazanmak için özel mikrodalga ağ kanalları için rekabet ettiği geleneksel ticareti yansıtmaktadır.

Ağ Olgunlaştıkça Ürün İterasyonu

Şimdi Ethereum ilerledikçe MEVA'nın nasıl geliştiğini, Şekil 2'de kronolojik olarak gösteriyoruz.

Şekil 2: Ethereum Ağı ilerledikçe MEVA'nın nasıl tekrar ettiğine dair kronolojik bir görünüm. Şekil, [4]'ten hafifçe uyarlanmıştır.

Öncelikli Gaz Müzayedesi (PGA) Dönemi

Şekil 3'te gösterildiği gibi, araştırmacılar karlı MEV fırsatlarını belirledi ve akıllı sözleşme kullanarak yapılan işlemlerini kamusal mempool'a gönderdi. Bu kamusal görünürlük, başarısız işlemler bile gaz maliyetleriyle karşı karşıya kalan açık artırma formatında on-chain bir açık artırma formatına yol açtı.

Bu dönem, aynı (hesap, nounce) çiftiyle yapılan ve [6] artan teklifler gibi rekabetçi ve maliyetli yapılandırılmamış MEV faaliyetlerini gördü, bu da ağın sıkışıklığına veya konsensüs istikrarsızlığına katkıda bulundu.

Şekil 3: Basit Öncelikli Gaz Müzayedesi. Şekil, [6] kaynağından hafifçe uyarlanmıştır.

Flashbots ve EIP-1559

Bu sorunları çözmek için Flashbots, araştırmacılar ve blok üreticileri (PoW döneminde madenciler) arasında aracı açık artırma evleri olan röleleri tanıttı. Bu girişim, MEV pazarını açık artırma yerine mühürlü teklif olan bir hale getirir. Şekil 4, rölelerin, genel mempool'da teklif yükselmesini önlemeye ve daha düzenli ve güvenli bir blok üretim süreci oluşturmaya nasıl yardımcı olduğunu göstermektedir.

EIP-1559 ücret yapısı burada da rol oynuyor [7]. Temel ücretler aracılığıyla kısmen yayınlanan fiyatlar tanıtılarak teklif verme işlemini basitleştirdi ancak bloklar içindeki işlem sırasını ele almadı ve hala öncelikli ücretler aracılığıyla MEV'yi yönlendiriyor. Gerçekte, birçok araştırmacı önceden madencilere doğrudan coinbase transferi yoluyla tekliflerini ifade ediyorlardı. Artık 0 gaz paketleri gönderemedikleri için coinbase ücretleri hakkında daha fazla şikayetleri oldu.

Şekil 4: Rölelerle MEVA. Şekil, [6] kaynağından hafifçe uyarlanmıştır.

Teklif Eden-Yapımcı Ayrımı (PBS)

Ethereum'un birleşmeden sonra Stake (PoS) modeline geçmesinin ardından, Blok Üretim Boru Hattındaki rollerin ayrımını daha da rafine etmek için Önerici-Oluşturucu Ayrımı (PBS) uygulandı. Daha önce açıklandığı gibi, artık aracılar blok oluşturucuları ve önericiler arasındaki aracılar olarak hareket ederler ve veri erişilebilirliği ve blok geçerliliğini sağlayan koruyucular olarak görev yaparlar. Bir önerici, farklı özel işlemler için birden fazla oluşturucuya bağlanabilir, bu nedenle oluşturucular, önericiye ödeme yaparak rekabet etmek zorundadır. Bu dinamik, Şekil 5'te gösterildiği gibi açıklanmıştır.

Şekil 5: PBS Döneminde MEVA. Bu şekil, [6] kaynağından hafifçe uyarlanmıştır.

Yoğunlaşma Riskleri

Bu tarihsel ilerlemelere rağmen, inşaatçı pazarındaki konsantrasyon risklerinin arttığına dikkat çekmek önemlidir. Geçen yıl, en üst 9 inşaatçının oligarşisi sürekli olarak pazarın >50'sini elinde tutmuş ve bu durum, Şekil 6'da belirtildiği gibi yüksek bir pazar konsantrasyonu derecesine işaret etmektedir. Konsantrasyon durumu şu anda daha da belirgin olup en üst üç inşaatçının blokların >90'ını kaplamaktadır.

Şekil 6: İnşaatçıların pazar payı. Grafik, inşaatçı piyasasında yaygın olan yüksek konsantrasyonu göstermektedir. Grafik, şuradan alınmıştır https://arxiv.org/pdf/2405.01329

Solana'da Jito

Jito'nun Mimarisi

Solana'daki kanonik MEV olarak, Jito, düşük işlem maliyetleri nedeniyle Solana'nın yüksek spam oranıyla başa çıkmak için oluşturuldu. Spam ticaretleri, başarısız bir işlemin maliyeti (yaklaşık 0.000005 SOL) beklenen kârı aşmadığı sürece etkili bir şekilde teşvik edilir.

2022 yılında Jito Labs tarafından yapılan bir rapora göre [8], o yıl arbitraj ve likidasyon girişimlerinin %96'sından fazlası başarısız oldu ve blokların %50'den fazlası MEV ile ilgili işlemleri içeriyordu. Rapor ayrıca likidasyon botlarının ağa milyonlarca kopya paket göndererek sadece birkaç bin başarılı likidasyon gerçekleştirmek için spam yaptığını ve bu durumun %99'dan daha yüksek bir başarısızlık oranına neden olduğunu vurguluyor [8].

Şekil 7: Jito'nun Solana'daki MEVA'sının kuşbakışı görünümü.

Solana'daki MEV dışsallıklarının ciddiyeti, Jito'nun blok üretim sürecine düzen ve belirlilik getirmeyi amaçlayan bir MEVA katmanı geliştirmesine yol açtı. Jito tarafından önerilen orijinal MEVA mimarisini Şekil 7'de gösterildiği gibi gözden geçirelim.

Jito'nun aşağıdaki bileşenleri bulunmaktadır:

Relay - işlem almak için bir proxy olarak hareket eder ve hem Blok Motoruna (veya MEVA tedarik zincirine) hem de doğrulayıcılara yönlendirir.

Block Motor - relayer'dan işlemleri alır, araştırmacılarla koordine eder, paketleri kabul eder, paket simülasyonları gerçekleştirir ve en iyi işlemleri ve paketleri işleme için doğrulayıcıya ileter. Özellikle, Jito, tarihsel olarak iki yuva içinde paketlerin %80'den fazlasını işleyen tam blok açık artırma yerine paket dahil etme için kısmi blok açık artırması yapar [9].

Pseudo Mempool - Jito-Solana istemcisi aracılığıyla yaklaşık 200 milisaniye işletimsel bir zaman penceresi oluşturur, sipariş akışı için bir diskretizasyon müzayedesi oluşturur [10]. Jito bu mempool'u 9 Mart 2024 tarihinde kapattı.

Jito’nun Tasarım Tercihleri

Jito'nun sistem tasarımının özel bileşenlerini keşfedelim ve bu tasarım tercihlerinin Solana'nın blok üretim sürecinden nasıl kaynaklandığını düşünelim.

Jito, Solana'nın çoklu iş parçacığı yürütme modelinden kaynaklanan global zamanlama eksikliği nedeniyle, tam blok oluşturma yerine yalnızca kısmi blok açık artırmalarını destekler. Özellikle, Şekil 8, işlemleri yürüten paralel iş parçacıklarını gösterir, her biri yürütülmeyi bekleyen işlemlerin kuyruğunu tutar. İşlemler rastgele iş parçacıklarına atılır ve öncelik ücretine ve zamana göre yerel olarak sıralanır. Planlayıcı tarafında (1.18.x güncellemesinden önce) global sıralama olmadan, Solana'nın işlemleri planlayıcı titremesinden [11] dolayı belirsizlik yaşar. Bu nedenle MEVA'da arayıcılar veya doğrulayıcılar güncel durumu güvenilir bir şekilde belirleyemez.

Şekil 8: Solana İstemci için Çoklu İş Parçacıklı yürütme modeli. MEVA'nın Paket Aşamasının çoklu iş parçacıklı kuyruğun içinde ayrı bir iş parçacığı olarak eklendiğini fark edin.

Bir mühendislik perspektifinden, Jito'nun blok motoru beslemesinin mevcut olanlarla paralel olarak ek bir iş paraleli olarak entegre edilmesi, Solana'nın çoklu iş paralelliği mimarisiyle iyi uyum sağlar. Paket açık artırmaları, Jito blok motoru iş paraleli içinde öncelik ücretine dayalı sıralamayı sağlarken, paketlerin her zaman kullanıcı işlemlerinden önce yerleştirileceğinin garantisi yoktur.

Bu sorunu çözmek için, Jito blok içi iş parçacığı için blok alanının bir kısmını önceden ayırır, böylece blokta yer alan paketleri garanti altına alır. Belirsizlik devam etmesine rağmen, bu yaklaşım başarılı strateji yürütme olasılığını arttırır. Ayrıca, ağa spam göndermek yerine arama yapanları açık artırmaya katılmaya teşvik eder. Jito, paketler için blok alanını ayırarak dengeli bir şekilde hareket edebilir, düzenli açık artırmaları teşvik eder ve işlem spam'inin kaotik etkilerini azaltır.

Pseudo-Mempool'un Kaldırılması

Jito'nun yaygın olarak benimsenmesi, Solana'daki istenmeyen e-posta sorununu hafifletmede olumlu sonuçlar vermiştir. P2p [12] tarafından yapılan araştırma ve 9. Şekilde gösterilen veriler, Jito istemcisini benimsedikten sonra göreli blok üretim oranında istatistiksel olarak önemli bir iyileşme olduğunu ortaya koymaktadır. Bu, 2023 yılında tanıtılan Jito'nun optimize blok motoru sayesinde işlem işleme sürecinin daha verimli hale geldiğini göstermektedir.

Şekil 9: Solana'daki spam sorununu hafifletme konusunda Jito'nun etkinliğine dair kanıtlar. Grafik, p2p ekibi tarafından yürütülen [12] numaralı araştırmada yer alan verilerden çıkarılmıştır.

Önemli ilerlemeler kaydedilmiş olsa da, birçok zorluk hala devam etmektedir. Jito demetlerinin sadece kısmen blokları doldurmasından dolayı, MEV tetikleyici işlemler hala Jito açık artırma kanalını atlayabilmektedir. Bu sorun, en azından kısmen, 2024 yılından bu yana ağın hala bot spamı nedeniyle ortalama olarak %50'den fazla başarısız işlem yaşadığını gösteren Dune Paneli'nde (Şekil 10 [13]) görülmektedir.

Şekil 10: Bir Dune Kontrol Paneli (https://dune.com/queries/3537204/5951285) Mayıs 2022'den bu yana Solana'da bot spam etkinliklerini gösteren bir resim var.

9 Mart 2024'te Jito, amiral gemisi mempool'unu askıya alma kararı aldı. Bu karar, memecoin işlemlerindeki büyüme ve buna bağlı olarak sandviç saldırılarındaki (arama yapanların hedef işlemden önce ve sonra işlem yaptığı bir tür önden çalıştırma) kaynaklanan ve sonuçta kullanıcı deneyimini bozan bir artıştan kaynaklandı. MEVA'daki özel sipariş akışı kanallarıyla Ethereum'da gözlemlenen eğilimlere benzer şekilde, halka açık mempool'u kapatmak, cüzdan sağlayıcıları ve Telegram botları gibi ön uç hizmetlerle ortaklıklar yoluyla özel sipariş akışının büyümesini teşvik edebilir. Arama yapanlar, tercih edilen yürütme, dahil etme ve hariç tutma için doğrudan doğrulayıcılarla ortaklıklar kurabilir. Aslında, bunun kanıtı, mempool kapanmasının ardından en büyük özel mempool arayıcısı (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) için saatlik sandviç bot kar profilini gösteren Şekil 11'de görülebilir.

Şekil 11: Özel Mempool'lu Sandviç Bot için Saatlik Kar, Arayan “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”.

Jito'nun mempool'u kapatma kararı, Solana ekosistemi içindeki temel sorunlarla mücadele etme konusundaki güçlü taahhüdünü vurguluyor. MEVA'yı yenilemek veya Solana'nın gaz ücreti mekanizmasını ayarlamaktan öte, Jito ayrıca, varsayılan kayma parametrelerini sınırlayarak saldırı vektörlerini azaltma konusunda protokollere eğitim de sağlar. Spam yapmayı daha pahalı hale getiren ücret yapısı ayarları veya iletişim protokollerini değiştirme yoluyla, Jito'nun altyapısı Solana'nın ağ sağlığı ve istikrarını korumak için temel olmaya devam edecektir.

Monad'da MEVA Tasarımı

Erteleme Yürütme & MEVA Üzerindeki Etkileri

Ethereum'dan farklı olarak, bir bloğun onaylanması için hem işlemlerin listesi (sıralı olarak) hem de tüm sonuç durumlarını özetleyen merkle root'unun gerekliliği olan Monad, önceki yürütme işlemlerini uzlaşmadan ayırır. Node anlaşması sadece resmi sıralamanın belirlenmesini gerektirir. Şekil 12'de gösterildiği gibi, her bir node blok N'deki işlemleri bağımsız olarak yürütürken blok N+1 üzerinde uzlaşmayı başlatır. Bu düzenleme, yürütmenin sadece uzlaşmayla aynı hızda olması gerektiğinden yürütme sırasında tam blok süresine karşılık gelen bir gaz bütçesine olanak tanır. [15] Lider nodun de facto durum kökünü hesaplama ihtiyacı olmaksızın, yürütme, bir sonraki blok için tüm uzlaşma dönemini kullanabilir.

Şekil 12: Ethereum'un Yürütme-Anlaşma aşamalarıyla karşılaştırıldığında Monad İleri İcra. Operasyonel Zaman Penceresi, MEVA tasarım perspektifinden de açıklanmaktadır.

Operasyonel Zaman Aralığını, Monad'da MEVA'nın hem uygun hem de karlı bir blok oluşturma önerisini tamamlamasına izin verilen zaman aralığı olarak tanımlarız. Erteleme yürütme modelinin iki hemen sonucu vardır:

1. MEVA, operasyonel zaman penceresi içinde N'inci blok için derleme yaptığında, doğrulayıcılar aynı anda N'inci blok için işlem listesi üzerinde anlaşırken N-1'inci blok için yürütmeyi tamamlamaya çalışıyorlar. Bu nedenle, N'deki operasyonel zaman penceresi içinde, kullanılabilir durumun hala N-2'de olması çok olasıdır. Bu, bu ertelenmiş yürütme mimarisi altında aktarıcı veya oluşturucu için garanti edilen "en son durum" olmadığı anlamına gelir. Bu nedenle, bir sonraki blok üretilmeden önce en son bloğa karşı simülasyon yapmak imkansızdır, bu da indeterminizm ile sonuçlanır.
2. Monad'ın 1 saniyelik blok süresi göz önüne alındığında, MEVA için operasyonel zaman penceresi son derece sınırlıdır. Bu, yapımcıların genellikle Ethereum'da yaptığı gibi işlemlerin ve paketlerin tam bloklarını sıralı bir şekilde simüle etmek için yeterli zamanı olmayabileceği anlamına gelir. EVM üzerinde işlem simülasyonu için gereken zamanı etkileyen pek çok değişken bulunmaktadır. Bununla birlikte, bir işlemin simüle edilmesinin 10^1 ile 10^2 mikrosaniye arasında sürdüğünü (kabaca bir tahminle) varsayarsak ve Monad'ın hedefi olan saniyede 10^4 işlem göz önüne alındığında, operasyonel zaman penceresi içinde tam bloğun simüle edilmesi yaklaşık olarak 1 tam saniye sürebilir. Monad'ın 1 saniyelik blok süresi göz önüne alındığında, yapımcıların veya rölelerin inşa edilen bloğu optimize etmek için birden fazla tam blok simülasyonunu tamamlamaları zor olabilir.

Olasılıksal Oluşturucu & Arayıcı Stratejisi

Kısıtlamalar göz önüne alındığında, işletme zaman penceresi içinde tam bir blok simülasyonunu tamamlamak ve en son duruma karşı simülasyon yapmak pratik değildir. Şimdi yapımcılar her iki durumda da her işlemden tam olarak ipucunu bilmek için hem zaman hem de en son durumdan yoksun olduklarından, araştırmacı ipucunu itibara dayanarak veya (en iyimser senaryoda) N-2 durumuna karşı simülasyon yaparak işlem iptal olasılığına dayalı olarak çıkarmanız gerekir. Bu, blok değerlendirmesini daha az belirleyici hale getirir.

Doğrulayıcı, oluşturucu tarafından oluşturulan bloğu kabul ettikten sonra işlem geri dönüşlerine karşı teorik garantinin olmaması nedeniyle arama yapanlar daha fazla yürütme belirsizliğiyle karşı karşıyadır. Bu, arama yapanların nispeten deterministik strateji uygulamaları için özel sipariş akışından oluşturucuya kanallar için rekabet ettiği Ethereum ile çelişiyor. Monad'daki bu nispeten olasılıklı ortamda, arama yapanlar artık daha yüksek bir demet riskiyle karşı karşıyadır ve bu da daha belirsiz bir yürütme PnL profiline yol açar. Bu, zaman içinde biraz pozitif beklenen getirilerle olasılıksal sinyaller üzerinde çalışan yüksek frekanslı tüccarları yansıtır.

Şekil 13: Önerilen blok kontrolü veya simulasyon derecesine göre kategorize edilen farklı MEVA tasarım paradigmalarını gösteren kavramsal bir spektrum diyagramı.

Şekil 13'te gösterildiği gibi, yapımcının önceden paket / blok kontrol derecesi, önerilen bloğun fiyatlandırması veya değerlemesi konusunda belirsizlik spektrumu yaratır. Bir uçta doğru fiyatlandırma olan Ethereum tarzı PBS modeli bulunur, burada yapımcıların önerilen bloktaki işlemi simüle etmek için Yürütme Katmanı (EL) İstemciyi kullanmaları gerekir. Gönderilen paketler arasında geniş bir kombinasyon aralığında dolaşmak zorundadırlar. Diğer uçta, asenkron blok kontrolüne sahip Ümitli Yapımcı Modeli [16] bulunur. Bu modelde, yapımcılar operasyonel zaman penceresinde herhangi bir simülasyon için gereken zamanı atlar ve kesilmeye tabi olan teminat yatırarak doğrulayıcılara veya röle gösterilen bahşişleri onurlandırır. Monad üzerinde burada önerilen olasılıksal kontrol veya kısmi simülasyon yaklaşımı, bazı belirsizliklere rağmen arayıcılar için başarılı strateji yürütme olasılığını artırır.

Örneğin, bir onchain sipariş defteri DEX'teki bir piyasa yapıcı, ters yönlü büyük bir fiyat hareketi fark ettiğinde olumsuz seçimden kaçınmak için pozisyonlarını MEVA aracılığıyla önceden taşımak için ödeme yapabilir. Bu olasılık stratejisi, en son durum bilgisi olmadan bile hızlı hareket etmelerine olanak tanır ve dinamik bir ticaret ortamında risk ve ödülü dengeleyerek işlem yapar.

Kapanış Konuşması

MEVA, dışsal etkileri azaltarak ve genel sistem istikrarını artırarak blok üretimini optimize etmede kritik bir rol oynar. Solana'daki Jito ve Ethereum'da çeşitli uygulamalar gibi MEVA çerçevelerinin sürekli evrimi, ölçeklenebilirlik sorunlarıyla başa çıkmak ve ağ katılımcılarının teşviklerini hizalamak için son derece yardımcıdır.

Monad, henüz bebek aşamasında olan umut vadeden bir ağdır ve topluluğun en iyi MEVA tasarımını şekillendirmesi için benzersiz bir fırsat sunar. Monad'ın benzersiz yürütme-consensus evresini dikkate alarak, araştırmacıları, geliştiricileri ve doğrulayıcıları işbirliği yapmaya ve bilgi paylaşmaya davet ediyoruz. Bu işbirliği, sağlam ve verimli bir blok üretim süreci oluşturmada önemli bir rol oynayacak ve Monad'ın yüksek işlem hacimli blok zinciri ağı olarak potansiyelini gerçekleştirmesine olanak tanıyacaktır.

Açıklama:

1. Bu makale [den alıntıdır0xapr]. Tüm telif hakları orijinal yazarına aittir [APRIORI ⌘]. Bu yeniden basım hakkında itirazlarınız varsa, lütfen iletişime geçin Gate Öğrenekip, ve onlar derhal ele alacaklar.
2. Sorumluluk Reddi: Bu makalede yer alan görüşler yalnızca yazarına aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılmaktadır. Belirtilmedikçe, çevrilmiş makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.