Đối với các token cơ sở hạ tầng – tương ứng với mạng Lớp 1 (hoặc một phần liền kề của ngăn xếp điện toán như Lớp 2) – các mô hình kinh tế được phát triển và hiểu rõ, bắt nguồn từ cung và cầu về không gian khối. Nhưng đối với các token ứng dụng – các giao thức hợp đồng thông minh triển khai các dịch vụ trên các blockchain chuyển tiếp quyền trong "các doanh nghiệp phân tán" – các mô hình kinh tế vẫn đang được giải quyết.

Mô hình kinh doanh của token ứng dụng nên được biểu hiện cũng như phần mềm cơ bản của chúng. Với mục tiêu đó, chúng tôi giới thiệu luồng tiền mặt cho token ứng dụng - một phương pháp cho phép ứng dụng tạo ra các mô hình linh hoạt và người dùng lựa chọn cách họ được thưởng cho giá trị mà họ mang lại. Phương pháp này tạo ra phí từ các hoạt động hợp pháp theo yêu cầu quy định của các khu vực khác nhau, khuyến khích việc tuân thủ lớn hơn. Nó cũng tối đa hóa giá trị tích lũy cho giao thức trong khi khuyến khíchtối thiểu hóa quản trị.

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

Thách thức cho mô hình mã thông báo

Các token cơ sở hạ tầng phụ thuộc vào cung cầu được nhúng: Khi nhu cầu tăng, cung giảm, và thị trường điều chỉnh tương ứng. Nền tảng kinh tế bản địa này cho nhiều token cơ sở hạ tầng đã được tăng tốc bởi Đề xuất Cải thiện Ethereum 1559 (EIP-1559)EIP-1559) đã thực hiện một phí cơ bản để đốt cháy cho tất cả các giao dịch Ethereum. Nhưng mặc dù có những nỗ lực rải rác về mô hình mua và đốt, nhưng không có sự tương đồng nào với EIP-1559 đối với các token ứng dụng.

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

Cũng có một số thách thức pháp lý ở đây: Các mô hình kinh tế mã thông báo cơ sở hạ tầng được cách ly nhiều hơn khỏi rủi ro pháp lý, vì bản 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. Nhưng đối với các mô hình kinh tế mã thông báo ứng dụng, các ứng dụng liên quan có thể phụ thuộc vào việc tạo điều kiện cho hoạt động được quy định và có thể yêu cầu trung gian bởi các chủ sở hữu mã thông báo quản trị – làm cho nền kinh tế phức tạp hơn. Một sàn giao dịch phi tập trung tạo điều kiện thuận lợi cho giao dịch các công cụ phái sinh, một hoạt động được quản lý chặt chẽ ở Hoa Kỳ, hoàn toàn khác với Ethereum.

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

Giải pháp của chúng tôi tập trung vào việc giải quyết ba vấn đề mà token ứng dụng đối mặt liên quan đến:

1. Thách thức với quản trị
2. Thách thức trong việc phân phối giá trị
3. Thách thức với hoạt động được quy định

1. Thách thức về quản trị

Các token ứng dụng thường có quyền quản trị, và sự hiện diện của một Tổ chức Tự trị Phi tập trung (DAO) có thể giới thiệu sự không chắc chắnnhững token cơ sở hạ tầng không phải đối mặt. Đối với DAO có hoạt động đáng kể tại Mỹ, rủi ro có thể phát sinh nếu DAO kiểm soát doanh thu giao thức hoặc trung gian hoạt động kinh tế của giao thức và thực hiện hoạt động đó theo chương trình. Để tránh những rủi ro này, các dự án có thể loại bỏ sự kiểm soát của DAO bằng cách tối thiểu hóa quản trị. Đối với DAO mà điều đó không thể thực hiện, Wyoming's new Decentralized Unincorporated Nonprofit Association (DUNA) cung cấp athực thể pháp lý phi tập trung có thể giúp giảm thiểu các rủi ro này và tuân thủ các luật thuế áp dụng.

2. Những thách thức về phân phối giá trị

