Một điều khiến tôi ngừng cuộn là không phải chính lỗi. Mà là dòng nói rằng “cửa sổ race chỉ tồn tại giữa một lần đọc từ cơ sở dữ liệu và một lần ghi vào cơ sở dữ liệu”. Nó trông như một chi tiết triển khai nhỏ, cho đến khi tôi bắt đầu suy nghĩ về điều mà nó nói lên về mô hình thực thi của Babylon.
Tôi ngừng tìm một kẻ tấn công và bắt đầu nhìn vào luồng hoạt động. Tôi quay lại để so sánh đường đi của việc xác thực và mất một thời gian để lần theo xem các thay đổi trạng thái thực sự trở thành “kết luận cuối cùng” ở đâu. Sau đó tôi lấy một ly cà phê và đọc lại trình tự một lần nữa. Càng nhìn thì cảm giác này càng không chỉ đơn thuần là một vấn đề bảo mật. Nó giống như một lựa chọn thiết kế về mức rủi ro liên quan đến thời gian mà giao thức sẵn sàng chấp nhận.
Điều dần dần trở nên rõ ràng là cơ chế bảo vệ không được xây dựng nhằm làm cho “race” trở nên không thể. Nó được xây dựng để làm cho cơ hội xảy ra race cực kỳ nhỏ. Đó là hai ý khác nhau. Ý thứ nhất loại bỏ điều kiện. Ý thứ hai làm giảm xác suất. Sự khác biệt này rất dễ bị bỏ sót vì cả hai đều có thể trông “an toàn” từ bên ngoài.
Đó là phần không ai đưa vào slide. Babylon phụ thuộc vào việc các validator và các dịch vụ xử lý trạng thái theo một trật tự dự đoán được, trong khi vẫn chấp nhận rằng vẫn tồn tại một khoảng trống thực thi rất nhỏ. Về cơ bản, giao thức đang nói rằng chi phí vận hành để loại bỏ mọi khả năng race có thể là lớn hơn so với rủi ro còn lại khi để lại một cửa sổ hẹp.
Có lẽ đó là mức đánh đổi đúng cho hiệu năng. Có lẽ phần phơi nhiễm còn lại nhỏ đến mức việc thêm đồng bộ hóa sẽ gây ra vấn đề lớn hơn ở nơi khác.
Điều tôi vẫn chưa quyết định được là Babylon vạch ranh giới ở đâu giữa một giả định về thời gian có thể chấp nhận và một cam kết của giao thức—điều mà tuyệt đối không nên phụ thuộc vào thời gian.
@BabylonLabs_io
#baby $BABY
Tôi ngừng tìm một kẻ tấn công và bắt đầu nhìn vào luồng hoạt động. Tôi quay lại để so sánh đường đi của việc xác thực và mất một thời gian để lần theo xem các thay đổi trạng thái thực sự trở thành “kết luận cuối cùng” ở đâu. Sau đó tôi lấy một ly cà phê và đọc lại trình tự một lần nữa. Càng nhìn thì cảm giác này càng không chỉ đơn thuần là một vấn đề bảo mật. Nó giống như một lựa chọn thiết kế về mức rủi ro liên quan đến thời gian mà giao thức sẵn sàng chấp nhận.
Điều dần dần trở nên rõ ràng là cơ chế bảo vệ không được xây dựng nhằm làm cho “race” trở nên không thể. Nó được xây dựng để làm cho cơ hội xảy ra race cực kỳ nhỏ. Đó là hai ý khác nhau. Ý thứ nhất loại bỏ điều kiện. Ý thứ hai làm giảm xác suất. Sự khác biệt này rất dễ bị bỏ sót vì cả hai đều có thể trông “an toàn” từ bên ngoài.
Đó là phần không ai đưa vào slide. Babylon phụ thuộc vào việc các validator và các dịch vụ xử lý trạng thái theo một trật tự dự đoán được, trong khi vẫn chấp nhận rằng vẫn tồn tại một khoảng trống thực thi rất nhỏ. Về cơ bản, giao thức đang nói rằng chi phí vận hành để loại bỏ mọi khả năng race có thể là lớn hơn so với rủi ro còn lại khi để lại một cửa sổ hẹp.
Có lẽ đó là mức đánh đổi đúng cho hiệu năng. Có lẽ phần phơi nhiễm còn lại nhỏ đến mức việc thêm đồng bộ hóa sẽ gây ra vấn đề lớn hơn ở nơi khác.
Điều tôi vẫn chưa quyết định được là Babylon vạch ranh giới ở đâu giữa một giả định về thời gian có thể chấp nhận và một cam kết của giao thức—điều mà tuyệt đối không nên phụ thuộc vào thời gian.
@BabylonLabs_io
#baby $BABY