نصائح للقراءة

· قبل قراءة هذه المقالة، تحتاج إلى فهم أساسي لـ MEV

· كن على دراية بمعاملات الإيثيريوم وفهم ما تحتويه المعاملة وكيف يتم تضمينها في الكتلة

· تعرف على شجرة Merkle ودور دليل الصفر المعرفة

· انقر للقراءة: MEV (5): نظام بيئي أكثر عدالة ل MEV (الجزء 1)

قدم المقال السابق (1) تصميم Flashbot SGX Builder، الذي يزيد من عدالة Block Builder من خلال الأجهزة الموثوقة، و (2) تصميم Chainlink FSS، الذي يمنع MEV من خلال تمزيق أدوار ترتيب المعاملات.

سيناقش هذا المقال تصميم Encrypted Mempools (3)، الذي يهدف إلى تقليل أو القضاء على MEV من خلال توفير الخصوصية للمعاملات من خلال الأساليب التشفيرية.

الحواضن المشفرة

هدفان: حماية MEV ومقاومة الرقابة

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

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

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

تأكد من أن يمكن فك تشفير المعاملات (التشفير المضمون)

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

هناك بعض الطرق لضمان أن يمكن فك تشفير المعاملات:

1. ثقة نقية (في الطيران)

2. الأجهزة الموثوق بها، المحيط الآمن

3. التشفير/فك التشفير العتبة

4. تأخير التشفير/فك التشفير

5. تشفير / فك تشفير الشاهد

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

مصدر الصورة:https://www.youtube.com/watch?v=XRM0CpGY3sw

التزام-كشف

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

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

△ يعد المقترح بتلقي التزام معاملة أليس

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

يمكن أن يؤدي إلزام المستخدمين بإرفاق إيداع ومصادرة الإيداع عندما ينتهي الأمر بعدم وجود إظهار إلى تفاقم تجربة المستخدم السيئة بالفعل لـ Commit-reveal.

△ لا تحتاج أليس إلى الكشف عن معاملتها

الثقة الصافية (في الطيران)

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

نصيحة القراءة: سيكون هذا الدور المركزي، على سبيل المثال، Builder أو Proposer أو Sequencer/Operator لـ PBS أو Rollup.

2.الحدائد الإلكترونية الموثوق والمجاد

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

3. تشفير / فك تشفير الحد

يستخدم Chainlink FSS أيضًا تشفير وفك تشفير الحد الأدنى، ولكن في Chainlink FSS مديرو مفاتيح الحد الأدنى هم Oracles of Chainlink، بينما في Encrypted Mempools قد يكون مديرو (يُسمون Keypers) Validators of L1 أو L2 (بشرط أن يكون L2 لديه أيضًا في حالة Validator مُفcentralized).

عملية تشفير / فك تشفير الحد الأدنى لها عدة عيوب:

• افتراض الغالبية الصادقة القوية: يجب أن يُفترض أن أكثر من نصف الحفّاظ صادقون. إذا كانوا غير صادقين، فيمكنهم فك تشفير ورؤية معاملات المستخدمين حسب الإرادة، ومراجعة المعاملات، أو استخراج MEV من المعاملات.
• نقص في المساءلة: طالما أن عددا كافيا من المشاركين في Keyper يتعاونون، يمكنهم فك تشفير المعلومات. ومع ذلك، عندما يتآمرون المشاركون في Keyper، ليس لدينا وسيلة لمعرفة الذين شاركوا في المؤامرة. بدون القدرة على تحديد الأطراف الخبيثة، من المستحيل تصميم آلية عقوبة لـ Keyper. لذلك، يجب أن نعتمد على افتراض أن غالبية المشاركين في Keyper صادقون.
• ضعف الحيوية: سيؤدي تعطل Keyper الزائد إلى عدم كفاية عدد Keyper على الإنترنت، مما سيمنع فك التشفير وإنتاج الكتل. وهذا سيؤدي إلى توقف السلسلة. هذا يتعارض مع آلية Ethereum PoS، التي تشدد على أن السلسلة ستستمر في إنتاج الكتل حتى في حالة حدوث حرب عالمية ثالثة، وفي النهاية تحقيق النهوض بالأمر. يمكن استنتاج أن احتمالية استخدام Ethereum PoS للفك التشفير بحد أعلى ليست مرتفعة.

