Một giao dịch mà Dusk có thể phát lại thì cũng phải có thể chấp nhận trực tiếp.
Ranh giới đó nghiêm ngặt hơn.
Tôi đã giả định rằng định dạng giao dịch là một quy tắc: giải mã thành công, và mạng sẽ hài lòng.
Dusk đã tách nhánh hướng đó.
Triển khai Rusk hiện tại tách việc đi vào giao dịch trực tiếp (live transaction ingress) khỏi dữ liệu sổ cái chuẩn (canonical ledger data). Các lớp bọc Aegis và Boreas có thể đi vào thông qua cơ chế chấp nhận trực tiếp và được chuẩn hoá về định dạng đi vào chuẩn đang hoạt động, sau đó đi qua `CanonicalTransaction` và `LedgerTransaction` trước khi giao dịch đã được niêm phong cục bộ được chuẩn hoá để cam kết vào khối. Đồng thuận vẫn kiểm tra rằng mã hoá sổ cái khớp với định dạng chuẩn yêu cầu tại độ cao khối đó.
Phần kỳ lạ nằm ở chỗ điều gì xảy ra với các định dạng cũ.
Mặc định kích hoạt Aegis trên mainnet của Dusk là khối **3,590,904**. Các định dạng giao dịch lịch sử vẫn có thể giải mã để phát lại sổ cái, nhưng chính những định dạng lịch sử đó bị từ chối trong quá trình chấp nhận vào mempool trực tiếp khi định dạng đó không còn được phép tại đó.
Vì vậy, hãy tưởng tượng một giao dịch cũ từ trước mốc ranh giới đó nằm trong lịch sử của chuỗi.
Dusk vẫn có thể hiểu nó khi phát lại sổ cái.
Nhưng thử đẩy định dạng lịch sử đó qua quá trình chấp nhận trực tiếp sau khi giao thức đã chuyển sang giai đoạn tiếp theo, và nó sẽ bị từ chối.
Nút có thể lưu giữ quá khứ mà không để quá khứ quyết định điều gì sẽ trở thành dữ liệu sổ cái mới.
Bao nhiêu khả năng tương thích giao dịch của Dusk đến từ việc bảo toàn các định dạng cũ cho lịch sử của chuỗi, và bao nhiêu đến từ việc duy trì tính nhất quán bằng cách từ chối không cho các định dạng đó quay lại nhánh đường đi trực tiếp?
@Dusk $DUSK #dusk
Ranh giới đó nghiêm ngặt hơn.
Tôi đã giả định rằng định dạng giao dịch là một quy tắc: giải mã thành công, và mạng sẽ hài lòng.
Dusk đã tách nhánh hướng đó.
Triển khai Rusk hiện tại tách việc đi vào giao dịch trực tiếp (live transaction ingress) khỏi dữ liệu sổ cái chuẩn (canonical ledger data). Các lớp bọc Aegis và Boreas có thể đi vào thông qua cơ chế chấp nhận trực tiếp và được chuẩn hoá về định dạng đi vào chuẩn đang hoạt động, sau đó đi qua `CanonicalTransaction` và `LedgerTransaction` trước khi giao dịch đã được niêm phong cục bộ được chuẩn hoá để cam kết vào khối. Đồng thuận vẫn kiểm tra rằng mã hoá sổ cái khớp với định dạng chuẩn yêu cầu tại độ cao khối đó.
Phần kỳ lạ nằm ở chỗ điều gì xảy ra với các định dạng cũ.
Mặc định kích hoạt Aegis trên mainnet của Dusk là khối **3,590,904**. Các định dạng giao dịch lịch sử vẫn có thể giải mã để phát lại sổ cái, nhưng chính những định dạng lịch sử đó bị từ chối trong quá trình chấp nhận vào mempool trực tiếp khi định dạng đó không còn được phép tại đó.
Vì vậy, hãy tưởng tượng một giao dịch cũ từ trước mốc ranh giới đó nằm trong lịch sử của chuỗi.
Dusk vẫn có thể hiểu nó khi phát lại sổ cái.
Nhưng thử đẩy định dạng lịch sử đó qua quá trình chấp nhận trực tiếp sau khi giao thức đã chuyển sang giai đoạn tiếp theo, và nó sẽ bị từ chối.
Nút có thể lưu giữ quá khứ mà không để quá khứ quyết định điều gì sẽ trở thành dữ liệu sổ cái mới.
Bao nhiêu khả năng tương thích giao dịch của Dusk đến từ việc bảo toàn các định dạng cũ cho lịch sử của chuỗi, và bao nhiêu đến từ việc duy trì tính nhất quán bằng cách từ chối không cho các định dạng đó quay lại nhánh đường đi trực tiếp?
@Dusk $DUSK #dusk