a16z: 8 thách thức trong thiết kế cơ chế blockchain
Tuyển chọn TechFlowTuyển chọn TechFlow
a16z: 8 thách thức trong thiết kế cơ chế blockchain
Crypto và Web3 đầy rẫy các vấn đề về thiết kế cơ chế.
Chuyên sâu báo cáo Web3Tác giả: Tim Roughgarden, Trưởng nhóm nghiên cứu a16z crypto
Biên dịch: 0xxz, Jinse Finance
Nghiên cứu sâu về một lĩnh vực sẽ dạy bạn nhận ra rằng những vấn đề xuất hiện trong thế giới thực chỉ là những phiên bản thô sơ của các vấn đề đã được giải quyết ổn thỏa. Ví dụ, khi giảng dạy kiến thức nền tảng về thuật toán, sinh viên học cách nhận diện những vấn đề có thể quy về bài toán tìm đường đi ngắn nhất hoặc lập trình tuyến tính.
Mô hình tương tự cũng hiệu quả trong thiết kế cơ chế – một dạng "lý thuyết trò chơi ngược" sử dụng động lực để đạt được kết quả mong muốn. Các công cụ và bài học từ thiết kế cơ chế đặc biệt hữu ích trong lý thuyết đấu giá, thiết kế thị trường và lý thuyết lựa chọn xã hội.
Crypto và web3 tràn ngập các vấn đề thuộc phạm trù thiết kế cơ chế. Người ta có thể nghĩ rằng nhiều vấn đề này có thể được giải quyết bằng cách áp dụng trực tiếp các nội dung trong sách giáo khoa, điều chỉnh lại những ý tưởng cũ cho bối cảnh mới. Tuy nhiên, những thách thức và hạn chế độc đáo từ các giao thức blockchain không cần cấp phép thường buộc chúng ta phải suy nghĩ lại các nguyên tắc cơ bản của những vấn đề tưởng chừng như đã được giải quyết. Điều này khiến thiết kế cơ chế trong web3 trở nên phức tạp. Nhưng chính những thách thức đó cũng làm cho thiết kế cơ chế trong web3 trở nên hấp dẫn.
Trong bài viết này, tôi sẽ thảo luận về một số thách thức mà thiết kế cơ chế trong web3 đang đối mặt. Những thách thức này có lẽ rất quen thuộc với người dùng bản địa trong lĩnh vực tiền mã hóa, nhưng hiểu sâu hơn về thiết kế cơ chế sẽ cung cấp một góc nhìn mới cho mọi nhà phát triển, giúp họ hiểu rõ tại sao việc giải quyết các vấn đề này lại khó đến vậy. Đối với các chuyên gia thiết kế cơ chế, nếu bạn đang cân nhắc xây dựng ứng dụng mới, bạn có thể thấy thú vị trước những thử thách mà môi trường không cần cấp phép mang lại.
Nhưng trước tiên, chúng ta cần hiểu rõ, thiết kế cơ chế là gì?
Lĩnh vực thiết kế cơ chế hình thành ít nhất từ năm 1961, khi nhà kinh tế học Đại học Columbia, sau này đoạt giải Nobel, William Vickrey chính thức mô tả hình thức đấu giá kín giá thứ hai. Dù hình thức này từng được tác giả Johann Wolfgang von Goethe sử dụng vào năm 1797 để bán bản thảo tác phẩm sử thi "Hermann und Dorothea", và phổ biến trong cộng đồng sưu tập tem vào thế kỷ 19, nhưng mãi đến năm 1961 mới được Vickrey chính thức hóa, nay thường gọi là "đấu giá Vickrey". Trong đấu giá Vickrey, người trả giá cao nhất chiến thắng nhưng chỉ phải trả mức giá bằng mức giá cao thứ hai. Loại đấu giá này khuyến khích người tham gia bộc lộ sở thích thật sự và trao tài sản cho người đánh giá cao nhất.
Đấu giá Vickrey là một thiết kế thanh lịch và hiệu quả, đã được áp dụng vào thực tiễn và điều chỉnh theo hoàn cảnh mới; thực tiễn bổ sung lý thuyết, và ngược lại. Giống như đấu giá Vickrey, quá trình phát triển của thiết kế cơ chế như một ngành khoa học chính thức là một lịch sử đan xen giữa lý thuyết và thực hành – vừa sâu sắc vừa đẹp đẽ.
Ngược lại với lý thuyết trò chơi – nơi xây dựng chiều kích tương tác chiến lược và khám phá kết quả hợp lý nhất từ hành vi – thiết kế cơ chế không bắt đầu từ trò chơi, mà từ kết quả mong muốn. Mục tiêu của thiết kế cơ chế là đảo ngược kỹ thuật để tạo ra một dạng trò chơi nào đó, sao cho kết quả mong muốn (có thể được đặc trưng bởi hiệu suất, công bằng hoặc một hành vi nhất định) đạt tới trạng thái cân bằng. Trong ví dụ đấu giá Vickrey, mục tiêu cuối cùng là thu hút người tham gia trả mức giá tối đa họ sẵn sàng chi trả mà không trừng phạt họ.
Cơ hội ứng dụng thiết kế cơ chế trong web3 là rất lớn. Chẳng hạn, một giao thức blockchain có thể muốn đạt được kết quả là các bên tham gia tuân thủ đúng hành vi (mà không lệch khỏi hành vi dự kiến). Hoặc, giao thức có thể muốn thu thập thông tin chính xác về giá trị giao dịch để phân bổ không gian khối một cách hiệu quả cho những giao dịch có giá trị cao nhất.
Những vấn đề thiết kế cơ chế như vậy luôn đầy thách thức, và trong môi trường blockchain thì thách thức còn đặc biệt hơn nữa.
1. Thiếu niềm tin
Thiết kế trong lĩnh vực blockchain trở nên khó khăn hơn khi không có bên đáng tin cậy nào để thực thi cơ chế.
Toàn bộ ý nghĩa của việc sử dụng các giao thức blockchain không cần cấp phép là bạn không cần phải tin tưởng bất kỳ thực thể hay cá nhân nào, mà chỉ cần giả định niềm tin ở mức trung bình – tức là đủ nhiều nút vận hành giao thức là trung thực.
Nhưng nghịch lý trong nhiều kiến trúc blockchain là mỗi lô giao dịch được thêm vào chuỗi lịch sử – và được thực thi trong máy ảo do giao thức duy trì – lại là sản phẩm của quyết định đơn phương từ một nút duy nhất.
Bạn không biết liệu có thể tin tưởng nút đó hay không.
Đây là lý do vì sao đấu giá Vickrey hiếm khi xuất hiện trong lĩnh vực blockchain. Việc triển khai đơn giản đấu giá Vickrey nhanh chóng gặp phải vấn đề bị thao túng bởi nhà sản xuất khối không đáng tin cậy. Cụ thể, một nhà sản xuất khối có thể tạo ra một "giá thầu giả" (shill bid), đặt giá thầu thấp hơn chút ít so với người sắp thắng, buộc người thắng phải trả gần như toàn bộ giá thầu của họ (thay vì mức giá thật sự cao thứ hai).
Việc nhà sản xuất khối không đáng tin cậy đưa ra giá thầu giả khiến đấu giá Vickrey trên thực tế suy giảm thành đấu giá giá thứ nhất – đây cũng là một phần lý do vì sao đấu giá giá thứ nhất lại phổ biến trong web3. (Dòng nghiên cứu mới nhất trong văn liệu thiết kế cơ chế truyền thống về "cơ chế đáng tin cậy" cũng xem xét thiết kế đấu giá với người tổ chức đấu giá không đáng tin cậy, nhưng từ một góc độ khác.)
2. Thường xuyên cấu kết
Một lý do khác khiến thiết kế cơ chế blockchain trở nên khó khăn là khả năng cấu kết giữa các bên tham gia. Ví dụ, đấu giá giá thứ hai dễ bị cấu kết thông qua thanh toán bồi hoàn. Lý do rất đơn giản: vì người trúng thầu chỉ phải trả mức giá cao thứ hai, nên người tham gia có thể hối lộ người trả giá cao thứ hai để họ đặt giá thấp hơn nhiều.
Văn liệu học thuật về thiết kế cơ chế không quá lo ngại về vấn đề này. Một lý do có thể là việc cấu kết (đặc biệt là với thanh toán bồi hoàn) rất khó thực hiện trong thế giới thực. Sau khi cấu kết, người thắng hoàn toàn có thể từ chối trả tiền hối lộ, do đó rất khó để đảm bảo thanh toán bồi hoàn đáng tin cậy. (Có câu nói: “kẻ trộm không có đạo đức với nhau”.)
Tuy nhiên, trong bối cảnh blockchain, những người có khả năng cấu kết thường có thể sử dụng hợp đồng thông minh để cam kết đáng tin cậy, khiến việc cấu kết thực sự diễn ra. Một lý do khác là thiếu cơ chế ngăn chặn cấu kết với thanh toán bồi hoàn – cơ chế "công bố giá" chỉ cung cấp báo giá, không hơn.
Tệ hơn nữa, người dùng giao thức không chỉ có thể cấu kết với nhau, mà còn có thể cấu kết với nhà sản xuất khối (không đáng tin cậy) – tương đương với việc người đấu giá cấu kết với người tổ chức đấu giá trong đấu giá đời thực.
Sự chống lại loại cấu kết cuối cùng này là một trong những động lực chính đằng sau việc đốt một phần phí giao dịch trong cơ chế phí Ethereum EIP-1559. Nếu không có việc "đốt" (hoặc giữ lại thu nhập này khỏi nhà sản xuất khối bằng cách khác), nhà sản xuất khối và người dùng cuối có thể cấu kết thông qua thanh toán bồi hoàn và né tránh bất kỳ mức giá sàn nào mà cơ chế cố gắng áp đặt.
3. Không thể chỉ dựa vào pháp luật
Vấn đề cấu kết rõ ràng không phải là mới. Nó đã ám ảnh nhiều cơ chế trong đời sống thực tế hàng thế kỷ, nhưng nếu bạn đọc văn liệu thiết kế cơ chế, bạn có thể ngạc nhiên khi thấy nó hầu như không được giải quyết. Văn liệu này đúng là bàn trực diện về động cơ thao túng cơ chế một cách đơn phương từ các cá nhân tham gia, nhưng thường mặc định vấn đề này được xử lý bởi một khái niệm mơ hồ về "pháp luật". Ví dụ, người tham gia cơ chế có thể ký hợp đồng pháp lý cam kết không cấu kết. Nếu phát hiện cấu kết, vụ việc sẽ được chuyển sang kênh pháp lý. Nhà thiết kế cơ chế có thể hỗ trợ bằng cách tạo ra cơ chế dễ phát hiện cấu kết.
Có một bí mật ngầm hiểu trong nhiều văn liệu thiết kế cơ chế: sự phụ thuộc vào pháp luật. Dù ta không thể nói là không có pháp luật trong lĩnh vực giao thức blockchain không cần cấp phép – chúng ta thường thấy cơ quan thực thi pháp luật thành công trong việc truy tố hành vi phạm tội trên blockchain không cần cấp phép – nhưng mức độ pháp luật vẫn thấp hơn nhiều so với các ứng dụng thiết kế cơ chế truyền thống.
Nếu bạn không thể dựa vào pháp luật bên ngoài cơ chế, thì trách nhiệm giải quyết vấn đề phải nằm trong cơ chế. Cách tiếp cận này phổ biến trong các quyết định thiết kế cơ chế trong lĩnh vực blockchain. Đặc biệt trong giao thức Ethereum, từ việc đốt phần phí cơ bản EIP-1559 đến việc tịch thu tài sản của các trình xác thực hành xử sai trong giao thức đồng thuận, có vô số ví dụ.
4. Không gian thiết kế rộng lớn hơn
Không gian thiết kế trong web3 lớn hơn nhiều so với những gì các nhà thiết kế cơ chế quen thuộc. Do đó, các nhà thiết kế phải suy nghĩ lại mọi vấn đề đã cho. Ví dụ, nhiều cơ chế liên quan đến thanh toán, trong các ứng dụng thiết kế cơ chế truyền thống, các khoản thanh toán này sẽ được thực hiện bằng tiền pháp định như đô la Mỹ. Nhiều giao thức blockchain có tiền tệ nội sinh riêng, và các cơ chế bên trong giao thức có khả năng thao tác với tiền tệ này.
Hãy tưởng tượng nếu bạn viết một bài về thiết kế cơ chế truyền thống, trong phần mô tả cơ chế có đoạn: "In một đống tiền mới rồi phân phát cho một nhóm người tham gia." Nhìn từ ngoài bối cảnh blockchain, điều này thật hoang đường. Nhưng khi nói về thiết kế cơ chế trong bối cảnh giao thức blockchain, bạn hoàn toàn có thể làm điều đó. Giao thức kiểm soát tiền tệ, do đó một phần cơ chế của giao thức có thể đúc token hoặc đốt token.
Điều này có nghĩa là một số thiết kế vốn không thể thực hiện nếu không có tiền tệ nội sinh nay trở nên khả thi. Ví dụ, làm thế nào để khuyến khích thợ đào Bitcoin thực hiện giao thức như mong đợi? Thông qua phần thưởng lạm phát: in tiền mới (Bitcoin) để thưởng cho các nhà sản xuất khối này. Nếu không có tiền tệ nội sinh, thiết kế như vậy là không thể.
5. Tiền tệ nội sinh có thể gây ra các vấn đề khác
Điểm trước nhấn mạnh sức mạnh của tiền tệ nội sinh. Bạn có thể làm hai việc với tiền tệ nội sinh: "đúc tiền" (như giao thức Bitcoin đúc Bitcoin mới để thưởng cho thợ đào) và "đốt token" (như cơ chế phí giao dịch EIP-1559 của Ethereum đốt ETH để chống cấu kết). Tiền tệ nội sinh tiềm ẩn những rủi ro không tồn tại trong thiết kế cơ chế truyền thống: các quyết định thiết kế vi mô có thể tạo ra hậu quả vĩ mô.
Trong thiết kế cơ chế truyền thống, không có lý do gì để lo lắng về các lực lượng vĩ mô. Các hình thức đấu giá truyền thống không ảnh hưởng đáng kể đến cung tiền hay tỷ lệ lạm phát của Mỹ. Đây là thử thách hoàn toàn mới đối với lĩnh vực thiết kế web3. Sẽ xảy ra vấn đề gì? Tôi sẽ đưa ra hai ví dụ, một về việc đúc Bitcoin, một về việc đốt ETH.
Do sử dụng phần thưởng khối – in tiền mới để thưởng cho thợ đào – Bitcoin buộc phải chịu lạm phát. Vì vậy, nó cũng phải có chính sách tiền tệ tương ứng để quyết định tỷ lệ lạm phát và cách tỷ lệ này thay đổi theo thời gian. Satoshi Nakamoto đã đặt giới hạn cứng 21 triệu Bitcoin. Vì số lượng Bitcoin có giới hạn cứng, tỷ lệ lạm phát phải tiến dần về không.
Nếu tỷ lệ lạm phát thực sự bằng không, thì dùng gì để khuyến khích thợ đào tiếp tục vận hành giao thức, đảm bảo an ninh cho Bitcoin? Người ta luôn hy vọng phí giao dịch sẽ bù đắp phần thưởng khối bị mất, dù cơ hội xảy ra điều này khá mong manh. Rõ ràng, nếu phí giao dịch tiến gần về không, giao thức Bitcoin sẽ gặp vấn đề an ninh nghiêm trọng.
Các nhà khoa học máy tính tại Đại học Princeton là Miles Carlston, Harry Kalodner, Matthew Weinberg và Arvind Narayanan đã chỉ ra một khác biệt khác giữa phí giao dịch và phần thưởng khối. Trong khi phần thưởng khối cho mỗi khối là giống nhau (ít nhất là giữa hai lần "chia đôi" liên tiếp của phần thưởng khối), phí giao dịch có thể thay đổi theo cấp độ – điều này lại tạo ra yếu tố bất ổn lý thuyết trò chơi mới cho giao thức. Theo nghĩa này, quyết định vĩ mô về giới hạn cung cố định lại gây ra hậu quả vi mô tiêu cực cho giao thức và người tham gia.
Giống như việc đúc tiền từ phần thưởng khối là lực lượng lạm phát đối với Bitcoin, việc đốt phí giao dịch trong EIP-1559 là lực lượng giảm phát đối với Ethereum. Trong giao thức Ethereum (thực sự sử dụng phần thưởng xác thực lạm phát), một cuộc giằng co giữa hai lực lượng này xảy ra, và thường thì giảm phát chiếm ưu thế. Hiện nay ETH là một loại tiền giảm phát ròng – hậu quả vĩ mô của quyết định thiết kế động lực vi mô trong cơ chế phí giao dịch của giao thức.
Giảm phát tốt hay xấu đối với giao thức Ethereum? Người nắm giữ ETH thích giảm phát, vì dưới các điều kiện khác như nhau, theo thời gian, token của họ sẽ tăng giá trị. (Thực tế, sản phẩm phụ này có thể là yếu tố thúc đẩy dư luận công chúng ủng hộ chuyển sang cơ chế phí giao dịch EIP-1559.) Tuy nhiên, từ "giảm phát" khiến các nhà kinh tế vĩ mô được đào tạo truyền thống e dè, gợi nhớ tình trạng đình trệ kinh tế của Nhật Bản những năm 1990.
Ai đúng? Theo cá nhân tôi, tôi không nghĩ tiền pháp định chủ quyền là phép so sánh phù hợp cho các tiền mã hóa như ETH. Vậy thì, phép so sánh đúng là gì? Đây vẫn là một câu hỏi bỏ ngỏ, cần các nhà nghiên cứu blockchain tiếp tục khám phá: tại sao một loại tiền giảm phát có thể làm chức năng tiền mã hóa hỗ trợ giao thức blockchain, nhưng lại không thể làm chức năng tiền pháp định hỗ trợ quốc gia chủ quyền?
6. Không thể bỏ qua tầng cơ sở
Trong khoa học máy tính, một trong những điều chúng ta theo đuổi là tính mô-đun và trừu tượng sạch, điều này cho phép chúng ta tin tưởng vào một phần hệ thống. Khi thiết kế và phân tích một phần hệ thống, bạn có thể cần biết chức năng đầu ra từ các phần khác của hệ thống. Nhưng lý tưởng nhất, bạn không cần biết chức năng đó được thực hiện底层 như thế nào.
Trong các giao thức blockchain, chúng ta chưa đạt đến trạng thái lý tưởng đó. Dù các nhà xây dựng và nhà thiết kế cơ chế có thể thích tập trung vào tầng ứng dụng, họ không thể phớt lờ cách hoạt động và chi tiết của tầng cơ sở hạ tầng.
Ví dụ, nếu bạn đang thiết kế một nhà tạo lập thị trường tự động, bạn phải tính đến khả năng nhà sản xuất khối không đáng tin cậy chịu trách nhiệm sắp xếp giao dịch. Hoặc, khi bạn cân nhắc thiết kế cơ chế phí giao dịch cho một rollup (L2), bạn không chỉ phải trả phí cho việc tiêu thụ tài nguyên L2, mà còn phải trả tất cả chi phí phát sinh trên giao thức L1 cơ sở (ví dụ như lưu trữ calldata).
Trong cả hai ví dụ, thiết kế cơ chế hiệu quả ở một tầng đòi hỏi hiểu biết chi tiết về các tầng khác. Có lẽ, khi công nghệ blockchain trưởng thành hơn, chúng ta sẽ có sự phân chia rõ ràng giữa các tầng. Nhưng hiện tại, chúng ta chắc chắn chưa đạt đến mức đó.
7. Yêu cầu hoạt động trong môi trường bị giới hạn tính toán
"Máy tính trên trời" được hiện thực hóa bởi các giao thức blockchain là một môi trường bị giới hạn tính toán. Thiết kế cơ chế truyền thống chỉ tập trung vào động lực kinh tế, bỏ qua các vấn đề tính toán (ví dụ, cơ chế Vickrey-Clarke-Groves nổi tiếng là không khả thi với các bài toán phân bổ phức tạp cao).
Khi Nisan và Ronen đề xuất thiết kế cơ chế thuật toán vào năm 1999, họ chỉ ra rằng chúng ta thực sự cần một dạng khả năng truy xuất tính toán nào đó để cơ chế có ý nghĩa thực tế trong thế giới thực. Vì vậy, họ đề nghị giới hạn chú ý vào các cơ chế sử dụng lượng tính toán và truyền thông mở rộng theo hàm đa thức (thay vì hàm mũ) với tham số bài toán.
Do máy ảo giao thức blockchain có khả năng tính toán rất hạn chế, các cơ chế trên chuỗi phải cực kỳ nhẹ – thời gian và truyền thông đa thức là cần thiết nhưng chưa đủ. Ví dụ, yếu tố khan hiếm là lý do chính khiến các nhà tạo lập thị trường tự động chiếm ưu thế tuyệt đối trong DeFi Ethereum, chứ không phải các giải pháp truyền thống hơn như sổ lệnh giá.
8. Vẫn ở giai đoạn sơ khai
Thông thường, khi người ta nói web3 còn ở giai đoạn sơ khai, họ ám chỉ cơ hội đầu tư hoặc mức độ áp dụng. Nhưng xét về mặt khoa học, chúng ta thậm chí còn sớm hơn thế. Điều này chỉ càng làm mọi thứ khó khăn hơn – dù cơ hội là rất lớn.
Lợi ích từ việc làm việc trong một lĩnh vực nghiên cứu trưởng thành bị xem là điều hiển nhiên. Có các mô hình và định nghĩa được chấp nhận rộng rãi. Có sự đồng thuận về các vấn đề quan trọng. Có sự phối hợp then chốt trong việc đo lường tiến triển. Có một từ vựng chung và một kho kiến thức công cộng khổng lồ. Cũng có các con đường tăng tốc như sách giáo khoa đã qua kiểm duyệt nghiêm ngặt, khóa học trực tuyến và các nguồn lực khác.
Ngược lại, trong nhiều khía cạnh của lĩnh vực blockchain, chúng ta vẫn chưa biết mô hình và định nghĩa "đúng" là gì để suy nghĩ rõ ràng và tiến bộ về các vấn đề quan trọng. Ví dụ, trong bối cảnh giao thức blockchain, khái niệm then chốt nào về động lực tương thích là quan trọng nhất? Web3 stack gồm những tầng nào? Các thành phần của giá trị trích xuất tối đa (MEV) là gì? Tất cả đều là những câu hỏi chưa có lời giải.
Đối với những ai quan tâm đến khoa học blockchain, sự non trẻ của lĩnh vực này quả thực là một thách thức. Nhưng tham gia sớm – ngay bây giờ – cũng mang lại cơ hội độc đáo.
Thiết kế cơ chế luôn là công cụ hữu ích cho tầng ứng dụng Internet – ví dụ như đấu giá quảng cáo thời gian thực, hoặc thiết kế thị trường hai bên phổ biến trong hầu hết ứng dụng tiêu dùng trực tuyến ngày nay, từ thương mại điện tử đến mua chung.
Nhưng trong web3, thiết kế cơ chế cũng cung cấp thông tin cho chính các quyết định thiết kế cơ sở hạ tầng.
Hãy nhớ lại những năm 1970-1980, khi các giao thức định tuyến Internet vẫn đang trong giai đoạn thảo luận và thiết kế. Theo tôi biết, không có chuyên gia nào về động lực và thiết kế cơ chế tham gia vào quá trình đó. Nhìn lại, chúng ta nhận ra rằng những người như vậy có thể đã cung cấp thông tin hữu ích cho thiết kế. Trong khi đó, trong web3, ngay từ bản whitepaper Bitcoin ban đầu, động lực đã là một phần trong cuộc thảo luận.
Sự bối rối xung quanh mô hình "đúng", định nghĩa và chỉ số thành công cho web3 thực chất đang nói với chúng ta rằng chúng ta đang ở trong một thời đại vàng son. Những sinh viên và nhà khoa học tương lai sẽ ghen tị với chúng ta, vì chúng ta đang ở đúng thời điểm, đúng địa điểm, có cơ hội định hình quỹ đạo phát triển của công nghệ này. Vì vậy, dù có thể chưa có nhiều sách giáo khoa về lĩnh vực này, nhưng một ngày nào đó sẽ có – và những gì chúng sẽ mô tả chính là những gì chúng ta đang làm hôm nay.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
a16z
