Bài gốc: Token Design: Mental Models, Capabilities, and Emerging Design Spaces with Eddy Lazzarin

Tác giả video: Eddy Lazzarin, a16z Crypto

Biên soạn: Qianwen, ChainCatcher

Eddy Lazzarin, Trưởng phòng Kỹ thuật của Nhóm Tiền điện tử, đề cập đến nhiều chủ đề khác nhau trong video này. Ông đề cập đến những cạm bẫy phổ biến mà nhiều người gặp phải khi cân nhắc thiết kế mã thông báo và các giải pháp khả thi. Anh ấy nghĩ rằng thiết kế mã thông báo là một lĩnh vực thực sự sớm và thực sự nên được gọi là thiết kế giao thức, bởi vì mã thông báo không phải là những gì bạn làm, những gì bạn thực sự làm là giao thức.

Mã thông báo là một công cụ mới rất thú vị, hữu ích và mạnh mẽ giúp thay đổi cách thiết kế các giao thức và những gì có thể đạt được, nhưng mã thông báo không phải là trung tâm của thiết kế. Thiết kế giao thức ngày nay giống như "giả kim thuật" hơn là một môn học, bởi vì sự hiểu biết của các nhà thiết kế còn lâu mới toàn diện hoặc khoa học, và hầu hết các dự án vẫn cần nhiều thử nghiệm.

Phần này được chia thành ba phần, bắt đầu với những tư duy chung trong thiết kế mã thông báo, tiếp theo 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 ta có thể 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ệ để làm cho thiết kế của chúng ta dễ thành công hơn.

1. Mô hình tư duy

Đầu tiên, mã thông báo dành cho giao thức, chúng là một công cụ, một phần của quy 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, thì mã thông báo có thể là một phần của điều đó bởi vì thật tuyệt khi mọi người có quyền sở hữu giao thức và cũng để giữ mọi người xếp hàng.

Ba giai đoạn thiết kế

Trong quá trình làm việc với các công ty trong danh mục đầu tư, tôi đã tóm tắt ba giai đoạn trong quy trình thiết kế thành công.

Giai đoạn 1: Xác định mục tiêu của bạn. Mục tiêu là một mô tả ngắn gọn về kết quả của một giao thức hợp lệ và nó phải rõ ràng liệu nó có đạt được bằng một thiết kế cụ thể hay không. Vì vậy chúng ta nên có sự phân biệt rấ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 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 Hai: Giới thiệu các hạn chế. Nói chung có hai loại ràng buộc, một là nội tại và một là ngoại sinh: ràng buộc nội tại là những thứ chúng ta chọn để đơn giản hóa quá trình thiết kế vì có một số sự đánh đổi phải thực hiện, hoặc bản thân chúng là sự đánh đổi. Giống như có tùy chọn để giới hạn các tính năng thú vị mà chúng tôi thích. Tôi đã xem các bài giảng của nhóm trò chơi Subset, họ đã thiết kế một số trò chơi rất hay, chẳng hạn như "Into the Battle" và "Fast Light", họ đã đề cập đến việc thiết kế dưới các ràng buộc. Tôi giới thiệu bài giảng này cho bất kỳ ai thiết kế các giao thức. Khi họ chọn giới hạn, họ chỉ xem xét điều thú vị trong trò chơi. Các ràng buộc nội tại có thể đến từ nhiều nguồn, nhưng thường được xác định bởi chính người thiết kế. Những ràng buộc ngoại sinh được áp đặt lên bạn bởi bản chất, trạng thái của công nghệ, các quy định và tất cả mọi thứ. Tôi sẽ nói về nó sau.

Giai đoạn thứ ba: cơ chế thiết kế. Khi chúng ta có một ràng buộc và một 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ế, nó sẽ thực sự rõ ràng nếu nó vi phạm những ràng buộc đó và giúp chúng ta tiến gần hơn đến mục tiêu đó. 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ể theo một số ràng buộc.

Lấy MakerDOA làm ví dụ. Mục tiêu của họ là phát triển một tài sản gốc Ethereum ổn định.Tất nhiên, có nhiều cách giải thích về tính ổn định và tính nguyên bản. Hạn chế của chúng là giá được chốt bằng USD; được hỗ trợ hoàn toàn bởi tài sản on-chain bản địa, v.v.

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

(1) Quá nhấn mạnh vào mã thông báo. Tôi đã đề cập đến vấn đề này một chút, nhưng nếu bạn luôn nghĩ về phần thưởng hoặc phân phối mã thông báo chứ không phải cách duy trì sự nhất quán giữa những người tham gia trong hệ thống của mình, thì có lẽ bạn không nghĩ về giao thức, bạn đang nghĩ 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ó mã thông báo? Nếu hệ thống bị lỗi hoàn toàn khi bạn xóa hoàn toàn mã thông báo, thì có thể bạn đang quá nhấn mạnh vai trò của mã thông báo. Sẽ tốt hơn là nếu một vài phần quan trọng của hệ thống bị lỗi, thì mã thông báo của bạn vẫn quan trọng và cần thiết cho sự cân bằng tổng thể, nhưng hệ thống vẫn nhất quán khi không có nó. Do đó, bạn vẫn nên suy nghĩ về các mục tiêu của hệ thống.

