Nội dung này được chia thành ba phần:

Đầu tiên là những kiểu suy nghĩ phổ biến trong thiết kế token.

Thứ hai 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 tôi 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 thành công hơn.

1. Mô hình tư duy

Đầu tiên, mã thông báo ở đó để phục vụ giao thức, chúng chỉ là một công cụ và một phần của quá trình thiết kế, 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 của nó vì nó rất hữu ích trong việc trao cho mọi người quyền sở hữu giao thức và cũng giúp mọi người được liên kết.

Ba giai đoạn thiết kế

Khi tương tác với các công ty trong danh mục đầu tư, tôi đã xác định được ba giai đoạn trong quá trình thiết kế thành công.

Giai đoạn đầu tiên: xác định mục tiêu. Mục tiêu là sự mô tả ngắn gọn về kết quả của một quy trình hiệu quả, mục tiêu này phải rõ ràng về việc liệu 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 mã thông báo. 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 hạn chế, một là hạn chế nội sinh và hai là hạn chế ngoại sinh: hạn chế nội sinh là những hạn chế chúng ta chọn để đơn giản hóa quá trình thiết kế vì cần phải thực hiện một số sự đánh đổi, hoặc Bản thân chúng là sự đánh đổi . Ví dụ: chúng ta có thể chọn giới hạn những tính năng thú vị mà chúng ta thích. Những ràng buộc nội sinh có thể đến từ nhiều nguồn nhưng thường do chính người thiết kế quyết định. Những ràng buộc ngoại sinh được áp đặt lên bạn bởi bản chất, điều kiện công nghệ, quy định và nhiều thứ khác nhau. Tôi sẽ nói chi tiết về nó sau.

Giai đoạn thứ ba: cơ chế thiết kế. Khi chúng ta có những ràng buộc và mục tiêu, chúng ta có thể suy nghĩ rõ ràng về các 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 cơ chế, cần phải thực sự rõ ràng liệu nó có vi phạm những ràng buộc này hay không và liệu nó có đưa chúng ta đến gần hơn với mục tiêu đó hay không. 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ể và phải tuân theo một số ràng buộc.

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

(1) Quá chú trọng vào token. Tôi đã đề cập một chút về vấn đề này, nhưng nếu bạn luôn nghĩ đến phần thưởng hoặc phân phối mã thông báo, thay vì cách duy trì tính nhất quán giữa những người tham gia trong hệ thống của mình, thì có thể bạn không nghĩ về giao thức mà là về mã thông báo. 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. Nếu một số phần chính của hệ thống bị lỗi, tình hình sẽ tốt hơn so với trước đây. Mã thông báo của bạn thực sự 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 và hoàn chỉnh nếu không có nó. Vì vậy, bạn vẫn nên nghĩ lại mục tiêu của hệ thống.

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

Nếu đưa những ràng buộc này vào, bạn sẽ thấy không gian thiết kế co lại và trở nên rõ ràng hơn. Hai câu hỏi hữu ích trong việc giới hạn không gian thiết kế của bạn là 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ó, tập trung vào nó hơn là nghĩ đến toàn bộ hệ thống trước tiên. Một câu hỏi khác: Điểm yếu lớn nhất của thiết kế này là gì? Điều gì khiến bạn thức đêm, đó có phải là điểm mà bạn nghĩ nó có thể không hiệu quả, điểm khiến bạn lo lắ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ế đáng kể không gian thiết kế.

(3) Luôn cho cộng đồng biết sự thật. Sẽ rất mạo hiểm nếu gặp phải thách thức khi thiết kế một số bộ phận nhất định của hệ thống và đẩy tất cả lên cộng đồng để giải quyết, hoặc mong đợi những thế lực 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ó. Mặc dù các hệ thống không được phép rất phổ biến và dẫn đến nhiều cải tiến đáng kinh ngạc, nhưng bạn không thể dự đoán được cộng đồng sẽ làm gì và bạn 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 mình.

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ì? Không phải chúng ta đang hỏi liệu chúng ta có cung cấp đủ token cho họ hay không? Đúng hơn, hãy hỏi xem chúng ta trao cho họ sức mạnh 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 điều 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ó định xây dựng ở đây không? Nếu bạn không thể, vì nó không có đủ sức mạnh, không đủ linh hoạt, thì đừng trông cậy vào người khác.

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

