منذ "صيف النقوش" في عام 2023 ، كانت تقنيات Layer2 من Bitcoin في طليعة ثورة Web3. على الرغم من دخولها المجال في وقت متأخر عن حلول Layer2 من Ethereum ، فقد استفادت Bitcoin من الجاذبية الفريدة لأسرى الحرب والإطلاق السلس لصناديق الاستثمار المتداولة الفورية ، الخالية من مخاطر "التوريق" ، لجذب مليارات الدولارات من الاستثمارات إلى هذا القطاع المزدهر في غضون ستة أشهر فقط. من بين هؤلاء ، تبرز Merlin باعتبارها الكيان الأكثر أهمية ومتابعة في مشهد Bitcoin Layer2 ، حيث تسيطر على المليارات من القيمة الإجمالية المقفلة (TVL). بفضل حوافز التخزين الواضحة والعوائد المثيرة للإعجاب ، سرعان ما برزت Merlin إلى الصدارة ، متجاوزة حتى النظام البيئي Blast المعروف في غضون أشهر. مع تزايد الضجة حول ميرلين ، استحوذ استكشاف بنيتها التحتية التقنية على جمهور متزايد. في هذه المقالة ، يركز Geek Web3 على فك رموز الاستراتيجيات التقنية وراء Merlin Chain. من خلال تفريغ المستندات المتاحة للجمهور والأساس المنطقي وراء تصميم البروتوكول الخاص بها ، نهدف إلى إزالة الغموض عن العمليات التشغيلية لشركة Merlin وتعزيز فهم إطار الأمان الخاص بها ، مما يوفر رؤية أوضح لكيفية عمل حل Bitcoin Layer2 الرائد هذا.

شبكة ميرلين للمعرف اللامركزي: لجنة داك الخارجية المفتوحة

بالنسبة لكل تقنية Layer2 ، فإن معالجة توافر البيانات (DA) وتكلفة نشر البيانات تظل تحديًا حرجًا ، سواء كان الأمر يتعلق بـ Ethereum Layer2 أو Bitcoin Layer2. نظرًا للقيود الجوهرية لشبكة Bitcoin ، التي تعاني من إنتاج بيانات كبير ، فإن وضع استراتيجيات لاستخدام فعال لمساحة DA القيمة هو اختبار كبير لإبداع مطوري Layer2.

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

من بين أولئك الذين يستخدمون الاستراتيجية الأولى ، تبرز Citrea. وهي تهدف إلى تحميل التغييرات في حالات Layer2 على فترات زمنية معينة ، والتي تتضمن تسجيل نتائج تغييرات الحالة عبر حسابات متعددة ، جنبا إلى جنب مع إثباتات المعرفة الصفرية المقابلة (ZKPs) ، على blockchain Bitcoin. بموجب هذا الترتيب ، يمكن لأي شخص الوصول إلى اختلافات الولاية و ZKPs من شبكة Bitcoin الرئيسية لتتبع تغييرات حالة Citrea. يقلل هذا النهج بشكل فعال من حجم البيانات التي تم تحميلها إلى blockchain بأكثر من 90٪.

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

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

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

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

الطبقة DA في توضيح طبقة 2 من بيتكوين:

(مصدر الصورة: Geek web3)

يضمن هذا النظام أن تتطابق البيانات من العقد الخارجية مع "دلائل" أو أدلة محددة على الطبقة1، مما يحمي ضد إمكانية حدوث مشكلة الطبقة DA التي تقدم معلومات خاطئة. ومع ذلك، ينشأ قلق كبير إذا فشل مبتكر البيانات — المُسلسل — في توزيع البيانات الفعلية المتعلقة بتجزئة للبيانات. لنفترض أن المُسلسل ينقل فقط تجزئة البيانات إلى سلسلة كتل بيتكوين مع احتجاز البيانات المقابلة عند الوصول العام. ماذا يحدث بعد ذلك؟

