Sự thật về 'decentralized sequencer' của Layer 2: Một phân tích mã nguồn từ góc nhìn của kẻ đào sâu
Đỗ Quân
Nếu bạn compile lại chính compiler, liệu bạn có tin tưởng vào output không? Câu hỏi đó ám ảnh tôi mỗi khi đọc một whitepaper Layer 2 hứa hẹn 'decentralized sequencing'. Tôi đã dành 3 tháng để đọc từng dòng mã của ba giao thức L2 hàng đầu, và phát hiện ra một sự thật khó chịu: sequencer của chúng, về cơ bản, vẫn là một node tập trung đơn lẻ. 'Decentralized sequencing' vẫn chỉ là PowerPoint suốt hai năm qua.
Hãy bắt đầu từ cơ chế gốc. Sequencer là bộ phận nhận giao dịch từ người dùng, sắp xếp chúng theo thứ tự, và tạo batch để gửi lên L1. Trong thiết kế hiện tại của hầu hết các rollup (Optimistic và ZK), sequencer là một thực thể duy nhất do đội ngũ vận hành. Nó có toàn quyền kiểm soát thứ tự giao dịch, có thể censored, MEV extraction, thậm chí là reorg tùy ý. Whitepaper thường gọi đây là 'phased decentralization' – giai đoạn 1 tập trung, giai đoạn 2 sẽ có nhiều sequencer. Nhưng khi tôi đào vào mã nguồn của Arbitrum, Optimism và zkSync, tôi thấy không có một dòng code nào cho phép nhiều sequencer hoạt động đồng thời. Các hợp đồng bridge và challenge period đều được thiết kế với giả định chỉ có một sequencer.
Cụ thể, trên Arbitrum, sequencer là một dịch vụ chạy trên máy chủ AWS của Offchain Labs. Nó ký các batch và gửi lên hợp đồng Inbox trên Ethereum. Hợp đồng Inbox chỉ chấp nhận chữ ký từ một địa chỉ duy nhất – địa chỉ của sequencer. Nếu bạn muốn thay đổi sequencer, bạn cần gọi hàm setSequencer, nhưng hàm đó chỉ có thể được gọi bởi owner (một multisig). Không có cơ chế để nhiều sequencer cùng tồn tại. Trên Optimism, tình hình tương tự: sequencer là một node duy nhất, và quyền submit batch được kiểm soát bởi một EOA. zkSync Era có một twist: họ dùng 'validator set' để xác thực các block, nhưng sequencer vẫn là một thực thể tập trung có quyền ưu tiên.
Tôi nhớ lại năm 2017, khi tôi đọc hợp đồng The DAO, tôi đã phát hiện lỗ hổng reentrancy mà nhiều người bỏ qua. Bài học đó dạy tôi: đừng tin vào lời hứa, chỉ tin vào code. Và code của các L2 hiện tại không hề có dấu hiệu của một sequencer phi tập trung. Các bài báo kỹ thuật thường nói về 'sequencer selection' và 'consensus among sequencers', nhưng trong thực tế, không có gì được triển khai. Điều này tạo ra một điểm mù bảo mật nghiêm trọng: nếu sequencer bị tấn công hoặc bị kiểm soát bởi kẻ xấu, toàn bộ rollup có thể bị kiểm soát. Hãy tưởng tượng một kịch bản: sequencer từ chối xử lý giao dịch của một nhóm người dùng, hoặc sắp xếp giao dịch để thực hiện sandwich attack. Không có cơ chế nào để người dùng phản kháng, ngoại trừ việc chờ force-inclusion qua L1 – một quá trình mất hàng giờ.
Điểm phản trực giác ở đây là: càng nhiều người tin vào 'decentralized sequencing', họ càng ít kiểm tra mã nguồn thực tế. Họ cho rằng đội ngũ sẽ 'sớm' triển khai, nhưng tôi đã thấy các lộ trình công nghệ bị trì hoãn hàng năm. Trong khi đó, các lỗ hổng bảo mật do sequencer tập trung gây ra đã xuất hiện: năm 2023, một sự cố trên Arbitrum khi sequencer ngừng hoạt động 30 phút do lỗi phần mềm, khiến người dùng không thể rút tiền. Nếu đó là một cuộc tấn công có chủ đích, hậu quả sẽ khủng khiếp.
Tôi từng tham gia thiết kế một zk-Rollup cho ứng dụng AI vào năm 2025. Chúng tôi đã thử nghiệm mô hình nhiều sequencer, nhưng chi phí gas tăng vọt và độ trễ tăng gấp 5 lần. Cuối cùng, chúng tôi quay lại sequencer đơn lẻ vì lý do hiệu suất. Điều này cho thấy một trade-off khó khăn: phi tập trung hóa sequencer làm giảm hiệu suất và tăng chi phí. Các đội ngũ Layer 2 biết điều này, nhưng họ không nói ra. Họ tiếp tục bán giấc mơ 'decentralized sequencing' để thu hút người dùng và nhà đầu tư.
Vậy takeaway là gì? Khi bạn nhìn thấy một dự án L2 tuyên bố có 'decentralized sequencer', hãy yêu cầu họ chỉ cho bạn dòng code triển khai nó. Nếu không, hãy coi đó là một rủi ro kỹ thuật cốt lõi. Tôi dự đoán rằng trong 12 tháng tới, ít nhất một L2 sẽ gặp sự cố bảo mật nghiêm trọng do sequencer tập trung, và điều đó sẽ làm rung chuyển niềm tin vào toàn bộ hệ sinh thái. Câu hỏi không phải là 'nếu', mà là 'khi nào'.