Sự cố Cloudflare: Vạch trần lớp vỏ phi tập trung giả tạo của ngành công nghiệp tiền mã hóa

4 sự cố lớn trong 18 tháng, tại sao bài toán tập trung hóa vẫn chưa có lời giải?

Nguồn: rekt news

Biên dịch: Saoirse, Foresight News

Ngày 18 tháng 11 năm 2025, 6:20 sáng theo giờ miền Đông nước Mỹ. Nhiều người trong chúng ta đã gặp phải sự cố mạng.

Không phải là sự cố ngắt quãng dần dần, cũng không có bất kỳ dấu hiệu cảnh báo nào. Một giây trước bạn vẫn đang lướt điện thoại, giao dịch, trò chuyện với AI, giây sau, mọi nơi bạn nhìn thấy gần như đều là trang lỗi 500.

Twitter đột ngột sập khi đang đăng bài, ChatGPT ngừng phản hồi giữa cuộc trò chuyện, Claude thì bị treo cứng.

Ngay cả Downdetector—trang web bạn thường kiểm tra khi các nền tảng khác gặp sự cố—cũng không thể tải, không thể cho bạn biết rằng “tất cả dịch vụ đều đã sập”.

20% lưu lượng mạng toàn cầu bỗng dưng biến mất, chỉ vì Cloudflare—đơn vị lẽ ra bảo vệ Internet khỏi các cuộc tấn công—lại vô tình “tấn công” chính mình.

Một thay đổi cấu hình thông thường (cập nhật quyền truy cập cơ sở dữ liệu) đã kích hoạt một lỗ hổng ẩn trong hệ thống bảo vệ bot của họ, trong chớp mắt, “người gác cổng” này đã chặn tất cả mọi người.

Tháng 10, khi dịch vụ đám mây Amazon (AWS) khiến Coinbase bị ngắt kết nối, người dùng Twitter trong lĩnh vực tiền mã hóa còn chế giễu gay gắt nhược điểm của “tập trung hóa”.

Nhưng đến khi sự cố Cloudflare bùng nổ vào tháng 11 thì sao? Ít nhất trong vài giờ đầu tiên, cả cộng đồng crypto đều im lặng.

Suy cho cùng, khi hạ tầng mà Twitter dựa vào cũng đã sập, bạn chẳng thể nào bàn luận về “tính mong manh của hạ tầng” trên Twitter được nữa.

Nhiều dịch vụ quan trọng bị đình trệ (hệ thống giao thông tê liệt), giao diện mạng của một số doanh nghiệp gặp sự cố, các trình duyệt blockchain như Arbiscan, DeFiLlama cũng liên tục hiện lỗi 500—nhưng bản thân blockchain không hề có dấu hiệu gián đoạn đồng thuận nào.

Khi cuộc “cách mạng phi tập trung” mà bạn tự hào lại bị đình trệ chỉ vì một file cấu hình của một công ty quá lớn, vậy ai mới là người thực sự kiểm soát mọi thứ?

Dòng thời gian sự cố: Từ “thay đổi cấu hình” đến “toàn mạng sập”

11:05 UTC: Triển khai xong thay đổi kiểm soát truy cập cơ sở dữ liệu.

23 phút sau, tức 11:28 UTC, thay đổi này lan tới môi trường người dùng, lần đầu tiên ghi nhận lỗi trong lưu lượng HTTP của người dùng.

Nói cách khác: Sự cố đã xảy ra, chỉ là lúc đó chưa ai biết vấn đề nằm ở đâu.

Đến 11:48 UTC, trang trạng thái chính thức của Cloudflare cuối cùng cũng thừa nhận “dịch vụ nội bộ gặp sự cố”—ngôn ngữ doanh nghiệp này thực chất có nghĩa là: “Mọi thứ đã rối tung, và ai cũng nhận ra điều đó.”

Hiệu ứng dây chuyền đến bất ngờ: Thay đổi này phá vỡ lớp quản lý bot của Cloudflare, khi hệ thống tải một file chức năng có kích thước gấp đôi, dịch vụ proxy của họ lập tức “sập”.

