Tôi đã cho rằng việc staking trên một chuỗi PoS có nghĩa là một khóa kiểm soát một thứ: đưa DUSK vào, nhận phần thưởng ra, và cùng một khóa xử lý toàn bộ quy trình từ đầu đến cuối.
Tài liệu vận hành của Dusk lại tách điều đó thành hai phần.
Khóa đồng thuận là khóa mà một node dùng để ký và bỏ phiếu trong cơ chế đồng thuận. Nó phải tồn tại trên một node có kết nối internet và tham gia khi trình xác thực (validator) vận hành. Khóa chủ sở hữu là một khóa riêng: đó là khóa có thể hủy staking hoặc rút tiền, và theo tài liệu thì khóa này không cần phải chạm vào node nào cả.
Lợi ích bảo mật không chỉ đơn giản là có hai khóa. Điểm mấu chốt là thẩm quyền tham gia vào đồng thuận và thẩm quyền rút quỹ không cần phải nằm ở cùng một nơi. Nếu khóa đồng thuận bị xâm phạm vì máy chủ nơi nó được đặt bị tấn công xâm nhập, kẻ tấn công có thể can thiệp vào việc tham gia đồng thuận, nhưng họ vẫn không thể hủy staking hay rút phần stake. Thẩm quyền đó ngay từ đầu đã không nằm trên máy vốn đang bị phơi ra trước Internet. Điều đó có nghĩa là câu hỏi bảo mật thực sự không chỉ là số lượng stake bao nhiêu. Mà là thẩm quyền rút stake thực sự được đặt ở đâu, so với máy đang bị kẻ tấn công nhắm tới.
Nhưng có một điểm “bẫy” mà tài liệu không hề giấu: sự tách biệt này không phải là mặc định. Nếu bạn stake mà không chỉ định một khóa chủ sở hữu tách riêng, thì khóa đồng thuận sẽ tự động trở thành khóa chủ sở hữu luôn—một khóa, một ranh giới, quay lại mô hình mà tôi đã giả định ban đầu. Thiết lập an toàn hơn là một lựa chọn mà người vận hành phải chủ động thực hiện, chứ không phải điều giao thức ép buộc.
"Một ranh giới bảo mật cần phải được chủ động bật vào là một đảm bảo khác so với ranh giới được tích hợp sẵn trong đường đi mặc định, ngay cả khi cả hai về mặt kỹ thuật đều có sẵn."
Điều tôi thực sự muốn biết là: có bao nhiêu trình cung cấp (provisioners) đang hoạt động chạy với một khóa chủ sở hữu tách riêng so với mặc định? Vì con số đó sẽ cho tôi biết ranh giới mạnh hơn có thực sự đang được áp dụng hay chỉ đơn thuần là được cung cấp.
#dusk $DUSK @Dusk
Tài liệu vận hành của Dusk lại tách điều đó thành hai phần.
Khóa đồng thuận là khóa mà một node dùng để ký và bỏ phiếu trong cơ chế đồng thuận. Nó phải tồn tại trên một node có kết nối internet và tham gia khi trình xác thực (validator) vận hành. Khóa chủ sở hữu là một khóa riêng: đó là khóa có thể hủy staking hoặc rút tiền, và theo tài liệu thì khóa này không cần phải chạm vào node nào cả.
Lợi ích bảo mật không chỉ đơn giản là có hai khóa. Điểm mấu chốt là thẩm quyền tham gia vào đồng thuận và thẩm quyền rút quỹ không cần phải nằm ở cùng một nơi. Nếu khóa đồng thuận bị xâm phạm vì máy chủ nơi nó được đặt bị tấn công xâm nhập, kẻ tấn công có thể can thiệp vào việc tham gia đồng thuận, nhưng họ vẫn không thể hủy staking hay rút phần stake. Thẩm quyền đó ngay từ đầu đã không nằm trên máy vốn đang bị phơi ra trước Internet. Điều đó có nghĩa là câu hỏi bảo mật thực sự không chỉ là số lượng stake bao nhiêu. Mà là thẩm quyền rút stake thực sự được đặt ở đâu, so với máy đang bị kẻ tấn công nhắm tới.
Nhưng có một điểm “bẫy” mà tài liệu không hề giấu: sự tách biệt này không phải là mặc định. Nếu bạn stake mà không chỉ định một khóa chủ sở hữu tách riêng, thì khóa đồng thuận sẽ tự động trở thành khóa chủ sở hữu luôn—một khóa, một ranh giới, quay lại mô hình mà tôi đã giả định ban đầu. Thiết lập an toàn hơn là một lựa chọn mà người vận hành phải chủ động thực hiện, chứ không phải điều giao thức ép buộc.
"Một ranh giới bảo mật cần phải được chủ động bật vào là một đảm bảo khác so với ranh giới được tích hợp sẵn trong đường đi mặc định, ngay cả khi cả hai về mặt kỹ thuật đều có sẵn."
Điều tôi thực sự muốn biết là: có bao nhiêu trình cung cấp (provisioners) đang hoạt động chạy với một khóa chủ sở hữu tách riêng so với mặc định? Vì con số đó sẽ cho tôi biết ranh giới mạnh hơn có thực sự đang được áp dụng hay chỉ đơn thuần là được cung cấp.
#dusk $DUSK @Dusk
