تفسير حل ميرلين التقني: كيف يعمل؟

المؤلف: فاوست، مهووس الويب3

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

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

في هذه المقالة، سيركز Geek web3 علىالحل التقني لسلسلة Merlin ويفسر وثائقه المنشورة وأفكار تصميم البروتوكول،

strong>نحن ملتزمون بالسماح لعدد أكبر من الأشخاص بفهم سير العمل العام لـ Merlin، والحصول على فهم أوضح لنموذج الأمان الخاص بها، والسماح للجميع بفهم كيفية عمل "رأس Bitcoin Layer 2" في طريقة أكثر سهولة.

شبكة أوراكل اللامركزية لـ Merlin: لجنة DAC مفتوحة خارج السلسلة

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

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

من بين الطبقة 2 التي تتبنى الفكرة الأولى، قد تكون Citrea هي الأكثر شهرة، وهم يخططون لتغيير حالة الطبقة 2 على مدى فترة من الزمن. الوقت (اختلاف الحالة)، أي أنه يتم تحميل نتائج تغيير الحالة على حسابات متعددة إلى سلسلة Bitcoin مع شهادات ZK المقابلة. في هذه الحالة، يمكن لأي شخص تنزيل State diff وZKP من شبكة Bitcoin الرئيسية، ثم مراقبة التغييرات في حالة Citrea. يمكن لهذه الطريقة ضغط حجم البيانات في السلسلة بنسبة تزيد عن 90%.

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

تتخذ العديد من طبقات Bitcoin 2 المسار الثاني: استخدم حل DA مباشرة ضمن سلسلة Bitcoin، إما قم ببناء طبقة DA بنفسك، أو استخدم Celestia و EigenDA et آل. يستخدم كل من B^Square وBitLayer وبطل هذه المقالة، Merlin، حل توسيع DA خارج السلسلة هذا.

المقالة السابقة في geekweb3——في "تحليل خارطة طريق تقنية الإصدار الجديد B^2: ضرورة DA وطبقة التحقق ضمن سلسلة Bitcoin"، ذكرنا حسنًا، قام B^2 بتقليد Celestia بشكل مباشر وقام ببناء شبكة DA خارج السلسلة تدعم وظيفة أخذ عينات البيانات، تسمى B^2 Hub. يتم تخزين "بيانات DA" مثل بيانات المعاملات أو اختلاف الحالة ضمن سلسلة Bitcoin، ويتم تحميل جذر datahash / Merkle فقط إلى شبكة Bitcoin الرئيسية.

هذا في الواقع يعامل Bitcoin كلوحة إعلانات غير موثوقة: يمكن لأي شخص قراءة تجزئة البيانات من سلسلة Bitcoin. بعد الحصول على بيانات DA من موفر البيانات خارج السلسلة، يمكنك التحقق مما إذا كانت تتوافق مع تجزئة البيانات الموجودة في السلسلة، أي hash(data1) == datahash1? . إذا كان هناك مراسلات بين الاثنين، فهذا يعني أن البيانات المقدمة لك من قبل مزود البيانات خارج السلسلة صحيحة.

(رسم تخطيطي للطبقة 2 لطبقة DA الموجودة ضمن سلسلة البيتكوين

المصدر: Geek web3)< /strong>

يمكن للعملية المذكورة أعلاه التأكد من أن البيانات المقدمة لك عن طريق العقد خارج السلسلة مرتبطة بـ "أدلة" معينة على Layer1 لمنع توفير DA بشكل ضار بيانات خاطئة. ولكن هنا سيناريو شرير مهم للغاية: إذا كان مصدر البيانات، Sequencer، لا يرسل البيانات المقابلة لـ datahash على الإطلاق، ولكنه يرسل فقط datahash إلى سلسلة Bitcoin، ولكنه يحجب البيانات المقابلة عمدًا لمنع أي شخص من قراءته، خذ ماذا أفعل في هذا الوقت؟