Hệ thống hạ nguồn cũng sụp đổ: Workers KV (dịch vụ lưu trữ key-value) và Access (dịch vụ kiểm soát truy cập) không thể kết nối với proxy; tỷ lệ lỗi toàn mạng tăng vọt, khi công cụ giám sát bị quá tải, mức sử dụng CPU cũng đạt đỉnh.

Lưu lượng vẫn liên tục đổ về các node biên của Cloudflare—nhưng dịch vụ proxy đã không còn phản hồi.

Ban đầu Cloudflare tưởng mình đang bị tấn công, và là một cuộc tấn công từ chối dịch vụ phân tán (DDoS) quy mô cực lớn.

Kỳ lạ hơn, ngay cả trang trạng thái chính thức được lưu trữ hoàn toàn ngoài hạ tầng Cloudflare cũng đồng thời bị tê liệt, khiến các kỹ sư nghi ngờ: Đây là một cuộc tấn công phối hợp nhắm vào hệ thống lõi và hệ thống giám sát của họ.

Nhưng thực tế không phải vậy. Họ không bị tấn công từ bên ngoài, vấn đề nằm ở chính họ.

Ngay sau khi dịch vụ được khôi phục, CTO của Cloudflare, Dane Knecht, đã công khai xin lỗi, cho rằng sự cố này “hoàn toàn không thể chấp nhận được”, và đổ lỗi cho một thay đổi cấu hình thông thường—chính thay đổi này đã kích hoạt sự sụp đổ của lớp bảo vệ bot.

“Chúng tôi đã phụ lòng khách hàng, cũng như người dùng Internet rộng lớn hơn,” Knecht viết trong tuyên bố, “Một lỗ hổng tiềm ẩn trong dịch vụ hỗ trợ chức năng bảo vệ bot của chúng tôi đã bất ngờ sụp đổ sau một thay đổi cấu hình thông thường, gây ra sự cố diện rộng cho mạng lưới và các dịch vụ khác. Đây không phải là một cuộc tấn công từ bên ngoài.”

Trong thời kỳ đỉnh điểm của sự cố, nền tảng Downdetector nhận được tới 11.183 báo cáo lỗi.

“Bóng tối số” này kéo dài hơn 5 tiếng rưỡi, đến 17:06 UTC dịch vụ mới hoàn toàn phục hồi; tuy nhiên, ngay từ 14:30, khi file cấu hình quản lý bot đúng được triển khai toàn cầu, ảnh hưởng nghiêm trọng nhất đã được giảm thiểu.

Tác động của sự cố: Từ Web2 đến lĩnh vực crypto, không ai thoát khỏi

Nền tảng Web2 chịu ảnh hưởng đầu tiên

Nền tảng X nhận được 9.706 báo cáo lỗi.

Người dùng không còn thấy timeline quen thuộc, thay vào đó là thông báo lỗi “Oops, đã xảy ra sự cố”.

ChatGPT đột ngột “im lặng” giữa cuộc trò chuyện, không phản hồi bất kỳ lệnh nào.

Dịch vụ phát nhạc trực tuyến Spotify bị gián đoạn, nền tảng thiết kế Canva từ chối truy cập của các nhà thiết kế, Uber và Door Dash (nền tảng giao đồ ăn) cũng lần lượt gặp sự cố chức năng.

Ngay cả game thủ cũng không thoát, người chơi Liên Minh Huyền Thoại bị ngắt kết nối giữa trận.

Thậm chí có tin cho biết, máy tự phục vụ của McDonald’s cũng hiện lỗi—đúng vào giờ cao điểm ăn trưa và lúc hạ tầng gặp sự cố.

Lĩnh vực tiền mã hóa cũng không thể “bình yên vô sự”.

Nền tảng crypto ngưng trệ diện rộng

Giao diện người dùng của Coinbase hoàn toàn sập, người dùng chỉ thấy trang đăng nhập không thể tải.

Trang web và ứng dụng di động của Kraken đều “chết” cùng lúc—đây là hậu quả trực tiếp của sự cố Cloudflare toàn cầu.

BitMEX đăng thông báo trên trang trạng thái: “Đang điều tra nguyên nhân sự cố, hiệu suất nền tảng giảm, nhưng tài sản người dùng vẫn an toàn.”—kịch bản tương tự, chỉ khác sàn giao dịch.

