1. Giới thiệu & Động lực
Bối cảnh
Nền tảng EQTY dựa vào kiến trúc hai lớp:
Một lớp riêng để quản lý các chuỗi sự kiện có thể xác minh (ví dụ: Ownables, tin nhắn)
Một lớp neo công khai để đánh dấu thời gian và xác minh các chuỗi sự kiện đó trên một blockchain bất biến
Lịch sử, lớp công khai này được cung cấp bởi LTO Network Layer 1, một blockchain Proof-of-Stake dành riêng cho việc neo.
Tuy nhiên, bối cảnh hoạt động đã thay đổi đáng kể.
Tại sao LTO Layer 1 phải bị loại bỏ
1. An ninh kinh tế đã sụp đổ
LTO hiện có vốn hóa thị trường dưới 5 triệu đô la, với chỉ ~20% token được đặt cọc.
Điều này có nghĩa là ngân sách an ninh hiệu quả (tức là tổng giá trị bảo vệ đồng thuận) là < 1 triệu đô la.
Tại những mức này, có khả năng tài chính cho một tác nhân độc hại để làm tổn hại đến đồng thuận, kiểm duyệt các giao dịch neo hoặc viết lại lịch sử.
Đối với một nền tảng như EQTY — nơi neo các hồ sơ tài sản có thể thực thi về mặt pháp lý — điều này là không thể chấp nhận.
2. Tập trung hóa người xác thực và động lực thấp
Các nút cộng đồng không còn khả thi về mặt kinh tế.
Việc các nút kết thúc dịch vụ có thể dẫn đến một tập hợp nhỏ các nút nắm giữ quyền kiểm soát không cân xứng đối với đồng thuận.
Điều này làm suy yếu các đảm bảo phân cấp mà việc neo nhằm cung cấp.
3. Ma sát chấp nhận
Ngày càng khó để biện minh cho LTO như một lớp neo an toàn trong các cuộc trò chuyện bán hàng hoặc kiểm toán.
Khách hàng và đối tác mong đợi EQTY neo trên các mạng công khai được chấp nhận rộng rãi và đáng tin cậy (ví dụ: Ethereum, Base).
Nhận thức về việc “neo đến một Lớp 1 trị giá 5 triệu đô la” làm yếu đi sự tin tưởng vào cơ sở hạ tầng cốt lõi của EQTY.
4. Sự mong manh của cơ sở hạ tầng
Nếu ngay cả một vài người xác thực chính đi offline, LTO trở nên không ổn định hoặc hoàn toàn ngừng hoạt động.
Việc duy trì liên tục (các trình thám hiểm, chỉ mục, hạ tầng nút) tạo thêm gánh nặng với giá trị giảm dần.
Tại sao Base là lớp neo đúng đắn
Base cung cấp:
Tính tương thích EVM đầy đủ
An ninh kinh tế và kỹ thuật kế thừa từ Ethereum
Hỗ trợ công cụ rộng rãi (MetaMask, WalletConnect, The Graph, v.v.)
Phí gần như bằng không với tính cuối cùng nhanh chóng
Sự phù hợp gần gũi với lớp tài sản và thanh khoản của EQTY, cũng sống trên Base
Neo đến Base loại bỏ gánh nặng duy trì một Lớp 1 tùy chỉnh trong khi tăng cường khả năng kiểm toán, tính tổng hợp và sự tin tưởng.
Động lực chiến lược
Giá trị của EQTY không nằm trong đồng thuận — nó nằm trong lớp riêng của nó, mô hình tài sản và kiến trúc tuân thủ.
Duy trì một Lớp 1 mang lại ít lợi thế chiến lược với chi phí cao.
Chuyển sang Base cho phép EQTY tập trung hoàn toàn vào việc áp dụng sản phẩm, tích hợp pháp lý và mã hóa tài sản, mà không bị kéo xuống bởi cơ sở hạ tầng Lớp 1.
2. Token $EQTY ERC-20 Mới
Nền tảng EQTY sẽ giới thiệu một token ERC-20 mới, $EQTY, được triển khai trên mạng Base. Token này thay thế token LTO và phục vụ như là tiền tệ bản địa cho các hoạt động giao thức, bao gồm neo và quản trị.
Hợp đồng token bắt đầu với nguồn cung bằng không. $EQTY được đúc theo yêu cầu khi người dùng hoán đổi token LTO của họ trong một khoảng thời gian di chuyển hạn chế. Cửa sổ này được thực thi trên chuỗi: sau một chiều cao block đã xác định, chức năng mint sẽ bị vô hiệu hóa vĩnh viễn. Bất kỳ token LTO nào không được chuyển đổi trước thời điểm này sẽ bị loại trừ khỏi hệ sinh thái EQTY, và nguồn cung cuối cùng của $EQTY sẽ thấp hơn nguồn cung ban đầu của LTO.
Hợp đồng token là tối thiểu cố ý. Nó theo tiêu chuẩn giao diện ERC-20, không có logic chuyển đặc biệt, tính năng airdrop hoặc lịch trình vesting.
Token $EQTY sẽ được sử dụng để thanh toán phí neo, tham gia quản trị giao thức và có thể hỗ trợ các vai trò tiện ích bổ sung khi nền tảng phát triển. Tiện ích yêu cầu token phải được đốt, giảm tổng nguồn cung.
3. Hợp đồng Neo trên Base
Việc neo sẽ được thực hiện thông qua một hợp đồng thông minh nhẹ được triển khai trên mạng Base. Hợp đồng này phát ra các sự kiện ghi lại công khai băm của các chuỗi sự kiện hoặc tin nhắn, mà không lưu trữ bất kỳ trạng thái nào trên chuỗi.
Mỗi neo ánh xạ một khóa đến một giá trị, nơi:
Đối với các chuỗi sự kiện: khóa = stateHash, giá trị = eventHash
Đối với các tin nhắn: khóa = messageHash, giá trị = 0x0
Giao diện
cấu trúc Neo {
giá trị bytes32 khóa;
giá trị bytes32;
}
hàm neo(Neo[] calldata anchors) bên ngoài;
sự kiện Neo(
giá trị bytes32 được lập chỉ mục khóa,
giá trị bytes32,
địa chỉ gửi được lập chỉ mục,
uint64 timestamp
);
Hành vi
Hợp đồng phát ra một sự kiện Neo cho mỗi cặp (khóa, giá trị).
Thời gian block.timestamp hiện tại được bao gồm trong sự kiện như một trường riêng cho sự thuận tiện và khả năng kiểm toán.
Không có trạng thái nào được lưu trữ trong hợp đồng. Tất cả dữ liệu neo được ghi lại thông qua các nhật ký.
Hợp đồng là không cần phép — bất kỳ ai cũng có thể neo.
Các sự kiện này được thiết kế để có thể lập chỉ mục và truy cập bởi:
Các thành phần nội bộ, như chỉ mục oBridge và nền tảng EQTY
Các dịch vụ bên ngoài, bao gồm The Graph, Infura hoặc các xác minh tùy chỉnh
Bằng cách giữ cho việc neo không trạng thái và phát ra các sự kiện hoàn chỉnh, thiết kế này đảm bảo rằng việc neo có thể xác minh, hiệu quả và độc lập với cơ sở hạ tầng.
Cơ chế phí
Các khách hàng cần gọi approve() trên hợp đồng ERC20 để kích hoạt neo
Mỗi neo đều phát sinh một lần đốt $EQTY, được thực thi trong chức năng anchor()
Số tiền phí được đọc từ một hợp đồng cấu hình kiểm soát bởi quản trị
Việc neo sẽ không sử dụng approve() mà thay vào đó đốt thông qua eqtyToken.burnFrom(msg.sender, fee * n)
4. Quản trị Phí
Để giữ cho việc neo kinh tế bền vững và công bằng theo thời gian, phí phải trả bằng $EQTY cho mỗi neo phải có khả năng điều chỉnh. Thay vì mã hóa một khoản phí tĩnh hoặc phụ thuộc vào oracle giá, EQTY sẽ sử dụng một mô hình quản trị trên chuỗi để kiểm soát tham số này một cách minh bạch và phi tập trung.
Một hợp đồng cấu hình dành riêng sẽ lưu trữ phí neo hiện tại. Giá trị này chỉ có thể được cập nhật bởi một hợp đồng quản trị — cụ thể là một phiên bản của OpenZeppelin’s Governor liên kết với token $EQTY. Các phiếu bầu sẽ được bỏ dựa trên số dư $EQTY sử dụng logic ERC20Votes tiêu chuẩn.
Hợp đồng neo đọc phí hiện tại từ hợp đồng cấu hình mỗi khi anchor() được gọi. Sau đó, nó đốt một lượng $EQTY thích hợp trực tiếp từ số dư của người gửi. Cách tiếp cận này tránh cần các giao dịch approve() và đảm bảo rằng hợp đồng neo vẫn nhẹ và không trạng thái ngoài việc thực thi phí.
Mô hình quản trị cho phép cộng đồng điều chỉnh phí theo thời gian để đáp ứng với điều kiện thị trường, dao động giá token hoặc thay đổi trong nhu cầu neo — mà không phụ thuộc vào nguồn dữ liệu bên ngoài hoặc kiểm soát tập trung.
5. Thư viện Lớp Riêng Tư Mới
Để hỗ trợ neo trên Base và ký gốc ví, một thư viện TypeScript độc lập mới sẽ được tạo ra để xử lý logic lớp riêng tư — bao gồm các chuỗi sự kiện, ký sự kiện, neo và cấu trúc tin nhắn relay. Thư viện này thay thế @ltonetwork/lto-api.js cụ thể cho LTO cho tất cả các trường hợp sử dụng EQTY.
Thư viện mới được thiết kế để sử dụng trong cả môi trường trình duyệt (ví dụ: MetaMask, WalletConnect) và công cụ phía máy chủ.
Phạm vi và nội dung
Chỉ các thành phần liên quan của lớp riêng tư LTO sẽ được bao gồm:
sự kiện/ Bao gồm Sự kiện, Chuỗi sự kiện, Xung đột hợp nhất và logic tuần tự hóa liên quan.
tin nhắn/ Bao gồm Tin nhắn và Relay, được sử dụng cho giao tiếp mã hóa ngoài chuỗi.
Mã hỗ trợ Bao gồm các lớp tiện ích như Nhị phân.
Thư viện sẽ không phụ thuộc vào LTO Network:
Không có API nút LTO
Không có logic giao dịch
Không có công cụ tạo cặp khóa
Không có mã hóa địa chỉ cụ thể cho LTO
Nó sẽ hỗ trợ neo qua các hợp đồng thông minh trên Base và tích hợp một cách sạch sẽ với ethers.js để ký và gửi neo.
Mô hình ký sự kiện
Phương thức Event.signWith() sẽ được thực hiện bất đồng bộ để hỗ trợ ký dựa trên trình duyệt thông qua MetaMask, WalletConnect hoặc bất kỳ signer bên ngoài nào, bên cạnh việc ký trực tiếp với ethers. Nó sử dụng một giao diện ISigner trừu tượng:
giao diện ISigner {
ký (dữ liệu: Uint8Array): Promise<Uint8Array>;
}
Sự kiện đã ký không còn yêu cầu khóa công khai; nó chỉ bao gồm chữ ký và địa chỉ đã suy diễn. Điều này làm cho nó tương thích với các luồng ký Ethereum (personal_sign) và loại bỏ nhu cầu trích xuất các khóa công khai, điều này không khả thi trong hầu hết các môi trường ví.
Tích hợp neo
Thư viện bao gồm một phương pháp để tạo bản đồ neo:
const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();
Mỗi neo ánh xạ một stateHash (khóa) đến một lastEventHash (giá trị), sẵn sàng được gửi đến hợp đồng thông minh Base. Đối với các tin nhắn relay, băm tin nhắn tự nó được sử dụng làm khóa neo, và giá trị được đặt thành không (0x0).
Việc neo có thể được thực hiện bằng cách gọi trực tiếp hợp đồng thông minh thông qua ethers.Contract.anchor(Anchor[]). Điều này tránh phụ thuộc vào bất kỳ dịch vụ backend hoặc cơ sở hạ tầng độc quyền nào.
Ký tin nhắn
Thư viện cũng bao gồm các lớp Tin nhắn và Relay cho giao tiếp ngoài chuỗi. Giống như các sự kiện, tin nhắn được ký bất đồng bộ bằng cách sử dụng giao diện ISigner. Các chữ ký được thực hiện trên băm tin nhắn, và không có khóa công khai nào được bao gồm — chỉ địa chỉ đã suy diễn được sử dụng để xác minh.
Sau khi ký, băm tin nhắn được neo trên chuỗi thông qua hợp đồng Anchor cùng một. Định dạng là:
khóa = messageHash
giá trị = 0x0
Điều này đảm bảo rằng các tin nhắn ngoài chuỗi có thể được đánh dấu thời gian công khai và xác minh mà không tiết lộ nội dung của chúng. Việc neo có thể được thực hiện bởi người gửi hoặc dịch vụ relay.
Triển khai và sử dụng
Thư viện sẽ được xuất bản như một gói NPM riêng biệt. Nó dự kiến sẽ là lõi chia sẻ được sử dụng bởi:
Ví EQTY (cho việc ký sự kiện và tin nhắn)
Dịch vụ relay (để tính toán băm và phân tích tin nhắn)
SDK Ownables (cho việc xây dựng và gửi sự kiện)
Bất kỳ giao diện hoặc xác minh bên thứ ba nào
6. Chỉ mục oBridge
Dịch vụ oBridge sẽ thay thế logic lập chỉ mục dựa trên LTO hiện tại của nó bằng một chỉ mục mới xử lý các sự kiện Neo được phát ra bởi hợp đồng neo trên Base.
Chỉ mục này lắng nghe các nhật ký neo trên Base và duy trì một cơ sở dữ liệu cục bộ của neo gần đây nhất cho mỗi khóa, có thể đại diện cho một trạng thái chuỗi sự kiện hoặc một băm tin nhắn relay. Mỗi mục bao gồm:
khóa: trạng thái neo hoặc băm tin nhắn
giá trị: băm sự kiện tương ứng hoặc 0x0
txHash, blockNumber, logIndex và người gửi
Các hồ sơ này được công bố thông qua một API HTTP công khai. Cấu trúc và hành vi của API này sẽ vẫn tương thích với chỉ mục neo LTO hiện có, bao gồm điểm cuối GET /hash/verify, cho phép các thành phần EQTY hiện có chuyển đổi với những thay đổi tối thiểu.
Chỉ mục oBridge phục vụ hai vai trò:
Như một phụ thuộc nội bộ cho dịch vụ relay, phải xác minh rằng các tin nhắn đã được neo trước khi phát hành chúng.
Như một dịch vụ xác minh công khai cho các khách hàng và ví bên ngoài muốn kiểm tra trạng thái neo mà không cần truy vấn trực tiếp đến Base.
Tất cả dữ liệu vẫn có thể xác minh trên chuỗi, và khách hàng có thể bỏ qua oBridge nếu muốn bằng cách sử dụng eth_getLogs hoặc chỉ mục của riêng họ.
7. Dịch vụ Relay
Dịch vụ relay xử lý việc gửi an toàn các tin nhắn được mã hóa giữa các bên. Để đảm bảo rằng các tin nhắn là xác thực, có dấu thời gian và kiểm soát truy cập, dịch vụ sẽ được cập nhật để hỗ trợ cả xác minh neo trên chuỗi và xác thực gốc ví hiện đại bằng cách sử dụng Đăng nhập với Ethereum (SIWE).
Xác thực tin nhắn với SIWE
Thay vì phụ thuộc vào chữ ký tin nhắn HTTP hoặc các thách thức tùy chỉnh, relay sẽ thực hiện tiêu chuẩn SIWE (EIP-4361). Cách tiếp cận này cho phép người dùng xác thực bằng cách ký một tin nhắn văn bản tiêu chuẩn bằng ví Ethereum của họ, tạo ra một chữ ký có thể phục hồi ràng buộc họ với một phiên.
Luồng đăng nhập:
Khách hàng yêu cầu một tin nhắn SIWE từ backend relay: GET /auth/siwe-message?address=0x...
Máy chủ trả về một tin nhắn SIWE tiêu chuẩn bao gồm:
Miền (ví dụ: relay.eqty.network)
Nonce
Thời gian hết hạn
Trường tài nguyên tùy chọn giới hạn ở /messages?to=...
Tuyên bố: ví dụ “Đăng nhập để truy cập tin nhắn EQTY của bạn.”
Khách hàng ký tin nhắn bằng cách sử dụng personal_sign
Khách hàng gửi tin nhắn đã ký và chữ ký đến POST /auth/verify
Máy chủ xác minh chữ ký và phát hành:
Mã truy cập JWT (thời gian ngắn, ví dụ 15 phút)
Mã làm mới (thời gian dài hơn, ví dụ 24 giờ)
Tất cả các yêu cầu truy xuất tin nhắn tiếp theo (GET /messages?to=...) phải bao gồm mã truy cập trong tiêu đề Ủy quyền.
Khi mã thông báo hết hạn, khách hàng có thể sử dụng mã làm mới để có được mã truy cập mới mà không cần ký lại.
Mô hình này hoàn toàn tương thích với MetaMask, WalletConnect và các ví EIP-1193 khác, và tuân theo các mẫu bảo mật được chấp nhận rộng rãi. Không cần logic hoặc cơ sở hạ tầng tùy chỉnh nào ngoài các thư viện SIWE hiện có.
Neo và Xác minh Tin nhắn
Ngoài xác thực, dịch vụ relay sẽ xác minh rằng mỗi tin nhắn đã được neo trên chuỗi trước khi gửi nó. Neo cung cấp tính bất biến, dấu thời gian và ngăn chặn spam hoặc các cuộc tấn công phát lại.
Dịch vụ relay duy trì chỉ mục nhẹ của riêng mình cho hợp đồng neo trên Base. Nó lắng nghe các sự kiện Neo và ghi lại:
khóa = messageHash
giá trị = 0x0
người gửi
blockNumber, txHash, timestamp
Để xác minh một tin nhắn trước khi gửi, dịch vụ relay kiểm tra rằng:
Một sự kiện Neo tồn tại với khóa = messageHash
Giá trị là chính xác 0x0 (tức là không phải là một neo chuỗi sự kiện)
Người gửi khớp với người ký tin nhắn (tức là địa chỉ từ)
Chỉ sau khi neo thành công, tin nhắn mới được phát hành cho người nhận. Điều này đảm bảo rằng tất cả các tin nhắn đều có thể xác minh công khai, có dấu thời gian trên Base và được neo bởi danh tính đúng.
Dịch vụ relay thực hiện xác minh này bằng cách sử dụng chỉ mục nội bộ của riêng nó và không phụ thuộc vào oBridge.
8. Thay đổi Hợp đồng Ownable (CosmWasm)
Với việc di chuyển ra khỏi LTO Layer 1 và việc loại bỏ ký sự kiện dựa trên khóa công khai, các hợp đồng Ownable phải được cập nhật để hỗ trợ ủy quyền dựa trên địa chỉ bằng cách sử dụng các địa chỉ Ethereum tiêu chuẩn.
Ủy quyền dựa trên địa chỉ
Trước đây, xác minh quyền sở hữu dựa vào việc phục hồi và so sánh các khóa công khai được trích xuất từ các sự kiện đã ký. Vì các ví Ethereum không tiết lộ các khóa công khai, và các chữ ký giờ đây sử dụng personal_sign (có thể phục hồi đến một địa chỉ), mô hình xác minh phải chuyển sang so sánh trực tiếp các địa chỉ.
Logic hợp đồng đã cập nhật sử dụng info.sender — địa chỉ đã ký và gửi sự kiện — như là danh tính có thẩm quyền.
Điều này ảnh hưởng đến tất cả các điểm truy cập nơi yêu cầu ủy quyền:
try_transfer: người gửi phải khớp với địa chỉ chủ sở hữu hiện tại
try_release: người gửi phải khớp với địa chỉ chủ sở hữu đã khóa trước đó
try_register_lock: xác minh rằng trường chủ sở hữu của sự kiện khớp với người ký
Thay vì chuyển đổi các khóa công khai thành các địa chỉ LTO, hợp đồng đơn giản chỉ lưu trữ và so sánh các giá trị Addr (ví dụ: 0xabc123...).
CAIP-2 và khớp mạng
Hợp đồng tiếp tục xác minh nguồn gốc của các sự kiện chéo bằng cách sử dụng định danh mạng CAIP-2. Đối với các tin nhắn dựa trên Ethereum, không gian tên là eip155:<chainId>. Hợp đồng xác minh rằng:
Mạng sự kiện khớp với mạng mong đợi
Trường chủ sở hữu trong sự kiện khớp với người ký (info.sender) dưới không gian tên CAIP đã cho
Các chức năng chuyển đổi address_lto() và address_eip155() có thể được loại bỏ, vì không còn cần chuyển đổi đến hoặc từ các địa chỉ LTO nữa.
Tác động
Thay đổi này làm cho hợp đồng Ownable:
Hoàn toàn tương thích với ký và danh tính dựa trên Ethereum
Độc lập với cơ sở hạ tầng khóa LTO
Tương thích với bất kỳ chuỗi nào hỗ trợ phục hồi dựa trên địa chỉ (ví dụ: EVM)
Các Ownables hiện có, dựa vào ký và neo cụ thể cho LTO, sẽ trở nên không thể xác minh dưới mô hình mới và phải được phát hành lại (xem Phần 11).
9. Cập nhật SDK Ownables
SDK Ownables phải được cập nhật để phản ánh sự chuyển đổi từ ký công khai dựa trên LTO sang ủy quyền dựa trên địa chỉ kiểu Ethereum và neo trên Base.
Cập nhật chính
Ký sự kiện
Cập nhật việc tạo sự kiện để sử dụng thư viện lớp riêng tư mới (@eqty-core/events)
Sử dụng các triển khai ISigner tương thích với MetaMask, WalletConnect hoặc các signer dựa trên ethers
Đảm bảo signWith() không còn phụ thuộc vào khóa công khai; chỉ sử dụng địa chỉ có thể phục hồi
Neo
Thay thế logic neo nút LTO bằng việc gửi hợp đồng thông minh trên Base
Sử dụng getAnchorMap() để thu thập các cặp (khóa, giá trị) và gửi chúng qua ethers.Contract.anchor()
Đảm bảo việc neo tin nhắn sử dụng (khóa = messageHash, giá trị = 0x0)
Xác minh
Cập nhật logic xác minh để sử dụng API /hash/verify tương thích với oBridge hoặc một truy vấn nhật ký trực tiếp
Xác nhận rằng giá trị neo khớp với băm sự kiện mong đợi và rằng người gửi khớp với địa chỉ Ethereum của người ký
Sử dụng địa chỉ
Thay thế bất kỳ logic nào so sánh hoặc tạo địa chỉ LTO
Sử dụng địa chỉ Ethereum thông thường (0x...) trong toàn bộ luồng sự kiện và tin nhắn
Tính tương thích
SDK đã cập nhật vẫn giữ cấu trúc tương tự nhưng không còn liên kết với thư viện @ltonetwork/lto-api.js hoặc dịch vụ nút LTO. Nó tương thích với thư viện lớp riêng tư mới và neo trên Base, và sẽ tương tác với các hợp đồng Ownable đã cập nhật và dịch vụ relay.
10. Cập nhật Ví Toàn cầu
Ví toàn cầu phải được cập nhật để phản ánh sự di chuyển sang Base và kiến trúc EQTY mới. Nó không còn tương tác với các nút LTO.
Cập nhật cốt lõi
Kết nối ví
Thay thế xử lý cặp khóa LTO bằng thư viện tương thích với Ethereum (ethers.js)
Sử dụng các giao diện nhà cung cấp EIP-1193 để kích hoạt ký và truy xuất địa chỉ
Hỗ trợ token
Thêm hỗ trợ để hiển thị và quản lý số dư của token $EQTY ERC-20 mới trên Base
Bao gồm siêu dữ liệu token, lịch sử và theo dõi số dư qua các điểm cuối RPC công khai
Ký sự kiện và tin nhắn
Tích hợp thư viện lớp riêng tư mới để cho phép người dùng tạo và ký các chuỗi sự kiện và tin nhắn
Sử dụng personal_sign qua ví kết nối; không còn yêu cầu khóa công khai
Neo
Gửi bản đồ neo trực tiếp đến hợp đồng neo Base bằng cách sử dụng ethers.js
Xử lý việc gửi trên chuỗi, xác nhận và phản hồi UI tùy chọn cho phí neo trong $EQTY
Tích hợp relay
Xác thực qua SIWE (Đăng nhập với Ethereum)
Lưu trữ và làm mới mã truy cập khi cần thiết
Sử dụng các yêu cầu xác thực để lấy tin nhắn được mã hóa từ dịch vụ relay
Các tính năng bị xóa
Giao diện cho thuê LTO
Chọn nút và xem chuỗi
Quản lý danh tính trên chuỗi liên kết với LTO
11. Kế hoạch Di chuyển
Với việc loại bỏ LTO Layer 1 và việc giới thiệu một hệ thống neo mới trên Base, tất cả các thành phần cốt lõi của giao thức phải di chuyển. Dữ liệu kế thừa liên kết với cơ sở hạ tầng LTO — bao gồm các neo, chuỗi sự kiện và tin nhắn — sẽ không còn hợp lệ.
Điều gì trở nên không hợp lệ
Chuỗi sự kiện được ký bằng các cặp khóa LTO không thể được xác minh, vì khóa công khai không còn có thể trích xuất từ các chữ ký dựa trên Ethereum.
Các neo được ghi lại trên LTO L1 không thể được tin tưởng hoặc truy vấn trong tương lai.
Các tài sản liên kết với các danh tính dựa trên LTO hoặc chuỗi neo phải được thay thế.
Các tin nhắn không được neo trên Base sẽ bị dịch vụ relay từ chối.
Các hành động cần thiết
Di chuyển tokenNgười dùng phải tự tay hoán đổi token LTO của họ lấy $EQTY thông qua cầu nối. Việc đúc chỉ có thể thực hiện cho đến một chiều cao block cụ thể trên Base. Sau block này, cầu nối sẽ bị đóng và chức năng đúc sẽ bị vô hiệu hóa vĩnh viễn. Các token LTO chưa được hoán đổi sẽ trở nên vô giá trị.
Phát hành lại Tài sản Ownables.Các nhà phát hành Ownable phải phát hành các ownables mới liên kết với mạng BASE. Hướng dẫn sẽ theo sau về cách hoán đổi các Ownables kế thừa thành các Ownables mới
Chuyển đổi ví Người dùng sẽ cần cập nhật Ví Toàn cầu.
Không có ảnh chụp
Sẽ không có ảnh chụp, di chuyển tự động hoặc lớp tương thích ngược. Mỗi thành phần (sự kiện, tin nhắn, số dư token) phải được thiết lập lại trên Base thông qua các giao diện phù hợp. Giao thức mới sạch sẽ theo thiết kế và không bảo tồn các liên kết với LTO L1.