Bài viết này đến từ a16z cryptoBài viết này đến từ

, tác giả gốc: Guy Wuollet, dịch giả Katie Gu của Odaily biên dịch.

Trên thực tế, nhiều nhóm đấu tranh để tìm thiết kế mã thông báo "đúng" cho dự án của họ. Nhưng ngành công nghiệp thiếu một khung thiết kế đã được thử nghiệm, vì vậy các thế hệ tương lai liên tục gặp phải những thách thức giống như những người tiền nhiệm của họ. May mắn thay, cũng có (vài) ví dụ ban đầu về thiết kế mã thông báo thành công. Hầu hết các mô hình mã thông báo hiệu quả đều có các yếu tố độc đáo dành riêng cho mục tiêu của chúng, nhưng hầu hết các thiết kế mã thông báo thiếu sót đề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ế mã thông báo, chứ không chỉ là "kinh tế mã thông báo" và liệt kê bảy mẹo "cạm bẫy".

tiêu đề phụ

#1 Làm rõ các mục tiêu của thiết kế mã thông báoVấn đề lớn nhất trong thiết kế mã thông báo là làm thế nào để xây dựng một mô hình mã thông báo phức tạp trước các mục tiêu rõ ràng. Bước đầu tiên là xác định mục tiêu và đảm bảo toàn đội hiểu rõ: mục tiêu đó là gì, tại sao nó quan trọng,Bạn đang thực sự cố gắng đạt được điều gì?

Việc không xác định rõ ràng các mục tiêu thường dẫn đến việc thiết kế lại và lãng phí thời gian. Mục đích rõ ràng cũng giúp tránh vấn đề “phát minh ra nền kinh tế mã thông báo cho thiết kế nền kinh tế mã thông báo”, vấn đề phổ biến với một số thiết kế nền kinh tế mã thông báo.

• Ngoài ra, mục tiêu phải xoay quanh chính mã thông báo, nhưng điều này thường bị bỏ qua. Ví dụ về các mục tiêu rõ ràng bao gồm:

• Thiết kế trò chơi với mô hình mã thông báo cho phép khả năng mở rộng tối ưu và hỗ trợ lập mô hình.

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

• Việc thiết kế một giao thức danh tiếng đảm bảo tiền không thể thay thế trực tiếp danh tiếng (ví dụ: bằng cách tách thanh khoản khỏi các tín hiệu danh tiếng).

• Thiết kế một mạng lưu trữ giúp các tệp có sẵn với độ trễ thấp.

• Thiết kế một mạng lưới đặt cược cung cấp bảo mật kinh tế tối đa.

Thiết kế một cơ chế quản trị gợi ra sở thích thực sự của người dùng hoặc mức độ tương tác tối đa.

Danh sách cứ kéo dài. Hãy để các mã thông báo 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, chứ không phải ngược lại.Vậy làm thế nào để bạn bắt đầu xác định một mục tiêu rõ ràng?

Các mục tiêu được xác định rõ ràng thường bắt nguồn từ "sứ mệnh dự án". Trong khi "các nhiệm vụ của dự án" có xu hướng ở mức độ cao và trừu tượng, thì các mục tiêu phải cụ thể và được rút gọn ở dạng cơ bản nhất.

Hãy lấy EIP-1559 làm ví dụ. Roughgarden đã nêu mục tiêu rõ ràng cho EIP-1559: "EIP-1559 sẽ cải thiện trải nghiệm người dùng bằng các ước tính chi phí đơn giản dưới dạng 'giá thầu tốt nhất rõ ràng' ngoài thời kỳ tăng trưởng nhu cầu nhanh chóng."

Điểm chung của hai ví dụ này là nêu rõ mục tiêu cấp cao, đưa ra phép loại suy có 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 các phương án thiết kế hỗ trợ tốt nhất cho mục tiêu đó.

tiêu đề phụ

#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 một cái gì đó mới, bạn nên bắt đầu với những gì bạn đã có. 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 giá trị kỹ thuật của chúng.Các yếu tố này có thể không liên quan đến khả năng đạt được các mục tiêu đã nêu của mô hình mã thông báo. Việc định giá, mức độ phổ biến hoặc các cách đơn giản khác để đánh giá mô hình mã thông báo có thể khiến Nhà xây dựng “đi đường vòng nhiều hơn”. Nếu bạn cho rằng các mô hình mã thông báo khác hoạt động bình thường trong khi thực tế thì không, thì bạn có thể đang tạo một mô hình mã thông báo “có lỗi bẩm sinh”.

