a16z CTO: Từ Memecoin đến token mạng, cách hiểu thiết kế token

Biên soạn bởi: KeyMapDAO

Link gốc: https://mp.weixin.qq.com/s/yCKTTzIjYKVD66PvofwYvw

Tuyên bố: Bài viết này là nội dung được in lại, bạn đọc có thể tham khảo thêm thông tin qua link gốc. Nếu tác giả có bất kỳ phản đối nào về hình thức in lại, vui lòng liên hệ với chúng tôi và chúng tôi sẽ thực hiện sửa đổi theo yêu cầu của tác giả. Việc in lại chỉ nhằm mục đích chia sẻ thông tin và không mang tính chất tư vấn đầu tư cũng như không thể hiện quan điểm và lập trường của Wu Shuo.

Bài viết này được Cikey dịch và Punkcan hiệu đính, dựa trên bài phát biểu đầu tiên của Eddy Lazzarin (CTO của a16z crypto) tại Crypto Startup Accelerator. Eddy Lazzarin sẽ đưa chúng ta từ Memecoin đến token, cung cấp phân tích chuyên sâu về sự khác biệt và tương đồng giữa các token khác nhau, cũng như con đường dẫn đến phân cấp lũy tiến.

Tôi đã mong chờ bài chia sẻ này từ lâu, nhưng trước khi chia sẻ, tôi xin đặt một câu hỏi: Ở đây có ai dự định phát hành token không?

Tôi đã lược bỏ hoặc đơn giản hóa nhiều nội dung trong bài giảng này vì chủ đề về token rất phức tạp. Vì vậy xin đừng ngần ngại hỏi nếu bạn có bất kỳ câu hỏi nào.

Hầu như ngày nào tôi cũng thảo luận về token với toàn bộ nhóm đầu tư của mình và đã nghiên cứu chúng trong vài năm, nhưng tôi vẫn cảm thấy như mình chưa nói đủ thấu đáo. Vì vậy, bạn phải giao tiếp bằng các câu hỏi.

Thông thường, tôi và nhóm của tôi thảo luận các vấn đề về mã thông báo theo cách trò chuyện. Họ chia sẻ quan điểm của mình về các quy trình và sản phẩm, điều này giúp tôi đưa ra các đề xuất có mục tiêu hơn.

Hôm nay chúng ta sẽ nói về token, đặc biệt là các ứng dụng thực tế của nó. Tôi không phải là luật sư nên đây không phải là lời khuyên pháp lý mà là một số ý kiến ​​của tôi với tư cách là một kỹ sư và người hành nghề.

Tôi đã nghe lập luận này nhiều lần, rằng mã thông báo về cơ bản chỉ là số dư tài khoản trong hệ thống mật mã. Chúng có thể đạt được bằng nhiều cách, một số cách thậm chí còn chưa được phát minh. Tôi hy vọng bạn có thể phát minh ra một số cách mới. Tuy nhiên, hôm nay chúng tôi sẽ tập trung vào một số trong số họ.

Đầu tiên, hãy bắt đầu với Memecoin vì chúng đã trở lại nổi bật trong thời gian gần đây. Mặc dù chúng có vẻ mới lạ nhưng Memecoin đã xuất hiện từ những ngày đầu của tiền điện tử, ngay cả trước khi Ethereum xuất hiện. Ban đầu, cách mọi người sử dụng nó là họ thực sự lấy một nhánh của cơ sở mã Bitcoin ban đầu, thực hiện một số sửa đổi nhỏ, đặt tên cho nó và phát hành nó.

Nếu bạn nhìn vào dữ liệu Wayback Machine và CoinMarketCap từ archive.org vào năm 2013, bạn sẽ thấy rằng có rất nhiều đồng tiền này nằm trong top 100. Chúng không phải là những cải tiến mới. Cá nhân tôi không có hứng thú với những đồng tiền này. Tôi cũng hy vọng rằng không ai ở đây tạo ra loại tiền này và chúng ta sẽ thảo luận chi tiết về lý do sau.

Nói một cách đơn giản, Memecoin là các token không có mục đích rõ ràng, đó là đặc điểm chính của chúng. Nếu chúng có mục đích rõ ràng, chúng không còn là Memecoin thuần túy nữa mà có thể liên quan đến thiết kế giao thức và các vấn đề pháp lý. Vì sự “vô mục đích” này mà chúng đã trở thành công cụ đầu cơ thuần túy. Bản chất đầu cơ khiến chúng về cơ bản gần giống với cờ bạc và cờ bạc được cho phép theo nhiều khuôn khổ pháp lý. Vì vậy, đặc điểm này cần phải nhất quán.

Do tính chất đầu cơ của Memecoin, giá của chúng cực kỳ biến động. Nhưng đây không phải là một khuyết điểm, đó là một đặc điểm của họ. Tuy nhiên, hãy lưu ý rằng Memecoin có thể được phân cấp, nhưng chúng cũng có thể gặp phải tình trạng bất cân xứng về thông tin hoặc thậm chí là lừa đảo. Ai đó có thể lên kế hoạch bán tháo trước, kiểm soát thông tin hoặc che giấu các lỗ hổng trong mã. Mặc dù những Memecoin này có thể trông bình thường nhưng thực tế chúng có thể ẩn giấu các cửa sau hoặc các vấn đề khác.

Tiếp theo là Stablecoin và mặc dù chúng ta sẽ không thảo luận sâu về chúng nhưng chúng có những ứng dụng quan trọng trong giao thức, đặc biệt là tài sản thế chấp trên chuỗi. Mặc dù stablecoin từ lâu đã được thảo luận trong giới tiền điện tử về tiềm năng thanh toán, nhưng mục đích sử dụng chính của chúng hiện vẫn là tài sản thế chấp. Điều này có thể thay đổi theo thời gian.

Loại mã thông báo thứ ba là Mã thông báo Arcade (mã thông báo trò chơi), đôi khi được gọi là "đồng xu mềm" và thường là mã thông báo thứ hai trong mô hình mã thông báo kép. Các token như vậy có thể được chuyển giao trực tuyến, nhưng giá thường bị giảm do các hạn chế về cơ chế phát hành và mua lại. Nguồn cung của chúng thường không giới hạn và có thể so sánh với các token nhỏ được sử dụng trong các trò chơi điện tử, hữu ích trong các tình huống cụ thể nhưng không có khả năng tăng giá.

Sau đó là Network Tokens (mã thông báo mạng), đại diện cho các giao thức phi tập trung và được tích hợp sâu với giao thức. Các mã thông báo này có thể có độ biến động cao hơn, nhưng chúng là một phần của mô hình kinh tế, như Ethereum, Maker, Uniswap (UNI), Hợp chất, v.v. Loại mã thông báo này được thiết kế không chỉ cho bản thân mã thông báo mà còn cho hoạt động của toàn bộ giao thức. Việc phát hành, mua lại, sáng tạo và hủy diệt đều gắn chặt với hệ thống lớn hơn.

