1. المقدمة والدافع

الخلفية

تعتمد منصة EQTY على بنية تحتية ذات طبقتين:

• طبقة خاصة لإدارة سلاسل الأحداث القابلة للتحقق (مثل الملكيات، الرسائل)

• طبقة تثبيت عامة لتسجيل الوقت والتحقق من تلك السلاسل على بلوكتشين غير قابلة للتغيير
  

تاريخياً، كانت هذه الطبقة العامة مقدمة من شبكة LTO الطبقة 1، وهي بلوكتشين مخصص يعتمد على إثبات الحصة ومُحسَّن للتثبيت.

ومع ذلك، فقد تغير سياق التشغيل بشكل كبير.

لماذا يجب إلغاء الطبقة 1 من LTO

1. انهار الأمان الاقتصادي

• تبلغ القيمة السوقية الحالية لشركة LTO أقل من 5 ملايين دولار، مع وجود حوالي 20% فقط من الرموز المميزة قيد التخزين.

• وهذا يعني أن ميزانية الأمن الفعالة (أي القيمة الإجمالية لتأمين الإجماع) تبلغ حوالي مليون دولار.

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

• بالنسبة لمنصة مثل EQTY - التي تُرسّخ سجلات الأصول القابلة للتنفيذ قانونيًا - فإن هذا الأمر غير مقبول.

2. مركزية المدققين وانخفاض الحوافز

• لم تعد مراكز التجمعات المجتمعية مجدية اقتصادياً.

• قد يؤدي إنهاء خدمة العقد إلى سيطرة مجموعة صغيرة من العقد بشكل غير متناسب على عملية الإجماع.

• هذا يقوض ضمانات اللامركزية التي من المفترض أن يوفرها التثبيت.

3. صعوبات التبني

• أصبح من الصعب بشكل متزايد تبرير استخدام تقنية LTO كطبقة تثبيت آمنة في محادثات المبيعات أو التدقيق.

• يتوقع العملاء والشركاء أن ترتكز EQTY على شبكات عامة واسعة الانتشار وذات مصداقية (مثل Ethereum و Base).

• إن فكرة "الاعتماد على طبقة أولى بقيمة 5 ملايين دولار" تضعف الثقة في البنية التحتية الأساسية لشركة EQTY.

4. هشاشة البنية التحتية

• إذا تعطلت حتى بضع جهات تحقق رئيسية، يصبح LTO غير مستقر أو يتوقف تمامًا.

• تؤدي الصيانة المستمرة (المستكشفون، والفهارس، والبنية التحتية للعقد) إلى زيادة التكاليف مع تناقص القيمة.

لماذا تُعتبر الطبقة الأساسية هي طبقة التثبيت المناسبة

العروض الأساسية:

• توافق كامل مع EVM

• الأمن الاقتصادي والتقني الموروث من إيثيريوم

• دعم واسع النطاق للأدوات (MetaMask، WalletConnect، The Graph، إلخ).

• رسوم شبه معدومة مع سرعة في الإنجاز

• التوافق الوثيق مع طبقة الأصول والسيولة الخاصة بشركة EQTY، والتي توجد أيضًا على Base
  

يؤدي التثبيت على القاعدة إلى إزالة عبء الحفاظ على طبقة 1 مخصصة مع زيادة إمكانية التدقيق والتكوين والثقة.

الدافع الاستراتيجي

• لا تكمن قيمة EQTY في الإجماع، بل في طبقتها الخاصة، ونموذج أصولها، وهيكلها الخاص بالامتثال.

• إن الحفاظ على الطبقة الأولى لا يوفر ميزة استراتيجية تذكر بتكلفة عالية.

• الانتقال إلى Base يسمح لشركة EQTY بالتركيز بشكل كامل على تبني المنتج والتكامل القانوني ورمزية الأصول، دون أن تتأثر بالبنية التحتية للطبقة 1.

2. رمز ERC-20 جديد $EQTY

