التراكمية الخاصة بالتطبيق

أطروحة Cartesi: كيف يمكن لبيئات التنفيذ المعيارية الخاصة بالتطبيق أن تحل مشكلات قابلية البرمجة ، وتوسيع نطاق الحوسبة ، ودفع الابتكار.
بقلم: فيليبي أرجينتو وإريك دي مورا وأوغوستو تيكسيرا

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

وفي الوقت نفسه ، تتحمل بيئات التنفيذ والطبقات الحسابية التي تخطط لتوسيع نطاق القوة الحسابية من خلال التجميعات (سواء كانت متفائلة أو ZK أو ذات سيادة) مسؤولية مطابقة قدرات البيانات المتزايدة وتقديم بنية تحتية قوية بما يكفي لتطوير تطبيقات حقيقية.

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

اختار Cartesi هذا المسار بالذات ، مما يمنح المطورين حسابات أرخص بكثير وإمكانية بناء عقود ذكية قوية باستخدام مكتبات ومكونات مفتوحة المصدر موجودة داخل أوقات تشغيل نظام التشغيل في العالم الحقيقي

حالة الأنظمة التراكمية

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

بالإضافة إلى ذلك ، بالمقارنة مع خدمات Web 2.0 الخلفية التقليدية ، فإن تجربة ترميز العقود الذكية مقيدة بشكل كبير. إن القول بأن هناك مسافة كبيرة بين قدرات خوادم الويب التقليدية والعقود الذكية blockchain هو بخس.

مجموعات Ethereum و EVM هي أجهزة كمبيوتر لا مركزية تجبرك على التعامل مع الجوانب المذكورة أعلاه. إنها بطيئة للغاية و "أجهزة كمبيوتر غريبة" تتطلب من المطورين كتابة التعليمات البرمجية بلغات البرمجة المتخصصة.

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

مشكلة قابلية التوسع: دفاعًا عن مجموعات التحديثات الخاصة بالتطبيق

الشبكة التي يتحقق فيها الجميع من كل شيء ليست مستدامة للتبني الجماعي. في الإجماع العالمي ، تؤدي الزيادة في الطلب حتمًا إلى معارك آكلي لحوم البشر بين تطبيقات blockspace. يتحول هذا السيناريو إلى رسوم عالية ، مما يشكل حاجزًا متزايدًا أمام المشاريع والمستخدمين على حدٍ سواء. لمعالجة هذا الصراع ، تمحور Ethereum ، واقترح خارطة طريق تتمحور حول الالتفافات.

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

بعد الدمج ، ومع التطورات على EIP-4844 وتقسيم Ethereum ، ستقلل تكلفة إضافة البيانات إلى blockchain الخاصة بها بعدة أوامر من حيث الحجم. وفي الوقت نفسه ، تم تفويض القياس الحسابي لمشاريع التجميع (ومن هنا جاء الاسم المتمحور حول التجميع).

تخفي العلاقة بين بروتوكول Ethereum وحلول التجميع مشكلة لا تحظى بالاهتمام الذي تستحقه. لا تعد المجموعات المتوافقة مع EVM أفضل تصميم لتحقيق قابلية التوسع الحسابي لمطابقة المكاسب الكبيرة في توفر البيانات التي ستحققها Ethereum.

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

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

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

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

على وجه الخصوص ، فإن خيار التجميع المتفائل مع الحماية التفاعلية للاحتيال يمنح التطبيقات اللامركزية موارد حسابية قابلة للمقارنة مع السائدة (على سبيل المثال ، تتضمن مليارات من خطوات التعليمات ومساحات كبيرة لعناوين الذاكرة) دون الحاجة إلى أجهزة خاصة لتحقيق الإجماع. هذا ممكن فقط لأن أدوات إثبات الاحتيال التفاعلية تسمح للحكام ذوي الموارد الحسابية المحدودة بحكم النزاعات بين المحققين غير المحدودين من الناحية الحسابية. على وجه الخصوص ، يعتبر الحكم لدينا طبقة تسوية محدودة الموارد ، ومثبتاتنا عبارة عن مدققين تراكميين مع موارد حسابية غير محدودة نسبيًا. لفهم كيفية إمكانية ذلك بشكل أفضل ، راجع القسم 5.2 من الورقة الفنية الخاصة بـ Cartesi Core.

