فيتاليك حول المستقبل المحتمل لـ Ethereum (6): The Splurge

في تصميم بروتوكول Ethereum، حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات EVM، بينما يتكون النصف الآخر من مواضيع متخصصة متنوعة، وهذا هو معنى "The Splurge" (الازدهار).

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

الكاتب: Vitalik Buterin

الترجمة: zhouzhou، BlockBeats

فيما يلي محتوى المقال الأصلي (تمت إعادة تنظيمه لتسهيل القراءة والفهم):

بعض الأمور يصعب تصنيفها تحت فئة واحدة، ففي تصميم بروتوكول Ethereum، هناك العديد من "التفاصيل" التي تعتبر مهمة جدًا لنجاح Ethereum. في الواقع، حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات EVM، بينما يتكون النصف الآخر من مواضيع متخصصة متنوعة، وهذا هو معنى "The Splurge" (الازدهار).

خارطة الطريق لعام 2023: الازدهار

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

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

تحسينات EVM

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

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

ما هو هذا التحسين، وكيف يعمل؟

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

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

هيكل شيفرة EOF

الازدهار: تحسينات EVM (متابعة)

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

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

فكرة أحدث هي الجمع بين EVM-MAX وميزة التعليمات الفردية المتعددة البيانات (SIMD)، حيث أن SIMD كفكرة في Ethereum موجودة منذ فترة طويلة، واقترحها لأول مرة Greg Colvin في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، وSTARKs ذات 32 بت، والتشفير القائم على الشبكات، ويجعل الجمع بين EVM-MAX وSIMD هذين التوسعين الموجهين للأداء زوجًا طبيعيًا.

سيبدأ التصميم التقريبي لمجموعة EIP مجمعة من EIP-6690، ثم:

• السماح بـ (i) أي عدد فردي أو (ii) أي قوة للعدد 2 حتى 2768 كموديلوس
• لكل رمز عملية EVM-MAX (جمع، طرح، ضرب)، إضافة إصدار لا يستخدم 3 أعداد مباشرة x، y، z، بل يستخدم 7 أعداد مباشرة: x_start، x_skip، y_start، y_skip، z_start، z_skip، count. في كود Python، تعمل هذه الرموز كما يلي:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

في التنفيذ الفعلي، سيتم معالجة ذلك بطريقة متوازية.

• قد تتم إضافة XOR، AND، OR، NOT وSHIFT (بما في ذلك الدائري وغير الدائري)، على الأقل لموديلوس قوة 2. كما تتم إضافة ISZERO (لدفع الإخراج إلى كومة EVM الرئيسية)، وهذا سيكون قويًا بما يكفي لتنفيذ التشفير البيضاوي، والتشفير في الحقول الصغيرة (مثل Poseidon، Circle STARKs)، ودوال التجزئة التقليدية (مثل SHA256، KECCAK، BLAKE)، والتشفير القائم على الشبكات. قد يتم تنفيذ ترقيات أخرى لـ EVM، لكن حتى الآن لم تحظ باهتمام كبير.

روابط الأبحاث الحالية

• EOF: 
• EVM-MAX: 
• SIMD: 

ما تبقى من العمل والمفاضلات

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

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

هناك عمل مهم يجب القيام به وهو تنفيذ ميزات مثل EVM-MAX مع SIMD، واختبار استهلاك الغاز لمختلف العمليات التشفيرية.

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

تعديل L1 لـ EVM يجعل من الأسهل على L2 إجراء تعديلات مماثلة، وإذا لم يتم التعديل بشكل متزامن، فقد يؤدي ذلك إلى عدم التوافق وتأثيرات سلبية. بالإضافة إلى ذلك، يمكن أن يقلل EVM-MAX وSIMD من تكلفة الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يسهل استبدال المزيد من الترجمة المسبقة بشيفرة EVM يمكنها تنفيذ نفس المهام، دون التأثير الكبير على الكفاءة.

تجريد الحسابات

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

