Chìa khóa cho bất kỳ hệ thống Web3 nào là đạt được sự tăng trưởng bền vững ngay từ đầu và sau đó duy trì quy mô nhất định để có thể xảy ra các hiệu ứng mạng đáng kể.

Tiêu đề gốc: "** Tokenomics đơn giản dành cho mã thông báo tiện ích bằng chứng cổ phần ***"

** Viết bởi Noam Nisan (Đại học StarkWare và Do Thái)**

Biên soạn bởi: Cộng đồng người Hoa Starknet

Tài liệu này khám phá "Nền tảng Web3 với Bằng chứng về cổ phần và Mã thông báo tiện ích", đây là một loại nền tảng khá phổ biến trong "thế giới blockchain". Chúng tôi sẽ giải thích chi tiết ý nghĩa của các thuật ngữ này, Bảng 1 hiển thị các nền tảng lớn nhất như vậy tính đến đầu tháng 8 năm 2023 và các chỉ số "tài chính" chính của chúng¹.

Bảng 1: Hệ thống Proof-of-Stake và các token tiện ích của chúng có vốn hóa thị trường ít nhất 3 tỷ USD

(Nguồn dữ liệu steringrewards.com*, dữ liệu tính đến ngày 7 tháng 8 năm 2023)*

Chúng tôi mong muốn đề xuất một số nguyên tắc chung và ngắn gọn để phân tích các hệ thống như vậy và tính kinh tế mã thông báo của chúng, được gọi là “kinh tế mã thông báo”. Chúng tôi cố gắng cực kỳ đơn giản, nhưng bất kỳ hệ thống cụ thể nào cũng sẽ yêu cầu phân tích phức tạp hơn dựa trên các mục tiêu, ràng buộc và hoàn cảnh cụ thể của nó. Tuy nhiên, chúng tôi hy vọng rằng những quan điểm này sẽ đóng vai trò là điểm khởi đầu hữu ích để hiểu và khám phá những vấn đề này và có thể cung cấp hướng dẫn cho các ước lượng thiết kế sơ bộ.

1. Loại hệ thống chúng ta thảo luận

***Trong phần này, chúng tôi sẽ giải thích ý nghĩa của “nền tảng Web3 với bằng chứng cổ phần và mã thông báo tiện ích” và tranh luận tại sao nền tảng đó phải cung cấp một số loại tiện ích cho người dùng, phải phát triển đến quy mô đủ lớn và các nhà khai thác của nó phải được khen thưởng. ***

1.1.Nền tảng Web3

Chúng tôi định nghĩa "nền tảng Web3" là bất kỳ nền tảng điện toán nào cung cấp các dịch vụ trực tuyến đạt được sự đồng thuận và tin cậy mà không cần dựa vào bất kỳ bên trung tâm đáng tin cậy nào. Các ví dụ điển hình bao gồm các loại tiền điện tử như Bitcoin, các nền tảng kinh tế kỹ thuật số như Ethereum, các L2 phi tập trung khác nhau giúp tăng thêm giá trị cho Ethereum và các nền tảng ứng dụng tài chính phi tập trung cụ thể (DeFi). Đặc điểm cốt lõi của các hệ thống này là chúng có thể duy trì hoạt động một cách đáng tin cậy mà không cần phụ thuộc vào sự tồn tại và hoạt động của bất kỳ công ty, tổ chức hoặc chính phủ nào. Về cơ bản, một bên đáng tin cậy duy nhất được thay thế bằng sự đồng thuận giữa một số lượng lớn các bên nhỏ hơn.

Tất nhiên, một số người có thể đặt câu hỏi về tính khả thi và tầm quan trọng của một hệ thống như vậy, vì nó tránh các cơ chế truyền thống, đã được thử và đúng như ngân hàng và tài chính, nhưng bài báo này lập luận rằng nhiều người muốn một hệ thống như vậy tồn tại và tin rằng đối với một số người ứng dụng, không dựa vào một thực thể trung tâm là một tính năng đáng giá và quan trọng.

Mức độ tin cậy do nền tảng Web3 cung cấp rõ ràng sẽ phụ thuộc vào quy mô và chất lượng của các đối tác, đây là nền tảng của niềm tin vào hệ thống. Do đó, loại nền tảng này thể hiện hiệu ứng mạng phản hồi tích cực đáng kể: nền tảng càng phát triển tốt thì độ tin cậy càng cao và trang giá trị mà nó có thể cung cấp càng lớn, từ đó thu hút nhiều người tham gia hơn, do đó thúc đẩy hơn nữa sự phát triển của nền tảng. nền tảng³.

***Như với bất kỳ hệ thống Web3 nào, điều quan trọng là ban đầu phải đạt được mức tăng trưởng bền vững và sau đó duy trì quy mô nhất định để có thể xảy ra các hiệu ứng mạng đáng kể. ***

1.2. Bằng chứng về cổ phần

Tính bảo mật của hệ thống Web3 dựa vào sự hợp tác và đồng thuận của nhiều người tham gia ở quy mô nhỏ.Do đó, một thách thức quan trọng mà mọi hệ thống Web3 phải đối mặt là “Phòng thủ tấn công Sybil”: tức là làm thế nào để đảm bảo rằng một nhóm người tham gia có vẻ lớn không được kiểm soát bởi một thực thể duy nhất. Sau hệ thống Bitcoin, các hệ thống ban đầu đã áp dụng cơ chế "bằng chứng công việc" để giải quyết thách thức này, cơ chế này yêu cầu những người tham gia hỗ trợ bảo mật hệ thống phải chứng minh sức mạnh tính toán của họ. Khi Bitcoin trở nên phổ biến hơn, sức mạnh tính toán cần thiết tiếp tục tăng lên, dẫn đến lượng điện cần thiết chiếm một phần lớn trong tổng lượng điện tiêu thụ của thế giới và có tác động đáng kể đến hiện tượng nóng lên toàn cầu.

Mặc dù đã có đề xuất về các loại cơ chế bảo vệ Sybil khác, chẳng hạn như “Bằng chứng về nhân loại”, xác định con người thật, nhưng công bằng mà nói thì giải pháp thay thế duy nhất hiện được coi là hiệu quả là “Bằng chứng cổ phần”. Trong loại hệ thống này, người tham gia phải nắm giữ một lượng "mã thông báo" nhất định của hệ thống và số lượng mã thông báo họ nắm giữ sẽ xác định "danh tính" và tầm ảnh hưởng của họ trong hệ thống. Cụ thể, sự đồng thuận trong hệ thống được xác định bằng thỏa thuận đạt được của những người tham gia nắm giữ đa số (hoặc có lẽ nhiều hơn đa số) lợi ích.

Đã có rất nhiều tài liệu thảo luận về việc so sánh giữa hệ thống proof-of-stake và proof-of-work, ở đây chúng ta khám phá cách một hệ thống proof-of-stake điển hình hoạt động từ góc độ kinh tế. Ban đầu, nền tảng “đúc” một số lượng token nhất định và phân phối chúng theo một cách nào đó. Để tham gia vào hoạt động của nền tảng, các nhà khai thác phải mua mã thông báo trên thị trường mã thông báo và "cam kết", nghĩa là khóa mã thông báo trong nền tảng làm tài sản thế chấp cho các hoạt động hợp pháp của nó. Đổi lại, những người đặt cọc đặt cược mã thông báo của họ và tiếp tục tham gia vào các hoạt động của nền tảng thường nhận được phần thưởng nền tảng dưới dạng nhiều mã thông báo hơn (họ có thể bán trên thị trường). Tùy thuộc vào giao thức nền tảng, những phần thưởng này có thể đến từ phí do người dùng nền tảng trả hoặc có thể là các mã thông báo mới được đúc. Nếu phần thưởng đến từ các token mới được đúc thì rõ ràng tổng nguồn cung token sẽ tăng lên, tức là token sẽ tăng cao⁴. Một cách khác để thưởng cho các nhà khai thác là trao cho họ quyền trích xuất giá trị nhất định từ người dùng hệ thống, được gọi là Giá trị có thể trích xuất của người khai thác (MEV).

***Trong nền tảng bằng chứng cổ phần, người đặt cược có thể kiếm được phần thưởng theo nhiều cách hoặc kết hợp các cách đó: phí do người dùng trả, đúc mã thông báo mới, giá trị được trích từ người dùng. ***

