Çoklu Eşzamanlı Önerici (MCP) Artıları ve Eksileri Analizi

Yazar: Maven11; Çeviri: Altın Finans xiaozou

Çoklu Eşzamanlı Teklif Sahipleri (Multiple Concurrent Proposers, kısaca MCP), birden çok teklif sahibinin aynı anda aktif olmasını sağlayan bir mekanizmayı ifade eder (Multi Context Protocol veya Güvenli Çok Taraflı Hesaplama (MPC) ile karıştırılmamalıdır, ancak aralarında bazı benzerlikler vardır). Bu, sansür sorununu çözmek için yenilikçi bir çözümdür. Bu makalede, birden fazla teklif sahibinin blok teklifi sorumluluğunu üstlenmesinin, blok zinciri mekanizma tasarımını geliştirmede neden kritik bir unsur olduğunu, işleyiş prensiplerini ve uygulanabilirliğini inceleyeceğiz.

MCP'nin temel kavramını anlamak nispeten kolay olsa da, şu anda mekanizmayı gerçekten benimseyen birkaç blok zinciri var. Bununla birlikte, bir bakıma, Bitcoin'in madencilik havuzu, birden fazla eşzamanlı teklif verene benzer şekilde çalışır - bir Bitcoin tam düğümü çalıştıran herkes, zincir üzerinde paketlenmiş işlemleri alabilir.

Öte yandan, Solana'nın çok eşzamanlı oluşturucu mekanizmasının, en azından blok oluşturmaya katılan birden fazla farklı katılımcının fikrini yansıtan (ancak blok önerisine değil) tam bir MCP'nin uygulanmasıyla bazı ortak noktaları vardır. Ethereum'da blokların yaklaşık %95'i MEV-Boost aracılığıyla oluşturulur. Aynı anda birden fazla aktif oluşturucu olsa da, açık artırma başına yalnızca bir kazanan olabilir, bu nedenle Solana'nın birden fazla eşzamanlı oluşturucu aracılığıyla elde ettiği avantaj burada geçerli değildir. Aslında, şu anda birden fazla teklif sahibinin herhangi bir zamanda blok teklif etme hakkına sahip olmasına izin veren bir zincir yoktur.

MCP'yi anlamanın en sezgisel yolu, onu iki düzeye ayırmaktır: Birden fazla teklif verenin aynı anda blok sağlaması ve bu alt blokların nihai birleştirilmesi.