ستطرح منصة EQTY رمزًا جديدًا من نوع ERC-20، وهو $EQTY، وسيتم نشره على الشبكة الأساسية. يحل هذا الرمز محل رمز LTO ويُستخدم كعملة أصلية لعمليات البروتوكول، بما في ذلك التثبيت والحوكمة.

يبدأ عقد الرمز المميز بدون أي عرض. يتم سكّ رمز $EQTY عند الطلب عندما يقوم المستخدمون باستبدال رموز LTO الخاصة بهم خلال فترة انتقال محدودة. يتم تطبيق هذه الفترة على سلسلة الكتل: بعد بلوغ ارتفاع كتلة محدد مسبقًا، يتم تعطيل وظيفة السكّ بشكل دائم. أي رموز LTO لم يتم تحويلها قبل هذا الحد تُستبعد من نظام EQTY البيئي، وسيكون العرض النهائي لرمز $EQTY أقل من العرض الأصلي لرموز LTO.

عقد الرمز المميز بسيط للغاية عن قصد. فهو يتبع واجهة ERC-20 القياسية، بدون منطق تحويل خاص، أو ميزات توزيع مجاني، أو جداول استحقاق.

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

3. عقد رئيسي في القاعدة

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

كل مرساة تربط مفتاحًا بقيمة، حيث:

• بالنسبة لسلاسل الأحداث: المفتاح = stateHash، القيمة = eventHash

• بالنسبة للرسائل: المفتاح = messageHash، القيمة = 0x0

واجهة المستخدم

struct Anchor {

مفتاح بايت 32؛

قيمة بايت 32؛

}

مرساة الوظيفة (مرساة [] مراسي بيانات الاتصال) خارجية ؛

الحدث مثبت (

مفتاح مفهرس بحجم 32 بايت،

قيمة بايت 32،

عنوان المرسل المفهرس،

طابع زمني uint64

);

سلوك

• يُصدر العقد حدثًا واحدًا مرتبطًا لكل زوج (مفتاح، قيمة).

• يتم تضمين الطابع الزمني الحالي للكتلة في الحدث كحقل منفصل للتسهيل والتدقيق.

• لا يتم تخزين أي حالة في العقد. يتم تسجيل جميع بيانات التثبيت من خلال السجلات فقط.

• العقد لا يتطلب إذناً - يمكن لأي شخص أن يقدم عرضاً.
  

صُممت هذه الفعاليات لتكون قابلة للفهرسة والوصول إليها من خلال:

• المكونات الداخلية، مثل جهاز فهرسة oBridge ومنصة EQTY

• الخدمات الخارجية، بما في ذلك The Graph و Infura أو أدوات التحقق المخصصة
  

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

آلية الرسوم

• يحتاج العملاء إلى استدعاء الدالة approve() لتفعيل التثبيت في عقد ERC20

• يُكلّف كل مرساة مبلغًا قدره $EQTY، ويتم فرضه في دالة anchor()

• يتم قراءة مبلغ الرسوم من عقد تكوين منفصل يخضع لرقابة الحوكمة

• لن يستخدم التثبيت الدالة approve()، بل سيتم حرق الرمز المميز عبر eqtyToken.burnFrom(msg.sender, fee * n)

4. إدارة الرسوم

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

سيخزن عقد تكوين مخصص رسوم التثبيت الحالية. ولا يمكن تحديث هذه القيمة إلا بواسطة عقد حوكمة، وتحديدًا بواسطة نسخة من مُحافظ OpenZeppelin المرتبطة برمز $EQTY. وسيتم التصويت بناءً على أرصدة $EQTY باستخدام منطق ERC20Votes القياسي.

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

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

5. مكتبة الطبقات الخاصة الجديدة

لدعم التثبيت على Base والتوقيع الأصلي للمحفظة، سيتم إنشاء مكتبة TypeScript مستقلة جديدة لمعالجة منطق الطبقة الخاصة - بما في ذلك سلاسل الأحداث، وتوقيع الأحداث، والتثبيت، وهياكل رسائل الترحيل. تحل هذه المكتبة محل مكتبة @ltonetwork/lto-api.js الخاصة بتقنية LTO لجميع حالات استخدام EQTY.

