Tôi phát hiện có một thay đổi kỹ thuật đã được gộp vào nhánh chính PLONK của Dusk. Phần thay đổi nằm ở quy trình giải tuần tự (deserialization) của tệp mạch nén: sau khi đọc xong phần nội dung (body), nếu vẫn còn byte dư thì compile_with_compressed sẽ trả về InvalidCompressedCircuit. Bộ hồi quy (regression) chính thức đã bổ sung riêng một giá trị hợp lệ ở phần đuôi (tail) theo MessagePack để xác nhận rằng trước khi sửa thì được chấp nhận, còn sau khi sửa thì bị từ chối.
Với cùng một mạch nén, phần nội dung giống hệt nhau, chỉ khác ở việc thêm vào cuối đúng một byte không liên quan. Bất kỳ hệ thống kiểm soát rủi ro hoặc cache nào tính băm (hash) theo byte gốc sẽ xem đó là một tệp khác; còn PLONK phiên bản cũ thì có thể vẫn đọc bình thường.
Thấy vậy, tôi thực sự hơi lo. Rõ ràng tệp đã thay đổi, vậy mà công cụ lại nói “không đổi”. Với hệ thống tài chính, điều này còn rắc rối hơn cả việc báo lỗi trực tiếp: một thứ mang đồng thời hai “giấy căn cước”.
Trước hết, tôi sẽ nhắm đúng đối tượng. Lần này, thay đổi áp dụng cho tệp mạch nén dùng để tạo chứng minh (proof); các chứng minh đã được tạo trên chuỗi không thuộc phạm vi lần này. Việc xử lý mới mà Dusk vừa gộp rất dứt khoát: sau khi đọc xong phần thân mạch, nếu phía sau vẫn còn byte dư thì toàn bộ tệp bị coi là không hợp lệ.
Nói thật, ban đầu tôi cũng thấy nó “cứng” hơi vô lý. Công cụ cũ vẫn chạy được, tại sao phải chém bỏ tương thích chỉ vì vài byte ở đuôi? Nhưng nếu đặt nó vào hệ thống giao dịch thì mọi thứ đổi khác. Nếu tệp gốc bị kiểm toán, cache hoặc kho phiên bản (version library) nhận diện theo byte, trong khi trình biên dịch lại coi hai tệp khác nhau là cùng một bộ quy tắc, thì khi có sự cố rất khó để nói rõ rốt cuộc phiên bản nào đã được dùng.
Vì vậy, đây là một chỉ dấu rất thực dụng: sau khi nâng cấp, nếu một số ứng dụng ZK đột nhiên fail, hãy trước tiên kiểm tra InvalidCompressedCircuit, phiên bản công cụ, và thử xem có thể phục hồi hay không sau khi re-export. Nếu tệp cũ fail còn tệp mới chạy bình thường, thì nhiều khả năng đó là vấn đề di chuyển định dạng (format migration); nếu tệp chuẩn vẫn fail trên diện rộng thì mới cần đào sâu vào logic chứng minh hoặc sự cố mạng. Đừng trộn hai rủi ro này vào cùng một kịch bản.
Đối với $DUSK , việc siết chặt trong ngắn hạn có thể làm giảm số lần gọi thành công, thậm chí khiến công cụ cũ phải dừng một thời gian; giá trị dài hạn phụ thuộc vào việc sau khi các hạ tầng/ứng dụng kế thừa (downstream) di chuyển, chi phí cho lỗi chứng minh, tranh cãi phiên bản và việc đối soát nội bộ của tổ chức có giảm đi hay không. Trình phân tích (parser) không tự tạo ra nhu cầu mua (buying). Thứ nó có thể làm là đảm bảo mỗi tệp mạch chỉ được nhận là một “giấy căn cước” duy nhất.
Trong giao dịch, tôi sẽ không xem việc “cố gắng vẫn đọc được” là thân thiện. Tôi cho rằng sổ cái tài chính cần tính hợp lệ và duy nhất. DYOR!
#dusk $DUSK @Dusk
Với cùng một mạch nén, phần nội dung giống hệt nhau, chỉ khác ở việc thêm vào cuối đúng một byte không liên quan. Bất kỳ hệ thống kiểm soát rủi ro hoặc cache nào tính băm (hash) theo byte gốc sẽ xem đó là một tệp khác; còn PLONK phiên bản cũ thì có thể vẫn đọc bình thường.
Thấy vậy, tôi thực sự hơi lo. Rõ ràng tệp đã thay đổi, vậy mà công cụ lại nói “không đổi”. Với hệ thống tài chính, điều này còn rắc rối hơn cả việc báo lỗi trực tiếp: một thứ mang đồng thời hai “giấy căn cước”.
Trước hết, tôi sẽ nhắm đúng đối tượng. Lần này, thay đổi áp dụng cho tệp mạch nén dùng để tạo chứng minh (proof); các chứng minh đã được tạo trên chuỗi không thuộc phạm vi lần này. Việc xử lý mới mà Dusk vừa gộp rất dứt khoát: sau khi đọc xong phần thân mạch, nếu phía sau vẫn còn byte dư thì toàn bộ tệp bị coi là không hợp lệ.
Nói thật, ban đầu tôi cũng thấy nó “cứng” hơi vô lý. Công cụ cũ vẫn chạy được, tại sao phải chém bỏ tương thích chỉ vì vài byte ở đuôi? Nhưng nếu đặt nó vào hệ thống giao dịch thì mọi thứ đổi khác. Nếu tệp gốc bị kiểm toán, cache hoặc kho phiên bản (version library) nhận diện theo byte, trong khi trình biên dịch lại coi hai tệp khác nhau là cùng một bộ quy tắc, thì khi có sự cố rất khó để nói rõ rốt cuộc phiên bản nào đã được dùng.
Vì vậy, đây là một chỉ dấu rất thực dụng: sau khi nâng cấp, nếu một số ứng dụng ZK đột nhiên fail, hãy trước tiên kiểm tra InvalidCompressedCircuit, phiên bản công cụ, và thử xem có thể phục hồi hay không sau khi re-export. Nếu tệp cũ fail còn tệp mới chạy bình thường, thì nhiều khả năng đó là vấn đề di chuyển định dạng (format migration); nếu tệp chuẩn vẫn fail trên diện rộng thì mới cần đào sâu vào logic chứng minh hoặc sự cố mạng. Đừng trộn hai rủi ro này vào cùng một kịch bản.
Đối với $DUSK , việc siết chặt trong ngắn hạn có thể làm giảm số lần gọi thành công, thậm chí khiến công cụ cũ phải dừng một thời gian; giá trị dài hạn phụ thuộc vào việc sau khi các hạ tầng/ứng dụng kế thừa (downstream) di chuyển, chi phí cho lỗi chứng minh, tranh cãi phiên bản và việc đối soát nội bộ của tổ chức có giảm đi hay không. Trình phân tích (parser) không tự tạo ra nhu cầu mua (buying). Thứ nó có thể làm là đảm bảo mỗi tệp mạch chỉ được nhận là một “giấy căn cước” duy nhất.
Trong giao dịch, tôi sẽ không xem việc “cố gắng vẫn đọc được” là thân thiện. Tôi cho rằng sổ cái tài chính cần tính hợp lệ và duy nhất. DYOR!
#dusk $DUSK @Dusk