Bu teklif sahibi gruplarının alt konseyler olması muhtemeldir (Ethereum'un mevcut mekanizmalarına benzer şekilde), çünkü tüm doğrulayıcıların dahil edilmesi pratik değildir. Bu aynı zamanda, bireysel alt komitelerin bir stake havuzu tarafından tekelleştirilmemesini sağlamanın önemli olduğu anlamına gelir, aksi takdirde sansür ve gizli anlaşma sorunları ortaya çıkabilir. Ek olarak, efsanevi ev bahisçilerinin genellikle sınırlı teknik yeteneklere sahip olduğuna dikkat etmek önemlidir - MCP, sistemin karmaşıklığını önemli ölçüde artıracaktır.

MCP'nin benimsenmesi gereken temel avantajları şunlardır:

Birden Fazla Eşzamanlı Teklif Sahibinin Desteklenme Nedenleri:

--Sansüre karşı direnci artırmak (mevcut darboğazda özellikle önemli)

--Temel protokol katmanında genişleme, dış çözümlere bağımlı olmamak

--Dağıtılmış MEV (artık tek bir önerici veya inşaatçı tarafından işlem paketleme kararlaştırılmıyor)

MCP'nin uygulanmasının doğrudan ortaya çıkaracağı sorunlar:

-- İşlem sıralaması (paketleme ve sıra) rekabetinin artması (belki PGA fenomeninin ortaya çıkmasına neden olabilir mi?)

--Geçersiz işlemlerin getirdiği simülasyon zorlukları

--Donanım gereksinimleri yükseldi

--Geçersiz işlem verimliliği sorunu

--Sonuç araçlarının dahil edilmesi gerekiyor

Bu özellikleri madde madde inceleyelim, önce avantajlardan başlayarak, ardından potansiyel sorunların teknik yükü ağır olan halka açık blok zincirleri için uygulama engeli oluşturup oluşturmayacağını değerlendirelim.

1. MCP'nin Avantajları

(1) Sansür direncini artırma

Günümüzün blok zincirlerinin çoğu deterministik bir kesinlik mekanizması kullanır ve fikir birliği süreçleri, bloğun içeriğini belirlemek için tek bir lidere dayanır (küçük farklılıklarla). Blok yayınlandıktan sonra, doğrulayıcıların çoğu fikir birliğine varır ve bunu kanonik zincire dahil eder. Ethereum, bir alt komite mekanizması aracılığıyla blok üretimini hızlandırır (ancak tüm doğrulayıcı setinin fikir birliğine varması daha uzun sürer). MCP çerçevesinde, birden fazla teklif sahibinin her biri kendi bloğunu oluşturur ve sonunda birleşir, bu da blok girişinin tek bir ilkeden (teklif eden/oluşturucu/tekrarlayıcı, bu roller ideal olarak MCP tarafından atılmalıdır) çok kanallı bir modele geçtiği anlamına gelir. Bu, gözden geçirmeyi çok daha zor hale getirir. Birden fazla paketleme gövdesi olduğunda, sistemin sansür direnci önemli ölçüde artacaktır.

Mevcut darboğazın merkezinde (Flashbots gibi ekiplerin mevcut durumu iyileştirdiğini unutmayın), tek bir inşaatçının bir açık artırma yoluyla tek bir teklif sahibinden blok oluşturma hakları alması ve müzayedeci olarak (güvenilir) aktarıcının merkezileşmeyi daha da şiddetlendirmesidir. Ethereum çekirdek protokolü merkeziyetsiz olsa da, mevcut zincir içi işlem süreci merkezi değildir. Solana ayrıca Jito rölelerinin/inşaatçılarının merkezileşmesiyle karşı karşıya ve bunu bir yeniden stake etme çözümüyle çözmeye çalışıyor (ilk gerçek getirili yeniden staking "AVS"!). ）。 Bitcoin kullanıcıları, tam bir düğüm çalıştırarak sorunu özerk bir şekilde (daha düşük bir maliyetle) çözebilir, ancak bu kesinlik pahasına gelir - Bitcoin olasılıksal kesinliği kullanır ve en uzun zincir kuralına dayanan MCP'yi uygulamak için gereken "kesinlik araçlarından" yoksundur.

(2) Temel protokol katmanında genişletme

Çoğu zaman, temel protokol sorunlarını çözmek için L1'in (Ethereum ile sınırlı olmayan) doğal tasarım kusurlarını düzeltmek için birçok geliştirme üçüncü taraf ekiplere dış kaynak sağlanır. MCP'yi uygulamak, aksi takdirde zincir dışı çözümlerle çözülecek/neden olacak sorunlarla doğrudan ilgilenmek anlamına gelir. Bu, donanım gereksinimlerini artırır (sansür direncini artırırken), bu da protokol kullanıcılarının ademi merkeziyetçilik ihtiyacına bağlı olarak değerli bir değiş tokuş olabilir. Özellikle Solana'nın, Jito'nun merkezileşmesini ele almak için bu yaklaşımı kullanması muhtemeldir. Ek olarak, blok oluşturma çabası birden fazla tarafa dağıtıldığından, genel ağ bant genişliği talebi sonuçta artacaktır.

(3) Dağıtılmış MEV

MCP'nin en özgün etkisi, belirli blokların MEV'sinin birden fazla aktif önerici tarafından paylaşılması (tek bir önerici veya inşaatçı tarafından tekelleştirilmesi yerine) sayesinde, mevcut "MEV piyango" modelini değiştirmesidir. Doğrulayıcılar (çoğunlukla kurumsal varlıklar) istikrarlı bir gelir akışı elde etmeyi tercih ederler; bu mekanizma aynı zamanda tek taraflı olarak işlem sıralamasını değiştirerek MEV'yi sömürmeyi etkili bir şekilde önler (mevcut durum). Bu özellik, sansürle mücadele amacına da sinerji sağlar.

Not: Eğer geçmişteki makalelerimizi okuduysanız, CAP teoremi terimiyle tanışık olabilirsiniz: Bu, dağıtık sistemlerin düzgün çalışabilmesi için yerine getirilmesi gereken üç temel özelliktir.

**C：**Tutarlılığı (consistency) temsil eder, yani kullanıcı deneyimi tüm kullanıcılar arasında bir bütünlük göstermelidir; sistem her kullanıldığında tek bir veritabanıyla etkileşimde bulunuyormuş gibi hissedilmelidir.

A： Kullanılabilirliği (availability) temsil eder, yani sıkça bahsettiğimiz aktiflik (liveness) demektir. Tüm mesajların sistem düğümleri tarafından işlenmesi ve sonraki bloklarda/sorgularda yansıtılması gerekir, tüm komutlar yerine getirilmelidir.

P： Bölüm hatasına dayanıklılığı (partition tolerance veya sansüre dayanıklılık) temsil eder, bu da sistemin saldırıya uğradığında veya düğüm ağı bölündüğünde bile tutarlılık ve kullanılabilirliği koruması gerektiği anlamına gelir.

MCP, CAP teoreminin temel unsurlarını, özellikle de sansür direncini, genellikle basitçe oyun teorisi problemlerine dahil edilen şekilde uygulamanın en iyi yollarından biridir. Unutmayın: oyun teorisine değil, protokolün kendisine güvenin.

Ancak avantajlar mutlaka bir bedel ile birlikte gelir, CAP teoremi işleyiş prensibi şunu gösteriyor: Büyük başarılar her zaman karşılık gelen eksikliklerle birlikte gelir - hemen hemen tüm özellikleri tam olarak karşılamak neredeyse imkansızdır. Bu nedenle, MCP'nin uygulanmasının neden olabileceği sorunları gözden geçirelim.

2、MCP'nin çözmesi gereken zorluklar

Ana sorun şudur: MCP, belirli bir ölçüde blok içindeki çift rekabet aşamalarını tetikleyebilir. Öncelikle işlem paketleme ücreti, ikincisi ise sıralama ücretidir. Sıralama ücretinin işlenmesi özellikle zordur çünkü birinci aşamada yerel üreticiler yalnızca yerel blok görünümüne sahip olup küresel görünümden yoksundurlar. Bu, belirli bir blok konumundaki en iyi teklifi tam olarak hesaplamanın zorlu bir görev olduğu anlamına gelir.

Bu sadece operasyonel olarak zor değil, daha da önemlisi (açık artırma mekanizması altında) bizi öncelikli Gas açık artırma (PGA) dönemine geri döndürecektir. Sansür direnci daha güçlü bir şekilde güvence altına alınsa da, aslında MEV-Boost'un çözmeye çalıştığı sorunları yeniden canlandırıyor - rekabetçi blokların yüksek Gas ücreti medyanı, paketleme aşamasındaki dışlayıcı fiyatlandırma gibi olgular.

Yerel ve küresel görünümler de dahil olmak üzere sıralama sorunlarına ek olarak, işlemle ilgili başka zorluklar da vardır. Bu, özellikle bloğun yerel-küresel görünümünün yayılması sırasında geçersiz işlemlerin neden olduğu sorunu ifade eder. Aşamanın başında (alt bloklar birden fazla teklif sahibinin ortak oluşturduğu bloklara birleştirilmeden önce) durum değişikliklerinin diğer teklif sahibinin işlemleri üzerindeki etkisini tahmin etmenin imkansız olduğu göz önüne alındığında, teklif verenlerin birbirlerine geçersiz işlemler geçirdiği durumlar olabilir (bu işlemler zincire veri kullanılabilirliği içeriği olarak yüklenirse sorun daha da kötüleşir). Mevcut MCP setindeki bir doğrulayıcının bir parametre sınırını ihlal etmesi de mümkündür (örneğin, maksimum gaz değerini kırmak). Bu, veri kullanılabilirliği açıklandıktan sonra aynı durum değişikliğine sahip düşük fiyatlı işlemleri ücrete göre filtreleyebilen bir hakem (veya protokol yerleşik kuralı) getirilerek çözülebilse de, bu bizi çözülmüş PGA ikilemine geri getiriyor. Bununla birlikte, arama yapanlara / inşaatçılara blok konumları üzerinde kontrol sağlamak için açık artırmalar gibi mekanizmaların hiç kullanılmaması, spam işlemlerinin seline ve gecikme kumarının kötüleşmesine yol açacaktır - bunların tümü önceden yapılandırma olasılığını baltalayacaktır. Ethereum (Pectra yükseltmesinden sonra) ve Solana'nın ek hususları vardır: Ethereum'un önerisi 7702, işlemlerin artık nonce'lar nedeniyle geçersiz kılınmamasını sağlar ve Solana'nın işlem nonce'u yoktur (hesap nonce'u hala mevcuttur). Bu, bir işlemin geçerliliğini değerlendirmeyi çok daha zor hale getirir - esasen doğru sıralamayı belirlemek için tüm kombinasyonları simüle eder, bu da ağın bant genişliği üzerinde büyük bir yük oluşturabilir. Solana'nın yüksek donanım giriş engeli ile idare edilmesi daha kolay olabilir, ancak Ethereum'un şüphesiz bir donanım yükseltmesine ihtiyacı olacak. Bununla birlikte, Ethereum'un potansiyel çözümü, yürütme istemcisinin (oluşturucu + tekrarlayıcı değil) alt blok birleştirme aşaması sırasında sıralamayı gerçekten hesaplamasıdır - bu da bir donanım yükseltme ihtiyacını yeniden teyit eder.