Etherscan không thể tải, Arbiscan thì sập hoàn toàn.

Bảng phân tích dữ liệu của DeFiLlama thỉnh thoảng xuất hiện lỗi máy chủ nội bộ.

Thậm chí Ledger cũng thông báo rằng, do ảnh hưởng từ sự cố Cloudflare, một số dịch vụ bị giảm khả năng truy cập.

“Ngoại lệ” duy nhất: Bản thân giao thức blockchain

Nhưng các hệ thống sau không bị ảnh hưởng:

Theo báo cáo, các sàn giao dịch lớn như Binance, OKX, Bybit, Crypto.com, KuCoin không gặp sự cố giao diện, giao dịch on-chain vẫn diễn ra bình thường—trong khi đó, bản thân blockchain vẫn vận hành hoàn hảo, không có dấu hiệu gián đoạn đồng thuận.

Giao thức blockchain luôn vận hành độc lập—vấn đề không nằm ở on-chain, mà nằm ở hạ tầng Web2 mà người dùng sử dụng để truy cập blockchain.

Nếu blockchain vẫn hoạt động, nhưng không ai có thể truy cập, vậy crypto thực sự còn “online” không?

Phân tích chuyên sâu: Một truy vấn cơ sở dữ liệu, tại sao có thể làm tê liệt 20% mạng lưới?

Cloudflare không lưu trữ website, cũng không cung cấp dịch vụ máy chủ đám mây như AWS.

Vai trò của họ là “người trung gian”—nằm giữa người dùng và Internet, phục vụ cho 24 triệu website, xử lý 20% lưu lượng mạng toàn cầu thông qua các node tại 120 quốc gia, 330 thành phố.

Thông điệp quảng cáo của Cloudflare là: Họ tự định vị mình là “lá chắn và bộ tăng tốc của Internet”, cung cấp bảo vệ DDoS 24/7, bảo vệ bot, định tuyến lưu lượng, tường lửa ứng dụng web toàn cầu (WAF), kết thúc TLS, điện toán biên dựa trên Workers và dịch vụ DNS—tất cả đều chạy trên một mạng lưới “bảo mật-hiệu suất” thống nhất.

Thực tế là: Họ chiếm 82% thị phần bảo vệ DDoS, tổng băng thông node biên đạt 449 Tbps, kết nối với nhiều nhà cung cấp dịch vụ Internet (ISP) và nhà cung cấp dịch vụ đám mây lớn trên thế giới.

Vấn đề cốt lõi: Khi tổ chức trung gian gặp sự cố, tất cả dịch vụ phía sau sẽ đồng thời trở nên “không thể tiếp cận”.

CTO Cloudflare Dane Knecht thẳng thắn trên nền tảng X:

“Tôi sẽ nói thẳng: Sáng nay, do sự cố mạng Cloudflare, lượng lớn lưu lượng phụ thuộc vào chúng tôi đã bị ảnh hưởng, chúng tôi đã phụ lòng khách hàng cũng như người dùng Internet rộng lớn hơn.”

CEO Matthew Prince còn trực diện hơn:

“Hôm nay là sự cố nghiêm trọng nhất của Cloudflare kể từ năm 2019... Hơn 6 năm qua, chúng tôi chưa từng gặp sự cố nào khiến phần lớn lưu lượng cốt lõi không thể truyền qua mạng lưới của mình.”

Gốc rễ kỹ thuật của sự cố

Mọi thứ bắt đầu từ một cập nhật quyền truy cập cơ sở dữ liệu thông thường. 11:05 UTC, Cloudflare thực hiện thay đổi trên cụm cơ sở dữ liệu ClickHouse nhằm tăng cường bảo mật và độ tin cậy—cho phép người dùng vốn chỉ có “quyền truy cập ngầm định” có thể “rõ ràng” xem metadata của bảng.

Vấn đề nằm ở đâu? Truy vấn cơ sở dữ liệu tạo file cấu hình dịch vụ bảo vệ bot của Cloudflare không lọc theo “tên cơ sở dữ liệu”.

