تسخير الأمان المشترك لتحقيق التوافق الآمن بين السلاسل

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

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

مقدمة غير رسمية للأمن المشترك

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

على سبيل المثال، تجمع سلاسل الكتل العامة مثل Bitcoin وEthereum بين خوارزميات الإجماع وآليات مقاومة Sybil - مثل إثبات العمل أو إثبات الحصة - لضمان الحيوية وزيادة تكلفة الهجمات المعادية في نفس الوقت (على سبيل المثال هجمات Sybil ، والهجمات بعيدة المدى ، وهجمات الكسوف ، وهجمات قطاع الوقت ، وهجمات الرشوة ).

على الرغم من أن مخططات الأمان المشتركة تعمل بشكل مختلف، إلا أن الأهداف تدور عادةً حول هدفين:

• زيادة كفاءة رأس المال في شبكات blockchain دون خلق مخاطر إضافية (تراكم المخاطر) أو تقديم افتراضات أمنية إضافية.
• تحسين قدرة شبكات blockchain (خاصة البروتوكولات الناشئة) للدفاع ضد انتقالات الحالة غير الصالحة، وإعادة التنظيم، ومقاومة الرقابة، وغيرها من الهجمات على حيوية البروتوكول وسلامته.

إن الأمان المشترك ليس مفهومًا جديدًا تمامًا؛ على سبيل المثال، تم تقديم التعدين المدمج في عام 2011، مما مكن عمال المناجم من استخدام نفس إثبات العمل المشفر (PoW) لإنشاء كتل على سلسلتين (أو أكثر) مختلفتين من إثبات العمل بتنفيذ إجماع ناكاموتو . سمح هذا للبروتوكولات الأحدث القائمة على إثبات العمل (مثل Namecoin وRootstock)، والتي لم تكتسب رموزها الأصلية قيمة كافية لجذب اهتمام كبير من عمال المناجم، بمشاركة الأمان من خلال إعادة استخدام الموارد الحسابية المخصصة لتأمين شبكة Bitcoin لزيادة صعوبة الكتل على البروتوكول الجديد.

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

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

لم تتطور المفاهيم الحديثة للأمن المشترك لتشمل الأمان المسؤول فحسب، بل تحولت أيضًا إلى استخدام وحدة استثمار مختلفة - رأس المال - كأساس للأمن المشترك. في هذا التصميم، يوجد بروتوكول أساسي يوفر الأمان لبروتوكولات PoS الأخرى المبنية عليه؛ تنضم العقد أولاً إلى الشبكة الأساسية (عن طريق قفل الرمز الأصلي للشبكة كحصة) قبل المشاركة في تأمين الشبكة الثانوية.

يمكن أن يأخذ هذا التصميم أشكالاً مختلفة:

• يشارك المحققون في الشبكة الأساسية والشبكة الثانوية في نفس الوقت
• يتم أخذ عينات عشوائية من مجموعة فرعية من المحققين (من الشبكة الأساسية) للتحقق من صحة الشبكة الثانوية وتأمينها
• يتم تأمين الشبكة الثانوية من خلال مجموعة مستقلة من المحققين المرتبطين بالشبكة الأساسية
• يقوم المحققون من الشبكة الأساسية بإعادة تفويض رأس المال المودع إلى المحققين على الشبكة الثانوية

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

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

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

يجعل هذا من الممكن قطع المحقق لإجراءات مختلفة يمكن تفسيرها على أنها هجوم على سلامة البروتوكول أو حيويته (أو كليهما في بعض الحالات):

• توقيع كتلتين متعارضتين خلال نفس الفترة (المعروفة رسميًا باسم "التضليل")
• التوقيع على كتلة غير صالحة (سواء أثناء الاقتراح أو الإثبات)
• الرقابة على معاملة واحدة أو أكثر
• إخفاء بعض أو كل أجزاء بيانات الكتلة

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

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

• يُطلب من مشغلي العقد إيداع كمية محددة من رموز ETH كضمان في عقد ذكي Ethereum قبل التسجيل كمحققين في شبكة PoS
• خلال العصور، يقوم مقترحو الكتل على بروتوكول PoS بإرسال تجزئات لرؤوس الكتل (والتي تتضمن توقيعات المحققين) إلى Ethereum عن طريق تخزينها في عقد ذكي
• يعتمد الأمان على إثباتات الاحتيال - لا تتحقق السلسلة الأصلية (Ethereum) من انتقالات الحالة، لكنها تستطيع التحقق من مثال مضاد يوضح أن انتقال حالة معينة غير صالح
• يتم تنشيط آلية التقطيع على السلسلة إذا كان هناك نزاع حول انتقال حالة معينة من قبل طرف واحد أو أكثر

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

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

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

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

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

• الاستثمار الرأسمالي واضح (يستثمر المشاركون رأس المال في شراء الرموز لتلبية متطلبات الضمانات) ويمكن الاستفادة منه لضمانات قوية وملموسة للأمن الاقتصادي. على سبيل المثال، من السهل تصور أن البروتوكول من المرجح أن يكون أكثر أمانًا عندما يكون لديه حصة بقيمة 1 ETH لتأمين معاملات بقيمة 0.9 ETH مقارنة بحصته بقيمة 0.9 ETH لتأمين معاملات بقيمة 1 ETH.
• وبما أن المشاركة في الإجماع مرتبطة باستثمار رأس المال "الخالص"، فمن الأسهل توسيع نطاق الأمن الاقتصادي وجعل المحققين يؤمنون بروتوكولات متعددة دون تكبد تكاليف تنسيق مفرطة (خاصة عندما تكون متطلبات الأجهزة منخفضة).

ومع ذلك، فإن كل نهج سيكون له عيوبه، ولا يشكل الأمان المشترك عبر المشاركة استثناءً؛ على سبيل المثال، تحديد مقدار الضمانات التي يجب على المحققين وضعها في بروتوكول إثبات الحصة مشكلة صعبة الحل. سنضع هذا في سياقه من خلال النظر في هذا البيان من الفقرة السابقة: " من السهل تصور أن البروتوكول من المرجح أن يكون أكثر أمانًا عندما يكون لديه حصة بقيمة 1 ETH لتأمين معاملات بقيمة 0.9 ETH مقارنة بحصة بقيمة 0.9 ETH لتأمين معاملات بقيمة 1 ETH. "

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

• إن طلب 1 ETH من المحققين لتأمين أصول بقيمة 0.9 ETH يقلل من كفاءة رأس المال ويؤدي إلى الإفراط في الضمانات.
• يؤدي تأمين معاملات بقيمة 2 ETH مع حصة بقيمة 1 ETH إلى تقليل النطاق الترددي الاقتصادي (أو "الرافعة المالية") في blockchain PoS ويؤدي إلى نقص الضمانات.

