مقالة جديدة لـ Vitalik: المستقبل المحتمل لبروتوكول Ethereum - The Verge

في الواقع، نحن بحاجة إلى عدة سنوات للحصول على إثبات صحة لإجماع Ethereum.

العنوان الأصلي: 《Possible futures of the Ethereum protocol, part 4: The Verge》

الكاتب: Vitalik Buterin

الترجمة: Mensh، ChainCatcher

 

شكر خاص لـ Justin Drake، Hsia-wei Wanp، Guillaume Ballet، Icinacio، Rosh Rudolf، Lev Soukhanoy Ryan Sean Adams وUma Roy على ملاحظاتهم ومراجعتهم.

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

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

خارطة طريق The Verge 2023

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

بالإضافة إلى التركيز طويل الأمد على التحقق عبر SNARK للسلسلة بأكملها، هناك مسألة جديدة تتعلق بما إذا كانت شجرة Verkle هي التقنية المثلى. شجرة Verkle عرضة لهجمات الحواسيب الكمومية، لذا إذا استبدلنا شجرة Merkle Patricia الحالية المبنية على KECCAK بشجرة Verkle، سيتعين علينا استبدال الشجرة مرة أخرى في المستقبل. الطريقة البديلة لشجرة Merkle هي تخطي استخدام فروع Merkle مباشرةً واستخدام STARK في شجرة ثنائية. تاريخيًا، كان يُعتقد أن هذه الطريقة غير عملية بسبب التكلفة والتعقيد التقني. لكن مؤخرًا، رأينا Starkware يثبت 1.7 مليون تجزئة Poseidon في الثانية على كمبيوتر محمول، ومع ظهور تقنيات مثل GKB، أصبح وقت إثبات التجزئات "التقليدية" أقصر بسرعة. لذلك، خلال العام الماضي، أصبح "Verge" أكثر انفتاحًا، مع عدة احتمالات.

The Verge: الأهداف الرئيسية

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

في هذا الفصل

• عميل عديم الحالة: Verkle أم STARKs
• إثبات صحة تنفيذ EVM
• إثبات صحة الإجماع

التحقق عديم الحالة: Verkle أم STARKs

ما المشكلة التي نريد حلها؟

اليوم، يحتاج عميل Ethereum إلى تخزين مئات الجيجابايت من بيانات الحالة للتحقق من الكتل، وهذا الرقم يزداد كل عام. تزداد بيانات الحالة الخام بحوالي 30GB سنويًا، ويجب على كل عميل تخزين بعض البيانات الإضافية فوق ذلك لتحديث الثلاثيات بكفاءة.

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

كيف تعمل؟

التحقق عديم الحالة هو تقنية تسمح للعقد بالتحقق من الكتل دون امتلاك الحالة الكاملة. بدلاً من ذلك، تأتي كل كتلة مع شاهد يتضمن: (i) القيم، الكود، الأرصدة، والتخزين في مواقع محددة من الحالة التي ستصل إليها الكتلة؛ (ii) إثباتات تشفيرية لصحة هذه القيم.

في الواقع، يتطلب تنفيذ التحقق عديم الحالة تغيير بنية شجرة حالة Ethereum. ذلك لأن شجرة Merkle Patricia الحالية غير مناسبة للغاية لأي مخطط إثبات تشفير، خاصة في أسوأ الحالات. سواء كانت فروع Merkle "الأصلية" أو إمكانية تغليفها بـ STARK، كلها تعاني من نفس الصعوبة. الصعوبة الرئيسية تأتي من بعض نقاط الضعف في MPT:

1. إنها شجرة سداسية عشرية (أي أن كل عقدة لها 16 ابنًا). هذا يعني أنه في شجرة بحجم N، يحتاج الإثبات في المتوسط إلى 32*(16-1)*log16(N) = 120*log2(N) بايت، أو حوالي 3840 بايت في شجرة بها 2^32 عنصرًا. في الشجرة الثنائية، نحتاج فقط إلى 32*(2-1)*log2(N) = 32*log2(N) بايت، أو حوالي 1024 بايت.

