1. Kirish va asoslar
Kontekst
EQTY platformasi ikki qatlamli arxitekturaga asoslangan:
Tekshirilishi mumkin bo‘lgan hodisalar zanjirlarini (masalan, Ownables, xabarlar) boshqarish uchun xususiy qatlam
Ushbu hodisalar zanjirlariga o‘zgarmas blokcheynda vaqt tamg‘asini qo‘yish va ularni tekshirish uchun ommaviy anchoring qatlami
Tarixan ushbu ommaviy qatlamni anchoring uchun optimallashtirilgan, Proof-of-Stake konsensusiga asoslangan maxsus blokcheyn — LTO Network Layer 1 ta’minlab kelgan.
Biroq, faoliyat yuritish sharoitlari sezilarli darajada o‘zgardi.
Nima uchun LTO Layer 1’dan foydalanish to‘xtatilishi kerak
1. Iqtisodiy xavfsizlik izdan chiqdi
Hozirda LTO’ning bozor qiymati $5M’dan kam, tokenlarning esa atigi ~20% qismi steyking qilingan.
Bu samarali xavfsizlik budjeti (ya’ni, konsensusni himoyalovchi jami qiymat) < $1M ekanini anglatadi.
Bu darajalarda zararli subyekt uchun konsensusni buzish, anchoring tranzaksiyalarini senzura qilish yoki tarixni qayta yozish moliyaviy jihatdan amalga oshirsa bo‘ladigan ishdir.
Yuridik kuchga ega aktivlar qaydlarini anchorlaydigan EQTY kabi platforma uchun bu qabul qilib bo‘lmaydi.
2. Validatorlarning markazlashuvi va rag‘batlarning pastligi
Hamjamiyat tugunlarini saqlash endi iqtisodiy jihatdan maqsadga muvofiq emas.
Tugunlar xizmat ko‘rsatishni to‘xtatsa, oz sonli tugunlar konsensus ustidan nomutanosib darajada katta nazoratga ega bo‘lishi mumkin.
Bu anchoring ta’minlashi kerak bo‘lgan markazsizlashtirish kafolatlariga putur yetkazadi.
3. Joriy etishdagi to‘siqlar
Savdo yoki audit muhokamalarida LTO’ni xavfsiz anchoring qatlami sifatida oqlash tobora qiyinlashmoqda.
Mijozlar va hamkorlar EQTY keng qo‘llanadigan va ishonchli ommaviy tarmoqlarda (masalan, Ethereum, Base) anchorlashini kutishadi.
“$5M qiymatli Layer 1’da anchorlash” degan tasavvur EQTY’ning asosiy infratuzilmasiga bo‘lgan ishonchni susaytiradi.
4. Infratuzilmaning zaifligi
Agar bir nechta muhim validator oflayn bo‘lsa ham, LTO beqarorlashadi yoki butunlay to‘xtaydi.
Explorerlar, indeksatorlar va tugun infratuzilmasiga doimiy xizmat ko‘rsatish qiymati kamayib borayotgan holda ortiqcha yuk keltiradi.
Nima uchun anchoring qatlami sifatida Base to‘g‘ri tanlov
Base quyidagilarni taklif etadi:
EVM bilan to‘liq muvofiqlik
Ethereum’dan meros bo‘lib o‘tgan iqtisodiy va texnik xavfsizlik
Keng vositalar qo‘llab-quvvatlovi (MetaMask, WalletConnect, The Graph va boshqalar)
Deyarli nol komissiya va tez yakunlanish
EQTY’ning Base’da joylashgan aktivlar va likvidlik qatlami bilan chambarchas bog‘liqlik
Anchoringni Base’ga ko‘chirish maxsus Layer 1’ni saqlash yukini kamaytirib, audit qilish imkoniyati, kompozitsiyalanish va ishonchlilikni oshiradi.
Strategik asos
EQTY’ning qiymati konsensusda emas — u xususiy qatlamida, aktivlar modelida va muvofiqlik arxitekturasida.
Layer 1’ni saqlash katta xarajat evaziga juda kam strategik ustunlik beradi.
Base’ga o‘tish EQTY’ga Layer 1 infratuzilmasi yukini ko‘tarmasdan, butun diqqatini mahsulotni ommalashtirish, huquqiy integratsiya va aktivlarni tokenlashtirishga qaratish imkonini beradi.
2. Yangi $EQTY ERC-20 tokeni
EQTY platformasi Base tarmog‘ida joylashtiriladigan yangi ERC-20 tokeni — $EQTY’ni joriy qiladi. Bu token LTO tokenining o‘rnini egallaydi va anchoring hamda boshqaruv kabi protokol amallari uchun mahalliy valyuta vazifasini bajaradi.
Token kontraktidagi dastlabki ta’minot nolga teng. Cheklangan migratsiya davrida foydalanuvchilar LTO tokenlarini almashtirganda $EQTY talabga ko‘ra zarb qilinadi. Bu muddat zanjirda cheklangan: oldindan belgilangan blok balandligidan so‘ng zarb qilish funksiyasi butunlay o‘chiriladi. Ushbu muddat tugashidan oldin almashtirilmagan LTO tokenlari EQTY ekotizimiga kiritilmaydi va yakuniy $EQTY ta’minoti dastlabki LTO ta’minotidan kam bo‘ladi.
Token kontrakti ataylab minimal darajada yaratilgan. U standart ERC-20 interfeysiga amal qiladi; unda maxsus o‘tkazish mantig‘i, airdrop funksiyalari yoki vesting jadvallari yo‘q.
$EQTY tokeni anchoring komissiyalarini to‘lash, protokol boshqaruvida qatnashish va platforma rivojlanishi davomida qo‘shimcha foydali vazifalarni bajarish uchun ishlatiladi. Foydalanish uchun tokenlar yoqiladi va umumiy ta’minot kamayadi.
3. Base’dagi anchor kontrakti
Anchoring Base tarmog‘ida joylashtirilgan yengil smart-kontrakt orqali amalga oshiriladi. Bu kontrakt hodisalar zanjiri yoki xabarlari xeshlarini ommaviy qayd etuvchi hodisalarni chiqaradi, ammo zanjirda hech qanday holatni saqlamaydi.
Har bir anchor kalitni qiymatga bog‘laydi. Bunda:
Hodisalar zanjiri uchun: key = stateHash, value = eventHash
Xabarlar uchun: key = messageHash, value = 0x0
Interfeys
struct Anchor {
bytes32 key;
bytes32 value;
}
function anchor(Anchor[] calldata anchors) external;
event Anchored(
bytes32 indexed key,
bytes32 qiymat,
address indexed sender,
uint64 timestamp
);
Xatti-harakat
Kontrakt har bir (key, value) juftligi uchun bittadan Anchored hodisasini chiqaradi.
Joriy block.timestamp qulaylik va audit uchun hodisaga alohida maydon sifatida kiritiladi.
Kontraktda hech qanday holat saqlanmaydi. Barcha anchoring ma’lumotlari faqat loglar orqali qayd etiladi.
Kontrakt ruxsatsiz ishlaydi — istalgan kishi anchor yaratishi mumkin.
Bu hodisalar quyidagilar tomonidan indekslanishi va ulardan foydalanilishi uchun mo‘ljallangan:
Ichki komponentlar, masalan, oBridge indeksatori va EQTY platformasi
Tashqi xizmatlar, jumladan The Graph, Infura yoki maxsus tekshiruvchilar
Anchoringni holatsiz saqlash va to‘liq hodisalarni chiqarish orqali ushbu dizayn anchoringni tekshirish mumkin, samarali va infratuzilmadan mustaqil bo‘lishini ta’minlaydi.
Komissiya mexanizmi
Mijozlar anchoringni yoqish uchun ERC20 kontraktida approve() chaqirishi kerak
Har bir anchor uchun $EQTY yoqiladi; bu anchor() funksiyasida ta’minlanadi
Komissiya miqdori boshqaruv nazoratidagi alohida konfiguratsiya kontraktidan olinadi
Anchoringda approve() ishlatilmaydi; uning o‘rniga eqtyToken.burnFrom(msg.sender, fee * n) orqali tokenlar yoqiladi
4. Komissiyalarni boshqarish
Anchoringni iqtisodiy jihatdan barqaror va vaqt o‘tishi bilan adolatli saqlash uchun har bir anchor uchun $EQTY’da to‘lanadigan komissiyani o‘zgartirish imkoniyati bo‘lishi kerak. Komissiyani oldindan qat’iy belgilash yoki narx orakullariga tayanish o‘rniga, EQTY ushbu parametrni shaffof va markazsiz tarzda boshqarish uchun zanjirdagi boshqaruv modelidan foydalanadi.
Maxsus konfiguratsiya kontrakti joriy anchoring komissiyasini saqlaydi. Bu qiymatni faqat boshqaruv kontrakti — xususan, $EQTY tokeniga bog‘langan OpenZeppelin Governor nusxasi — yangilashi mumkin. Ovozlar standart ERC20Votes mantig‘i asosida $EQTY qoldiqlariga qarab beriladi.
Anchoring kontrakti anchor() chaqirilgan har safar konfiguratsiya kontraktidan joriy komissiyani o‘qiydi. Keyin tegishli miqdordagi $EQTY’ni yuboruvchining balansidan bevosita yoqadi. Bu usul approve() tranzaksiyalariga bo‘lgan ehtiyojni yo‘q qiladi hamda komissiyani qo‘llashdan tashqari anchoring kontraktini yengil va holatsiz saqlaydi.
Boshqaruv modeli hamjamiyatga bozor sharoitlari, token narxidagi o‘zgarishlar yoki anchoring talabiga javoban, tashqi ma’lumot manbalari yoki markazlashgan boshqaruvga tayanmasdan, vaqt o‘tishi bilan komissiyalarni o‘zgartirish imkonini beradi.
5. Yangi xususiy qatlam kutubxonasi
Base’da anchoring va hamyon orqali imzolashni qo‘llab-quvvatlash uchun xususiy qatlam mantig‘ini — jumladan hodisalar zanjiri, hodisalarni imzolash, anchoring va relay xabarlari tuzilmalarini — boshqaradigan mustaqil TypeScript kutubxonasi yaratiladi. Bu kutubxona EQTY’ning barcha holatlarida LTO’ga xos @ltonetwork/lto-api.js o‘rnini egallaydi.
Yangi kutubxona brauzer muhitlarida (masalan, MetaMask, WalletConnect) ham, server tomonidagi vositalarda ham ishlatish uchun mo‘ljallangan.
Qamrov va tarkib
LTO xususiy qatlamining faqat tegishli qismlari kiritiladi:
events/ Event, EventChain, MergeConflict va tegishli serializatsiya mantig‘ini o‘z ichiga oladi.
message/ Zanjirdan tashqarida shifrlangan aloqa uchun ishlatiladigan Message va Relay’ni o‘z ichiga oladi.
Yordamchi kod Binary kabi yordamchi klasslarni o‘z ichiga oladi.
Kutubxona LTO Network’ga bog‘liq bo‘lmaydi:
LTO tugun API’si yo‘q
Tranzaksiya mantig‘i yo‘q
Kalit juftliklarini yaratish vositalari yo‘q
LTO’ga xos manzil kodlashi yo‘q
U Base’dagi smart-kontraktlar orqali anchoringni qo‘llab-quvvatlaydi hamda anchorlarni imzolash va yuborish uchun ethers.js bilan muammosiz integratsiyalanadi.
Hodisalarni imzolash modeli
Event.signWith() metodi MetaMask, WalletConnect yoki har qanday tashqi imzolagich orqali brauzerda imzolashni qo‘llab-quvvatlash, shuningdek ethers bilan bevosita imzolash imkonini berish uchun asinxron qilinadi. U mavhum ISigner interfeysidan foydalanadi:
interface ISigner {
sign(data: Uint8Array): Promise<Uint8Array>;
}
Imzolangan hodisa uchun endi ochiq kalit talab qilinmaydi; unda faqat imzo va undan hosil qilingan manzil bo‘ladi. Bu Ethereum imzolash jarayonlari (personal_sign) bilan muvofiqlikni ta’minlaydi va aksariyat hamyon muhitlarida imkonsiz bo‘lgan ochiq kalitni ajratib olish zaruratini yo‘q qiladi.
Anchoring integratsiyasi
Kutubxonada anchor xaritalarini yaratish usuli mavjud:
const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();
Har bir anchor stateHash’ni (key) oxirgi eventHash’ga (value) bog‘laydi va Base smart-kontraktiga yuborishga tayyor bo‘ladi. Relay xabarlari uchun xabar xeshining o‘zi anchor kaliti sifatida ishlatiladi, qiymat esa nolga (0x0) teng qilib belgilanadi.
Anchoringni ethers.Contract.anchor(Anchor[]) orqali smart-kontraktga bevosita murojaat qilib bajarish mumkin. Bu har qanday backend xizmati yoki xususiy infratuzilmaga bog‘liqlikni bartaraf etadi.
Xabarlarni imzolash
Kutubxonada zanjirdan tashqaridagi aloqa uchun Message va Relay klasslari ham mavjud. Hodisalardagi kabi, xabarlar ISigner interfeysi yordamida asinxron imzolanadi. Imzolar xabar xeshi ustidan qo‘yiladi va ochiq kalit kiritilmaydi — tekshirish uchun faqat undan hosil qilingan manzildan foydalaniladi.
Imzolangandan keyin xabar xeshi ayni Anchor kontrakti orqali zanjirga anchorlanadi. Formati quyidagicha:
key = messageHash
value = 0x0
Bu zanjirdan tashqaridagi xabarlarni mazmunini oshkor qilmasdan, ommaviy tarzda vaqt tamg‘asi bilan belgilash va tekshirish imkonini beradi. Anchoringni yuboruvchi yoki relay xizmati amalga oshirishi mumkin.
Joylashtirish va foydalanish
Kutubxona alohida NPM paketi sifatida nashr etiladi. U quyidagilar foydalanadigan umumiy yadro bo‘lishi ko‘zda tutilgan:
EQTY hamyoni (hodisa va xabarlarni imzolash uchun)
Relay xizmati (xeshni hisoblash va xabarni tahlil qilish uchun)
Ownables SDK (hodisalarni yaratish va yuborish uchun)
Har qanday uchinchi tomon frontend’i yoki tekshiruvchisi
6. oBridge indeksatsiyasi
oBridge xizmati amaldagi LTO asosidagi indeksatsiya mantig‘ini Base anchoring kontrakti chiqaradigan Anchored hodisalarini qayta ishlovchi yangi indeksator bilan almashtiradi.
Bu indeksator Base’dagi anchoring loglarini tinglaydi va har bir kalit uchun eng so‘nggi anchorning mahalliy ma’lumotlar bazasini yuritadi. U hodisalar zanjirining holatini yoki relay xabarining xeshini ifodalashi mumkin. Har bir yozuv quyidagilarni o‘z ichiga oladi:
key: anchorlangan holat yoki xabar xeshi
value: tegishli hodisa xeshi yoki 0x0
txHash, blockNumber, logIndex va sender
Bu qaydlar ommaviy HTTP API orqali taqdim etiladi. Ushbu API tuzilishi va xatti-harakati amaldagi LTO anchoring indeksatori bilan, jumladan GET /hash/verify endpointi bilan muvofiqligicha qoladi. Bu mavjud EQTY komponentlarining juda oz o‘zgarish bilan o‘tishiga imkon beradi.
oBridge indeksatori ikki vazifani bajaradi:
Relay xizmatining ichki bog‘liqligi sifatida; u xabarlarni yuborishdan oldin ularning anchorlanganini tekshirishi kerak.
Base’ga bevosita so‘rov yubormasdan anchoring holatini tekshirmoqchi bo‘lgan tashqi mijozlar va hamyonlar uchun ommaviy tekshiruv xizmati sifatida.
Barcha ma’lumotlarni zanjirda tekshirish mumkin bo‘lib qoladi; mijozlar xohlasa, eth_getLogs yoki o‘z indeksatoridan foydalanib oBridge’ni chetlab o‘tishi mumkin.
7. Relay xizmati
Relay xizmati tomonlar o‘rtasida shifrlangan xabarlarni xavfsiz yetkazib beradi. Xabarlarning haqiqiyligi, vaqt tamg‘asi va kirish nazorati ta’minlanishi uchun xizmat zanjirda anchoringni tekshirish hamda Sign-In with Ethereum (SIWE) yordamida hamyon orqali autentifikatsiyani qo‘llab-quvvatlaydigan tarzda yangilanadi.
SIWE yordamida xabarlarni autentifikatsiya qilish
HTTP xabar imzolari yoki maxsus tekshiruvlardan foydalanish o‘rniga, relay SIWE standartini (EIP-4361) joriy qiladi. Bu usul foydalanuvchilarga Ethereum hamyoni bilan standart matnli xabarni imzolash orqali autentifikatsiyadan o‘tish imkonini beradi; natijada ularni sessiyaga bog‘laydigan va tiklash mumkin bo‘lgan imzo yaratiladi.
Kirish jarayoni:
Mijoz relay backendidan SIWE xabarini so‘raydi: GET /auth/siwe-message?address=0x...
Server standart SIWE xabarini qaytaradi. Unda quyidagilar bo‘ladi:
Domen (masalan, relay.eqty.network)
Nonce
Tugash vaqti tamg‘asi
Ixtiyoriy resources maydoni /messages?to=... bilan cheklangan
Bayonot: masalan, “EQTY xabarlaringizga kirish uchun tizimga kiring.”
Mijoz xabarni personal_sign yordamida imzolaydi
Mijoz imzolangan xabar va imzoni POST /auth/verify manziliga yuboradi
Server imzoni tekshiradi va quyidagilarni beradi:
JWT kirish tokeni (qisqa muddatli, masalan, 15 daqiqa)
Yangilash tokeni (uzoqroq muddatli, masalan, 24 soat)
Xabarlarni olish uchun keyingi barcha so‘rovlar (GET /messages?to=...) Authorization sarlavhasida kirish tokenini o‘z ichiga olishi shart.
Token muddati tugaganda, mijoz qayta imzolamasdan yangi kirish tokenini olish uchun yangilash tokenidan foydalanishi mumkin.
Bu model MetaMask, WalletConnect va boshqa EIP-1193 hamyonlari bilan to‘liq mos keladi hamda keng qo‘llanadigan xavfsizlik tamoyillariga amal qiladi. Mavjud SIWE kutubxonalaridan tashqari maxsus mantiq yoki infratuzilma talab qilinmaydi.
Xabarlarni anchorlash va tekshirish
Autentifikatsiyaga qo‘shimcha ravishda, relay xizmati har bir xabarni yetkazishdan oldin uning zanjirda anchorlanganini tekshiradi. Anchoring o‘zgarmaslik va vaqt tamg‘asini ta’minlaydi hamda spam yoki takroriy hujumlarning oldini oladi.
Relay Base’dagi anchoring kontrakti uchun o‘zining yengil indeksatorini yuritadi. U Anchored hodisalarini tinglab, quyidagilarni qayd etadi:
key = messageHash
value = 0x0
yuboruvchi
blockNumber, txHash, timestamp
Xabarni yetkazishdan oldin tekshirish uchun relay quyidagilarni tekshiradi:
key = messageHash bo‘lgan Anchored hodisasi mavjud
Qiymat aynan 0x0 (ya’ni, hodisalar zanjiri anchori emas)
Yuboruvchi xabarni imzolagan shaxsga mos keladi (ya’ni from manzili)
Xabar faqat anchoring muvaffaqiyatli bajarilgandan keyin oluvchiga yetkaziladi. Bu barcha xabarlarni ommaviy tekshirish, Base’da vaqt tamg‘asi bilan belgilash va to‘g‘ri identifikator tomonidan anchorlash imkonini beradi.
Relay bu tekshiruvni o‘zining ichki indeksatori yordamida bajaradi va oBridge’ga tayanmaydi.
8. Ownable kontrakti o‘zgarishlari (CosmWasm)
LTO Layer 1’dan voz kechish va ochiq kalit asosidagi hodisa imzolashni bekor qilish sababli, Ownable kontraktlari standart Ethereum manzillaridan foydalangan holda manzilga asoslangan avtorizatsiyani qo‘llab-quvvatlaydigan qilib yangilanishi kerak.
Manzilga asoslangan avtorizatsiya
Avval egalik huquqi imzolangan hodisalardan ajratib olingan ochiq kalitlarni tiklash va taqqoslash orqali tekshirilardi. Ethereum hamyonlari ochiq kalitlarni oshkor qilmagani, imzolar esa endi personal_sign yordamida yaratilgani (manzilni tiklash mumkin) sababli, tekshirish modeli manzillarni bevosita taqqoslashga o‘tishi kerak.
Yangilangan kontrakt mantig‘i info.sender’dan — hodisani imzolagan va yuborgan manzildan — ishonchli identifikator sifatida foydalanadi.
Bu avtorizatsiya talab qilinadigan barcha kirish nuqtalariga ta’sir qiladi:
try_transfer: yuboruvchi joriy egasining manziliga mos kelishi kerak
try_release: yuboruvchi avval bloklangan egasining manziliga mos kelishi kerak
try_register_lock: hodisaning owner maydoni imzolovchiga mos kelishini tekshiradi
Ochiq kalitlarni LTO manzillariga aylantirish o‘rniga, kontrakt shunchaki Addr qiymatlarini (masalan, 0xabc123...) saqlaydi va taqqoslaydi.
CAIP-2 va tarmoq mosligi
Kontrakt CAIP-2 tarmoq identifikatoridan foydalanib, zanjirlararo hodisalarning kelib chiqishini tekshirishda davom etadi. Ethereum asosidagi xabarlar uchun namespace eip155:<chainId> hisoblanadi. Kontrakt quyidagilarni tekshiradi:
event.network kutilgan tarmoqqa mos keladi
Hodisadagi owner maydoni berilgan CAIP namespace doirasida imzolovchiga (info.sender) mos keladi
Endi LTO manzillariga aylantirish kerak bo‘lmagani uchun address_lto() va address_eip155() konversiya funksiyalarini olib tashlash mumkin.
Ta’siri
Bu o‘zgarish Ownable kontraktini quyidagicha qiladi:
Ethereum’ning mahalliy imzolash va identifikatsiya tizimlari bilan to‘liq muvofiq
LTO kalit infratuzilmasidan mustaqil
Manzil asosida tiklashni qo‘llab-quvvatlaydigan har qanday zanjir bilan mos (masalan, EVM)
LTO’ga xos imzolash va anchoringga tayangan mavjud Ownable’larni yangi model bo‘yicha tekshirib bo‘lmaydi va ularni qayta chiqarish kerak (11-bo‘limga qarang).
9. Ownables SDK yangilanishi
Ownables SDK’ni LTO asosidagi ochiq kalit bilan imzolashdan Ethereum uslubidagi manzilga asoslangan avtorizatsiya va Base’da anchoringga o‘tishni aks ettiradigan tarzda yangilash kerak.
Asosiy yangilanishlar
Hodisalarni imzolash
Hodisa yaratishni yangi xususiy qatlam kutubxonasi (@eqty-core/events) bilan ishlaydigan qilib yangilang
MetaMask, WalletConnect yoki ethers asosidagi imzolagichlarga mos ISigner implementatsiyalaridan foydalaning
signWith() endi ochiq kalitga tayanmasligini ta’minlang; faqat tiklanadigan manzildan foydalaniladi
Anchoring
LTO tugunlari orqali anchoring mantig‘ini Base’da smart-kontraktga yuborish bilan almashtiring
(key, value) juftliklarini to‘plash va ethers.Contract.anchor() orqali yuborish uchun getAnchorMap() dan foydalaning
Xabarlarni anchorlashda (key = messageHash, value = 0x0) ishlatilishini ta’minlang
Tekshirish
Tekshirish mantig‘ini oBridge bilan mos /hash/verify API’si yoki loglarni bevosita so‘rashdan foydalanadigan qilib yangilang
Anchor qiymati kutilgan hodisa xeshiga, yuboruvchi esa imzolovchining Ethereum manziliga mos kelishini tasdiqlang
Manzillardan foydalanish
LTO manzillarini taqqoslaydigan yoki yaratadigan har qanday mantiqni almashtiring
Hodisa va xabarlar oqimida oddiy Ethereum manzillaridan (0x...) foydalaning
Muvofiqlik
Yangilangan SDK tuzilish jihatidan o‘xshashligicha qoladi, ammo endi @ltonetwork/lto-api.js kutubxonasiga yoki LTO tugun xizmatlariga bog‘liq bo‘lmaydi. U yangi xususiy qatlam kutubxonasi va Base anchoring bilan mos keladi hamda yangilangan Ownable kontraktlari va relay xizmati bilan hamkorlikda ishlaydi.
10. Universal Wallet yangilanishi
Universal hamyon Base’ga va yangi EQTY arxitekturasiga o‘tishni aks ettiradigan tarzda yangilanishi kerak. U endi LTO tugunlari bilan ishlamaydi.
Asosiy yangilanishlar
Hamyonni ulash
LTO kalit juftliklarini boshqarishni Ethereum bilan mos kutubxonaga (ethers.js) almashtiring
Imzolash va manzillarni olish uchun EIP-1193 provayder interfeyslaridan foydalaning
Tokenni qo‘llab-quvvatlash
Base’dagi yangi $EQTY ERC-20 tokenining qoldiqlarini ko‘rsatish va boshqarishni qo‘llab-quvvatlang
Ommaviy RPC endpointlari orqali token metama’lumotlari, tarix va qoldiqlar kuzatuvini kiriting
Hodisa va xabarlarni imzolash
Foydalanuvchilarga hodisalar zanjiri va xabarlarini yaratish hamda imzolash imkonini berish uchun yangi xususiy qatlam kutubxonasini integratsiya qiling
Ulangan hamyon orqali personal_sign’dan foydalaning; endi ochiq kalitlar talab qilinmaydi
Anchoring
Anchor xaritalarini ethers.js yordamida Base anchor kontraktiga bevosita yuboring
Zanjirga yuborish, tasdiqlash va anchoring uchun $EQTY’dagi xarajatni ixtiyoriy ravishda interfeysda ko‘rsatishni boshqaring
Relay bilan integratsiya
SIWE (Sign-In with Ethereum) orqali autentifikatsiyadan o‘ting
Kirish tokenlarini kerak bo‘lganda saqlang va yangilang
Relay xizmatidan shifrlangan xabarlarni olish uchun autentifikatsiyadan o‘tgan so‘rovlardan foydalaning
Olib tashlangan funksiyalar
LTO lizing interfeysi
Tugun tanlash va zanjir ko‘rinishi
LTO’ga bog‘langan zanjirdagi identifikator boshqaruvi
11. Migratsiya rejasi
LTO Layer 1’ning bekor qilinishi va Base’da yangi anchoring tizimi joriy etilishi bilan protokolning barcha asosiy komponentlari ko‘chirilishi kerak. LTO infratuzilmasiga bog‘langan eski ma’lumotlar — jumladan anchorlar, hodisalar zanjirlari va xabarlar — endi yaroqli bo‘lmaydi.
Nima yaroqsiz bo‘lib qoladi
LTO kalit juftliklari bilan imzolangan hodisalar zanjirlarini tekshirib bo‘lmaydi, chunki Ethereum asosidagi imzolardan ochiq kalitni endi ajratib olish imkoni yo‘q.
LTO L1’da qayd etilgan anchorlarga bundan buyon ishonib yoki ularni so‘rov orqali olib bo‘lmaydi.
LTO asosidagi identifikatorlar yoki anchorlangan zanjirlarga bog‘langan Ownable’lar almashtirilishi kerak.
Base’da anchorlanmagan xabarlar relay xizmati tomonidan rad etiladi.
Bajarilishi kerak bo‘lgan ishlar
Token migratsiyasi Foydalanuvchilar bridge yordamida LTO tokenlarini $EQTY’ga qo‘lda almashtirishlari kerak. Zarb qilish faqat Base’da belgilangan blok balandligigacha mumkin. Bu blokdan keyin bridge o‘chirilib, zarb qilish funksiyasi butunlay o‘chirib qo‘yiladi. Almashtirilmagan LTO tokenlari qiymatini yo‘qotadi.
Ownables aktivlarini qayta chiqarish. Ownable emitentlari BASE tarmog‘iga bog‘langan yangi ownable’larni chiqarishlari kerak. Eski Ownable’larni yangilariga almashtirish bo‘yicha ko‘rsatmalar keyinroq beriladi
Hamyonni o‘tkazish: foydalanuvchilar Universal Wallet’ni yangilashlari kerak.
Snapshot yo‘q
Snapshot, avtomatik migratsiya yoki orqaga muvofiqlik qatlami bo‘lmaydi. Har bir komponent (hodisalar, xabarlar, token qoldiqlari) tegishli interfeyslar orqali Base’da qayta tiklanishi kerak. Yangi protokol toza arxitektura asosida yaratilgan va LTO L1 bilan aloqalarni saqlab qolmaydi.