Thiết kế mã thông báo: Tiềm năng lớn, cạm bẫy, giải pháp và triển vọng trong tương lai

Mã thông báo là một công cụ mới rất thú vị, hữu ích và mạnh mẽ giúp thay đổi cách thiết kế các giao thức và những gì có thể đạt được, nhưng mã thông báo không phải là trọng tâm của thiết kế. Thiết kế giao thức ngày nay giống “thuật giả kim” hơn là một môn học vì sự hiểu biết của các nhà thiết kế còn lâu mới toàn diện hay khoa học, và hầu hết các dự án vẫn đòi hỏi nhiều thử nghiệm.
Phiên này được chia thành ba phần, bắt đầu với những tư duy chung trong thiết kế mã thông báo, tiếp theo là phân loại mã thông báo, nói cụ thể hơn về mã thông báo thực sự là gì và cách chúng ta có thể nghĩ về việc phát triển và nâng cao khả năng của chúng. Cuối cùng là lý thuyết cây công nghệ, cách sử dụng công nghệ để thiết kế của chúng ta dễ thành công hơn.
Thiết kế mã thông báo: Tiềm năng lớn, cạm bẫy, giải pháp và triển vọng trong tương lai

Chế độ suy nghĩ

Đầu tiên, mã thông báo dành cho giao thức, chúng là một công cụ, một phần của quy trình thiết kế và chúng không phải là mục tiêu. Nếu bạn muốn làm điều gì đó phi tập trung, mã thông báo có thể là một phần trong đó vì thật tuyệt vời khi mọi người có quyền sở hữu giao thức và cũng để giúp mọi người tuân thủ quy định.

Ba giai đoạn thiết kế

Giai đoạn 1: Xác định mục tiêu của bạn

Mục tiêu là một mô tả ngắn gọn về kết quả của một giao thức hợp lệ và phải rõ ràng liệu một thiết kế cụ thể có đạt được mục tiêu đó hay không. Vì vậy chúng ta nên có sự phân biệt thật rõ ràng giữa thành công và thất bại. Nếu không rõ mục tiêu của chúng ta là gì, chúng ta cần phải bắt đầu lại và quên đi các token. Lý tưởng nhất là các mục tiêu có thể đo lường được, ngay cả khi chúng ta chưa chắc chắn về cách đo lường thành công.

Giai đoạn 2: Đưa ra các hạn chế

Nói chung, có hai loại ràng buộc, một là ràng buộc nội tại và một là ràng buộc ngoại sinh: các ràng buộc nội tại là những ràng buộc mà chúng ta chọn để đơn giản hóa quá trình thiết kế vì có một số sự đánh đổi phải được thực hiện hoặc chúng là sự đánh đổi trong chúng tôi.

Những ràng buộc nội tại có thể đến từ nhiều nguồn nhưng thường do chính người thiết kế xác định. Những ràng buộc ngoại sinh được áp đặt lên bạn bởi bản chất, tình trạng công nghệ, các quy định và tất cả những thứ khác. Tôi sẽ nói về nó sau.

Giai đoạn 3: Cơ chế thiết kế

Sau khi có ràng buộc và mục tiêu, chúng ta có thể suy nghĩ rõ ràng về cơ chế sẽ đáp ứng mục tiêu đó. Bây giờ, bất cứ khi nào chúng ta nghĩ về một người thợ cơ khí, chúng ta phải thực sự rõ ràng liệu nó có vi phạm những hạn chế đó hay không và đưa chúng ta đến gần hơn với mục tiêu đó. Một giao thức sẽ là một tập hợp các cơ chế, tất cả đều hướng tới một mục tiêu cụ thể theo một số ràng buộc.

Hãy MakerDAO như một ví dụ. Mục tiêu của họ là phát triển ổn định Ethereum tài sản bản địa. Tất nhiên, có nhiều cách giải thích về sự ổn định và bản chất. Hạn chế của chúng là giá được chốt bằng USD, được hỗ trợ hoàn toàn bởi tài sản gốc trên chuỗi, v.v.

Thiết kế mã thông báo: Tiềm năng lớn, cạm bẫy, giải pháp và triển vọng trong tương lai

Những cạm bẫy phổ biến

Quá nhấn mạnh vào token. Mã thông báo không phải là giao thức và mã thông báo không phải là mục tiêu của bạn. Nó chỉ nên là một công cụ.

Làm thế nào để thoát khỏi cái bẫy này? Hãy tự hỏi: Hệ thống này sẽ hoạt động như thế nào nếu không có token? Nếu hệ thống hoàn toàn thất bại khi bạn loại bỏ hoàn toàn các mã thông báo thì có thể bạn đang quá nhấn mạnh vai trò của các mã thông báo. Sẽ tốt hơn nếu một vài phần chính của hệ thống bị lỗi, mã thông báo của bạn có ý nghĩa quan trọng và cần thiết cho sự cân bằng tổng thể, nhưng hệ thống vẫn mạch lạc nếu không có nó. Vì vậy, bạn vẫn nên suy nghĩ về mục tiêu của hệ thống.

Không gian thiết kế là không giới hạn. Trong thiết kế, bạn có rất nhiều ý tưởng và rất nhiều khả năng mà bạn thậm chí không biết bắt đầu từ đâu vì có rất nhiều thứ có thể làm được. Điều này thường là do mục tiêu không rõ ràng nên cần phải điều chỉnh lại mục tiêu. Cũng có thể do bạn chưa hiểu rõ những giới hạn mà thế giới bên ngoài đặt ra cho mình hoặc do bạn chưa chấp nhận chúng.

Nếu bạn kết hợp những ràng buộc này, bạn sẽ thấy rằng không gian thiết kế co lại và trở nên rõ ràng hơn nhiều. Hai câu hỏi giúp hạn chế không gian thiết kế là bạn hãy tự hỏi mình: Ý tưởng mạnh mẽ mà bạn muốn xây dựng là gì? Đó có thể là một số ý tưởng sâu sắc, một số ưu điểm, một số thay đổi theo xu hướng của thời đại, v.v. Hãy tự hỏi khái niệm mạnh mẽ này là gì? Làm thế nào bạn có thể tận dụng tối đa nó và tập trung vào nó thay vì nghĩ đến toàn bộ hệ thống trước tiên? Một câu hỏi khác là: điểm yếu lớn nhất của thiết kế này là gì? Điều gì khiến bạn mất ngủ, đó là những điểm bạn nghĩ có thể không hiệu quả, những điểm bạn lo lắng, những điểm yếu chính và những hạn chế nào bạn có thể chấp nhận để cải thiện nó? Điều này có thể hạn chế rất nhiều không gian thiết kế.

