1. Giới thiệu & Động lực
Bối cảnh
Nền tảng EQTY dựa vào một kiến trúc hai lớp:
Một lớp riêng tư để 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 cộng để đóng dấu thời gian và xác minh các chuỗi sự kiện đó trên một blockchain không thể thay đổi
Về mặt lịch sử, lớp công cộng này đã được cung cấp bởi LTO Network Layer 1, một blockchain Proof-of-Stake chuyên dụng được tối ưu hóa cho việc neo.
Tuy nhiên, bối cảnh hoạt động đã thay đổi đáng kể.
Tại sao Layer 1 của LTO phải bị ngừng hoạt động
1. An ninh kinh tế đã sụp đổ
LTO hiện có vốn hóa thị trường dưới 5 triệu USD, với chỉ khoảng 20% mã thông báo được stake.
Điều này có nghĩa là ngân sách bảo mật hiệu quả (tức là tổng giá trị bảo vệ sự đồng thuận) là < 1 triệu USD.
Tại những mức này, thật kinh tế hợp lý cho một tác nhân xấu để làm tổn hại đến sự đồ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 hợp pháp — đ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 chấm dứt dịch vụ của các nút 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 tương xứng đối với sự đồng thuận.
Điều này làm suy yếu các đảm bảo phân quyền mà việc neo được thiết kế để 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.
Các khách hàng và đối tác mong đợi EQTY neo trên các mạng công cộng được chấp nhận rộng rãi và đáng tin cậy (ví dụ: Ethereum, Base).
Nhận thức về “neo vào một Layer 1 trị giá 5 triệu USD” làm suy yếu niềm tin vào cơ sở hạ tầng cốt lõi của EQTY.
4. Sự dễ vỡ 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 dừng lại.
Bảo trì liên tục (các trình khám phá, chỉ mục, cơ sở hạ tầng nút) làm tăng chi phí 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 được thừa hưởng 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 sự 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 tồn tại trên Base
Neo vào Base loại bỏ gánh nặng duy trì một Layer 1 tùy chỉnh trong khi tăng cường khả năng kiểm tra, khả năng kết hợp và niềm tin.
Động lực chiến lược
Giá trị của EQTY không nằm trong sự đồng thuận — nó nằm trong lớp riêng tư, mô hình tài sản và kiến trúc tuân thủ của nó.
Giữ một Layer 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 chấp nhận 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 Layer 1.
2. Mã thông báo $EQTY ERC-20 mới
Nền tảng EQTY sẽ giới thiệu một mã thông báo ERC-20 mới, $EQTY, được triển khai trên mạng Base. Mã thông báo này thay thế mã thông báo 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 mã thông báo bắt đầu với nguồn cung bằng không. $EQTY được đúc theo nhu cầu khi người dùng hoán đổi các mã thông báo 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 khối được xác định trước, chức năng đúc sẽ bị vô hiệu hóa vĩnh viễn. Bất kỳ mã thông báo LTO nào không được chuyển đổi trước thời hạn này sẽ không được đưa vào hệ sinh thái EQTY, và tổng cung $EQTY cuối cùng sẽ thấp hơn nguồn cung LTO ban đầu.
Hợp đồng mã thông báo được thiết kế tối giản. Nó tuân theo giao diện ERC-20 tiêu chuẩn, không có logic chuyển nhượng đặc biệt, tính năng airdrop hoặc lịch trình vesting.
Mã thông báo $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 các mã thông báo phải được đốt, giảm tổng 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 hash 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ị, trong đó:
Đối với chuỗi sự kiện: khóa = stateHash, giá trị = eventHash
Đối với tin nhắn: khóa = messageHash, giá trị = 0x0
Giao diện
cấu trúc Anchor {
khóa bytes32;
giá trị bytes32;
}
hàm anchor(Anchor[] calldata anchors) bên ngoài;
sự kiện được neo (
khóa bytes32 đã chỉ mục,
giá trị bytes32,
địa chỉ đã chỉ mục người gửi,
uint64 timestamp
);
Hành vi
Hợp đồng phát ra một sự kiện được neo cho mỗi cặp (khóa, giá trị).
Thời gian khối hiện tại được đưa vào sự kiện như một trường riêng cho sự tiện lợi và khả năng kiểm tra.
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 bản ghi.
Hợp đồng là không có quyền — 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ộ, chẳng hạn như chỉ mục oBridge và nền tảng EQTY
Dịch vụ bên ngoài, bao gồm The Graph, Infura hoặc các xác thực tùy chỉnh
Bằng cách giữ cho neo không có 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 neo là có thể xác minh, hiệu quả và độc lập với cơ sở hạ tầng.
Cơ chế phí
Khách hàng cần gọi approve() trên hợp đồng ERC20 để kích hoạt neo
Mỗi neo phát sinh một khoản đốt $EQTY, được thực thi trong hàm anchor()
Số tiền phí được đọc từ một hợp đồng cấu hình được kiểm soát bởi quản trị riêng
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 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ó thể điều chỉnh. Thay vì mã hóa một khoản phí tĩnh hoặc dựa vào các 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 chuyên dụ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 Governor của OpenZeppelin liên kết với mã thông báo $EQTY. Các phiếu bầu sẽ được đưa ra dựa trên số dư $EQTY bằng cách sử dụng logic tiêu chuẩn ERC20Votes.
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. Nó sau đó đốt số lượng thích hợp $EQTY trực tiếp từ số dư của người gửi. Cách tiếp cận này tránh sự cần thiết cho các giao dịch approve() và đảm bảo rằng hợp đồng neo vẫn nhẹ và không có 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 để phản ứng với điều kiện thị trường, biến động giá mã thông báo hoặc thay đổi trong nhu cầu neo — mà không cần dựa 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ý bản địa ví, một thư viện TypeScript độc lập mới sẽ được tạo ra để xử lý logic lớp riêng — bao gồm các chuỗi sự kiện, ký sự kiện, neo và cấu trúc tin nhắn chuyển tiếp. 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:
events/ Bao gồm Event, EventChain, MergeConflict và logic tuần tự hóa liên quan.
message/ Bao gồm Message 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ư Binary.
Thư viện sẽ không có phụ thuộc vào mạng LTO:
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ể của LTO
Nó sẽ hỗ trợ neo thông qua các hợp đồng thông minh trên Base, và tích hợp sạch sẽ với ethers.js để ký và gửi các neo.
Mô hình ký sự kiện
Phương thức Event.signWith() sẽ được làm 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ỳ người ký bên ngoài nào, ngoài việc ký trực tiếp bằng ethers. Nó sử dụng một giao diện ISigner trừu tượng:
giao diện ISigner {
sign(data: Uint8Array): Promise<Uint8Array>;
}
Sự kiện đã ký không còn yêu cầu một khóa công khai; nó chỉ bao gồm chữ ký và địa chỉ được suy ra. Đ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 thức để tạo các 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 chuyển tiếp, chính hash tin nhắn được sử dụng làm khóa neo, và giá trị được đặt là không (0x0).
Neo có thể được thực hiện bằng cách gọi hợp đồng thông minh trực tiếp thông qua ethers.Contract.anchor(Anchor[]). Điều này tránh sự phụ thuộc vào bất kỳ dịch vụ backend nào hoặc cơ sở hạ tầng độc quyền.
Ký tin nhắn
Thư viện cũng bao gồm các lớp Tin nhắn và Chuyển tiếp cho giao tiếp ngoài chuỗi. Giống như các sự kiện, các tin nhắn được ký bất đồng bộ bằng cách sử dụng giao diện ISigner. Chữ ký được thực hiện trên hash tin nhắn, và không có khóa công khai nào được bao gồm — chỉ địa chỉ được suy ra được sử dụng để xác minh.
Sau khi ký, hash tin nhắn được neo trên chuỗi thông qua cùng một hợp đồng Anchor. Đị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 đóng dấu thời gian và xác minh công khai 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ụ bộ tiếp nhận.
Triển khai và sử dụng
Thư viện sẽ được xuất bản dưới dạng một gói NPM riêng biệt. Nó được dự định là lõi chia sẻ được sử dụng bởi:
Ví EQTY (để ký sự kiện và tin nhắn)
Dịch vụ bộ tiếp nhận (để tính toán hash và phân tích tin nhắn)
SDK của Ownables (để xây dựng và gửi sự kiện)
Bất kỳ frontend hoặc xác thực bên thứ ba nào
6. Lập 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 bằng một chỉ mục mới xử lý các sự kiện được neo 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 theo mỗi khóa, có thể đại diện cho trạng thái chuỗi sự kiện hoặc hash tin nhắn chuyển tiếp. Mỗi mục bao gồm:
khóa: trạng thái neo hoặc hash tin nhắn đã được neo
giá trị: hash sự kiện tương ứng hoặc 0x0
txHash, blockNumber, logIndex và người gửi
Các bản ghi này được công khai thông qua một API HTTP công cộng. 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 tiếp với thay đổi tối thiểu.
Chỉ mục oBridge phục vụ hai vai trò:
Là một phụ thuộc nội bộ cho dịch vụ bộ tiếp nhận, mà phải xác minh rằng các tin nhắn đã được neo trước khi phát hành chúng.
Là 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 Base.
Tất cả dữ liệu vẫn có thể xác minh trên chuỗi, và các 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 riêng của họ.
7. Dịch vụ Bộ Tiếp Nhận
Dịch vụ bộ tiếp nhận xử lý việc gửi an toàn các tin nhắn mã hóa giữa các bên. Để đảm bảo các tin nhắn là xác thực, có dấu thời gian, và được kiểm soát truy cập, dịch vụ sẽ được cập nhật để hỗ trợ cả xác thực neo chuỗi và xác thực hiện đại, bản địa ví bằng cách sử dụng Đăng Nhập với Ethereum (SIWE).
Xác thực Tin nhắn bằng SIWE
Thay vì dựa vào các chữ ký tin nhắn HTTP hoặc các thử thách tùy chỉnh, bộ tiếp nhận 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 liên kết 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 bộ tiếp nhận: 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 đế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ột mã thông báo truy cập JWT (ngắn hạn, ví dụ: 15 phút)
Một mã thông báo làm mới (dài hạn, ví dụ: 24 giờ)
Tất cả các yêu cầu lấy tin nhắn sau (GET /messages?to=...) phải bao gồm mã thông báo truy cập trong tiêu đề Authorization.
Khi mã thông báo hết hạn, khách hàng có thể sử dụng mã thông báo làm mới để có được một mã thông báo 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 áp dụng 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 việc xác thực, dịch vụ bộ tiếp nhận sẽ xác minh rằng mỗi tin nhắn đã được neo trên chuỗi trước khi phát hành. Neo cung cấp tính không thể thay đổi, đóng dấu thời gian, và ngăn chặn các cuộc tấn công spam hoặc phát lại.
Bộ tiếp nhận duy trì chỉ mục nhẹ của riêng nó cho hợp đồng neo trên Base. Nó lắng nghe các sự kiện được 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 phát hành, bộ tiếp nhận kiểm tra rằng:
Một sự kiện được neo tồn tại với khóa = messageHash
Giá trị chính xác là 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à từ địa chỉ)
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 tất cả tin nhắn được xác minh công khai, có dấu thời gian trên Base và được neo bởi danh tính đúng.
Bộ tiếp nhận 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 dựa vào oBridge.
8. Thay đổi hợp đồng Ownable (CosmWasm)
Với việc di chuyển khỏi LTO Layer 1 và ngừng 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ỉ sử dụng địa chỉ Ethereum tiêu chuẩn.
Ủy quyền dựa trên địa chỉ
Trước đây, việc xác minh quyền sở hữu phụ thuộc 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ý bây giờ 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 các địa chỉ trực tiếp.
Logic hợp đồng đã cập nhật sử dụng info.sender — địa chỉ đã ký và gửi sự kiện — như danh tính có thẩm quyền.
Điều này ảnh hưởng đến tất cả các điểm đầu vào 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 đị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à mạng khớp
Hợp đồng tiếp tục xác thực nguồn gốc của các sự kiện chéo chuỗi 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 dự kiến
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 hàm chuyển đổi address_lto() và address_eip155() có thể bị xóa, vì không còn cần thiết phải chuyển đổi từ hoặc đến 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ý điện tử và danh tính gốc 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 Ownable hiện tại, phụ thuộc vào ký và neo cụ thể của LTO, sẽ trở nên không thể xác minh theo 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 của Ownables
SDK của Ownables phải được cập nhật để phản ánh sự chuyển đổi từ ký điện tử 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 khóa
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 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 người ký dựa trên ethers
Đảm bảo signWith() không còn phụ thuộc vào một khóa công khai; chỉ địa chỉ có thể phục hồi được sử dụng
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 hash 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 đơn giản (0x...) trong toàn bộ dòng sự kiện và tin nhắn
Khả năng tương thích
SDK đã cập nhật vẫn tương tự về cấu trúc nhưng không còn bị ràng buộc 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 Base, và sẽ tương tác với các hợp đồng Ownable đã được cập nhật và dịch vụ bộ tiếp nhận.
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 việc 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 giao diện nhà cung cấp EIP-1193 để kích hoạt ký và truy xuất địa chỉ
Hỗ trợ mã thông báo
Thêm hỗ trợ để hiển thị và quản lý số dư của mã thông báo $EQTY ERC-20 mới trên Base
Bao gồm siêu dữ liệu mã thông báo, 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 thông qua ví kết nối; các khóa công khai không còn cần thiết
Neo
Gửi các bản đồ neo trực tiếp đến hợp đồng neo trên 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 chi phí neo trong $EQTY
Tích hợp bộ tiếp nhận
Xác thực qua SIWE (Đăng Nhập với Ethereum)
Lưu trữ và làm mới các mã thông báo truy cập khi cần thiết
Sử dụng các yêu cầu được xác thực để lấy các tin nhắn đã mã hóa từ dịch vụ bộ tiếp nhận
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 quan đến LTO
11. Kế hoạch di chuyển
Với việc ngừng hoạt động của 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 quan đến 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ệ.
Những gì trở nên không hợp lệ
Các 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 cậy hoặc truy vấn trong tương lai.
Các Ownables liên kết với các danh tính dựa trên LTO hoặc các chuỗi được neo phải được thay thế.
Các tin nhắn không được neo trên Base sẽ bị dịch vụ bộ tiếp nhận từ chối.
Các hành động cần thiết
Di chuyển mã thông báoNgười dùng phải tự tay hoán đổi các mã thông báo LTO của họ cho $EQTY thông qua cầu nối. Việc đúc chỉ có thể thực hiện đến một chiều cao khối cụ thể trên Base. Sau khối 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 mã thông báo LTO chưa 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 ownable 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 Ownable di sản sang các Ownable 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 nhanh
Sẽ không có ảnh chụp nhanh, 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ư mã thông báo) phải được thiết lập lại trên Base thông qua các giao diện thích hợp. Giao thức mới được thiết kế sạch sẽ và không giữ lại các ràng buộc với LTO L1.