إذا لم تقرأ الجزء الأول من سلسلة كيفية جعل الرموز عبر السلاسل قابلة للتبادل مرة أخرى، قد ترغب في ذلكتحقق من ذلكأولاً - يفسر كيف تفقد الرموز المتمرنة قابليتها للتبادل والتحديات التي يخلقها ذلك. في الجزء الثاني، نستكشف ERC-7281، وهو معيار جديد يبسط تحويل الرموز عبر السلاسل، ويعزز الموثوقية، ويمنح المرسلين مزيدًا من السيطرة.
حتى الآن، لقد استكشفنا حلول مختلفة لمشكلة جعل الرموز المتقاطعة قابلة للتبادل وحل مشكلات تجزئة السيولة وتجربة المستخدم السيئة من التمثيلات غير الكنسية لرمز أصلي يتداول على سلاسل الكتل غير الأصلية:
يعرض كل من هذه الأساليب مقايضات ، لذلك من المناسب فقط أن يحاول اقتراح ERC-7281 لإنشاء رموز مميزة قابلة للاستبدال أخذ الأفضل من كل نهج لإنشاء حل أكثر شمولية وكفاءة ويمكن الوصول إليه للبروتوكولات التي ترغب في نشر الرموز عبر السلسلة دون المقايضة بالأمان أو السيادة أو تجربة المستخدم.
ERC-7281: الرموز المميزة ذات الجسر السياديهو مقترح لتمكين إنشاء تمثيلات كانونية لرمز تشفيري تكون متوافقة وقابلة للتبادل مع التمثيلات التي تم ضربها بواسطة العديد من الجسور المختلفة. يعمل ERC-7281 عن طريق توسيع واجهة ERC-20 لتشمل:
1) تعيين مشغلي الجسور لسك وحرق الرموز عند الجسر بين السلاسل ؛
2) تقييد سرعة إنتاج وحرق الرموز لكل مشغل جسر معتمد، على سبيل المثال، تحديد حدود صغيرة للجسور المركزية وحدود أعلى للبروتوكولات الأكثر أمانًا.
نظرًا للفارق الطفيف بين ERC-7281 و ERC-20 tokens، وصف الكتاب الفنيون في EIP الأولى بـ "xERC-20". بالنسبة للقراء الذين يحتاجون إلى نظرة عامة على ERC-20 tokens، لديها OpenZeppelin ممتازة دليل حول الموضوع.
في جوهرها ، ينفذ كل عقد رمز مميز ERC-20 واجهة ERC-20 التي تحدد توريد الرمز المميز العالمي وتخزن معلومات حول العناوين التي تمتلك الرمز المميز والمبلغ الذي تمتلكه. يتضمن ERC-20 أيضا وظائف مفيدة لإدارة الوصول إلى الرموز المميزة للمستخدم (عبر الموافقات) واسترداد المعلومات حول الرمز المميز - مثل إجمالي العرض المتداول والرصيد لعنوان معين.
ميزة إضافية يضيفها ERC-7281 إلى مواصفات ERC-20 هي صندوق قفل اختياري يعمل كعقد تفاف (مشابه لعقد WETH (Wrapped Ether. يقوم عقد صندوق القفل بتغليف رموز ERC-20 في رموز xERC-20 من خلال آليات النقد والحرق المألوفة ويجعل ERC-7281 متوافقًا مع عقود رموز ERC-20 الحالية التي تفتقر إلى واجهة حرق/نقد وغير قابلة للترقية.
باستخدام الإطار المقدم في المقالة السابقة، يمكننا تصنيف ERC-7281 كنهج "ثق في مصدر رمز الرموز + ثق في موفر الجسر (المعتمد)" لتشكيل الرموز متعددة السلاسل. يتحكم رمز ERC-7281 المنشأ عبر سلاسل متعددة من قبل مصدره (على عكس التصاميم البديلة للرموز عبر السلاسل التي عادة ما تتطلب التنازل عن السيادة). على الرغم من أن المصدر ما زال معرضًا لخطر تعرض جسر معتمد لحادث أمني، إلا أن المصدر يدير هذا الخطر عن طريق اختيار مقدمي الجسر المعتمدين يدويًا وفرض الحد الأقصى للمعدل.
الفارق الكبير، الذي سنستكشفه في هذا التقرير، هو أنه يمكن لمُصدري الرموز ضبط التعرض للاختراقات والاستغلالات عن طريق فرض حدود ديناميكية على عدد الرموز التي يمكن لمشغل جسر معين إنتاجها/حرقها. تسمح ERC-7281 أيضًا لمُصدر الرموز بتحديد مزودي جسور متعددين ليتمكنوا من إنتاج نفس الرمز الكنسي عبر السلاسل، مما يقلل من الاعتماد على مزود واحد لمعالجة عمليات عبور السلاسل.
تجعل كلتا الميزتين ERC-7281 تحسنا كبيرا على الأساليب التقليدية لتسهيل الربط عبر السلاسل لرموز البروتوكول ولها تأثيرات إيجابية من الدرجة الثانية للمستخدمين وموفري البنية التحتية للتشغيل البيني (خاصة المجمعين) ومطوري التطبيقات. بعد مناقشة المواصفات في القسم التالي ، سنراجع مزايا وعيوب تنفيذ ERC-7281.
في المواصفة، ينتشر مشروع عقدًا جديدًا متوافقًا مع ERC20 ينفذ واجهة IXERC20. يقوم مشغلو الجسر بطبع الرموز المميزة للمستخدمين على سلسلة الوجهة بعد حرق الوديعة على سلسلة المصدر. يتحقق عملية الطباعة من أن كمية الرمز المميز لا تتجاوز الحد الخاص بالجسر ويقوم بتحديث إجمالي العرض الكلي للرمز المميز والحد الخاص بطباعة الجسر في حال نجاحها.
بالنسبة للرموز ERC-20 القائمة بالفعل، يتم تطبيق منطق "صندوق القفل": يقوم مزود الجسر بتغليف رموز ERC-20 التي يقوم المستخدمون بإيداعها في رموز xERC-20 عن طريق نقلها إلى عقد Lockbox. يقوم Lockbox بعد ذلك بالموافقة على الجسر لطباعة كمية مكافئة من رموز xERC-20.
يتم حرق الرموز المميزة xERC-20 التي تم سكها بواسطة جسر على سلسلة الوجهة على سلسلة المصدر باستخدام الدالة burn(). تضمن هذه العملية أن مبلغ الرمز المميز لا يتجاوز حد حرق الجسر ، ويزيده ، ويقلل من إجمالي المعروض من رمز xERC-20. تقوم طبقة نقل الجسر بنقل رسالة النسخ إلى الوجهة. يتحقق عقد الجسر على الجانب الوجهة من الرسالة وينقل كمية متساوية من رموز xERC-20 المميزة إلى عنوان المستخدم على تلك السلسلة. يقلل هذا السك من إجمالي المعروض من الرمز المميز وحد سك الجسر.
لربط الرموز مرة أخرى بسلسلة الوجهة، يحرق مشغل الجسر الرموز xERC-20 على السلسلة البعيدة، ويقدم عنوان المستخدم وكمية الرموز. يتم نقل إيصال الحرق إلى سلسلة الوجهة بواسطة طبقة النقل. إذا تم التحقق من رسالة الحرق، يقوم مشغل الجسر بطبع وحرق رموز xERC-20 جديدة على سلسلة الوجهة للمستخدم. عند التحقق من إيصال الحرق من قبل عقد الرمز، يقوم مشغل الجسر بإطلاق رموز ERC-20 المودعة للمستخدم. يقلل حرق رموز xERC-20 على سلسلة الوجهة من إجمالي العرض الكلي للرموز وحد الحرق للجسر.
نقطة مهمة: يمكن لعقد xERC-20 من الناحية الفنية سك الرموز المميزة دون أن يتحقق الجسر من الإثباتات. لقد وصفنا النهج القياسي (اقرأ: متوقع) ، ولكن الجسور التي لا تنفذ أي نوع من التحقق من الرسائل - أو تنفذ آليات جديدة للتحقق من الرسائل عبر السلاسل - يمكن إدراجها في القائمة البيضاء لسك وحرق رموز xERC-20. كل هذا يتوقف على ما يمكن أن تقبله جهة إصدار الرمز المميز.
الدالة setBridgeLimits هي دالة محمية لا يمكن استدعاؤها إلا من قبل مالك عقد الرمز المميز. تسمح هذه الوظيفة بتعيين عنوان عقد الجسر وتحديد الحد الأقصى لمقدار الرموز المميزة التي يمكن للجسر سكها (mintingLimit) ونسخها (burningLimit) للمستخدمين. يمكن للمالك تحديث هذه الحدود ، مما يتيح ضبط قدرات الجسر حسب الحاجة. على سبيل المثال، إذا تم اكتشاف مشكلات أمنية في البنية الأساسية لموفر الجسر، فيمكن تقليل mintingLimit لتقليل المخاطر. على العكس من ذلك ، قد تؤدي التحسينات الأمنية إلى زيادة حد السك.
تشمل مواصفات xERC-20 أيضًا وظائف للتحقق من حدود الحرق والضخ للجسور المعتمدة للتعامل مع الرمز. يُعيد "mintingMaxLimitOf" الحد الأقصى لكمية الرموز التي يمكن لجسر إنشاؤها، وبالتالي، يُعيد "burningMaxLimit" الحد الأقصى لكمية الرموز التي يمكن لجسر حرقها خلال فترة محددة. بالإضافة إلى ذلك، تُظهر هذه الوظائف الرموز المتبقية التي يمكن للجسر حرقها وإنتاجها قبل بلوغ الحدود المحددة مسبقًا.
تعد وظائف العارض هذه مفيدة لمجمعي الجسور الذين يحتاجون إلى معرفة الحدود المتاحة لموفري الجسور المختلفين قبل توجيه المعاملات. إذا وصل الجسر إلى حد النسخ أو سك العملة على سلسلة المصدر أو الوجهة، فقد يؤثر ذلك على المعاملات الجارية وتجربة المستخدم. لذلك، يفضل المجمعون توجيه الطلبات إلى الجسور التي لم تصل إلى حدود سكها وحرقها ويمكنها إجراء مبادلة مبلغ معين.
تتضمن مواصفات واجهة xERC-20 للرمز المميز "Bridge" struct الذي يحتوي على "burningParams" و "mintingParams" (معلمات وظيفة تحديد الحد لرمز xERC-20 تحكم في كمية الرموز التي يمكن للجسر حرقها وطبعها على مدى فترة محددة). تحدد "maxLimit" الحد الأقصى لطباعة الرموز وحرقها وتزيد كل ثانية بسعر محدد مسبقًا ("ratePerSecond").
هنا حيث نتناول نقطة احتمالية للارتباك: "الحد الأقصى" (المحدد لكل من حرق وتحديد الحد الأقصى) يبدو وكأنه سقف على عمليات التحديد والحرق على جدول زمني معين - وليس حد للمعدل الذي يقوم بتخفيض تحديد وحرق وفقًا لعتبات محددة مسبقًا خلال النافذة الزمنية المحددة مسبقًا. "الحد الحالي" يحدد كمية يمكن للجسر تحديد أو حرقها ويزيد بمعدل محدد مسبقًا. على النقيض، "الحد الأقصى" يحدد كمية يمكن للجسر تحديدها أو حرقها يوميًا.
تعتبر معلمات النسخ والسك ذات صلة بشكل أساسي بمالكي الرموز المميزة (ومشغلي الجسور بدرجة أقل). ومع ذلك ، فإن معلمات الحد الأقصى والحالية هي اعتبارات مهمة للمستخدمين ومشغلي الجسور. على سبيل المثال، يمكن أن يؤثر الحد الحالي على مدى قدرة المستخدم على الربط بثقة باستخدام بروتوكول عبر السلاسل دون التعرض للتأخير في تلقي رموز xERC-20 المميزة في الوجهة.
لا يحدد رمز ERC-20 الأصلي وظائف لزيادة وتقليل المعروض من الرمز المميز (مرة أخرى عندما كانت "الرموز المميزة" تعني إنشاء عدد ثابت من الرموز المميزة وإخبار المستخدمين بأن الرمز المميز له قيمة لأنه سيكون نادرا في غضون بضع سنوات *). لذلك ، ليس كل رمز ERC-20 له وظيفة سك وحرق. نظرا لأن ERC-7281 يستخدم آلية سك العملة والحرق التي تفضلها معظم الجسور (إن لم يكن كلها) اليوم ، فلا يمكن أن تعمل رموز ERC-20 القديمة أو غير القابلة للترقية خارج الصندوق مع ERC-7281.
يوفر عقد Lockbox حلاً بديلًا ويمكن التوافق مع التوافق مع الرموز الحالية. في المواصفة الأصلية (أي ينتشر مشروع عقد رمز جديد ينفذ واجهة IXERC20)، يتعين على مشغلي الجسر فقط استدعاء mint() لإطلاق رموز لمستخدم على سلسلة الوجهة (بعد قفل إيداع على سلسلة المصدر).
يستعير عقد Lockbox بشكل كبير من تصميم عقد المُغلف WETH. ينفذ وظيفة الإيداع() لإيداع الرمز الخاص ب ERC-20 المقابل في Lockbox ووظيفة السحب() لمشغلي الجسر لفتح الرموز ERC-20 بعد حرق الرموز المُغلفة على نطاق بعيد.
يتم تسليط الضوء على أول نوعين من أنواع الأخطاء في المواصفات (“IXERC-20Lockbox_NotNative” و“IXERC-20Lockbox_Native”) عندما يحاول المستخدم إيداع الرموز التشفيرية في عقد Lockbox الخطأ. يمكن أن يكون Lockbox أصليًا أو غير أصلي، اعتمادًا على أنواع الرموز التشفيرية التي يدعمها.
الصناديق الأمانية الأصلية تحتفظ بالرموز الأصلية - وهي الرموز المستخدمة لدفع رسوم الغاز إلى المحققين. مثال على رمز سيكون لديه صندوق أماني أصلي لتغليفه في رمز xERC-20 هو ETH: سيتطلب تغليف ETH في رمز xERC-20 استدعاء وظيفة depositNative() للصندوق الأماني وإيداع ETH لاستلام التمثيل المتوافق مع ERC7281 لـ ETH.
الصناديق العادية (غير الأصلية) للقفل تحتفظ برموز ERC-20 مثل USDC و DAI و WETH و USDT وما إلى ذلك. على سبيل المثال، لكي يتمكن المستخدم من إطلاق USDC كرمز xERC-20، سيقوم بتسجيل () على عقد الصندوق بعد قفل USDC.
سيؤدي استدعاء الإيداع () باستخدام ETH إلى قفل هذه الأموال إلى الأبد نظرا لأن عقد Lockbox العادي يمكنه فقط تغليف رموز ERC-20 المميزة وفكها. سيؤدي استدعاء depositNative() باستخدام رمز ERC-20 إلى نتائج مماثلة لأن عقود Lockbox الأصلية تهدف إلى العمل مع الرموز المميزة الأصلية ، وليس رموز ERC-20.
وبهذه الطريقة، من خلال تغليف رموز ERC-20 الكنونية في رموز xERC-20 مع دعم الإنشاء/الحرق، يوفر القفل طبقة توافق مهمة للمعيار. ومع ذلك، بالنسبة لبعض الحالات، مثل دمج حلول الجسرية الأخرى في xERC-20، فإن استخدام القفل فقط، وإعادة الرمز المغلف ليست خيارًا. لهذا السبب، قد يقوم المشاريع بتنفيذ عقود محولة.
في الحالات التي لا يتم فيها تصميم بروتوكولات التوصيل للتعرف على العمليات المتأصلة في رموز xERC-20 المميزة (سك / حرق ، والتسجيل المقابل ، وما إلى ذلك) ، يمكن للتطبيقات إنشاء عقود محول. تعمل هذه العقود كأغلفة آلية وفك الأغلفة - تترجم بشكل فعال ERC-20 القياسي الموافقة + سلوك المكالمة إلى مخطط سك / حرق أكثر دقة يتطلبه xERC-20.
هذا ضروري لأن العديد من بروتوكولات الجسر (على سبيل المثال، CCIP لـ Chainlink) لا تزال محسنة لسلوك ERC-20 التقليدي. يمكن لعقد المحول تجاوز هذه الفجوة في التوافق عن طريق توثيق مثل هذا الطريقة: يقوم بإيداع الرموز التشفيرية في الصندوق الأمني لتوليد تمثيل xERC-20 على سلسلة المصدر، وفي وقت لاحق، عند استلام الرسالة على سلسلة الوجهة، يُشغّل آلية السحب للعودة إلى الأصل الكانوني.
يضمن هذا التدفق حصول المستخدم في النهاية على رمز مميز أساسي متسق - لا يتأثر بآليات التغليف المدعومة من xERC-20 تحت الغطاء. بهذه الطريقة ، يمكن للمحولات السماح للبروتوكولات بالتكامل بسلاسة مع الجسور غير المتوافقة مع xERC-20 وزيادة مجموعة الحلول القابلة للتشغيل البيني التي تدعمها.
على مستوى عالي، يحتوي ERC-7281 على أربعة أهداف رئيسية:
كانت الرؤية الأصلية لإنشاء مواصفات ERC-20 هي ضمان قابلية الاستبدال والتشغيل البيني السلس بين الرموز المميزة على Ethereum عبر التطبيقات والبنية التحتية ل Ethereum. ومع ذلك ، بعد اعتماد خارطة طريق تحجيم تتمحور حول التجميع ، نشأت مشكلة نقص قابلية التركيب الذري ، وأدى إنشاء العديد من المجالات المختلفة إلى تدهور خصائص قابلية الاستبدال تلك. يسمح xERC-20 بتجميع سيولة جسور التجميع المتقاطعة المختلفة في رموز موحدة متعددة الاكتساب ، واستعادة الرؤية الأولية ل Ethereum.
الأمان: لتقليل مخاطر الطرف المقابل ، يجب أن يكون لدى مصدري الرموز المميزة خيار الاختيار من بين موفري الجسور المنافسين وفقا لتقييم البنية التحتية للأمان. علاوة على ذلك، يجب أن يتمتع مصدرو الرموز المميزة بحماية ذات مغزى من تداعيات الحوادث الأمنية التي تؤثر على موفري الجسور الشريكين - لا ينبغي أن تمحو الهجمات المعزولة على خدمة واحدة أو اثنتين من خدمات الجسر TVLs بأكملها.
التمويل الذاتي للسيولة لرموز السلاسل العبرية: لا ينبغي أن يُجبر بروتوكول DAOs على إنفاق موارد كبيرة (مالية) على تمويل السيولة للرموز المعبرة كجزء من خطط التوسع متعددة السلاسل. ليس فقط أن توجيه السيولة سيء لتجربة المستخدم، ولكن قد يصبح الإنفاق على حوافز توفير السيولة غير قابل للتنفيذ لفرق المشروع بمجرد زيادة عدد سلاسل الكتل قريبًا.
السيادة لمصدري الرموز المميزة: يجب أن يظل مصدر الرمز المميز متحكما في التمثيل الأساسي للرموز المميزة للبروتوكول التي تم سكها على سلاسل غير أصلية. لا ينبغي أن يتطلب حل مشكلة الرموز المميزة غير القابلة للاستبدال تسليم التحكم في الرمز المميز الجسر للمشروع - خاصة الجوانب الإدارية مثل التحكم في إجمالي العرض وتكوين آليات سك والحرق - إلى جسر تابع لجهة خارجية.
يمكننا التوسع في هذه الأهداف لمعرفة الفوائد التي يوفرها ERC-7281 للبروتوكولات والمجتمعات.
يحل ERC-7281 إصدارات مختلفة من مشكلة الاعتماد على المسار الموضحة في المقدمة.
يمكن أن تكون الاعتمادية على المسار محددة للسلسلة (على سبيل المثال، الإيثيريوم المعبر عنه من إيثيريوم → أربيتروم → تفاؤل يختلف عن الإيثيريوم المعبر عنه من إيثيريوم → تفاؤل → أربيتروم) أو محددة للجسر (على سبيل المثال، الإيثيريوم المعبر عنه من إيثيريوم إلى تفاؤل عبر سيلر يختلف عن الإيثيريوم المعبر عنه من إيثيريوم إلى تفاؤل عبر كونيكست).
التبعية المسارية هي ميزة أمان قيمة، ولكن يمكن أيضًا أن تكون مضرة بتوصيل تجربة المستخدم وقابلية التكامل عبر السلاسل. على سبيل المثال، لا يمكن للمستخدم تزويد السيولة برمجيًا لصرف عبر السلاسل يعمل على أوبتيميزم وأربيترم لأن التطبيق يجب أن يقبل opETH أو arbETH.
يقضي ERC-7281 على المشكلة من خلال تقديم رموز xERC-20 التي تظل قابلة للاستبدال بغض النظر عن عدد المرات التي يربط فيها المستخدم عبر السلاسل أو موفري الجسور الذين اعتادوا على ربط الرموز المميزة. لنفترض أن المستخدم يرغب في نقل USDT المغلف من Arbitrum إلى Optimism دون الانسحاب إلى Ethereum أولا. يمكن لمزود الجسر حرق رموز xERC-20 المميزة على Arbitrum وسك xERC-20s على Optimism - لا تزال قيمة الرموز المميزة التي تم سكها على Optimism مرتبطة بالرموز المميزة المودعة في Lockbox ويتم إعادة تعيينها للحفاظ على دعمها 1: 1.
على نحو مهم، يوفر ERC-7281 فوائد نشر عملة جسرية كانونية مثل CCTP لشركة Circle (بروتوكول نقل عبر السلاسل) دون الحاجة إلى وجود حضانة مركزية للعملات الجسرية. على سبيل المثال، يتم توحيد السيولة حول التمثيل الكانوني لعملة المشروع، مما يحسن من فائدة العملة لتطبيقات DeFi ويقلل من التكاليف الزائدة لإنشاء أسواق مختلفة لإصدارات مختلفة من نفس الأصل.
توصف xERC-20s بأنها "رموز مميزة ذات جسر سيادي" حيث لا يتم تقييد مصدري الرموز المميزة باستخدام خيار معين لسك التمثيلات الأساسية للرمز المميز والاحتفاظ بالتحكم في تصميم وإدارة الرموز المميزة الجسرية عبر عمليات النشر. ERC-7281 عبارة عن مزيج بين "سك الرموز المميزة الأساسية عبر جسر تابع لجهة خارجية" و "سك الرموز المميزة الأساسية عبر جسر يتحكم فيه مصدر الرمز المميز" الذي يجمع بين السيادة وتجربة المستخدم واللامركزية في نفس الحزمة.
يمكن للمشاريع التي تنشر الرموز المميزة عبر السلاسل باستخدام ERC-7281 سك التمثيلات الأساسية للرموز الأصلية عبر جسور متعددة دون الوقوع في مشكلة الإصدارات المغلفة غير القابلة للاستبدال من نفس الأصل الأصلي ، مما يؤدي إلى كسر تجربة المستخدم للمستخدمين الذين يأملون في الاستفادة من قابلية التركيب وقابلية الاستبدال لرموز ERC-20. تحتفظ مثل هذه المشاريع أيضا بمستوى مماثل من التحكم في عمليات النشر عبر السلاسل للرمز المميز كمصدر رمز مميز يدير بنية تحتية داخلية لإدارة عمليات نقل الرموز المميزة الأساسية بين النطاقات نظرا لأن عقود الرمز المميز xERC-20 و Lockbox - التي تستخدمها الجسور لقفل الرموز المميزة وسكها وحرقها للمستخدمين - يتم نشرها والتحكم فيها بواسطة المشروع.
يمكن أن يكون هذا الميزة البسيطة مفيدًا في الحالات التي تكون فيها مشروع ذو شهرة عالية لديه رمز مميز صادر على سلسلة البيت. يرغب مستخدمون من بيئات أخرى في التعرض للرمز دون الاحتفاظ به على سلسلته الأصلية لأسباب مختلفة.
ومع ذلك، لا يتوفر للمشروع القدرة أو الرغبة في تشغيل بنية تحتية للجسر الداخلية لكل سلسلة لضمان التوافق 1:1 بين الرموز المتصلة - ولا يرغب في تسليم التحكم في رمزه إلى طرف ثالث ليس بالضرورة متماشي مع البروتوكول ومجتمعه. يصبح مثل هذه الحالة مراعاة عند تنفيذ حكم عبر السلاسل الذي يسمح بالتصويت باستخدام الرموز المتصلة بينما يتم تسجيل الأصوات على السلسلة الأصلية؛ مزود الجسر غير المتماشي مع التحكم في الرموز المتصلة يصبح نقطة اختناق لحكم البروتوكول.
كما اعتمد Beefy ، وهو بروتوكول لزراعة الغلة ، xERC-20 لهذا السبب. كما تصفها وثائق جسر المشروع ، زود ERC-7281 المشروع بمزيد من الخيارات لتجسير الرموز - والتي أصبحت ضرورية بعد أن عانى شريك جسر رئيسي من اختراق (موضوع أصبح مألوفا بسرعة للسكان الأصليين للعملات المشفرة) - وقدم تحكما أكثر دقة في تصميم آليات الجسر. في حالة Beefy ، مكنت ميزة القائمة المسموح بها في ERC-7281 البروتوكول من تحديد شركاء تجسير مختلفين وتقديم خيارات مختلفة للمستخدمين بين تحسين السرعة واللامركزية والتكاليف والأمان عند سد رموز mooBIFI.
يفضل توجيه السيولة بناءً على المشاريع التي تمتلك القدرة المالية على إنفاق حوافز السيولة - حيث يرغب مصدرو الرموز في إنفاق أقل على حوافز LP وتقديم تجربة جسرية متفوقة، تصبح السيولة العامل الأكثر أهمية بالنسبة للبروتوكولات التي تستخدم جسور L1/L2 القنونية. يمتد هذا أيضًا إلى اختيار مزودي الجسور من قبل مجمعي الجسور، مما يجعل من الصعب بالقول أن يتنافس الخدمات الجديدة للجسور (حتى تلك التي تمتلك بنية تحتية آمنة) مع بروتوكولات الجسور الأكثر تأسيسا.
يعالج ERC-7281 المشكلة عن طريق إزالة الحاجة إلى التجسير القائم على السيولة. دون الحاجة إلى سك ومبادلة الرموز غير الأساسية بالرموز الأساسية ، يمكن الموافقة على الجسور من أي حجم لسك الرمز المميز للمشروع على نطاق بعيد. نظرا لأن مصدري الرموز المميزة يرغبون في تقليل التعرض لفشل الجسور ، فمن المحتمل أن تبدأ المزيد من البروتوكولات في إيلاء المزيد من الاهتمام للتصميمات الأمنية للجسور عبر السلاسل بدلا من التركيز على السيولة أولا.
هذا يحفز المنافسة المفتوحة لأنها تصبح حالة "دع الجسر الأكثر أمانا يفوز" وليس "دع الجسر الأكثر سيولة يفوز". يمكن أن تتخذ هذه المنافسة المفتوحة شكل جسور تتنافس على المزيد من الميزات التي تتجاوز السيولة / الأمان (على سبيل المثال ، الرسوم ، واجهات برمجة التطبيقات / SDKs ، وتكامل التطبيقات ، وما إلى ذلك). يمكن القول إن هذه الميزات أسهل في خبزها في تطبيق من البداية لأنها تعتمد بشكل أساسي على خبرة فريق التطوير. في المقابل ، تعد أحجام السيولة والتجسير أكثر تعقيدا في التمهيد وتتطلب مزيجا من تطوير الأعمال والتمويل والاتصالات الصناعية والتسويق والمزيد.
يقدم ERC-7281 حدا للمعدل قابلا للتكوين على سك وحرق الرمز المميز الذي يحسن بشكل كبير ملف تعريف المخاطر للبروتوكولات التي تعمل مع جسور الجهات الخارجية لسك الرموز المميزة الأساسية على سلاسل غير أصلية. في حالة اختراق موفر الجسر الشريك أو اختراقه، فإن أكبر ضرر يمكن أن يسببه المهاجم يعادل الحد المعين للجسر المخترق. إذا اختارت جهة إصدار الرمز المميز معلمات تحديد المعدل بعناية، فيجب أن يكون للهجمات المعزولة على الجسر تأثير ضئيل على ملاءة البروتوكول.
قد يساعد أيضًا تكوين حدود المعدلات لكل جسر في تحسين عملية تقييم المخاطر لبروتوكولات DAO. حاليًا ، قد يستغرق تقييم مخاطر الجسر أشهرًا لإكماله بسبب مدى التأثير الناتج عن اختراق جسر طرف ثالث كانوني؛ حيث ترغب البروتوكولات في التأكد من اتخاذ قرارات مدافعة ، حيث يتم فحص أمان الجسر المختار بشكل مكثف لتقديم ضمانات أقوى للمجتمع بشأن السلامة. بالإضافة إلى كونها تضيع بشكل غير ضروري للجهد والوقت ، ما زال تحليل أمان الجسر يضمن بعد أن الجسر المختار غير معرض للاستغلال في اليوم الصفر.
اعتماد ERC-7281 يجعل تقييم المخاطر أكثر ديناميكية. لا يزال يتعين على المشاريع إكمال العناية الواجبة على مزودي الجسور لاختيار الخصائص المناسبة التي تحد من المعدل. ومع ذلك ، يمكن تقليل الجداول الزمنية لتقييم المخاطر لتعكس أن البروتوكولات لم تعد في وضع كل شيء أو لا شيء. بدلا من قضاء أشهر في تحليل العديد من الجسور لاختيار خيار واحد ، يمكن للمشروع قضاء نصف الوقت في اختيار العديد من موفري الجسور في البداية ووضع حدود سك مختلفة بناء على تقييم الأمان. يمكن لمصدر الرمز المميز بعد ذلك إجراء مراجعات أمنية لتحديد ما إذا كان سيتم زيادة أو تقليل حدود سك لشركاء التوصيل المحددين أو سحب حقوق سك من الجسر (على سبيل المثال، استجابة للاختراق أو الكشف عن الثغرات الأمنية).
تقلل ERC-7281 أيضًا من الحواجز التي تواجه المشاريع التي ترغب في الانضمام إلى التطورات الحديثة في أمان الجسر ولكنها تتردد في اعتماد تقنية معينة بالكامل حتى يتم اختبار التكنولوجيا بشكل جيد ويتم فحصها بدقة من قبل المجتمع (أي مأزق المبتكر). فإذا اقترح موفر الجسر بنية تحتية جديدة تحسن بشكل كبير ضمانات الأمان، يمكن لبروتوكول "اختبار المياه" عن طريق منح حقوق البناء المحدودة للجسر وزيادة حد البناء تدريجيًا مع ارتفاع الثقة في تصميم النظام المقترح.
مثل إزالة مخاوف السيولة ذات الصلة، إزالة الحاجة إلى أن يثق البروتوكول في تكنولوجيا الجسر 100٪ قبل منح حقوق الإصدار يخلق منافسة متساوية بين الداخلين الجدد واللاعبين القدامى - اللاعبون القدامى لديهم حافز للتكرار على أفضل النهج للأمان حيث يمتلك مُصدر الرموز الآن مرونة لسحب حقوق الإصدار وإعادة الإسناد إلى مشروع أصغر فقط لأن الأخير قد أظهر التزامًا أعلى بالسلامة واللامركزية. كما يقضي هذا أيضًا على عامل الخطر الآخر للبروتوكولات التي تعمل مع جسور الطرف الثالث: خطر أن مزود الجسر المختار يتوقف عن الابتكار في مجال الأمان على الرغم من وتيرة الكشف عن العيوب والمشاكل في أمان الجسر واكتشافها بسرعة لأنه يعلم أن مصدر الرموز لا يمكنه فرض إجراءات عقابية (على سبيل المثال، الانتقال إلى مزود جسر آخر) بسبب صعوبة تنفيذ مثل هذه الأنشطة.
بناء سير العمل التطبيقية المعقدة التي تتطلب توجيه الرموز عبر أي عدد من السلاسل أمر صعب اليوم بسبب التسعير غير المتوقع للجسور القائمة على السيولة. على سبيل المثال، لدى وسيط الجسر الذي يربط بين إيثيريوم → لينيا → القاعدة خياران:
بالمقارنة، يمكن لمجمعو الجسور معرفة مسبقا كم عدد الرموز يجب أن يتوقعوها على كل نطاق مشارك في عملية تشفير عبر السلاسل من خلال التحقق من mintingLimit و burningLimit للجسور المسموح لها بتشفير رمز معين. من المسلم به، يمكن لجسر أن يصل إلى الحد الأقصى بين وقت بث الصفقة ووصول الصفقة إلى النطاق—مما يعني أن المستخدم لا يمكنه تلقي الرموز الكنسية في الوجهة.
ومع ذلك ، لا يزال ERC-7281 يمثل تحسنا في هذا الصدد للأسباب التالية:
التحولات غير المتوقعة في السيولة تعني أيضًا عدم التنبؤ في تسعير عمليات توجيه الجسور. لنفترض أن مجمع الجسر (أو تطبيق آخر) يضع عرضًا لعملية تبادل عبر السلسلة استنادًا إلى سعر الزوج الحالي لزوج الرموز في بركة السيولة للجسر (يستند هذا السعر إلى إجمالي سيولة البركة). لا يزال بالإمكان تنفيذ العملية بسبب الانخفاض الحاد في سيولة البركة. لنفترض أن الصفقة معلقة وتمت إعادة المحاولة لاحقًا. في هذه الحالة، لا يمكن لمطور التطبيق أن يعرف ما إذا كان العرض السابق ما زال دقيقًا أم ما إذا كانت السيولة ستصل إلى نفس المستويات كما كانت عندما قدم المستخدم المعاملة للمرة الأولى.
نظرًا لأن ربط الرموز xERC-20 لا يخضع لحركات السيولة، يمكن للمستخدمين أن يكونوا واثقين من أن المعاملات عبر السلاسل لن تتكبد الانزلاق حتى لو لم يتم تنفيذها على الفور.
مجمعات التجسير ليست الوحيدة التي تستفيد من هذا التحسين في قابلية التكوين. يمكن لأي تطبيق عبر السلاسل تسخير قابلية استبدال رموز xERC-20 لإنشاء تطبيقات أكثر إثارة. هذا أكثر صعوبة اليوم بسبب المشاكل المتعلقة بالاعتماد على المسار: لنفترض أن أحد المطورين يرغب في سد ETH من Ethereum ، وفتح مركز إقراض على Arbitrum DEX ، واستخدام الأرباح لشراء NFT على Optimism قبل العودة إلى Ethereum. هنا ، يجب على المطور التأكد من التكامل مع موفري الجسور على تلك السلاسل - حيث لا يمكنك تبديل الإصدارات الخاصة بسهولة - وهذا ليس هو الحال بمجرد أن تصبح الرموز المميزة الجسرية للمشروع قابلة للاستبدال بعد اعتماد xERC-20.
هذه السير العمل مشابهة لجسور الإصدار الرمزية الموصوفة سابقا. دعونا نأخذ Circle CCTP كمثال:
يسمح بروتوكول النقل عبر السلاسل الخاص ب Circle للمستخدمين بالحصول على نسخة أساسية موحدة من رمز USDC الخاص به دون الوقوع في شرك النظام البيئي لسلاسلهم. تتم معالجة جميع عمليات النقل عبر السلاسل من خلال بروتوكولها باستخدام مخطط الاحتراق والسك.
ومع ذلك، بينما يعتبر CCTP بروتوكولًا مركزيًا، حيث أن مشغلي Circle هم الكيانات الوحيدة المخولة بحرق وطباعة رموز USDC الخاصة به، يقوم xERC-20 بتصفية مخاطر الثقة من خلال السماح لكيانات متعددة بآليات أمان مختلفة بتشغيل تحويلات عبر السلاسل.
يمكن لـ ERC-7281 تسريع خارطة طريق إيثيريوم المتمحورة حول Rollup عن طريق منح المشاريع الثقة لنشر الرموز على L2s الجديدة لـ EVM والتي قد تفتقر إلى ملامح أمان قوية لسلاسل L2 المؤسسة. على سبيل المثال، فإن الجسر الكانوني لـ rollup المرحلة 0 أقل أمانًا لأن Ethereum L1 لا تضمن أمان الجسر. يمكن لمشروع الرمز تنفيذ إطلاق تدريجي على مثل هذه السلسلة عن طريق منح حقوق النقد المحدودة للجسر الكانوني وزيادة حد النقد بمجرد تقدم rollup إلى المرحلة 1.
يمكن أن تستمر هذه العملية حتى يصل L2 إلى المرحلة 2 (أعلى مرحلة من اللامركزية والأمان للمجموعة المجمعة). إن الآلية التي يمكن من خلالها نشر البروتوكولات على السلاسل التي تم إطلاقها حديثا بطريقة تقلل من المخاطر تفيد نظام Ethereum البيئي من خلال تسهيل تشغيل L2s الجديدة لسيولة وتطبيقات الرمز المميز مع تشجيع المزيد من الابتكار في مساحة تصميم القيمة المحتسبة.
بينما يعتبر ERC-7281 جذابًا للغاية للبروتوكولات، قد تتردد الDAOs في اعتماد رموز xERC-20 بسبب العبء التشغيلي الكبير الذي يتعين على فرق مشاريع الDAO تحمله لإدارة رموز xERC-20 على مستويات نشر مختلفة.
جيرارد بيرسونإدارة الرموز المميزة الجسرية على عدد كبير من السلاسل يتضمن قائمة غير شاملة بالمهام لمرة واحدة والمتكررة التي يجب على البروتوكول تنفيذها بعد الانتقال من ERC-20 إلى xERC-20:
هذه قائمة طويلة جدا من المهام
الحل المقترح هو أن تقوم DAOs بالاستعانة بمصادر خارجية لبعض هذه المهام الإدارية المتعلقة بإدارة رموز xERC-20 عبر السلاسل لخدمات الجهات الخارجية ، ولكن هذا مجرد تبادل مقايضة واحدة (تكاليف الموارد البشرية) بأخرى (تكاليف خدمات التوظيف).
لنفترض أن بروتوكولا كان يدير سابقا الرموز المميزة عبر السلاسل مع بنية تحتية داخلية (على سبيل المثال ، نشر عقد رمز مميز منفصل لكل سلسلة والتحكم في سك وحرق). في هذه الحالة ، لا يبدو ERC-7281 تغييرا جذريا. ومع ذلك ، فإن المشاريع المستخدمة للاستعانة بمصادر خارجية لإدارة البنية التحتية الأساسية للتجسير بين فرق التطوير ستجد عبء العمل الإضافي مثيرا للقلق.
على سبيل المثال،حدد أحد أعضاء فريق Lido الأساسي(ردًا على اقتراح لـ Lido بنشر wstETH كرمز xERC-20 عبر جميع النشرات) المسؤوليات الحالية لفريق إدارة المشروعات المعني ببنية التوافق ومقارنتها مع المجموعة المطلوبة من أعضاء الفريق نفسهم لتوليها إذا صوتت Lido DAO لنقل wstETH على جميع النطاقات إلى الإصدار xERC-20.
كما يظهر الحوار أعلاه، فإن إدارة رموز xERC-20 تفرض زيادة لا يمكن تجاهلها في السلبيات الإدارية على البروتوكولات وأعضاء المجتمع. على سبيل المثال، تتطلب حدود الجسر مراقبة نشطة وتقييمًا لأمان الجسر لإبلاغ التعديلات على حدود الإنتاج، وقد تخضع قرارات حول حدود الجسر (أو سحب/تخصيص حقوق الإنتاج) للتصويت في DAO (إذا كان من الضروري اتخاذ مثل هذه الخيارات بشكل متكرر، فقد يعاني أعضاء DAO من تعب الناخب).
هذا لا يجب أن يُفسر على أنه حكم قيمة على ERC-7281، مع ذلك. سيكون لكل مشروع ملامح مخاطر مختلفة، وأهداف طويلة الأجل، وموارد، وتحدد هذه العوامل مجتمعة ما إذا كانت الفائدة طويلة الأجل من اعتماد ERC-7281 تفوق التكاليف القصيرة الأجل والمستمرة للقيام بذلك.
على سبيل المثال، قد يجد المشاريع الأصغر صعوبة في إدارة التكاليف الإدارية والتشغيلية لإصدار رموز xERC-20 ويختارون اللجوء إلى خدمة جسر الرموز متعددة السلاسل المدارة مثل خدمة Axelar ITS (Interchain Token Service) أو NTT (Native Token Transfers) لـ Wormhole. قد تمتلك المشاريع الأكثر تماسكاً الموارد الكافية لإدارة التكاليف الإدارية والتشغيلية لإصدار رمز xERC-20 وقد تنظر في أن السيطرة التي يوفرها ERC-7281 تستحق التكلفة الإضافية لإدارة رموز عبر السلاسل.
بالنسبة للمشاريع التي ليس لديها واجهة البناء/الحرق، أو التي لا يمكن ترقية عقود الرموز لاستخدام IERC20 عبر الوراثة، ولديها بالفعل تمثيلات كانونية للرموز الأصلية المتداولة على سلاسل غير أصلية، فإن التحول إلى رموز xERC-20 هو عملية طويلة تتطلب الكثير من التنسيق وتشمل شبكة معقدة من المشاركين— تتراوح من حاملي الرموز، والبورصات (DEXes وCEXes)، وجسور الشراكة، والتطبيقات المتكاملة مع الرمز ERC-20 التقليدي. حتى مع تلك الجزء المعالج، البروتوكولات لا تزال تتحمل تكلفة فك تشفير ERC-20s إلى xERC-20s لاستكمال عملية التحول.
كما هو موضح في مناقشة مواصفة ERC-7281، سيحتاج الرموز الحالية إلى أن تُقفل في صندوق القفل لإصدار xERC-20s مغلفة للمستخدمين. يحدث تقاعد ERC-20 القديم بعد ذلك بفترة قصيرة ويتضمن عملية طويلة أخرى لمشاركة الاتصال مع المجتمع حول الجدول الزمني لتجميد إصدار الرموز الجديدة (القديمة) ERC-20. مرة أخرى، قد تكون هذه التكلفة مبررة تمامًا من وجهة نظر البروتوكول — على الرغم من أن الفوائد قد لا تكون كافية أيضًا لتبرير تكاليف تنسيق هجرة على نطاق النظام البيئي إلى التمثيل المتوافق مع xERC20 لرمز البروتوكول.
تتطلب إدارة رموز xERC-20 المميزة على نطاقات متعددة باستخدام ERC-7281 حوكمة نشطة من DAO التي تشرف على البروتوكول. يتضمن ذلك تعيين معلمات مثل حدود سك العملة وترقية عقد Lockbox وإيقاف سك الرموز المميزة أو حرقها مؤقتا. هذه القرارات حساسة للأمن ويجب أن تحكمها DAO لتجنب مسؤولية قرارات مجلس الإدارة المغلقة.
يهدف ERC-7281 إلى منح البروتوكولات السيطرة على هذه القرارات بدلا من جسور الطرف الثالث. هذا منطقي ، حيث تدير DAOs بالفعل الرموز المميزة على سلاسلها الأصلية ، لذا فإن توسيع حوكمتها لتشمل الرموز المميزة على سلاسل أخرى أمر معقول للبروتوكولات والمجتمعات التي تسعى إلى هذا التحكم. ومع ذلك ، قد لا ترغب بعض البروتوكولات في التحكم الإضافي في DAO بسبب مخاوف بشأن الحوكمة والاستقرار.
على سبيل المثال، تواجه المشاريع ذات الشهرة العالية مثل ليدو انتقادات حادة بشأن مسائل الحوكمة. إضافة السيطرة على إدارة الرموز يزيد من مخاطر انقلاب الحوكمة. هجوم الحوكمة يمكن أن يكون له تأثيرات واسعة النطاق إذا ما جمع المشروع جميع الرموز ERC-20 في صندوق قفل ويديره الديسي. يمكن للمهاجم السيطرة على صندوق القفل وإدخال موفر جسر شرير بدون حدود للطباعة، مما يجعل الرموز xERC-20 على سلاسل أخرى بلا قيمة.
تتوازى هذه السيناريوهات مع استغلال السلاسل المتعددة، حيث سمحت الثغرة في بنية التوقيع بالحساب التعددي (MPC) للمتسللين بالتسلل إلى عناوين السلاسل المتعددة الأساسية التي كانت تحتضن الرموز الأصلية على الإيثيريوم ودوجكوين - هذه الرموز دعمت الرموز المضافة التي تم ضربها على سلاسل غير أصلية مثل فانتوم وموونريفر، مما أدى إلى تفعيل تأثير الدومينو الذي تسبب في تكبد المشاريع خسائر في مكان آخر نتيجة للهجوم على العقود الذكية للسلاسل المتعددة على الإيثيريوم ودوجكوين.
يناسب ERC-7281 الغرض عندما يتم إصدار الرمز المميز بواسطة بروتوكول مع حوكمة الرمز المميز أو كيان مركزي (على سبيل المثال ، USDC الخاص ب Circle أو عملة CZKC المستقرة). ومع ذلك ، فهي ليست ذات قيمة إذا كان البروتوكول لامركزيا إلى أقصى حد ويفتقر إلى الحوكمة الرسمية - تعد عملة LUSD المستقرة من Liquity مثالا على رمز مميز يصعب جعله متوافقا مع معيار xERC-20.
يتطلب رمز xERC-20 من الكيان اتخاذ قرار بشأن معلمات محددة مثل حدود سك وحرق واتخاذ قرارات مثل ما إذا كان سيتم إدراج بعض مزودي الجسور في القائمة البيضاء أم لا. هذا يعني الحاجة إلى استمرار الحوكمة لوجود رمز xERC-20. بالنسبة للمشاريع التي ترغب في تحقيق اللامركزية في المكونات الهامة للبروتوكول - مثل عقد الرمز المميز ل DAO - بمرور الوقت ، قد يتسبب ذلك في حدوث مشكلات وتعقيد خطط اللامركزية.
لقد ذكرنا بالفعل كيفية عمل الاعتماد على المسار ولماذا يساعد في توفير ضمانات بأن الاستغلال الذي يؤثر على السلسلة A لن يؤثر على السلسلة B ، أو أن الاستغلال الذي يتضمن الجسر A على السلسلة A لن يؤثر على الجسر B على السلسلة B. يزيل ERC-7281 اعتماد المسار ، والذي له فوائد ، ولكنه يقدم أيضا مقايضة حول الأمان:
لم يعد الحد الأقصى للسيولة المتاحة في الجسر يمثل حدا أعلى للتأثير المحتمل لاستغلال الجسر على مصدر الرمز المميز، حيث أن الرموز المميزة التي يتم سكها من قبل موفري الجسور المختلفين قابلة للاستبدال عبر المجالات. يقترح مؤلفو ERC-7281 اختيار حد سعر لموفري الجسور بناء على المبلغ الذي يمكن أن ينفقه مصدر الرمز المميز للتعويض عن الخسائر الناجمة عن سك العملة الاحتيالية. ومع ذلك ، ربما كان حد المعدل المحدد متحفظا للغاية في وقت لاحق.
إذا تم الاعتداء على جسر ذو حد أعلى عالٍ، يمكن أن تكون التأثيرات ملحوظة حتى على مستخدمي الجسور الأخرى الذين يقومون بطباعة نفس الرمز. يمكن للبروتوكولات تقليل المخاطر من خلال توزيع حقوق الطباعة عبر عدد كبير من الجسور (بحيث لا يمتلك مزود جسر واحد عددًا كبيرًا من الرموز التي يمكنه طباعتها مقارنة بالجسور الأخرى)، ولكن محاولة تحويط المخاطر بهذه الطريقة قد تزيد من عدم الكفاءة حيث ستتطلب كل جسر تقييمًا مستقلًا من فريق داو والتنسيق مع المزيد من الجسور يزيد من النفقات الإدارية التي ذكرناها سابقًا.
يمكن أن يؤدي عقد Lockbox الذي تحكمه DAO إلى حدوث تأثيرات عدوى ضارة في حالة وقوع هجوم حوكمة. ولكن حتى مع حوكمة DAO الآمنة ، يمكن أن يتسبب الخطأ في عقود Lockbox الأصلية / غير الأصلية على السلسلة الرئيسية للرمز المميز في حدوث العديد من المشاكل (Sifu هو الآن مالك عقد Lockbox لمشروع ما ، ولم تعد الأموال SAFU). وبالمقارنة ، يتم تقليل هذه المشكلة في الوضع الراهن حيث أن عقود الخزينة (المكافئ لموفر الجسر لعقد Lockbox) تحتفظ فقط بالرموز المميزة التي تم جسرها من خلال خدمة الجسر المقابلة. لذلك ، يؤثر الخطأ في عقد المخزن لموفر واحد فقط على المستخدمين الذين قاموا بإيداع الرموز المميزة في هذا الجسر.
يؤثر العمل الإداري الإضافي مع ERC-7281 أيضا على مطوري التطبيقات وموفري الخدمات الذين يستخدمون رمز xERC-20 المميز للمشروع. يحتاج مجمعو الجسور إلى تتبع التعيينات بين رموز xERC-20 وعقود Lockbox المقابلة لها لمنع مشكلات مثل الرموز المميزة للبريد العشوائي وهجمات الانتحال. في حين أن سجل هذه التعيينات يمكن أن يساعد ، إلا أن إنشاء مثل هذا السجل يمثل تحديا دون المخاطرة بالمركزية أو تعريض متبني xERC-20 للتهديدات.
يأتي الخطر من احتمال قيام المهاجمين بإضافة عقود ضارة إلى سجل الرمز المميز وخداع المستخدمين والمطورين لإرسال الرموز المميزة إلى العنوان الخطأ. قد يؤدي ذلك إلى سرقة الرمز المميز على كل من شبكات L2 و L1. تواجه البورصات تحديات مماثلة ، حيث يمكن أن تسبب الرموز المميزة المخادعة مشاكل خطيرة ، مثل سلوك الرمز المميز غير المتوقع ، والذي يختلف عن الرموز المميزة الأساسية التي تم فحصها.
يقدم ERC-7281 حلا مقنعا لمشاكل الرموز الجسور غير القابلة للتبادل ويقدم ميزات تعزز تجربة المستخدم واللامركزية والأمان والمرونة في تصميمات الرمز الجسور. بعض هذه المشاكل تؤثر مباشرة على قابلية جدول الطريق المتمحور حول الRollup، مما يجعل معيار xERC-20 بنية تحتية حرجة للبيئة البيئية Ethereum L2.
تعهد العديد من اللاعبين الرئيسيين في مجال الربط، بما في ذلك Hyperlane و Omni و Sygma و Router Protocol و Everclear، بتبني ERC-7281، مما يشير إلى جاذبية كبيرة للاقتراح. حتى الجهات الصادرة للرموز المعتمدة (التي لديها آليات عمل لربط الرموز) - مثل Circle - أبدت اهتمامًا بـ ERC-7281 لمعالجة التحديات التي تواجه المستخدمين والمطورين نتيجة للرموز غير المعتمدة.
يعالج ERC-7281 هذه المشاكل مع التخفيف من العديد من التنازلات المرتبطة بالنهج السابقة لضخ الرموز الكنسية على النطاقات البعيدة. إنه يوفر تشغيلًا خاليًا من السيولة، على عكس الجسور الموثقة، ولا يتطلب بنية تحتية مخصصة مثل جسور مُصدِر الرموز، ويتجنب الاحتجاز البائعي من خلال السماح بضخ الرموز الكنسية متعددة الجسور بواسطة مزودي الجسور المعتمدين.
للمهتمين بمتابعة المناقشة حول ERC-7281 أو المطورين الذين يتطلعون إلى دمج xERC-20 ، زمالة سحرة Ethereum و موقع xERC-20 هي موارد ممتازة. قام المجتمع أيضا ببناء منصة إطلاق xERC-20 لتجميع الأدوات لإنشاء رموز xERC-20 المميزة ومراقبتها وإدارتها - وهي أداة قيمة للبناة الذين يتطلعون إلى نشر رمز xERC-20 لأول مرة أو ترحيل رمز مميز موجود إلى معيار الرمز المميز xERC-20.
إذا لم تقرأ الجزء الأول من سلسلة كيفية جعل الرموز عبر السلاسل قابلة للتبادل مرة أخرى، قد ترغب في ذلكتحقق من ذلكأولاً - يفسر كيف تفقد الرموز المتمرنة قابليتها للتبادل والتحديات التي يخلقها ذلك. في الجزء الثاني، نستكشف ERC-7281، وهو معيار جديد يبسط تحويل الرموز عبر السلاسل، ويعزز الموثوقية، ويمنح المرسلين مزيدًا من السيطرة.
حتى الآن، لقد استكشفنا حلول مختلفة لمشكلة جعل الرموز المتقاطعة قابلة للتبادل وحل مشكلات تجزئة السيولة وتجربة المستخدم السيئة من التمثيلات غير الكنسية لرمز أصلي يتداول على سلاسل الكتل غير الأصلية:
يعرض كل من هذه الأساليب مقايضات ، لذلك من المناسب فقط أن يحاول اقتراح ERC-7281 لإنشاء رموز مميزة قابلة للاستبدال أخذ الأفضل من كل نهج لإنشاء حل أكثر شمولية وكفاءة ويمكن الوصول إليه للبروتوكولات التي ترغب في نشر الرموز عبر السلسلة دون المقايضة بالأمان أو السيادة أو تجربة المستخدم.
ERC-7281: الرموز المميزة ذات الجسر السياديهو مقترح لتمكين إنشاء تمثيلات كانونية لرمز تشفيري تكون متوافقة وقابلة للتبادل مع التمثيلات التي تم ضربها بواسطة العديد من الجسور المختلفة. يعمل ERC-7281 عن طريق توسيع واجهة ERC-20 لتشمل:
1) تعيين مشغلي الجسور لسك وحرق الرموز عند الجسر بين السلاسل ؛
2) تقييد سرعة إنتاج وحرق الرموز لكل مشغل جسر معتمد، على سبيل المثال، تحديد حدود صغيرة للجسور المركزية وحدود أعلى للبروتوكولات الأكثر أمانًا.
نظرًا للفارق الطفيف بين ERC-7281 و ERC-20 tokens، وصف الكتاب الفنيون في EIP الأولى بـ "xERC-20". بالنسبة للقراء الذين يحتاجون إلى نظرة عامة على ERC-20 tokens، لديها OpenZeppelin ممتازة دليل حول الموضوع.
في جوهرها ، ينفذ كل عقد رمز مميز ERC-20 واجهة ERC-20 التي تحدد توريد الرمز المميز العالمي وتخزن معلومات حول العناوين التي تمتلك الرمز المميز والمبلغ الذي تمتلكه. يتضمن ERC-20 أيضا وظائف مفيدة لإدارة الوصول إلى الرموز المميزة للمستخدم (عبر الموافقات) واسترداد المعلومات حول الرمز المميز - مثل إجمالي العرض المتداول والرصيد لعنوان معين.
ميزة إضافية يضيفها ERC-7281 إلى مواصفات ERC-20 هي صندوق قفل اختياري يعمل كعقد تفاف (مشابه لعقد WETH (Wrapped Ether. يقوم عقد صندوق القفل بتغليف رموز ERC-20 في رموز xERC-20 من خلال آليات النقد والحرق المألوفة ويجعل ERC-7281 متوافقًا مع عقود رموز ERC-20 الحالية التي تفتقر إلى واجهة حرق/نقد وغير قابلة للترقية.
باستخدام الإطار المقدم في المقالة السابقة، يمكننا تصنيف ERC-7281 كنهج "ثق في مصدر رمز الرموز + ثق في موفر الجسر (المعتمد)" لتشكيل الرموز متعددة السلاسل. يتحكم رمز ERC-7281 المنشأ عبر سلاسل متعددة من قبل مصدره (على عكس التصاميم البديلة للرموز عبر السلاسل التي عادة ما تتطلب التنازل عن السيادة). على الرغم من أن المصدر ما زال معرضًا لخطر تعرض جسر معتمد لحادث أمني، إلا أن المصدر يدير هذا الخطر عن طريق اختيار مقدمي الجسر المعتمدين يدويًا وفرض الحد الأقصى للمعدل.
الفارق الكبير، الذي سنستكشفه في هذا التقرير، هو أنه يمكن لمُصدري الرموز ضبط التعرض للاختراقات والاستغلالات عن طريق فرض حدود ديناميكية على عدد الرموز التي يمكن لمشغل جسر معين إنتاجها/حرقها. تسمح ERC-7281 أيضًا لمُصدر الرموز بتحديد مزودي جسور متعددين ليتمكنوا من إنتاج نفس الرمز الكنسي عبر السلاسل، مما يقلل من الاعتماد على مزود واحد لمعالجة عمليات عبور السلاسل.
تجعل كلتا الميزتين ERC-7281 تحسنا كبيرا على الأساليب التقليدية لتسهيل الربط عبر السلاسل لرموز البروتوكول ولها تأثيرات إيجابية من الدرجة الثانية للمستخدمين وموفري البنية التحتية للتشغيل البيني (خاصة المجمعين) ومطوري التطبيقات. بعد مناقشة المواصفات في القسم التالي ، سنراجع مزايا وعيوب تنفيذ ERC-7281.
في المواصفة، ينتشر مشروع عقدًا جديدًا متوافقًا مع ERC20 ينفذ واجهة IXERC20. يقوم مشغلو الجسر بطبع الرموز المميزة للمستخدمين على سلسلة الوجهة بعد حرق الوديعة على سلسلة المصدر. يتحقق عملية الطباعة من أن كمية الرمز المميز لا تتجاوز الحد الخاص بالجسر ويقوم بتحديث إجمالي العرض الكلي للرمز المميز والحد الخاص بطباعة الجسر في حال نجاحها.
بالنسبة للرموز ERC-20 القائمة بالفعل، يتم تطبيق منطق "صندوق القفل": يقوم مزود الجسر بتغليف رموز ERC-20 التي يقوم المستخدمون بإيداعها في رموز xERC-20 عن طريق نقلها إلى عقد Lockbox. يقوم Lockbox بعد ذلك بالموافقة على الجسر لطباعة كمية مكافئة من رموز xERC-20.
يتم حرق الرموز المميزة xERC-20 التي تم سكها بواسطة جسر على سلسلة الوجهة على سلسلة المصدر باستخدام الدالة burn(). تضمن هذه العملية أن مبلغ الرمز المميز لا يتجاوز حد حرق الجسر ، ويزيده ، ويقلل من إجمالي المعروض من رمز xERC-20. تقوم طبقة نقل الجسر بنقل رسالة النسخ إلى الوجهة. يتحقق عقد الجسر على الجانب الوجهة من الرسالة وينقل كمية متساوية من رموز xERC-20 المميزة إلى عنوان المستخدم على تلك السلسلة. يقلل هذا السك من إجمالي المعروض من الرمز المميز وحد سك الجسر.
لربط الرموز مرة أخرى بسلسلة الوجهة، يحرق مشغل الجسر الرموز xERC-20 على السلسلة البعيدة، ويقدم عنوان المستخدم وكمية الرموز. يتم نقل إيصال الحرق إلى سلسلة الوجهة بواسطة طبقة النقل. إذا تم التحقق من رسالة الحرق، يقوم مشغل الجسر بطبع وحرق رموز xERC-20 جديدة على سلسلة الوجهة للمستخدم. عند التحقق من إيصال الحرق من قبل عقد الرمز، يقوم مشغل الجسر بإطلاق رموز ERC-20 المودعة للمستخدم. يقلل حرق رموز xERC-20 على سلسلة الوجهة من إجمالي العرض الكلي للرموز وحد الحرق للجسر.
نقطة مهمة: يمكن لعقد xERC-20 من الناحية الفنية سك الرموز المميزة دون أن يتحقق الجسر من الإثباتات. لقد وصفنا النهج القياسي (اقرأ: متوقع) ، ولكن الجسور التي لا تنفذ أي نوع من التحقق من الرسائل - أو تنفذ آليات جديدة للتحقق من الرسائل عبر السلاسل - يمكن إدراجها في القائمة البيضاء لسك وحرق رموز xERC-20. كل هذا يتوقف على ما يمكن أن تقبله جهة إصدار الرمز المميز.
الدالة setBridgeLimits هي دالة محمية لا يمكن استدعاؤها إلا من قبل مالك عقد الرمز المميز. تسمح هذه الوظيفة بتعيين عنوان عقد الجسر وتحديد الحد الأقصى لمقدار الرموز المميزة التي يمكن للجسر سكها (mintingLimit) ونسخها (burningLimit) للمستخدمين. يمكن للمالك تحديث هذه الحدود ، مما يتيح ضبط قدرات الجسر حسب الحاجة. على سبيل المثال، إذا تم اكتشاف مشكلات أمنية في البنية الأساسية لموفر الجسر، فيمكن تقليل mintingLimit لتقليل المخاطر. على العكس من ذلك ، قد تؤدي التحسينات الأمنية إلى زيادة حد السك.
تشمل مواصفات xERC-20 أيضًا وظائف للتحقق من حدود الحرق والضخ للجسور المعتمدة للتعامل مع الرمز. يُعيد "mintingMaxLimitOf" الحد الأقصى لكمية الرموز التي يمكن لجسر إنشاؤها، وبالتالي، يُعيد "burningMaxLimit" الحد الأقصى لكمية الرموز التي يمكن لجسر حرقها خلال فترة محددة. بالإضافة إلى ذلك، تُظهر هذه الوظائف الرموز المتبقية التي يمكن للجسر حرقها وإنتاجها قبل بلوغ الحدود المحددة مسبقًا.
تعد وظائف العارض هذه مفيدة لمجمعي الجسور الذين يحتاجون إلى معرفة الحدود المتاحة لموفري الجسور المختلفين قبل توجيه المعاملات. إذا وصل الجسر إلى حد النسخ أو سك العملة على سلسلة المصدر أو الوجهة، فقد يؤثر ذلك على المعاملات الجارية وتجربة المستخدم. لذلك، يفضل المجمعون توجيه الطلبات إلى الجسور التي لم تصل إلى حدود سكها وحرقها ويمكنها إجراء مبادلة مبلغ معين.
تتضمن مواصفات واجهة xERC-20 للرمز المميز "Bridge" struct الذي يحتوي على "burningParams" و "mintingParams" (معلمات وظيفة تحديد الحد لرمز xERC-20 تحكم في كمية الرموز التي يمكن للجسر حرقها وطبعها على مدى فترة محددة). تحدد "maxLimit" الحد الأقصى لطباعة الرموز وحرقها وتزيد كل ثانية بسعر محدد مسبقًا ("ratePerSecond").
هنا حيث نتناول نقطة احتمالية للارتباك: "الحد الأقصى" (المحدد لكل من حرق وتحديد الحد الأقصى) يبدو وكأنه سقف على عمليات التحديد والحرق على جدول زمني معين - وليس حد للمعدل الذي يقوم بتخفيض تحديد وحرق وفقًا لعتبات محددة مسبقًا خلال النافذة الزمنية المحددة مسبقًا. "الحد الحالي" يحدد كمية يمكن للجسر تحديد أو حرقها ويزيد بمعدل محدد مسبقًا. على النقيض، "الحد الأقصى" يحدد كمية يمكن للجسر تحديدها أو حرقها يوميًا.
تعتبر معلمات النسخ والسك ذات صلة بشكل أساسي بمالكي الرموز المميزة (ومشغلي الجسور بدرجة أقل). ومع ذلك ، فإن معلمات الحد الأقصى والحالية هي اعتبارات مهمة للمستخدمين ومشغلي الجسور. على سبيل المثال، يمكن أن يؤثر الحد الحالي على مدى قدرة المستخدم على الربط بثقة باستخدام بروتوكول عبر السلاسل دون التعرض للتأخير في تلقي رموز xERC-20 المميزة في الوجهة.
لا يحدد رمز ERC-20 الأصلي وظائف لزيادة وتقليل المعروض من الرمز المميز (مرة أخرى عندما كانت "الرموز المميزة" تعني إنشاء عدد ثابت من الرموز المميزة وإخبار المستخدمين بأن الرمز المميز له قيمة لأنه سيكون نادرا في غضون بضع سنوات *). لذلك ، ليس كل رمز ERC-20 له وظيفة سك وحرق. نظرا لأن ERC-7281 يستخدم آلية سك العملة والحرق التي تفضلها معظم الجسور (إن لم يكن كلها) اليوم ، فلا يمكن أن تعمل رموز ERC-20 القديمة أو غير القابلة للترقية خارج الصندوق مع ERC-7281.
يوفر عقد Lockbox حلاً بديلًا ويمكن التوافق مع التوافق مع الرموز الحالية. في المواصفة الأصلية (أي ينتشر مشروع عقد رمز جديد ينفذ واجهة IXERC20)، يتعين على مشغلي الجسر فقط استدعاء mint() لإطلاق رموز لمستخدم على سلسلة الوجهة (بعد قفل إيداع على سلسلة المصدر).
يستعير عقد Lockbox بشكل كبير من تصميم عقد المُغلف WETH. ينفذ وظيفة الإيداع() لإيداع الرمز الخاص ب ERC-20 المقابل في Lockbox ووظيفة السحب() لمشغلي الجسر لفتح الرموز ERC-20 بعد حرق الرموز المُغلفة على نطاق بعيد.
يتم تسليط الضوء على أول نوعين من أنواع الأخطاء في المواصفات (“IXERC-20Lockbox_NotNative” و“IXERC-20Lockbox_Native”) عندما يحاول المستخدم إيداع الرموز التشفيرية في عقد Lockbox الخطأ. يمكن أن يكون Lockbox أصليًا أو غير أصلي، اعتمادًا على أنواع الرموز التشفيرية التي يدعمها.
الصناديق الأمانية الأصلية تحتفظ بالرموز الأصلية - وهي الرموز المستخدمة لدفع رسوم الغاز إلى المحققين. مثال على رمز سيكون لديه صندوق أماني أصلي لتغليفه في رمز xERC-20 هو ETH: سيتطلب تغليف ETH في رمز xERC-20 استدعاء وظيفة depositNative() للصندوق الأماني وإيداع ETH لاستلام التمثيل المتوافق مع ERC7281 لـ ETH.
الصناديق العادية (غير الأصلية) للقفل تحتفظ برموز ERC-20 مثل USDC و DAI و WETH و USDT وما إلى ذلك. على سبيل المثال، لكي يتمكن المستخدم من إطلاق USDC كرمز xERC-20، سيقوم بتسجيل () على عقد الصندوق بعد قفل USDC.
سيؤدي استدعاء الإيداع () باستخدام ETH إلى قفل هذه الأموال إلى الأبد نظرا لأن عقد Lockbox العادي يمكنه فقط تغليف رموز ERC-20 المميزة وفكها. سيؤدي استدعاء depositNative() باستخدام رمز ERC-20 إلى نتائج مماثلة لأن عقود Lockbox الأصلية تهدف إلى العمل مع الرموز المميزة الأصلية ، وليس رموز ERC-20.
وبهذه الطريقة، من خلال تغليف رموز ERC-20 الكنونية في رموز xERC-20 مع دعم الإنشاء/الحرق، يوفر القفل طبقة توافق مهمة للمعيار. ومع ذلك، بالنسبة لبعض الحالات، مثل دمج حلول الجسرية الأخرى في xERC-20، فإن استخدام القفل فقط، وإعادة الرمز المغلف ليست خيارًا. لهذا السبب، قد يقوم المشاريع بتنفيذ عقود محولة.
في الحالات التي لا يتم فيها تصميم بروتوكولات التوصيل للتعرف على العمليات المتأصلة في رموز xERC-20 المميزة (سك / حرق ، والتسجيل المقابل ، وما إلى ذلك) ، يمكن للتطبيقات إنشاء عقود محول. تعمل هذه العقود كأغلفة آلية وفك الأغلفة - تترجم بشكل فعال ERC-20 القياسي الموافقة + سلوك المكالمة إلى مخطط سك / حرق أكثر دقة يتطلبه xERC-20.
هذا ضروري لأن العديد من بروتوكولات الجسر (على سبيل المثال، CCIP لـ Chainlink) لا تزال محسنة لسلوك ERC-20 التقليدي. يمكن لعقد المحول تجاوز هذه الفجوة في التوافق عن طريق توثيق مثل هذا الطريقة: يقوم بإيداع الرموز التشفيرية في الصندوق الأمني لتوليد تمثيل xERC-20 على سلسلة المصدر، وفي وقت لاحق، عند استلام الرسالة على سلسلة الوجهة، يُشغّل آلية السحب للعودة إلى الأصل الكانوني.
يضمن هذا التدفق حصول المستخدم في النهاية على رمز مميز أساسي متسق - لا يتأثر بآليات التغليف المدعومة من xERC-20 تحت الغطاء. بهذه الطريقة ، يمكن للمحولات السماح للبروتوكولات بالتكامل بسلاسة مع الجسور غير المتوافقة مع xERC-20 وزيادة مجموعة الحلول القابلة للتشغيل البيني التي تدعمها.
على مستوى عالي، يحتوي ERC-7281 على أربعة أهداف رئيسية:
كانت الرؤية الأصلية لإنشاء مواصفات ERC-20 هي ضمان قابلية الاستبدال والتشغيل البيني السلس بين الرموز المميزة على Ethereum عبر التطبيقات والبنية التحتية ل Ethereum. ومع ذلك ، بعد اعتماد خارطة طريق تحجيم تتمحور حول التجميع ، نشأت مشكلة نقص قابلية التركيب الذري ، وأدى إنشاء العديد من المجالات المختلفة إلى تدهور خصائص قابلية الاستبدال تلك. يسمح xERC-20 بتجميع سيولة جسور التجميع المتقاطعة المختلفة في رموز موحدة متعددة الاكتساب ، واستعادة الرؤية الأولية ل Ethereum.
الأمان: لتقليل مخاطر الطرف المقابل ، يجب أن يكون لدى مصدري الرموز المميزة خيار الاختيار من بين موفري الجسور المنافسين وفقا لتقييم البنية التحتية للأمان. علاوة على ذلك، يجب أن يتمتع مصدرو الرموز المميزة بحماية ذات مغزى من تداعيات الحوادث الأمنية التي تؤثر على موفري الجسور الشريكين - لا ينبغي أن تمحو الهجمات المعزولة على خدمة واحدة أو اثنتين من خدمات الجسر TVLs بأكملها.
التمويل الذاتي للسيولة لرموز السلاسل العبرية: لا ينبغي أن يُجبر بروتوكول DAOs على إنفاق موارد كبيرة (مالية) على تمويل السيولة للرموز المعبرة كجزء من خطط التوسع متعددة السلاسل. ليس فقط أن توجيه السيولة سيء لتجربة المستخدم، ولكن قد يصبح الإنفاق على حوافز توفير السيولة غير قابل للتنفيذ لفرق المشروع بمجرد زيادة عدد سلاسل الكتل قريبًا.
السيادة لمصدري الرموز المميزة: يجب أن يظل مصدر الرمز المميز متحكما في التمثيل الأساسي للرموز المميزة للبروتوكول التي تم سكها على سلاسل غير أصلية. لا ينبغي أن يتطلب حل مشكلة الرموز المميزة غير القابلة للاستبدال تسليم التحكم في الرمز المميز الجسر للمشروع - خاصة الجوانب الإدارية مثل التحكم في إجمالي العرض وتكوين آليات سك والحرق - إلى جسر تابع لجهة خارجية.
يمكننا التوسع في هذه الأهداف لمعرفة الفوائد التي يوفرها ERC-7281 للبروتوكولات والمجتمعات.
يحل ERC-7281 إصدارات مختلفة من مشكلة الاعتماد على المسار الموضحة في المقدمة.
يمكن أن تكون الاعتمادية على المسار محددة للسلسلة (على سبيل المثال، الإيثيريوم المعبر عنه من إيثيريوم → أربيتروم → تفاؤل يختلف عن الإيثيريوم المعبر عنه من إيثيريوم → تفاؤل → أربيتروم) أو محددة للجسر (على سبيل المثال، الإيثيريوم المعبر عنه من إيثيريوم إلى تفاؤل عبر سيلر يختلف عن الإيثيريوم المعبر عنه من إيثيريوم إلى تفاؤل عبر كونيكست).
التبعية المسارية هي ميزة أمان قيمة، ولكن يمكن أيضًا أن تكون مضرة بتوصيل تجربة المستخدم وقابلية التكامل عبر السلاسل. على سبيل المثال، لا يمكن للمستخدم تزويد السيولة برمجيًا لصرف عبر السلاسل يعمل على أوبتيميزم وأربيترم لأن التطبيق يجب أن يقبل opETH أو arbETH.
يقضي ERC-7281 على المشكلة من خلال تقديم رموز xERC-20 التي تظل قابلة للاستبدال بغض النظر عن عدد المرات التي يربط فيها المستخدم عبر السلاسل أو موفري الجسور الذين اعتادوا على ربط الرموز المميزة. لنفترض أن المستخدم يرغب في نقل USDT المغلف من Arbitrum إلى Optimism دون الانسحاب إلى Ethereum أولا. يمكن لمزود الجسر حرق رموز xERC-20 المميزة على Arbitrum وسك xERC-20s على Optimism - لا تزال قيمة الرموز المميزة التي تم سكها على Optimism مرتبطة بالرموز المميزة المودعة في Lockbox ويتم إعادة تعيينها للحفاظ على دعمها 1: 1.
على نحو مهم، يوفر ERC-7281 فوائد نشر عملة جسرية كانونية مثل CCTP لشركة Circle (بروتوكول نقل عبر السلاسل) دون الحاجة إلى وجود حضانة مركزية للعملات الجسرية. على سبيل المثال، يتم توحيد السيولة حول التمثيل الكانوني لعملة المشروع، مما يحسن من فائدة العملة لتطبيقات DeFi ويقلل من التكاليف الزائدة لإنشاء أسواق مختلفة لإصدارات مختلفة من نفس الأصل.
توصف xERC-20s بأنها "رموز مميزة ذات جسر سيادي" حيث لا يتم تقييد مصدري الرموز المميزة باستخدام خيار معين لسك التمثيلات الأساسية للرمز المميز والاحتفاظ بالتحكم في تصميم وإدارة الرموز المميزة الجسرية عبر عمليات النشر. ERC-7281 عبارة عن مزيج بين "سك الرموز المميزة الأساسية عبر جسر تابع لجهة خارجية" و "سك الرموز المميزة الأساسية عبر جسر يتحكم فيه مصدر الرمز المميز" الذي يجمع بين السيادة وتجربة المستخدم واللامركزية في نفس الحزمة.
يمكن للمشاريع التي تنشر الرموز المميزة عبر السلاسل باستخدام ERC-7281 سك التمثيلات الأساسية للرموز الأصلية عبر جسور متعددة دون الوقوع في مشكلة الإصدارات المغلفة غير القابلة للاستبدال من نفس الأصل الأصلي ، مما يؤدي إلى كسر تجربة المستخدم للمستخدمين الذين يأملون في الاستفادة من قابلية التركيب وقابلية الاستبدال لرموز ERC-20. تحتفظ مثل هذه المشاريع أيضا بمستوى مماثل من التحكم في عمليات النشر عبر السلاسل للرمز المميز كمصدر رمز مميز يدير بنية تحتية داخلية لإدارة عمليات نقل الرموز المميزة الأساسية بين النطاقات نظرا لأن عقود الرمز المميز xERC-20 و Lockbox - التي تستخدمها الجسور لقفل الرموز المميزة وسكها وحرقها للمستخدمين - يتم نشرها والتحكم فيها بواسطة المشروع.
يمكن أن يكون هذا الميزة البسيطة مفيدًا في الحالات التي تكون فيها مشروع ذو شهرة عالية لديه رمز مميز صادر على سلسلة البيت. يرغب مستخدمون من بيئات أخرى في التعرض للرمز دون الاحتفاظ به على سلسلته الأصلية لأسباب مختلفة.
ومع ذلك، لا يتوفر للمشروع القدرة أو الرغبة في تشغيل بنية تحتية للجسر الداخلية لكل سلسلة لضمان التوافق 1:1 بين الرموز المتصلة - ولا يرغب في تسليم التحكم في رمزه إلى طرف ثالث ليس بالضرورة متماشي مع البروتوكول ومجتمعه. يصبح مثل هذه الحالة مراعاة عند تنفيذ حكم عبر السلاسل الذي يسمح بالتصويت باستخدام الرموز المتصلة بينما يتم تسجيل الأصوات على السلسلة الأصلية؛ مزود الجسر غير المتماشي مع التحكم في الرموز المتصلة يصبح نقطة اختناق لحكم البروتوكول.
كما اعتمد Beefy ، وهو بروتوكول لزراعة الغلة ، xERC-20 لهذا السبب. كما تصفها وثائق جسر المشروع ، زود ERC-7281 المشروع بمزيد من الخيارات لتجسير الرموز - والتي أصبحت ضرورية بعد أن عانى شريك جسر رئيسي من اختراق (موضوع أصبح مألوفا بسرعة للسكان الأصليين للعملات المشفرة) - وقدم تحكما أكثر دقة في تصميم آليات الجسر. في حالة Beefy ، مكنت ميزة القائمة المسموح بها في ERC-7281 البروتوكول من تحديد شركاء تجسير مختلفين وتقديم خيارات مختلفة للمستخدمين بين تحسين السرعة واللامركزية والتكاليف والأمان عند سد رموز mooBIFI.
يفضل توجيه السيولة بناءً على المشاريع التي تمتلك القدرة المالية على إنفاق حوافز السيولة - حيث يرغب مصدرو الرموز في إنفاق أقل على حوافز LP وتقديم تجربة جسرية متفوقة، تصبح السيولة العامل الأكثر أهمية بالنسبة للبروتوكولات التي تستخدم جسور L1/L2 القنونية. يمتد هذا أيضًا إلى اختيار مزودي الجسور من قبل مجمعي الجسور، مما يجعل من الصعب بالقول أن يتنافس الخدمات الجديدة للجسور (حتى تلك التي تمتلك بنية تحتية آمنة) مع بروتوكولات الجسور الأكثر تأسيسا.
يعالج ERC-7281 المشكلة عن طريق إزالة الحاجة إلى التجسير القائم على السيولة. دون الحاجة إلى سك ومبادلة الرموز غير الأساسية بالرموز الأساسية ، يمكن الموافقة على الجسور من أي حجم لسك الرمز المميز للمشروع على نطاق بعيد. نظرا لأن مصدري الرموز المميزة يرغبون في تقليل التعرض لفشل الجسور ، فمن المحتمل أن تبدأ المزيد من البروتوكولات في إيلاء المزيد من الاهتمام للتصميمات الأمنية للجسور عبر السلاسل بدلا من التركيز على السيولة أولا.
هذا يحفز المنافسة المفتوحة لأنها تصبح حالة "دع الجسر الأكثر أمانا يفوز" وليس "دع الجسر الأكثر سيولة يفوز". يمكن أن تتخذ هذه المنافسة المفتوحة شكل جسور تتنافس على المزيد من الميزات التي تتجاوز السيولة / الأمان (على سبيل المثال ، الرسوم ، واجهات برمجة التطبيقات / SDKs ، وتكامل التطبيقات ، وما إلى ذلك). يمكن القول إن هذه الميزات أسهل في خبزها في تطبيق من البداية لأنها تعتمد بشكل أساسي على خبرة فريق التطوير. في المقابل ، تعد أحجام السيولة والتجسير أكثر تعقيدا في التمهيد وتتطلب مزيجا من تطوير الأعمال والتمويل والاتصالات الصناعية والتسويق والمزيد.
يقدم ERC-7281 حدا للمعدل قابلا للتكوين على سك وحرق الرمز المميز الذي يحسن بشكل كبير ملف تعريف المخاطر للبروتوكولات التي تعمل مع جسور الجهات الخارجية لسك الرموز المميزة الأساسية على سلاسل غير أصلية. في حالة اختراق موفر الجسر الشريك أو اختراقه، فإن أكبر ضرر يمكن أن يسببه المهاجم يعادل الحد المعين للجسر المخترق. إذا اختارت جهة إصدار الرمز المميز معلمات تحديد المعدل بعناية، فيجب أن يكون للهجمات المعزولة على الجسر تأثير ضئيل على ملاءة البروتوكول.
قد يساعد أيضًا تكوين حدود المعدلات لكل جسر في تحسين عملية تقييم المخاطر لبروتوكولات DAO. حاليًا ، قد يستغرق تقييم مخاطر الجسر أشهرًا لإكماله بسبب مدى التأثير الناتج عن اختراق جسر طرف ثالث كانوني؛ حيث ترغب البروتوكولات في التأكد من اتخاذ قرارات مدافعة ، حيث يتم فحص أمان الجسر المختار بشكل مكثف لتقديم ضمانات أقوى للمجتمع بشأن السلامة. بالإضافة إلى كونها تضيع بشكل غير ضروري للجهد والوقت ، ما زال تحليل أمان الجسر يضمن بعد أن الجسر المختار غير معرض للاستغلال في اليوم الصفر.
اعتماد ERC-7281 يجعل تقييم المخاطر أكثر ديناميكية. لا يزال يتعين على المشاريع إكمال العناية الواجبة على مزودي الجسور لاختيار الخصائص المناسبة التي تحد من المعدل. ومع ذلك ، يمكن تقليل الجداول الزمنية لتقييم المخاطر لتعكس أن البروتوكولات لم تعد في وضع كل شيء أو لا شيء. بدلا من قضاء أشهر في تحليل العديد من الجسور لاختيار خيار واحد ، يمكن للمشروع قضاء نصف الوقت في اختيار العديد من موفري الجسور في البداية ووضع حدود سك مختلفة بناء على تقييم الأمان. يمكن لمصدر الرمز المميز بعد ذلك إجراء مراجعات أمنية لتحديد ما إذا كان سيتم زيادة أو تقليل حدود سك لشركاء التوصيل المحددين أو سحب حقوق سك من الجسر (على سبيل المثال، استجابة للاختراق أو الكشف عن الثغرات الأمنية).
تقلل ERC-7281 أيضًا من الحواجز التي تواجه المشاريع التي ترغب في الانضمام إلى التطورات الحديثة في أمان الجسر ولكنها تتردد في اعتماد تقنية معينة بالكامل حتى يتم اختبار التكنولوجيا بشكل جيد ويتم فحصها بدقة من قبل المجتمع (أي مأزق المبتكر). فإذا اقترح موفر الجسر بنية تحتية جديدة تحسن بشكل كبير ضمانات الأمان، يمكن لبروتوكول "اختبار المياه" عن طريق منح حقوق البناء المحدودة للجسر وزيادة حد البناء تدريجيًا مع ارتفاع الثقة في تصميم النظام المقترح.
مثل إزالة مخاوف السيولة ذات الصلة، إزالة الحاجة إلى أن يثق البروتوكول في تكنولوجيا الجسر 100٪ قبل منح حقوق الإصدار يخلق منافسة متساوية بين الداخلين الجدد واللاعبين القدامى - اللاعبون القدامى لديهم حافز للتكرار على أفضل النهج للأمان حيث يمتلك مُصدر الرموز الآن مرونة لسحب حقوق الإصدار وإعادة الإسناد إلى مشروع أصغر فقط لأن الأخير قد أظهر التزامًا أعلى بالسلامة واللامركزية. كما يقضي هذا أيضًا على عامل الخطر الآخر للبروتوكولات التي تعمل مع جسور الطرف الثالث: خطر أن مزود الجسر المختار يتوقف عن الابتكار في مجال الأمان على الرغم من وتيرة الكشف عن العيوب والمشاكل في أمان الجسر واكتشافها بسرعة لأنه يعلم أن مصدر الرموز لا يمكنه فرض إجراءات عقابية (على سبيل المثال، الانتقال إلى مزود جسر آخر) بسبب صعوبة تنفيذ مثل هذه الأنشطة.
بناء سير العمل التطبيقية المعقدة التي تتطلب توجيه الرموز عبر أي عدد من السلاسل أمر صعب اليوم بسبب التسعير غير المتوقع للجسور القائمة على السيولة. على سبيل المثال، لدى وسيط الجسر الذي يربط بين إيثيريوم → لينيا → القاعدة خياران:
بالمقارنة، يمكن لمجمعو الجسور معرفة مسبقا كم عدد الرموز يجب أن يتوقعوها على كل نطاق مشارك في عملية تشفير عبر السلاسل من خلال التحقق من mintingLimit و burningLimit للجسور المسموح لها بتشفير رمز معين. من المسلم به، يمكن لجسر أن يصل إلى الحد الأقصى بين وقت بث الصفقة ووصول الصفقة إلى النطاق—مما يعني أن المستخدم لا يمكنه تلقي الرموز الكنسية في الوجهة.
ومع ذلك ، لا يزال ERC-7281 يمثل تحسنا في هذا الصدد للأسباب التالية:
التحولات غير المتوقعة في السيولة تعني أيضًا عدم التنبؤ في تسعير عمليات توجيه الجسور. لنفترض أن مجمع الجسر (أو تطبيق آخر) يضع عرضًا لعملية تبادل عبر السلسلة استنادًا إلى سعر الزوج الحالي لزوج الرموز في بركة السيولة للجسر (يستند هذا السعر إلى إجمالي سيولة البركة). لا يزال بالإمكان تنفيذ العملية بسبب الانخفاض الحاد في سيولة البركة. لنفترض أن الصفقة معلقة وتمت إعادة المحاولة لاحقًا. في هذه الحالة، لا يمكن لمطور التطبيق أن يعرف ما إذا كان العرض السابق ما زال دقيقًا أم ما إذا كانت السيولة ستصل إلى نفس المستويات كما كانت عندما قدم المستخدم المعاملة للمرة الأولى.
نظرًا لأن ربط الرموز xERC-20 لا يخضع لحركات السيولة، يمكن للمستخدمين أن يكونوا واثقين من أن المعاملات عبر السلاسل لن تتكبد الانزلاق حتى لو لم يتم تنفيذها على الفور.
مجمعات التجسير ليست الوحيدة التي تستفيد من هذا التحسين في قابلية التكوين. يمكن لأي تطبيق عبر السلاسل تسخير قابلية استبدال رموز xERC-20 لإنشاء تطبيقات أكثر إثارة. هذا أكثر صعوبة اليوم بسبب المشاكل المتعلقة بالاعتماد على المسار: لنفترض أن أحد المطورين يرغب في سد ETH من Ethereum ، وفتح مركز إقراض على Arbitrum DEX ، واستخدام الأرباح لشراء NFT على Optimism قبل العودة إلى Ethereum. هنا ، يجب على المطور التأكد من التكامل مع موفري الجسور على تلك السلاسل - حيث لا يمكنك تبديل الإصدارات الخاصة بسهولة - وهذا ليس هو الحال بمجرد أن تصبح الرموز المميزة الجسرية للمشروع قابلة للاستبدال بعد اعتماد xERC-20.
هذه السير العمل مشابهة لجسور الإصدار الرمزية الموصوفة سابقا. دعونا نأخذ Circle CCTP كمثال:
يسمح بروتوكول النقل عبر السلاسل الخاص ب Circle للمستخدمين بالحصول على نسخة أساسية موحدة من رمز USDC الخاص به دون الوقوع في شرك النظام البيئي لسلاسلهم. تتم معالجة جميع عمليات النقل عبر السلاسل من خلال بروتوكولها باستخدام مخطط الاحتراق والسك.
ومع ذلك، بينما يعتبر CCTP بروتوكولًا مركزيًا، حيث أن مشغلي Circle هم الكيانات الوحيدة المخولة بحرق وطباعة رموز USDC الخاصة به، يقوم xERC-20 بتصفية مخاطر الثقة من خلال السماح لكيانات متعددة بآليات أمان مختلفة بتشغيل تحويلات عبر السلاسل.
يمكن لـ ERC-7281 تسريع خارطة طريق إيثيريوم المتمحورة حول Rollup عن طريق منح المشاريع الثقة لنشر الرموز على L2s الجديدة لـ EVM والتي قد تفتقر إلى ملامح أمان قوية لسلاسل L2 المؤسسة. على سبيل المثال، فإن الجسر الكانوني لـ rollup المرحلة 0 أقل أمانًا لأن Ethereum L1 لا تضمن أمان الجسر. يمكن لمشروع الرمز تنفيذ إطلاق تدريجي على مثل هذه السلسلة عن طريق منح حقوق النقد المحدودة للجسر الكانوني وزيادة حد النقد بمجرد تقدم rollup إلى المرحلة 1.
يمكن أن تستمر هذه العملية حتى يصل L2 إلى المرحلة 2 (أعلى مرحلة من اللامركزية والأمان للمجموعة المجمعة). إن الآلية التي يمكن من خلالها نشر البروتوكولات على السلاسل التي تم إطلاقها حديثا بطريقة تقلل من المخاطر تفيد نظام Ethereum البيئي من خلال تسهيل تشغيل L2s الجديدة لسيولة وتطبيقات الرمز المميز مع تشجيع المزيد من الابتكار في مساحة تصميم القيمة المحتسبة.
بينما يعتبر ERC-7281 جذابًا للغاية للبروتوكولات، قد تتردد الDAOs في اعتماد رموز xERC-20 بسبب العبء التشغيلي الكبير الذي يتعين على فرق مشاريع الDAO تحمله لإدارة رموز xERC-20 على مستويات نشر مختلفة.
جيرارد بيرسونإدارة الرموز المميزة الجسرية على عدد كبير من السلاسل يتضمن قائمة غير شاملة بالمهام لمرة واحدة والمتكررة التي يجب على البروتوكول تنفيذها بعد الانتقال من ERC-20 إلى xERC-20:
هذه قائمة طويلة جدا من المهام
الحل المقترح هو أن تقوم DAOs بالاستعانة بمصادر خارجية لبعض هذه المهام الإدارية المتعلقة بإدارة رموز xERC-20 عبر السلاسل لخدمات الجهات الخارجية ، ولكن هذا مجرد تبادل مقايضة واحدة (تكاليف الموارد البشرية) بأخرى (تكاليف خدمات التوظيف).
لنفترض أن بروتوكولا كان يدير سابقا الرموز المميزة عبر السلاسل مع بنية تحتية داخلية (على سبيل المثال ، نشر عقد رمز مميز منفصل لكل سلسلة والتحكم في سك وحرق). في هذه الحالة ، لا يبدو ERC-7281 تغييرا جذريا. ومع ذلك ، فإن المشاريع المستخدمة للاستعانة بمصادر خارجية لإدارة البنية التحتية الأساسية للتجسير بين فرق التطوير ستجد عبء العمل الإضافي مثيرا للقلق.
على سبيل المثال،حدد أحد أعضاء فريق Lido الأساسي(ردًا على اقتراح لـ Lido بنشر wstETH كرمز xERC-20 عبر جميع النشرات) المسؤوليات الحالية لفريق إدارة المشروعات المعني ببنية التوافق ومقارنتها مع المجموعة المطلوبة من أعضاء الفريق نفسهم لتوليها إذا صوتت Lido DAO لنقل wstETH على جميع النطاقات إلى الإصدار xERC-20.
كما يظهر الحوار أعلاه، فإن إدارة رموز xERC-20 تفرض زيادة لا يمكن تجاهلها في السلبيات الإدارية على البروتوكولات وأعضاء المجتمع. على سبيل المثال، تتطلب حدود الجسر مراقبة نشطة وتقييمًا لأمان الجسر لإبلاغ التعديلات على حدود الإنتاج، وقد تخضع قرارات حول حدود الجسر (أو سحب/تخصيص حقوق الإنتاج) للتصويت في DAO (إذا كان من الضروري اتخاذ مثل هذه الخيارات بشكل متكرر، فقد يعاني أعضاء DAO من تعب الناخب).
هذا لا يجب أن يُفسر على أنه حكم قيمة على ERC-7281، مع ذلك. سيكون لكل مشروع ملامح مخاطر مختلفة، وأهداف طويلة الأجل، وموارد، وتحدد هذه العوامل مجتمعة ما إذا كانت الفائدة طويلة الأجل من اعتماد ERC-7281 تفوق التكاليف القصيرة الأجل والمستمرة للقيام بذلك.
على سبيل المثال، قد يجد المشاريع الأصغر صعوبة في إدارة التكاليف الإدارية والتشغيلية لإصدار رموز xERC-20 ويختارون اللجوء إلى خدمة جسر الرموز متعددة السلاسل المدارة مثل خدمة Axelar ITS (Interchain Token Service) أو NTT (Native Token Transfers) لـ Wormhole. قد تمتلك المشاريع الأكثر تماسكاً الموارد الكافية لإدارة التكاليف الإدارية والتشغيلية لإصدار رمز xERC-20 وقد تنظر في أن السيطرة التي يوفرها ERC-7281 تستحق التكلفة الإضافية لإدارة رموز عبر السلاسل.
بالنسبة للمشاريع التي ليس لديها واجهة البناء/الحرق، أو التي لا يمكن ترقية عقود الرموز لاستخدام IERC20 عبر الوراثة، ولديها بالفعل تمثيلات كانونية للرموز الأصلية المتداولة على سلاسل غير أصلية، فإن التحول إلى رموز xERC-20 هو عملية طويلة تتطلب الكثير من التنسيق وتشمل شبكة معقدة من المشاركين— تتراوح من حاملي الرموز، والبورصات (DEXes وCEXes)، وجسور الشراكة، والتطبيقات المتكاملة مع الرمز ERC-20 التقليدي. حتى مع تلك الجزء المعالج، البروتوكولات لا تزال تتحمل تكلفة فك تشفير ERC-20s إلى xERC-20s لاستكمال عملية التحول.
كما هو موضح في مناقشة مواصفة ERC-7281، سيحتاج الرموز الحالية إلى أن تُقفل في صندوق القفل لإصدار xERC-20s مغلفة للمستخدمين. يحدث تقاعد ERC-20 القديم بعد ذلك بفترة قصيرة ويتضمن عملية طويلة أخرى لمشاركة الاتصال مع المجتمع حول الجدول الزمني لتجميد إصدار الرموز الجديدة (القديمة) ERC-20. مرة أخرى، قد تكون هذه التكلفة مبررة تمامًا من وجهة نظر البروتوكول — على الرغم من أن الفوائد قد لا تكون كافية أيضًا لتبرير تكاليف تنسيق هجرة على نطاق النظام البيئي إلى التمثيل المتوافق مع xERC20 لرمز البروتوكول.
تتطلب إدارة رموز xERC-20 المميزة على نطاقات متعددة باستخدام ERC-7281 حوكمة نشطة من DAO التي تشرف على البروتوكول. يتضمن ذلك تعيين معلمات مثل حدود سك العملة وترقية عقد Lockbox وإيقاف سك الرموز المميزة أو حرقها مؤقتا. هذه القرارات حساسة للأمن ويجب أن تحكمها DAO لتجنب مسؤولية قرارات مجلس الإدارة المغلقة.
يهدف ERC-7281 إلى منح البروتوكولات السيطرة على هذه القرارات بدلا من جسور الطرف الثالث. هذا منطقي ، حيث تدير DAOs بالفعل الرموز المميزة على سلاسلها الأصلية ، لذا فإن توسيع حوكمتها لتشمل الرموز المميزة على سلاسل أخرى أمر معقول للبروتوكولات والمجتمعات التي تسعى إلى هذا التحكم. ومع ذلك ، قد لا ترغب بعض البروتوكولات في التحكم الإضافي في DAO بسبب مخاوف بشأن الحوكمة والاستقرار.
على سبيل المثال، تواجه المشاريع ذات الشهرة العالية مثل ليدو انتقادات حادة بشأن مسائل الحوكمة. إضافة السيطرة على إدارة الرموز يزيد من مخاطر انقلاب الحوكمة. هجوم الحوكمة يمكن أن يكون له تأثيرات واسعة النطاق إذا ما جمع المشروع جميع الرموز ERC-20 في صندوق قفل ويديره الديسي. يمكن للمهاجم السيطرة على صندوق القفل وإدخال موفر جسر شرير بدون حدود للطباعة، مما يجعل الرموز xERC-20 على سلاسل أخرى بلا قيمة.
تتوازى هذه السيناريوهات مع استغلال السلاسل المتعددة، حيث سمحت الثغرة في بنية التوقيع بالحساب التعددي (MPC) للمتسللين بالتسلل إلى عناوين السلاسل المتعددة الأساسية التي كانت تحتضن الرموز الأصلية على الإيثيريوم ودوجكوين - هذه الرموز دعمت الرموز المضافة التي تم ضربها على سلاسل غير أصلية مثل فانتوم وموونريفر، مما أدى إلى تفعيل تأثير الدومينو الذي تسبب في تكبد المشاريع خسائر في مكان آخر نتيجة للهجوم على العقود الذكية للسلاسل المتعددة على الإيثيريوم ودوجكوين.
يناسب ERC-7281 الغرض عندما يتم إصدار الرمز المميز بواسطة بروتوكول مع حوكمة الرمز المميز أو كيان مركزي (على سبيل المثال ، USDC الخاص ب Circle أو عملة CZKC المستقرة). ومع ذلك ، فهي ليست ذات قيمة إذا كان البروتوكول لامركزيا إلى أقصى حد ويفتقر إلى الحوكمة الرسمية - تعد عملة LUSD المستقرة من Liquity مثالا على رمز مميز يصعب جعله متوافقا مع معيار xERC-20.
يتطلب رمز xERC-20 من الكيان اتخاذ قرار بشأن معلمات محددة مثل حدود سك وحرق واتخاذ قرارات مثل ما إذا كان سيتم إدراج بعض مزودي الجسور في القائمة البيضاء أم لا. هذا يعني الحاجة إلى استمرار الحوكمة لوجود رمز xERC-20. بالنسبة للمشاريع التي ترغب في تحقيق اللامركزية في المكونات الهامة للبروتوكول - مثل عقد الرمز المميز ل DAO - بمرور الوقت ، قد يتسبب ذلك في حدوث مشكلات وتعقيد خطط اللامركزية.
لقد ذكرنا بالفعل كيفية عمل الاعتماد على المسار ولماذا يساعد في توفير ضمانات بأن الاستغلال الذي يؤثر على السلسلة A لن يؤثر على السلسلة B ، أو أن الاستغلال الذي يتضمن الجسر A على السلسلة A لن يؤثر على الجسر B على السلسلة B. يزيل ERC-7281 اعتماد المسار ، والذي له فوائد ، ولكنه يقدم أيضا مقايضة حول الأمان:
لم يعد الحد الأقصى للسيولة المتاحة في الجسر يمثل حدا أعلى للتأثير المحتمل لاستغلال الجسر على مصدر الرمز المميز، حيث أن الرموز المميزة التي يتم سكها من قبل موفري الجسور المختلفين قابلة للاستبدال عبر المجالات. يقترح مؤلفو ERC-7281 اختيار حد سعر لموفري الجسور بناء على المبلغ الذي يمكن أن ينفقه مصدر الرمز المميز للتعويض عن الخسائر الناجمة عن سك العملة الاحتيالية. ومع ذلك ، ربما كان حد المعدل المحدد متحفظا للغاية في وقت لاحق.
إذا تم الاعتداء على جسر ذو حد أعلى عالٍ، يمكن أن تكون التأثيرات ملحوظة حتى على مستخدمي الجسور الأخرى الذين يقومون بطباعة نفس الرمز. يمكن للبروتوكولات تقليل المخاطر من خلال توزيع حقوق الطباعة عبر عدد كبير من الجسور (بحيث لا يمتلك مزود جسر واحد عددًا كبيرًا من الرموز التي يمكنه طباعتها مقارنة بالجسور الأخرى)، ولكن محاولة تحويط المخاطر بهذه الطريقة قد تزيد من عدم الكفاءة حيث ستتطلب كل جسر تقييمًا مستقلًا من فريق داو والتنسيق مع المزيد من الجسور يزيد من النفقات الإدارية التي ذكرناها سابقًا.
يمكن أن يؤدي عقد Lockbox الذي تحكمه DAO إلى حدوث تأثيرات عدوى ضارة في حالة وقوع هجوم حوكمة. ولكن حتى مع حوكمة DAO الآمنة ، يمكن أن يتسبب الخطأ في عقود Lockbox الأصلية / غير الأصلية على السلسلة الرئيسية للرمز المميز في حدوث العديد من المشاكل (Sifu هو الآن مالك عقد Lockbox لمشروع ما ، ولم تعد الأموال SAFU). وبالمقارنة ، يتم تقليل هذه المشكلة في الوضع الراهن حيث أن عقود الخزينة (المكافئ لموفر الجسر لعقد Lockbox) تحتفظ فقط بالرموز المميزة التي تم جسرها من خلال خدمة الجسر المقابلة. لذلك ، يؤثر الخطأ في عقد المخزن لموفر واحد فقط على المستخدمين الذين قاموا بإيداع الرموز المميزة في هذا الجسر.
يؤثر العمل الإداري الإضافي مع ERC-7281 أيضا على مطوري التطبيقات وموفري الخدمات الذين يستخدمون رمز xERC-20 المميز للمشروع. يحتاج مجمعو الجسور إلى تتبع التعيينات بين رموز xERC-20 وعقود Lockbox المقابلة لها لمنع مشكلات مثل الرموز المميزة للبريد العشوائي وهجمات الانتحال. في حين أن سجل هذه التعيينات يمكن أن يساعد ، إلا أن إنشاء مثل هذا السجل يمثل تحديا دون المخاطرة بالمركزية أو تعريض متبني xERC-20 للتهديدات.
يأتي الخطر من احتمال قيام المهاجمين بإضافة عقود ضارة إلى سجل الرمز المميز وخداع المستخدمين والمطورين لإرسال الرموز المميزة إلى العنوان الخطأ. قد يؤدي ذلك إلى سرقة الرمز المميز على كل من شبكات L2 و L1. تواجه البورصات تحديات مماثلة ، حيث يمكن أن تسبب الرموز المميزة المخادعة مشاكل خطيرة ، مثل سلوك الرمز المميز غير المتوقع ، والذي يختلف عن الرموز المميزة الأساسية التي تم فحصها.
يقدم ERC-7281 حلا مقنعا لمشاكل الرموز الجسور غير القابلة للتبادل ويقدم ميزات تعزز تجربة المستخدم واللامركزية والأمان والمرونة في تصميمات الرمز الجسور. بعض هذه المشاكل تؤثر مباشرة على قابلية جدول الطريق المتمحور حول الRollup، مما يجعل معيار xERC-20 بنية تحتية حرجة للبيئة البيئية Ethereum L2.
تعهد العديد من اللاعبين الرئيسيين في مجال الربط، بما في ذلك Hyperlane و Omni و Sygma و Router Protocol و Everclear، بتبني ERC-7281، مما يشير إلى جاذبية كبيرة للاقتراح. حتى الجهات الصادرة للرموز المعتمدة (التي لديها آليات عمل لربط الرموز) - مثل Circle - أبدت اهتمامًا بـ ERC-7281 لمعالجة التحديات التي تواجه المستخدمين والمطورين نتيجة للرموز غير المعتمدة.
يعالج ERC-7281 هذه المشاكل مع التخفيف من العديد من التنازلات المرتبطة بالنهج السابقة لضخ الرموز الكنسية على النطاقات البعيدة. إنه يوفر تشغيلًا خاليًا من السيولة، على عكس الجسور الموثقة، ولا يتطلب بنية تحتية مخصصة مثل جسور مُصدِر الرموز، ويتجنب الاحتجاز البائعي من خلال السماح بضخ الرموز الكنسية متعددة الجسور بواسطة مزودي الجسور المعتمدين.
للمهتمين بمتابعة المناقشة حول ERC-7281 أو المطورين الذين يتطلعون إلى دمج xERC-20 ، زمالة سحرة Ethereum و موقع xERC-20 هي موارد ممتازة. قام المجتمع أيضا ببناء منصة إطلاق xERC-20 لتجميع الأدوات لإنشاء رموز xERC-20 المميزة ومراقبتها وإدارتها - وهي أداة قيمة للبناة الذين يتطلعون إلى نشر رمز xERC-20 لأول مرة أو ترحيل رمز مميز موجود إلى معيار الرمز المميز xERC-20.