حاليًا، لا يمكن التحقق من المعاملات إلا بطريقة واحدة: توقيع ECDSA. في البداية، كان الهدف من تجريد الحسابات هو تجاوز ذلك، والسماح لمنطق التحقق في الحساب بأن يكون أي شيفرة EVM. يمكن أن يتيح ذلك مجموعة من التطبيقات:

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

السماح لبروتوكولات الخصوصية بالعمل بدون وسيط، مما يقلل بشكل كبير من تعقيدها ويزيل نقطة اعتماد مركزية رئيسية

منذ اقتراح تجريد الحسابات في 2015، توسعت أهدافه لتشمل العديد من "أهداف الراحة"، مثل تمكين حساب لا يملك ETH ولكن يملك بعض ERC20 من دفع الغاز باستخدام ERC20. فيما يلي رسم بياني يلخص هذه الأهداف:

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

EIP-7702 هو اقتراح مخطط إدراجه في الهارد فورك القادم، وهو نتيجة إدراك متزايد لفائدة تجريد الحسابات لجميع المستخدمين (بما في ذلك مستخدمي EOA)، ويهدف إلى تحسين تجربة جميع المستخدمين على المدى القصير وتجنب الانقسام إلى نظامين بيئيين.

بدأ هذا العمل مع EIP-3074، وتطور في النهاية إلى EIP-7702. يوفر EIP-7702 ميزات "الراحة" لتجريد الحسابات لجميع المستخدمين، بما في ذلك مستخدمي EOA اليوم (الحسابات المملوكة خارجيًا، أي التي يتحكم فيها توقيع ECDSA).

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

ما هو تجريد الحسابات، وكيف يعمل؟

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

تحدٍ رئيسي نموذجي هو مشكلة الفشل المتعدد:

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

بعد سنوات من العمل، بهدف توسيع الوظائف مع الحد من مخاطر رفض الخدمة (DoS)، تم التوصل أخيرًا إلى حل لتحقيق "تجريد الحسابات المثالي": ERC-4337.

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

تم تصميم ERC-4337 كمعيار بروتوكول إضافي (ERC)، لأنه في ذلك الوقت كان مطورو عملاء Ethereum يركزون على الدمج (Merge)، ولم يكن لديهم طاقة إضافية لمعالجة ميزات أخرى. لهذا السبب يستخدم ERC-4337 كائنات تسمى عمليات المستخدم، وليس المعاملات العادية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء منها على الأقل في البروتوكول.

هناك سببان رئيسيان لذلك:

1. الكفاءة المنخفضة المتأصلة في EntryPoint كعقد: هناك تكلفة ثابتة تبلغ حوالي 100,000 غاز لكل حزمة، بالإضافة إلى عدة آلاف من الغاز لكل عملية مستخدم.
2. الحاجة إلى ضمان خصائص Ethereum: مثل ضمانات الإدراج التي أنشأتها قائمة الإدراج والتي يجب نقلها إلى مستخدمي تجريد الحسابات.

بالإضافة إلى ذلك، يوسع ERC-4337 وظيفتين:

• دافعي الرسوم (Paymasters): السماح لحساب بدفع الرسوم نيابة عن حساب آخر، وهذا ينتهك قاعدة أن مرحلة التحقق يمكنها فقط الوصول إلى حساب المرسل نفسه، لذا تم إدخال معالجة خاصة لضمان أمان آلية دافعي الرسوم.
• المجمعون (Aggregators): دعم تجميع التوقيعات، مثل تجميع BLS أو التجميع القائم على SNARK. هذا ضروري لتحقيق أعلى كفاءة بيانات على Rollup.

روابط الأبحاث الحالية

• محاضرة حول تاريخ تجريد الحسابات:
• ERC-4337:
• EIP-7702:
• كود BLSWallet (يستخدم ميزة التجميع):
• EIP-7562 (تجريد الحسابات المكتوب في البروتوكول):
• EIP-7701 (تجريد الحسابات المكتوب في البروتوكول القائم على EOF):

ما تبقى من العمل والمفاضلات

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

ما يميز هذه الطريقة هو أنها توضح بوضوح وجهتي نظر متكافئتين لتجريد الحسابات المحلي:

1. اعتبار EIP-4337 جزءًا من البروتوكول
2. نوع جديد من EOA حيث تكون خوارزمية التوقيع هي تنفيذ شيفرة EVM

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

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

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

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

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

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

تحسينات EIP-1559

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

تم تفعيل EIP-1559 في Ethereum في عام 2021، مما أدى إلى تحسين كبير في متوسط وقت تضمين الكتل.

وقت الانتظار

ومع ذلك، فإن تنفيذ EIP-1559 الحالي ليس مثاليًا في عدة جوانب:

1. الصيغة بها بعض العيوب: فهي لا تستهدف 50% من الكتل، بل تستهدف حوالي 50-53% من الكتل الممتلئة، وهذا يعتمد على التباين (وهذا مرتبط بما يسميه الرياضيون "متباينة المتوسط الحسابي والهندسي").
2. الضبط ليس سريعًا بما فيه الكفاية في الحالات القصوى.

الصيغة المستخدمة لاحقًا للـ blobs (EIP-4844) صممت خصيصًا لحل المشكلة الأولى، وهي أيضًا أكثر بساطة بشكل عام. ومع ذلك، لم يحاول كل من EIP-1559 وEIP-4844 حل المشكلة الثانية. لذلك، الوضع الحالي هو حالة وسطية فوضوية، تتضمن آليتين مختلفتين، وهناك رأي بأن كليهما يحتاج إلى تحسين مع مرور الوقت.

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

ما هو الغاز متعدد الأبعاد، وكيف يعمل؟

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

لدينا حاليًا غاز متعدد الأبعاد للتنفيذ وblobs؛ من حيث المبدأ، يمكننا توسيعه ليشمل أبعادًا أخرى: مثل calldata (بيانات المعاملات)، وقراءة/كتابة الحالة، وتوسيع حجم الحالة.

يقدم EIP-7706 بعدًا جديدًا للغاز مخصصًا لـ calldata. كما أنه يبسط آلية الغاز متعدد الأبعاد من خلال توحيد ثلاثة أنواع من الغاز في إطار عمل واحد (على غرار EIP-4844)، مما يحل أيضًا العيب الرياضي في EIP-1559. EIP-7623 هو حل أكثر دقة، يعالج مشكلة موارد الحالة المتوسطة والأسوأ بشكل أكثر صرامة، دون إدخال بعد جديد بالكامل.

اتجاه بحثي آخر هو حل مشكلة معدل التحديث، والبحث عن خوارزمية حساب رسوم أساسية أسرع، مع الحفاظ على المتغيرات الأساسية التي أدخلها EIP-4844 (أي: على المدى الطويل، يكون الاستخدام المتوسط قريبًا من القيمة المستهدفة).

روابط الأبحاث الحالية

• الأسئلة الشائعة حول EIP-1559: 
• تحليل تجريبي لـ EIP-1559: 
• اقتراحات تحسين لضبط أسرع: 
• جزء آلية الرسوم الأساسية في الأسئلة الشائعة حول EIP-4844: 
• EIP-7706: 
• EIP-7623: 
• الغاز متعدد الأبعاد: 

ما تبقى من العمل والمفاضلات؟

هناك مفاضلتان رئيسيتان للغاز متعدد الأبعاد:

1. زيادة تعقيد البروتوكول: إدخال الغاز متعدد الأبعاد يجعل البروتوكول أكثر تعقيدًا.
2. زيادة تعقيد الخوارزمية المثلى لملء الكتل: تصبح الخوارزمية المثلى لملء الكتل إلى السعة أكثر تعقيدًا.

تعقيد البروتوكول بالنسبة لـ calldata صغير نسبيًا، لكن بالنسبة لأبعاد الغاز داخل EVM (مثل قراءة وكتابة التخزين)، يزداد التعقيد. المشكلة هي أن المستخدمين لا يحددون فقط حدود الغاز، بل تحدد العقود أيضًا حدودًا عند استدعاء عقود أخرى. حاليًا، الطريقة الوحيدة لتحديد الحدود هي أحادية البعد.

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