تم تصميم المكتبة الجديدة ليتم استخدامها في كل من بيئات المتصفح (مثل MetaMask و WalletConnect) وأدوات جانب الخادم.

النطاق والمحتويات

سيتم تضمين المكونات ذات الصلة فقط من الطبقة الخاصة لهيئة النقل البري:

• الأحداث/ تتضمن الحدث، وسلسلة الأحداث، ودمج التعارض، ومنطق التسلسل ذي الصلة.

• الرسالة/ تتضمن الرسالة والترحيل، المستخدمة للاتصال المشفر خارج السلسلة.

• يتضمن الكود الداعم فئات مساعدة مثل Binary.
  

لن تعتمد المكتبة على شبكة LTO:

• لا يوجد واجهة برمجة تطبيقات لعقدة LTO

• لا يوجد منطق للمعاملات

• لا توجد أدوات لتوليد أزواج المفاتيح

• لا يوجد ترميز عناوين خاص بشركة LTO
  

سيدعم ذلك التثبيت عبر العقود الذكية على Base، وسيتكامل بسلاسة مع ethers.js لتوقيع وإرسال نقاط التثبيت.

نموذج توقيع الأحداث

سيتم جعل دالة Event.signWith() غير متزامنة لدعم التوقيع عبر المتصفح باستخدام MetaMask أو WalletConnect أو أي مُوقِّع خارجي، بالإضافة إلى التوقيع المباشر باستخدام الإيثرنت. وهي تستخدم واجهة ISigner مجردة.

واجهة ISigner {

sign(data: Uint8Array): Promise<Uint8Array>;

}

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

التكامل المرتكز

تتضمن المكتبة طريقة لإنشاء خرائط مرجعية:

const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();

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

يمكن إجراء عملية التثبيت عن طريق استدعاء العقد الذكي مباشرةً عبر ethers.Contract.anchor(Anchor[]). وهذا يتجنب الاعتماد على أي خدمة خلفية أو بنية تحتية خاصة.

توقيع الرسائل

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

بعد التوقيع، يتم تثبيت تجزئة الرسالة على سلسلة الكتل عبر نفس عقد التثبيت. ويكون التنسيق كالتالي:

• المفتاح = تجزئة الرسالة

• القيمة = 0x0
  

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

النشر والاستخدام

سيتم نشر المكتبة كحزمة NPM منفصلة. وهي مصممة لتكون النواة المشتركة المستخدمة من قبل:

• محفظة EQTY (لتوقيع الأحداث والرسائل)

• خدمة الترحيل (لحساب التجزئة وتحليل الرسائل)

• مجموعة أدوات تطوير البرمجيات الخاصة بـ Ownables (لإنشاء الأحداث وتقديمها)

• أي واجهة أمامية أو أداة تحقق تابعة لجهة خارجية

6. فهرسة oBridge

ستقوم خدمة oBridge باستبدال منطق الفهرسة الحالي القائم على LTO بفهرس جديد يقوم بمعالجة الأحداث المرتبطة الصادرة عن عقد التثبيت الأساسي.

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

• المفتاح: حالة التثبيت أو تجزئة الرسالة

• القيمة: تجزئة الحدث المقابلة أو 0x0

• txHash، وblockNumber، وlogIndex، والمرسل
  

تُعرض هذه السجلات عبر واجهة برمجة تطبيقات HTTP عامة. سيظل هيكل وسلوك واجهة برمجة التطبيقات هذه متوافقين مع مُفهرس التثبيت LTO الحالي، بما في ذلك نقطة النهاية GET /hash/verify، مما يسمح لمكونات EQTY الحالية بالانتقال بأقل قدر من التغييرات.

يؤدي جهاز فهرسة oBridge دورين:

1. باعتبارها تبعية داخلية لخدمة الترحيل، والتي يجب أن تتحقق من تثبيت الرسائل قبل إصدارها.