(2) Không gian thiết kế là không giới hạn. 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ó quá nhiều thứ có thể làm được. Điều này thường là do mục tiêu không rõ ràng nên cần phải tinh chỉnh lại mục tiêu. Cũng có thể do bạn chưa hiểu rõ 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 chúng.

Nếu bạn đưa những ràng buộc này vào hỗn hợp, bạn sẽ thấy rằng không gian thiết kế thu nhỏ lại và trở nên rõ ràng hơn nhiều. Hai câu hỏi giúp giới hạn không gian thiết kế là hãy tự hỏi: Ý 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 bản thân khái niệm mạnh mẽ này là gì? Làm thế nào để bạn có thể đạt được hiệu quả cao nhất và tập trung vào nó thay vì nghĩ về toàn bộ hệ thống trước. Một câu hỏi khác là: điểm yếu lớn nhất của thiết kế này là gì? Điều gì khiến bạn thao thức hàng đêm, đó là những điểm bạn nghĩ có thể không hiệu quả, những điểm bạn lo lắng, nhữ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ế rất nhiều không gian thiết kế.

(3) Luôn cho cộng đồng biết sự thật. Có những thách thức trong việc thiết kế một số phần của hệ thống, đẩy tất cả chúng cho cộng đồng để giải quyết hoặc mong đợi những thế lực vô hình 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ó, điều này rất rủi ro. Bất chấp sự phổ biến của các hệ thống không được phép và những đổi mới đáng kinh ngạc đã xảy ra, bạn không thể dự đoán hành động của cộng đồng, cũng như 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 bạn.

Có một vài câu hỏi chính 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ọ điều gì? Nó không đủ để yêu cầu chúng tôi cung cấp cho họ đủ mã thông báo sao? Thay vào đó, chúng ta đã trao cho họ những quyền hạn 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 một thứ gì đó, nếu bạn mong đợi những người đầy 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ó xây dựng ở đây không? Nếu bạn không muốn vì nó không có đủ ưu điểm, đủ sức mạnh hoặc đủ tính linh hoạt, thì đừng tìm đâu xa.

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

Đây không phải là một danh sách đầy đủ, tôi đã thảo luận điều 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 nó chỉ để liệt kê tất cả các khả năng mà chúng tôi đã thấy các mã thông báo 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ậy làm thế nào để chúng ta thấy cấu trúc dữ liệu này được sử dụng trong các giao thức khác nhau? Chúng có thể được nhóm thành năm danh mục rất chung chung: Thanh toán, Bỏ phiếu, Các bên liên quan, Siêu dữ liệu và Xác nhận quyền sở hữu. Tôi chắc chắn rằng sẽ có nhiều giải pháp hơn cho từng danh mục theo thời gian. Nhóm này ít nhất phù hợp với tôi. Cho biết cảm giác trực quan hơn .

Thanh toán

Chức năng thanh toán được chia thành ba loại, loại đầu tiên là tiền tệ nội bộ của cộng đồng hoặc dự án. Chúng tôi chưa thấy nhiều như thế này, nhưng có một vài ví dụ. Ví dụ: SourceCred là một ví dụ thú vị và FWB có thể đang đi theo hướng này. Nó khác với các phương thức thanh toán truyền thống như thanh toán bằng USD 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 loại tiền nội tệ này, chẳng hạn như loại tiền tệ này phải ổn định, Nên được chốt vào giá trị của một số tài sản cụ thể khác, có thể họ đúc hoặc đốt nó dựa trên các mục tiêu cụ thể, toàn cộng đồng.

Hình thức thanh toán thứ hai, và có lẽ là hình thức thanh toán được sử dụng phổ biến nhất và được hiểu rõ nhất để sử dụng tiền điện tử, là một tài nguyên trực tuyến và 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, dung lượng lưu trữ 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, tính 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 biệt là tài nguyên máy tính.

Mã thông báo thanh toán thứ ba tồn tại dưới dạng tiền tệ trò chơi tương tự. Ví dụ: trò chơi, tài nguyên hoặc một số tài nguyên giao thức cần ổ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á mã thông báo cũng cần tương đối ổn định. Việc nó có được cung cấp ổn định hay không không quan trọng, bởi vì bạn chỉ đang 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, một loại tiền tệ ổn định có thể được sử dụng để thanh toán theo ba cách trên. Nhưng điều làm cho một stablecoin trở thành một stablecoin là cơ chế đằng sau nó giúp ổn định nó, vì vậy các stablecoin thường thuộc danh mục sở hữu.