في السيناريو المثالي، يفضل مصمم البروتوكول أن يكون هناك 1 ETH من الحصة لتأمين معاملات بقيمة 1 ETH. ولكن من الصعب تحقيق مثل هذه التوازنات في ظروف العالم الحقيقي لأسباب مختلفة؛ على سبيل المثال، فإن مقدار رأس المال الذي سيتم تأمينه لكل وحدة زمنية (دالة على القيمة الهامشية للمعاملات لكل كتلة/عصر) ديناميكي. وهذا يجعل تحديد السند المثالي في نظام إثبات الحصة مشكلة آلية صعبة للغاية واعتبارًا مهمًا لمخططات الأمان المشتركة القائمة على الحصة، مثل إعادة المراهنة (التي سنناقشها في القسم التالي).

الأمن المشترك من إعادة التوطين ونقاط التفتيش

إعادة التثبيت

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

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

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

إن الخطر الآخر هو الخطر الذي وصفناه بإيجاز في السابق والذي يدور حول الموازنة بين الإفراط في الضمانات ونقص الضمانات. في المثال الذي تم تسليط الضوء عليه سابقًا، إذا دخل البنك ب (بنك جون) في موقف مفرط في الاستدانة - حيث يقترض أكثر من قيمة الضمانات المقدمة من جون - وتكبد خسارة، يصبح من الصعب سداد القرض من البنك ب (أو إعادة أصول جون). قد يحمي البنك ب من هذه الحالة المتطرفة من خلال مطالبة البنك أ (بنك جون) بالاقتراض بأقل من قيمة الضمانات المقدمة من جون؛ ومع ذلك، فإن هذا يزيد من عدم كفاءة رأس المال للبنك أ ويقلل من المكاسب من إعادة رهن الضمانات المقدمة من جون في المقام الأول.

تنطبق نفس مجموعة الإيجابيات والسلبيات أيضًا على إعادة المراهنة. قبل المضي قدمًا، من المهم توضيح تفصيل مهم: تمر حصة المراهن دائمًا عبر البروتوكول الأساسي أولاً. على سبيل المثال، سيتعين على المراهن على Ethereum إما إيداع 32 ETH في عقد Beacon Chain أو تفويض ETH إلى محقق يعمل بواسطة خدمة المراهنة - اعتمادًا على ما إذا كان يتم استخدام إعادة المراهنة الأصلية أو إعادة المراهنة السائلة .

على مستوى عالٍ، تتضمن عملية إعادة التخزين في حالة Ethereum ما يلي:

#1: منح حقوق ملكية بروتوكول إعادة التخزين (أو المطالبة) لعملة ETH المودعة

في إعادة الإيداع الأصلية، يتعين على المُصدِّق تغيير عنوان السحب الخاص به إلى عقد ذكي يديره بروتوكول إعادة الإيداع. وبالتالي، بدلاً من ذهاب الأموال مباشرة إلى المُصدِّق بعد الخروج من Beacon Chain، تمر الحصة عبر بروتوكول إعادة الإيداع أولاً قبل الوصول إلى المُصدِّق (سنرى سبب حدوث ذلك قريبًا).

من الممكن أيضًا إيداع تمثيلات قابلة للاستبدال (مشتقات) لعملة ETH المودعة في العقود الذكية لبروتوكول إعادة المودع (إعادة المودع السائل). تُصدر هذه الرموز، التي تسمى "رموز المودع السائل"، من قبل مشغلي المودع كخدمة (مثل RocketPool وLido وCoinbase وما إلى ذلك). وتمثل مطالبة بجزء من ETH المودع من قبل جهة التحقق (بما في ذلك العائد من المكافآت) ويمكن استردادها بنسبة 1:1 مقابل رموز ETH الأصلية.

#2: الاشتراك في شروط التقطيع الإضافية التي يفرضها بروتوكول إعادة الرهان

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

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

ملاحظة مهمة: شروط خفض AVS مستقلة عن شروط خفض الأسعار التي يفرضها إجماع Beacon Chain الخاص بـ Ethereum، لذا يمكن خفض حصة ETH الخاصة بالمحقق حتى لو لم يرتكب جريمة قابلة للخفض على Ethereum نفسها. قد يؤدي هذا إلى ما نسميه "تراكم المخاطر": في مقابل كفاءة رأس المال الأعلى، ترث الشبكة الأساسية مخاطر إضافية أكثر مما كانت لتتحمله بخلاف ذلك. (تراكم المخاطر له أيضًا آثار على بروتوكول EigenLayer الأساسي نفسه كما سنرى لاحقًا.)

#3: الحصول على مكافآت إضافية

يتطلب إعادة الرهان تحمل مخاطر كبيرة (على سبيل المثال، قد يتم قطع المحقق المعاد رهنه عن طريق الخطأ بسبب خلل في آلية القطع على السلسلة) ولكن تمامًا كما يفتح إعادة الرهن السيولة في TradFi، يمكن لإعادة الرهان تحسين كفاءة رأس المال في أنظمة PoS وتوليد عائد أعلى من المتوسط للمراهنين.

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

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

الطبقة الذاتية

EigenLayer هو بروتوكول إعادة تخزين تم إنشاؤه لتوسيع نطاق الأمان الاقتصادي لـ Ethereum لتأمين التطبيقات والشبكات والبروتوكولات الموزعة الجديدة (والتي يطلق عليها بشكل جماعي "الخدمات المعتمدة بنشاط" أو AVSs باختصار). إذا كنت قد قرأت القسم السابق الذي يصف مثال إعادة التخزين على Ethereum، فأنت بالفعل تفهم عمليات EigenLayer على مستوى عالٍ؛ ومع ذلك، سنضيف بعض التفاصيل الإضافية للسياق.

بعد إعادة تثبيت ETH (عن طريق توجيه بيانات اعتماد السحب المرتبطة بالمحقق إلى العقود الذكية التي يتحكم فيها EigenLayer)، يتعين على المحقق تنفيذ المهام المحددة بواسطة AVS التي يرغبون في تشغيلها. على سبيل المثال، إذا كان AVS عبارة عن سلسلة جانبية، فيجب على المحقق المعاد تثبيته تشغيل برنامج العميل للسلسلة الجانبية لتنفيذ المعاملات والتحقق من الكتل، مع كسب المكافآت لتنفيذ هذه المهام بشكل صحيح. على نطاق أوسع، يمكن أن تختلف المهام اعتمادًا على طبيعة AVS:

• تخزين البيانات في شبكة توفر البيانات

• الموافقة على معاملات الإيداع والسحب لجسر عبر السلسلة أو الموافقة على الرسائل لبروتوكول المراسلة عبر السلسلة

• إنشاء وإثبات إثباتات المعرفة الصفرية لتطبيق يركز على الخصوصية أو شبكة مدفوعات محمية