Trong bảng trên, chúng ta thấy dữ liệu “kinh tế mã thông báo” của Ethereum, có vốn hóa thị trường hơn 20 tỷ đô la và 8 nền tảng đặt cược lớn khác có vốn hóa thị trường là hàng tỷ đô la. (Tính đến thời điểm viết bài này, cũng có nhiều nền tảng nhỏ hơn, với khoảng 50 nền tảng trong số đó có vốn hóa thị trường trên 100 triệu USD.) Như chúng ta có thể thấy, phần thưởng danh nghĩa được trao cho những người đặt cọc (trên cơ sở hàng năm, dựa trên số tiền đặt cược của họ) ) phần trăm) thay đổi dao động từ 2% đến 20%, với mức trung bình chỉ hơn 5%. Có tính đến lạm phát mã thông báo, phần thưởng thực tế dao động trong khoảng từ 0% đến 10%, với mức trung bình khoảng 3%. Trong các hệ thống này, không phải tất cả các mã thông báo đều được đặt cược, với tỷ lệ đặt cược dao động từ 15% đến 70%, với mức trung bình gần hơn là 50%⁵. Một trong những mục tiêu của bài viết này là đề xuất một cách suy nghĩ có nguyên tắc về những dữ liệu này.

1.3 Token tiện ích

Có nhiều loại token và cách phân loại khác nhau. Bài viết này chủ yếu liên quan đến việc phân loại dựa trên mục đích kinh tế. Nghĩa là, mã thông báo được chia thành mã thông báo thanh toán, mã thông báo tiện ích và mã thông báo bảo mật. Mục đích của mã thông báo thanh toán là hoạt động như "tiền tệ" và thường được sử dụng làm phương tiện trao đổi và lưu trữ giá trị. Bitcoin là một ví dụ điển hình về mã thông báo thanh toán, cũng như nhiều loại tiền ổn định⁶. Mã thông báo bảo mật là một công cụ tài chính, tương tự như chứng khoán tài chính như cổ phiếu hoặc trái phiếu, cung cấp cho chủ sở hữu các quyền hoặc khiếu nại pháp lý nhất định đối với nhà phát hành.

Mã thông báo tiện ích có thể được sử dụng để tự động ⁷ nhận các dịch vụ cụ thể từ nền tảng, cung cấp cho người dùng tiện ích thực tế của nền tảng. Mã thông báo tiện ích thường được sử dụng để thanh toán cho việc sử dụng nền tảng để đổi lấy các dịch vụ do nền tảng cung cấp. Chuỗi khối Ethereum là một ví dụ điển hình, cung cấp dịch vụ thực hiện các giao dịch trên sổ cái công khai của Ethereum, “máy tính trên bầu trời”, một dịch vụ mà nhiều người dùng sẵn sàng trả số tiền lớn. Mã thông báo gốc của Ethereum, ETH, là cách duy nhất để thanh toán cho các dịch vụ này, vì vậy người dùng chuỗi khối Ethereum tiềm năng phải mua một số mã thông báo ETH từ người sẵn sàng bán chúng và sau đó sử dụng các mã thông báo đó để thanh toán vào chuỗi khối Ethereum.

Khi chúng tôi phân tích nền tảng Web3 từ góc độ "tiện ích" thuần túy, rõ ràng mục tiêu chính của hệ thống như vậy thực sự là cung cấp càng nhiều tiện ích càng tốt cho người dùng. Đương nhiên, để cung cấp tiện ích trên nền tảng Web3, phải duy trì đủ độ tin cậy và tính cởi mở, đồng thời phải đáp ứng các yêu cầu cụ thể khác dành cho nền tảng. Việc sở hữu token thực sự là một yếu tố quan trọng trong việc tạo điều kiện cho sự cộng tác không cần tin cậy. Từ góc độ nền tảng cung cấp tiện ích của chúng tôi, mục đích của mã thông báo và tính kinh tế của mã thông báo của nó cũng phải phục vụ mục tiêu cung cấp tiện ích. Chúng tôi sẽ tiến hành phân tích mã thông báo thuần túy “kinh tế vi mô” này tại đây.

Rõ ràng, hầu hết các mã thông báo tiện ích có thể có các chức năng khác, chẳng hạn như là mã thông báo thanh toán ở một mức độ nào đó. Người ta có thể đặt câu hỏi rằng giá trị hiện tại của ETH không chỉ xuất phát từ tiện ích của nó trong việc thực hiện các giao dịch trên chuỗi khối Ethereum, như Bitcoin, mà còn từ chức năng của nó như một kho lưu trữ giá trị và phương tiện thanh toán. Phân tích của chúng tôi chỉ hợp lý khi một phần lớn hoặc ít nhất một phần đáng kể giá trị của mã thông báo bắt nguồn từ vai trò của nó là mã thông báo tiện ích.

2. Kinh tế mã thông báo vi mô: Phí và phúc lợi xã hội

***Phần này mô tả hệ thống mã thông báo vi mô của mã thông báo, tập trung vào phí giao dịch mà người dùng cần phải trả để sử dụng nền tảng. Chúng tôi tin rằng phí giao dịch tối ưu sẽ là chi phí biên mà nền tảng phải gánh chịu khi thực hiện các giao dịch, bao gồm cả chi phí tắc nghẽn khi xảy ra tắc nghẽn. ***

Đúng như tên gọi, một nền tảng có mã thông báo tiện ích sẽ cung cấp một dịch vụ nhất định cho người dùng, do đó chắc chắn sẽ thiết lập một thị trường cho dịch vụ này, thị trường này sẽ xác định ai có thể nhận được dịch vụ và họ cần trả bao nhiêu cho dịch vụ đó. Phần này sẽ cung cấp một phân tích cơ bản về thị trường này.

Để phù hợp với mục tiêu đơn giản hóa, chúng tôi đã duy trì cuộc thảo luận của mình đơn giản nhất có thể trong khi chúng tôi tin rằng chúng tôi vẫn nắm bắt được tính kinh tế cơ bản của các hệ thống Web3 dựa trên tiện ích. Đặc biệt, chúng tôi nhấn mạnh vào phân tích "tĩnh" để tránh liên quan đến các vấn đề động và thời gian phức tạp hơn. Mặc dù những vấn đề này nhìn chung khó xử lý hơn nhưng chúng tôi tin rằng chúng nên được giải quyết bằng cách sử dụng các nguyên tắc tương tự như trường hợp tĩnh.

2.1. Mục tiêu của nền tảng và phúc lợi xã hội

Điều đầu tiên chúng ta cần làm rõ là mục tiêu mà nền tảng nên cố gắng tối ưu hóa. Mặc dù phản ứng đầu tiên của mọi người là "làm cho những người xây dựng nền tảng trở nên giàu có", quan điểm này bỏ qua hành vi của những người tham gia được mong đợi trong hệ sinh thái nền tảng và không đề xuất bất kỳ khuyến nghị ra quyết định nào. Quan điểm của chúng tôi hoàn toàn ngược lại: mục tiêu của nền tảng là tối đa hóa tổng giá trị mà nền tảng đó mang lại cho “thế giới”, điều mà các nhà kinh tế đôi khi gọi là tối đa hóa phúc lợi xã hội.

Hãy bắt đầu từ góc độ quy chuẩn: Nền tảng nên tối ưu hóa để làm gì? Nếu nền tảng được xem như một công ty và các token của nó được coi là cổ phiếu của công ty thì đương nhiên người ta sẽ cố gắng tối ưu hóa lợi nhuận cho “các cổ đông”. Nhưng quan điểm này không phù hợp với triết lý của cộng đồng Web3. Cộng đồng Web3 không muốn coi cơ sở hạ tầng của mình như một công ty mà là một dịch vụ công cộng cung cấp cho người dùng. Chuỗi khối Ethereum là một ví dụ điển hình, trừ khi ETH được thế chấp, chủ sở hữu ETH không trực tiếp nhận được bất kỳ lợi nhuận nào từ hoạt động của chuỗi khối Ethereum. Quay trở lại cuộc thảo luận trước đây của chúng ta về việc phân biệt giữa mã thông báo bảo mật và mã thông báo tiện ích, mục đầu tiên liên quan đến việc tối đa hóa lợi nhuận cho người nắm giữ mã thông báo (cổ phiếu), trong khi với mục sau – trọng tâm của chúng tôi là tối đa hóa giá trị của toàn bộ hệ sinh thái nền tảng. Một cách nhất quán, điều này chủ yếu là bao gồm (hầu hết) người dùng của nó.

