الطريق إلى التحقق

الميزة الأساسية لـ Web3 هي التحقق - يمكن للمستخدمين التحقق من كيفية عمل الأنظمة في الواقع. تفسير هذه الميزة يشرح لماذا يصف العديد من داخل وخارج صناعة العملات الرقمية Web3 كخطوة نحو إنترنت أكثر شفافية وقابلية للتحقق.

على عكس منصات Web2 مثل Facebook أو Instagram ، حيث يبقى خوارزميات وقواعد غامضة حتى عند وثقها ، تم تصميم بروتوكولات العملات المشفرة للحصول على قدر كامل من القابلية للتدقيق. حتى إذا تمت مشاركتها ، فإنك تفتقر إلى القدرة على التحقق مما إذا كانت المنصة تعمل وفقًا للمواصفات المحددة. هذا هو العكس تمامًا للعملات المشفرة ، حيث يتم تصميم كل بروتوكول ليكون قابلاً للتدقيق قدر الإمكان - أو على الأقل من المتوقع أن يكون.

اليوم، سنستكشف “ذا فيرج”، قسمًا من المقال الذي نشره مؤخرًا فيتاليك.سلسلة مكونة من ستة أجزاء حول مستقبل إثيريوم, لتحليل الخطوات التي يقوم بها إثيريوم نحو تحقيق القابلية للتحقق والاستدامة والتوسع في المستقبل. تحت عنوان ‘الحافة’، سنناقش كيف يمكن جعل هندسة البلوكشين أكثر قابلية للتحقق، والابتكارات التي تجلبها هذه التغييرات على مستوى البروتوكول، وكيف توفر للمستخدمين نظام بيئي أكثر أمانًا. دعونا نبدأ!

ماذا يعني “قابلية التحقق”؟

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

اللامركزية ما تستطيع تحققه، وتحقق الباقي.

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

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

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

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

بعد طبقة الإجماع، هناك طبقة التنفيذ التي توجد في كل بلوكشين. تتشكل طبقة التنفيذ من المعاملات التي يرغب المستخدمون في تنفيذها.

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

إذا كان لديك 100 دولار في الحالة التي نسميها “S” وترغب في إرسال 10 دولارات لشخص آخر، سيكون رصيدك في الحالة التالية، “S+1”، 90 دولارًا. هذه العملية لتطبيق المعاملات للانتقال من حالة إلى أخرى هي ما نسميه بـ STF (وظيفة انتقال الحالة).

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

في سلسلة الكتل، هناك ثلاث مكونات أساسية تحتاج إلى التحقق منها أو يمكنك التحقق منها:

1. الحالة: قد ترغب في قراءة قطعة من البيانات على سلسلة الكتل، ولكن تفتقد الوصول إلى الحالة لأنك لا تقوم بتشغيل نود كامل. لذلك، تطلب البيانات عبر موفر RPC (Remote Procedure Call) مثل Alchemy أو Infura. ومع ذلك، يجب عليك التحقق من أن البيانات لم يتم التلاعب بها من قبل موفر RPC.
2. التنفيذ: كما ذكر سابقًا ، تستخدم سلاسل الكتل STF. يجب عليك التحقق من أن انتقال الحالة تم تنفيذه بشكل صحيح - ليس على أساس كل عملية واحدة ولكن على أساس كتلة بكتلة.
3. التوافق: يمكن للكيانات الخارجية مثل RPCs أن تزودك بكتل صالحة لم تتم إضافتها بعد في سلسلة الكتل. لذا، يجب عليك التحقق من أن تلك الكتل تم قبولها بالتوافق وإضافتها إلى سلسلة الكتل.

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

كيفية التحقق من حالة البلوكشين؟

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

كل كتلة Ethereum تحتوي على قيمة تلخص الحالة الحالية للشبكة بعد تلك الكتلة: stateRoot. هذه القيمة هي تمثيل مضغوط للحالة الكاملة لـ Ethereum ، وتتكون من هاش 64 حرفاً.

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

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

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

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

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

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

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

1. العقدة الورقية: تحتوي هذه العقد على التجزئة الفرعية للبيانات الفردية وتوجد في المستوى السفلي من الشجرة. تمثل كل عقدة ورقية التجزئة الخاصة ببيانات محددة في شجرة ميركل.
2. العقدة الفرعية: تحتوي هذه العقدة على مجموع التجزئة لعقدات الأطفال المرتبطة بها. على سبيل المثال، في شجرة ميركل الثنائية (حيث N=2)، يتم دمج تجزئتي عقدتين فرعيتين ومن ثم إجراء التجزئة مرة أخرى لإنتاج تجزئة لعقدة فرعية على مستوى أعلى.
3. العقدة الجذرية: العقدة الجذرية هي في أعلى مستوى من شجرة ميركل وتمثل الملخص الرمزي للشجرة بأكملها. يتم استخدام هذه العقدة للتحقق من سلامة وصحة جميع البيانات داخل الشجرة.

إذا كنت تتساءل عن كيفية بناء مثل هذه الشجرة، فإنه ينطوي على خطوتين بسيطتين فقط:

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

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

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

كيف نستخدم جذور Merkle للتحقق من حالة إثيريوم؟

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

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

مثال: التحقق من نقطة البيانات باستخدام دليل Merkle

لنفترض أننا تلقينا البيانات رقم 4 من RPC ونرغب في التحقق من صحتها باستخدام دليل ميركل. للقيام بذلك، سيقدم RPC مجموعة من قيم التجزئة على طول المسار اللازم للوصول إلى جذر ميركل. بالنسبة للبيانات 4، ستتضمن هذه التجزئة الشقيقة قيم التجزئة #3 والتجزئة #12 والتجزئة #5678.