Ứng dụng cũng phải cẩn trọng khi thiết kế cơ chế phân phối giá trị cho người nắm giữ mã thông báo. Kết hợp quyền bỏ phiếu và quyền kinh tếcó thể gây ra lo ngại dưới luật chứng khoán Mỹ, đặc biệt là với các cơ chế đơn giản và trực tiếp như phân phối pro rata và mua và đốt token. Các cơ chế này trông giống như cổ tức và mua lại cổ phiếu, và có thể đe dọa lập luận rằng các token xứng đáng với một khung pháp lý quản lý khác biệt so với cổ phần.

Thay vào đó, các dự án nên tìm hiểu hình thức vốn hóa cổ đông — thưởng cho chủ sở hữu token cho những đóng góp vào dự án một 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 việc vận hành một giao diện người dùng (Liquity), tham gia vào giao thức (Goldfinch) và cam kết tài sản đảm bảo như một phần của mô-đun an toàn (Aave. Không gian thiết kế ở đây rất rộng mở, nhưng nơi tốt để bắt đầu là vẽ ra tất cả các bên liên quan trong dự án, xác định những hành vi nên được khuyến khích từ mỗi bên, và quyết định giá trị bao quát mà giao thức có thể tạo ra thông qua sự khuyến khích đó.

Vì sự đơn giản, trong bài viết này chúng tôi sẽ giả định một mô hình đền bù đơn giản để thưởng cho người giữ token tham gia vào quản trị, mặc dù cũng có các kế hoạch khác tồn tại.

3. Thách thức với hoạt động được điều chỉnh

Các ứng dụng giúp quy định hoạt động cũng phải cẩn trọng khi thiết kế cơ chế tích lũy giá trị cho người sở hữu token. Nếu các cơ chế này tích lũy giá trị từ các giao diện trước hoặc API không hoạt động tuân thủ theo luật pháp hiện hành, người sở hữu 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 việc tích lũy giá trị đối với hoạt động được phép tại Hoa Kỳ - ví dụ, chỉ bật các phí giao thức đối với các hồ bơi thanh khoản liên quan đến một số tài sản cụ thể. Điều này khiến cho các dự án phải tuân thủ theo cách tiếp cận quy định chung nhất 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. Điều này cũng trực tiếp làm suy yếu các nỗ lực tối thiểu hóa quản trị. Xác định chiến lược phí nào phù hợp từ quan điểm tuân thủ quy định không phải là nhiệm vụ thích hợp cho DAOs.

Trong một thế giới lý tưởng, các dự án sẽ có thể thu thập phí từ hoạt động ở bất kỳ lãnh thổ nào mà hoạt động đó được phép, mà không phải dựa vào DAO để xác định điều gì là được phép. giải phápMục đích không yêu cầu tuân thủ quy định về tiêu chuẩn giao thức mà đảm bảo rằng phí được tạo ra bởi giao thức chỉ được chuyển tiếp nếu giao diện hoặc API gốc tuân thủ các quy luật và quy định liên quan đến vị trí của giao diện. Nếu Mỹ tuyên bố việc thu phí trên một loại giao dịch cụ thể mà ứng dụng hỗ trợ là bất hợp pháp, điều này có thể làm giá trị kinh tế của token của ứng dụng đó giảm xuống còn 0, ngay cả khi hoạt động này hoàn toàn hợp pháp ở tất cả các quốc gia khác trên thế giới. Sự linh hoạt trong việc tích lũy và phân phối phí cuối cùng tạo nên tính mạnh mẽ trước áp lực của quy định.

Một vấn đề cốt lõi: Theo dõi phí

Sự theo dõi phí là điều quan trọng để giải quyết các rủi ro tiềm ẩn từ các giao diện không tuân thủ mà không đưa ra rủi ro kiểm duyệt hoặc làm cho giao thức được cấp phép. Với sự theo dõi, một ứng dụng có thể đảm bảo rằng bất kỳ khoản phí nào tích luỹ cho người nắm giữ mã thông báo chỉ đến từ các giao diện tuân thủ pháp luật trong khu vực của người nắm giữ mã thông báo. Nếu các khoản phí không thể được theo dõi, sẽ không có cách nào để cách ly người nắm giữ mã thông báo khỏi việc tích lũy giá trị từ các giao diện không tuân thủ (tức là các khoản phí thu thập bởi các giao diện không tuân thủ), điều này có thể làm lộ nguy cơ cho người nắm giữ mã thông báo.

Để có thể theo dõi phí, một giao thức có thể sử dụng thiết kế hệ thống đặt cọc token ứng dụng theo hai bước.

Bước 1: xác định xem giao diện người dùng nào đã tạo ra các khoản phí, và

Bước 2: định tuyến các khoản phí vào các pool khác nhau dựa trên logic tùy chỉnh.

Ánh xạ giao diện trước

Theo dõi phí yêu cầu một ánh xạ một cửa sổ từ miền đến cặp khóa công khai / riêng tư. Mà không có ánh xạ này, một giao diện người dùng độc hại có thể giả mạo giao dịch và giả vờ chúng được gửi từ một miền trung thực. Mật mã cho phép chúng ta 'đăng ký' giao diện người dùng, ghi lại miền một cách bất biến đến ánh xạ khóa công khai, chứng minh miền thực sự điều khiển khóa công khai đó và ký giao dịch với khóa riêng đó. Điều này cho chúng ta khả năng gán giao dịch, và do đó phí, cho một miền cụ thể.

Phí định tuyến

Một khi nguồn phí được truy vết, giao thức có thể xác định cách phân phối những khoản phí đó một cách sao cho người nắm giữ token không nhận được phí từ các giao dịch bất hợp pháp, nhưng cũng không làm tăng gánh nặng quản trị phi tập trung của DAO. Để minh họa điểm này, hãy nghĩ về các thiết kế có thể có cho việc đặt cược token ứng dụng, 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ả giao diện người dùng.

Trong cấu trúc đơn giản nhất, các khoản phí của mỗi giao diện người dùng có thể được định tuyến đến một mô-đun đặt cược cụ thể cho từng giao diện người dùng. Bằng cách chọn giao diện người dùng để đặt cược, người giữ token sẽ có thể quyết định khoản phí mà họ nhận được và tránh bất kỳ khoản phí nào đặt người giữ token vào tình trạng pháp lý nguy hiểm. Ví dụ, người giữ token có thể chỉ đặt cược vào mô-đun liên kết với một giao diện người dùng đã nhận được tất cả các phê duyệt quy định tại Châu Âu. Mặc dù thiết kế này nghe có vẻ đơn giản, thực tế nó khá phức tạp. Có thể có 50 hồ bơi đặt cược cho 50 giao diện người dùng khác nhau, và sự pha loãng của khoản phí có thể làm tổn thương giá trị token.

Ở phía đối diện của phạm vi, các khoản phí từ mọi giao diện trước có thể được gộp lại với nhau — nhưng điều này vô hiệu hóa tính năng theo dõi khoản phí. Nếu tất cả các khoản phí được gộp lại, không có cách nào phân biệt được khoản phí từ các giao diện trước tuân thủ so với các giao diện không tuân thủ — một quả táo hỏng sẽ làm hỏng cả thùng. Người nắm giữ token sẽ buộc phải lựa chọn giữa không nhận được bất kỳ khoản phí nào hoặc sở hữu trong một pool nơi họ sẽ hưởng lợi từ hoạt động bất hợp pháp của các giao diện trước không tuân thủ trong lãnh thổ của họ — một lựa chọn có thể làm nản lòng nhiều người nắm giữ token hoặc có thể đưa hệ thống trở lại các thiết kế không tối ưu hiện tại, trong đó DAO phải đánh giá xem khoản phí có thể được áp dụng ở đâu.

Giải quyết việc theo dõi phí thông qua việc sắp xếp

Những rắc rối này có thể được giải quyết thông qua việc chăm sóc. Hãy xem xét một ứng dụng giao thức hợp đồng thông minh không cần phép có một khoản phí và một token. Bất kỳ ai cũng có thể tạo ra giao diện người dùng cho ứng dụng và bất kỳ giao diện nào cũng có thể có mô-đun đặt cược riêng của mình. Hãy gọi một giao diện người dùng cho ứng dụng 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ể đối với khu vực tài phán mà nó tọa lạc. Hoạt động ứng dụng có nguồn gốc từ app.xyz tạo ra phí giao thức. App.xyz có mô-đun đặt cọc riêng và chủ sở hữu mã thông báo có thể đặt cọc mã thông báo của họ vào mô-đun đó trực tiếp hoặc cho người quản lý muốn chọn riêng một giỏ 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ẽ kiếm được lợi nhuận dưới dạng phí từ tập hợp các giao diện người dùng mà họ đặt cược. Nếu một frontend tạo ra 100 đô la phí và 100 thực thể mỗi thực thể đặt cọc 1 mã thông báo, thì mỗi thực thể được hưởng 1 đô la. Người phụ trách ban đầu có thể tính phí cho các dịch vụ của họ. Trong tương lai, các chính phủ có thể thực hiện chứng thực onchain về frontend tuân thủ thẩm quyền của họ để giúp bảo vệ người tiêu dùng, với lợi ích phụ trợ là tự động hóa 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ể rẻ hơn để vận hành vì chúng thiếu chi phí quản trị của các giao diện người dùng tuân thủ. Họ cũng có thể đưa ra các mô hình để tái chế phí giao diện người dùng cho các nhà giao dịch để khuyến khích hơn nữa cách giải quyết của họ. Hai yếu tố giảm thiểu rủi ro này. Đầu tiên, hầu hết người dùng thực sự muốn các giao diện người dùng tuân thủ tuân theo luật pháp và quy định địa phương của họ. Điều này đặc biệt áp dụng cho các tổ chức lớn, được quy định. Thứ hai, quản trị có thể đóng một vai trò quan trọng như là phương sách cuối cùng hoặc "quyền phủ quyết" đố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 ứng dụng, ngăn cản hành vi xấu.

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 thông qua giao diện người dùng đã đăng ký sẽ được gửi vào một mô-đun staking tổng quát duy nhất, cho phép giao thức thu về doanh thu từ các giao dịch được khởi tạo bởi bot 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 thi: Đưa phương pháp vào thực tế

Hãy xem xét chi tiết hơn về ngăn xếp mã thông báo ứng dụng. Để giao thức cho phép việc đặt cược phía trước, nó sẽ cần thiết lập một hợp đồng thông minh danh mục mà các giao diện phía trước cần phải đăng ký.

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

1. Bên giao diện người dùng có thể gọi hàm register() và chứng minh rằng nó sở hữu tên miền của mình. Một ánh xạ giữa tên miền và khóa công khai của chứng chỉ, và ngược lại, được lưu trữ.
2. Khi giao dịch được tạo thông qua máy khách, nó cũng ký payload giao dịch bằng khóa công khai chứng chỉ của nó. Những thông tin này được chuyển đến hợp đồng thông minh của ứng dụng dưới dạng một gói.
3. Các hợp đồng thông minh của ứng dụng xác thực chứng chỉ, kiểm tra xem nó có tương ứng với nội dung tx phù hợp hay không và đã được đăng ký. Nếu có, giao dịch sẽ được xử lý. Các khoản phí được tạo ra bởi giao dịch sau đó được gửi đến hợp đồng FeeCollector cùng với tên miền (từ cơ quan đăng ký).
4. FeeCollector cho phép các người quản lý, người dùng, người xác minh và những người khác đặt cọc token trực tiếp vào một tên miền hoặc một tập hợp các tên 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 trăm của địa chỉ đó trong số tiền đặt cược đó và thời gian đã đặt cược. Các triển khai phổ biến của khai thác thanh khoản có thể được sử dụng như một điểm bắt đầu cho logic hợp đồng này.
5. Người dùng đã gửi tiền gửi đến người quản lý (hoặc trực tiếp đến các hợp đồng Quản lý Phí) sau đó có thể rút ra số lượng phí tương ứng theo số lượng token ứng dụng đã gửi tiền gửi đến miền. Kiến trúc có thể tương tự như MetaMorpho/Morpho Blue.

Điều này có thể được giới thiệu mà không tăng gánh nặng quản trị của DAO của ứng dụng. Trên thực tế, trách nhiệm quản trị có thể được giảm bớt khi công tắc phí có thể được bật mặc định cho tất cả giao dịch được hỗ trợ bởi giao thức, do đó loại bỏ bất kỳ kiểm soát nào của DAO đối với mô hình kinh tế của giao thức.

Các yếu tố bổ sung dựa trên loại ứng dụng

Mặc dù những nguyên tắc này áp dụng rộng rãi đối với các mô hình kinh tế mã thông báo ứng dụng, nhưng có thể có các yếu tố phí khác dựa trên loại ứng dụng: ứng dụng được xây dựng trên Layer 1 hoặc Layer 2, app-chains và ứng dụng được xây dựng bằng cách sử dụng rollups.

Các yếu tố cần xem xét cho ứng dụng L1/ L2

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

Thay vì phụ thuộc vào các người điều hành để lọc các khoản phí giao diện người dùng, các ứng dụng cũng có thể áp dụng cách tiếp cận danh sách trắng hoặc danh sách đen đối với các giao diện người dùng đóng góp cho các khoản phí mạng. Mục đích ở đây cũng sẽ là đảm bảo rằng người nắm giữ token và giao thức tổng thể không thu lợi hoặc hưởng lợi từ hoạt động trái pháp luật và tuân thủ các quy định pháp lý cụ thể của từng quốc gia.

Trong phương pháp danh sách trắng, ứng dụng sẽ xuất bản một bộ quy tắc cho các giao diện, tạo một đăng ký của những giao diện đó tuân theo các quy tắc, phát hành chứng chỉ cho các giao diện tham gia, và yêu cầu các giao diện đặt cược token để nhận một phần của khoản phí ứng dụng. Nếu các giao diện không tuân theo các quy tắc này, họ sẽ bị cắt giảm, và chứng chỉ của họ về đóng góp phí sẽ bị gỡ bỏ.

Trong phương pháp danh sách đen, các ứng dụng sẽ không cần tạo bất kỳ quy tắc nào, nhưng việc khởi chạy giao diện người dùng cho ứng dụng sẽ không được tự do. Thay vào đó, ứng dụng sẽ yêu cầu bất kỳ giao diện người dùng nào cần cung cấp ý kiến ​​của một công ty luật rằng giao diện người dùng đó tuân thủ pháp luật của lãnh thổ trước khi cho phép giao diện người dùng đó sử dụng ứng dụng. Sau khi nhận được ý kiến, ứng dụng sẽ phát hành một chứng chỉ cho giao diện người dùng để đóng góp phí chỉ được gỡ bỏ nếu ứng dụng nhận được thông báo từ cơ quan quản lý rằng giao diện người dùng không tuân thủ.

Ống phí sẽ phản ánh những ví dụ được cung cấp trong các phần trước đó.

Cả hai phương pháp này đều tăng đáng kể gánh nặng của quản trị phi tập trung, đòi hỏi DAO phải thiết lập và duy trì một bộ quy tắc hoặc đánh giá ý 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, việc giao gánh nặng tuân thủ này cho một người quản trị viên sẽ được ưu tiên hơn.

Các yếu tố cần xem xét cho appchains

Appchains là các chuỗi khối cụ thể cho ứng dụng với các người xác minh chỉ hoạt động cho ứng dụng đó.

Trong quá trình làm việc, những người xác minh này nhận được tiền thù lao. Không giống như các blockchain Layer 1 nơi mà những người xác minh thường được thưởng thông qua việc phát hành token dư thừa, một số appchains (dYdX) thay vào đó chuyển tiền phí của khách hàng cho người xác minh.

Trong mô hình này, người giữ token phải đặt cược cho các máy chủ để nhận phần thưởng. Các máy chủ trở thành các mô-đun đặt cược được curation.

Bộ cài đặt công việc này khác biệt so với một nhà xác nhận Layer 1. Các nhà xác nhận Appchain giải quyết giao dịch cụ thể từ một ứng dụng cụ thể. Do sự khác biệt này, các nhà xác nhận Appchain có thể chịu mức độ rủi ro pháp lý lớn hơn đối với hoạt động cơ bản mà họ đang hỗ trợ. Do đó, các giao thức nên cấp quyền cho nhà xác nhận tự do thực hiện công việc mà họ có thể thực hiện theo luật pháp của lãnh thổ của họ và mức độ thoải mái của họ. Quan trọng hơn, điều này có thể được thực hiện mà không đe dọa tính không cần phép của Appchain hoặc đưa ra rủi ro kiểm duyệt đáng kể miễn là bộ xác nhận của nó phân tán địa lý.

Kiến trúc cho các appchain muốn tận dụng lợi ích của tính minh bạch phí sẽ tương tự như các ứng dụng Layer 1 cho đến đường ống phí. Tuy nhiên, các nhà xác minh sẽ có thể sử dụng bản đồ front-end để xác định các front-end mà họ muốn xử lý các giao dịch. Phí cho bất kỳ giao dịch cụ thể nào sẽ được chuyển đến bộ xác minh hoạt động, với các nhà xác minh không hoạt động không tham gia vào các khoản phí như vậy. Từ quan điểm phí, nhà xác minh thực hiện chức năng tương tự như các nhà quản lý mô-đun đặt cược được thảo luận ở trên và staker cho các nhà xác minh đó có thể đảm bảo rằng họ không nhận được doanh thu từ bất kỳ hoạt động bất hợp pháp nào. Các nhà xác minh cũng có thể bầu một nhà quản lý để xác định các front-end tuân thủ theo phạm vi hành chính.

Các yếu tố cần xem xét cho ứng dụng rollups

Rollups có blockspace riêng nhưng có thể kế thừa tính bảo mật của một chuỗi khác. Hầu hết các rollup ngày nay có một trình tự duy nhất chịu trách nhiệm giải trình tự và bao gồm các giao dịch, mặc dù các giao dịch có thể được gửi trực tiếp đến Lớp 1 thông qua một quy trình gọi là "bắt buộc bao gồm.”

Nếu các bản tổng hợp này dành riêng cho ứng dụng và coi trình tự của chúng là trình xác thực duy nhất, phí được tạo ra từ các giao dịch được bao gồm bởi trình sắp xếp đó có thể được phân tán cho các nhà đặt cọc dựa trên 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 rollups phân cấp bộ sequencer của họ, các sequencer sẽ trở thành các mô-đun staking được lựa chọn mặc định và đường ống phí sẽ phản ánh điều đó của appchains. Các sequencer thay thế các nhà xác minh cho phân phối phí, và mỗi sequencer có thể tự quyết định chấp nhận phí từ các giao diện người dùng nào.

Trong khi có nhiều mô hình khả dụng cho token ứng dụng, việc cung cấp các hồ bơi staking được chọn lọc là một con đường tiến lên mà giúp giải quyết những thách thức đặc biệt của ứng dụng. Bằng cách nhận ra những thách thức cố hữu và thách thức bên ngoài đối mặt với ứng dụng, nhà sáng lập có thể thiết kế mô hình token ứng dụng tốt hơn từ đầu cho dự án của họ.

Miễn trừ trách nhiệm:

1. Bài viết này được tái bản từ [ a16zcrypto]. All copyrights belong to the original author [Mason HallPorter SmithMiles Jennings and Ross Shuel]. Nếu có bất kỳ khiếu nại nào về việc tái bản này, vui lòng liên hệ Gate Learnđội ngũ, và họ sẽ xử lý nhanh chóng.
2. Miễn trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi có đề cập, sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.