a16z: Token giao thức tạo ra dòng tiền như thế nào?

Tác giả gốc: a16z Crypto

Biên soạn gốc: Pzai, Tin tức tầm nhìn xa

Đối với mã thông báo cơ sở hạ tầng—tương ứng với Lớp 1 của mạng (hoặc các phần liền kề của ngăn xếp máy tính, chẳng hạn như Lớp 2)—mô hình kinh tế đã được phát triển và hiểu rõ, đồng thời bắt nguồn từ cung và cầu của không gian khối. Nhưng đối với mã thông báo giao thức (Mã thông báo ứng dụng)—các giao thức hợp đồng thông minh triển khai các dịch vụ trên chuỗi khối và kế thừa các quyền trong “kinh doanh phân tán”—việc xây dựng các mô hình kinh tế vẫn đang được khám phá.

Mô hình kinh doanh của mã thông báo giao thức phải mang tính biểu cảm như phần mềm cơ bản của nó. Để thực hiện điều này, chúng tôi đã giới thiệu dòng tiền của mã thông báo giao thức - một cách tiếp cận cho phép các giao thức tạo ra các mô hình lỏng lẻo, linh hoạt trong đó người dùng có thể chọn cách nhận thưởng dựa trên giá trị mà chúng cung cấp. Cách tiếp cận này tạo ra phí từ các hoạt động tuân thủ dựa trên các yêu cầu pháp lý ở các khu vực pháp lý khác nhau, do đó khuyến khích sự tuân thủ cao hơn. Nó cũng tối đa hóa giá trị do giao thức tạo ra đồng thời khuyến khích quản trị ở mức tối thiểu.

Các nguyên tắc chúng tôi chia sẻ ở đây áp dụng cho tất cả các giao thức Web3—từ DeFi đến mạng xã hội phi tập trung, mạng DePIN và mọi nơi ở giữa.

Những thách thức đối với mô hình token

Mã thông báo cơ sở hạ tầng phụ thuộc vào cung và cầu nội tại: khi nhu cầu tăng, nguồn cung giảm và thị trường sẽ điều chỉnh tương ứng. EIP-1559 tăng tốc nền tảng kinh tế gốc của nhiều mã thông báo cơ sở hạ tầng, với đề xuất thực hiện đốt phí cơ bản cho tất cả các giao dịch Ethereum. Tuy nhiên, bất chấp những nỗ lực lẻ tẻ trong việc mua và đốt các mô hình, vẫn chưa có nỗ lực nào có thể so sánh được với EIP-1559 đối với mã thông báo giao thức.

Các giao thức là người sử dụng không gian khối chứ không phải nhà cung cấp, vì vậy họ không thể dựa vào phí gas từ những người khác sử dụng không gian khối của họ. Đó là lý do tại sao họ cần phát triển mô hình kinh tế của riêng mình.

Ngoài ra còn có một số thách thức pháp lý ở đây: do tính chất chung của các giao dịch blockchain điển hình và các cơ chế lập trình mà chúng sử dụng, các mô hình kinh tế mã thông báo cơ sở hạ tầng sẽ miễn nhiễm hơn với các rủi ro pháp lý. Nhưng đối với các mô hình kinh tế mã thông báo giao thức, các giao thức liên quan có thể phụ thuộc vào việc thúc đẩy các hoạt động tuân thủ và có thể yêu cầu sự can thiệp của chủ sở hữu mã thông báo quản trị, khiến tính kinh tế của nó trở nên phức tạp hơn. Sàn giao dịch phi tập trung tạo điều kiện thuận lợi cho giao dịch phái sinh là một hoạt động được quản lý chặt chẽ ở Hoa Kỳ, rất khác với Ethereum.