Quyền sở hữu

Nhìn chung có hai loại quyền sở hữu, trên chuỗi (tiền gửi) và ngoài chuỗi (quyền sở hữu). Mã thông báo tiền gửi thể hiện quyền sở hữu đối với các mã thông báo khác, một ví dụ là mã thông báo LP uniswap, là erc20 trong V2 và NFT trong V3. Dai, stablecoin xuất phát từ giao thức Maker, cũng là một khoản ký gửi trực tuyến vì bạn hoặc chủ sở hữu kho tiền sử dụng nó để xác nhận tài sản thế chấp cơ bản của họ. Vì vậy, mã thông báo tiền gửi 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 tuyến.

Mã thông báo thứ hai đại diện cho quyền sở hữu một số tài sản ngoài chuỗi, vì vậy đây có thể là thứ gì đó giống như 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ự. Chúng tôi chưa thấy nhiều ví dụ về điều này. Một ví dụ hiện đại hơn là thứ hiện được gọi là có thể đổi được, trong đó các mã thông báo có thể được đổi lấy các vật thể. Ví dụ: NFT được sử dụng để trao đổi tác phẩm nghệ thuật với tác phẩm nghệ thuật và NFT này đại diện cho quyền sở hữu sân. Thậm chí có một số giao dịch thú vị nếu bạn muốn. Bạn có thể sử dụng các đối tượng vật lý để kiểm soát NFT và kiểm soát quyền sở hữu của NFT tiếp theo thông qua một số chức năng kỹ thuật số như chip.

Bỏ phiếu

Biểu quyết có thể được sử dụng để tài trợ cho các dự án, phân bổ tài nguyên, tức là thực hiện thanh toán hoặc chuyển khoản theo nhóm và để thực hiện nâng cấp phần mềm. Nó cũng có thể được sử dụng như một 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 của một dự án.

Lời hứa

Mã thông báo có thể được thiết kế để được hưởng 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 cơ chế hoạt động có nghĩa là mã thông báo sẽ được hưởng lợi từ một số loại hoạt động trên chuỗi. Một ví dụ là Maker, nếu Maker hoạt động tốt, nếu chủ sở hữu mã thông báo Maker đang làm tốt công việc của họ và hệ thống hoạt động bình thường, thì họ sẽ được hưởng lợi từ một số lợi nhuận, đây là cách của hợp đồng thông minh, cách giao thức được thiết kế , Để thưởng cho sự quản trị tốt của cộng đồng.

Bạn cũng có thể tạo mã thông báo do các thỏa thuận pháp lý cho phép bạn trả lại hàng. Bạn có thể tạo một 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, tất nhiên là với các yêu cầu và hạn chế pháp lý khác nhau. Đã có lúc có những người về mặt lý thuyết có thể tạo mã thông báo bảo mật, mặc dù chúng ta chưa thấy nhiều về điều đó.

Mã thông báo cũng được sử dụng để bảo lãnh 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, thì sẽ tạo ra nhiều token Maker hơn, làm giảm giá trị mà những người nắm giữ Maker nắm giữ. Bằng cách nắm giữ mã thông báo Maker, chủ sở hữu sở hữu một số rủi ro, đây là một phần động lực thúc đẩy chủ sở hữu Maker thúc đẩy 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ợ sự phát triển của hệ thống này.

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ó quyền truy cập vào một không gian cụ thể hay không, liệu bạn có thuộc một cộng đồng cụ thể hay không hoặc liệu bạn có thuộc một số nhóm hay không. Các giao thức hoặc công cụ do một số bên thứ ba viết có thể sử dụng thuộc tính thành viên này theo bất kỳ cách nào mà 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ư nắm giữ mã thông báo này. Những cộng đồng cung cấp chức năng cụ thể và như thế. 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 các mã thông báo.

Mã thông báo cũng đại diện cho danh tiếng. Một số người đang tranh luận liệu danh tiếng có nên được chuyển nhượng hay không, cá nhân tôi nghĩ có 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 trong 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à một dữ liệu liên tục, vì vậy nó là một loại siêu dữ liệu.

Mã thông báo cũng đại diện cho danh tính hoặc tài liệu tham khảo. 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à một kyc ngoài chuỗi hoặc một số loại chứng chỉ có thể kiểm chứng được. 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 đó trao cho bạn chứng chỉ này và chứng chỉ này đượ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. Giống như một số thực thể cấp quyền cho bạn một cách rõ ràng, chẳng hạn như khả năng gọi một chức năng, thay đổi một đoạn mã hoặc chuyển thứ gì đó trên chuỗi. 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ụ về điều này, nơi bạn không chỉ có thể đặt dữ liệu SVG vào URI mã thông báo, bạn có thể đặt toàn bộ trang web HTML vào đó, 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, kiểm soát giao diện hoặc nhúng giao diện vào một đố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 vào NFT, sau đó bạn có thể truyền văn bản tới những người nắm giữ BEEP3R khác bằng cách sở hữu văn bản đó. Những văn bản này đượ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 sở hữu máy BEEP3R khác, giống như chỉ sử dụng xmtb.

