تحليل مزايا وعيوب المقترحين المتزامنين المتعددين (MCP)

المؤلف: Maven11؛ الترجمة: 金色财经xiaozou

المقترحون المتزامنون المتعددون (Multiple Concurrent Proposers، المشار إليهم لاحقًا بـ MCP) هم آلية تسمح لعدة مقترحين بالتواجد في حالة نشاط في نفس الوقت (يجب الانتباه لعدم الخلط بينها وبين بروتوكول السياقات المتعددة Multi Context Protocol أو الحسابات متعددة الأطراف الآمنة MPC، على الرغم من وجود بعض التشابهات بينها)، وهي حل مبتكر لمشكلة الرقابة. ستتناول هذه المقالة لماذا يجب أن يكون هناك مقترحون متعددون بدلاً من مقترح واحد مسؤولين عن اقتراح الكتل، حيث تُعتبر هذه النقطة عنصرًا رئيسيًا في تحسين تصميم آليات البلوكشين، بما في ذلك كيفية عملها وأهمية تنفيذها.

على الرغم من أن المفهوم الأساسي لـ MCP سهل الفهم نسبياً، إلا أنه لا يوجد تقريباً أي اعتماد فعلي لهذه الآلية في عالم البلوكشين حتى الآن. ومع ذلك، من ناحية ما، يوجد تشابه بين نموذج تشغيل تجمعات التعدين في بيتكوين ومقترحي التوازي المتعدد - حيث يمكن لأي شخص يقوم بتشغيل عقدة كاملة لبيتكوين أن يجعل المعاملات تُدمج في السلسلة.

! xoZWXtWoJyweT8MeGgBugxwm51IfcxfkToqRw1dr.png

من ناحية أخرى، فإن آلية البناة المتزامنين المتعددة في سولانا تشترك في بعض النقاط مع الشكل الكامل لتنفيذ MCP، على الأقل تعكس فكرة مشاركة عدة مشاركين مختلفين في بناء الكتل (لكن ليس في اقتراح الكتل). وفي الإيثيريوم، يتم بناء حوالي 95% من الكتل من خلال MEV-Boost. على الرغم من وجود عدة بناة نشطين في نفس الوقت، إلا أن المزاد في كل مرة يمكن أن يكون له فائز واحد فقط، لذا فإن ميزة سولانا التي تحققت من خلال بناة متزامنين متعددة لا تنطبق هنا. في الواقع، لا توجد أي سلسلة حالياً قادرة على تحقيق اقتراحات متعددة في أي وقت.

أبسط طريقة لفهم MCP هي تقسيمها إلى مستويين: تقديم العديد من المقترحات في الوقت نفسه، ودمج هذه المقترحات الفرعية في النهاية.

! UgLFVd0gPFQlFly7IsDhalymLrME44Xqp1yaA0W7.png

من المحتمل أن تتبنى هذه المجموعات من المقترحين شكل اللجان الفرعية (على غرار الآلية الحالية للإيثيريوم) لأن إشراك جميع المدققين ليس واقعياً. وهذا يعني أيضاً أنه يجب التأكد من عدم احتكار أي مجموعة فرعية من قبل مجموعة معينة من حصص التشفير، وإلا فقد يؤدي ذلك إلى مشاكل في الرقابة والتواطؤ. بالإضافة إلى ذلك، يجب ملاحظة أن ما يسمى بمقدمي الحصص العائلية غالباً ما تكون قدراتهم التقنية محدودة - ستزيد MCP بشكل كبير من تعقيد النظام.

فيما يلي المزايا الأساسية التي تجعل MCP جديرًا بالتبني:

أسباب دعم مقترحات متعددة في وقت واحد:

--تعزيز مقاومة الرقابة (وهذا مهم بشكل خاص في ظل الاختناقات الحالية)

--التوسع على مستوى البروتوكول الأساسي بدلاً من الاعتماد على الحلول الخارجية

--توزيع MEV (لم يعد يتم تحديد حزم المعاملات من قبل مقترح أو بناء واحد)

المسائل التي ستظهر مباشرة عند تنفيذ MCP:

--تزايد المنافسة في ترتيب المعاملات (الحزم والترتيب) (هل يمكن أن يؤدي ذلك إلى ظهور ظاهرة PGA؟)

--التحديات المحاكاة الناتجة عن المعاملات غير الصالحة

--زيادة متطلبات الأجهزة

