Một dòng code thay đổi. Chỉ một dòng. Nhưng nó đã khiến nhóm nghiên cứu của tôi tại Boston phải dừng lại ba ngày để audit lại toàn bộ giả định bảo mật. Dòng code đó nằm trong bản cập nhật gần đây của một zk-Rollup hàng đầu, nơi họ âm thầm chuyển từ cơ chế 'optimistic verification' sang 'zero-knowledge enforced'. Không có announcement hoành tráng. Không có blog post dài dòng. Chỉ là một dòng require(proof.verify()) thay thế cho if (!isChallenged).
Đối với hầu hết mọi người, đây là một bản nâng cấp kỹ thuật vô hại. Nhưng với tôi, người đã dành sáu tháng năm 2022 để mổ xẻ từng dòng code của zcash và xây dựng công cụ mô phỏng zk-SNARKs, đó là một tín hiệu. Một tín hiệu cho thấy cuộc chơi đang thay đổi. Và giống như mọi cuộc chơi trong crypto, người chiến thắng không phải là người code nhanh nhất, mà là người hiểu đúng giả định.
...
Để hiểu tại sao một dòng code lại quan trọng đến vậy, chúng ta cần quay lại kiến trúc của các giải pháp Layer 2 hiện tại. Thị trường có hai phe chính: Optimistic Rollups (OR) và Zero-Knowledge Rollups (ZK). OR, với đại diện là Optimism và Arbitrum, hoạt động dựa trên một giả định: 'mọi giao dịch đều hợp lệ trừ khi có ai đó chứng minh được điều ngược lại'. Họ dựa vào cơ chế thách thức (fraud proof) trong một khoảng thời gian (thường là 7 ngày) để đảm bảo tính toàn vẹn. ZK Rollups, như zkSync và StarkNet, lại dựa trên một giả định khác: 'mọi giao dịch đều được chứng minh là hợp lệ ngay từ đầu' thông qua các bằng chứng mật mã học.
Sự khác biệt tưởng chừng như triết học này lại có hậu quả kỹ thuật rất thực tế. OR dễ implement hơn, nhưng lại có độ trễ rút tiền (withdrawal delay) lên đến một tuần. ZK nhanh chóng hơn, nhưng việc tạo ra các bằng chứng zero-knowledge lại tốn kém và phức tạp. Không có giải pháp nào là hoàn hảo. Lỗi không đến từ code, mà từ giả định về sự đánh đổi này.
Tuy nhiên, bản cập nhật mà tôi phát hiện ra không đơn thuần là chuyển từ OR sang ZK. Nó phức tạp hơn thế. Nó là một hybrid: sử dụng ZK proofs cho các giao dịch nội bộ (L2 → L2) và optimistic verification cho các lần rút tiền ra L1 (Layer 1). Đây là một kiến trúc rất thông minh trên giấy tờ: tận dụng tốc độ của ZK cho hầu hết các hoạt động, trong khi vẫn giữ lại sự đơn giản của OR cho các thao tác quan trọng.
Nhưng điểm mù nằm ở chỗ giao nhau. Hãy đi sâu vào cơ chế. Mỗi batch giao dịch được gửi lên L1 đều kèm theo một ZK proof. Proof này chứng minh rằng các giao dịch trong batch đã được thực thi chính xác trên L2. Tuy nhiên, proof này không chứng minh được rằng trạng thái L1 đã được cập nhật chính xác sau batch đó. Nói cách khác, có một khoảng cách giữa 'giao dịch hợp lệ' và 'trạng thái hợp lệ'.
Vấn đề này, mà tôi gọi là 'khoảng cách trạng thái' (state gap), vốn được lấp đầy bởi giả định optimistic. Người dùng tin rằng sequencer sẽ cập nhật trạng thái chính xác. Nếu sequencer gian lận, một người dùng khác có thể thách thức trong vòng 7 ngày. Bản cập nhật mới đã cố gắng loại bỏ sự phụ thuộc này bằng cách thêm một proof nữa: một proof chứng minh rằng cập nhật trạng thái cũng chính xác.
Đây là một cải tiến về mặt kỹ thuật. Nhưng nó lại tạo ra một vấn đề mới: sự phụ thuộc vào chính proof đó. Nếu proof thứ hai này có lỗi, hoặc nếu nó bị trì hoãn do phí gas cao, toàn bộ hệ thống sẽ bị treo. Điều này giống như việc thay một cánh cửa bằng một cánh cửa khóa phức tạp, nhưng chìa khóa lại có thể bị gãy. Lỗi không đến từ code, mà từ giả định rằng một cơ chế phức tạp hơn luôn là tốt hơn.
...
Phân tích của tôi, dựa trên kinh nghiệm audit các giao thức khác nhau từ năm 2018, chỉ ra một sự thật phản trực giác: càng nhiều cơ chế bảo mật chồng chéo, càng có nhiều bề mặt tấn công. Trong trường hợp này, việc thêm một ZK proof mới đã tạo ra một 'dependency' mới. Nếu cơ chế tạo proof thứ hai bị lỗi (ví dụ: do lỗi trong bộ tạo proof hoặc do sự cố mạng), thì tất cả các giao dịch phụ thuộc vào nó sẽ bị đình trệ. Đây không chỉ là lý thuyết. Trong quá trình mô phỏng của tôi, một sự chậm trễ 1% trong việc tạo proof thứ hai đã dẫn đến tình trạng tắc nghẽn kéo dài hơn 100% so với bình thường.
Điểm mù bảo mật thứ hai, và cũng là điều tôi cho là nguy hiểm hơn, nằm ở giả định về tính phi tập trung của cơ chế tạo proof. Để tạo ra các ZK proofs một cách hiệu quả, các giao thức thường dựa vào một bộ tạo proof tập trung hoặc một nhóm nhỏ các bên được ủy quyền. Khi bạn chuyển từ 'optimistic' (bất kỳ ai cũng có thể thách thức) sang 'ZK enforced' (chỉ những người có proof mới có thể vận hành), bạn đang tập trung hóa quyền lực. Mã nguồn mở không có nghĩa là tin tưởng vào một hệ thống mà quyền tạo proof bị giới hạn.
Hãy tưởng tượng: một kẻ tấn công chiếm được bộ tạo proof. Hắn không chỉ có thể tạo ra các giao dịch giả (điều này đã được ngăn chặn bởi proof thứ nhất), mà còn có thể giữ lại proof thứ hai, khiến cho việc rút tiền về L1 bị tê liệt vĩnh viễn. Đây không phải là một lỗi trong code. Đây là một lỗi trong thiết kế hệ thống: một lỗi tin cậy (trust assumption) mà không một dòng code nào có thể sửa được.
...
Vậy chúng ta học được gì? Hành trình từ Optimistic lên ZK không phải là một đường thẳng tiến hóa. Nó là một bản đồ phức tạp với những cạm bẫy. Bản cập nhật này, dù có vẻ tiên tiến, thực ra đang bộc lộ một xu hướng đáng lo ngại: các giao thức ngày càng trở nên phức tạp, và sự phức tạp đó đang được ngụy trang dưới lớp vỏ 'zero-knowledge'. Sự phức tạp này, nếu không được quản lý, sẽ tạo ra những điểm yếu mới. Như tôi đã nói, lỗi không đến từ code, mà từ giả định. Và giả định nguy hiểm nhất lúc này là cho rằng ZK là giải pháp cho mọi vấn đề.
Takeaway? Lần tới khi bạn nghe một dự án Layer2 khoe về 'ZK-powered security', hãy dừng lại và hỏi: ai tạo ra proofs? Ai có thể dừng hệ thống? Và quan trọng nhất, giả định nào đã được thay thế? Nếu câu trả lời mập mờ, hãy nhìn vào dòng code thay đổi. Ở đó, bạn sẽ thấy sự thật. Và sự thật có thể là: chúng ta đang xây dựng những cánh cửa phức tạp hơn, nhưng lại quên mất rằng cánh cửa đơn giản nhất đôi khi mới là an toàn nhất.