Veri kullanılabilirliği (DA) açısından, daha önce de belirtildiği gibi, bir diğer önemli konu da bu geçersiz işlemlerin zincir üzerinde sızdırılabilmesidir (esasen ücretsiz işlemler haline gelebilir). Bu, konsensüs öncesi aşamada bahsedilen simülasyon hesaplamasının yükünü daha da artırır - ancak birleştirme aşamasında geçersiz işlemleri filtreleyebilirsiniz. FOCIL'in mevcut uygulamalarından bazıları (tam işlem yerine adres gönderme) yeniden kullanılabilir (yalnızca simülasyon doğrulamasına dayanmadıkları sürece, ancak protokol kuralları yerine insan müdahalesi diğer işlemleri geçersiz kılarak simülasyon sürecine müdahale edebilir).

Daha önce de belirtildiği gibi, MCP'nin uygulanması büyük olasılıkla senkronizasyon sorunlarıyla başa çıkmak için kesinlik araçları gerektirecektir - bu, yukarıdaki konsensüs öncesi sipariş simülasyonu bölümünde ima edilen şeydir. Bu aynı zamanda, teklif sahiplerinin kendi bloklarını oluşturmadan önce diğer bloklara bakabilmeleri ve böylece kasıtlı olarak diğer insanların işlemlerini geçersiz kılan işlemler gönderebilmeleri (özellikle arama yapanlar için faydalı) etkisiyle, blok tekliflerinin zaman oyununu (MEV-Boost müzayedelerinde görülen bir fenomen) geciktirme sorununu da gündeme getirir. Anti-zaman oyununun kuralları çok katıysa, daha zayıf doğrulayıcıların ortadan kaldırılmasına yol açacaktır (bu da daha fazla eksik blok anlamına gelir).