نظرًا لأن تشفير وفك تشفير الحد الأدنى يتطلب العديد من التغييرات، L2 أكثر مناسبة لهذا النهج من L1.

يقترح هذا المقال التصميم والاعتبارات للتنفيذ في L1. يمكن للمشاريع التي تختبر هذا التصميم الرجوع إلى شبكة Shutter. لمزيد من المعلومات، يرجى التحقق:https://ethresear.ch/t/shutterized-beacon-chain/12249

4. تأخير التشفير / فك التشفير

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

المفهوم الذي يقف وراء تشفير التأخير مشابه لوظيفة التأخير القابلة للتحقق (VDF)، وكلاهما ينتمي إلى عائلة التشفير الزمني.

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

△ مع VDF يمكنك التحقق من نتيجة حساب أنجزته في 10 ثوانٍ، على سبيل المثال، في 0.01 ثانية، ولم يكن لدي وسيلة لتوازي حسابي. المصدر: الصورةhttps://techtelegraph.co.uk/وظائف-تأخير-قابلة-للتحقق-على-بيتكوين

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

حاليًا، تعاونت مؤسسة Ethereum وProtocol Labs بالفعل في بحث رقاقة VDF ASIC، على أمل تصدير أحدث أجهزة الحوسبة إلى السوق، بحيث لا يمكن لأحد الحصول على مزايا معدات مختلفة وفك تشفير سريًا مسبقًا. لمعرفة المزيد، يرجى التحقق: https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

نصيحة القراءة: يمكن أيضًا استخدام VDF لزيادة عدم قابلية التلاعب في الأرقام العشوائية لـ Ethereum.

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

5. تشفير / فك تشفير الشاهد

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

نصيحة قراءة: "معرفة مفتاح فك تشفير النص المشفّر" أو "معرفة نتائج الحسابات المستمرة" هي في الواقع شرط.

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

يمكن فك تشفير ما يكفي من Keypers عبر الإنترنت (أعلاه) أو بعد مرور وقت كافٍ (أدناه)

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

△ نضوج تقنيات التشفير وفك التشفير المختلفة. تقنية تشفير وفك تشفير الشاهد (الشاهد) ليست ناضجة بما فيه الكفاية. مصدر الصورة: https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

التلاعب والقيام بعمليات على النص المشفر من خلال التشفير التشريحي

الفقرات السابقة قد قدمت طرقًا مختلفة لضمان أن يمكن فك تشفير المعاملات، ولكن متى يمكن فك تشفير المعاملات؟ الإجابة هي: بعد تضمين المعاملة في الكتلة وتحديد الترتيب. ولكن كيف يقوم بناء الكتلة بتجميع كتلة من حفنة من الكلام اللغوي، أو حتى بتجميع كتلة مربحة بشكل كبير؟ الإجابة هي: التشفير الهومومورفي (HE).

△ مثال على التشفير المتجانس المستخدم للتصويت: تم تشفير محتوى التصويت، ولكن يمكن للنص المشفر ما زال يمكن جمعه وفك تشفيره بعد حساب النتيجة. مصدر الصورة:https://twitter.com/khushii_w/status/1660278622291210242

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

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

△ من خلال التشفير المتجانس، يمكن لمنشئ الكتلة أن يجمع بلوك كامل وقانوني من المعاملات المشفرة

نصيحة القراءة: هناك مستويات من التشفير المتجانس، مثل التشفير المتجانس جزئيًا (Partially HE) والتشفير المتجانس بالكامل (Fully HE). يمكن للتشفير المتجانس جزئيًا إضافة أو ضرب النص المشفر فقط، بينما يمكن للتشفير المتجانس بالكامل إضافة وضرب النص المشفر (بشكل أساسي، يمكن تنفيذ أي عملية).