Nếu cuộc thảo luận mang tính quy phạm ở trên có vẻ quá lý tưởng hoặc quá cao cả, chúng ta cũng có thể bắt đầu từ góc độ thực tế hơn. Giả sử một số người tham gia có các mục tiêu khác ít mang tính từ thiện hơn, chẳng hạn như tối đa hóa thu nhập cá nhân của họ với tư cách là người nắm giữ mã thông báo. Làm thế nào họ có thể làm điều này về lâu dài? Vì hiệu ứng mạng là động lực nội tại của bất kỳ hệ thống Web3 nào nên mục tiêu chính của nền tảng là tăng trưởng. Nền tảng phát triển càng nhanh thì càng có khả năng tồn tại và mang lại nhiều “lợi ích xã hội” hơn cho hệ sinh thái, người sáng tạo và chủ sở hữu mã thông báo. Cách chính để đạt được sự tăng trưởng là đảm bảo rằng nền tảng thực sự cung cấp càng nhiều tiện ích càng tốt. Điều này không chỉ thu hút người dùng sử dụng nền tảng vì họ nhận được giá trị trực tiếp mà việc “tối ưu hóa cho người dùng” còn cung cấp thông tin công khai tốt hơn, điều này rất quan trọng trong cộng đồng Web3. Một phép ẩn dụ thích hợp cho các mục tiêu của một nền tảng có thể là nó giống một quốc gia hơn là một công ty: mục tiêu không phải là tăng giá trị cổ đông gây tổn hại đến các lợi ích khác mà là phát triển toàn bộ nền kinh tế, cuối cùng là cải thiện rất nhiều tất cả những người tham gia⁸. Chuyển quan điểm này sang hoạt động hàng ngày của nền tảng, cuối cùng chúng tôi nỗ lực hướng tới tối đa hóa phúc lợi xã hội.

***Mục tiêu của nền tảng Web3 với mã thông báo tiện ích là tối đa hóa lợi ích xã hội mà nó mang lại. ***

2.2.Làm thế nào để tối đa hóa phúc lợi xã hội?

Vì vậy, giả sử rằng chúng ta muốn tối ưu hóa phúc lợi xã hội vì những lý do chuẩn mực hoặc thực tế, chúng ta nên làm gì? Đầu tiên, nền tảng rõ ràng phải cung cấp một số dịch vụ thực sự hữu ích, vì vậy trong phần còn lại của cuộc thảo luận, chúng tôi sẽ cho rằng nó thực hiện được điều này.

Hãy cụ thể hơn một chút và hãy đi vào một mô hình kinh tế. Khi chúng tôi nói một nền tảng làm được điều gì đó hữu ích, điều đó có nghĩa là nó phải hữu ích cho ai đó. Chúng tôi gọi những "người nhất định" này có thể đạt được giá trị từ nền tảng là người dùng (tiềm năng). Chúng tôi gọi đơn vị "dịch vụ" do nền tảng cung cấp một cách trừu tượng là giao dịch. Hoạt động của nền tảng có thể yêu cầu một số tài nguyên và năng lượng. Chúng tôi gọi cá nhân (hoặc công ty) cung cấp các tài nguyên và năng lượng này là nhà điều hành.

Ở cấp độ mô hình này, câu hỏi cơ bản về tối đa hóa phúc lợi xã hội tập trung vào những giao dịch mà nền tảng sẽ phục vụ. Ngay cả khi một giao dịch mang lại giá trị cho người dùng, chúng tôi có thể có hai lý do để không thực hiện giao dịch đó. Đầu tiên, chi phí (công sức và nguồn lực cần thiết) để thực hiện một giao dịch có thể cao hơn giá trị mà giao dịch đó mang lại cho người dùng, trong trường hợp đó tổng lợi ích của việc thực hiện giao dịch đó là âm. Thứ hai, nền tảng có thể có giới hạn công suất nhất định⁹, nếu nhu cầu giao dịch vượt quá khả năng cung cấp, nền tảng sẽ phải chọn những giao dịch “có giá trị” nhất và bỏ qua các giao dịch khác. Để tiếp tục phân tích, chúng ta hãy đi sâu vào một mô hình kinh tế rất đơn giản cho tình huống này.

2.3.Mô hình kinh tế cơ bản

Chúng tôi cố gắng xây dựng một mô hình kinh tế cơ bản nắm bắt được bản chất của tình huống mà chúng tôi thảo luận: Giả sử có nhiều giao dịch i=1,2,…,N mong muốn được nền tảng phục vụ. Mỗi giao dịch i có một người dùng khởi tạo có giá trị liên quan vᵢ cho giao dịch này. Đồng thời, mỗi giao dịch cũng phát sinh chi phí cận biên liên quan cᵢ, đây là chi phí mà nền tảng (thông qua nhà điều hành) phải chịu để xử lý giao dịch đó (ngoài các giao dịch khác đã được xử lý). Trong lý thuyết kinh tế truyền thống, chi phí biên của một đơn vị sản phẩm thường phụ thuộc vào số lượng đơn vị khác đã được sản xuất (chi phí biên tăng hoặc giảm), nhưng trong trường hợp của chúng ta, có thể an toàn hơn nếu coi chi phí giao dịch là chi phí cố định (sau khi chịu một số chi phí cố định để bắt đầu hoạt động cho đến khi đạt đến giới hạn công suất nào đó của nền tảng). Tối đa hóa phúc lợi xã hội có nghĩa là chọn bộ giao dịch dịch vụ S trong số tất cả các bộ giao dịch có thể đáp ứng dung lượng nền tảng để tối đa hóa ∑ i∈S (vᵢ-cᵢ).

Vì vậy, trong mô hình này, chúng ta nên phục vụ những giao dịch nào? Nếu nền tảng chưa đạt đến giới hạn công suất, chúng ta nên xử lý tất cả các giao dịch có giá trị ròng dương (vᵢ-cᵢ), tức là các giao dịch có vᵢ > cᵢ. Vậy làm thế nào để làm điều đó? Mặc dù chúng tôi có thể giả định rằng các nền tảng có thể tính toán (hoặc ít nhất là ước tính) chi phí *cᵢ* liên quan đến các giao dịch dịch vụ, nhưng giá trị vᵢ của mỗi giao dịch là chủ quan trong mắt người dùng quan tâm và chỉ bản thân người dùng mới có thể biết được Chắc chắn. Có một thủ thuật kinh tế cơ bản ở đây: tính phí giao dịch cho người dùng bằng cᵢ để xử lý giao dịch của anh ta. Trong trường hợp này, người dùng sẽ chọn thực hiện giao dịch của mình khi và chỉ khi giá trị cá nhân của anh ta vᵢ cao hơn chi phí, tức là vᵢ > cᵢ. Đây được gọi là định giá "chi phí cận biên" và là thực tế cơ bản được trình bày trong khóa học "Kinh tế 101": để tối đa hóa phúc lợi xã hội, giá của một đơn vị phải bằng "chi phí biên" của việc cung cấp đơn vị¹⁰.

***Để tối ưu hóa phúc lợi xã hội, phí giao dịch phải được đặt ở mức chi phí cận biên. Làm như vậy sẽ gắn kết tiện ích ròng của người dùng với phúc lợi xã hội. ***

Trong trường hợp tắc nghẽn, "chi phí cận biên" có liên quan cũng phải tính đến tác động của việc xử lý các giao dịch của chúng tôi gây thiệt hại cho các giao dịch khác không được xử lý. Trong trường hợp này, phí giao dịch không chỉ nên xem xét chi phí trực tiếp của giao dịch cᵢ mà còn cả “chi phí tắc nghẽn”: tổn thất phúc lợi xã hội ròng gây ra cho những người dùng khác. Hãy xem cách tính toán điều này trong trường hợp đơn giản và phổ biến nhất.

Mô hình khí một chiều: Đây là mô hình đơn giản và phổ biến nhất để mô tả các giới hạn dung lượng của hệ thống Web3. Mỗi giao dịch có một kích thước si nhất định, được sử dụng để mô tả lượng tài nguyên hệ thống mà nó tiêu thụ (thuật ngữ Ethereum gọi đây là "gas" được sử dụng bởi giao dịch) và tổng tài nguyên của hệ thống (tức là gas) có Dung lượngK nhất định. Do đó, nếu ∑i∈S si ≤ K thì một tập hợp giao dịch S là khả thi và tối đa hóa phúc lợi xã hội có nghĩa là tối đa hóa ∑i∈S(vi-ci) theo ràng buộc này. Hơn nữa, trong mô hình này, chi phí liên quan để thực hiện một giao dịch được coi là tỷ lệ thuận với quy mô của giao dịch, tức là cᵢ=αsᵢ (trong đó α là một hằng số toàn cầu nào đó). Mặc dù vấn đề tối ưu hóa này về cơ bản là một vấn đề về chiếc ba lô cổ điển nhưng thường không có thuật toán hiệu quả nào để giải quyết nó một cách trực tiếp. Nhưng có một thuật toán gần đúng tham lam nổi tiếng: sắp xếp các giao dịch theo thứ tự giảm dần vᵢ/sᵢ và xử lý các giao dịch từ trên xuống cho đến khi việc xử lý giao dịch tiếp theo vượt quá giới hạn dung lượng (hoặc cho đến vᵢᵢ). "Giá gas" được đặt thành g=vi/si trong giao dịch được chấp nhận cuối cùng i hoặc trong trường hợp không có tắc nghẽn, ở mức giá thấp nhất g=α và phí sẽ tỷ lệ thuận với giá gas đó, tức là fᵢ = gsᵢ¹².