1. ابدأ بالبيانات 4: أولاً، نقوم بعمل تجزئة للبيانات رقم 4 للحصول على التجزئة رقم 4.
2. دمج مع الأشقاء: بعد ذلك نقوم بدمج Hash #4 مع Hash #3 (أخيها عند مستوى الأوراق) ونقوم بعمل هاش لهما معًا لإنتاج Hash #34.
3. تحرك لأعلى في الشجرة: بعد ذلك، نأخذ الهاش #34 ونجمعه مع الهاش #12 (شقيقه في المستوى التالي لأعلى) ونقوم بعمل هاش للحصول على الهاش #1234.
4. الخطوة النهائية: في النهاية، نقوم بدمج الهاش #1234 مع الهاش #5678 (الأخير المقدم) ونقوم بدمجهما معًا. يجب أن يتطابق الهاش الناتج مع الجذر الميركل (الهاش #12345678) المخزن في رأس الكتلة.

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

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

عاملان رئيسيان يؤثران على أداء شجرة ميركل: ⌛

1. عامل الفروع: عدد عقد الأطفال في الفرع الواحد.
2. حجم البيانات الإجمالي: حجم مجموعة البيانات التي تمثل في الشجرة.

تأثير عامل الفرع:

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

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

تأثير حجم البيانات الإجمالي:

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

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

في الختام، على الرغم من أن أشجار Merkle تقدم درجة من الكفاءة، إلا أنها لا تصل إلى أن تكون حلاً مثلى لمجموعة البيانات المتزايدة باستمرار في إثيريوم. لهذا السبب، خلال مرحلة The Verge، تهدف إثيريوم إلى استبدال أشجار Merkle ببنية أكثر كفاءة تعرف باسمأشجار فيركلي. تتمتع Verkle Trees بالقدرة على تقديم أحجام إثبات أصغر مع الحفاظ على نفس المستوى من الأمان ، مما يجعل عملية التحقق أكثر استدامة وقابلية للتطوير لكل من Provers و Verifiers.

الفصل 2: تحديث إمكانية التحقق في إثيريوم - ذا فيرج

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

منذ الانتقال إلى نموذج الموافقة بالحصة بعد الدمج ، كان لدى محققي إثيريوم مسؤوليتين رئيسيتين:

1. ضمان التوافق: دعم العمل السليم لكل من بروتوكولات التوافق الاحتمالية والحاسمة وتطبيق خوارزمية اختيار التفرعات.
2. التحقق من دقة الكتلة: بعد تنفيذ المعاملات في كتلة، التحقق من مطابقة جذر شجرة الحالة الناتجة مع جذر الحالة المعلن من قبل المُقترح.

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

أول خطوة في التحقق من الصحة: الحالة

الانتقال إلى أشجار Verkle جزء أساسي من هذه العملية. في البداية ، ركزت The Verge على استبدال هياكل شجرة Merkle الخاصة بـ Ethereum بأشجار Verkle. السبب الرئيسي وراء اعتماد أشجار Verkle هو أن شجرة Merkle تشكل عقبة كبيرة للتحقق من صحة Ethereum. بينما يمكن لشجرة Merkle ودلائلها العمل بكفاءة في السيناريوهات العادية ، فإن أدائها يتدهور بشكل كبير في سيناريوهات الحالات الأسوأ.

وفقًا لحسابات فيتاليك ، يبلغ حجم الدليل المتوسط حوالي 4 كيلوبايت ، مما يبدو مُدارًا. ومع ذلك ، في الحالات الأسوأ ، يمكن أن يتضخم حجم الدليل إلى 330 ميغابايت. نعم ، قرأت ذلك بشكل صحيح - 330 ميغابايت.

تعود الكفاءة المتناقصة لأشجار مركل في إثيريوم في أسوأ الحالات إلى سببين رئيسيين:

1. استخدام الأشجار السداسية: يستخدم إثيريوم حاليًا أشجار ميركل بعامل فروع يبلغ 16. وهذا يعني أن التحقق من عقد واحد يتطلب تقديم العلامات المتبقية 15 في الفرع. نظرًا لحجم حالة إثيريوم وعدد الفروع، يخلق هذا عبءًا كبيرًا في السيناريوهات الأسوأ.

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

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

لهذه الأسباب، اقترح مجتمع إثيريوم حلولًا متميزة لمعالجة هذه المسألة:

1. أشجار Verkle
2. براهين STARK + أشجار ميركل الثنائية

شجرة Verkle والتزامات الاتجاه

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

في المقابل ، تستخدم Verkle Trees بنية متخصصة تعرف باسم “التزامات المتجهات القائمة على المنحنى الإهليلجي” ، وبشكل أكثر تحديدا ، التزام المتجه القائم على حجة المنتج الداخلي (IPA). المتجه هو في الأساس قائمة بعناصر البيانات المنظمة في تسلسل معين. يمكن اعتبار حالة Ethereum كمتجه: هيكل يتم فيه تخزين العديد من أجزاء البيانات بترتيب معين ، مع كون كل عنصر حاسما. تشتمل هذه الحالة على مكونات بيانات مختلفة مثل العناوين ورموز العقود ومعلومات التخزين ، حيث يلعب ترتيب هذه العناصر دورا مهما في الوصول والتحقق.

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

على عكس أشجار Merkle ، تستخدم أشجار Verkle التزامات بيانات نقطية مستندة إلى المنحنيات البيضاء توفر ميزتين رئيسيتين:

