#dusk $DUSK @Dusk Khi đọc ghi chú phát hành của Boreas, tôi dừng lại ở một thay đổi nhỏ: DUSK không còn định giá SHA-256, Keccak và băm tổng quát như thể mọi đầu vào đều có cùng “chi phí”.
Một hàm băm 32 byte và một hàm băm cỡ nhiều kilobyte gọi tới cùng một truy vấn máy chủ, nhưng chúng không đòi hỏi lượng công việc bằng nhau. Boreas thêm định giá theo kích thước cho cả ba loại này, trong khi việc xác minh đa chữ ký BLS (multisig) mở rộng theo số lượng khóa. Việc xác minh KZG và thao tác khôi phục secp256k1 không được mô tả là được định giá theo độ dài đầu vào. Hỏi truy vấn nào “đắt nhất” mà không cố định độ dài đầu vào và số lượng khóa thì gần như là một câu hỏi sai.
So sánh ở đây là định giá theo số lần gọi API (phẳng) so với phần tính toán bị áp đặt lên các trình xác thực (validator). DUSK đã tiến gần hơn về phía cách nhìn thứ hai.
Có một điểm phức tạp. Boreas nhận biết ngữ cảnh fork: việc thực thi lịch sử giữ nguyên ngữ nghĩa trước fork, trong khi các hợp đồng hiện tại nhận lịch biểu mới. Mức tính toán tương đương có thể mang lại lượng gas khác nhau do ngữ cảnh thực thi cần thiết cho việc phát lại (replay), điều này bất tiện cho các nhà phát triển khi dự báo chi phí.
Với DUSK, độ chính xác gas tốt hơn sẽ giảm tình trạng định giá thấp đối với các tải công việc mật mã và làm cho việc thực thi nhất quán hơn giữa các nút. Nó không chứng minh rằng các chuyển trạng thái thành công đã trở nên rẻ hơn. Có thể chúng đã được định giá “thật” hơn, ngay cả khi con số tăng lên.
Tôi vẫn đang chờ dữ liệu benchmark theo từng “bucket” đầu vào. Kế toán xác định (deterministic) chỉ thực sự thuyết phục khi gas tính phí khớp với công việc CPU thực tế.
@Dusk #dusk #Dusk
Một hàm băm 32 byte và một hàm băm cỡ nhiều kilobyte gọi tới cùng một truy vấn máy chủ, nhưng chúng không đòi hỏi lượng công việc bằng nhau. Boreas thêm định giá theo kích thước cho cả ba loại này, trong khi việc xác minh đa chữ ký BLS (multisig) mở rộng theo số lượng khóa. Việc xác minh KZG và thao tác khôi phục secp256k1 không được mô tả là được định giá theo độ dài đầu vào. Hỏi truy vấn nào “đắt nhất” mà không cố định độ dài đầu vào và số lượng khóa thì gần như là một câu hỏi sai.
So sánh ở đây là định giá theo số lần gọi API (phẳng) so với phần tính toán bị áp đặt lên các trình xác thực (validator). DUSK đã tiến gần hơn về phía cách nhìn thứ hai.
Có một điểm phức tạp. Boreas nhận biết ngữ cảnh fork: việc thực thi lịch sử giữ nguyên ngữ nghĩa trước fork, trong khi các hợp đồng hiện tại nhận lịch biểu mới. Mức tính toán tương đương có thể mang lại lượng gas khác nhau do ngữ cảnh thực thi cần thiết cho việc phát lại (replay), điều này bất tiện cho các nhà phát triển khi dự báo chi phí.
Với DUSK, độ chính xác gas tốt hơn sẽ giảm tình trạng định giá thấp đối với các tải công việc mật mã và làm cho việc thực thi nhất quán hơn giữa các nút. Nó không chứng minh rằng các chuyển trạng thái thành công đã trở nên rẻ hơn. Có thể chúng đã được định giá “thật” hơn, ngay cả khi con số tăng lên.
Tôi vẫn đang chờ dữ liệu benchmark theo từng “bucket” đầu vào. Kế toán xác định (deterministic) chỉ thực sự thuyết phục khi gas tính phí khớp với công việc CPU thực tế.
@Dusk #dusk #Dusk
