تتيح EIP-8361 لمعاملة إطار EIP-8141 إرسال إثبات STARK مختصر مع حمولة النظير إلى النظير، مما يمكّن العقد من التأكد من أن بادئة التحقق وافقت على المعاملة بناءً على الافتراضات المعلنة للحالة. بدلاً من تكرار نفس الآلية، تقوم العقد بفحص إثبات واحد، واعتمادياته، وشروط الحالة ذات الصلة، مما قد يقلل من تكلفة التحقق للمنطق المعقد للحسابات. تستعرض الأقسام أدناه كيفية حصول المعاملات الصحيحة على الإثباتات، وكيفية اكتشاف العقد للمعاملات الراكدة أو الاحتيالية، ولماذا يشير الإثبات إلى الحالة الصحيحة السابقة دون أن يكون جذر ميركل، ولماذا يتم التخلص منه بعد تضمينه في الكتلة.
كما يوضح الشرح الفارق بين EIP-8361 وأنواع الأمان الرئيسية في الرول أب: إثباتات ZK التي تثبت الصحة قبل القبول، وإثباتات الاحتيال التي تتطلب عملية تحدٍ لإثبات وجود انتقال غير صالح. كما يوضح الحدود المتعلقة بتواقيع ECDSA، وأمان الكم، والمخاطر المحتملة من الحواسيب الكمومية، والدور المحدود للاقتراح مقارنة بحلول التوسع. يستهدف هذا التحليل الفني فرق المحافظ، ومطوري العملاء، ومشغلي المُثبِّت، والمستخدمين الذين يقيمون كيف يمكن للمعاملات الحاملة للإثبات تمكين تحقق أكثر تعقيدًا لإيثريوم بينما تظل EIP-8361 اقتراحًا شبكيًا مسودّة وليس قاعدة إجماع فعالة.
النقاط الرئيسية
- تتيح EIP-8361 لمعاملة إطار EIP-8141 إرفاق إثبات قبول كبيانات وصفية للنقل خارج السلسلة.
- ينفذ مُثبِّت خارج السلسلة بادئة التحقق وفق الافتراضات المعلنة وينتج STARK مرتبطًا بالمعاملة، والدافع، والاعتماديات، وشروط الصحة.
- تجري العقدة المستقبلة فحوصات عديمة الحالة، وتتحقق من الإثبات والاعتماديات، وتقارن الافتراضات بحالة إيثريوم الحالية لديها.
- يسمح الإثبات الصحيح بقبول المعاملة في الذاكرة المؤقتة دون تكرار محاكاة بادئة التحقق الكاملة.
- لا يحدد الإثبات صحة الكتلة أو يغير التنفيذ أو يصبح جزءًا من الحالة الدائمة لإيثريوم. يتم التخلص منه بعد التضمين أو الإزالة من الذاكرة المؤقتة.
ما هي إثباتات صحة المعاملات في EIP-8361؟
تحدد EIP-8361 طريقة قبول مقترحة للمعاملات المنشأة وفق EIP-8141، بهدف جعل بعض المعاملات المكلفة حسابيًا رخيصة بما يكفي لتقييمها من قبل العقد قبل تمريرها عبر الذاكرة المؤقتة العامة.
يمكن أن تحتوي معاملة إطار EIP-8141 على منطق قابل للبرمجة يحدد ما إذا كان المرسل يصرح بالمعاملة، ومن سيدفع تكاليف التنفيذ، وما إذا كانت الشروط المحددة قد تم استيفاؤها. يظهر هذا المنطق في بادئة تحقق تُنفذ قبل أطر التنفيذ العادية للمعاملة.
عادةً، في القبول المحاكى، قد تحتاج كل عقدة مستقبلة إلى تنفيذ تلك البادئة لتحديد ما إذا كان ينبغي إدخال المعاملة إلى الذاكرة المؤقتة لديها. تضيف EIP-8361 خيارًا آخر: ينفذ المُثبِّت البادئة مرة واحدة خارج السلسلة وينشئ إثباتًا تشفيريًا يُظهر أنها تنتهي بنتيجة APPROVE ودافع محدد.
تسافر المعاملة والإثبات معًا، وتتحقق العقدة من الإثبات بدلاً من إعادة بناء عملية التحقق الكاملة.
يهتم إطار عمل EIP-8361 بقبول المعاملات الحاملة للإثبات في الذاكرة المؤقتة، بينما تحدد عملية التحقق من المعاملات في EIP-8361 كيف تقرر العقد المستقبلة ما إذا كانت ستقبل أو تحتفظ أو توقف أو تزيل هذه المعاملات.
اعتبارًا من 6 أغسطس 2026، يتم تقديم EIP-8361 في طلب سحب مسودة رقم #12075 كمقترح مسار معايير للشبكات. لا يقدم نوع معاملة جديد أو يغير إجماع إيثريوم بحد ذاته.
كيف يعمل الإثبات التشفيري في EIP-8361؟
يغطي الإثبات بيانًا محددًا بدلاً من الادعاء بأن كل نتيجة تنفيذ مستقبلية معروفة.
بصيغة مبسطة، يجب على المُثبِّت إثبات أن:
بادئة التحقق للمعاملة T، عند تقييمها وفق الافتراضات والاعتماديات المعلنة، تتبع قواعد تتبع EIP-8141 وتنتهي بـ APPROVE والدافع P، وفق الشروط المعلنة.
تربط المدخلات العامة المقترحة الإثبات بخمسة عناصر:
| المدخل العام |
ما يمثله |
| sig_hash(T) |
تجزئة تحدد معاملة الإطار |
| H(A) |
التزام بموجه الافتراضات |
| H(D) |
التزام بالاعتماديات أو التواقيع المعلنة |
| P |
الحساب المحدد كدافع للمعاملة |
| C |
الشروط التي تحكم متى يبقى القبول صالحًا |
هذا الربط ضروري لأن إثباتًا صحيحًا لمعاملة واحدة لا يمكن إرفاقه بمعاملة أخرى ببيانات أو اعتماديات أو شروط أو معلومات دافع مختلفة.
يتضمن الشاهد الخاص المعلومات المطلوبة لتقييم البادئة، بما في ذلك محتويات قائمة الاعتماديات المعلنة. يوضح الإثبات صحة تلك العملية الحسابية دون إلزام كل عقدة مستقبلة بتكرارها.
تقترح EIP-8361 حاليًا إعادة استخدام تنسيق الإثبات وآلية التحقق من الدخول المرتبطة بـ EIP-8288. تسمي EIP إثباتات STARK لأنها تمثل حسابًا كبيرًا بإثبات مختصر نسبيًا ولا تتطلب من كل مُحقِّق إعادة إنتاج عبء العمل الأصلي.
كيف يُستخدم موجه الافتراضات في التحقق من المعاملات؟
يمكن لإثبات تشفيري أن يُظهر أن عملية حسابية كانت صحيحة لمدخلات معينة، لكن عقدة الذاكرة المؤقتة يجب أن تحدد ما إذا كانت تلك المدخلات تطابق حالة إيثريوم الحالية.
تعالج EIP-8361 هذا بموجه افتراضات، يُمثل بـ A، يسرد كل قيمة حالة تقرأها بادئة التحقق. تشمل الإدخالات المقترحة عنوانًا، ومفتاح تخزين أو مرجع رصيد، ونوع مقارنة، وقيمة.
يتم تعريف نوعي مقارنة:
- افتراضات EQ تتطلب أن تكون قيمة الحالة الحالية مساوية للقيمة المعلنة في الإثبات.
- افتراضات GEQ تتطلب أن تبقى قيمة الحالة الحالية أكبر من أو تساوي حدًا معلنًا.
قد يكون إدخال EQ مناسبًا لتجزئة الشيفرة أو العداد أو فرع التخزين الذي يتغير معناه كلما تغيرت القيمة الأساسية. إدخال GEQ أكثر فائدة للمتطلبات الأحادية الاتجاه مثل التحقق من أن الدافع لديه أموال كافية لتغطية الدفع المسبق.
على سبيل المثال، إذا كانت بادئة التحقق لحساب ذكي توافق على معاملة فقط عندما يكون رصيد الممول لا يقل عن 0.2 ETH. يمكن للمُثبِّت تسجيل افتراض GEQ بحد 0.2 ETH، وتستمر العقدة في اعتبار الإثبات صالحًا طالما بقي الرصيد 0.2 ETH أو أعلى. لا تحتاج إلى إثبات جديد كلما زاد الرصيد أو تغير فوق ذلك الحد.
يتجنب هذا التصميم ربط الإثبات بجذر حالة كاملة أو الحاجة إلى إثبات ميركل كبير لحالة إيثريوم بأكملها. يقيم الدائرة بادئة التحقق مقابل القيم المعلنة، بينما تتحقق العقدة من تلك القيم مقابل حالتها الحالية.
كيف تعمل إثباتات صحة المعاملات وفق EIP-8361؟
تتبع عملية التحقق المقترحة للمعاملة سلسلة مرتبة من الفحوصات:
- تشغيل الفحوصات عديمة الحالة. تتحقق العقدة من صحة المعاملة الجوهرية وتؤكد أن قائمة الاعتماديات أو التواقيع مُشكلة بشكل صحيح. تُرفض المعاملة المشوهة قبل التحقق المكلف من الإثبات.
- التحقق من إثبات القبول. تتحقق العقدة من STARK مقابل مفتاح التحقق المخصص. الفشل يعني أن الحساب المزعوم لم يتم إثباته.
- التحقق من الاعتماديات الخارجية. قد يفترض الإثبات أن التواقيع أو الاعتماديات الأخرى المعلنة صحيحة. تتحقق العقدة من تلك الاعتماديات بشكل منفصل وتؤكد أن قائمتها تطابق تجزئة الاعتماديات الملتزم بها.
- فحص شروط الصحة. تقيم العقدة الشروط المعلنة، والتي قد تشمل المواعيد النهائية، أو نوافذ الخانات أو الفترات، أو نطاقات انتهاء الصلاحية، أو متطلبات العداد.
- مقارنة الافتراضات بالحالة الحية. يتم فحص كل إدخال EQ للمساواة، بينما يتم اختبار كل إدخال GEQ مقابل حده.
- قبول المعاملة. عند نجاح كل فحص، قد تقبل العقدة المعاملة وتنشرها دون محاكاة بادئة التحقق الكاملة.
تمنع هذه السلسلة من الفحوصات الإثبات من تجاوز الفحوصات الهيكلية أو التوقيعات أو الحالة أو التوقيت العادية. إنها تغير الطريقة الحسابية لاتخاذ قرار القبول، وليس متطلبات صحة المعاملة الأساسية.
ماذا يحدث عند تغير حالة إيثريوم؟
قبول المعاملة في الذاكرة المؤقتة ليس ضمانًا دائمًا لأن حالة إيثريوم تتغير بعد دخول المعاملة إلى التجمع.
وفق EIP-8361، تعيد العقدة فحص شروط الصحة وموجه الافتراضات عند تغير رأس السلسلة بكتلة جديدة. لا تحتاج إلى إعادة إنشاء الإثبات أو إعادة تنفيذ بادئة التحقق أو التحقق من نفس الإثبات مرة أخرى. يبقى الإثبات الذي تم التحقق منه سابقًا نتيجة مخزنة حول وظيفة التحقق وفق مدخلاته المعلنة.
عادة ما يؤدي فشل EQ إلى إبطال الإثبات لأن مدخلاً دقيقًا قد تغير. يجب على العقدة إخلاء المعاملة ما لم يُنشئ المرسل إثباتًا جديدًا أو كانت المعاملة مؤهلة للقبول المحاكى العادي.
يمكن التعامل مع فشل شرط GEQ بشكل مختلف. قد توقف العقدة المعاملة بدلاً من إزالتها تمامًا. إذا تلقى الدافع أو الممول لاحقًا أموالاً كافية، يمكن للعقدة إعادة تفعيل المعاملة بفحص الحد مرة أخرى.
هذا التمييز يجعل موجه الافتراضات أكثر من مجرد التزام بأسلوب ميركل بحالة تاريخية واحدة. إنه يحدد أي تغييرات في الحالة تبطل القبول وأيها تبقى متوافقة معه.
لماذا يتم التخلص من الإثبات بعد تضمينه في الكتلة؟
يحتاج إثبات EIP-8361 فقط للقبول في الذاكرة المؤقتة العامة والنشر. ليس هو الإثبات الرسمي بأن المعاملة المضمنة أنتجت انتقال حالة صحيح.
بمجرد أن يدرج المُدقِّق المعاملة في كتلة، تعالجها إيثريوم عبر التنفيذ البروتوكولي العادي. ينفذ EVM بادئة التحقق والأطر المتبقية وفقًا للحالة الرسمية للكتلة. تحدد عملاء الإجماع ما إذا كانت الكتلة صالحة باستخدام قواعد إيثريوم العادية.
بالتالي، فإن إثبات القبول:
- لا يوضع في الكتلة؛
- لا يُضاف إلى بيانات الاستدعاء للمعاملة؛
- لا يظهر في الإيصال؛
- لا يصبح جزءًا من شجرة ميركل أو جذر الحالة؛
- لا ينشئ تغييرًا دائمًا في الحالة على السلسلة؛
- لا يحتاج إلى الاحتفاظ به بعد تضمين المعاملة أو حذفها.
التخلص منه يتجنب تكلفة بيانات الاستدعاء الدائمة ونمو الحالة لمعلومات أدت غرضها الشبكي بالفعل. تبقى المعاملة نفسها على السلسلة، لكن غلاف الإثبات المؤقت لا يبقى.
نظام إثباتات EIP-8361 مقابل إثباتات صحة ZK-Rollup
تستخدم EIP-8361 تقنية الإثبات التشفيري، لكن إثبات القبول الخاص بها لا ينبغي الخلط بينه وبين إثباتات الصحة المستخدمة في ZK rollups.
| البعد |
إثبات القبول في EIP-8361 |
إثبات صحة ZK-rollup |
| الغرض الرئيسي |
تحديد ما إذا كانت المعاملة قد تدخل وتنتشر عبر الذاكرة المؤقتة العامة |
إثبات صحة دفعة من انتقالات الحالة في الطبقة 2 |
| النطاق |
بادئة التحقق لمعاملة إطار واحدة |
دفعة من معاملات الطبقة 2 وانتقال حالتها الناتج |
| المُحقِّق |
عقد الشبكة المستلمة |
عادة عقدة تحقق في الطبقة 1 |
| التقديم على السلسلة |
لا |
نعم |
| الدور البرتوكولي الدائم |
لا يوجد بعد القبول أو الحذف |
يُصرح أو يؤكد تحديث حالة الطبقة 2 |
| متطلبات الخصوصية |
غير مطلوبة جوهريًا |
قد توفر أو لا توفر الخصوصية |
| فترة التحدي |
لا يوجد |
إثباتات الصحة لا تعتمد على فترة تحدي متفائلة |
تستخدم ZK rollups عادةً ZK-SNARKs أو ZK-STARKs لإثبات صحة دفعات المعاملات. بمجرد قبول الإثبات من عقدة الطبقة 1، يمكن للرول أب إنهاء انتقال الحالة المرتبط دون انتظار فترة التحدي المستخدمة في الرول أب المتفائل.
لا تثبت EIP-8361 دفعة من الطبقة 2، أو تصرح بسحب فوري من الرول أب، أو تضمن ألا تدخل سلسلة الطبقة 2 في حالة غير صالحة. إثباتها هو أثر شبكي مؤقت حول التحقق قبل التضمين.
وبالمثل، رغم أن إثباتات المعرفة الصفرية يمكن أن تتحقق من بيان دون كشف كل بيانات الشاهد، إلا أن EIP-8361 ليست اقتراحًا للخصوصية أساسًا. "الإثبات المختصر" و"المعرفة الصفرية" صفات مترابطة لكن غير متبادلة دائمًا.
يمكن أن تكون عمليات السحب من الطبقة 2 إلى الطبقة 1 أسرع مع إثباتات الصحة لأن ZK rollups لا تتطلب فترة التحدي المستخدمة في الرول أب المتفائل. لا تزال مدة السحب النهائية تعتمد على توليد الإثبات، والتحقق في الطبقة 1، وقواعد الجسر، ونهائية إيثريوم. لا تقدم EIP-8361 هذه الآلية؛ إثباتها يدعم قبول معاملة إطار EIP-8141 فردية في الذاكرة المؤقتة، وليس تسوية دفعة معاملات الطبقة 2.
كيف تعمل إثباتات الاحتيال في الرول أب المتفائل؟
تعتمد إثباتات الاحتيال على آلية أمان مختلفة. يقبل الرول أب المتفائل في البداية انتقال حالة مقترح ويسمح للمعترضين بإثبات الاحتيال خلال فترة نزاع. حسب التنفيذ، قد يتطلب حل النزاع جولات متعددة أو إثبات تنفيذ محدد.
تحاول EIP-8361 إثبات بيان القبول المطلوب قبل قبول المعاملة في فئة الذاكرة المؤقتة ذات الصلة. لا توجد فترة تحدٍ بعد القبول يمكن فيها لمشارك آخر إثبات أن نتيجة البادئة كانت احتيالية.
الفرق الرئيسي يكمن في التوقيت والنطاق:
- إثبات الصحة يثبت ادعاءً محددًا قبل القبول.
- إثبات الاحتيال يسمح بادعاء متفائل إلا إذا تم تحديه بنجاح.
- إثبات القبول في EIP-8361 يتعلق بسياسة الذاكرة المؤقتة.
- إثبات الاحتيال في الرول أب يتعلق بصحة انتقال حالة الطبقة 2.
تتناول EIP-8361 مقابل محاكاة المعاملات المفاضلات التقنية بين تنفيذ EVM المتكرر والتحقق المختصر، بما في ذلك حيث تحل تكلفة توليد الإثبات محل تكلفة المحاكاة على جانب العقدة.
EIP-8361، تحقق الحسابات المعقدة، وأمان ما بعد الكم
قد تستخدم الحسابات القابلة للبرمجة تفويضًا متعدد التواقيع، أو تدوير المفاتيح، أو قواعد الاسترداد، أو مخططات توقيع غير قياسية، أو مرشحين لتواقيع ما بعد الكم، أو سياسات إنفاق، أو فحوصات معرفة صفرية كثيفة الرسوم. قد يكون بعض هذا المنطق صحيحًا لكنه مكلف للغاية بحيث لا يمكن لكل عقدة ذاكرة مؤقتة محاكاته بأمان.
تحاول EIP-8361 الحفاظ على نشر المعاملات العامة لهذه الحسابات بجعل التحقق مكلفًا للمُثبِّت ورخيصًا نسبيًا لكل مُحقِّق. قد يقلل ذلك أيضًا من الضغط لنقل التفويض المعقد إلى مرحلة التنفيذ، حيث قد يصبح الفحص الفاشل معاملة مرتدة مدفوعة ومسجلة علنًا.
لا تجعل هذه الآلية كل عقد ذكي آمنًا أو تحقق أمانًا كاملًا لما بعد الكم. قد يتجنب STARK بعض الافتراضات المرتبطة بأنظمة الإثبات القائمة على المنحنيات الإهليلجية، لكن المعاملة قد تعتمد على مفاتيح عامة، أو مخططات توقيع، أو تنفيذات العملاء، أو شيفرة المحفظة، أو مفاتيح تحقق ذات خصائص أمان منفصلة.
تختلف المسؤوليات الناتجة عن منشئي المعاملات، والمحافظ، والمُثبِّتين، والعملاء بشكل كبير، كما هو ملخص في أثر EIP-8361 على المحفظة والعقدة والمطور.
على سبيل المثال، يمكن للمتداول الذي يقيم ما إذا كانت تطورات تجريد حسابات إيثريوم تؤثر على معنويات السوق مقارنة مراحل الاقتراح مع مخطط سوق ETH/USDT، رغم أن حركة السعر لا يمكنها تأكيد ما إذا تم تنفيذ أو اعتماد EIP مسودّة.
المخاطر والقيود
تظل EIP-8361 مسودة مبكرة، لذا قد تتغير صيغة الإثبات، والحدود، والاعتماديات، والمصطلحات، وتفاصيل التنفيذ قبل التقييس.
كما يقدم النظام عدة مخاطر تقنية:
تركيز توليد الإثبات: قد يتطلب إنتاج STARK برامج متخصصة وحسابًا كبيرًا. إذا كانت خدمات قليلة فقط قادرة على توليد الإثباتات بكفاءة، قد تعتمد المحافظ على بنية تحتية مركزية للمُثبِّت.
ضغط هجمات حجب الخدمة: التحقق من الإثبات أرخص من تكرار الحساب الأصلي، لكنه ليس مجانيًا. يحتاج العملاء إلى حدود حجم الإثبات ثابتة، وحدود معدل النظراء، ونسب الفشل لمنع المهاجمين من إغراق العقد بإثباتات غير صالحة أو كبيرة الحجم.
اكتمال الافتراضات: يكون الإثبات ذا معنى فقط عندما يحتوي موجه الافتراضات على كل حالة قراءة استخدمتها بادئة التحقق. قد يؤدي خطأ في الدائرة أو العميل يتجاهل اعتمادًا إلى قرارات قبول غير صحيحة.
ركود الحالة: قد يبقى الإثبات صحيحًا تشفيريًا بينما لم تعد شروطه المعلنة تطابق الحالة الحالية. يجب على العقد الاستمرار في إعادة فحص A و C ما دامت المعاملة موجودة في التجمع.
لا يوجد ضمان للتنفيذ: القبول في الذاكرة المؤقتة لا يضمن تضمين الكتلة أو التنفيذ النهائي الناجح. قد تغير معاملة أخرى العداد أو الرصيد أو الشيفرة أو التخزين أو حالة أخرى ذات صلة للمرسل قبل التضمين.
تعقيد التنفيذ: يجب على العملاء، والمحافظ، وأنظمة المُثبِّت الاتفاق على ترميز الإثبات، ومفاتيح التحقق، والتعامل مع الاعتماديات، وسلوك النظراء، وقواعد إعادة التحقق. قد تؤدي التنفيذات غير المتسقة إلى تجزئة انتشار المعاملات.
هل EIP-8361 هو نفسه اقتراح Tapered Issuance Burn؟
ربطت بعض النقاشات المبكرة رقم EIP-8361 باقتراح منفصل لسياسة نقدية في إيثريوم يُسمى Tapered Issuance Burn. تم تحديد هذا الاقتراح لاحقًا كـ EIP-8363، بينما تشير EIP-8361 إلى إثباتات صحة المعاملات في فئة الشبكات. الاقتراحان غير مرتبطين: تعالج EIP-8361 قبول المعاملات الحاملة للإثبات في الذاكرة المؤقتة، بينما يغير Tapered Issuance Burn اقتصاد المكافآت في طبقة الإجماع وفق رصيد التخزين النشط.
الخلاصة
تنقل إثباتات صحة المعاملات في EIP-8361 الجزء المكلف من تحقق المعاملات القابلة للبرمجة بعيدًا عن كل عقدة مستقبلة نحو مُثبِّت خارج السلسلة. يربط STARK الناتج معاملة EIP-8141 بنتيجة القبول، والدافع، والاعتماديات، والشروط، وافتراضات الحالة، مما يمكّن العقد من التحقق من ادعاء مختصر قبل القبول في الذاكرة المؤقتة.
تكون الآلية أكثر فائدة عندما يحتوي الحساب الذكي على منطق تحقق مشروع يتجاوز حدود المحاكاة العملية. قيدها الرئيسي لا يقل أهمية: ينطبق الإثبات فقط على القبول في طبقة الشبكة. لا تزال إيثريوم تنفذ المعاملة بشكل طبيعي عند التضمين، ويتم التخلص من الإثبات المؤقت لأنه لا دور له في الإجماع أو على السلسلة لاحقًا.
الأسئلة الشائعة
كيف تستخدم ZK rollups إثباتات الصحة؟
تعالج ZK rollups المعاملات خارج السلسلة، وتجمعها في دفعات، وتولد إثبات صحة لكل دفعة. يتيح الإثبات، الذي يُبنى غالبًا باستخدام ZK-SNARKs أو ZK-STARKs أو التزامات متعددة الحدوديات، لعقدة إيثريوم التحقق من أن انتقال الحالة الناتج صحيح دون إعادة تنفيذ كل معاملة.
هل تضمن إثباتات الصحة أن سلسلة الطبقة 2 لا يمكن أن تصبح غير صالحة؟
تمنع إثباتات الصحة عقدة الطبقة 1 من قبول انتقال حالة غير صالح عندما تعمل الدائرة، وعقدة التحقق، والتشفير، والتنفيذ بشكل صحيح. لكنها لا تقضي على المخاطر المتعلقة بأخطاء الشيفرة، وتوافر البيانات، والجسور، والمنسقين، والحوكمة، أو ضوابط التحديث.
لماذا تكون عمليات السحب في ZK-rollup أسرع عادة؟
يمكن لـ ZK rollups إنهاء عمليات السحب بعد تقديم والتحقق من إثبات الصحة، دون انتظار فترة التحدي المستخدمة في الرول أب المتفائل. قد تعتمد عمليات السحب أيضًا على توليد الإثبات، وتقديم الدفعة، وقواعد الجسر، ونهائية إيثريوم، لذا "الفورية" لا تعني دائمًا آنية.
ما الفرق بين إثباتات الصحة وإثباتات الاحتيال؟
تثبت إثباتات الصحة صحة المعاملة قبل قبول انتقال الحالة. تعمل إثباتات الاحتيال وفق نموذج متفائل حيث قد يُقبل الانتقال مؤقتًا ويُطعن فيه لاحقًا؛ يستخدم العديد من الرول أب المتفائل فترة تحدٍ تقارب سبعة أيام، رغم أن المدة الفعلية تختلف.
هل تخفي إثباتات المعرفة الصفرية دائمًا بيانات المعاملة؟
لا. يمكن لإثباتات المعرفة الصفرية التحقق من بيان دون كشف الشاهد الخاص، لكن الخصوصية تعتمد على أي مدخلات تبقى مخفية. تستخدم العديد من ZK rollups الإثباتات أساسًا للتحقق القابل للتوسع للمعاملات بدلاً من المعاملات الخاصة بالكامل.
ما الفرق بين ZK-SNARKs وZK-STARKs؟
تنتج ZK-SNARKs عادة إثباتات صغيرة مع تكلفة تحقق منخفضة، رغم أن العديد من التصميمات تتطلب إعدادًا موثوقًا. لا تتطلب ZK-STARKs إعدادًا موثوقًا وتُعتبر أكثر مقاومة لهجمات الحواسيب الكمومية المستقبلية، لكن إثباتاتها غالبًا أكبر حجمًا.
ماذا يتحقق إثبات ميركل؟
يؤكد إثبات ميركل أن بيانات محددة تنتمي إلى مجموعة بيانات يمثلها جذر ميركل دون كشف أو تحميل المجموعة الكاملة. يثبت الإدراج أو الاستبعاد، وليس صحة دفعة معاملات كاملة أو انتقال حالة.
هل تقلل إثباتات الصحة من استهلاك الموارد على السلسلة؟
نعم، يمكنها ضغط حساب كبير خارج السلسلة في إثبات واحد أرخص للتحقق على السلسلة من إعادة تنفيذ كل معاملة. تعتمد الوفورات الفعلية على تكلفة التحقق من الإثبات، وحجم الدفعة، واستخدام بيانات الاستدعاء أو blob، وتنفيذ الرول أب.
هل تقلل إثباتات الصحة من خطر هجوم %51؟
ليس بشكل مباشر. تحمي إثباتات الصحة صحة انتقالات الحالة في الطبقة 2، بينما يتعلق هجوم %51 بالسيطرة على إجماع إيثريوم واختيار التفرع. الآليتان تعالجان مخاطر أمان مختلفة.
هل إثباتات EIP-8361 هي نفسها إثباتات ZK-rollup؟
لا. تحقق إثباتات ZK-rollup من دفعات معاملات الطبقة 2 وتدعم نهائية الحالة وعمليات السحب. تدعم إثباتات EIP-8361 قبول معاملة إطار EIP-8141 فردية في الذاكرة المؤقتة، وتبقى خارج الكتلة، ويتم التخلص منها بعد التضمين أو الإزالة.
إخلاء مسؤولية
هذا المحتوى تعليمي ويصف اقتراحًا مسودّة لإيثريوم قد تتغير مواصفاته وحالته التنفيذية. لا يقدم نصيحة مالية أو أمنية أو متعلقة بنشر البرمجيات. يجب على المطورين التحقق من نص EIP الأحدث ومتطلبات العميل قبل بناء أنظمة الإنتاج.