Các mô hình được thảo luận ở trên rất đơn giản và bỏ qua nhiều khía cạnh sẽ xảy ra trong các nền tảng thực tế. Nhưng ý nghĩa kinh tế chính của nó vẫn mang tính phổ quát: để tối đa hóa phúc lợi xã hội, chúng ta nên tính phí giao dịch bằng chi phí biên. Khi tắc nghẽn xảy ra, phí giao dịch cũng phải bao gồm "chi phí tắc nghẽn".

2.4. Cơ chế phí giao dịch

Mặc dù chúng tôi đã xác định các khoản phí cần thiết để đảm bảo tối đa hóa phúc lợi xã hội, nhưng chúng tôi vẫn cần xác định một cơ chế cụ thể cho phép nền tảng của chúng tôi thực sự thu các khoản phí này. Cơ chế như vậy phải tính đến việc cả người dùng và nhà điều hành nền tảng đều hành xử hợp lý và "chiến lược", mỗi người cố gắng tối ưu hóa tiện ích của riêng mình và nhà điều hành có thể tương tác với nhiều người dùng (dù là thật hay sai) thì có sự thông đồng. Mặc dù chúng tôi thường cho rằng người dùng hành xử có chiến lược, nhưng chỉ trong những trường hợp cụ thể, chúng tôi mới cần lo lắng về hành vi chiến lược của người vận hành. Tình huống này xảy ra khi người vận hành có một mức độ tự do nhất định và hành vi phi giao thức của nó rất khó bị người vận hành khác "bắt". Đối với các nhà khai thác không có quyền tự do, họ chỉ cần được khuyến khích tiếp tục tham gia thông qua các khoản thanh toán lớn, “phần thưởng khối”, v.v. Khi có một mức độ tự do nào đó, chẳng hạn như khi một hoạt động có thể quyết định chấp nhận giao dịch nào, giao thức nền tảng cần đảm bảo rằng nhà điều hành có động cơ để hành động phù hợp với mong đợi. Có lẽ đáng ngạc nhiên là ngay cả một cơ chế đơn giản cũng có thể tính các khoản phí cần thiết ở trạng thái cân bằng.

Cơ chế đặt giá thầu để thanh toán: Lấy cơ chế "đặt giá thầu để trả" đơn giản được sử dụng trong Bitcoin để quyết định giao dịch nào sẽ được chấp nhận làm ví dụ, hãy khám phá lý do tại sao cơ chế này có thể tính gần đúng chi phí cận biên (bao gồm cả chi phí tắc nghẽn) , và do đó gần đúng với Tối ưu hóa phúc lợi xã hội. Cơ chế cơ bản hoạt động như sau: tại một thời điểm cụ thể - trong một khối - có một nhà điều hành (thợ đào) quyết định giao dịch nào có thể vào khối. Đối với chúng tôi, việc lựa chọn nhà điều hành như thế nào không quan trọng, thỏa thuận quan trọng là đảm bảo rằng quyết định của nhà điều hành này có nhiều khả năng trở thành sự đồng thuận nhất. Người dùng đặt giá thầu cho các giao dịch của riêng họ và nhà điều hành được chọn có thể chấp nhận bất kỳ tập hợp con giá thầu nào họ muốn trong một khả năng nhất định và tính phí cho giá thầu của mình đối với bất kỳ giao dịch nào được chấp nhận. Vì vậy, điều gì xảy ra trong thời gian dài ở trạng thái cân bằng? Nếu chúng ta coi tình huống của mình là một thị trường kinh tế (tức là một không gian giao dịch), chúng ta kỳ vọng thị trường sẽ đạt đến trạng thái cân bằng trong đó phí bằng chi phí biên và phúc lợi xã hội được tối đa hóa.

Cân bằng trong mô hình Gas:* Hãy quay lại mô hình tài nguyên một chiều của chúng ta, trong đó mỗi giao dịch i* có giá trị *vᵢ*, kích thước *sᵢ* và chi phí Tỷ lệ theo kích thước của nó, tức là *cᵢ=αsᵢ*, tổng dung lượng của một khối được giới hạn ở *K*. Bây giờ, chủ sở hữu của mỗi giao dịch đặt giá thầu *bᵢ*. Nhìn lại việc nhà điều hành quyết định giao dịch nào sẽ được chấp nhận, có thể thấy rõ rằng nhà điều hành nếu được trả thù lao cho việc đặt giá thầu bᵢ sẽ chấp nhận tập hợp giá thầu tối đa hóa ∑i∈S bi*S * , có nghĩa là (bỏ qua các ràng buộc về số nguyên) rằng anh ta sẽ chấp nhận tập hợp giá thầu có tỷ lệ bᵢ/sᵢ cao nhất cho đến khi đạt đến giới hạn dung lượng khối. Chúng tôi hy vọng động lực đặt giá thầu sẽ cho phép người đặt giá thầu tìm và đặt giá thầu ở giá trị bᵢ tối thiểu (có lẽ về lâu dài) khiến giao dịch của họ có thể chấp nhận được (yêu cầu *bᵢ≤vᵢ*, nếu không thì họ không sẵn lòng trả bᵢ). Trạng thái cân bằng đạt được theo giả định này sẽ khiến những người đặt giá thầu có giá trị kích thước đơn vị đủ cao bᵢ/sᵢ đặt giá thầu ở "giá gas cân bằng" p, trong khi những người đặt giá thầu có giá trị thấp hơn sẽ đặt giá thầu thấp hơn Một mức giá này. Nghĩa là, mọi người đặt giá thầu có *vᵢ ≥p*sᵢ sẽ đặt giá thầu *bᵢ=p*sᵢ và *vᵢα* (hãy nhớ rằng *cᵢ=αsᵢ*), sau đó là *∑i∈S (vᵢ – cᵢ)*, do đó tối đa hóa phúc lợi. Để xử lý các tình huống không bị tắc nghẽn, trong đó các giao dịch với vᵢ ≥cᵢ=αsᵢ không lấp đầy dung lượng khối, hệ thống phải chỉ định giá gas tối thiểu *p* ≥α*¹³ như một phần của giao thức.

Khả năng tương thích khuyến khích:* Có thể có những lo ngại về tốc độ và mức độ mà cơ chế trả giá thầu sẽ đạt được (ít nhất là xấp xỉ) trạng thái cân bằng này và cách người dùng tìm ra các tham số kỳ diệu mà họ cần để đặt giá thầu phù hợp. P*. Các cơ chế tính phí phức tạp hơn (chẳng hạn như cơ chế EIP-1559 được sử dụng trong Ethereum) có thể làm cho quá trình đấu thầu trở nên minh bạch hơn (“tương thích khuyến khích” trong các điều khoản thiết kế cơ chế), từ đó trực tiếp hướng dẫn hệ thống đạt được sự cân bằng hiệu quả, điều này sẽ giúp Tối đa hóa xã hội phúc lợi và bằng chi phí với chi phí cận biên¹⁴. Có rất nhiều nghiên cứu¹⁵ về cách thiết kế các cơ chế như vậy và nghiên cứu này có thể được khái quát hóa cho các tình huống phức tạp và thực tế hơn.

Trích xuất giá trị từ người dùng (MEV): Khi cơ chế cho phép các nhà khai thác trích xuất một số giá trị từ giao dịch của người dùng, có lẽ nên cân nhắc việc tính "phí ẩn" từ người dùng. Bản chất của việc trích xuất này phụ thuộc vào các dịch vụ được cung cấp bởi nền tảng, nhưng một ví dụ điển hình trong blockchain là người xác thực tạo khối có thể thêm các giao dịch của riêng họ, khiến nó "chặn trước" một số giao dịch người dùng nhất định, từ đó chuyển giá trị sang Trong của bạn. chính tay mình. Việc nắm bắt giá trị cơ hội này không liên quan gì đến chi phí dịch vụ giao dịch hoặc tắc nghẽn, do đó, các khoản phí MEV ẩn này không phù hợp với tình hình kinh tế của hệ thống và có thể, chẳng hạn, khiến những người dùng có giao dịch có thể bị lợi dụng sợ hãi. Vì vậy, mặc dù đôi khi không thể loại bỏ hoàn toàn khả năng này nhưng các cơ chế liên quan nên hạn chế tối đa khả năng này.

2.5. Kết luận: Kinh tế mã thông báo vi mô

Do đó, ý tưởng cốt lõi của phần này là các hệ thống Web3 có mã thông báo tiện ích phải nhằm mục đích tối đa hóa phúc lợi xã hội (tức là giá trị gia tăng) mà chúng cung cấp. Điều này đạt được khi phí được tính bằng với chi phí cận biên của các giao dịch được phục vụ (bao gồm cả chi phí tắc nghẽn). Trên thực tế, có một số cơ chế kinh tế để đạt được điều này. Mặc dù các chi tiết có thể phức tạp do sự phức tạp của nền tảng nhưng các nguyên tắc cơ bản vẫn được áp dụng.

