Cơ chế phân bổ không gian khối - Đồng tác giả bởi các nhà nghiên cứu Ethereum và a16z
Tuyển chọn TechFlowTuyển chọn TechFlow
Cơ chế phân bổ không gian khối - Đồng tác giả bởi các nhà nghiên cứu Ethereum và a16z
Cơ chế phân bổ không gian khối ảnh hưởng đến MEV như thế nào?
Chuyên sâu báo cáo Web3Tác giả: mike, nhà nghiên cứu Ethereum; Pranav Garimidi, Tim Roughgarden, các nhà nghiên cứu tại a16z
Biên dịch: 0XNATALIE
Bài viết "On block-space distribution mechanisms" do các nhà nghiên cứu Ethereum mike và các nhà nghiên cứu a16z Pranav Garimidi, Tim Roughgarden đồng tác giả đã hệ thống hóa việc khám phá cách thức cơ chế phân bổ không gian khối ảnh hưởng đến MEV. Trước tiên bài viết trình bày tính cần thiết của việc giới thiệu cơ chế nội giao thức để xử lý việc phân bổ không gian khối, sau đó sử dụng khung hỏi đáp "Ai, Cái gì, Khi nào, Ở đâu, Như thế nào" (W^4H) để đánh giá và so sánh các phương án phân bổ hiện có, tiếp theo đi sâu phân tích mô hình vé thực thi (execution tickets) đạt được cân bằng giữa độ nhạy MEV và công bằng trong phân bổ. Dưới đây là bản dịch bài viết này.
Tóm tắt nhanh: Không gian khối, tức dung lượng chứa giao dịch, là tài nguyên chính mà blockchain tạo ra. Khi hệ sinh thái mã hóa mở rộng và chuyên biệt hóa, giá trị phát sinh từ việc sử dụng hiệu quả không gian khối (MEV) đóng vai trò quan trọng trong kinh tế học của cơ chế đồng thuận không cần cho phép. Cộng đồng nghiên cứu đã viết rất nhiều bài về việc giao thức nên xử lý MEV như thế nào (xem phần công trình liên quan). Cuộc thảo luận vài năm gần đây giống như câu chuyện "sờ voi trong bóng tối", đưa ra nhiều quan điểm, giải pháp và lý thuyết khác nhau, nhưng mỗi góc nhìn dường như rời rạc, khó so sánh với nhau. Nửa đầu bài viết nhằm mục đích phác họa bức tranh tổng thể về "con voi MEV" bằng cách tinh lọc một loạt câu hỏi cốt lõi và khám phá cách các đề xuất hiện tại ứng phó với những câu hỏi này. Nửa sau tập trung vào cơ chế phân bổ được kích hoạt bởi vé thực thi, minh họa một hiểu biết mới quan trọng—có sự đánh đổi giữa chất lượng của oracle MEV nội giao thức và tính công bằng của cơ chế.
Cấu trúc bài viết: Mục 1 trình bày lý do vì sao cần cơ chế nội giao thức để xử lý việc phân bổ không gian khối như một phần của "tình trạng cuối cùng" Proof-of-Stake. Mục 2 liệt kê năm chiều kích có thể dùng để đo lường cơ chế phân bổ không gian khối, sử dụng bộ câu hỏi quen thuộc: Ai, Cái gì, Khi nào, Ở đâu, Như thế nào (gọi tắt là các câu hỏi W^4H). Mục 3 tìm hiểu cách chọn người xây dựng khối, tập trung vào mô hình vé thực thi. Mục 4 triển khai thảo luận thông qua tổng kết và đặt ra các câu hỏi mở tiếp theo.
Lưu ý: Bài viết này khá dài, chứa một số yếu tố kỹ thuật. Chúng tôi khuyến khích bạn đọc tập trung vào phần bài viết mà bạn quan tâm nhất. Các mục 1, 2 và 4 cung cấp cái nhìn tổng quát về các đề xuất hiện tại và phương pháp phân tích chúng tôi đề xuất. Mục 3 (chiếm khoảng 44% toàn văn, nhưng chứa 100% nội dung toán học) cung cấp phân tích chi tiết về cơ chế phân bổ được kích hoạt bởi thiết kế vé thực thi. Phần này có thể đọc tuần tự, đọc độc lập hoặc hoàn toàn bỏ qua—do bạn quyết định!
(1) Động lực
Trước khi đi sâu vào chủ đề phức tạp này, hãy làm rõ ngắn gọn về tính cần thiết của cơ chế phân bổ không gian khối. Trong Proof-of-Stake, nhiệm vụ của các trình xác thực là tạo và bỏ phiếu cho khối. Hình dưới đây lấy từ bài viết của Barnabé "More pictures about proposers and builders", mô tả chúng như quyền đề xuất (proposing) và quyền chứng thực (attesting).
1) Cái gì
Cơ chế phân bổ không gian khối là quá trình giao thức quyết định ai sở hữu quyền "đề xuất" hay "xây dựng khối". Giao thức Proof-of-Stake thường sử dụng một trong các quy tắc sau:
-
Quyền không gian khối (quyền đề xuất) – Chọn ngẫu nhiên một trình xác thực làm người lãnh đạo, cho phép nó tạo khối tiếp theo.
-
Quyền bỏ phiếu (chứng thực) – Tất cả các trình xác thực trong một cửa sổ thời gian nhất định bỏ phiếu cho khối mà họ cho là khối gốc chính thống.
Các trình xác thực nhận phần thưởng vì thực hiện các nhiệm vụ này. Chúng tôi phân loại dựa trên nguồn gốc phần thưởng thành lớp đồng thuận (phát hành giao thức, ví dụ ETH đúc mới) hoặc lớp thực thi (phí giao dịch và MEV):
Lớp đồng thuận
a. Phần thưởng chứng thực – (xem attestation deltas).
b. Phần thưởng khối – (xem get_proposer_reward).
Lớp thực thi
a. Phí giao dịch – (xem gas tracker).
b. MEV (sắp xếp giao dịch) – (xem mevboost.pics).
Các phần thưởng 1a, 1b và 2a là nổi tiếng và "trong tầm nhìn giao thức". Phần thưởng MEV thì thách thức hơn, vì việc nắm bắt hoàn toàn giá trị tạo ra qua sắp xếp giao dịch là rất khó. Khác với các phần thưởng khác, lượng MEV trong một khối thực tế là không thể biết được (do là hệ thống không cần cho phép và ẩn danh, không thể theo dõi ai kiểm soát từng tài khoản và bất kỳ hoạt động bên ngoài chuỗi nào phối hợp kiếm lợi nhuận). MEV cũng thay đổi mạnh theo thời gian (ví dụ, biến động giá), dẫn đến phần thưởng lớp thực thi có phương sai lớn hơn phần thưởng lớp đồng thuận. Ngoài ra, giao thức Ethereum khi triển khai không có khả năng quan sát MEV mà giao dịch của nó tạo ra và khai thác. Để tăng khả năng nhìn thấy MEV của giao thức, nhiều cơ chế cố gắng ước tính MEV trong một khối nhất định, chúng tôi gọi là oracle MEV. Cơ chế phân bổ không gian khối thường có khả năng tạo ra oracle như vậy, khiến giao thức "nhận thức được MEV".
Điều này đặt ra câu hỏi, tại sao giao thức lại quan tâm đến việc nhận thức MEV? Một câu trả lời là: Nhận thức MEV có thể làm tăng khả năng của giao thức duy trì sự bình đẳng phần thưởng khi các trình xác thực có mức độ phức tạp khác nhau. Ví dụ, nếu giao thức có thể đốt cháy chính xác toàn bộ MEV, thì động lực của các trình xác thực sẽ hoàn toàn nằm trong tầm nhìn giao thức (giống như 1a, 1b và 2a ở trên). Hoặc, một cơ chế chia sẻ toàn bộ MEV giữa các trình xác thực bất kể mức độ phức tạp của họ (ví dụ, mev-smoothing) dường như sẽ thúc đẩy một tập hợp trình xác thực lớn hơn, đa dạng hơn và phi tập trung hơn, đồng thời giữ phần thưởng MEV như một động lực bổ sung cho việc stake. Nếu không có nhận thức MEV, những trình xác thực giỏi nhất trong việc khai thác hoặc san bằng MEV (ví dụ, do mối quan hệ với người xây dựng khối, thuật toán/phần mềm độc quyền, quyền truy cập vào dòng đơn hàng độc quyền và lợi thế kinh tế nhờ quy mô) có thể nhận được phần thưởng cao bất thường và gây áp lực tập trung đáng kể lên giao thức.
Thiết kế giao thức Ethereum nỗ lực giữ tập hợp trình xác thực phi tập trung bằng mọi giá. Điều này không cần nói, nhưng để đầy đủ: Tính trung lập đáng tin cậy, chống kiểm duyệt và không cần cho phép của giao thức trực tiếp phụ thuộc vào tập hợp trình xác thực phi tập trung.
Phân bổ không gian khối hiện tại
Ngày nay trên Ethereum, mev-boost chiếm khoảng 90% khối. Với mev-boost, người đề xuất (trình xác thực lãnh đạo được chọn ngẫu nhiên) bán quyền xây dựng khối của họ cho người đấu giá cao nhất. Hình dưới đây minh họa quy trình này (chúng tôi loại trừ các trung gian vì thực tế chúng là phần mở rộng của người xây dựng).
Người đề xuất có động lực thuê ngoài việc xây dựng khối vì người xây dựng (các đại lý chuyên sắp xếp giao dịch để khai thác MEV) trả cho họ nhiều hơn những gì họ có thể kiếm được nếu tự xây dựng khối. Quay lại mục tiêu của chúng ta là "duy trì sự bình đẳng phần thưởng cho trình xác thực trong bối cảnh tồn tại MEV", chúng ta thấy mev-boost cho phép tất cả các trình xác thực tham gia thị trường người xây dựng, thực tế giữ phần thưởng MEV gần như tương đương giữa người stake độc lập và nhà cung cấp dịch vụ stake chuyên nghiệp—tốt! Nhưng…
Tất nhiên, mev-boost có một số vấn đề, vẫn khiến một số thành viên cộng đồng Ethereum lo ngại. Tóm lại, đây là một số tác dụng phụ tiêu cực của việc dùng thuốc mev-boost:
-
Các trung gian – Những bên thứ ba đáng tin cậy này môi giới việc bán khối giữa người đề xuất và người xây dựng. Sự phụ thuộc lớn vào các trung gian làm tăng tính dễ tổn thương tổng thể của giao thức, như đã thấy qua các sự kiện lặp lại, liên quan đến trung gian. Hơn nữa, do các trung gian không có nguồn thu nhập nội tại, đang triển khai thêm các phương pháp (và mã nguồn đóng) để thu lợi nhuận (ví dụ, trò chơi thời gian như một dịch vụ và điều chỉnh giá thầu).
-
Dễ bị tổn thương do phần mềm ngoài giao thức – Ngoài các trung gian, việc tham gia thị trường mev-boost yêu cầu các trình xác thực chạy thêm phần mềm. Bộ công cụ tiêu chuẩn cho việc stake độc lập giờ đây liên quan đến việc chạy bốn tệp nhị phân: (i) nút beacon đồng thuận, (ii) khách hàng trình xác thực đồng thuận, (iii) khách hàng thực thi, và (iv) mev-boost. Đối với người stake độc lập, điều này không chỉ làm tăng đáng kể chi phí, mà sự phụ thuộc vào các phần mềm này cũng tạo ra một điểm lỗi tiềm tàng khác trong thời gian nâng cấp hard fork. Xem sự kiện Shapella và nâng cấp Dencun để hiểu rõ hơn về sự phức tạp do phần mềm ngoài giao thức gây ra.
-
Tập trung hóa người xây dựng và kiểm duyệt – Mặc dù điều này có thể là không tránh khỏi, nhưng việc áp dụng mev-boost trên diện rộng đã đẩy nhanh quá trình tập trung hóa người xây dựng. Ba người xây dựng chiếm khoảng 95% khối mev-boost (chiếm 85% tổng số khối Ethereum). mev-boost triển khai đấu giá công khai, giá thầu đầu tiên, người thắng nhận hết, dẫn đến mức độ tập trung hóa người xây dựng cao và việc thầu chiến lược. Danh sách bao gồm hoặc các công cụ chống kiểm duyệt khác chưa được triển khai, người xây dựng có ảnh hưởng lớn đến việc bao gồm hoặc loại trừ giao dịch—(xem censorship.pics).
-
Trò chơi thời gian – Mặc dù trò chơi thời gian được coi là một vấn đề cơ bản của giao thức Proof-of-Stake, mev-boost thúc đẩy các nhà cung cấp dịch vụ stake cạnh tranh mỏng manh. Ngoài ra, các trung gian (đại diện cho người đề xuất trong đấu giá mev-boost) đóng vai trò là trung gian phức tạp, thúc đẩy trò chơi thời gian. Do đó, chúng ta thấy các chiến dịch tiếp thị khuyến khích tăng lợi nhuận bằng cách stake với nhà cung cấp cụ thể.
(2) Liệt kê
Sau phần "dàn dựng sân khấu" cần thiết, hãy xem xét kỹ hơn bản chất của cơ chế phân bổ không gian khối.
Các yếu tố của việc phân bổ không gian khối
Hãy xem xét trò chơi giành quyền truy cập vào không gian khối; MEV khuyến khích các đại lý tham gia, trong khi sự kết hợp giữa phần mềm nội và ngoại giao thức định nghĩa luật chơi. Khi thiết kế trò chơi này, cần cân nhắc những yếu tố nào? Để trả lời câu hỏi này, chúng tôi sử dụng mô hình tu từ quen thuộc "Ai, Cái gì, Khi nào, Ở đâu, Như thế nào" (hy vọng mục 1 đã đủ trả lời cho "Tại sao"), chúng tôi gọi là các câu hỏi W^4H.
-
Ai kiểm soát kết quả trò chơi?
-
Cái gì là hàng hóa mà người chơi tranh giành?
-
Khi nào trò chơi diễn ra?
-
Oracle MEV đến từ đâu?
-
Làm thế nào để chọn người xây dựng khối?
Những câu hỏi này dường như quá đơn giản, nhưng khi xem xét riêng biệt, mỗi câu hỏi có thể được coi là một trục đo lường không gian thiết kế cơ chế. Để minh họa điều này, chúng tôi nhấn mạnh một số loại cơ chế phân bổ không gian khối khác nhau đã được khám phá trước đây. Mặc dù chúng có vẻ không liên quan, nhưng qua việc hiểu cách chúng trả lời các câu hỏi W^4H, mối quan hệ giữa chúng trở nên rõ ràng.
Vé thực thi và các phương pháp khác
Chúng tôi trình bày sơ đồ của nhiều cơ chế đề xuất khác nhau. Lưu ý rằng đây chỉ là một tập con của tài liệu khá lớn xung quanh các thiết kế này—(xem infinite buffet). Đối với từng cái dưới đây, chúng tôi chỉ tóm tắt ý tưởng chính (xem phần công trình liên quan để biết chi tiết).
Vé thực thi
Ý tưởng chính: Quyền xây dựng khối và đề xuất được bán trực tiếp thông qua "vé" do giao thức phát hành. Người sở hữu vé được chọn ngẫu nhiên làm người xây dựng khối, được thông báo trước. Người sở hữu vé có quyền sản xuất khối trong khoảng thời gian được phân bổ.
PBS đấu giá khối (Phân tách Người đề xuất - Người xây dựng)
Ý tưởng chính: Giao thức trao quyền sản xuất khối thông qua quá trình bầu chọn lãnh đạo ngẫu nhiên. Trình xác thực được chọn có thể bán trực tiếp khối của họ cho thị trường người xây dựng hoặc tự xây dựng tại chỗ. Người xây dựng phải cam kết một khối cụ thể trong đấu giá. mev-boost là phiên bản ngoài giao thức của PBS đấu giá khối; như ban đầu đề xuất, ePBS là phiên bản tương đương trong giao thức.
Đốt MEV / San bằng MEV
Ý tưởng chính: Một ủy ban chịu trách nhiệm đặt mức giá thầu tối thiểu trên giá thầu mà người đề xuất chọn trong đấu giá. Bằng cách yêu cầu người đề xuất chọn giá thầu "đủ lớn", tạo ra một oracle MEV. MEV hoặc được san bằng giữa các thành viên ủy ban hoặc bị đốt (san bằng cho tất cả người nắm giữ ETH).
PBS đấu giá khe thời gian (slot)
Ý tưởng chính: Tương tự PBS đấu giá khối, nhưng thay vì bán khe cho thị trường người xây dựng mà không cần cam kết khối cụ thể—đôi khi gọi là tương lai không gian khối. Bằng cách không yêu cầu người xây dựng cam kết khối cụ thể, các khe tương lai có thể được đấu giá sớm, thay vì chờ đến khe đó.
Đấu giá khối một phần
Ý tưởng chính: Cho phép bán các đơn vị linh hoạt hơn của không gian khối. Thay vì bán toàn bộ khối hoặc khe, cho phép người đề xuất bán _một phần_ khối của họ, ví dụ, đỉnh khối (có giá trị nhất đối với các nhà arbitrage), trong khi giữ lại phần còn lại để tự xây dựng. Đang hoạt động trên các mạng Proof-of-Stake khác, ví dụ như động cơ khối Jito và làn MEV Skip.
APS Đấu giá thực thi bằng cách đốt
Ý tưởng chính: Đề xuất mới từ Barnabé, buộc người đề xuất đấu giá trước quyền xây dựng và đề xuất khối. Khe được bán trước (thời gian cố định), không cần cam kết khối cụ thể; một ủy ban (giống như đốt/san bằng MEV) đảm bảo giá thầu đủ lớn.
Bằng cách so sánh cách các đề xuất này trả lời các câu hỏi W^4H, chúng ta có thể thấy chúng là những phần khác nhau trong cùng một không gian thiết kế.
Áp dụng W^4H: Phân tích so sánh
Đối với từng câu hỏi W^4H, chúng tôi mô tả các điểm đánh đổi khác nhau trong các đề xuất trên. Để ngắn gọn, chúng tôi sẽ không phân tích từng đề xuất ứng với từng câu hỏi, mà tập trung vào những khác biệt then chốt mang lại bởi từng luồng câu hỏi.
Ai kiểm soát kết quả trò chơi?
-
Trong cơ chế vé thực thi, giao thức quyết định người thắng bằng cách chọn ngẫu nhiên người sở hữu vé.
-
Trong PBS đấu giá khối, người đề xuất (lãnh đạo được giao thức chọn) đơn phương chọn người thắng.
-
Trong cơ chế đốt MEV, người đề xuất vẫn chọn người thắng, nhưng giá thầu chiến thắng bị ủy ban giới hạn, giảm bớt quyền tự chủ của người đề xuất.
Cuộc tranh giành là gì?
-
Trong PBS đấu giá khối, toàn bộ khối được bán, nhưng giá thầu phải cam kết nội dung khối.
-
Trong PBS đấu giá khe, toàn bộ khối được bán, nhưng không cần cam kết nội dung khối cụ thể.
-
Trong PBS khối một phần, chỉ một phần khối được bán.
Trò chơi diễn ra khi nào?
-
Trong PBS đấu giá khối, đấu giá diễn ra trong suốt khe.
-
Trong PBS đấu giá khe, đấu giá có thể diễn ra trước nhiều khe (ví dụ 32 khe), do không cần cam kết nội dung khối.
-
Trong cơ chế vé thực thi, vé được phân bổ cho khe với thời gian trước cố định.
Oracle MEV đến từ đâu?
-
Trong cơ chế đốt/san bằng MEV, ủy ban buộc giá thầu được chọn phải đủ lớn, giá thầu này chính là oracle.
-
Trong cơ chế vé thực thi, tổng chi phí cho vé được dùng làm oracle.
Làm thế nào để chọn người xây dựng khối?
-
Trong PBS đấu giá khối, mọi việc sản xuất khối được thuê ngoài đều là phân bổ người thắng nhận hết, người thầu cao nhất nhận quyền xây dựng khối.
-
Trong cơ chế vé thực thi, có thể thực hiện nhiều cơ chế phân bổ khác nhau. Ví dụ, trong đề xuất ban đầu, vé được chọn ngẫu nhiên, cơ chế là "phân bổ theo tỷ lệ số vé"; trong trường hợp này, người thầu cao nhất (người sở hữu nhiều vé nhất) chỉ có xác suất được chọn cao nhất, chứ không đảm bảo nhận quyền xây dựng khối.
Nếu nội dung trên có vẻ khó hiểu, đừng lo lắng. Phần tiếp theo sẽ đi sâu vào các cơ chế phân bổ khác nhau này.
Ôn lại động lực
Trước khi tiếp tục, hãy ôn lại động lực ban đầu của chúng ta:
Cơ chế phân bổ không gian khối nhằm mục đích duy trì tính đồng nhất phần thưởng cho trình xác thực trong bối cảnh tồn tại MEV.
Đó là một nền tảng tốt, nhưng nếu đây là mục tiêu duy nhất của chúng ta, tại sao không tiếp tục dùng mev-boost? Hãy nhớ rằng, mev-boost có một số tác động tiêu cực, có thể cần giao thức cuối cùng chúng ta thiết kế phải có khả năng kháng lại. Chúng tôi nhấn mạnh bốn mục tiêu thiết kế tiềm năng khác cho cơ chế phân bổ không gian khối:
-
Khuyến khích cạnh tranh rộng rãi hơn giữa các người xây dựng.
-
Cho phép tương tác đáng tin cậy giữa trình xác thực và người xây dựng.
-
Tích hợp nhận thức MEV vào giao thức lớp nền tảng.
-
Loại bỏ hoàn toàn MEV khỏi phần thưởng trình xác thực.
Lưu ý rằng mặc dù (1, 2, 3) tương đối không gây tranh cãi, (4) lại gây tranh cãi hơn (và cần (3) làm điều kiện tiên quyết). Giao thức có thể muốn loại bỏ phần thưởng MEV để đảm bảo phần thưởng lớp đồng thuận (phần do giao thức kiểm soát) phản ánh chính xác hơn toàn bộ động lực hệ thống. Điều này cũng liên quan đến vĩ mô kinh tế stake và việc phát hành giao thức—đây là cuộc thảo luận mang tính chính trị hơn. Mặt khác, phần thưởng MEV là sản phẩm phụ của việc sử dụng mạng; MEV có thể được coi là cơ chế thu giữ giá trị cho token gốc. Chúng tôi không cố gắng giải quyết những vấn đề này ở đây, mà khám phá cách các câu trả lời khác nhau ảnh hưởng đến thiết kế cơ chế như thế nào.
Chúng ta có thể làm gì ở cấp độ thiết kế giao thức để phù hợp với những mong đợi này? Như đã nêu, có nhiều điểm đánh đổi cần cân nhắc, nhưng trong phần tiếp theo, chúng ta sẽ khám phá "Làm thế nào để chọn người xây dựng khối?" để cải thiện ở một số khía cạnh.
(3) Đặt câu hỏi
Ghi chú biên tập: Như đã đề cập trước đó, phần này dài và kỹ thuật hơn các phần khác—nếu bạn giới hạn về thời gian (hoặc hứng thú), có thể nhảy thẳng đến mục 4.
Mục tiêu phụ: Minh họa sự đánh đổi định lượng giữa chất lượng oracle MEV và tính công bằng của cơ chế giữa hai phương pháp phân bổ quyền đề xuất khối quen thuộc nhất (chúng tôi gọi là «trả toàn bộ theo tỷ lệ» (Proportional-all-pay) và «người thắng nhận hết» (Winner-take-all)).
Chúng tôi dự định đạt được mục tiêu này thông qua các phần nhỏ sau:
Kiến thức cơ bản
Trước khi đi sâu vào các cơ chế phân bổ mà vé thực thi có thể thực hiện, chúng ta phải thiết lập mô hình trước. Xét một giao thức, bán vé thực thi theo quy tắc sau:
-
Giá cố định là 1 WEI, và
-
Có thể mua và bán vé với số lượng không giới hạn.
Lưu ý: Phiên bản vé thực thi này thực tế tương đương với việc tạo ra hai cơ chế stake độc lập—một cho việc chứng thực, một cho việc đề xuất. Những thay đổi nhỏ trong thiết kế, ví dụ như không cho phép bán lại vé cho giao thức, có thể ảnh hưởng lớn đến hoạt động thị trường, nhưng không phải trọng tâm bài viết này. Chúng tôi chỉ thu hẹp phạm vi khám phá vấn đề phân bổ không gian khối trong bối cảnh tập hợp người sở hữu vé đã có.
Đáng chú ý, từ góc nhìn giao thức, người sản xuất khối và người chứng thực là cá thể độc lập—cá nhân phải chọn tham gia phần nào của giao thức, bằng cách quyết định stake hay mua vé. Thị trường vé thứ cấp có thể phát triển thành nơi mua bán quyền xây dựng kịp thời trên thị trường đấu giá (giống như mev-boost ngày nay).
Hơn nữa, người xây dựng có thể chọn tương tác trực tiếp với giao thức, mua vé thực thi, nhưng vốn của họ có thể phù hợp hơn với tư cách thanh khoản hoạt động, bắt lợi arbitrage giữa các sàn giao dịch. Vì vậy, họ có thể sẵn sàng mua không gian khối trên thị trường thứ cấp tại thời điểm đấu giá.
Tại sao chúng ta lại giới hạn trong cơ chế phát hành giá cố định cung ứng vô hạn này? Hai lý do:
1. Không rõ liệu một thị trường phức tạp có thể được thực hiện ở lớp đồng thuận hay không. Việc tối ưu hóa client khiến bất kỳ trình xác thực nào có phần cứng tiêu dùng đều có thể tham gia mạng. Yêu cầu này có thể không tương thích với đấu giá nhanh, đường cong ràng buộc hoặc các cơ chế bán vé tiềm năng khác. Các vấn đề về số lượng vé bán ra, MEV chứa trong việc bán vé trên chuỗi (meta MEV?!), và thời gian bán vé (và trò chơi thời gian) dường như gần với các vấn đề lớp thực thi hơn là điều mà đồng thuận Ethereum có thể hợp lý thực hiện, đồng thời duy trì yêu cầu phần cứng hạn chế.
«Có thể hình dung việc bao gồm các giao dịch liên quan đến thị trường ET có thể gây ra MEV, bất kể các giao dịch này được bao gồm trong khối beacon hay tải trọng thực thi.» ——Barnabé trong «More pictures about proposers and builders».
2. Ngay cả khi (một giả định lớn) giao thức có thể triển khai một thị trường vé chặt chẽ hơn, không gian thiết kế cơ chế là rất lớn. Nhiều cơ chế định giá tiềm năng đã được thảo luận, ví dụ, đường cong ràng buộc, định giá động kiểu 1559, đấu giá, v.v.; đưa ra tuyên bố tổng quát về những cái này vượt quá phạm vi bài viết này.
Do đó, chúng tôi tập trung vào phiên bản vé thực thi «vô hạn, giá cố định 1 WEI», trong đó độ phức tạp nội hóa vào giao thức là tối thiểu. Trong khuôn khổ này, chúng ta có thể đặt câu hỏi có lẽ đang cháy bỏng trong bạn, «cho trước một tập hợp người sở hữu vé thực thi, làm thế nào để chọn người thắng?»…… nghe có vẻ đơn giản, đúng không? Hóa ra, ngay cả một câu hỏi dường như đơn giản như vậy, chúng ta cũng có nhiều điều để nói; hãy khám phá một vài lựa chọn khác nhau.
x:b→[0,1]n ∑ixi(b)=1 p:b→Rn≥0
Mô hình
Xét trò chơi lặp lại việc giành phần thưởng MEV thông qua việc mua vé thực thi:
-
Mỗi chu kỳ, mỗi người chơi nộp một giá thầu, biểu thị số lượng vé họ mua. Dùng vectơ b biểu thị giá thầu, trong đó bi là giá thầu của người chơi thứ i.
-
Mỗi người chơi có một định giá cho việc thắng quyền sản xuất khối. Dùng vectơ v biểu thị định giá, trong đó vi là định giá của người chơi thứ i.
-
Mỗi bước thời gian, một cơ chế phân bổ quyết định phân bổ cho mỗi người chơi dựa trên vectơ giá thầu. Giả sử các người thầu trung lập rủi ro, chúng ta có thể nói tương đương rằng mỗi người được phân bổ «một phần khối», điều này cũng có thể được hiểu là «xác suất thắng một khối nào đó». Trong trò chơi n người chơi, dùng x: b →[0,1]^n biểu thị ánh xạ thực hiện cơ chế phân bổ, trong đó xi(b) là phân bổ của người chơi thứ i, với ràng buộc ∑ixi(b)=1 (tức là cơ chế phân bổ hoàn toàn).
-
Việc thanh toán của mỗi người chơi được thu mỗi vòng. Dùng p: b →Rn≥0 biểu thị quy tắc thanh toán xác định theo tập giá thầu, trong đó pi(b) là khoản thanh toán của người chơi thứ i.
-
Hàm tiện ích của trò chơi cho mỗi người chơi được định nghĩa là Ui(b) = vi xi(b) - pi(b), tức là tiện ích người chơi bằng giá trị thắng khối nhân với phần nhận được trừ đi khoản thanh toán
Các cơ chế phân bổ quen thuộc
Xét hai cơ chế khả thi (hoàn toàn khác nhau).
Toàn bộ theo tỷ lệ (biến thể nhỏ từ đề xuất vé thực thi ban đầu)
-
Trong suốt mỗi vòng, tất cả người chơi nộp giá thầu. Dùng vectơ b biểu thị giá thầu.
-
Xác suất thắng trò chơi bằng giá thầu chia cho tổng tất cả giá thầu
Mỗi người chơi phải thanh toán giá thầu của họ bất kể kết quả trò chơi (do đó gọi là «toàn bộ»), pi(b) = bi.
Người thắng nhận hết (triển khai hiện tại của PBS)
-
Trong suốt mỗi vòng, tất cả người chơi nộp giá thầu. Dùng vectơ b biểu thị giá thầu.
-
Người thầu cao nhất thắng trò chơi, do đó x_i(b) = 1, nếu max(b) = bi và xi(b) = 0 (ví dụ, ưu tiên người thầu thấp hơn trong trường hợp hòa).
-
Chỉ người thắng thanh toán giá thầu của họ, do đó pi(b) = bi, nếu max(b) = bi và pi(b) = 0 (cũng xử lý hòa tương tự).
So sánh kết quả
Để minh họa kết quả khác nhau của hai cơ chế này, hãy xét một trò chơi hai người chơi, trong đó người chơi 1 có định giá v1 = 4, người chơi 2 có định giá v2 = 2 (chúng tôi xét thiết lập thông tin đầy đủ, trong đó định giá cá nhân là kiến thức chung).
Kết quả Toàn bộ theo tỷ lệ:
-
Giá thầu cân bằng: b1 = 8/9, b2 = 4/9
-
Phân bổ cân bằng: x1 = 2/3, x2 = 1/3
-
Thanh toán cân bằng: p1 = 8/9, p2 = 4/9
Điều này cảm giác đúng theo trực giác; khi v1 = 2·v2 (giá trị khối của người chơi 1 gấp đôi người chơi 2), người chơi 1 thầu, nhận và thanh toán gấp đôi người chơi 2.
Kết quả Người thắng nhận hết:
-
Giá thầu cân bằng: b1 = 2+ϵ, b2 = 2
-
Phân bổ cân bằng: x1 = 1, x2 = 0
-
Thanh toán cân bằng: p1 = 2+ϵ, p2 = 0
Điều này khá khác biệt. Người chơi 1 thầu vừa cao hơn giá trị của người chơi 2 (chúng tôi dùng ϵ biểu thị một lượng nhỏ), nhận toàn bộ phân bổ. Người chơi 2 không nhận được gì và không thanh toán.
Bây giờ hãy xét «thu nhập» mà cơ chế thu được trong mỗi trường hợp (hay tổng giá thầu):
-
Thu nhập Toàn bộ theo tỷ lệ: b1 + b2 = 4/3
-
Thu nhập Người thắng nhận hết: b1 = 2+ϵ
Thu nhập Người thắng nhận hết cao hơn, tương đương với oracle MEV chính xác hơn (do đó giao thức đốt hoặc san bằng nhiều MEV hơn), so với Toàn bộ theo tỷ lệ. Theo trực giác, bằng cách phân bổ quyền sản xuất khối cho người chơi có giá trị thấp hơn (như Toàn bộ theo tỷ lệ làm), chúng ta từ bỏ thu nhập có thể đạt được nếu phân bổ toàn bộ quyền cho người chơi có giá trị cao nhất. Xem Phụ lục 1 để xử lý đầy đủ hơn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
a16z