2. الكود غير مدمج في Merkle. هذا يعني أنه لإثبات أي وصول إلى كود الحساب، يجب توفير الكود بالكامل، حتى 24000 بايت.

 

يمكننا حساب أسوأ الحالات كما يلي:

30000000 gas / 2400 (تكلفة قراءة الحساب البارد) * (5 * 488 + 24000) = 330000000 بايت

تكلفة الفروع أقل قليلاً (باستخدام 5*480 بدلاً من 8*480)، لأنه عندما يكون هناك العديد من الفروع، تتكرر الأجزاء العليا. لكن حتى مع ذلك، فإن كمية البيانات التي يجب تنزيلها في فترة زمنية واحدة غير واقعية تمامًا. إذا حاولنا تغليفها بـ STARK، سنواجه مشكلتين: (i) KECCAK غير مناسب لـ STARK؛ (ii) 330MB من البيانات تعني أنه يجب إثبات 5 ملايين استدعاء لدالة KECCAK round، وهو أمر قد لا يكون ممكنًا على أي جهاز باستثناء أقوى الأجهزة الاستهلاكية، حتى لو تمكنا من جعل إثبات STARK لـ KECCAK أكثر كفاءة.

إذا استبدلنا الشجرة السداسية عشرية مباشرة بشجرة ثنائية وقمنا بدمج الكود في Merkle، فإن أسوأ الحالات ستصبح تقريبًا 30000000/2400*32*(32-14+8) = 10400000 بايت (14 هو طرح للبتات الزائدة لفروع 2^14، و8 هو طول إثبات الدخول إلى ورقة الكود). يجب ملاحظة أن هذا يتطلب تغيير تكلفة gas، وفرض رسوم على كل كتلة كود منفصلة؛ هذا ما يفعله EIP-4762. سعة 10.4MB أفضل بكثير، لكن بالنسبة للعديد من العقد، لا تزال كمية البيانات التي يجب تنزيلها في فترة زمنية واحدة كبيرة جدًا. لذلك، نحتاج إلى تقنيات أقوى. في هذا الصدد، هناك حلان رائدان: شجرة Verkle وشجرة تجزئة ثنائية مدعومة بـ STARK.

شجرة Verkle

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

لذلك، يصبح حجم فرع واحد في الإثبات 32 - log256(N) = 4*log2(N) بايت. وبالتالي، فإن الحد الأقصى النظري لحجم الإثبات هو تقريبًا 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 بايت (بسبب التوزيع غير المتساوي للكتل، قد يختلف الحساب الفعلي قليلاً، لكن هذا تقريبي جيد).

يجب أيضًا ملاحظة أنه في جميع الأمثلة أعلاه، هذه "أسوأ حالة" ليست الأسوأ: الحالة الأسوأ هي أن يقوم مهاجم "بتعدين" عنوانين بحيث يكون لهما بادئة مشتركة طويلة في الشجرة، ويقرأ البيانات من أحد العناوين، مما قد يضاعف طول الفرع في أسوأ الحالات. لكن حتى مع ذلك، فإن طول إثبات شجرة Verkle في أسوأ الحالات هو 2.6MB، وهو ما يتوافق تقريبًا مع بيانات التحقق في أسوأ الحالات حاليًا.

كما نستفيد من هذه الملاحظة في أمر آخر: نجعل تكلفة الوصول إلى مساحات التخزين "المجاورة" منخفضة جدًا: سواء كانت عدة كتل كود لنفس العقد أو فتحات تخزين متجاورة. يوفر EIP-4762 تعريفًا للجوار، ويحتسب فقط 200 gas للوصول المجاور. في حالة الوصول المجاور، يصبح حجم الإثبات في أسوأ الحالات 30000000 / 200*32 - 4800800 بايت، وهذا لا يزال ضمن النطاق المقبول تقريبًا. إذا أردنا تقليل هذه القيمة لمزيد من الأمان، يمكننا زيادة تكلفة الوصول المجاور قليلاً.

شجرة تجزئة ثنائية مدعومة بـ STARK

