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

خلفية

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

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

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

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

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

لماذا يجب إلغاء LTO Layer 1

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

  • يملك LTO حاليًا قيمة سوقية أقل من $5M، مع رهن/تكديس فقط نحو ~20% من الرموز.

  • وهذا يعني أن ميزانية الأمان الفعلية (أي إجمالي القيمة التي تؤمّن الإجماع) هي < $1M.

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

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

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

  • لم تعد العقد المجتمعية قابلة للتطبيق اقتصاديًا.

  • قد يؤدي إيقاف خدمة العقد إلى مجموعة صغيرة من العقد التي تمتلك تحكمًا غير متناسب في آلية الإجماع.

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

3. احتكاك التبني

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

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

  • فكرة “التثبيت على Layer 1 بقيمة 5M دولار” تُضعف الثقة في البنية التحتية الأساسية لـ EQTY.

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

  • إذا تعطّل حتى عدد قليل من مدققي (validators) رئيسيين، سيصبح LTO غير مستقر أو سيتوقف بالكامل.

  • تضيف الصيانة المستمرة (المستكشفات، الفهارس، بنية العقد) عبئًا مع قيمة متناقصة.

لماذا تعد طبقة التثبيت في Base هي الخيار الصحيح

تقدم Base:

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

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

  • دعم أدوات واسع (MetaMask, WalletConnect, The Graph, إلخ.)

  • رسوم شبه منعدمة مع حسم سريع

  • مواءمة قوية مع طبقة أصول وسيولة EQTY، والتي تعيش أيضًا على Base

يزيل التثبيت على Base عبء الحفاظ على Layer 1 مخصص مع زيادة قابلية التدقيق، وقابلية التركيب (composability)، والثقة.

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

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

  • تقديم Layer 1 مقابل تكلفة عالية يوفر ميزة استراتيجية محدودة.

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

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

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

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

عقد الرمز (token contract) مصمم ليكون بسيطًا للغاية. يتبع واجهة ERC-20 القياسية، دون منطق نقل خاص أو ميزات airdrop أو جداول vesting.

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

3. عقد Anchor على Base

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

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

  • لسلاسل الأحداث: key = stateHash, value = eventHash

  • للرسائل: key = messageHash, value = 0x0

الواجهة

struct Anchor {

bytes32 key;

قيمة bytes32;

}

function anchor(Anchor[] calldata anchors) external;

event Anchored(

bytes32 indexed key,

قيمة bytes32،

address indexed sender،

uint64 timestamp

) ;

السلوك

  • يقوم العقد بإصدار حدث Anchored واحد لكل زوج (key, value).

  • يتم تضمين block.timestamp الحالي في الحدث كحقل منفصل للراحة وقابلية التدقيق.

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

  • العقد لا يتطلب صلاحيات — يمكن لأي شخص تثبيت (anchor).

تم تصميم هذه الأحداث لتكون قابلة للفهرسة والوصول من خلال:

  • المكونات الداخلية، مثل oBridge indexer ومنصة EQTY

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

من خلال إبقاء التثبيت بلا حالة (stateless) وإصدار أحداث كاملة، تضمن هذه البنية أن التثبيت قابل للتحقق وفعّال وغير معتمد على البنية التحتية.

آلية الرسوم

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

  • يترتب على كل anchor حرق $EQTY، ويتم فرض ذلك في دالة anchor()

  • يتم قراءة مبلغ الرسوم من عقد إعدادات مستقل يتحكم به نظام حوكمة

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

4. حوكمة الرسوم

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

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

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

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

5. مكتبة Private Layer جديدة

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

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

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

سيتم تضمين المكونات ذات الصلة فقط من LTO private layer:

  • events/ يتضمن Event وEventChain وMergeConflict ومنطق التسلسل المرتبط.

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

  • يدعم الكود البرمجي أدوات مساعدة مثل Binary.

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

  • لا توجد واجهة API لعقد LTO

  • لا منطق للمعاملات

  • لا توجد أدوات لإنشاء أزواج مفاتيح

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

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

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

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

interface ISigner {

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

}

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

تكامل التثبيت

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

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

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

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

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

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

بعد التوقيع، يتم تثبيت message hash على السلسلة عبر نفس عقد Anchor. يكون التنسيق:

  • key = messageHash

  • value = 0x0

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

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

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

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

  • خدمة relay (لحساب الـ hash وتحليل الرسائل)

  • Ownables SDK (لإنشاء الأحداث والإرسال)

  • أي واجهة أمامية (frontend) تابعة لجهة ثالثة أو مُحقق

6. فهرسة oBridge

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

يستمع هذا المفهرس إلى سجلات التثبيت على Base ويحتفظ بقاعدة بيانات محلية لأحدث تثبيت لكل مفتاح (key)، وقد يمثل ذلك إمّا حالة سلسلة أحداث أو قيمة message hash لرسالة relay. يحتوي كل إدخال على:

  • key: حالة التثبيت المرسية أو message hash

  • value: hash الحدث الموافق أو 0x0

  • txHash, blockNumber, logIndex, و sender