Câu truy vấn quản lý lưu lượng đe dọa bắt đầu trả về các mục trùng lặp—một từ cơ sở dữ liệu mặc định, một từ cơ sở dữ liệu lưu trữ r0 bên dưới. Điều này khiến file chức năng tăng gấp đôi kích thước, từ khoảng 60 đặc trưng lên hơn 200 đặc trưng.

Cloudflare từng đặt giới hạn cứng cho việc cấp phát bộ nhớ là 200 đặc trưng, cho rằng “điều này cao hơn nhiều so với mức sử dụng thực tế khoảng 60 đặc trưng hiện tại”. Đây là tư duy kỹ thuật điển hình: đặt một biên an toàn tưởng như “rộng rãi”, cho đến khi sự cố xảy ra.

File vượt quá kích thước kích hoạt giới hạn này, mã Rust sập ngay, báo lỗi: “thread fl2_worker_thread panicked: called Result::unwrap () on an Err value” (luồng fl2_worker_thread bị sập: gọi Result::unwrap () trên một giá trị lỗi).

Hệ thống bảo vệ bot là thành phần cốt lõi của lớp kiểm soát Cloudflare. Khi nó sập, hệ thống kiểm tra sức khỏe dùng để báo cho bộ cân bằng tải “máy chủ nào đang hoạt động bình thường” cũng “mất tác dụng”.

Tệ hơn: File cấu hình này được tạo lại mỗi 5 phút.

Chỉ khi câu truy vấn chạy trên “node cụm đã cập nhật” mới tạo ra dữ liệu lỗi. Vì vậy, cứ mỗi 5 phút, mạng Cloudflare lại chuyển đổi giữa “bình thường” và “sự cố”—lúc thì tải file đúng, lúc thì tải file lỗi.

Việc “nhảy qua lại” này khiến các kỹ sư tưởng rằng đang bị tấn công DDoS—lỗi nội bộ thường không gây ra vòng lặp “phục hồi rồi lại sập”.

Cuối cùng, tất cả node ClickHouse đều cập nhật xong, mỗi lần tạo file đều là file lỗi. “Nhảy qua lại” dừng lại, thay vào đó là “sự cố hoàn toàn và ổn định”.

Không có tín hiệu hệ thống chính xác, hệ thống mặc định chuyển sang “chế độ bảo thủ”, coi phần lớn máy chủ là “không khỏe mạnh”. Lưu lượng vẫn đổ về, nhưng không thể được định tuyến đúng.

Các node biên Cloudflare vẫn nhận được yêu cầu từ người dùng—nhưng không thể xử lý bất kỳ yêu cầu nào.

“Đây không phải là một cuộc tấn công từ bên ngoài,” Knecht nhấn mạnh nhiều lần, “Không có hành vi ác ý, cũng không phải DDoS. Chỉ là một truy vấn cơ sở dữ liệu thiếu điều kiện lọc, lại trùng với cập nhật quyền truy cập, cuối cùng gây ra sự cố.”

Cloudflare từng cam kết “99,99% khả dụng”—nhưng lần này, lời hứa đã không thành hiện thực.

Đúng là như vậy.

Lịch sử lặp lại: 4 sự cố lớn trong 18 tháng, tại sao bài toán tập trung hóa vẫn chưa có lời giải?

Ngày 20 tháng 10 năm 2025—Sự cố AWS kéo dài 15 giờ. DNS của cơ sở dữ liệu DynamoDB khu vực Đông Mỹ 1 gặp lỗi, khiến Coinbase bị đóng băng, Robinhood lag, Infura ngừng dịch vụ (ảnh hưởng đến MetaMask), các mạng blockchain như Base, Polygon, Optimism, Arbitrum, Linea, Scroll đều offline. Dù tài sản người dùng trên chain vẫn an toàn, nhưng nhiều người chỉ thấy số dư tài khoản là “0”.

Ngày 29 tháng 10 năm 2025—Sự cố Microsoft Azure. Azure Front Door (cổng trước) gặp vấn đề đồng bộ cấu hình, khiến bộ ứng dụng văn phòng Microsoft 365 offline, Xbox Live sập, dịch vụ doanh nghiệp bị gián đoạn.

Tháng 7 năm 2024—Gói cập nhật Windows của CrowdStrike (công ty bảo mật) có lỗ hổng. Sự cố này khiến các chuyến bay bị hoãn, quy trình y tế bệnh viện bị trì hoãn, dịch vụ tài chính bị đóng băng, mất nhiều ngày mới hoàn toàn phục hồi.