• تخزين وتحقق رؤوس الكتل وتشغيل أجهزة التتابع/أوراكل لبروتوكولات التشغيل البيني عبر السلسلة

  
  

سيلاحظ القراء الأذكياء أمرين: (أ) المهام التي يحددها نظام AVS يمكن أن تكون تعسفية تمامًا (ب) تتطلب المهام المختلفة التي يحددها نظام AVS مستويات متفاوتة من الاستثمار والجهد. لتوضيح النقطة الأخيرة، من الممكن أن نتخيل أن تخزين رؤوس الكتل في بروتوكول عبر السلسلة سيتطلب مساحة قرص/ذاكرة أقل مقارنة بتخزين البيانات وتوفيرها في شبكة توفر البيانات (حتى حيث تعمل تقنيات مثل أخذ عينات توفر البيانات على تقليل أعباء التخزين على العقد الفردية).

هذا هو أحد الأسباب التي تجعل EigenLayer يسمح للمحققين الذين أعيد تعيينهم بتفويض تنفيذ المهام المحددة بواسطة AVS إلى طرف آخر (مشغل) يتقاسم المكافآت المكتسبة من AVS مع المحقق. هذا النهج له مستويات متفاوتة من المخاطر بالنسبة للمحققين الذين أعيد تعيينهم اعتمادًا على مدى تقاسم عبء التقطيع - والذي يمكن أن يحدث إذا فشل المشغل في تنفيذ مهام AVS بشكل صحيح - بين المحقق الذي أعيد تعيينه والمشغل الخارجي.

تحدد كل AVS مجموعة من الشروط التي يمكن بموجبها خفض حصة أحد المشاركين في EigenLayer. على سبيل المثال، قد تقوم شبكة توفر البيانات التي تنفذ آليات Proof of Space/Storage بخفض حصة المشغلين الذين يفشلون في تخزين البيانات للمدة المتفق عليها. يؤدي خفض الحصة إلى تجميد المشغل داخل EigenLayer - مما يمنع المزيد من المشاركة في خدمة أو أكثر تم التحقق من صحتها بنشاط - وفي النهاية خفض رصيد ETH الخاص بالمحقق.

ولكي يحدث التقطيع، يجب أن تكون الجريمة قابلة للإثبات - وهو ما يسمح للبروتوكول الأساسي (الإيثريوم في هذه الحالة) - بالفصل في النزاعات ومعاقبة الطرف غير النزيه. يسمح التصميم الحالي للإيثريوم بتقطيع ما يصل إلى 50٪ من حصة المحقق (16 ETH)، مما يترك لـ EigenLayer الحق في تقطيع النسبة المتبقية (16 ETH) في حالة انتهاك المشغل للقواعد التي حددها AVS أثناء تنفيذ المهام.

تشير آليات التقطيع الخاصة بـ EigenLayer أيضًا إلى خطر خفي لإعادة المراهنة: يؤدي التقطيع بواسطة خدمة واحدة إلى تقليل الرصيد الإجمالي للمحقق في عقود EigenLayer الذكية وسلسلة Beacon Chain الخاصة بـ Ethereum. من المهم أن يظهر سيناريو حالة هامشية، مع ذلك، عندما يحدث التقطيع بسبب خلل في منطق التقطيع لـ AVS معين وليس نتيجة لجريمة يمكن إثباتها. في هذه الحالة، فإن فقدان المكافآت من التحقق من صحة سلسلة Ethereum الرئيسية - والتي يُفترض أنها أعلى من المكافآت من التحقق من صحة AVS - من شأنه أن يجعل عائد الاستثمار من إعادة المراهنة دون المستوى الأمثل من منظور المحقق.

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

يمكن أن يحدث نفس الديناميكية في إعادة إنشاء الهياكل مثل EigenLayer إذا ارتكب محقق إعادة إنشاء (عمدًا أو عمدًا) جرائم قابلة للقطع في نفس الوقت على Beacon Chain في Ethereum وواحد أو أكثر من AVSs. اعتمادًا على مكان حدوث القطع الأول، قد لا يتبقى لدى AVSs الأخرى حصة للقطع - مما يتيح فعليًا هجومًا خاليًا من المخاطر على التطبيقات المؤمنة بواسطة EigenLayer.

لقد أقر فريق EigenLayer بوجود هذا المتجه الهجومي (انظر الملحق ب: تحليل المخاطر الاقتصادية المشفرة لورقة عمل EigenLayer البيضاء ) واتخذ عدة خطوات لمعالجة هذا الخطر. ويشمل ذلك توفير وسيلة رسمية لتقييم نقص الضمانات وزيادة الضمانات من قبل أصحاب المصلحة في AVSs، والإشارة إلى الخطط لتزويد مطوري AVS بمعلومات استشارية عبر لوحة معلومات إدارة المخاطر عند الإطلاق.

سلاسل بولكادوت

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

في بولكادوت، يتم تعيين مجموعات فرعية من المحققين (الذين لديهم رموز DOT مودعون على سلسلة التتابع) بشكل عشوائي إلى سلاسل فرعية (اعتقد أنها "سلاسل فرعية") للتحقق من الكتل - وإثبات الصلاحية المرتبط بها (PoV) - التي ينتجها جامع كل سلسلة فرعية. المجمع هو العقدة المسؤولة عن تنفيذ معاملات السلسلة الفرعية وينشئ "كتلة فرعية" يتم إرسالها إلى مجموعة محققي السلسلة الفرعية للتحقق منها.

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

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

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

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

الأمن بين السلاسل

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

في تكرارها الحالي، تتطلب أمان السلاسل المتداخلة وجود مُحقق (لديه رموز ATOM مراهنة) للتحقق من صحة كل من Cosmos Hub وجميع سلاسل المستهلكين المتصلة بها. ويخاطر المُحقق الذي يتصرف بشكل خبيث على سلسلة المستهلكين بخسارة حصته في سلسلة المزود (Cosmos Hub في هذه الحالة) بسبب التقطيع.

تتطلب عملية قطع التحقق المخالفة عادةً نقل حزمة تحتوي على دليل على سلوك قابل للقطع عبر قناة IBC (الاتصالات بين سلاسل الكتل) بين سلسلة المزود وسلسلة المستهلك. وبالتالي، يمكن النظر إلى أمان السلاسل بين السلاسل باعتباره شكلاً من أشكال إعادة التعيين؛ بالإضافة إلى ذلك، فإنه يحقق هدفًا بالغ الأهمية: تسهيل إطلاق سلاسل الكتل الخاصة بالتطبيقات في نظام Cosmos البيئي.