افترض سيناريوهات حيث يتم نشر الإثبات ZK و StateRoot فقط، ولكن البيانات DA المرافقة (مثل diffs الحالة أو بيانات المعاملات) لا تُطلق. على الرغم من أنه من الممكن التحقق من الإثبات ZK وضمان دقة الانتقال من Prev_Stateroot إلى New_Stateroot، إلا أنه يترك مجهولًا أي حسابات تغيرت. في ظل هذه الظروف، على الرغم من أن أصول المستخدمين آمنة، إلا أن حالة الشبكة الفعلية تبقى غير واضحة. لا أحد يعلم أي المعاملات تم دمجها في سلسلة الكتل أو أي حالات العقود تم تحديثها، مما يجعل Layer2 غير فعال، تقريبًا كما لو أنه قد تم إيقافه.

يشار إلى هذه الممارسة بأنها "امتناع عن البيانات." في أغسطس 2023، بدأ Dankrad من مؤسسة Ethereum نقاشًا على تويتر حول مفهوم يعرف بـ "DAC."

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

تلتزم اللجان الرئيسية لـ Ethereum Layer2 DAC بشكل أساسي بنموذج Proof of Authority (POA)، محددة العضوية لمجموعة مختارة من العقد التي اجتازت إجراءات التحقق من الهوية (KYC) أو تم تعيينها رسميًا. لقد جعل هذا النهج من DAC علامة تجارية لـ "التمركز" و "بلوكتشين العصبة". بالإضافة إلى ذلك، في بعض Ethereum Layer2s التي تستخدم نهج DAC، يوزع السيكونسر بيانات DA فقط إلى عقد أعضاء DAC، مع انتشار خارجي محدود. ونتيجة لذلك، يجب على أي شخص يبحث عن بيانات DA الحصول على موافقة من DAC، على غرار العمل في بلوكتشين العصبة.

من الواضح أن DACs تحتاج إلى أن تكون مركزية. على الرغم من أن قد لا يكون Layer2 مطلوبًا لتحميل بيانات DA مباشرة إلى Layer1، يجب أن يكون الوصول إلى عضوية DAC علنيًا لتجنب التواطؤ وسوء السلوك من قبل عدد قليل من الأفراد. (لمزيد من المعلومات حول هذه المسألة، راجع مناقشات Dankrad السابقة على تويتر.)

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

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

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

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

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

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

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

(مخطط مبدأ عمل ميرلين المصدر: غيك ويب3)

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

المراجع:تفسير موحد لـ BitVM: كيفية التحقق من دلائل الاحتيال على سلسلة BTC

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

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

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

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

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

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

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

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

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

استراتيجية تقديم التحقق من الهوية بخطوتين لـ Lumoz ZKP

في مناقشاتنا السابقة، غمرنا إطار الأمان لميرلين واستكشفنا مفهوم التحفيزي المبتكر للتجميع ZK-rollups. عنصر رئيسي في مسار تقنيات ميرلين هو البراهين المركزية. هذا الدور حاسم ضمن هندسة التجميع ZK-Rollup، مكلف بتوليد براهين ZK للدُفعات التي يطلقها المُتسَلسل. إن إنشاء براهين المعرفة الصفرية مكلف للغاية من النواحي الموارد، مما يشكل تحديا كبيرا.

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

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

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

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

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

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

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

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

الشبح ميرلين: التوافق متعدد السلاسل

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

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

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

تلخيص

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

تنصيح:

1. يتم نسخ هذا المقال من [المتخصص في تقنية الويب3], the copyright belongs to the original author [Faust], if you have any objection to the reprint, please contact فريق تعلم جيت، سيقوم الفريق بالتعامل معه في أقرب وقت ممكن وفقا للإجراءات ذات الصلة.

2. الآراء والآراء المعبر عنها في هذه المقالة تمثل وجهات نظر الكاتب فقط ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة النسخ الأخرى من المقال بواسطة فريق Gate Learn. دون الرجوعGate.io, نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.