Khi thiết kế các token này, chúng ta phải đặc biệt chú ý đến sự cân bằng giữa cơ chế phát hành và tiêu hủy. Việc phát hành mã thông báo có thể mở rộng giá trị do giao thức cung cấp, nhưng nếu nguồn cung lưu thông không được kiểm soát, nó có thể dẫn đến lạm phát. Vì vậy, việc thiết kế một mô hình kinh tế bền vững đòi hỏi sự cân bằng giữa phát hành và tiêu hủy là rất quan trọng.

Trước khi chúng ta tiếp tục, vui lòng đặt bất kỳ câu hỏi nào:

Hỏi: Bạn có cân nhắc thứ gì đó như Fly Tokens không?

"Fly Tokens" hiện không phải là thuật ngữ được công nhận rộng rãi trong ngành hoặc dự án mã thông báo cụ thể. Nó có thể là một mã thông báo giả định hoặc mang tính khái niệm được đề cập trong một bối cảnh cụ thể. - Giải thích từ gpt

Hiện tại, Fly Token không được coi là token thực sự vào thời điểm hiện tại vì chúng nằm ngoài chuỗi và không thể chuyển trên blockchain. Tuy nhiên, nếu nó có thể chuyển nhượng được và trở thành một phần của hệ thống lớn hơn trong tương lai thì nó có thể được coi là một token.

Tôi đã có một số trao đổi với nhóm Blackbird và họ cũng đang suy nghĩ nghiêm túc về vấn đề này. Fly Token cuối cùng có thể được phân loại là token chơi game. Ví dụ: bạn có thể tưởng tượng việc sử dụng Fly Token để thanh toán tại một nhà hàng và nhà hàng đó có thể thực hiện một số biện pháp để đảm bảo rằng giá trị quy đổi của Fly tương đối ổn định.

Khi xem xét mã thông báo, chúng ta không nên dễ dàng giả định giá trị hoặc chức năng của nó mà hãy phân tích cẩn thận mục đích và cơ chế thực tế của nó. Mặc dù Fly Token hiện không thể chuyển nhượng được, nhưng nếu có quy trình trực tuyến hoặc cơ chế kinh tế vĩ mô để xử lý việc phát hành và mua lại nó trong tương lai thì nó có thể được phân loại là token trò chơi.

Thực sự ngày càng có nhiều nhóm khám phá các phương pháp tương tự. Tôi sẽ thảo luận điều này chi tiết hơn sau.

Khi thảo luận về mã thông báo, tôi thích sử dụng một mô hình tinh thần đơn giản để giúp mọi người hiểu. Hãy tưởng tượng một "vòi" thể hiện khả năng tạo mã thông báo của bạn. Khả năng này không chỉ là kỹ năng lập trình mà còn là chìa khóa để xác định các điều kiện phát hành token. Đây là một công cụ rất mạnh mẽ. Ví dụ: trong Ethereum, hệ thống có thể đảm bảo rằng người xác thực được thanh toán bằng cách phát hành mã thông báo mới, thay vì rút từ một nhóm cố định. Điều này không có nghĩa là bạn có thể phát hành token theo ý muốn mà không có bất kỳ giới hạn nào, vì điều đó sẽ gây ra lạm phát nghiêm trọng.

Chúng ta không thể đánh giá thấp sức mạnh của "vòi". Khi bạn tăng nguồn cung cấp mã thông báo lưu hành, bạn nên đảm bảo rằng những mã thông báo đó có thể được sử dụng để thanh toán cho thứ gì đó có giá trị lớn, từ đó tăng chất lượng và số lượng hàng hóa hoặc dịch vụ do giao thức cung cấp. Tuy nhiên, đồng thời, bạn cũng cần xem xét “sự thoát nước” – tức là cơ chế làm thế nào các mã thông báo này cuối cùng bị phá hủy, khóa hoặc bị loại khỏi lưu thông. Số dư này rất quan trọng vì nó giúp duy trì giá của token để nó vẫn có giá trị cho các khoản thanh toán trong tương lai.

Mục tiêu cuối cùng là tạo ra một hệ thống bền vững trong đó việc phát hành và tiêu hủy mã thông báo có thể duy trì sự cân bằng nhất định. Mặc dù sự cân bằng này không dễ đạt được một cách hoàn hảo, nhưng khi thiết kế một hệ thống, bạn phải luôn nhớ rằng khả năng phát hành mã thông báo là công cụ cơ bản của bạn và "sự thoát nước" là chìa khóa để đảm bảo rằng mã thông báo được gắn với giá trị thực tế do hệ thống tạo ra.

Một điểm nữa là khi hiểu thỏa thuận, bạn có thể coi nó như một thị trường. Thị trường này có hai khía cạnh: cung và cầu. Ở đây, "vòi" và "cống" tương ứng là cung và cầu. Bên cung đề cập đến các bên hoặc cơ chế tạo ra nhu cầu về hàng hóa, trong khi bên cầu đề cập đến những người hoặc tổ chức trả tiền để tiêu thụ hàng hóa đó.

Mô hình của Ethereum là một ví dụ điển hình. Trong Ethereum, mạng xử lý các phần thưởng lạm phát bằng cách trả cho người xác nhận ngân sách bảo mật, một quy trình đại diện cho phía cung. Điều này có nghĩa là hệ thống đảm bảo tính bảo mật của mạng bằng cách phát hành Ethereum (ETH) mới để thanh toán cho người xác thực. Thoát nước xảy ra khi mọi người trả phí tính toán, một phần trong số đó được trả cho người xác nhận và một phần trong số đó bị đốt cháy. Ví dụ: thông qua cơ chế EIP-1559, một phần phí giao dịch sẽ bị đốt trực tiếp, do đó làm giảm nguồn cung ETH đang lưu hành.

Phía cầu được phản ánh ở nhu cầu về điện toán, lưu trữ và các phép tính có thể kiểm chứng. Ví dụ: khi người dùng triển khai hợp đồng thông minh hoặc thực hiện giao dịch trên Ethereum, họ cần phải trả tiền cho các dịch vụ này. Phía cung cấp bao gồm dung lượng mạng và không gian khối. Việc cung cấp các tài nguyên này quyết định mức độ nhu cầu mà hệ thống có thể đáp ứng.

Nhìn chung, thiết kế của giao thức cần duy trì sự cân bằng giữa cung và cầu để đảm bảo cơ chế phát hành và tiêu hủy token có thể hỗ trợ hoạt động bền vững của toàn bộ hệ thống.