تتضمن السيناريوهات المشابهة، على سبيل المثال لا الحصر، ما يلي: نشر ZK-Proof وStateRoot فقط، ولكن عدم نشر بيانات DA المقابلة (اختلاف الحالة أو بيانات المعاملات)، على الرغم من أن يمكن للأشخاص التحقق من ZKProof والتأكد من أن عملية الحساب من Prev_Stateroot إلى New_Stateroot صالحة، ولا يعرفون حالات الحسابات التي تغيرت. في هذه الحالة، على الرغم من أن أصول المستخدم آمنة، لا يمكن للجميع التأكد من الحالة الفعلية للشبكة على الإطلاق، ولا يعرفون المعاملات التي تم حزمها في السلسلة وحالة العقد التي تم تحديثها في هذا الوقت 2 يعادل في الأساس إيقاف التشغيل.

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

غالبًا ما تقوم العديد من طبقة Ethereum 2 التي تتبنى حلول DA خارج السلسلة بإعداد عدة عقد بأذونات خاصة لتشكيل لجنة، الاسم الكامل هو لجنة توفر البيانات (DAC) ). تعمل لجنة DAC هذه كضامن وتدعي للعالم الخارجي أن Sequencer قد أصدر بالفعل بيانات DA كاملة (بيانات المعاملات أو فرق الحالة) خارج السلسلة. ثم تقوم عقد DAC بشكل جماعي بإنشاء توقيع متعدد وطالما أن التوقيع المتعدد يلبي متطلبات الحد الأدنى (مثل 2/4)، فإن العقود ذات الصلة على Layer1 ستتخلف عن السداد أصدرت بيانات DA الكاملة خارج السلسلة.

لجنة DAC للطبقة الثانية من Ethereum هي باتباع نموذج POA، يُسمح فقط لعدد قليل من العقد التي مرت عبر KYC أو التعيين الرسمي بالانضمام إلى لجنة DAC. وهذا يجعل DAC مرادفًا لـ "المركزية" و"سلسلة التحالف". بالإضافة إلى ذلك، في بعض طبقات Ethereum 2 التي تعتمد وضع DAC، يرسل جهاز التسلسل بيانات DA فقط إلى العقد الأعضاء في DAC ولا يقوم أبدًا بتحميل البيانات إلى أماكن أخرى اختلاف جوهري عن سلسلة التحالف.

ليس هناك شك في أن DAC يجب أن تكون لا مركزية. ولا تحتاج الطبقة 2 إلى تحميل بيانات DA مباشرة إلى Layer1، ولكن يجب أن تكون حقوق الوصول للجنة DAC مفتوحة إلى العالم الخارجي، وبهذه الطريقة فقط يمكن منع عدد قليل من الناس من التآمر لفعل الشر. (لمناقشة سيناريوهات DAC الشريرة، يمكنك الرجوع إلى تصريحات Dankrad السابقة على Twitter)

تم استبدال BlobStream الذي اقترحته Celestia سابقًا بشكل أساسي بـ Celestia DAC المركزي يمكن لجهاز التسلسل الخاص بـ Ethereum L2 نشر بيانات DA إلى سلسلة Celestia إذا قام ثلثا عقد Celestia بالتوقيع عليها، فإن عقد Layer2 الحصري المنشور على Ethereum سيعتبر أن بيانات DA صادقة تم إصداره، والذي يسمح في الواقع لعقد Celestia بالعمل كضامنين. وبالنظر إلى أن سيليستيا لديها المئات من عقد التحقق من الصحة، يمكننا أن نعتقد أن لجنة المساعدة الإنمائية الكبيرة هذه لا مركزية نسبيًا.

إن حل DA الذي تبنته Merlin هو في الواقع قريب نسبيًا من BlobStream من Celestia، وكلاهما مفتوح الوصول إلى DAC من خلال نقطة البيع، مما يجعله أكثر لامركزية. يمكن لأي شخص تشغيل عقدة DAC طالما أنه يمتلك ما يكفي من الأصول. في وثائق Merlin، تسمى عقدة DAC المذكورة أعلاه Oracle، ويشار إلى أنها ستدعم تعهدات الأصول الخاصة بـ BTC و MERL وحتى الرموز المميزة BRC-20 لتنفيذ آلية تعهد مرنة وأيضًا دعم تعهدات الوكيل المشابهة لـ Lido. (تعد اتفاقية تعهد POS الخاصة بـ Oracle في الأساس إحدى روايات Merlin الأساسية التالية، وأسعار الفائدة على التعهدات المقدمة مرتفعة نسبيًا)