3. Kinh tế mã thông báo vĩ mô: Chi phí đặt cược và đúc mã thông báo mới

***Phần này sẽ giải thích tính kinh tế vĩ mô của mã thông báo, tập trung vào mối quan hệ giữa tỷ lệ đúc mã thông báo mới, phần thưởng của người đặt cược và tính bảo mật có được thông qua đặt cược. Quan điểm chính của chúng tôi là phần thưởng đặt cược phải trang trải chi phí tài trợ của người đặt cược, tốt nhất là được thanh toán thông qua mã thông báo mới được đúc và là yếu tố chính trong việc xác định tỷ lệ đúc. ***

Phần trước tập trung vào chi phí giao dịch, kinh tế vi mô của nền tảng Web3 cung cấp tiện ích cho người dùng. Bây giờ chúng tôi chuyển sự chú ý sang *kinh tế vĩ mô* của nền tảng: cách quản lý tiền trong toàn hệ thống và cách quản lý phân phối mã thông báo. Tất nhiên, các hệ thống thực tế có thể cần xem xét các yếu tố phức tạp hơn, nhưng hy vọng phân tích của chúng tôi vẫn có thể đóng vai trò là điểm khởi đầu hữu ích. Trước tiên, chúng ta hãy bắt đầu với những khác biệt chính giữa phân tích kinh tế vi mô nêu trên và các yếu tố cần thiết đảm bảo sự vận hành của nền kinh tế hệ thống.

##3.1 Chi phí cố định

Công thức tính phí giao dịch dựa trên chi phí cận biên đã bỏ qua một vấn đề cốt lõi, đó là "chi phí ngoài biên". Hãy chính xác hơn. Trong tất cả các cuộc thảo luận của chúng ta ở trên, chi phí duy nhất liên quan đến việc phục vụ một giao dịch i là chi phí cận biên bổ sung, tức là chi phí để phục vụ giao dịch đó cộng với các chi phí giao dịch khác đã phát sinh là bao nhiêu. Thực tế, điều này xác định liệu chúng tôi có nên phục vụ giao dịch bổ sung này hay không (giả sử chúng tôi đã quyết định những giao dịch nào khác sẽ được phục vụ). Ví dụ: chi phí phục vụ các giao dịch N là $100+N(1\*, khi đó chi phí phục vụ 9 giao dịch là 109 và chi phí phục vụ 10 giao dịch là 110. Trong trường hợp này, chúng tôi sẽ xem xét rằng có chi phí cố định là 100 và chi phí cận biên là 1. Mặc dù chi phí cận biên là 1 nhưng chi phí trung bình để phục vụ 10 giao dịch là 11. Nếu chúng ta chỉ tính chi phí cận biên thì chúng ta chỉ có thể tính phí )1 từ mỗi giao dịch, nhưng chi phí cố định 100 USD còn thiếu đến từ đâu? Khi chi phí cận biên thấp hơn chi phí trung bình, vấn đề thâm hụt do chỉ tính chi phí cận biên sẽ trở nên rõ ràng, đây dường như là một vấn đề điển hình trong blockchain¹⁶.

Trong thế giới thực, mọi chi phí cố định cuối cùng phải do chính người dùng chịu, do đó, việc định giá theo chi phí cận biên là không khả thi¹⁷, trong khi ở nền tảng được mã hóa, chi phí cố định có thể được thanh toán bằng cách tạo ra các mã thông báo mới. Ưu điểm của việc này là chi phí cố định và chi phí cận biên có thể được giữ bằng nhau. Tất nhiên, vẫn có những “người” cần phải trả chi phí cố định và những “người” này là tập hợp của tất cả những người nắm giữ token. Nghĩa là, việc đúc các mã thông báo mới có nghĩa là mã thông báo sẽ gặp phải lạm phát, có khả năng làm giảm giá trị của nó, do đó mỗi chủ sở hữu mã thông báo thực sự sẽ mất một phần nhỏ giá trị của mã thông báo.

Người ta có thể đặt câu hỏi về mức độ hợp lý hoặc mong muốn đặt gánh nặng này lên người nắm giữ token. Theo chúng tôi, đây là lựa chọn ít tệ nhất trong số rất nhiều lựa chọn. Đầu tiên, nó cho phép chúng tôi tối đa hóa việc sử dụng hệ thống bằng cách chỉ tính phí cho người dùng ở mức chi phí cận biên, phù hợp với các mục tiêu cơ bản của chúng tôi. Thứ hai, khi việc sử dụng hệ thống được tối đa hóa, tổng giá trị của nền tảng sẽ tăng lên, do đó giá trị của token tăng lên. Giá trị token tăng lên này có thể bù đắp cho những người nắm giữ token đã trả chi phí cố định.

**Để cho phép định giá chi phí cận biên, mọi chi phí cố định liên quan đến việc vận hành nền tảng sẽ được thanh toán tốt nhất bằng cách tạo ra các token mới. **

Nhìn vào các dự án blockchain hiện có, thông lệ phổ biến hiện nay là các mã thông báo mới được đúc để trả "phần thưởng khối". Những phần thưởng này không liên quan gì đến các giao dịch cụ thể trong khối mà là để thưởng cho người khai thác, người đặt cọc hoặc người sắp xếp thiết bị. Những phần thưởng khối này về cơ bản bao gồm các chi phí cố định liên quan, trong khi phí giao dịch do người dùng thanh toán là một phần bổ sung được trả cho các nhà khai thác.

Những độc giả hoài nghi có thể đặt câu hỏi về tính bền vững của quá trình này: Việc chủ sở hữu token tiếp tục trợ cấp cho nền tảng có hợp lý không? “Kết thúc” sẽ đi về đâu? Có một số "kết thúc" có thể xảy ra: Thứ nhất, có khả năng nền tảng sẽ đạt được sự tăng trưởng bền vững như một phần của sự tăng trưởng bền vững của nền kinh tế thế giới¹⁸. Một khả năng khác là nhu cầu về dịch vụ nền tảng tăng nhanh hơn mức tăng nguồn cung nền tảng. Trong trường hợp này, phí tắc nghẽn sẽ tiếp tục tăng (vì các lý do được nêu chi tiết trong phần kinh tế mã thông báo vi mô) và vì đây không phải là chi phí thực tế do nhà điều hành hệ thống gánh chịu nên phí tắc nghẽn có thể trang trải chi phí cố định¹⁹. Cũng có khả năng là khi mức độ sử dụng nền tảng tăng lên, chi phí cố định có thể trở nên không đáng kể so với chi phí cận biên ngày càng tăng và có thể được tính như một khoản phí bổ sung nhỏ mà không gây ra biến dạng thị trường đáng kể. Nếu không có cách nào ở trên giải quyết được vấn đề, chúng ta có thể mong đợi rằng về lâu dài, * sau khi đạt mức tăng trưởng đủ*, nền tảng thực sự sẽ tăng dần phí vượt quá chi phí cận biên đã nêu, giống như trong "thế giới thực" như đã làm .

3.2 Chi phí cầm cố

Trong hệ thống bằng chứng cổ phần, chi phí cố định quan trọng nhất thường là chi phí tài chính của việc đặt cược, đôi khi được gọi là "chi phí bảo mật", "chi phí vốn" hoặc "chi phí cơ hội". Cụ thể, những người đặt cọc nắm giữ và đặt cọc một số lượng token nhất định trong hệ thống, từ bỏ các cách khác để sử dụng số tiền đó. Sử dụng trực tiếp hoặc bán token để đổi lấy tiền tệ pháp định (chẳng hạn như đô la Mỹ) và sau đó sử dụng chúng theo những cách khác. Các chi phí này về cơ bản là chi phí tài chính, quy mô của nó được xác định bởi cả môi trường tài chính bên ngoài (ví dụ: lãi suất hiện tại) và bởi các thuộc tính dành riêng cho nền tảng được liên kết với mã thông báo đặt cọc (bao gồm cả rủi ro thực tế và nhận thức được) cũng như các cách sử dụng khác có thể có của các quyết định về mã thông báo (ví dụ: Cung cấp tính thanh khoản cho các nhà tạo lập thị trường tự động). Cụ thể, nếu tổng số tiền đặt cược là *S* (bằng USD) và người đặt cược kiếm được tỷ lệ lợi nhuận hàng năm là *r%* thì tổng chi phí đặt cược hàng năm là *r%*S *.