H: Bạn có một mô hình tinh thần tương tự để phân tích tính kinh tế của lạm phát và giảm phát không?

Liên quan đến tính kinh tế của lạm phát và giảm phát, rất khó để thiết kế một hệ thống đạt được sự cân bằng hoàn hảo, vì vậy tôi không khuyên bạn nên theo đuổi sự cân bằng như vậy ngay từ đầu. Trên thực tế, tôi không nghĩ có sự cân bằng hoàn hảo luôn được duy trì trong tự nhiên. Tôi có xu hướng nghĩ rằng lạm phát vừa phải sẽ tốt hơn nguồn cung cố định nghiêm ngặt, bởi vì lạm phát có nghĩa là bạn được đảm bảo thanh toán cho một thứ gì đó. Một điểm quan trọng khác là thời điểm rút phí khỏi hệ thống phải là khi một thứ gì đó có giá trị được tiêu thụ.

Ví dụ: trong Uniswap, họ trả phí giao dịch bằng cách tiêu thụ thanh khoản; trong Maker, họ trả tiền cho việc sử dụng đòn bẩy và rủi ro phát sinh trong hệ thống; và trong Ethereum, họ trả tiền cho không gian khối và phí tính toán. Tóm lại, điều quan trọng là đảm bảo mọi người trả tiền cho thứ gì đó có giá trị.

Hỏi: Trước đây, chúng tôi đã có những thứ như Đường cong liên kết để giải quyết một số vấn đề. Bạn có gợi ý gì cho việc này không? Ví dụ, nên sử dụng Đường cong liên kết hay cơ chế tương tự? Bạn nghĩ những cơ chế này áp dụng cho những vấn đề cụ thể nào?

Về việc có nên sử dụng cơ chế như Bonding Curves, Bonding Curves hiệu quả hơn khi tạo ra thị trường có tính thanh khoản rất hạn chế. Họ có thể thiết lập một đường giá cố định có thể không phản ánh đầy đủ nhu cầu thị trường.

H: Bạn thấy thế nào khi đo lường hiệu ứng đồng bộ hóa và thiết kế đồng bộ hóa?

Khi đo lường tác động của bồn rửa và thiết kế thoát nước, có những bồn rửa chính thức rõ ràng, chẳng hạn như đốt trực tiếp phí và các bồn rửa không chính thức, chẳng hạn như hợp đồng gửi đến "địa chỉ chết". Việc đo lường những dòng chảy này trong hệ sinh thái là rất khó khăn. Tôi chia chúng thành rõ ràng và ngầm định:

• Cống thoát nước rõ ràng: Ví dụ: chi phí được hạch toán và thanh toán, đốt cháy hoặc các phương pháp xử lý trực tiếp khác.
• Các dòng chảy ẩn: Ví dụ: sự tin tưởng và nắm giữ mã thông báo của mọi người hoặc việc sử dụng nó trên thị trường.
• 
  

Có nhiều cơ chế phá hủy ngầm ("syns") được dùng làm tài sản thế chấp trong một số mục đích sử dụng khác. Tôi sẽ cảnh giác với các thiết kế giao thức dựa vào các cơ chế phá hủy ngầm này vì chúng khó định lượng hơn. Mặc dù các cơ chế phá hủy tiềm ẩn này có thể rất mạnh mẽ nhưng chúng cần được xem xét trong bối cảnh và cố gắng đo lường chúng, nhưng hoạt động của hệ thống không nên dựa vào các cơ chế phá hủy ngầm này. Các cơ chế phá hủy ngầm có thể rất nguy hiểm, và một số thứ có vẻ như là cơ chế phá hủy thì không phải vậy.

Mọi người thường nói, "Ồ, người ta dùng nó để thanh toán, đó là cơ chế đốt tiền vì họ có một ít trong ví." Nhưng làm thế nào để bạn đo lường được điều đó? Hệ thống của bạn có nên dựa vào những thứ này không? Ngoài ra, nó có phần là một gánh nặng vì cơ chế hủy diệt này có thể biến mất nhanh chóng, thực tế nó không phải là hạch toán kép.

Tiếp theo, tôi liệt kê một số lý do tốt và xấu. Đây là một bản tóm tắt đơn giản của so sánh. Tôi có thể nói nhiều hơn nếu tôi mở rộng.

Trước hết, về ưu đãi, điều này làm tôi hơi khó chịu. Đôi khi mọi người sẽ đến gặp tôi và nói, "Eddy, tôi muốn tạo một token, tôi thực sự muốn tạo ra token này." Và tôi hỏi, "Được rồi, vậy nó làm gì?" và họ trả lời, "Ồ, nó sẽ được dùng để trả cho cái này cái kia." Thật tệ, đó không thực sự là thiết kế giao thức, nó chỉ in tiền không giới hạn và chi tiêu theo cách bạn muốn.

Trên thực tế, bạn rất dễ rơi vào quan niệm sai lầm rằng bạn có thể tạo mã thông báo để thanh toán cho một thứ gì đó, giống như có ngân sách quảng cáo không giới hạn mà bạn không phải trả tiền. Đây không phải là một thiết kế giao thức thực sự, và thậm chí tệ hơn, nó sẽ gây ra những vấn đề lớn cho lý luận của bạn về hệ thống.

Là một doanh nhân, mục tiêu của bạn là tìm ra sản phẩm phù hợp với thị trường. Bạn đang tạo ra một sản phẩm và bạn muốn chắc chắn rằng đó là thứ mà mọi người thực sự quan tâm, sẵn sàng sử dụng và trả tiền vì giá trị bạn tạo ra lớn hơn số tiền bạn đầu tư. Nếu bạn sử dụng token của mình vào những mục đích khuyến khích sai lầm, bạn có thể bóp méo sự hiểu biết của mình về sự phù hợp của sản phẩm với thị trường. Giống như nếu ai đó nói, "Tôi kiếm được năm triệu, tôi cảm thấy ổn", nhưng bạn kiểm tra và ngân sách quảng cáo của họ là hai mươi triệu, thì bạn biết điều đó không đúng vì họ đang trả tiền cho nó.

Trong một công ty truyền thống, điều này hiển thị trên bảng cân đối kế toán và bạn có thể thấy nó. Nhưng trong tiền điện tử, rất khó để đo lường xem mã thông báo có tồn tại ở nơi khác hay không. Bạn sẽ ngạc nhiên khi thấy mọi người làm rất ít việc để định lượng chi phí thu hút khách hàng mà họ thực sự chi tiêu thông qua một số loại chương trình khuyến khích mã thông báo.

