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

المؤلف الأصلي: فاوست، مهووس web3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< p> لجنة ethereum & nbsp ؛ dac & nbsp ؛ 2 & nbsp ؛ يتبع بشكل أساسي نموذج & nbsp ؛ "المركزية" و"سلسلة التحالف". بالإضافة إلى ذلك، في بعض طبقة Ethereum2 التي تتبنى وضع DAC، يرسل جهاز التسلسل بيانات DA فقط إلى عقد أعضاء DAC ولا يقوم بتحميل البيانات إلى أماكن أخرى تقريبًا إذن من لجنة DAC، والتي لا تختلف بشكل أساسي عن سلسلة التحالف.

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

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

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

هنا نصف بإيجاز سير عمل Merlin (الصورة أدناه):< /p>

• بعد تلقي عدد كبير من طلبات المعاملات، يقوم جهاز التسلسل بتجميعها وإنشاءها؛ دفعة بيانات (دفعة بيانات)، تم تمريرها إلى Prover  العقد، وعقد أوراكل (DAC اللامركزية).

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

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

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

< / p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الملخص

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