Sự kết hợp của những thách thức bên trong và bên ngoài này có nghĩa là các token giao thức yêu cầu các mô hình kinh tế khác nhau. Với ý nghĩ này, chúng tôi đề xuất một giải pháp khả thi: một cách tiếp cận để thiết kế các giao thức nhằm tối đa hóa doanh thu giao thức, khuyến khích tuân thủ quy định và kết hợp việc giảm thiểu quản trị trong khi mang lại lợi ích cho chủ sở hữu mã thông báo giao thức được cung cấp cho các dịch vụ. Mục tiêu của chúng tôi rất đơn giản: cung cấp mã thông báo giao thức có cùng nền tảng kinh tế thông qua dòng tiền mà nhiều mã thông báo cơ sở hạ tầng đã có.

Giải pháp của chúng tôi tập trung vào giải quyết ba vấn đề mà mã thông báo giao thức phải đối mặt liên quan đến: thách thức quản trị, thách thức phân phối giá trị và thách thức hoạt động tuân thủ.

Thách thức quản trị

Mã thông báo giao thức thường có quyền quản trị và sự tồn tại của một tổ chức tự trị phi tập trung (DAO) có thể tạo ra những điều không chắc chắn mà mã thông báo cơ sở hạ tầng không gặp phải. Đối với các DAO có hoạt động quan trọng ở Hoa Kỳ, rủi ro có thể phát sinh nếu DAO kiểm soát doanh thu giao thức hoặc can thiệp vào các hoạt động kinh tế của giao thức và khiến các hoạt động đó mang tính thủ tục. Để tránh những rủi ro này, các dự án có thể loại bỏ quyền kiểm soát DAO bằng cách giảm thiểu việc quản trị. Đối với các DAO không thể thực hiện điều này, Hiệp hội phi lợi nhuận chưa hợp nhất phi tập trung (DUNA) mới của Wyoming cung cấp một thực thể pháp lý phi tập trung có thể giúp giảm thiểu những rủi ro này và tuân thủ luật thuế hiện hành.

Thách thức của việc phân phối giá trị

Các giao thức cũng phải thận trọng khi thiết kế cơ chế phân bổ giá trị cho chủ sở hữu token. Việc kết hợp quyền biểu quyết với quyền kinh tế có thể gây lo ngại theo luật chứng khoán của Hoa Kỳ, đặc biệt đối với các cơ chế đơn giản và dễ hiểu như chia tỷ lệ và mua và tiêu hủy mã thông báo. Các cơ chế này trông tương tự như cổ tức và mua lại cổ phần, đồng thời có thể làm suy yếu các lập luận rằng token phải nhận được khung pháp lý khác với cổ phiếu.

Thay vào đó, các dự án nên khám phá chủ nghĩa tư bản của các bên liên quan—thưởng cho những người nắm giữ mã thông báo vì những đóng góp của họ cho dự án theo cách có lợi cho dự án. Nhiều dự án khuyến khích sự tham gia có tổng giá trị dương, bao gồm các hoạt động đầu cuối (Liquity), tham gia vào các giao thức (Goldfinch) và cầm cố tài sản thế chấp như một phần của mô-đun bảo mật (Aave). Không gian thiết kế ở đây rất mở, nhưng điểm khởi đầu tốt là vạch ra tất cả các bên liên quan trong dự án, xác định hành vi nào của mỗi người trong số họ nên được khuyến khích và quyết định giá trị tổng thể mà giao thức có thể tạo ra thông qua khuyến khích này.

Để đơn giản, trong bài viết này, chúng tôi sẽ giả định một mô hình bồi thường đơn giản nhằm thưởng cho những người nắm giữ mã thông báo khi tham gia quản trị ngay cả khi có các chương trình khác tồn tại.

Những thách thức về hoạt động tuân thủ

Các giao thức hỗ trợ các hoạt động tuân thủ cũng phải thận trọng khi thiết kế cơ chế tích lũy giá trị cho chủ sở hữu token. Nếu các cơ chế như vậy tạo ra giá trị từ giao diện người dùng hoặc API không hoạt động tuân thủ luật hiện hành thì chủ sở hữu mã thông báo có thể thu lợi từ hoạt động bất hợp pháp.