Vậy thì sao Tôi đang nói không phải là bạn không nên sử dụng token để thanh toán mọi thứ, bạn nên sử dụng token và các giao thức tốt sẽ sử dụng token để thanh toán cho những thứ phù hợp. Nhưng nếu bạn chỉ coi token như một cách để vung tiền, bạn sẽ không học được nhiều điều và sẽ không tạo ra giá trị lâu dài ngoài một chu kỳ cường điệu hóa duy nhất. Chắc chắn còn rất nhiều điều để nói, nhưng những gì bạn thực sự đang làm là trả tiền cho các hiệu ứng mạng, thúc đẩy các hiệu ứng mạng của hệ thống. Hiện tại rất khó để đảm bảo rằng những gì bạn đang trả tiền là có giá trị và nguồn cung mà bạn hy vọng hướng dẫn sự phát triển là có thật, cần thiết hơn và hiệu quả hơn. Nhưng có nhiều cách để làm điều này, ví dụ: Hợp chất là trang trại lợi nhuận đầu tiên mà tôi biết nơi họ sẽ trả tiền cung cấp bằng cách cung cấp mã thông báo cho người dùng khi họ gửi một số loại tài sản thế chấp vào giao thức.

Đây là một cách tương đối đơn giản để xác minh, vì bạn biết tài sản thế chấp là gì và bạn đã chọn tài sản thế chấp nào để sử dụng, vì vậy bạn có thể biết rằng tài sản thế chấp đó là tài sản thế chấp hữu ích và có giá trị, vì vậy bạn có thể thanh toán nó một cách thích hợp. Đó là tất cả những gì hệ thống cần. Nhưng nếu bạn nghĩ về giao thức của mình, chìa khóa để phát triển hiệu ứng mạng là gì? Bên cung là gì? Bên cầu là gì? Làm thế nào để chúng tôi cải thiện nguồn cung cấp chất lượng cao?

Hết sức thận trọng khi nói đến yêu cầu trợ cấp vì nó có thể làm cho hệ thống trở nên phức tạp hơn. Bạn cần tập trung vào những yếu tố góp phần vào sự phát triển của hiệu ứng mạng lưới. Một lĩnh vực đặc biệt quan tâm khác là bảo mật và điều này không chỉ áp dụng cho các giao thức cơ bản như Ethereum mà còn cho nhiều giao thức khác. Bạn trả tiền cho sự bảo mật và "bảo mật" ở đây là một khái niệm rất rộng.

Cố gắng tìm một từ khác để thay thế từ này, nhưng thực sự rất khó.

Lấy bằng chứng cổ phần của Ethereum làm ví dụ, trả tiền cho bảo mật thông qua việc phát hành mã thông báo, đền bù cho những người xác thực để đảm bảo rằng việc cung cấp không gian khối có chất lượng cao. Đây là những gì sẽ xảy ra - họ đảm bảo chất lượng của không gian khối, đảm bảo rằng tài nguyên máy tính được thanh toán và được sao chép và xác minh trong hệ thống. Đây là ở cấp độ cơ sở hạ tầng. Nhưng bạn cũng có thể nghĩ về điều này ở cấp độ ứng dụng. Đó là lý do tại sao Hợp chất và Maker thường xuyên trả tiền bảo mật.

Đối với Hợp chất, khái niệm bảo mật là tất cả tài sản được tập trung trong một nhóm và có một rủi ro nhất định - tức là các tài sản thế chấp nguy hiểm hoặc chất lượng thấp được thêm vào nhóm. Điều này tiềm ẩn rủi ro cao vì nếu thêm tài sản thế chấp xấu, ai đó có thể gửi một lượng lớn tài sản xấu và lấy đi mọi thứ có giá trị. Do đó, giao thức được thiết kế đặc biệt để bảo vệ tiền gửi trong nhóm, đó là điều nó luôn làm. Những người nắm giữ mã thông báo của Hợp chất bỏ phiếu cẩn thận về việc tiếp nhận tài sản thế chấp mới và giới hạn nợ đối với tài sản thế chấp. Mục tiêu của họ là đảm bảo rằng các nhà cung cấp không bị mất tài sản thế chấp hoặc tiền đặt cọc và người đi vay phải trả phí và các khoản nợ của họ. Do đó, giao thức đảm bảo tính bảo mật của hệ thống và các mã thông báo tồn tại để đảm bảo đạt được tính bảo mật này.

Điều này cũng đúng với Maker. Tôi đã đề cập đến Story Protocol sớm hơn một chút và nếu bạn có một mạng lưới nơi bạn có tất cả các loại tài sản trí tuệ có thể được thương mại hóa hoặc tạo thành các tác phẩm phái sinh, bạn có thể tưởng tượng rằng một khái niệm bảo mật rất quan trọng là tài sản trí tuệ mà tôi thương mại hóa là hợp pháp. Điều này rất khó đo lường trong thế giới thực và bạn cần phải thực hiện nhiều công việc pháp lý và thẩm định để đảm bảo rằng đây là tài sản trí tuệ thực sự và hợp pháp cũng như người tuyên bố sở hữu nó thực sự sở hữu nó. Nhưng nếu bạn có thể coi đó là điều hiển nhiên, nếu giao thức đảm bảo tính hợp pháp của tất cả tài sản thì sản phẩm của mạng này sẽ có chất lượng rất cao. Tôi có thể nói điều này về bất kỳ ứng dụng nào trong không gian tiền điện tử, sản phẩm đó cần đảm bảo tính xác thực và tính trung lập tin cậy. Nếu bạn có thể sử dụng token của mình để thanh toán cho nội dung này thì về lâu dài nó rất có thể trở thành một giao thức có giá trị.

Hỏi: Bạn có thể hình dung ra một thỏa thuận lý tưởng với tất cả các nhu cầu của nó và sau đó lập ngân sách cho những nhu cầu đó không, và đó có phải là ngân sách cho thỏa thuận không?

Có, hãy nghĩ về những gì thỏa thuận của bạn thực sự mang lại. Khi người dùng tiếp xúc với nó, họ sẽ hỏi: "Sản phẩm này có tốt không? Có đáng tin cậy không? Chất lượng có cao không?" Bạn cần đảm bảo nó luôn có chất lượng cao. Mặc dù “chất lượng cao” nghe có vẻ giống như một tuyên bố đơn giản, nhưng cốt lõi của nó là về “xác minh”—và mặc dù từ “xác minh” nghe có vẻ không hấp dẫn lắm nhưng không thể bỏ qua tầm quan trọng của nó.

Hỏi: Bạn có nghĩ rằng bảo mật, như bạn định nghĩa, là một phần nội tại của giá trị của mã thông báo mạng không?

Hãy nói chi tiết về vấn đề này.

