Đối với token cơ sở hạ tầng (chẳng hạn như L1 hoặc L2), mô hình kinh tế đã được phát triển và hiểu rõ đầy đủ, bắt nguồn từ mối quan hệ cung cầu đối với không gian khối. Nhưng đối với token(giao thức hợp đồng thông minh triển khai dịch vụ trên blockchain), mô hình kinh tế vẫn đang được hoàn thiện .
Mô hình việc kinh doanh của token ứng dụng phải mang tính biểu cảm như phần mềm cơ bản của nó. Để đạt được mục đích này, bài viết này giới thiệu khái niệm dòng tiền của token. Phương pháp này cho phép các ứng dụng 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 thưởng cho giá trị mà họ cung cấp. Phương pháp này khuyến khích sự tuân thủ cao hơn bằng cách phát sinh phí cho các hoạt động hợp pháp tuân theo các yêu cầu pháp lý ở các khu vực pháp lý khác nhau. Hơn nữa, giá trị của giao thức có thể được tối đa hóa đồng thời khuyến khích quản trị tối thiểu.
Các nguyên tắc được chia sẻ trong bài viết nà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 thứ ở giữa.
Những thách thức đối với mô hình token
Token cơ sở hạ tầng phụ thuộc vào cung và cầu vốn có: khi nhu cầu tăng, nguồn cung giảm và thị trường sẽ đ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 nhờ Đề án cải tiến Ethereum 1559 (EIP-1559), Đề án hiện cơ chế đốt cho tất cả các giao dịch Ethereum . Mặc dù có những nỗ lực lẻ tẻ để mua và đốt các mô hình nhưng không có mô hình nào tương tự như EIP-1559 token.
Các ứ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 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ơ chế lập trình mà chúng sử dụng, mô hình kinh tế token cơ sở hạ tầng ít gặp rủi ro pháp lý hơn. Nhưng đối với mô hình kinh tế token , các ứng dụng liên quan có thể dựa vào các hoạt động quản lý và có thể yêu cầu các bên trung gian quản lý người nắm giữ token – khiến nền kinh tế trở nên phức tạp hơn. Ví dụ: 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 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.
Những thách thức bên trong và bên ngoài này có nghĩa là token ứng dụng yêu cầu các mô hình kinh tế khác nhau. Với suy nghĩ này, bài viết này đề xuất một giải pháp khả thi: phương pháp thiết kế các giao thức bù đắp cho người nắm giữ token ứng dụng trong khi tối đa hóa thu nhập giao thức, khích lệ tuân thủ quy định và kết hợp các dịch vụ giảm thiểu quản trị. Mục tiêu rất đơn giản: cung cấp token ứng dụng có cùng nền tảng kinh tế thông qua dòng tiền mà nhiều token cơ sở hạ tầng đã có.
Giải pháp tập trung vào giải quyết ba vấn đề mà token ứng dụng gặp phải:
· Những thách thức về quản trị
· Những thách thức về phân phối giá trị
· Những thách thức về quy định
Thách thức quản trị
Token ứng dụng thường có quyền quản trị và sự tồn tại của DAO có thể mang đến những điều không chắc chắn mà token cơ sở hạ tầng không gặp phải. Đối với các DAO có việc kinh doanh quan trọng ở Hoa Kỳ, rủi ro có thể phát sinh nếu DAO kiểm soát thu nhập giao thức hoặc đóng vai trò trung gian cho các hoạt động kinh tế giao thức và chương trình các hoạt động đó. Để tránh 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 phi tập trung tập trung chưa hợp nhất (DUNA) mới thành lập 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 rủi ro này và tuân thủ luật thuế hiện hành.
Thử thách phân phối giá trị
Các ứng dụng phải thiết kế cẩn thận các 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 của Hoa Kỳ, đặc biệt là với các cơ chế đơn giản và dễ hiểu như chia tỷ lệ và mua vào và đốt token . 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 tuân theo khung pháp lý khác với cổ phiếu.
Các dự án nên khám phá các mô hình của bên liên quan—thưởng cho người nắm giữ token vì những đóng góp của họ theo cách có lợi cho dự án. Nhiều dự án đang khuyến khích sự tham gia tích cực, bao gồm các mặt trận vận hành ( Liquity), tham gia vào các giao thức (Goldfinch) và đặt cọc 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 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 mà mỗi người trong số họ nên được khuyến khích thực hiện và quyết định giá trị tổng thể mà giao thức có thể tạo ra thông qua khích lệ này.
Để đơn giản, bài viết này sẽ giả định một mô hình bồi thường đơn giản nhằm thưởng cho người nắm giữ token khi tham gia quản trị.
thách thức pháp lý
Các ứng dụng hỗ trợ các hoạt động được quản lý cũng phải thận trọng khi thiết kế cơ chế gia tăng giá trị cho người nắm giữ token . Nếu các cơ chế như vậy thu được giá trị từ giao diện người dùng hoặc API không tuân thủ luật hiện hành, 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 được đề xuất cho vấn đề này đều tập trung vào việc hạn chế giá trị gia tăng cho 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 tài sản nhất định. Điều này buộc các dự án phải tuân theo phương pháp theo 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 những nỗ lực nhằm giảm thiểu quản trị. Việc DAO xác định chiến lược tính phí nào hiệu quả từ góc độ tuân thủ quy định là không phù hợp.
Trong một thế giới lý tưởng, các dự án sẽ có thể thu phí ở 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. 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 rằng các khoản phí phát sinh từ giao thức chỉ được chuyển qua nếu giao diện người dùng hoặc API tạo ra các khoản phí đó tuân thủ luật pháp và quy định hiện hành ở khu vực nơi giao diện người dùng được đặt. Nếu Hoa Kỳ cấm tính phí đối với một giao dịch nhất định được hỗ trợ bởi một ứng dụng, điều đó có thể làm giảm giá trị kinh tế của token của ứng dụng xuống 0, ngay cả khi hoạt động đó được cho phép ở các 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: phí hồi tố
Việc truy xuất nguồn gốc các khoản phí là rất quan trọng để giải quyết rủi ro tiềm ẩn phát sinh từ việc không tuân thủ mà không gây ra rủi ro giám sát hoặc cấp phép cho thỏa thuận. Với khả năng truy xuất nguồn gốc, các ứng dụng có thể đảm bảo rằng mọi khoản phí mà người nắm giữ token nhận được chỉ đến từ các giao diện người dùng hợp pháp và tuân thủ trong phạm vi quyền hạn người nắm giữ token . Nếu các khoản phí không thể theo dõi được thì không có cách nào để bảo vệ người nắm giữ token khỏi việc tích lũy giá trị trên giao diện người dùng không tuân thủ, điều này có thể khiến người nắm giữ token gặp rủi ro.
Để có thể theo dõi chi phí, các quy trình có thể được thiết kế theo hai bước:
· Bước 1: Xác định các chi phí phát sinh trước đó
· 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 sang cặp private key. Nếu không có ánh xạ này, giao diện người dùng độc hại có thể ngụy tạo các giao dịch và giả vờ được gửi từ một miền trung thực. Mật mã học cho phép giao diện người dùng "đã đăng ký" ghi lại ánh xạ từ miền đến khóa công khai 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 private key nói trên để ký các 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.
Phí định tuyến
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 để người nắm giữ token không bị tính phí cho các giao dịch bất hợp pháp và 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ều này, chúng tôi có thể xem xét nhiều thiết kế khả thi khác nhau để áp dụng đặt cược token, 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 duy nhất được chia sẻ bởi tất cả các giao diện người dùng.
Trong cấu hình đơn giản nhất, phí từ mỗi giao diện người dùng có thể được chuyển đến một mô-đun -đ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 nào để đặt cược, người nắm giữ token sẽ có thể quyết định mức phí họ tính và tránh mọi khoản phí khiến họ gặp rủi ro pháp lý. Ví dụ: người nắm giữ token chỉ có thể đặt cược vào mô-đun đun liên quan đến giao diện người dùng đã được tất cả các cơ quan quản lý ở Châu Âu phê duyệt. 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ể ảnh hưởng xấu đến giá trị token .
Mặt khác, phí cho 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 thì sẽ không thể phân biệt được giữa chi phí của giao diện người dùng tuân thủ và chi phí của giao diện người dùng không tuân thủ. Người nắm giữ token 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 và nắm giữ cổ phần trong một nhóm nơi họ sẽ được hưởng lợi từ các hoạt động bất hợp pháp của các giao diện người dùng không tuân thủ trong phạm vi quyền hạn của họ — —Tùy chọn này có thể ngăn cản nhiều người nắm giữ token tham gia, hoặc nó có thể hoàn nguyên hệ thống về thiết kế lần ưu hiện tại, tức là DAO cần đánh giá nơi có thể áp dụng phí.
Giải quyết các vấn đề truy xuất nguồn gốc chi phí thông qua quản lý
Những sự phức tạp này có thể được giải quyết thông qua quản lý. Hãy xem xét một ứng dụng giao thức hợp đồng thông minh không được phép có tính phí và token, bất kỳ ai cũng có thể tạo giao diện người dùng cho ứng dụng và bất kỳ giao diện người dùng nào cũng có thể có mô-đun đun đặt cược riêng, một giao diện người dùng cho giao thức này được gọi 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 ứng dụng bắt nguồn từ app.xyz phải chịu phí giao thức. App.xyz có mô-đun đun đặt cược riêng token người nắm giữ mã thông báo có thể đặt token trực tiếp mô-đun thông báo của họ hoặc cho những người quản lý muốn quản lý riêng một nhóm giao diện người dùng mà họ cho rằng tuân thủ. Những người đặt cược token này sẽ nhận được lợi nhuận dưới dạng phí từ nhóm giao diện người dùng mà họ đặt cược. Nếu một giao diện người dùng tạo ra 100 đô la phí và 100 thực thể đặt cược mỗi người 1 token thì mỗi thực thể sẽ được hưởng 1 đô la. Quản trị viên ban đầu có thể tính phí dịch vụ. Trong tương lai, các chính phủ có thể chứng nhận sự tuân thủ giao diện người dùng trên Chuỗi trong khu vực pháp lý của họ để giúp bảo vệ người tiêu dùng, với lợi ích phụ là tự động hóa quản trị.
Một rủi ro tiềm ẩn với 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 vì chúng không có chi phí quản trị như 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. 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 một giao diện tuân thủ tuân thủ luật pháp và quy định của địa phương, đặc biệt là đối với 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 ứng dụng, việc quản trị có thể được sử dụng như biện pháp cuối cùng hoặc sử dụng "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ột mô-đun đun đặt cược toàn diện duy nhất, cho phép giao thức tạo thu nhập 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ế
Đánh giá chi tiết về ngăn xếp token ứng dụng. Để 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 các 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 trạm ngoại vi có thể gọi hàm register() và chứng minh rằng nó sở hữu tên miền. Hệ thống lưu trữ ánh xạ các miền tới khóa công khai chứng chỉ và ngược lại.
Khi một giao dịch được tạo thông qua máy trạm, nó cũng ký tải trọng giao dịch bằng khóa chung chứng chỉ của nó. Những thứ này sẽ được chuyển đến hợp đồng thông minh của ứng dụng dưới dạng một gói.
Hợp đồng thông minh của ứng dụng sẽ xác minh chứng chỉ, kiểm tra xem nó có tương ứng với nguyên tắc tx chính xác hay không và đã được đăng ký. Nếu vậy, giao dịch được xử lý. 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ý).
FeeCollector cho phép người quản lý, người dùng, người xác thực, v.v. đặt token trực tiếp vào một tên miền hoặc tập hợp 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, thị phần đặt cược của từng địa chỉ và thời gian đặt cược. Việc triển khai Khai thác thanh khoản phổ biến có thể được sử dụng làm điểm khởi đầu cho logic hợp đồng này.
Những người dùng đã đặt cọc cho quản trị viên (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 token ứng dụng được cam kết cho miền. Kiến trúc có thể tương tự như MetaMorpho/Morpho Blue.
Việc giới thiệu tính năng này sẽ không làm tăng gánh nặng quản trị của ứng dụng DAO. Trên thực tế, trách nhiệm quản trị có thể được giảm bớt do việc chuyển đổi phí có thể được bật vĩnh viễn cho tất cả các giao dịch được giao thức hỗ trợ, do đó loại bỏ mọi quyền kiểm soát của DAO đố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 ứ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, nhưng có thể xem xét các khoản phí khác tùy thuộc vào loại ứng dụng: ứng dụng được xây dựng trên hoặc ngoài L2, Chuỗi ứng dụng và ứng dụng được xây dựng bằng cách sử dụng rollups .
Ứng dụng L1/L2
Các ứng dụng trên blockchain L1/L2 triển khai các hợp đồng thông minh trực tiếp trên Chuỗi. Phí được thu khi người dùng tương tác với hợp đồng thông minh của ứng dụng. Thông thường, điều này xảy ra thông qua giao diện người dùng dễ sử dụng (chẳng hạn như ứng dụng hoặc trang web) hoạt động như một giao diện giữa 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ẽ bắt nguồ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 ứng dụng L1.
Ngoài việc dựa vào người quản lý để lọc phí giao diện người dùng, các ứng dụng cũng có thể sử dụng phương pháp danh sách trắng hoặc danh sách đen để lọc các giao diện người dùng làm tăng phí mạng. Một lần nữa, mục đích ở đây là để đảm bảo rằng người nắm giữ token và toàn bộ giao thức không thu 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 phương pháp danh sách trắng, ứng dụng sẽ xuất bản một bộ quy tắc cho giao diện người dùng, tạo sổ đăng ký các giao diện người dùng tuân thủ 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 token để nhận được một phần lệ phí nộp đơn. Nếu giao diện người dùng không tuân thủ các quy tắc, nó sẽ bị cắt và chứng nhận đóng phí của nó sẽ bị xóa.
Theo phương pháp danh sách đen, ứng dụng không phải 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 ứng dụng không phải là không được phép. Thay vào đó, ứng dụng sẽ yêu cầu bất kỳ giao diện người dùng nào đưa ra ý kiến từ một 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 ứng dụng. Sau khi nhận được nhận xét, ứng dụng sẽ cấp giấy chứng nhận đóng góp phí cho giao diện người dùng. Giấy chứng nhận này sẽ chỉ bị xóa nếu cơ quan quản lý thông báo ứng dụng rằng giao diện người dùng không tuân thủ.
Kênh chi phí tương tự như các ví dụ được cung cấp trong các 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 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 hơn là giao trách nhiệm tuân thủ này cho người quản lý.
Chuỗi ứng dụng
Chuỗi ứng dụng là một blockchain dành riêng cho ứng dụng có trình xác thực dành riêng cho ứng dụng đó.
Đổ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ư blockchain L1, nơi người xác thực thường được thưởng bằng cách phát hành token thông qua 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, người nắm giữ token 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 đun đặt cược được quản lý.
Bộ làm việc này khác với bộ xác minh L1. Trình xác thực Chuỗi ứng dụng xử lý các giao dịch cụ thể từ các ứng dụng cụ thể. Do sự khác biệt này, người xác nhận Chuỗi có thể chịu mức độ rủi ro pháp lý cao hơn liên quan đến rủi ro hoạt động cơ bản mà họ đang hỗ trợ. Do đó, giao thức phải cấp cho người xác nhận quyền tự do thực hiện công việc mà họ có thể thực hiện theo luật pháp thuộc thẩm quyền và ý muốn 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 Chuỗi 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ó phân tán về mặt địa lý.
Kiến trúc của Chuỗi ứng dụng mong muốn tận dụng khả năng truy xuất nguồn gốc chi phí sẽ tương tự như các ứng dụng L1. 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. Phí cho bất kỳ giao dịch nhất định nào sẽ chuyển đến nhóm trình xác thực đang hoạt động, trong khi những người 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 các chức năng tương tự như người quản lý mô-đun đun đặt cược đã thảo luận ở trên và người đặt cược của những người xác nhận này được đả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ý.
Rollups
Rollups 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. Hầu hết rollups ngày nay đều có một sắp xếp tự duy nhất. Nếu rollups này dành riêng cho ứng dụng và có sắp xếp là người xác thực duy nhất, thì phí được tạo ra bởi các giao dịch có trong sắp xếp đó 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 Rollups phi tập trung sắp xếp của nó, sắp xếp sẽ trở thành mô-đun đun đặt cược đặc trưng trên thực tế và các kênh tính phí sẽ giống như Chuỗi ứng dụng. Sắp xếp thay thế người xác nhận để phân phối phí và mỗi sắp xếp có thể tự quyết định giao diện người dùng nào sẽ chấp nhận phí.
Mặc dù có nhiều mô hình khả thi cho token ứng dụng, nhưng việc cung cấp nhóm đặt cược được quản lý có thể giúp giải quyết các thách thức bên ngoài dành riêng cho ứng dụng. Bằng cách nhận ra những thách thức bên trong và bên ngoài mà các ứng dụng phải đối mặt, người sáng lập có thể thiết kế tốt hơn các mô hình token ứng dụng cho các dự án của họ ngay từ đầu.
Chào mừng bạn tham gia cộng đồng chính thức BlockBeats BlockBeats:
Nhóm đăng ký Telegram: https://t.me/theblockbeats
Nhóm liên lạc Telegram: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