Hầu hết các giải pháp được đề xuất cho vấn đề này đều tập trung vào việc hạn chế tích lũy giá trị từ các hoạt động được phép ở Hoa Kỳ - ví dụ: chỉ tính phí giao thức cho các nhóm thanh khoản liên quan đến một số tài sản nhất định. Điều này hướng tới mẫu số chung thấp nhất của các phương pháp tiếp cận quy định và làm suy yếu đề xuất giá trị của các giao thức phần mềm tự trị toàn cầu. Nó cũng trực tiếp làm suy yếu các nỗ lực giảm thiểu quản trị. Từ góc độ tuân thủ quy định, việc xác định chiến lược tính phí nào hiệu quả không phải là nhiệm vụ phù hợp đối với DAO.

Trong một thế giới lý tưởng, các dự án sẽ có thể thu phí từ hoạt động ở bất kỳ khu vực pháp lý nào cho phép hoạt động đó mà không cần phải dựa vào DAO để xác định những gì được phép. Thay vì yêu cầu tuân thủ ở cấp độ giao thức, giải pháp là đảm bảo rằng các khoản phí phát sinh từ giao thức chỉ được chuyển nếu giao diện người dùng hoặc API tạo ra khoản phí tuân thủ luật và quy định hiện hành tại vị trí của giao diện người dùng. Nếu Hoa Kỳ quy định việc tính phí đối với một số loại giao dịch được hỗ trợ bởi một giao thức là bất hợp pháp, thì điều này có thể làm giảm giá trị kinh tế của các token của giao thức đó xuống 0, mặc dù hoạt động đó hoàn toàn được cho phép ở mọi quốc gia khác trên thế giới. Tính linh hoạt trong việc tích lũy và phân bổ phí cuối cùng tương đương với khả năng phục hồi trước áp lực pháp lý.

Vấn đề cốt lõi: truy xuất nguồn gốc chi phí

Việc truy xuất nguồn gốc các khoản phí là rất quan trọng để giải quyết các rủi ro tiềm ẩn phát sinh từ việc không tuân thủ ở mặt trước mà không gây ra rủi ro khi xem xét hoặc khiến giao thức không thể được cấp phép. Thông qua khả năng truy xuất nguồn gốc, giao thức đảm bảo rằng mọi khoản phí mà chủ sở hữu mã thông báo phải chịu chỉ bắt nguồn từ giao diện người dùng hợp pháp và tuân thủ trong khu vực pháp lý nơi chủ sở hữu mã thông báo sinh sống. Nếu các khoản phí không thể theo dõi được, chủ sở hữu mã thông báo không thể tạo ra giá trị từ các giao diện người dùng không tuân thủ (tức là phí được tính bởi các giao diện người dùng không tuân thủ), điều này có thể khiến chủ sở hữu mã thông báo gặp rủi ro.

Để có thể theo dõi phí, các giao thức có thể được thiết kế bằng hệ thống đặt cược mã thông báo giao thức hai bước.

• Bước 1: Xác định giao diện người dùng nào tạo ra chi phí

• Bước 2: Định tuyến phí đến các nhóm khác nhau dựa trên logic tùy chỉnh

Giao diện bản đồ

Khả năng truy xuất nguồn gốc phí yêu cầu ánh xạ một-một từ tên miền đến cặp khóa công khai/riêng tư. Nếu không có ánh xạ này, giao diện người dùng độc hại có thể giả mạo các giao dịch và giả vờ như chúng được gửi từ một miền trung thực. Mật mã học cho phép chúng tôi "đăng ký" giao diện người dùng, ghi lại ánh xạ của miền tới khóa chung một cách bất biến, chứng minh rằng miền thực sự kiểm soát khóa chung đó và sử dụng khóa riêng tư nói trên để ký giao dịch. Điều này cho phép chúng tôi phân bổ các giao dịch và do đó tính phí cho một miền nhất định.

chi phí tuyến đường

Sau khi có thể truy nguyên nguồn phí, giao thức có thể xác định cách phân phối các khoản phí này theo cách bảo vệ chủ sở hữu mã thông báo khỏi phí giao dịch bất hợp pháp nhưng không làm tăng gánh nặng quản trị phi tập trung của DAO. Để giúp minh họa điểm này, hãy xem xét phạm vi thiết kế có thể có để đặt cược mã thông báo giao thức, từ một nhóm đặt cược cho mỗi giao diện người dùng đến một nhóm đặt cược cho tất cả các giao diện người dùng.

