Tôi đã từng thêm tất cả mọi người vào một nhóm chat trước khi kiểm tra xem ai vẫn còn khả dụng khi công việc thực sự bắt đầu.
Sai sót nhỏ đó đã thay đổi cách tôi đọc thiết kế người thách thức của @BabylonLabs_io.
Một Hầm Bitcoin Không Cần Tin Tưởng không đợi đến khi có tranh chấp mới quyết định ai được tham gia. Người khởi kiện và người thách thức được cố định ngay khi hầm được tạo ra, vì quy trình tranh chấp bằng mạch xáo trộn (garbled-circuit) hoạt động giữa các bên đã được xác định trước.
Điều đó khiến đồ thị giao dịch trở nên dự đoán được.
Nhưng đồng thời, nó chuyển việc bảo mật thành một danh sách đội hình được chọn trước khi các điều kiện trong tương lai được biết đến.
Rủi ro ẩn không nằm ở việc BABY có người thách thức hay không.
Mà là liệu những người thách thức phù hợp có còn hoạt động khi cuối cùng họ được cần đến hay không.
Một tập Người Thách Thức Phổ Quát (Universal Challenger) phiên bản tĩnh có thể giảm bất định và ngăn các tác nhân ngẫu nhiên chen vào các đường đi then chốt. Nhưng nếu tư cách thành viên không theo cơ chế không cần cấp phép, thì BABY có thể thay thế nhanh đến mức nào một người vận hành bị chậm, thiếu kinh phí hoặc không khả dụng? Và điều gì xảy ra với các hầm cũ khi hạ tầng giám sát mạnh hơn tiến đến phiên bản sổ đăng ký (registry) mới?
Một số thành viên cố định là hợp lý. Tham gia hoàn toàn mở có thể tạo ra spam, trách nhiệm không rõ ràng và thất bại trong phối hợp.
Tuy vậy, việc chọn trước các người phòng thủ sẽ chuyển một phần bảo mật của Babylon từ mật mã sang tính sẵn sàng dài hạn. Hệ thống chứng minh có thể vẫn đúng về mặt logic, trong khi những người tham gia mà kỳ vọng sẽ kích hoạt nó dần dần biến mất.
Tôi không nghĩ điều đó làm “BABY” bị phá vỡ.
Tôi đang theo dõi xem Babylon có thể giữ một cấu trúc tranh chấp cố định mà không để danh sách người tham gia của hôm qua trở thành nút thắt về tính sống còn (liveness) của ngày mai hay không.
@BabylonLabs_io $BABY #baby
Sai sót nhỏ đó đã thay đổi cách tôi đọc thiết kế người thách thức của @BabylonLabs_io.
Một Hầm Bitcoin Không Cần Tin Tưởng không đợi đến khi có tranh chấp mới quyết định ai được tham gia. Người khởi kiện và người thách thức được cố định ngay khi hầm được tạo ra, vì quy trình tranh chấp bằng mạch xáo trộn (garbled-circuit) hoạt động giữa các bên đã được xác định trước.
Điều đó khiến đồ thị giao dịch trở nên dự đoán được.
Nhưng đồng thời, nó chuyển việc bảo mật thành một danh sách đội hình được chọn trước khi các điều kiện trong tương lai được biết đến.
Rủi ro ẩn không nằm ở việc BABY có người thách thức hay không.
Mà là liệu những người thách thức phù hợp có còn hoạt động khi cuối cùng họ được cần đến hay không.
Một tập Người Thách Thức Phổ Quát (Universal Challenger) phiên bản tĩnh có thể giảm bất định và ngăn các tác nhân ngẫu nhiên chen vào các đường đi then chốt. Nhưng nếu tư cách thành viên không theo cơ chế không cần cấp phép, thì BABY có thể thay thế nhanh đến mức nào một người vận hành bị chậm, thiếu kinh phí hoặc không khả dụng? Và điều gì xảy ra với các hầm cũ khi hạ tầng giám sát mạnh hơn tiến đến phiên bản sổ đăng ký (registry) mới?
Một số thành viên cố định là hợp lý. Tham gia hoàn toàn mở có thể tạo ra spam, trách nhiệm không rõ ràng và thất bại trong phối hợp.
Tuy vậy, việc chọn trước các người phòng thủ sẽ chuyển một phần bảo mật của Babylon từ mật mã sang tính sẵn sàng dài hạn. Hệ thống chứng minh có thể vẫn đúng về mặt logic, trong khi những người tham gia mà kỳ vọng sẽ kích hoạt nó dần dần biến mất.
Tôi không nghĩ điều đó làm “BABY” bị phá vỡ.
Tôi đang theo dõi xem Babylon có thể giữ một cấu trúc tranh chấp cố định mà không để danh sách người tham gia của hôm qua trở thành nút thắt về tính sống còn (liveness) của ngày mai hay không.
@BabylonLabs_io $BABY #baby