• تقنية إلتيبتيك كيرف-فيكتور كوميتمنت تقضي على الحاجة لتفاصيل العناصر غير المراد التحقق منها. في شجرة ميركل ذات عامل تفرع قدره 16، يتطلب التحقق من فرع واحد توفير العشرين هاش الأخرى. نظرًا لحجم حالة إيثريوم الهائل الذي ينطوي على فروع عديدة، فإن ذلك يخلق عدم كفاءة كبيرة. لكن تقنية إلتيبتيك كيرف-فيكتور كوميتمنت تتميز بتقليل هذه العقدة، وتتيح التحقق بجهد حسابي وبيانات أقل.
• من خلال البراهين المتعددة ، يمكن ضغط البراهين الناتجة عن التزامات المتجه القائمة على المنحنى الإهليلجي في دليل واحد ثابت الحجم. حالة Ethereum ليست كبيرة فحسب ، بل تنمو أيضا باستمرار ، مما يعني أن عدد الفروع التي تحتاج إلى التحقق للوصول إلى Merkle Root يزداد بمرور الوقت. ومع ذلك ، باستخدام Verkle Trees ، يمكننا “ضغط” البراهين لكل فرع في دليل واحد ثابت الحجم باستخدام الطريقة المفصلة في مقال دانكراد فايست. يتيح هذا للمحققين التحقق من الشجرة بأكملها باستخدام دليل صغير بدلاً من التحقق من كل فرع على حدة. يعني ذلك أيضًا أن شجرات Verkle غير متأثرة بنمو حالة إثيريوم.

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

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

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

STARK proofs + الأشجار الميركل الثنائية

تقدم Verkle Trees أحجام إثبات أصغر وعمليات تحقق فعالة مقارنة بأشجار Merkle ، مما يسهل إدارة حالة Ethereum المتنامية باستمرار. بفضل التزامات المتجهات القائمة على المنحنى الإهليلجي ، يمكن إنشاء براهين واسعة النطاق ببيانات أقل بكثير. ومع ذلك ، على الرغم من مزاياها المثيرة للإعجاب ، فإن ضعف Verkle Trees أمام أجهزة الكمبيوتر الكمومية يجعلها مجرد حل مؤقت. بينما يرى مجتمع Ethereum Verkle Trees كأداة قصيرة الأجل لكسب الوقت ، ينصب التركيز على المدى الطويل على الانتقال إلى حلول مقاومة للكم. هذا هو المكان الذي تقدم فيه STARK Proofs و Binary Merkle Trees بديلا قويا لبناء بنية تحتية أكثر قوة للتحقق في المستقبل.

في عملية التحقق من حالة إثيريوم ، يمكن تقليل عامل التفرع في أشجار ميركل (من 16 إلى 2) باستخدام أشجار ميركل الثنائية. هذا التغيير هو خطوة حاسمة لتقليل أحجام البرهان وجعل عمليات التحقق أكثر كفاءة. ومع ذلك ، حتى في أسوأ السيناريوهات ، يمكن لأحجام البرهان أن تصل إلى 10 ميجابايت ، وهو أمر كبير. هنا تأتي دلائل STARK لتضغط هذه البراهين الثنائية الكبيرة إلى ما يقرب من 100-300 كيلوبايت فقط.

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

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

التحديات الرئيسية لدلائل STARK:

1. الحمل الحسابي العالي للبروفرز: \
   عملية إنشاء أدلة STARK مكثفة حسابيا، خاصةً من جانب الدليل، مما يمكن أن يزيد من تكاليف التشغيل.
2. عدم الكفاءة في إثباتات البيانات الصغيرة:

على الرغم من أن STARK proofs تتفوق في التعامل مع مجموعات البيانات الكبيرة ، إلا أن كفاءتها أقل عند إثبات كميات صغيرة من البيانات ، مما يمكن أن يعوق تطبيقها في سيناريوهات معينة. عند التعامل مع البرامج التي تنطوي على خطوات أو مجموعات بيانات أصغر ، يمكن أن يجعل حجم البرهان النسبي الكبير لـ STARKs منها أقل عملية أو فعالة من حيث التكلفة.

يأتي الأمن الكمي بتكلفة: الحمل الحسابي من جانب Prover

يمكن أن يتضمن دليل Merkle Proof للكتلة حوالي 330،000 تجزئة، وفي أسوأ السيناريوهات، يمكن أن يرتفع هذا الرقم إلى 660،000. في مثل هذه الحالات، سيحتاج دليل STARK إلى معالجة حوالي 200،000 تجزئة في الثانية.

هذا هو المكان الذي تلعب فيه وظائف التجزئة الصديقة ل zk مثل Poseidon ، والتي تم تحسينها خصيصا لبراهين STARK لتقليل هذا الحمل. تم تصميم Poseidon للعمل بسلاسة أكبر مع براهين ZK مقارنة بخوارزميات التجزئة التقليدية مثل SHA256 و Keccak. يكمن السبب الرئيسي لهذا التوافق في كيفية عمل خوارزميات التجزئة التقليدية: فهي تعالج المدخلات كبيانات ثنائية (0s و 1s). من ناحية أخرى ، تعمل براهين ZK مع الحقول الأولية ، والهياكل الرياضية التي تختلف اختلافا جوهريا. هذا الموقف مشابه لأجهزة الكمبيوتر التي تعمل في النظام الثنائي بينما يستخدم البشر نظاما عشريا في الحياة اليومية. تتضمن ترجمة البيانات المستندة إلى البتات إلى تنسيقات متوافقة مع ZK عبئا حسابيا كبيرا. يحل Poseidon هذه المشكلة من خلال العمل أصلا في الحقول الرئيسية ، مما يسرع بشكل كبير من تكامله مع أدلة ZK.

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

على سبيل المثال، يمكن لبراهين ستارك باستخدام تلك الدوال الهاش التقليدية معالجة 10,000 إلى 30,000 هاش حالياً. لحسن الحظ، تقترح التطورات في تكنولوجيا ستارك أن هذه الطاقة الاستيعابية قد تزيد قريباً إلى 100,000 إلى 200,000 هاش، مما يحسن بشكل كبير كفاءتها.