Luôn cho cộng đồng biết. Có những thách thức trong việc thiết kế các bộ phận nhất định của hệ thống, đẩy tất cả chúng đến cộng đồng để giải quyết hoặc mong đợi các lực lượng vô hình sẽ lấp đầy những khoảng trống; bạn luôn mong đợi mọi người tìm ra vấn đề và giải quyết nó, điều này rất rủi ro. Bất chấp sự phổ biến của các hệ thống không được phép và những đổi mới đáng kinh ngạc đã xảy ra, bạn không thể dự đoán được hành động của cộng đồng cũng như không nên mong đợi họ giải quyết những vấn đề rõ ràng nhất trong hệ thống của bạn.

Có một số câu hỏi quan trọng mà bạn nên tự hỏi mình, chúng ta thực sự mong đợi điều gì từ cộng đồng của mình và chúng ta đang mang lại cho họ những gì? Yêu cầu chúng tôi cung cấp đủ token cho họ vẫn chưa đủ sao? Đúng hơn là chúng ta đã trao cho họ những quyền năng gì? Những khả năng nào được trao cho họ? Họ có quyền sở hữu gì? Họ có đủ quyền lực để cân bằng trách nhiệm này không?

Nếu bạn thực sự mong đợi họ sửa chữa một thứ gì đó, nếu bạn mong đợi những người có tham vọng khác thêm một số tiện ích mở rộng thú vị hoặc sửa chữa một số thành phần của hệ thống, thì trước tiên bạn phải tự hỏi mình, bạn có xây dựng ở đây không? Nếu bạn không làm như vậy vì nó không có đủ ưu điểm, đủ sức mạnh hoặc đủ tính linh hoạt thì đừng tìm đâu xa.

Phân loại mã thông báo

Mã thông báo là một công cụ trong giao thức, chúng là một công cụ và một giao thức, và trừu tượng hơn, chúng là một cấu trúc dữ liệu. Vậy làm thế nào để chúng ta thấy cấu trúc dữ liệu này được sử dụng trong các giao thức khác nhau? Chúng có thể được nhóm thành năm loại rất chung: Thanh toán, Biểu quyết, Các bên liên quan, Siêu dữ liệu và Yêu cầu.

Trả

Chức năng thanh toán được chia thành ba loại, loại thứ nhất là nội tệ của cộng đồng hoặc dự án. Chúng tôi chưa thấy nhiều trường hợp như thế này, nhưng có một vài ví dụ. Ví dụ, NguồnCred là một ví dụ thú vị, và FWB có thể đang di chuyển theo hướng này.

Nó khác với các phương thức thanh toán truyền thống như thanh toán bằng USD vì nó tồn tại trong một cộng đồng cụ thể có quyền kiểm soát tiền tệ và họ có thể sử dụng chính sách tiền tệ và các phương tiện khác đối với loại nội tệ này, chẳng hạn như loại tiền tệ này phải ổn định, Nên được gắn với giá trị của một số tài sản cụ thể khác, có thể họ đúc hoặc đốt nó dựa trên các mục tiêu cụ thể, trên toàn cộng đồng.

Hình thức thanh toán thứ hai và có lẽ là được sử dụng phổ biến nhất và được hiểu rõ nhất khi sử dụng tiền điện tử, là dưới dạng tài nguyên trực tuyến, Ethereum và Bitcoin cũng thuộc loại này. Bạn trả tiền cho sức mạnh tính toán, bộ nhớ hoặc một số tài nguyên mạng tiền điện tử khác. Chúng ta có EIP1559, đặt cược, thanh khoản, v.v. để xác định cách sử dụng mã thông báo để tính toán các tài nguyên khác nhau trong hệ thống, đặc biệt là tài nguyên máy tính.

Mã thông báo thanh toán thứ ba tồn tại dưới dạng tiền tệ trò chơi tương tự. Ví dụ: trò chơi, tài nguyên hoặc một số tài nguyên giao thức cần phải ổn định và cần được định giá, bởi vì nếu bạn sử dụng hệ thống và các tài nguyên này ổn định thì giá token cũng cần phải tương đối ổn định. Việc nguồn cung cấp ổn định hay không không quan trọng vì bạn chỉ sử dụng nó để triển khai một phần cụ thể trong ứng dụng của mình.

Vậy stablecoin nên được đặt ở đâu? Tất nhiên, một loại tiền tệ ổn định có thể được sử dụng để thanh toán theo ba cách trên. Nhưng điều khiến stablecoin trở thành stablecoin là cơ chế đằng sau nó giúp ổn định nó, vì vậy, stablecoin thường thuộc danh mục quyền sở hữu.

Quyền sở hữu

Nhìn chung có hai loại quyền sở hữu, trên chuỗi (tiền gửi) và ngoài chuỗi (quyền sở hữu). Mã thông báo gửi tiền thể hiện quyền sở hữu đối với các mã thông báo khác, một ví dụ là Unwwap LP mã thông báo, đó là một ERC-20 ở V2 và NFT ở V3. DAI, stablecoin xuất phát từ giao thức Maker, cũng là một khoản tiền gửi trên chuỗi vì bạn hoặc chủ sở hữu kho tiền sử dụng nó để yêu cầu tài sản thế chấp cơ bản của họ. Vì vậy, mã thông báo gửi tiền có nghĩa là nó có thể được sử dụng để yêu cầu các mã thông báo khác trong môi trường ngoài chuỗi.

Mã thông báo thứ hai thể hiện quyền sở hữu một số tài sản ngoài chuỗi, vì vậy đây có thể là mã thông báo tài sản trong thế giới thực, mã thông báo bất động sản hoặc thứ gì đó tương tự. Chúng tôi chưa thấy nhiều ví dụ về điều này. Một ví dụ hiện đại hơn là cái mà ngày nay được gọi là vật có thể đổi được, trong đó token có thể được trao đổi để lấy vật thể. Ví dụ: NFT được sử dụng để trao đổi tác phẩm nghệ thuật với tác phẩm nghệ thuật và NFT này thể hiện quyền sở hữu sân. Thậm chí còn có một số giao dịch thú vị nếu bạn muốn. Bạn có thể sử dụng các vật thể vật lý để kiểm soát NFT và kiểm soát quyền sở hữu NFT tiếp theo thông qua một số chức năng kỹ thuật số như chip.

