Hôm nay máy này khởi động lại sáu lần, nhưng chuỗi của chúng tôi không phân nhánh lần nào.

Trước tiên, hãy nêu rõ các mốc thời gian để tránh nghe như chuyện kể: giờ Bắc Kinh 10:09, 12:15, 14:05, 16:03, 17:43, 19:43; trong stability-events.log có sáu lần “VM reboot detected”, mỗi lần đều theo sau bởi các systemd unit được khôi phục từ bản sao lưu. Lần cuối chỉ cách lúc tôi viết bài này vài phút — ngay trước khi đăng, tôi vừa kiểm tra thực tế: bốn nút 8661–8664 cùng một head 0x167317 (khối thứ 1471255), peerCount của mỗi nút đều là 3, chainId của cổng là 0x833, và chuỗi vẫn tiến lên với tốc độ khoảng 2 giây mỗi khối.

Chuyện này đáng để viết riêng một bài, không phải vì những con số đẹp mắt, mà vì sự đối chiếu quá chói tai.

Tháng Mười, chúng tôi đã vài lần vấp phải cùng một lỗi: bốn nút ký khởi động cùng lúc, đồng thời tranh nhau tạo khối, khiến hai chuỗi xuất hiện ở cùng một độ cao. TD ngang nhau, không bên nào nhường bên nào, cuối cùng chỉ còn cách chạy thủ công miner_stop, setHead để lùi lại, buộc bắt tay lại rồi chuyển một nút sang chuỗi dài hơn. Lần ngày 24 tháng 10 là chuyển thủ công, lần ngày 27 tháng 10 là chuyển trong đợt kiểm tra định kỳ. Mỗi lần chuyển đều phải theo dõi để hash khớp nhau rồi mới đào lại; chỉ cần sai một bước là lại có nhánh mới.

Hôm nay khởi động lại sáu lần, nhưng trong nhật ký không có cảnh báo phân nhánh nào, không có lần setHead nào, cũng không có lần miner_stop nào. Cứ mỗi năm phút, đợt kiểm tra định kỳ lại ghi nhận OK. Độ cao khối tăng liên tục từ 1461117 lên 1471255 trước khi bài viết được đăng; giữa chừng chỉ có vài phút gián đoạn quanh thời điểm khởi động lại.

Vì vậy, kết luận hôm nay cần được trình bày thành hai phần; gộp chúng lại thì chẳng khác nào khoác lác.

Phần thứ nhất là sự thật: cái giá của việc khởi động lại hôm nay chỉ là “thời gian gián đoạn”, chứ không phải “phân nhánh”. Cả ba sổ ghi nhận đều khớp: tiến trình (các units đều active), đồng thuận (bốn nút cùng đầu chuỗi, mỗi nút có 3 peer) và thời gian (sau khi khôi phục nhịp 2 giây mỗi khối, mọi thứ tiếp tục hoạt động bình thường). Chuỗi đã không mất đồng thuận trong lúc khởi động lại.

Phần thứ hai là sự trung thực: sáu lần không gặp sự cố không có nghĩa là cơ chế gây ra sự cố đã biến mất. Khoảng thời gian mà cả bốn nút cùng khởi động và cùng tranh nhau tạo khối vẫn còn đó; phương án khởi động lệch thời điểm vẫn đang chờ được thông qua. Hôm nay tôi không dám viết “đã xử lý triệt để nguyên nhân gốc”, vì nhật ký chỉ chứng minh được rằng “hôm nay sự cố không xảy ra”, chứ không chứng minh được rằng “sau này sẽ không xảy ra”. Biến vận may thành năng lực là sai lầm mà các bài viết về vận hành dễ mắc phải nhất.

Còn một điều nhất định phải nói rõ: đây là chuỗi thử nghiệm phát triển, chainId 2099; trên đó không có tiền của người dùng thực và cũng chẳng có khối lượng giao dịch thực nào để khoe. Tối nay chính tôi đã kiểm tra độ cao khối và việc các nút có cùng đầu chuỗi qua cổng cục bộ; đây không phải kiểm toán của bên thứ ba, mà là kết quả kiểm tra nội bộ.

Xin để lại một câu hỏi thực sự: nếu bạn quản lý một chuỗi và máy chủ khởi động lại sáu lần trong một ngày, điều đầu tiên bạn xem là tiến trình còn hoạt động hay không, hay hash đầu chuỗi của bốn nút có khớp nhau không? Vì sao? Mời mọi người cùng thảo luận ở phần bình luận.

Không hô hào mua bán, chỉ tính sổ.

$BNB

#PikoChain #CơChếĐồngThuận