--مشكلة توفر بيانات المعاملات غير الصالحة

--يجب إدخال أدوات نهائية

دعنا نقوم بتحليل هذه الميزات واحدة تلو الأخرى، بدءًا من المزايا، ثم تقييم ما إذا كانت المشكلات المحتملة ستشكل عقبة أمام تنفيذ سلاسل الكتل العامة التي تعاني من عبء تقني كبير.

1، مزايا MCP

(1) تعزيز مقاومة الرقابة

تستخدم معظم سلاسل الكتل اليوم آلية نهائية حتمية ، وتعتمد عملية الإجماع الخاصة بها على قائد واحد لتحديد محتوى الكتلة (مع اختلافات طفيفة). بعد بث الكتلة ، يتوصل غالبية المدققين إلى توافق في الآراء ويدمجونها في السلسلة الأساسية. تعمل Ethereum على تسريع إنتاج الكتلة من خلال آلية لجنة فرعية (ولكن الأمر يستغرق وقتا أطول حتى تصل المجموعة الكاملة من المدققين إلى توافق في الآراء). في إطار عمل MCP ، يقوم كل من مقدمي الاقتراحات المتعددين ببناء الكتلة الخاصة بهم والدمج في النهاية ، مما يعني أن إدخال الكتلة ينتقل من أصل واحد (مقدم / منشئ / مكرر ، يجب تجاهل هذه الأدوار بشكل مثالي بواسطة MCP) إلى نموذج متعدد القنوات. هذا يجعل المراجعة أكثر صعوبة. عندما يكون هناك العديد من هيئات التعبئة والتغليف ، سيتم تعزيز مقاومة الرقابة على النظام بشكل كبير.

في قلب عنق الزجاجة الحالي (لاحظ أن فرقا مثل Flashbots تعمل على تحسين الوضع الراهن) هو أن منشئ واحد يتلقى حقوق بناء الكتل من مقدم عرض واحد من خلال مزاد ، وإعادة الطبقة (الموثوق بها) كبائع المزاد تؤدي إلى تفاقم المركزية. في حين أن بروتوكول Ethereum الأساسي لامركزي ، فإن عملية المعاملات الحالية على السلسلة ليست كذلك. يواجه Solana أيضا مركزية مرحلات / بناة Jito ويحاول حلها من خلال حل إعادة التخزين (أول "AVS" لإعادة العائد الحقيقي!). ）。 يمكن لمستخدمي Bitcoin حل المشكلة بشكل مستقل (بتكلفة أقل) عن طريق تشغيل عقدة كاملة ، ولكن هذا يأتي على حساب النهاية - تستخدم Bitcoin النهائية الاحتمالية وتفتقر إلى "أدوات النهائية" اللازمة لتنفيذ MCP ، والتي تعتمد على أطول قاعدة سلسلة.

(2) التوسع على مستوى بروتوكول الأساس

في كثير من الأحيان ، يتم الاستعانة بمصادر خارجية للكثير من التطوير لفرق الجهات الخارجية لإصلاح عيوب التصميم المتأصلة في L1 (لا تقتصر على Ethereum) لحل مشكلات البروتوكول الأساسية. يعني تنفيذ MCP التعامل المباشر مع المشكلات التي كان من الممكن حلها / سببها الحلول خارج السلسلة. هذا يزيد من متطلبات الأجهزة (مع زيادة مقاومة الرقابة) ، والتي قد تكون مقايضة جديرة بالاهتمام اعتمادا على الحاجة إلى اللامركزية من قبل مستخدمي البروتوكول. من المرجح أن يستخدم سولانا ، على وجه الخصوص ، هذا النهج لمعالجة مركزية جيتو. بالإضافة إلى ذلك ، نظرا لتوزيع جهد بناء الكتلة على أطراف متعددة ، فإن الطلب الإجمالي على النطاق الترددي للشبكة سيزداد في النهاية.

(3) توزيع MEV

تتمثل الميزة الفريدة لـ MCP في: تغيير نموذج "يانصيب MEV" الأصلي من خلال توزيع MEV لكتل معينة بين مقترحين نشطين متعددين (بدلاً من احتكاره من قبل مقترح أو مُنشئ واحد). يميل المدققون (معظمهم من الكيانات التجارية) إلى الحصول على تدفقات دخل مستقرة، كما أن هذه الآلية يمكن أن تمنع بشكل فعال استغلال MEV عن طريق إعادة ترتيب المعاملات (الحالة الحالية). هذه السمة تتماشى مع أهداف مقاومة الرقابة.