Bỏ phiếu

Việc bỏ phiếu có thể được sử dụng để tài trợ cho các dự án, phân bổ nguồn lực, tức là thực hiện thanh toán hoặc chuyển khoản theo nhóm và nâng cấp phần mềm. Nó cũng có thể được sử dụng như thước đo sự đồng thuận của xã hội, chẳng hạn như việc lựa chọn người lãnh đạo để xác định kế hoạch tương lai của một dự án.

Lời hứa

Token có thể được thiết kế để nhận phần thưởng thông qua hợp đồng thông minh, không có thỏa thuận pháp lý nào ở đây, nhưng cơ chế hoạt động có nghĩa là token sẽ được hưởng lợi từ một số loại hoạt động trên chuỗi. Một ví dụ là Maker; nếu chủ sở hữu mã thông báo Maker đang thực hiện tốt công việc của họ và hệ thống hoạt động bình thường thì họ sẽ được hưởng lợi từ một số lợi nhuận; đây là cách thức của hợp đồng thông minh, cách thức thiết kế giao thức, khen thưởng sự quản trị tốt của cộng đồng.

Bạn cũng có thể tạo mã thông báo nhờ các thỏa thuận pháp lý cho phép bạn trả lại. Tất nhiên, bạn có thể tạo mã thông báo đại diện cho một phần vốn chủ sở hữu hoặc phần vốn chủ sở hữu trong một công ty với nhiều yêu cầu và hạn chế pháp lý khác nhau. Đã có lúc có những người về mặt lý thuyết có thể tạo ra mã thông báo bảo mật, mặc dù chúng tôi chưa thấy nhiều về điều đó.

Token cũng được sử dụng để bảo lãnh rủi ro để đổi lấy lợi nhuận. Maker sử dụng nguyên tắc này. Nếu có sự mất mát trong giao thức Maker, nhiều mã thông báo Maker sẽ được tạo ra, điều này làm giảm giá trị mà chủ sở hữu Maker nắm giữ. Bằng cách nắm giữ token Maker, chủ sở hữu sẽ gặp phải một số rủi ro, đây là một phần nguyên nhân thúc đẩy chủ sở hữu Maker thúc đẩy xây dựng cộng đồng. Nếu họ muốn thấy khoản đầu tư của mình tăng giá trị, họ cần hỗ trợ phát triển hệ thống này.

Siêu dữ liệu

Đầu tiên, mã thông báo đại diện cho tư cách thành viên, xác định xem bạn có quyền truy cập vào một không gian cụ thể hay không, bạn có thuộc cộng đồng cụ thể hay bạn thuộc một số nhóm nào đó. Các giao thức hoặc công cụ do một số bên thứ ba viết có thể sử dụng thuộc tính thành viên này theo bất kỳ cách nào mà không được phép. Ví dụ: một số cộng đồng NFT có thể quyết định rằng chỉ những người nắm giữ mã thông báo mới có thể tham gia, chẳng hạn như nắm giữ mã thông báo này. Những cái cung cấp chức năng cụ thể, v.v. Tư cách thành viên là một loại siêu dữ liệu thú vị được cung cấp bởi mã thông báo.

Token cũng đại diện cho danh tiếng. Một số người đang tranh luận liệu danh tiếng có nên được chuyển nhượng hay không. Nhưng nó có thể đồng nhất trong một số trường hợp và không đồng nhất ở những trường hợp khác. Nếu nó đề cập đến thành tích của bạn, nó có thể không đồng nhất; nếu nó đề cập đến các nguồn thông tin, tín dụng hoặc các loại hệ thống tính điểm tín dụng khác nhau thì nó có thể đồng nhất. Đây là dữ liệu liên tục nên nó là một loại siêu dữ liệu.

Mã thông báo cũng đại diện cho danh tính hoặc tài liệu tham khảo. Ens là một ví dụ về điều này, ENS tên có thể trỏ đến địa chỉ và có thể được cập nhật, không giống như DNS hệ thống.

Dữ liệu ngoài chuỗi có thể là một loại siêu dữ liệu. Một ví dụ sẽ là KYC ngoài chuỗi hoặc một số loại chứng chỉ có thể xác minh được. Một ví dụ điển hình khác là bằng tốt nghiệp hoặc bằng cấp học thuật. Ai đó sẽ trao cho bạn chứng chỉ này và nó được hiển thị công khai, có thể theo dõi và xác thực. Chúng tôi chưa thấy nhiều trường hợp thể hiện quyền và khả năng trên chuỗi.

Giống như một số thực thể cấp cho bạn các quyền một cách rõ ràng, chẳng hạn như khả năng gọi một hàm, thay đổi một đoạn mã hoặc chuyển một thứ gì đó trên chuỗi. Thậm chí có thể sử dụng mã thông báo làm giao diện, chúng tôi đã xem các ví dụ về điều này, trong đó bạn không chỉ có thể đặt dữ liệu SVG vào URI mã thông báo mà còn có thể đặt toàn bộ trang web HTML vào đó và thậm chí bạn có thể đặt một chút JavaScript. Bạn có thể đặt giao diện trong nft, điều khiển giao diện hoặc nhúng giao diện vào đối tượng mà mọi người sở hữu và chuyển giao.

Một ví dụ thú vị là BÍP3R, trong đó trước tiên bạn đúc văn bản thành NFT, sau đó bạn có thể truyền văn bản đó tới người khác BÍP3R người nắm giữ bằng cách sở hữu nó. Những văn bản này được hiển thị trên hình ảnh nhỏ của BÍP3R. Khi bạn có một BÍP3R máy, bạn cũng có thể gửi tin nhắn trực tiếp đến máy khác BÍP3R giá đỡ máy, giống như chỉ sử dụng XMTB.

Vậy chức năng của token này là gì? Đây là mã thông báo thành viên và với mã thông báo này, bạn có thể nhận được tin nhắn. Bất kỳ giao diện ví nào thể hiện chính xác các URL động đều có thể hiển thị bất kỳ thông báo nào bạn nhận được miễn là nó hỗ trợ tiêu chuẩn này.

