Tối ngày 22/9, một người dùng đã thực hiện một giao dịch chuyển ATOM.

Qua một đêm, giao dịch vẫn nằm trong trạng thái "chờ xác nhận".

Private key không bị mất, ví cũng không có bất thường về chữ ký. Kiểm tra lại vào ngày hôm sau, nhiều RPC công khai đều hiển thị Cosmos Hub đang dừng ở độ cao block 33.086.740.

Không có block mới nào được tạo ra, đương nhiên cũng không có nơi nào có thể đóng gói giao dịch này vào.

Cho đến khoảng một ngày sau, khi Cosmos Hub khôi phục việc tạo block, giao dịch ATOM vốn vẫn đang trong trạng thái chờ này cuối cùng mới thành công.

Đối với người dùng bình thường, đây có thể là bài học trực quan nhất để hiểu về đồng thuận blockchain.

Chúng ta thường nói "không có bất kỳ tổ chức tập trung nào có thể tắt một public chain", nhưng thực tế rõ ràng phức tạp hơn nhiều. Một blockchain đủ phi tập trung thường thực sự không tồn tại "nút tắt máy" trong phòng server, nhưng nó vẫn có thể dừng lại.

Lần tạm dừng của Cosmos Hub này đã đưa toàn bộ cơ chế vốn thường ẩn dưới lớp nền tảng ra trước mắt người dùng bình thường một cách trọn vẹn.

1. Tại sao Cosmos đột nhiên "ngừng tạo block"?

Trước tiên cần làm rõ một vấn đề dễ gây nhầm lẫn: đối tượng bị tấn công trực tiếp lần này không phải là Cosmos Hub.

Sự việc ban đầu xảy ra tại Neutron.

Ngày 22/9, một đề xuất quản trị của Neutron có tên "AIATO: AI Agent Takeover" đã được thông qua. Kẻ tấn công đã lợi dụng lỗ hổng trong quyền quản trị cấp chuỗi, sử dụng các lệnh đặc quyền được cung cấp sẵn bởi framework wasmd để đổi địa chỉ quản trị viên hợp đồng của các ứng dụng như Astroport, Drop thành địa chỉ do kẻ tấn công kiểm soát.

Đây không phải là kiểu "lỗ hổng code" hay "khiếm khuyết giao thức" mà chúng ta thường hiểu.

Có thể hiểu đơn giản rằng, bản thân ứng dụng có "khóa cửa" riêng, nhưng quyền quản trị cấp chuỗi của Neutron còn nắm giữ một "chìa khóa tổng" có quyền hạn cao hơn. Và khi kẻ tấn công kiểm soát được kết quả quản trị, cũng đồng nghĩa với việc lấy được chìa khóa này, có thể chỉ định lại quản trị viên, di chuyển hợp đồng, từ đó chuyển dịch tài sản bên trong.

Điều thực sự khiến Cosmos Hub bị cuốn vào là hoạt động chuyển tài sản xuyên chuỗi diễn ra sau đó.

Theo đánh giá lại của Cosmos Labs, trước khi Neutron ngừng hoạt động, kẻ tấn công đã chuyển một phần tài sản sang nhiều mạng khác nhau, trong đó khoảng 1,7 triệu ATOM được chuyển vào Cosmos Hub và bắt đầu được đổi thông qua thanh khoản xuyên chuỗi.

Nói cách khác, bản thân Cosmos Hub không bị tấn công trực tiếp, tài sản của người dùng Hub thông thường cũng không bị đánh cắp trực tiếp do lỗ hổng Neutron.

Nhưng số ATOM có được từ tấn công đã đi vào Hub. Để ngăn phần ATOM còn lại tiếp tục chảy ra, một số validator của Cosmos Hub bắt đầu dừng vận hành node.

Đến khoảng 19:18 ngày 22/9 (SGT), các validator đã dừng vận hành đã đại diện cho hơn một phần ba tổng voting power, khiến Cosmos Hub không thể tiếp tục hình thành block mới, cuối cùng dừng ở 33.086.740.

Bước này rất quan trọng.

Nó có nghĩa là Cosmos Hub không tồn tại một nút "Pause" mà một công ty nào đó có thể nhấn trực tiếp, cũng không thông qua một cuộc bỏ phiếu quản trị on-chain trước. Điều thực sự khiến mạng dừng lại là việc đủ nhiều validator không còn tham gia hình thành đồng thuận.