ملاحظة: إذا كنت قد قرأت مقالاتنا السابقة، فقد تكون على دراية بمصطلح نظرية CAP: وهي الخصائص الأساسية الثلاث التي يجب أن تلبيها الأنظمة الموزعة لتعمل بشكل صحيح.

C： تمثل الاتساق (consistency) ، مما يعني أن تجربة المستخدم يجب أن تظل موحدة بين جميع المستخدمين ، ويجب أن يشعر المستخدم في كل مرة يستخدم فيها النظام وكأنه يتفاعل مع قاعدة بيانات واحدة.

ج: التوافر ، وهو ما نسميه غالبا الحيوية ، يعني أن جميع الرسائل تحتاج إلى معالجتها بواسطة عقد النظام وانعكاس في الكتل / الاستعلامات اللاحقة ، ويجب تنفيذ جميع التعليمات.

P: تعني تحمل التقسيم ، مما يعني أن النظام يحتاج إلى الحفاظ على الاتساق والتوافر حتى عند تعرضه للهجوم أو تقسيم شبكة العقدة.

MCP هو أحد أفضل الطرق لتحقيق العناصر الرئيسية لنظرية CAP (خاصة مقاومة الرقابة) - وغالبًا ما يتم تبسيط هذه العناصر إلى مسائل نظرية الألعاب. تذكر: يجب أن تثق في البروتوكول نفسه، وليس في نظرية الألعاب.

ومع ذلك، فإن المزايا لا بد أن تأتي مع تكاليف، حيث تشير قوانين تشغيل نظرية CAP إلى أن الإنجازات العظيمة دائماً ما تكون مصحوبة بعيوب مناسبة - من شبه المستحيل تلبية جميع الخصائص بشكل كامل. لذا دعونا نفحص المشكلات التي قد تثيرها تنفيذ MCP.

2، التحديات التي يجب على MCP حلها

المشكلة الرئيسية هي أن MCP يمكن أن يؤدي إلى مرحلة تنافس مزدوج داخل الكتلة إلى حد ما. أولاً هي رسوم تجميع المعاملات، وثانياً هي رسوم الترتيب. إن معالجة رسوم الترتيب صعبة بشكل خاص، لأن المنتجين المحليين في المرحلة الأولى يمتلكون فقط وجهة نظر محلية للكتلة وليس وجهة نظر شاملة. وهذا يعني أن حساب أفضل عرض لموقع كتلة معين هو مهمة شاقة.

! ch8ILlNsaae7gXUMsXRIibmRDzmECCY1A73W5FDF.png

هذا ليس فقط صعب التنفيذ، بل الأهم من ذلك (تحت آلية المزاد) أن هذا سيعيدنا إلى عصر مزادات الغاز ذات الأولوية (PGA). على الرغم من أن مقاومة الرقابة أصبحت أكثر ضمانًا، إلا أنه يعيد في جوهره إلى الحياة المشكلة التي حاول MEV-Boost حلها - ظواهر مثل الوسيط العالي لرسوم الغاز في الكتل التنافسية، والتسعير الحصري في مرحلة التعبئة.