Đây không phải là danh sách đầy đủ, tôi đã thảo luận vấn đề này với các thành viên trong nhóm và tôi chắc chắn rằng chúng tôi sẽ sớm sửa đổi nó, nhưng đây chỉ là để liệt kê tất cả các khả năng mà chúng tôi đã thấy mã thông báo thể hiện cho đến nay.

Mã thông báo là một công cụ trong một 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ì vậy, làm thế nào để chúng ta thấy cấu trúc dữ liệu này đang được sử dụng trong các giao thức khác nhau? Chúng có thể được chia thành năm loại rất chung: thanh toán, biểu quyết, bên liên quan, siêu dữ liệu và quyền sở hữu (Yêu cầu bồi thường). Tôi tin rằng theo thời gian, sẽ có nhiều giải pháp hơn cho từng danh mục này, ít nhất là đối với tôi. trực quan hơn.

chi trả

Đầu tiên, là tiền tệ nội bộ của cộng đồng hoặc dự án. Nó khác với các phương thức thanh toán truyền thống như thanh toán bằng đô la Mỹ, 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 đồng tiền nội tệ. Nó phải được gắn với giá trị của một số tài sản cụ thể khác và 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.

Cách thứ hai, và có lẽ là cách phổ biến nhất và dễ hiểu nhất để thanh toán bằng tiền điện tử, là dưới dạng tài nguyên mạng, 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 tôi 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ụ thể là tài nguyên máy tính.

Loại mã thông báo thanh toán thứ ba tồn tại dưới dạng tiền tệ trong trò chơi. 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. Sẽ không có vấn đề gì nếu nó được cung cấp ổn định, bởi 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, stablecoin có thể được sử dụng làm phương thức thanh toán theo ba phương thức 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 rơi vào 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, on-chain (tiền gửi) và off-chain (quyền sở hữu)

Mã thông báo gửi tiền (tiền gửi) trên chuỗi đầu tiên thể hiện quyền sở hữu các mã thông báo khác. Một ví dụ là mã thông báo Uniswap LP, là ERC 20 trong V2 và NFT trong V3. Stablecoin DAI 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 người giữ 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ự. Một ví dụ hiện đại hơn là những gì ngày nay được gọi là vật có thể đổi được, trong đó mã thông báo có thể được đổi lấy vật thể. Ví dụ: sử dụng NFT để đổi lấy tác phẩm nghệ thuật. 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 có khuynh hướng như vậy. 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

Sử dụng biểu quyết để tài trợ cho các dự án, phân bổ nguồn lực, 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 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 cho 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 hoạt động của cơ chế này 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à DroneLink, nếu DroneLink hoạt động tốt và nhiều chủ sở hữu mã thông báo của DRONE thực hiện công việc của họ và hệ thống chạy bình thường, thì họ sẽ được hưởng lợi từ một số phần thưởng và đó là cách hợp đồng thông minh, đó là cách giao thức được thiết kế, Để thưởng tốt sự quản lý của cộng đồng.

Bạn cũng có thể tạo mã thông báo do thỏa thuận pháp lý cho phép bạn nhận tiền lãi. 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 một phần vốn chủ sở hữu trong một công ty và tất nhiên sẽ có nhiều yêu cầu và hạn chế pháp lý khác nhau.

Token cũng được sử dụng để bảo đảm 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 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 việc 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ợ hệ thống khi nó phát triển.

metadata