Hỏi: Với những mã thông báo mạng mà bạn xác định, có vẻ như bảo mật thực sự là yếu tố then chốt: bạn không thể có mã thông báo mạng và không phải trả tiền cho bảo mật.

Ví dụ tiếp theo của tôi không có khía cạnh này, nhưng vấn đề là mã thông báo mạng phải trả tiền cho bảo mật. Giá trị của mã thông báo mạng đến từ việc mọi người trả tiền cho những thứ an toàn mà họ tiêu thụ và mã thông báo sẽ nắm giữ một phần giá trị đó để duy trì giá của chính nó và do đó duy trì hoạt động của hệ thống. Đó là tất cả về việc làm cho hệ thống bền vững. Ngoài ra còn có các hệ thống tạo ra rủi ro, chẳng hạn như Hợp chất và Nhà sản xuất, có rủi ro hệ thống. Những rủi ro này, nếu không được lan truyền giữa những người dùng giao thức, có thể được nội bộ hóa cho chủ sở hữu mã thông báo. Người nắm giữ mã thông báo sẽ chấp nhận những rủi ro này và lợi ích của việc đẩy rủi ro vào là bạn có thể trả tiền cho mọi người để quản lý những rủi ro này. Mọi người nên được trả tiền để chấp nhận rủi ro và khi họ chấp nhận rủi ro, họ có thể làm việc để giảm thiểu rủi ro và đảm bảo hệ thống tiếp tục hoạt động bình thường. Một số hệ thống không yêu cầu thanh toán liên tục để bảo mật.

Ví dụ: các hệ thống bất biến có thể có chi phí bảo mật rất thấp. Lấy Uniswap làm ví dụ. Uniswap hoàn toàn bất biến, mỗi phiên bản đều độc lập và không yêu cầu ngân sách bảo mật liên tục. Lý do là các thuộc tính thiết kế của Uniswap đã loại bỏ các vấn đề bảo mật. Mỗi nhóm Uniswap độc lập và các nhà giao dịch chấp nhận rủi ro của nhóm khi trao đổi tài sản trong nhóm. Kết quả là không có khoản thanh toán bảo mật liên tục và không có rủi ro hệ thống cần được giám sát cẩn thận. Nhưng không phải tất cả các giao thức đều có thể được thiết kế để bất biến.

Ví dụ: bạn không thể triển khai tính bất biến trong Hợp chất vì nó yêu cầu phải quyết định tài sản thế chấp nào là an toàn vì tính thanh khoản được chia sẻ giữa các tài sản.

Vì vậy, nếu bạn có thể làm cho hệ thống trở nên bất biến, bạn có thể tiết kiệm rất nhiều chi phí và có khả năng giảm thiểu hoặc loại bỏ việc quản trị. Một số người tạo mã thông báo vì những lý do tồi tệ, chẳng hạn như mã thông báo dùng để bỏ phiếu. Mục đích của mã thông báo quản trị này là gì? Bỏ phiếu không có nghĩa là bạn không nên có phiếu bầu trong hệ thống, nhưng bỏ phiếu là phương sách cuối cùng. Điều này cũng đúng trong chính trị: bầu cử là phương sách cuối cùng, có nghĩa là chúng ta không có cách nào tổ chức xã hội ở cấp độ tổ chức phù hợp, vì vậy chúng ta cần phải làm điều đau đớn, tốn kém và khó phân tích nhất.

Bỏ phiếu rất tẻ nhạt.

Chúng tôi yêu cầu mọi người cân nhắc về một vấn đề phức tạp, đa chiều. Bạn chỉ nên sử dụng biểu quyết khi thực sự cần thiết. Cho đến nay, việc quản trị mã thông báo có mức độ tham gia thấp và chi phí cơ hội cao, gây khó khăn cho việc khuyến khích các chuyên gia tiến hành nghiên cứu. Nó không hoàn toàn không hiệu quả, chỉ là một quá trình chậm chạp tẻ nhạt và chỉ nên được sử dụng như là phương sách cuối cùng khi cần thiết.

Mọi thứ có thể được tự động hóa và tích hợp vào hệ thống hoặc ủy quyền cho cơ chế thị trường đều phải như vậy.

Nếu đề xuất giá trị của mã thông báo của bạn chỉ là để bỏ phiếu thì bạn đang tự đùa mình. Không ai thực sự muốn bỏ phiếu, việc bỏ phiếu là trách nhiệm của chủ sở hữu token. Điều bạn thực sự muốn là tất cả các bên liên quan trong mạng lưới được khuyến khích làm việc hướng tới các mục tiêu giống nhau. Đây là một thuộc tính rất mạnh mẽ của token mà tôi nghĩ là rất khó đạt được so với vốn chủ sở hữu.

Ý tưởng cơ bản là bạn có thứ gì đó gần đó quan trọng đối với chức năng của giao thức.

Bạn có nhà cung cấp, người dùng, đối tác công nghệ, v.v. Bạn có thể thỏa thuận với họ, nhưng thay vì chỉ thực hiện một giao dịch tiền mặt nhỏ, tốt hơn là bạn nên có mã thông báo và họ muốn giao thức thành công, đồng thời, bạn có thể tạo kết nối giữa các khu vực lân cận khác nhau mà có thể đang cạnh tranh lẫn nhau. Hiệu ứng tổng hợp mạnh hơn nhiều so với hiệu ứng riêng lẻ.

Trong quá trình thiết lập này, bạn có thể triển khai nhiều công cụ khác nhau như phân bổ, các mốc quan trọng, khóa, v.v.

Tôi sẽ nói về một số phương pháp khác sau. Bạn có thể hình dung một số phương pháp tự động và một số phương pháp thủ công. Ví dụ: các phương pháp thủ công ban đầu bao gồm các giao dịch phát triển kinh doanh, quan hệ đối tác, trao đổi mã thông báo có điều kiện, v.v. Các phương pháp tự động như mọi người gửi tài sản thế chấp, khóa chúng, cam kết thực hiện một số công việc có thể xác minh được, sau khi hoàn thành họ được trả tiền, những phần thưởng này sẽ được mở khóa theo thời gian, v.v.

Chúng tôi có thể rất sáng tạo với điều này và tôi nghĩ mọi người thực sự đánh giá thấp tác động của việc này vì những tác động đáng chú ý nhất thường rất tinh tế. Ví dụ, mọi người đồng ý với nhau, không cạnh tranh, chia sẻ mã nguồn mở, quảng bá sản phẩm của nhau trên mạng xã hội, v.v., đều là những phần quan trọng trong sự phát triển của lĩnh vực mã hóa.