مبدأ هذه التقنية واضح: فقط أنشئ شجرة ثنائية، واحصل على إثبات بحد أقصى 10.4MB، وأثبت القيم في الكتلة، ثم استبدل الإثبات بإثبات STARK. بذلك، يحتوي الإثبات نفسه فقط على البيانات المثبتة، بالإضافة إلى تكلفة ثابتة من STARK الفعلي تتراوح بين 100-300kB.

التحدي الرئيسي هنا هو وقت التحقق. يمكننا إجراء نفس الحسابات الأساسية أعلاه، لكننا نحسب عدد التجزئات بدلاً من عدد البايتات. كتلة بحجم 10.4MB تعني 330000 تجزئة. إذا أضفنا احتمال أن يقوم مهاجم "بتعدين" عناوين في الشجرة لها بادئة مشتركة طويلة، فإن عدد التجزئات في أسوأ الحالات سيصل إلى حوالي 660000 تجزئة. لذلك، إذا استطعنا إثبات 200,000 تجزئة في الثانية، فلا توجد مشكلة.

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

1. إجراء تحليل أمني مكثف وسريع لـ Poseidon، والتعرف عليها بما يكفي لنشرها على L1
2. استخدام دوال تجزئة أكثر "تحفظًا" مثل SHA256 أو BLAKE

إذا أردنا إثبات دوال التجزئة التحفظية، فإن دائرة STARK من Starkware في وقت كتابة هذه السطور يمكنها إثبات 10-30k تجزئة في الثانية فقط على كمبيوتر محمول استهلاكي. ومع ذلك، تتطور تقنية STARK بسرعة. حتى اليوم، أظهرت تقنيات قائمة على GKR إمكانية رفع هذه السرعة إلى نطاق 100-200k.

حالات استخدام الشاهد خارج التحقق من الكتل

بالإضافة إلى التحقق من الكتل، هناك ثلاث حالات استخدام رئيسية أخرى تتطلب تحقق عديم الحالة أكثر كفاءة:

• ذاكرة المعاملات (mempool): عند بث المعاملة، تحتاج العقد في شبكة P2P إلى التحقق من صحة المعاملة قبل إعادة بثها. اليوم، يشمل التحقق التحقق من التوقيع، بالإضافة إلى التحقق من كفاية الرصيد وصحة البادئة. في المستقبل (على سبيل المثال، مع استخدام تجريد الحساب الأصلي مثل EIP-7701)، قد يتطلب ذلك تشغيل بعض كود EVM الذي يصل إلى بعض الحالة. إذا كانت العقدة عديمة الحالة، يجب أن تأتي المعاملة مع إثبات للحالة.
• قوائم الإدراج: هذه ميزة مقترحة تسمح (لمصادقين إثبات الحصة الصغار وغير المعقدين) بفرض إدراج معاملة في الكتلة التالية، بغض النظر عن رغبة صانعي الكتل (الكبار والمعقدين). هذا يضعف قدرة الأقوياء على التلاعب بالسلسلة من خلال تأخير المعاملات. ومع ذلك، يتطلب ذلك أن يكون لدى المصادقين وسيلة للتحقق من صحة المعاملات في قائمة الإدراج.
• العملاء الخفيفون: إذا أردنا أن يصل المستخدمون إلى السلسلة عبر المحافظ (مثل Metamask، Rainbow، Rabby، إلخ)، يجب عليهم تشغيل عميل خفيف (مثل Helios). يوفر Helios للمستخدم جذر حالة تم التحقق منه. وللحصول على تجربة عديمة الثقة بالكامل، يجب على المستخدمين تقديم إثبات لكل استدعاء RPC يقومون به (على سبيل المثال، لاستدعاء eth_call، يجب إثبات جميع الحالات التي تم الوصول إليها أثناء الاستدعاء).

تشترك جميع هذه الحالات في نقطة واحدة: أنها تتطلب عددًا كبيرًا من الإثباتات، لكن كل إثبات صغير جدًا. لذلك، لا معنى عمليًا لاستخدام إثبات STARK لها؛ بل من الواقعي استخدام فروع Merkle مباشرة. ميزة أخرى لفروع Merkle هي أنها قابلة للتحديث: إذا كان لديك إثبات لجسم حالة X متجذر في الكتلة B، وعند استلام كتلة فرعية B2 وشاهدها، يمكنك تحديث الإثبات ليكون متجذرًا في B2. إثباتات Verkle أيضًا قابلة للتحديث أصلاً.