Trong cấu trúc đơn giản nhất, phí của mỗi giao diện người dùng có thể được chuyển đến một mô-đun đặt cược dành riêng cho giao diện người dùng riêng biệt. Bằng cách chọn giao diện người dùng để đặt cược, chủ sở hữu mã thông báo sẽ có thể quyết định mức phí nào họ sẽ nhận và tránh mọi khoản phí có thể khiến chủ sở hữu mã thông báo gặp rủi ro pháp lý. Ví dụ: chủ sở hữu mã thông báo chỉ có thể đặt cọc các mô-đun liên quan đến giao diện người dùng đã nhận được tất cả các phê duyệt theo quy định ở Châu Âu. Mặc dù thiết kế này nghe có vẻ đơn giản nhưng thực tế nó khá phức tạp. Với 50 giao diện khác nhau có khả năng có 50 nhóm đặt cược, việc giảm phí có thể có tác động bất lợi đến giá trị mã thông báo.

Mặt khác, phí từ mỗi giao diện người dùng có thể được gộp lại với nhau, nhưng điều này làm mất đi mục đích truy xuất nguồn gốc của phí. Nếu tất cả các chi phí được gộp lại với nhau, sẽ không có cách nào để phân biệt giữa chi phí đầu vào tuân thủ và không tuân thủ—một phân chuột có thể làm hỏng cả số tiền. Chủ sở hữu mã thông báo sẽ buộc phải lựa chọn giữa việc không tính bất kỳ khoản phí nào hoặc nắm giữ cổ phần trong một nhóm nơi họ sẽ được hưởng lợi từ hoạt động bất hợp pháp của các giao diện không tuân thủ trong phạm vi quyền hạn của họ - một tùy chọn có thể ngăn cản Nhiều chủ sở hữu mã thông báo tham gia hoặc có thể hoàn nguyên hệ thống theo thiết kế chưa tối ưu hiện tại, trong đó DAO phải đánh giá nơi có thể thu phí.

Giải quyết các vấn đề truy xuất nguồn gốc chi phí thông qua giám tuyển

Những sự phức tạp này có thể được giải quyết thông qua việc giám tuyển. Hãy xem xét một giao thức hợp đồng thông minh không được phép có phí và mã thông báo. Bất kỳ ai cũng có thể tạo giao diện người dùng cho giao thức và bất kỳ giao diện người dùng nào cũng có thể có mô-đun đặt cược riêng. Chúng tôi gọi giao diện người dùng là app.xyz.

App.xyz có thể tuân thủ các quy tắc tuân thủ cụ thể tại khu vực pháp lý mà nó hoạt động. Hoạt động giao thức bắt nguồn từ app.xyz phải chịu phí giao thức. App.xyz có mô-đun đặt cược riêng mà chủ sở hữu mã thông báo có thể đặt cược trực tiếp mã thông báo của họ hoặc đặt mã thông báo cho những người quản lý muốn chọn riêng một nhóm giao diện người dùng mà họ cho là tuân thủ. Những người đặt cược mã thông báo này sẽ nhận được doanh thu dưới dạng phí từ bộ giao diện người dùng mà họ đặt cược. Nếu giao diện người dùng tạo ra 100 đô la phí và 100 thực thể đặt cược mỗi mã thông báo 1, thì mỗi thực thể sẽ được hưởng 1 đô la. Ban đầu, người quản lý có thể tính phí cho dịch vụ của họ. Trong tương lai, các chính phủ có thể tiến hành chứng thực trực tuyến để chứng minh sự tuân thủ từ đầu đến cuối trong phạm vi quyền hạn của họ nhằm giúp bảo vệ người tiêu dùng, với lợi ích phụ là tự động hóa việc quản lý.