المزيد من البحث حول الغاز متعدد الأبعاد سيساعد في فهم هذه المفاضلات، والعثور على نقطة التوازن المثالية.

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

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

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

الدوال المؤجلة القابلة للتحقق (VDFs)

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

حاليًا، يستخدم Ethereum عشوائية قائمة على RANDAO لاختيار المقترحين، حيث تعمل عشوائية RANDAO من خلال مطالبة كل مقترح بالكشف عن سر التزم به مسبقًا، وخلط كل سر مكشوف في العشوائية.

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

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

الدالة المؤجلة القابلة للتحقق هي دالة لا يمكن حسابها إلا بشكل تسلسلي، ولا يمكن تسريعها من خلال التوازي. مثال بسيط هو التجزئة المتكررة: for i in range(10**9): x = hash(x). النتيجة، مع إثبات SNARK لصحتها، يمكن استخدامها كقيمة عشوائية.

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

الخطر الرئيسي في VDF هو التحسين غير المتوقع: أن يجد شخص ما طريقة لتشغيل الدالة بسرعة أكبر من المتوقع، وبالتالي التلاعب بالمعلومات التي يكشفها في الوقت T.

يمكن أن يحدث التحسين غير المتوقع بطريقتين:

1. تسريع الأجهزة: أن يصنع شخص ما ASIC أسرع من الأجهزة الحالية لتنفيذ الحلقة الحسابية.
2. التوازي غير المتوقع: أن يجد شخص ما طريقة لتشغيل الدالة بشكل متوازي بسرعة أكبر، حتى لو تطلب ذلك 100 ضعف الموارد.

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

روابط الأبحاث الحالية

• موقع أبحاث VDF: 
• تفكير حول الهجمات على VDF في Ethereum، 2018: 
• هجمات على VDF MinRoot المقترحة: 

ما تبقى من العمل والمفاضلات؟

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

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

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

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

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

التعتيم والتوقيعات لمرة واحدة: مستقبل التشفير البعيد

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

إحدى أشهر مقالات Nick Szabo هي ورقته حول "بروتوكول الإله" التي كتبها عام 1997. في هذه الورقة، أشار إلى أن العديد من التطبيقات متعددة الأطراف تعتمد على "طرف ثالث موثوق" لإدارة التفاعل. في رأيه، دور التشفير هو إنشاء طرف ثالث موثوق محاكى، يؤدي نفس العمل، دون الحاجة إلى الثقة بأي مشارك معين.

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

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

في العقد الثاني من القرن الحادي والعشرين، لمحت لأول مرة إلى طريقة مختلفة وأقوى، تعتمد على التشفير القابل للبرمجة. بدلاً من إنشاء بروتوكول جديد لكل تطبيق، يمكننا استخدام بروتوكولات قوية جديدة — وتحديدًا ZK-SNARKs — لإضافة ضمانات تشفيرية لأي برنامج.

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

ومع ذلك، فإن ZK-SNARKs هي واحدة فقط من ثلاث أدوات عامة قوية للغاية من هذا النوع. هذه البروتوكولات قوية لدرجة أنها تذكرني بمجموعة من البطاقات القوية جدًا في لعبة Yu-Gi-Oh التي كنت ألعبها في طفولتي: بطاقات الآلهة المصرية.

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

ما هي ZK-SNARKs، وكيف تعمل؟

ZK-SNARKs هي واحدة من البروتوكولات الثلاثة التي نمتلكها بالفعل، وهي ناضجة نسبيًا. في السنوات الخمس الماضية، أدى التحسن الكبير في سرعة المُثبِت وملاءمة المطورين إلى جعل ZK-SNARKs حجر الزاوية في استراتيجية قابلية التوسع والخصوصية في Ethereum. لكن لدى ZK-SNARKs قيدًا مهمًا: يجب أن تعرف البيانات لتثبتها. يجب أن يكون لكل حالة في تطبيق ZK-SNARK مالك وحيد يجب أن يكون حاضرًا للموافقة على القراءة أو الكتابة.

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

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

Cursive هو تطبيق يستخدم الحوسبة الثنائية والتشفير المتماثل بالكامل (FHE) لاكتشاف الاهتمامات المشتركة مع الحفاظ على الخصوصية.

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