△ العمود الثالث: نضوج تقنيات التشفير وفك التشفير المختلفة التي تدعم FHE. باستثناء في الطيران والحظيرة، التي لا تتطلب HE وبالتالي تعتبر مدعومة، الأخرى ليست متاحة بعد. مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

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

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

تأكد من عدم تسرب البيانات الوصفية للخصوصية

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

1. عنوان IP

2. توقيع المعاملة

3. رسوم المعاملات

4. المبادر للمعاملة وقيمتها Nonce

5. حجم المعاملة

△ البيانات الوصفية المختلفة للمعاملات قد تكشف خصوصية المستخدم. مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

عنوان IP

قد تكشف الشبكة التي يتصل بها المستخدم لإرسال المعاملات المشفرة عن هوية المستخدم استنادًا إلى عنوان IP الخاص بالمستخدم وقد تتم مراقبته. تعتمد حماية الخصوصية على مستوى الشبكة على تقنيات مثل Tor.

توقيع المعاملة، رسوم الإجراءات، مبادر المعاملة وقيمتها غير القابلة للتكرار

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

عندما يتلقى العقد معاملة مشفرة ، يجب (1) التحقق أولاً من أن مبادر المعاملة قام فعليًا ببدء المعاملة ، أي التحقق من توقيع المعاملة ، ثم (2) التأكد من أن المبادر لديه ما يكفي من ETH لدفع المعاملة (رصيد المستخدم ≥ سعر الغاز * حد الغاز) ، و (3) التحقق من قيمة nonce المرسل لتجنب هجمات إعادة البث للمعاملات.

دليل الصفر المعرفة

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

△ على سبيل المثال ، المعلومات العامة (الإدخال العام) هي معاملة مشفرة (نص مشفر tx) ، والمعلومات الخاصة (شاهد خاص) هي معاملة غير مشفرة (نص مشفر tx) ، والبيان (بيان zk) الذي يجب إثباته بواسطة دليل المعرفة الصفرية هذا هو "هذا" المعاملات المشفرة قانونية "(النص المشفر tx صالح). مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

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

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

لا يمكن الكشف عن العنوان والتوقيع وإثبات Merkle وهي معلومات خاصة (شاهد خاص).

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

المعلومات الوحيدة التي يعرفها بوب هي المعلومات العامة عن جذر الحالة ونتائج التحقق. لن يعرف أيًا من معلومات أليس الخاصة.

△ تقدم أليس مدخلين خاصين: دليل ميركل وتوقيع. يقدم بوب المدخل العام لجذر الحالة. يمكن للبيان zk التحقق من أن أليس لديها عنوان وأن رصيد العنوان هو > 10 ETH

(1) التحقق من توقيع المعاملة

تتكون التحقق من توقيع المعاملة من جزأين: (أ) مبادر المعاملة شرعي و (ب) تم توقيع توقيع المعاملة بواسطة مبادر المعاملة.

(a) بشكل رئيسي للتحقق من أن عنوان الإيثيريوم لمبادر المعاملة هو عنوان قانوني وليس رقم عشوائي. سيثبت هذا من خلال دليل ميركل أن العنوان موجود في شجرة حالة الإيثيريوم.

(b) يتحقق من أن توقيع المعاملة موقع بمفتاح المعاملة المبادل.

△ يتحقق هذا الدليل (أ) عنوان مبدأ عملية النقل (عبر دليل Merkle pubkey للمرسل) و (ب) أن التوقيع داخل العملية النقدية شرعي (سيتم تضمين التوقيع في نص عملية النقل). نص عملية النقل هو البيانات الأساسية غير المشفرة للعملية النقدية، والتي تعتبر معلومات خاصة تم تقديمها من قبل مبادر العملية النقدية.

Image source:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

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

