فيتاليك: الأهداف الرئيسية لمرحلة The Verge الخاصة بـ Ethereum

المؤلف: فيتاليك، مؤسس إيثريوم؛ المترجم: دينج تونج، جولدن فاينانس

ملاحظة: هذه المقالة هي الرابعة في سلسلة من المقالات حول "التطور المستقبلي لبروتوكول إيثريوم" التي نشرتها مؤخرًا فيتاليك، مؤسس إيثريوم الجزء "العقود المستقبلية المحتملة لبروتوكول الإيثريوم، الجزء 4: الحافة". بالنسبة للجزء الثالث، راجع "فيتاليك: الأهداف الرئيسية لمرحلة البلاء في إيثريوم"، ثانيًا راجع الجزء "فيتاليك: كيف يجب تطوير بروتوكول إيثريوم أثناء مرحلة الاندفاع"، وراجع الجزء الأول "< a href= "https://www.jinse.cn/blockchain/3699549.html">ما الأشياء الأخرى التي يمكن تحسينها في Ethereum PoS". فيما يلي النص الكامل للجزء الرابع:

---

شكر خاص لجوستين دريك، وهسياو-وي وانغ، وغيوم باليه، وإجناسيو، وجوش رودولف، وليف سوخانوف، وريان شون آدامز، وأوما روي على ملاحظاتهم ومراجعتهم.

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

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

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

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

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

ونتيجة لذلك، أصبحت الحافة أكثر انفتاحًا خلال العام الماضي وهناك العديد من الاحتمالات.

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

• عميل عديم الحالة: لا يتطلب التحقق الكامل من العملاء وعقد التخزين أكثر من بضع غيغابايت من مساحة التخزين.

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

نركز في هذه المقالة على ما يلي:

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

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

< li>

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

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

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

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

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

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

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

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

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

• هذا الرمز ليس Merkelized. وهذا يعني أن توفير أي وصول إلى رمز الحساب يتطلب توفير الرمز الكامل، بحد أقصى يبلغ 24000 بايت.

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

30,000,000 غاز / 2,400 تكلفة قراءة الحساب ("البارد") * (5 * 480 + 24,000) = 330,000,000 بايت

< p >تم تخفيض تكلفة الفرع قليلاً (5*480 بدلاً من 8*480) لأنه عندما يكون عدد الفروع كبيراً، يتم تكرار الجزء العلوي من الفرع. ولكن حتى في هذه الحالة، فإن كمية البيانات التي يتم تنزيلها في فتحة واحدة غير عملية على الإطلاق. إذا حاولنا تغليفها بـ STARK، فسنواجه مشكلتين: (1) KECCAK ليس صديقًا جدًا لـ STARK، (2) 330 ميجابايت من البيانات تعني أنه يتعين علينا تبرير 5 ملايين مكالمة لوظيفة KECCAK الدائرية، والتي على الرغم من أننا يمكن أن يجعل دليل STARK KECCAK أكثر كفاءة، هناك الكثير مما لا يمكن إثباته على جميع الأجهزة باستثناء أقوى الأجهزة الاستهلاكية.

إذا استبدلنا الشجرة السداسية بشجرة ثنائية وأضفنا رمز Merkelize، فستصبح الحالة الأسوأ تقريبًا 30,000,000 / 2,400 * 32 * (32 - 14 + 8) = 10,400,000 بايت ~ 214 فرعًا ، 8 منها دليل على طول دخول الورقة). لاحظ أن هذا يتطلب تغيير تكلفة الغاز مقابل الوصول إلى كل كتلة فردية من التعليمات البرمجية؛ ويقوم EIP-4762 بذلك. تعد مساحة 10.4 ميغابايت أفضل بكثير، ولكنها لا تزال تحتوي على قدر كبير جدًا من البيانات التي لا يمكن تنزيلها في فتحة واحدة للعديد من العقد. لذلك نحن بحاجة إلى تقديم بعض التقنيات الأكثر قوة. هناك حلان رئيسيان لهذا: أشجار Verkle وأشجار التجزئة الثنائية Starked.

أشجار Verkle

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

وبالتالي الدليل قيد التقدم يصبح حجم الفرع الواحد 32*log256(N) = 4*log2(N) بايت. يصبح الحد الأقصى لحجم الدليل النظري حوالي 30,000,000/2,400*32*(32-14+8)/8 = 1,300,000 بايت (تختلف الرياضيات قليلاً في الممارسة العملية بسبب التوزيع غير المتساوي لكتل ​​الحالة، ولكن هذا بمثابة أول جيد جدًا) ).

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