بالإضافة إلى قضايا الفرز ، بما في ذلك وجهات النظر المحلية مقابل وجهات النظر العالمية ، هناك تحديات أخرى متعلقة بالمعاملات. يشير هذا على وجه التحديد إلى المشكلة الناجمة عن الحركات غير الصالحة أثناء نشر العرض المحلي والعالمي للكتلة. بالنظر إلى أنه من المستحيل التنبؤ بتأثير تغييرات الحالة على معاملات مقدم الاقتراح الآخر في بداية المرحلة (قبل دمج الكتل الفرعية في كتل مشتركة متعددة لمقدمي الاقتراحات) ، قد تكون هناك حالات يقوم فيها المقترحون بتمرير معاملات غير صالحة لبعضهم البعض (تتفاقم المشكلة إذا تم تحميل هذه المعاملات إلى السلسلة كمحتوى لتوفر البيانات). من الممكن أيضا أن ينتهك المدقق في مجموعة MCP الحالية حد المعلمة (على سبيل المثال ، كسر الحد الأقصى لقيمة الغاز). في حين أنه يمكن حل ذلك عن طريق تقديم محكم (أو قاعدة بروتوكول مضمنة) يمكنها تصفية المعاملات منخفضة السعر بنفس تغيير الحالة حسب الرسوم بعد الكشف عن توفر البيانات ، فإن هذا يعيدنا إلى معضلة PGA التي تم حلها. ومع ذلك ، فإن عدم استخدام آليات مثل المزادات على الإطلاق لمنح الباحثين / المنشئين التحكم في مواقع الكتل سيؤدي إلى طوفان من المعاملات غير المرغوب فيها وتفاقم المقامرة في زمن الوصول - وكل ذلك من شأنه أن يقوض إمكانية حدوث preconfs. لدى Ethereum (بعد ترقية Pectra) و Solana اعتبارات إضافية: اقتراح Ethereum 7702 يجعل المعاملات لم تعد باطلة بسبب nonces ، و Solana ليس لديه معاملة nonce (لا يزال الحساب موجودا). هذا يجعل من الصعب الحكم على صحة المعاملة - محاكاة جميع المجموعات بشكل أساسي لتحديد الترتيب الصحيح ، مما قد يضع ضغطا كبيرا على النطاق الترددي للشبكة. قد يكون من الأسهل التعامل مع Solana مع حاجز الأجهزة العالي للدخول ، لكن Ethereum ستحتاج بلا شك إلى ترقية الأجهزة. ومع ذلك ، فإن الحل المحتمل ل Ethereum هو أن يقوم عميل التنفيذ (وليس المنشئ + المكرر) بحساب الطلب فعليا أثناء مرحلة دمج الكتلة الفرعية - مما يؤكد الحاجة إلى ترقية الأجهزة.

! x7UlHJpjjdPKvjjZ3KnsdNRxm1Y0Ci2Zg34ezx9w.png

فيما يتعلق بتوافر البيانات (DA) ، كما ذكرنا سابقا ، هناك مشكلة مهمة أخرى وهي أنه يمكن تسريب هذه المعاملات غير الصالحة على السلسلة (تصبح بشكل أساسي معاملات مجانية). يؤدي هذا إلى تفاقم عبء حساب المحاكاة المذكور في مرحلة ما قبل الإجماع - على الرغم من أنه يمكنك تصفية المعاملات غير الصالحة أثناء مرحلة الدمج. يمكن إعادة استخدام بعض التطبيقات الحالية ل FOCIL (إرسال العنوان بدلا من المعاملة الكاملة) (ما لم تعتمد فقط على التحقق من صحة المحاكاة ، ولكن التدخل البشري بدلا من قواعد البروتوكول قد يتداخل مع عملية المحاكاة عن طريق إبطال المعاملات الأخرى).

كما ذكرنا سابقا ، سيتطلب تنفيذ MCP على الأرجح أدوات نهائية للتعامل مع مشكلات التزامن - وهو ما هو مذكور في قسم محاكاة ترتيب ما قبل الإجماع أعلاه. يثير هذا أيضا مشكلة تأخير اللعبة الزمنية لمقترحات الكتلة (وهي ظاهرة شوهدت في مزادات MEV-Boost) ، مع تأثير أن مقدمي الاقتراحات قد ينظرون إلى الكتل الأخرى قبل إنشاء الكتل الخاصة بهم ، وبالتالي إرسال المعاملات عمدا التي تبطل معاملات الآخرين (مفيدة بشكل خاص للباحثين). إذا كانت قواعد لعبة مكافحة الزمن صارمة للغاية ، فسيؤدي ذلك إلى القضاء على المدققين الأفقر (مما يعني المزيد من الكتل المفقودة).

يمكن استعارة الحلول الممكنة للعبة الوقت من تحسينات السلاسل مثل Monad ، والتي تستخدم آلية التنفيذ غير المتزامن (التنفيذ المؤجل). على سبيل المثال، يمكنك تعيين قاعدة: يجب أن ينتظر التأثير الكامل لمجموعة المعاملات لجميع مقدمي الاقتراحات النشطين في فترة زمنية واحدة حتى يتم إنشاء جميع المجموعات. هذا يحد بشكل كبير من الإنتاجية ، حيث يوجد احتمال كبير أن يحتوي العديد من مقدمي الاقتراح على نفس المعاملة. يعني التنفيذ المتأخر أيضا أنه حتى إذا تم "تضمين" المعاملة في كتلة فرعية ، فقد لا تصل إلى كتلة الدمج النهائية ، مما يؤدي إلى معاملة "مضمنة ولكن تراجع" (مرددا مشكلة التضمين المزدوج المذكورة في البداية). لاحظ أن هذا قد يتطلب أدوات نهائية محددة لتنفيذ مثل هذه العمليات (بما في ذلك تنفيذ الكتل ونشرها ووضع اللمسات الأخيرة عليها).