ما هي الروابط مع الأبحاث الحالية:

• Verkle trees
• ورقة John Kuszmaul الأصلية حول شجرة Verkle
• Starkware
• ورقة Poseidon2
• Ajtai (دالة تجزئة سريعة بديلة قائمة على صعوبة الشبكات)
• Verkle.info

ما الذي يمكن فعله أيضًا؟

العمل الرئيسي المتبقي هو

1. المزيد من التحليل لعواقب EIP-4762 (تغييرات تكلفة gas عديمة الحالة)

2. المزيد من العمل على إكمال واختبار برنامج الانتقال، وهو الجزء الرئيسي من تعقيد أي تنفيذ بيئة عديمة الجنسية

3. المزيد من التحليل الأمني لـ Poseidon، Ajtai ودوال التجزئة الأخرى "المناسبة لـ STARK"

4. تطوير ميزات بروتوكول STARK عالية الكفاءة بشكل أكبر لـ "التجزئة التحفظية" (أو "التقليدية")، مثل وجهات النظر القائمة على Binius أو GKR.

بالإضافة إلى ذلك، سنقرر قريبًا اختيار أحد الخيارات الثلاثة التالية: (i) شجرة Verkle، (ii) دالة تجزئة مناسبة لـ STARK، و(iii) دالة تجزئة تحفظية. يمكن تلخيص خصائصها في الجدول التالي:

بالإضافة إلى هذه "الأرقام الرئيسية"، هناك بعض الاعتبارات المهمة الأخرى:

• اليوم، كود شجرة Verkle ناضج إلى حد ما. استخدام أي كود آخر غير Verkle سيؤخر النشر، وربما يؤخر الهارد فورك. هذا ليس مشكلة، خاصة إذا كنا بحاجة إلى وقت إضافي لتحليل دالة التجزئة أو تنفيذ المصادق، أو إذا كان لدينا ميزات مهمة أخرى نريد دمجها في Ethereum في وقت أبكر.
• تحديث جذر الحالة باستخدام التجزئة أسرع من استخدام شجرة Verkle. هذا يعني أن الطرق القائمة على التجزئة يمكن أن تقلل من وقت مزامنة العقدة الكاملة.
• شجرة Verkle لها خصائص تحديث شاهد مثيرة للاهتمام — إثباتات Verkle قابلة للتحديث. هذه الخاصية مفيدة لـ mempool، قوائم الإدراج، وحالات الاستخدام الأخرى، وقد تساعد أيضًا في تحسين كفاءة التنفيذ: إذا تم تحديث جسم الحالة، يمكن تحديث شاهد الطبقة قبل الأخيرة دون الحاجة إلى قراءة محتوى الطبقة الأخيرة.
• شجرة Verkle أصعب في إثبات SNARK. إذا أردنا تقليل حجم الإثبات إلى بضعة آلاف من البايتات، ستواجه إثباتات Verkle بعض الصعوبات. ذلك لأن تحقق إثبات Verkle يتطلب الكثير من العمليات 256-بت، مما يتطلب من نظام الإثبات إما تكلفة عالية أو بنية داخلية مخصصة تحتوي على جزء إثبات Verkle 256-بت. هذا ليس مشكلة للتحقق عديم الحالة نفسه، لكنه يضيف صعوبات إضافية.

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

إذا لم يكن نظام الإثبات فعالًا بما فيه الكفاية في أسوأ الحالات، يمكننا أيضًا استخدام أداة غير متوقعة هي gas متعدد الأبعاد لتعويض هذا النقص: وضع حدود gas منفصلة لـ (i) calldata؛ (ii) الحساب؛ (iii) الوصول إلى الحالة، وربما موارد أخرى. يزيد gas متعدد الأبعاد من التعقيد، لكنه يحد بشكل أكثر صرامة من النسبة بين الحالة المتوسطة وأسوأ الحالات. مع gas متعدد الأبعاد، يمكن أن ينخفض الحد الأقصى النظري لعدد الفروع التي يجب إثباتها من 12500 إلى مثلًا 3000. هذا يجعل BLAKE3 بالكاد كافيًا حتى اليوم.

