#dusk
Tôi đã nhận ra rằng mình đã viết cụm “bằng chứng không kiến thức” trong có lẽ tám bài đăng khác nhau mà chưa lần nào giải thích thực sự chúng đang tính toán điều gì.
Tôi bắt đầu tìm các nguyên thủy mật mã đứng sau thay vì chỉ nhắc lại thuật ngữ một cách chung chung.
Hóa ra không phải là một mảnh toán học làm mọi thứ. Mà là bốn mảnh, mỗi mảnh phụ trách một nhiệm vụ khác nhau.
BLS12-381 là đường cong elliptic nằm bên dưới hệ thống chữ ký và bằng chứng.
Nó là “pairing-friendly” — tính chất cụ thể giúp việc gộp chữ ký và xây dựng bằng chứng gọn nhẹ trở nên thực tế thay vì tốn kém tính toán một cách bạo lực.
JubJub là một đường cong riêng, được tối ưu đặc biệt để chạy hiệu quả bên trong các mạch SNARK — nơi mà các ghi chú được che chắn của Phoenix thực sự chứng minh được quyền riêng tư.
Poseidon là hàm băm đảm nhiệm phần “nặng nhọc” bên trong các mạch đó.
Các hàm băm thông thường như SHA-256 thì dùng ổn cho mục đích thông thường, nhưng rất đắt khi tính toán bên trong một bằng chứng không kiến thức.
Poseidon được xây dựng riêng để rẻ trong bối cảnh đó, vì vậy nó xuất hiện cho các cam kết và băm cây Merkle thay vì một thứ quen thuộc hơn.
PLONK là phần biến tất cả những thứ này thành một mệnh đề có thể được chứng minh.
Nó chính là hệ thống chứng minh — thứ cho phép một nhà phát triển định nghĩa mạch một lần và tạo ra các bằng chứng được xác minh trên chuỗi mà không cần tính toán lại phép gốc.
Điều khiến tôi chú ý khi ghép những cái này lại với nhau: không cái nào trong số đó là phát minh riêng của Dusk.
Chúng là các khối xây dựng mật mã đã được thiết lập, được chọn và lắp ghép cho đúng một nhiệm vụ cụ thể.
Quyết định kỹ thuật thực sự là chọn đúng sự kết hợp, chứ không phải tự chế ra toán học mới từ đầu.
$DUSK
Vậy thì, @Dusk .
Việc dùng các nguyên thủy mật mã đã được nghiên cứu kỹ thay vì mật mã mới mẻ có khiến một chuỗi quyền riêng tư trở nên đáng tin hơn không, hay việc xếp chồng bốn hệ thống khác nhau chỉ tạo ra thêm các điểm lỗi mới ở các mối nối? Và một người bình thường sử dụng bất kỳ thứ gì trong số này có cần phải biết một cái tên nào trong số đó không, hay nó vĩnh viễn nằm ở hậu trường, chỉ quan trọng với các auditor và nhà nghiên cứu?
Tôi đã nhận ra rằng mình đã viết cụm “bằng chứng không kiến thức” trong có lẽ tám bài đăng khác nhau mà chưa lần nào giải thích thực sự chúng đang tính toán điều gì.
Tôi bắt đầu tìm các nguyên thủy mật mã đứng sau thay vì chỉ nhắc lại thuật ngữ một cách chung chung.
Hóa ra không phải là một mảnh toán học làm mọi thứ. Mà là bốn mảnh, mỗi mảnh phụ trách một nhiệm vụ khác nhau.
BLS12-381 là đường cong elliptic nằm bên dưới hệ thống chữ ký và bằng chứng.
Nó là “pairing-friendly” — tính chất cụ thể giúp việc gộp chữ ký và xây dựng bằng chứng gọn nhẹ trở nên thực tế thay vì tốn kém tính toán một cách bạo lực.
JubJub là một đường cong riêng, được tối ưu đặc biệt để chạy hiệu quả bên trong các mạch SNARK — nơi mà các ghi chú được che chắn của Phoenix thực sự chứng minh được quyền riêng tư.
Poseidon là hàm băm đảm nhiệm phần “nặng nhọc” bên trong các mạch đó.
Các hàm băm thông thường như SHA-256 thì dùng ổn cho mục đích thông thường, nhưng rất đắt khi tính toán bên trong một bằng chứng không kiến thức.
Poseidon được xây dựng riêng để rẻ trong bối cảnh đó, vì vậy nó xuất hiện cho các cam kết và băm cây Merkle thay vì một thứ quen thuộc hơn.
PLONK là phần biến tất cả những thứ này thành một mệnh đề có thể được chứng minh.
Nó chính là hệ thống chứng minh — thứ cho phép một nhà phát triển định nghĩa mạch một lần và tạo ra các bằng chứng được xác minh trên chuỗi mà không cần tính toán lại phép gốc.
Điều khiến tôi chú ý khi ghép những cái này lại với nhau: không cái nào trong số đó là phát minh riêng của Dusk.
Chúng là các khối xây dựng mật mã đã được thiết lập, được chọn và lắp ghép cho đúng một nhiệm vụ cụ thể.
Quyết định kỹ thuật thực sự là chọn đúng sự kết hợp, chứ không phải tự chế ra toán học mới từ đầu.
$DUSK
Vậy thì, @Dusk .
Việc dùng các nguyên thủy mật mã đã được nghiên cứu kỹ thay vì mật mã mới mẻ có khiến một chuỗi quyền riêng tư trở nên đáng tin hơn không, hay việc xếp chồng bốn hệ thống khác nhau chỉ tạo ra thêm các điểm lỗi mới ở các mối nối? Và một người bình thường sử dụng bất kỳ thứ gì trong số này có cần phải biết một cái tên nào trong số đó không, hay nó vĩnh viễn nằm ở hậu trường, chỉ quan trọng với các auditor và nhà nghiên cứu?