Vậy chức năng của mã thông báo 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 tin nhắn. Bất kỳ giao diện ví nào 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à giao diện đó hỗ trợ tiêu chuẩn này.

Đây cũng là một mã thông báo nhận dạng, bởi vì với tư cách là chủ sở hữu BP, bạn có thể nhận và gửi thông tin. Vì vậy, điều này chỉ xảy ra trong bộ đó. Đó cũng là một mã thông báo nhận dạng, bởi vì họ gửi cho bạn mã thông báo ID BP của bạn. Đồng thời, nó cũng tồn tại dưới dạng một giao diện và có thể 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 đã đạt được tiến bộ vượt bậc, chẳng hạn như mã thông báo làm phương tiện thanh toán và tài nguyên mạng, trong khi một số lĩnh vực vẫn chưa phát triển, chẳng hạn như giao diện và siêu dữ liệu. Vậy tại sao lại như vậ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 vào những thời điểm 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 nợ trong một thỏa thuận cho vay, bạn muốn đại diện cho nó bằng một tài sản ổn định, bởi vì bạn có thể dự đoán giá của tài sản này, vì vậy chúng tôi cần tiền ổn định trước khi chúng tôi thực sự có một thỏa thuận cho vay.

Tương tự, chúng tôi cũng có một thỏa thuận cho vay yêu cầu AMM, bởi vì nếu bạn muốn sử dụng hợp đồng cho vay để làm đòn bẩy, đặc biệt là thỏa thuận 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ư tiền ổn định. Nếu bạn muốn đổi stablecoin đó lấy tài sản đó thật nhanh và bạn muốn tiếp xúc nhiều hơn, thì bạn cần có AMM. Mãi cho đến khi chúng tôi có AMM và stablecoin hoạt động thì các giao thức cho vay mới phát triển.

Nhưng làm thế nào để có được một AMM và stablecoin hoạt động? Điều này khó thực hiện nếu không có tiêu chuẩn mã thông báo có thể tương tác, bởi vì stablecoin, AMM và tất cả các hệ thống xung quanh chúng cần hiểu 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ó các hợp đồng thông minh có thể lập trình đầy đủ. Có thể bạn 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ó thể để lại đủ không gian thiết kế mở, tất nhiên điều này có thể được thảo luận thêm. Nhưng tóm lại, tôi nghĩ rằng có những cây công nghệ trong đó một số công nghệ nhất định là điều kiện tiên quyết cho những công nghệ khác.

Có hai câu hỏi ở đây: các công nghệ chính nào sẽ mở khóa các ứng dụng và giao thức trong tương lai? Đó là, chúng ta cần những công nghệ nào để phát triển các hệ thống danh tiếng hữu ích hoặc các giao diện phi tập trung và không tin cậy? Và câu hỏi thứ hai ngược lại hơi giống với câu hỏi đầ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, EIP4844, cây dọc, máy học không kiến ​​thức, v.v. Những câu hỏi này rất thú vị bởi vì nếu chúng ta có thể thấy trước sự xuất hiện của một số công nghệ giúp giảm bớt hoặc đưa ra các hạn chế trong thiết kế, thì điều đó sẽ thay đổi thiết kế của chúng ta như thế nào? Nếu có những công nghệ cụ thể có thể giảm bớt những hạn chế, chúng ta có nên dành năng lượng để 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 tôi 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 muốn. Vì vậy, liên kết nó trở lại điểm hạn chế ban đầu của tôi, tôi nghĩ rằng công nghệ mới làm 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ì các ràng buộc đối với bất kỳ thiết kế AMM hoặc stablecoin nào sẽ là nó cần phải đưa ra một tiêu chuẩn hoặc có thể đối phó với nhiều thiết kế khác nhau.

Hãy tưởng tượng việc thiết kế một AMM có mục đích chung nhưng không sử dụng một tiêu chuẩn mã thông báo cụ thể, điều đó sẽ rất, rất khó khăn. Tôi nghĩ rằng đây sẽ là một hạn chế gần như không thể vượt qua, nhưng có một 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 hạn chế không gian thiết kế và khiến điều đó trở nên khả thi.

Nếu chúng ta có thể dự đoán công nghệ nào sẽ xuất hiện trong tương lai, thì điều này ảnh hưởng như thế nào đến các ràng buộc đối với 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 ràng buộc cụ thể, 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à làm cho những mục tiêu này trở lại khả thi thông qua các cơ chế mới.