a16z: 7 gợi ý để tránh khuyết điểm trong thiết kế token

Tiêu đề gốc: 7 Kiểm tra Tâm lý Trước khi Thiết kế một Token

Tác giả: Guy Wuollet

Biên soạn: Katie 辜, Odaily 星球日报

Token là một nguyên lý mới mạnh mẽ có thể được định nghĩa theo nhiều cách khác nhau. Không gian thiết kế token rất phong phú, nhưng chúng ta vẫn đang ở giai đoạn khám phá ban đầu.

Trên thực tế, nhiều đội ngũ đang nỗ lực tìm kiếm thiết kế token "đúng đắn" cho dự án của họ. Tuy nhiên, ngành công nghiệp này vốn thiếu các khung thiết kế đã được kiểm nghiệm, do đó những người đi sau thường gặp phải những thách thức tương tự như những người đi trước. May mắn thay, cũng có (ít) ví dụ về thiết kế token thành công sớm. Hầu hết các mô hình token hiệu quả đều có những yếu tố độc đáo cho mục tiêu của chúng, nhưng hầu hết các thiết kế token có khuyết điểm đều có một số lỗi phổ biến. Do đó, bài viết này sẽ thảo luận về lý do tại sao chúng ta nên xem xét nghiên cứu và thiết kế token, không chỉ đơn thuần là "kinh tế token", và liệt kê bảy mẹo "tránh bẫy".

#1 Xác định rõ mục tiêu thiết kế token

Vấn đề lớn nhất trong thiết kế token là cách xây dựng mô hình token phức tạp trước khi xác định mục tiêu rõ ràng. Bước đầu tiên nên là xác định mục tiêu và đảm bảo toàn bộ đội ngũ có thể hiểu rõ: nó là gì, tại sao nó quan trọng, bạn thực sự muốn hoàn thành điều gì? Việc không định nghĩa rõ ràng mục tiêu thường dẫn đến việc phải thiết kế lại và lãng phí thời gian. Việc xác định rõ mục tiêu cũng giúp tránh vấn đề "bịa ra một kinh tế token để thiết kế kinh tế token", đây là hiện tượng phổ biến trong một số thiết kế kinh tế token.

Hơn nữa, mục tiêu nên xoay quanh bản thân token, nhưng điều này thường bị bỏ qua. Một số ví dụ về mục tiêu rõ ràng bao gồm:

• Thiết kế một mô hình token cho một trò chơi, mô hình này có thể đạt được khả năng mở rộng tốt nhất và hỗ trợ mô hình hóa.

• Một giao thức DeFi muốn thiết kế một mô hình token phân bổ rủi ro hợp lý giữa các người tham gia.

• Thiết kế một giao thức tín dụng cho tiền đảm bảo không thể thay thế trực tiếp tín dụng (ví dụ, bằng cách tách biệt tính thanh khoản và tín hiệu tín dụng).

• Thiết kế một mạng lưu trữ có thể đảm bảo tài liệu có sẵn trong điều kiện độ trễ thấp.

• Thiết kế một mạng staking có thể cung cấp an ninh kinh tế tối đa.

• Thiết kế một cơ chế quản trị có thể dẫn dắt sở thích thực sự của người dùng hoặc mức độ tham gia tối đa.

Có vô số ví dụ như vậy. Để token có thể hỗ trợ bất kỳ trường hợp sử dụng nào và đạt được bất kỳ mục tiêu nào, thay vì đi ngược lại.

Vậy làm thế nào để bắt đầu xác định một mục tiêu rõ ràng? Mục tiêu được định nghĩa rõ ràng thường đến từ "sứ mệnh dự án". Mặc dù "sứ mệnh dự án" thường ở cấp độ cao và trừu tượng, nhưng mục tiêu nên cụ thể và được đơn giản hóa thành hình thức cơ bản nhất.