**Lấy Ethereum làm ví dụ: **Dựa trên dữ liệu vào đầu tháng 8 năm 2023, hãy tính chi phí đặt cược của nền tảng đặt cược lớn nhất, mạng Ethereum. Theo Bảng 1, khoảng 19% mã thông báo nền tảng Ethereum đã được thế chấp vào thời điểm đó và tổng giá trị của tất cả các mã thông báo là 224 tỷ USD, do đó tổng giá trị của mã thông báo được thế chấp là 42 tỷ USD. Như bảng hiển thị, lợi nhuận hàng năm của các token này là khoảng 5%, dẫn đến tổng chi phí đặt cược hàng năm là hơn 2 tỷ USD. Khối lượng giao dịch hàng năm của Ethereum là khoảng 400 triệu giao dịch (khoảng 12 giao dịch mỗi giây), do đó, mỗi giao dịch có giá hơn 5 USD, có thể là một phần quan trọng trong tổng chi phí vận hành nền tảng Ethereum.

3.3 Phần thưởng đặt cược

Mặc dù nền tảng cần đúc mã thông báo mới để trang trải chi phí cho nhà điều hành, nhưng đây chắc chắn là gánh nặng đối với chủ sở hữu mã thông báo, vì vậy tốt nhất chỉ nên đúc số lượng mã thông báo mới được yêu cầu. Giao thức cần đảm bảo rằng phần thưởng được phân phối đủ để khuyến khích các nhà khai thác tham gia và hành xử đúng đắn, do đó, phải tìm thấy sự cân bằng giữa các nhà khai thác có phần thưởng đầy đủ và việc đúc số lượng token mới tối thiểu. Chúng tôi tin rằng các biện pháp khuyến khích nói chung có thể điều chỉnh được ở cấp độ kinh tế vi mô, nói một cách tương đối, và do đó, yếu tố chính trong việc xác định tỷ lệ đúc tiền phải là chi phí vốn để thưởng cho các nhà khai thác.

Ví dụ: hãy xem mô hình “chuẩn” của blockchain, trong mỗi khối có một người vận hành, người lãnh đạo, người chịu trách nhiệm xây dựng khối và chịu phần lớn chi phí, trong khi những người vận hành khác về cơ bản chỉ sử dụng một số loại giao thức đồng thuận "ký" khối. Để giữ cho hệ thống hoạt động bình thường, những người lãnh đạo xây dựng các khối phải được đền bù xứng đáng, cũng như những người vận hành khác “vẫn hoạt động”. Điều thứ hai thường dễ đạt được vì họ không có quyền đại diện đáng kể và do đó, từ góc độ kinh tế vĩ mô, không có hạn chế khuyến khích rõ ràng2⁰. Việc khen thưởng các lãnh đạo khối thường là một vấn đề nan giải vì lãnh đạo có quyền tự chủ rất rộng nên chúng ta cần có những ưu đãi “vừa phải”. Tuy nhiên, cơ chế phí giao dịch có thể trực tiếp giải quyết vấn đề này bằng cách sử dụng phương pháp định giá chi phí cận biên đúng đắn, đồng thời tính đến động cơ của người đứng đầu và khuyến khích họ đưa các giao dịch đúng vào khối “vừa phải”. Ngoài việc xử lý hợp lý các động cơ khuyến khích chi phí cận biên, chúng ta chỉ cần bồi thường chi phí cố định cho người dẫn đầu và một "phần thưởng khối" cố định đủ lớn có thể thực hiện được điều này.

**Yếu tố chính quyết định tỷ lệ đúc phải là chi phí vốn của nhà điều hành phần thưởng. **

Trong phân tích sau đây, chúng tôi sẽ giả định rằng tỷ lệ phần thưởng nền tảng mà nhà điều hành yêu cầu được xác định bởi những người đặt cược theo những cách khác nhau dựa trên tính toán tài chính của họ. Những cân nhắc về tài chính của người đặt cọc có thể liên quan đến môi trường tài chính, rủi ro và tiềm năng được nhận thấy của nền tảng và mã thông báo cũng như khả năng thay thế của mã thông báo. Mặc dù có thể áp dụng nhiều mô hình tài chính khác nhau để ước tính mức độ ảnh hưởng của tỷ lệ phần thưởng bắt buộc bởi các thông số tài chính khác như lãi suất bên ngoài hoặc sự biến động lịch sử của tỷ giá hối đoái mã thông báo²¹, chúng tôi không yêu cầu ước tính như vậy và sẽ tiếp tục xử lý phần thưởng bắt buộc tỷ lệ được coi là một thực tế đã được xác lập. Theo kinh nghiệm, trên các nền tảng lớn khác nhau được liệt kê trong Bảng 1, tỷ lệ phần thưởng hàng năm dành cho người đặt cược là từ 2% đến 20% và thông thường tỷ lệ phần thưởng sẽ nằm trong khoảng từ 3% -7,5%, với mức trung bình là khoảng 5%. Sự khác biệt lớn này có thể phụ thuộc vào nhiều yếu tố và chắc chắn có rất nhiều "tiếng ồn" về ý nghĩa chính xác của những con số này. Tuy nhiên, chúng ta có thể thống nhất về một tỷ suất lợi nhuận hợp lý để xếp nó vào cùng loại với lợi suất trái phiếu hoặc cổ phiếu thông thường.

3.4 Token mới được đúc

Nền tảng phải cung cấp đủ phần thưởng cam kết cho các nhà khai thác, nếu không các nhà khai thác sẽ không sẵn lòng tham gia vào các hoạt động của nền tảng. Như đã đề cập ở trên, khái niệm “đủ” được xác định bởi chính những người đặt cọc, chủ yếu là vấn đề tài chính. Vậy nền tảng này nên được thiết kế như thế nào? Đó là những gì chúng tôi đang cố gắng giải quyết bây giờ. Phân tích cơ bản của chúng tôi sẽ xác định chi phí cố định và chi phí đặt cược, đồng thời giả định rằng nguồn phần thưởng đặt cược sẽ là các mã thông báo mới được đúc, sẽ được phân bổ đều cho những người đăng ký theo tỷ lệ. Chúng tôi sẽ chỉ tập trung vào tổng số lượng token và phần thưởng được đúc chứ không phải thành phần cụ thể của chúng, giả định rằng cơ chế phí giao dịch có thể xử lý các vấn đề này một cách thích hợp.

Để phân tích đơn giản, chúng ta hãy tập trung vào các thông số sau: (1) tỷ lệ đúc mã thông báo hàng năm trên tổng nguồn cung cấp mã thông báo hiện tại, (2) tỷ lệ phần thưởng đặt cược hàng năm trên tổng số tiền đặt cược, (3 ) tỷ lệ đặt cược, có Tỷ lệ mã thông báo được đặt cược trên tất cả các mã thông báo đang lưu hành. Phương trình tổng thể chi phối mối quan hệ này và ảnh hưởng đến kinh tế mã thông báo vĩ mô của nền tảng trông như thế này:

(% số tiền đúc mới mỗi năm) = (% phần thưởng đặt cược mỗi năm)*(Tỷ lệ đặt cược)

Chúng ta đã thảo luận về tỷ lệ phần thưởng đặt cược, bây giờ chúng ta hãy xem xét kỹ hơn về tỷ lệ tạo ra các mã thông báo mới. Tỷ lệ này được xác định bởi giao thức, sẽ quyết định thời điểm các mã thông báo mới được tạo ra (hoặc khi mã thông báo bị hủy). Theo giả định của chúng tôi, các mã thông báo mới được đúc sẽ được sử dụng để thanh toán cho phần thưởng đặt cược, đây là tổng ròng của tất cả các phần thưởng được giao thức phân phối hàng năm²². Cụ thể, trong giao thức blockchain, nếu giao thức quy định tổng phần thưởng cho mỗi khối là R token (trung bình, điều này đề cập đến tổng của tất cả các nhà khai thác, trừ đi việc tiêu hủy token), thì tổng số token hiện có là S, và có N khối mỗi năm, thì tỷ lệ đúc hàng năm của các token mới là RN/S.

Lưu ý rằng phần thưởng đặt cược trong công thức này là "lý tưởng", nghĩa là chúng không tính đến bất kỳ lạm phát nào về giá trị của mã thông báo. Nghĩa là, bất kỳ lạm phát nào về giá trị của mã thông báo đều không được tính đến. Công thức này dành cho những người đặt cược tin rằng các mã thông báo mới được đúc sẽ không thực sự làm giảm giá trị mã thông báo của họ (vì nền tảng đang phát triển nhanh hơn tốc độ được đúc). Nhưng những người đặt cược hoài nghi có thể quan tâm nhiều hơn đến tỷ lệ phần thưởng thực tế hoặc được điều chỉnh, được tính bằng cách trừ tỷ lệ đúc tiền khỏi tỷ lệ phần thưởng để có được con số tương ứng:

*(tỷ lệ phần thưởng được điều chỉnh) = (tỷ lệ đúc tiền)/(tỷ lệ đặt cược)-(tỷ lệ đúc tiền). *

3.5 Tỷ lệ cam kết và bảo mật

