将抗审查写进协议：谁来决定一笔以太坊交易能否上链？

Trong thế giới blockchain, chúng ta thường nghe đến một từ: "chống kiểm duyệt".

Phản ứng đầu tiên của nhiều người, nghe có vẻ như một khẩu hiệu chính trị hóa, thậm chí mang màu sắc vô chính phủ nào đó, nhưng đối với một mạng lưới thanh toán mở dành cho người dùng toàn cầu như Ethereum, chống kiểm duyệt trước hết không phải là một lập trường chính trị, mà là một năng lực kỹ thuật rất cụ thể.

Hãy tưởng tượng, bạn khởi tạo một giao dịch trong ví imToken.

Chữ ký chính xác, số dư tài khoản đầy đủ, phí Gas cũng không hề thấp, nhưng giao dịch vẫn không được ghi vào khối, trạng thái trong ví luôn dừng ở "Pending", trong khi đó, các giao dịch khác có mức phí tương đương hoặc thậm chí thấp hơn lại liên tục được lên khối.

Lúc này, vấn đề trở thành: rốt cuộc ai có quyền quyết định một giao dịch có thể vào khối hay không? Dù sao đi nữa, nếu Ethereum cuối cùng vẫn cần một vài bên tham gia tập trung quyết định giao dịch nào được lên khối, thì nó cũng chẳng có sự khác biệt về bản chất so với hệ thống tài chính truyền thống.

Vì vậy, Ethereum trong những năm gần đây đang khám phá một loạt cơ chế chống kiểm duyệt như FOCIL, FairFIL, cố gắng trả lời một câu hỏi nghe có vẻ đơn giản nhưng thực ra vô cùng quan trọng: làm thế nào để đảm bảo mọi giao dịch tuân thủ quy tắc của giao thức đều có cơ hội công bằng để vào khối?

1. "Kiểm duyệt" rốt cuộc đến từ đâu?

Để hiểu vì sao Ethereum cần những cơ chế này, trước tiên cần làm rõ, sau khi một giao dịch được gửi từ ví, nó thực sự trải qua những gì.

Khi người dùng ký và gửi giao dịch trong ví, giao dịch này thường sẽ trước tiên đi vào bể giao dịch công khai của Ethereum, tức là Mempool, nó giống như một khu vực chờ, nơi chứa một lượng lớn các giao dịch chưa được ghi vào khối.

Nhưng vào khu vực chờ, không có nghĩa là giao dịch đã lên khối, vẫn cần có người chọn lọc giao dịch, quyết định thứ tự của chúng, tạo thành một khối hoàn chỉnh, rồi giao cho mạng lưới xác nhận.

Vấn đề cũng chính là phát sinh ở khâu này.

Sau khi Ethereum nâng cấp lên cơ chế PoS (Proof of Stake), để ngăn chặn các nhóm stake lớn lợi dụng MEV (Maximal Extractable Value) hình thành độc quyền kinh tế, Ethereum đã giới thiệu hệ thống PBS (Proposer-Builder Separation), trong kiến trúc này, quy trình xử lý mỗi giao dịch Ethereum thực chất được tách thành hai vai trò phụ trách:

• Builder (Người xây dựng): chịu trách nhiệm thu thập giao dịch, sắp xếp thứ tự giao dịch, tìm kiếm cơ hội arbitrage và thanh lý, đồng thời xây dựng một khối có lợi nhuận cao nhất có thể;
• Proposer (Người đề xuất): chịu trách nhiệm chọn một trong số các khối ứng viên do Builder gửi lên, và gửi nó cho mạng lưới;

Sự phân công này có những lợi ích rất thực tế.

Như chúng ta đã biết, trong những năm gần đây, các chiến lược MEV ngày càng phức tạp, nếu yêu cầu mỗi validator thông thường đều tự hoàn thành việc sắp xếp giao dịch và tối ưu hóa khối, thì chắc chắn sẽ khiến các node lớn có nhiều vốn, dữ liệu và năng lực kỹ thuật hơn chiếm ưu thế.

Vì vậy, giao việc xây dựng khối phức tạp cho các Builder chuyên nghiệp, các node xác thực thông thường dù không có khả năng arbitrage cao cấp, vẫn có thể tham gia đề xuất khối và nhận được lợi nhuận tương ứng, từ đó giảm thiểu tác động của MEV đến tính phi tập trung của việc stake.

