ERC721-O: Giao thức và triển khai tiêu chuẩn NFT trên toàn bộ chuỗi
Tuyển chọn TechFlowTuyển chọn TechFlow
ERC721-O: Giao thức và triển khai tiêu chuẩn NFT trên toàn bộ chuỗi
NFT Catddle sẽ là NFT toàn chuỗi đầu tiên được phát triển bằng ERC721-O.
Chuyên sâu báo cáo Web3ERC721-O do đội phát triển Catddle Lab của Catddle NFT thiết kế. Catddle NFT sẽ là NFT toàn chuỗi đầu tiên được phát triển dựa trên ERC721-O.
*ERC721-O là một dự án mã nguồn mở hoàn toàn; hãy tham gia đóng góp tại GitHub !
Tổng quan
ERC721-O là giao thức chuẩn và hiện thực cho NFT (Non-Fungible Token) toàn chuỗi, được xây dựng dựa trên ERC721.
Giao thức ERC721-O nhằm hỗ trợ các ứng dụng bên thứ ba (ví dụ như ví hay sàn giao dịch) xác minh và tương tác thống nhất với mọi NFT đã triển khai giao thức này.
ERC721-O bổ sung nhiều tính năng xuyên chuỗi và đề xuất một loạt giải pháp xử lý các vấn đề an ninh liên quan đến việc di chuyển giữa các chuỗi.
Bối cảnh
LayerZero là một hạ tầng blockchain mới, có khả năng cung cấp dịch vụ truyền tin nhắn giữa các blockchain khác nhau. Theo bài viết từ LayerZero, dịch vụ truyền tin nhắn này đảm bảo việc truyền tải hiệu quả. Khi bên nhận nhận được tin nhắn m từ dịch vụ truyền tải hợp lệ, dịch vụ sẽ đảm bảo rằng giao dịch liên quan t là hợp lệ và đã được xác nhận trên sidechain của bên gửi.
Thông qua giao thức tin nhắn chung này, việc hiện thực NFT toàn chuỗi trở nên khả thi.
Sự khác biệt giữa ERC721-O và các NFT toàn chuỗi hiện có*
Cải tiến của ERC721-O
An toàn hơn
· Cơ chế bảo vệ gas xuyên chuỗi
Mặc dù chúng tôi đã có hàng loạt thiết kế an toàn như không chặn (non-blocking), nhưng khi giới hạn gas đích (destination gas limit) được đặt quá thấp, NFT vẫn có thể bị kẹt trong quá trình di chuyển giữa các chuỗi.
Để tránh tình trạng này, chúng tôi giới thiệu cơ chế bảo vệ gas xuyên chuỗi; chủ sở hữu hợp đồng có thể thiết lập giới hạn tối thiểu hợp lý cho gas xuyên chuỗi để đảm bảo tất cả NFT đều thành công trong việc di chuyển mà không gặp phải tình trạng thiếu gas, đồng thời vẫn duy trì các chức năng xuyên chuỗi khác.
· Thiết lập địa chỉ từ xa an toàn
Việc cập nhật hợp đồng NFT toàn chuỗi đang hoạt động có thể dẫn đến mất vĩnh viễn tài sản. Hơn nữa, khi triển khai hợp đồng NFT toàn chuỗi lên một chuỗi mới mà không tuân theo đúng thứ tự gọi hàm cụ thể, NFT có thể bị chặn hoặc thậm chí mất vĩnh viễn trong quá trình di chuyển.
Để giải quyết các vấn đề này, ERC721-O giới thiệu cơ chế thiết lập địa chỉ từ xa an toàn. Thông qua cơ chế này, chủ sở hữu hợp đồng có thể tránh được rủi ro mất tài sản khi cập nhật hợp đồng, và không cần lo lắng về thứ tự gọi hàm giữa các chuỗi.
· Cố định phiên bản thư viện bên thứ ba
Việc gửi và nhận tin nhắn phụ thuộc vào thư viện LayerZero. Khi LayerZero được cập nhật, cần có khả năng cố định phiên bản thư viện bên thứ ba để tránh các lỗi tiềm ẩn do nâng cấp. Đây cũng là phương pháp tốt nhất được chính thức khuyến nghị bởi LayerZero.
· Giữ lại biện pháp cuối cùng
Ngay cả khi đã áp dụng nhiều thiết kế an toàn (ví dụ: không chặn, bảo vệ gas xuyên chuỗi), vẫn có thể xảy ra trường hợp đường truyền tin nhắn bị chặn và không thể thử lại thành công.
forceResumeReceive là biện pháp cuối cùng chúng ta có thể sử dụng, nếu không thì lỗi chuỗi sẽ bị kẹt vĩnh viễn. Chúng tôi giữ lại nó trong phần hiện thực như một biện pháp cuối cùng.
Thêm nhiều tính năng
· Hỗ trợ mô hình chuyển nhượng ba bên (Approval)
Chức năng phê duyệt (Approve) cho phép bên thứ ba chuyển token của bạn – đây là một khả năng then chốt trong ERC20 và ERC721. Chúng tôi thêm chức năng này nhằm giúp các ứng dụng bên thứ ba tương tác tốt hơn với NFT toàn chuỗi.
· Tự do chọn địa chỉ đích khi chuyển xuyên chuỗi
Người dùng giờ đây có thể chuyển NFT tới bất kỳ địa chỉ nào trên chuỗi khác, chứ không chỉ giới hạn ở địa chỉ tương ứng trên chuỗi đích.
· Gửi NFT kèm theo airdrop gas
Sau khi người dùng gửi NFT sang một chuỗi khác, nếu muốn sử dụng NFT đó, họ cần gửi thêm gas gốc (Ether, BNB, AVAX, v.v.) vào địa chỉ trên chuỗi đích – bước bổ sung này khá phiền phức.
Giờ đây, việc airdrop gas có thể được thực hiện đồng thời với việc gửi NFT, loại bỏ nhu cầu thao tác thêm trên chuỗi đích.
· Cho phép dùng token thanh toán phí xuyên chuỗi
Khi LayerZero ra mắt token riêng, người dùng có thể thiết lập chủ sở hữu token cụ thể để thanh toán phí xuyên chuỗi. Họ có thể cung cấp một số ưu đãi :)
Minh bạch hơn
· Công khai thông tin triển khai quan trọng
Trong thiết kế giao thức ERC721-O, địa chỉ cổng kết nối (endpoint) và địa chỉ hợp đồng từ xa (remote) đều bắt buộc phải công khai, do đó bất kỳ người dùng hay bên thứ ba nào cũng có thể kiểm tra xem địa chỉ endpoint có phải từ LayerZero chính thức hay không, và địa chỉ remote có được thiết lập đúng hay không.
Do đó, các bên thứ ba như sàn giao dịch hay ví có thể dễ dàng triển khai cơ chế kiểm tra đối với token ERC721-O nhằm bảo vệ người dùng khỏi rủi ro mất tài sản.
· Tiết lộ các hoạt động quan trọng trên chuỗi
Khi các hoạt động quan trọng xảy ra trên chuỗi, việc phát sự kiện có thể giúp người dùng và bên thứ ba nắm bắt ngay lập tức những gì đang diễn ra.
Trong thiết kế giao diện ERC721-O, việc gửi và nhận NFT sang chuỗi khác đều bắt buộc phải phát sự kiện. Điều này giúp người dùng và bên thứ ba hiểu rõ những gì đang xảy ra trên chuỗi.
Trong phần hiện thực ERC721-O, các hoạt động quan trọng khác (ví dụ: tạm dừng, thiết lập địa chỉ hợp đồng từ xa) cũng sẽ phát sự kiện để thông báo về các thay đổi lớn.
· Cho phép theo dõi Nonce
Nonce đánh dấu số thứ tự giao dịch được gửi từ một địa chỉ cụ thể. LayerZero cung cấp khả năng theo dõi Nonce, và ERC721-O tích hợp điều này vào sự kiện xuyên chuỗi của hợp đồng. Nhờ thông tin từ các sự kiện, người dùng và bên thứ ba có thể dễ dàng khớp giao dịch giữa chuỗi nguồn và chuỗi đích.
Giảm tiêu thụ Gas
Vì LayerZero đã thực hiện kiểm tra ước lượng gas cho người dùng, nên việc kiểm tra ước lượng gas trước khi gửi tin nhắn là dư thừa. ERC721-O loại bỏ bước này để giảm chi phí gas khi di chuyển xuyên chuỗi.
Dễ dàng ghi đè và tái sử dụng mã
Tất cả các hàm và biến đều được thiết kế để dễ dàng ghi đè và tái sử dụng.
Là một lớp cơ sở, các từ khóa virtual, override và internal được sử dụng rộng rãi trong mã, cùng với chú thích rõ ràng, nhằm cung cấp hướng dẫn chi tiết khi nhà phát triển kế thừa mã hợp đồng.
Cơ sở lý luận đằng sau thiết kế an toàn
LayerZero chính thức cung cấp một mẫu hiện thực cơ bản rất tốt ở đây. Ngoài ra, các NFT như Gh0stly Gh0sts đã chứng minh sức mạnh to lớn của NFT xuyên chuỗi.
Tuy nhiên, nếu token toàn chuỗi muốn phát triển xa hơn, cần lưu ý và giải quyết một số vấn đề an ninh nghiêm trọng. Để giải quyết các vấn đề này, ERC721-O giới thiệu một loạt thiết kế an toàn đặc thù.
Trước khi đi sâu vào các thiết kế cụ thể, cần làm rõ một khái niệm quan trọng: tắc nghẽn tin nhắn xuyên chuỗi. Tắc nghẽn tin nhắn xuyên chuỗi là trạng thái không thể gửi tin nhắn từ hợp đồng nguồn đến chuỗi đích. Trong trạng thái này, hợp đồng nguồn vẫn có thể tiếp tục gửi tin nhắn, nhưng tất cả đều bị kẹt giữa chừng — không nằm trên chuỗi nguồn cũng không nằm trên chuỗi đích, không thể được chấp nhận hay thực thi.
Tình trạng này không chỉ gây khó chịu cho người dùng NFT mà còn rất nguy hiểm vì:
Tất cả tin nhắn bị kẹt đều biến mất khỏi chuỗi và chờ trong hàng đợi do LayerZero quản lý, điều này tiềm ẩn rủi ro.
Nếu tin nhắn thất bại không thể được xử lý, hàng đợi tin nhắn bị kẹt sẽ mãi mãi không thể giải quyết.
Nếu chủ sở hữu hợp đồng sử dụng hàm forceResumeReceive để xử lý tin nhắn thất bại thay vì retryPayload, tin nhắn thất bại có thể bị mất vĩnh viễn. Lưu ý rằng trong hiện thực NFT toàn chuỗi, mất tin nhắn đồng nghĩa với mất NFT.
Do đó, mục tiêu chính của thiết kế an toàn là giảm thiểu tối đa khả năng xảy ra tắc nghẽn tin nhắn.
· Cơ chế bảo vệ gas xuyên chuỗi
Cần lưu ý rằng, ngay cả khi sử dụng cơ chế không chặn (non-blocking), token vẫn có thể bị kẹt do giới hạn gas xuyên chuỗi quá thấp.
Trong thiết kế ERC721-O, tham số bộ điều hợp (adapter) được mở hoàn toàn cho người dùng nhằm cung cấp nhiều khả năng hơn, ví dụ như airdrop token gas (Ether, BNB, AVA, v.v.) khi gửi NFT. Người dùng cũng có thể tự thiết lập giới hạn gas xuyên chuỗi theo nhu cầu. Nếu người dùng đặt giới hạn gas là 100 rồi gửi yêu cầu xuyên chuỗi, điều này là hợp lệ đối với endpoint LayerZero, nhưng thực tế sẽ khiến giao dịch bị tắc. Ngay cả với chế độ không chặn cũng vậy.
Lý do là khi giới hạn gas quá thấp, giao dịch trên chuỗi đích sẽ thất bại trước cả khi đoạn mã try-catch được thực thi. Nói cách khác, chế độ không chặn trong trường hợp này vô hiệu.
Để giải quyết vấn đề này, ERC721-O giới thiệu cơ chế bảo vệ gas. Cơ chế này sẽ kiểm tra tính hợp lệ của tham số bộ điều hợp do người dùng nhập vào. Nếu tham số bộ điều hợp không hợp lệ hoặc lượng gas phân bổ thấp hơn mức tối thiểu do chủ sở hữu hợp đồng quy định, giao dịch sẽ không được gửi đi. Cơ chế bảo vệ này không hạn chế việc người dùng sử dụng tham số bộ điều hợp nâng cao, họ vẫn có thể dùng các tham số này để thực hiện airdrop gas, v.v.
Thông qua cơ chế này, chủ sở hữu hợp đồng có thể thiết lập mức giới hạn gas tối thiểu hợp lý dựa trên mức tiêu thụ gas của hàm nhận, nhằm tránh các vấn đề tắc nghẽn.
· Thiết lập địa chỉ từ xa an toàn
Bất kỳ ai cũng có thể gửi tin nhắn qua LayerZero đến bất kỳ ai, do đó cần thiết lập địa chỉ từ xa để tránh thực thi tin nhắn trái phép từ bên ngoài. Trong các hiện thực hiện tại, hàm setTrustedRemote giúp giới hạn nguồn gửi tin nhắn. Chủ sở hữu hợp đồng sẽ gọi setTrustRemote để thiết lập địa chỉ hợp đồng từ xa, sau đó hợp đồng chỉ chấp nhận tin nhắn từ địa chỉ đó.
Nghe có vẻ hợp lý, nhưng chưa tính đến việc thao tác trên các chuỗi khác nhau luôn có độ trễ về thời gian xác nhận.
Giả sử một kịch bản: hợp đồng a trên chuỗi A và hợp đồng b trên chuỗi B đã thiết lập lẫn nhau làm địa chỉ từ xa và đang hoạt động. "Đang hoạt động" nghĩa là cả hai chuỗi đều đã đúc sẵn NFT. Giờ ta muốn cập nhật hợp đồng a trên chuỗi A thành hợp đồng mới c cũng trên chuỗi A.
Ta có thể đơn giản gọi hàm setTrustRemote trên chuỗi B để thiết lập c làm địa chỉ từ xa mới cho hợp đồng b. Nhưng điều này có thể dẫn đến hậu quả xấu. Lúc này người dùng trên chuỗi A vẫn có thể tiếp tục gửi NFT sang chuỗi B, nhưng vì địa chỉ từ xa trên chuỗi B đã thay đổi (không còn là a), nên mọi NFT gửi đến sẽ bị mất vĩnh viễn. Lưu ý rằng cơ chế không chặn ở đây vô ích, vì nó chỉ hoạt động khi địa chỉ từ xa đã được thiết lập đúng.
Ngược lại, ngay cả khi ta đổi địa chỉ từ xa của hợp đồng a trước, kết quả cũng tương tự. Người dùng NFT trên chuỗi B có thể gửi NFT đến hợp đồng a trước khi thiết lập xong trên chuỗi B. Điều này cũng dẫn đến mất NFT vĩnh viễn, vì địa chỉ từ xa trên hợp đồng a đã thay đổi và sẽ không bao giờ được đặt lại thành b.
Ở đây cần nhấn mạnh rằng, chúng ta không bao giờ có thể đảm bảo các thao tác trên các chuỗi khác nhau xảy ra đồng thời. Vậy có phải chúng ta không thể cập nhật hợp đồng sau khi nó đã được sử dụng?
Thật ra có cách giải quyết, chẳng hạn như cơ chế thiết lập địa chỉ từ xa an toàn trong ERC721-O. Chúng tôi giới thiệu hàm pauseMove, nhận một tham số chainId. Hàm này sẽ khóa chức năng move trên chuỗi chainId. Nghĩa là người dùng trên chuỗi hiện tại tạm thời không thể gửi NFT sang chuỗi chainId. Chủ sở hữu hợp đồng có thể gọi unPauseMove(chainId) để mở khóa sau khi đã xác nhận rằng thao tác setRemote trên cả hai chuỗi đều đã được xác nhận, cho phép người dùng tiếp tục gửi NFT sang chuỗi chainId.
Nhờ thiết kế này, chủ sở hữu hợp đồng có thể xử lý việc cập nhật hợp đồng đang hoạt động. Trở lại ví dụ, chủ sở hữu có thể gọi pauseMove(A) trên chuỗi B, lúc này người dùng trên chuỗi B không thể gửi NFT sang chuỗi A, nhưng người dùng trên chuỗi A vẫn có thể gửi sang chuỗi B. Lưu ý rằng, tại thời điểm này, hợp đồng b vẫn có thể nhận NFT từ hợp đồng a một cách chính xác, do đó không có NFT nào bị mất trong khoảng thời gian này. Sau đó, chủ sở hữu gọi pauseMove(B) trên hợp đồng a của chuỗi A, khiến người dùng trên chuỗi A cũng không thể gửi sang chuỗi B. Đồng thời, cũng cần gọi pauseMove(B) trên hợp đồng c của chuỗi A.
Lúc này, chủ sở hữu có thể gọi hàm setRemote trên hợp đồng b và c theo bất kỳ thứ tự nào để thiết lập lẫn nhau làm địa chỉ từ xa. Cuối cùng, gọi unpause trên cả hai hợp đồng để khôi phục khả năng gửi xuyên chuỗi, như vậy hợp đồng a trên chuỗi A đã được thay thế thành công bằng hợp đồng c.
Thiết kế này cũng áp dụng cho các trường hợp khác. Ví dụ, khi một NFT đang hoạt động trên chuỗi A muốn triển khai lên chuỗi B, chủ sở hữu phải thiết lập địa chỉ từ xa trên chuỗi B trước, nếu không NFT có thể bị kẹt. Với chức năng pauseMove, chủ sở hữu có thể tạm khóa trước, rồi thiết lập địa chỉ từ xa trên chuỗi A hoặc B mà không lo về thứ tự gọi hàm.
Thực tế, mẫu thiết kế này có thể mở rộng sang các loại token khác như ERC20, tuy nhiên ở đây không đi sâu.
Thảo luận
· Có nên hủy bỏ ước lượng gas trên chuỗi không?
Tài liệu chính thức của LayerZero khuyến nghị thực hiện ước lượng gas trên chuỗi để tránh giao dịch thất bại trên chuỗi đích.
Tuy nhiên, thực tế họ đã triển khai kiểm tra này trong các hợp đồng thông minh chính thức. Hơn nữa, với nhiều loại tin nhắn, ngay cả khi ước lượng gas trên chuỗi cũng không đảm bảo tính chính xác. Ngoài ra, ngay cả khi ước lượng sai, hợp đồng ERC721-O có thiết kế không chặn vẫn xử lý hoàn hảo mà không gây tổn thất lớn.
Do đó, việc bắt buộc ước lượng gas trên chuỗi dường như không mang nhiều ý nghĩa thực tiễn, chúng tôi đã loại bỏ nó khỏi phiên bản giao thức hiện tại.
· Có nên loại bỏ hàm forceResumeReceive không?
Hàm forceResumeRecive có khả năng cao dẫn đến mất tài sản. Tuy nhiên, nếu một tin nhắn lỗi bất ngờ làm tắc đường truyền và không thể thử lại thành công, forceResumeRecive là cách duy nhất để dọn dẹp trạng thái tắc nghẽn này. Cần lưu ý rằng thiết kế không chặn không phải lúc nào cũng đảm bảo đường truyền thông suốt. Để phòng tránh tắc nghẽn ngoài ý muốn, chúng tôi giữ lại hàm này trong hiện thực hiện tại. Bạn chỉ nên ghi đè và vô hiệu hóa hàm này nếu hợp đồng của bạn có tính chất IFG (xác định tức thời) – nghĩa là nếu giao dịch được chấp nhận trên chuỗi nguồn thì cũng sẽ được chấp nhận trên chuỗi đích.
Tắc nghẽn gây hại cho trải nghiệm người dùng và có nguy cơ mất tài sản. Vì vậy, chúng tôi muốn giảm thiểu tối đa khả năng xảy ra tắc nghẽn. Với việc thứ tự giao dịch không quan trọng trong thao tác NFT xuyên chuỗi, chúng tôi có thể tận dụng cơ chế không chặn để đảm bảo đường truyền luôn thông suốt ngay cả khi có lỗi bất ngờ. Nếu hợp đồng của bạn đảm bảo luôn thực thi đúng sau khi kiểm tra địa chỉ từ xa, bạn có thể loại bỏ phần cơ chế không chặn.
ERC721-O vẫn là một tiêu chuẩn mở, cần cộng đồng cùng xây dựng. Chúng tôi tin rằng, dưới sự đóng góp của cộng đồng, ERC721-O sẽ trở thành giao thức chuẩn cho NFT toàn chuỗi.
Tất cả các kết luận trên đều được rút ra từ tài liệu mã nguồn mở và mã hiện thực của Phòng thí nghiệm LayerZero, cũng như các thử nghiệm trên nút chính thức của LayerZero. Nếu bạn phát hiện bất kỳ lỗi nào, rất mong bạn để lại bình luận hoặc tạo issue trên Github. Cảm ơn bạn đã đọc!
* Ghi chú: Trong bài viết, chúng tôi sử dụng hiện thực Gh0stly Gh0sts và ví dụ chính thức ở đây làm chuẩn so sánh
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