Theo định nghĩa, tính bảo mật của nền tảng bằng chứng cổ phần phụ thuộc vào cách nắm giữ mã thông báo để ngăn chặn các cuộc tấn công của Sybil. Nói cách khác, sự đồng thuận mà hệ thống ngụ ý được hình thành bởi các nhà khai thác nắm giữ một tỷ lệ token đủ lớn. Hãy cùng khám phá lý do tại sao chúng tôi tin tưởng loại sự đồng thuận này. Lý do đầu tiên đơn giản là chúng tôi không tin rằng bất kỳ bên độc hại nào sẽ có đủ tài nguyên để kiểm soát phần lớn số cổ phần đã đặt cược và những người đặt cược không độc hại sẽ trung thành tuân theo giao thức2³. Lý do thứ hai là bất kỳ bên nào cùng sở hữu phần lớn mã thông báo sẽ bị mất đáng kể nếu nền tảng ngừng hoạt động trung thực, vì giá trị mã thông báo có thể giảm đáng kể trong trường hợp như vậy. Lập luận đầu tiên là lập luận "đa số trung thực" điển hình trong khoa học máy tính, trong khi lập luận thứ hai là lập luận "khuyến khích" lý thuyết trò chơi phổ biến trong kinh tế học.

Việc định lượng hai lý do an toàn này là một bài tập khá thiếu chính xác vì cả hai đều phụ thuộc vào nhiều yếu tố. Vì lý do đầu tiên, chúng tôi phải cố gắng xác định tỷ lệ nào trong tổng số cam kết mà nền tảng phải chống lại sự tiếp quản của các bên độc hại. Vì lý do thứ hai, chúng tôi nên ước tính lợi ích kinh tế có thể đạt được khi một bên độc hại giành được phần lớn quyền lực đặt cược2⁴ và chúng tôi ước tính thiệt hại kinh tế do hành vi thao túng đó khiến giá trị mã thông báo giảm. Mặc dù việc định lượng chính xác là khó khăn, nhưng trong cả hai trường hợp, có vẻ như lợi ích từ việc sở hữu độc hại phần lớn các token đặt cọc sẽ ở mức tỷ lệ cố định nào đó trong tổng giá trị của tất cả các token. Do đó, để đạt được mức độ bảo mật hợp lý trước những người chơi độc hại đòi hỏi phải đặt cọc ít nhất một tỷ lệ cố định trong tổng số token. Tỷ lệ cố định chính xác được yêu cầu bởi các nền tảng khác nhau sẽ khác nhau tùy thuộc vào khả năng thao túng, giá trị của mã thông báo và tính thanh khoản của nó, tỷ lệ bị khóa và tính chất của khóa. Tuy nhiên, đối với bất kỳ nền tảng cụ thể nào, tỷ lệ mã thông báo được đặt cược có thể được coi là một chỉ báo đại diện cho mức độ bảo mật đạt được. Dựa trên kinh nghiệm, như có thể thấy trong Bảng 1, tỷ lệ cam kết của các nền tảng chính là khoảng từ 20% đến 70%²⁵, trong đó nền tảng lớn nhất thường có tỷ lệ cam kết thấp nhất.

**Tỷ lệ mã thông báo được đặt cược trong nền tảng bằng chứng cổ phần ít nhất phải là một hằng số liên quan đến nền tảng và khi tỷ lệ đặt cược tăng lên thì tính bảo mật cũng tăng lên. **

Dựa trên ước tính về mức độ bảo mật cần thiết và ước tính phần thưởng bắt buộc hiện tại dành cho người đặt cược, chúng tôi có thể tính toán tỷ lệ đúc tiền được yêu cầu²⁶. Lấy mức trung bình trong Bảng 1 làm ví dụ: Giả sử rằng người đặt cược yêu cầu lợi nhuận hàng năm là 5% và tỷ lệ đặt cược mà chúng tôi muốn đạt được là 50%. Khi đó tỷ lệ đúc hàng năm cần thiết được tính theo công thức là 2,5% (50%*5%). Loại tính toán này là tĩnh, giả sử cả phần thưởng đặt cược bắt buộc và tỷ lệ đặt cược bắt buộc đều cố định.

Hãy xem cách tính toán này được thực hiện trong giao thức. Nói chung, giao thức xác định tỷ lệ đúc bằng cách đặt "phần thưởng khối". Sau đó, các bên liên quan có thể quyết định có nên đặt cược mã thông báo của họ hay không và sau đó các mã thông báo mới được đúc về cơ bản sẽ được phân phối giữa các bên đặt cược, cung cấp cho họ phần thưởng đặt cược. Chúng tôi chắc chắn có thể giả định rằng tỷ lệ phần thưởng đặt cược càng cao thì càng có nhiều người đặt cược quyết định đặt cược mã thông báo của họ. Do đó, tỷ lệ đặt cược sẽ tự điều chỉnh cho đến khi đạt được phương trình trên: nếu tỷ lệ đặt cược thấp hơn phương trình yêu cầu thì mỗi người đặt cược sẽ nhận được phần thưởng cao hơn “nhu cầu” nên sẽ có nhiều người đặt cược tham gia đặt cược hơn. Nếu tỷ lệ đặt cược quá cao, phần thưởng quá thấp và người đặt cược sẽ rời đi. Sự cân bằng chỉ có thể thực hiện được khi tỷ lệ đặt cược mang lại phần thưởng đặt cược phù hợp với nhu cầu thị trường.

Ngoài ra, nếu môi trường tài chính thay đổi trong khi giao thức vẫn giữ nguyên, tỷ lệ đặt cược sẽ tự điều chỉnh. Ví dụ: nếu lãi suất bên ngoài tăng hoặc các mục đích sử dụng tài chính khác cho mã thông báo trong nền tảng trở nên hấp dẫn hơn, thì người đặt cược có thể yêu cầu phần thưởng cao hơn, điều này sẽ đạt được bằng cách giảm tỷ lệ đặt cược. Tương tự như vậy, nếu niềm tin vào tương lai của nền tảng tăng lên, người đặt cược sẽ yêu cầu ít phần thưởng hơn và do đó tỷ lệ đặt cược sẽ tăng lên.

Tất nhiên, nền tảng không nhất thiết phải chọn tỷ lệ truyền cố định "một lần và mãi mãi". Thay vào đó, nền tảng có thể quan sát tỷ lệ đặt cược hiện tại và sử dụng thông tin này để xác định tỷ lệ đúc. Cơ chế tỷ lệ đúc tiền năng động này cho phép kiểm soát chi tiết hơn sự cân bằng giữa tỷ lệ đặt cược và tỷ lệ đúc tiền như một chức năng của phần thưởng đặt cược bắt buộc được quan sát thấy từ hành vi của người đặt cược. Ví dụ: Ethereum xác định một đường cong trong đó tỷ lệ đúc tiền tăng tỷ lệ thuận với căn bậc hai của tỷ lệ đặt cược, do đó khiến tỷ lệ phần thưởng giảm tỷ lệ nghịch với căn bậc hai của tỷ lệ đặt cược. Một tùy chọn khác là giao thức động giúp tăng tốc độ đúc khi tỷ lệ đặt cược dưới mức mong muốn (và giảm tốc độ đúc khi tỷ lệ đặt cược cao hơn mức mong muốn). Trong cả hai trường hợp, trạng thái cân bằng sẽ chỉ đạt được khi tỷ lệ phần thưởng bằng với nhu cầu của người đặt cọc.

3.6.Tóm tắt: Kinh tế mã thông báo vĩ mô

Do đó, ý tưởng cốt lõi của phần này là nền tảng bằng chứng cổ phần có mã thông báo tiện ích sẽ trang trải mọi chi phí cố định của nền tảng bằng cách tạo ra các mã thông báo mới. Phần lớn chi phí cố định có thể là chi phí tài trợ cho khoản cam kết, tùy thuộc vào môi trường tài chính. Vì tính bảo mật của nền tảng phụ thuộc vào tỷ lệ đặt cược nên giao thức sẽ tạo đủ số token mới để đạt được mức độ bảo mật cần thiết.

* [1] Độc giả có thể tham khảo trang web * *stakerewards.com * * để biết định nghĩa của từng cột trong bảng. Do sự khác biệt khác nhau giữa các nền tảng, những con số này có thể cần phải được xem xét kỹ càng và nên được coi là mang tính biểu thị. *

• [2] Đây là những phần thưởng "thực sự" sau khi tính đến lạm phát mã thông báo (đúc tiền). Đối với mã thông báo được đúc ròng, phần thưởng được điều chỉnh thấp hơn phần thưởng ban đầu, trong khi đối với mã thông báo bị đốt ròng, phần thưởng được điều chỉnh sẽ cao hơn. *

• [3] Người ta có thể cố gắng xác định chính xác hơn loại phát triển nào là cần thiết để tăng cường niềm tin vào một nền tảng? Và giới hạn của hiệu ứng này là gì? Nhưng đối với mục đích của chúng tôi, chỉ cần giả định rằng các chỉ số liên quan sẽ cùng nhau tăng trưởng ít nhiều là đủ. *

