Ghi vào thỏa thuận việc chống kiểm duyệt: Ai sẽ quyết định một giao dịch Ethereum có thể được đưa lên chuỗi hay không?

• tác giả: imToken *

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

Nhiều người có phản ứng đầu tiên rằng nghe có vẻ như một khẩu hiệu mang tính chính trị, thậm chí có 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ở 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 khả năng kỹ thuật rất cụ thể.

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

Chữ ký đúng, số dư tài khoản đủ, phí Gas cũng không thấp, nhưng giao dịch vẫn chưa được ghi vào khối, trạng thái trong ví vẫn dừng lại ở "Đang chờ", trong khi đó, các giao dịch khác có phí gần giống hoặc thậm chí thấp hơn vẫn liên tục được đưa lên chuỗi.

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

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

Một, "kiểm duyệt" đến từ đâu?

Để hiểu tại sao Ethereum cần những cơ chế này, trước tiên cần làm rõ rằng một giao dịch từ ví được phát đi đã 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ẽ vào hồ bơi giao dịch công cộng của Ethereum, tức là bộ nhớ (Mempool), nó giống như một khu vực chờ, nơi chứa nhiều 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 chuỗi, vẫn cần có người chọn 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 gửi cho mạng để xác nhận.

Vấn đề cũng phát sinh ở giai đoạn này.

Khi Ethereum nâng cấp lên cơ chế PoS (bằng chứng cổ phần), để ngăn chặn các hồ bơi staking lớn lợi dụng MEV (giá trị có thể khai thác tối đa) tạo ra độc quyền kinh tế, Ethereum đã giới thiệu hệ thống PBS (Proposer-Builder Separation, tách biệt người đề xuất và người xây dựng), trong cấu trúc này, quy trình xử lý giao dịch Ethereum thực sự được chia thành hai vai trò:

• Người xây dựng (Builder): 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 chênh lệch giá và thanh lý, và xây dựng một khối có lợi nhuận cao nhất có thể;
• Người đề xuất (Proposer): chịu trách nhiệm chọn một khối ứng cử viên từ Builder và gửi nó cho mạng;

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

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

Vì vậy, việc giao công việc xây dựng khối phức tạp cho các Builder chuyên nghiệp, các nút xác thực bình thường ngay cả khi không có khả năng chênh lệch cao cấp cũng 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 sự phi tập trung của staking.

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. Chẳng hạn, hiện tại hơn 90% khối Ethereum trên toàn mạng chỉ được sản xuất bởi một vài Builder chuyên nghiệp, và do những Builder này thường có nền tảng kinh doanh rõ ràng, rất dễ bị áp lực từ pháp lý của một số quốc gia hoặc khu vực cụ thể (ví dụ như danh sách trừng phạt OFAC), nên thực tế đã tạo ra rủi ro tập trung.

Cũng chính vì vậy, nếu một vài Builder chính chọn lọc lọc bỏ 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ông thể được đóng gói trong thời gian dài, thậm chí đối mặt với rủi ro bị "cấm ngầm".

Tóm lại, từ góc độ người dùng bình 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 độ hoạt động của giao thức, việ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, sắp xếp và ghi vào khối hay không.

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

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

Hai, từ FOCIL đến FairFIL: Ethereum làm thế nào để hạn chế Builder khối

Thực ra, khi 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 quyết định giao dịch vẫn tập trung lâu dài trong tay một số Builder, Ethereum sẽ lại hình thành rủi ro độc quyền tập trung mới.

Để giải quyết điều 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".

Tên gọi 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ự quyết định tất cả các giao dịch có được xử lý hay không, các nút xác thực tham gia staking bình thường cũng cần giữ lại một phần quyền lực, để họ có thể liệt kê một số giao dịch cần được xử lý.

Lấy ví dụ về một bến xe buýt, có thể hiểu một khối như một chuyến xe có số ghế 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, từ đó thông qua sắp xếp hiệu quả hơn để tăng lợi nhuận cho toàn bộ chuyến xe; nhưng các nút xác thực cũng có thể nộp một "danh sách phải lên xe", chỉ cần các giao dịch trong danh sách vẫn hợp lệ, 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á nhân để từ chối chúng mãi mãi.

Tuy nhiên, một danh sách bao gồm cuối cùng sẽ 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à phát triển theo hai hướng này.

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

FOCIL (Fork-Choice Enforced Inclusion Lists) sẽ chuyển quyền quyết định giao dịch phải được bao gồm từ một người đề xuất đơn lẻ sang một "ủy ban nút xác thực" được tạo thành từ nhiều bên.

