Bài viết gốc - Casey Rodarmor
Biên dịch - Odaily
Hôm qua, Casey Rodarmor, người tạo ra Ordinals đã đăngBlog, đã giới thiệu Runes giao thức mã thông báo có thể thay thế (FT) mới.
Về việc Bitcoin có cần FT hay không, Casey Rodarmortweet của nócó nghĩa là FT có hai mặt. Một mặt, 99,99% FT là chuyện vớ vẩn và lừa đảo, làm suy yếu tính thuần khiết của Bitcoin; mặt khác, chúng mang lại nhiều thu nhập từ phí, nhà phát triển và người dùng cho hệ sinh thái Bitcoin. “Mọi người yêu thích token và chúng giống như các sòng bạc cyberpunk, vì vậy doanh thu từ phí có thể sẽ rất đáng kể và liên tục cho đến khi những lo ngại về ngân sách bảo mật (mạng) được giảm bớt hoàn toàn.”
Ông nói thêm rằng các giao thức FT như BRC-20, RGB và Taproot đã xuất hiện. So với các giao thức trên chuỗi đơn giản, các giao thức như RGB và Taproot rất phức tạp và có thể đặt ra những thách thức đối với trải nghiệm người dùng. BRC-20 rất đơn giản và có thể cung cấp trải nghiệm người dùng tốt so với RGB/Taproot vốn yêu cầu cơ sở hạ tầng truy xuất và lưu trữ dữ liệu ngoài chuỗi; nhưng vấn đề với mã thông báo BRC 20 là chúng tạo ra UTXO rác và chiếm không gian của đồng xu bit.
Rodarmor cho biết Runes là một giao thức dựa trên UTXO phù hợp với Bitcoin một cách tự nhiên hơn và thúc đẩy việc giảm thiểu các bộ sưu tập UTXO bằng cách tránh tạo ra “các UTXO rác”.
Nội dung sau đây được lấy từ bài blog của Casey Rodarmor và được Odaily biên soạn
Tôi không chắc liệu việc tạo giao thức Fungible Token (FT) mới cho Bitcoin có phải là một ý tưởng hay hay không. 99,9% FT là lừa đảo và meme. Tuy nhiên, chúng dường như sẽ không sớm biến mất, giống như các sòng bạc dường như sẽ không sớm biến mất.
Việc tạo ra một giao thức FT tốt cho Bitcoin có thể mang lại thu nhập đáng kể từ phí giao dịch, sự chú ý của nhà phát triển và người dùng đối với Bitcoin. Ngoài ra, nếu giao thức có dấu chân trên chuỗi nhỏ hơn và khuyến khích quản lý UTXO có trách nhiệm, thì nó có thể giảm tác hại so với các giao thức hiện có. Ví dụ: BRC-20 phổ biến hiện nay đã dẫn đến việc tạo ra một lượng lớn UTXO rác.
Nếu so sánh các giao thức FT hiện có, chúng ta sẽ thấy rằng chúng có một số điểm khác biệt quan trọng:
Độ phức tạp: Thỏa thuận phức tạp đến mức nào? Có dễ thực hiện không? Có dễ dàng để áp dụng?
Trải nghiệm người dùng: Có chi tiết triển khai nào tác động tiêu cực đến trải nghiệm người dùng không? Đặc biệt, các giao thức dựa trên dữ liệu ngoài chuỗi có dấu chân trên chuỗi nhẹ hơn nhưng có độ phức tạp đáng kể và yêu cầu người dùng chạy máy chủ của riêng họ hoặc khám phá và tương tác với các máy chủ hiện có.
Mô hình trạng thái: Các giao thức dựa trên UTXO phù hợp tự nhiên hơn với Bitcoin và thúc đẩy việc giảm thiểu bộ UTXO bằng cách tránh tạo ra các UTXO “rác”.
Mã thông báo gốc: Các giao thức có mã thông báo gốc cần thiết cho hoạt động của giao thức rất cồng kềnh, có thể rút và đương nhiên ít được áp dụng rộng rãi hơn.
Dựa trên các khía cạnh trên, kết quả so sánh của các giao thức FT hiện có trong hệ sinh thái Bitcoin như sau:
BRC-20: Không dựa trên UTXO và khá phức tạp vì nó yêu cầu sử dụng lý thuyết thứ tự trong một số thao tác;
RGB: Rất phức tạp, dựa trên dữ liệu ngoài chuỗi, đã được phát triển từ lâu và chưa được áp dụng;
Đối tác: Cần có mã thông báo gốc cho một số hoạt động nhất định, thay vì dựa trên UTXO;
Lớp Omni: Có mã thông báo gốc cần thiết cho một số hoạt động nhất định, thay vì dựa trên UTXO;
Tài sản Taproot: Hơi phức tạp và dựa vào dữ liệu ngoài chuỗi.
Đối với Bitcoin, giao thức FT đơn giản, dựa trên UTXO với trải nghiệm người dùng tốt sẽ như thế nào? Tiếp theo, tôi xin giới thiệu với các bạn một giải pháp rất hay mang tên Runes.
(1. Khái quát chung
Số dư ngọc được giữ trong UTXO; UTXO có thể chứa số lượng ngọc bất kỳ.
Một giao dịch chứa một thông báo giao thức nếu nó chứa một đầu ra có mã pubkey chứa OP_RETURN, theo sau là một lệnh đẩy dữ liệu có chữ hoa ASCII R. Thông báo giao thức là tất cả dữ liệu được đẩy sau dữ liệu đầu tiên.
Dữ liệu nhập ngọc vào các giao dịch với thông báo giao thức không hợp lệ sẽ bị hủy, cho phép các bản nâng cấp trong tương lai thay đổi cách phân bổ hoặc tạo ngọc, tránh cho các khách hàng cũ phân bổ số dư ngọc không chính xác.
Các số nguyên được mã hóa dưới dạng tiền tố varint, trong đó số đứng đầu trong varint xác định độ dài của nó tính bằng byte.
(2) Chuyển khoản
Lần đẩy dữ liệu đầu tiên trong thông báo giao thức được giải mã thành một chuỗi các số nguyên.
Các số nguyên này được hiểu là một chuỗi các bộ dữ liệu (ID, OUTPUT, AMOUNT). Nếu số số nguyên được giải mã không phải là bội số của 3 thì thông báo giao thức không hợp lệ.
ID là ID số của lần chạy được chỉ định
OUTPUT là chỉ số của đầu ra được gán
AMOUNT là số lần chạy cần phân bổ
ID được mã hóa dưới dạng delta. Điều này cho phép gán cùng một rune nhiều lần để tránh trùng lặp ID rune đầy đủ. Ví dụ: bộ: [(100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Thực hiện các nhiệm vụ sau:
ID 100, đầu ra 1, 20 rune
ID 100, đầu ra 2, 10 rune
id 120, đầu ra 1, 5 rune
AMOUNT 0 là viết tắt của tất cả rune còn lại.
Sau khi tất cả việc phân bổ bộ dữ liệu đã được xử lý, mọi rune chưa được gán sẽ được gán cho đầu ra không phải OP_RETURN đầu tiên (nếu có). Các bài tập bổ sung sẽ bị bỏ qua.
Rune có thể được ghi bằng cách gán chúng cho đầu ra OP_RETURN có chứa thông báo giao thức.
(3)Phát hành
Nếu thông báo giao thức có lần đẩy dữ liệu thứ hai thì đó là giao dịch có vấn đề. Lần đẩy dữ liệu thứ hai được giải mã thành hai số nguyên SYMBOL và DECIMALS. Nếu còn lại số nguyên bổ sung, thông báo giao thức không hợp lệ.
Một giao dịch phát hành có thể tạo ra bất kỳ số lượng rune phát hành nào bằng cách sử dụng ID 0 trong bộ dữ liệu gán, tối đa là 2^128 - 1 .
SYMBOL là ký hiệu mã hóa cơ sở 26 bit mà con người có thể đọc được, tương tự như ký hiệu được sử dụng trong tên sat thứ tự. Các ký tự hợp lệ duy nhất là từ A đến Z.
THẬP KỲ là số chữ số sau dấu thập phân nên được sử dụng khi hiển thị các rune đã phát hành.
Nếu BIỂU TƯỢNG chưa được gán, nó sẽ được gán cho ngọc đã xuất bản và ngọc đã xuất bản sẽ nhận được ID rune số có sẵn tiếp theo (bắt đầu từ 1).
Nếu SYMBOL đã được phân bổ hoặc là BITCOIN, BTC hoặc XBT thì sẽ không có rune mới nào được tạo. Việc phân bổ giao dịch phát hành sử dụng ID rune là 0 sẽ bị bỏ qua, nhưng các phân bổ khác vẫn sẽ được xử lý.
(4) Chú ý
Khi hiển thị số dư UTXO, số dư Bitcoin gốc của UTXO có thể được hiển thị với ID rune 0 và ký hiệu BITCOIN, BTC hoặc XBT.
Để giữ cho giao thức đơn giản, (Runes) không áp dụng cơ chế tránh việc chiếm dụng biểu tượng. Trên thực tế, một cách hiệu quả và đơn giản để tránh ràng buộc ký hiệu là chỉ cho phép phân bổ các ký hiệu trên một độ dài nhất định, độ dài này giảm dần theo thời gian và cuối cùng đạt đến 0 và cho phép tất cả các ký hiệu. Điều này sẽ tránh việc phân bổ sớm các ký hiệu ngắn, lý tưởng trong giao thức và khuyến khích những người đến sau cạnh tranh để có được các ký hiệu lý tưởng - nếu sự cạnh tranh đó có ý nghĩa.
viết ở cuối
Giải pháp này có thực sự hiệu quả với thị trường? Tôi không có ý kiến.
Nó đơn giản nhất có thể, không dựa vào dữ liệu ngoài chuỗi, không có mã thông báo gốc và hoàn toàn phù hợp với mô hình UTXO gốc của Bitcoin. Kế hoạch như vậy có thể thu hút người dùng từ các kế hoạch khác có dấu chân trên chuỗi kém hơn và chuyển sự chú ý của các nhà phát triển và người dùng sang Bitcoin, khuyến khích họ chấp nhận chính Bitcoin.
Mặt khác, thế giới FT là một vực thẳm hoàn toàn không thể cứu vãn được của sự lừa dối và tham lam nên có thể bị cuốn trôi.