Tháng 6 năm 2022—Sự cố lớn gần nhất của Cloudflare. Nhiều sàn giao dịch crypto buộc phải tạm ngừng dịch vụ—kịch bản tương tự, chỉ khác năm.

Tháng 7 năm 2019—Sự cố Cloudflare trước đó. Coinbase offline, CoinMarketCap không thể truy cập—đây là “tín hiệu cảnh báo” đầu tiên bị tất cả mọi người bỏ qua.

Chỉ trong 18 tháng, đã xảy ra 4 sự cố hạ tầng lớn.

Bốn sự cố, cùng một bài học: Hạ tầng tập trung chắc chắn dẫn đến “sự cố tập trung”.

Bốn sự cố, lẽ ra có thể thúc đẩy ngành crypto chuyển đổi sang phi tập trung—nhưng đến nay vẫn phụ thuộc vào hạ tầng của ba công ty.

Phải trải qua bao nhiêu cảnh báo, ngành mới chuyển từ “giả định sự cố có thể xảy ra” sang “xây dựng hệ thống theo tiêu chuẩn sự cố chắc chắn xảy ra”?

“Lời nói dối” phi tập trung: Giao thức phi tập trung không đồng nghĩa với truy cập phi tập trung

Họ từng vẽ ra cho bạn một viễn cảnh như sau:

“Tài chính phi tập trung, tiền tệ chống kiểm duyệt, hệ thống không cần tin tưởng, không điểm lỗi đơn lẻ, ‘không phải private key của bạn thì không phải coin của bạn’, code là luật.”

Nhưng thực tế ngày 18 tháng 11 đã giáng một đòn mạnh: Chỉ một buổi sáng Cloudflare gặp sự cố, một phần dịch vụ của ngành crypto đã tê liệt hàng giờ liền.

Sự thật về mặt kỹ thuật:

Không có giao thức blockchain nào được báo cáo gặp sự cố. Mạng Bitcoin hoạt động bình thường, mạng Ethereum cũng vậy—bản thân chain không có vấn đề gì.

Thực tế khi sử dụng:

Giao diện sàn giao dịch sập, trình duyệt blockchain tê liệt, giao diện ví không hoạt động, nền tảng phân tích dữ liệu sập, giao diện giao dịch hiện lỗi 500.

Người dùng không thể truy cập blockchain “phi tập trung” mà lẽ ra họ “sở hữu”. Giao thức vận hành bình thường—miễn là bạn có thể “chạm tới” nó.

Những nhận định sau đây có thể khiến nhiều người khó chịu…

COO SovereignAI David Schwed thẳng thắn chỉ ra:

“Sự cố Cloudflare hôm nay, sự cố AWS vài tuần trước, cho thấy rõ: Chúng ta không thể đơn giản giao phó ‘khả năng chống sự cố’ của hạ tầng cho một nhà cung cấp duy nhất. Nếu tổ chức của bạn cần vận hành 24/7, bạn phải xây dựng hạ tầng theo tiêu chuẩn ‘sự cố chắc chắn xảy ra’. Nếu kế hoạch liên tục kinh doanh của bạn chỉ có ‘chờ nhà cung cấp khôi phục dịch vụ’, đó là sự cẩu thả thuần túy.”

“Sự cẩu thả thuần túy”—không phải bất cẩn, không phải sơ suất, mà là cẩu thả.

Jameson Lopp nhận xét rất xác đáng:

“Chúng ta sở hữu một công nghệ phi tập trung tuyệt vời, nhưng lại khiến nó cực kỳ mong manh vì tập trung phần lớn dịch vụ vào một vài nhà cung cấp.”

Ben Schiller từng nói về sự cố AWS, nay vẫn còn nguyên giá trị:

“Nếu blockchain của bạn bị offline vì sự cố AWS, nó hoàn toàn chưa đủ phi tập trung.”

Thay “AWS” bằng “Cloudflare”, bản chất vấn đề không hề thay đổi—ngành chưa bao giờ rút ra bài học.

Tại sao chọn “tiện lợi” thay vì “nguyên tắc”?