2. كخدمة تحقق عامة للعملاء الخارجيين والمحافظ الإلكترونية الذين يرغبون في التحقق من حالة التثبيت دون الاستعلام مباشرة من Base.
   

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

7. خدمة الترحيل

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

مصادقة الرسائل باستخدام SIWE

بدلاً من الاعتماد على توقيعات رسائل HTTP أو التحديات المخصصة، سيطبق نظام الترحيل معيار SIWE (EIP-4361). يتيح هذا الأسلوب للمستخدمين المصادقة عن طريق توقيع رسالة نصية عادية باستخدام محفظة إيثيريوم الخاصة بهم، مما ينتج عنه توقيع قابل للاسترداد يربطهم بجلسة.

خطوات تسجيل الدخول:

1. يطلب العميل رسالة SIWE من خادم الترحيل: GET /auth/siwe-message?address=0x...
   

2. يقوم الخادم بإرجاع رسالة SIWE قياسية تتضمن ما يلي:

• النطاق (على سبيل المثال: relay.eqty.network)

• نونسي

• تاريخ انتهاء الصلاحية

• حقل الموارد الاختياري يقتصر على /messages?to=...

• بيان: على سبيل المثال: "سجل الدخول للوصول إلى رسائل EQTY الخاصة بك."
  

1. يقوم العميل بتوقيع الرسالة باستخدام التوقيع الشخصي
   

2. يقوم العميل بإرسال الرسالة الموقعة والتوقيع إلى POST /auth/verify
   

3. يقوم الخادم بالتحقق من التوقيع ويصدر ما يلي:

• رمز وصول JWT (قصير الأجل، على سبيل المثال 15 دقيقة)

• رمز التحديث (طويل الأمد، على سبيل المثال 24 ساعة)
  

يجب أن تتضمن جميع طلبات استرجاع الرسائل اللاحقة (GET /messages?to=...) رمز الوصول في رأس Authorization.

عند انتهاء صلاحية الرمز المميز، يمكن للعميل استخدام رمز التحديث للحصول على رمز وصول جديد دون إعادة التوقيع.

يتوافق هذا النموذج تمامًا مع MetaMask وWalletConnect ومحافظ EIP-1193 الأخرى، ويتبع أنماط الأمان المعتمدة على نطاق واسع. لا يتطلب الأمر أي منطق أو بنية تحتية مخصصة تتجاوز مكتبات SIWE الحالية.

تثبيت الرسائل والتحقق منها

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

يحتفظ جهاز الترحيل بمؤشر خفيف الوزن خاص به لعقد التثبيت في القاعدة. ويستمع إلى أحداث التثبيت ويسجلها.

• المفتاح = تجزئة الرسالة

• القيمة = 0x0

• مرسل

• رقم الكتلة، تجزئة المعاملة، الطابع الزمني
  

للتحقق من صحة الرسالة قبل تسليمها، يقوم جهاز الترحيل بالتحقق مما يلي:

• يوجد حدث مرتبط بمفتاح يساوي messageHash

• القيمة هي بالضبط 0x0 (أي أنها ليست نقطة ارتكاز لسلسلة الأحداث)

• يتطابق المرسل مع مُوقِّع الرسالة (أي عنوان المرسل)
  

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

يقوم جهاز الترحيل بإجراء هذا التحقق باستخدام الفهرس الداخلي الخاص به ولا يعتمد على oBridge.

8. تغييرات العقد القابلة للملكية (CosmWasm)

مع الانتقال بعيدًا عن طبقة LTO 1 وإلغاء التوقيع على الأحداث القائم على المفتاح العام، يجب تحديث عقود Ownable لدعم التفويض القائم على العناوين باستخدام عناوين Ethereum القياسية.

التفويض المستند إلى العنوان

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

يستخدم منطق العقد المحدث info.sender - العنوان الذي وقع على الحدث وقدمه - كهوية موثوقة.

يؤثر هذا على جميع نقاط الدخول التي تتطلب الحصول على ترخيص:

• محاولة التحويل: يجب أن يتطابق عنوان المرسل مع عنوان المالك الحالي

• try_release: يجب أن يتطابق عنوان المرسل مع عنوان المالك المقفل سابقًا

• try_register_lock: يتحقق من أن حقل مالك الحدث يطابق المُوقِّع
  

بدلاً من تحويل المفاتيح العامة إلى عناوين LTO، يقوم العقد ببساطة بتخزين ومقارنة قيم Addr (على سبيل المثال 0xabc123 ...).

CAIP-2 ومطابقة الشبكة

يستمر العقد في التحقق من مصدر الأحداث العابرة للسلاسل باستخدام مُعرّف شبكة CAIP-2. بالنسبة للرسائل المستندة إلى إيثيريوم، يكون نطاق الاسم هو eip155:<chainId>. يتحقق العقد مما يلي:

• تتطابق شبكة الحدث مع الشبكة المتوقعة

• يتطابق حقل المالك في الحدث مع المُوقِّع (info.sender) ضمن مساحة اسم CAIP المحددة
  

يمكن إزالة وظائف التحويل address_lto() و address_eip155()، حيث لم تعد هناك حاجة إلى الترجمة من أو إلى عناوين LTO.

تأثير

هذا التغيير يجعل العقد القابل للتملك:

• متوافق تمامًا مع التوقيع والهوية الأصليين لشبكة إيثيريوم

• بصرف النظر عن البنية التحتية الرئيسية لهيئة النقل البري

• متوافق مع أي سلسلة تدعم الاسترداد القائم على العنوان (مثل EVM)
  

ستصبح الأصول المملوكة الحالية، والتي تعتمد على التوقيع والتثبيت الخاصين بـ LTO، غير قابلة للتحقق بموجب النموذج الجديد ويجب إعادة إصدارها (انظر القسم 11).

9. تحديث حزمة تطوير البرامج (SDK) الخاصة بـ Ownables

يجب تحديث مجموعة أدوات تطوير البرمجيات الخاصة بـ Ownables لتعكس التحول من التوقيع بالمفتاح العام القائم على LTO إلى التفويض القائم على العناوين على غرار Ethereum وتثبيت القاعدة.

تحديثات رئيسية

1. توقيع الفعاليات

• قم بتحديث عملية إنشاء الأحداث لاستخدام مكتبة الطبقة الخاصة الجديدة (@eqty-core/events)

• استخدم تطبيقات ISigner المتوافقة مع MetaMask أو WalletConnect أو التوقيعات القائمة على الإيثرنت

• تأكد من أن الدالة signWith() لم تعد تعتمد على مفتاح عام؛ يتم استخدام العنوان القابل للاسترداد فقط
  

1. التثبيت

• استبدل منطق تثبيت عقدة LTO بتقديم عقد ذكي على Base

• استخدم الدالة getAnchorMap() لجمع أزواج (المفتاح، القيمة) وإرسالها عبر ethers.Contract.anchor()

• تأكد من أن تثبيت الرسالة يستخدم (المفتاح = messageHash، القيمة = 0x0)
  

1. تَحَقّق

• قم بتحديث منطق التحقق لاستخدام واجهة برمجة التطبيقات /hash/verify المتوافقة مع oBridge أو استعلام سجل مباشر

• تأكد من أن قيمة المرساة تطابق تجزئة الحدث المتوقعة وأن المرسل يطابق عنوان إيثيريوم الخاص بالموقّع
  

1. استخدام العنوان

• استبدل أي منطق يقارن أو يُنشئ عناوين LTO

• استخدم عناوين إيثيريوم العادية (0x...) في جميع مراحل تدفق الأحداث والرسائل.

التوافق

يظلّ SDK المُحدّث مُشابهًا من حيث البنية، ولكنه لم يعد مرتبطًا بمكتبة @ltonetwork/lto-api.js أو خدمات عقدة LTO. وهو متوافق مع مكتبة الطبقة الخاصة الجديدة وربط Base، وسيعمل بالتكامل مع عقود Ownable المُحدّثة وخدمة الترحيل.