Đây cũng là mã thông báo nhận dạng vì với tư cách là người nắm giữ BP, bạn có thể nhận và gửi thông tin. Vì vậy, điều này chỉ xảy ra trong bộ đó. Đó cũng là mã thông báo nhận dạng vì họ nhắn tin cho bạn bằng ID mã thông báo BP của bạn. Đồng thời, nó cũng tồn tại dưới dạng một giao diện và có thể xem được thông tin liên quan đến NFT.

Thiết kế mã thông báo: Tiềm năng lớn, cạm bẫy, giải pháp và triển vọng trong tương lai

Lý thuyết cây công nghệ

Chúng ta có thể thấy rằng một số lĩnh vực đã đạt được tiến bộ vượt bậc, chẳng hạn như mã thông báo làm phương tiện thanh toán và tài nguyên mạng, trong khi một số lĩnh vực vẫn chưa phát triển, chẳng hạn như giao diện và siêu dữ liệu. Vậy tại sao lại như vậy?

Tại sao một số sản phẩm xuất hiện vào những thời điểm nhất định và tại sao một số sản phẩm mất nhiều thời gian xuất hiện hơn những sản phẩm khác? Lấy giao thức cho vay làm ví dụ, và thật khó để tưởng tượng giao thức cho vay hoạt động mà không có stablecoin. Điều này là do khi bạn cho vay nợ trong một hợp đồng cho vay, bạn muốn thể hiện nó bằng một tài sản ổn định vì bạn có thể dự đoán giá của tài sản này, vì vậy chúng tôi cần stablecoin trước khi thực sự có thể có một hợp đồng cho vay.

Tương tự, chúng tôi cũng có một hợp đồng cho vay yêu cầu AMM bởi vì nếu bạn muốn sử dụng hợp đồng cho vay để làm đòn bẩy, đặc biệt là hợp đồng cho vay đơn giản ban đầu, bạn cần có khả năng vay các tài sản, chẳng hạn như stablecoin. Nếu bạn muốn trao đổi stablecoin đó lấy tài sản đó thật nhanh chóng và bạn muốn có nhiều khả năng hiển thị hơn thì bạn cần có AMM. Mãi cho đến khi chúng ta có các AMM và stablecoin hoạt động thì các giao thức cho vay mới phát triển.

Nhưng làm thế nào để có được AMM và stablecoin hoạt động? Điều này khó thực hiện nếu không có tiêu chuẩn token có khả năng tương tác vì stablecoin, AMM và tất cả các hệ thống xung quanh chúng cần hiểu cách các dự án khác giao tiếp với chúng. Và để có mã thông báo ERC-20, bạn cần có hợp đồng thông minh được lập trình đầy đủ. Bạn có thể không thực sự cần chúng, nhưng đó là cách chúng xuất hiện lần đầu tiên trên Ethereum, vì Ethereum được ra mắt mà không có tiêu chuẩn mã thông báo ERC-20. Chúng tôi cần khả năng lập trình đầy đủ để có thể có đủ không gian thiết kế mở; tất nhiên, điều này có thể được thảo luận thêm. Nhưng tóm lại, tôi nghĩ có những cây công nghệ trong đó một số công nghệ nhất định là điều kiện tiên quyết cho những cây khác.

Có hai câu hỏi ở đây: công nghệ chính nào sẽ mở khóa các ứng dụng và giao thức trong tương lai? Nghĩa là, chúng ta cần những công nghệ nào để phát triển hệ thống danh tiếng hữu ích hoặc giao diện phi tập trung và không cần tin cậy? Và câu hỏi thứ hai hơi giống câu hỏi ngược đầu tiên, những ứng dụng và giao thức nào sẽ được mở khóa bởi công nghệ sắp tới?

Ví dụ: trừu tượng hóa tài khoản, EIP4844, cây dọc, máy học không kiến ​​thức, v.v. Những câu hỏi này rất thú vị vì nếu chúng ta có thể thấy trước sự xuất hiện của một số công nghệ giúp giảm bớt hoặc đưa ra các hạn chế về thiết kế, thì điều đó sẽ thay đổi thiết kế của chúng ta như thế nào? Nếu có những công nghệ cụ thể có thể giảm bớt những hạn chế, chúng ta có nên dành năng lượng để phát triển chúng không?

Nếu bạn coi mọi thứ như một cây công nghệ, nó có thể giúp chúng ta suy luận về những gì sắp xảy ra hoặc những gì bạn cần để đạt được tập hợp các ràng buộc mà bạn muốn. Vì vậy, liên kết nó với điểm hạn chế ban đầu của tôi, tôi nghĩ công nghệ mới sẽ giảm bớt những hạn chế mà chúng ta gặp phải trước đây. Ví dụ: nếu không có tiêu chuẩn ERC-20 thì hạn chế đối với bất kỳ thiết kế AMM hoặc stablecoin nào sẽ là nó cần phải đưa ra một tiêu chuẩn hoặc có thể đáp ứng được nhiều thiết kế khác nhau.

Hãy tưởng tượng việc thiết kế một AMM có mục đích chung nhưng không sử dụng một tiêu chuẩn token cụ thể thì sẽ rất rất khó khăn. Tôi nghĩ rằng đây sẽ là một hạn chế gần như không thể vượt qua, nhưng việc có tiêu chuẩn về khả năng tương tác có nghĩa là chúng tôi có thể hỗ trợ trực tiếp các mã thông báo ERC-20, điều này hạn chế không gian thiết kế và khiến điều đó trở nên khả thi.

Nếu chúng ta có thể dự đoán những công nghệ nào sẽ xuất hiện trong tương lai, thì điều này ảnh hưởng như thế nào đến những hạn chế đối với thiết kế giao thức của chúng ta? Nếu chúng ta có những mục tiêu cụ thể hoặc những hạn chế cụ thể, chúng ta cần công nghệ gì? Công nghệ sẽ có thể giảm bớt những hạn chế này và hiện thực hóa những mục tiêu này thông qua các cơ chế mới.

KHUYẾN CÁO: Thông tin trên trang web này được cung cấp dưới dạng bình luận chung về thị trường và không cấu thành lời khuyên đầu tư. Chúng tôi khuyến khích bạn tự nghiên cứu trước khi đầu tư.

Hãy cùng chúng tôi theo dõi tin tức: https://linktr.ee/coincu

website: coincu.com

Harold

đồng xu Tin tức