Trong mỗi chu kỳ tạo khối, mạng sẽ ngẫu nhiên chọn một nhóm nút xác thực để tạo thành một ủy ban tạm thời, mỗi thành viên trong ủy ban sẽ độc lập quan sát bộ nhớ mạng và nộp 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à người đề xuất trên toàn mạng cố gắng kiểm duyệt một giao dịch, chỉ cần có 1 nút 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 vào ràng buộc của giao thức, và nếu người kiểm duyệt muốn tiếp tục loại bỏ nó, họ không chỉ cần vượt qua một người mà phải vượt qua nhiều người tham gia độc lập.

Vì vậy, lợi thế của nó là không cần phải tin tưởng rằng mỗi người trong ủy ban đều giữ trung lập.

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

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

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

2. FairFIL: không chỉ cần bù đắp thiếu sót, mà còn phải để thiếu sót có thể được kiểm chứng

Nếu FOCIL là từ quy tắc đồng thuận cấm kiểm duyệt một cách cứng nhắc, thì FairFIL (Fair Forward Inclusion Lists) và cơ chế có thể truy cứu 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 bền vững.

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

Trong hoạt động thực tế của mạng, Builder có thể cần một khoảng thời gian rất ngắn để tối ưu hóa thứ tự giao dịch và chênh lệch giá MEV, FairFIL cho phép Builder thực hiện điều chỉnh linh hoạt 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 sang 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 tổng thể 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 khảo công khai, có thể xác minh, để xác định các giao dịch nào trong hồ bơi giao dịch công cộng, 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 khảo vốn có đủ điều kiện vào khối nhưng cuối cùng không được xử lý, Builder sẽ cần công khai đưa chúng vào FairFIL;
• Sau đó, các xác thực viên sẽ kiểm tra xem danh sách này có đầy đủ hay không, nếu Builder rõ ràng đã bỏ sót các giao dịch đủ điều kiện nhưng không đưa chúng vào danh sách, thì hành vi này có thể bị phát hiện và ảnh hưởng đến việc các nút xác thực có hỗ trợ khối đó hay không;
• Cuối cùng, các giao dịch hợp lệ vào FairFIL sẽ trở thành nhiệm vụ cần được ưu tiên xử lý trong các khối tiếp theo, Builder tiếp theo vẫn có thể sắp xếp vị trí cụ thể của chúng trong khối, nhưng không thể tiếp tục giả vờ không thấy;

Nếu một giao dịch bị bỏ sót liên tục, khối liên quan có thể mất sự hỗ trợ của các xác thực viên, và Builder cũng có thể do đó mất toàn bộ lợi nhuận của khối.

Nói cách khác, "có thể truy cứu" mà FairFIL nhấn mạnh thực sự là thông qua việc đưa ra hình phạt kinh tế theo từng bậc, các Builder liên tục kiểm duyệt giao dịch sẽ phải đối mặt với rủi ro bị tước bỏ toàn bộ phần thưởng khối, thậm chí có thể bị phạt tiền đặt cọc.

Đây cũng là hướng đi dần sâu của cơ chế chống kiểm duyệt của Ethereum, nhằm xây dựng một bộ ràng buộc thực tế hơn, ngay cả khi một số người tham gia có ý định kiểm duyệt, cũng rất khó để kiểm soát lâu dài lối vào giao dịch; ngay cả khi có người cố tình bỏ sót giao dịch, cũng cần để lại dấu vết và phải trả giá ngày càng cao cho việc kiểm duyệt liên tục.

Ba, điều này có nghĩa là gì đối với người dùng bình thường?

Đối với những người dùng bình thường chuyển tiền, đổi tiền hoặc sử dụng DeFi hàng ngày qua ví, những cơ chế nền tảng này ngay cả khi trong tương lai được triển khai, cũng không cần thay đổi thói quen thao tác hiện tại.

Người dùng vẫn sẽ điền số tiền trong ví, xác nhận Gas, hoàn thành chữ ký, rồi chờ giao dịch lên chuỗi, nhưng trong nền tảng giao thức không thấy, logic liệu giao dịch có vào khối hay không có thể xảy ra thay đổi quan trọng.

Điều mà nó thực sự cải thiện là tính chắc chắn của quá trình bao gồm giao dịch.

• Đầu tiên, một giao dịch phù hợp với quy tắc sẽ không còn hoàn toàn phụ thuộc vào sự lựa chọn của một Builder nào đó: ngay cả khi Builder hiện tại không muốn xử lý, các xác thực viên khác cũng có thể thông qua danh sách bao gồm để thiết lập một yêu cầu bao gồm ở cấp độ giao thức cho nó;
• Thứ hai, quyền bao gồm giao dịch và quyền sắp xếp giao dịch có thể dần dần tách rời: Builder vẫn có thể sử dụng thuật toán chuyên nghiệp để sắp xếp thứ tự giao dịch, tăng lợi nhuận khối, và vẫn có thể cạnh tranh xung quanh chênh lệch giá và thanh lý, nhưng quyền quyết định "ai có đủ điều kiện vào thị trường" sẽ bị hạn chế;