Tôi đề cập đến điều này chỉ vì nó xuất hiện quá thường xuyên: trả tiền. Một số người nói rằng token được sử dụng để thanh toán. Tôi đang nói về token mạng, không phải token trò chơi và không phải stablecoin. Tôi đang nói về mã thông báo giao thức. Bằng chứng cho đến nay cho thấy rằng mọi người không sẵn lòng thanh toán bằng mã thông báo giao thức và trên thực tế, sẽ có xung đột khi làm như vậy. Tùy thuộc vào cách hoạt động của mạng hiện tại, trước tiên người ta phải có được số dư token và cũng xem xét rủi ro khi nắm giữ một tài sản có khả năng biến động. Mọi người không thích thanh toán bằng tài sản dễ bay hơi, ngay cả khi họ cho rằng làm như vậy là hợp lý.

Nếu giá trị số token được coi là cao thì mọi người có thể không sẵn lòng bán nó; nếu họ tin rằng nó không có giá trị, họ có thể không muốn giữ số lượng lớn token để chuẩn bị thanh toán. Điều đó không có nghĩa là nó sẽ không bao giờ hoạt động, chỉ là chúng ta sẽ cần rất nhiều sự phát triển thú vị của những token này để nó hoạt động. Phần này vẫn còn hơi mơ hồ. Điểm cuối cùng là nếu thanh toán không phải là đồng bộ hóa trực tiếp thì việc thu phí từ khoản thanh toán có thể là một cách đồng bộ hóa, nhưng việc thanh toán yêu cầu mọi người thanh toán bằng mã thông báo không phải là đồng bộ hóa trực tiếp.

Hỏi: Bạn nghĩ quản trị thực sự có khả năng hỗ trợ bảo mật như thế nào?

Quản trị và bảo mật, trong các ví dụ bạn đề cập, như Hợp chất, quản trị thực sự là một khía cạnh giúp bảo mật. Quản trị không hẳn là điều xấu, nếu bạn hiểu rằng các quyết định về cách bảo mật mạng không thể được tự động hóa và con người phải tham gia vào quyết định đó thì quản trị có thể phục vụ mục đích đó. Ví dụ: việc quyết định mã thông báo nào đủ an toàn để mạng được đưa vào nhóm đặt cược cần có sự can thiệp của con người thay vì quyết định hoàn toàn tự động. Quản trị có thể đạt được mục đích này và thực sự có bằng chứng cho thấy nó có thể hoạt động hiệu quả. Các giao thức DeFi như Maker và Hợp chất đã làm như vậy và có các ủy ban bảo mật chuyên xử lý các vấn đề như lỗ hổng hệ thống. Quản trị thực sự có thể giúp ích cho an ninh, nhưng nó cũng tiềm ẩn nguy cơ thất bại và rủi ro chính trị. Bạn phải suy nghĩ cẩn thận về cách thiết kế nó. Compound and every other lending protocol are putting a lot of effort into figuring out how to have experts review their protocols and pay for it. They need to ensure that at least some experts are publicly weighing in on the changes and that their token holders are also evaluating the changes. I'm not saying it's impossible, just that it's a pain point. Can you do it without depending on it? Can it be minimized? To the extent you can minimize this, you make the system more robust. Of course, I don't think complete removal is possible in all cases, but that's the framework.

Q: Convert subjective incentives into objective evaluations?

Marketing and Measurement For example, on marketing, if you’re spending $20 million and only bringing in $5 million in revenue, then you need to focus on customer acquisition cost (CAC) and lifetime value (LTV) ratios. If this ratio is poor, you are paying more than you are earning, which is a sign that you need to optimize your customer acquisition costs.

Protocol design, in the protocol design, you need to consider the payment content. For example, early crypto project Steam stem was a social network where users earned tokens for commenting. This incentive system leads to a lot of spam because people only care about getting tokens rather than the quality of the comments. This shows that it is crucial to verify the quality of supply in the incentive mechanism.

Objective measurement, how to objectively measure the content you inspire? It’s better to incentivize content that automatically validates its quality to a degree that directly leads to high-quality network effects, rather than vanity metrics. For example, instead of incentivizing meaningless random transactions, high-quality supply should be incentivized. You know, quality conversations are hard to measure. Capital deposits are relatively easier to measure.

Q: It’s basically combining simple marketing metrics with the actual goals of the product.

Yes, but not just marketing, but security, liquidity, and any value created by our system, which may or may not be marketing.

Q: Do you think a protocol should be designed around incentives or what you want to pay for?你如何看待激励机制随着时间的推移发生变化？

嗯，这取决于应用场景和使用方式，以及你想激励的目标是否会随着时间变化。你想要促进的东西随着时间的推移可能会改变，如何考虑这一点？

这也是为什么我特别喜欢手动激励机制的原因。虽然在实现真正的去中心化和可持续性时，自动化程序是至关重要的，因为最终目标是实现去中心化，确保即使你离开系统，它也能正常运行，这是一个很好的测试标准。所以，显然需要自动化支付来维持系统，但在早期阶段，你应该积极地手动分配代币，引入合适的合作伙伴、贡献者等。而且在这种情况下，你所激励的内容应当随着时间的推移而改变，因为你会从市场中不断获取信号，了解什么在起作用，并发现新的瓶颈，解决一个问题后出现另一个问题。你应该根据能验证的信息来调整激励措施。

Q：人们把代币当作“印钞机”，然后用投票来合理化这个过程，基本上做了所有不该做的事情。投票是 DAO 的一部分，你会投票决定什么？它能做什么？这些都很不明确。 DAO 能够被正确实施吗？ What do you think?

是的，我认为是可以的。

其实有一些事情是很重要的，比如在法律上如何正确实施。如果你还没有研究过或者了解过，我建议你看一下 Aragon 框架，我们推荐大家使用这个框架来管理 DAO。这是一种在美国的法律实体，但你不需要在美国也可以利用它。这个框架可以作为一种公司之外的选择，适合 DAO 成员。它允许他们进行投票，发表法律上有约束力的意见，并保护他们在这些投票中的责任，同时可以纳税并遵守法律，而不需要系统的管理控制者或传统公司那样的雇佣解雇制度。所以，首先，这在实施 DAO 方面帮助很大。许多 DAO 在试图实现自己的目标时，没有正确处理法律风险，导致了许多不必要的风险。

另一方面，是要明确 DAO 的目的。我认为，仅仅是为了支付和投票是荒谬的，这完全不是 DAO 应有的功能。在我看来，DAO 应该是一个由不同利益相关者组成的团体，他们代表协议相关的人类。比如 Uniswap，这是一个更简单的例子，因为它不需要支付安全性费用，但它确实会收取费用。这些人是持有代币的用户、使用 Uniswap 的用户、在 Uniswap 上构建应用程序的人，他们围绕着不断扩展的生态系统，有着共同的利益，希望协议和基金会能够代表并执行这些利益。