Zaman oyununa olası çözümler, asenkron yürütme (ertelenmiş yürütme) mekanizması kullanan Monad gibi zincirlerin iyileştirmelerinden ödünç alınabilir. Örneğin, bir kural belirleyebilirsiniz: tüm aktif teklif sahiplerinin işlem kümesinin tek bir zaman dilimindeki tam etkisi, tüm kümeler oluşturulana kadar beklemelidir. Bu, birden fazla teklif verenin aynı işlemi içerme olasılığı yüksek olduğundan, verimi önemli ölçüde sınırlar. Gecikmeli yürütme aynı zamanda, bir işlem bir alt bloğa "dahil edilmiş" olsa bile, son birleştirme bloğuna ulaşamayacağı anlamına gelir ve bu da "dahil edilmiş ancak geri alma" işlemiyle sonuçlanır (başlangıçta bahsedilen çift dahil etme sorununu yansıtır). Bunun, bu tür işlemleri (blokların yürütülmesi, yayılması ve sonlandırılması dahil) gerçekleştirmek için belirli kesinlik araçları gerektirebileceğini unutmayın.

Öncelikle Ethereum'a odaklanmış olsak da, Solana'nın MCP'yi aktif olarak ilerlettiğini belirtmekte fayda var. Bu eğilim, Max Resnick'in Anza'ya eklenmesi ve Anatoly'nin uygulamaya yönelik kamuoyu desteği ile daha da belirgin hale geldi. Anatoly'nin son makalesi aşağıdaki temel endişeleri ele alıyor:

--Farklı doğrulayıcılardan gelen blokların ulaşım zamanları farklıysa ne yapmalı (bu aynı zamanda zaman oyunları da olabilir)

-- İşlemleri nasıl birleştirirsiniz (önceki bölümde tartışılmıştır)

--Doğrulayıcılar arasında blok kapasitesinin (maksimum Gas limiti) dağıtımını nasıl yaparak bant genişliğini maksimize edebiliriz

--Kaynak israfı sorunu (aynı işlemin birden fazla alt blokta yer alması, bu sorun daha önce de bahsedilmiştir)

Solana'da MCP'nin uygulanmasındaki birçok sorun genellikle Ethereum'un karşılaştığı sorunlarla örtüşmektedir. Ancak Solana, bant genişliği ve performans optimizasyonuna daha fazla önem vermektedir, bu da sağlam bir konsensusun sağlanmasının yanı sıra, blok kaynak yönetimi ve blok birleştirmenin daha önemli hale geldiği anlamına geliyor.

Makalenin başında bahsettiğimiz bir diğer önemli nokta, MCP'nin sadece protokolü sertleştirmekle kalmayıp, aynı zamanda protokolü genişletmek için de kullanılabilmesidir. Hatta uygulamaya özel serileştirmeyi (ASS) bir sıralama mekanizması aracılığıyla protokol katmanına dahil edebilir. Gelecekte, XYZ işleminin teklif sahibi olmak yerine, uygulamanın kendisinin teklif sahibi olarak hareket ettiği ve işlem kümesini kendi ihtiyaçlarına göre sıraladığı (Project Delta'nın üzerinde çalıştığı şey budur) - veya tersine, uygulama teklif sahibine bir işlem harmanlaması sağlar. MEV vergisini başvuru tarafına (işlem başlatan) aktarma ve bunu MCP ile birleştirme seçeneğinin de araştırıldığını belirtmekte fayda var (artık tek bir teklif sahibi tarafından kontrol edilmediği için uygulanması daha kolay olacaktır).

Yakın tarihli bir gönderide Max ve Anatoly, MCP'nin özel serileştirme (merkezi olmayan NASDAQ konsepti) uygulayarak daha dar teklif-satış spreadleri elde edebileceğini savundu. Mevcut ortamda, daha önce de belirtildiği gibi, yalnızca tek bir lider blok önerebilir. Bu, fiyat dalgalandığında, emir defterindeki teklif veren tarafın belirli kotasyonları tersine çevirmeye çalışacağı anlamına gelir. Solana'nın tek teklif sahibi modeline göre, teklif sahibinin güç üzerindeki tekeli nedeniyle yalnızca Jito müzayedeleri yoluyla yapılabilir. İdeal olarak, Hyperliquid'in gösterdiği gibi, piyasa yapıcıların daha sıkı spreadleri korumasına izin vermek için geri ödeme taleplerine öncelik verilmelidir. Bu nedenle, bunun bir uygulama olarak ASS aracılığıyla gerçekleştirileceği umulmaktadır - tek lider modeli altında açık artırma gücü üzerinde bir tekele sahiptirler ve bu tekel MPC'nin benimsenmesiyle ortadan kaldırılabilir. Ancak, bu ASS çözümünün durum yalıtım senaryolarıyla sınırlı olması muhtemeldir. Teklifin özü, uygulama geliştiricilerinin belirli hesaplar için öncelikli eylemler (örneğin, sipariş iptalleri) tanımlamasına ve belirli hesaplar için en yüksek öncelikli işlemlere (mutlaka en yüksek bahşiş işlemleri değil, likiditenin can damarı) öncelik vermesine izin vermektir. Temel fikir, belirli öncelikli işlemlerin limiti aşmasına izin verirken, normal işlemler için bir ücret eşiği belirlemektir.