في السابق، كانت المشاريع التي تحاول إنشاء سلاسل كتل سيادية مطلوبة لإنشاء رمز أصلي للتخزين وجذب عدد كافٍ من المدققين لتزويد المستخدمين الجدد بأدنى حد من ضمانات الأمان. ومع ذلك، يضمن الأمان بين السلاسل إمكانية توسيع نطاق أمان Cosmos Hub (المؤمن بحوالي 2.5 مليار دولار في الرهان وقت كتابة هذا التقرير) لتأمين سلاسل أحدث منخفضة القيمة دون الحاجة إلى توسيع حجم مجموعة المدققين الحالية في Cosmo.

ملاحظة : تعمل النسخة الحالية من أمان Interchain Security في Cosmos على تعطيل التقطيع بناءً على الحزم التي تنقلها سلاسل المستهلكين فقط بسبب خطر وجود كود ضار على سلسلة المستهلكين يؤدي إلى نقل حزم التقطيع المزيفة وتقطيع المحققين الصادقين - بدلاً من ذلك، تخضع المخالفات مثل التصويت المزدوج (توقيع كتلتين على نفس الارتفاع) للتقطيع الاجتماعي عبر الحوكمة. ومع ذلك، فإن التقطيع الاجتماعي يأتي بمخاطره الخاصة، كما هو موضح في المناقشة الأخيرة حول تقطيع المحققين للتوقيع المزدوج على سلسلة المستهلكين (وهو ما يشير أيضًا إلى بعض التعقيدات المرتبطة ببناء بروتوكولات الأمان المشتركة) .

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

تمامًا مثل EigenLayer (حيث يمكن لمحقق Ethereum أن يطلب من المشغل التحقق من صحة بروتوكول ثانوي واحد أو أكثر (AVSs) نيابة عنه)، لا يُطلب من المحقق المفوض وضع أي رهان للتحقق من صحة سلسلة المستهلك. إذا فشل المحقق المفوض في تنفيذ المهام بشكل صحيح (على سبيل المثال، المعاناة من توقف الخدمة أو إنشاء/التصويت على كتل غير صالحة)، يتم قطع المفوض على سلسلة المستهلك وفقًا لقواعد البروتوكول.

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

لجنة مزامنة الإيثريوم

لجنة المزامنة الخاصة بإيثريوم هي مجموعة من 512 جهة تحقق مسؤولة عن التوقيع على رؤوس كتلة Beacon النهائية. يتم إعادة تشكيل لجنة مزامنة جديدة كل 256 حقبة (حوالي 27 ساعة)، مع اختيار الأعضاء من مجموعة جهات التحقق الموجودة في Beacon Chain. لاحظ أنه من المتوقع أن يستمر الأعضاء في أداء واجبات التحقق العادية (بما في ذلك التصديق واقتراحات الكتلة) أثناء المشاركة في لجنة المزامنة.

تم تنفيذ لجنة المزامنة لأول مرة أثناء شوكة Altair لسلسلة Beacon لتمكين العملاء الخفيفين من التحقق من الكتل الجديدة (دون معرفة مجموعة المحققين الكاملة) وتتبع التغييرات في حالة Ethereum. نظرًا لأن المشاركة في لجنة المزامنة تتطلب جهدًا أكبر من مجرد المشاركة في إجماع Beacon Chain، يتلقى الأعضاء مكافأة صغيرة (بالإضافة إلى المكافآت العادية لإكمال مهام سلسلة Beacon).

ومع ذلك، فإن الأعضاء الذين يوقعون على رؤوس كتل غير صالحة لا يخضعون للقطع - على عكس ما يحدث في Beacon Chain. دافع مطورو Ethereum الأساسيون عن هذا التصميم قائلين إن قطع أعضاء لجنة المزامنة الخبيثين من شأنه أن يؤدي إلى مزيد من التعقيد، بينما ألمح آخرون إلى صعوبة التواطؤ بين الأغلبية العظمى من أعضاء لجنة المزامنة (ما يتطلبه الأمر لخداع عملاء Light لقبول رأس كتلة سيئ).

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

على سبيل المثال، يمكن تخفيض رصيد أحد المحققين إلى الحد الأقصى إذا انتهك قواعد البروتوكول أثناء وجوده في لجنة المزامنة، حتى لو تصرف بصدق أثناء مشاركته في إجماع Beacon Chain. يمكننا أيضًا مقارنة لجنة المزامنة بنظام Polkadot parachain وأشكال أخرى من الأمان المشترك الذي يأخذ عينات عشوائية من مجموعة فرعية من العقد للتحقق من صحة بروتوكول فرعي داخل شبكة blockchain الأكبر (على سبيل المثال، لجان ولاية Lagrange، وشبكات Avalanche الفرعية، وبروتوكول State Proofs الخاص بـ Algorand).

نقطة تفتيش

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

تُوصَف هذه الالتزامات بأنها "نقاط تفتيش" لأن السلسلة الأصلية تضمن عدم رجوع تاريخ السلسلة الفرعية إلى تلك النقطة. بعبارة أخرى، تضمن السلسلة الأصلية وتفرض ترتيبًا زمنيًا (قانونيًا) للسلسلة الفرعية، وتحميها من محاولات إعادة تنظيم الكتل وإنشاء شوكة متضاربة (على سبيل المثال، لعكس المعاملات القديمة وإجراء إنفاق مزدوج).

قد تضمن السلسلة الأصلية أيضًا صحة السلسلة الفرعية، وخاصةً عندما تحتوي رؤوس الكتل على معلومات حول من قام بإثبات صحة/إنتاج كتلة معينة. إذا تبين أن الكتلة غير صالحة، يمكن لعقدة صادقة أن تبدأ تحديًا على السلسلة الأصلية (مع تحكيم السلسلة الأصلية في النزاع) وتحفيز التراجع عن حالة السلسلة الفرعية.

بالإضافة إلى ذلك، إذا تم تنفيذ آلية لإدارة حصص المحقق (مثل العقد الذكي) على السلسلة الأصلية، يصبح من الممكن فرض السلامة المسؤولة عن طريق قطع المحققين الذين ينتهكون البروتوكول بعد قبول دليل صالح للاحتيال على السلسلة. إن ضمان السلسلة الأصلية للتاريخ الرسمي للسلسلة الأصلية أمر مهم هنا لأنه يمنع العقد من إعادة كتابة التاريخ (عن طريق إزالة الكتل) لإخفاء أدلة السلوك الخبيث.

تطبق سلاسل الالتزام الجانبية (Polygon PoS)، والبروتوكولات المثلى (Arbitrum Nova/Metis)، وعمليات التجميع، والسلاسل المتكاملة مع بروتوكولات نقاط التفتيش مثل Babylon هذا الشكل من أشكال الأمان المشترك. في جميع الحالات، يستمد البروتوكول أمانه الاقتصادي من سلسلة بلوكتشين خارجية من خلال استخدامها كطبقة تسوية (مسؤولة عن إنهاء الكتل). للسياق، تخزن Polygon PoS وArbitrum Nova/Metis الرؤوس في عقد على السلسلة على Ethereum، بينما تقوم Babylon ببث الرؤوس من مناطق Cosmos المتصلة إلى Bitcoin.