Một rủi ro tiềm ẩn trong mô hình này là các giao diện người dùng không tuân thủ có thể có chi phí vận hành thấp hơn do chúng thiếu chi phí quản lý so với các giao diện người dùng tuân thủ. Họ cũng có thể thiết kế các mô hình thu lại phí ban đầu cho các nhà giao dịch để khuyến khích hơn nữa các giải pháp của họ. Hai yếu tố làm giảm nguy cơ này. Đầu tiên, hầu hết người dùng thực sự muốn có một giao diện người dùng tuân thủ luật pháp và quy định của địa phương và điều này đặc biệt áp dụng cho các tổ chức lớn được quản lý. Thứ hai, đối với các giao diện người dùng không tuân thủ, liên tục vi phạm các quy tắc và gây nguy hiểm cho khả năng tồn tại của giao thức, quản trị có thể đóng một vai trò quan trọng như là biện pháp cuối cùng hoặc "quyền phủ quyết" để ngăn chặn hành vi xấu.

Cuối cùng, tất cả phí giao dịch không được thực hiện thông qua giao diện người dùng đã đăng ký sẽ được gửi vào mô-đun đặt cược toàn diện, cho phép giao thức tạo doanh thu từ các giao dịch do bot thực hiện và các tương tác trực tiếp khác với hợp đồng thông minh của giao thức.

Từ lý thuyết đến thực hành: áp dụng phương pháp vào thực tế

Hãy quay lại ngăn xếp mã thông báo giao thức một cách chi tiết hơn. Để một giao thức tạo điều kiện thuận lợi cho việc đặt cược giao diện người dùng, nó yêu cầu thiết lập một hợp đồng thông minh đăng ký mà giao diện người dùng cần đăng ký.

• Mỗi giao diện người dùng hoặc API có thể thêm bản ghi TXT đặc biệt vào bản ghi DNS của miền của nó, chẳng hạn như tích hợp DNS ENS. Bản ghi TXT này chứa khóa chung của cặp khóa được tạo một lần bởi giao diện người dùng, được gọi là chứng chỉ.

• Sau đó, máy khách ngoại vi có thể gọi hàm đăng ký và chứng minh rằng nó sở hữu tên miền của mình, lưu trữ ánh xạ khóa công khai từ miền đến chứng chỉ và ngược lại.

• Khi một giao dịch được tạo thông qua máy khách, nó cũng ký tải trọng giao dịch bằng khóa chung chứng chỉ của nó. Chúng được chuyển đến các hợp đồng thông minh của giao thức dưới dạng gói.

• Hợp đồng thông minh của giao thức xác minh chứng chỉ, kiểm tra xem nó có tương ứng với giao dịch gốc (giao diện người dùng) chính xác hay không và đã được đăng ký. Nếu vậy, hãy xử lý giao dịch. Sau đó, phí do giao dịch tạo ra sẽ được gửi đến hợp đồng FeeCollector cùng với tên miền (từ cơ quan đăng ký).

• Hợp đồng FeeCollector cho phép người quản lý, người dùng, người xác thực và những người khác đặt cược mã thông báo trực tiếp vào một miền hoặc tập hợp các miền. Các hợp đồng này phải theo dõi số lượng token được đặt cược trên mỗi tên miền, phần chia sẻ của mỗi địa chỉ trong số cổ phần đó và thời gian chúng được đặt cược. Việc triển khai chung khai thác thanh khoản có thể đóng vai trò là điểm khởi đầu cho logic hợp đồng này.

• Người dùng đặt cọc cho Người quản lý (hoặc trực tiếp vào chính hợp đồng quản lý phí) có thể rút một phần phí theo tỷ lệ dựa trên số lượng mã thông báo giao thức được đặt vào miền. Kiến trúc có thể tương tự như MetaMorpho/Morpho Blue.

Cơ chế này có thể được giới thiệu mà không làm tăng gánh nặng quản trị của giao thức DAO. Trên thực tế, trách nhiệm quản trị có thể được giảm bớt vì chúng tôi có thể bật vĩnh viễn công tắc phí cho tất cả các giao dịch được giao thức hỗ trợ, từ đó loại bỏ mọi quyền kiểm soát mà DAO có đối với mô hình kinh tế của giao thức.