gas متعدد الأبعاد يسمح بقيود موارد الكتلة أن تقترب أكثر من قيود موارد العتاد الأساسي

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

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

كيف يتفاعل هذا مع أجزاء أخرى من خارطة الطريق؟

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

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

هناك أيضًا تآزر مهم بين التحقق عديم الحالة وانتهاء صلاحية التاريخ. اليوم، يجب على العميل تخزين ما يقرب من 1TB من البيانات التاريخية؛ هذه البيانات أكبر بعدة مرات من بيانات الحالة. حتى إذا كان العميل عديم الحالة، ما لم نتمكن من رفع مسؤولية تخزين البيانات التاريخية عن العميل، فإن حلم العميل عديم التخزين بالكامل لن يتحقق تقريبًا. الخطوة الأولى في هذا الاتجاه هي EIP-4444، والتي تعني أيضًا تخزين البيانات التاريخية في torrents أو Portal Network.

إثبات صحة تنفيذ EVM

ما المشكلة التي نريد حلها؟

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

لتحقيق ذلك، نحتاج إلى إثبات SNARK أو STARK لكل من (i) طبقة الإجماع (أي إثبات الحصة) و(ii) طبقة التنفيذ (أي EVM). الأول تحدٍ بحد ذاته، ويجب معالجته مع التحسين المستمر لطبقة الإجماع (مثلًا، من أجل إنهاء الفتحة الواحدة). الثاني يتطلب إثبات تنفيذ EVM.

ما هو، وكيف يعمل؟

من الناحية الشكلية، يتم تعريف EVM في مواصفات Ethereum كدالة تحويل حالة: لديك حالة سابقة S، وكتلة B، وأنت تحسب حالة لاحقة S' = STF(S، B). إذا كان المستخدم يستخدم عميلًا خفيفًا، فهو لا يمتلك S وS' بالكامل، أو حتى E؛ بل لديه جذر الحالة السابقة R، وجذر الحالة اللاحقة R'، وهاش الكتلة H.

• المدخلات العامة: جذر الحالة السابقة R، جذر الحالة اللاحقة R'، هاش الكتلة H
• المدخلات الخاصة: جسم الكتلة B، الكائنات في الحالة التي يصل إليها البرنامج Q، نفس الكائنات بعد تنفيذ البرنامج Q'، إثباتات الحالة (مثل فروع Merkle) P
• الادعاء 1: P هو إثبات صالح يثبت أن Q يحتوي على أجزاء من الحالة التي يمثلها R
• الادعاء 2: إذا تم تشغيل STF على Q، (i) تصل عملية التنفيذ فقط إلى الكائنات داخل Q، (ii) الكتلة صالحة، (iii) النتيجة هي Q'
• الادعاء 3: إذا أعدنا حساب جذر الحالة الجديد باستخدام معلومات Q' وP، سنحصل على R'

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

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

ما هي الروابط مع الأبحاث الحالية؟

• EFPSE ZK-EVM (تم إيقافه بسبب وجود خيارات أفضل)
• Zeth، الذي يعمل عن طريق تجميع EVM إلى RISC-0 ZK-VM
• مشروع التحقق الشكلي من ZK-EVM

ما الذي يمكن فعله أيضًا؟

اليوم، تعاني إثباتات صحة أنظمة المحاسبة الإلكترونية من جانبين: الأمان ووقت التحقق.

يتطلب إثبات صحة آمن ضمان أن SNARK يتحقق فعليًا من حسابات EVM، ولا توجد ثغرات. هناك تقنيتان رئيسيتان لتحسين الأمان: المصادقون المتعددون والتحقق الشكلي. المصادقون المتعددون تعني وجود عدة تطبيقات مستقلة لإثبات الصحة، كما هو الحال مع عدة عملاء، وإذا أثبتت مجموعة فرعية كبيرة بما فيه الكفاية من هذه التطبيقات صحة كتلة، سيقبلها العميل. التحقق الشكلي يتضمن استخدام أدوات تُستخدم عادةً لإثبات النظريات الرياضية، مثل Lean4، لإثبات أن إثبات الصحة يقبل فقط التنفيذ الصحيح لمواصفات EVM الأساسية (مثل دلالات EVM K أو مواصفات تنفيذ Ethereum المكتوبة بـ python (EELS)).