تستخدم عمليات التجميع في الطبقة 2 (L2) آلية مماثلة (نشر جذور الكتل على سلسلة الكتل في الطبقة 1)، مع اختلاف جوهري: يتم نشر البيانات المطلوبة لإعادة إنشاء كتل التجميع أيضًا على طبقة التسوية. وهذا يعني أن طبقة التسوية تضمن أمان التجميع بالكامل (في النهاية). على النقيض من ذلك، قد لا تتوفر البيانات المطلوبة لإعادة بناء حالة سلسلة جانبية للالتزام أو سلسلة متفائلة - خاصة في حالة وجود جهاز تسلسل ضار أو مجموعة محققين تنفذ هجمات حجب البيانات.

الأمان المشترك لبروتوكولات التشغيل البيني عبر السلاسل

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

قد يثير هذا التعريف تساؤلات في ذهن القارئ، مثل:

• لماذا التركيز الصريح على بروتوكولات التشغيل المتبادل؟

• ما هي الفوائد التي يستمدها بروتوكول التشغيل البيني من التكامل مع تقنية الأمان المشتركة؟

  
  

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

مقدمة موجزة عن بروتوكولات التشغيل المتبادل

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

• الجسور التي تنفذ آليات القفل والسك أو الحرق والسك وتسمح بنقل أحد الأصول من blockchain الأصلية (حيث تم إصدارها) لاستخدامها على blockchain غير الأصلية

• بروتوكولات المراسلة التي تسمح للمستخدمين بنقل المعلومات بشكل آمن (عبر حزم البيانات) بين سلاسل الكتل التي لا تشترك في مصدر واحد للحقيقة ولا يمكنها التحقق من حالات بعضها البعض

  
  

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

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

خذ مثال الجسر بين Ethereum وNEAR؛ سيحتاج مشغل الجسر إلى التحقق من صحة المعلومات التالية حول حالة كل سلسلة عندما يقوم المستخدم بربط أحد الأصول (على سبيل المثال، DAI):

• قبل سك رموز nearDAI إلى عنوان NEAR الخاص بالمستخدم، يحتاج مشغل الجسر إلى إثبات أن المستخدم المذكور أودع DAI في عقد الجسر على Ethereum
• قبل إصدار إيداع DAI الأصلي (عند الربط من NEAR إلى Ethereum)، يحتاج مشغل الجسر إلى إثبات أن المستخدم المذكور أحرق رموز nearDAI على NEAR وأرسل إيصال "إثبات الحرق" المطلوب إلى عقد الجسر على NEAR

سيتطلب بروتوكول المراسلة بين السلاسل المذكورة أعلاه متطلبات مماثلة، ولكنها مختلفة قليلاً. إذا طلب مستخدم Ethereum تنفيذ معاملة عبر السلسلة ("استدعاء عقد X على NEAR")، فيجب على البروتوكول التحقق من أن طلب الرسالة تم وضعه في الأصل على Ethereum (عادةً عن طريق استدعاء عقد على السلسلة).

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

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

لتمكين الاتصال بين سلسلتين -والتي سنسميها السلسلة أ والسلسلة ب- فإن بروتوكول التشغيل البيني سيشغل عميلًا خفيفًا للسلسلة أ على السلسلة ب التي تخزن رؤوس الكتل للسلسلة ب (والعكس صحيح). وهذا يمكّنه من التحقق من أدلة مختلفة للحالة/التخزين (رؤوس الكتل، أدلة ميركل، إلخ) التي يمررها المستخدمون (أو أي طرف ثالث) من تطبيق على سلسلة المصدر إلى تطبيق آخر على سلسلة الوجهة. يعمل العميل الخفيف كمصدر للمعلومات ("أوراكل") حول حالات سلسلتي الكتل كما هو موضح في الصورة أدناه:

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

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

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

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

يمكن لبوب أن يعامل الرقم 1 كدليل ملموس على صحة الكتلة، ولكن هذا يعتمد على افتراضات حول المحققين على سلسلة المصدر:

• " إن غالبية المحققين على السلسلة A صادقون ولن يوافقوا على كتلة تحتوي على معاملة واحدة أو أكثر غير صالحة. "
• " إن غالبية المحققين على السلسلة A هم ممثلون عقلانيون اقتصاديًا ولديهم حوافز منخفضة للموافقة على كتلة تحتوي على معاملات غير صالحة. "

هنا، من السهل أن نرى أين يمكن لأي من هذه الافتراضين (أو كليهما) أن ينهار - على سبيل المثال، إذا كانت كمية الرهان < قيمة المعاملات على السلسلة A (على سبيل المثال، المبلغ الذي يمكن سرقته من جسر عبر معاملات احتيالية)، فإن المحققين لديهم حافز لإتمام كتلة غير صالحة - حتى لو كان هذا يعني التعرض للضرب - لأن الربح من الهجوم يفوق التكاليف.

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

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

تحليل آليات الأمن عبر السلسلة الحالية

لقد توصل مصممو البروتوكول منذ ذلك الحين إلى حلول لمشكلة التحقق من صحة المعلومات في الاتصالات عبر السلاسل؛ وأكثرها شيوعًا هو استخدام طرف ثالث للتحقق من وجود/صلاحية معاملة عبر السلاسل. والسبب بسيط: قد لا يتمكن تطبيق على السلسلة أ من التحقق من حالة السلسلة ب، ولكن يمكننا أن نجعله يتحقق من أن مجموعة من الأشخاص (نثق بهم أو نتوقع منهم أن يكونوا صادقين من خلال بعض الآليات) قد تحققوا من صحة قطعة من المعلومات (أو الادعاء) تشير إلى حالة السلسلة ب.

يُطلق على هذا "التحقق الخارجي" لأن طرفًا آخر خارج سلسلة الكتل يعمل كمصدر للحقيقة للأحداث التي تحدث على السلسلة ويتضمن (عادةً) محققًا واحدًا أو أكثر ينفذ التوقيعات على رؤوس الكتل من سلسلة المصدر. بمجرد أن يتلقى التطبيق على سلسلة الوجهة هذا الرأس الموقع، يمكنه بعد ذلك التحقق من أدلة الحالة المختلفة التي يقدمها المستخدم (الأرصدة والأحداث والإيداعات/السحوبات وما إلى ذلك) ضده.

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

على سبيل المثال، قد يخترق شخص ما عددًا كافيًا من الموقّعين في مخطط متعدد التوقيعات ويشرع في تفويض عمليات سحب احتيالية من جسر عبر سلسلة. يعد إعداد MPC أكثر أمانًا قليلاً (يمكن تغيير عتبة الموافقة وتدوير مشاركات المفاتيح بشكل أكثر تكرارًا)، لكنه لا يزال عرضة للهجمات (خاصة في الحالات التي يتحكم فيها طرف واحد في غالبية مشاركات المفاتيح).