في بحثهم عن الحد الأقصى من قابلية التوسع والتخصيص ، يوجه مطورو التطبيقات والبروتوكولات انتباههم إلى أشكال مختلفة من السلاسل الخاصة بالتطبيقات. بعض الأمثلة هي: Ronin sidechain من Axie Infinity ، وسلسلة dYdX السيادية ، وتصميم التحجيم النمطي هندسيًا من Starkware ، وطبقات التنفيذ المعيارية لشركة Celestia.

يمكن لسلاسل التجميع الخاصة بالتطبيق تلبية هذا الطلب ، مع ميزة عدم تكبد التجزئة الخطيرة للتحقق من صحة السلاسل الخاصة بالتطبيقات السيادية (الطبقة الأولى). بدلاً من ذلك ، ترث سلاسل التجميع الخاصة بالتطبيق ضمانات الأمان القوية للطبقات الأساسية الأساسية دون الاعتماد على الجسور عبر السلسلة ، والتي ثبت أنها خطيرة.

تنبع الميزة التكنولوجية لسلاسل التطبيقات التراكمية من حقيقة أنها آمنة مع أحزاب صادقة من فئة 1 من N بدلاً من ضرورة وجود أغلبية صادقة. باختصار ، تعد مجموعات التحديثات الخاصة بالتطبيق جيدة مثل سلاسل جانبية خاصة بالتطبيق ، دون التنازلات الكبيرة في الأمان.

يمكن تصور تأثيرات التحجيم المتزامن للقدرة الحاسوبية وتوافر البيانات بمساعدة الشكل أعلاه.

ينقسم الشكل إلى مناطق رئيسية ، تمثل حلول القياس التي يتم دمجها وكيفية أدائها من حيث القدرة الحسابية والبيانات. تتحسن السعة الحسابية عندما ننتقل من طبقة الإيثيريوم الأولى إلى مجموعات EVM وأخيراً إلى سلاسل التطبيقات المخصصة ، بينما تتحسن البيانات بإضافة EIP-4844 والتجزئة. يُظهر المخروط الأزرق التطبيقات التي تصبح ممكنة تدريجياً مع المقاييس في كلا البعدين. نحن نطلق على مخروط Blue Area web3 للابتكار.

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

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

قضية البرمجة: دفاعًا عن أفضل التجريدات

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

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

المثال أعلاه بعيد كل البعد عن كونه فريدًا. يتم كتابة العديد من المكتبات (على سبيل المثال: 1 ، 2 ، 3 ، 4 ، 5 ، 6) في Solidity للمساعدة في تطوير العقود الذكية و DApps. لكن الوضع الحالي للغة لا يزال غير ناضج للغاية ، حيث لا تزال بعض المهام الأساسية تتطلب من الأشخاص اللجوء إلى المنتديات بحثًا عن المساعدة.

ليس هذا هو الواقع في صناعة البرمجيات التقليدية. على سبيل المثال ، احتاجت لعبة Angry Birds إلى نفس المكتبات مثل Topology (بعد كل شيء ، تتبع الكواكب والطيور الطائرة نفس قوانين الفيزياء). ومع ذلك ، لم يُجبر مطورو Angry Birds على كتابة كل سطر من التعليمات البرمجية يحتاجون إليه من البداية. توجد مكتبات موجودة لهذا الغرض في الأساس بكل لغة يمكن تخيلها!

الشيء الوحيد الذي يجعل من الممكن للمطورين التقليديين الوصول إلى جميع هذه المكتبات هو المعيار الذهبي لحل مشكلة قابلية البرمجة: نظام تشغيل كامل. يعتمد المطورون الذين يعملون في جميع المجالات ، بدءًا من Web2 إلى الألعاب التقليدية ووصولاً إلى إطلاق القمر الصناعي ، على نظام تشغيل لمنحهم الدعم الذي يحتاجون إليه. إن اللغات والمكتبات التي يحتاجون إليها لتجسيد أفكارهم هي ما يسمح لهم بتركيز جهودهم على ما يريدون حقًا بناءه ، بدلاً من البنية التحتية الأساسية التي تجعل ذلك ممكنًا.