tiêu đề phụ

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

Nói rõ các giả định của bạn. Khi bạn tập trung vào việc xây dựng mã thông báo, bạn sẽ dễ dàng coi các giả định cơ bản là điều hiển nhiên. Bạn cũng dễ hiểu sai những giả định mà bạn đang thực hiện.

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

Trình bày rõ ràng các giả định của bạn giúp bạn hiểu thiết kế mã thông báo của mình dễ dàng hơn và đảm bảo rằng nó hoạt động. Bạn cũng không thể kiểm tra các giả định của mình mà không nói rõ về các giả định của mình.

tiêu đề phụ

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

Có câu nói: "Không phải điều bạn không biết khiến bạn gặp rắc rối. Mà chính điều bạn biết chắc chắn là không."

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

tiêu đề phụ

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

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

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

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

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

Bằng cách tạo các rào cản trừu tượng rõ ràng, các nhà thiết kế mã thông báo có thể dễ dàng dự đoán mức độ thay đổi cụ thể sẽ ảnh hưởng đến từng phần của thiết kế mã thông báo. Xóa các rào cản trừu tượng cũng giúp mở rộng quy mô mã thông báo hoặc giao thức dễ dàng hơn và tạo ra một cộng đồng Builder toàn diện và có thể mở rộng hơn.

tiêu đề phụ

#6 Giảm 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à vốn có của hệ thống, nhưng có thể ảnh hưởng đến hiệu suất và thành công tổng thể, chẳng hạn như chi phí tài nguyên máy tính, khối lượng giao dịch hoặc độ trễ trong giai đoạn đầu của quá trình tạo mô hình mã thông báo.Nhưng trong khi mô hình mã thông báo chỉ hoạt động khi các tham số được giữ trong một phạm vi giới hạn,Có thể thể hiện hành vi bất ngờ

Hoặc lấy một ví dụ khác, các mạng phi tập trung thường dựa vào các thuật toán mật mã hoặc các câu đố tính toán khó, nhưng không phải là không thể giải được. Độ khó thường phụ thuộc vào một biến ngoại sinh, chẳng hạn như tốc độ máy tính có thể tính toán hàm băm hoặc bằng chứng không kiến ​​thức. Hãy xem xét một giao thức đưa ra các giả định về tốc độ tính toán của một hàm băm nhất định và trả phần thưởng mã thông báo tương ứng. Nếu ai đó phát minh ra một cách mới để tính toán các hàm băm nhanh hơn hoặc đơn giản là có quá nhiều tài nguyên để giải quyết một vấn đề không tương xứng với công việc thực tế của họ trong hệ thống, thì họ có thể được thưởng bằng các mã thông báo lớn bất ngờ.

tiêu đề phụ

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

Thiết kế mã thông báo giống như thiết kế một hệ thống đối nghịch. Hành vi của người dùng sẽ thay đổi khi cách hoạt động của mã thông báo thay đổi.Một sai lầm phổ biến là điều chỉnh mô hình mã thông báo mà không đảm bảo rằng các hành động tùy ý của người dùng vẫn tạo ra kết quả có thể chấp nhận được. Đừng cho rằng hành vi của người dùng sẽ không thay đổi do mô hình mã thông báo thay đổi.

Thông thường, loại lỗi này xảy ra muộn trong quá trình thiết kế, khi ai đó dành nhiều thời gian để xác định mục tiêu của mã thông báo, xác định chức năng của mã thông báo và thực hiện xác thực để đảm bảo mã thông báo hoạt động như dự định. Sau đó, họ đã xác định một trường hợp đặc biệt và thay đổi thiết kế mã thông báo để phù hợp với trường hợp đó, nhưng lại quên xác thực lại toàn bộ mô hình mã thông báo. Bằng cách khắc phục một trường hợp đặc biệt, họ đã tạo ra một (hoặc một số) hậu quả ngoài ý muốn khác.