Thiết kế mã thông báo: Tiềm năng lớn, cạm bẫy, giải pháp và triển vọng trong tương lai

Mã thông báo là một công cụ mới rất thú vị, hữu ích và mạnh mẽ giúp thay đổi cách thiết kế các giao thức và những gì có thể đạt được, nhưng mã thông báo không phải là trọng tâm của thiết kế. Thiết kế giao thức ngày nay giống “thuật giả kim” hơn là một môn học vì sự hiểu biết của các nhà thiết kế còn lâu mới toàn diện hay khoa học, và hầu hết các dự án vẫn đòi hỏi nhiều thử nghiệm.
Phiên này được chia thành ba phần, bắt đầu với những tư duy chung trong thiết kế mã thông báo, tiếp theo là phân loại mã thông báo, nói cụ thể hơn về mã thông báo thực sự là gì và cách chúng ta có thể nghĩ về việc phát triển và nâng cao khả năng của chúng. Cuối cùng là lý thuyết cây công nghệ, cách sử dụng công nghệ để thiết kế của chúng ta dễ thành công hơn.
Thiết kế mã thông báo: Tiềm năng lớn, cạm bẫy, giải pháp và triển vọng trong tương lai

Chế độ suy nghĩ

Đầu tiên, mã thông báo dành cho giao thức, chúng là một công cụ, một phần của quy trình thiết kế và chúng không phải là mục tiêu. Nếu bạn muốn làm điều gì đó phi tập trung, mã thông báo có thể là một phần trong đó vì thật tuyệt vời khi mọi người có quyền sở hữu giao thức và cũng để giúp mọi người tuân thủ quy định.

Ba giai đoạn thiết kế

Giai đoạn 1: Xác định mục tiêu của bạn

Mục tiêu là một mô tả ngắn gọn về kết quả của một giao thức hợp lệ và phải rõ ràng liệu một thiết kế cụ thể có đạt được mục tiêu đó hay không. Vì vậy chúng ta nên có sự phân biệt thật rõ ràng giữa thành công và thất bại. Nếu không rõ mục tiêu của chúng ta là gì, chúng ta cần phải bắt đầu lại và quên đi các token. Lý tưởng nhất là các mục tiêu có thể đo lường được, ngay cả khi chúng ta chưa chắc chắn về cách đo lường thành công.

Giai đoạn 2: Đưa ra các hạn chế

Nói chung, có hai loại ràng buộc, một là ràng buộc nội tại và một là ràng buộc ngoại sinh: các ràng buộc nội tại là những ràng buộc mà chúng ta chọn để đơn giản hóa quá trình thiết kế vì có một số sự đánh đổi phải được thực hiện hoặc chúng là sự đánh đổi trong chúng tôi.

Những ràng buộc nội tại có thể đến từ nhiều nguồn nhưng thường do chính người thiết kế xác định. Những ràng buộc ngoại sinh được áp đặt lên bạn bởi bản chất, tình trạng công nghệ, các quy định và tất cả những thứ khác. Tôi sẽ nói về nó sau.

Giai đoạn 3: Cơ chế thiết kế

Sau khi có ràng buộc và mục tiêu, chúng ta có thể suy nghĩ rõ ràng về cơ chế sẽ đáp ứng mục tiêu đó. Bây giờ, bất cứ khi nào chúng ta nghĩ về một người thợ cơ khí, chúng ta phải thực sự rõ ràng liệu nó có vi phạm những hạn chế đó hay không và đưa chúng ta đến gần hơn với mục tiêu đó. Một giao thức sẽ là một tập hợp các cơ chế, tất cả đều hướng tới một mục tiêu cụ thể theo một số ràng buộc.

Hãy MakerDAO như một ví dụ. Mục tiêu của họ là phát triển ổn định Ethereum tài sản bản địa. Tất nhiên, có nhiều cách giải thích về sự ổn định và bản chất. Hạn chế của chúng là giá được chốt bằng USD, được hỗ trợ hoàn toàn bởi tài sản gốc trên chuỗi, v.v.

Thiết kế mã thông báo: Tiềm năng lớn, cạm bẫy, giải pháp và triển vọng trong tương lai

Những cạm bẫy phổ biến

Quá nhấn mạnh vào token. Mã thông báo không phải là giao thức và mã thông báo không phải là mục tiêu của bạn. Nó chỉ nên là một công cụ.

Làm thế nào để thoát khỏi cái bẫy này? Hãy tự hỏi: Hệ thống này sẽ hoạt động như thế nào nếu không có token? Nếu hệ thống hoàn toàn thất bại khi bạn loại bỏ hoàn toàn các mã thông báo thì có thể bạn đang quá nhấn mạnh vai trò của các mã thông báo. Sẽ tốt hơn nếu một vài phần chính của hệ thống bị lỗi, mã thông báo của bạn có ý nghĩa quan trọng và cần thiết cho sự cân bằng tổng thể, nhưng hệ thống vẫn mạch lạc nếu không có nó. Vì vậy, bạn vẫn nên suy nghĩ về mục tiêu của hệ thống.

Không gian thiết kế là không giới hạn. Trong thiết kế, bạn có rất nhiều ý tưởng và rất nhiều khả năng mà bạn thậm chí không biết bắt đầu từ đâu vì có rất nhiều thứ có thể làm được. Điều này thường là do mục tiêu không rõ ràng nên cần phải điều chỉnh lại mục tiêu. Cũng có thể do bạn chưa hiểu rõ những giới hạn mà thế giới bên ngoài đặt ra cho mình hoặc do bạn chưa chấp nhận chúng.

Nếu bạn kết hợp những ràng buộc này, bạn sẽ thấy rằng không gian thiết kế co lại và trở nên rõ ràng hơn nhiều. Hai câu hỏi giúp hạn chế không gian thiết kế là bạn hãy tự hỏi mình: Ý tưởng mạnh mẽ mà bạn muốn xây dựng là gì? Đó có thể là một số ý tưởng sâu sắc, một số ưu điểm, một số thay đổi theo xu hướng của thời đại, v.v. Hãy tự hỏi khái niệm mạnh mẽ này là gì? Làm thế nào bạn có thể tận dụng tối đa nó và tập trung vào nó thay vì nghĩ đến toàn bộ hệ thống trước tiên? Một câu hỏi khác là: điểm yếu lớn nhất của thiết kế này là gì? Điều gì khiến bạn mất ngủ, đó là những điểm bạn nghĩ có thể không hiệu quả, những điểm bạn lo lắng, những điểm yếu chính và những hạn chế nào bạn có thể chấp nhận để cải thiện nó? Điều này có thể hạn chế rất nhiều không gian thiết kế.

