في بيئة البلوكشين العامة لـ ويب3، كانت الشفافية دائمًا إحدى خصائصها المميزة. بعد أن يرسل المستخدم معاملة، فإنها تدخل عادةً إلى Mempool، حيث تنتظر المدققين أو منتجي الكتل لترتيبها وإدراجها في كتلة. وقبل تنفيذ المعاملة فعليًا، يمكن للمراقبين على الشبكة غالبًا الاطلاع على بعض معلوماتها أو جميعها، بما في ذلك العقد الذي يتم استدعاؤه، ومعلمات الاستدعاء، والأصول المعنية، وحجم المعاملة. تتيح الرؤية العامة التحقق، لكنها تكشف أيضًا استراتيجيات التداول أمام الباحثين وروبوتات المراجحة وغيرهم من المشاركين في السوق.
تكتسب هذه الشفافية أهمية خاصة في DeFi. فقد يرغب المستخدم ببساطة في إجراء مبادلة أو تعديل مركز أو إرسال عملية معقدة على السلسلة. لكن قبل تنفيذ المعاملة، يستطيع مشاركون آخرون بالفعل ملاحظة نية المستخدم واتخاذ إجراءات بناءً على تلك المعلومات. ونتيجة لذلك، ظلّت السبق في تنفيذ المعاملات، وهجمات الساندويتش، والمشكلة الأوسع للقيمة القصوى القابلة للاستخراج (MEV)، من المشكلات المهمة التي يجب أن تعالجها البنية التحتية للتداول على السلسلة.
يقوم مفهوم Mempool المشفّر على إضافة طبقة من الحماية التشفيرية إلى محتوى المعاملة بعد دخولها إلى Mempool وقبل إتمام الكتلة. يشفّر المستخدم حمولة المعاملة على جانب العميل، ثم تدخل المعاملة إلى Mempool بصيغة نص مشفّر وتبقى مخفية أثناء ترتيب المعاملات. ولا يقوم المدققون بفك تشفيرها وتنفيذها بشكل مشترك إلا بعد وصول الكتلة إلى الإجماع. ونشرت Aptos بروتوكول Mempool مشفّرًا أصليًا على الشبكة الرئيسية في أكتوبر 2026، وصممته كميزة يمكن تفعيلها لكل معاملة على حدة.
والأهم من ذلك، أن Mempool المشفّر لا يتعلق ببساطة بـ «إخفاء المعاملات». بل يعيد تعريف رؤية المعلومات بصورة جوهرية طوال دورة حياة معاملة البلوكشين: من يمكنه رؤية المعاملة، ومتى يمكنه رؤيتها، ومن المسؤول عن ترتيبها، ومن المسؤول عن فك تشفيرها، وكيف يمكن الحفاظ على قابلية التحقق العامة مع الحد من تسرب نية المعاملة. وبالنسبة إلى ويب3، يجعل ذلك من Mempool المشفّر اتجاهًا تقنيًا مهمًا يربط بين خصوصية المعاملات والحماية من MEV وتصميم البنية التحتية للبلوكشين.
لفهم Mempool المشفّر، تحتاج أولًا إلى فهم دور Mempool في البلوكشين. بعد أن يرسل المستخدم معاملة، لا تصبح فورًا جزءًا من الكتلة النهائية. بل تدخل أولًا إلى مجمع معاملات في انتظار المعالجة. يختار المدققون أو منتجو الكتل المعاملات المعلقة ويرتبونها، ثم يستخدمون الإجماع لإدراجها في كتلة. لذلك، يمكن فهم Mempool باعتباره طبقة وسيطة مهمة بين «إرسال المستخدم» و«تأكيد الكتلة».
تتمثل السمة الأساسية لـ Mempool العام التقليدي في الرؤية العالية لمحتوى المعاملات. بعد أن يوقّع المستخدم معاملة ويبثها، يستطيع المشاركون الآخرون في الشبكة ملاحظة المعلومات ذات الصلة وتحليل نيتها قبل تنفيذ المعاملة رسميًا. على سبيل المثال، قد تكشف مبادلة كبيرة عن الأصل الذي يستعد المستخدم لشرائه أو بيعه، بينما قد تكشف عملية DeFi معقدة عن الاستراتيجية التي ينفذها المستخدم. وبالنسبة إلى الباحثين المؤتمتين، يمكن أن تشكل هذه المعلومات أساسًا لاتخاذ إجراءات مسبقة.
يغيّر Mempool المشفّر مستوى رؤية المعلومات خلال هذه المرحلة. عند استخدام هذه الآلية، يشفّر المستخدم أولًا حمولة المعاملة على جانب العميل، ثم يرسل المعاملة المشفّرة إلى الشبكة. بعد دخول المعاملة إلى Mempool، يظل بإمكان منتجي الكتل رؤية معلومات الحساب والرسوم الضرورية، لكنهم لا يستطيعون قراءة الوظائف التي يتم استدعاؤها أو المعلمات المحددة مباشرةً. يمكن ترتيب المعاملة مع بقائها مشفّرة، ثم تدخل مرحلة فك التشفير والتنفيذ بعد إتمام الكتلة. تستخدم Aptos حاليًا هذا التدفق للمعاملات.
لذلك، لا يخفي Mempool المشفّر المعاملات بشكل دائم. بل يؤخر النقطة التي يصبح عندها «محتوى المعاملة عامًا» إلى مرحلة لاحقة. ولا يزال من الممكن في النهاية تسجيل المعاملات على السلسلة والتحقق منها علنًا. لكن قبل إتمام المعاملة، لم يعد بإمكان المراقبين الوصول إلى نيتها الكاملة مسبقًا. يجعل هذا التصميم Mempool المشفّر أقرب إلى آلية لـ «خصوصية ما قبل التنفيذ» منه إلى نظام معاملات مجهول الهوية تقليدي.