المراهنة

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

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

بطبيعة الحال، فإن وجود نظام مرخص به مشاركون يمكن التعرف عليهم يفتح الباب أمام الهجمات المعادية؛ على سبيل المثال، قد ينجح المهاجم في انتحال شخصية بعض هؤلاء المدققين أو رشوتهم وبالتالي يتولى السيطرة على الأغلبية. والأسوأ من ذلك، أن نظام إثبات السلطة (PoA) حيث لا يتم وضع المدققين فعليًا (ويتم تعيينهم ببساطة) يقلل من تكلفة مهاجمة النظام إلى الصفر (يمكن للمهاجمين ببساطة اختراق مدققي إثبات السلطة من خلال مخططات الهندسة الاجتماعية واختطاف النظام، على سبيل المثال).

إن نظام المراهنة بدون إذن يزيد من تكلفة إفساد النظام من خلال السماح لأي طرف مهتم (بقدر مناسب من رأس المال) بالبدء في التحقق من صحة العمليات عبر السلسلة. وإذا تم دمجه مع بروتوكول إجماع يتطلب ≥ ⅔ أغلبية للتصديق على رؤوس الكتل، فإن تكلفة إفساد النظام تساوي فعليًا الحد الأدنى المطلوب لإفساد غالبية المحققين في النظام. بالإضافة إلى ذلك، فإن المستخدمين لديهم افتراضات ثقة أقل (يمكن تقليص المحققين)، وتزيد مجموعة ديناميكية من المحققين من صعوبة اختراق عقد معينة من خلال تقنيات مثل الهندسة الاجتماعية.

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

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

• إيداع مبلغ كبير من المال مقدمًا (كحصة) قبل المشاركة في مهام التحقق

• ترك الأموال دون استخدام لفترة طويلة (من أجل السلامة، تفرض بروتوكولات نقاط البيع تأخيرات طويلة على عمليات السحب - بعضها يصل إلى أسابيع أو أشهر - لمنع الحالات المتطرفة حيث يرتكب المحقق جريمة قابلة للتخفيض ويحاول السحب على الفور لتجنب خسارة الأموال بسبب التخفيض)

  
  

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

التحقق المتفائل

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

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

يحول التحقق المتفائل مشكلة الاضطرار إلى الثقة في عدد كبير ( k من n ) أو أغلبية ( m من n ) من المحققين إلى مشكلة الثقة في محقق واحد ( 1 من n ) ليتصرف بصدق. لكي تظل البروتوكولات التي تم التحقق منها بشكل متفائل آمنة، يكفي أن يكون هناك ممثل واحد لديه بيانات حالة كافية لإعادة تنفيذ المعاملات وإنشاء أدلة احتيال لتحدي المعاملات الاحتيالية خلال فترة التأخير (ومن هنا جاء افتراض الأمان 1 of n ).

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

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

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

نظرًا لأن إثباتات الاحتيال تفاعلية بطبيعتها (في الغالب)، فإن التحدي غير الصحيح من شأنه أن يتسبب في إهدار المرسلين الصادقين للموارد - بما في ذلك الأموال التي يتم إنفاقها على رسوم الغاز للمعاملات على السلسلة. وبالتالي، قد يفقد المرسلون الصادقون الحافز لنقل المعلومات عبر السلسلة، مما قد يترك فرصة للمرسلين غير الصادقين لنقل المعلومات عبر السلسلة. قد يؤدي إلزام المتحدين بنشر إيداع أدنى إلى ردع الإزعاج، ولكن الإيداع الأدنى المرتفع قد يثبط عزيمة المراقبين الصادقين (الذين يفتقرون إلى رأس المال) عن تحدي تحديثات الحالة غير الصالحة.

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

التحقق التشفيري

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

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

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

ومن السهل أيضًا أن نرى كيف يعمل هذا النهج على التخلص من بعض العيوب المرتبطة ببعض آليات الأمان عبر السلسلة التي تمت مناقشتها سابقًا:

1. انعدام كفاءة رأس المال : إن استخدام zkSNARKs للتحقق من حالات السلاسل المتقاطعة يلغي الحاجة إلى آلية المراهنة/الترابط وعدم الكفاءة المرتبطة بإخضاع الرموز لفترة حظر. وعلى نحو مماثل، لا يحتاج المرسلون إلى نشر سند (على عكس التحقق المتفائل) قبل تقديم ادعاءات حول المعاملات عبر السلسلة لأن الدليل المصاحب يتحقق من الادعاء بإيجاز .
2. زمن انتقال منخفض : بدون الحاجة إلى تنفيذ فترة تأخير - لتمكين إثباتات الاحتيال في الوقت المناسب - يمكن لبروتوكول التشغيل البيني تنفيذ رسالة عبر السلسلة أو عملية ربط بمجرد التحقق من إثبات SNARK الذي يؤمنها. ومع ذلك، فإن إنشاء الإثبات يتطلب عادةً عمليات حسابية مكثفة، لذا قد يكون النظام الذي تم التحقق منه خارجيًا أكثر كفاءة مقارنة ببروتوكول التشغيل البيني القائم على SNARK.

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

على سبيل المثال، نظرًا لأن التحقق من صحة جميع التوقيعات عبر مجموعة محققي Ethereum ( أكثر من 925000 محقق حسب الأرقام الحالية ) في دائرة zkSNARK قد يكون مكلفًا، فقد اعتمدت بعض البروتوكولات تاريخيًا وسائل أخرى لاستنتاج أدلة على حالة Ethereum. أحد الأمثلة هو جسر " Ethereum to X " (حيث يمكن أن يكون X أي blockchain) الذي يولد دليلاً على أن رؤوس الكتل تم توقيعها من قبل أغلبية لجنة مزامنة Ethereum (التي قدمناها سابقًا).

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

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

تعتمد أمان جسور العميل الخفيف وجسور ZK وإثباتات لجنة المزامنة على التحقق من التوقيعات من لجنة مزامنة عميل Ethereum الخفيف. ونظرًا لأن حجم لجنة المزامنة ثابت، فإن الأمان الاقتصادي الذي يدعمها محدود أيضًا بفترة زمنية مدتها 27 ساعة. وبمجرد تنفيذ التقطيع في النهاية للجان مزامنة Ethereum، سيتم تحديد الأمان الاقتصادي على النحو التالي:

• الأمن الاقتصادي للجنة المزامنة = 512 عقدة * 32 إيثريوم * 1650 دولارًا أمريكيًا / إيثريوم = 27،033،600 دولارًا أمريكيًا
• الحد الأدنى للتسوية للجنة المزامنة = 27,033,600 دولار × 2/3 = 18,022,400 دولار

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