Luôn cho cộng đồng biết. Có những thách thức trong việc thiết kế các bộ phận nhất định của hệ thống, đẩy tất cả chúng đến cộng đồng để giải quyết hoặc mong đợi các lực lượng vô hình sẽ lấp đầy những khoảng trống; bạn luôn mong đợi mọi người tìm ra vấn đề và giải quyết nó, điều này rất rủi ro. Bất chấp sự phổ biến của các hệ thống không được phép và những đổi mới đáng kinh ngạc đã xảy ra, bạn không thể dự đoán được hành động của cộng đồng cũng như không nên mong đợi họ giải quyết những vấn đề rõ ràng nhất trong hệ thống của bạn.

Có một số câu hỏi quan trọng mà bạn nên tự hỏi mình, chúng ta thực sự mong đợi điều gì từ cộng đồng của mình và chúng ta đang mang lại cho họ những gì? Yêu cầu chúng tôi cung cấp đủ token cho họ vẫn chưa đủ sao? Đúng hơn là chúng ta đã trao cho họ những quyền năng gì? Những khả năng nào được trao cho họ? Họ có quyền sở hữu gì? Họ có đủ quyền lực để cân bằng trách nhiệm này không?

Nếu bạn thực sự mong đợi họ sửa chữa một thứ gì đó, nếu bạn mong đợi những người có tham vọng khác thêm một số tiện ích mở rộng thú vị hoặc sửa chữa một số thành phần của hệ thống, thì trước tiên bạn phải tự hỏi mình, bạn có xây dựng ở đây không? Nếu bạn không làm như vậy vì nó không có đủ ưu điểm, đủ sức mạnh hoặc đủ tính linh hoạt thì đừng tìm đâu xa.

Phân loại mã thông báo

Mã thông báo là một công cụ trong giao thức, chúng là một công cụ và một giao thức, và trừu tượng hơn, chúng là một cấu trúc dữ liệu. Vậy làm thế nào để chúng ta thấy cấu trúc dữ liệu này được sử dụng trong các giao thức khác nhau? Chúng có thể được nhóm thành năm loại rất chung: Thanh toán, Biểu quyết, Các bên liên quan, Siêu dữ liệu và Yêu cầu.

Trả

Chức năng thanh toán được chia thành ba loại, loại thứ nhất là nội tệ của cộng đồng hoặc dự án. Chúng tôi chưa thấy nhiều trường hợp như thế này, nhưng có một vài ví dụ. Ví dụ, NguồnCred là một ví dụ thú vị, và FWB có thể đang di chuyển theo hướng này.

Nó khác với các phương thức thanh toán truyền thống như thanh toán bằng USD vì nó tồn tại trong một cộng đồng cụ thể có quyền kiểm soát tiền tệ và họ có thể sử dụng chính sách tiền tệ và các phương tiện khác đối với loại nội tệ này, chẳng hạn như loại tiền tệ này phải ổn định, Nên được gắn với giá trị của một số tài sản cụ thể khác, có thể họ đúc hoặc đốt nó dựa trên các mục tiêu cụ thể, trên toàn cộng đồng.

Hình thức thanh toán thứ hai và có lẽ là được sử dụng phổ biến nhất và được hiểu rõ nhất khi sử dụng tiền điện tử, là dưới dạng tài nguyên trực tuyến, Ethereum và Bitcoin cũng thuộc loại này. Bạn trả tiền cho sức mạnh tính toán, bộ nhớ hoặc một số tài nguyên mạng tiền điện tử khác. Chúng ta có EIP1559, đặt cược, thanh khoản, v.v. để xác định cách sử dụng mã thông báo để tính toán các tài nguyên khác nhau trong hệ thống, đặc biệt là tài nguyên máy tính.

Mã thông báo thanh toán thứ ba tồn tại dưới dạng tiền tệ trò chơi tương tự. Ví dụ: trò chơi, tài nguyên hoặc một số tài nguyên giao thức cần phải ổn định và cần được định giá, bởi vì nếu bạn sử dụng hệ thống và các tài nguyên này ổn định thì giá token cũng cần phải tương đối ổn định. Việc nguồn cung cấp ổn định hay không không quan trọng vì bạn chỉ sử dụng nó để triển khai một phần cụ thể trong ứng dụng của mình.

Vậy stablecoin nên được đặt ở đâu? Tất nhiên, một loại tiền tệ ổn định có thể được sử dụng để thanh toán theo ba cách trên. Nhưng điều khiến stablecoin trở thành stablecoin là cơ chế đằng sau nó giúp ổn định nó, vì vậy, stablecoin thường thuộc danh mục quyền sở hữu.

Quyền sở hữu

Nhìn chung có hai loại quyền sở hữu, trên chuỗi (tiền gửi) và ngoài chuỗi (quyền sở hữu). Mã thông báo gửi tiền thể hiện quyền sở hữu đối với các mã thông báo khác, một ví dụ là Unwwap LP mã thông báo, đó là một ERC-20 ở V2 và NFT ở V3. DAI, stablecoin xuất phát từ giao thức Maker, cũng là một khoản tiền gửi trên chuỗi vì bạn hoặc chủ sở hữu kho tiền sử dụng nó để yêu cầu tài sản thế chấp cơ bản của họ. Vì vậy, mã thông báo gửi tiền có nghĩa là nó có thể được sử dụng để yêu cầu các mã thông báo khác trong môi trường ngoài chuỗi.

Mã thông báo thứ hai thể hiện quyền sở hữu một số tài sản ngoài chuỗi, vì vậy đây có thể là mã thông báo tài sản trong thế giới thực, mã thông báo bất động sản hoặc thứ gì đó tương tự. Chúng tôi chưa thấy nhiều ví dụ về điều này. Một ví dụ hiện đại hơn là cái mà ngày nay được gọi là vật có thể đổi được, trong đó token có thể được trao đổi để lấy vật thể. Ví dụ: NFT được sử dụng để trao đổi tác phẩm nghệ thuật với tác phẩm nghệ thuật và NFT này thể hiện quyền sở hữu sân. Thậm chí còn có một số giao dịch thú vị nếu bạn muốn. Bạn có thể sử dụng các vật thể vật lý để kiểm soát NFT và kiểm soát quyền sở hữu NFT tiếp theo thông qua một số chức năng kỹ thuật số như chip.