التالي هو البروتوكول الثالث، وهو أقوى من الاثنين السابقين مجتمعين: التعتيم غير القابل للتمييز (indistinguishability obfuscation). على الرغم من أن هذه التقنية لا تزال بعيدة عن النضج، إلا أننا منذ عام 2020 لدينا بروتوكولات فعالة نظريًا تعتمد على افتراضات أمان قياسية، وبدأنا مؤخرًا في تنفيذها.

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

الشيء الوحيد الذي لا يمكن أن يفعله برنامج التعتيم غير القابل للتمييز هو منع نفسه من النسخ. ومع ذلك، هناك تقنيات أقوى في الأفق لهذا الغرض، رغم أنها تعتمد على امتلاك الجميع لحاسوب كمي: التوقيعات الكمية لمرة واحدة (quantum one-shot signatures).

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

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

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

بعد ذلك، نضيف ZK-SNARKs، والآن لدينا الخصوصية: كل صوت مجهول، مع ضمان أن الناخبين المصرح لهم فقط يمكنهم التصويت، ولا يمكن لكل ناخب التصويت إلا مرة واحدة.

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

نقوم بعد ذلك بتشغيل العد في FHE، ثم إجراء فك تشفير عتبة N/2-of-N. هذا يجعل ضمان مقاومة الإكراه يصل إلى N/2-of-N، بدلاً من 1-of-1.

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

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

يدعم التعتيم غير القابل للتمييز تطبيقات قوية أخرى، مثل:

1. المنظمات المستقلة اللامركزية (DAOs)، والمزادات على السلسلة، وغيرها من التطبيقات ذات الحالة السرية الداخلية العامة.
2. إعداد ثقة عام حقيقي: يمكن لشخص ما إنشاء برنامج معتم يحتوي على مفتاح، وتشغيل أي برنامج وتقديم المخرجات، مع وضع hash(key, program) كمدخل في البرنامج. يمكن لأي شخص بعد ذلك وضع البرنامج 3 في نفسه، ودمج المفتاح المسبق للبرنامج مع مفتاحه الخاص، لتوسيع الإعداد. يمكن استخدام ذلك لإنشاء إعداد ثقة 1-of-N لأي بروتوكول.
3. التحقق من ZK-SNARKs يتطلب فقط توقيعًا واحدًا: يتم ذلك بسهولة عن طريق إعداد بيئة موثوقة، حيث ينشئ شخص ما برنامجًا معتمًا يوقع الرسائل باستخدام المفتاح فقط في حالة وجود ZK-SNARK صالح.
4. ذاكرة مؤقتة مشفرة: تصبح المعاملات المشفرة سهلة التنفيذ، بحيث لا يمكن فك تشفير المعاملة إلا عند حدوث حدث معين على السلسلة في المستقبل. يمكن أن يشمل ذلك حتى تنفيذ دالة مؤجلة قابلة للتحقق (VDF) بنجاح.

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

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

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

• بروتوكول التعتيم غير القابل للتمييز (2021): 
• كيف يساعد التعتيم Ethereum: 
• أول بناء معروف للتوقيعات لمرة واحدة: 
• محاولة تنفيذ التعتيم (1): 
• محاولة تنفيذ التعتيم (2): 

ما العمل المتبقي، وما هي المفاضلات؟

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

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

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

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

قد يغير التشفير القوي للغاية قواعد اللعبة، مثل:

1. إذا أصبح التحقق من ZK-SNARKs سهلاً مثل التوقيع، فقد لا نحتاج إلى أي بروتوكولات تجميع؛ يمكننا التحقق مباشرة على السلسلة.
2. قد تعني التوقيعات لمرة واحدة بروتوكولات إثبات حصة أكثر أمانًا.
3. قد يتم استبدال العديد من بروتوكولات الخصوصية المعقدة بآلة Ethereum الافتراضية (EVM) واحدة تحمي الخصوصية.
4. تصبح الذاكرة المؤقتة المشفرة أسهل في التنفيذ.

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