△ أثبت أن عنوان مبادلة المبادلة موجود في شجرة الحالة الخاصة بـ Ethereum وأن المبادل الفعلي لديه فعلاً مفتاح خاص للمكان

(2) تأكد من أن بادئ المعاملة لديه ما يكفي من ETH لدفع رسوم المناولة

تمامًا مثل المثال السابق حول أليس وبوب يثبتان أن الرصيد أكبر من 10 إيث، يحتاج مبادر العملية إلى تقديم دليل ميركل على رصيد عنوانه الخاص، والبيان المراد إثباته هو 'رصيد العنوان ≥ رسوم المعاملة'. تعادل رسوم المعاملة سعر الغاز مضروبًا بحد الغاز. تتضمن معلومات كل من سعر الغاز وحد الغاز في البيانات الأصلية للمعاملة غير المشفرة (tx plaintext). tx plaintext هو معلومات خاصة تقدمها مبادر المعاملة.

△ يتحقق هذا الإثبات من أن رصيد عنوان بادئ المعاملة (عبر إثبات Merkle لرصيد المرسل) أكبر من أو يساوي رسوم المعاملة (يتم تضمين معلومات رسوم المعاملة في النص العادي tx). مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ أثبت رصيد عنوان مبدأ المعاملة > سعر الغاز

(3) تحقق من قيمة Nonce لبادئ المعاملة

لأن الرقم التعريفي أيضًا مُسجل في حالة Ethereum، يُستخدم أيضًا دليل Merkle لإثبات قيمة الرقم التعريفي الحالي لمبادر المعاملة، ثم مقارنته مع قيمة الرقم التعريفي المحددة في المعاملة لتأكيد أن المعاملة لم تُعاد بثها.

△ يقارن هذا الدليل قيمة الـ Nonce لعنوان مبادرة الصفقة (من خلال دليل Merkle الخاص بالـ nonce) وقيمة الـ Nonce المحددة بواسطة الصفقة (تتضمن قيمة الـ Nonce المحددة بواسطة الصفقة في نص الصفقة). مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ إثبات nonce لعنوان بادئ المعاملة = tx nonce

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

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

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

△ سيقوم هذا الدليل بحساب علامة الإعادة ومقارنتها مع علامة الإعادة الممررة من قبل الإدخال العام. قيمة العدم للمعاملة موجودة في نص tx، والمفتاح الخاص موجود في الشاهد الخاص.

مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ إثبات nonce لعنوان مبادلة المبادلة = tx nonce وعلامة إعادة التشغيل = H(nonce, key)

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

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

△ ستمر الإدخال العام في قيم فتحة إضافية لحساب علامة الإعادة. مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5. حجم المعاملة

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

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

△ الأبيض هو التبطين. صفقات اللون الأزرق والبرتقالي هي نفس الحجم، لذلك لا يمكن التمييز بينهما بناءً على الحجم. مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

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

△ العيب هو عدم الكفاءة والحماية المحدودة للخصوصية. مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

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

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

△ استخدم التشفير المتجانس لإزالة التبطين أثناء دمج المعاملات المشفرة. المصدر: الصورةhttps://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

قراءة النصيحة: يمكن للبناء الكتلي مع الثقة النقية أو الأجهزة الموثوقة تحقيق نفس التأثير بدون التشفير المتجانس (بعد كل شيء، الجميع يثق بها).

كيف يبني Block Builder كتلًا فعالة

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

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

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

△ يتم تحديدها بواسطة رسوم الاستخدام وقائمة الوصول التي يتم جمع المعاملات وترتيبها وفقًا لها. مصدر الصورة:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

الوقت الذي يحدث فيه الصفقة

إذا كنا قلقين من أن الوقت الذي يتم فيه إرسال المعاملات المشفرة إلى شبكة الند للند قد يتسرب الخصوصية (على سبيل المثال، إذا كانت أليس تُجري معاملات في توقيت عالمي منطقة +8 منتصف الليل إلى الساعة 04:00)، يمكننا أن نطلب من المحققين إرسال مجموعة من المعاملات الوهمية المشفرة بانتظام للخلط في عقل المراقب.

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