وقت تحقق سريع بما فيه الكفاية يعني أن أي كتلة Ethereum يمكن التحقق منها في أقل من 4 ثوانٍ. اليوم، نحن بعيدون عن هذا الهدف، رغم أننا أقرب مما كنا نتخيله قبل عامين. لتحقيق هذا الهدف، نحتاج إلى تقدم في ثلاثة اتجاهات:

• التوازي — أسرع مصادق EVM حاليًا يمكنه إثبات كتلة Ethereum في المتوسط خلال 15 ثانية. يتم ذلك عن طريق التوازي بين مئات وحدات GPU، ثم تجميع عملهم في النهاية. من الناحية النظرية، نعرف تمامًا كيف نصنع مصادق EVM يمكنه إثبات الحساب في وقت O(log(N)): اجعل وحدة GPU تقوم بكل خطوة، ثم أنشئ "شجرة تجميع":

هناك تحديات في التنفيذ. حتى في أسوأ الحالات، أي معاملة كبيرة جدًا تستهلك الكتلة بالكامل، لا يمكن تقسيم الحساب حسب المعاملات، بل يجب تقسيمه حسب التعليمات البرمجية (opcode) للآلة الافتراضية (EVM أو RISC-V). ضمان بقاء "ذاكرة" الآلة الافتراضية متسقة بين أجزاء الإثبات المختلفة هو تحدٍ رئيسي في التنفيذ. لكن إذا استطعنا تحقيق هذا الإثبات التكراري، نعلم أنه حتى بدون تحسينات أخرى، تم حل مشكلة تأخير المصادق.

• تحسين نظام الإثبات — أنظمة إثبات جديدة مثل Orion، Binius، GRK وغيرها من المعلومات من المرجح أن تؤدي إلى تقليل وقت التحقق للحساب العام مرة أخرى.
• تغييرات أخرى في تكلفة gas لـ EVM — يمكن تحسين العديد من الأشياء في EVM لجعلها أكثر ملاءمة للمصادقين، خاصة في أسوأ الحالات. إذا كان بإمكان مهاجم بناء كتلة تعيق المصادق لمدة عشر دقائق، فإن القدرة على إثبات كتلة Ethereum عادية في 4 ثوانٍ ليست كافية. يمكن تقسيم التغييرات المطلوبة في EVM إلى الفئات التالية:
• تغييرات تكلفة gas — إذا كانت العملية تستغرق وقتًا طويلاً لإثباتها، حتى لو كانت سريعة نسبيًا في الحساب، يجب أن يكون لها تكلفة gas عالية. تم اقتراح EIP-7667 لمعالجة أخطر هذه المشكلات: فهو يزيد بشكل كبير من تكلفة gas لدوال التجزئة "التقليدية"، لأن opcode ووظائفها المسبقة رخيصة نسبيًا. لتعويض هذه الزيادة، يمكننا تقليل تكلفة gas لـ opcode EVM التي تكون تكلفة إثباتها منخفضة، مما يحافظ على نفس متوسط الإنتاجية.
• استبدال الهياكل البيانية — بالإضافة إلى استبدال شجرة الحالة بطريقة أكثر ملاءمة لـ STARK، نحتاج أيضًا إلى استبدال قائمة المعاملات، شجرة الإيصالات، والهياكل الأخرى ذات تكلفة الإثبات العالية. نقل Etan Kissling لهياكل المعاملات والإيصالات إلى SSZ في EIP هو خطوة في هذا الاتجاه.