لا يكمن مفتاح Mempool المشفّر في استخدام مفتاح تشفير عادي فحسب. بل يجب أن يحل مشكلة أكثر تعقيدًا: إذا كانت جهة واحدة فقط تمتلك القدرة على فك تشفير المعاملات، فقد تصبح تلك الجهة نفسها مصدرًا جديدًا لمخاطر الثقة. لذلك، يحتاج البروتوكول إلى توزيع قدرات فك التشفير بين عدة مدققين، مع منع أي مدقق فردي من قراءة المعاملات مسبقًا.
تستخدم Aptos حاليًا آلية التشفير العتبي. يحصل المستخدم على مفتاح التشفير العام الموافق للحقبة الحالية، ويشفّر حمولة المعاملة ويرسلها. بعد دخول المعاملة إلى Mempool، يمكن لقائد الكتلة المشاركة في ترتيب المعاملات، لكنه لا يستطيع معرفة الوظائف التي تستدعيها المعاملة أو المعلمات التي تحتويها. ولا يعيد المدققون معًا تكوين قدرة فك التشفير ويسمحون للمعاملة بدخول مرحلة التنفيذ إلا بعد وصول الكتلة إلى الإجماع.
هنا، تعني «العتبة» أن قدرات فك التشفير موزعة بين عدة مدققين. ووفقًا لتصميم Aptos، لا يستطيع مدقق واحد فك تشفير المعاملات المعلقة بشكل مستقل، كما لا تستطيع مجموعة فرعية من المدققين تسيطر على أقل من ثلثي الحصة الصادقة على السلسلة إتمام عملية فك التشفير. بعبارة أخرى، تتوافق الأغلبية المرجحة بالحصة المطلوبة لتفعيل فك التشفير مع افتراضات أمان الإجماع التي تعتمد عليها Aptos لإنتاج الكتل.
تكمن القيمة الأساسية لهذا التصميم في أنه يتجنب إدخال «حارس بوابة» مركزي مخصص فقط لخصوصية المعاملات. فإذا كان يجب تسليم المعاملة أولًا إلى مرحّل خاص أو منشئ خارجي أو لجنة خارجية لفك التشفير، فإن المستخدم ينقل الثقة فعليًا من مدققي البلوكشين إلى مؤسسة أخرى. أما التشفير العتبي الأصلي للبروتوكول، فيسعى بدلًا من ذلك إلى إرساء خصوصية المعاملات مباشرةً على نظام المدققين والإجماع الخاص بالبلوكشين.
وهذا مهم بصفة خاصة من منظور فلسفة تصميم ويب3. فالخصوصية لا تتعلق فقط بـ «عدم قدرة أي شخص على رؤية أي شيء». بل تتضمن أيضًا التساؤل: «هل يتعين عليّ الوثوق بطرف مركزي جديد للحصول على الخصوصية؟». ويعد الحفاظ على اتساق حماية الخصوصية قدر الإمكان مع نموذج أمان الإجماع الحالي أحد المجالات الأساسية التي تستكشفها Mempools المشفّرة.
أحد المصادر المهمة لـ MEV هو نافذة الرؤية الموجودة قبل تنفيذ المعاملة. فعندما تُبث معاملة المستخدم لكنها لم تدخل الكتلة النهائية بعد، يستطيع الباحثون تحليل محتواها ومحاولة تحقيق ربح عبر إعادة ترتيب المعاملات أو إدراج معاملات أو تعديل موضع معاملاتهم الخاصة.
على سبيل المثال، في مجمع معاملات عام، قد تكشف مبادلة كبيرة عن اتجاه تداول واضح. وبعد اكتشاف المعاملة، قد يحاول روبوت شراء الأصل ذي الصلة مسبقًا، ثم السماح لمعاملة المستخدم بتحريك السعر، ثم إتمام معاملة عكسية. هذا هو المفهوم النموذجي وراء السبق في تنفيذ المعاملات وهجمات الساندويتش. وبالنسبة إلى المستخدمين، قد لا تنبع المشكلة من العقد الذكي نفسه، بل من بنية المعلومات التي تجعل «نية المعاملة معلنة مسبقًا».
لا يقضي Mempool المشفّر على MEV مباشرةً. بل يقلل أحد مصادر المعلومات التي تعتمد عليها أنواع معينة من MEV. فعندما تظل حمولة المعاملة مشفّرة خلال مرحلة الترتيب، لا يستطيع الباحثون معرفة الوظيفة التي يستدعيها المستخدم، أو الأصول التي يجري تداولها، أو المعلمات المستخدمة مسبقًا. وهذا يحد من فرص اتخاذ مراكز مسبقة استنادًا إلى محتوى المعاملة. وتحدد Aptos أيضًا الحد من السبق في تنفيذ المعاملات وهجمات الساندويتش وتسرب قيمة المعاملات باعتبارها مجالات تطبيق مهمة لهذه الآلية.
ومع ذلك، من المهم تجنب مفهوم خاطئ شائع: لا يعني Mempool المشفّر أن جميع أشكال MEV ستختفي. فلـ MEV مصادر عديدة، بما فيها ترتيب الكتل وعمليات التصفية والمراجحة وعوامل أخرى مرتبطة ببنية السوق. وإذا كان أحد أشكال MEV لا يعتمد على أن تكون حمولة المعاملة مرئية علنًا قبل التنفيذ، فإن مجرد إخفاء محتوى المعاملة لن يقضي عليه. وبصورة أدق، يقلل Mempool المشفّر بالأساس من MEV القائم على ملاحظة محتوى المعاملات المعلقة والتصرف بناءً عليه مسبقًا.
وهذا ما يميزه أيضًا عن آليات الحماية التقليدية من MEV. إذ يمكن لـ RPCs الخاصة ومنشئي المعاملات الموثوقين وبيئات التنفيذ الموثوقة (TEEs) ولجان المفاتيح الخارجية أيضًا الحد من تسرب محتوى المعاملات، لكن كل منها يرتبط بنموذج ثقة مختلف. ويركز Mempool المشفّر على وضع هذه الحماية مباشرةً على طبقة البروتوكول.

