Giải mã token ORC-20: Quy tắc phát hành token mới trong hệ sinh thái ordinals
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải mã token ORC-20: Quy tắc phát hành token mới trong hệ sinh thái ordinals
Orc20 đã gỡ bỏ một số giới hạn của BRC20 và định nghĩa thêm nhiều thao tác mới.
Chuyên sâu báo cáo Web3*TechFlow được ủy quyền bởi xiyu để đăng lại
Trong ordinals, bất kỳ việc đúc inscription bằng json và sau đó giải thích đều có khả năng cao là đang sử dụng inscription như giấy nháp, đồng thời đi kèm với rủi ro phụ thuộc quá mức vào các dịch vụ tập trung.
1. Bối cảnh
BRC20 có rất nhiều hạn chế, bao gồm chỉ có thể dùng tên đồng coin gồm bốn ký tự, không thể nâng cấp, rủi ro tiêu dùng kép (double spend), không thể hủy giao dịch, v.v. Mục đích của ORC20 là loại bỏ những hạn chế này, có thể nói đây là một lần hard fork của BRC20. Đến đây bạn có cảm giác quen thuộc chưa? Đây chính là mô hình phân nhánh truyền thống trong hệ sinh thái BTC.
2. ORC20 là gì?
ORC-20 là một tiêu chuẩn mở nhằm tăng cường chức năng của token theo thứ tự trên mạng Bitcoin, cải thiện tiêu chuẩn token theo thứ tự BRC-20 phổ biến. ORC20 tương thích ngược với BRC-20, đồng thời nâng cao tính linh hoạt, khả năng mở rộng và bảo mật, loại bỏ khả năng tiêu dùng kép.
3. Những thay đổi trong ORC20
3.1 Có thể thay đổi lượng cung ban đầu và giới hạn đúc tối đa. Tôi cho rằng điều này không thực sự là một bước tiến, vì việc cố định lượng cung ban đầu và tổng lượng cung không phải là điểm yếu. ORC20 chỉ làm cho hình thức phát hành coin trên ordinals trở nên linh hoạt hơn. Cố định hay linh hoạt chỉ là một lựa chọn, không liên quan đến tốt hay xấu.
3.2 Không gian đặt tên không bị giới hạn cố định, có thể sử dụng tên có độ dài tùy ý. Việc đặt tên đúng là một điểm khó chịu, đặc biệt khi phần lớn các từ bốn chữ cái trong BRC20 đã bị đúc trước.
3.3 Sử dụng mô hình UTXO để đảm bảo không xảy ra tiêu dùng kép trong quá trình giao dịch. Mọi người có thể tự tìm hiểu mô hình UTXO là gì — tức là khi gửi một giao dịch, số dư còn lại cũng sẽ được gửi dưới dạng một giao dịch tới địa chỉ hoàn trả. Điều này có thể giải quyết hợp lý vấn đề tiêu dùng kép.
Ví dụ: chia 10.000 ORC có ID là 1 thành hai phần để gửi tới địa chỉ nhận. Mỗi giao dịch phải có nonce duy nhất. Bước 1: Ghi nhận sự kiện gửi tới bên nhận, gửi 1.000 (nonce là 5) đến địa chỉ nhận; Bước 2: Ghi nhận sự kiện gửi về bên gửi, gửi số dư còn lại về địa chỉ gửi (nonce là 6). Chỉ khi phần dư còn lại được gửi thành công thì giao dịch mới hoàn tất.
3.4 Cho phép hủy giao dịch, chỉ cần dùng "op": "cancel" là có thể hủy giao dịch với nonce tương ứng.
3.5 Cho phép chuyển đổi các đồng BRC20 đã triển khai sang ORC20. Chỉ người triển khai đồng BRC20 mới có thể thực hiện lệnh chuyển đổi.
4. Các quy tắc mới được thêm vào trong ORC20
4.1 Định danh id, mặc định là 1. Định danh phải là duy nhất giữa các ORC-20 chia sẻ cùng một định danh. Nếu tồn tại hai ORC-20 có cùng định danh và cùng ID, thì áp dụng “nguyên tắc đầu tiên”, ORC-20 thứ hai sẽ bị coi là vô hiệu.
4.2 Nonce là định danh duy nhất gắn với mỗi giao dịch, giúp người gửi theo dõi các giao dịch từng phần của họ. Bằng cách đưa nonce vào mỗi giao dịch, người gửi có thể đảm bảo rằng mỗi giao dịch từng phần là duy nhất, không thể bị sao chép do nhầm lẫn hoặc ác ý, nếu không sẽ gây nguy hiểm cho bảo mật giao dịch. Với nonce, người gửi cũng có thể chỉ định nonce tương ứng khi gửi giao dịch hủy để hủy một giao dịch từng phần cụ thể. Điều này mang lại thêm tính an toàn và linh hoạt cho tiêu chuẩn token ORC-20.
4.3 "op": "cancel", thao tác hủy một giao dịch từng phần.
4.4 Trường ug, có thể nâng cấp hay không: true hoặc false, giá trị mặc định là true. Cho phép người triển khai nâng cấp ORC-20 sau này.
4.5 Trường wp, di dời (migrate): true hoặc false, giá trị mặc định là false. Dùng cho mục đích di dời token và không thể đảo ngược. Chỉ người triển khai BRC-20 gốc mới có thể triển khai sự kiện di dời. Trình bao bọc (wrapper) sẽ sao chép dữ liệu gốc của BRC-20 gốc, ví dụ như lượng cung tối đa và giới hạn phát hành giống nhau.
4.6 Version: Phiên bản: Thông tin này hữu ích khi nâng cấp ORC-20. Thông thường, mỗi lần nâng cấp nên cập nhật số phiên bản, giúp xác định các phiên bản hợp đồng khác nhau, thuận tiện cho phát triển, quản lý và sử dụng sau này.
4.7 msg: Tin nhắn: Văn bản tùy chỉnh, thông điệp hoặc tuyên ngôn, có thể có kích thước tùy ý. Trường này có thể dùng để cung cấp thông tin về token, ví dụ như mục đích, tầm nhìn, kịch bản sử dụng, v.v. Điều này giúp người dùng hiểu rõ hơn về giá trị và mục đích sử dụng của token, đồng thời tăng độ tin cậy của token.
4.8 Khóa tùy chỉnh (Custom Key). Chỉ dùng cho các triển khai tùy chỉnh, ví dụ như thuế – thuế giao dịch bắt buộc, ví dụ như tiền bản quyền; người đúc – địa chỉ đúc đặc biệt; hình ảnh – ảnh token; tkid – ID token; url – URL thông tin token.
Các trường tùy chọn này có thể được sử dụng để đáp ứng nhu cầu cá nhân hóa token, mở rộng các chức năng đặc biệt mà giao thức ORC-20 chuẩn không cung cấp. Ví dụ, thuế có thể được dùng để thu một khoản phí nhất định trong mỗi giao dịch, tiền bản quyền có thể được dùng để thu phí từ người sáng tạo ban đầu, v.v. Người đúc có thể chỉ định địa chỉ đặc biệt để cấp quyền đúc token.
5. Hạn chế của ORC20
5.1 Phức tạp, dựa trên ordinals trong hệ sinh thái Bitcoin, đơn giản cũng có thể được xem là một ưu điểm. Tuy nhiên, trên nền tảng BRC20 vốn đã làm phức tạp hóa việc phát hành coin, ORC20 tiếp tục làm nó phức tạp hơn nữa. Nhiều định nghĩa hơn, thao tác rườm rà dễ dẫn đến nhiều vấn đề hơn. Ví dụ như thao tác di dời, có thể dẫn đến việc tồn tại hai loại tiền.
5.2 Tập trung hóa, mục đích sử dụng json là để dễ tra cứu, nhưng việc tra cứu chắc chắn phải dùng đến dịch vụ tập trung, đây cũng là điểm yếu tự nhiên của các ứng dụng ngoài NFT trong hệ sinh thái ordinals hiện nay.
5.3 Tiền bản quyền bắt buộc, đại khái là đưa hình thức thu tiền bản quyền trên thị trường giao dịch vào quy tắc. Theo tôi, việc áp dụng tiền bản quyền lên đồng tiền là dấu hiệu của sự thiếu suy xét. Đối với NFT, bản chất của nó là nghệ thuật, việc trả tiền bản quyền cho nghệ sĩ là có thể hiểu được, mối quan hệ giữa người sáng tạo và người sở hữu là giữa người sáng tác và người sử dụng. Nhưng đối với tiền tệ, người nắm giữ nên được coi là nhà đầu tư, nhà đầu tư bỏ tiền vào dự án nhưng vẫn phải trả tiền bản quyền cho đội ngũ dự án, điều này dường như không hợp lý.
5.4 Phụ thuộc đường mòn (path dependency), qua việc phân tích, ta thấy điều ORC20 đang làm là kéo việc phát hành tiền trên Bitcoin gần hơn về phía RC20. Vậy thì đặt ra câu hỏi: tại sao không dùng ERC20?
6. Tổng kết
Tóm gọn trong một câu: ORC20 loại bỏ một số hạn chế của BRC20 và định nghĩa thêm nhiều thao tác hơn.
Thực tế, sức cạnh tranh cốt lõi của việc phát hành tiền trên ordinals nằm ở dịch vụ tập trung, chứ không phải ở tiêu chuẩn này. Chỉ khi toàn bộ quy trình xác thực khép kín đều được đặt trên chuỗi, mới có thể ngăn ngừa rủi ro tập trung hóa.
Vấn đề lớn nhất của BRC20 không nằm ở việc quá nhiều hạn chế, mà ở sự phụ thuộc vào hệ thống tập trung. ORC20 không giải quyết được vấn đề này. ORC20 coi BRC20 là đối thủ cạnh tranh, mục tiêu là chiếm lĩnh thị trường. ORC20 không ảnh hưởng nhiều đến hệ sinh thái ordinals, và ảnh hưởng đến BRC20 cũng rất hạn chế.
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
xiyu