Önceki yazıda tartışılan paketleme ücretleri ve sıralama ücretleri sorununa, Solana'nın bir çözüm önerisi olduğu görülüyor. Paketleme ücreti işlem doğrulayıcısına, sıralama ücreti ise protokole (yakma) ödeniyor. Birden fazla alt blok birleştirildiğinde, yalnızca önceden belirlenmiş sıralama ücretine göre birleştirilmiş işlem kümesi sıralanıp yürütülüyor.

Yukarıdaki mekanizma, Solana'nın blok yayılma mekanizması Turbine ile yakın bir şekilde çalışır. Liderler (MCP'ler), Türbin ağacındaki röle düğümlerine gönderilen veri parçalarını (parçalar) kullanır - bu röleler tüm liderlerden gelen parçaları içermelidir. Röle düğümü, yayın yapmak ve fikir birliğine varmak için yeterli mesaj parçası toplaması gereken tek bir konsensüs liderine bir parça onay mesajı gönderir.

Alpenglow'un piyasaya sürülmesiyle birlikte, tek katmanlı ara düğüm mimarisinin ve zincir üzerindeki oylama mekanizmasının kaldırılması (şimdi tamamen zincir üzerinde) göz önüne alındığında, belirli uygulamalarda bazı değişiklikler olabilir. Bu değişikliklerin, doğrulayıcıların işletme maliyetlerini düşürmesi ve böylece doğrulayıcı sayısını artırarak teknik kapasitesi daha düşük olan katılımcıları çekmesi bekleniyor. Bu, merkeziyetsizliğe kesinlikle fayda sağlasa da, zincirin performansını etkileyebilir. Tartışmaya değer olan, Solana'nın MCP'yi uyguladıktan sonra doğrulayıcı arızası sorunuyla nasıl başa çıkacağıdır.

**3、**Diğer Ekosistemlerde MCP Uygulamaları

Cosmos ekosistemi de MCP uygulamasını ilerletiyor, tanınmış kuruluş Informal Systems, BFT konsensüs modeli altında çoklu önerici standartlarını yeni yayınladı. Onlar güvenli yayın protokolünü kullanarak, oylama genişletme mekanizması aracılığıyla her doğrulayıcının alt bloklarının diğer doğrulayıcılar tarafından onaylanmasını gerektiriyor. Tendermint/CometBFT'nin blok inşa modülü daha sonra bu alt blok kümesi üzerinde konsensüs sağlıyor, bu da belirli doğrulayıcıların çok sayıda alt blok üretmesi anlamına geliyor.

Sei, kısmen Autobahn makalesinden (şiddetle tavsiye edilir) ilham alan Sei Giga projesi aracılığıyla MCP'yi (uygulanacak ilk proje olmayı hedefleyen) geliştiriyor. Temel fikir, veri kullanılabilirliğini sıralamadan ayırmak, birden çok paralel kanal aracılığıyla veri kullanılabilirliğini hızlandırmak ve son olarak küresel zincire göre sıralamaktır. Bu, doğrulayıcıların blokları belirli bir süre boyunca senkronize etmediği, ancak bloklar üretmeye ve bunları küresel bir görünümde birleştirmeye devam ettiği Ethereum'un MCP konseptinden biraz farklıdır.

Commonware'dan Patrick O'Grady de ilgili çözümleri araştırıyor.

Son olarak, Delta projesi, sansür karşıtı bir ilan tahtası işlevine sahip bir altyapı tasarladı ve her uygulama kendi eşzamanlı sıralayıcısını çalıştırarak, üretilen bloklar nihayetinde küresel durum katmanına hesaplanır.