فكر في موقف حيث يبلغ مجموع قيمة جميع الأصول المؤمنة بواسطة جميع جسور العميل الخفيف والعميل الخفيف ZK مبلغًا k. عندما يكون k < 18 مليون دولار، تكون جميع الأصول المؤمنة عبر الجسور آمنة، حيث إن الهجوم غير مجدٍ اقتصاديًا. مع نمو k بحيث يصبح k > 27 مليون دولار، يصبح من المربح لمجموعة من الجهات السيئة في لجنة المزامنة أن تشهد على الكتل الخبيثة من أجل المساس بالأصول المؤمنة.

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

لجان ولاية لاغرانج: الأمن المشترك كخدمة لبروتوكولات الاتصال عبر السلسلة

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

ما هي لجان ولاية لاجرانج؟

شبكة لجنة ولاية لاغرانج (LSC) عبارة عن بروتوكول عميل خفيف ZK بسيط وفعال لعمليات التجميع المتفائلة (ORUs) التي تستقر على Ethereum (على سبيل المثال، Optimism وArbitrum وBase وMantle). تشبه LSCs مفهوميًا لجنة Sync Committee الخاصة بـ Ethereum وتدعم التطبيقات القائمة على العميل الخفيف - مثل الجسور وطبقات الرسائل بين السلاسل - التي تريد استخدام حالة التجميع المتفائلة دون تحمل افتراضات الثقة المفرطة.

لجنة ولاية لاغرانج هي مجموعة من عقد العملاء التي أعادت تأمين 32 ETH بقيمة ضمان على Ethereum عبر EigenLayer. بعبارة أخرى، شبكة لجنة ولاية لاغرانج هي خدمة AVS أو خدمة تم التحقق من صحتها بنشاط . تشهد كل لجنة ولاية لاغرانج على نهائية الكتل لعملية تجميع متفائلة معينة بمجرد الانتهاء من دفعات المعاملات المرتبطة على طبقة توفر البيانات (DA). تُستخدم هذه الشهادات بعد ذلك لتوليد أدلة الحالة، والتي يمكن للتطبيقات التعامل معها كمصدر للحقيقة لحالة عملية التجميع المتفائلة المعينة.

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

كيف تعمل شبكة لجنة ولاية لاغرانج؟

المكونان الرئيسيان لبروتوكول لجنة ولاية لاغرانج هما جهاز التسلسل وعقد العميل ("عقد العميل" هو اسم آخر للمحققين المسجلين في لجنة ولاية لاغرانج). جهاز التسلسل هو كيان مركزي مسؤول عن تنسيق الشهادات في شبكة لجنة ولاية لاغرانج وتقديم الشهادات للمثبتين الذين ينتجون أدلة الحالة. عقدة جهاز التسلسل هي في الواقع مزيج من ثلاث وحدات ذات وظائف مختلفة: Sequencer Consensus Governance .

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

(1). Block_header : رأس كتلة التجميع المتفائل النهائي (ORU). تعني "النهائية" هنا كتلة مشتقة من عقد التجميع من بيانات المعاملات النهائية على طبقة DA معينة. على سبيل المثال، يتم تعريف النهائية بواسطة رأس L2 الآمن لعمليات التجميع المتفائلة/المتفائلة وكتلة L2 ذات نهائية معادلة لـ Ethereum لسلاسل Arbitrum وArbitrum Orbit. (تعرف على المزيد حول نهائية التجميع في هذه المقالة .)

(2). current_committee : التزام تشفيري بمجموعة المفاتيح العامة المرتبطة بعقد العميل المسموح لها بتوقيع كتلة ب. من المتوقع أن تقوم عقدة العميل ببناء شجرة ميركل، حيث تمثل الأوراق المفاتيح العامة لجميع أعضاء اللجنة النشطين، وتوقيع جذر شجرة ميركل بمفتاح BLS12–381 الخاص بها.

(3). next_committee : التزام تشفيري بمجموعة المفاتيح العامة المرتبطة بالعقد المسموح لها بتوقيع الكتلة التالية (b+1). يجب على العقد التي ترغب في مغادرة لجنة الدولة تقديم معاملة في نهاية فترة الإثبات إلى عقد Lagrange Service على Ethereum الذي يتعامل مع تسجيل وإلغاء تسجيل المشغلين في AVS للجنة الدولة.

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

ELI5: ما هي أدلة الحالة؟

إثبات الحالة هو إثبات تشفيري لحالة سلسلة الكتل: إثبات لرأس كتلة من سلسلة مصدر (سلسلة A)، والذي يمكن استخدامه لإثبات وجود حالة على سلسلة المصدر، مثل معاملة معينة، لسلسلة الوجهة. بعبارة أخرى، يمثل إثبات الحالة إثباتًا لحالة سلسلة المصدر عند ارتفاع كتلة محدد.

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

تم تصميم شبكة لجنة ولاية لاجرانج لتوليد أدلة الحالة لعمليات التجميع المتفائلة المؤمنة بواسطة إيثريوم. يتم توليد أدلة الحالة من خلال تجميع توقيعات BL12–381 على المجموعة الموصوفة سابقًا ( block_header و prev_committee و next_committee ) من ثلثي العقد في لجنة الحالة على الأقل. ثم يتم توليد دليل الحالة بواسطة دائرة SNARK بناءً على الوزن الجماعي للتوقيعات التي تشهد على رأس كتلة معين.

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

• على الأقل ⅔ من العقد n في لجنة الدولة وقعت على رأس الكتلة ب.

• تساوي اللجنة current_committee للكتلة b شجرة next_committee للكتلة b-1.

• الكتلة ب-1 هي إما كتلة التكوين، أو أنها صالحة فيما يتعلق بهذه الشروط الثلاثة.

  
  

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

كيف تتفاعل شبكة لجنة ولاية لاغرانج مع مجموعة البيانات الضخمة ZK؟

في أول منشور من سلسلة منتجات Lagrange، سلطنا الضوء على العلاقة بين الأجزاء المختلفة من مجموعة ZK Big Data Stack : لجان حالة Lagrange، وRecproofs، وzkMapReduce، ومعالج Lagrange المساعد. توفر كل من هذه المكونات، عند دمجها معًا، وصولاً آمنًا وفعالًا إلى الحوسبة الديناميكية والتعبيرية لبيانات الحالة:

#1. تتكامل شبكة لجنة ولاية لاغرانج مع المكونات الأخرى لمجموعة البيانات الضخمة ZK لتحسين الأداء

نحن نستخدم Recproofs وzkMapReduce لإنشاء أدلة مفتاح عام مجمعة قابلة للتحديث (APK) للجان الدولة - مما يسمح لنا بتجنب العملية المكلفة والتي تستغرق وقتًا طويلاً لتفكيك وإعادة تجميع المفاتيح العامة لغير الموقعين كلما كان من الضروري إنشاء توقيع مجمع جديد.