هنا باختصار وصف سير عمل Merlin (الصورة أدناه):

1. بعد يتلقى جهاز التسلسل عددًا كبيرًا من طلبات المعاملات، ويقوم بتلخيصها وإنشاء مجموعة بيانات (دُفعة بيانات)، والتي يتم تمريرها إلى عقدة Prover وعقدة Oracle (DAC اللامركزية).

2. عقدة Merlin's Prover لا مركزية وتستخدم Prover's Lumoz كخدمة خدمة. بعد تلقي دفعات متعددة من البيانات، سيقوم مجمع التعدين Prover بإنشاء إثباتات المعرفة الصفرية المقابلة، وبعد ذلك سيتم إرسال ZKP إلى عقدة Oracle للتحقق.

3. ستتحقق عقدة Oracle مما إذا كان دليل ZK المرسل من مجمع تعدين ZK الخاص بـ Lmuoz يمكن أن يتطابق مع مراسلات Sequencer إلى دفعة البيانات المرسلة. إذا كان من الممكن مطابقة الاثنين ولا يحتويان على أخطاء أخرى، فسيتم تمرير عملية التحقق. خلال هذه العملية،ستقوم عقد Oracle اللامركزية بإنشاء توقيعات متعددة من خلال توقيعات العتبة وتعلن للعالم الخارجي أن جهاز التسلسل قد أرسل بيانات DA بالكامل، وأن ZKP المقابل صالح واجتاز التحقق من عقدة Oracle.

4. يقوم الفارز بجمع نتائج التوقيع المتعدد من عقدة Oracle استيفاء عدد التوقيعات بعد استيفاء متطلبات الحد الأدنى، يتم إرسال معلومات التوقيع إلى سلسلة Bitcoin، جنبًا إلى جنب مع تجزئة بيانات DA (دفعة البيانات)، ويتم تسليمها إلى العالم الخارجي للقراءة والتأكيد.

(مصدر مخطط مبدأ عمل Merlin: geek web3)

< li>

تقوم عقد Oracle بإجراء معالجة خاصة في عملية الحساب للتحقق من إثبات ZK، وإنشاء التزامات الالتزام، وإرسالها إلى سلسلة Bitcoin، مما يسمح لأي شخص بـ "الالتزام" للتحدي، العملية هنا هي في الأساس نفس بروتوكول مكافحة الاحتيال الخاص بـ bitVM. إذا نجح التحدي، فستتم معاقبة عقدة Oracle التي أصدرت الالتزام ماليًا. بالطبع، تتضمن البيانات التي تريد Oracle نشرها على سلسلة Bitcoin أيضًا تجزئة حالة الطبقة الثانية الحالية - StateRoot، بالإضافة إلى ZKP نفسها، والتي يجب نشرها على سلسلة Bitcoin للكشف الخارجي.

المرجع: "التفسير البسيط لـ BitVM: كيفية التحقق من إثبات الاحتيال في سلسلة BTC"< /p>

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

المواد المرجعية: "تحليل خارطة طريق تقنية الإصدار الجديد B^2: ضرورة طبقة DA والتحقق ضمن سلسلة Bitcoin"

تحليل نموذج الأمان: خدمة MPC ZKRollup+Cobo المتفائلة

لقد وصفنا Merlin بإيجاز أعلاه سير العمل، أعتقد أنك قد أتقنت بالفعل بنيتها الأساسية. ليس من الصعب أن نرى أن Merlin وB^Square وBitLayer وCitrea يتبعون بشكل أساسي نفس نموذج الأمان - ZK-Rollup المتفائل.

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

