مقدمة

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

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

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

نختتم هذا المقال بملاحظة أن سلاسل الكتل تتجه نحو مستقبل حيث تكون الحوسبة مركزية، ولكن التحقق يظل مركزيًا. يعتبر ال Rollups، وحدات المعالجة المشتركة، وأي شكل آخر من الحوسبة خارج السلسلة القابل للتحقق مجرد تجسيدات مختلفة لهذا المستقبل.

كيف وصلنا إلى هنا:

في "حدود قدرة توسيع سلسلة الكتل" ، ذكر فيتاليك أنه بالنسبة للتفcentralization، من المهم أن يتمكن المستخدمون العاديون من تشغيل عقدة.

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

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

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

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

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

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

الذاكرة المقيدة - تحتوي العقود الذكية على حدود تخزين دائمة صغيرة، مما يجعل البرامج الكبيرة صعبة.

لا تخزين ملفات دائم - لا يوجد وسيلة لتخزين ملفات مثل الرسومات أو الصوت أو الفيديو على البلوكشين.

السرعة البطيئة - سرعات المعاملات على الإيثيريوم حاليًا حوالي 15 معاملة في الثانية، بمرات عديدة أبطأ من وحدة المعالجة المركزية.

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

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

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

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

هناك طريقتان شائعتان لجعل المزيد من الحوسبة متاحة لتطبيقات blockchain:

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

الأرشيف الويب (ملاحظة: نحن نستخدم متطلبات الذاكرة العشوائية الوسطية من عام 2020)

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

نحو توحيد الحوسبة خارج السلسلة

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

معالجات التعاون ZK: Axiom، Bonsai لـ Risc Zero.

TEEs: الحلزون مارلين،

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

قبل أن نذهب أبعد من ذلك، دعونا نعرف بإيجاز كل من التجميع والمعالجات المساعدة لمنع الالتباس:

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

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

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

قراءة / كتابة تخزين العقد أبطأ من نظام الملفات أو قاعدة البيانات. قد يكلف الوصول إلى 1 كيلوبايت من البيانات ملايين الغاز.

بينما يستمر الحالة العالمية، تحتفظ العقد الفردية فقط بالحالة الأخيرة محليًا في وضع "التقليم". تتطلب تاريخ الحالة الكاملة عقد الأرشيف.

لا توجد مبادئ أساسية لنظام الملفات الأصلي لمعالجة الملفات مثل الصور والصوت والمستندات. يمكن للعقود الذكية قراءة/كتابة أنواع بيانات أساسية فقط إلى التخزين.

الحلول حول هذا هي:

يمكن تقسيم الملفات الكبيرة إلى قطع أصغر لتناسب الحدود التخزينية للعقد.

يمكن تخزين مراجع الملفات على السلسلة، مع تخزين الملفات خارج السلسلة في أنظمة مثل IPFS.

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

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

لذلك، يبدو أن أكبر اختلافين بين اللفات والمعالجات المشتركة هما:

تحتفظ تكديسات بحالة مستمرة مقسمة، والمعالجات المشتركة لا تفعل ذلك (فهي تستخدم حالة سلسلة المضيف).

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

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

في حديث في قمة Modular Summit، 2023 بعنوان "المعاملات المحمية هي Rollups"، تحدث هنري دي فالانس عن هذا المفهوم الدقيق وقدم صورة بسيطة جدًا لتعريف Rollup:

تفترض المحادثة أن أي تنفيذ يتم تحميله من قبل السلسلة الأساسية إلى طرف ثالث هو Rollup. بموجب تعريفه، ستكون الكوبروسيسورات أيضًا Rollups. يختلف هذا قليلاً عن وجهة نظرنا في توحيد Rollups و Coprocessors تحت راية الحوسبة التحقق منها خارج السلسلة لكن المشاعر العامة تظل كما هي!

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

نفس الشيء ولكن مختلف

على الرغم من تشابهها العام، فإن الرول أبز ومعالجات العمل تخدم الأسواق المختلفة تماما اليوم. قد يسأل أحدهم، 'إذا كان بإمكاننا فقط استخدام معالج العمل على ETH L1 والوصول إلى سيولته، لماذا نحتاج إلى الرول أبز؟' على الرغم من أن هذا سؤال معقول، إلا أننا نعتقد أن هناك بعض الأسباب التي تجعل الرول أبز لا تزال منطقية (وتمثل فرصة سوق أكبر بكثير من معالجات العمل اليوم)

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

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

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

نقطة مهمة أخرى للإشارة إليها هنا هي أن معظم السيولة اليوم تقع على ETH L1، لذا بالنسبة للعديد من البروتوكولات التي تعتمد على السيولة لتحسين منتجاتها، فقد يكون من الحكمة الإطلاق على شبكة Ethereum mainnet. يمكن لتطبيق على Ethereum mainnet الحصول على وصول إلى المزيد من الحوسبة عن طريق القيام بشكل متقطع بالمعاملات على معالج فرعي. على سبيل المثال، يمكن لـ DEX مثل Ambient أو Uniswap v4 استخدام الخطافات بالتزامن مع المعالجات الفرعية للقيام بمنطق معقد حول كيفية تغيير الرسوم أو حتى تعديل شكل منحنى السيولة بناءً على بيانات السوق.

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

مستقبل قائم على الأدلة

إذا انتهينا في عالم حيث يتم تركيز الحسابات، لكن التحقق من الحساب المركزي غير موثوق ومفcentralizه للغاية، فأين سيترك ذلك الإيثيريوم؟ هل سيتم تقليل الكومبيوتر العالمي إلى مجرد قاعدة بيانات؟ هل هذا شيء سيء؟

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

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

كل شيء في الأخير، نحن نعتقد أننا نتجه نحو النموذج التالي:

————————————————————لا تثق، تحقق————————————————————-

إخلاء المسؤولية:

1. تم نشر هذه المقالة من [Gateمرآة]. جميع حقوق النشر تنتمي إلى الكاتب الأصلي [جايكوب كو]. إذا كانت هناك اعتراضات على هذه الإعادة طباعتها، يرجى الاتصال بالبوابة تعلمالفريق، وسيتولون بذلك على الفور.
2. تنصل المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط تلك التي يعبر عنها المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم الترجمات للمقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.