Những cân nhắc bổ sung dựa trên loại giao thức

Mặc dù các nguyên tắc này áp dụng rộng rãi cho các mô hình kinh tế mã thông báo giao thức, nhưng có thể có những cân nhắc bổ sung về phí tùy thuộc vào loại giao thức: các giao thức được xây dựng trên Lớp 1 hoặc Lớp 2, chuỗi ứng dụng và các giao thức được xây dựng bằng cách sử dụng Tổng hợp.

Những cân nhắc đối với giao thức L1/L2

Các giao thức trên chuỗi khối Lớp 1 hoặc Lớp 2 triển khai các hợp đồng thông minh trực tiếp trên chuỗi. Phí được tính khi người dùng tương tác với hợp đồng thông minh của giao thức. Điều này thường xảy ra thông qua giao diện người dùng dễ sử dụng (chẳng hạn như giao thức hoặc trang web) hoạt động như một giao diện giữa các nhà đầu tư bán lẻ và hợp đồng thông minh cơ bản. Trong trường hợp này, mọi khoản phí sẽ đến từ giao diện người dùng đó. Ví dụ trên về app.xyz minh họa cách hệ thống tính phí hoạt động cho các giao thức Lớp 1.

Các giao thức cũng có thể sử dụng danh sách trắng hoặc danh sách đen để lọc phí giao diện người dùng, thay vì dựa vào người quản lý để lọc phí giao diện người dùng. Một lần nữa, mục đích ở đây là để đảm bảo rằng chủ sở hữu mã thông báo và toàn bộ giao thức không thu lợi hoặc hưởng lợi từ các hoạt động bất hợp pháp và tuân thủ luật pháp và quy định của khu vực tài phán cụ thể. Theo cách tiếp cận danh sách trắng, giao thức sẽ xuất bản một bộ quy tắc cho giao diện người dùng, tạo sổ đăng ký cho các giao diện người dùng tuân theo quy tắc, cấp chứng chỉ cho các giao diện người dùng chọn tham gia và yêu cầu giao diện người dùng đặt cược mã thông báo để nhận một phần phí giao thức . Nếu giao diện người dùng không tuân thủ các quy tắc này, chúng sẽ bị cắt và chứng nhận đóng phí của họ sẽ bị xóa.

Theo cách tiếp cận danh sách đen, giao thức không phải tạo bất kỳ quy tắc nào, nhưng giao diện người dùng khởi chạy giao thức sẽ không bị loại bỏ. Thay vào đó, thỏa thuận sẽ yêu cầu bất kỳ giao diện người dùng nào đưa ra ý kiến của công ty luật xác nhận rằng giao diện người dùng tuân thủ quyền tài phán của mình trước khi cho phép giao diện người dùng sử dụng thỏa thuận. Sau khi nhận được nhận xét, giao thức sẽ cấp chứng chỉ cho giao diện người dùng để thanh toán phí. Chứng chỉ này sẽ chỉ bị xóa nếu giao thức nhận được thông báo từ cơ quan quản lý về việc không tuân thủ giao diện người dùng.

Kênh chi phí sẽ phản ánh các ví dụ được cung cấp trong các phần trước. Cả hai cách tiếp cận đều làm tăng đáng kể gánh nặng quản trị phi tập trung, yêu cầu DAO phải thiết lập và duy trì một bộ quy tắc hoặc đánh giá các ý kiến pháp lý về việc tuân thủ. Trong một số trường hợp, điều này có thể chấp nhận được, nhưng trong hầu hết các trường hợp, tốt nhất là giao trách nhiệm tuân thủ này cho người phụ trách.

Những điều cần lưu ý về chuỗi ứng dụng

Chuỗi ứng dụng là một chuỗi khối dành cho một giao thức cụ thể và trình xác thực của nó chỉ áp dụng cho giao thức đó. Đổi lại công việc của họ, những người xác nhận này sẽ nhận được tiền bồi thường. Không giống như các chuỗi khối Lớp 1, nơi người xác thực thường được thưởng thông qua việc phát hành mã thông báo lạm phát, một số chuỗi ứng dụng (dYdX) chuyển phí khách hàng cho người xác thực.