بالنسبة لبيئة Ethereum الخاصة بمعسكر Rollup الأساسي، قد يكون ZK-Rollup المتفائل غير موصوف بعض الشيء، ولكن هذا يتماشى تمامًا مع الوضع الحالي لطبقة Bitcoin 2. نظرًا للقيود الفنية، لا يمكن لسلسلة Bitcoin التحقق من ZK Proof بشكل كامل، ويمكنها فقط التحقق من خطوة معينة من عملية حساب ZKP في ظل ظروف خاصة، وفي ظل هذه الفرضية، يمكن لسلسلة Bitcoin في الواقع دعم بروتوكول إثبات الاحتيال للأشخاص فقط تجدر الإشارة إلى أن هناك خطأ في خطوة حسابية معينة لـ ZKP أثناء عملية التحقق خارج السلسلة، ويتم الطعن فيه من خلال إثبات الاحتيال. بالطبع، لا يمكن مقارنة ذلك بـ ZK Rollup على طراز Ethereum، ولكنه الأفضل بالفعل التي يمكن أن تحققها طبقة Bitcoin Layer 2 حاليًا.

بموجب مخطط ZK-Rollup المتفائل أعلاه، بافتراض وجود N من الأشخاص في شبكة الطبقة الثانية الذين لديهم السلطة لبدء التحديات، طالما مثل هؤلاء المنافسين لـ N، إذا كان أحد الأشخاص صادقًا وموثوقًا ويمكنه اكتشاف الأخطاء وبدء إثبات الاحتيال في أي وقت، فإن انتقال الحالة للطبقة الثانية يكون آمنًا. بالطبع، يحتاج التراكمي المتفائل بدرجة عالية نسبيًا من الاكتمال إلى التأكد من أن جسر السحب الخاص به محمي أيضًا بواسطة بروتوكول مكافحة الاحتيال، ومع ذلك، لا تستطيع جميع طبقات Bitcoin Layer 2 حاليًا تحقيق هذه الفرضية وتحتاج إلى الاعتماد على التوقيع المتعدد/. إذن، كيف يتم اختيار التوقيع المتعدد؟ أصبح التوقيع على حل MPC مشكلة مرتبطة ارتباطًا وثيقًا بأمان الطبقة الثانية.

اختار Merlin خدمة MPC من Cobo لحل التجسير من خلال اعتماد تدابير مثل عزل المحفظة الساخنة والباردة، ويتم توفير أصول التجسير تتم إدارة سلسلة Cobo وMerlin بشكل مشترك، ويجب التعامل مع أي سلوك سحب بشكل مشترك من قبل المشاركين في لجنة السياسة النقدية في Cobo وMerlin Chain. وفي جوهر الأمر، يتم ضمان موثوقية جسر السحب من خلال المصادقة الائتمانية للمؤسسة. بالطبع، هذا مجرد إجراء مؤقت في هذه المرحلة مع تحسن المشروع تدريجيًا، يمكن استبدال جسر السحب بـ "جسر التفاؤل" بافتراض الثقة 1/N من خلال تقديم BitVM وبروتوكول مكافحة الاحتيال سيكون تنفيذ ذلك أكثر صعوبة (تعتمد جميع جسور الطبقة الثانية الرسمية تقريبًا حاليًا على التوقيع المتعدد).

بشكل عام، يمكننا حل هذه المشكلة.قدمت Merlin DAC المستندة إلى نقطة البيع، وZK-Rollup المتفائل المستند إلى BitVM، وأصول MPC المستندة إلى Cobo حل الحفظ: حل مشكلة DA عن طريق فتح أذونات DAC؛ وضمان أمان انتقال الحالة من خلال تقديم BitVM وبروتوكول مكافحة الاحتيال؛ وضمان موثوقية جسر السحب من خلال تقديم خدمة MPC الخاصة بـ Cobo، وهي منصة معروفة لحفظ الأصول.

مخطط إرسال ZKP للتحقق من خطوتين استنادًا إلى Lumoz