Đầ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ó thể 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 nhóm nào đó. Giao thức hoặc một số công cụ do bên thứ ba viết có thể khai thác thuộc tính thành viên này theo bất kỳ cách nào, điều này 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ư đối với những người nắm giữ mã thông báo này của những ngườ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.

Thứ hai, token cũng thể hiện sự tin cậy. Một số người đang tranh luận liệu tín dụng có nên được chuyển nhượng hay không, cá nhân tôi nghĩ có lẽ là không nên. 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, 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ột lần nữa, mã thông báo cũng đại diện cho danh tính hoặc tham chiếu. ENS là một ví dụ về điều này, tên ENS có thể trỏ đến địa chỉ và có thể được cập nhật, không giống như hệ thống DNS.

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 loại chứng chỉ có thể xác minh nào đó. 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. Ví dụ: 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 thứ gì đó trên chuỗi. Bạn thậm chí có thể sử dụng mã thông báo làm giao diện, chúng tôi đã thấy các ví dụ 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 HTML vào đó và thậm chí bạn có thể đặt một chút JavaScript. Bạn có thể đặt một giao diện trong nft và điều khiển giao diện đó hoặc bạn có thể nhúng giao diện đó vào các đối tượng mà mọi người sở hữu và chuyển giao.

Một ví dụ thú vị là BEEP3R, trong đó trước tiên bạn đúc văn bản thành NFT và sau đó bạn có thể truyền văn bản đó đến những người nắm giữ BEEP3R khác bằng cách sở hữu nó. Văn bản được hiển thị trên hình ảnh nhỏ của BEEP3R. Khi bạn có máy BEEP3R, bạn cũng có thể gửi tin nhắn trực tiếp đến những người giữ máy BEEP3R khác, 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 có thể 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à chủ sở hữu BP, bạn có thể nhận và gửi tin nhắn. Vì vậy, điều này chỉ xảy ra trong bộ đó. Đây cũng là mã thông báo nhận dạng vì họ sử dụng ID mã thông báo BP của bạn để gửi tin nhắn cho bạn. Đồng thời, nó còn tồn tại dưới dạng giao diện để xem thông tin liên quan đến NFT.

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

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

Câu hỏi của tôi là tại sao một số sản phẩm xuất hiện trong những giờ nhất định và tại sao một số sản phẩm lại xuất hiện lâu hơn những sản phẩm khác? Lấy giao thức cho vay làm ví dụ, 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 một khoản nợ trong 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 ta 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ó các giao thức cho vay yêu cầu AMM, vì nếu bạn muốn sử dụng giao thức cho vay để làm đòn bẩy, đặc biệt là các giao thức cho vay đơn giản ban đầu, bạn cần có khả năng vay 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. Sẽ không có sự phát triển nào về các giao thức cho vay cho đến khi chúng tôi có các AMM và stablecoin hoạt động được.

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 đều yêu cầu hiểu biết về cách các dự án khác giao tiếp với chúng. Và để có mã thông báo ERC20, 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 ERC20. Chúng tôi cần khả năng lập trình đầy đủ để có đủ không gian thiết kế mở, nhưng điều này tất nhiên 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ệ và một số công nghệ là điều kiện tiên quyết cho những công nghệ khá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, EIP 4844, cây dọc, học máy không có 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 các công nghệ cụ thể giúp giảm thiểu 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ác công nghệ cụ thể có thể giảm bớt những hạn chế, chúng ta có nên nỗ lực 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 mong muốn. Vì vậy, gắn kết điều đó với quan đ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 ERC20 thì hạn chế đối với bất kỳ thiết kế AMM hoặc stablecoin nào là nó sẽ 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 phổ quát 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ĩ đây sẽ là một giới hạn gần như không thể vượt qua, nhưng việc có 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 ERC20, điều này giới hạn không gian thiết kế để biến điều này thành hiện thực.

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 sẽ có tác động gì đến những hạn chế trong 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.