عدم كفاءة STARKs في إثبات البيانات الصغيرة

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

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

في حالات الاستخدام هذه ، توفر براهين STARK ميزة قليلة. تعمل STARKs ، التي تركز على قابلية التوسع (كما هو موضح بواسطة “S” في اسمها) ، بشكل جيد لمجموعات البيانات الكبيرة ولكنها تكافح مع سيناريوهات البيانات الصغيرة. على النقيض من ذلك ، تركز SNARKs ، المصممة للإيجاز (كما يؤكد الحرف “S” في اسمها) ، على تقليل حجم الدليل ، مما يوفر مزايا واضحة في البيئات ذات النطاق الترددي أو قيود التخزين.

عادة ما يكون حجم براهين STARK 40-50 كيلوبايت ، وهو أكبر بحوالي 175 مرة من براهين SNARK ، والتي تبلغ 288 بايت فقط. يزيد اختلاف الحجم هذا من وقت التحقق وتكاليف الشبكة. السبب الرئيسي لبراهين STARKs الأكبر هو اعتمادها على الشفافية والالتزامات متعددة الحدود لضمان قابلية التوسع ، والتي تقدم تكاليف الأداء في سيناريوهات البيانات الصغيرة. في مثل هذه الحالات ، قد تكون الطرق الأسرع والأكثر كفاءة في المساحة مثل Merkle Proofs أكثر عملية. تقدم Merkle Proofs تكاليف حسابية منخفضة وتحديثات سريعة ، مما يجعلها مناسبة لهذه المواقف.

على الرغم من ذلك، تظل إثباتات STARK أمرًا حاسمًا لمستقبل إثيريوم الخالي من الحالة بسبب أمانها الكمي.

كما تم تلخيصه في الجدول، لدى إثيريوم أربع مسارات محتملة للاختيار من بينها:

• أشجار فيركيل
  1. تلقت Verkle Trees دعما واسعا من مجتمع Ethereum ، مع عقد اجتماعات نصف شهرية لتسهيل تطويرها. بفضل هذا العمل والاختبار المتسقين ، تبرز Verkle Trees باعتبارها الحل الأكثر نضجا ومدروسا جيدا بين البدائل الحالية. علاوة على ذلك ، فإن خصائصها المتجانسة المضافة تلغي الحاجة إلى إعادة حساب كل فرع لتحديث جذر الحالة ، على عكس أشجار Merkle ، مما يجعل Verkle Trees خيارا أكثر كفاءة. بالمقارنة مع الحلول الأخرى ، تؤكد Verkle Trees على البساطة ، وتلتزم بالمبادئ الهندسية مثل “اجعلها بسيطة” أو “البساطة هي الأفضل”. تسهل هذه البساطة الاندماج في Ethereum وتحليل الأمان.
  2. ومع ذلك ، فإن أشجار Verkle ليست آمنة كميا ، مما يمنعها من أن تكون حلا طويل الأجل. إذا تم دمج هذه التكنولوجيا في Ethereum ، فمن المحتمل أن تحتاج إلى استبدالها في المستقبل عندما تكون هناك حاجة إلى حلول مقاومة للكم. حتى فيتاليك ينظر إلى أشجار Verkle كإجراء مؤقت لكسب الوقت لتنضج STARKs والتقنيات الأخرى. بالإضافة إلى ذلك ، تفرض التزامات المتجهات القائمة على المنحنى الإهليلجي المستخدمة في Verkle Trees حملا حسابيا أعلى مقارنة بدالات التجزئة البسيطة. قد توفر الأساليب القائمة على التجزئة أوقات مزامنة أسرع للعقد الكاملة. علاوة على ذلك ، فإن الاعتماد على العديد من عمليات 256 بت يجعل من الصعب إثبات Verkle Trees باستخدام SNARKs ضمن أنظمة الإثبات الحديثة ، مما يعقد الجهود المستقبلية لتقليل أحجام الإثبات.

مع ذلك ، من المهم أن نلاحظ أن أشجار Verkle ، بسبب عدم اعتمادها على التجزئة ، هي أكثر إثباتًا بكثير من أشجار Merkle.

• STARKs + وظائف التجزئة المحافظة
  1. يوفر الجمع بين STARKs ووظائف التجزئة المحافظة الراسخة مثل SHA256 أو BLAKE حلا قويا يعزز البنية التحتية الأمنية ل Ethereum. تم استخدام وظائف التجزئة هذه على نطاق واسع واختبارها على نطاق واسع في كل من المجالات الأكاديمية والعملية. بالإضافة إلى ذلك ، تعزز مقاومتها الكمومية مرونة Ethereum ضد التهديدات المستقبلية التي تشكلها أجهزة الكمبيوتر الكمومية. بالنسبة للسيناريوهات الأمنية الحرجة ، يوفر هذا المزيج أساسا موثوقا به.
  2. ومع ذلك ، فإن استخدام وظائف التجزئة المحافظة في أنظمة STARK يقدم قيودا كبيرة على الأداء. تؤدي المتطلبات الحسابية لوظائف التجزئة هذه إلى زمن انتقال عالي للبروفير ، حيث يستغرق إنشاء الإثبات أكثر من 10 ثوان. هذا عيب كبير ، خاصة في سيناريوهات مثل التحقق من صحة الكتلة التي تتطلب زمن انتقال منخفض. في حين أن الجهود مثل مقترحات الغاز متعددة الأبعاد تحاول مواءمة أسوأ الحالات ومتوسط زمن انتقال الحالة ، فإن النتائج محدودة. بالإضافة إلى ذلك ، على الرغم من أن الأساليب القائمة على التجزئة يمكن أن تسهل أوقات مزامنة أسرع ، إلا أن كفاءتها قد لا تتوافق مع أهداف قابلية التوسع الأوسع نطاقا ل STARKs. تقلل أوقات الحساب الطويلة لوظائف التجزئة التقليدية من الكفاءة العملية وتحد من إمكانية تطبيقها.