! Idvyka85De1Y0RFlDGYtAavBV04lPdP3OkgpJ9zA.png

على الرغم من أننا نركز بشكل أساسي على الإيثريوم، إلا أنه من الجدير بالذكر أن Solana تدفع بنشاط MCP. مع انضمام ماكس ريسنيك إلى أنزا وبيان أناتولي العلني لدعم التنفيذ، أصبحت هذه الاتجاهات أكثر وضوحًا. تشير المقالة الأخيرة التي نشرها أناتولي إلى النقاط الرئيسية التالية:

--ماذا تفعل إذا كان وقت وصول الكتل من مدققين مختلفين مختلفاً (يمكن أن تكون هذه أيضاً لعبة زمنية)

--كيفية دمج الصفقة (تمت مناقشتها في النص السابق)

--كيفية توزيع سعة الكتلة (حد الغاز الأقصى) بين المدققين لتحقيق أقصى استفادة من النطاق الترددي

--مشكلة هدر الموارد (تم تضمين نفس الصفقة في عدة كتل فرعية، وقد تم الإشارة إلى هذه المشكلة سابقًا)

تتوافق العديد من القضايا المتعلقة بتنفيذ MCP على سولانا مع القضايا التي تواجهها إيثيريوم. ومع ذلك، تركز سولانا بشكل أكبر على عرض النطاق الترددي وتحسين الأداء، مما يعني أن إدارة موارد الكتلة ودمج الكتل يصبحان أكثر أهمية مع ضمان قوة الإجماع.

نقطة رئيسية أخرى ذكرناها في بداية المقال هي: MCP لا يعزز البروتوكول فحسب، بل يمكن أيضًا استخدامه لتوسيع البروتوكول. يمكنه حتى دمج التسلسل التخصصي للتطبيقات (ASS) في طبقة البروتوكول من خلال آلية الترتيب. قد يظهر هذا السيناريو في المستقبل: بدلاً من أن يكون مقترح الصفقة هو XYZ، سيصبح التطبيق نفسه هو المقترح، مرتبا مجموعة المعاملات حسب احتياجاته الخاصة (وهذا هو الاتجاه الذي يسعى إليه مشروع Delta) - أو العكس، حيث يقدم التطبيق قواعد ترتيب المعاملات للمقترح. من الجدير بالذكر أن الحل الذي ينقل ضريبة MEV إلى جهة التطبيق (مبادر الصفقة) بالاقتران مع MCP قيد الاستكشاف أيضاً (لأنه لم يعد يتم التحكم في التعبئة من قبل مقترح واحد، سيكون التنفيذ أسهل).

في منشور حديث ، جادل ماكس وأناتولي بأن MCP يمكن أن تحقق فروق أسعار أضيق بين العرض والطلب من خلال تطبيق التسلسل المخصص (مفهوم NASDAQ اللامركزي). في البيئة الحالية ، كما ذكرنا سابقا ، يمكن لقائد واحد فقط اقتراح الكتل. هذا يعني أنه عندما يتقلب السعر ، سيحاول الطرف المعروض في دفتر الطلبات عكس عروض أسعار معينة. بموجب نموذج مقدم الاقتراح الفردي لسولانا ، لا يمكن القيام بذلك إلا من خلال مزادات جيتو بسبب احتكار مقدم الاقتراح للسلطة. من الناحية المثالية ، كما يظهر Hyperliquid ، يجب إعطاء الأولوية لطلبات رد المبالغ المدفوعة للسماح لصناع السوق بالحفاظ على فروق أسعار أضيق. لذلك ، من المأمول أن يتم تحقيق ذلك من خلال ASS كتطبيق - لديهم احتكار لسلطة المزاد في إطار نموذج القائد الواحد ، ويمكن القضاء على هذا الاحتكار من خلال اعتماد MPC. ومع ذلك ، من المحتمل أن يقتصر حل ASS هذا على سيناريوهات عزل الحالة. يتمثل جوهر الاقتراح في السماح لمطوري التطبيقات بتحديد الإجراءات ذات الأولوية (على سبيل المثال ، إلغاء الطلبات) لحسابات محددة ، وإعطاء الأولوية للمعاملات ذات الأولوية القصوى (ليس بالضرورة معاملات الإكرامية الأعلى ، ولكن شريان الحياة للسيولة) لحسابات محددة. الفكرة الأساسية هي تحديد حد رسوم للصفقات العادية ، مع السماح لبعض الصفقات ذات الأولوية باختراق الحد.

