منذ إنشاء صناعة blockchain، ظهر عدد لا يحصى من L1/L2s، وطورت كل سلسلة عامة تقريبًا نظام DeFi البيئي الخاص بها. يتفاعل بعض الأشخاص فقط في سلاسل عامة محددة، بينما يأمل المزيد من الناس في العثور على فرص الربح مثل التداول والتعدين في سلاسل مختلفة. ومن بين هذه العوامل، أصبح تحويل الأموال عبر السلاسل ضرورة لا غنى عنها.
بالإضافة إلى المستخدمين العاديين، تحتاج العديد من أطراف المشروع أيضًا إلى تحويل الأموال بين السلاسل المختلفة، وتوجيه السيولة على السلاسل المختلفة، وتحقيق «أموال واحدة لاستخدامات متعددة».
ومع ذلك، فإن سلاسل البلوكشين المختلفة هي أنظمة إجماع معزولة، ولا توجد طريقة لنقل الأموال مباشرة من سلسلة إلى أخرى. يتمثل جوهر الصناديق عبر السلاسل في أن الجسر عبر السلاسل يعمل كطرف مقابل عام، حيث يتلقى أموال المستخدمين في سلسلة المصدر ويرسل الأموال إلى المستخدمين في السلسلة المستهدفة. (إصدار الأصول المعينة، أو تحرير الأموال للمستخدمين من مجمع السيولة المحجوز من قبل السلسلة المستهدفة).
ما هي أفضل طريقة لتحقيق الصناديق عبر السلاسل؟ في البداية، كان الناس لا يزالون يثقون في البورصات المركزية. كان هناك قول مأثور في وقت من الأوقات: «التبادلات المركزية هي أفضل الجسور عبر السلاسل». ومع ذلك، فإن عملية «Stake-swap-Wrawift» مرهقة للغاية، ويأمل الناس في الحصول على سلسلة نقية. وبهذه الطريقة، يمكن ربط الأموال بشكل مباشر أكثر.
علاوة على ذلك، وبالمقارنة مع البورصات المركزية، يمكن للجسور عبر السلاسل إكمال رسائل أكثر عمومية عبر السلاسل، ولا تقتصر فقط على تحويلات الأموال. على سبيل المثال، إذا كنت تستخدم DApp للإقراض عبر السلاسل لتوفير حصة من السلسلة A وإقراض الأصول في السلسلة B، فأنت بحاجة إلى استخدام المراسلة عبر السلاسل.
إذا قمت بفحص الأصل التاريخي للسلسلة المتقاطعة، فيمكن إرجاعه إلى المراحل الأولى من تطوير تقنية بلوكتشين. في ذلك الوقت، أدى ظهور سلاسل عامة مختلفة إلى جعل الناس يدركون أنه يجب حل مشكلة قابلية التشغيل البيني بين السلاسل، وإلا ستظهر العديد من جزر المعلومات/الصناديق. بمرور الوقت، اقترح الناس أنواعًا مختلفة من الأساليب عبر السلاسل، وشكلوا تدريجيًا النموذج العام للسلسلة المتقاطعة اليوم.
سنشرح أدناه بعض التطورات في التكنولوجيا عبر السلاسل.
ابحث عن الأطراف المقابلة بنفسك فكر في الأمر، ما هي الطريقة الأكثر سهولة عبر السلاسل؟ لنفترض أن لديك 100 USDT على السلسلة A وتريد نقلها إلى السلسلة B. يحدث أن يكون هناك شخص لديه 100 USDT في السلسلة B، ويريد نقل USDT إلى السلسلة A. رأى كلاكما أن هذا كان صحيحًا تمامًا، لذلك قمت بإيقاف تشغيله على الفور. ولكن عندما قمت بنقل USDT إلى عنوان الطرف الآخر على السلسلة A، فقد ندم على ذلك ولم ينقل USDT الخاص به على السلسلة B إلى عنوانك. لذلك، لا يمكن الاعتماد على نموذج تداول P2P هذا بشكل كبير. أولاً، قد يفسخ الطرف الآخر العقد، مما يتسبب في تكبدك خسائر دون أي ضمان؛ ثانيًا، ليس من السهل العثور على هذا الطرف المقابل، وقد تضطر إلى الانتظار لفترة طويلة للعثور على واحد يطابق المبلغ الذي تريد عبوره، ولكن الاتجاه عبر السلاسل على العكس من ذلك، قد لا يتمكن المستخدمون حتى من انتظار مثل هذا الطرف المقابل إلى الأبد.
لذلك اعتقدنا أنه نظرًا لأن الطرف الآخر قد يخرق العقد، فهل يمكنني العثور على طرف ثالث موثوق به لإجراء المعاملات؟ أعطيه المال أولاً في سلسلة المصدر، ثم يعد بتحويل الأموال إلي في السلسلة المستهدفة. على سبيل المثال، يمتلك هذا الشخص أصولًا في كل من السلسلة A والسلسلة B، ثم يضمن أنه طالما أنه يتلقى 100 USDT مني في السلسلة A، فسوف يقوم بتحويل 100 USDT إلي من السلسلة B.
هذا أفضل بكثير من أول تبادل للأصول بين السلاسل P2P، لأن هناك طرفًا عامًا موثوقًا به، لديه شيء سحري يسمى «السيولة» في يديه، ويمكنك التداول معه في أي وقت.
بعبارة أخرى، تصبح معاملتك معه معاملة «من نقطة إلى تجمع» بدلاً من معاملة «من نقطة إلى نقطة». لكنك ما زلت تشعر بعدم الارتياح. إذا قمت بتداول 100 USDT معه، فلا بأس بذلك. ماذا لو كنت تريد تداول مليون دولار أمريكي معه؟ على الرغم من أنه يتمتع بسمعة جيدة نسبيًا، إلا أنه استمر في أخذ المال وهرب.
بعد كل شيء، يقدم كاتب العدل هذا نوعًا من المركزية، والتي لا تزال ليست طريقة Trustless عبر السلاسل التي نريدها.
2.2 كتاب العدل المتعدد (MultiSIG)
ماذا لو لم يكن كاتب العدل هذا شخصًا واحدًا، بل مجموعة من الأشخاص؟ يمكننا إنشاء حساب مُدار بشكل مشترك، ويقوم العديد من الموقعين بإدارة الحساب بشكل مشترك. يجب عليهم التوقيع على رسالة. فقط عندما يصل عدد التوقيعات إلى الحد الأدنى (عادة 2/3) سيتم تحويل الأموال.
في هذه الحالة، إذا كان لدى عدد صغير منهم (لا يزيد عن 1/3) فكرة خاطئة ويريدون جمع الأموال مني في سلسلة المصدر، ولكن لا يريدون إرسال الأموال إلي في السلسلة المستهدفة، أو كانوا غير متصلين بالإنترنت، فلا يهم. سيظل كاتب عدل صادق آخر يوقع ويحول الأموال المستحقة لي.
هذا الحل أكثر موثوقية، ويضعف خطر المركزية، وهو أكثر أمانًا. على سبيل المثال، إذا كان هناك 20 من كتاب العدل ذوي السمعة الطيبة في المجموع، فإن احتمال تصرفهم بشكل خاطئ في نفس الوقت لا يزال منخفضًا للغاية. (لا يشمل ذلك حالات مثل Multichain حيث تتم إدارة 20 عقدة بواسطة شخص واحد، أو حالات مثل جسر Axie عبر السلسلة حيث سرق المتسللون 2/3 من مفاتيح توقيع كاتب العدل.)
ومع ذلك، فإن طريقة إدارة الحسابات متعددة التوقيعات تنطوي أيضًا على العديد من المضايقات.
تعمل التوقيعات المتعددة على جعل قواعد التوقيع أكثر سهولة في الكشف عنها. إذا كان مخطط التوقيع 5/7، فإن رمز العقد الذكي للمحفظة متعددة التوقيعات سيكشف عن عدد الموقعين، ويمكن للقراصنة البحث عن هؤلاء الموقعين بطريقة مستهدفة وانتظار الفرص لسرقة المفتاح الخاص.
يتطلب التوقيع المتعدد التكيف مع السلاسل العامة المختلفة. على سبيل المثال، لا تدعم بعض السلاسل العامة العقود الذكية، لذلك يتعين عليك استخدام أساسيات التشفير المتخصصة للسلسلة لتنفيذ حسابات متعددة التوقيعات. إذا لم يكن هذا مدعومًا، فلن تتمكن محفظتك متعددة التوقيعات من العمل.
لا يمكن تغيير الموقّع على التوقيعات المتعددة بمجرد تحديد الموقّع. على سبيل المثال، إذا كنت ترغب في تغيير نظام التوقيع 5/7 إلى مخطط 6/8، أو إذا كنت ترغب في تغيير الموقّع، يجب عليك إعادة نشر العقد متعدد التوقيعات وتحويل الأموال إلى العقد الجديد متعدد التوقيعات.
استخدم أول حل متعدد السلاسل لمشتقات BTC، tBTC، طريقة التوقيع المتعدد، والتي تم إلغاؤها لأنها كانت ضعيفة وصعبة الاستخدام. تعتمد معظم الجسور المتقاطعة الحالية طريقة MPC الأكثر تقدمًا.
الاسم الكامل للحساب متعدد الأطراف هو الحساب متعدد الأطراف (الحساب الآمن متعدد الأطراف)، وهو تقنية مشاركة المفتاح الخاص. يدير الحساب متعدد التوقيعات حسابًا بمفاتيح خاصة متعددة، بينما يدير حساب MPC حسابًا بمفتاح خاص واحد. المفتاح الخاص مقسم إلى أجزاء متعددة. يحمل كل من الموقعين جزءًا واحدًا من المفتاح الخاص. عندما يكون عدد الموقعين يمكن تجميع التوقيع الكامل فقط عند الوصول إلى الحد الأدنى، ولن يتم الكشف عن المفتاح الخاص الكامل أثناء عملية التوقيع. تتمتع حسابات MPC بالمزايا التالية: فهي أكثر سرية من المحافظ العادية متعددة التوقيعات. عندما يكون التوقيع مطلوبًا، على سبيل المثال، يتم استخدام 5/7 أجزاء من المفاتيح الخاصة لتوقيع كل منها، ويتم دمج العديد من التوقيعات الفرعية لتشكيل توقيع قانوني نهائي. بهذه الطريقة، ما تراه على السلسلة هو توقيع عادي واحد. لا يمكنك معرفة ما إذا كان يأتي من حساب MPC، ناهيك عن هوية الموقّع الذي يقف وراءه، ولا عدد أجزاء المفتاح الخاص وقواعد التوقيع المحددة. يمكن أن تتكيف مع معظم السلاسل العامة بشكل أفضل من المحافظ متعددة التوقيعات. MPC هي تقنية مميزة ولا علاقة لها بالسلسلة. حساب MPC هو حساب عادي. بغض النظر عما إذا كانت السلسلة العامة تدعم العقود الذكية، يمكن إنشاء حساب مُدار بشكل مشترك من خلال تقنية MPC. آلية توقيع استبدال MPC أكثر مرونة. يمكن أن يدعم تعديلات قواعد التوقيع الأكثر مرونة، مثل تغيير عدد أجزاء المفتاح الخاص وحدود التوقيع في أي وقت، ويمكنك أيضًا تغيير الموقّع في أي وقت. تحتاج فقط إلى إعادة مشاركة المفتاح الخاص.
بعد أن استلم حساب الوصاية الخاص بكاتب العدل مبلغ 100 USDT الخاص بي على السلسلة A، قام بتحويل 100 USDT إلى عنواني في السلسلة B. ماذا يجب أن تكون عملية التحفيز لهذا السلوك؟
لنفترض أن كل عضو في كاتب العدل لديه جهاز يراقب المعاملات على السلسلة A. عندما اكتشفوا أنني قمت بتحويل 100 USDT إلى حساب الحفظ عبر السلاسل، ذكرت هذه المعاملة أنني آمل أن يتم تسميتي في السلسلة B. احصل على USDT مقابل عنوان المستخدم 2.
في هذا الوقت، قام كتاب العدل بالتوقيع بشكل مشترك وتحويل 100 USDT في حساب الجسر عبر السلاسل على السلسلة B إلى المستخدم. يجب كتابة هذه العملية في التعليمات البرمجية وتشغيلها تلقائيًا، وإلا، يجب أن يكون كاتب العدل متصلاً بالإنترنت في الوقت الفعلي ويجب أن يعمل فورًا بعد تلقي الطلب، وهو أمر غير واقعي للغاية.
سيحتوي هذا البرنامج الآلي على عدة أجزاء
برنامج المراقبة: مسؤول عن مراقبة المعاملات على سلسلة المصدر. لتصفية المعاملات غير ذات الصلة أو المعاملات غير الصالحة، قد تؤدي هذه الخطوة بعض عمليات التحقق الأساسية من التنسيق؛
إجراءات التحقق: سيشمل ذلك عميل العقدة الخفيفة (الذي قد يكون أيضًا عقدة كاملة) من بلوكتشين المدعومة، المسؤول عن التحقق من أن المعاملة على سلسلة المصدر التي تتفاعل مع عقد الجسر عبر السلاسل يتم تجميعها في كتلة ووضعها على السلسلة. ؛
إجراءات التوقيع: مسؤولة عن توقيع وبدء معاملات النقل للمستخدمين في السلسلة المستهدفة.
لكن الأتمتة تجلب أيضًا مشكلة، أي أن البرنامج الآلي قد يتعرض للهجوم والتلاعب من قبل المتسللين. لذلك، للسيطرة على المخاطر، ستتخذ الجسور عبر السلاسل تدابير لفصل الساخن والبارد. يتحكم البرنامج الآلي في مفتاح التشغيل السريع، ومقدار النقل محدود. بالنسبة لعمليات النقل الكبيرة، يجب على كاتب العدل استخدام المفتاح البارد للتوقيع يدويًا. يمكن تنفيذ قواعد الفصل الساخن والبارد في حساب MPC.
إذا كان هناك خطأ، ألا تريد التعامل معه كله في حادثة واحدة؟ لذلك، من الضروري عزل مجمع رأس المال واستخدام حسابات حفظ متعددة لإدارة صناديق السيولة. على سبيل المثال، وفقًا للعزلة بين السلاسل العامة المختلفة، تعد A و B و B و C و C و D كلها مجمعات رأسمالية مستقلة.
يمكن تشغيل برامج المراقبة والتوقيع الآلية التي يديرها كاتب العدل على أجهزة TEE، والتي يمكن أن تزيد بشكل كبير من صعوبة هجمات القراصنة. tee تعني Trusted Execute Environment، وهي بيئة حوسبة تعمل على جهاز معين معزول عن نظام التشغيل الرئيسي، مثل الجيب.
يتم فرض هذه العزلة بواسطة الأجهزة بأمان عالٍ للغاية، بحيث يمكن لـ TEES تشغيل التطبيقات ذات متطلبات الأمان العالية، مثل إدارة مفاتيح التشفير والمصادقة البيومترية ومعالجة الدفع الآمنة وما إلى ذلك.
لجعل الجسور عبر السلاسل أكثر أمانًا، هناك اتجاهان في اختيار كتاب العدل:
الأول هو اختيار الشركات الكبيرة والمؤسسات المعروفة ذات السمعة الجيدة قدر الإمكان. بالنسبة لهذه المؤسسات، فإن تكلفة فعل الشر مرتفعة للغاية، وقد تفقد سنوات من النوايا الحسنة. بالإضافة إلى ذلك، حاول إبقائها متنوعة جغرافيًا قدر الإمكان (تجنب التركيز في نفس الولاية القضائية).
على سبيل المثال، اختار مشروع الجسر متعدد السلاسل Wormhole هذا النموذج. يتم دعم العقد الـ 19 الخاصة بها من قبل مؤسسات كبيرة معروفة ذات أحجام كبيرة وصناديق قوية. هذه هي طريقة PoA.
هناك طريقة أخرى تتمثل في قبول كتاب العدل غير المصرح لهم ولكن مطالبتهم بالمشاركة. إذا أساءوا التصرف، سيتم تخفيض أموالهم المحتجزة. هذه هي الطريقة التي يعمل بها PoS. هذا ما تستخدمه ZetaChain.
أي من الطريقتين أفضل وأيهما أسوأ من الصعب استخلاص نتيجة تعسفية مباشرة. يعتمد ذلك على مدى جودة أداء أطراف مشروع الجسر عبر السلاسل في اتجاهات كل منها.
سواء كان PoA أو PoS، يمكنك تحويل الجسر عبر السلاسل مباشرة إلى سلسلة عامة. تقوم كل عقدة بتشغيل نفس البرنامج، وسيتم تسجيل جميع الطلبات عبر السلاسل وعمليات المعالجة على هذه السلسلة. يمكن للسلسلة نفسها أيضًا استضافة التطبيقات، وبالتالي تصبح مركزًا بيئيًا.
هناك طريقة أخرى لتعزيز الأمن وهي تعيين دور مراقب. هذا الدور مسؤول عن مراقبة السلوك عبر السلاسل، وفي حالة اكتشاف المشكلات، الإبلاغ عن المعاملات داخل السلسلة والمعاملات المجهضة. نظرًا لأن المراقبين يحتاجون إلى فترة نافذة للرد، فقد يتأخر وقت وصول عمليات النقل عبر السلاسل. لذلك، لن يتدخل المراقبون إلا إذا قبل المستخدمون تأخيرات النقل للمعاملات ذات القيمة الكبيرة أو العمليات الحساسة عبر السلاسل.
حلول أخرى عبر السلاسل Hash LockBack إلى الطريقة الأولى المذكورة في هذه المقالة: P2P تبحث عن أطراف مقابلة لتبادل الأصول عبر السلاسل. إذا كنا خائفين من أن الطرف المقابل سيتخلف عن سداد القرض، فيمكننا إنشاء آلية. بمجرد أن يتراجع شخص ما، يمكن للطرف الآخر استعادة الأموال وإعادتها سليمة. هذا هو قفل التجزئة، والذي يستخدم بذكاء أقفال التجزئة وأقفال الوقت، ويجبر متلقي الأموال على تأكيد الدفع قبل الموعد النهائي وإنشاء إثبات الاستلام على سلسلة المصدر. باستخدام إثبات الاستلام هذا، سيتمكن الدافع من الحصول على الأصول المكافئة للمستلم في السلسلة المستهدفة. بخلاف ذلك، سيتم إرجاع جميع الأموال من كلا الطرفين عبر المسار الأصلي.
ومع ذلك، يمكن لهذه الطريقة فقط تبادل الأموال ولا يمكنها إكمال نقل المعلومات العامة عبر السلاسل. حتى من منظور تحويل الأموال عبر السلاسل، فإن تجربة المستخدم لأقفال وقت التجزئة سيئة للغاية: إذا كان تقلب أسعار العملات غير مواتٍ للطرف المقابل (مزود السيولة)، فقد يختار بعقلانية عدم إكمال المعاملة؛ للإكمال بالنسبة للتبادل عبر السلاسل، يجب على كل من المستخدم والطرف المقابل التوقيع مرتين. لذلك، كحل متعدد السلاسل، تم التخلص من أقفال وقت التجزئة. لقد غيرت الجسور المبكرة عبر السلاسل (مثل cBridge و Connext) التي استخدمت هذا الحل طرقها. العميل الخفيف على السلسلة: هذه الطريقة هي النشر المباشر لعقد العميل الخفيف لسلسلة المصدر على السلسلة المستهدفة. إذا قمت بنشر عقد على سلسلة، فستقوم جميع العقد في السلسلة بتشغيل رمز العقد الذي قمت بنشره.
لذلك، يسمح حل العميل الخفيف على السلسلة للسلسلة المستهدفة بالتحقق مباشرة من المعاملات من سلسلة المصدر. هذه الطريقة آمنة للغاية ولكنها أيضًا الأغلى. تنعكس التكلفة في الجوانب التالية: يحتاج عقد العميل الخفيف للسلسلة المستهدفة إلى استلام رأس الكتلة الجديد والتحقق منه من سلسلة المصدر في الوقت الفعلي. تستهلك هذه العملية الكثير من الغاز. حتى إذا تم استخدام ZK لتحقيق إثبات موجز، فإن استهلاك الغاز للتحقق من إثبات ZK لن يقل عن 400000 غاز (EVM على سبيل المثال)، في مخطط MPC، كل ما هو مطلوب للتحقق منه على السلسلة هو التوقيع، واستهلاك الغاز يزيد قليلاً عن 20000، بفارق 20 مرة! هل ستستخدم جسرًا أكثر أمانًا ولكن أكثر تكلفة بعشرين مرة؟
حجم العمل المطلوب لتطوير عقود العملاء الخفيفة ضخم. لجعل الجسر عبر السلاسل متوافقًا مع المزيد من السلاسل غير المتجانسة، تحتاج إلى تنفيذ عقود العملاء الخفيفة للسلاسل الأخرى في بيئات تطوير مختلفة تمامًا لسلاسل مختلفة، وهو تحدٍ على مستوى الجحيم للمطورين. وهذا يؤدي إلى زيادة احتمال حدوث أخطاء في كتابة العقود، أي أن أمان جسر العميل الخفيف يكون فقط على المستوى النظري، ولكن من حيث الممارسة الهندسية، فهو غير آمن للغاية. لتقليل حجم أعمال التطوير، يتمثل الحل المجدي في إدخال سلسلة ترحيل والسماح لجميع السلاسل بإنشاء عقود عملاء خفيفة مع سلسلة الترحيل هذه. يمكن أن يؤدي هذا بالفعل إلى تقليل عبء العمل من C (n,2) إلى n، ولكن لا يزال ليس صغيرًا جدًا. أصبح النقل الأصلي المباشر عبر السلسلة من سلسلة المصدر إلى السلسلة المستهدفة بمثابة نقل من الدرجة الثانية لسلسلة المصدر ← سلسلة الترحيل ← السلسلة المستهدفة، مما سيؤدي إلى استهلاك إضافي للغاز واستهلاك الوقت.
لذلك، لا يمكن استخدام الحل التقني للعميل الخفيف حاليًا لبناء جسر متعدد السلاسل أكثر شمولية.
بادئ ذي بدء، تمتلك السلاسل العامة المختلفة مناهج مختلفة ولديها موارد مختلفة لدعمها. طالما أنهم لا يعترفون بالهزيمة، فإن النظام البيئي سيكون موجودًا. حتى لو لم يكن التطوير جيدًا جدًا على المدى القصير، فقد تتم ترقيته يومًا ما وسيعود إلى الحياة. إن الشيء المتعلق بالبنية التحتية الأساسية مثل هذه هو معرفة من يمكنه الاستمرار لفترة أطول ومن يمكنه التكيف مع السوق بسرعة.
لا يمكن لـ Bitcoin و Ethereum حل جميع سيناريوهات التطبيق، أو في قطاع معين، هناك دائمًا أشخاص لا يحبون المقام الأول، لذلك يقومون بإنشاء عجلة جديدة، لذلك سيكون المستقبل متعدد السلاسل. في المستقبل، لن تكون الطبقة السفلية عبارة عن سلسلة، لذلك يجب أن يكون المستقبل متعدد البيئات. تتطلب كيفية تحويل الأموال والرسائل بين بيئات متعددة تقنية متعددة السلاسل/عبر البيئة!
ما الذي يثير قلق المستخدمين أكثر عندما يتعلق الأمر بالسلاسل المتقاطعة؟ لا شيء أكثر من النقاط التالية:
السرعة: كم من الوقت يستغرق إكمال عملية عبر السلاسل؟
الرسوم: ما المبلغ الذي أحتاج إلى دفعه مقابل عملية عبر السلاسل
الأمان: هل الجسر عبر السلاسل آمن وهل ستفقد الأموال؟
السيولة: هل هناك سيولة كافية لدعم تجارتي وتأثير مقبول على السعر؟
نطاق الاتصال: كم عدد السلاسل التي تدعمها؟ هل تدعم السلاسل التي أحتاج إلى استخدامها في العمليات عبر السلاسل؟
التجربة: هل التشغيل عبر السلاسل ملائم، مثل ما إذا كان يدعم دفع الغاز، وما إذا كان تقدير التكلفة دقيقًا، وما إذا كان يدعم الاستعلام المرحلي وعرض المتصفح، وما إذا كانت حالات الفشل تحدث بشكل متكرر، وكيفية التعامل مع حالات الفشل، وما إلى ذلك؟
دعونا أولاً نلقي نظرة عامة على خصائص بعض المشاريع من ثلاث وجهات نظر واضحة نسبيًا: الأمان والتكلفة ونطاق الاتصال.
انقر فوق الارتباط لعرض الجدول الواضح (يتم تحديث الجدول باستمرار):
https://docs.google.com/spreadsheets/d/1LKlbd5KJUnQIx3ZBTgyMADhxHtWVwBH9qDRm765tPMw/
لشرح الجسر المتقاطع بشكل كامل، هناك العديد من تفاصيل الأبعاد التي يجب مناقشتها، مثل جميع الأبعاد وتحليل البيانات في الجدول أعلاه. إذن ما هي العوامل التي تهتم بها عند عبور السلاسل؟ ما الجسور المتقاطعة التي تستخدمها غالبًا؟ ما الجوانب التي تعتقد أن الجسور عبر السلاسل يجب أن تركز عليها من أجل التحسين؟ إذا كانت لديك أفكارك، فلا تتردد في التواصل مع المؤلف.
منذ إنشاء صناعة blockchain، ظهر عدد لا يحصى من L1/L2s، وطورت كل سلسلة عامة تقريبًا نظام DeFi البيئي الخاص بها. يتفاعل بعض الأشخاص فقط في سلاسل عامة محددة، بينما يأمل المزيد من الناس في العثور على فرص الربح مثل التداول والتعدين في سلاسل مختلفة. ومن بين هذه العوامل، أصبح تحويل الأموال عبر السلاسل ضرورة لا غنى عنها.
بالإضافة إلى المستخدمين العاديين، تحتاج العديد من أطراف المشروع أيضًا إلى تحويل الأموال بين السلاسل المختلفة، وتوجيه السيولة على السلاسل المختلفة، وتحقيق «أموال واحدة لاستخدامات متعددة».
ومع ذلك، فإن سلاسل البلوكشين المختلفة هي أنظمة إجماع معزولة، ولا توجد طريقة لنقل الأموال مباشرة من سلسلة إلى أخرى. يتمثل جوهر الصناديق عبر السلاسل في أن الجسر عبر السلاسل يعمل كطرف مقابل عام، حيث يتلقى أموال المستخدمين في سلسلة المصدر ويرسل الأموال إلى المستخدمين في السلسلة المستهدفة. (إصدار الأصول المعينة، أو تحرير الأموال للمستخدمين من مجمع السيولة المحجوز من قبل السلسلة المستهدفة).
ما هي أفضل طريقة لتحقيق الصناديق عبر السلاسل؟ في البداية، كان الناس لا يزالون يثقون في البورصات المركزية. كان هناك قول مأثور في وقت من الأوقات: «التبادلات المركزية هي أفضل الجسور عبر السلاسل». ومع ذلك، فإن عملية «Stake-swap-Wrawift» مرهقة للغاية، ويأمل الناس في الحصول على سلسلة نقية. وبهذه الطريقة، يمكن ربط الأموال بشكل مباشر أكثر.
علاوة على ذلك، وبالمقارنة مع البورصات المركزية، يمكن للجسور عبر السلاسل إكمال رسائل أكثر عمومية عبر السلاسل، ولا تقتصر فقط على تحويلات الأموال. على سبيل المثال، إذا كنت تستخدم DApp للإقراض عبر السلاسل لتوفير حصة من السلسلة A وإقراض الأصول في السلسلة B، فأنت بحاجة إلى استخدام المراسلة عبر السلاسل.
إذا قمت بفحص الأصل التاريخي للسلسلة المتقاطعة، فيمكن إرجاعه إلى المراحل الأولى من تطوير تقنية بلوكتشين. في ذلك الوقت، أدى ظهور سلاسل عامة مختلفة إلى جعل الناس يدركون أنه يجب حل مشكلة قابلية التشغيل البيني بين السلاسل، وإلا ستظهر العديد من جزر المعلومات/الصناديق. بمرور الوقت، اقترح الناس أنواعًا مختلفة من الأساليب عبر السلاسل، وشكلوا تدريجيًا النموذج العام للسلسلة المتقاطعة اليوم.
سنشرح أدناه بعض التطورات في التكنولوجيا عبر السلاسل.
ابحث عن الأطراف المقابلة بنفسك فكر في الأمر، ما هي الطريقة الأكثر سهولة عبر السلاسل؟ لنفترض أن لديك 100 USDT على السلسلة A وتريد نقلها إلى السلسلة B. يحدث أن يكون هناك شخص لديه 100 USDT في السلسلة B، ويريد نقل USDT إلى السلسلة A. رأى كلاكما أن هذا كان صحيحًا تمامًا، لذلك قمت بإيقاف تشغيله على الفور. ولكن عندما قمت بنقل USDT إلى عنوان الطرف الآخر على السلسلة A، فقد ندم على ذلك ولم ينقل USDT الخاص به على السلسلة B إلى عنوانك. لذلك، لا يمكن الاعتماد على نموذج تداول P2P هذا بشكل كبير. أولاً، قد يفسخ الطرف الآخر العقد، مما يتسبب في تكبدك خسائر دون أي ضمان؛ ثانيًا، ليس من السهل العثور على هذا الطرف المقابل، وقد تضطر إلى الانتظار لفترة طويلة للعثور على واحد يطابق المبلغ الذي تريد عبوره، ولكن الاتجاه عبر السلاسل على العكس من ذلك، قد لا يتمكن المستخدمون حتى من انتظار مثل هذا الطرف المقابل إلى الأبد.
لذلك اعتقدنا أنه نظرًا لأن الطرف الآخر قد يخرق العقد، فهل يمكنني العثور على طرف ثالث موثوق به لإجراء المعاملات؟ أعطيه المال أولاً في سلسلة المصدر، ثم يعد بتحويل الأموال إلي في السلسلة المستهدفة. على سبيل المثال، يمتلك هذا الشخص أصولًا في كل من السلسلة A والسلسلة B، ثم يضمن أنه طالما أنه يتلقى 100 USDT مني في السلسلة A، فسوف يقوم بتحويل 100 USDT إلي من السلسلة B.
هذا أفضل بكثير من أول تبادل للأصول بين السلاسل P2P، لأن هناك طرفًا عامًا موثوقًا به، لديه شيء سحري يسمى «السيولة» في يديه، ويمكنك التداول معه في أي وقت.
بعبارة أخرى، تصبح معاملتك معه معاملة «من نقطة إلى تجمع» بدلاً من معاملة «من نقطة إلى نقطة». لكنك ما زلت تشعر بعدم الارتياح. إذا قمت بتداول 100 USDT معه، فلا بأس بذلك. ماذا لو كنت تريد تداول مليون دولار أمريكي معه؟ على الرغم من أنه يتمتع بسمعة جيدة نسبيًا، إلا أنه استمر في أخذ المال وهرب.
بعد كل شيء، يقدم كاتب العدل هذا نوعًا من المركزية، والتي لا تزال ليست طريقة Trustless عبر السلاسل التي نريدها.
2.2 كتاب العدل المتعدد (MultiSIG)
ماذا لو لم يكن كاتب العدل هذا شخصًا واحدًا، بل مجموعة من الأشخاص؟ يمكننا إنشاء حساب مُدار بشكل مشترك، ويقوم العديد من الموقعين بإدارة الحساب بشكل مشترك. يجب عليهم التوقيع على رسالة. فقط عندما يصل عدد التوقيعات إلى الحد الأدنى (عادة 2/3) سيتم تحويل الأموال.
في هذه الحالة، إذا كان لدى عدد صغير منهم (لا يزيد عن 1/3) فكرة خاطئة ويريدون جمع الأموال مني في سلسلة المصدر، ولكن لا يريدون إرسال الأموال إلي في السلسلة المستهدفة، أو كانوا غير متصلين بالإنترنت، فلا يهم. سيظل كاتب عدل صادق آخر يوقع ويحول الأموال المستحقة لي.
هذا الحل أكثر موثوقية، ويضعف خطر المركزية، وهو أكثر أمانًا. على سبيل المثال، إذا كان هناك 20 من كتاب العدل ذوي السمعة الطيبة في المجموع، فإن احتمال تصرفهم بشكل خاطئ في نفس الوقت لا يزال منخفضًا للغاية. (لا يشمل ذلك حالات مثل Multichain حيث تتم إدارة 20 عقدة بواسطة شخص واحد، أو حالات مثل جسر Axie عبر السلسلة حيث سرق المتسللون 2/3 من مفاتيح توقيع كاتب العدل.)
ومع ذلك، فإن طريقة إدارة الحسابات متعددة التوقيعات تنطوي أيضًا على العديد من المضايقات.
تعمل التوقيعات المتعددة على جعل قواعد التوقيع أكثر سهولة في الكشف عنها. إذا كان مخطط التوقيع 5/7، فإن رمز العقد الذكي للمحفظة متعددة التوقيعات سيكشف عن عدد الموقعين، ويمكن للقراصنة البحث عن هؤلاء الموقعين بطريقة مستهدفة وانتظار الفرص لسرقة المفتاح الخاص.
يتطلب التوقيع المتعدد التكيف مع السلاسل العامة المختلفة. على سبيل المثال، لا تدعم بعض السلاسل العامة العقود الذكية، لذلك يتعين عليك استخدام أساسيات التشفير المتخصصة للسلسلة لتنفيذ حسابات متعددة التوقيعات. إذا لم يكن هذا مدعومًا، فلن تتمكن محفظتك متعددة التوقيعات من العمل.
لا يمكن تغيير الموقّع على التوقيعات المتعددة بمجرد تحديد الموقّع. على سبيل المثال، إذا كنت ترغب في تغيير نظام التوقيع 5/7 إلى مخطط 6/8، أو إذا كنت ترغب في تغيير الموقّع، يجب عليك إعادة نشر العقد متعدد التوقيعات وتحويل الأموال إلى العقد الجديد متعدد التوقيعات.
استخدم أول حل متعدد السلاسل لمشتقات BTC، tBTC، طريقة التوقيع المتعدد، والتي تم إلغاؤها لأنها كانت ضعيفة وصعبة الاستخدام. تعتمد معظم الجسور المتقاطعة الحالية طريقة MPC الأكثر تقدمًا.
الاسم الكامل للحساب متعدد الأطراف هو الحساب متعدد الأطراف (الحساب الآمن متعدد الأطراف)، وهو تقنية مشاركة المفتاح الخاص. يدير الحساب متعدد التوقيعات حسابًا بمفاتيح خاصة متعددة، بينما يدير حساب MPC حسابًا بمفتاح خاص واحد. المفتاح الخاص مقسم إلى أجزاء متعددة. يحمل كل من الموقعين جزءًا واحدًا من المفتاح الخاص. عندما يكون عدد الموقعين يمكن تجميع التوقيع الكامل فقط عند الوصول إلى الحد الأدنى، ولن يتم الكشف عن المفتاح الخاص الكامل أثناء عملية التوقيع. تتمتع حسابات MPC بالمزايا التالية: فهي أكثر سرية من المحافظ العادية متعددة التوقيعات. عندما يكون التوقيع مطلوبًا، على سبيل المثال، يتم استخدام 5/7 أجزاء من المفاتيح الخاصة لتوقيع كل منها، ويتم دمج العديد من التوقيعات الفرعية لتشكيل توقيع قانوني نهائي. بهذه الطريقة، ما تراه على السلسلة هو توقيع عادي واحد. لا يمكنك معرفة ما إذا كان يأتي من حساب MPC، ناهيك عن هوية الموقّع الذي يقف وراءه، ولا عدد أجزاء المفتاح الخاص وقواعد التوقيع المحددة. يمكن أن تتكيف مع معظم السلاسل العامة بشكل أفضل من المحافظ متعددة التوقيعات. MPC هي تقنية مميزة ولا علاقة لها بالسلسلة. حساب MPC هو حساب عادي. بغض النظر عما إذا كانت السلسلة العامة تدعم العقود الذكية، يمكن إنشاء حساب مُدار بشكل مشترك من خلال تقنية MPC. آلية توقيع استبدال MPC أكثر مرونة. يمكن أن يدعم تعديلات قواعد التوقيع الأكثر مرونة، مثل تغيير عدد أجزاء المفتاح الخاص وحدود التوقيع في أي وقت، ويمكنك أيضًا تغيير الموقّع في أي وقت. تحتاج فقط إلى إعادة مشاركة المفتاح الخاص.
بعد أن استلم حساب الوصاية الخاص بكاتب العدل مبلغ 100 USDT الخاص بي على السلسلة A، قام بتحويل 100 USDT إلى عنواني في السلسلة B. ماذا يجب أن تكون عملية التحفيز لهذا السلوك؟
لنفترض أن كل عضو في كاتب العدل لديه جهاز يراقب المعاملات على السلسلة A. عندما اكتشفوا أنني قمت بتحويل 100 USDT إلى حساب الحفظ عبر السلاسل، ذكرت هذه المعاملة أنني آمل أن يتم تسميتي في السلسلة B. احصل على USDT مقابل عنوان المستخدم 2.
في هذا الوقت، قام كتاب العدل بالتوقيع بشكل مشترك وتحويل 100 USDT في حساب الجسر عبر السلاسل على السلسلة B إلى المستخدم. يجب كتابة هذه العملية في التعليمات البرمجية وتشغيلها تلقائيًا، وإلا، يجب أن يكون كاتب العدل متصلاً بالإنترنت في الوقت الفعلي ويجب أن يعمل فورًا بعد تلقي الطلب، وهو أمر غير واقعي للغاية.
سيحتوي هذا البرنامج الآلي على عدة أجزاء
برنامج المراقبة: مسؤول عن مراقبة المعاملات على سلسلة المصدر. لتصفية المعاملات غير ذات الصلة أو المعاملات غير الصالحة، قد تؤدي هذه الخطوة بعض عمليات التحقق الأساسية من التنسيق؛
إجراءات التحقق: سيشمل ذلك عميل العقدة الخفيفة (الذي قد يكون أيضًا عقدة كاملة) من بلوكتشين المدعومة، المسؤول عن التحقق من أن المعاملة على سلسلة المصدر التي تتفاعل مع عقد الجسر عبر السلاسل يتم تجميعها في كتلة ووضعها على السلسلة. ؛
إجراءات التوقيع: مسؤولة عن توقيع وبدء معاملات النقل للمستخدمين في السلسلة المستهدفة.
لكن الأتمتة تجلب أيضًا مشكلة، أي أن البرنامج الآلي قد يتعرض للهجوم والتلاعب من قبل المتسللين. لذلك، للسيطرة على المخاطر، ستتخذ الجسور عبر السلاسل تدابير لفصل الساخن والبارد. يتحكم البرنامج الآلي في مفتاح التشغيل السريع، ومقدار النقل محدود. بالنسبة لعمليات النقل الكبيرة، يجب على كاتب العدل استخدام المفتاح البارد للتوقيع يدويًا. يمكن تنفيذ قواعد الفصل الساخن والبارد في حساب MPC.
إذا كان هناك خطأ، ألا تريد التعامل معه كله في حادثة واحدة؟ لذلك، من الضروري عزل مجمع رأس المال واستخدام حسابات حفظ متعددة لإدارة صناديق السيولة. على سبيل المثال، وفقًا للعزلة بين السلاسل العامة المختلفة، تعد A و B و B و C و C و D كلها مجمعات رأسمالية مستقلة.
يمكن تشغيل برامج المراقبة والتوقيع الآلية التي يديرها كاتب العدل على أجهزة TEE، والتي يمكن أن تزيد بشكل كبير من صعوبة هجمات القراصنة. tee تعني Trusted Execute Environment، وهي بيئة حوسبة تعمل على جهاز معين معزول عن نظام التشغيل الرئيسي، مثل الجيب.
يتم فرض هذه العزلة بواسطة الأجهزة بأمان عالٍ للغاية، بحيث يمكن لـ TEES تشغيل التطبيقات ذات متطلبات الأمان العالية، مثل إدارة مفاتيح التشفير والمصادقة البيومترية ومعالجة الدفع الآمنة وما إلى ذلك.
لجعل الجسور عبر السلاسل أكثر أمانًا، هناك اتجاهان في اختيار كتاب العدل:
الأول هو اختيار الشركات الكبيرة والمؤسسات المعروفة ذات السمعة الجيدة قدر الإمكان. بالنسبة لهذه المؤسسات، فإن تكلفة فعل الشر مرتفعة للغاية، وقد تفقد سنوات من النوايا الحسنة. بالإضافة إلى ذلك، حاول إبقائها متنوعة جغرافيًا قدر الإمكان (تجنب التركيز في نفس الولاية القضائية).
على سبيل المثال، اختار مشروع الجسر متعدد السلاسل Wormhole هذا النموذج. يتم دعم العقد الـ 19 الخاصة بها من قبل مؤسسات كبيرة معروفة ذات أحجام كبيرة وصناديق قوية. هذه هي طريقة PoA.
هناك طريقة أخرى تتمثل في قبول كتاب العدل غير المصرح لهم ولكن مطالبتهم بالمشاركة. إذا أساءوا التصرف، سيتم تخفيض أموالهم المحتجزة. هذه هي الطريقة التي يعمل بها PoS. هذا ما تستخدمه ZetaChain.
أي من الطريقتين أفضل وأيهما أسوأ من الصعب استخلاص نتيجة تعسفية مباشرة. يعتمد ذلك على مدى جودة أداء أطراف مشروع الجسر عبر السلاسل في اتجاهات كل منها.
سواء كان PoA أو PoS، يمكنك تحويل الجسر عبر السلاسل مباشرة إلى سلسلة عامة. تقوم كل عقدة بتشغيل نفس البرنامج، وسيتم تسجيل جميع الطلبات عبر السلاسل وعمليات المعالجة على هذه السلسلة. يمكن للسلسلة نفسها أيضًا استضافة التطبيقات، وبالتالي تصبح مركزًا بيئيًا.
هناك طريقة أخرى لتعزيز الأمن وهي تعيين دور مراقب. هذا الدور مسؤول عن مراقبة السلوك عبر السلاسل، وفي حالة اكتشاف المشكلات، الإبلاغ عن المعاملات داخل السلسلة والمعاملات المجهضة. نظرًا لأن المراقبين يحتاجون إلى فترة نافذة للرد، فقد يتأخر وقت وصول عمليات النقل عبر السلاسل. لذلك، لن يتدخل المراقبون إلا إذا قبل المستخدمون تأخيرات النقل للمعاملات ذات القيمة الكبيرة أو العمليات الحساسة عبر السلاسل.
حلول أخرى عبر السلاسل Hash LockBack إلى الطريقة الأولى المذكورة في هذه المقالة: P2P تبحث عن أطراف مقابلة لتبادل الأصول عبر السلاسل. إذا كنا خائفين من أن الطرف المقابل سيتخلف عن سداد القرض، فيمكننا إنشاء آلية. بمجرد أن يتراجع شخص ما، يمكن للطرف الآخر استعادة الأموال وإعادتها سليمة. هذا هو قفل التجزئة، والذي يستخدم بذكاء أقفال التجزئة وأقفال الوقت، ويجبر متلقي الأموال على تأكيد الدفع قبل الموعد النهائي وإنشاء إثبات الاستلام على سلسلة المصدر. باستخدام إثبات الاستلام هذا، سيتمكن الدافع من الحصول على الأصول المكافئة للمستلم في السلسلة المستهدفة. بخلاف ذلك، سيتم إرجاع جميع الأموال من كلا الطرفين عبر المسار الأصلي.
ومع ذلك، يمكن لهذه الطريقة فقط تبادل الأموال ولا يمكنها إكمال نقل المعلومات العامة عبر السلاسل. حتى من منظور تحويل الأموال عبر السلاسل، فإن تجربة المستخدم لأقفال وقت التجزئة سيئة للغاية: إذا كان تقلب أسعار العملات غير مواتٍ للطرف المقابل (مزود السيولة)، فقد يختار بعقلانية عدم إكمال المعاملة؛ للإكمال بالنسبة للتبادل عبر السلاسل، يجب على كل من المستخدم والطرف المقابل التوقيع مرتين. لذلك، كحل متعدد السلاسل، تم التخلص من أقفال وقت التجزئة. لقد غيرت الجسور المبكرة عبر السلاسل (مثل cBridge و Connext) التي استخدمت هذا الحل طرقها. العميل الخفيف على السلسلة: هذه الطريقة هي النشر المباشر لعقد العميل الخفيف لسلسلة المصدر على السلسلة المستهدفة. إذا قمت بنشر عقد على سلسلة، فستقوم جميع العقد في السلسلة بتشغيل رمز العقد الذي قمت بنشره.
لذلك، يسمح حل العميل الخفيف على السلسلة للسلسلة المستهدفة بالتحقق مباشرة من المعاملات من سلسلة المصدر. هذه الطريقة آمنة للغاية ولكنها أيضًا الأغلى. تنعكس التكلفة في الجوانب التالية: يحتاج عقد العميل الخفيف للسلسلة المستهدفة إلى استلام رأس الكتلة الجديد والتحقق منه من سلسلة المصدر في الوقت الفعلي. تستهلك هذه العملية الكثير من الغاز. حتى إذا تم استخدام ZK لتحقيق إثبات موجز، فإن استهلاك الغاز للتحقق من إثبات ZK لن يقل عن 400000 غاز (EVM على سبيل المثال)، في مخطط MPC، كل ما هو مطلوب للتحقق منه على السلسلة هو التوقيع، واستهلاك الغاز يزيد قليلاً عن 20000، بفارق 20 مرة! هل ستستخدم جسرًا أكثر أمانًا ولكن أكثر تكلفة بعشرين مرة؟
حجم العمل المطلوب لتطوير عقود العملاء الخفيفة ضخم. لجعل الجسر عبر السلاسل متوافقًا مع المزيد من السلاسل غير المتجانسة، تحتاج إلى تنفيذ عقود العملاء الخفيفة للسلاسل الأخرى في بيئات تطوير مختلفة تمامًا لسلاسل مختلفة، وهو تحدٍ على مستوى الجحيم للمطورين. وهذا يؤدي إلى زيادة احتمال حدوث أخطاء في كتابة العقود، أي أن أمان جسر العميل الخفيف يكون فقط على المستوى النظري، ولكن من حيث الممارسة الهندسية، فهو غير آمن للغاية. لتقليل حجم أعمال التطوير، يتمثل الحل المجدي في إدخال سلسلة ترحيل والسماح لجميع السلاسل بإنشاء عقود عملاء خفيفة مع سلسلة الترحيل هذه. يمكن أن يؤدي هذا بالفعل إلى تقليل عبء العمل من C (n,2) إلى n، ولكن لا يزال ليس صغيرًا جدًا. أصبح النقل الأصلي المباشر عبر السلسلة من سلسلة المصدر إلى السلسلة المستهدفة بمثابة نقل من الدرجة الثانية لسلسلة المصدر ← سلسلة الترحيل ← السلسلة المستهدفة، مما سيؤدي إلى استهلاك إضافي للغاز واستهلاك الوقت.
لذلك، لا يمكن استخدام الحل التقني للعميل الخفيف حاليًا لبناء جسر متعدد السلاسل أكثر شمولية.
بادئ ذي بدء، تمتلك السلاسل العامة المختلفة مناهج مختلفة ولديها موارد مختلفة لدعمها. طالما أنهم لا يعترفون بالهزيمة، فإن النظام البيئي سيكون موجودًا. حتى لو لم يكن التطوير جيدًا جدًا على المدى القصير، فقد تتم ترقيته يومًا ما وسيعود إلى الحياة. إن الشيء المتعلق بالبنية التحتية الأساسية مثل هذه هو معرفة من يمكنه الاستمرار لفترة أطول ومن يمكنه التكيف مع السوق بسرعة.
لا يمكن لـ Bitcoin و Ethereum حل جميع سيناريوهات التطبيق، أو في قطاع معين، هناك دائمًا أشخاص لا يحبون المقام الأول، لذلك يقومون بإنشاء عجلة جديدة، لذلك سيكون المستقبل متعدد السلاسل. في المستقبل، لن تكون الطبقة السفلية عبارة عن سلسلة، لذلك يجب أن يكون المستقبل متعدد البيئات. تتطلب كيفية تحويل الأموال والرسائل بين بيئات متعددة تقنية متعددة السلاسل/عبر البيئة!
ما الذي يثير قلق المستخدمين أكثر عندما يتعلق الأمر بالسلاسل المتقاطعة؟ لا شيء أكثر من النقاط التالية:
السرعة: كم من الوقت يستغرق إكمال عملية عبر السلاسل؟
الرسوم: ما المبلغ الذي أحتاج إلى دفعه مقابل عملية عبر السلاسل
الأمان: هل الجسر عبر السلاسل آمن وهل ستفقد الأموال؟
السيولة: هل هناك سيولة كافية لدعم تجارتي وتأثير مقبول على السعر؟
نطاق الاتصال: كم عدد السلاسل التي تدعمها؟ هل تدعم السلاسل التي أحتاج إلى استخدامها في العمليات عبر السلاسل؟
التجربة: هل التشغيل عبر السلاسل ملائم، مثل ما إذا كان يدعم دفع الغاز، وما إذا كان تقدير التكلفة دقيقًا، وما إذا كان يدعم الاستعلام المرحلي وعرض المتصفح، وما إذا كانت حالات الفشل تحدث بشكل متكرر، وكيفية التعامل مع حالات الفشل، وما إلى ذلك؟
دعونا أولاً نلقي نظرة عامة على خصائص بعض المشاريع من ثلاث وجهات نظر واضحة نسبيًا: الأمان والتكلفة ونطاق الاتصال.
انقر فوق الارتباط لعرض الجدول الواضح (يتم تحديث الجدول باستمرار):
https://docs.google.com/spreadsheets/d/1LKlbd5KJUnQIx3ZBTgyMADhxHtWVwBH9qDRm765tPMw/
لشرح الجسر المتقاطع بشكل كامل، هناك العديد من تفاصيل الأبعاد التي يجب مناقشتها، مثل جميع الأبعاد وتحليل البيانات في الجدول أعلاه. إذن ما هي العوامل التي تهتم بها عند عبور السلاسل؟ ما الجسور المتقاطعة التي تستخدمها غالبًا؟ ما الجوانب التي تعتقد أن الجسور عبر السلاسل يجب أن تركز عليها من أجل التحسين؟ إذا كانت لديك أفكارك، فلا تتردد في التواصل مع المؤلف.