• STARKs + وظائف تجزئة جديدة نسبيا
  1. تجمع STARKs مع وظائف التجزئة الجديدة الودية لل STARK من الجيل الجديد (مثل Poseidon) تحسين الأداء لهذه التكنولوجيا بشكل كبير. تم تصميم هذه الوظائف للاندماج بسلاسة مع أنظمة STARK وتقليل وقت الانتظار لمولد البرهان بشكل كبير. على عكس وظائف التجزئة التقليدية ، فإنها تتيح إنشاء البرهان في غضون 1-2 ثانية فقط. كفاءتها والإجهاد الحسابي المنخفض يعززان إمكانيات التوسع ل STARKs ، مما يجعلها فعالة للغاية في التعامل مع مجموعات البيانات الكبيرة. هذه القدرة تجعلها خاصة جذابة للتطبيقات التي تتطلب أداءً عاليًا.
  2. ومع ذلك، فإن الجديد نسبيًا لهذه الوظائف الهاش يستلزم تحليل أمان شامل واختبار. نقص التحليل الشامل يُدخل المخاطر عند النظر في تنفيذها في النظم البيئية الحرجة مثل إثيريوم. بالإضافة إلى ذلك، نظرًا لعدم اعتماد هذه الوظائف الهاش بشكل واسع حتى الآن، فإن عمليات الاختبار والتحقق المطلوبة قد تؤدي إلى تأخير أهداف إثيريوم فيما يتعلق بالتحقق. قد يجعل الوقت اللازم لضمان أمانها بالكامل هذا الخيار أقل جاذبية على المدى القصير، مما قد يؤجل طموحات إثيريوم فيما يتعلق بقابلية التوسع والتحقق.
• أشجار ميركل القائمة على الشبكة
  1. تقدم Merkle Trees القائمة على الشبكة حلا مستقبليا يجمع بين الأمان الكمي وكفاءة التحديث في Verkle Trees. تعالج هذه الهياكل نقاط الضعف في كل من Verkle Trees و STARKs وتعتبر خيارا واعدا على المدى الطويل. من خلال تصميمها القائم على الشبكة ، فإنها توفر مقاومة قوية لتهديدات الحوسبة الكمومية ، بما يتماشى مع تركيز Ethereum على إثبات نظامها البيئي في المستقبل. علاوة على ذلك ، من خلال الاحتفاظ بمزايا التحديث ل Verkle Trees ، فإنها تهدف إلى توفير أمان محسن دون التضحية بالكفاءة.
  2. ومع ذلك ، لا يزال البحث في أشجار ميركل القائمة على الشبكة في مراحله المبكرة ونظريا إلى حد كبير. وهذا يخلق قدرا كبيرا من عدم اليقين بشأن تنفيذها العملي وأدائها. سيتطلب دمج مثل هذا الحل في Ethereum بحثا وتطويرا مكثفا ، بالإضافة إلى اختبارات صارمة للتحقق من فوائده المحتملة. هذه الشكوك وتعقيدات البنية التحتية تجعل من غير المرجح أن تكون أشجار ميركل القائمة على الشبكة خيارا ممكنا ل Ethereum في المستقبل القريب ، مما قد يؤخر التقدم نحو أهداف التحقق من الشبكة.

ماذا عن التنفيذ: إثباتات صلاحية تنفيذ EVM

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

في البداية ، تم تصور The Verge كمعلم يركز فقط على نقل شجرة ولاية Ethereum من أشجار Merkle إلى Verkle Trees لتحسين إمكانية التحقق من الحالة. ولكن مع مرور الوقت، تطورت إلى مبادرة أوسع تهدف إلى تعزيز إمكانية التحقق من تحولات الدول وتوافق الآراء. في عالم يمكن فيه التحقق تماما من ثلاثي الدولة والتنفيذ والإجماع ، يمكن لمدققي Ethereum العمل على أي جهاز تقريبا متصل بالإنترنت يمكن تصنيفه على أنه عميل خفيف. وهذا من شأنه أن يقرب إيثريوم من تحقيق رؤيتها المتمثلة في “اللامركزية الحقيقية”.

ما هو تعريف المشكلة؟

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

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

إذا كنت ترغب في تحويل ثلاجة ذكية - نعم ، حتى الثلاجة - إلى محقق إثيريوم بمساعدة بعض البرامج المثبتة ، فإنك تواجه عقبتين رئيسيتين:

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

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

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

جذر الحالة في الكتلة السابقة = S ، جذر الحالة في الكتلة التالية = S + 1 ، تجزئة الكتلة = H

1. يجب أن يكون الكتلة نفسها صالحة، ويجب أن يتحقق بدقة دليل الحالة داخلها - سواء كان دليل فيركل أو ستاركس - من البيانات المصاحبة للكتلة.
   باختصار: تحقق من الكتلة والدليل الحالي المرافق.
2. عندما يتم تنفيذ STF باستخدام البيانات المطلوبة للتنفيذ وتضمينها في الكتلة المقابلة ل H ، يجب تحديث البيانات التي يجب أن تتغير في الحالة بشكل صحيح.
   باختصار: تحقق من انتقال الحالة.
3. عندما يتم إعادة بناء شجرة الحالة الجديدة بالبيانات المحدثة بشكل صحيح ، يجب أن يتطابق قيمة جذرها مع S + 1.
   باختصار: التحقق من عملية بناء الشجرة.