Hãy lấy EIP-1559 làm ví dụ. Roughgarden đã phát biểu một mục tiêu rõ ràng cho EIP-1559: "EIP-1559 nên cải thiện trải nghiệm người dùng thông qua ước lượng phí đơn giản dưới dạng 'giá thầu tốt nhất rõ ràng' trong thời kỳ nhu cầu tăng nhanh."

Ông tiếp tục đưa ra một mục tiêu rõ ràng khác: "Chúng ta có thể thiết kế lại cơ chế phí giao dịch của Ethereum để việc thiết lập giá Gas cho giao dịch trở nên 'mượt mà' như khi mua sắm trên Amazon không? Lý tưởng nhất là một cơ chế công bố giá, có nghĩa là một cơ chế cung cấp cho mỗi người dùng một lựa chọn chấp nhận hoặc từ chối giá Gas."

Điểm chung của hai ví dụ này là chúng đã nêu ra một mục tiêu cấp cao, cung cấp một phép so sánh liên quan để giúp người khác hiểu mục tiêu của bạn, sau đó tiếp tục phác thảo thiết kế hỗ trợ tốt nhất cho mục tiêu đó.

#2 Đánh giá công việc hiện có dựa trên các nguyên tắc cơ bản

Khi tạo ra điều mới, việc nghiên cứu từ những gì đã có là một ý tưởng hay. Khi bạn đánh giá các giao thức hiện có và tài liệu hiện có, bạn nên đánh giá chúng một cách khách quan dựa trên những ưu điểm kỹ thuật của chúng.

Mô hình token thường được đánh giá dựa trên giá của token hoặc mức độ phổ biến của dự án liên quan. Những yếu tố này có thể không liên quan đến khả năng của mô hình token trong việc đạt được mục tiêu đã định. Việc định giá, mức độ phổ biến hoặc các phương pháp đơn giản khác để đánh giá mô hình token có thể dẫn đến việc Builder "đi lòng vòng". Nếu bạn giả định rằng các mô hình token khác hoạt động bình thường, trong khi thực tế chúng không hoạt động bình thường, thì có thể tạo ra một mô hình token "bẩm sinh đã có khuyết điểm".

#3 Làm rõ giả định của bạn

Rõ ràng diễn đạt giả định của bạn. Khi bạn tập trung vào việc xây dựng token, rất dễ dàng để coi những giả định cơ bản là hiển nhiên. Cũng rất dễ dàng để diễn đạt sai những giả định mà bạn thực sự đã đưa ra.

Lấy một giao thức mới làm ví dụ, giao thức này giả định rằng nút thắt phần cứng của nó là tốc độ tính toán. Việc đưa giả định đó vào một phần của mô hình token (ví dụ, bằng cách giới hạn chi phí phần cứng cần thiết để tham gia giao thức) có thể giúp giữ cho thiết kế phù hợp với hành vi mong đợi.

Tuy nhiên, nếu các nhà thiết kế giao thức và token không rõ ràng diễn đạt giả định của họ, hoặc giả định mà họ diễn đạt là sai, thì những người tham gia nhận ra sự không khớp này có thể rút giá trị từ giao thức. Những kẻ tấn công thường là những người hiểu hệ thống hơn cả những người ban đầu xây dựng hệ thống.

Làm rõ giả định của bạn có thể giúp người khác dễ dàng hiểu thiết kế token của bạn và đảm bảo nó hoạt động bình thường. Nếu không làm rõ giả định của bạn, bạn cũng không thể xác minh giả định của mình.

#4 Xác minh giả định của bạn

Có một câu nói: "Không phải những điều bạn không biết khiến bạn gặp rắc rối. Mà là những điều bạn chắc chắn là đúng lại không phải như vậy."