Tự xây dựng hạ tầng đồng nghĩa với: mua phần cứng đắt tiền, đảm bảo nguồn điện ổn định, duy trì băng thông riêng, thuê chuyên gia bảo mật, thực hiện dự phòng địa lý, xây dựng hệ thống phòng chống thảm họa, giám sát 24/7—mỗi thứ đều cần đầu tư lớn.

Còn dùng Cloudflare chỉ cần: nhấn một nút, nhập thông tin thẻ tín dụng, hoàn tất triển khai trong vài phút.

Bảo vệ DDoS do người khác lo, khả dụng do người khác đảm bảo, mở rộng do người khác xử lý.

Startup muốn “ra mắt nhanh”, quỹ đầu tư yêu cầu “hiệu quả vốn”—mọi người đều chọn “tiện lợi”, thay vì “khả năng chống sự cố”.

Cho đến khi “tiện lợi” không còn tiện lợi nữa.

Sự cố AWS tháng 10 đã gây ra cuộc tranh luận bất tận về “phi tập trung” trên Twitter.

Sự cố Cloudflare tháng 11 thì sao? Im lặng hoàn toàn.

Không phải vì “im lặng triết lý”, cũng không phải “lặng thinh sau suy ngẫm”.

Mà bởi: mọi người muốn than phiền, nhưng nền tảng thường dùng để than phiền (Twitter) cũng sập vì sự cố hạ tầng.

Khi “điểm lỗi đơn lẻ” lại chính là nền tảng bạn dùng để chế giễu “điểm lỗi đơn lẻ”, bạn chẳng còn nơi nào để than phiền.

Khi tầng truy cập phụ thuộc vào hạ tầng của ba công ty, trong đó hai công ty gặp sự cố chỉ trong cùng một tháng, “phi tập trung ở tầng giao thức” trở nên vô nghĩa.

Nếu người dùng không thể truy cập blockchain, vậy cái gọi là “phi tập trung” của chúng ta thực chất là “phi tập trung” cái gì?

Bài toán độc quyền: Ba công ty kiểm soát 60% thị trường đám mây, ngành crypto sẽ đi về đâu?

AWS kiểm soát khoảng 30% thị trường hạ tầng đám mây toàn cầu, Microsoft Azure chiếm 20%, Google Cloud chiếm 13%.

Ba công ty, kiểm soát hơn 60% hạ tầng đám mây hiện đại của Internet.

Ngành crypto lẽ ra là giải pháp cho “tập trung hóa”, nay lại phụ thuộc vào hạ tầng tập trung nhất thế giới.

Danh sách “phụ thuộc tập trung” của ngành crypto

• Coinbase—phụ thuộc AWS;
• Binance, BitMEX, Huobi, Crypto.com—đều phụ thuộc AWS;
• Kraken dù xây dựng hạ tầng trên AWS, vẫn bị ảnh hưởng bởi sự cố CDN (mạng phân phối nội dung) của Cloudflare.

Nhiều sàn giao dịch “phi tập trung” thực chất vẫn chạy trên hạ tầng tập trung.

Sự cố tháng 10 và tháng 11 còn có một điểm khác biệt quan trọng:

Khi AWS gặp sự cố, nền tảng X (Twitter cũ) vẫn hoạt động bình thường, người dùng crypto trên Twitter vẫn có thể chế giễu “tính mong manh của hạ tầng”.

Nhưng khi Cloudflare gặp sự cố, nền tảng X cũng sập theo.

Khi nền tảng bạn dùng để “chế giễu điểm lỗi đơn lẻ” lại chính là một phần của “điểm lỗi đơn lẻ”, bạn chẳng thể cười nổi.

Cảm giác châm biếm này khiến cuộc thảo luận ngành lẽ ra phải diễn ra lại tắc nghẽn ngay từ đầu.

Ba sự cố lớn trong 30 ngày, các cơ quan quản lý đã đặc biệt quan tâm.

Những vấn đề cốt lõi mà cơ quan quản lý cần đối mặt