Nhìn xa hơn, tính trung lập đáng tin cậy của Ethereum cũng có thể từ một giá trị dựa vào cam kết của người tham gia, dần dần chuyển thành các quy tắc giao thức được thực hiện tự động bởi khách hàng.

Người dùng không cần biết khối hiện tại được xây dựng bởi Builder nào, cũng không cần tin tưởng từng Builder sẽ chủ động giữ trung lập, các nút xác thực sẽ kiểm tra khối theo cùng một bộ quy tắc, khiến các khối vi phạm nghĩa vụ bao gồm khó có thể được mạng công nhận.

Trong tương lai, ví và trình duyệt khối thậm chí có thể cung cấp trạng thái giao dịch chi tiết hơn dựa trên điều này.

Một giao dịch không còn chỉ hiển thị một cách tổng quát là "đang xử lý", mà có thể thông báo thêm cho người dùng, liệu nó đã vào danh sách bao gồm hay chưa, có nhận được nghĩa vụ bao gồm của các khối tiếp theo hay không, và việc chờ đợi có thực sự là do phí không đủ, giao dịch đã hết hiệu lực, hay có sự cố trong giai đoạn xây dựng khối.

Tuy nhiên, cơ chế chống kiểm duyệt không có nghĩa là mỗi giao dịch đều có thể ngay lập tức thành công.

Giao dịch có thể vẫn không vào khối do số dư không đủ, xung đột Nonce, phí Gas quá thấp hoặc điều kiện thực thi hợp đồng đã hết hiệu lực, khi mạng bị tắc nghẽn, không đủ không gian khối, người dùng vẫn cần thông qua cạnh tranh phí để chờ xác nhận.

Nhưng điều mà nó chủ yếu cải thiện là một giao dịch vốn đã hợp lệ, phí hợp lý và đã được phát tán vào hồ bơi giao dịch công cộng, không nên bị trì hoãn vô thời hạn chỉ vì sự lựa chọn chủ quan của một số Builder khối.

Về tiến độ, tính đến tháng 8 năm 2026, EIP-7805 tương ứng với FOCIL vẫn đang ở trạng thái Draft, tuy nhiên nó đã được các nhà phát triển cốt lõi của Ethereum chọn làm Headliner cho nâng cấp Hegotá và đã vào giai đoạn Scheduled for Inclusion, có nghĩa là đội ngũ khách hàng đã đồng ý thúc đẩy việc thực hiện và phát triển thử nghiệm mạng xung quanh nó, nhưng thời gian cụ thể ra mắt trên mạng chính vẫn chưa được xác định cuối cùng.

FairFIL thì còn ở giai đoạn sớm hơn, hiện chủ yếu là một kế hoạch nghiên cứu được phát hành vào tháng 7 năm 2026, tương lai có vào lộ trình của Ethereum hay không, vẫn cần trải qua thảo luận, thực hiện và xác minh an toàn rộng rãi hơn.

Viết ở cuối

Nói một cách khách quan, Ethereum không thể đảm bảo rằng mọi Builder, xác thực viên và nhà điều hành cơ sở hạ tầng đều sẽ mãi mãi giữ trung lập.

Các bên tham gia có thể chịu áp lực quản lý, cũng có thể theo đuổi lợi ích của riêng mình, và cũng có thể nhận được động lực bên ngoài, một mạng lưới phi tập trung thực sự có khả năng chống chịu không thể được xây dựng dựa trên giả thuyết lý tưởng rằng "tất cả mọi người sẽ làm điều đúng đắn".

Chống kiểm duyệt thực sự là ngay cả khi một số bên tham gia cố gắng can thiệp vào giao dịch, các bên tham gia khác vẫn có khả năng phá vỡ sự kiểm soát đó; ngay cả khi có người chọn lệch khỏi nguyên tắc trung lập, giao thức cũng có thể khiến hành vi đó trở nên rõ ràng, tốn kém và khó duy trì.

Từ danh sách bao gồm ban đầu, đến FOCIL với ủy ban phân phối cùng ràng buộc Builder, rồi đến FairFIL yêu cầu hành vi bỏ sót có thể được kiểm chứng công khai, từ cho phép bất kỳ ai gửi giao dịch, đến đảm bảo rằng giao dịch của bất kỳ ai cũng có cơ hội được nhìn thấy.

Từ góc độ này, Ethereum thực sự đang cố gắng biến cam kết này từ một tuyên bố giá trị, từng bước viết vào chính giao thức.

Đáng để mong đợi.