Chỉ là nó cũng vô tình mang lại một tác dụng phụ khác, đó là sự tập trung quá mức quyền xây dựng khối. Ví dụ, hiện tại hơn 90% số khối của toàn mạng Ethereum chỉ được sản xuất bởi một số ít Builder chuyên nghiệp, và vì các Builder này thường có nền tảng hoạt động doanh nghiệp rõ ràng, rất dễ chịu áp lực tuân thủ pháp luật từ các quốc gia hoặc khu vực cụ thể (ví dụ danh sách trừng phạt OFAC), nên trên thực tế đã cấu thành rủi ro tập trung hóa.

Cũng chính vì vậy, một khi các Builder chủ đạo này lọc bỏ có chọn lọc một số hợp đồng nhạy cảm (như Tornado Cash) hoặc giao dịch từ các địa chỉ cụ thể, những giao dịch này sẽ rơi vào tình trạng khó được đóng gói trong thời gian dài, thậm chí đối mặt với rủi ro bị "phong sát ngầm".

Tóm lại, trong con mắt của người dùng thông thường, Ethereum là một mạng lưới mở mà bất kỳ ai cũng có thể kết nối, chuyển tiền và gọi hợp đồng thông minh, nhưng từ góc độ vận hành giao thức, gửi giao dịch chỉ là bước đầu tiên, liệu giao dịch có thực sự có hiệu lực hay không, còn phụ thuộc vào việc nó có được một Builder khối nào đó chọn lọc, sắp xếp và ghi vào khối hay không.

Vì vậy, "chống kiểm duyệt" mà Ethereum thảo luận, không chỉ là một khái niệm vĩ mô liên quan đến chính trị, quy định hoặc trừng phạt, trước hết nó là một vấn đề kỹ thuật rất cụ thể:

Khi một giao dịch đáp ứng các quy tắc của giao thức, liệu mạng lưới có thể đảm bảo nó có cơ hội vào khối trong một khoảng thời gian hợp lý hay không?

2. Từ FOCIL đến FairFIL: Ethereum hạn chế Builder khối như thế nào

Thực ra nói đến đây, vấn đề đã rất rõ ràng, Builder có thể nâng cao hiệu quả xây dựng khối, nhưng nếu quyền bao gồm giao dịch cũng tập trung lâu dài trong tay một số ít Builder, Ethereum sẽ một lần nữa hình thành rủi ro độc quyền tập trung mới.

Vì mục đích này, các nhà nghiên cứu Ethereum đã đề xuất Inclusion Lists, thường được gọi là "danh sách bao gồm".

Cái tên này nghe có vẻ trừu tượng, nhưng logic cốt lõi của nó không phức tạp — Builder vẫn chịu trách nhiệm tạo khối, nhưng không thể tự mình quyết định số phận của mọi giao dịch, các node xác thực tham gia stake Ethereum bình thường cũng cần giữ lại một phần quyền lực, cho phép họ liệt kê một số giao dịch bắt buộc phải được xử lý.

Lấy ví dụ về trạm xe buýt, có thể hiểu một khối như một chuyến xe có số lượng chỗ ngồi hạn chế.

Builder quyết định phần lớn hành khách xếp hàng như thế nào, ngồi ở vị trí nào, nhờ đó thông qua việc sắp xếp hiệu quả hơn để tăng lợi nhuận của cả chuyến xe; nhưng các node xác thực cũng có thể đệ trình một "danh sách bắt buộc lên xe", chỉ cần giao dịch trong danh sách vẫn còn hiệu lực, sẵn sàng trả phí hợp lý, và khối còn đủ không gian, Builder không thể chỉ dựa vào sở thích của mình mà từ chối chúng mãi mãi.

Tuy nhiên, một danh sách bao gồm rốt cuộc do ai tạo ra, và nếu có người cố tình bỏ sót giao dịch thì phải làm sao, vẫn là hai vấn đề cần tiếp tục giải quyết.

FOCIL và FairFIL, chính là triển khai theo hai hướng này.

1. FOCIL: Không còn để một Proposer tự mở danh sách bao gồm