Bỏ phiếu

Việc bỏ phiếu có thể được sử dụng để tài trợ cho các dự án, phân bổ nguồn lực, tức là thực hiện thanh toán hoặc chuyển khoản theo nhóm và nâng cấp phần mềm. Nó cũng có thể được sử dụng như thước đo sự đồng thuận của xã hội, chẳng hạn như việc lựa chọn người lãnh đạo để xác định kế hoạch tương lai của một dự án.

Lời hứa

Token có thể được thiết kế để nhận phần thưởng thông qua hợp đồng thông minh, không có thỏa thuận pháp lý nào ở đây, nhưng cơ chế hoạt động có nghĩa là token sẽ được hưởng lợi từ một số loại hoạt động trên chuỗi. Một ví dụ là Maker; nếu chủ sở hữu mã thông báo Maker đang thực hiện tốt công việc của họ và hệ thống hoạt động bình thường thì họ sẽ được hưởng lợi từ một số lợi nhuận; đây là cách thức của hợp đồng thông minh, cách thức thiết kế giao thức, khen thưởng sự quản trị tốt của cộng đồng.

Bạn cũng có thể tạo mã thông báo nhờ các thỏa thuận pháp lý cho phép bạn trả lại. Tất nhiên, bạn có thể tạo mã thông báo đại diện cho một phần vốn chủ sở hữu hoặc phần vốn chủ sở hữu trong một công ty với nhiều yêu cầu và hạn chế pháp lý khác nhau. Đã có lúc có những người về mặt lý thuyết có thể tạo ra mã thông báo bảo mật, mặc dù chúng tôi chưa thấy nhiều về điều đó.

Token cũng được sử dụng để bảo lãnh rủi ro để đổi lấy lợi nhuận. Maker sử dụng nguyên tắc này. Nếu có sự mất mát trong giao thức Maker, nhiều mã thông báo Maker sẽ được tạo ra, điều này làm giảm giá trị mà chủ sở hữu Maker nắm giữ. Bằng cách nắm giữ token Maker, chủ sở hữu sẽ gặp phải một số rủi ro, đây là một phần nguyên nhân thúc đẩy chủ sở hữu Maker thúc đẩy xây dựng cộng đồng. Nếu họ muốn thấy khoản đầu tư của mình tăng giá trị, họ cần hỗ trợ phát triển hệ thống này.

Siêu dữ liệu

Đầu tiên, mã thông báo đại diện cho tư cách thành viên, xác định xem bạn có quyền truy cập vào một không gian cụ thể hay không, bạn có thuộc cộng đồng cụ thể hay bạn thuộc một số nhóm nào đó. Các giao thức hoặc công cụ do một số bên thứ ba viết có thể sử dụng thuộc tính thành viên này theo bất kỳ cách nào mà không được phép. Ví dụ: một số cộng đồng NFT có thể quyết định rằng chỉ những người nắm giữ mã thông báo mới có thể tham gia, chẳng hạn như nắm giữ mã thông báo này. Những cái cung cấp chức năng cụ thể, v.v. Tư cách thành viên là một loại siêu dữ liệu thú vị được cung cấp bởi mã thông báo.

Token cũng đại diện cho danh tiếng. Một số người đang tranh luận liệu danh tiếng có nên được chuyển nhượng hay không. Nhưng nó có thể đồng nhất trong một số trường hợp và không đồng nhất ở những trường hợp khác. Nếu nó đề cập đến thành tích của bạn, nó có thể không đồng nhất; nếu nó đề cập đến các nguồn thông tin, tín dụng hoặc các loại hệ thống tính điểm tín dụng khác nhau thì nó có thể đồng nhất. Đây là dữ liệu liên tục nên nó là một loại siêu dữ liệu.

Mã thông báo cũng đại diện cho danh tính hoặc tài liệu tham khảo. Ens là một ví dụ về điều này, ENS tên có thể trỏ đến địa chỉ và có thể được cập nhật, không giống như DNS hệ thống.

Dữ liệu ngoài chuỗi có thể là một loại siêu dữ liệu. Một ví dụ sẽ là KYC ngoài chuỗi hoặc một số loại chứng chỉ có thể xác minh được. Một ví dụ điển hình khác là bằng tốt nghiệp hoặc bằng cấp học thuật. Ai đó sẽ trao cho bạn chứng chỉ này và nó được hiển thị công khai, có thể theo dõi và xác thực. Chúng tôi chưa thấy nhiều trường hợp thể hiện quyền và khả năng trên chuỗi.

Giống như một số thực thể cấp cho bạn các quyền một cách rõ ràng, chẳng hạn như khả năng gọi một hàm, thay đổi một đoạn mã hoặc chuyển một thứ gì đó trên chuỗi. Thậm chí có thể sử dụng mã thông báo làm giao diện, chúng tôi đã xem các ví dụ về điều này, trong đó bạn không chỉ có thể đặt dữ liệu SVG vào URI mã thông báo mà còn có thể đặt toàn bộ trang web HTML vào đó và thậm chí bạn có thể đặt một chút JavaScript. Bạn có thể đặt giao diện trong nft, điều khiển giao diện hoặc nhúng giao diện vào đối tượng mà mọi người sở hữu và chuyển giao.

Một ví dụ thú vị là BÍP3R, trong đó trước tiên bạn đúc văn bản thành NFT, sau đó bạn có thể truyền văn bản đó tới người khác BÍP3R người nắm giữ bằng cách sở hữu nó. Những văn bản này được hiển thị trên hình ảnh nhỏ của BÍP3R. Khi bạn có một BÍP3R máy, bạn cũng có thể gửi tin nhắn trực tiếp đến máy khác BÍP3R giá đỡ máy, giống như chỉ sử dụng XMTB.

Vậy chức năng của token này là gì? Đây là mã thông báo thành viên và với mã thông báo này, bạn có thể nhận được tin nhắn. Bất kỳ giao diện ví nào thể hiện chính xác các URL động đều có thể hiển thị bất kỳ thông báo nào bạn nhận được miễn là nó hỗ trợ tiêu chuẩn này.