Trong mô hình này, chủ sở hữu mã thông báo phải đặt cọc cho người xác thực để nhận phần thưởng. Trình xác thực trở thành mô-đun đặt cược được phối hợp. Bộ công việc này khác với bộ xác thực Lớp 1. Trình xác thực chuỗi ứng dụng giải quyết các giao dịch cụ thể từ các giao thức cụ thể. Vì sự khác biệt này, người xác nhận Lisk có thể chịu mức độ rủi ro pháp lý cao hơn trong các hoạt động cơ bản mà họ hỗ trợ. Do đó, các giao thức phải cung cấp cho người xác nhận quyền tự do thực hiện những gì họ có thể theo luật pháp thuộc thẩm quyền của họ và mức độ thoải mái của riêng họ. Điều quan trọng là điều này có thể được thực hiện mà không gây nguy hiểm cho tính chất không cần cấp phép của blockchain hoặc khiến nó gặp rủi ro kiểm duyệt đáng kể, miễn là bộ trình xác thực của nó được phân cấp về mặt địa lý.

Kiến trúc của chuỗi ứng dụng muốn tận dụng khả năng truy xuất nguồn gốc phí sẽ tương tự như các giao thức Lớp 1 cho đến khi có kênh tính phí. Tuy nhiên, người xác thực sẽ có thể sử dụng ánh xạ giao diện người dùng để xác định giao diện người dùng nào họ muốn xử lý giao dịch. Sau đó, phí cho bất kỳ giao dịch cụ thể nào sẽ được chuyển đến nhóm trình xác thực đang hoạt động và những trình xác thực không hoạt động chọn không tham gia sẽ bỏ lỡ các khoản phí đó. Từ góc độ phí, người xác nhận thực hiện chức năng tương tự như người quản lý mô-đun đặt cược được đề cập ở trên và người đặt cược của những người xác thực này có thể đảm bảo rằng họ không nhận được thu nhập từ bất kỳ hoạt động bất hợp pháp nào. Người xác thực cũng có thể bầu người quản lý để xác định giao diện người dùng nào tuân thủ trong từng khu vực pháp lý.

Lưu ý về Bản tổng hợp giao thức

Rollup có không gian khối riêng nhưng có thể kế thừa tính bảo mật của chuỗi khác. Ngày nay, hầu hết các bản tổng hợp đều có một trình sắp xếp thứ tự chịu trách nhiệm sắp xếp và bao gồm các giao dịch, mặc dù các giao dịch có thể được chuyển giao trực tiếp đến Lớp 1 thông qua một quy trình được gọi là "đưa vào bắt buộc".

Nếu các đợt tổng hợp này dành riêng cho giao thức và có trình đặt hàng của chúng là trình xác thực duy nhất, thì phí được tạo bởi các giao dịch có trong trình đặt hàng đó có thể được phân phối cho những người đặt cược dựa trên một tập hợp các giao diện người dùng tuân thủ được quản lý hoặc dưới dạng nhóm chung.

Nếu Rollup phi tập trung hóa bộ trình tự sắp xếp của họ, thì trình sắp xếp trình tự sẽ trở thành mô-đun đặt cược được quản lý trên thực tế và kênh phí sẽ phản ánh kênh doanh thu của Appchain. Người đặt hàng thay thế người xác nhận để phân phối phí và mỗi người đặt hàng có thể tự quyết định giao diện người dùng nào sẽ chấp nhận phí.

Tóm tắt

Mặc dù có nhiều mô hình khả thi cho mã thông báo giao thức, nhóm đặt cược, nếu được quản lý cẩn thận, có thể giúp giải quyết các thách thức bên ngoài dành riêng cho giao thức. Bằng cách nhận ra những thách thức cố hữu và bên ngoài mà các giao thức phải đối mặt, người sáng lập có thể thiết kế tốt hơn mô hình mã thông báo giao thức cho dự án của họ ngay từ đầu.

Lời cảm ơn: Cảm ơn Porter Smith đã khởi động dự án này.