Việc đánh giá một bản di chuyển cơ sở dữ liệu đường cong có “dùng được” hay không không thể chỉ nhìn một câu kiểu “đã di chuyển xong”. Thông tin mà Dusk hiện đang công khai còn phù hợp để tách thành ba lớp: (1) stack đường cong của Citadel được chuyển sang stack đường cong hiện tại của Dusk; (2) API của Citadel cần được sửa tương ứng; (3) Dusk Curves cũng liên quan đến việc hỗ trợ BLS12-381 để di chuyển sang thư viện đường cong của Dusk. Ba việc này có liên quan nhưng không phải là cùng một hạng mục bàn giao.
Đối với người dùng sản phẩm, lớp thứ nhất là phụ thuộc: bên gọi của stack đường cong cũ đã trỏ sang thư viện mới hay chưa; lớp thứ hai là quan hệ giao diện: sau khi API được sửa, cách gọi ban đầu có còn đúng hay không; chỉ ở lớp thứ ba mới là năng lực cụ thể của đường cong có sẵn trong thư viện đích hay không. Nếu gộp cả ba thành “di chuyển hoàn tất”, bạn sẽ bỏ qua phần khớp nối dễ xảy ra lỗi nhất.
Đây cũng là điểm then chốt để phán đoán trạng thái “thực sự dùng được”. Có thể xác nhận được những gì: đối tượng di chuyển, việc sửa giao diện và việc hỗ trợ đường cong đều được liệt kê. Còn nếu chỉ dựa vào các tài liệu đó thì không thể xác nhận rằng mọi nghiệp vụ đã chuyển đổi hết, mọi lời gọi phía dưới đã được kiểm chứng, hoặc mainnet đã được bật toàn diện. Với những độc giả quan tâm đến @Dusk và $DUSK , quan điểm vững nhất không phải là dán nhãn “thành công” hay “thất bại” cho việc di chuyển, mà hãy hỏi trước: ai chịu trách nhiệm di chuyển thư viện, ai chịu trách nhiệm điều chỉnh API, và bằng chứng trực tiếp nằm ở lớp nào? Cách này gần với quyết định thực tế hơn nhiều so với một câu “nâng cấp hạ tầng”.#dusk
Vì vậy, việc đánh giá di chuyển cần dựa trên trách nhiệm và bằng chứng: thư viện có được chuyển đổi hay không, giao diện có được thích ứng hay không, và hỗ trợ đường cong có được xác minh hay không. Khi ranh giới giữa ba điểm này rõ ràng, mới nói đến chuyện “dùng được”.
Do đó, trước khi áp dụng, nhóm sản phẩm cần xác nhận phạm vi di chuyển và trách nhiệm xác minh, thay vì lấy sự thay đổi tên thư viện làm năng lực nhìn thấy được đối với người dùng.
Giá trị của công việc di chuyển không nằm ở việc khiến ai cũng tin rằng “tiên tiến hơn”, mà là ở chỗ giúp người áp dụng biết rõ thư viện, giao diện và năng lực đường cong mà họ phụ thuộc đang ở trạng thái nào.
Đối với người dùng sản phẩm, lớp thứ nhất là phụ thuộc: bên gọi của stack đường cong cũ đã trỏ sang thư viện mới hay chưa; lớp thứ hai là quan hệ giao diện: sau khi API được sửa, cách gọi ban đầu có còn đúng hay không; chỉ ở lớp thứ ba mới là năng lực cụ thể của đường cong có sẵn trong thư viện đích hay không. Nếu gộp cả ba thành “di chuyển hoàn tất”, bạn sẽ bỏ qua phần khớp nối dễ xảy ra lỗi nhất.
Đây cũng là điểm then chốt để phán đoán trạng thái “thực sự dùng được”. Có thể xác nhận được những gì: đối tượng di chuyển, việc sửa giao diện và việc hỗ trợ đường cong đều được liệt kê. Còn nếu chỉ dựa vào các tài liệu đó thì không thể xác nhận rằng mọi nghiệp vụ đã chuyển đổi hết, mọi lời gọi phía dưới đã được kiểm chứng, hoặc mainnet đã được bật toàn diện. Với những độc giả quan tâm đến @Dusk và $DUSK , quan điểm vững nhất không phải là dán nhãn “thành công” hay “thất bại” cho việc di chuyển, mà hãy hỏi trước: ai chịu trách nhiệm di chuyển thư viện, ai chịu trách nhiệm điều chỉnh API, và bằng chứng trực tiếp nằm ở lớp nào? Cách này gần với quyết định thực tế hơn nhiều so với một câu “nâng cấp hạ tầng”.#dusk
Vì vậy, việc đánh giá di chuyển cần dựa trên trách nhiệm và bằng chứng: thư viện có được chuyển đổi hay không, giao diện có được thích ứng hay không, và hỗ trợ đường cong có được xác minh hay không. Khi ranh giới giữa ba điểm này rõ ràng, mới nói đến chuyện “dùng được”.
Do đó, trước khi áp dụng, nhóm sản phẩm cần xác nhận phạm vi di chuyển và trách nhiệm xác minh, thay vì lấy sự thay đổi tên thư viện làm năng lực nhìn thấy được đối với người dùng.
Giá trị của công việc di chuyển không nằm ở việc khiến ai cũng tin rằng “tiên tiến hơn”, mà là ở chỗ giúp người áp dụng biết rõ thư viện, giao diện và năng lực đường cong mà họ phụ thuộc đang ở trạng thái nào.