Vitalik Buterin cho rằng đến thập niên 2030, các lập trình viên ưu tiên bảo mật sẽ có thể tiến gần mục tiêu viết phần mềm “không lỗi”, nhờ nhiều lớp cơ chế giảm chênh lệch giữa ý định và việc thực thi mã.
Dự báo này xuất hiện trong bối cảnh tranh cãi quanh một hard fork của Gnosis Chain nhằm thu hồi 9,4 triệu USD sau vụ khai thác Balancer, làm dấy lên câu hỏi về tính bất biến và cách xây dựng ứng dụng blockchain bằng smart contract.
- Vitalik Buterin dự đoán “viết code không lỗi” sẽ trở nên khả thi hơn trong thập niên 2030 với đội ngũ ưu tiên bảo mật.
- Ông nhấn mạnh “formal verification” không đồng nghĩa “chứng minh không có lỗi”, vì ý định con người rất phức tạp.
- Giải pháp trọng tâm là nhiều lớp dư thừa: hệ thống kiểu dữ liệu, kiểm chứng hình thức theo từng mệnh đề, và các lớp thử nghiệm khác.
Vitalik Buterin dự đoán code không lỗi sẽ khả thi hơn trong thập niên 2030
Vitalik Buterin cho rằng niềm tin “lỗi là điều không thể tránh” sẽ không còn đúng trong thập niên 2030, ít nhất với các nhà phát triển đặt bảo mật lên hàng đầu và áp dụng nhiều lớp kỹ thuật để giảm sai lệch giữa ý định và thực thi.
Nhận định được ông chia sẻ trong phần trao đổi trên mạng xã hội X, khi thảo luận xoay quanh quyết định hard fork của Gnosis Chain vào ngày 22/12 để thu hồi 9,4 triệu USD bị đánh cắp trong vụ khai thác Balancer tháng 11/2024.
Theo thông tin được nêu trong cuộc thảo luận, vụ khai thác Balancer đã rút hơn 128 triệu USD trên nhiều blockchain. Việc thu hồi yêu cầu phần lớn validator cài phần mềm mới, và các validator không cập nhật sẽ đối mặt với hình phạt.
Động thái này gây phản ứng trái chiều trong cộng đồng ủng hộ blockchain, vì bị cho là xung đột với nguyên tắc “tính bất biến” (immutability). Từ đó, tranh luận chuyển sang câu hỏi cốt lõi: ứng dụng blockchain đang được thiết kế và triển khai smart contract như thế nào.
Hard fork Gnosis Chain làm nổi bật tranh luận về tính bất biến và thiết kế smart contract
Vụ việc cho thấy một mặt cộng đồng muốn bảo vệ tính bất biến, mặt khác lại cần cơ chế can thiệp khi rủi ro bảo mật gây thiệt hại lớn, đặc biệt với các ứng dụng dùng smart contract chạy trong môi trường máy ảo có thể lập trình.
Một tài khoản X có biệt danh “colluding node” cho rằng vấn đề thật sự nằm ở cách xây dựng ứng dụng blockchain, và lập luận rằng dùng smart contract trong các máy ảo lập trình là hướng tiếp cận sai.
Người này còn viết: “Chỉ có 7 contract đáng để viết, và chúng nên được ‘đóng đinh’ ở lớp cơ sở (base layer) và nhận bảo mật từ sự đa dạng của client”. Quan điểm này nghiêng về việc giảm bề mặt tấn công bằng cách tối giản số hợp đồng và tăng tính chuẩn hóa ở tầng nền.
Formal verification không đồng nghĩa “chứng minh không có lỗi”
Buterin nhấn mạnh formal verification không làm cho phần mềm “chắc chắn không lỗi”, và thậm chí “provably bug free” có thể là điều không thể đạt được, vì “không lỗi” đòi hỏi không có khoảng cách giữa ý định và thực thi.
Ông phản hồi trực tiếp trên X tại liên kết: bài đăng phản hồi của Vitalik Buterin. Lập luận trung tâm của ông là “ý định” của con người là một đối tượng cực kỳ phức tạp và ta chỉ có khả năng truy cập, mô tả nó một cách hữu hạn.
“Tôi thậm chí còn cho rằng ‘provably bug free’ là không thể, bởi ‘bug-free’ nghĩa là ‘không có khoảng trống giữa ý định và việc thực thi code’, trong khi ý định của chúng ta là một đối tượng cực kỳ phức tạp mà chúng ta chỉ có thể tiếp cận ở mức hạn chế.”
– Vitalik Buterin, đồng sáng lập Ethereum, bài đăng trên X
Formal verification là tập hợp phương pháp toán học nhằm kiểm tra liệu hệ thống quan trọng về an toàn có hoạt động đúng hay không. Kỹ thuật này đã được sử dụng từ thập niên 1960 trong các lĩnh vực như kỹ thuật hàng không vũ trụ.
Audit nhiều lần vẫn có thể bỏ sót lỗ hổng trong smart contract
Ví dụ Balancer cho thấy kiểm toán (audit) và thử nghiệm không đảm bảo phát hiện hết lỗi, ngay cả khi có nhiều vòng và nhiều đơn vị tham gia, vì vẫn có thể tồn tại lỗ hổng nghiêm trọng lọt qua quy trình.
Trong thảo luận, Buterin nêu rằng các hợp đồng Balancer đã được audit 11 lần bởi bốn công ty bảo mật khác nhau, nhưng một lỗi nghiêm trọng vẫn bị bỏ sót. Trường hợp này thường được dùng để minh họa rủi ro “độ bao phủ kiểm tra” không bao giờ tuyệt đối trong các hệ thống phức tạp.
Nhiều lớp dư thừa là hướng đi thực tế để tiến tới phần mềm ít lỗi hơn
Buterin đề xuất xây dựng nhiều lớp dư thừa để “lọc” chênh lệch giữa ý định và thực thi, trong đó type system là một lớp, còn formal verification theo từng tuyên bố cụ thể là một lớp khác.
Theo hướng tiếp cận này, nhà phát triển không chỉ dựa vào một kỹ thuật đơn lẻ. Hệ thống kiểu dữ liệu (type system) giúp loại bỏ sớm nhiều lỗi logic ở thời điểm biên dịch hoặc phân tích tĩnh. Trong khi đó, formal verification có thể chứng minh một số thuộc tính đã được đặc tả, thay vì tuyên bố chung chung “phần mềm không lỗi”.
Buterin cũng lưu ý formal verification có thể phát hiện các vấn đề như integer underflow/overflow, re-entrancy, và tối ưu gas kém, những thứ đôi khi lọt qua auditor và tester. Ngược lại, kiểm thử truyền thống thường chỉ chứng minh “có lỗi hay không” trong phạm vi kịch bản kiểm thử, chứ không chứng minh được “không có lỗi”.
Không phải mọi phần mềm đều theo đuổi “không lỗi”, nhưng phần mềm ưu tiên bảo mật có thể đạt chuẩn cao hơn
Buterin cho rằng một số phần mềm vẫn sẽ có lỗi vì nhiều trường hợp ưu tiên thêm tính năng hơn là đạt mức hoàn hảo, nhưng nhóm phát triển ưu tiên bảo mật sẽ có công cụ để tiến gần “thực sự không lỗi”.
Trong thực tế ngành tiền điện tử, điều này ngụ ý các dự án xử lý tài sản người dùng, cầu nối (bridge), giao thức lending, DEX và hạ tầng ví có thể phải chấp nhận chi phí cao hơn cho thiết kế đặc tả, verification theo mệnh đề, và nhiều vòng phòng vệ, đổi lại là giảm xác suất sự cố gây thiệt hại lớn.
Những câu hỏi thường gặp
Vitalik Buterin nói gì về “code không lỗi” trong thập niên 2030?
Ông cho rằng trong thập niên 2030, các lập trình viên ưu tiên bảo mật có thể có đủ công cụ và quy trình để đạt mức “không lỗi” theo nghĩa thực dụng, nhờ nhiều lớp giảm sai lệch giữa ý định và thực thi.
Vì sao “formal verification” không có nghĩa là phần mềm chắc chắn không lỗi?
Vì formal verification chỉ chứng minh hệ thống thỏa một đặc tả nhất định, trong khi “không lỗi” đòi hỏi không có khoảng cách giữa ý định và thực thi, mà ý định con người lại khó mô tả đầy đủ và chính xác.
Hard fork Gnosis Chain liên quan gì đến tranh luận này?
Hard fork của Gnosis Chain nhằm thu hồi 9,4 triệu USD sau vụ khai thác Balancer đã làm bùng lên tranh luận về tính bất biến và cách thiết kế ứng dụng blockchain, từ đó dẫn tới trao đổi của Buterin về giới hạn và hướng đi của kỹ thuật bảo mật phần mềm.
Tại sao audit nhiều lần vẫn có thể bỏ sót lỗ hổng?
Vì kiểm toán và kiểm thử không thể bao phủ mọi trạng thái và mọi tương tác trong hệ thống phức tạp. Ngay cả khi Balancer được audit 11 lần bởi bốn công ty khác nhau, một lỗi nghiêm trọng vẫn có thể lọt qua.
Những lớp “dư thừa” nào được nêu để giảm lỗi trong smart contract?
Buterin nêu type system như một lớp giảm lỗi, và formal verification cho các tuyên bố cụ thể như một lớp khác. Kết hợp nhiều lớp giúp giảm khoảng trống giữa ý định và hành vi thực thi của code.