بالإضافة إلى ذلك، يمكن للأداتين المذكورتين في القسم السابق (gas متعدد الأبعاد وجذر الحالة المؤجل) أن تساعدا في هذا المجال أيضًا. ومع ذلك، من الجدير بالذكر أنه على عكس التحقق عديم الحالة، فإن استخدام هاتين الأداتين يعني أن لدينا بالفعل التقنية الكافية لإنجاز ما نحتاجه حاليًا، وحتى مع استخدام هذه التقنيات، لا يزال التحقق الكامل من ZK-EVM يتطلب المزيد من العمل — فقط العمل المطلوب أقل.

هناك نقطة لم يتم ذكرها أعلاه وهي عتاد المصادق: استخدام GPU، FPGA وASIC لتوليد الإثباتات بشكل أسرع. Fabric Cryptography، Cysic وAccseal هي ثلاث شركات أحرزت تقدمًا في هذا المجال. هذا ذو قيمة كبيرة لـ L2، لكنه من غير المرجح أن يكون عاملًا حاسمًا لـ L1، لأن هناك رغبة قوية في أن يبقى L1 لامركزيًا للغاية، مما يعني أن توليد الإثبات يجب أن يكون في متناول مستخدمي Ethereum، ولا يجب أن يعتمد على عتاد شركة واحدة. يمكن لـ L2 اتخاذ قرارات أكثر جرأة.

هناك المزيد من العمل الذي يجب القيام به في هذه المجالات:

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

التكاليف المحتملة:

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

كيف يتفاعل هذا مع أجزاء أخرى من خارطة الطريق؟

التقنية الأساسية المطلوبة لإثبات صحة EVM على L1 تتشارك إلى حد كبير مع مجالين آخرين:

• إثبات صحة L2 (أي "ZK rollup")
• طريقة "إثبات تجزئة ثنائية STARK" عديمة الحالة

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

بالإضافة إلى ذلك، يمكن أن يؤدي إثبات صحة EVM على L1 إلى زيادة حد gas على L1 بشكل كبير.

إثبات صحة الإجماع

ما المشكلة التي نريد حلها؟

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

الإجماع أبسط بكثير من EVM، لكنه يواجه تحديًا هو أنه ليس لدينا L2 EVM convolution، لذا على أي حال، يجب إنجاز معظم العمل من البداية. لذلك، يتطلب أي تنفيذ لإثبات إجماع Ethereum "البدء من الصفر"، رغم أن نظام الإثبات نفسه يمكن أن يبنى عليه عمل مشترك.

ما هو، وكيف يعمل؟

يتم تعريف سلسلة beacon كسلسلة تحويل حالة، تمامًا مثل EVM. تتكون دالة تحويل الحالة أساسًا من ثلاثة أجزاء:

• ECADD (للتحقق من توقيعات BLS)
• الاقتران (للتحقق من توقيعات BLS)
• تجزئة SHA256 (لقراءة وتحديث الحالة)

في كل كتلة، نحتاج لإثبات 1-16 ECADD لـ BLS12-381 لكل مصادق (ربما أكثر من واحد، لأن التوقيعات قد تكون في مجموعات متعددة). يمكن تعويض ذلك بتقنيات التحضير الجزئي، لذا يمكننا القول إن كل مصادق يحتاج فقط لإثبات ECADD واحد لـ BLS12-381. حاليًا، هناك 30000 توقيع مصادق لكل فترة زمنية. في المستقبل، مع تحقيق إنهاء الفتحة الواحدة، قد يتغير هذا الرقم في اتجاهين: إذا اتبعنا نهج "القوة الغاشمة"، قد يرتفع عدد المصادقين لكل فترة إلى مليون. في الوقت نفسه، إذا استخدمنا Orbit SSF، سيبقى عدد المصادقين عند 32768 أو حتى ينخفض إلى 8192.

كيف تعمل تجميعات BLS: التحقق من التوقيع الإجمالي يتطلب ECADD واحد لكل مشارك، وليس ECMUL واحد. لكن 30000 ECADD لا تزال كمية إثبات كبيرة.

بالنسبة للاقتران، هناك حاليًا ما يصل إلى 128 إثباتًا لكل فترة، مما يعني الحاجة للتحقق من 128 اقترانًا. من خلال ElP-7549 وتعديلات أخرى، يمكن تقليل ذلك إلى 16 لكل فترة. عدد الاقترانات قليل، لكن تكلفتها عالية جدًا: كل اقتران يستغرق وقتًا أطول بعدة آلاف من المرات من ECADD.

