a16z: Làm thế nào để các token ứng dụng xây dựng mô hình tài chính tạo ra dòng tiền?
Tuyển chọn TechFlowTuyển chọn TechFlow
a16z: Làm thế nào để các token ứng dụng xây dựng mô hình tài chính tạo ra dòng tiền?
Mô hình thương mại của token ứng dụng nên có tính biểu đạt như phần mềm nền tảng của nó.
Chuyên sâu báo cáo Web3Tác giả: Mason Hall, Porter Smith, Miles Jennings, Ross Shuel
Biên dịch: TechFlow
Đối với các token cơ sở hạ tầng như mạng Layer1 (hoặc các phần liền kề trong chồng tính toán như Layer2), mô hình kinh tế đã tương đối trưởng thành và dễ hiểu, chủ yếu dựa trên mối quan hệ cung - cầu về không gian khối. Tuy nhiên, đối với các token ứng dụng – các giao thức hợp đồng thông minh triển khai dịch vụ trên blockchain, nơi truyền tải quyền lợi trong “thương mại phân tán” – thì mô hình kinh tế vẫn đang được khám phá.
Mô hình thương mại của token ứng dụng cần linh hoạt như chính phần mềm nền tảng của nó. Vì vậy, chúng tôi đề xuất một mô hình dòng tiền cho token ứng dụng – một phương pháp giúp các ứng dụng tạo ra mô hình kinh tế linh hoạt và mở rộng, đồng thời cho phép người dùng lựa chọn cách họ được thưởng theo giá trị mà họ đóng góp. Phương pháp này khuyến khích tuân thủ pháp lý tốt hơn bằng cách tạo ra doanh thu từ các hoạt động hợp pháp dưới yêu cầu quản lý ở nhiều khu vực pháp lý khác nhau. Đồng thời, nó cũng tối đa hóa giá trị tích lũy cho giao thức và khuyến khích giảm thiểu quản trị.
Các nguyên tắc chúng tôi chia sẻ tại đây áp dụng cho mọi ứng dụng Web3 – từ tài chính phi tập trung (DeFi) đến mạng xã hội phi tập trung, mạng cơ sở hạ tầng vật lý phi tập trung (DePIN), và các lĩnh vực liên quan khác.
Thách thức đối với mô hình token
Token cơ sở hạ tầng chịu ảnh hưởng bởi mối quan hệ nội tại giữa cung và cầu: khi nhu cầu tăng, nguồn cung giảm, thị trường điều chỉnh theo. Cơ sở kinh tế này được củng cố thêm ở nhiều token cơ sở hạ tầng nhờ Đề xuất cải tiến Ethereum 1559 (EIP-1559), thiết lập cơ chế đốt phí cơ bản cho mọi giao dịch Ethereum. Nhưng dù đã có những nỗ lực với mô hình mua vào và đốt, token ứng dụng vẫn chưa có cơ chế nào sánh được với EIP-1559.
Ứng dụng là người dùng không gian khối chứ không phải nhà cung cấp, vì vậy chúng không thể dựa vào việc thu phí gas từ các người dùng khác sử dụng không gian khối của mình. Đó là lý do vì sao chúng cần phát triển mô hình kinh tế riêng.
Ở đây cũng tồn tại thách thức pháp lý: mô hình kinh tế của token cơ sở hạ tầng ít rủi ro pháp lý hơn do bản chất tổng quát của giao dịch blockchain điển hình và cơ chế lập trình mà chúng sử dụng. Trong khi đó, mô hình kinh tế của token ứng dụng có thể liên quan đến các hoạt động được quản lý và đòi hỏi sự can thiệp từ người nắm giữ token quản trị – làm cho mô hình kinh tế trở nên phức tạp hơn. Việc hỗ trợ giao dịch phái sinh trên một sàn giao dịch phi tập trung là một hoạt động bị kiểm soát chặt chẽ tại Hoa Kỳ, điều này khác biệt căn bản so với các dự án như Ethereum.
Sự kết hợp của các thách thức nội tại và bên ngoài này có nghĩa là token ứng dụng cần một mô hình kinh tế khác biệt. Với suy nghĩ đó, chúng tôi đề xuất một giải pháp khả thi: một phương pháp thiết kế giao thức nhằm bồi thường cho người nắm giữ token ứng dụng, đồng thời tối đa hóa doanh thu giao thức, thúc đẩy tuân thủ pháp luật và tích hợp giảm thiểu quản trị. Mục tiêu của chúng tôi rất đơn giản: cung cấp cho token ứng dụng cùng một cơ sở kinh tế thông qua dòng tiền như nhiều token cơ sở hạ tầng.
Giải pháp của chúng tôi tập trung vào ba vấn đề mà token ứng dụng đang đối mặt:
-
Thách thức liên quan đến quản trị
-
Thách thức liên quan đến phân phối giá trị
-
Thách thức liên quan đến các hoạt động bị quản lý
1. Thách thức liên quan đến quản trị
Token ứng dụng thường có quyền biểu quyết, và sự tồn tại của tổ chức tự trị phi tập trung (DAO) có thể dẫn đến sự bất định mà token cơ sở hạ tầng không gặp phải. Đối với DAO có hoạt động đáng kể tại Hoa Kỳ, nếu DAO kiểm soát doanh thu giao thức hoặc trung gian các hoạt động kinh tế và khiến các hoạt động này mang tính chương trình, sẽ tiềm ẩn rủi ro. Để tránh rủi ro này, các dự án có thể loại bỏ quyền kiểm soát của DAO bằng cách giảm thiểu quản trị. Với những DAO không thể làm điều này, hiệp hội phi lợi nhuận phi tập trung (DUNA) kiểu mới của Wyoming có thể cung cấp một thực thể pháp lý phi tập trung, giúp giảm thiểu rủi ro và tuân thủ luật thuế áp dụng.
2. Thách thức liên quan đến phân phối giá trị
Các ứng dụng cũng phải thận trọng khi thiết kế cơ chế phân phối giá trị cho người nắm giữ token. Việc kết hợp quyền biểu quyết và quyền kinh tế có thể gây lo ngại theo luật chứng khoán Hoa Kỳ, đặc biệt với các cơ chế đơn giản trực tiếp như phân phối tỷ lệ hay mua vào và đốt token. Những cơ chế này trông giống cổ tức và mua lại cổ phiếu, có thể làm suy yếu luận điểm rằng token nên được hưởng một khuôn khổ quản lý khác biệt so với cổ phần.
Các dự án nên khám phá chủ nghĩa tư bản vì lợi ích các bên liên quan – thưởng cho người nắm giữ token theo cách có lợi cho dự án. Nhiều dự án khuyến khích sự tham gia tích cực, bao gồm vận hành giao diện (như Liquity), tham gia vào giao thức (như Goldfinch) và cam kết tài sản thế chấp như một phần của mô-đun bảo mật (như Aave). Không gian thiết kế ở đây rất rộng lớn, nhưng một điểm khởi đầu tốt là liệt kê tất cả các bên liên quan trong dự án, xác định hành vi nào cần khuyến khích và quyết định tổng giá trị mà giao thức có thể tạo ra thông qua các động lực này.
Để đơn giản hóa, 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, thưởng cho người nắm giữ token khi tham gia quản trị, mặc dù còn tồn tại các phương án khác.
3. Thách thức liên quan đến các hoạt động bị quản lý
Các ứng dụng hỗ trợ các hoạt động bị quản lý cũng phải cẩn trọng khi thiết kế cơ chế tích lũy giá trị cho người nắm giữ token. Nếu các cơ chế này tích lũy giá trị từ các giao diện hoặc API chưa từng hoạt động theo luật pháp áp dụng, người nắm giữ token có thể thu lợi từ các hoạt động bất hợp pháp.
Hầu hết các giải pháp đề xuất cho vấn đề này tập trung vào việc giới hạn tích lũy giá trị chỉ ở các hoạt động được phép tại Hoa Kỳ – ví dụ, chỉ kích hoạt phí giao thức trong các nhóm thanh khoản liên quan đến tài sản cụ thể. Điều này khiến các dự án bị ràng buộc bởi phương pháp quản lý thấp nhất chung, làm suy yếu giá trị cốt lõi của các giao thức phần mềm tự chủ toàn cầu. Nó cũng trực tiếp làm suy yếu nỗ lực giảm thiểu quản trị. Việc xác định chiến lược phí nào hiệu quả từ góc độ tuân thủ pháp lý không phải là nhiệm vụ thích hợp của DAO.
Trong hoàn cảnh lý tưởng, các dự án nên có thể thu phí từ bất kỳ khu vực pháp lý nào cho phép hoạt động đó, mà không cần phụ thuộc vào DAO để xác định điều gì được cho phép. Giải pháp không phải là yêu cầu tuân thủ ở cấp độ giao thức, mà là đảm bảo phí do giao thức tạo ra chỉ được chuyển tiếp nếu giao diện hoặc API gốc tuân thủ luật pháp và quy định áp dụng. Nếu Hoa Kỳ coi việc thu phí cho một giao dịch do ứng dụng hỗ trợ là bất hợp pháp, ngay cả khi hoạt động đó hoàn toàn hợp pháp ở các quốc gia khác, điều này có thể khiến giá trị kinh tế của token ứng dụng tụt xuống mức bằng không. Tính linh hoạt cuối cùng trong việc tích lũy và phân phối phí đồng nghĩa với sức chống chịu trước áp lực quản lý.
Một vấn đề cốt lõi: Khả năng truy xuất nguồn gốc phí
Khả năng truy xuất nguồn gốc phí là then chốt để giải quyết rủi ro tiềm tàng từ các giao diện không tuân thủ, đồng thời không tạo ra rủi ro kiểm duyệt hay biến giao thức thành dạng có giấy phép. Nhờ truy xuất nguồn gốc, ứng dụng có thể đảm bảo rằng bất kỳ khoản phí nào tích lũy cho người nắm giữ token đều chỉ đến từ các giao diện hợp pháp và tuân thủ trong khu vực pháp lý của người nắm giữ token. Nếu phí không thể truy xuất nguồn gốc, sẽ không thể tách biệt người nắm giữ token khỏi giá trị tích lũy từ các giao diện không tuân thủ (tức là phí do các giao diện không tuân thủ thu thập), điều này có thể khiến người nắm giữ token gặp rủi ro.
Để làm cho phí có thể truy xuất nguồn gốc, giao thức có thể áp dụng thiết kế hệ thống hai bước cho việc đặt cược token ứng dụng:
-
Bước một: Xác định giao diện nguồn phát sinh phí
-
Bước hai: Định tuyến phí đến các nhóm khác nhau theo logic tùy chỉnh
Ánh xạ giao diện
Khả năng truy xuất nguồn gốc phí cần ánh xạ từ tên miền đến cặp khóa công khai/khóa riêng. Thiếu ánh xạ này, các giao diện độc hại có thể giả mạo giao dịch, tuyên bố rằng chúng được gửi từ một tên miền trung thực. Mã hóa cho phép chúng ta "đăng ký" giao diện, ghi vĩnh viễn ánh xạ tên miền tới khóa công khai, chứng minh rằng tên miền đó thực sự kiểm soát khóa công khai và sử dụng khóa riêng để ký các giao dịch. Điều này cho phép chúng ta quy trách nhiệm các giao dịch (và do đó cả phí) cho một tên miền cụ thể.
Định tuyến phí
Khi nguồn gốc phí có thể truy xuất, giao thức có thể quyết định cách phân bổ các khoản phí này nhằm bảo vệ người nắm giữ token khỏi các khoản phí phát sinh từ giao dịch bất hợp pháp, đồng thời không làm tăng gánh nặng quản trị phi tập trung của DAO. Để minh họa, hãy xem xét phạm vi thiết kế đặt cược token ứng dụng, từ mỗi giao diện một nhóm đặt cược đến một nhóm đặt cược duy nhất cho tất cả giao diện.
Trong cấu trúc đơn giản nhất, phí từ mỗi giao diện có thể được định tuyến đến một mô-đun đặt cược riêng biệt dành riêng cho giao diện đó. Bằng cách chọn đặt cược vào những giao diện nào, người nắm giữ token sẽ có thể quyết định họ nhận phí nào và tránh bất kỳ khoản phí nào có thể khiến họ gặp rủi ro pháp lý. Ví dụ, người nắm giữ token có thể chỉ đặt cược vào các mô-đun liên kết với các giao diện đã được phê duyệt đầy đủ về mặt quản lý tại châu Âu. Mặc dù thiết kế này nghe có vẻ đơn giản, nhưng thực tế khá phức tạp. Có thể có 50 nhóm đặt cược tương ứng với 50 giao diện khác nhau, và việc pha loãng phí có thể ảnh hưởng tiêu cực đến giá trị token.
Ở đầu kia của phổ thiết kế, phí từ mỗi giao diện có thể được tổng hợp lại – nhưng điều này đi ngược lại mục đích của khả năng truy xuất nguồn gốc phí. Nếu tất cả phí đều được gộp chung, sẽ không thể phân biệt được phí từ giao diện tuân thủ và không tuân thủ; chỉ cần một "quả táo hỏng" là có thể làm hỏng cả thùng. Người nắm giữ token sẽ buộc phải lựa chọn giữa việc không nhận bất kỳ khoản phí nào hoặc đặt cược vào một nhóm duy nhất, nơi họ sẽ hưởng lợi từ các hoạt động bất hợp pháp của giao diện không tuân thủ trong khu vực pháp lý của họ – lựa chọn này có thể khiến nhiều người nắm giữ token không muốn tham gia, hoặc có thể đưa hệ thống quay lại thiết kế hiện tại kém ưu việt, nơi DAO phải đánh giá nơi nào có thể áp dụng phí.
Giải quyết khả năng truy xuất nguồn gốc phí thông qua tuyển chọn (curated)
Những phức tạp này có thể được giải quyết thông qua tuyển chọn. Hãy tưởng tượng một ứng dụng giao thức hợp đồng thông minh không cần quyền cho phép, có phí và token. Bất kỳ ai cũng có thể tạo giao diện cho ứng dụng này, và mỗi giao diện có thể có mô-đun đặt cược riêng. Chúng tôi gọi một giao diện của giao thức này là App.xyz.
App.xyz có thể tuân theo các quy tắc tuân thủ cụ thể của khu vực pháp lý nơi nó hoạt động. Các hoạt động ứng dụng từ App.xyz sẽ tạo ra phí giao thức. App.xyz có mô-đun đặt cược riêng, nơi người nắm giữ token có thể trực tiếp đặt cược token của họ vào mô-đun đó, hoặc đặt cược cho những người tuyển chọn muốn tự chọn một rổ các giao diện mà họ cho là tuân thủ. Những người đặt cược này sẽ nhận được lợi nhuận dưới dạng phí do các giao diện họ đặt cược tạo ra. Nếu một giao diện tạo ra 100 đô la phí và 100 thực thể mỗi thực thể đặt cược 1 token, thì mỗi thực thể sẽ có quyền nhận 1 đô la. Người tuyển chọn có thể ban đầu thu phí cho dịch vụ của họ. Trong tương lai, chính phủ có thể cấp chứng nhận trên chuỗi về tính tuân thủ của các giao diện trong khu vực pháp lý của họ để giúp bảo vệ người tiêu dùng, đồng thời đạt được lợi ích bổ sung là tự động hóa việc tuyển chọn.
Một rủi ro tiềm tàng trong mô hình này là chi phí vận hành của các giao diện không tuân thủ có thể thấp hơn, vì chúng thiếu chi phí quản lý của các giao diện tuân thủ. Chúng cũng có thể thiết kế mô hình hoàn trả phí giao diện cho các nhà giao dịch, để tiếp tục khuyến khích các biện pháp thay thế. Hai yếu tố có thể làm giảm rủi ro này. Thứ nhất, phần lớn người dùng thực sự muốn các giao diện tuân thủ tuân theo luật pháp địa phương, điều này đặc biệt đúng với các tổ chức lớn bị quản lý. Thứ hai, quản trị có thể đóng vai trò quan trọng như biện pháp cuối cùng hoặc "quyền phủ quyết", nhằm kiềm chế các hành vi xấu từ các giao diện không tuân thủ liên tục vi phạm quy tắc và đe dọa khả năng sống sót của ứng dụng.
Cuối cùng, tất cả các khoản phí từ các giao dịch không được khởi tạo qua giao diện đã đăng ký sẽ được gửi vào một mô-đun đặt cược tổng hợp duy nhất, cho phép giao thức thu nhập từ các bot và các giao dịch khác tương tác trực tiếp với hợp đồng thông minh của giao thức.
Từ lý thuyết đến thực tiễn: Đưa phương pháp vào thực tế
Hãy xem lại chi tiết hơn về ngăn xếp token ứng dụng. Để hỗ trợ việc đặt cược giao diện, giao thức cần thiết lập một hợp đồng thông minh đăng ký, nơi các giao diện cần đăng ký.
-
Mỗi giao diện hoặc API có thể thêm một bản ghi TXT đặc biệt vào bản ghi DNS của tên miền, giống như tích hợp ENS DNS. Bản ghi TXT này chứa khóa công khai từ cặp khóa do giao diện tạo ra, gọi là chứng chỉ.
-
Giao diện khách hàng có thể gọi hàm register() và chứng minh rằng nó sở hữu tên miền đó. Ánh xạ giữa tên miền và khóa công khai chứng chỉ, cùng ánh xạ ngược lại, sẽ được lưu trữ.
-
Khi tạo giao dịch qua khách hàng, nó cũng sẽ ký tải trọng giao dịch bằng khóa công khai chứng chỉ của mình. Những dữ liệu này được đóng gói và truyền đến hợp đồng thông minh của ứng dụng.
-
Hợp đồng thông minh của ứng dụng xác minh chứng chỉ, kiểm tra xem nó có khớp với chủ thể giao dịch đúng hay không và đã được đăng ký hay chưa. Nếu đúng, giao dịch sẽ được xử lý. Phí phát sinh từ giao dịch sau đó được gửi cùng với tên miền (từ bộ đăng ký) đến hợp đồng FeeCollector.
-
FeeCollector cho phép người tuyển chọn, người dùng, trình xác thực và những người khác trực tiếp đặt cược token cho một tên miền cụ thể hoặc một nhóm tên miền. Các hợp đồng này phải theo dõi số lượng token đặt cược trên mỗi tên miền, phần chia của mỗi địa chỉ trong khoản đặt cược đó và thời gian họ đặt cược. Các triển khai đào tạo nổi bật có thể làm điểm khởi đầu cho logic hợp đồng này. Người dùng đã đặt cược cho người tuyển chọn (hoặc người dùng trực tiếp đặt cược cho hợp đồng quản lý phí) có thể rút phần phí tương ứng dựa trên số lượng token ứng dụng đã đặt cược vào tên miền đó. Kiến trúc này có thể tương tự như MetaMorpho/Morpho Blue.
Giải pháp này có thể được triển khai mà không làm tăng gánh nặng quản trị của DAO ứng dụng. Trên thực tế, trách nhiệm quản trị thậm chí có thể giảm bớt, vì công tắc phí có thể được bật vĩnh viễn cho mọi giao dịch mà giao thức hỗ trợ, từ đó loại bỏ mọi quyền kiểm soát của DAO đối với mô hình kinh tế giao thức.
Xem xét bổ sung theo loại ứng dụng
Mặc dù các nguyên tắc này áp dụng rộng rãi cho mô hình kinh tế token ứng dụng, nhưng tùy theo loại ứng dụng (ví dụ: ứng dụng xây dựng trên L1 hoặc L2, chuỗi ứng dụng và ứng dụng sử dụng Rollup), có thể có các cân nhắc phí bổ sung.
Xem xét cho ứng dụng L1/L2
Ứng dụng trên blockchain Layer1 hoặc Layer2 triển khai hợp đồng thông minh trực tiếp trên chuỗi. Khi người dùng tương tác với hợp đồng thông minh của ứng dụng, phí sẽ được thu. Thông thường, sự tương tác này diễn ra thông qua một giao diện thân thiện (như ứng dụng hoặc trang web), đóng vai trò là giao diện giữa người dùng bán lẻ và hợp đồng thông minh nền tảng. Trong trường hợp này, mọi phí đều bắt nguồn từ giao diện đó. Ví dụ trên app.xyz minh họa cách hệ thống phí hoạt động trong ứng dụng Layer1.
Ứng dụng cũng có thể áp dụng phương pháp danh sách trắng hoặc danh sách đen để lọc phí từ giao diện, thay vì dựa vào người tuyển chọn. Mục đích ở đây là đảm bảo rằng người nắm giữ token và toàn bộ giao thức sẽ 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 theo luật pháp và quy định của khu vực pháp lý cụ thể.
Với phương pháp danh sách trắng, ứng dụng sẽ công bố một bộ quy tắc cho giao diện, tạo bảng đăng ký cho các giao diện tuân theo các quy tắc này, cấp chứng chỉ cho các giao diện tham gia tự nguyện và yêu cầu giao diện đặt cược token để nhận một phần phí ứng dụng. Nếu giao diện không tuân theo các quy tắc này, họ sẽ bị loại khỏi tư cách đóng góp phí và chứng chỉ sẽ bị thu hồi.
Với phương pháp danh sách đen, ứng dụng không cần tạo bất kỳ quy tắc nào, nhưng quá trình khởi động giao diện cho ứng dụng sẽ không phải không cần quyền. Thay vào đó, ứng dụng yêu cầu mọi giao diện phải cung cấp ý kiến từ một văn phòng luật sư chứng minh rằng giao diện đó tuân thủ quy định trong khu vực pháp lý của họ. Sau khi nhận được ý kiến, ứng dụng sẽ cấp chứng chỉ đóng góp phí cho giao diện, và chứng chỉ này chỉ bị thu hồi nếu ứng dụng nhận được thông báo từ cơ quan quản lý rằng giao diện không tuân thủ.
Ống dẫn phí sẽ tương tự như ví dụ được cung cấp ở phần trước.
Cả hai phương pháp đều làm tăng đáng kể gánh nặng quản trị phi tập trung, yêu cầu DAO hoặc phải xây dựng và duy trì một bộ quy tắc, hoặc đánh giá các ý kiến pháp lý về tính 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, việc thuê ngoài gánh nặng tuân thủ cho người tuyển chọn sẽ khả thi hơn.
Xem xét cho chuỗi ứng dụng
Chuỗi ứng dụng là blockchain chuyên biệt cho một ứng dụng cụ thể, nơi các trình xác thực chỉ làm việc cho ứng dụng đó.
Đổi lại công việc của họ, các trình xác thực này sẽ được trả thù lao. Khác với blockchain Layer1, nơi các trình xác thực thường được thưởng bằng việc phát hành token lạm phát, một số chuỗi ứng dụng (như dYdX) chuyển phí khách hàng cho các trình xác thực.
Trong mô hình này, người nắm giữ token phải đặt cược cho các trình xác thực để nhận thưởng. Các trình xác thực trở thành các mô-đun đặt cược được tuyển chọn.
Tập công việc này khác với trình xác thực Layer1. Trình xác thực chuỗi ứng dụng xử lý các giao dịch cụ thể từ một ứng dụng cụ thể. Do sự khác biệt này, các trình xác thực chuỗi ứng dụng có thể chịu rủi ro pháp lý lớn hơn, do bản chất của các hoạt động mà họ hỗ trợ. Vì vậy, giao thức nên cho phép các trình xác thực tự do thực hiện công việc của họ theo luật pháp khu vực pháp lý và mức độ thoải mái cá nhân. Quan trọng là, miễn là sự phân bố địa lý của các trình xác thực là phi tập trung, điều này có thể thực hiện mà không làm tổn hại đến tính không cần quyền của chuỗi ứng dụng hoặc khiến nó đối mặt với rủi ro kiểm duyệt nghiêm trọng.
Kiến trúc chuỗi ứng dụng mong muốn tận dụng lợi ích của khả năng truy xuất nguồn gốc phí sẽ giống với ứng dụng Layer1 cho đến ống dẫn phí. Nhưng các trình xác thực sẽ có thể sử dụng ánh xạ giao diện để xác định các giao diện mà họ muốn xử lý. Phí từ mọi giao dịch nhất định sẽ được phân bổ cho tập các trình xác thực đang hoạt động, trong khi các 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í này. Về mặt phí, chức năng của trình xác thực giống như người tuyển chọn mô-đun đặt cược đã thảo luận ở trên, và những người đặt cược cho các trình xác thực này có thể đảm bảo họ sẽ không thu nhập từ bất kỳ hoạt động bất hợp pháp nào. Các trình xác thực cũng có thể chọn người tuyển chọn để xác định giao diện nào là tuân thủ trong khu vực pháp lý tương ứng của họ.
Xem xét cho Rollup ứng dụng
Rollup có không gian khối riêng nhưng có thể kế thừa tính bảo mật từ một chuỗi khác. Hầu hết Rollup ngày nay do một trình sắp xếp đơn lẻ chịu trách nhiệm sắp xếp và bao gồm giao dịch, mặc dù giao dịch có thể được gửi trực tiếp lên Layer1 thông qua quá trình gọi là "buộc bao gồm".
Nếu các Rollup này chuyên biệt theo ứng dụng và coi trình sắp xếp của chúng là trình xác thực duy nhất, thì phí phát sinh từ các giao dịch do trình sắp xếp đó bao gồm có thể được phân bổ cho những người đặt cược theo tập giao diện tuân thủ được tuyển chọn hoặc dưới dạng một nhóm chung.
Nếu Rollup phi tập trung hóa tập các trình sắp xếp, thì các trình sắp xếp sẽ trở thành các mô-đun đặt cược được tuyển chọn trên thực tế, và ống dẫn phí sẽ giống với chuỗi ứng dụng. Trình sắp xếp thay thế trình xác thực trong việc phân bổ phí, mỗi trình sắp xếp có thể quyết định chấp nhận phí từ những giao diện nào.
Mặc dù có nhiều mô hình khả thi cho token ứng dụng, nhưng việc cung cấp các nhóm đặt cược được tuyển chọn là một hướng đi giúp giải quyết các thách thức bên ngoài độc đáo của ứng dụng. Bằng cách nhận thức rõ các thách thức nội tại và bên ngoài mà ứng dụng phải đối mặt, các nhà sáng lập có thể thiết kế mô hình token ứng dụng tốt hơn ngay từ đầu cho dự án của họ.
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