这对我来说是一个合理的 DAO，现在他们是否做到了这一点，确切地说，是否完全正确很难下结论，但 DAO 应该能够从他们的金库中分配资金，支持特定项目，进行协议升级等等，对吧？

这是可以理解的。而关于如何避免投票权只与加入时间早晚挂钩，这确实是个有趣且细微的问题。我在这里简单提到了一句，像那种简单的代币治理其实并不太好，就是你有多少代币就有多少投票权。其实我们有很多更有趣的方式，比如可以有不同的投票机制、自动委员会，或者加入抗女巫攻击机制（Sybil resistance），甚至可以随机选举人等等。这些都有很多有创造性且有趣的可能性。我可以整天谈论如何更合理地分配投票权。确实，单纯看谁持有更多代币是有一定优势的，毕竟有更多利益在其中的人确实应该有更多发言权。但关键是如何获取整个生态的高质量信号，这是一项复杂而微妙的任务。

Q：我们还讨论了代币的价值是如何保障网络和协议的安全性。在 MakerDAO 的例子中，他们有两个代币，一个是用于治理，另一个是稳定币。这两个代币显然是分离的，但我们也可以问，是否有必要分离它们？持币者是否可以直接使用原生代币进行质押，而不是用两个不同的代币？

其实，Maker 的两个代币是因为一个是产品本身，而另一个是网络代币。我不会称它为“效用代币”，它实际上是一个稳定币。如果你是用户，那么你使用的是稳定币，但如果你是通过杠杆操作获得它的，那么它就像是一张债务凭证，等着你回购偿还并赎回你的抵押品。所以它有点像是“双重用途”的代币，其中有一些细微之处。最重要的设计决策之一是，Maker 团队简化了 DAI 持有者的责任。持有 DAI 的人只需要关心一个问题——DAI 能保持稳定。这就明确了产品的社会契约，所有的风险和问题都是由 MKR 持有者来承担，而普通用户只需要相信 DAI 的稳定性就行了。

接着我们来谈去中心化的路径。我们有一个图表，纵轴代表去中心化程度，越向下代表去中心化越多；横轴代表协议功能，越向右代表功能越强大。我们的目标是到达右下角——高度去中心化且功能强大的协议。有些人可能会问，为什么我们要追求去中心化？其实去中心化是产品的一部分。虽然很多用户不太关心去中心化的技术细节，但他们关心的是他们的钱能保持价值、不被通货膨胀侵蚀，以及他们的银行不会随意冻结账户。所以人们其实非常在意这些与去中心化相关的问题，只是他们的需求会通过市场选择反映出来。

当你创建一个去中心化的网络时，它会吸引很多开发者，因为它是最稳固的基础设施。去中心化和高质量的协议功能是我们最终追求的目标。我们推荐的方式是渐进式去中心化——从高度中心化但功能强大的状态开始，然后逐步向右下角过渡。

我们还没有发布代币，所以我想说，事情是这样的：

我们的目标是首先要有一个良好的开端。左边的这些点并不是一个详尽的列表，而是一些示例，这些事情一旦发生，意味着我们可能变得更加去中心化。我们有多样化的利益相关者，有更多人的经济活动，使用不同的客户端，系统是无许可的，我们减少了单点故障。这些特性开始描绘一个去中心化的系统。随着我们变得越来越去中心化，我们离拥有一个可转让的代币也越来越近。

在开始时，如果你在中心化的情况下发布一个可转让的代币，你将面临极大的法律风险。但随着去中心化的进展，这些风险会逐渐减少。我稍后会用一个小图表来说明这个问题。你可以使用积分系统，积分的好处在于你可以激励人们，而不需要担心他们会受到损失。所谓的损失是指，有人购买了大量代币，但由于你发布了不当的推文，导致价格暴跌，他们就会对你提起诉讼，SE C（证券交易委员会）也会介入。这显然是我们要避免的情况。

为了避免这种情况，我们可以让代币不可转让。这样，人们可以赚取某种东西，但它没有市值，他们还无法确切知道其价值，但他们知道自己在积累某种东西。实际上，有大量的实证证据表明，人们确实会对这些激励机制做出反应。随着去中心化的程度加深，或许有一天我们可以让代币变得可转让。我们可能需要将团队、基金会和投资者锁仓，这样的长时间锁仓是好的。然后我们可以让通过空投或做出贡献而获得代币的人将其转让，并且形成市场价格。

关于测试网，有一种策略是把所有功能和代币转让性都整合到一起，并声称这只是一个测试网。然后，当你觉得一切就绪时，可以宣布“现在我们要在主网上做同样的事”，并把测试网的余额迁移到主网。

但是，如果你在迁移时保留了相同的余额，那么从一开始，这个所谓的“测试网”可能就已经具备主网的特性了。所以，在这种情况下，你需要格外谨慎。越是模糊测试网和主网的界限，潜在的风险就越大。如果它实际上已经是主网，用户仍然可能会承担损失，市场也会因此产生波动。

这很难准确描述，我也不是律师，但很多时候问题的关键在于它看起来怎么样。我并不是在开玩笑，我的意思是，真正要看的是你是否在促成一个高风险市场的形成，你是否承诺了钱，别人给你钱而最终失去了。如果这是事实，他们会狠狠地打击你，不管你多么巧妙地使用了法律术语。

所以，如果你真诚地在朝着正确的方向前进，且清晰地表明了这一点，同时保持诚实，没有做出疯狂的承诺，并且事实表明创建一个工作良好的企业已经很难了，创建一个去中心化且运行良好的加密协议更难，那么即使你在某些方面处于灰色地带，只要你的意图极为明确且良好，并且你竭尽全力避免对人造成伤害，那么你可能会处于一个相对安全的位置。

现在，很多网络在启动时，都会有一个测试网，所有功能都可以操作和转让，然后通过空投与测试网活动高度相关的方式进入主网。如果人们必须通过实际工作来赚取未来的空投，你告诉他们“这是你的积分，你做了一些真正的工作”，那么这不是金钱投资，而是他们在合法地帮助构建网络。如果你让人们向你转移大量资金，承诺以后会给他们很多有价值的积分，这就听起来像是一个销售行为。

判断去中心化的一个简单测试是：如果你消失了，如果你的团队消失了，如果代币发行方消失了，那么代币的价格会发生什么？如果代币价格会归零，那么你就不是真正去中心化的。如果代币价格会因为单一故障而归零，那么这个系统很可能并不是去中心化的。

如果人们将代币视为一种投资，那就是一个灰色地带。但这是一个简单的测试，可以让你考虑去中心化的程度。