10. تحديث المحفظة العالمية

يجب تحديث المحفظة العامة لتعكس عملية الانتقال إلى Base وبنية EQTY الجديدة. لم تعد تتفاعل مع عقد LTO.

تحديثات أساسية

1. اتصال المحفظة

• استبدل معالجة أزواج مفاتيح LTO بمكتبة متوافقة مع إيثيريوم (ethers.js)

• استخدم واجهات موفر EIP-1193 لتمكين التوقيع واسترجاع العناوين
  

1. دعم الرموز المميزة

• أضف دعمًا لعرض وإدارة أرصدة رمز $EQTY ERC-20 الجديد على Base

• قم بتضمين بيانات تعريف الرموز، وسجل المعاملات، وتتبع الرصيد عبر نقاط نهاية RPC العامة
  

1. توقيع الفعاليات والرسائل

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

• استخدم التوقيع الشخصي عبر المحفظة المتصلة؛ لم تعد المفاتيح العامة مطلوبة
  

1. التثبيت

• قم بإرسال خرائط نقاط الارتكاز مباشرةً إلى عقد نقاط الارتكاز الأساسي باستخدام مكتبة ethers.js

• معالجة عملية الإرسال والتأكيد على سلسلة الكتل، بالإضافة إلى التعليقات الاختيارية على واجهة المستخدم، لتحديد تكلفة التثبيت بوحدة $EQTY
  

1. تكامل المرحل

• المصادقة عبر SIWE (تسجيل الدخول باستخدام إيثيريوم)

• قم بتخزين وتحديث رموز الوصول حسب الحاجة

• استخدم الطلبات الموثقة لجلب الرسائل المشفرة من خدمة الترحيل

تمت إزالة الميزات

• واجهة مستخدم تأجير LTO

• تحديد العقدة وعرض السلسلة

• إدارة الهوية على سلسلة الكتل المرتبطة بتقنية LTO

11. خطة الهجرة

مع إيقاف دعم طبقة LTO 1 وإدخال نظام تثبيت جديد على Base، يجب نقل جميع المكونات الأساسية للبروتوكول. ولن تكون البيانات القديمة المرتبطة ببنية LTO التحتية - بما في ذلك نقاط التثبيت وسلاسل الأحداث والرسائل - صالحة بعد الآن.

ما يصبح غير صالح

• لا يمكن التحقق من سلاسل الأحداث الموقعة باستخدام أزواج مفاتيح LTO، حيث لم يعد من الممكن استخراج المفتاح العام من التوقيعات القائمة على Ethereum.

• لا يمكن الوثوق بالبيانات المسجلة على LTO L1 أو الاستعلام عنها في المستقبل.

• يجب استبدال العناصر المملوكة المرتبطة بهويات قائمة على تقنية LTO أو سلاسل متصلة.

• سيتم رفض الرسائل غير المرتبطة بالقاعدة من قبل خدمة الترحيل.

الإجراءات المطلوبة

1. ترحيل الرموز المميزةيجب على المستخدمين استبدال رموز LTO الخاصة بهم بـ $EQTY يدويًا باستخدام الجسر. لا يمكن سكّ الرموز إلا حتى ارتفاع كتلة محدد على الشبكة الأساسية. بعد هذه الكتلة، سيتم إيقاف الجسر وتعطيل وظيفة سكّ الرموز نهائيًا. تصبح رموز LTO غير المستبدلة عديمة القيمة.
   

2. إعادة إصدار أصول مملوكة.يجب على الجهات المصدرة للأوراق المالية القابلة للتملك إصدار أوراق مالية جديدة مرتبطة بشبكة BASE. ستتبع ذلك تعليمات حول كيفية استبدال الأوراق المالية القديمة بالأوراق المالية الجديدة.
   

3. عملية نقل المحفظة: سيحتاج المستخدمون إلى تحديث المحفظة العالمية.

لا توجد لقطة شاشة

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