• Những công ty này có phải là “tổ chức có tầm quan trọng hệ thống” không?
• Dịch vụ xương sống của Internet có nên được quản lý như “tiện ích công cộng” không?
• Khi tính chất “quá lớn để sụp đổ” kết hợp với hạ tầng công nghệ, sẽ phát sinh rủi ro gì?
• Nếu Cloudflare kiểm soát 20% lưu lượng mạng toàn cầu, điều này có cấu thành vấn đề độc quyền không?

Corinne Cath-Speth của tổ chức Điều 19 từng nói thẳng về sự cố AWS: “Khi một nhà cung cấp bị tê liệt, các dịch vụ quan trọng cũng offline theo—truyền thông không thể truy cập, các ứng dụng liên lạc an toàn như Signal ngừng hoạt động, hạ tầng hỗ trợ xã hội số sụp đổ. Chúng ta cần đa dạng hóa điện toán đám mây một cách cấp bách.”

Nói cách khác: Các chính phủ đang dần nhận ra, chỉ vài công ty cũng đủ khiến Internet đình trệ.

Thực ra, các giải pháp phi tập trung thay thế đã tồn tại từ lâu, chỉ là không ai muốn dùng.

Ví dụ như Arweave cho lưu trữ, IPFS cho truyền file phân tán, Akash cho tính toán, Filecoin cho lưu trữ phi tập trung.

Tại sao giải pháp phi tập trung “được khen nhưng không được dùng”?

Hiệu năng kém hơn giải pháp tập trung, độ trễ người dùng cảm nhận rõ rệt.

Tỷ lệ phổ cập cực thấp, so với trải nghiệm “nhấn nút ‘triển khai lên AWS’” thì quy trình sử dụng giải pháp phi tập trung phức tạp hơn nhiều.

Chi phí thường cao hơn so với thuê hạ tầng từ “ba ông lớn” (AWS, Azure, Google Cloud).

Thực tế là:

Xây dựng hạ tầng phi tập trung thực sự cực kỳ khó, vượt xa tưởng tượng.

Đa số dự án chỉ nói về “phi tập trung” mà hiếm khi thực hiện. Chọn giải pháp tập trung luôn là lựa chọn đơn giản, rẻ hơn—cho đến khi 4 sự cố trong 18 tháng xảy ra, mọi người mới nhận ra cái giá khổng lồ ẩn sau “đơn giản rẻ tiền”.

CEO OORT, tiến sĩ Max Li, trong bài viết gần đây trên CoinDesk, đã chỉ thẳng sự giả dối của ngành:

“Một ngành tự hào về ‘phi tập trung’, liên tục quảng bá ưu thế của nó, nhưng lại phụ thuộc nghiêm trọng vào nền tảng đám mây tập trung mong manh—đó chính là sự giả dối.”

Giải pháp ông đưa ra là: áp dụng chiến lược đám mây lai, để các sàn giao dịch phân tán hệ thống quan trọng lên mạng phi tập trung.

Nền tảng đám mây tập trung có lợi thế không thể thay thế về hiệu năng và quy mô—nhưng khi liên quan đến hàng tỷ đô la, mỗi giây giao dịch đều quan trọng, khả năng chống sự cố của nó kém xa giải pháp phân tán.

Chỉ khi cái giá của “tiện lợi” đủ lớn để thay đổi hành vi ngành, “nguyên tắc” mới thắng “tiện lợi”.

Rõ ràng, sự cố ngày 18 tháng 11 vẫn chưa đủ nghiêm trọng, sự cố AWS ngày 20 tháng 10 cũng chưa đủ, sự cố CrowdStrike tháng 7 năm 2024 cũng vậy.

Phải đến mức nào, “hạ tầng phi tập trung” mới từ “chủ đề bàn tán” thành “yêu cầu bắt buộc”?

Ngày 18 tháng 11, ngành crypto không “thất bại”—bản thân blockchain vận hành hoàn hảo.

Thứ thực sự “thất bại” là lời nói dối tự lừa dối tập thể của ngành: tưởng rằng có thể xây dựng “ứng dụng không thể ngăn cản” trên “hạ tầng có thể sập”; tưởng rằng khi ba công ty kiểm soát “cổng truy cập”, “chống kiểm duyệt” vẫn còn ý nghĩa thực tế; tưởng rằng khi một file cấu hình của Cloudflare có thể quyết định hàng triệu người có giao dịch được hay không, “phi tập trung” vẫn còn là phi tập trung thực sự.

