Hỏi đâu là minh chứng cho sự thiếu an toàn/ổn định, thiếu phân tán/trung lập của Ethereum? Đâu là minh chứng là đánh đổi sự an toàn và trung lập (trade-off) để lấy thêm nhiều tính năng là lựa chọn sai lầm?
Bình thường mình không quá quan tâm tới các dự án blockchain ngoài Bitcoin (xem bài “Bitcoin và ngưỡng số Dunbar” của mình để hiểu thêm tại sao mình có quan điểm này). 90% thời gian mình bỏ ra hiện tại là vào Bitcoin. Nhưng anh Tuấn đã hỏi thì mình cũng chia sẻ một vài ví dụ cho mọi người tham khảo. Danh sách dưới đây là thông tin hoàn toàn public, mọi người có thể tự Google kiểm chứng.
SỰ THIẾU AN TOÀN
1. DAO hack (2016)
Reentrancy bug: $50 mil hacked (tất cả trị giá các vụ hack trong bài này đều tính theo thời điểm lúc đó, bây giờ thì đã hơn rất nhiều).
DAO hack có lẽ là vụ hack nổi tiếng nhất của Ethereum. Lỗ hổng và vụ hack này xảy ra ngay từ thuở sơ khai của Ethereum. Lời thoại “ok can you guys stop trading” của Vitalk bây giờ đã trở thành một câu bất hủ (nhiều phần châm biếm) vì nó đặt ra một tiền lệ nguy hiểm: một cá nhân có thể đơn phương xoá sổ dữ liệu (“roll back”) một blockchain công cộng mang tính “quốc tế” (“world computer”) để viết lại lịch sử, thậm chí là dừng mọi hoạt động mua bán của Ether trên các sàn trong thời điểm đó để thuận tiện hơn cho việc người đó viết lại lịch sử. Việc này có liên quan mật thiết đến chuyện gần 70% các đồng ether đã được “đào trước” và chia đều cho Vitalik, bạn bè và cộng sự. Việc viết lại lịch sử Ethereum blockchain chính là để bảo vệ 70% số lượng ether đó, bảo vệ lợi ích nhóm của Vitalik và bạn bè. Đây là vết nhơ lớn nhất trong lịch sử Ethereum.
2. Parity hack (2017)
Poor Solidity visibility rule: xấp xỉ $30mil hacked, $280mil đóng băng.
Một trong những ví điện tử phổ biến nhất của Ethereum, Parity, được phát triển bởi một trong những Ethereum co-founders, Gavin Wood, cũng chính là người đề xuất ra ngôn ngữ lập trình Solidity và giúp triển khai nó, đã bị hacker tận dụng một lỗ hổng trong ví multisig, làm cho $280mil “đóng băng”, tắc không lấy ra được. Ngoài ra còn chiếm đoạt $30mil của người dùng. Vụ này còn minh chứng cho thấy, một blockchain có thể quảng bá nhiều tính năng hợp đồng thông minh (smart contract), chạy nhanh gấp 10 Bitcoin này kia. Nhưng cái hợp đồng thông minh đơn giản nhất là ví multisig còn không đảm bảo được độ an toàn, thì có lẽ cũng không nên bàn đến những chuyện quá cao siêu. Turing-completeness thế này, chữ ký thuật toán BLS thế kia.
3. “Unannounced hard fork” (2020) (hark fork bất thình lình)
Ngày 11 tháng 11 năm 2020, hệ thống Ethereum sập hoàn toàn. Các ứng dụng phổ biến nhất Ethereum như Metamask, MakerDAO, Uniswap, Compound và MyCrypto đều ngỏm củ tỏi. Binance ngừng giao dịch Ether vì phát hiện mâu thuẫn thông tin hệ thống.
Hoá ra là chiếc ví phổ biến nhất Ethereum, geth (80% thị phần), đã… vô tình tách Ethereum blockchain ra làm hai. Việc này làm cho một đồng tiền Ether có thể tiêu được 2 nơi khác nhau trong thời điểm đó (double-spent), một trong những điều mà blockchain sinh ra để giải quyết.
Lý do của việc blockchain bị tách đôi này, là vì các lập trình viên Ethereum, trước đó vài tháng phát hiện một lỗi bảo mật vô cùng nghiêm trọng (lỗ hổng này được hình thành từ một nâng cấp Ethereum từ năm 2019), đã “lẳng lặng” vá lỗ hổng này trong phiên bản mới của ví geth mà không thông báo cho các đơn vị tổ chức liên quan. Vì họ lẳng lặng sửa lỗi nâng cấp không thông báo, các thành viên khác trong cộng đồng không biết vẫn chạy những phiên bản cũ của geth. Hai phiên bản geth khác nhau đã gây mâu thuẫn thông tin giao dịch, dẫn đến việc blockchain của Ethereum bị tách ra làm đôi.
Vâng, quá nhiều điều nguy hiểm và đáng nói ở đây. Tại sao lỗ hổng nghiêm trọng lại lọt được vào phần mềm trọng yếu nhất của Ethereum (consensus layer) năm 2019? Tại sao gần 2 năm trời mới phát hiện ra lỗi nghiêm trọng đó? Tại sao khi phát hiện ra lại lẳng lặng vá lỗi, không thông báo cho cộng đồng? Ai là người đã quyết định đơn phương đi vá cái lỗi theo phong cách đó? Một hệ thống blockchain toàn cầu mà một nhóm nhỏ có thể lẳng lặng muốn thay đổi là thay đổi vậy sao? Có ai có thể đảm bảo FBI (ví dụ) không cài người vào Ethereum để cố tính đẩy lỗi nghiêm trọng hơn hay tạo backdoor?
Hiện số lượng người sử dụng Ethereum vẫn chỉ tính hàng triệu, nhưng bạn cứ thử tưởng tượng, nếu thực sự cả thế giới này dùng Ethereum (“máy tính thế giới” mà), thì có thể đã có bao nhiêu người, doanh nghiệp mất tài sản, gián đoạn công việc, xử lý hậu quả chồng chất như thế nào. (Nghịch lý thay, sau khi lý do Ethereum bị sập hệ thống được công bố, giá của Ether không những không bị ảnh hưởng mà lại còn tăng, chứng tỏ việc thị trường bị biến chất và đánh giá đang bị méo mó như thế nào).
4. Berlin bug (2021)
Gần đây nhất, tháng 4 năm 2021, nâng cấp “Berlin” của Ethereum đã đánh sập 12% hệ thống. Lý do lần này lại liên quan đến một ví phổ biến khác của Ethereum, Open Ethereum. Open Ethereum tính sai giá giao dịch và đã coi một số block của Ethereum là “sai luật” (invalid). Blockchain của các đơn vị sử dụng Open Ethereum (12% hệ thống) bị “tắc”, chôn chân tại chỗ. Cũng giống như Binance ở sự cố trước, Coinbase phải tạm thời dừng giao dịch Ether.
Trên đây là một số ví dụ tiêu biểu cho sự thiếu an toàn của Ethereum. Còn rất nhiều các lỗ hổng khác liên quan đến ngôn ngữ Solidity, viết ra quá dài.
Những vụ tai nạn trên của Ethereum chắc chắn mới chỉ là bề nổi của tảng băng lớn. Cũng giống như việc Windows hay Macintosh qua hàng chục năm phát triển vẫn có những lỗ hổng nguy hiểm. Khác biệt ở đây là, lỗ hổng Windows/Mac đa số thường chỉ làm người dùng mất dữ liệu. Còn lỗ hổng blockchain ảnh hưởng trực tiếp đến tài sản của rất nhiều người. Có lẽ không ai có thể phủ nhận rằng: tính an toàn khi triển khai hệ thống blockchain là phải luôn được đặt lên hàng đầu (sau vấn đề thành công về mặt TIỀN TỆ – một chủ đề hay gây hiểu lầm khác).
Ngoài ra, một số lỗ hổng sẽ chỉ hiện hình trong tình huống hiếm có, những sự kiện “thiên nga đen” (black swan events). Trong thế giới vật chất, các dự án máy bay Concorde, tàu bay Challenger, và nhà máy điện Fukushima trong thời điểm trước khi xảy ra tai nạn thảm khốc đều đạt được những tiêu chuẩn an toàn và thậm chí được đánh giá là bậc nhất trong sự an toàn, nhưng khi sự cố không ngờ xảy ra, thì mới biết mèo trắng mèo đen như thế nào. Việc trào lưu các blockchain chuyển sang sử dụng Proof-of-Stake cũng vậy. Mọi chuyện sẽ có vẻ êm đẹp, cho đến khi tất cả đều sập xuống. Cái đáng nói ở đây là, thái độ chủ quan trong xây dựng và thiết kế sẽ gây ra những tai nạn khôn lường.
Đằng sau những lỗ hổng của Ethereum là một vấn đề mang tính hệ thống, tư tưởng (systemic): ngôn ngữ lập trình blockchain quá nhiều tính năng rất khó đảm bảo cho sự an toàn. Điều này ai có kinh nghiệm làm bảo mật sẽ hiểu ngay. Tất cả các phầm mềm, phần cứng về bản chất đều có lỗ hổng (Bitcoin không phải là ngoại lệ và cũng đã từng có bugs, nhưng hạn chế hơn Ethereum rất nhiều). Hãy tham khảo sự kiện Mỹ hack hệ thống hạt nhân và đánh sập 1/5 số lượng máy ly tâm hạt nhân của Iran (Stuxnet), một hệ thống tưởng chừng không có kẽ hở, không có kết nối với thế giới bên ngoài (air-gapped), “con kiến cũng không thể lọt qua”, để hiểu vấn đề bảo mật khó như thế nào. Càng nhiều tính năng, lỗ hổng bảo mật càng lớn (large attack surface). Việc Ethereum chú trọng các tính năng ở base layer mà xem nhẹ những vấn đề bảo mật đã gây ra những hậu quả nghiêm trọng như trên. Chỉ đơn cử việc số lượng dòng code của EVM và các ví Ethereum là quá nhiều, là đã khó phát hiện ra các lỗi nghiêm trọng hơn nhiều rồi (để ý 3 ví dụ sự cố ở trên liên quan đến 3 ví phổ biến khác nhau của Ethereum).
Có một số người sẽ nói: ừ, cũng đúng, đi nhanh hơn, mạo hiểm hơn sẽ rủi ro hơn, thiếu an toàn hơn, nhưng bù lại sẽ làm được những thứ “hay ho” hơn. Nhưng ngoài những hậu quả gây thiếu an toàn, việc đi nhanh đi tắt còn sẽ dễ dàng làm mất đi thứ ý nghĩa nhất của công nghệ blockchain: tính phân tán / trung lập (decentralization / apoliticism). Nếu một dự án blockchain không duy trì được tính trung lập, thứ nhất là không có đột phá về góc độ tiền tệ. Thứ hai là blockchain, nghe có vẻ cao siêu, nhưng thực ra là một loại cấu trúc dữ liệu (data structure) tồi tệ nhất bạn có thể sử dụng khi viết phần mềm. 99% các dự án blockchain nên sử dụng các cấu trúc dữ liệu và database truyền thống như MySql, chứ không nên đội mũ blockchain, vì thực sự là nếu không duy trì được tính phân tán, sử dụng cấu trúc blockchain là một điều cồng kềnh, phí phạm.
SỰ THIẾU PHÂN TÁN/TRUNG LẬP
5. DAO Hack, tập 2
Nói về tính thiếu trung lập thì lại phải nhắc lại vụ DAO hack trên, vì nó quá kinh điển.
So sánh việc Vitalik viết lại lịch sử trong vụ DAO hack và việc Satoshi không “đào trước” Bitcoin, không tham sân si mưu lợi cá nhân, hay việc ông ta tự động rút lui, biến mất để bảo đảm tính trung lập cho Bitcoin, sẽ thấy sự khác nhau một trời một vực trong tư tưởng. Trong genesis block của Bitcoin, Satoshi đã ám chỉ rõ sứ mệnh của Bitcoin: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”. Hệ thống ngân hàng trung ương, hệ thống tiền tệ thế giới quá thối nát, Bitcoin sinh ra để chống lại và thay đổi những điều bất công vô lý đó. Còn sứ mệnh Ethereum là gì? máy tính chung của thế giới? không đề cập gì đến vấn đề tiền tệ, là trọng yếu của cuộc cách mạng blockchain. Từ cái tư tưởng sai lầm ngay từ lúc hình thành, Ethereum đã liên tục mắc lỗi trong thiết kế và những quyết định quan trọng. Giờ đây, ngay cả khi Vitalik nói không còn quyền lực thao túng Ethereum như trước nữa (đã ăn no kiếm tiền đủ từ những phi vụ trước, ha!), thì sức ảnh hưởng của Vitalik và Ethereum Foundation trong sự chèo lái Ethereum trên thực tế là không bao giờ mất (sẽ nói thêm ở dưới).
Đây cũng là câu hỏi lớn đặt ra cho những dự án blockchain khác: các founders có sẵn sàng “lui vào bóng tối” như Satoshi, để vận mệnh của đứa con tinh thần của mình hoàn toàn trôi lạc theo cộng đồng hay không? Hay là mang mác phân tán nhưng thực ra vẫn giữ những chìa khoá chủ chốt, để lúc nào muốn bật/tắt blockchain là bật/tắt như cái quạt trần, muốn sửa blockchain theo ý mình là sửa (có thể bị tổ chức khác đe doạ, thao túng), như Vitalik đã từng làm để bảo vệ lợi ích nhóm? Rất ít dự án blockchain nào làm được điều này.
6. Infura
Việc cho tất cả các dữ liệu hợp đồng lên blockchain khiến kích cỡ blockchain của Ethereum tăng trưởng với tốc độ chóng mặt. Sinh sau Bitcoin 6 năm nhưng giờ Ethereum blockchain đã cồng kềnh hơn Bitcoin blockchain gần gấp 3 lần. Ngày nay, rất ít cá nhân, tổ chức có thể tự chạy 1 Ethereum full node để kiểm chứng các giao dịch trên Ethereum, mà phải phụ thuộc vào server Infura của ConsenSys. Số lượng người có thể kiểm chứng được dữ liệu blockchain ngày càng nhỏ đi đồng nghĩa với việc blockchain dễ bị thao túng, không còn tính trung lập.
Khi Infura sập năm 2020 (đọc ở trên), các ứng dụng phổ biến nhất của Ethereum, hoá ra đều dựa vào Infura, cũng đã ngỏm củ tỏi theo.
7. Ice Age
Lịch trình phát triển của Ethereum ngay từ những ngày đầu đã có một khái niệm là “Ice Age” (thời kỳ đóng băng). Nôm na có nghĩa là, Ethereum cam kết sẽ chuyển sang hệ thống Proof-of-Stake trước ngày “nổ bom” (Difficulty Bomb), một ngày trong tương lai đã được định sẵn. Về lý thuyết, đây là việc các lập trình viên Ethereum tự tạo ra áp lực để Ethereum cải tiến hệ thống nhanh chóng.
Trên thực tế, Ice Age đã bị gián đoạn 3 lần: Byzantium (2017), Constantinople (2019) và Muir Glacier (2020). Và khái niệm “tự sát” này chỉ làm tăng sự tập trung quyền lực vào đội ngũ lập trình viên của Ethereum: chỉ có họ là được chọn ngày “nổ bom” hoặc dời ngày “nổ bom”.
Quyền lực tập trung vào nhóm lập trình viên nhỏ của Ethereum cũng là lý do những sự cố nghiêm trọng ở phía trên xảy ra, khi đội ngũ này đơn phương đưa ra những quyết định mạo hiểm cho hệ thống mà không cần tham khảo ý kiến của cộng đồng. Quyền lực tập trung này cũng là điều khiến Ethereum gần đây có thể bất thình lình thay đổi luật chơi: EIP-1559 sẽ cho phép “tiêu huỷ” ether, gây phẫn nộ trong cộng đồng đào Ether. Những gì Ethereum nói về sự phân tán, tóm lại chỉ là một màn diễn mà thôi.
Trên đây là một vài ví dụ tiêu biểu, còn nhiều vấn đề khác như phí giao dịch tăng cao (Tether đã phải bỏ Ethereum vì chi phí Ethereum giờ còn cao hơn cả Bitcoin), tắc nghẽn giao dịch, hay các vấn đề khi thay thế Proof-of-Work bằng Proof-of-Stake. Mình không tiện nói ở bài này.
(Theo Hugo Nguyen)