Tác giả: Vitalik Buterin, Người dịch: Kurt Pan, XPTY
Bài viết này giả định rằng bạn đã quen với những kiến thức cơ bản về cách SNARK và STARK hoạt động, nếu bạn chưa quen thì nên đọc phần này; vài phần đầu tiên của bài viết này. Đặc biệt cảm ơn Eli ben-Sasson, Shahar Papini, Avihu Levy và những người khác tại starkware vì những phản hồi và thảo luận của họ.
Sự chuyển đổi này đã dẫn đến những cải thiện đáng kể về tốc độ chứng minh, đáng chú ý nhất là khả năng của Starkware trong việc chứng minh 620.000 băm Poseidon2 mỗi giây trên máy tính xách tay M3. Cụ thể, điều này có nghĩa là miễn là chúng ta sẵn sàng tin tưởng Poseidon2 như một phần của hàm băm thì một trong những phần khó khăn nhất trong việc xây dựng ZK-EVM hiệu quả đã được giải quyết một cách hiệu quả. Nhưng những kỹ thuật này hoạt động như thế nào và bằng chứng mật mã (thường yêu cầu số nguyên lớn để bảo mật) được xây dựng trên các miền này như thế nào? Và làm thế nào để so sánh các giao thức này với các cấu trúc kỳ lạ hơn như Binius? Bài viết này sẽ khám phá một số khác biệt nhỏ, đặc biệt tập trung vào cấu trúc có tên Circle STARK (được triển khai trong stwo của Starkware, plonky3 của Polygon và triển khai python của riêng tôi), có một số thuộc tính độc đáo được thiết kế để Tương thích với miền Mersenne31 hiệu quả.
https://x.com/StarkWareLtd/status/1807776563188162562
< /li>https://vitalik.eth.limo/general/2022/08/04/zkevm.html
https://vitalik.eth.limo/general/2024/04/29/binius.html
https://www.irreducible.com/posts/binius-hardware-optimized-snark
https://eprint.iacr.org/2024/278
https://github.com/starkware-libs /stwo
https://github.com/Plonky3/Plonky3
https://github.com/ethereum/research/tree/master/circlestark
Các vấn đề thường gặp ở các miền nhỏ p> h2>
Một trong những "thủ thuật" quan trọng nhất khi thực hiện chứng minh dựa trên hàm băm (hoặc thực tế là bất kỳ loại chứng minh nào) là chứng minh điều gì đó về việc đánh giá đa thức tại các điểm ngẫu nhiên thay vì chứng minh điều gì đó về đa thức cơ bản .
- https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic
Có hai giải pháp tự nhiên cho vấn đề này:
- Thực thi Nhiều kiểm tra ngẫu nhiên
< /p >
- https://www2.clarku.edu/faculty/djoyce/complex/mult.html
< p style="text-align: center;">
Việc triển khai ở đây không tối ưu (có thể tối ưu hóa bằng Karatsuba), nó chỉ thể hiện nguyên tắc p>
< h2>FRI thông thường
- https://eccc.weizmann.ac.il /báo cáo /2017/134/
Hình tròn FRI
- https://elibensasson.blog/why-im-excited-by-circle-stark-and-stwo/
< p style ="text-align: center;">
Các dấu chấm này tuân theo định luật cộng và nếu gần đây bạn đã học lượng giác hoặc phép nhân phức, bạn có thể thấy định luật này quen thuộc:
- https://unacademy.com/content/cbse-class- 11/study -material/mathematics/algebra-of-complex-numbers-multiplication/
Từ vòng thứ hai trở đi, ánh xạ thay đổi:
Vòng tròn FFT
- https://vitalik.eth.limo/general/2019/05/12/fft.html phần>< phần>
- https://www.researchgate.net/publication/353344649_Elliptic_Curve_Fast_Fourier_Transform_ECFFT_Part_I_Fast_Polynomial_Algorithms_over_all_Finite_Fields
Từ đây, hãy tìm hiểu thêm một số chi tiết bí truyền dành cho những người triển khai STARK vòng tròn, so với những điều này thông thường chi tiết sẽ khác so với STARK.
Khởi nghiệp
- https:/ /eprint.iacr.org/2019/336
Đa thức biến mất
Thứ tự bit đảo ngược
Hiệu quả
Do đó, hãy khoanh tròn STARK thực sự là rất gần với mức tối ưu! Binius thậm chí còn mạnh mẽ hơn vì nó cho phép trộn và kết hợp các miền có kích thước khác nhau, mang lại khả năng đóng gói bit hiệu quả hơn cho mọi thứ. Binius cũng cung cấp tùy chọn để thực hiện các phép cộng 32 bit mà không cần sử dụng bảng tra cứu. Tuy nhiên, những lợi ích này phải trả giá bằng (theo ý kiến của tôi) độ phức tạp về mặt lý thuyết cao hơn đáng kể, trong khi vòng tròn STARK (và STARK thông thường dựa trên BabyBear) về mặt khái niệm khá đơn giản.
Kết luận: Tôi nghĩ gì về STARK hình tròn?
So với STARK thông thường, Circle STARK không mang lại nhiều sự phức tạp bổ sung cho các nhà phát triển. Trong quá trình triển khai, ba vấn đề trên về cơ bản là điểm khác biệt duy nhất tôi thấy so với FRI thông thường. Phép toán đằng sau "đa thức" mà Circle FRI thực hiện khá phản trực giác và phải mất một thời gian để hiểu và đánh giá cao. Nhưng điều xảy ra là sự phức tạp này bị ẩn đi nên các nhà phát triển không nhìn thấy quá nhiều về nó. Sự phức tạp của toán học Vòng tròn được gói gọn chứ không mang tính hệ thống.
Hiểu FRI vòng tròn và FFT vòng tròn cũng là một cách tiếp cận trí tuệ tốt để hiểu các "FFT kỳ lạ" khác: tốt nhất Đáng chú ý là FFT miền nhị phân, trước đây được sử dụng trong Binius và LibSTARK, cũng như các cấu trúc kỳ lạ hơn, chẳng hạn như FFT đường cong elip, sử dụng nhiều ánh xạ một số và hoạt động tốt với các phép toán điểm trên đường cong elip.
https://github.com/ethereum/research/blob/master/binius/ nhị phân_ntt.py#L60
https://github.com/elibensasson/libSTARK
https://arxiv.org/abs/2107.08473
Bằng cách kết hợp Mersenne31, BabyBear và công nghệ miền nhị phân như với tư cách là Binius, chúng tôi cảm thấy rằng chúng tôi đang đạt đến giới hạn về hiệu quả "lớp cơ sở" của STARK. Tại thời điểm này, tôi hy vọng giới hạn của tối ưu hóa STARK sẽ chuyển sang hướng số học hiệu quả nhất của các nguyên hàm như hàm băm và chữ ký (và tối ưu hóa chính các nguyên hàm đó cho mục đích này), các cấu trúc đệ quy để mở khóa nhiều khả năng song song hơn, Số học hóa các máy ảo để cải thiện kinh nghiệm của nhà phát triển và các nhiệm vụ cấp cao khác.