يتم كشف هذه السجلات عبر واجهة برمجة تطبيقات HTTP عامة. سيبقى هيكل وسلوك هذه الـ API متوافقًا مع فهرسة تثبيت LTO الحالية، بما في ذلك نقطة GET /hash/verify، مما يسمح لمكونات EQTY الحالية بالانتقال مع تغييرات محدودة جدًا.

يقوم مُفهرس oBridge بأدوار اثنين:

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

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

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

7. خدمة Relay

يتولى Relay service التسليم الآمن للرسائل المشفرة بين الأطراف. لضمان أن الرسائل أصلية، ومؤرخة زمنيًا، ومتحكم في الوصول إليها، سيتم تحديث الخدمة لدعم التحقق من التثبيت على السلسلة (on-chain) والتحقق المصادق عليه حديثًا باستخدام المصادقة الأصلية للمحفظة عبر Sign-In with Ethereum (SIWE).

مصادقة الرسالة عبر SIWE

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

تدفق تسجيل الدخول:

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

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

  • المجال (مثلاً relay.eqty.network)

  • Nonce

  • طابع انتهاء الصلاحية الزمني

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

  • العبارة: مثل “Sign in to access your EQTY messages.”

  1. يُوقِّع العميل الرسالة باستخدام personal_sign

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

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

  • رمز وصول JWT (قصير العمر، مثل 15 دقيقة)

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

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

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

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

تثبيت الرسالة والتحقق

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

يحتفظ relay بفهرس (indexer) خفيف خاص به لعقد التثبيت على Base. يستمع إلى أحداث Anchored ويسجل:

  • key = messageHash

  • value = 0x0

  • sender

  • blockNumber, txHash, timestamp

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

  • يوجد حدث Anchored بمفتاح = messageHash

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

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

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

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

8. تغييرات عقد Ownable (CosmWasm)

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

تفويض قائم على العناوين

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

منطق العقد المُحدَّث يستخدم info.sender — وهو العنوان الذي وقّع وأرسل الحدث — كهوية مرجعية.

هذا يؤثر على جميع نقاط الدخول التي يلزم فيها التفويض:

  • try_transfer: يجب أن يطابق sender عنوان المالك الحالي

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

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

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

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

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

  • يطابق event.network الشبكة المتوقعة

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

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

الأثر

يُحدث هذا التغيير عقد Ownable:

  • متوافق بالكامل مع التوقيع والهوية الأصلية في Ethereum

  • مستقل عن بنية مفاتيح LTO

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

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

9. تحديث Ownables SDK

يجب تحديث Ownables SDK ليعكس التحول من توقيع مفاتيح عامة قائم على LTO إلى تفويض قائم على عناوين بنمط Ethereum مع تثبيت على Base.

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

  1. توقيع الحدث

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

  • استخدم تطبيقات ISigner المتوافقة مع MetaMask أو WalletConnect أو المُوقِّعات المبنية على ethers

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

  1. التثبيت (Anchoring)

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

  • استخدم getAnchorMap() لجمع (key, value) وأرسلها عبر ethers.Contract.anchor()

  • تأكد أن تثبيت الرسالة يستخدم (key = messageHash, value = 0x0)

  1. التحقق

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

  • أكد أن قيمة anchor تطابق event hash المتوقعة وأن المرسل يطابق عنوان Ethereum للموقِّع

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

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

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

التوافق

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

10. تحديث Universal Wallet

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

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

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

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

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

  1. دعم الرموز

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

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

  1. توقيع الأحداث والرسائل

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

  • استخدم personal_sign عبر المحفظة المتصلة؛ لم تعد هناك حاجة إلى مفاتيح عامة

  1. التثبيت (Anchoring)

  • ارسل خرائط anchor مباشرةً إلى عقد anchor في Base باستخدام ethers.js

  • تولّي إرسال التثبيت على السلسلة والتأكيد وإرجاع ملاحظات واجهة مستخدم اختيارية بشأن تكلفة التثبيت في $EQTY

  1. تكامل Relay

  • مصادقة عبر SIWE (Sign-In with Ethereum)

  • خزن وحدّث رموز الوصول عند الحاجة

  • استخدم طلبات مُصادق عليها لجلب الرسائل المشفرة من خدمة relay

الميزات المُزالة

  • واجهة تأجير LTO

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

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

11. خطة الهجرة

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

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

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

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

  • يجب استبدال Ownables المرتبطة بهويات معتمدة على LTO أو سلاسل مُثبتة على LTO.

  • سيتم رفض الرسائل غير المثبتة على Base بواسطة خدمة relay.

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

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

  2. إعادة إصدار Ownables Asset. يجب على مُصدري Ownable إصدار Ownables جديدة مرتبطة بشبكة BASE. ستتبع التعليمات كيفية تبديل Ownables القديمة إلى Ownables جديدة

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

لا يوجد Snapshot

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

#ETH