Tác giả: Charles Shen @ inWeb3.com
Trong hai bài viết trước, chúng ta đã thảo luận về 5 chữ "W" của khung W5H: cụ thể là "Tại sao, Khi nào, Cái gì, Ở đâu, Ai". Trong số đó, "Tại sao" khám phá cơ sở lý luận của mã thông báo và việc tạo ra giá trị bền vững của nền kinh tế tiền điện tử đằng sau chúng; "Khi nào" thảo luận về thời điểm tốt nhất để phát hành mã thông báo; "Cái gì" kiểm tra các loại mã thông báo phù hợp cho các mục đích cụ thể; ” tập trung vào mạng blockchain nào nên tạo mã thông báo; “Ai” kiểm tra những người tham gia hệ sinh thái nào phù hợp để sở hữu mã thông báo.
Trong bài viết này, chúng ta sẽ tiếp tục khám phá "Cách thiết kế mã thông báo". Phải thừa nhận rằngcác cuộc thảo luận về “cách thiết kế mã thông báo” có thể rất rộng. Bài viết này sẽ thảo luận về một số vấn đề chính, bao gồm cần bao nhiêu mã thông báo khác nhau, cách tạo và phân phối nguồn cung cấp mã thông báo, cách phân phối mã thông báo và cách xây dựng tính thanh khoản của mã thông báo.
"Mô hình mã thông báo kép" là mô hình được sử dụng rộng rãi trong đó các chức năng quản trị và phi quản trị được thực hiện bởi hai mã thông báo khác nhau. Một ví dụ điển hình là trò chơi Axie Infinity, trong đó mã thông báo AXS đảm nhận vai trò quản trị và mã thông báo SLP đóng vai trò là tiền tệ trong trò chơi. Tuy nhiên, mô hình mã thông báo képkhông phải là giải pháp phổ quát cho vấn đề này vì mã thông báo có tiện ích vượt xa khả năng quản trị và tiền tệ.
Để giải quyết vấn đề này, chúng ta có thể thực hiện phương pháp chung sau:
< Lập danh sách tất cả các mục tiêu mà chúng tôi muốn mã thông báo đạt được (chẳng hạn như các tính năng sản phẩm cụ thể hoặc mục tiêu khuyến khích). Thông tin này phải được lấy từ bước "Tại sao bạn cần mã thông báo" trong phần đầu tiên của loạt bài này.
Giả sử rằng mỗi mục tiêu được gán một mã thông báo riêng.
Khám phá khả năng tổng hợp các mã thông báo nhất định dựa trên sự thống nhất về lợi ích giữa những người nắm giữ tiềm năng.
Lặp lại các giải pháp kỹ thuật để đảm bảo rằng logic kinh doanh cần thiết được triển khai đồng thời cho phép tích hợp mã thông báo.
Trong quá trình này, các thuộc tính khác của từng mã thông báo ứng cử viên cũng cần được xem xét, chẳng hạn như khả năng thay thế, ứng dụng và cơ sở hạ tầng, v.v.
Khi đưa ra quyết định, có một số điều quan trọng cần nhớ:
Kết quả quyết định cuối cùng phụ thuộc rất lớn vào Thực tế việc triển khai giải pháp và kết quả có thể khác nhau đáng kể ngay cả giữa các sản phẩm tương tự.
Mức độ liên kết lợi ích giữa các bên liên quan là chìa khóa trong việc xác định liệu nhiều mục tiêu có thể được kết hợp vào cùng một mã thông báo hay không.
Việc kết hợp các mục tiêu ở các cấp độ khác nhau của ngăn xếp mạng sẽ tạo ra những rủi ro bổ sung cần được chú ý đặc biệt.
Quyết định chọn các mã thông báo khác nhau chỉ là một phần của thiết kế và nó không đảm bảo liệu các nguyên tắc cơ bản của dự án có hợp lý hay không.
Trong phần phụ lục của bài viết này, chúng tôi trình bày cách áp dụng các bước trên thông qua nghiên cứu điển hình về một số dự án stablecoin phi tập trung và phản ánh cách phản ánh những cân nhắc này trong quy trình thực tế.
Khi chúng tôi đã xác định được mã thông báo mà chúng tôi muốn tạo, bước tiếp theo là xem xét cách tạo và cung cấp tiền tệ cho họ.
Nguồn cung tối đa: Khi xây dựng kế hoạch tạo mã thông báo, trước tiên chúng tôi cần xác định xem tổng nguồn cung cấp mã thông báo là có hạn hay không giới hạn. Chỉ riêng quyết định này không quyết định được tình trạng của thiết kế mã thông báo, vì điều thực sự quan trọng là sự cân bằng liên tục giữa cung và cầu. Ví dụ: trong số các loại tiền điện tử chính, nguồn cung Bitcoin (BTC) tối đa được cố định ở mức 21 triệu, trong khi nguồn cung Ethereum (ETH) là không giới hạn. Một số dự án sẽ đặt nguồn cung tối đa dựa trên số lượng chủ sở hữu ước tính để tránh số lượng token nhỏ lẻ, chẳng hạn như Ankr có nguồn cung tối đa là 10 tỷ.
Lịch khai thác: Mặc dù tất cả các mã thông báo có thể được đúc cùng một lúc, nhưng việc tăng dần nguồn cung tối đa theo thời gian sẽ phổ biến hơn vì điều này có lợi hơn. Có hai cách chính để thực hiện việc này: truyền theo yêu cầu hoặc phát theo lịch trình. Ví dụ: DAI stablecoin của MakerDAO có thể được đúc bất cứ lúc nào bằng cách cung cấp tài sản thế chấp tương ứng, không có lịch trình đúc tiền hoặc giới hạn nguồn cung cố định. Chuỗi khối Bitcoin tạo ra một khối khoảng 10 phút một lần và tạo ra Bitcoin mới trong mỗi khối mới, một quá trình sẽ tiếp tục cho đến khi đạt được số lượng Bitcoin tối đa.
Lịch phân bổ:Các dự án thường sẽ phát triển lịch phân bổ để làm rõ cách phân phối nguồn cung cấp mã thông báo giữa các bên liên quan chính khác nhau. Điều đáng lưu ý là chúng tôi không muốn việc nắm giữ mã thông báo quá tập trung, vì sự tập trung quá mức có thể khiến giá mã thông báo dễ bị một số nhà đầu tư lớn thao túng. Ví dụ: báo cáo của Coopahtroopa và Lstephanian đã tóm tắt dữ liệu từ 60 dự án và đề xuất một số ví dụ phân bổ, chẳng hạn như nhóm 17,5%, nhà đầu tư 17,5%, cộng đồng sớm (airdrop) 5%, khuyến khích sinh thái 10%, Tài chính 50% . Một báo cáo tiếp theo từ Liquifi cũng đưa ra kết luận tương tự, mặc dù nó sử dụng các định nghĩa phân loại khác nhau. Ngoài ra còn có cái gọi là trường hợp ngoại lệ “phát hành công bằng”, trong đó mã thông báo được cung cấp cho tất cả người tham gia một cách công bằng và minh bạch, do đó không có phân phối ban đầu cho nhóm, nhà đầu tư hoặc bất kỳ bên liên quan cụ thể nào. Yearn Finance áp dụng phương thức phát hành công bằng này. Mã thông báo YFI của nó không được phân bổ trước và bất kỳ ai cũng có thể nhận được nguồn cung cấp mã thông báo ban đầu bằng cách tham gia vào nhóm thanh khoản ban đầu của nó.
Một phần nguồn cung cấp mã thông báo thường sẽ được phân bổtrực tiếp cho các lợi ích cụ thể thông qua việc bán trước hoặc phần thưởng cho các bên liên quan làm điều này vì nhiều mục đích khác nhau, bao gồm cả việc gây quỹ hoặc khuyến khích cộng đồng.
Đối với những mã thông báo không được phân bổ trước cho lần phát hành đầu tiên, chẳng hạn như các mã thông báo nằm trong nhóm khuyến khích hệ sinh thái và bộ phận tài chính, chúng có thể được phân bổ liên tục cho các bên liên quan theo quy định quá trình quản lý dự án của các bên quan tâm.
Nếu token được phân phối với số lượng lớn với chi phí thấp hoặc miễn phí, đặc biệt là trong bối cảnh kế hoạch phát hành token kèm theo kỳ vọng lạm phát, điều đó có thể tạo ra áp lực bán bất lợi và làm gián đoạn Cung và cầu về token . Để giải quyết vấn đề này, các chiến lược bắt nguồn từ lý thuyết trò chơi và lý thuyết thiết kế cơ chế kinh tế đã được áp dụng, chúng ta sẽ khám phá sâu hơn trong phần thứ tư của loạt bài này.
Việc phân phối token cho các nhà đầu tư tư nhân thường được thực hiện thông qua việc bán hàng chiết khấu để đổi lấy sự đóng góp của họ cho dự án A đầu tư có rủi ro cao trong giai đoạn đầu. Việc phân phối token cho các nhà đầu tư đại chúng đặt ra những thách thức lớn hơn do sự mơ hồ về mặt pháp lý. Chào bán tiền xu ban đầu (ICO) từng là một phương thức huy động vốn từ cộng đồng tiền điện tử được áp dụng rộng rãi, nhưng chúng đã trở nên hạn chế do sự giám sát chặt chẽ của cơ quan quản lý. Vào năm 2022, mọi người thường gọi các đợt phát hành tiền xu lần đầu là các sự kiện tạo mã thông báo (TGE). TGE thường cung cấp mã thông báo cho công chúng và có thể có nhiều hình thức, chẳng hạn như Ưu đãi DEX ban đầu (IDO) và Ưu đãi trao đổi ban đầu (IEO). Một số đội đã nghĩ ra một số cái tên rất sáng tạo để thu hút sự tham gia của công chúng trong việc gây quỹ ban đầu. Ví dụ: dự án JPEG'd cho phép những người sở hữu NFT có giá trị, chẳng hạn như chủ sở hữu Cryptopunk, sử dụng NFT của họ làm tài sản thế chấp để vay vốn. Trước khi ra mắt dự án vào cuối tháng 4 năm 2022, nhóm đã tổ chức một sự kiện vào tháng 2 có tên là “Chiến dịch quyên góp mã thông báo”. Họ mời công chúng quyên góp Ethereum (ETH) cho dự án và đổi lại, những nhà tài trợ này sẽ nhận được tỷ lệ chia sẻ tương ứng là 30% token gốc của dự án, JPEG.
Nhiều dự án tiền điện tử sẽ phân phối miễn phí mã thông báo cho các thành viên cộng đồng có liên quan và các nhóm cốt lõi trong giai đoạn đầu. Khởi xướng cộng đồng hoặc khen thưởng nhóm nòng cốt.
Airdrop là cách phổ biến để phân phối token miễn phí. Trước khi tiến hành airdrop thành công, trước tiên dự án cần xác định địa chỉ của người nhận đủ điều kiện. Mặc dù việc lấy địa chỉ của nhóm nòng cốt tương đối đơn giản nhưng việc xác định địa chỉ của các thành viên cộng đồng đủ tiêu chuẩn có thể khó khăn hơn. Quyết định này thường được đưa ra bởi cơ quan quản lý dự án, cho dù đó là một nhóm tập trung hay cơ quan quản trị phi tập trung.
Trong giai đoạn đầu của dự án, nhiều dự án sử dụng thời điểm các thành viên cộng đồng bắt đầu tương tác với sản phẩm làm cơ sở chính để xác định người dùng trung thành. Ví dụ: Uniswap đã airdrop token tới các ví đã tương tác với chúng ít nhất một lần ngay trước ngày ra mắt token.
Một nhược điểm của cơ chế đánh giá dựa trên thời gian đơn giản là nó có thể thu hút những người không phải là người dùng thực sự đáp ứng tiêu chuẩn ngắn hạn bằng cách tạo nhiều ví và thực hiện giao dịch bot đơn giản. giống như người thực hiện vụ tấn công Sybil. Do đó, các đợt airdrop tiếp theo đã nâng cao tiêu chuẩn tham gia, đòi hỏi các tương tác có ý nghĩa hơn với giao thức, chẳng hạn như sao chép và nhiều kiểu sử dụng thực tế hơn, dẫn đến cải thiện tổng thể.
Chương trình airdrop của Dịch vụ tên Ethereum (ENS) được phân bổ cho những người đã đăng ký tên miền ".ETH" trước một ngày cụ thể. Vì đăng ký tên miền là một quy trình duy nhất bao gồm nhiều bước và chi phí nên điều này giúp giảm khả năng thao túng quy trình đánh giá chất lượng.
Rarible là một nền tảng giao dịch NFT ban đầu phân bổ các đợt airdrop hàng tuần dựa trên hoạt động giao dịch của người mua và người bán. Cách tiếp cận có vẻ hợp lý này đã nhanh chóng được khai thác bởi một số lượng lớn người giao dịch lệnh để thúc đẩy khối lượng giao dịch của họ. để nhận được nhiều phần thưởng hơn. Hành vi này cuối cùng đã dẫn đến một cuộc bỏ phiếu của ban quản lý giao thức để chấm dứt cơ chế phân phối phần thưởng này.
Đợt airdrop mới nhất của Optimism cải tiến hơn nữa cơ chế đánh giá chất lượng, bao gồm nhiều vòng airdrop và chú trọng nhiều hơn đến giá trị hành vi của người dùng mục tiêu. Airdrop đầu tiên của nó tiếp cận những người tích cực sớm áp dụng hệ thống Optimism. Vì Optimism là giao thức lớp thứ hai của Ethereum nên airdrop của nó cũng nhắm đến những người tham gia Ethereum tích cực, những người có tính nhất quán cao với mục tiêu của dự án, chẳng hạn như cử tri DAO, người ký nhiều chữ ký, nhà tài trợ Gitcoin và người dùng vẫn đang tích cực sử dụng Ethereum.
Xác định chính xác các nhóm bên liên quan mục tiêu là một cách để xác định nhóm airdrop dự định; một cách khác là sàng lọc các thành viên không mong muốn khỏi các nhóm hiện có, thường do những kẻ tấn công Sybil tạo ra. Ví dụ: HopDAO cung cấp phần thưởng cho cộng đồng người dùng khi báo cáo những kẻ tấn công Sybil và cho phép những kẻ tấn công Sybil tự báo cáo hành vi sai trái của mình để những kẻ tấn công này vẫn có thể nhận được phần thưởng được phân bổ. Nếu không tự ra đầu thú mà bị người khác tố giác thì sẽ chẳng được gì.
Tiêu chí phân bổ mã thông báo cũng có thể tính đến hiệu suất thực tế của người dùng cung cấp dịch vụ cho mạng. Giao thức cộng hóa trị là mạng truy cập dữ liệu blockchain phân tán sử dụng mã thông báo để thanh toán cho các nút cung cấp dịch vụ mạng. Ngoài ra, các nút hoạt động tốt nhất về độ trễ và độ tin cậy có thể nhận được hệ số phần thưởng bổ sung.
Tính hiệu quả của airdrop vẫn còn bị nghi ngờ. Ngoài airdrop, một cách khác để đạt được sự phân phối mã thông báo là thông qua các airdrop có khóa. Không giống như airdrop, airdrop khóa yêu cầu người nhận khóa một phần tài sản tiền điện tử của họ trong một khoảng thời gian để nhận phần thưởng mã thông báo, từ đó tạo ra chi phí cơ hội cho người nhận mã thông báo. Cách tiếp cận này thường có lợi cho các dự án. Ví dụ: Astroport, airdrop đặt cược của một sàn giao dịch phi tập trung, yêu cầu các thành viên cộng đồng khóa mã thông báo LP để nhận phần thưởng mã thông báo ASTRO. Quá trình này đã giúp giao thức tích lũy tính thanh khoản và đồng thời đạt được mức phân phối token ban đầu. Người nhận airdrop đặt cược thực chất là những token “kiếm được”, một biến thể của mô hình phân phối giá trị “đặt cọc và tham gia” mà chúng ta sẽ thảo luận trong phần năm của loạt bài này. Sự khác biệt là tài sản bị khóa thường không phải là mã thông báo phần thưởng (nếu mã thông báo phần thưởng chưa được phân phối) và nếu không có yêu cầu hoạt động nào khác thì không liên quan đến việc cắt giảm.
Tính thanh khoản là yếu tố chính quyết định mức độ dễ dàng của người dùng khi mua và bán một mã thông báo cụ thể. Tính thanh khoản của dự án Web3 có thể được so sánh với băng thông của dự án Web2. Nếu so sánh nền kinh tế mã thông báo với một thành phố trong thế giới thực thì tính thanh khoản sẵn có giống như đường cao tốc nối thành phố với thế giới bên ngoài. Về cơ bản nó là cửa ngõ vào thế giới kinh tế mã thông báo. Thiếu thanh khoản có thể tạo ra “phần bù thanh khoản”, khiến token được giao dịch dưới giá trị nội tại của nó. Các phương pháp cải thiện tính thanh khoản bao gồm tận dụng các nhà tạo lập thị trường chuyên nghiệp trên các sàn giao dịch tập trung và thiết lập các nhóm thanh khoản sâu trên các sàn giao dịch phi tập trung. Nhưng đối với các token mới ra mắt, việc tung ra thanh khoản ban đầu là một thách thức lớn.
Trước khi mã thông báo được liệt kê, chúng tôi cần quyết định mã thông báo hiện tại nào sẽ được ghép nối với mã thông báo mới. Một cách tiếp cận phổ biến là chọn mã thông báo cơ sở hạ tầng của chuỗi khối đó làm đối tác ghép nối. Ví dụ: nếu dự án trên Ethereum thì ETH thường sẽ được chọn làm cặp. Lý do cho sự lựa chọn này là vì các token cơ sở hạ tầng thường được sử dụng rộng rãi nhất trong hệ sinh thái blockchain và việc kết hợp với chúng có thể tối đa hóa hiệu quả của tính thanh khoản ban đầu. Một lựa chọn phổ biến khác là kết hợp với một loại tiền ổn định, chẳng hạn như USDC, điều này sẽ thuận tiện hơn cho những người nắm giữ muốn giảm bớt sự biến động. Mặc dù việc tạo nhiều cặp thanh khoản có thể giúp các mã thông báo mới dễ tiếp cận hơn nhưng nó cũng phân bổ tính thanh khoản tổng thể của các mã thông báo mới trên các nhóm khác nhau. Nếu một dự án có số vốn ban đầu hạn chế, có lẽ sẽ khôn ngoan hơn nếu tập trung vào một vài cặp chính.
Token có thể được niêm yết trên nhiều sàn giao dịch. Binance, FTX và Coinbase là một trong những sàn giao dịch tập trung lớn nhất. Mỗi hệ sinh thái blockchain cũng có các sàn giao dịch phi tập trung lớn, ví dụ: Uniswap là sàn giao dịch lớn nhất trên Ethereum, trong khi PancakeSwap là sàn giao dịch lớn nhất trên Binance Smart Chain. Các sàn giao dịch tập trung thường có các tiêu chuẩn khắt khe hơn đối với việc niêm yết token so với các sàn giao dịch phi tập trung. Nhiều dự án cũng thuê các nhà tạo lập thị trường chuyên nghiệp để giảm trượt giá giao dịch và cung cấp sổ lệnh sâu hơn để cải thiện tính thanh khoản hơn nữa.
Khi mã thông báo được bán công khai trên một sàn giao dịch, chúng ta cần đặt giá ban đầu. Quỹ khởi động thanh khoản (LBP) là một phương pháp xác định giá ban đầu. Cách thức hoạt động của LBP là nó bắt đầu ở mức giá cao hơn và nếu không có người mua thì giá sẽ giảm xuống mức mà mọi người cho rằng nên mua. Ngoài việc cung cấp cơ chế khám phá giá không được phép, phương pháp này còn giúp gây quỹ trong quá trình này, tương tự như bán trước công khai. Số tiền thu được thông qua quy trình LBP có thể được sử dụng để bổ sung tính thanh khoản cần thiết cho việc niêm yết mã thông báo tiếp theo trên sàn giao dịch. Balancer cung cấp các dịch vụ LBP phổ biến, trong khi Copper cung cấp giao diện thân thiện với người dùng để tham gia LBP của Balancer. Delphi Labs cũng thiết kế Lockdrop + Liquidity Bootstrap và áp dụng nó cho các dự án như Astroport và Mars.
Trong trường hợp không có cơ chế phát hiện giá công khai phù hợp, các dự án cần ước tính trực tiếp giá trị của token, đồng thời cần cân bằng nhiều yếu tố, chẳng hạn như số lượng token được phát hành ban đầu, tính thanh khoản ban đầu quỹ và tỷ lệ lạm phát đặt trước chờ đợi.
Khi một mã thông báo được tung ra, các nhóm thường muốn xây dựng tính thanh khoản ngoài nguồn tài chính của chính họ. Do đó, nhiều dự án khuyến khích các nhà cung cấp thanh khoản bên ngoài cung cấp các cặp giao dịch thanh khoản cần thiết và thanh toán bằng token mới phát hành của dự án. Các mã thông báo mới này dành cho nhà cung cấp thanh khoản hoạt động giống như tiền thuê và thường được lấy từ phần khuyến khích sinh thái của bảng phân phối mã thông báo. Mộtlỗ hổng lớn của mô hình này là tính thanh khoản của các hợp đồng thuê này tương tự như tính thanh khoản của vốn đánh thuê, trong đó các nhà cung cấp thường không trung thành với chính dự án và có thể nhanh chóng bán bớt mã thông báo của họ để tìm kiếm các cơ hội khác có lợi nhuận cao hơn. Phương pháp này được gọi là canh tác năng suất. Theo dữ liệu năm 2021 của Nansen, 42% nông dân năng suất đã bỏ chương trình vào ngày nó ra mắt, khoảng 16% còn lại trong vòng 48 giờ và đến ngày thứ ba, 70% người dùng đã bỏ chương trình. Chu kỳ canh tác và bán này khiến giá token giảm mạnh, làm giảm thêm lợi nhuận của nông dân và đẩy nhanh việc họ rời khỏi nhóm thanh khoản. Do đó,chiến lược thanh khoản này chỉ hoạt động trong thời gian ngắn, thường là ngay sau khi mã thông báo được phát hành.
Giải pháp thanh khoản dài hạn bền vững hơn là bản thân dự án phải nắm giữ đủ Token tính thanh khoản, đây được gọi là tính thanh khoản thuộc sở hữu của giao thức. Thay vì sử dụng mã thông báo để thuê thanh khoản, hãy bán mã thông báo với giá chiết khấu và sử dụng mã thông báo đó để mua thanh khoản từ bên thứ ba. OlympusDAO đã phổ biến khái niệm này và giúp các giao thức khác triển khai quy trình này thông qua dịch vụ Olympus Pro. Tính thanh khoản thuộc sở hữu của giao thức là chủ đề cốt lõi của DeFi 2.0.
Bài viết này tiếp tục phần “tại sao, khi nào, cái gì, ở đâu, ai” xem xét các mã thông báo trong phần thảo luận Phần Một và Hai. Chúng tôi đi sâu vào một số khía cạnh chính của "cách thiết kế mã thông báo", bao gồm xác định số lượng mã thông báo khác nhau được yêu cầu, tạo và cấu hình cung cấp mã thông báo, phân phối mã thông báo cho các bên liên quan chính và cấu trúc giới tính dòng mã thông báo. Trong phần thứ tư sắp tới, chúng tôi sẽ tập trung vào động lực cung và cầu, hoàn thành phần cuối cùng của khuôn khổ W5H. Sự cân bằng năng động giữa cung và cầu là yếu tố chính đảm bảo tính bền vững liên tục của các dự án mã thông báo.
Nghiên cứu điển hình: Cách xác định số lượng token khác nhau mà một dự án cần
Chúng tôi áp dụng các bước được đề cập trong các chương trước để đánh giá một số dự án thiết kế stablecoin phi tập trung và chứng minh quy trình này.
Mục tiêu cốt lõi của stablecoin là giá trị của nó có thể được gắn với một loại tiền tệ hợp pháp như đồng đô la Mỹ. Chúng tôi có thể xác định các mục tiêu cụ thể sau (O1 đến O4), có thể đạt được bằng cách sử dụng mã thông báo trong hệ thống stablecoin phi tập trung:
O1: Cung cấp stablecoin làm phương thức thanh toán
O2 : Điều chỉnh sự biến động giá của stablecoin và duy trì tỷ giá của chúng với đồng đô la Mỹ
O3: Giao thức quản trị, xác định các thay đổi của hệ thống, chẳng hạn như điều chỉnh các cơ chế và thông số điều chỉnh
O4: Bảo mật cơ sở hạ tầng blockchain nơi triển khai stablecoin
Sau các bước này, chúng tôi bắt đầu thiết kế một mã thông báo riêng cho từng mục tiêu. Cụ thể, chúng tôi gọi chúng là mã thông báo T1 của O1, mã thông báo T2 của O2, mã thông báo T3 của O3 và mã thông báo T4 của O4. Làm thế nào chúng ta có thể kết hợp chúng?
Phương pháp A: Giả sử chúng ta muốn xây dựng trên Ethereum để stablecoin có thể tương tác trực tiếp với hệ sinh thái Ethereum. Điều này có nghĩa là token T4 là ETH. Vậy còn token T1 đến T3 thì sao? Cần có ít nhất một mã thông báo để đại diện cho sản phẩm stablecoin, do đó cần có mã thông báo T1. Ngoài ra, mối liên hệ giữa các bên liên quan đến token T2 và T3 đã được ghi nhận. Người dùng tham gia vào quá trình điều chỉnh chốt cũng có thể lo ngại về việc điều chỉnh và tối ưu hóa cơ chế điều chỉnh. Điều này cho thấy lợi ích của các bên liên quan đến token T2 và T3 rất phù hợp. Vì vậy, có thể hợp nhất chúng thành một. Có giải pháp nào không? MakerDAO có câu trả lời. MakerDAO có hai mã thông báo độc lập, một là stablecoin DAI (T1) và mã còn lại là mã thông báo MKR (T2 và T3) được sử dụng để điều chỉnh các chốt và quản trị DAI.
Phương pháp B: Hãy xem lại danh sách mục tiêu của chúng tôi. Rõ ràng, mã thông báo T1 là bắt buộc vì nó đại diện trực tiếp cho chính sản phẩm. Nếu chúng tôi chọn xây dựng trên Ethereum thì T4 sẽ do ETH nắm giữ. Trong phương pháp A, chúng tôi đã hợp nhất T2 và T3 thành một mã thông báo. Tuy nhiên, lợi ích của các bên liên quan của T1 và T2 cũng phù hợp với nhau, vì việc duy trì sự ổn định của stablecoin chính xác là điều mà các bên liên quan của T2 đang theo đuổi. Vì vậy, có thể sử dụng một mã thông báo để đáp ứng cả hai chức năng T1 và T2 không? Giao thức AMPL cung cấp một ví dụ. Trong giao thức này, mã thông báo AMPL vừa là một stablecoin (T1) vừa được sử dụng trực tiếp để điều chỉnh tỷ giá cố định của nó (T2). Ngoài ra, nó sử dụng mã thông báo quản trị riêng, FORTH (T3).
Phương pháp C: Điều gì sẽ xảy ra nếu thay vì triển khai stablecoin trên blockchain hiện có, nhóm muốn tạo blockchain của riêng mình? Mã thông báo T1 vẫn được yêu cầu. Cả các bên liên quan của T2 chịu trách nhiệm về quy định và các bên liên quan của T3 chịu trách nhiệm quản trị đều cam kết duy trì mức ổn định ổn định. Đồng thời, các bên liên quan của T4, những người chịu trách nhiệm đảm bảo tính bảo mật của blockchain, cũng hy vọng rằng ứng dụng stablecoin sẽ thành công. Vì vậy, có thể xem xét việc hợp nhất T2, T3 và T4 thành một token không? Đây chính xác là cách tiếp cận được thực hiện bởi dự án TerraUSD (UST). UST là một stablecoin (T1) và chuỗi khối cơ bản Terra của nó là chuỗi PoS được hỗ trợ bởi mã thông báo cơ sở hạ tầng LUNA (T4). Đồng thời, LUNA cũng được sử dụng cho quy định được chốt bằng USD (T2) và quản trị (T3) của UST.
Qua những ví dụ này, chúng ta có thể thấy rằng có nhiều cách kết hợp mã thông báo khác nhau có thể được sử dụng để đạt được cùng một mục tiêu.
Làm thế nào để phản ánh “nguyên tắc nhất quán lợi ích của các bên liên quan quan trọng” trong thiết kế trên? Trong ba trường hợp này, không có thiết kế nào kết hợp chính stablecoin (T1) với khả năng quản trị của nó (T3). Điều này có thể là do stablecoin, với tư cách là công cụ giao dịch, thường được lưu hành thường xuyên. Số lượng token mà mọi người nắm giữ phản ánh nhu cầu về khối lượng giao dịch của họ nhiều hơn là mức độ sẵn sàng tham gia quản trị của họ. Điều này có nghĩa là lợi ích của người sử dụng stablecoin (các bên liên quan của T1) và quyền quản trị của stablecoin (các bên liên quan của T3) không hoàn toàn giống nhau (mặc dù cả hai đều sẽ thua nếu stablecoin thất bại, vì vậy chúng có một số điểm đáy chung- lợi ích dòng). Ngược lại, có sự liên kết rõ ràng hơn về lợi ích giữa các cơ quan quản lý stablecoin (các bên liên quan của T2) và cơ quan quản trị (các bên liên quan của T3).
Chúng ta cũng có thể thấy hậu quả của việc hợp nhất các mã thông báo ở các cấp độ khác nhau của hệ thống phân cấp mạng, chẳng hạn như mã thông báo cơ sở hạ tầng so với mã thông báo ứng dụng. Ví dụ: khi mã thông báo ứng dụng cũng đóng vai trò là mã thông báo cơ sở hạ tầng bảo vệ chuỗi khối, nếu có sự cố xảy ra với mã thông báo ứng dụng, nó có thể gây thiệt hại cho toàn bộ cơ sở hạ tầng. Đây chính xác là những gì đã xảy ra trong vụ tai nạn Terra UST/LUNA. Mã thông báo LUNA được sử dụng để bảo mật chuỗi khối Terra (dưới dạng mã thông báo cơ sở hạ tầng) và duy trì tỷ giá USD của stablecoin UST (dưới dạng mã thông báo ứng dụng). Khi UST bị tách rời và giá trị của LUNA gần như bằng 0, hệ thống xác minh khuyến khích của mạng không thể tiếp tục hoạt động. Nhóm đã phải tạm dừng mạng nhiều lần và thực hiện các bước để ngăn chặn kẻ thù chiếm lấy mạng. Nếu mã thông báo xác thực chuỗi khối được tách khỏi mã thông báo ứng dụng hoặc ứng dụng được triển khai trên chuỗi khối hiện có đã được thử nghiệm trong trận chiến, thì giao thức có thể giảm ít nhất một yếu tố tấn công trong tình trạng hỗn loạn này.
Cuối cùng, các quyết định về số lượng mã thông báo dự án không đảm bảo tính đúng đắn cơ bản của mã thông báo hoặc dự án. Sự thành công của mã thông báo phụ thuộc vào sự tích hợp hiệu quả của tất cả các thành phần của hệ thống. Lấy lại ví dụ UST/LUNA, ngay cả khi mã thông báo LUNA chỉ đóng vai trò là mã thông báo ứng dụng, dự án vẫn không thể được lưu do sai sót trong thiết kế cơ bản.
Quản trị đa chuỗi mới của Wormhole cho phép chủ sở hữu mã thông báo W bỏ phiếu cho các đề xuất trên nhiều chuỗi khác nhau. Người dùng có thể đóng góp và ủy quyền quyền quản trị của mình một cách linh hoạt. Bất chấp những thách thức trong quá khứ, mã thông báo W nhận thấy sự gia tăng về giá và khối lượng giao dịch.
EdmundTrong các phần trước của loạt bài Cơ bản về Tokenomics, chúng ta đã thảo luận về “Tại sao, Khi nào, Cái gì, Ở đâu, Ai và Như thế nào” trong thiết kế mã thông báo.
JinseFinanceWormhole tiết lộ lộ trình ra mắt mã thông báo W, bao gồm chuỗi Solana và EVM. Các tính năng bao gồm chuyển mã thông báo gốc, khóa, ủy quyền và quản trị DAO. Hướng tới tương lai phi tập trung trong quản trị blockchain.
EdmundTin thú vị từ Binance: Wormhole (W) tham gia đội hình giao dịch vào ngày 04.03.2024, không mất phí niêm yết và có nhiều cặp giao dịch. Hãy sẵn sàng để giao dịch!
Huang BoĐối với các mã thông báo có tiện ích cụ thể, nguyên tắc chung là - mã thông báo phải được phát hành khi tiện ích của nó cần thiết cho dự án tiền điện tử.
JinseFinanceBinance có kế hoạch giảm phí giao dịch LUNC từ 100% xuống 50%. LUNC đã phản ứng tiêu cực, giảm 12% trong ngày.
cryptopotatoMột phần thông tin dễ hiểu về wETH (Ether bọc).
NellCông ty có trung tâm dữ liệu được đặt tại Hoa Kỳ, đã tạo ra doanh thu 40 triệu đô la vào năm ngoái.
CointelegraphH2O Securities, một công ty cơ sở hạ tầng có trụ sở tại Nam Phi, đã tạo ra 150 triệu đô la để giới thiệu mã thông báo nước tiền điện tử. Công ty đã hạ cánh...
BitcoinistNFT liên quan đến thể thao cần cung cấp một số lợi ích hữu hình, nếu không, người hâm mộ thể thao sẽ chỉ xem chúng như một mánh khóe khác để khai thác lòng trung thành của người hâm mộ.
Cointelegraph