نستخدم هذا التحذير أيضًا لفعل شيء آخر: نجعل الوصول إلى التخزين "المجاور" رخيصًا جدًا: العديد من كتل التعليمات البرمجية لنفس العقد، أو فتحات التخزين المتجاورة. يوفر EIP-4762 تعريفًا للمجاورة، ولا يتقاضى الوصول المجاور سوى 200 غاز. بالنسبة لعمليات الوصول المتجاورة، يصبح حجم إثبات الحالة الأسوأ 30,000,000/200*32 = 4,800,800 بايت، والذي لا يزال ضمن التسامح تقريبًا. إذا أردنا خفض هذه القيمة لأسباب أمنية، فيمكننا زيادة تكلفة الوصول المجاورة قليلاً.

شجرة التجزئة الثنائية المميزة بنجمة

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

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

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

• الأمن الجماعي على بوسيدون قم بتحليله سريعًا ، وتعرف عليها لنشرها في L1

• استخدم دالة تجزئة "أكثر تحفظًا" مثل SHA256 أو BLAKE

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

حالات استخدام الشهود تتجاوز التحقق من صحة الكتل

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

• مجمع الذاكرة: عند بث معاملة ما، تحتاج العقد إلى التحقق من صحة المعاملة قبل إعادة بثه. اليوم، لا يشمل التحقق التحقق من التوقيع فحسب، بل يشمل أيضًا التحقق من أن الرصيد كافٍ وأن الرقم صحيح. في المستقبل (على سبيل المثال، استخدام تجريدات الحساب الأصلي مثل EIP-7701) قد يتضمن ذلك تشغيل بعض أكواد EVM التي يمكنها الوصول إلى بعض الحالة. إذا كانت العقدة عديمة الحالة، فيجب أن تكون المعاملات مصحوبة بإثباتات تثبت كائن الحالة.

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

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

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

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

شجرة Verkle: https://vitalik.eth.limo/general/2021/06/18/verkle.html

جون ورقة شجرة فيركل الأصلية لكوزماول: https://math.mit /research/highschool/primes/materials/2018/Kuszmaul.pdf

بيانات شهادة Starkware: https://x.com/StarkWareLtd/status/1807776563188162562

ورقة بوسيدون2 : https://eprint.iacr.org/2023/323

Ajtai (وظيفة التجزئة السريعة البديلة القائمة على صلابة الشبكة): https://www.wisdom.weizmann.ac.il/~oded/COL/cfh pdf< /a>

Verkle.info: https:// verkle. info/

ما الذي يجب القيام به أيضًا، وما هي المقايضات التي يجب القيام بها؟

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

• المزيد تحليل عواقب EIP-4762 (تغيرات تكلفة الغاز عديمي الجنسية)

• المزيد من العمل لإكمال واختبار إجراء النقل، وهو خطوة كبيرة في تعقيد أي خطة EIP عديمة الجنسية الجزء

• المزيد من التحليل الأمني ​​لوظائف التجزئة Poseidon وAjtai وغيرها من وظائف التجزئة "الصديقة لـ STARK"

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

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

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

< li>

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

• يعد استخدام التجزئة لتحديث جذور الحالة أسرع من استخدام أشجار Verkle. وهذا يعني أن الطريقة القائمة على التجزئة يمكنها تقصير وقت مزامنة العقدة الكاملة.

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

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

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

إذا تبين أن النظام ليس فعالًا بدرجة كافية في أسوأ الحالات، فيمكننا استخدام "أرنب آخر في القبعة" للتعويض عن هذا النقص، وهو الغاز متعدد الأبعاد: من أجل (i) بيانات الاتصال، (2) هناك حدود غاز منفصلة للحساب، (3) الوصول إلى الحالة، وربما موارد مختلفة أخرى. يضيف الغاز متعدد الأبعاد تعقيدًا، لكنه في المقابل يحد بشكل أكثر إحكامًا من النسبة بين المتوسط ​​وأسوأ الحالات. بالنسبة للغاز متعدد الأبعاد، يمكن تخفيض الحد الأقصى لعدد فروع النظرية المطلوب إثباتها من 30,000,000 / 2400 = 12,500 إلى 3000. وهذا من شأنه أن يجعل BLAKE3 (بالكاد) مناسبًا حتى اليوم، دون مزيد من التحسينات المثبتة.

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

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

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

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

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

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

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

إثبات فعالية تنفيذ EVM

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

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

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

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

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

• الإدخال العام:< /p> strong>جذر الحالة السابقة R، وجذر ما بعد الحالة R'، وتجزئة الكتلة H.

• المدخلات الخاصة: الكتلة B، الكائنات الموجودة في الحالة التي يتم الوصول إليها عن طريق الكتلة Q، نفس الكائنات بعد تنفيذ الكتلة Q'، إثباتات الحالة (على سبيل المثال Merkle) فرع) ص.