قمنا في وقت سابق بتحليل نموذج أمان Merlin وقدمنا ​​مفهوم ZK-rollup المتفائل. في خريطة طريق التكنولوجيا الخاصة بـ Merlin، تم الحديث أيضًا عن Prover اللامركزي. كما نعلم جميعًا، يعد Prover دورًا أساسيًا في بنية ZK-Rollup، وهو مسؤول عن إنشاء ZKProof للدفعة الصادرة عن Sequencer. ومع ذلك، فإن عملية إنشاء إثبات المعرفة الصفرية تستهلك موارد الأجهزة للغاية وهي مشكلة شائكة للغاية .

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

من أجل تسريع عملية إنشاء إثبات ZK، سوف تتبنى Merlin حل Lumoz's Prover، وهو ما يعني في الواقع جمع عدد كبير من الأجهزة معًا لتشكيل تجمع تعدين، و ثم قم بتعيين مهام الحوسبة المخصصة للأجهزة المختلفة وتخصيص الحوافز المقابلة، والتي تشبه إلى حد ما تعدين أسرى الحرب.

في حل Prover اللامركزي هذا، يوجد نوع من سيناريو الهجوم، المعروف باسم الهجوم الأمامي: بافتراض أن مجمعًا قد أنشأ ZKP، فإنه يرسل ZKP على أمل الحصول على مكافآت. بعد أن يرى المجمعون الآخرون محتوى ZKP، ينشرون نفس المحتوى قبله، مدعين أنه قام بإنشاء ZKP أولاً. كيف يمكن حل هذا الموقف؟

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

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

يعتمد Lumoz طريقة إرسال شهادة ZK للتحقق من خطوتين. بعد أن يقوم المجمع بإنشاء شهادة ZK، لا يحتاج إلى إرسال المحتوى الكامل أولاً، ولكنه ينشر فقط تجزئة ZKP. وبعبارة أخرى، ينشر التجزئة ( ZKP + عنوان المجمع). بهذه الطريقة، حتى لو رأى الآخرون قيمة التجزئة، فإنهم لا يعرفون محتوى ZKP المقابل ولا يمكنهم القفز للأمام مباشرة؛

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

من خلال نظام إرسال ZKP للتحقق المكون من خطوتين، يمكن لـ Merlin (Lumoz) حل مشكلة التشغيل الأمامي في عملية تقديم ZKP، وبالتالي تحقيق قدرة تنافسية عالية يؤدي إثبات المعرفة الصفرية إلى توليد حوافز لزيادة سرعة توليد ZKP.

Merlin's Phantom: إمكانية التشغيل البيني متعدد السلاسل

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

على سبيل المثال، يمكن نشر حساب EOA الذي تتحكم فيه شبكة Merlin على Polygon عندما يصدر المستخدم تعليمات قابلية التشغيل البيني عبر السلسلة على سلسلة Merlin تقوم شبكة Merlin أولاً بتحليل محتواها وإنشاء بيانات معاملة ليتم تنفيذها على السلسلة المستهدفة، ثم تقوم شبكة Oracle Network بمعالجة توقيع MPC على المعاملة لإنشاء توقيع رقمي للمعاملة. بعد ذلك، تقوم عقدة Merlin's Relayer بتحرير المعاملة على Polygon وإكمال العمليات اللاحقة من خلال أصول Merlin في حساب EOA على السلسلة المستهدفة.

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

الملخص

في هذه المقالة نناقش سلسلة ميرلين تم شرح الحل الفني العام بإيجاز، والذي أعتقد أنه يمكن أن يساعد المزيد من الأشخاص على فهم سير العمل العام لـ Merlin والحصول على فهم أوضح لنموذج الأمان الخاص به. وبالنظر إلى أن النظام البيئي الحالي للبيتكوين يسير على قدم وساق، فإننا نعتقد أن هذا النوع من أنشطة تعميم التكنولوجيا ذو قيمة ويحتاجها عامة الناس وسنجري متابعة طويلة المدى لـ Merlin وbitLayer وB^Square و مشاريع أخرى في المستقبل للحصول على تحليل أكثر تعمقًا لحلولها التقنية، يرجى متابعة أخبارنا!