Nếu blockchain vẫn tạo block, nhưng không ai có thể gửi giao dịch, vậy nó thực sự còn “online” không?

Ngành không có bất kỳ phương án dự phòng nào.

Khi gặp sự cố, chỉ có thể chờ Cloudflare sửa, chờ AWS khôi phục dịch vụ, chờ Azure vá lỗi.

Đó chính là “chiến lược phục hồi thảm họa” của ngành hiện tại.

Hãy thử tưởng tượng: Nếu danh tính số gắn chặt với blockchain, chuyện gì sẽ xảy ra?

Bộ Tài chính Mỹ đang thúc đẩy nhúng thông tin định danh vào hợp đồng thông minh, yêu cầu mọi tương tác DeFi đều phải KYC.

Khi sự cố hạ tầng xảy ra lần tới, người dùng sẽ không chỉ mất quyền giao dịch—mà còn mất khả năng “xác minh danh tính” trong hệ thống tài chính.

Sự cố 3 giờ sẽ biến thành 3 giờ “không thể tải giao diện xác minh người-máy”—chỉ vì dịch vụ xác minh chạy trên hạ tầng đã sập.

“Hàng rào an toàn” mà cơ quan quản lý muốn xây dựng, tiền đề là “hạ tầng luôn online”. Nhưng sự cố ngày 18 tháng 11 chứng minh, tiền đề này hoàn toàn không tồn tại.

Khi vấn đề “giám sát quá mức” trở nên rõ ràng, người làm công nghệ sẽ chuyển sang “bảo vệ quyền riêng tư”.

Có lẽ đã đến lúc đưa “khả năng chống sự cố của hạ tầng” vào phạm trù này.

Nó không nên là “điểm cộng tùy chọn”, mà phải là “yêu cầu nền tảng cho mọi thứ”—không có nó, mọi chức năng khác đều vô nghĩa.

Sự cố tiếp theo đang được ấp ủ—có thể từ AWS, có thể từ Azure, có thể từ Google Cloud, cũng có thể là sự cố lần hai của Cloudflare.

Có thể là tháng sau, cũng có thể là tuần sau. Hạ tầng không đổi, quan hệ phụ thuộc không đổi, cơ chế khuyến khích ngành cũng không đổi.

Chọn giải pháp tập trung vẫn là lựa chọn rẻ hơn, nhanh hơn, tiện hơn—cho đến khi nó không còn như vậy.

Khi Cloudflare thực hiện thay đổi cấu hình thông thường tiếp theo, kích hoạt lỗ hổng ẩn trong một dịch vụ quan trọng, chúng ta sẽ lại chứng kiến “kịch bản” quen thuộc: tràn ngập trang lỗi 500, giao dịch dừng toàn bộ, blockchain vẫn chạy nhưng không ai truy cập được, muốn đăng tweet bàn về “phi tập trung” nhưng Twitter đã sập, doanh nghiệp hứa “lần sau sẽ làm tốt hơn” nhưng chưa bao giờ thực hiện.

Mọi thứ sẽ không thay đổi, vì “tiện lợi” luôn thắng “phòng ngừa rủi ro”—cho đến khi cái giá của “tiện lợi” lớn đến mức không thể làm ngơ.

Lần này, “người gác cổng” sập 3 tiếng rưỡi.

Lần sau, sự cố có thể kéo dài hơn; lần sau, sự cố có thể xảy ra đúng lúc thị trường sụp đổ khi “mỗi giây giao dịch đều sống còn”; lần sau, hệ thống xác minh danh tính cũng có thể bị cuốn vào sự cố.

Khi hạ tầng bạn sống dựa vào sập đúng lúc bạn không thể thua, đó là lỗi của ai?

Nguồn dữ liệu: The Guardian, Johnny Popov, PC Magazine, IT Professional, CNBC, Cloudflare, TechCrunch, Associated Press, CoinDesk, Tom’s Hardware, Dane Knecht, Tom’s Guide, Surya, Sheep Esports, TheBlock, Kraken, BitMEX, Ledger, Blockchain News, Statista, Shout Computer, Jameson Lopp, Ben Schiller, Article 19, CoinTelegraph