Nhưng điều đáng chú ý hơn thực ra là quá trình khôi phục sau đó.

Khoảng 4 giờ sau khi chuỗi dừng, các validator nhận được một phương án khôi phục hoàn chỉnh: thực hiện một lần sửa đổi trạng thái một lần duy nhất tại độ cao dừng chuỗi, chuyển số ATOM còn lại trong địa chỉ kẻ tấn công vào địa chỉ multisig do các validator cộng đồng cùng quản lý.

Sau đó, Cosmos Labs dựa trên phương án mà các validator đã đạt được để tạo bản vá Gaia v28.3.0, tiến hành kiểm thử và phân phối cho các validator.

Phiên bản Gaia này sẽ thực hiện một thay đổi trạng thái một lần duy nhất tại độ cao khôi phục được chỉ định, chuyển 1.227.121 ATOM trong địa chỉ kẻ tấn công vào địa chỉ multisig 4-of-6 gồm sáu bên: Nansen, Keplr, Enigma, Silknodes, Kiln và Polkachu.

Đến rạng sáng ngày 23/9, các validator xác nhận đã cài đặt v28.3.0 đã vượt quá 67% tổng voting power. Do đó, vào 12:00 UTC cùng ngày, Cosmos Hub phối hợp khởi động lại. Khoảng 6 phút sau, thay đổi trạng thái một lần này được thực thi tại độ cao block 33.086.741, mạng lưới khôi phục việc tạo block bình thường.

Rốt cuộc, trong toàn bộ quá trình từ khi Cosmos ngừng tạo block đến khi khôi phục vận hành, các validator trước tiên khiến mạng mất Liveness, sau đó hơn hai phần ba voting power chấp nhận một bộ quy tắc chuyển đổi trạng thái mới, cuối cùng biến bộ quy tắc này thành canonical state sau khi khôi phục.

Đến đây, một câu hỏi tưởng chừng đơn giản cũng xuất hiện: Vì đây là một public chain phi tập trung, tại sao chỉ hơn một phần ba quyền validator đã có thể khiến nó dừng lại, còn để khôi phục mạng lưới lại cần đủ nhiều validator cùng chấp nhận và vận hành cùng một bộ phần mềm?

Câu trả lời thực ra nằm trong chính hai chữ "đồng thuận".

2. Cái gọi là đồng thuận, vốn dĩ không phải là "mãi mãi không bao giờ dừng"

Một trong những điều dễ bị hiểu sai nhất về blockchain là đánh đồng "phi tập trung" với "không bao giờ ngừng hoạt động".

Thực tế, vấn đề mà cơ chế đồng thuận thực sự giải quyết là trong điều kiện không có một người ghi sổ trung tâm, nhiều node làm thế nào để đạt được sự nhất trí về thứ tự giao dịch và trạng thái sổ cái.

Tuy nhiên, cách các public chain khác nhau thực hiện điều này không giống nhau.

Ví dụ kinh điển nhất của Bitcoin là PoW, tức proof of work — thợ đào dựa vào sức tính toán để cạnh tranh tạo block. Khi mạng lưới tạm thời xuất hiện hai nhánh hợp lệ, các node sẽ chọn một trong số đó để tiếp tục xây dựng theo tổng công việc tích lũy.

Vì vậy, Bitcoin không tồn tại một thời điểm rõ ràng kiểu "sau khi 67% bỏ phiếu thì block này mãi mãi Finalized". Nó gần với một dạng finality theo xác suất hơn. Càng nhiều block phía sau, muốn tổ chức lại các giao dịch trước đó sẽ càng cần chi phí sức tính toán cao hơn.

Đây cũng là lý do trước đây mọi người thường nói rằng một giao dịch Bitcoin tốt nhất nên chờ 6 block xác nhận. Rốt cuộc, dù sức tính toán có cao đến đâu, cũng không thể đơn giản bỏ qua các quy tắc đồng thuận mà node đang thực thi.

Tất nhiên, điều này không có nghĩa là trạng thái của Bitcoin trong mọi trường hợp đều "tuyệt đối không thể sửa đổi". Về mặt lý thuyết, nếu toàn bộ hệ sinh thái chấp nhận một bộ client mới và quy tắc đồng thuận mới, thông qua Hard Fork, cũng có thể khiến những thay đổi trạng thái vốn không hợp lệ theo quy tắc cũ trở nên hợp lệ.

