من صيف النقوش في عام 2023 حتى الوقت الحاضر ، كان بيتكوين طبقة 2 دائما أبرز ما في Web3 بأكمله. على الرغم من أن ارتفع هذا المجال متأخر كثيرا عن طبقة 2 في عام إثيريوم ، مع السحر الفريد لأسرى الحرب والهبوط السلس فوري ETF ، فإن بيتكوين دون النظر في خطر "التوريق" قد اجتذب انتباه عشرات المليارات من الدولارات من رأس المال للمسار المشتق طبقة 2 في نصف عام فقط.
في المسار بيتكوين طبقة 2 ، فإن Merlin ، التي لديها مليارات الدولارات في TVL ، هي بلا شك صاحبة أكبر الحجم وأكثر المتابعين طويل. مع حوافز تخزين واضحة وعائد لائق ، ظهرت Merlin في غضون أشهر تقريبا ، مما خلق أسطورة بيئية تتجاوز Blast. مع تزايد شعبية Merlin ، أصبحت مناقشة حلولها التقنية موضوعا طويل بشكل متزايد.
في هذه المقالة ، سيركز Geek Web3 على الحلول التقنية ل Merlin Chain ، وتفسير مستنداتها المنشورة وأفكار تصميم بروتوكول ، ونحن ملتزمون بالسماح لمزيد من الأشخاص طويل بفهم سير العمل العام لشركة Merlin والحصول على فهم أوضح لنموذج الأمان الخاص بها ، بحيث يمكن للجميع فهم كيفية عمل "بيتكوين طبقة 2 الرأس" بطريقة أكثر سهولة.
شبكة ميرلين شبكة أوراكل اللامركزية: مجلس مفتوح خارج السلسلة لجنة المساعدة الإنمائية
بالنسبة لجميع الطبقة 2 ، سواء كانت إثيريوم طبقة 2 أو بيتكوين طبقة 2 ، تعد تكاليف DA ونشر البيانات واحدة من أهم المشكلات التي يجب حلها. نظرا لأطول مشاكل شبكة بيتكوين نفسها ، والتي لا الدعم بطبيعتها إنتاجية كبيرة للبيانات ، أصبحت كيفية استخدام شورت DA هذا مشكلة صعبة لاختبار خيال طبقة 2 المشاريع.
أحد الاستنتاجات واضح: إذا طبقة 2 تنشر "مباشرة" بيانات المعاملات غير المعالجة إلى بيتكوين كتلة ، فلن تكون قادرة على تحقيق إنتاجية عالية أو رسوم منخفضة. الحل الأكثر شيوعا هو إما ضغط حجم البيانات إلى أصغر حجم ممكن من خلال الضغط العالي وتحميلها على بيتكوين كتلة ، أو نشر البيانات مباشرة على بيتكوين خارج السلسلة. **
من المحتمل أن تكون الطبقات طبقة 2 الأكثر شهرة التي تتخذ النهج الأول هي Citrea ، والتي تعتزم تحميل فرق الحالة لعام طبقة 2 على مدار فترة زمنية ، أي نتائج تغيير الحالة على طويل الحساب ، جنبا إلى جنب مع براهين ZK المقابلة ، إلى بيتكوين داخل السلسلة. في هذه الحالة ، يمكن لأي شخص تنزيل فرق الحالة و ZKP من بيتكوين الشبكة الرئيسية لمراقبة نتائج تغيير حالة Citrea. يمكن أن تقلل هذه الطريقة من حجم البيانات على السلسلة بأكثر من 90٪.
في حين أن هذا يمكن أن يقلل بشكل كبير من حجم البيانات ، إلا أن عنق الزجاجة لا يزال كبيرا. في حالة حدوث عدد كبير من تغييرات حالة الحساب في فترة زمنية قصير ، يحتاج طبقة 2 إلى تلخيص وتحميل جميع التغييرات في هذه الحساب إلى بيتكوين داخل السلسلة ، ولا يمكن الاحتفاظ بتكلفة إصدار البيانات النهائية منخفضة للغاية ، والتي يمكن رؤيتها في طويل إثيريوم ZK Rollup.
من طويل بيتكوين طبقة 2 جدا اتخاذ المسار الثاني ببساطة: استخدام حل DA بيتكوين خارج السلسلة مباشرة ، إما بناء طبقة DA بمفردها ، أو استخدام Celestia ، EigenDA ، إلخ. B ^ Square و BitLayer و Merlin ، بطل الرواية في هذه المقالة ، جميعهم يتبعون مخطط تحجيم DA خارج السلسلة هذا.
في المقالة السابقة ل Geek web3 - "تحليل الإصدار الجديد من خارطة طريق التكنولوجيا B ^ 2: ضرورة بيتكوين خارج السلسلة DA وطبقة التحقق" ، ذكرنا أن ** B ^ 2 يقلد Celestia مباشرة ويبني شبكة DA تدعم وظيفة أخذ عينات البيانات في خارج السلسلة ، المسماة B ^ 2 Hub. يتم تخزين "بيانات DA" مثل بيانات المعاملة أو فرق الحالة في بيتكوين خارج السلسلة ، ويتم تحميل جذر datahash / merkle فقط إلى بيتكوين الشبكة الرئيسية. **
إنها حقا تتعامل مع بيتكوين كلوحة إعلانات عديم الثقة: يمكن لأي شخص قراءة تجزئة البيانات من بيتكوين داخل السلسلة. ** عندما تحصل على بيانات DA من مزود بيانات خارج السلسلة ، يمكنك التحقق مما إذا كانت تتوافق مع داخل السلسلة datahash ** ، أي التجزئة(data1) == datahash1 ?. إذا كان هناك تطابق بين الاثنين ، فهذا يعني أن مزود البيانات بموجب خارج السلسلة أعطاك البيانات الصحيحة.
يمكن أن تضمن العملية المذكورة أعلاه أن البيانات المقدمة لك من قبل خارج السلسلة العقدة مرتبطة ببعض "القرائن" على الطبقة 1 ، مما يمنع طبقة DA من تقديم بيانات خاطئة بشكل ضار. ولكن هناك سيناريو دبوس مهم للغاية هنا: ماذا لو لم يرسل مصدر البيانات ، Sequencer ، البيانات المقابلة لتجزئة البيانات على الإطلاق ، ولكنه يرسل فقط تجزئة البيانات إلى بيتكوين داخل السلسلة ، ولكنه يحجب عمدا البيانات المقابلة عن أي شخص لقراءتها؟
تتضمن السيناريوهات المماثلة ، على سبيل المثال لا الحصر ، نشر ZK-Proof و StateRoot فقط ، ولكن لا تنشر بيانات DA المقابلة (فرق الحالة أو بيانات المعاملة) ، على الرغم من أنه يمكن للأشخاص التحقق من صحة عملية حساب ZKProof ، والتأكد من أن عملية الحساب من Prev \ _Stateroot إلى New \ _Stateroot صالحة ، لكنهم لا يعرفون أي حالة الحساب (ولاية) قد تغيرت. في هذه الحالة ، على الرغم من أن أصول المستخدم آمنة ، لا يمكنك تحديد الحالة الفعلية للشبكة على الإطلاق ، ولا تعرف المعاملات التي تم حزمها على السلسلة والعقود التي تم تحديثها.
هذا في الواقع ** "حجب البيانات **" ، وناقش Dankrad من مؤسسة إثيريوم لفترة وجيزة مشكلة مماثلة على Twitter في أغسطس 2023 ، بالطبع ، فهو شمعة طويلة الفتيل بشكل أساسي لشيء يسمى "DAC".
الأطول إثيريوم Layer2 ، التي تتبنى حلول DA خارج السلسلة ، غالبا ما تنشئ عدة عقد بأذونات خاصة لتشكيل لجنة ، الاسم الكامل للجنة توافر البيانات (DAC). تعمل لجنة DAC هذه كضامن ، مدعية أن Sequencer تنشر بيانات DA الكاملة (بيانات المعاملة أو فرق الحالة) خارج السلسلة. ثم يقوم العقدة DAC بشكل جماعي بإنشاء أطول ، حيث طويل أن الأطول يفي بمتطلبات العتبة (مثل 2/4) ، فإن العقد ذي الصلة في الطبقة 1 سيتخلف عن السداد الافتراضي ، وقد اجتاز Sequencer فحص لجنة DAC وأصدر بصدق بيانات DA الكاملة خارج السلسلة.
تتبع لجنة إثيريوم طبقة 2 DAC بشكل أساسي نموذج التوكيل الرسمي ، مما يسمح فقط لعدد قليل من العقد توثيق KYC أو المعينة رسميا بالانضمام إلى لجنة DAC ، مما يجعل DAC مرادفا ل "مركزي" و "كونسورتيوم blockchain". بالإضافة إلى ذلك ، في بعض إثيريوم طبقة 2 التي تعتمد نموذج DAC ، يرسل جهاز التسلسل بيانات DA فقط إلى العقد الأعضاء في DAC ، ولا يقوم أبدا بتحميل البيانات في مكان آخر ، ويجب على أي شخص يريد الحصول على بيانات DA الحصول على إذن من لجنة DAC ، والتي لا تختلف اختلافا جوهريا عن كونسورتيوم بلوكتشين.
ليس هناك شك في أنه يجب اللامركزية DAC ، ولا يمكن طبقة 2 تحميل بيانات DA مباشرة إلى الطبقة 1 ، ولكن يجب أن تكون سلطة الوصول للجنة DAC مفتوحة للعالم الخارجي لمنع عدد قليل من الأشخاص من التواطؤ لفعل الشر. (لمناقشة سيناريو الأذى في لجنة المساعدة الإنمائية، يرجى الرجوع إلى بيان دانكراد السابق على تويتر)
** BlobStream ، الذي اقترحته Celestia سابقا ، هو في الأساس استبدال DAC المركزي ب Celestia ، ** إثيريوم يمكن لجهاز التسلسل L2 نشر بيانات DA إلى داخل السلسلة Celestia ، إذا وقع عليها 2/3 من عقدة Celestia ، فإن العقد الحصري Layer2 المنشور على إثيريوم يعتقد أن جهاز التسلسل يصدر بيانات DA بصدق ، وهو في الواقع السماح ل Celestia العقدة بالعمل كضامن. بالنظر إلى أن Celestia لديها المئات من عقد المدقق ، يمكننا اعتبار DAC الكبير هذا لامركزية نسبيا.
** حل DA الذي تستخدمه Merlin هو في الواقع قريب من BlobStream من Celestia ، والذي يفتح حقوق الوصول إلى DAC في شكل نقاط البيع لجعلها تميل إلى اللامركزية. يمكن لأي شخص تشغيل العقدة DAC بنفس طويل لأنه التكديس أصول كافية. في وثائق Merlin ، يشار إلى العقدة DAC أعلاه باسم Oracle ، ويشار إلى أنه سيتم دعم تخزين الأصول ل BTC و MERL وحتى BRC-20 Tokens ، مما يتيح آلية تخزين مرنة ، بالإضافة إلى تخزين الوكيل على غرار Lido. (التكديس بروتوكول نقاط البيع الخاصة ب آلة أوراكل هي في الأساس واحدة من روايات ميرلين الأساسية التالية ، التكديس معدل الفائدة المقدمة مرتفعة نسبيا)
** فيما يلي وصف موجز لسير عمل Merlin (الصورة أدناه) :* *
بعد تلقي عدد كبير من طلبات المعاملات ، يقوم جهاز التسلسل بتجميعها وإنشاء دفعة بيانات ، والتي يتم تمريرها إلى العقدة Prover و Oracle العقدة (اللامركزية DAC).
العقدة Prover من Merlin اللامركزية ، باستخدام Lumoz's Prover كخدمة خدمة. بعد تلقي أطول دفعات البيانات ، سيقوم مجمع تعدين Prover بإنشاء zk-SNARKs المقابلة ، وبعد ذلك سيتم إرسال ZKP إلى العقدة Oracle للتحقق منه.
سيتحقق العقدة Oracle مما إذا كان دليل ZK المرسل بواسطة مجمع التعدين ZK الخاص ب Lmuoz يتوافق مع دفعة البيانات المرسلة بواسطة Sequencer. إذا كان من الممكن مراسلة الاثنين ، ولا توجد أخطاء أخرى ، يتم التحقق منها. في هذه العملية ، ستقوم اللامركزية Oracle Nodes بإنشاء توقيعات أطول من خلال توقيعات العتبة ، وتعلن خارجيا - قام جهاز التسلسل بإصدار بيانات DA بالكامل ، ويكون ZKP المقابل صالحا ، والذي اجتاز التحقق من Oracle العقدة.
يجمع جهاز التسلسل نتائج توقيع طويل من العقدة Oracle ، وعندما يفي عدد التوقيعات بمتطلبات العتبة ، فإنه يرسل معلومات التوقيع إلى بيتكوين داخل السلسلة ، مع تجزئة بيانات دفعة بيانات DA ، ويسلمها إلى العالم الخارجي لقراءتها وتأكيدها.
العقدة Oracle معالجة خاصة لعملية الحساب الخاصة بها للتحقق من ZK Proof ، وإنشاء التزام التزام ، وإرساله إلى بيتكوين داخل السلسلة ، والسماح لأي شخص بتحدي "الالتزام" ، والعملية في هذه العملية هي في الأساس نفس دليل على الاحتيال بروتوكول bitVM. إذا نجح التحدي ، فسيتم معاقبة العقدة Oracle التي تنشر الالتزام ماليا. بالطبع ، يجب نشر البيانات التي تريد Oracle نشرها على بيتكوين داخل السلسلة ، بما في ذلك التجزئة الحالة طبقة 2 الحالية - StateRoot ، و ZKP نفسها ، على بيتكوين داخل السلسلة حتى يكتشفها العالم الخارجي.
لا تزال هناك بعض التفاصيل التي تحتاج إلى توضيح ، أولا وقبل كل شيء ، تشير خارطة طريق Merlin إلى أنه في المستقبل ، ستقوم Oracle بعمل نسخة احتياطية من بيانات DA إلى Celestia ، بحيث يمكن ل Oracle العقدة التخلص من البيانات التاريخية المحلية بشكل صحيح ولا تحتاج إلى الاحتفاظ بالبيانات محليا إلى الأبد. في الوقت نفسه ، فإن الالتزام الذي تم إنشاؤه بواسطة Oracle Network هو في الواقع جذر شجرة ميركل ، ولا يكفي الكشف عن الجذر للعالم الخارجي ، ولكن للكشف عن جميع مجموعات البيانات الكاملة المقابلة للالتزام ، من الضروري العثور على منصة DA تابعة لجهة خارجية ، والتي يمكن أن تكون Celestia أو EigenDA أو طبقات DA أخرى.
تحليل نموذج الأمان: خدمة MPC ZKRollup + Cobo المتفائلة
لقد وصفنا أعلاه بإيجاز سير عمل Merlin ، وأعتقد أن لديك بالفعل فهما جيدا لهيكله الأساسي. ليس من الصعب أن نرى أن Merlin يتبع بشكل أساسي نفس نموذج الأمان مثل B ^ Square و BitLayer و Citrea - ZK-Rollup المتفائل.
القراءة الأولى لهذه الكلمة قد تجعل العديد من المتحمسين طويل إثيريوم يشعرون بالغرابة ، ما هو "ZK-Rollup المتفائل"؟ في إدراك المجتمع إثيريوم ، يعتمد "النموذج النظري" ل ZK Rollup بالكامل على موثوقية الحسابات التشفير ، وليس هناك حاجة لتقديم افتراضات الثقة ، وكلمة التفاؤل تقدم افتراضات الثقة بدقة ، مما يعني أن الناس يجب أن يكونوا متفائلين بأن Rollups ليست خاطئة وموثوقة عندما طويل عدد كبير من المرات. وبمجرد حدوث خطأ ، يمكن معاقبة مشغل Rollup بواسطة دليل على الاحتيال ، وهو أصل اسم Optimistic Rollup ، المعروف أيضا باسم OP Rollup.
بالنسبة للنظام البيئي إثيريوم لقاعدة Rollup الرئيسية ، قد يكون ZK-Rollup المتفائل غير عادي بعض الشيء ، ولكن هذا يتماشى تماما مع الوضع الحالي بيتكوين طبقة 2. نظرا للقيود الفنية ، لا يمكن بيتكوين داخل السلسلة التحقق بشكل كامل من ZK Proof ، ولا يمكنه التحقق إلا من خطوة معينة من عملية حساب ZKP في ظل ظروف خاصة ، في ظل هذه الفرضية ، يمكن بيتكوين داخل السلسلة في الواقع الدعم دليل على الاحتيال بروتوكول فقط ، يمكن للناس الإشارة إلى أن ZKP في عملية التحقق خارج السلسلة ، خطوة حسابية معينة بها خطأ ، ومن خلال الطريقة دليل على الاحتيال للتحدي ، بالطبع ، لا يمكن مقارنة ذلك ب ZK Rollup على غرار إثيريوم ، ولكنه بيتكوين بالفعل الأكثر موثوقية و أقوى نموذج أمان.
بموجب مخطط ZK-Rollup المتفائل أعلاه ، بافتراض وجود منافسين معتمدين من N في شبكة طبقة 2 ، حيث أن طويل 1 من منافسي N هؤلاء صادقون وموثوقون ، ويمكنهم اكتشاف الأخطاء وبدء دليل على الاحتيال في أي وقت ، فإن انتقال حالة طبقة 2 آمن. بالطبع ، يحتاج مجموعات المتفائلون بدرجة عالية نسبيا من الإنجاز إلى التأكد من أن جسور السحب الخاصة بهم محمية أيضا من قبل دليل على الاحتيال بروتوكول ، وفي الوقت الحالي ، لا يستطيع جميع بيتكوين طبقة 2 تقريبا تحقيق هذه الفرضية ويحتاجون إلى الاعتماد على توقيع / MPC طويل ، لذلك أصبحت كيفية اختيار طويل التوقيع / حل MPC مشكلة مرتبطة ارتباطا وثيقا بأمن طبقة 2.
اختارت ميرلين خدمة Cobo MPC على مخطط الجسر ، باستخدام تدابير مثل عزل المحفظة الباردة والساخنة ، وتدار أصول الجسور بشكل مشترك من قبل Cobo و Merlin Chain ، ويجب التعامل مع أي سحب بشكل مشترك من قبل المشاركين MPC في Cobo و Merlin Chain ، مما يضمن بشكل أساسي موثوقية السحب الجسر من خلال المصادقة الائتمانية للمؤسسة. بالطبع ، هذا مجرد إجراء مؤقت في هذه المرحلة ، ومع التحسين التدريجي للمشروع ، يمكن استبدال الجسر الانسحاب ب "الجسر المتفائل" لافتراض الثقة 1 / N من خلال إدخال BitVM و دليل على الاحتيال بروتوكول ، ولكن سيكون من الصعب الهبوط (في الوقت الحالي ، تعتمد جميع الجسور الرسمية Layer2 تقريبا على علامة طويل).
على العموم ، يمكننا فرز أن Merlin قد قدمت DAC قائما على نقاط البيع ، و ZK-Rollup متفائلا يعتمد على BitVM ، وحل حفظ الأصول MPC يعتمد على Cobo ، وحل مشكلة DA عن طريق فتح أذونات DAC ، وضمان أمان انتقال الحالة من خلال تقديم BitVM و دليل على الاحتيال بروتوكول ، وضمان موثوقية الجسر السحب من خلال تقديم الخدمة MPC لمنصة حفظ الأصول المعروفة Cobo.
مخطط تقديم ZKP للتحقق من خطوتين قائم على Lumoz
في وقت سابق ، قمنا بتمشيط نموذج أمان Merlin وقدمنا مفهوم ZK-rollup المتفائل. في خارطة طريق تكنولوجيا Merlin ، تمت مناقشة اللامركزية Prover أيضا. كما نعلم جميعا ، يعد Prover دورا أساسيا في بنية ZK-Rollup ، وهو المسؤول عن إنشاء ZKProofs للدفعات التي أصدرها Sequencer ، وعملية توليد zk-SNARKs كثيفة الاستخدام لموارد الأجهزة ومشكلة صعبة للغاية.
لتسريع توليد براهين ZK ، يعد موازاة المهمة واحدة من أكثر العمليات الأساسية. ** ما يسمى بالتوازي هو في الواقع تقسيم مهمة توليد إثبات ZK إلى أجزاء مختلفة ، والتي يتم إكمالها بشكل منفصل بواسطة Provers مختلفة ، وأخيرا يقوم مجمع المجمع بتجميع أطول إثبات في الكل.
في طلب لتسريع عملية توليد براهين ZK ، ستستخدم Merlin Lumoz's Prover كحل خدمة ، وهو في الواقع جمع عدد كبير من الأجهزة معا لتشكيل تجمع تعدين ، ثم تعيين مهام الحوسبة لأجهزة مختلفة وتعيين الحوافز المقابلة ، على غرار تعدين أسرى الحرب.
في مخطط اللامركزية Prover هذا ، هناك فئة من سيناريوهات الهجوم ، والمعروفة باسم الهجمات الأمامية: لنفترض أن المجمع قد شكل ZKP ، ويرسل ZKP على أمل الحصول على مكافأة. بعد أن رأى المجمعين الآخرين محتوى ZKP ، هرعوا لنشر نفس المحتوى أمامه ، مدعين أن ZKP هذا من صنع زوجهم ، وكيفية حل هذا الموقف؟
أحد أكثر الحلول الغريزية التي قد تتبادر إلى الذهن هو تعيين رقم مهمة محدد لكل مجمع ، على سبيل المثال ، يمكن للمجمع A فقط تولي المهمة 1 ، ولن يحصل أي شخص آخر على مكافأة حتى لو أكملوا المهمة 1. لكن إحدى مشاكل هذا النهج هي أنه لا يحمي من نقطة خطر واحدة. إذا كان المجمع A يعاني من فشل في الأداء أو قطع الاتصال، فستكون المهمة 1 عالقة وغير قادرة على الإكمال. وعلاوة على ذلك، فإن هذه الممارسة المتمثلة في إسناد المهام إلى كيان واحد ليست طريقة جيدة لتحسين الإنتاجية بحوافز تنافسية.
اقترحت Polygon zkEVM طريقة تسمى إثبات الكفاءة في منشور مدونة ، والتي تنص على أنه يجب ترقية المجمعين المختلفين للتنافس مع بعضهم البعض بطريقة تنافسية ، وأنه يجب توزيع الحوافز على أساس من يأتي أولا يخدم أولا ، وأن أول المجمعين الذين يقدمون ZK-Proof إلى السلسلة يمكنهم الحصول على مكافآت. بالطبع ، لم يذكر كيفية حل مشكلة MEV الأمامية.
يستخدم Lumoz طريقة تقديم إثبات ZK للتحقق من خطوتين ، بعد أن يقوم المجمع بإنشاء دليل ZK ، لا يحتاج إلى إرسال المحتوى الكامل ، ولكنه ينشر فقط التجزئة ZKP ، بمعنى آخر ، ينشر التجزئة (ZKP + Aggregator العنوان). بهذه الطريقة ، حتى لو رأى الآخرون القيمة التجزئة ، فإنهم لا يعرفون محتوى ZKP المقابل ولا يمكنهم التسرع فيه مباشرة ؛
إذا قام شخص ما ببساطة بنسخ التجزئة بالكامل ونشره أولا ، فهذا لا معنى له ، لأن التجزئة يحتوي على العنوان مجمع معين X ، وحتى إذا نشر المجمع A التجزئة أولا ، عندما يتم الكشف عن الصورة الأصلية ل التجزئة ، سيرى الجميع أن المجمع العنوان الموجود فيه هو X وليس A.
من خلال مخطط تقديم ZKP للتحقق المكون من خطوتين ، يمكن ل Merlin (Lumoz) حل مشكلة التشغيل الأمامي في عملية تقديم ZKP ، ثم تحقيق حوافز توليد zk-SNARKs تنافسية للغاية ، وبالتالي تحسين سرعة توليد ZKP.
فانتوم ميرلين: أطول سلسلة قابلية للتشغيل البيني
وفقا لخارطة الطريق الفنية ل Merlin ، فإنها س الدعم أيضا قابلية التشغيل البيني بين Merlin وسلاسل EVM الأخرى ، ومسار تنفيذها هو في الأساس نفس فكرة Zetachain السابقة ، إذا تم استخدام Merlin كسلسلة مصدر وتم استخدام سلاسل EVM الأخرى كسلسلة مستهدفة ، عندما تدرك Merlin العقدة طلب التشغيل البيني عبر السلاسل الذي قدمه المستخدم ، فسيؤدي ذلك إلى تشغيل سير العمل اللاحق على داخل السلسلة الهدف.
على سبيل المثال ، يمكن نشر الحساب EOA التي تتحكم فيها شبكة Merlin على Polygon ، ** عندما ينشر المستخدم تعليمات التشغيل البيني عبر السلاسل على Merlin Chain ، تقوم شبكة Merlin أولا بتحليل محتواها وإنشاء بيانات معاملة يتم تنفيذها على داخل السلسلة الهدف ، ثم تقوم معالجة توقيع Oracle Network MPC على المعاملة بإنشاء توقيع رقمي للمعاملة. ثم تقوم شركة Merlin's Relayer العقدة بتحرير المعاملة ** على Polygon ، واستكمال العمليات اللاحقة من خلال أصول Merlin في EOA الحساب على داخل السلسلة المستهدف.
عند اكتمال العملية المطلوبة من قبل المستخدم ، سيتم إعادة توجيه الأصل المقابل مباشرة إلى عنوان المستخدم في داخل السلسلة الهدف ، ومن الناحية النظرية يمكن أيضا العبور مباشرة إلى سلسلة Merlin. يتميز هذا الحل ببعض المزايا الواضحة: يمكنه تجنب تآكل الرسوم الناتجة عن عبر السلاسل الأصول التقليدية وعقود الجسور عبر السلسلة ، وهو مضمون مباشرة من قبل شبكة Oracle من Merlin لضمان أمان عمليات عبر السلاسل ، ولا حاجة أطول إلى الاعتماد على البنية التحتية الخارجية. طويل يثق المستخدمون في Merlin Chain ، فلا توجد مشكلة في التخلف عن مثل هذه عبر السلاسل التشغيل البيني.
ملخص
في هذه المقالة ، نقدم شرحا موجزا للحل التقني العام لسلسلة Merlin ، والذي يعتقد أنه يساعد الأشخاص الأكثر طويل على فهم سير العمل العام لشركة Merlin والحصول على فهم أوضح لنموذج الأمان الخاص بها. بالنظر إلى البيئة بيتكوين الحالية على قدم وساق ، نعتقد أن هذا النوع من سلوك تعميم العلوم التقنية قيم ويحتاجه عامة الناس ، ** سنجري متابعة طويل المدى على Merlin و bitLayer و B ^ Square ومشاريع أخرى في المستقبل ** ، ونجري تحليلا أكثر تعمقا لحلولها التقنية ، لذلك ترقبوا كل جديد!
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
التفسير الفني لآلية تشغيل ميرلين
المؤلف: فاوست ، المهوس web3
من صيف النقوش في عام 2023 حتى الوقت الحاضر ، كان بيتكوين طبقة 2 دائما أبرز ما في Web3 بأكمله. على الرغم من أن ارتفع هذا المجال متأخر كثيرا عن طبقة 2 في عام إثيريوم ، مع السحر الفريد لأسرى الحرب والهبوط السلس فوري ETF ، فإن بيتكوين دون النظر في خطر "التوريق" قد اجتذب انتباه عشرات المليارات من الدولارات من رأس المال للمسار المشتق طبقة 2 في نصف عام فقط.
في المسار بيتكوين طبقة 2 ، فإن Merlin ، التي لديها مليارات الدولارات في TVL ، هي بلا شك صاحبة أكبر الحجم وأكثر المتابعين طويل. مع حوافز تخزين واضحة وعائد لائق ، ظهرت Merlin في غضون أشهر تقريبا ، مما خلق أسطورة بيئية تتجاوز Blast. مع تزايد شعبية Merlin ، أصبحت مناقشة حلولها التقنية موضوعا طويل بشكل متزايد.
في هذه المقالة ، سيركز Geek Web3 على الحلول التقنية ل Merlin Chain ، وتفسير مستنداتها المنشورة وأفكار تصميم بروتوكول ، ونحن ملتزمون بالسماح لمزيد من الأشخاص طويل بفهم سير العمل العام لشركة Merlin والحصول على فهم أوضح لنموذج الأمان الخاص بها ، بحيث يمكن للجميع فهم كيفية عمل "بيتكوين طبقة 2 الرأس" بطريقة أكثر سهولة.
شبكة ميرلين شبكة أوراكل اللامركزية: مجلس مفتوح خارج السلسلة لجنة المساعدة الإنمائية
بالنسبة لجميع الطبقة 2 ، سواء كانت إثيريوم طبقة 2 أو بيتكوين طبقة 2 ، تعد تكاليف DA ونشر البيانات واحدة من أهم المشكلات التي يجب حلها. نظرا لأطول مشاكل شبكة بيتكوين نفسها ، والتي لا الدعم بطبيعتها إنتاجية كبيرة للبيانات ، أصبحت كيفية استخدام شورت DA هذا مشكلة صعبة لاختبار خيال طبقة 2 المشاريع.
أحد الاستنتاجات واضح: إذا طبقة 2 تنشر "مباشرة" بيانات المعاملات غير المعالجة إلى بيتكوين كتلة ، فلن تكون قادرة على تحقيق إنتاجية عالية أو رسوم منخفضة. الحل الأكثر شيوعا هو إما ضغط حجم البيانات إلى أصغر حجم ممكن من خلال الضغط العالي وتحميلها على بيتكوين كتلة ، أو نشر البيانات مباشرة على بيتكوين خارج السلسلة. **
من المحتمل أن تكون الطبقات طبقة 2 الأكثر شهرة التي تتخذ النهج الأول هي Citrea ، والتي تعتزم تحميل فرق الحالة لعام طبقة 2 على مدار فترة زمنية ، أي نتائج تغيير الحالة على طويل الحساب ، جنبا إلى جنب مع براهين ZK المقابلة ، إلى بيتكوين داخل السلسلة. في هذه الحالة ، يمكن لأي شخص تنزيل فرق الحالة و ZKP من بيتكوين الشبكة الرئيسية لمراقبة نتائج تغيير حالة Citrea. يمكن أن تقلل هذه الطريقة من حجم البيانات على السلسلة بأكثر من 90٪.
في حين أن هذا يمكن أن يقلل بشكل كبير من حجم البيانات ، إلا أن عنق الزجاجة لا يزال كبيرا. في حالة حدوث عدد كبير من تغييرات حالة الحساب في فترة زمنية قصير ، يحتاج طبقة 2 إلى تلخيص وتحميل جميع التغييرات في هذه الحساب إلى بيتكوين داخل السلسلة ، ولا يمكن الاحتفاظ بتكلفة إصدار البيانات النهائية منخفضة للغاية ، والتي يمكن رؤيتها في طويل إثيريوم ZK Rollup.
من طويل بيتكوين طبقة 2 جدا اتخاذ المسار الثاني ببساطة: استخدام حل DA بيتكوين خارج السلسلة مباشرة ، إما بناء طبقة DA بمفردها ، أو استخدام Celestia ، EigenDA ، إلخ. B ^ Square و BitLayer و Merlin ، بطل الرواية في هذه المقالة ، جميعهم يتبعون مخطط تحجيم DA خارج السلسلة هذا.
في المقالة السابقة ل Geek web3 - "تحليل الإصدار الجديد من خارطة طريق التكنولوجيا B ^ 2: ضرورة بيتكوين خارج السلسلة DA وطبقة التحقق" ، ذكرنا أن ** B ^ 2 يقلد Celestia مباشرة ويبني شبكة DA تدعم وظيفة أخذ عينات البيانات في خارج السلسلة ، المسماة B ^ 2 Hub. يتم تخزين "بيانات DA" مثل بيانات المعاملة أو فرق الحالة في بيتكوين خارج السلسلة ، ويتم تحميل جذر datahash / merkle فقط إلى بيتكوين الشبكة الرئيسية. **
إنها حقا تتعامل مع بيتكوين كلوحة إعلانات عديم الثقة: يمكن لأي شخص قراءة تجزئة البيانات من بيتكوين داخل السلسلة. ** عندما تحصل على بيانات DA من مزود بيانات خارج السلسلة ، يمكنك التحقق مما إذا كانت تتوافق مع داخل السلسلة datahash ** ، أي التجزئة(data1) == datahash1 ?. إذا كان هناك تطابق بين الاثنين ، فهذا يعني أن مزود البيانات بموجب خارج السلسلة أعطاك البيانات الصحيحة.
يمكن أن تضمن العملية المذكورة أعلاه أن البيانات المقدمة لك من قبل خارج السلسلة العقدة مرتبطة ببعض "القرائن" على الطبقة 1 ، مما يمنع طبقة DA من تقديم بيانات خاطئة بشكل ضار. ولكن هناك سيناريو دبوس مهم للغاية هنا: ماذا لو لم يرسل مصدر البيانات ، Sequencer ، البيانات المقابلة لتجزئة البيانات على الإطلاق ، ولكنه يرسل فقط تجزئة البيانات إلى بيتكوين داخل السلسلة ، ولكنه يحجب عمدا البيانات المقابلة عن أي شخص لقراءتها؟
تتضمن السيناريوهات المماثلة ، على سبيل المثال لا الحصر ، نشر ZK-Proof و StateRoot فقط ، ولكن لا تنشر بيانات DA المقابلة (فرق الحالة أو بيانات المعاملة) ، على الرغم من أنه يمكن للأشخاص التحقق من صحة عملية حساب ZKProof ، والتأكد من أن عملية الحساب من Prev \ _Stateroot إلى New \ _Stateroot صالحة ، لكنهم لا يعرفون أي حالة الحساب (ولاية) قد تغيرت. في هذه الحالة ، على الرغم من أن أصول المستخدم آمنة ، لا يمكنك تحديد الحالة الفعلية للشبكة على الإطلاق ، ولا تعرف المعاملات التي تم حزمها على السلسلة والعقود التي تم تحديثها.
هذا في الواقع ** "حجب البيانات **" ، وناقش Dankrad من مؤسسة إثيريوم لفترة وجيزة مشكلة مماثلة على Twitter في أغسطس 2023 ، بالطبع ، فهو شمعة طويلة الفتيل بشكل أساسي لشيء يسمى "DAC".
الأطول إثيريوم Layer2 ، التي تتبنى حلول DA خارج السلسلة ، غالبا ما تنشئ عدة عقد بأذونات خاصة لتشكيل لجنة ، الاسم الكامل للجنة توافر البيانات (DAC). تعمل لجنة DAC هذه كضامن ، مدعية أن Sequencer تنشر بيانات DA الكاملة (بيانات المعاملة أو فرق الحالة) خارج السلسلة. ثم يقوم العقدة DAC بشكل جماعي بإنشاء أطول ، حيث طويل أن الأطول يفي بمتطلبات العتبة (مثل 2/4) ، فإن العقد ذي الصلة في الطبقة 1 سيتخلف عن السداد الافتراضي ، وقد اجتاز Sequencer فحص لجنة DAC وأصدر بصدق بيانات DA الكاملة خارج السلسلة.
تتبع لجنة إثيريوم طبقة 2 DAC بشكل أساسي نموذج التوكيل الرسمي ، مما يسمح فقط لعدد قليل من العقد توثيق KYC أو المعينة رسميا بالانضمام إلى لجنة DAC ، مما يجعل DAC مرادفا ل "مركزي" و "كونسورتيوم blockchain". بالإضافة إلى ذلك ، في بعض إثيريوم طبقة 2 التي تعتمد نموذج DAC ، يرسل جهاز التسلسل بيانات DA فقط إلى العقد الأعضاء في DAC ، ولا يقوم أبدا بتحميل البيانات في مكان آخر ، ويجب على أي شخص يريد الحصول على بيانات DA الحصول على إذن من لجنة DAC ، والتي لا تختلف اختلافا جوهريا عن كونسورتيوم بلوكتشين.
ليس هناك شك في أنه يجب اللامركزية DAC ، ولا يمكن طبقة 2 تحميل بيانات DA مباشرة إلى الطبقة 1 ، ولكن يجب أن تكون سلطة الوصول للجنة DAC مفتوحة للعالم الخارجي لمنع عدد قليل من الأشخاص من التواطؤ لفعل الشر. (لمناقشة سيناريو الأذى في لجنة المساعدة الإنمائية، يرجى الرجوع إلى بيان دانكراد السابق على تويتر)
** BlobStream ، الذي اقترحته Celestia سابقا ، هو في الأساس استبدال DAC المركزي ب Celestia ، ** إثيريوم يمكن لجهاز التسلسل L2 نشر بيانات DA إلى داخل السلسلة Celestia ، إذا وقع عليها 2/3 من عقدة Celestia ، فإن العقد الحصري Layer2 المنشور على إثيريوم يعتقد أن جهاز التسلسل يصدر بيانات DA بصدق ، وهو في الواقع السماح ل Celestia العقدة بالعمل كضامن. بالنظر إلى أن Celestia لديها المئات من عقد المدقق ، يمكننا اعتبار DAC الكبير هذا لامركزية نسبيا.
** حل DA الذي تستخدمه Merlin هو في الواقع قريب من BlobStream من Celestia ، والذي يفتح حقوق الوصول إلى DAC في شكل نقاط البيع لجعلها تميل إلى اللامركزية. يمكن لأي شخص تشغيل العقدة DAC بنفس طويل لأنه التكديس أصول كافية. في وثائق Merlin ، يشار إلى العقدة DAC أعلاه باسم Oracle ، ويشار إلى أنه سيتم دعم تخزين الأصول ل BTC و MERL وحتى BRC-20 Tokens ، مما يتيح آلية تخزين مرنة ، بالإضافة إلى تخزين الوكيل على غرار Lido. (التكديس بروتوكول نقاط البيع الخاصة ب آلة أوراكل هي في الأساس واحدة من روايات ميرلين الأساسية التالية ، التكديس معدل الفائدة المقدمة مرتفعة نسبيا)
** فيما يلي وصف موجز لسير عمل Merlin (الصورة أدناه) :* *
العقدة Oracle معالجة خاصة لعملية الحساب الخاصة بها للتحقق من ZK Proof ، وإنشاء التزام التزام ، وإرساله إلى بيتكوين داخل السلسلة ، والسماح لأي شخص بتحدي "الالتزام" ، والعملية في هذه العملية هي في الأساس نفس دليل على الاحتيال بروتوكول bitVM. إذا نجح التحدي ، فسيتم معاقبة العقدة Oracle التي تنشر الالتزام ماليا. بالطبع ، يجب نشر البيانات التي تريد Oracle نشرها على بيتكوين داخل السلسلة ، بما في ذلك التجزئة الحالة طبقة 2 الحالية - StateRoot ، و ZKP نفسها ، على بيتكوين داخل السلسلة حتى يكتشفها العالم الخارجي.
لا تزال هناك بعض التفاصيل التي تحتاج إلى توضيح ، أولا وقبل كل شيء ، تشير خارطة طريق Merlin إلى أنه في المستقبل ، ستقوم Oracle بعمل نسخة احتياطية من بيانات DA إلى Celestia ، بحيث يمكن ل Oracle العقدة التخلص من البيانات التاريخية المحلية بشكل صحيح ولا تحتاج إلى الاحتفاظ بالبيانات محليا إلى الأبد. في الوقت نفسه ، فإن الالتزام الذي تم إنشاؤه بواسطة Oracle Network هو في الواقع جذر شجرة ميركل ، ولا يكفي الكشف عن الجذر للعالم الخارجي ، ولكن للكشف عن جميع مجموعات البيانات الكاملة المقابلة للالتزام ، من الضروري العثور على منصة DA تابعة لجهة خارجية ، والتي يمكن أن تكون Celestia أو EigenDA أو طبقات DA أخرى.
تحليل نموذج الأمان: خدمة MPC ZKRollup + Cobo المتفائلة
لقد وصفنا أعلاه بإيجاز سير عمل Merlin ، وأعتقد أن لديك بالفعل فهما جيدا لهيكله الأساسي. ليس من الصعب أن نرى أن Merlin يتبع بشكل أساسي نفس نموذج الأمان مثل B ^ Square و BitLayer و Citrea - ZK-Rollup المتفائل.
القراءة الأولى لهذه الكلمة قد تجعل العديد من المتحمسين طويل إثيريوم يشعرون بالغرابة ، ما هو "ZK-Rollup المتفائل"؟ في إدراك المجتمع إثيريوم ، يعتمد "النموذج النظري" ل ZK Rollup بالكامل على موثوقية الحسابات التشفير ، وليس هناك حاجة لتقديم افتراضات الثقة ، وكلمة التفاؤل تقدم افتراضات الثقة بدقة ، مما يعني أن الناس يجب أن يكونوا متفائلين بأن Rollups ليست خاطئة وموثوقة عندما طويل عدد كبير من المرات. وبمجرد حدوث خطأ ، يمكن معاقبة مشغل Rollup بواسطة دليل على الاحتيال ، وهو أصل اسم Optimistic Rollup ، المعروف أيضا باسم OP Rollup.
بالنسبة للنظام البيئي إثيريوم لقاعدة Rollup الرئيسية ، قد يكون ZK-Rollup المتفائل غير عادي بعض الشيء ، ولكن هذا يتماشى تماما مع الوضع الحالي بيتكوين طبقة 2. نظرا للقيود الفنية ، لا يمكن بيتكوين داخل السلسلة التحقق بشكل كامل من ZK Proof ، ولا يمكنه التحقق إلا من خطوة معينة من عملية حساب ZKP في ظل ظروف خاصة ، في ظل هذه الفرضية ، يمكن بيتكوين داخل السلسلة في الواقع الدعم دليل على الاحتيال بروتوكول فقط ، يمكن للناس الإشارة إلى أن ZKP في عملية التحقق خارج السلسلة ، خطوة حسابية معينة بها خطأ ، ومن خلال الطريقة دليل على الاحتيال للتحدي ، بالطبع ، لا يمكن مقارنة ذلك ب ZK Rollup على غرار إثيريوم ، ولكنه بيتكوين بالفعل الأكثر موثوقية و أقوى نموذج أمان.
بموجب مخطط ZK-Rollup المتفائل أعلاه ، بافتراض وجود منافسين معتمدين من N في شبكة طبقة 2 ، حيث أن طويل 1 من منافسي N هؤلاء صادقون وموثوقون ، ويمكنهم اكتشاف الأخطاء وبدء دليل على الاحتيال في أي وقت ، فإن انتقال حالة طبقة 2 آمن. بالطبع ، يحتاج مجموعات المتفائلون بدرجة عالية نسبيا من الإنجاز إلى التأكد من أن جسور السحب الخاصة بهم محمية أيضا من قبل دليل على الاحتيال بروتوكول ، وفي الوقت الحالي ، لا يستطيع جميع بيتكوين طبقة 2 تقريبا تحقيق هذه الفرضية ويحتاجون إلى الاعتماد على توقيع / MPC طويل ، لذلك أصبحت كيفية اختيار طويل التوقيع / حل MPC مشكلة مرتبطة ارتباطا وثيقا بأمن طبقة 2.
اختارت ميرلين خدمة Cobo MPC على مخطط الجسر ، باستخدام تدابير مثل عزل المحفظة الباردة والساخنة ، وتدار أصول الجسور بشكل مشترك من قبل Cobo و Merlin Chain ، ويجب التعامل مع أي سحب بشكل مشترك من قبل المشاركين MPC في Cobo و Merlin Chain ، مما يضمن بشكل أساسي موثوقية السحب الجسر من خلال المصادقة الائتمانية للمؤسسة. بالطبع ، هذا مجرد إجراء مؤقت في هذه المرحلة ، ومع التحسين التدريجي للمشروع ، يمكن استبدال الجسر الانسحاب ب "الجسر المتفائل" لافتراض الثقة 1 / N من خلال إدخال BitVM و دليل على الاحتيال بروتوكول ، ولكن سيكون من الصعب الهبوط (في الوقت الحالي ، تعتمد جميع الجسور الرسمية Layer2 تقريبا على علامة طويل).
على العموم ، يمكننا فرز أن Merlin قد قدمت DAC قائما على نقاط البيع ، و ZK-Rollup متفائلا يعتمد على BitVM ، وحل حفظ الأصول MPC يعتمد على Cobo ، وحل مشكلة DA عن طريق فتح أذونات DAC ، وضمان أمان انتقال الحالة من خلال تقديم BitVM و دليل على الاحتيال بروتوكول ، وضمان موثوقية الجسر السحب من خلال تقديم الخدمة MPC لمنصة حفظ الأصول المعروفة Cobo.
مخطط تقديم ZKP للتحقق من خطوتين قائم على Lumoz
في وقت سابق ، قمنا بتمشيط نموذج أمان Merlin وقدمنا مفهوم ZK-rollup المتفائل. في خارطة طريق تكنولوجيا Merlin ، تمت مناقشة اللامركزية Prover أيضا. كما نعلم جميعا ، يعد Prover دورا أساسيا في بنية ZK-Rollup ، وهو المسؤول عن إنشاء ZKProofs للدفعات التي أصدرها Sequencer ، وعملية توليد zk-SNARKs كثيفة الاستخدام لموارد الأجهزة ومشكلة صعبة للغاية.
لتسريع توليد براهين ZK ، يعد موازاة المهمة واحدة من أكثر العمليات الأساسية. ** ما يسمى بالتوازي هو في الواقع تقسيم مهمة توليد إثبات ZK إلى أجزاء مختلفة ، والتي يتم إكمالها بشكل منفصل بواسطة Provers مختلفة ، وأخيرا يقوم مجمع المجمع بتجميع أطول إثبات في الكل.
في طلب لتسريع عملية توليد براهين ZK ، ستستخدم Merlin Lumoz's Prover كحل خدمة ، وهو في الواقع جمع عدد كبير من الأجهزة معا لتشكيل تجمع تعدين ، ثم تعيين مهام الحوسبة لأجهزة مختلفة وتعيين الحوافز المقابلة ، على غرار تعدين أسرى الحرب.
في مخطط اللامركزية Prover هذا ، هناك فئة من سيناريوهات الهجوم ، والمعروفة باسم الهجمات الأمامية: لنفترض أن المجمع قد شكل ZKP ، ويرسل ZKP على أمل الحصول على مكافأة. بعد أن رأى المجمعين الآخرين محتوى ZKP ، هرعوا لنشر نفس المحتوى أمامه ، مدعين أن ZKP هذا من صنع زوجهم ، وكيفية حل هذا الموقف؟
أحد أكثر الحلول الغريزية التي قد تتبادر إلى الذهن هو تعيين رقم مهمة محدد لكل مجمع ، على سبيل المثال ، يمكن للمجمع A فقط تولي المهمة 1 ، ولن يحصل أي شخص آخر على مكافأة حتى لو أكملوا المهمة 1. لكن إحدى مشاكل هذا النهج هي أنه لا يحمي من نقطة خطر واحدة. إذا كان المجمع A يعاني من فشل في الأداء أو قطع الاتصال، فستكون المهمة 1 عالقة وغير قادرة على الإكمال. وعلاوة على ذلك، فإن هذه الممارسة المتمثلة في إسناد المهام إلى كيان واحد ليست طريقة جيدة لتحسين الإنتاجية بحوافز تنافسية.
اقترحت Polygon zkEVM طريقة تسمى إثبات الكفاءة في منشور مدونة ، والتي تنص على أنه يجب ترقية المجمعين المختلفين للتنافس مع بعضهم البعض بطريقة تنافسية ، وأنه يجب توزيع الحوافز على أساس من يأتي أولا يخدم أولا ، وأن أول المجمعين الذين يقدمون ZK-Proof إلى السلسلة يمكنهم الحصول على مكافآت. بالطبع ، لم يذكر كيفية حل مشكلة MEV الأمامية.
يستخدم Lumoz طريقة تقديم إثبات ZK للتحقق من خطوتين ، بعد أن يقوم المجمع بإنشاء دليل ZK ، لا يحتاج إلى إرسال المحتوى الكامل ، ولكنه ينشر فقط التجزئة ZKP ، بمعنى آخر ، ينشر التجزئة (ZKP + Aggregator العنوان). بهذه الطريقة ، حتى لو رأى الآخرون القيمة التجزئة ، فإنهم لا يعرفون محتوى ZKP المقابل ولا يمكنهم التسرع فيه مباشرة ؛
إذا قام شخص ما ببساطة بنسخ التجزئة بالكامل ونشره أولا ، فهذا لا معنى له ، لأن التجزئة يحتوي على العنوان مجمع معين X ، وحتى إذا نشر المجمع A التجزئة أولا ، عندما يتم الكشف عن الصورة الأصلية ل التجزئة ، سيرى الجميع أن المجمع العنوان الموجود فيه هو X وليس A.
من خلال مخطط تقديم ZKP للتحقق المكون من خطوتين ، يمكن ل Merlin (Lumoz) حل مشكلة التشغيل الأمامي في عملية تقديم ZKP ، ثم تحقيق حوافز توليد zk-SNARKs تنافسية للغاية ، وبالتالي تحسين سرعة توليد ZKP.
فانتوم ميرلين: أطول سلسلة قابلية للتشغيل البيني
وفقا لخارطة الطريق الفنية ل Merlin ، فإنها س الدعم أيضا قابلية التشغيل البيني بين Merlin وسلاسل EVM الأخرى ، ومسار تنفيذها هو في الأساس نفس فكرة Zetachain السابقة ، إذا تم استخدام Merlin كسلسلة مصدر وتم استخدام سلاسل EVM الأخرى كسلسلة مستهدفة ، عندما تدرك Merlin العقدة طلب التشغيل البيني عبر السلاسل الذي قدمه المستخدم ، فسيؤدي ذلك إلى تشغيل سير العمل اللاحق على داخل السلسلة الهدف.
على سبيل المثال ، يمكن نشر الحساب EOA التي تتحكم فيها شبكة Merlin على Polygon ، ** عندما ينشر المستخدم تعليمات التشغيل البيني عبر السلاسل على Merlin Chain ، تقوم شبكة Merlin أولا بتحليل محتواها وإنشاء بيانات معاملة يتم تنفيذها على داخل السلسلة الهدف ، ثم تقوم معالجة توقيع Oracle Network MPC على المعاملة بإنشاء توقيع رقمي للمعاملة. ثم تقوم شركة Merlin's Relayer العقدة بتحرير المعاملة ** على Polygon ، واستكمال العمليات اللاحقة من خلال أصول Merlin في EOA الحساب على داخل السلسلة المستهدف.
عند اكتمال العملية المطلوبة من قبل المستخدم ، سيتم إعادة توجيه الأصل المقابل مباشرة إلى عنوان المستخدم في داخل السلسلة الهدف ، ومن الناحية النظرية يمكن أيضا العبور مباشرة إلى سلسلة Merlin. يتميز هذا الحل ببعض المزايا الواضحة: يمكنه تجنب تآكل الرسوم الناتجة عن عبر السلاسل الأصول التقليدية وعقود الجسور عبر السلسلة ، وهو مضمون مباشرة من قبل شبكة Oracle من Merlin لضمان أمان عمليات عبر السلاسل ، ولا حاجة أطول إلى الاعتماد على البنية التحتية الخارجية. طويل يثق المستخدمون في Merlin Chain ، فلا توجد مشكلة في التخلف عن مثل هذه عبر السلاسل التشغيل البيني.
ملخص
في هذه المقالة ، نقدم شرحا موجزا للحل التقني العام لسلسلة Merlin ، والذي يعتقد أنه يساعد الأشخاص الأكثر طويل على فهم سير العمل العام لشركة Merlin والحصول على فهم أوضح لنموذج الأمان الخاص بها. بالنظر إلى البيئة بيتكوين الحالية على قدم وساق ، نعتقد أن هذا النوع من سلوك تعميم العلوم التقنية قيم ويحتاجه عامة الناس ، ** سنجري متابعة طويل المدى على Merlin و bitLayer و B ^ Square ومشاريع أخرى في المستقبل ** ، ونجري تحليلا أكثر تعمقا لحلولها التقنية ، لذلك ترقبوا كل جديد!