هذا هو السبب في أننا اخترنا بنية RISC-V لبناء حل Rollups الخاص بنا. يجعل من الممكن نقل Linux أو أنظمة تشغيل أخرى إلى مجموعات. بهذه الطريقة ، يمكن للمطورين إحياء أفكارهم باللغات والمكتبات المفضلة لديهم ، دون التخلي عن ضمانات الأمان القوية لـ blockchain ، كما هو مفصل في المقالات السابقة (1 ، 2 ، 3).

حتى هذه النقطة ، كان Linux هو محور التركيز ، ولكن من الممكن تشغيل أي أنظمة تشغيل يمكن تجميعها إلى RISC-V ، مثل بعض النواة الصغيرة الآمنة جدًا الموجودة هناك.

تجميعات كارتيزي

ناقشنا أولاً أهمية طبقة تنفيذ التجميع المعيارية التي تقيس حقاً الحساب وتمنع DApps من المشاركة مع بعضها البعض في لعبة محصلتها صفر للموارد الحسابية. ثم شرحنا بالتفصيل مدى أهمية أن يعتمد المطورون على قوة التجريد لنظام التشغيل كما يفعل المطورون العاديون.

مع وضع هاتين الحاجتين في الاعتبار ، قمنا بتصميم وبناء Cartesi Rollups كطبقة تنفيذ معيارية توفر مزايا القياس التالية لـ DApps:

يحتوي كل تطبيق DApp على سلسلة تطبيقات تراكمية عالية الأداء مع وحدة معالجة مركزية مخصصة ؛
لا يوجد تفكيك للموارد من تطبيقات DApps الأخرى في النظام البيئي لـ Cartesi ؛
مكاسب كبيرة في قابلية التوسع الحسابي خارج بيئة لعبة محصلتها صفر ؛
الحفاظ على الضمانات الأمنية القوية لـ blockchain الأساسية ؛
نظام تشغيل متكامل يوفر أدوات على مستوى الصناعة للمطورين.
يمكن استخدام تطبيقات Cartesi Rollups كطبقة ثانية (أي أعلى Ethereum) ، كطبقة ثالثة (أي أعلى سلاسل Arbitrum أو ZK-EVM) أو كطبقة تراكمية ذات سيادة (أي أعلى Celestia). يمكن للمطورين نقل تطبيقاتهم من نظام أساسي إلى آخر بأقل تغييرات في التعليمات البرمجية.

الكلمات الأخيرة

تسمح Cartesi للمطورين بالتركيز على ما يبنونه بدلاً من المكان الذي يبنون فيه أو ما هي القيود المزعجة التي سيحتاجون إلى التعامل معها.

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

من منظور التخصيص ، تمنح سلاسل تطبيقات Cartesi Rollups DApps إمكانية فرض أسعار مختلفة للإجراءات المختلفة. يمكنهم ، على سبيل المثال ، التنازل عن رسوم الغاز لصانعي السوق في التبادلات اللامركزية أو زيادة تكلفة الصيد الجائر على جهاز محاكاة المحيطات DApp.

لدى Cartesi رؤية واضحة جدًا للثورة التي توشك على الحدوث في التقنيات اللامركزية. يتم تطوير Cartesi Rollups كإجابة تركز على الليزر لاحتياجات هذه البيئة الجديدة.

حول Cartesi

يقوم نظام التشغيل Blockchain OS ببناء Cartesi Rollups ، وهي طبقة تنفيذ معيارية ترفع العقود الذكية البسيطة إلى أوقات تشغيل Linux اللامركزية. يسمح للمطورين بإطلاق سلاسل تجميع قابلة للتطوير بدرجة كبيرة ، ومنطق لامركزي مع لغاتهم ومكونات البرامج المفضلة لديهم.

يحتوي كل تطبيق DApp على سلسلة تراكمية عالية الأداء ؛
لا تفكيك للموارد من تطبيقات DApps الأخرى في النظام البيئي لـ Cartesi ؛
لا يوجد تحسين للشبكة ؛
تمكين فئة جديدة تمامًا من DApps التي لا يمكن تشغيلها حاليًا على سلاسل EVM ؛
حافظ على الضمانات الأمنية القوية لـ blockchain الأساسية
مرحبًا بك في The Blockchain OS ، موطن ماهو قادم.