FOCIL (Fork-Choice Enforced Inclusion Lists) chuyển quyền quyết định giao dịch có bắt buộc được bao gồm hay không, từ một proposer duy nhất sang một "ủy ban node xác thực" gồm nhiều bên.

Trong mỗi chu kỳ sản xuất khối, mạng lưới sẽ chọn ngẫu nhiên một nhóm node xác thực để tạo thành ủy ban lâm thời, mỗi thành viên trong ủy ban sẽ độc lập quan sát mempool của mạng lưới, và tự đệ trình một danh sách bao gồm cục bộ.

Điều này có nghĩa là ngay cả khi 99% Builder và proposer trên toàn mạng đều âm mưu kiểm duyệt một giao dịch nào đó, chỉ cần có 1 node trung thực trong ủy ban đưa giao dịch đó vào danh sách, giao dịch này sẽ có cơ hội được ràng buộc bởi giao thức, kẻ kiểm duyệt nếu muốn tiếp tục loại trừ nó, không còn chỉ ảnh hưởng đến một người, mà cần phải vượt qua cùng lúc nhiều bên tham gia độc lập.

Vì vậy, ưu điểm của nó là, không cần tin tưởng mọi người trong ủy ban đều giữ thái độ trung lập.

Nhưng chỉ có danh sách thôi vẫn chưa đủ, nếu Builder nhận được danh sách mà vẫn chọn không thực hiện, danh sách bao gồm sẽ trở thành một khuyến nghị không có tính ràng buộc.

Vì vậy, FOCIL lại thêm một tầng thiết kế thứ hai, giới thiệu quy tắc lựa chọn nhánh (Fork-Choice Rule) để ràng buộc cứng rắn, khiến các node chịu trách nhiệm bỏ phiếu xác thực trên toàn mạng kiểm tra nghiêm ngặt khối do Builder đệ trình, một khi phát hiện Builder dám vi phạm danh sách bao gồm được tổng hợp bởi ủy ban, toàn bộ mạng lưới sẽ trực tiếp từ chối bỏ phiếu cho khối đó.

Điều này có nghĩa là khối vi phạm sẽ bị giao thức phán quyết là khối không hợp lệ ngay lập tức, Builder sẽ phải trả giá rất lớn cho việc thất bại trong sản xuất khối.

2. FairFIL: Không chỉ vá lỗ hổng, mà còn khiến việc bỏ sót có thể được kiểm chứng

Nếu nói FOCIL là ngăn chặn kiểm duyệt một cách cứng rắn từ quy tắc đồng thuận, thì FairFIL (Fair Forward Inclusion Lists) và cơ chế minh bạch trách nhiệm là từ góc độ kinh tế, khiến hành vi kiểm duyệt trở nên cực kỳ tốn kém và không thể bền vững.

Nói thẳng ra, nó đặt ra yêu cầu cao hơn, ví dụ như một giao dịch tại sao không vào được khối, cần phải để lại càng nhiều càng tốt các ghi chép có thể được kiểm tra công khai.

Trong quá trình vận hành mạng lưới thực tế, Builder có thể cần một khoảng thời gian đệm rất ngắn để tối ưu hóa thứ tự giao dịch và arbitrage MEV, FairFIL cho phép Builder linh hoạt điều chỉnh trong các ràng buộc cụ thể, nhưng nếu Builder cố gắng kéo dài một hành vi kiểm duyệt nào đó đến khối tiếp theo, giao thức sẽ ngay lập tức khởi động quy trình truy cứu trách nhiệm.

Logic đại khái của nó, có thể được hiểu qua ba bước.

• Đầu tiên, giao thức sẽ thiết lập một bộ quy tắc tham chiếu công khai, có thể xác minh, để xác định những giao dịch nào trong bể giao dịch công khai, trong điều kiện bình thường, đủ điều kiện vào khối hiện tại, nếu một số giao dịch theo quy tắc tham chiếu vốn dĩ có đủ điều kiện vào khối nhưng cuối cùng không được xử lý, Builder cần phải công khai liệt kê chúng vào FairFIL;
• Sau đó, các validator sẽ kiểm tra danh sách này có đầy đủ hay không, nếu Builder rõ ràng bỏ sót một giao dịch đủ điều kiện mà không ghi