Nhưng vấn đề nằm ở đây: ai có khả năng khiến đủ nhiều thợ đào, Full Node, sàn giao dịch, ví và người dùng cùng chấp nhận một bộ quy tắc mới như vậy?

Gần như không có ai.

Đội ngũ phát triển không thể thay toàn bộ mạng Bitcoin quyết định quy tắc đồng thuận, thợ đào và sàn giao dịch cũng rất khó, bởi ngưỡng đồng thuận cần vượt qua là cực kỳ cao. Khi Binance từng bị hack 7.000 BTC, có người đề xuất CZ liên hệ với các thợ đào lớn để xử lý, cuối cùng không có kết quả.

Ethereum lại cung cấp một mẫu kinh điển khác.

Sau khi chuyển sang PoS, Ethereum hiện tại sử dụng đồng thuận Gasper được tạo thành từ Casper FFG và LMD-GHOST. Hiểu đơn giản, một phần cơ chế chịu trách nhiệm xác định "hiện tại nên theo chuỗi nào", phần còn lại chịu trách nhiệm giúp block đạt được Finality theo đúng nghĩa.

Khi các validator đại diện cho ít nhất hai phần ba ETH staking đạt được nhất trí về checkpoint tương ứng, block mới có thể tiến thêm tới trạng thái được finalize. Ngược lại, nếu hơn một phần ba stake trong thời gian dài không tham gia bỏ phiếu đúng, mạng có thể tạm thời không thể hình thành Finality. Tuy nhiên Ethereum còn thiết kế inactivity leak, khi thời gian dài không thể finalizing sẽ dần giảm trọng số hiệu lực của các validator offline, để cuối cùng mạng có cơ hội khôi phục Finality.

Muốn thực sự thay đổi kết quả này, cũng cần thay đổi quy tắc giao thức và client.

Giống như sự kiện The DAO năm 2016, cộng đồng Ethereum cuối cùng đã thông qua Hard Fork, thực hiện tại block 1.920.000 một lần sửa đổi trạng thái đặc biệt mà Ethereum Foundation lúc đó gọi trực tiếp là irregular state change, chuyển số ETH liên quan vào hợp đồng khôi phục.

Chỉ có điều, một phần thợ đào và cộng đồng từ chối nâng cấp, tiếp tục duy trì trạng thái cũ, cuối cùng hình thành Ethereum Classic (ETC), dẫn đến sự kiện fork ETH và ETC mà ai cũng biết, cho thấy không phải tất cả mọi người đều chấp nhận bộ quy tắc này.

Cosmos Hub lại có điểm khác, nó sử dụng CometBFT, gần với đồng thuận BFT điển hình hơn.

Có thể hiểu nó là một dạng đồng thuận BFT điển hình hơn, tức là một block muốn thực sự được commit cần nhận được Commit từ hơn hai phần ba voting power.

Ưu điểm là Finality rất rõ ràng. Một khi block đã được đủ quyền validator bỏ phiếu commit, không cần giống PoW phải tiếp tục chờ ngày càng nhiều block để đổi xác suất lấy cảm giác an toàn.

Nhưng mặt còn lại cũng rất trực tiếp: nếu một phần ba hoặc hơn voting power không còn cung cấp số phiếu cần thiết để hình thành Commit, các validator còn lại dù cố gắng đến đâu cũng không thể gom đủ hơn hai phần ba.

Lúc này, lựa chọn an toàn nhất của mạng chính là "tạm dừng tạo block" như lần này. Vì vậy, từ góc độ hệ thống phân tán, việc Cosmos Hub tạm dừng ngắn lần này thực ra không hề thần bí.

Tóm lại một câu, sau khi một nhóm validator nắm đủ voting power ngừng tham gia, giao thức đồng thuận theo quy tắc của chính nó thà mất tính khả dụng còn hơn tiếp tục xác nhận block mới trong điều kiện thiếu đồng thuận đầy đủ.

Đằng sau điều này thực ra tương ứng với hai khái niệm trong hệ thống phân tán thường bị người dùng bình thường gộp chung:

• Safety: Không thể để các node khác nhau đồng thời xác nhận hai trạng thái cuối cùng xung đột với nhau;
• Liveness: Mạng còn có thể tiếp tục vận