تمت مناقشة مشكلة رسوم التعبئة ورسوم الترتيب في النص السابق، ويبدو أن سولانا لديها خطة للتعامل معها. تذهب رسوم التعبئة إلى مُصادق المعاملات، بينما تُدفع رسوم الترتيب للبروتوكول (لإتلافها). عند دمج عدة كتل فرعية، يكفي ترتيب مجموعة المعاملات المدمجة وتنفيذها وفقًا لرسوم الترتيب المعدة مسبقًا.

! iYPNZnNzqp5tf0XoZCz0g88JRxA3c57RpBWm2aOw.png

تتعاون الآلية المذكورة بشكل وثيق مع آلية نشر الكتل في سولانا المعروفة باسم توربين. يقوم القادة (MCP) باستخدام تجزئة البيانات (shreds) لإرسالها إلى عقد الترحيل في هيكل شجرة توربين - يجب أن تحتوي هذه العقد على التجزئات من جميع القادة. تقوم عقد الترحيل بإرسال تأكيدات التجزئة إلى قائد إجماع واحد، ويجب على هذا القائد جمع عدد كافٍ من رسائل التجزئة قبل أن يقوم بالبث والتوصل إلى إجماع.

مع إصدار Alpenglow، وبالنظر إلى إلغاء بنية عقد الترحيل أحادية الطبقة وآلية التصويت على السلسلة (التي تم تحويلها الآن إلى بالكامل على السلسلة)، قد يتم تعديل التنفيذ المحدد. من المتوقع أن تقلل هذه التغييرات من تكاليف تشغيل المدققين، مما يزيد من عدد المدققين ويجذب المشاركين ذوي القدرات الفنية الضعيفة. هذا مفيد بالتأكيد لللامركزية، لكنه قد يؤثر على أداء السلسلة. ما يستحق المناقشة هو كيف سيتعاملون مع مشكلة فشل المدققين بعد تنفيذ MCP في Solana.

**3،**ممارسات MCP في بيئات أخرى

تقوم بيئة كوزموس أيضًا بدفع تنفيذ MCP، حيث أصدرت المؤسسة المعروفة Informal Systems مؤخرًا معيار المقترحات المتعددة تحت نموذج الإجماع BFT. يستخدمون بروتوكول البث الآمن، ويتطلبون من خلال آلية التصويت أن يحصل كل كتلة فرعية للمدقق على تأكيد من مدققين آخرين. بعد ذلك، توصلت وحدة بناء الكتل في Tendermint/CometBFT إلى توافق بشأن مجموعة هذه الكتل الفرعية، مما يعني أن مدققًا معينًا سيولد عددًا كبيرًا من الكتل الفرعية.

تقوم Sei بتطوير MCP (بهدف أن يكون أول مشروع يتم تنفيذه) من خلال مشروع Sei Giga ، المستوحى جزئيا من مقالة Autobahn (موصى به بشدة). تتمثل الفكرة الأساسية في فصل توافر البيانات عن الفرز ، وتسريع توافر البيانات من خلال قنوات متوازية متعددة ، وأخيرا الفرز إلى السلسلة العالمية. يختلف هذا قليلا عن مفهوم MCP الخاص ب Ethereum ، حيث لا يقوم المدققون بمزامنة الكتل لفترة زمنية محددة ، لكنهم يستمرون في إنتاج الكتل ودمجها في عرض عالمي.

باتريك أوغريدي من كومونوير يستكشف أيضًا الحلول ذات الصلة.

أخيرًا، صمم مشروع دلتا طبقة أساسية تتمتع بميزة لوحة إعلانات مقاومة للرقابة، وفي الوقت نفسه، تقوم كل تطبيق بتشغيل مُرتب متزامن خاص بها، حيث يتم تسوية الكتل الناتجة في النهاية إلى طبقة الحالة العالمية.