في تشبيه Prover-Verifier الذي أشرنا إليه سابقا ، من الإنصاف عموما القول إنه عادة ما يكون هناك توازن حسابي بين الفاعلين. في حين أن قدرة البراهين المطلوبة لجعل STF قابلا للتحقق من صحة أشياء متعددة في وقت واحد توفر مزايا كبيرة للمدقق ، فإنها تشير أيضا إلى أن إنشاء مثل هذه البراهين لضمان صحة التنفيذ سيكون تحديا نسبيا ل Prover. مع السرعة الحالية ل Ethereum ، يجب إثبات كتلة Ethereum في أقل من 4 ثوان. ومع ذلك ، حتى أسرع EVM Prover لدينا اليوم يمكنه فقط إثبات كتلة متوسطة في حوالي 15 ثانية. [1]

هذا قول، هناك ثلاثة مسارات مميزة يمكننا اتخاذها للتغلب على هذا التحدي الكبير:

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

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

1. استخدام أنظمة الإثبات المحسنة: تتمتع أنظمة إثبات الجيل الجديد بالقدرة على جعل العمليات الحسابية ل Ethereum أسرع وأكثر كفاءة. أنظمة متقدمة مثل ORION, Binius، وGKRيمكن أن تقلل بشكل كبير من وقت المثبت للحسابات العامة. تهدف هذه الأنظمة إلى التغلب على قيود التقنيات الحالية، وزيادة سرعة المعالجة مع استهلاك أقل للموارد. بالنسبة لشبكة تركز على التوسع والكفاءة مثل إثيريوم، توفر هذه الأمثلة ميزة كبيرة. ومع ذلك، يتطلب التنفيذ الكامل لهذه الأنظمة الجديدة جهودًا شاملة في الاختبار والتوافق داخل النظام البيئي.
2. تغييرات تكلفة الغاز: تاريخيا ، تم تحديد تكاليف الغاز للعمليات على آلة Ethereum الافتراضية (EVM) عادة بناء على تكاليفها الحسابية. ومع ذلك ، اليوم ، اكتسب مقياس آخر أهمية: تعقيد البروفر. في حين أن بعض العمليات من السهل نسبيا إثباتها ، فإن البعض الآخر له هيكل أكثر تعقيدا ويستغرق وقتا أطول للتحقق منه. يعد تعديل تكاليف الغاز ليس فقط بناء على الجهد الحسابي ولكن أيضا على صعوبة إثبات العمليات أمرا بالغ الأهمية لتعزيز أمن الشبكة وكفاءتها.

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

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

من ناحية أخرى ، فإن الدوائر المتخصصة (على سبيل المثال ، ASICs و FPGAs و GPUs) المصممة خصيصا لمهام معينة تحمل إمكانات كبيرة لتسريع عملية إنشاء الإثبات. توفر هذه الحلول كفاءة أعلى بكثير مقارنة بالأجهزة التقليدية ويمكنها تسريع عمليات التنفيذ. ومع ذلك ، فإن أهداف اللامركزية في Ethereum على مستوى الطبقة 1 تمنع وصول هذه الأجهزة إلى مجموعة مختارة فقط من الجهات الفاعلة. نتيجة لذلك ، من المتوقع أن تشهد هذه الحلول استخداما أكثر شمولا في أنظمة الطبقة 2. ومع ذلك ، يجب على المجتمع أيضا التوصل إلى توافق في الآراء بشأن متطلبات الأجهزة لتوليد الإثبات. يبرز سؤال تصميم رئيسي: هل يجب أن يعمل توليد الإثبات على أجهزة من فئة المستهلك مثل أجهزة الكمبيوتر المحمولة المتطورة ، أم يتطلب بنية تحتية صناعية؟ تشكل الإجابة بنية Ethereum بالكامل - مما يسمح بالتحسين القوي لحلول الطبقة 2 مع المطالبة بمناهج أكثر تحفظا للطبقة 1.

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

الخطوة الأخيرة لإمكانية التحقق الكاملة الحقيقية: توافق الآراء

آلية التوافق في إثيريوم تسعى لتحقيق توازن فريد يحافظ على اللامركزية والوصولية مع تحقيق أهداف التحقق. في هذا الإطار، تقدم طرق التوافق الاحتمالية والحتمية مزايا وتحديات متميزة.

الإجماع الاحتمالي مبني على نموذج اتصال النميمة. في هذا النموذج ، بدلا من الاتصال المباشر بجميع العقد التي تمثل الشبكة ، تشارك العقدة المعلومات مع مجموعة مختارة عشوائيا من 64 أو 128 عقدة. يعتمد اختيار سلسلة العقدة على هذه المعلومات المحدودة ، والتي تقدم إمكانية الخطأ. ومع ذلك ، بمرور الوقت ، مع تقدم blockchain ، من المتوقع أن تتقارب هذه التحديدات نحو السلسلة الصحيحة بمعدل خطأ 0٪.

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

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

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

بروتوكول عميل Altair: لجنة المزامنة

لجنة المزامنة هي آلية تم إدخالها مع ترقية Altair للتغلب على قيود الاتفاق الاحتمالي لـ Ethereum وتحسين قابلية التحقق من صحة السلسلة للعملاء الخفيفة. تتكون اللجنة من 512 محققًا عشوائيًا يتم اختيارهم لمدة 256 حقبة (~ 27 ساعة). يقوم هؤلاء المحققون بإنتاج توقيع يمثل رأس السلسلة، مما يتيح للعملاء الخفيفة التحقق من صحة السلسلة دون الحاجة إلى تنزيل بيانات السلسلة التاريخية. يمكن تلخيص عمل لجنة المزامنة على النحو التالي:

1. تشكيل اللجنة:
   تم اختيار 512 محقق بشكل عشوائي من جميع المحققين في الشبكة. يتم تحديث هذا الاختيار بانتظام للحفاظ على اللامركزية ومنع الاعتماد على مجموعة معينة.
2. توليد التوقيع:
   يقوم أعضاء اللجنة بإنتاج توقيع يمثل أحدث حالة للسلسلة. هذا التوقيع هو توقيع BLS جماعي يتم إنشاؤه من قبل الأعضاء ويُستخدم للتحقق من صحة السلسلة.
3. التحقق من العميل الخفيف:
   يمكن للعملاء الخفيفين التحقق من صحة السلسلة عن طريق ببساطة التحقق من التوقيع من لجنة المزامنة. يتيح لهم ذلك تتبع السلسلة بأمان دون تحميل بيانات السلسلة السابقة.

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

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

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

بسبب هذه القيود ، هناك جهود مستمرة في نظام Ethereum البيئي لإعادة تصميم آلية الإجماع وتنفيذ الحلول التي توفر نهائية حتمية في فترات أقصر. مقترحات مثل Orbit-SSFو3SF تهدف إلى إعادة تشكيل هيكل إجماع Ethereum من الألف إلى الياء ، وإنشاء نظام أكثر فعالية ليحل محل الإجماع الاحتمالي. ولا تسعى هذه النهج إلى تقصير الوقت النهائي للسلسلة فحسب، بل تسعى أيضا إلى توفير هيكل شبكي أكثر كفاءة وقابلية للتحقق. يواصل مجتمع Ethereum تطوير وإعداد هذه المقترحات بنشاط للتنفيذ في المستقبل.

التجاوز الغنوية للتوافق

يهدف The Verge إلى تعزيز آليات الإجماع الحالية والمستقبلية ل Ethereum من خلال جعلها أكثر قابلية للتحقق من خلال تقنية zk-proof ، بدلا من استبدالها بالكامل. يسعى هذا النهج إلى تحديث عمليات إجماع Ethereum مع الحفاظ على مبادئها الأساسية المتمثلة في اللامركزية والأمن. يلعب تحسين جميع عمليات الإجماع التاريخية والحالية للسلسلة باستخدام تقنيات zk دورا مهما في تحقيق أهداف Ethereum طويلة الأجل للتوسع والكفاءة. العمليات الأساسية المستخدمة في طبقة إجماع Ethereum لها أهمية كبيرة في هذا التحول التكنولوجي. دعونا نلقي نظرة فاحصة على هذه العمليات والتحديات التي تواجهها.

• ECADDs:
  • الغرض: تُستخدم هذه العملية لتجميع مفاتيح المحققين العامة وهي حيوية لضمان دقة وكفاءة السلسلة. بفضل طبيعة التجميعية لتواقيع BLS، يمكن دمج تواقيع متعددة في هيكل واحد. يقلل هذا من الزائرة في التواصل ويجعل عمليات التحقق على السلسلة أكثر كفاءة. يجعل ضمان التزامن بين مجموعات المحققين الكبيرة بشكل أكثر فعالية هذه العملية حرجة.
  • التحديات: كما ذكرنا سابقا ، يصوت مدققو Ethereum على ترتيب السلسلة خلال العصور. اليوم ، Ethereum هي شبكة تضم ما يقرب من 1.1 مليون مدقق. إذا حاول جميع المدققين نشر أصواتهم في وقت واحد ، فسيخلق ذلك ضغطا كبيرا على الشبكة. لتجنب ذلك ، تسمح Ethereum للمدققين بالتصويت على أساس الفتحة خلال حقبة ما ، حيث يصوت 1/32 فقط من جميع المدققين لكل فتحة. في حين أن هذه الآلية تقلل من حمل اتصالات الشبكة وتجعل الإجماع أكثر كفاءة ، بالنظر إلى عدد المدققين اليوم ، يصوت حوالي 34000 مدقق في كل فتحة. وهذا يترجم إلى ما يقرب من 34000 عملية ECADD لكل فتحة.
• زوجيات:
  • الغرض: تستخدم عمليات الزوج للتحقق من توقيعات BLS وضمان صحة الحقبات على السلسلة. تسمح هذه العملية بالتحقق الدفعي من التوقيعات. ومع ذلك، فهي غير صديقة لـ zk، مما يجعلها مكلفة للغاية للإثبات باستخدام تقنية zk-proof. وهذا يشكل تحديًا كبيرًا في إنشاء عملية تحقق متكاملة مع تقنيات الصفر المعرفة.
  • التحديات: يتم تحديد عمليات التزوج في إثيريوم بحد أقصى 128 مصادقة (توقيعات مجمعة) لكل فتحة، مما يؤدي إلى عدد أقل من عمليات التزوج مقارنة بالعمليات ECADDs. ومع ذلك، فإن عدم وجود الصداقة مع zk في هذه العمليات يشكل تحديًا كبيرًا. إثبات عملية التزوج بواسطة zk-proofs أكثر تكلفة بآلاف المرات من إثبات عملية ECADD [2]. وهذا يجعل تكييف عمليات التزوج لتقنيات الصفر المعرفة أحد أكبر العقبات في عمليات التحقق من التوافق في إثيريوم.