Mô hình token thường đưa ra một loạt giả định. Cách tiếp cận này một phần đến từ thiết kế hệ thống Byzantine, là nguồn cảm hứng cho blockchain. Hệ thống đưa ra một giả định và xây dựng một hàm, nếu giả định đó đúng, thì có thể đảm bảo một đầu ra nhất định. Ví dụ, Bitcoin đảm bảo tính khả dụng trong mô hình mạng đồng bộ, nếu 51% sức mạnh băm trong mạng là trung thực, thì đảm bảo tính nhất quán. Một số blockchain nhỏ hơn đã bị tấn công 51%, vi phạm số lượng giả định trung thực yêu cầu blockchain hoạt động bình thường theo sự đồng thuận của Satoshi Nakamoto.

Các nhà thiết kế token có thể xác minh giả định của họ bằng nhiều cách khác nhau. Mô hình thống kê nghiêm ngặt, thường dưới dạng mô hình dựa trên tác nhân, có thể giúp kiểm tra những giả định này. Các giả định về hành vi người dùng cũng thường có thể được xác minh bằng cách trò chuyện với người dùng, tốt hơn là thông qua việc quan sát những gì mọi người thực sự làm (thay vì những gì họ nói họ làm). Điều này có khả năng thành công cao hơn, đặc biệt là thông qua việc tạo ra kết quả kinh nghiệm trong một mạng thử nghiệm có động lực. Việc xác minh chính thức hoặc kiểm toán chặt chẽ cũng sẽ giúp đảm bảo rằng mã nguồn hoạt động như mong đợi.

#5 Làm rõ "rào cản trừu tượng"

"Rào cản trừu tượng" (abstraction barrier) là giao diện giữa các cấp độ khác nhau của hệ thống hoặc giao thức. Nó được sử dụng để tách biệt các thành phần khác nhau của hệ thống, cho phép thiết kế, triển khai và sửa đổi độc lập từng thành phần. Rào cản trừu tượng rõ ràng là hữu ích trong tất cả các lĩnh vực kỹ thuật, đặc biệt là trong lĩnh vực thiết kế phần mềm, nhưng nó càng cần thiết hơn cho phát triển phi tập trung và các đội ngũ lớn xây dựng các hệ thống phức tạp mà cá nhân không thể hiểu.

Trong thiết kế token, mục tiêu của việc làm rõ rào cản trừu tượng là giảm thiểu độ phức tạp. Giảm thiểu sự phụ thuộc (nội bộ) giữa các thành phần khác nhau của mô hình token có thể tạo ra mã đơn giản hơn, ít lỗi hơn và thiết kế token tốt hơn.

Lấy một ví dụ, nhiều blockchain được xây dựng bởi các đội ngũ kỹ sư lớn. Một đội có thể đưa ra giả định về chi phí phần cứng trong một khoảng thời gian và sử dụng nó để xác định có bao nhiêu thợ mỏ đóng góp phần cứng cho blockchain với một mức giá token nhất định. Nếu một đội khác phụ thuộc vào giá token như một tham số, nhưng không biết giả định của đội đầu tiên về chi phí phần cứng, họ rất dễ dàng đưa ra những giả định mâu thuẫn với nhau.

Ở cấp độ ứng dụng, rào cản trừu tượng rõ ràng là rất quan trọng để đạt được khả năng kết hợp. Khi ngày càng nhiều giao thức kết hợp với nhau, khả năng thích ứng, xây dựng, mở rộng và tái kết hợp chỉ trở nên quan trọng hơn. Cấu trúc lớn hơn mang lại nhiều khả năng hơn, nhưng cũng mang lại độ phức tạp lớn hơn. Khi các ứng dụng muốn kết hợp, chúng phải hiểu chi tiết của các giao thức kết hợp mà chúng đang sử dụng.