Đây cũng là mã thông báo nhận dạng vì với tư cách là người nắm giữ BP, bạn có thể nhận và gửi thông tin. Vì vậy, điều này chỉ xảy ra trong bộ đó. Đó cũng là mã thông báo nhận dạng vì họ nhắn tin cho bạn bằng ID mã thông báo BP của bạn. Đồng thời, nó cũng tồn tại dưới dạng một giao diện và có thể xem được thông tin liên quan đến NFT.

Thiết kế mã thông báo: Tiềm năng lớn, cạm bẫy, giải pháp và triển vọng trong tương lai

Lý thuyết cây công nghệ

Chúng ta có thể thấy rằng một số lĩnh vực đã đạt được tiến bộ vượt bậc, chẳng hạn như mã thông báo làm phương tiện thanh toán và tài nguyên mạng, trong khi một số lĩnh vực vẫn chưa phát triển, chẳng hạn như giao diện và siêu dữ liệu. Vậy tại sao lại như vậy?

Tại sao một số sản phẩm xuất hiện vào những thời điểm nhất định và tại sao một số sản phẩm mất nhiều thời gian xuất hiện hơn những sản phẩm khác? Lấy giao thức cho vay làm ví dụ, và thật khó để tưởng tượng giao thức cho vay hoạt động mà không có stablecoin. Điều này là do khi bạn cho vay nợ trong một hợp đồng cho vay, bạn muốn thể hiện nó bằng một tài sản ổn định vì bạn có thể dự đoán giá của tài sản này, vì vậy chúng tôi cần stablecoin trước khi thực sự có thể có một hợp đồng cho vay.

Tương tự, chúng tôi cũng có một hợp đồng cho vay yêu cầu AMM bởi vì nếu bạn muốn sử dụng hợp đồng cho vay để làm đòn bẩy, đặc biệt là hợp đồng cho vay đơn giản ban đầu, bạn cần có khả năng vay các tài sản, chẳng hạn như stablecoin. Nếu bạn muốn trao đổi stablecoin đó lấy tài sản đó thật nhanh chóng và bạn muốn có nhiều khả năng hiển thị hơn thì bạn cần có AMM. Mãi cho đến khi chúng ta có các AMM và stablecoin hoạt động thì các giao thức cho vay mới phát triển.

Nhưng làm thế nào để có được AMM và stablecoin hoạt động? Điều này khó thực hiện nếu không có tiêu chuẩn token có khả năng tương tác vì stablecoin, AMM và tất cả các hệ thống xung quanh chúng cần hiểu cách các dự án khác giao tiếp với chúng. Và để có mã thông báo ERC-20, bạn cần có hợp đồng thông minh được lập trình đầy đủ. Bạn có thể không thực sự cần chúng, nhưng đó là cách chúng xuất hiện lần đầu tiên trên Ethereum, vì Ethereum được ra mắt mà không có tiêu chuẩn mã thông báo ERC-20. Chúng tôi cần khả năng lập trình đầy đủ để có thể có đủ không gian thiết kế mở; tất nhiên, điều này có thể được thảo luận thêm. Nhưng tóm lại, tôi nghĩ có những cây công nghệ trong đó một số công nghệ nhất định là điều kiện tiên quyết cho những cây khác.

Có hai câu hỏi ở đây: công nghệ chính nào sẽ mở khóa các ứng dụng và giao thức trong tương lai? Nghĩa là, chúng ta cần những công nghệ nào để phát triển hệ thống danh tiếng hữu ích hoặc giao diện phi tập trung và không cần tin cậy? Và câu hỏi thứ hai hơi giống câu hỏi ngược đầu tiên, những ứng dụng và giao thức nào sẽ được mở khóa bởi công nghệ sắp tới?

Ví dụ: trừu tượng hóa tài khoản, EIP4844, cây dọc, máy học không kiến ​​thức, v.v. Những câu hỏi này rất thú vị vì nếu chúng ta có thể thấy trước sự xuất hiện của một số công nghệ giúp giảm bớt hoặc đưa ra các hạn chế về thiết kế, thì điều đó sẽ thay đổi thiết kế của chúng ta như thế nào? Nếu có những công nghệ cụ thể có thể giảm bớt những hạn chế, chúng ta có nên dành năng lượng để phát triển chúng không?

Nếu bạn coi mọi thứ như một cây công nghệ, nó có thể giúp chúng ta suy luận về những gì sắp xảy ra hoặc những gì bạn cần để đạt được tập hợp các ràng buộc mà bạn muốn. Vì vậy, liên kết nó với điểm hạn chế ban đầu của tôi, tôi nghĩ công nghệ mới sẽ giảm bớt những hạn chế mà chúng ta gặp phải trước đây. Ví dụ: nếu không có tiêu chuẩn ERC-20 thì hạn chế đối với bất kỳ thiết kế AMM hoặc stablecoin nào sẽ là nó cần phải đưa ra một tiêu chuẩn hoặc có thể đáp ứng được nhiều thiết kế khác nhau.

Hãy tưởng tượng việc thiết kế một AMM có mục đích chung nhưng không sử dụng một tiêu chuẩn token cụ thể thì sẽ rất rất khó khăn. Tôi nghĩ rằng đây sẽ là một hạn chế gần như không thể vượt qua, nhưng việc có tiêu chuẩn về khả năng tương tác có nghĩa là chúng tôi có thể hỗ trợ trực tiếp các mã thông báo ERC-20, điều này hạn chế không gian thiết kế và khiến điều đó trở nên khả thi.

Nếu chúng ta có thể dự đoán những công nghệ nào sẽ xuất hiện trong tương lai, thì điều này ảnh hưởng như thế nào đến những hạn chế đối với thiết kế giao thức của chúng ta? Nếu chúng ta có những mục tiêu cụ thể hoặc những hạn chế cụ thể, chúng ta cần công nghệ gì? Công nghệ sẽ có thể giảm bớt những hạn chế này và hiện thực hóa những mục tiêu này thông qua các cơ chế mới.

KHUYẾN CÁO: Thông tin trên trang web này được cung cấp dưới dạng bình luận chung về thị trường và không cấu thành lời khuyên đầu tư. Chúng tôi khuyến khích bạn tự nghiên cứu trước khi đầu tư.

Hãy cùng chúng tôi theo dõi tin tức: https://linktr.ee/coincu

website: coincu.com

Harold

đồng xu Tin tức

Đã truy cập 72 lần, 1 lần truy cập hôm nay