• [4] Trừ khi có cơ chế nào khác làm giảm số lượng token. *

• [5] Tất cả các con số đều không đáng tin cậy do sự khác biệt về chi tiết nền tảng, vấn đề đo lường, sự hiện diện của mã thông báo bị khóa, v.v. *

• [6] Mặc dù Bitcoin rủi ro và “stablecoin” ổn định rất khác nhau về mục tiêu và hành vi, nhưng cả hai đều phục vụ một mục đích rõ ràng là “tiền” và do đó được phân loại theo cùng một cách ở đây. *

• [7] Như đã đề cập trước đó, mã thông báo bảo mật thể hiện các khiếu nại chống lại nhà phát hành đáng tin cậy. Người nắm giữ phải tin tưởng rằng tổ chức phát hành sẽ tôn trọng yêu cầu bồi thường hoặc yêu cầu thực thi yêu cầu bồi thường cụ thể. Ngược lại, mã thông báo tiện ích không phải là yêu cầu có hiệu lực pháp lý đối với một bên đáng tin cậy; nó là một đơn vị tài sản kỹ thuật số khan hiếm, theo các quy tắc của giao thức, có thể kích hoạt giao thức tự động cung cấp một số dịch vụ hữu ích. Khi các hệ thống này hoạt động như dự định, chủ sở hữu mã thông báo không cần phải tin tưởng vào bất kỳ nhà phát hành hoặc tòa án nào để nhận các dịch vụ từ giao thức. *

• [8] Chúng ta thường chấp nhận kiểu lập luận này trong các mô hình kinh tế vĩ mô. Nếu những người nắm giữ đồng đô la cực kỳ ích kỷ, họ sẽ không chấp nhận bất kỳ tỷ lệ lạm phát nào. Tuy nhiên, với sự hiểu biết chung rằng tỷ lệ lạm phát ổn định thường khuyến khích tiêu dùng và phát triển nền kinh tế, những người nắm giữ đồng đô la sẽ chấp nhận và thậm chí ủng hộ các chính sách lạm phát vì về lâu dài, những chính sách này dẫn đến kết quả phúc lợi cá nhân và xã hội tốt hơn. *

• [9] "Năng lực" của nền tảng thường được xác định theo thỏa thuận để đảm bảo rằng nhiều nhà khai thác có khả năng tính toán hợp lý có thể tham gia hoạt động. *

• [10] Nếu người đọc lo lắng rằng việc định giá theo chi phí cận biên không bao gồm chi phí cố định khi vận hành nền tảng và do đó không thể đảm bảo được thì bạn nên đưa ra quyết định sau khi đọc phần kinh tế mã thông báo vĩ mô, phần này sẽ đề xuất các nguồn trang trải các chi phí này. *

* [11] Chính xác hơn, chúng tôi có thể muốn coi giao dịch bị từ chối đầu tiên là i*, nhưng phân tích sơ bộ của chúng tôi ở đây coi các giao dịch này về cơ bản là giống nhau. *

• [12] Thuật toán này có thể được xem như là một cách xử lý gần đúng cho việc nới lỏng quy hoạch tuyến tính của bài toán tối ưu hóa. Khoảng cách của nó với giá trị tối ưu bị giới hạn bởi tỷ lệ của tổng công suất của giao dịch bị từ chối đầu tiên, do đó nó cung cấp một giá trị gần đúng tốt miễn là các giao dịch tương đối nhỏ so với tổng công suất. Giá gas đương nhiên có thể được coi là một biến kép của LP này. Bỏ qua ràng buộc số nguyên, khi S chứa giao dịch có giá trị vi/si cao nhất và ngưỡng được đặt ở g, ∑i∈S(vi-ci)=∑i∈S(vi-αsi) khi ∑i∈Ssi≤ K Sự tối đa hóa dưới những ràng buộc của thực sự xảy ra. *

• [13] Giả định của chúng tôi ở đây là chi phí hệ thống ci=αsi của một giao dịch không phải do nhà điều hành cụ thể quyết định khối chịu, mà được chia sẻ bởi các nhà điều hành tổng hợp và chi phí của nhà điều hành cụ thể là không đáng kể. Nếu không, cần có cơ chế “thích hợp” để đền bù cho người vận hành quyết định khối. *

• [14] Là phép tính gần đúng đầu tiên, giao thức EIP-1599 tự động tìm giá phát hành Gas rất gần với chi phí tắc nghẽn biên của khối tiếp theo. *

• [15] Nếu bạn muốn bắt đầu nghiên cứu tài liệu về lĩnh vực này, bài báo "Thiết kế cơ chế phí giao dịch" của Tim Roughgarden là một nơi tốt để bắt đầu. *

• [16] Tuy nhiên, nếu chi phí ùn tắc đủ lớn thì những chi phí này (là một phần của phí, nhưng không phải là chi phí thực sự do nhà điều hành nền tảng gánh chịu) ít nhất có thể trang trải một phần chi phí cố định. Ở một mức độ nào đó, điều này đang xảy ra ở Ethereum. *

• [17] Có lẽ một ngoại lệ gây tranh cãi là các dự án công do chính phủ tài trợ, có thể được tài trợ bằng tiền vay, được đảm bảo hiệu quả dựa trên niềm tin vào tăng trưởng kinh tế và tăng thuế trong tương lai. *

• [18] Nếu chúng ta sử dụng r để biểu thị tốc độ truyền và g để biểu thị tốc độ tăng trưởng của nền tảng, thì miễn là r, việc thanh toán chi phí cố định thông qua truyền là bền vững. *

• [19] Tùy thuộc vào cơ chế tính phí được sử dụng, các khoản phí tắc nghẽn này có thể được thanh toán trực tiếp cho nhà điều hành và trang trải chi phí của họ hoặc chúng có thể bị đốt cháy để bù đắp cho phí đúc tiền mới. *

• [20] Tuy nhiên, chúng tôi thường mong đợi rằng những người vận hành "ký" các khối sẽ thực sự kiểm tra những người dẫn đầu này và xác minh rằng các khối đó là chính xác, điều mà chúng tôi có thể cần khuyến khích và về vấn đề này, chúng tôi vẫn cần nỗ lực. Trong một số hệ thống, điều này có thể không tầm thường ở cấp độ kinh tế vi mô, nhưng từ góc độ kinh tế vĩ mô, nó dường như không tạo thành một hạn chế đáng kể. *

• [21] Giống như một ví dụ cụ thể, phép tính sau đây có thể đóng vai trò là điểm khởi đầu rất đơn giản cho các phép tính như vậy: Giả sử rằng nền tảng này dự kiến sẽ tăng trưởng g% mỗi năm, tỷ lệ đúc tiền dự kiến là r%, lãi suất thực bên ngoài là R% và dự kiến phần thưởng rủi ro cho việc đặt cược mã thông báo được ước tính là y%, khi đó chúng tôi có thể kỳ vọng rằng phần thưởng đặt cược bắt buộc là (R-g+r+y)%. Những tính toán tài chính thực tế hơn đương nhiên sẽ nhấn mạnh đến việc mô hình hóa phần bù rủi ro và tốc độ tăng trưởng. *

• [22] Khi có chi phí cố định đáng kể ngoài chi phí vốn, những chi phí này cũng phải được chi trả bằng các token mới được đúc và thỏa thuận phải cung cấp các phương tiện để đạt được điều này. Phương trình trên sẽ được sửa đổi bằng cách thêm các thuật ngữ thích hợp để giá đúc cũng bao gồm các chi phí này. *

• [23] Khi "nhóm cầm cố" tập trung sức mạnh của nhiều người cầm cố độc lập, giả định này có thể hơi quá lạc quan, mặc dù những người cầm cố riêng lẻ có thể không có ác ý, nhưng bản thân nhóm cầm cố có thể là một sự tồn tại độc hại vào thời điểm này. *

• [24] Trong một số nền tảng, một tỷ lệ lớn các bên độc hại có thể chỉ đơn giản là "đánh cắp tất cả mã thông báo từ mọi người", trong khi trong các trường hợp khác, chỉ những kế hoạch phức tạp hơn mới có thể mang lại lợi ích đáng kể như vậy. Ví dụ: ngay cả khi phần lớn các bên độc hại chỉ đơn giản là tắt hệ thống một cách hiệu quả, điều này có thể mang lại lợi ích đáng kể bằng cách rút ngắn mã thông báo bên ngoài nền tảng (nếu có thể). *

• [25] Ví dụ: những con số này nên được coi là muối bỏ bể vì trong một số trường hợp, có những mã thông báo “bị khóa” chỉ có thể được sử dụng để đặt cược. *

• [26] Nếu giao thức cũng liên quan đến việc đốt mã thông báo thì việc đốt mã thông báo này cần phải được tính đến khi xem xét tỷ lệ đúc ròng. *