Các giả định và giao diện không rõ ràng đôi khi có thể dẫn đến các lỗi mơ hồ, đặc biệt là trong các giao thức DeFi ban đầu. Rào cản trừu tượng không rõ ràng cũng làm tăng hiệu suất giao tiếp cần thiết giữa các đội ngũ xử lý các thành phần khác nhau của giao thức, kéo dài thời gian phát triển. Rào cản trừu tượng không rõ ràng cũng làm tăng độ phức tạp của giao thức, khiến rất khó để hiểu hoàn toàn cơ chế của nó.

Bằng cách tạo ra các rào cản trừu tượng rõ ràng, các nhà thiết kế token có thể dễ dàng dự đoán cách mà các thay đổi cụ thể sẽ ảnh hưởng đến từng phần của thiết kế token. Rào cản trừu tượng rõ ràng cũng làm cho việc mở rộng token hoặc giao thức trở nên dễ dàng hơn và tạo ra một cộng đồng Builder bao gồm và mở rộng hơn.

#6 Giảm thiểu sự phụ thuộc vào các tham số bên ngoài

Các tham số bên ngoài không phải là nội tại của hệ thống, nhưng chúng có thể ảnh hưởng đến hiệu suất tổng thể và thành công, chẳng hạn như chi phí tài nguyên tính toán, khối lượng giao dịch hoặc độ trễ trong giai đoạn đầu của việc tạo ra mô hình token.

Nhưng khi mô hình token chỉ hoạt động khi các tham số giữ trong một phạm vi hạn chế, có thể xảy ra hành vi bất ngờ. Ví dụ, một giao thức bán dịch vụ và cung cấp hoàn tiền dưới dạng phần thưởng token cố định, nếu giá token cao ngoài dự kiến, thì giá trị của phần thưởng token có thể lớn hơn chi phí của dịch vụ. Trong trường hợp này, việc mua dịch vụ không giới hạn từ giao thức sẽ rất hợp lý, tận dụng tối đa phần thưởng token và dịch vụ.

Hoặc một ví dụ khác, mạng phi tập trung thường phụ thuộc vào các thuật toán mã hóa hoặc bài toán tính toán, những bài toán này khó giải nhưng không phải là không thể giải. Độ khó thường phụ thuộc vào một biến số bên ngoài, chẳng hạn như tốc độ mà máy tính tính toán hàm băm hoặc chứng minh không kiến thức. Ví dụ, có một giao thức giả định tốc độ tính toán hàm băm nhất định và trả phần thưởng token tương ứng. Nếu ai đó phát minh ra một phương pháp tính toán hàm băm nhanh hơn, hoặc chỉ đơn giản là có nguồn lực khổng lồ không tương xứng với công việc thực tế của họ trong hệ thống, họ có thể nhận được phần thưởng token khổng lồ ngoài dự kiến.

#7 Xác minh lại giả định

Thiết kế một token nên giống như thiết kế một hệ thống đối kháng. Hành vi của người dùng sẽ thay đổi khi cách thức hoạt động của token thay đổi.

Một sai lầm phổ biến là điều chỉnh mô hình token mà không đảm bảo rằng hành vi của người dùng tùy ý vẫn tạo ra kết quả chấp nhận được. Đừng nghĩ rằng hành vi của người dùng sẽ giữ nguyên khi mô hình token thay đổi. Thường thì sai lầm này xảy ra vào giai đoạn cuối của quá trình thiết kế, khi ai đó đã dành nhiều thời gian để xác định mục tiêu của token, xác định chức năng của nó và thực hiện xác minh để đảm bảo nó hoạt động như mong đợi. Sau đó, họ xác định một trường hợp đặc biệt và thay đổi thiết kế token để phù hợp với nó, nhưng quên xác minh lại toàn bộ mô hình token. Bằng cách sửa chữa một trường hợp đặc biệt, họ đã tạo ra một hậu quả không mong muốn khác (hoặc một số hậu quả khác).

Hãy nhớ đừng để công sức của bạn trở nên vô ích, hãy xác minh lại xem mô hình token có hoạt động như mong đợi mỗi khi dự án thay đổi mô hình token của nó.