• تجزئة SHA256:
  • الغرض: تستخدم وظائف التجزئة SHA256 لقراءة حالة السلسلة وتحديثها ، مما يضمن سلامة بيانات السلسلة. ومع ذلك ، فإن افتقارهم إلى التوافق مع zk يؤدي إلى عدم الكفاءة في عمليات التحقق القائمة على zk ، مما يشكل عقبة رئيسية أمام أهداف التحقق المستقبلية ل Ethereum.
  • التحديات: تستخدم وظائف التجزئة SHA256 بشكل متكرر لقراءة وتحديث حالة السلسلة. ومع ذلك، تتعارض عدم صداقتها مع zk-proof-based verification أهداف إثيريوم. على سبيل المثال، بين حقبتين، يقوم كل محقق بتشغيل STF طبقة إجماع إثيريوم لتحديث الحالة مع المكافآت والعقوبات استنادًا إلى أداء المحقق خلال الحقبة. يعتمد هذا العملية بشدة على وظائف تجزئة SHA256، مما يزيد بشكل كبير من التكاليف في أنظمة zk-proof-based. هذا يخلق حاجزًا كبيرًا لمزامنة آلية إثيريوم للإجماع مع تقنيات zk.

تلعب عمليات ECADD و Pairing و SHA256 المستخدمة في طبقة الإجماع الحالية دورا مهما في أهداف التحقق من Ethereum. ومع ذلك ، فإن افتقارهم إلى الود ZK يشكل تحديات كبيرة على طريق تحقيق هذه الأهداف. تخلق عمليات ECADD عبئا مكلفا بسبب الحجم الكبير لأصوات المدققين ، في حين أن عمليات الاقتران ، على الرغم من كونها أقل عددا ، إلا أنها أغلى بآلاف المرات لإثباتها باستخدام أدلة zk. بالإضافة إلى ذلك, عدم ملاءمة zk-لوظائف التجزئة SHA256 يجعل إثبات انتقال حالة سلسلة المنارة أمرا صعبا للغاية. تسلط هذه القضايا الضوء على الحاجة إلى تحول شامل لمواءمة البنية التحتية الحالية ل Ethereum مع تقنيات المعرفة الصفرية.

الحل “سلسلة الشعاع”: إعادة تصور طبقة إجماع Ethereum

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

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

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

في هذا القسم ، قمنا بفحص خطوات إجماع The Verge والحالة والتنفيذ بالتفصيل ، ومن أبرز المشكلات التي تم تسليط الضوء عليها خلال هذه العملية استخدام وظيفة التجزئة SHA256 في سلسلة منارة Ethereum. بينما يلعب SHA256 دورا مركزيا في ضمان أمان الشبكة ومعالجة المعاملات ، فإن افتقارها إلى الود ZK يشكل عقبة كبيرة أمام تحقيق أهداف التحقق من Ethereum. إن تكلفتها الحسابية العالية وعدم توافقها مع تقنيات zk تجعلها قضية حرجة يجب معالجتها في التطورات المستقبلية ل Ethereum.

تتصور خارطة طريق جاستن دريك، المقدمة خلال حديثه في مؤتمر Devcon، استبدال SHA256 في سلسلة Beacon بوظائف تجزئة صديقة للـ zk مثل Poseidon. يهدف هذا الاقتراح إلى تحديث طبقة الإجماع في إثيريوم، مما يجعلها أكثر قابلية للتحقق وكفاءة ومتوافقة مع تقنيات zk-proof.

في هذا السياق ، نرى أن Ethereum لا تواجه تحديات مع وظائف التجزئة غير الودية zk فحسب ، بل تحتاج أيضا إلى إعادة تقييم التوقيعات الرقمية المستخدمة في طبقة الإجماع الخاصة بها من أجل الأمان على المدى الطويل. مع تقدم الحوسبة الكمومية ، قد تواجه خوارزميات التوقيع الرقمي مثل ECDSA المستخدمة حاليا تهديدات كبيرة. كما هو مذكور في الإرشادات التي نشرها NIST ، سيتم إهمال متغيرات ECDSA بمستوى أمان 112 بت بحلول عام 2030 وحظرها تماما بحلول عام 2035. وهذا يستلزم انتقال Ethereum والشبكات المماثلة نحو بدائل أكثر مرونة مثل التوقيعات الآمنة الكمومية في المستقبل.

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

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

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

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

أفكار واستنتاجات نهائية

مسار إثيريوم نحو التحقق يمثل تحولاً جوهريًا في تكنولوجيا سلسلة الكتل. تتناول مبادرة Verge الفجوات الأساسية من خلال أشجار Verkle للتحقق من الحالة وأدلة STARK لتحويلات مقيدة القياس.

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

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

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

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

ما يميز Ethereum ليس فقط ابتكاراتها التقنية ولكن نهجها التكراري لحل بعض أصعب المشاكل في blockchain. يعتمد المسار إلى الأمام - سواء من خلال تقنيات مثل Beam Chain أو Verkle Trees أو STARK - على جهد تعاوني من قبل المطورين والباحثين والمجتمع الأوسع. لا تتعلق هذه التطورات بتحقيق الكمال بين عشية وضحاها ، بل تتعلق بإنشاء أساس لإنترنت شفاف ولامركزي ويمكن التحقق منه.

تطور إيثيريوم يؤكد دوره كلاعب حاسم في تشكيل عصر ويب 3. من خلال مواجهة التحديات الحالية بحلول عملية، يقترب إيثيريوم من مستقبل يصبح فيه التحقق والمقاومة الكمية والتوسعة المعيار، وليس الاستثناء.

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

1. تم نشر هذه المقالة مرة أخرى من[[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[2077 بحوث](https://research.2077.xyz/)\]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [كوراي أكبينار]. إذا كانت هناك اعتراضات على هذا النشر المعاد، يرجى التواصل مع بوابة التعلمالفريق ، وسوف يتعاملون معها بسرعة.
2. تنصل المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك التي تعود إلى المؤلف ولا تشكل أي نصيحة استثمارية.
3. يتم إجراء ترجمة المقال إلى لغات أخرى من قبل فريق gate Learn. ما لم يذكر غير ذلك، يُحظر نسخ أو توزيع أو نسخ المقالات المترجمة.