إن التجميع الفعّال لمفاتيح BLS العامة للمشغلين في لجان ولاية لاغرانج AVS يسهل معدلات المشاركة الأعلى في AVS دون زيادة التكلفة الحسابية للتحقق من الشهادات من عقد لجان الولاية. وهذا هو السبب في أن لجان ولاية لاغرانج قادرة على دعم مجموعة غير محدودة محتملة من العقد وإظهار أمان فائق الخطية مع تجميع المزيد من رأس المال في لجان الولاية. يمكنك معرفة المزيد عن هذه الخاصية في منشورنا حول توسيع نطاق الثقة القابلة للبرمجة على EigenLayer باستخدام ZK Big Data .

كما أن دمج لجان ولاية لاغرانج مع مجموعة البيانات الضخمة ZK له فوائد أكثر مباشرة لتطبيقات العميل التي تستفيد من أدلة حالة لاغرانج. على سبيل المثال، يمكننا استخدام ميزة zkMapReduce في معالج لاغرانج المساعد لدمج أدلة حالة متعددة من سلاسل التجميع المتفائلة n في دليل حالة واحد متعدد السلاسل . وهذا يسمح بـ "التحقق المتداخل"، حيث تتحقق معاملة واحدة على السلسلة في نفس الوقت من حالة عمليات التجميع المتفائلة المتعددة، وتقلل من تكاليف التحقق لخدمات العميل.

#2: يتكامل معالج Lagrange المساعد مع شبكة لجنة ولاية Lagrange لتشغيل الحوسبة خارج السلسلة التي لا تتطلب الثقة

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

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

لماذا تعد شبكة لجان ولاية لاغرانج بمثابة عامل تغيير في قابلية التشغيل البيني في التجميعات المتفائلة

أمان مشترك وخطي للغاية لعملاء التجميع الخفيف المتفائلين

حاليًا، تكون بروتوكولات التشغيل البيني التي تدعم الربط بين سلاسل التجميع المتفائلة مسؤولة بشكل مستقل عن التحقق من حالة سلاسل المصدر. تعتمد أمان بروتوكولات التشغيل البيني هذه على آلية التحقق من صحة رأس الكتلة.

تحاول بعض بروتوكولات الاتصال عبر السلاسل تقليل افتراضات الثقة من خلال تنفيذ التخزين المحلي وطلب مجموعة من المتحققين لربط الضمانات قبل التصديق على رؤوس الكتل لسلاسل المصدر. ومع ذلك، يؤدي هذا إلى تفتيت الأمن الاقتصادي عبر بروتوكولات عبر السلاسل المختلفة، حيث تكون تكلفة إفساد مجموعة فرعية ( k من n ) من مجموعة المدققين لكل بروتوكول أقل.

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

على عكس بروتوكولات العميل الخفيفة الأخرى، تدعم شبكة لجنة الدولة التابعة لشركة Lagrange مجموعة ديناميكية غير محدودة من عقد التصديق. وبالتالي، يمكن للوزن الاقتصادي للتوقيعات التي تؤمن كل تصديق أن يتوسع ديناميكيًا مع تجميع المزيد من الحصص في لجان الدولة - مما يتيح زيادة فائقة الخطية في الأمان ويزيد من صعوبة مهاجمة بروتوكولات السلسلة المتكاملة بشكل معزول.

وهذا يجعل من لجنة ولاية لاغرانج "منطقة أمان مشتركة" يمكن لأي بروتوكول عبر السلسلة (بغض النظر عن حجمه) الاتصال بها لتحقيق أقصى قدر من الأمان - على غرار الطريقة التي تؤمن بها سلسلة التتابع على بولكادوت ومركز كوزموس على كوزموس الشبكات الثانوية في النظام البيئي متعدد السلاسل. بالإضافة إلى ذلك، فإن التكامل مع برنامج الوسيط لإعادة التعيين من EigenLayer يمكّن شبكة لجنة ولاية لاغرانج من توسيع نطاق الأمان الاقتصادي لإيثريوم لتأمين عدد عشوائي من بروتوكولات الاتصال عبر السلسلة.

تقليل النفقات العامة لفرق تطوير المنتجات عبر السلسلة

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

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

أمان إضافي لبروتوكولات التشغيل البيني الحالية

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

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

كيف تقارن شبكة لجنة ولاية لاغرانج مع آليات الأمن عبر السلسلة الأخرى؟

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

التحقق الخارجي من خلال محققين بدون إذن

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

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

نلاحظ أيضًا أن بروتوكولات الإجماع المستخدمة في إثبات الحصة التقليدية تفرض قيودًا على عدد المصدقين (على سبيل المثال، يحدد Tendermint BFT الحد الأقصى للمشاركة عند 100-200 مصدق) وتمنع بروتوكولات إثبات الحصة التقليدية من توسيع نطاق الأمان الاقتصادي كلما دعت الحاجة. وعلى العكس من ذلك، تستخدم شبكة لجنة ولاية لاغرانج آلية إثبات تدعم مجموعة غير محدودة محتملة من العقد المشاركة في الإجماع. وهذا يضمن أن الشبكة يمكنها زيادة عدد المصدقين ديناميكيًا وبالتالي، توفير ضمانات أكثر قوة للأمان الاقتصادي لتطبيقات العملاء.

التحقق الخارجي من خلال المحققين المعتمدين

تعتمد بروتوكولات السلاسل المتقاطعة القائمة على إثبات السلطة (PoA) على الشهادات لمنع الرؤوس من مجموعة صغيرة من العقد المسموح لها. وقد أثبتت هذه الأساليب تاريخيًا أنها غير آمنة مع وقوع حوادث بارزة بما في ذلك اختراق Ronin (تم اختراق 5 من أصل 7 محققين) واختراق جسر Harmony One (تم اختراق 2 من أصل 5 محققين).

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

الجسر الكنسي

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

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

خاتمة

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

لقد استكشفنا أيضًا لجان ولاية لاغرانج: حلنا المشترك للأمن كخدمة المصمم مع وضع بروتوكولات الاتصال عبر السلسلة في الاعتبار. تعد لجان ولاية لاغرانج جزءًا من رؤيتنا لتمكين التشغيل البيني الآمن والفعال والحد من الثقة وستكون جزءًا من مجموعة أكبر تمكن المطورين من بناء تطبيقات قوية عبر السلسلة للمستخدمين.

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

الشكر والتقدير

ساهم في كتابة هذه المقالة إيمانويل أوسيكا ( 2077 Research )، وعمر يحيى ( Lagrange Labs )، وإسماعيل هيشون رضا زاده ( Lagrange Labs )، وأمير رضا زاده ( Lagrange Labs ). تعاقدت مختبرات لاغرانج مع إيمانويل لدعم كتابة هذه المقالة.

لقد تم نشر نسخة من هذه المقالة مسبقًا هنا .