أحد التحديات الرئيسية في إثبات عمليات BLS12-381 هو عدم وجود منحنى مناسب يساوي ترتيب منحنى BLS12-381 حجم الحقل، مما يزيد من تكلفة أي نظام إثبات. من ناحية أخرى، تم بناء شجرة Verkle المقترحة لـ Ethereum على منحنى Bandersnatch، مما يجعل BLS12-381 نفسه منحنى ذاتي في نظام SNARK المستخدم لإثبات فروع Verkle. يمكن لتطبيق بسيط إثبات 100 جمع G1 في الثانية؛ لجعل سرعة الإثبات كافية، سنحتاج بالتأكيد إلى تقنيات ذكية مثل GKR.

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

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

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

• تغيير دالة التجزئة: الآن نستخدم دالة SHA256 "الكاملة"، لذا بسبب الحشو، كل استدعاء يتطلب استدعاءين لدالة الضغط الأساسية. إذا استخدمنا دالة ضغط SHA256 فقط، سنحصل على ضعف الأداء على الأقل. إذا استخدمنا Poseidon، قد نحصل على زيادة بمقدار 100 مرة، مما يحل جميع مشاكلنا (على الأقل في جانب التجزئة): عند 1.7 مليون تجزئة في الثانية (54MB)، حتى مليون سجل مصادق يمكن "قراءته" في الإثبات خلال ثوانٍ.
• إذا استخدمنا Orbit، نخزن سجلات المصادقين بعد التبديل مباشرة: إذا اخترنا عددًا معينًا من المصادقين (مثل 8192 أو 32768) كلجنة لفترة معينة، نضعهم مباشرة بجانب بعضهم البعض في الحالة، بحيث يمكن قراءة جميع المفاتيح العامة للمصادقين في الإثبات بأقل قدر من التجزئة. هذا يسمح أيضًا بتحديث جميع الأرصدة بكفاءة.
• تجميع التوقيعات: أي مخطط تجميع توقيعات عالي الأداء سيتضمن نوعًا من الإثبات التكراري، حيث تقوم العقد المختلفة في الشبكة بإثبات مجموعات فرعية من التوقيعات. هذا يوزع عبء الإثبات بشكل طبيعي على عدة عقد في الشبكة، مما يقلل بشكل كبير من عبء "المصادق النهائي".
• مخططات توقيع أخرى: بالنسبة لتوقيعات Lamport+ Merkle، نحتاج إلى 256 + 32 تجزئة للتحقق من التوقيع؛ مضروبًا في 32768 مصادق، نحصل على 9437184 تجزئة. بعد تحسين مخطط التوقيع، يمكن تحسين هذه النتيجة بعامل ثابت صغير. إذا استخدمنا Poseidon، يمكن إثبات ذلك في فترة واحدة. لكن في الواقع، سيكون استخدام مخطط تجميع تكراري أسرع.

ما هي الروابط مع الأبحاث الحالية؟

• إثبات إجماع Ethereum المختصر (لجنة المزامنة فقط)
• Helios داخل SP1 المختصر
• تجميع BLS12-381 المختصر مسبقًا
• التحقق من توقيع BLS المجمع القائم على Halo2

ما العمل المتبقي، وكيفية الموازنة:

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

من المرجح أن يكون التوازن الرئيسي في ترتيب العمليات، بين نهج تدريجي لإصلاح طبقة إجماع Ethereum ونهج أكثر جرأة "يغير الكثير دفعة واحدة". بالنسبة لـ EVM، النهج التدريجي معقول لأنه يقلل من تعطيل التوافقية العكسية. بالنسبة لطبقة الإجماع، التأثير على التوافقية العكسية أقل، وهناك فائدة في إعادة التفكير "الشاملة" في تفاصيل بناء سلسلة beacon لتحسين ملاءمة SNARK بأفضل طريقة.

كيف يتفاعل هذا مع أجزاء أخرى من خارطة الطريق؟

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