Tiêu đề gốc: 7 kiểm tra độ tỉnh táo trước khi thiết kế mã thông báo
Tác giả: Guy Wuollet
Biên soạn bởi: Katie Gu, Odaily Planet Daily
Mã thông báo là một dạng nguyên thủy mới mạnh mẽ có thể được định nghĩa theo nhiều cách. Không gian thiết kế mã thông báo rất phong phú, nhưng chúng tôi vẫn đang trong giai đoạn đầu khám phá.
Trên thực tế, nhiều nhóm gặp khó khăn trong việc tìm ra thiết kế mã thông báo “phù hợp” cho dự án của họ. Tuy nhiên, ngành này thiếu một khuôn khổ thiết kế đã được thử nghiệm nên các thế hệ sau liên tục 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ó (một 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ố 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 lý do tại sao chúng ta nên xem xét việc nghiên cứu và thiết kế mã thông báo thay vì chỉ “kinh tế mã thông báo” và liệt kê bảy mẹo để tránh những cạm bẫy.
#1 Làm rõ mục tiêu của thiết kế token
Vấn đề lớn nhất trong thiết kế token là làm thế nào để xây dựng một mô hình token phức tạp trước khi 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 rằng cả nhóm hoàn toàn hiểu nó: nó là gì, tại sao nó quan trọng và bạn thực sự muốn đạ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 phải thiết kế lại và lãng phí thời gian. Có mục tiêu rõ ràng cũng giúp tránh được vấn đề “tạo nên nền kinh tế mã thông báo vì mục đích thiết kế nền kinh tế mã thông báo”, vốn là một hiện tượng phổ biến trong một số thiết kế 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ợ mô hình hóa.
Giao thức DeFi hy vọng sẽ thiết kế một mô hình token phân phối rủi ro hợp lý giữa những người tham gia.
Thiết kế một giao thức danh tiếng đảm bảo tiền không thể trực tiếp thay thế danh tiếng (ví dụ: bằng cách tách tính thanh khoản khỏi tín hiệu danh tiếng).
Thiết kế mạng lưu trữ đảm bảo các tệp luôn sẵn có với độ trễ thấp.
Thiết kế một mạng lưới đặt cược mang lại sự an toàn kinh tế tối đa.
Thiết kế cơ chế quản trị khơi gợi sở thích thực sự của người dùng hoặc tối đa hóa sự tham gia.
Danh sách cứ kéo dài. Hãy để mã thông báo hỗ trợ mọi trường hợp sử dụng và đạt được bất kỳ mục tiêu nào, thay vì 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 xuất phát từ “nhiệm vụ của dự án”. Trong khi “sứ mệnh 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 thành 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 thông qua ướ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ỳ nhu cầu tăng trưởng nhanh chóng."
Ông tiếp tục đề xuất 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 để làm cho việc thiết lập giá gas giao dịch trở nên 'mượt mà' hơn như mua sắm trên Amazon không? Lý tưởng nhất là một cơ chế xuất bản giá, nghĩa là một cơ chế để mỗi người dùng chấp nhận hoặc từ bỏ giá xăng."
Điểm chung của cả hai ví dụ là bạn nêu ra mục tiêu cấp cao, đưa ra sự so sánh có liên quan để giúp người khác hiểu mục tiêu của bạn và sau đó tiếp tục phác thảo giải pháp thiết kế hỗ trợ tốt nhất cho mục tiêu đó.
#2 Đánh giá công việc hiện tại 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 từ cái gì đó đã tồn tại. Khi bạn đánh giá các giao thức hiện có và tài liệu hiện có, chúng phải được đánh giá khách quan dựa trên giá trị kỹ thuật của chúng.
Các 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 để đạt được các mục tiêu đã nêu. Việc định giá, mức độ phổ biến hoặc các cách đánh giá mô hình mã thông báo đơn giản khác có thể khiến các nhà xây dựng phải “đi đường vòng”. Nếu bạn cho rằng các mô hình mã thông báo khác đang hoạt động bình thường trong khi thực tế lại không như vậy, thì bạn có thể tạo một mô hình mã thông báo "vốn có sai sót".
#3 Làm rõ các giả định của bạn
Hãy làm rõ các giả định của bạn. Khi bạn tập trung vào việc xây dựng một đồng xu, bạn rất dễ coi đó là điều hiển nhiên. Bạn cũng rất dễ nhầm lẫn những giả định mà bạn thực sự đang đưa ra.
Lấy ví dụ, một giao thức mới giả định rằng nút thắt cổ chai phần cứng của nó là tốc độ tính toán. Việc biến giả định này 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 điều chỉnh thiết kế với hành vi mong muốn.
Tuy nhiên, nếu người thiết kế giao thức và mã thông báo không thể hiện rõ ràng các giả định của họ hoặc các giả định mà họ đưa ra là sai. Những người tham gia nhận thức được sự không phù hợp này sẽ có khả năng trích xuất giá trị từ giao thức. Tin tặc thường là những người hiểu rõ hệ thống hơn những người xây dựng nó ban đầu.
Việc làm rõ các giả định của bạn giúp mọi người dễ hiểu thiết kế mã thông báo của bạn hơn và đảm bảo nó hoạt động chính xác. Nếu bạn không làm rõ giả thuyết của mình, bạn sẽ không thể kiểm tra giả thuyết của mình.
#4 Kiểm tra giả định của bạn
Có một 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”.
Các 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 xuất phát từ thiết kế hệ thống Byzantine, vốn 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 mà nếu giả định đó đúng thì sẽ đảm bảo một đầu ra nhất định. Ví dụ: Bitcoin đảm bảo hoạt động trong mô hình mạng đồng bộ, đảm bảo tính nhất quán nếu 51% sức mạnh băm trong mạng là trung thực. Một số blockchain nhỏ hơn đã phải hứng chịu các cuộc tấn công 51%, vi phạm số lượng giả định trung thực mà sự đồng thuận của Satoshi yêu cầu để các blockchain hoạt động bình thường.
Các nhà thiết kế mã thông báo có thể xác minh các giả định của họ theo nhiều cách khác nhau. 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 xác minh bằng cách nói chuyện với người dùng và tốt hơn nữa là bằng cách quan sát những gì mọi người thực sự làm (thay vì nói những gì họ làm). Khả năng xác thực thành công cao hơn, đặc biệt là với các 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 thực 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ã hoạt động như mong đợi.
#5 Xác định “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 để phân 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 mọi 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 cho 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à không một cá nhân nào có thể hiểu được.
Trong thiết kế mã thông báo, mục tiêu xóa bỏ các rào cản trừu tượng là giảm thiểu độ phức tạp. 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 có thể 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 blockchain được xây dựng bởi các nhóm kỹ thuật 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 thông tin đó để xác định số lượng thợ mỏ đóng góp phần cứng cho chuỗi khối ở một mức giá token nhất định. Nếu một nhóm khác dựa vào giá mã thông báo làm thông 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 nhau.
Ở lớp ứng dụng, các 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 nhiều giao thức được kết hợp với nhau hơn, khả năng thích ứng, xây dựng, mở rộng và phối lại sẽ chỉ trở nên quan trọng hơn. Các tác phẩm lớn hơn mang lại 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.
Các giả định và giao diện không rõ ràng đôi khi có thể dẫn đến các lỗi khó hiểu, đặc biệt là trong các giao thức DeFi đời đầu. Rào cản trừu tượng mờ cũng làm tăng hiệu quả giao tiếp cần thiết giữa các nhóm làm việc trên các thành phần khác nhau của giao thức, từ đó kéo dài thời gian phát triển. Các rào cản trừu tượng mơ hồ cũng làm tăng độ phức tạp của giao thức, khiến việc hiểu đầy đủ về cơ chế của nó trở nên khó khă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ế mã thông báo có thể dễ dàng dự đoán những thay đổi cụ thể sẽ ảnh hưởng đến từng phần của thiết kế mã thông báo như thế nào. Các rào cản trừu tượng rõ ràng cũng giúp việc mở rộng mã thông báo hoặc giao thức trở nên dễ dàng hơn và tạo ra một cộng đồng Builder toàn diện và có khả năng mở rộng hơn.
#6 Giảm sự phụ thuộc vào các thông 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 tạo mô hình mã thông báo.
Nhưng khi mô hình mã thông báo chỉ hoạt động khi các tham số được giữ trong phạm vi giới hạn thì có thể xảy ra hành vi không mong muốn. Ví dụ: một giao thức bán dịch vụ và cung cấp giảm giá dưới dạng phần thưởng mã thông báo cố định có thể có giá trị cao hơn chi phí dịch vụ nếu giá mã thông báo cao bất ngờ. Trong trường hợp này, việc mua các dịch vụ không giới hạn từ giao thức sẽ khá tiết kiệm chi phí, điều này sẽ tận dụng tối đa các phần thưởng và dịch vụ mã thông báo.
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ã hóa 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 có kiến thức. Ví dụ: có một giao thức giả định 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 hàm băm nhanh hơn hoặc đơn giản là có nguồn lực quá lớn để giải quyế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, họ có thể được thưởng những mã thông báo khổng lồ bất ngờ.
#7 Xác nhận lại các giả định
Thiết kế mã thông báo cũng 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 thức hoạt động của mã thông báo thay đổi.
Một lỗi phổ biến là điều chỉnh mô hình mã thông báo mà không đảm bảo rằng hành vi 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 những thay đổi trong mô hình mã thông báo. 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 nó và xác thực nó để đả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 cho phù hợp nhưng lại quên xác nhận 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 (hoặc một số) hậu quả không mong muốn khác.
Hãy nhớ đừng để công sức của bạn bị lãng phí, bất cứ khi nào dự án thay đổi mô hình mã thông báo, hãy xác minh lại rằng nó đang hoạt động như mong đợi.