• الادعاء 1:P هو دليل صالح على أن Q يحتوي على جزء من الحالة التي يمثلها R.

• الادعاء 2: إذا قمت بتشغيل STF على Q، (i) يصل التنفيذ إلى الكائنات الموجودة داخل Q فقط، (ii) الكتلة صالحة، و (3) النتيجة هي Q' .

• المطالبة 3: إذا قمت بإعادة حساب جذر الحالة الجديد باستخدام المعلومات الواردة في Q' وP، فستحصل على R' .

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

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

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

EC PSE ZK-EVM (تم إهماله الآن نظرًا لوجود خيارات أفضل): https://github.com/privacy-scaling-explorations/zkevm- الدوائر

Zeth, والذي يعمل عن طريق تجميع EVM في RISC-0 ZK-VM: https://github.com /risc0/zeth

مشروع التحقق الرسمي من ZK-EVM: https:/ /verified-zkevm.org/

ما الذي يجب القيام به أيضًا، وما هي المقايضات التي يجب القيام بها؟

اليوم، الأدلة على فعالية EVM غير كافية من جانبين: الأمان ووقت الإثبات.

يتطلب إثبات الصلاحية الأمنية التأكد من أن SNARK يتحقق فعليًا من حساب EVM ومن عدم وجود أخطاء فيه. الطريقتان الرئيسيتان لتحسين الأمان هما الإثباتات المتعددة والتحقق الرسمي. يعني Multi-prover وجود تطبيقات متعددة مكتوبة بشكل مستقل لإثباتات الصلاحية، تمامًا مثل وجود عملاء متعددين، وجعل العملاء يقبلون الكتلة إذا كانت مجموعة فرعية كبيرة بما يكفي من تلك التطبيقات تثبت هذا الحظر. يتضمن التحقق الرسمي إثبات الصلاحية باستخدام الأدوات المستخدمة بشكل شائع لإثبات النظريات الرياضية (مثل Lean4). يقبل الإثبات فقط كمدخل التنفيذ الصحيح لمواصفات EVM الأساسية المكتوبة بلغة Python.

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

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

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

• إثبات تحسين النظام—— Orion, قد تؤدي أنظمة الإثبات الجديدة مثل Binius وGKR إلى انخفاض كبير آخر في وقت الإثبات للحوسبة ذات الأغراض العامة.

• تغييرات أخرى في استهلاك الغاز لـ EVM - يمكن تحسين العديد من الأشياء في EVM لجعلها أكثر ملاءمة للمُثبِّت، خاصة في السيناريو الأسوأ. إن إثبات كتلة إيثريوم متوسطة في 4 ثوانٍ لا يكفي إذا كان المهاجم قادرًا على إنشاء كتلة تستغرق عشر دقائق من وقت الإثبات. يمكن تقسيم تغييرات EVM المطلوبة إلى فئتين رئيسيتين:

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

• استبدال بنية البيانات - بالإضافة إلى استبدال شجرة الحالة ببديل أكثر ملاءمة لـ STARK، نحتاج أيضًا إلى استبدال قائمة المعاملات والإيصالات أثبتت الشجرة والهياكل الأخرى أنها مكلفة. يعد EIP الخاص بإيثان كيسلينج بنقل هياكل المعاملات والإيصالات إلى SSZ ([1] [2] [3]) خطوة في هذا الاتجاه.

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

هناك شيء واحد لم يتم ذكره أعلاه وهو أجهزة الإثبات: استخدام وحدات معالجة الرسومات، وFPGAs، وASICs لإنشاء البراهين بشكل أسرع. تعتبر Fabric Cryptography وCysic وAccseal هي القوى الدافعة وراء هذه الشركات الثلاث. يعد هذا أمرًا ذا قيمة كبيرة بالنسبة للطبقة الثانية، ولكن من غير المرجح أن يكون اعتبارًا حاسمًا للطبقة الأولى نظرًا لوجود رغبة قوية في الحفاظ على الطبقة الأولى لامركزية للغاية، مما يعني أن إنشاء الدليل يجب أن يكون على مجموعة فرعية كبيرة ضمن نطاق القدرات. يجب ألا يواجه مستخدمو Ethereum عنق الزجاجة في أجهزة شركة واحدة. يمكن للطبقة الثانية إجراء مقايضات أكثر جذرية.

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

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

• نحن بحاجة إلى مزيد من التحليل للعثور على المجموعة المثالية لتغيرات تكلفة الغاز لتقليل أوقات إثبات أسوأ الحالات.

• نحن بحاجة إلى بذل المزيد من العمل على نظام الإثبات

تتضمن المقايضات المحتملة هنا ما يلي:

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

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

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

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

تتم مشاركة التقنية الأساسية المطلوبة لتنفيذ إثباتات صلاحية EVM في الطبقة 1 بشكل كبير مع المنطقتين الأخريين:

• إثباتات صحة الطبقة الثانية (أي "مجموعات ZK")

• "منهجية عديمة الحالة لإثباتات التجزئة الثنائية STARK"

  < /li>

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

علاوة على ذلك، أثبتت فعالية EVM في L1 أنها تعمل على تحسين حد الغاز في L1 بشكل كبير.

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

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

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

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

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

يتم تعريف سلسلة المنارات على أنها وظيفة انتقال الحالة، تمامًا مثل EVM. يتم تحديد وظيفة انتقال الحالة من خلال ثلاثة عوامل:

• ECADD (يستخدم للتحقق من BLS) التوقيعات )

• الاقتران (يستخدم للتحقق من توقيعات BLS)

• تجزئة SHA256 (تستخدم لقراءة الحالة وتحديثها)

  p>

في كل كتلة نحتاج إلى التصديق على 1-16 BLS12-381 ECADDs لكل مدقق (ربما أكثر من واحد حيث يمكن تضمين التوقيعات في مجاميع متعددة بالوسط). يمكن تعويض ذلك من خلال تقنيات الحساب المسبق للمجموعة الفرعية، لذلك يمكننا القول أن كل مدقق هو BLS12-381 ECADD. اليوم، يتم التوقيع على كل حقبة من قبل ما يقرب من 30.000 مدقق. في المستقبل، قد يتغير هذا في أي من الاتجاهين بالنسبة للنهائية ذات الفتحة الواحدة (راجع التعليمات هنا): إذا سلكنا طريق "القوة الغاشمة"، فمن المحتمل أن يزيد هذا إلى مليون أداة تحقق لكل فتحة. وفي الوقت نفسه، مع Orbit SSF سيبقى عند 32,768 أو حتى ينخفض ​​إلى 8,1.

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

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

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

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

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

بشكل عام، هناك العديد من التحديات.

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

• تغييرات دالة التجزئة:اليوم، يتم استخدام وظيفة تجزئة SHA256 "الكاملة"، لذلك بسبب الحشو، تتوافق كل مكالمة مع مكالمتين لوظيفة الضغط الأساسية. على أقل تقدير، يمكننا الحصول على مكاسب 2x عن طريق التبديل إلى ضغط SHA256. إذا استخدمنا Poseidon بدلاً من ذلك، فسنحصل على ربح قدره 100x تقريبًا، مما يحل جميع مشكلاتنا تمامًا (على الأقل بالنسبة للتجزئة): 1.7 مليون تجزئة في الثانية (54 ميجابايت) وحتى "قراءة مليون سجل مدقق" "يمكن إثباته في ثوانٍ.

• في حالة Orbit، قم بتخزين سجلات أداة التحقق المجمعة مباشرةً: إذا قمت بتحديد عدد معين من أدوات التحقق (على سبيل المثال، 8,192 أو 32,768) كما هو محدد لجنة الفتحة، ثم ضعها مباشرة في الحالة بجانب بعضها البعض بحيث يكون الحد الأدنى لمبلغ التجزئة مطلوبًا لقراءة جميع المفاتيح العامة للمدقق في الدليل. سيؤدي هذا أيضًا إلى تمكين استكمال جميع تحديثات الرصيد بكفاءة.

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

• أنظمة التوقيع الأخرى: بالنسبة لتوقيع Lamport+Merkle، نحتاج إلى 256+32 علامة تجزئة للتحقق من التوقيع؛ وضربها في 32,768 موقعًا للحصول على 9,437,184 علامة تجزئة . يمكن أن تؤدي تحسينات نظام التوقيع إلى تحسين ذلك بعامل ثابت صغير. وإذا استخدمنا بوسيدون، فهذا ضمن نطاق ما يمكن إثباته ضمن فتحة واحدة. ولكن في الواقع، يصبح هذا أسرع مع نظام التجميع التكراري.

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

دليل بسيط لإجماع الإيثريوم (لجنة المزامنة فقط): https://github.com/succinctlabs/eth-proof-of-consensus

بسيط، Helios في SP1: https://github.com/succinctlabs/sp1-helios

تجميع مسبق موجز لـ BLS12-381:< a href="https ://blog.succinct.xyz/succinctshipsprecompiles/" _src="https://blog.succinct.xyz/succinctshipsprecompiles/">https://blog.succinct.xyz/succinctshipsprecompiles/

< p style="text-align: left;">التحقق من التوقيع الكلي لـ BLS استنادًا إلى Halo2: https://ethresear.ch/t/zkpos -with-halo2-pairing-for-verifying-aggregate-bls-signatures/14671

ما الذي يجب فعله أيضًا، وما هي المقايضات التي يجب إجراؤها؟

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

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

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

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