في حلول خصوصية البلوكشين، يوجد سؤال يُغفل كثيرًا: هل تؤدي حماية المعاملات إلى إدخال افتراضات ثقة جديدة؟ قد يرغب المستخدمون في إخفاء محتوى معاملاتهم، لكن إذا تطلب ذلك تسليم المعاملة النصية الصريحة إلى مؤسسة جديدة، فقد تنشئ حماية الخصوصية نفسها سطح هجوم جديدًا.
ترسل مسارات المعاملات الخاصة التقليدية المعاملات عادةً إلى RPC أو منشئ أو خدمة ترحيل محددة. ويمنع ذلك المشاركين الآخرين في الشبكة العامة من رؤية المعاملة مباشرةً، لكن قد يظل مقدم الخدمة قادرًا على الاطلاع على المعاملة النصية الصريحة. وبالنسبة إلى المستخدمين العاديين، يمثل ذلك حلًا عمليًا، لكن الخصوصية تعتمد على سلوك وأمان المشغل الخارجي.
يتمثل نهج آخر في استخدام بيئة تنفيذ موثوقة (TEE) للحفاظ على سرية المعاملات داخل بيئة عتادية محددة. ويمكن لـ TEE توفير عزل قوي، لكن أمنها يعتمد أيضًا على العتاد الأساسي والبرامج الثابتة وبيئة التشغيل. وتوزع لجنة عتبية خارجية حقوق فك التشفير بين لجنة مستقلة، ما قد يقلل مخاطر نقطة الفشل الواحدة، لكنه يضيف متطلبات ثقة مرتبطة بالحوكمة خارج السلسلة وعمليات اللجنة.
يسعى Mempool المشفّر الخاص بـ Aptos بدلًا من ذلك إلى دمج التشفير العتبي مباشرةً في AptosBFT، بحيث يشارك المدققون المسؤولون عن ترتيب المعاملات أيضًا في إدارة قدرات فك التشفير. ولا يتمثل الهدف في الادعاء بأن «الثقة لم تعد مطلوبة»، بل في إعادة استخدام افتراضات ثقة إجماع البلوكشين التي يحتاج المستخدمون بالفعل إلى قبولها، قدر الإمكان. وتعرّف Aptos هذا رسميًا باعتباره تنفيذًا أصليًا للبروتوكول، وتؤكد أنه يستخدم افتراضات الثقة نفسها التي تعتمد عليها السلسلة ذاتها.
من منظور تطور البنية التحتية لـ ويب3، يعد هذا التصميم مهمًا. فلا ينبغي تقييم حماية الخصوصية في الأنظمة اللامركزية فقط بالسؤال عما إذا كان من الممكن تشفير شيء ما. بل من الضروري أيضًا التساؤل عن الأطراف التي يجب أن يثق بها المستخدمون بعد إدخال التشفير. وتكمن قيمة التصميم الأصلي للبروتوكول في محاولته تقليل طبقات الثقة الإضافية وجعل قدرات الخصوصية جزءًا من البنية التحتية الأساسية للبلوكشين.
على المستوى النظري، لا يعد تشفير المعاملات أمرًا صعبًا. ويتمثل التحدي الحقيقي في تمكين المعاملات المشفّرة من العمل على نطاق واسع في بلوكشين عالي الأداء. يمنع التشفير العقد من قراءة محتوى المعاملة مباشرةً، لكن يجب في النهاية فك تشفير المعاملة وتنفيذها بصورة صحيحة. وإذا كانت كل معاملة تتطلب اتصالًا مكثفًا بين العديد من العقد، فقد تعوض تكلفة أداء التشفير مزايا إنتاجية البلوكشين.
لذلك، تتمثل إحدى القضايا الرئيسية لـ Mempool مشفّر جاهز للإنتاج في كيفية الحفاظ على قابلية توسيع التشفير العتبي عندما يدخل عدد كبير من المعاملات إلى كتلة في الوقت نفسه. تعالج Aptos ذلك باستخدام مخطط تشفير عتبي جماعي يتيح فك تشفير كتلة كاملة على دفعات، مع الحفاظ على استقرار نسبي لحجم الاتصال المطلوب من كل مدقق. وأظهر معيار Aptos المنشور باستخدام 50 عقدة أن المخطط أضاف نحو 20 مللي ثانية إلى زمن استجابة الكتلة مقارنةً بـ AptosBFT في بيئة إنتاج، بينما يمكن لكتل Aptos الوصول إلى النهائية في أقل من ثانية واحدة.
وفي الوقت نفسه، لا يسعى Mempool المشفّر إلى إخفاء جميع معلومات المعاملة. ففي الإصدار الحالي من Aptos، تظل معلومات مثل عناوين المستخدمين ورسوم Gas مرئية، بينما تظل حمولة المعاملة — أي الوظائف التي يتم استدعاؤها ومعلماتها — مشفّرة قبل التنفيذ. وبعد إتمام الكتلة، يمكن تسجيل محتوى المعاملة على السلسلة، ما يسمح للسلسلة بالحفاظ على قابلية التدقيق العامة.
ينشئ ذلك نهجًا تصميميًا يختلف عن الأنظمة مجهولة الهوية بالكامل. فبدلًا من جعل المعاملات غير مرئية بشكل دائم، فإنه يتحكم في رؤية معلومات المعاملة عبر مراحل مختلفة من دورة الحياة. وبالنسبة إلى أنظمة DeFi التي تتطلب تسوية عامة وقابلية للتحقق، قد يكون هذا النوع من «الخصوصية المرحلية» أكثر عملية من إخفاء المعاملات بالكامل.
ومن منظور البنية التحتية، يعد هذا أيضًا ما يجعل Mempools المشفّرة جديرة بالاهتمام. فهي لا تضيف ببساطة مفتاحًا للخصوصية، بل تعيد تصميم دورة حياة المعاملة بالكامل، من الإرسال والنشر إلى الترتيب والإجماع والتنفيذ.
رغم أن Mempool المشفّر يمثل شكلًا من البنية التحتية الأساسية للبلوكشين، فإن المشكلة الجوهرية التي يعالجها — كشف نية المعاملة قبل التنفيذ وما ينتج عنه من السبق في تنفيذ المعاملات وهجمات الساندويتش وMEV — ترتبط ارتباطًا وثيقًا بالبنية التحتية للتداول في قطاع العملات المشفرة. وبالنسبة إلى المستخدمين المشاركين في DeFi وDEXs والعقود الدائمة على السلسلة والتطبيقات المالية الأخرى على السلسلة، لا يقتصر التداول على «إرسال معاملة وإتمامها». بل يتضمن مراحل متعددة، بما فيها البث والدخول إلى Mempool والترتيب والإجماع والتنفيذ. ويعد فهم Mempools المشفّرة وسيلة لفهم متى تكون المعلومات مرئية للمشاركين الآخرين بينما تنتقل معاملة أصول مشفرة من إنشائها إلى تنفيذها النهائي.
وينشئ هذا أيضًا رابطًا مفاهيميًا مباشرًا مع سيناريوهات تداول العملات المشفرة التي يواجهها مستخدمو Gate. توفر Gate مجموعة من خدمات تداول الأصول المشفرة، بما فيها التداول الفوري وتداول العقود الآجلة. وتختلف آليات التداول وهياكل السيولة ورؤية المعلومات التي يواجهها المستخدمون بين بيئات التداول. ففي منصات التداول المركزية، تُعالج الأوامر عادةً بواسطة محرك المطابقة الخاص بالمنصة، بينما تعتمد الأسواق على السلسلة مثل DEXs مباشرةً على آليات نشر المعاملات وترتيبها وتنفيذها في البلوكشين. ويمكن أن يساعد فهم «سبب إمكانية رؤية المعاملة»، و«من يمكنه التأثير في ترتيب المعاملات»، و«سبب حدوث MEV» المستخدمين على فهم الفروقات الهيكلية الأساسية بين التداول المركزي والتداول على السلسلة بصورة أعمق.
بالنسبة إلى المشاركين في قطاع العملات المشفرة ضمن منظومة Gate، لا يقتصر هذا الفهم على DEXs. فمع استمرار تطور العقود الدائمة على السلسلة وDeFi والتطبيقات المالية الأخرى على السلسلة، يحتاج المستخدمون بشكل متزايد إلى فهم هياكل المخاطر المختلفة للتداول المركزي والتداول على السلسلة. فعلى سبيل المثال، في بيئة التداول المركزية، يحتاج المستخدمون أساسًا إلى مراعاة آليات المطابقة والسيولة ومخاطر المنصة وتنفيذ الأوامر. أما في التداول على السلسلة، فيجب عليهم أيضًا مراعاة Gas ومساحة الكتلة وترتيب المعاملات ورؤية Mempool وMEV. ويقع Mempool المشفّر عند تقاطع هذه القضايا، إذ يوسع «مخاطر تنفيذ المعاملات» لتتجاوز اعتبارات السعر والسيولة إلى طبقة البنية التحتية للبلوكشين.
من هذا المنظور، يمثل Mempool المشفّر أيضًا نقطة دخول مهمة لفهم المرحلة التالية من البنية التحتية لتداول العملات المشفرة. وباعتبارها منصة تغطي أصولًا مشفرة متعددة وسيناريوهات تداول مختلفة، تخدم Gate المستخدمين الذين يتعاملون مع الأسواق المركزية والمنظومة المتوسعة على السلسلة معًا. وقد يصبح مفهوم «خصوصية ما قبل التنفيذ» الذي تمثله Mempools المشفّرة اتجاهًا مهمًا للتطور المستمر للبنية التحتية للتداول على السلسلة: تمكين المستخدمين من تحقيق تنفيذ أفضل مع تقليل احتمالية قراءة المشاركين الآخرين لاستراتيجياتهم مسبقًا قبل تنفيذها فعليًا. بالنسبة إلى مستخدمي قطاع العملات المشفرة، لا يتعلق فهم Mempools المشفّرة بفهم تقنية بلوكشين فحسب، بل أيضًا بفهم الكيفية التي قد تسعى بها أسواق التداول المستقبلية إلى تحقيق توازن بين الشفافية والخصوصية والكفاءة والإنصاف.
لا يمثل Mempool المشفّر حلًا شاملًا للخصوصية. أولًا، يعالج بشكل أساسي تسرب محتوى المعاملة قبل التنفيذ. فبمجرد إتمام الكتلة واكتمال فك التشفير، يمكن أن يظل محتوى المعاملة مسجلًا ومدققًا علنًا. لذلك، إذا احتاج المستخدمون إلى الحفاظ على إخفاء مبالغ المعاملات أو أرصدة الحسابات أو هويات المشاركين على المدى الطويل، فستظل هناك حاجة إلى تقنيات خصوصية إضافية.
ثانيًا، لا يعني تشفير حمولة المعاملة أن جميع البيانات الوصفية مخفية. ففي تنفيذ Aptos الحالي، تظل معلومات مثل عنوان المرسل ورسوم Gas مرئية. وهذا يعني أن مراقبي الشبكة لا يزال بإمكانهم الحصول على معلومات جزئية عن نشاط المعاملات، حتى إن لم يتمكنوا من قراءة نية المعاملة الكاملة مباشرةً قبل التنفيذ.
إضافةً إلى ذلك، لا يزال التشفير العتبي الأصلي للبروتوكول يعتمد على مجموعة مدققي البلوكشين وافتراضات أمان الإجماع. فهو يقلل الثقة الإضافية، لكنه لا يلغي جميع أشكال الثقة. وإذا تعرض نموذج أمان إجماع الشبكة نفسه للاختراق، فقد تتأثر أيضًا آلية خصوصية المعاملات. ولذلك، يتطلب تقييم Mempool المشفّر فهم تصميمه التشفيري ومجموعة المدققين وآلية الإجماع.
قد ينطوي التطور المستقبلي على الجمع بين طبقات متعددة من قدرات الخصوصية. إذ يمكن لـ Mempool مشفّر حماية نية المعاملة، ويمكن للخصوصية على مستوى الحساب أن تحمي الأرصدة والمبالغ بشكل أكبر، كما يمكن لإثباتات المعرفة الصفرية إثبات صحة المعاملة دون كشف البيانات الأساسية. وتعالج التقنيات المختلفة طبقات مختلفة من المشكلة، لتشكل في النهاية بنية تحتية أكثر اكتمالًا للخصوصية على السلسلة.
كانت الشفافية العامة في السابق سمة مهمة تميز أنظمة البلوكشين عن الأنظمة المالية التقليدية. لكن مع نمو حجم التمويل على السلسلة، كشفت هذه الشفافية أيضًا عن مشكلات جديدة. فكون جميع المعاملات قابلة للملاحظة لا يعني أن كل معاملة يجب الكشف عنها بالكامل قبل التنفيذ.
يتمثل الاتجاه الذي تمثله Mempools المشفّرة في نقل البلوكشين من «جميع المعلومات علنية فورًا» إلى «إفصاح عن المعلومات المختلفة في أوقات مختلفة وبطرق مختلفة». ولا يزال من الممكن في النهاية تسجيل المعاملات والتحقق منها، بينما يستطيع المشاركون الحفاظ على مرونتهم الاستراتيجية قبل اكتمال التنفيذ.
وهذا في جوهره نهج قائم على «الشفافية المنضبطة». فهو لا يرفض مبدأ التحقق العام في ويب3، بل يسعى إلى إيجاد توازن جديد بين التسوية العامة وخصوصية المعاملات. وبالنسبة إلى DeFi والتداول على السلسلة والتطبيقات المالية المتزايدة التعقيد في المستقبل، قد يصبح هذا التوازن أكثر أهمية.
كما يوضح دمج Aptos لـ Mempool مشفّر مباشرةً في بروتوكولها ونظام إجماعها أن الخصوصية على السلسلة تنتقل تدريجيًا من أدوات طبقة التطبيق إلى تصميم البنية التحتية الأساسية.
وعبر قطاع ويب3، لا تقتصر قيمة Mempools المشفّرة على حل معاملة واحدة تتعرض للسبق في التنفيذ. بل إنها تشجع السوق أيضًا على إعادة النظر في سؤال أساسي: متى ينبغي للبلوكشين أن يفصح عن أي معلومات؟ وعندما تصبح خصوصية المعاملات قدرة أساسية في البروتوكول، قد لا تعود الشفافية والخصوصية في ويب3 خيارين متعارضين. بل يمكن أن تصبحا طبقات تصميم مختلفة ضمن البنية التحتية نفسها.
Mempool المشفّر هو آلية بلوكشين تشفّر محتوى المعاملة بعد دخولها إلى Mempool. ويمكن نشر المعاملات وترتيبها بصيغة مشفّرة، ثم فك تشفيرها وتنفيذها بعد إتمام الكتلة، ما يقلل خطر كشف نية المعاملة قبل التنفيذ.
في Mempool العادي، يمكن لمراقبي الشبكة عادةً قراءة المحتوى التفصيلي للمعاملات المعلقة. يخفي Mempool المشفّر حمولة المعاملة، ما يحافظ على عدم إمكانية قراءتها قبل التأكيد النهائي مع السماح لها بالمشاركة في ترتيب الكتل والإجماع.
لا. يستهدف Mempool المشفّر بالأساس MEV الذي يعتمد على قراءة محتوى المعاملة مسبقًا، مثل أنواع معينة من السبق في تنفيذ المعاملات وهجمات الساندويتش. ولن تختفي تلقائيًا أشكال MEV الأخرى الناشئة عن آليات مثل عمليات التصفية والمراجحة وترتيب الكتل لمجرد أن حمولة المعاملة مشفّرة.
لا. يحمي Mempool المشفّر محتوى المعاملة قبل التنفيذ بالأساس، ولا يشكل إخفاءً كاملًا للهوية. ففي تنفيذ Aptos الحالي مثلًا، يظل عنوان المرسل ورسوم Gas مرئيين. وبعد إتمام المعاملة، يُفك تشفيرها وتُسجل أيضًا، ما يحافظ على قابلية التدقيق على السلسلة.
يوزع التشفير العتبي قدرات فك التشفير بين عدة مدققين، ويمنع مدققًا واحدًا من قراءة المعاملات المعلقة بشكل مستقل. ويحمي ذلك محتوى المعاملة، مع السماح لأمان الخصوصية بالاقتراب قدر الإمكان من نموذج ثقة الإجماع الحالي للبلوكشين.
تعد مناسبة بصفة خاصة لسيناريوهات ويب3 التي تنطوي على منافسة في التداول ومعاملات حساسة للاستراتيجيات، بما في ذلك التداول اللامركزي والعقود الدائمة واستراتيجيات DeFi المعقدة والتطبيقات الأخرى على السلسلة التي تحتاج إلى الحد من تسرب نية المعاملة. وكشفت Aptos أن Decibel ستستخدم هذه الآلية لحماية خصوصية ما قبل التنفيذ لأوامر العقود الدائمة.
* لا يُقصد من المعلومات أن تكون أو أن تشكل نصيحة مالية أو أي توصية أخرى من أي نوع تقدمها منصة Gate أو تصادق عليها .
* لا يجوز إعادة إنتاج هذه المقالة أو نقلها أو نسخها دون الرجوع إلى منصة Gate. المخالفة هي انتهاك لقانون حقوق الطبع والنشر وقد تخضع لإجراءات قانونية.