有人可能会问：为什么我们不直接从底部开始？为什么不一开始就发行一个代币，然后再逐步增加功能？这个原因有些复杂，但非常清晰。首先，这是你在各个阶段面临的法律风险：在中心化状态下发布代币，风险极高；随着去中心化的加深，风险降低。而当你有了丰富的协议功能并且去中心化程度更高时，风险会进一步降低。

在完全去中心化的情况下，找到产品市场契合度的难度会非常大。因为你需要说服使用你系统的95% 的人去尝试一个可能有效也可能无效的实验，这几乎是不可能的。在中心化的情况下，找到产品市场契合度更容易，因为你可以控制局面，可以不断尝试，直到市场反馈告诉你这是有效的。所以，如果你将这些路径重叠，可以看到一条更清晰的道路：在中心化的情况下找到产品市场契合度，然后逐步去中心化，同时保持功能性。

关于去中心化和 Memecoins 的例子，这里有一个有趣的点。如果你发布了一个 Memecoins，且它是合法的，且你一切操作都符合法规，那么你可能会考虑在一段时间后再进行尝试，找到产品市场契合度。可是，一旦你开始从这个 Memecoins 中获利，比如大量出售，或者承诺用这个 Memecoins 作为协议的主要代币，你实际上可能会将去中心化的程度降低，从而将自己从安全区带回到危险区。这并不是单向的通行证，你不能保证自己就此永远不会变成证券。实际上，你可能会再次成为证券。所以，关于如何将 Memecoins 转换为网络代币的复杂性更高，这也是为什么我们推荐这种路径的原因。

Q：很多讨论围绕着代币的设计和方法，但在构建产品时，何时是开始考虑发行代币的最佳时机？是否有一个点，当你看到某些公司时，你会认为这是一个很好的时机来开始考虑代币设计和发行？

越早越好。在我看来，你应该首先设计一个协议，然后再考虑代币的角色。事实上，我认为没有例外，当你完成了协议设计的完整思路，并且系统运作方式明确时，你会发现代币的位置是显而易见的。

实际上，协议可能在没有代币的情况下无法正常运作。存在一种模式，即你可以先建立一个协议，然后再有一个集中式应用和业务。没有理由非得将两者结合起来。比如，Chris Dixon 有一个观点可以考虑：假设 Coinbase 制造了比特币。他们本可以这样做，尽管他们没有。你可以想象，第一家交易所可能会说，“我希望有一种数字资产，大家可以进行交易。”他们最终创造了比特币，并且它现在是完全去中心化的，开源的，所有我们喜欢的特性都具备，或许他们是早期的矿工，拥有相当数量的比特币，但比特币真正属于每个人，它是一个完全去中心化的协议。

与此同时，他们可以有一个传统的业务作为该协议的客户。这样，你的业务就是一种附属业务。考虑一下它们是如何互补的，它们一起做得更好。这是一种非常有说服力和合理的玩法：你可以有一个你喜欢的公司，但你需要一个协议，或者你喜欢一个协议，但你能想到一个公司愿意成为该协议的客户，然后共同开发、推广，让协议自主发展，比如 Uniswap 基金会就是真正独立于 Uniswap Labs 开发协议的。两者可能会走向不同的方向，甚至有可能相互竞争，这就是加密世界的方式。

Q：除了 Uniswap 和可能的 DYDX 之外，你们还看到哪些公司做得很好？

显然，BOD 做得也非常好，他们都来自 a16z。我很想知道其他公司如何成功地将中心化业务与代币结合，如何在代币和股权之间分配价值。如果有人问你，“价值是流向股权还是代币？”你会如何回答才能让人理解？

有些早期的例子我们可以线下讨论。对于第二个问题，因为时间有限，我只能简单回答。我们在投资时，通常喜欢同时拥有代币和股权。这不是因为我们想要一切，而是为了保持与创业者的对齐。创业者应当在后期做出这一决定，而这不应该成为创业者的限制。在许多情况下，他们原本认为项目会朝某个方向发展，比如我们以为只做一个协议并发放代币，股权只是一个工具，但后来公司可能会消失，然后他们决定做一个相邻的业务，或者反之，他们决定股权并不那么重要，他们希望成为多个基于该协议建设的公司之一。因此，在早期阶段，我建议保持开放心态，找到有效的市场契合度已经足够困难，不要在前期就给自己设限，让自己自由探索。你会在发展过程中逐渐学习。

接下来，我要快速过一下最后一部分。

这是一个假设的代币发行时间表，其中包含了很多信息。按照这个时间表，至少需要六个月才能发布代币。这段时间不仅包括协议设计、网络选择和协议代码的实施，还包括代币生成和发布前的准备工作。在代币生成和发布的六个月里，你需要与交易所谈判，进行安全审计，与机构托管人交涉，处理员工和团队的资产保管，设立基金会和治理结构，进行备案，还要与市场制造商沟通，分析空投和其他代币分发活动。发布代币的工作量很大，这只是一个假设性的时间表，实际上每个项目都是不同的。总之，发行代币不仅仅是将其部署到主网上就完事了，还需要处理一系列复杂的事务。幸运的是，这些事情变得越来越清晰，我可以帮助回答相关问题。

最后，我没有足够的时间深入讨论，但分发代币的方式只有四种。

第一个是代币销售，即向投资者销售代币，私下销售没有问题，法律也很明确；但销售给公众是个大问题，不要这样做。这是单一风险因素中最危险的之一。

第二种方式是定位。发布代币时，特别是当代币是协议的一部分时，人们需要访问这些代币，工作者需要出售代币来支付运营成本，未来的贡献者也需要购买代币。你希望市场成熟，但如果市场流动性差且不稳定，就会传递出糟糕的信号。成熟的公司在经历 IPO 过程时，经过了许多检验，需要足够的生存时间才能进行 IPO。代币早期发布时，所有人都能看到其波动，市场参与者也会参与其中，这就使得代币价格成为了一个公众的观赏对象。相比之下，正常的公司如果股票价格暴跌，通常说明公司经历了重大事件。但代币价格的波动有时被认为是正常现象。希望你能够平稳代币价格，使市场行为不那么疯狂，因为你不希望人们对早期协议有错误的认知。

第三种方式是自动化程序。我之前提到过，这些程序包括安全预算、支付可验证的高质量工作、供应侧等。基本上，这些程序是通过机制自动发行代币，以奖励你希望的类型。

最后一种方式是手动程序，比如空投。虽然空投有显著的优点和风险，但也有一些优点。像 Optimism 推广的 Grant 程序、奖励和合作伙伴关系，这些都是早期阶段可以采取的方式。通常，你可以考虑如何将代币分发给长期利益相关者，这些人会在你的协议上进行开发、筹集资金、建立自己的业务，或者带来用户。这样的做法最有助于协议的长期成功。