Bằng chứng không có kiến thức (ZKP) đang ngày càng trở nên quan trọng đối với các hệ thống phi tập trung. ZK lần đầu tiên xuất hiện trong mắt công chúng vì thành công của nó trong các dự án như ZCash, nhưng ngày nay ZK được biết đến như một giải pháp mở rộng quy mô cho Ethereum.
Tận dụng ZK, Lớp 2 (ví dụ: Cuộn và Đa giác), còn được gọi là Rollups, đang phát triển zkEVM (Máy ảo zk Ethereum). Các zkEVM này xử lý một loạt các giao dịch và tạo ra một bằng chứng nhỏ (tính bằng kilobyte). Chứng thực này có thể được sử dụng để xác minh cho toàn bộ mạng rằng lô giao dịch là hợp lệ và chính xác.
Tuy nhiên, công dụng của chúng không dừng lại ở đó. ZK cho phép một loạt các ứng dụng thú vị.
Lớp riêng 1 – Mina, ví dụ, ẩn các chi tiết của các giao dịch và dữ liệu trên blockchain của nó, cho phép người dùng chỉ chứng minh tính hợp lệ của các giao dịch của họ mà không tiết lộ chi tiết cụ thể của chính giao dịch. neptune.cash và Aleo cũng là những dự án rất thú vị.
Nền tảng đám mây phi tập trung - FedML và together.xyz cho phép các mô hình học máy (ML) được đào tạo theo cách phi tập trung, thuê ngoài tính toán vào mạng và xác minh tính chính xác của tính toán bằng ZKP. Druglike đang xây dựng một nền tảng khám phá ma túy cởi mở hơn bằng cách sử dụng các công nghệ tương tự.
** Lưu trữ phi tập trung ** - Filecoin đang cách mạng hóa lưu trữ đám mây và ZK là cốt lõi của nó, cho phép các nhà cung cấp dịch vụ lưu trữ chứng minh rằng họ đã lưu trữ đúng dữ liệu trong một khoảng thời gian.
GAME - Một phiên bản nâng cao hơn của Darkforest có thể xuất hiện, yêu cầu bằng chứng thời gian thực. ZK cũng có thể mở rộng trò chơi để giảm khả năng gian lận. Cũng có thể làm việc với một nền tảng đám mây phi tập trung để cho phép trò chơi trả tiền cho dịch vụ lưu trữ của riêng mình!
Danh tính - Xác thực phi tập trung hiện cũng có thể thông qua ZK. Xung quanh ý tưởng này, một số dự án thú vị đang được xây dựng. Ví dụ: notebook và zkemail (được khuyến nghị để tìm hiểu).
Tác động của ZK và các hệ thống phi tập trung là rất lớn, tuy nhiên, sự phát triển của câu chuyện chưa hoàn hảo, và vẫn còn nhiều trở ngại và thách thức hiện nay. Quá trình bao gồm việc tạo ra các bằng chứng rất tốn tài nguyên và đòi hỏi nhiều phép toán phức tạp. Khi các nhà phát triển tìm cách xây dựng các giao thức và hệ thống phức tạp và đầy tham vọng hơn bằng cách sử dụng công nghệ ZK, cho cả quy trình tạo bằng chứng và xác minh, các nhà phát triển đang yêu cầu kích thước bằng chứng nhỏ hơn, hiệu suất nhanh hơn và tối ưu hóa tốt hơn.
Trong bài viết này, chúng ta sẽ khám phá tình trạng tăng tốc phần cứng hiện tại và cách nó sẽ đóng vai trò quan trọng trong việc thúc đẩy việc áp dụng ZK.
Snark vs Stark
Có hai kỹ thuật zero-knowledge phổ biến hiện nay, zk-STARK và zk-SNARK (chúng tôi đã bỏ qua Bulletproofs trong bài viết này).
| | | |
| --- | --- | --- |
| zk-STARK | zk-SNARK | |
| Sự phức tạp - Prover | O(N * poly-log(N)) | O(N * log(N)) |
| Độ phức tạp - Trình xác minh | O(poly-log(N)) | O(1) |
| Kích thước bằng chứng | 45KB-200KB | ~ 288 byte |
| 抗量子 | Có (dựa trên hàm băm) | Không |
| Thiết lập đáng tin cậy | Không | Vâng |
| Không có kiến thức | Có | Có |
| Tương tác | Tương tác hoặc không tương tác | Không tương tác |
| Tài liệu dành cho nhà phát triển | Hạn chế, nhưng mở rộng Tốt |
表1:Snark VS Stark
Như đã đề cập ở trên, có sự khác biệt và đánh đổi giữa hai người. Điểm quan trọng nhất là thiết lập đáng tin cậy của hệ thống dựa trên zk-SNARK phụ thuộc vào ít nhất một người tham gia trung thực tham gia vào quá trình thiết lập đáng tin cậy và khóa của họ bị hủy vào cuối quá trình. Về mặt xác minh trên chuỗi, zk-SNARKs rẻ hơn nhiều về phí gas. Ngoài ra, bằng chứng của zk-SNARKs cũng nhỏ hơn đáng kể, làm cho chúng rẻ hơn để lưu trữ trên chuỗi.
Hiện tại, zk-SNARKs phổ biến hơn zk-STARKs. Lý do rất có thể là zk-SNARKs có lịch sử lâu đời hơn nhiều. Một lý do khác có thể là Zcash, một trong những blockchain ZK đầu tiên, đã sử dụng zk-SNARKs, vì vậy hầu hết các công cụ và tài liệu phát triển hiện tại đều xoay quanh hệ sinh thái zk-SNARK.
Cách xây dựng Ứng dụng ZK
Các nhà phát triển có thể cần hai thành phần để hoàn thành việc phát triển ứng dụng ZK
Phương pháp tính toán biểu thức thân thiện với ZK (DSL hoặc thư viện cấp thấp).
Một hệ thống chứng thực thực hiện hai chức năng: Chứng minh và Xác minh.
DSL (ngôn ngữ dành riêng cho miền) và thư viện cấp thấp
Khi nói đến DSL, có rất nhiều lựa chọn, chẳng hạn như Circom, Halo2, Noir, v.v. Circom có lẽ là phổ biến nhất tại thời điểm này.
Khi nói đến các thư viện cấp thấp, một ví dụ phổ biến là Arkworks; Ngoài ra còn có các thư viện đang được phát triển, chẳng hạn như ICICLE, là một thư viện tăng tốc CUDA.
Các DSL này được thiết kế để xuất ra các hệ thống hạn chế. Không giống như chương trình thông thường, thường được đánh giá dưới dạng x: = y *z, cùng một chương trình ở dạng ràng buộc trông giống như x-y * z = 0. Bằng cách biểu diễn chương trình dưới dạng một hệ thống các ràng buộc, chúng tôi thấy rằng các hoạt động như cộng hoặc nhân có thể được biểu diễn bằng một ràng buộc duy nhất. Tuy nhiên, các hoạt động phức tạp hơn, chẳng hạn như hoạt động bit, có thể yêu cầu hàng trăm ràng buộc!
Do đó, việc triển khai một số hàm băm như các chương trình thân thiện với ZK trở nên phức tạp. Trong các bằng chứng không có kiến thức, các hàm băm thường được sử dụng để đảm bảo tính toàn vẹn của dữ liệu và / hoặc để xác minh các thuộc tính cụ thể của dữ liệu, nhưng do số lượng lớn các ràng buộc của các hoạt động bit, một số hàm băm rất khó thích ứng với môi trường của các bằng chứng không có kiến thức. Sự phức tạp này có thể ảnh hưởng đến hiệu quả của việc tạo và xác minh bằng chứng, và do đó trở thành một vấn đề mà các nhà phát triển cần xem xét và giải quyết khi xây dựng các ứng dụng dựa trên ZK
Do đó, việc triển khai một số hàm băm để thân thiện với ZK trở nên phức tạp.
Minh
Một hệ thống chứng minh có thể được ví như một phần mềm hoàn thành hai nhiệm vụ chính: tạo ra bằng chứng và xác minh bằng chứng. Các hệ thống chứng minh thường chấp nhận mạch, bằng chứng và các thông số công khai / riêng tư làm đầu vào.
Hai hệ thống chứng minh phổ biến nhất là dòng Groth16 và PLONK (Plonk, HyperPlonk, UltraPlonk)
| | | | | | |
| --- | --- | --- | --- | --- | --- |
| | Thiết lập đáng tin cậy | Kích thước bằng chứng | Sự phức tạp của Prover | Độ phức tạp của trình xác minh | Linh hoạt |
| Groth16 | Mạch cụ thể | Nhỏ | Thấp | Thấp | Thấp |
| Plonk | Phổ quát | Lớn | Cao | 常数 | Cao |
表2:Groth16 vs Plonk
Như thể hiện trong Bảng 2, Groth16 yêu cầu quy trình thiết lập đáng tin cậy, nhưng Groth16 cung cấp cho chúng tôi thời gian chứng minh và xác minh nhanh hơn, cũng như kích thước bằng chứng không đổi.
Plonk cung cấp một thiết lập chung thực hiện giai đoạn tiền xử lý cho mạch bạn đang chạy mỗi khi tạo bằng chứng. Mặc dù hỗ trợ nhiều mạch, thời gian xác minh của Plonk là không đổi.
Cũng có sự khác biệt giữa hai về các ràng buộc. Groth16 phát triển tuyến tính về kích thước hạn chế và thiếu tính linh hoạt, trong khi Plonk linh hoạt hơn.
Nhìn chung, hãy hiểu rằng hiệu suất liên quan trực tiếp đến số lượng ràng buộc trong ứng dụng ZK của bạn. Càng nhiều ràng buộc, người chứng minh càng phải tính toán nhiều hoạt động.
Bottleneck
Hệ thống chứng minh bao gồm hai phép toán chính: phép nhân đa hướng (MSM) và biến đổi Fourier nhanh (FFT). Hôm nay chúng ta sẽ khám phá các hệ thống mà cả hai tồn tại, nơi MSM có thể chiếm khoảng 60% thời gian chạy, trong khi FFT có thể chiếm khoảng 30%.
MSM yêu cầu nhiều quyền truy cập bộ nhớ, trong hầu hết các trường hợp tiêu tốn rất nhiều bộ nhớ trên máy, đồng thời thực hiện nhiều thao tác nhân vô hướng.
Các thuật toán FFT thường yêu cầu sắp xếp lại dữ liệu đầu vào thành một thứ tự cụ thể để thực hiện chuyển đổi. Điều này có thể đòi hỏi nhiều chuyển động dữ liệu và có thể là một nút cổ chai, đặc biệt là đối với kích thước đầu vào lớn. Sử dụng bộ nhớ cache cũng có thể là một vấn đề nếu các mẫu hình truy cập bộ nhớ không phù hợp với hệ thống phân cấp bộ nhớ cache.
**Trong trường hợp này, tăng tốc phần cứng là cách duy nhất để tối ưu hóa hoàn toàn hiệu suất của ZKP. **
Tăng tốc phần cứng
Khi nói đến tăng tốc phần cứng, nó nhắc nhở chúng ta về cách ASIC và GPU thống trị khai thác Bitcoin và Ethereum.
Mặc dù tối ưu hóa phần mềm cũng quan trọng và có giá trị như nhau, nhưng chúng có những hạn chế. Mặt khác, tối ưu hóa phần cứng có thể cải thiện tính song song bằng cách thiết kế FPGA với nhiều đơn vị xử lý, chẳng hạn như giảm đồng bộ hóa luồng hoặc vectơ hóa. Truy cập bộ nhớ cũng có thể được tối ưu hóa hiệu quả hơn bằng cách cải thiện hệ thống phân cấp bộ nhớ và mẫu hình truy cập.
Bây giờ trong không gian ZKP, xu hướng chính dường như đã thay đổi: GPU và FPGA.
Trong ngắn hạn, GPU có lợi thế về giá, đặc biệt là sau khi ETH chuyển sang bằng chứng cổ phần (POS), khiến một số lượng lớn các thợ đào GPU không hoạt động và ở chế độ chờ. Ngoài ra, GPU có lợi thế là chu kỳ phát triển ngắn và cung cấp cho các nhà phát triển rất nhiều tính song song "plug-and-play".
Tuy nhiên, FPGA nên bắt kịp, đặc biệt là khi so sánh các yếu tố hình thức và mức tiêu thụ điện năng. FPGA cũng cung cấp độ trễ thấp hơn cho các luồng dữ liệu tốc độ cao. Khi nhiều FPGA được nhóm lại với nhau, chúng cung cấp hiệu suất tốt hơn so với các cụm GPU.
GPU SO VỚI FPGA
GPU:
Thời gian phát triển: GPU cung cấp thời gian phát triển nhanh. Tài liệu dành cho nhà phát triển cho các khung như CUDA và OpenCL được phát triển tốt và phổ biến.
Tiêu thụ điện năng: GPU rất "ngốn điện". Ngay cả khi các nhà phát triển tận dụng tính song song ở cấp độ dữ liệu và song song cấp luồng, GPU vẫn tiêu thụ rất nhiều năng lượng.
Tính khả dụng: GPU cấp tiêu dùng rẻ và sẵn có ngay bây giờ.
FPGA:
Chu kỳ phát triển: FPGA có chu kỳ phát triển phức tạp hơn và đòi hỏi các kỹ sư chuyên môn hơn. FPGA cho phép các kỹ sư đạt được nhiều tối ưu hóa "cấp thấp" mà GPU không thể.
Độ trễ: FPGA cung cấp độ trễ thấp hơn, đặc biệt là khi xử lý các luồng dữ liệu lớn.
Chi phí so với tính khả dụng: FPGA đắt hơn GPU và không có sẵn như GPU.
ZPRIZE
Ngày nay, khi nói đến nút cổ chai của tối ưu hóa phần cứng và ZKP, có một sự cạnh tranh không thể tránh khỏi - **ZPRIZE **
ZPrize là một trong những sáng kiến quan trọng nhất trong lĩnh vực ZK hiện nay. ZPrize là một cuộc thi khuyến khích các nhóm phát triển khả năng tăng tốc phần cứng cho các tắc nghẽn chính của ZKP (ví dụ: MSM, NTT, Poseidon, v.v.) trên nhiều nền tảng (ví dụ: FPGA, GPU, thiết bị di động và trình duyệt) dựa trên độ trễ, thông lượng và hiệu quả.
Kết quả rất thú vị. Ví dụ, những cải tiến về GPU là rất lớn:
MSM ở mức 2 ^ 26 đã tăng 131% từ 5,86 giây lên 2,52 giây. Mặt khác, các giải pháp FPGA có xu hướng không có bất kỳ điểm chuẩn nào so với kết quả GPU, có điểm chuẩn trước đó để so sánh và hầu hết các giải pháp FPGA đều có nguồn mở lần đầu tiên với các thuật toán như vậy dự kiến sẽ cải thiện trong tương lai.
Những kết quả này cho thấy hướng mà hầu hết các nhà phát triển cảm thấy thoải mái trong việc phát triển các giải pháp tăng tốc phần cứng của họ. Nhiều đội cạnh tranh cho hạng mục GPU, nhưng chỉ một tỷ lệ nhỏ cạnh tranh cho hạng mục FPGA. Tôi không chắc liệu đó có phải là do thiếu kinh nghiệm khi phát triển cho FPGA hay không, hoặc nếu hầu hết các công ty / nhóm FPGA chọn phát triển bí mật để bán các giải pháp của họ thương mại.
ZPrize đã cung cấp một số nghiên cứu rất thú vị cho cộng đồng. Khi nhiều vòng ZPrize bắt đầu, chúng ta sẽ thấy ngày càng nhiều giải pháp và vấn đề thú vị xuất hiện.
Ví dụ thực tế về tăng tốc phần cứng
Lấy Groth16 làm ví dụ, nếu chúng ta kiểm tra việc triển khai rapidsnark cho Groth16, chúng ta có thể quan sát thấy rằng hai hoạt động chính được thực hiện: FFT (Biến đổi Fourier nhanh) và MSM (Nhân đa hướng); Hai hoạt động cơ bản này là phổ biến trong nhiều hệ thống chứng minh. Thời gian thực hiện của chúng liên quan trực tiếp đến số lượng ràng buộc trong mạch. Đương nhiên, số lượng ràng buộc tăng lên khi các mạch phức tạp hơn được viết.
Để hiểu được các hoạt động FFT và MSM chuyên sâu về mặt tính toán như thế nào, chúng ta có thể kiểm tra điểm chuẩn của mạch Groth16 của Ingonyama (quy trình Vanilla C2 của Filecoin được thực hiện trên khu vực 32GB) và kết quả như sau
Như thể hiện trong hình trên, MSM (Multiscalar Multiscalar Multiplication) có thể tốn thời gian và là một nút cổ chai hiệu suất nghiêm trọng đối với nhiều provers, khiến MSM trở thành một trong những toán tử mật mã quan trọng nhất cần được tăng tốc.
Vậy MSM chiếm bao nhiêu tính toán cho người chứng minh trong các hệ thống chứng minh ZK khác? Điều này được thể hiện trong hình dưới đây
Ở Plonk, MSM chiếm hơn 85% chi phí chung, như thể hiện trong bài báo mới nhất của Ingonyama, Pipe MSM. **
Vậy tăng tốc phần cứng nên tăng tốc MSM như thế nào? **
MSM
Trước khi chúng ta nói về cách tăng tốc MSM, chúng ta cần hiểu MSM là gì
Multi-Scalar Multiplication (MSM) là một thuật toán để tính tổng của nhiều phép nhân vô hướng ở dạng sau
trong đó G là một điểm trong nhóm đường cong elip, a là vô hướng và kết quả của MSM cũng sẽ là điểm đường cong elip
Chúng ta có thể phân tách MSM thành hai thành phần phụ chính:
Phép nhân mô-đun
Bổ sung điểm đường cong elip
Hãy lấy Affine (x, y) làm ví dụ để thực hiện thao tác P + Q ngây thơ.
Khi chúng ta muốn tính P + Q = R, chúng ta cần tính một giá trị k, bằng abscissa của k và P,Q
Lấy tọa độ của R. Quá trình tính toán như trên, trong quá trình này chúng ta thực hiện 2 lần phép nhân, 1 phép toán vuông, 1 phép toán nghịch đảo và nhiều lần phép cộng và trừ. Điều đáng chú ý là các hoạt động trên được thực hiện trong một trường hữu hạn, tức là dưới mod P. Trong thực tế, P sẽ rất lớn. **
Chi phí của phép toán trên là tìm nghịch đảo >> phép nhân ** **> **** bình phương, và chi phí cộng và trừ là không đáng kể.
Vì vậy, chúng tôi muốn tránh nghịch đảo càng nhiều càng tốt, bởi vì chi phí của một lần đảo ngược ít nhất là gấp trăm lần phép nhân. Chúng ta có thể làm điều này bằng cách mở rộng hệ tọa độ, nhưng với chi phí tăng số phép nhân trong quy trình, chẳng hạn như tọa độ Jacobian: XYZ += XYZ và nhân hơn 10 lần, tùy thuộc vào thuật toán cộng. **
** GPU VS FPGA MSM tăng tốc **
Phần này so sánh hai triển khai MSM hàng đầu, PipeMSM và Sppark, trong đó PipeMSM được triển khai trên FPGA và Sppark được triển khai trên GPU.
Sppark và PipeMSM sử dụng thuật toán Pippenger hiện đại để triển khai MSM, còn được gọi là thuật toán bucket; **
Sppark được thực hiện bằng CUDA; Các phiên bản của chúng có tính song song cao và đã đạt được kết quả ấn tượng khi chạy trên các GPU mới nhất.
Tuy nhiên, PipeMSM không chỉ tối ưu hóa thuật toán mà còn cung cấp tối ưu hóa cho các nguyên thủy toán học của Modular Multiplication và EC Addition. PipeMSM xử lý toàn bộ "MSM stack", thực hiện một loạt các thủ thuật toán học và tối ưu hóa nhằm làm cho MSM phù hợp hơn với phần cứng và thiết kế một thiết kế phần cứng được thiết kế để giảm độ trễ với trọng tâm là song song.
Chúng ta hãy tóm tắt nhanh về việc triển khai PipeMSM.
Độ trễ thấp
PipeMSM được thiết kế để cung cấp độ trễ thấp khi thực hiện nhiều MSM trên một số lượng lớn đầu vào. GPU không cung cấp độ trễ thấp xác định do tỷ lệ tần số động và GPU điều chỉnh tốc độ xung nhịp dựa trên khối lượng công việc.
Nhưng nhờ thiết kế phần cứng được tối ưu hóa, việc triển khai FPGA có thể cung cấp hiệu suất và độ trễ xác định cho khối lượng công việc cụ thể.
** Triển khai bổ sung EC **
Phép cộng điểm đường cong Elliptic (Bổ sung EC) được triển khai dưới dạng công thức có độ trễ thấp, song song cao và ** hoàn chỉnh ** (hoàn thành có nghĩa là nó tính toán chính xác tổng của hai điểm bất kỳ trong nhóm đường cong elip). Bổ sung điểm đường cong elip được sử dụng theo cách đường ống trong mô-đun bổ sung EC để giảm độ trễ.
Chúng tôi đã chọn biểu diễn tọa độ dưới dạng tọa độ chiếu và trên thuật toán cộng, chúng tôi sử dụng công thức cộng điểm đường cong elip hoàn chỉnh. Ưu điểm chính là chúng tôi ** không phải đối phó với các trường hợp cạnh **. Hoàn thành công thức;
Chúng tôi đã triển khai công thức cộng này theo kiểu đường ống và song song, và mạch cộng đường cong elip FPGA của chúng tôi chỉ cần 12 phép nhân, 17 phép cộng và công thức này đã được thực thi. Công thức ban đầu yêu cầu 15 phép nhân modulo và 13 phép cộng. Thiết kế FPGA như sau
Nhiều mod
Chúng tôi đã sử dụng các thuật toán Barrett Reduction và Karatsuba.
Barrett Reduction là một thuật toán tính toán hiệu quả r ≡ ab mod p (trong đó p là cố định). Barrett Reduction cố gắng thay thế phép chia (một hoạt động tốn kém) bằng phép chia gần đúng. Dung sai lỗi có thể được chọn để mô tả phạm vi mà chúng tôi đang tìm kiếm kết quả chính xác. Chúng tôi thấy rằng khả năng chịu lỗi lớn cho phép sử dụng các hằng số khử nhỏ hơn; Điều này làm giảm kích thước của các giá trị trung gian được sử dụng trong các hoạt động khử modulo, làm giảm số lượng phép nhân cần thiết để tính kết quả cuối cùng.
Trong hộp màu xanh bên dưới, chúng ta có thể thấy rằng do khả năng chịu lỗi cao, chúng ta phải thực hiện nhiều lần kiểm tra để tìm ra kết quả chính xác.
Tóm lại, thuật toán Karatsuba được sử dụng để tối ưu hóa phép nhân mà chúng ta thực hiện trong Barrett Reduction. Thuật toán của Karatsuba đơn giản hóa việc nhân hai chữ số n với phép nhân của ba n / 2 chữ số; Những phép nhân này có thể đơn giản hóa số chữ số đủ hẹp để được tính toán trực tiếp bằng phần cứng. **Chi tiết có thể được đọc trong bài báo của Ingo: Pipe MSM **
Sử dụng các toán tử trên, chúng tôi đã phát triển triển khai MSM song song, độ trễ thấp.
Ý tưởng cốt lõi là thay vì tính toán toàn bộ MSM cùng một lúc, mỗi đoạn được chuyển song song vào bộ cộng EC. Kết quả của bộ cộng EC được tích lũy vào MSM cuối cùng.
Kết quả cuối cùng****
Sơ đồ trên cho thấy sự so sánh giữa Sppark và PipeMSM.
Nổi bật nhất là tiết kiệm năng lượng đáng kể được cung cấp bởi FPGA, điều này có thể cực kỳ quan trọng đối với các hoạt động tạo bằng chứng quy mô lớn trong tương lai. Cần lưu ý rằng việc triển khai của chúng tôi đã được tạo mẫu và đo điểm chuẩn theo @125MHz và việc tăng tốc độ xung nhịp lên @500MHz có thể tăng thời gian tính toán lên gấp 4 lần trở lên.
Một ưu điểm khác của việc sử dụng FPGA của chúng tôi là chúng có thể được cài đặt trong các máy chủ khung nhỏ vì chúng tiêu thụ ít năng lượng hơn và tạo ra ít nhiệt hơn.
Chúng tôi đang trong giai đoạn đầu của kỹ thuật FPGA cho ZKP và nên mong đợi những cải tiến hơn nữa trong các thuật toán. Ngoài ra, FPGA đang tính toán MSM trong khi CPU không hoạt động và có thể đạt được thời gian nhanh hơn bằng cách sử dụng FPGA kết hợp với tài nguyên hệ thống (CPU / GPU).
Tóm tắt
ZKP đã trở thành một công nghệ quan trọng cho các hệ thống phân tán.
Việc áp dụng ZKP sẽ vượt xa việc chỉ mở rộng cấp độ Ethereum, cho phép thuê ngoài tính toán cho các bên thứ ba không đáng tin cậy, cho phép phát triển các hệ thống trước đây không thể, chẳng hạn như điện toán đám mây phân tán, hệ thống nhận dạng, v.v.
Theo truyền thống, tối ưu hóa ZKP đã tập trung vào các cải tiến cấp phần mềm, nhưng khi nhu cầu về hiệu suất vượt trội hơn tăng lên, chúng ta sẽ thấy các giải pháp tăng tốc tiên tiến hơn liên quan đến cả phần cứng và phần mềm.
Hiện tại, các giải pháp tăng tốc chúng ta thấy chủ yếu sử dụng GPU, vì thời gian phát triển sử dụng CUDA ngắn, còn GPU tiêu dùng hiện nay rất rẻ và dồi dào. GPU cũng cung cấp hiệu suất đáng kinh ngạc. Vì vậy, GPU khó có thể biến mất khỏi không gian này sớm.
Khi các nhóm phát triển phức tạp hơn tham gia vào không gian, có khả năng chúng ta sẽ thấy FPGA dẫn đầu về hiệu quả năng lượng và hiệu suất. So với GPU, FPGA cung cấp nhiều tùy chỉnh cấp thấp hơn cũng như nhiều tùy chọn cấu hình hơn. FPGA cung cấp tốc độ phát triển nhanh hơn và linh hoạt hơn ASIC. Với sự phát triển nhanh chóng của thế giới ZKP, FPGA có thể được phản xạ lại bằng các chương trình khác nhau để phù hợp với các hệ thống và giải pháp cập nhật khác nhau.
Tuy nhiên, để tạo bằng chứng gần thời gian thực, có thể cần kết hợp cấu hình GPU / FPGA / ASIC tùy thuộc vào hệ thống mà chúng tôi tạo bằng chứng.
ZPU cũng có khả năng phát triển để cung cấp các giải pháp cực kỳ hiệu quả cho các máy phát điện bằng chứng quy mô lớn và các thiết bị công suất thấp (xem bài viết trước để biết chi tiết).
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Một kỷ nguyên mới của ZK được thúc đẩy bởi khả năng tăng tốc phần cứng
Câu chuyện cho đến nay
Bằng chứng không có kiến thức (ZKP) đang ngày càng trở nên quan trọng đối với các hệ thống phi tập trung. ZK lần đầu tiên xuất hiện trong mắt công chúng vì thành công của nó trong các dự án như ZCash, nhưng ngày nay ZK được biết đến như một giải pháp mở rộng quy mô cho Ethereum.
Tận dụng ZK, Lớp 2 (ví dụ: Cuộn và Đa giác), còn được gọi là Rollups, đang phát triển zkEVM (Máy ảo zk Ethereum). Các zkEVM này xử lý một loạt các giao dịch và tạo ra một bằng chứng nhỏ (tính bằng kilobyte). Chứng thực này có thể được sử dụng để xác minh cho toàn bộ mạng rằng lô giao dịch là hợp lệ và chính xác.
Tuy nhiên, công dụng của chúng không dừng lại ở đó. ZK cho phép một loạt các ứng dụng thú vị.
Lớp riêng 1 – Mina, ví dụ, ẩn các chi tiết của các giao dịch và dữ liệu trên blockchain của nó, cho phép người dùng chỉ chứng minh tính hợp lệ của các giao dịch của họ mà không tiết lộ chi tiết cụ thể của chính giao dịch. neptune.cash và Aleo cũng là những dự án rất thú vị.
Nền tảng đám mây phi tập trung - FedML và together.xyz cho phép các mô hình học máy (ML) được đào tạo theo cách phi tập trung, thuê ngoài tính toán vào mạng và xác minh tính chính xác của tính toán bằng ZKP. Druglike đang xây dựng một nền tảng khám phá ma túy cởi mở hơn bằng cách sử dụng các công nghệ tương tự.
** Lưu trữ phi tập trung ** - Filecoin đang cách mạng hóa lưu trữ đám mây và ZK là cốt lõi của nó, cho phép các nhà cung cấp dịch vụ lưu trữ chứng minh rằng họ đã lưu trữ đúng dữ liệu trong một khoảng thời gian.
GAME - Một phiên bản nâng cao hơn của Darkforest có thể xuất hiện, yêu cầu bằng chứng thời gian thực. ZK cũng có thể mở rộng trò chơi để giảm khả năng gian lận. Cũng có thể làm việc với một nền tảng đám mây phi tập trung để cho phép trò chơi trả tiền cho dịch vụ lưu trữ của riêng mình!
Danh tính - Xác thực phi tập trung hiện cũng có thể thông qua ZK. Xung quanh ý tưởng này, một số dự án thú vị đang được xây dựng. Ví dụ: notebook và zkemail (được khuyến nghị để tìm hiểu).
Tác động của ZK và các hệ thống phi tập trung là rất lớn, tuy nhiên, sự phát triển của câu chuyện chưa hoàn hảo, và vẫn còn nhiều trở ngại và thách thức hiện nay. Quá trình bao gồm việc tạo ra các bằng chứng rất tốn tài nguyên và đòi hỏi nhiều phép toán phức tạp. Khi các nhà phát triển tìm cách xây dựng các giao thức và hệ thống phức tạp và đầy tham vọng hơn bằng cách sử dụng công nghệ ZK, cho cả quy trình tạo bằng chứng và xác minh, các nhà phát triển đang yêu cầu kích thước bằng chứng nhỏ hơn, hiệu suất nhanh hơn và tối ưu hóa tốt hơn.
Trong bài viết này, chúng ta sẽ khám phá tình trạng tăng tốc phần cứng hiện tại và cách nó sẽ đóng vai trò quan trọng trong việc thúc đẩy việc áp dụng ZK.
Snark vs Stark
Có hai kỹ thuật zero-knowledge phổ biến hiện nay, zk-STARK và zk-SNARK (chúng tôi đã bỏ qua Bulletproofs trong bài viết này).
| | | | | --- | --- | --- | | zk-STARK | zk-SNARK | | | Sự phức tạp - Prover | O(N * poly-log(N)) | O(N * log(N)) | | Độ phức tạp - Trình xác minh | O(poly-log(N)) | O(1) | | Kích thước bằng chứng | 45KB-200KB | ~ 288 byte | | 抗量子 | Có (dựa trên hàm băm) | Không | | Thiết lập đáng tin cậy | Không | Vâng | | Không có kiến thức | Có | Có | | Tương tác | Tương tác hoặc không tương tác | Không tương tác | | Tài liệu dành cho nhà phát triển | Hạn chế, nhưng mở rộng Tốt |
表1:Snark VS Stark
Như đã đề cập ở trên, có sự khác biệt và đánh đổi giữa hai người. Điểm quan trọng nhất là thiết lập đáng tin cậy của hệ thống dựa trên zk-SNARK phụ thuộc vào ít nhất một người tham gia trung thực tham gia vào quá trình thiết lập đáng tin cậy và khóa của họ bị hủy vào cuối quá trình. Về mặt xác minh trên chuỗi, zk-SNARKs rẻ hơn nhiều về phí gas. Ngoài ra, bằng chứng của zk-SNARKs cũng nhỏ hơn đáng kể, làm cho chúng rẻ hơn để lưu trữ trên chuỗi.
Hiện tại, zk-SNARKs phổ biến hơn zk-STARKs. Lý do rất có thể là zk-SNARKs có lịch sử lâu đời hơn nhiều. Một lý do khác có thể là Zcash, một trong những blockchain ZK đầu tiên, đã sử dụng zk-SNARKs, vì vậy hầu hết các công cụ và tài liệu phát triển hiện tại đều xoay quanh hệ sinh thái zk-SNARK.
Cách xây dựng Ứng dụng ZK
Các nhà phát triển có thể cần hai thành phần để hoàn thành việc phát triển ứng dụng ZK
Phương pháp tính toán biểu thức thân thiện với ZK (DSL hoặc thư viện cấp thấp).
Một hệ thống chứng thực thực hiện hai chức năng: Chứng minh và Xác minh.
DSL (ngôn ngữ dành riêng cho miền) và thư viện cấp thấp
Khi nói đến DSL, có rất nhiều lựa chọn, chẳng hạn như Circom, Halo2, Noir, v.v. Circom có lẽ là phổ biến nhất tại thời điểm này.
Khi nói đến các thư viện cấp thấp, một ví dụ phổ biến là Arkworks; Ngoài ra còn có các thư viện đang được phát triển, chẳng hạn như ICICLE, là một thư viện tăng tốc CUDA.
Các DSL này được thiết kế để xuất ra các hệ thống hạn chế. Không giống như chương trình thông thường, thường được đánh giá dưới dạng x: = y *z, cùng một chương trình ở dạng ràng buộc trông giống như x-y * z = 0. Bằng cách biểu diễn chương trình dưới dạng một hệ thống các ràng buộc, chúng tôi thấy rằng các hoạt động như cộng hoặc nhân có thể được biểu diễn bằng một ràng buộc duy nhất. Tuy nhiên, các hoạt động phức tạp hơn, chẳng hạn như hoạt động bit, có thể yêu cầu hàng trăm ràng buộc!
Do đó, việc triển khai một số hàm băm như các chương trình thân thiện với ZK trở nên phức tạp. Trong các bằng chứng không có kiến thức, các hàm băm thường được sử dụng để đảm bảo tính toàn vẹn của dữ liệu và / hoặc để xác minh các thuộc tính cụ thể của dữ liệu, nhưng do số lượng lớn các ràng buộc của các hoạt động bit, một số hàm băm rất khó thích ứng với môi trường của các bằng chứng không có kiến thức. Sự phức tạp này có thể ảnh hưởng đến hiệu quả của việc tạo và xác minh bằng chứng, và do đó trở thành một vấn đề mà các nhà phát triển cần xem xét và giải quyết khi xây dựng các ứng dụng dựa trên ZK
Do đó, việc triển khai một số hàm băm để thân thiện với ZK trở nên phức tạp.
Minh
Một hệ thống chứng minh có thể được ví như một phần mềm hoàn thành hai nhiệm vụ chính: tạo ra bằng chứng và xác minh bằng chứng. Các hệ thống chứng minh thường chấp nhận mạch, bằng chứng và các thông số công khai / riêng tư làm đầu vào.
Hai hệ thống chứng minh phổ biến nhất là dòng Groth16 và PLONK (Plonk, HyperPlonk, UltraPlonk)
| | | | | | | | --- | --- | --- | --- | --- | --- | | | Thiết lập đáng tin cậy | Kích thước bằng chứng | Sự phức tạp của Prover | Độ phức tạp của trình xác minh | Linh hoạt | | Groth16 | Mạch cụ thể | Nhỏ | Thấp | Thấp | Thấp | | Plonk | Phổ quát | Lớn | Cao | 常数 | Cao |
表2:Groth16 vs Plonk
Như thể hiện trong Bảng 2, Groth16 yêu cầu quy trình thiết lập đáng tin cậy, nhưng Groth16 cung cấp cho chúng tôi thời gian chứng minh và xác minh nhanh hơn, cũng như kích thước bằng chứng không đổi.
Plonk cung cấp một thiết lập chung thực hiện giai đoạn tiền xử lý cho mạch bạn đang chạy mỗi khi tạo bằng chứng. Mặc dù hỗ trợ nhiều mạch, thời gian xác minh của Plonk là không đổi.
Cũng có sự khác biệt giữa hai về các ràng buộc. Groth16 phát triển tuyến tính về kích thước hạn chế và thiếu tính linh hoạt, trong khi Plonk linh hoạt hơn.
Nhìn chung, hãy hiểu rằng hiệu suất liên quan trực tiếp đến số lượng ràng buộc trong ứng dụng ZK của bạn. Càng nhiều ràng buộc, người chứng minh càng phải tính toán nhiều hoạt động.
Bottleneck
Hệ thống chứng minh bao gồm hai phép toán chính: phép nhân đa hướng (MSM) và biến đổi Fourier nhanh (FFT). Hôm nay chúng ta sẽ khám phá các hệ thống mà cả hai tồn tại, nơi MSM có thể chiếm khoảng 60% thời gian chạy, trong khi FFT có thể chiếm khoảng 30%.
MSM yêu cầu nhiều quyền truy cập bộ nhớ, trong hầu hết các trường hợp tiêu tốn rất nhiều bộ nhớ trên máy, đồng thời thực hiện nhiều thao tác nhân vô hướng.
Các thuật toán FFT thường yêu cầu sắp xếp lại dữ liệu đầu vào thành một thứ tự cụ thể để thực hiện chuyển đổi. Điều này có thể đòi hỏi nhiều chuyển động dữ liệu và có thể là một nút cổ chai, đặc biệt là đối với kích thước đầu vào lớn. Sử dụng bộ nhớ cache cũng có thể là một vấn đề nếu các mẫu hình truy cập bộ nhớ không phù hợp với hệ thống phân cấp bộ nhớ cache.
**Trong trường hợp này, tăng tốc phần cứng là cách duy nhất để tối ưu hóa hoàn toàn hiệu suất của ZKP. **
Tăng tốc phần cứng
Khi nói đến tăng tốc phần cứng, nó nhắc nhở chúng ta về cách ASIC và GPU thống trị khai thác Bitcoin và Ethereum.
Mặc dù tối ưu hóa phần mềm cũng quan trọng và có giá trị như nhau, nhưng chúng có những hạn chế. Mặt khác, tối ưu hóa phần cứng có thể cải thiện tính song song bằng cách thiết kế FPGA với nhiều đơn vị xử lý, chẳng hạn như giảm đồng bộ hóa luồng hoặc vectơ hóa. Truy cập bộ nhớ cũng có thể được tối ưu hóa hiệu quả hơn bằng cách cải thiện hệ thống phân cấp bộ nhớ và mẫu hình truy cập.
Bây giờ trong không gian ZKP, xu hướng chính dường như đã thay đổi: GPU và FPGA.
Trong ngắn hạn, GPU có lợi thế về giá, đặc biệt là sau khi ETH chuyển sang bằng chứng cổ phần (POS), khiến một số lượng lớn các thợ đào GPU không hoạt động và ở chế độ chờ. Ngoài ra, GPU có lợi thế là chu kỳ phát triển ngắn và cung cấp cho các nhà phát triển rất nhiều tính song song "plug-and-play".
Tuy nhiên, FPGA nên bắt kịp, đặc biệt là khi so sánh các yếu tố hình thức và mức tiêu thụ điện năng. FPGA cũng cung cấp độ trễ thấp hơn cho các luồng dữ liệu tốc độ cao. Khi nhiều FPGA được nhóm lại với nhau, chúng cung cấp hiệu suất tốt hơn so với các cụm GPU.
GPU SO VỚI FPGA
GPU:
Thời gian phát triển: GPU cung cấp thời gian phát triển nhanh. Tài liệu dành cho nhà phát triển cho các khung như CUDA và OpenCL được phát triển tốt và phổ biến.
Tiêu thụ điện năng: GPU rất "ngốn điện". Ngay cả khi các nhà phát triển tận dụng tính song song ở cấp độ dữ liệu và song song cấp luồng, GPU vẫn tiêu thụ rất nhiều năng lượng.
Tính khả dụng: GPU cấp tiêu dùng rẻ và sẵn có ngay bây giờ.
FPGA:
Chu kỳ phát triển: FPGA có chu kỳ phát triển phức tạp hơn và đòi hỏi các kỹ sư chuyên môn hơn. FPGA cho phép các kỹ sư đạt được nhiều tối ưu hóa "cấp thấp" mà GPU không thể.
Độ trễ: FPGA cung cấp độ trễ thấp hơn, đặc biệt là khi xử lý các luồng dữ liệu lớn.
Chi phí so với tính khả dụng: FPGA đắt hơn GPU và không có sẵn như GPU.
ZPRIZE
Ngày nay, khi nói đến nút cổ chai của tối ưu hóa phần cứng và ZKP, có một sự cạnh tranh không thể tránh khỏi - **ZPRIZE **
ZPrize là một trong những sáng kiến quan trọng nhất trong lĩnh vực ZK hiện nay. ZPrize là một cuộc thi khuyến khích các nhóm phát triển khả năng tăng tốc phần cứng cho các tắc nghẽn chính của ZKP (ví dụ: MSM, NTT, Poseidon, v.v.) trên nhiều nền tảng (ví dụ: FPGA, GPU, thiết bị di động và trình duyệt) dựa trên độ trễ, thông lượng và hiệu quả.
Kết quả rất thú vị. Ví dụ, những cải tiến về GPU là rất lớn:
MSM ở mức 2 ^ 26 đã tăng 131% từ 5,86 giây lên 2,52 giây. Mặt khác, các giải pháp FPGA có xu hướng không có bất kỳ điểm chuẩn nào so với kết quả GPU, có điểm chuẩn trước đó để so sánh và hầu hết các giải pháp FPGA đều có nguồn mở lần đầu tiên với các thuật toán như vậy dự kiến sẽ cải thiện trong tương lai.
Những kết quả này cho thấy hướng mà hầu hết các nhà phát triển cảm thấy thoải mái trong việc phát triển các giải pháp tăng tốc phần cứng của họ. Nhiều đội cạnh tranh cho hạng mục GPU, nhưng chỉ một tỷ lệ nhỏ cạnh tranh cho hạng mục FPGA. Tôi không chắc liệu đó có phải là do thiếu kinh nghiệm khi phát triển cho FPGA hay không, hoặc nếu hầu hết các công ty / nhóm FPGA chọn phát triển bí mật để bán các giải pháp của họ thương mại.
ZPrize đã cung cấp một số nghiên cứu rất thú vị cho cộng đồng. Khi nhiều vòng ZPrize bắt đầu, chúng ta sẽ thấy ngày càng nhiều giải pháp và vấn đề thú vị xuất hiện.
Ví dụ thực tế về tăng tốc phần cứng
Lấy Groth16 làm ví dụ, nếu chúng ta kiểm tra việc triển khai rapidsnark cho Groth16, chúng ta có thể quan sát thấy rằng hai hoạt động chính được thực hiện: FFT (Biến đổi Fourier nhanh) và MSM (Nhân đa hướng); Hai hoạt động cơ bản này là phổ biến trong nhiều hệ thống chứng minh. Thời gian thực hiện của chúng liên quan trực tiếp đến số lượng ràng buộc trong mạch. Đương nhiên, số lượng ràng buộc tăng lên khi các mạch phức tạp hơn được viết.
Để hiểu được các hoạt động FFT và MSM chuyên sâu về mặt tính toán như thế nào, chúng ta có thể kiểm tra điểm chuẩn của mạch Groth16 của Ingonyama (quy trình Vanilla C2 của Filecoin được thực hiện trên khu vực 32GB) và kết quả như sau
Như thể hiện trong hình trên, MSM (Multiscalar Multiscalar Multiplication) có thể tốn thời gian và là một nút cổ chai hiệu suất nghiêm trọng đối với nhiều provers, khiến MSM trở thành một trong những toán tử mật mã quan trọng nhất cần được tăng tốc.
Vậy MSM chiếm bao nhiêu tính toán cho người chứng minh trong các hệ thống chứng minh ZK khác? Điều này được thể hiện trong hình dưới đây
Ở Plonk, MSM chiếm hơn 85% chi phí chung, như thể hiện trong bài báo mới nhất của Ingonyama, Pipe MSM. **
Vậy tăng tốc phần cứng nên tăng tốc MSM như thế nào? **
MSM
Trước khi chúng ta nói về cách tăng tốc MSM, chúng ta cần hiểu MSM là gì
Multi-Scalar Multiplication (MSM) là một thuật toán để tính tổng của nhiều phép nhân vô hướng ở dạng sau
trong đó G là một điểm trong nhóm đường cong elip, a là vô hướng và kết quả của MSM cũng sẽ là điểm đường cong elip
Chúng ta có thể phân tách MSM thành hai thành phần phụ chính:
Phép nhân mô-đun
Bổ sung điểm đường cong elip
Hãy lấy Affine (x, y) làm ví dụ để thực hiện thao tác P + Q ngây thơ.
Khi chúng ta muốn tính P + Q = R, chúng ta cần tính một giá trị k, bằng abscissa của k và P,Q
Lấy tọa độ của R. Quá trình tính toán như trên, trong quá trình này chúng ta thực hiện 2 lần phép nhân, 1 phép toán vuông, 1 phép toán nghịch đảo và nhiều lần phép cộng và trừ. Điều đáng chú ý là các hoạt động trên được thực hiện trong một trường hữu hạn, tức là dưới mod P. Trong thực tế, P sẽ rất lớn. **
Chi phí của phép toán trên là tìm nghịch đảo >> phép nhân ** **> **** bình phương, và chi phí cộng và trừ là không đáng kể.
Vì vậy, chúng tôi muốn tránh nghịch đảo càng nhiều càng tốt, bởi vì chi phí của một lần đảo ngược ít nhất là gấp trăm lần phép nhân. Chúng ta có thể làm điều này bằng cách mở rộng hệ tọa độ, nhưng với chi phí tăng số phép nhân trong quy trình, chẳng hạn như tọa độ Jacobian: XYZ += XYZ và nhân hơn 10 lần, tùy thuộc vào thuật toán cộng. **
** GPU VS FPGA MSM tăng tốc **
Phần này so sánh hai triển khai MSM hàng đầu, PipeMSM và Sppark, trong đó PipeMSM được triển khai trên FPGA và Sppark được triển khai trên GPU.
Sppark và PipeMSM sử dụng thuật toán Pippenger hiện đại để triển khai MSM, còn được gọi là thuật toán bucket; **
Sppark được thực hiện bằng CUDA; Các phiên bản của chúng có tính song song cao và đã đạt được kết quả ấn tượng khi chạy trên các GPU mới nhất.
Tuy nhiên, PipeMSM không chỉ tối ưu hóa thuật toán mà còn cung cấp tối ưu hóa cho các nguyên thủy toán học của Modular Multiplication và EC Addition. PipeMSM xử lý toàn bộ "MSM stack", thực hiện một loạt các thủ thuật toán học và tối ưu hóa nhằm làm cho MSM phù hợp hơn với phần cứng và thiết kế một thiết kế phần cứng được thiết kế để giảm độ trễ với trọng tâm là song song.
Chúng ta hãy tóm tắt nhanh về việc triển khai PipeMSM.
Độ trễ thấp
PipeMSM được thiết kế để cung cấp độ trễ thấp khi thực hiện nhiều MSM trên một số lượng lớn đầu vào. GPU không cung cấp độ trễ thấp xác định do tỷ lệ tần số động và GPU điều chỉnh tốc độ xung nhịp dựa trên khối lượng công việc.
Nhưng nhờ thiết kế phần cứng được tối ưu hóa, việc triển khai FPGA có thể cung cấp hiệu suất và độ trễ xác định cho khối lượng công việc cụ thể.
** Triển khai bổ sung EC **
Phép cộng điểm đường cong Elliptic (Bổ sung EC) được triển khai dưới dạng công thức có độ trễ thấp, song song cao và ** hoàn chỉnh ** (hoàn thành có nghĩa là nó tính toán chính xác tổng của hai điểm bất kỳ trong nhóm đường cong elip). Bổ sung điểm đường cong elip được sử dụng theo cách đường ống trong mô-đun bổ sung EC để giảm độ trễ.
Chúng tôi đã chọn biểu diễn tọa độ dưới dạng tọa độ chiếu và trên thuật toán cộng, chúng tôi sử dụng công thức cộng điểm đường cong elip hoàn chỉnh. Ưu điểm chính là chúng tôi ** không phải đối phó với các trường hợp cạnh **. Hoàn thành công thức;
Chúng tôi đã triển khai công thức cộng này theo kiểu đường ống và song song, và mạch cộng đường cong elip FPGA của chúng tôi chỉ cần 12 phép nhân, 17 phép cộng và công thức này đã được thực thi. Công thức ban đầu yêu cầu 15 phép nhân modulo và 13 phép cộng. Thiết kế FPGA như sau
Nhiều mod
Chúng tôi đã sử dụng các thuật toán Barrett Reduction và Karatsuba.
Barrett Reduction là một thuật toán tính toán hiệu quả r ≡ ab mod p (trong đó p là cố định). Barrett Reduction cố gắng thay thế phép chia (một hoạt động tốn kém) bằng phép chia gần đúng. Dung sai lỗi có thể được chọn để mô tả phạm vi mà chúng tôi đang tìm kiếm kết quả chính xác. Chúng tôi thấy rằng khả năng chịu lỗi lớn cho phép sử dụng các hằng số khử nhỏ hơn; Điều này làm giảm kích thước của các giá trị trung gian được sử dụng trong các hoạt động khử modulo, làm giảm số lượng phép nhân cần thiết để tính kết quả cuối cùng.
Trong hộp màu xanh bên dưới, chúng ta có thể thấy rằng do khả năng chịu lỗi cao, chúng ta phải thực hiện nhiều lần kiểm tra để tìm ra kết quả chính xác.
Tóm lại, thuật toán Karatsuba được sử dụng để tối ưu hóa phép nhân mà chúng ta thực hiện trong Barrett Reduction. Thuật toán của Karatsuba đơn giản hóa việc nhân hai chữ số n với phép nhân của ba n / 2 chữ số; Những phép nhân này có thể đơn giản hóa số chữ số đủ hẹp để được tính toán trực tiếp bằng phần cứng. **Chi tiết có thể được đọc trong bài báo của Ingo: Pipe MSM **
Sử dụng các toán tử trên, chúng tôi đã phát triển triển khai MSM song song, độ trễ thấp.
Ý tưởng cốt lõi là thay vì tính toán toàn bộ MSM cùng một lúc, mỗi đoạn được chuyển song song vào bộ cộng EC. Kết quả của bộ cộng EC được tích lũy vào MSM cuối cùng.
Kết quả cuối cùng****
Sơ đồ trên cho thấy sự so sánh giữa Sppark và PipeMSM.
Nổi bật nhất là tiết kiệm năng lượng đáng kể được cung cấp bởi FPGA, điều này có thể cực kỳ quan trọng đối với các hoạt động tạo bằng chứng quy mô lớn trong tương lai. Cần lưu ý rằng việc triển khai của chúng tôi đã được tạo mẫu và đo điểm chuẩn theo @125MHz và việc tăng tốc độ xung nhịp lên @500MHz có thể tăng thời gian tính toán lên gấp 4 lần trở lên.
Một ưu điểm khác của việc sử dụng FPGA của chúng tôi là chúng có thể được cài đặt trong các máy chủ khung nhỏ vì chúng tiêu thụ ít năng lượng hơn và tạo ra ít nhiệt hơn.
Chúng tôi đang trong giai đoạn đầu của kỹ thuật FPGA cho ZKP và nên mong đợi những cải tiến hơn nữa trong các thuật toán. Ngoài ra, FPGA đang tính toán MSM trong khi CPU không hoạt động và có thể đạt được thời gian nhanh hơn bằng cách sử dụng FPGA kết hợp với tài nguyên hệ thống (CPU / GPU).
Tóm tắt
ZKP đã trở thành một công nghệ quan trọng cho các hệ thống phân tán.
Việc áp dụng ZKP sẽ vượt xa việc chỉ mở rộng cấp độ Ethereum, cho phép thuê ngoài tính toán cho các bên thứ ba không đáng tin cậy, cho phép phát triển các hệ thống trước đây không thể, chẳng hạn như điện toán đám mây phân tán, hệ thống nhận dạng, v.v.
Theo truyền thống, tối ưu hóa ZKP đã tập trung vào các cải tiến cấp phần mềm, nhưng khi nhu cầu về hiệu suất vượt trội hơn tăng lên, chúng ta sẽ thấy các giải pháp tăng tốc tiên tiến hơn liên quan đến cả phần cứng và phần mềm.
Hiện tại, các giải pháp tăng tốc chúng ta thấy chủ yếu sử dụng GPU, vì thời gian phát triển sử dụng CUDA ngắn, còn GPU tiêu dùng hiện nay rất rẻ và dồi dào. GPU cũng cung cấp hiệu suất đáng kinh ngạc. Vì vậy, GPU khó có thể biến mất khỏi không gian này sớm.
Khi các nhóm phát triển phức tạp hơn tham gia vào không gian, có khả năng chúng ta sẽ thấy FPGA dẫn đầu về hiệu quả năng lượng và hiệu suất. So với GPU, FPGA cung cấp nhiều tùy chỉnh cấp thấp hơn cũng như nhiều tùy chọn cấu hình hơn. FPGA cung cấp tốc độ phát triển nhanh hơn và linh hoạt hơn ASIC. Với sự phát triển nhanh chóng của thế giới ZKP, FPGA có thể được phản xạ lại bằng các chương trình khác nhau để phù hợp với các hệ thống và giải pháp cập nhật khác nhau.
Tuy nhiên, để tạo bằng chứng gần thời gian thực, có thể cần kết hợp cấu hình GPU / FPGA / ASIC tùy thuộc vào hệ thống mà chúng tôi tạo bằng chứng.
ZPU cũng có khả năng phát triển để cung cấp các giải pháp cực kỳ hiệu quả cho các máy phát điện bằng chứng quy mô lớn và các thiết bị công suất thấp (xem bài viết trước để biết chi tiết).