Trước đây tôi nghĩ rằng một epoch chủ yếu là một cách thuận tiện để nhóm các khối. Khi xem vòng đời của provisioner của Dusk, quan điểm đó có vẻ nông cạn quá.
Tôi nhận ra rằng 2.160 khối không chỉ là một con số trong đặc tả mạng. Nó trở thành một đơn vị thời gian rời rạc, quyết định khi nào một provisioner mới được stake thực sự có thể tham gia vào quá trình đồng thuận.
Tôi quay lại tài liệu vì phần thú vị nằm ở logic ranh giới. Một stake mới không kích hoạt ngay lập tức. Việc kích hoạt diễn ra ở ranh giới epoch sau đó, tức là sau epoch kế tiếp, nghĩa là chính khối cụ thể nơi stake được gửi đi sẽ ảnh hưởng đến thời gian người vận hành phải chờ.
Điều đó tạo ra một sự đánh đổi kỹ thuật hữu ích: chuyển trạng thái vòng đời có thể dự đoán trước so với việc tham gia ngay lập tức.
Cơ chế về cơ bản là:
giao dịch stake → epoch hiện tại → ranh giới epoch kế tiếp → ranh giới epoch tiếp theo → stake ở trạng thái hoạt động.
Vì vậy, độ dài epoch chuyển thời gian liên tục thành các mốc kiểm tra do giao thức quy định. Thay vì mỗi khối đều có thể làm thay đổi tập provisioner đang hoạt động, các thay đổi vòng đời được đồng bộ hóa quanh những ranh giới cố định.
Hệ quả là một điều tinh tế. Hai stake giống hệt nhau được gửi ở những thời điểm khác nhau trong cùng một epoch có thể trải nghiệm các độ trễ kích hoạt khác nhau, dù bản thân quy tắc của giao thức là xác định và mang tính quyết định.
Sự dự đoán này giúp việc suy luận về chuyển đổi tập validator dễ hơn, nhưng cái giá là độ trễ: việc tham gia đồng thuận không phải là một thao tác tức thời.
Điều khiến tôi bất ngờ là vì vậy 2.160 khối hoạt động ít giống như một khoảng thời gian theo lịch và nhiều hơn như một chiếc đồng hồ chuyển trạng thái cho các provisioner.
Câu hỏi tôi cứ mãi quay lại là: phần nào trong tính đơn giản trong vận hành của Dusk đến từ việc buộc các thay đổi vòng đời phải rơi đúng vào các ranh giới epoch rời rạc này?
@Dusk_Foundation $DUSK #dusk
Tôi nhận ra rằng 2.160 khối không chỉ là một con số trong đặc tả mạng. Nó trở thành một đơn vị thời gian rời rạc, quyết định khi nào một provisioner mới được stake thực sự có thể tham gia vào quá trình đồng thuận.
Tôi quay lại tài liệu vì phần thú vị nằm ở logic ranh giới. Một stake mới không kích hoạt ngay lập tức. Việc kích hoạt diễn ra ở ranh giới epoch sau đó, tức là sau epoch kế tiếp, nghĩa là chính khối cụ thể nơi stake được gửi đi sẽ ảnh hưởng đến thời gian người vận hành phải chờ.
Điều đó tạo ra một sự đánh đổi kỹ thuật hữu ích: chuyển trạng thái vòng đời có thể dự đoán trước so với việc tham gia ngay lập tức.
Cơ chế về cơ bản là:
giao dịch stake → epoch hiện tại → ranh giới epoch kế tiếp → ranh giới epoch tiếp theo → stake ở trạng thái hoạt động.
Vì vậy, độ dài epoch chuyển thời gian liên tục thành các mốc kiểm tra do giao thức quy định. Thay vì mỗi khối đều có thể làm thay đổi tập provisioner đang hoạt động, các thay đổi vòng đời được đồng bộ hóa quanh những ranh giới cố định.
Hệ quả là một điều tinh tế. Hai stake giống hệt nhau được gửi ở những thời điểm khác nhau trong cùng một epoch có thể trải nghiệm các độ trễ kích hoạt khác nhau, dù bản thân quy tắc của giao thức là xác định và mang tính quyết định.
Sự dự đoán này giúp việc suy luận về chuyển đổi tập validator dễ hơn, nhưng cái giá là độ trễ: việc tham gia đồng thuận không phải là một thao tác tức thời.
Điều khiến tôi bất ngờ là vì vậy 2.160 khối hoạt động ít giống như một khoảng thời gian theo lịch và nhiều hơn như một chiếc đồng hồ chuyển trạng thái cho các provisioner.
Câu hỏi tôi cứ mãi quay lại là: phần nào trong tính đơn giản trong vận hành của Dusk đến từ việc buộc các thay đổi vòng đời phải rơi đúng vào các ranh giới epoch rời rạc này?
@Dusk_Foundation $DUSK #dusk