سيتم تحديد المعاملة الوهمية وتجاهلها أثناء عملية التشفير المتجانس لكتلة المجموعة.

△ يقوم المدققون بانتظام بإرسال المعاملات الوهمية (الرمادية) لإرباك المراقبين، ولكن ذلك سيزيد من العبء على الشبكة والعقد. المصدر: الصورةhttps://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

مسابير مشفرة ضد FSS

كما أشارت FSS في المقال السابق إلى أن FSS ستقوم أيضًا بتشفير المعاملات أولاً ثم تسليمها إلى Chainlink Oracle للفرز. عملية تشفير FSS للمعاملات والتحقق من صحة المعاملات المشفرة هي في الواقع نفسها كما في Encrypted Mempools، باستثناء:

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

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

مواجهة MEV بالتشفير

يتحدث هذا الحديث عن مجموعات الذاكرة المشفرة، حيث يشارك الكاتب كيف يمكن أن تساعد تقنيات التشفير والتحسينات في طبقة الاتفاق على الإيثيريوم في مكافحة المشاكل التي تسببها MEV. للتفاصيل، يرجى التحقق من: https://www.youtube.com/watch?v=mpRq-WFihz8

ملخص وأبرز النقاط

1. غرض المجموعات الشبكية المشفرة هو حماية ضد MEV والرقابة عن طريق تشفير المعاملات. يمكن للآخرين أن يعرفوا فقط أن معاملاتك صالحة، ولكنهم لا يمكنهم معرفة الإجراءات التي تقوم بها ضمن معاملاتك.

2. ومع ذلك، لتحقيق مقاومة فعالة حقًا للرقابة، يجب استخدام آلية مثل قائمة الاستثناءات في PBS. وإلا، يمكن للمُنشئ ما زال القيام بالرقابة عن طريق رفض استقبال المعاملات المُشفرة.

3. ليس من السهل إثبات أن المعاملة المشفرة صالحة. تحتاج إلى عدة دلائل بدون معرفة لإثبات توقيع المعاملة، قيمة الـ Nonce لمبادل المعاملات، رسوم التعامل الكافية، إلخ.

4. بالإضافة إلى ذلك، من الضروري تجنب تسرب البيانات الوصفية مثل عنوان IP، حجم بيانات المعاملة أو وقت إرسال المعاملة الخاص بخصوصية المعاملة.

5. وأخيرًا، الأمر الأهم هو ضمان أن يمكن فك تشفير المعاملات —— تشفير مضمون. هناك خمس طرق مختلفة: الثقة النقية (في الرحلة)، الحواجز الأمنية الموثوقة، تشفير/فك تشفير العتبة، تأخير التشفير/الفك، وشاهد تشفير/فك تشفير. كل طريقة لها مزايا وعيوبها الخاصة.

البيانات المرجعية والقراءة الموصى بها

مجموعات الذاكرة المشفرة

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• كيف تساعد علم التشفير في حل المشاكل الناجمة عن MEV من طبقة التطبيق وطبقة الاتفاق:https://youtu.be/jLHf6yw7b5Y?t=4139

شكر خاص لستيفن وو، كيمي وو، كيفن ماي-هسوان تشيا، وأنطون تشنغ على مراجعة وتحسين هذا المنشور.

تنصل:

1. تم نشر هذا المقال مرة أخرى من [Gatetechflowpost]. جميع حقوق النشر تنتمي إلى الكاتب الأصلي [سوف 阿望؛ ديان تشيونغ]. إذا كانت هناك اعتراضات على هذه الإعادة، يرجى التواصل معبوابة تعلمفريقنا، وسيتولى التعامل معها على الفور.
2. تنصل المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك التي تنتمي إلى الكاتب ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يذكر غير ذلك، يُمنع نسخ أو توزيع أو نسخ المقالات المترجمة.