Nhiều người thấy một giao thức đã bị hack, phản ứng đầu tiên là loại bỏ nó. Tôi ngày càng cảm thấy rằng, lịch sử sự cố của một giao thức là thông tin dễ bị hiểu sai nhất mà tôi có thể có.
Về Bedrock, tôi xem xét vấn đề một cách công khai. Trước khi nó phát triển hệ thống đa tài sản, PoSL 2.0, nó đã gặp phải hai sự cố: vào tháng 9 năm 2024, hợp đồng uniBTC đã xảy ra lỗi khai thác vượt mức, gây thiệt hại khoảng hai triệu đô la; vào tháng 6 năm 2025, lại gặp phải sự cố thanh khoản bị rút cạn, hơn hai mươi địa chỉ đã rút khoảng bốn mươi bảy triệu trong khoảng một trăm giây, giá coin lập tức bị cắt đôi. Hai khoản này kết hợp lại, thực sự xấu xí, bất kỳ ai nói "không sao" đều đang tô hồng.
Nhưng điều tôi thực sự muốn nói là cách đọc nó. Bị hack một lần và sự cố lần này thực sự cho bạn biết điều gì, là hai chuyện khác nhau. Tôi sẽ xem hai lần này có phải là cùng một loại vấn đề không — một lần là lỗi khai thác ở lớp hợp đồng, một lần là sự kiện thị trường ở lớp thanh khoản, bản chất không giống nhau, điều này cho thấy nó không phải là cùng một cái hố mà liên tục bị ngã. Hãy xem cách đội ngũ xử lý thời điểm đó: lần sự cố tháng Sáu, chính thức nhanh chóng công khai địa chỉ LP gặp vấn đề, đưa ra thanh khoản để bảo vệ, không giả vờ chết. Những hành động này, quan trọng hơn cả việc "đã xảy ra sự cố". Một giao thức chưa từng bị hack, đôi khi chỉ là chưa từng bị tấn công một cách nghiêm túc.
Vì vậy, @Bedrock , hai vết sẹo này, lại giúp tôi mài dũa ra một thước đo để đọc sự cố: đừng coi "bị hack" như một dấu X để loại bỏ, hãy xem ba điều — hai lần đó có phải cùng một loại bệnh không, đội ngũ lúc đó có đối mặt không, có chặn đứng loại lỗ hổng đó từ gốc không. Nếu ba điều này trả lời tốt, lịch sử sự cố là học phí mà nó đã trả; nếu không, đó mới thực sự là mối nguy cần tránh. $BR có đáng để tham gia không, hai sự cố này không phải là kết luận, mà là một bộ mẫu cho bạn thấy rõ hơn về chất lượng đội ngũ. Khả năng nó không bị vấp ngã cùng một kiểu lần nữa, quan trọng hơn nhiều so với việc nó đã từng bị ngã hay chưa. #bedrock $BR
Về Bedrock, tôi xem xét vấn đề một cách công khai. Trước khi nó phát triển hệ thống đa tài sản, PoSL 2.0, nó đã gặp phải hai sự cố: vào tháng 9 năm 2024, hợp đồng uniBTC đã xảy ra lỗi khai thác vượt mức, gây thiệt hại khoảng hai triệu đô la; vào tháng 6 năm 2025, lại gặp phải sự cố thanh khoản bị rút cạn, hơn hai mươi địa chỉ đã rút khoảng bốn mươi bảy triệu trong khoảng một trăm giây, giá coin lập tức bị cắt đôi. Hai khoản này kết hợp lại, thực sự xấu xí, bất kỳ ai nói "không sao" đều đang tô hồng.
Nhưng điều tôi thực sự muốn nói là cách đọc nó. Bị hack một lần và sự cố lần này thực sự cho bạn biết điều gì, là hai chuyện khác nhau. Tôi sẽ xem hai lần này có phải là cùng một loại vấn đề không — một lần là lỗi khai thác ở lớp hợp đồng, một lần là sự kiện thị trường ở lớp thanh khoản, bản chất không giống nhau, điều này cho thấy nó không phải là cùng một cái hố mà liên tục bị ngã. Hãy xem cách đội ngũ xử lý thời điểm đó: lần sự cố tháng Sáu, chính thức nhanh chóng công khai địa chỉ LP gặp vấn đề, đưa ra thanh khoản để bảo vệ, không giả vờ chết. Những hành động này, quan trọng hơn cả việc "đã xảy ra sự cố". Một giao thức chưa từng bị hack, đôi khi chỉ là chưa từng bị tấn công một cách nghiêm túc.
Vì vậy, @Bedrock , hai vết sẹo này, lại giúp tôi mài dũa ra một thước đo để đọc sự cố: đừng coi "bị hack" như một dấu X để loại bỏ, hãy xem ba điều — hai lần đó có phải cùng một loại bệnh không, đội ngũ lúc đó có đối mặt không, có chặn đứng loại lỗ hổng đó từ gốc không. Nếu ba điều này trả lời tốt, lịch sử sự cố là học phí mà nó đã trả; nếu không, đó mới thực sự là mối nguy cần tránh. $BR có đáng để tham gia không, hai sự cố này không phải là kết luận, mà là một bộ mẫu cho bạn thấy rõ hơn về chất lượng đội ngũ. Khả năng nó không bị vấp ngã cùng một kiểu lần nữa, quan trọng hơn nhiều so với việc nó đã từng bị ngã hay chưa. #bedrock $BR