Tìm hiểu lịch sử của bằng chứng không có kiến ​​thức

Nguồn: Cộng đồng Denglian

Bằng chứng kiến ​​thức không có kiến ​​thức, ngắn gọn, không tương tác (zk-SNARK) là một công cụ mã hóa nguyên thủy mạnh mẽ cho phép một bên, tức là Người chứng minh thuyết phục một bên khác, người xác minh, rằng một tuyên bố nhất định là đúng mà không tiết lộ bất kỳ thông tin nào khác ngoài tính hợp lệ của tuyên bố đó. Chúng đã thu hút sự chú ý rộng rãi nhờ các ứng dụng của chúng trong tính toán riêng tư có thể kiểm chứng, cung cấp bằng chứng về tính chính xác của việc thực thi chương trình máy tính và giúp mở rộng quy mô chuỗi khối. Chúng tôi tin rằng SNARK sẽ có tác động đáng kể đến việc định hình thế giới của chúng ta, như chúng tôi mô tả trong bài viết ^[6] của mình. SNARK là một thuật ngữ chung cho các loại hệ thống chứng minh khác nhau, sử dụng các sơ đồ cam kết đa thức (PCS), sơ đồ số học, bằng chứng Oracle tương tác (IOP) hoặc bằng chứng có thể kiểm tra xác suất (PCP) khác nhau. Tuy nhiên, những ý tưởng và khái niệm cơ bản này đã có từ giữa những năm 1980. Sau sự ra đời của Bitcoin và Ethereum, công việc phát triển đã tăng tốc đáng kể, điều này được chứng minh là một trường hợp sử dụng thú vị và mạnh mẽ vì bạn có thể sử dụng bằng chứng không có kiến ​​thức (thường được gọi là bằng chứng hợp lệ cho trường hợp sử dụng cụ thể này) để mở rộng chúng. SNARK là một công cụ quan trọng để mở rộng blockchain. Như Ben-Sasson mô tả, vài năm qua đã chứng kiến ​​sự bùng nổ của các bằng chứng mật mã trong kỷ Cambri^[7] . Mọi hệ thống chứng minh đều có những ưu điểm và nhược điểm và được thiết kế với sự cân nhắc nhất định. Những tiến bộ về phần cứng, thuật toán tốt hơn, các đối số và tiện ích mới đã dẫn đến hiệu suất được cải thiện và tạo ra các hệ thống mới. Nhiều hệ thống trong số này đang được sử dụng trong sản xuất và chúng tôi tiếp tục vượt qua các giới hạn. Liệu chúng ta sẽ có một hệ thống chứng minh phổ quát hoạt động cho tất cả các ứng dụng hay một số hệ thống phù hợp với các nhu cầu khác nhau? Chúng tôi cho rằng khó có khả năng một hệ thống chứng minh sẽ thống trị tất cả các ứng dụng vì:

1. Sự đa dạng của các ứng dụng.

2. Chúng ta có nhiều loại ràng buộc khác nhau (liên quan đến bộ nhớ, thời gian xác minh, thời gian chứng minh).

3. Sự cần thiết của sự vững chắc (nếu một hệ thống chứng minh bị hỏng, chúng ta vẫn còn các hệ thống khác).

Ngay cả khi hệ thống chứng minh đã thay đổi nhiều, chúng đều có chung một đặc tính quan trọng: chứng minh có thể được xác minh nhanh chóng. Những khó khăn liên quan đến việc thay đổi các lớp cơ sở như Ethereum cũng được giải quyết bằng cách có một lớp xác thực bằng chứng và có thể dễ dàng điều chỉnh để xử lý các hệ thống bằng chứng mới.

Để cung cấp cái nhìn tổng quan về các đặc điểm khác nhau của SNARK:

• Các giả định về mật mã: hàm băm chống va chạm, rời rạc hóa về các đường cong elip Các bài toán logarit và kiến ​​thức về số mũ.

• Cài đặt minh bạch và cài đặt đáng tin cậy.

• Thời gian chứng minh: tuyến tính và siêu tuyến tính.

• Thời gian kiểm chứng: thời gian hằng số, logarit, cận tuyến tính, tuyến tính.

• Chứng minh kích thước.

• Sự tiện lợi của đệ quy.

• Lược đồ số học.

• Đa thức một biến và đa thức.

Bài viết này sẽ khám phá nguồn gốc của SNARK, một số khối xây dựng cơ bản và sự thăng trầm của các hệ thống chứng minh khác nhau. Bài viết này không có ý định cung cấp một phân tích toàn diện về các hệ thống chứng minh. Thay vào đó, chúng tôi tập trung vào những điều có tác động đến chúng tôi ở hiện tại. Tất nhiên, những phát triển này chỉ có thể thực hiện được trên cơ sở công sức và ý tưởng tuyệt vời của những người tiên phong trong lĩnh vực này.

Những điều cơ bản

Như chúng tôi đã đề cập, bằng chứng không có kiến ​​thức không phải là mới. Các định nghĩa, cơ sở, các định lý quan trọng và thậm chí cả các giao thức quan trọng đã được thiết lập từ giữa những năm 1980. Một số ý tưởng và giao thức chính được sử dụng để xây dựng SNARK hiện đại đã được đề xuất vào những năm 1990 (giao thức sumcheck), ngay cả trước Bitcoin (GKR năm 2007). Các vấn đề chính trong việc áp dụng vào thời điểm đó chủ yếu liên quan đến việc thiếu các trường hợp sử dụng mạnh mẽ (Internet không phát triển như ngày nay vào những năm 1990) và sức mạnh tính toán cần thiết.

Bằng chứng không có kiến ​​thức: nguồn gốc (1985/1989)

Lĩnh vực chứng minh không có kiến ​​thức xuất hiện lần đầu tiên trong tài liệu học thuật ở [ Goldwasser, Micali và Rackoff](https://people.csail.mit.edu/silvio/Selected Scientific Papers/Proof Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf?ref=blog.lambdaclass.com "Goldwasser, Micali và Rackoff"). Để thảo luận về nguồn gốc, bạn có thể xem video sau ^[8]. Bài báo giới thiệu các khái niệm về tính đầy đủ, tính đúng và kiến ​​thức bằng 0, đồng thời đưa ra cách xây dựng phần dư bậc hai và phần không dư bậc hai.

Giao thức Sumcheck (1992)

Giao thức sumcheck ^[9] được phát triển bởi Lund, Fortnow, Karloff và Nisan^{[10]< /sup > Được đề xuất vào năm 1992. Đây là một trong những khối xây dựng quan trọng nhất của bằng chứng tương tác ngắn gọn. Nó giúp chúng ta rút gọn phát biểu về tổng các đánh giá của một đa thức nhiều biến thành một đánh giá duy nhất tại một điểm được chọn ngẫu nhiên.}

Goldwasser-Kalai-Rothblum (GKR) (2007)

Giao thức GKR ^[11] là một giao thức tương tác có thời gian chạy của bộ chứng minh. Nó tỷ lệ tuyến tính với số lượng cổng trong mạch, trong khi thời gian chạy của trình xác minh tỷ lệ tuyến tính với kích thước của mạch. Trong giao thức này, người chứng minh và người xác minh thống nhất về mạch số học của quạt trong hai trên một trường hữu hạn có độ sâu d, trong đó lớp d tương ứng với lớp đầu vào và lớp 0 tương ứng với lớp đầu ra. Giao thức bắt đầu bằng việc khai báo đầu ra của mạch, giảm nó thành khai báo giá trị của lớp trước đó. Với đệ quy, chúng ta có thể biến điều này thành một khai báo về đầu vào của mạch, có thể dễ dàng kiểm tra. Những mức giảm này đạt được thông qua giao thức sumcheck.

sơ đồ cam kết đa thức KZG (2010)

sơ đồ cam kết đa thức KZG (sơ đồ cam kết đa thức KZG (PCS)) Kate, Zaverucha và Goldberg^[12] Năm 2010, một sơ đồ cam kết đa thức sử dụng các nhóm ghép nối song tuyến đã được giới thiệu. Cam kết bao gồm một phần tử nhóm duy nhất và người cam kết có thể mở cam kết một cách hiệu quả đối với bất kỳ đánh giá chính xác nào về đa thức. Hơn nữa, nhờ công nghệ xử lý hàng loạt, nhiều đánh giá có thể được mở ra. Các cam kết của KZG cung cấp nền tảng cơ bản cho một số SNARK hiệu quả như Pinocchio, Groth16 và Plonk. Đây cũng là cốt lõi của EIP-4844^[13]. Để hiểu trực quan về công nghệ xử lý hàng loạt, bạn có thể xem bài viết của chúng tôi về cầu Mina-Ethereum^[14].

SARK thực tế sử dụng đường cong elip

Cấu trúc SNARK thực tế đầu tiên xuất hiện vào năm 2013. Các cấu trúc này yêu cầu các bước tiền xử lý để tạo bằng chứng và khóa xác minh và dành riêng cho chương trình/mạch. Các khóa này có thể khá lớn và phụ thuộc vào các tham số bí mật nên vẫn chưa được biết; nếu không, chúng có thể giả mạo bằng chứng. Việc chuyển đổi mã thành thứ gì đó có thể chứng minh được đòi hỏi phải biên dịch mã thành một loạt các hệ thống ràng buộc đa thức. Ban đầu, việc này phải được thực hiện thủ công, tốn thời gian và dễ xảy ra lỗi. Tiến bộ trong lĩnh vực này cố gắng loại bỏ một số vấn đề chính:

1. Có nhiều bộ chứng minh hiệu quả hơn.

2. Giảm số lượng tiền xử lý.

3. Có các cài đặt chung thay vì cụ thể theo mạch.

4. Tránh cài đặt tin cậy.

5. Phát triển các phương pháp mô tả mạch bằng ngôn ngữ cấp cao thay vì viết thủ công các ràng buộc đa thức.

Pinocchio (2013)

Pinocchio^[15] là zk-SNARK thực tế và có thể sử dụng được đầu tiên. SNARK dựa trên Chương trình số học bậc hai (QAP). Kích thước bằng chứng ban đầu là 288 byte. Chuỗi công cụ của Pinocchio cung cấp trình biên dịch từ mã C đến các mạch số học và chuyển đổi thêm sang QAP. Giao thức yêu cầu người xác minh tạo các khóa dành riêng cho từng mạch. Nó sử dụng các cặp đường cong elip để kiểm tra phương trình. Việc tạo bằng chứng và cài đặt khóa là tuyến tính tiệm cận về kích thước tính toán và thời gian xác minh là tuyến tính theo kích thước của đầu vào và đầu ra chung.

Groth 16 (2016)

Groth^[16] giới thiệu một đối số kiến ​​thức mới với hiệu suất nâng cao ^[17] , được sử dụng để mô tả vấn đề của R1CS. Nó có kích thước bằng chứng tối thiểu (chỉ có ba phần tử nhóm) và xác minh nhanh chóng, bao gồm ba cặp đôi. Nó cũng bao gồm một bước tiền xử lý để có được chuỗi tham chiếu có cấu trúc. Nhược điểm chính của nó là yêu cầu các cài đặt tin cậy khác nhau cho từng chương trình mà chúng tôi muốn chứng nhận, điều này gây bất tiện. Groth16 được ZCash sử dụng.

Bulletproofs & IPA (2016)

Một điểm yếu của KZG PCS là nó yêu cầu thiết lập niềm tin. Bootle và cộng sự ^[18] đã giới thiệu một hệ thống lập luận không có kiến ​​thức hiệu quả, đáp ứng mối quan hệ sản phẩm bên trong của việc mở ra cam kết Pedersen. Đối số sản phẩm bên trong có bộ chứng minh tuyến tính, giao tiếp và tương tác logarit, nhưng có xác minh thời gian tuyến tính. Họ cũng đã phát triển một sơ đồ cam kết đa thức không yêu cầu thiết lập niềm tin. Kế hoạch cam kết đa thức (PCS) sử dụng những ý tưởng này đã được Halo 2 và Kimchi sử dụng.

Sonic, Marlin và Plonk (2019)

Sonic^[19], Plonk^[20] và Marlin ^[21] Giải quyết vấn đề chúng tôi gặp phải trong Groth16 là mọi chương trình đều cần cài đặt tin cậy bằng cách giới thiệu chuỗi tham chiếu có cấu trúc phổ quát và có thể cập nhật. Marlin cung cấp một hệ thống bằng chứng dựa trên R1CS (Hệ thống ràng buộc cấp 1), là cốt lõi của Aleo.

Plonk^[22] đã giới thiệu một sơ đồ số học mới (sau này gọi là Plonkish) và việc sử dụng các kiểm tra sản phẩm lớn để kiểm tra các ràng buộc sao chép. Plonkish cũng cho phép giới thiệu các loại cửa chuyên dụng cho một số hoạt động nhất định, được gọi là cửa tùy chỉnh. Một số dự án có phiên bản tùy chỉnh của Plonk, bao gồm Aztec, ZK-Sync, Polygon ZKEVM, Mina's Kimchi, Plonky2, Halo 2 và Scroll, cùng nhiều dự án khác.

Tra cứu (2018/2020)

Gabizon và Williamson đã giới thiệu plookup^[23] vào năm 2020, sử dụng tính năng kiểm tra sản phẩm vĩ mô để chứng minh rằng có một giá trị trong trong một bảng các giá trị được tính toán trước. Mặc dù tham số tra cứu trước đây đã được đề xuất trong Arya^[24], nhưng cấu trúc này đòi hỏi phải xác định bội số tra cứu, điều này làm cho việc xây dựng kém hiệu quả hơn. Bài viết PlonkUp^[25] hướng dẫn cách đưa tham số plookup vào Plonk. Vấn đề với các tham số tra cứu này là chúng buộc người chứng minh phải trả tiền cho toàn bộ bảng, bất kể số lần tra cứu mà anh ta thực hiện. Điều này có nghĩa là chi phí của các bảng lớn là đáng kể và những nỗ lực đáng kể đã được thực hiện để giảm chi phí cho người chuẩn chỉ phải trả cho số lượng tra cứu mà anh ta sử dụng. Haböck đã giới thiệu LogUp^[26], sử dụng đạo hàm logarit để chuyển đổi các phép kiểm tổng thành thành tổng các nghịch đảo. LogUp rất quan trọng đối với hiệu suất trong Polygon ZKEVM^[27], nơi chúng yêu cầu chia toàn bộ bảng thành nhiều mô-đun STARK. Các mô-đun này phải được liên kết chính xác và việc tra cứu bảng chéo sẽ thực thi điều này. Giới thiệu LogUp-GKR^[28] để sử dụng giao thức GKR nhằm cải thiện hiệu suất của LogUp. Caulk^[29] là sơ đồ đầu tiên trong đó thời gian chuẩn là tuyến tính phụ với kích thước bảng, sử dụng thời gian tiền xử lý O(NlogN) và dung lượng lưu trữ O(N), trong đó N là kích thước bảng. Một số kế hoạch khác sau đó đã xuất hiện, chẳng hạn như Baloo^[30], flookup^[31], cq^[32] và caulk+^{[ 33} . Lasso^[34] đã đề xuất một số cải tiến để tránh làm hỏng một bảng nếu nó có cấu trúc nhất định. Hơn nữa, trình chứng minh của Lasso chỉ trả tiền cho các mục trong bảng được truy cập bằng các hoạt động tra cứu. Jolt^[35] sử dụng Lasso để chứng minh khả năng thực thi của máy ảo thông qua tra cứu.

Spartan (2019)

Spartan^[36] cung cấp IOP ("Bằng chứng Oracle tương tác.") cho các mạch được mô tả bằng R1CS, tận dụng nhiều Thuộc tính của đa thức trong các biến và giao thức sumcheck. Sử dụng sơ đồ cam kết đa thức phù hợp, nó mang lại SNARK minh bạch theo thời gian tuyến tính.

HyperPlonk (2022)

HyperPlonk^[37] Dựa trên ý tưởng của Plonk, sử dụng đa thức đa biến. Nó dựa vào giao thức sumcheck thay vì thương số để kiểm tra việc thực hiện các ràng buộc. Nó cũng hỗ trợ các ràng buộc bậc cao hơn mà không ảnh hưởng đến thời gian chạy của trình chứng minh. Vì nó dựa trên các đa thức nhiều biến nên không cần FFT và thời gian chạy của bộ chuẩn tỷ lệ tuyến tính với kích thước mạch. HyperPlonk giới thiệu IOP hoán vị mới cho các trường nhỏ hơn và giao thức mở hàng loạt dựa trên sumcheck, giúp giảm công việc của người chứng minh, kích thước bằng chứng và thời gian của người xác minh.

Các sơ đồ gấp (2008/2021)

Nova^[38] giới thiệu khái niệm về các sơ đồ gấp, đó là một cách để đạt được sự gia tăng Một phương pháp mới cho tính toán có thể kiểm chứng tăng dần (IVC). Khái niệm IVC có thể bắt nguồn từ Valiant^[39], người đã chỉ ra cách hợp nhất hai bằng chứng về độ dài k thành một bằng chứng duy nhất về độ dài k. Ý tưởng là chúng ta có thể chứng minh điều đó bằng cách chứng minh đệ quy rằng việc thực hiện từ bước i đến bước I +1 là đúng và xác minh bằng chứng cho thấy việc chuyển đổi từ bước i−1 sang bước i là đúng. Bất kỳ phép tính dài hạn nào. Nova xử lý tốt tính toán hợp nhất; sau đó nó được mở rộng để xử lý các loại mạch khác nhau, giới thiệu Supernova^[40]. Nova sử dụng phiên bản R1CS thoải mái và hoạt động trên các đường cong elip thân thiện. Việc triển khai IVC bằng cách sử dụng các vòng đường cong thân thiện (chẳng hạn như đường cong Pasta) cũng được sử dụng trong Pickles, khối xây dựng chính của Mina để triển khai các trạng thái ngắn gọn. Tuy nhiên, khái niệm gấp khác với xác minh SNARK đệ quy.

Ý tưởng về bộ tích lũy có mối liên hệ sâu sắc hơn với khái niệm bằng chứng lô. Halo^[41] đã giới thiệu khái niệm tích lũy như một giải pháp thay thế cho các kết hợp chứng minh đệ quy. Protostar^[42] cung cấp sơ đồ IVC không đồng nhất cho Plonk, hỗ trợ các cổng bậc cao và tra cứu vectơ.

Sử dụng hàm băm chống va chạm

Trong khi Pinocchio đang được phát triển, đã có một số ý tưởng tạo ra các sơ đồ mạch/số học có thể chứng minh tính đúng đắn của việc thực thi máy ảo. Mặc dù việc phát triển số học cho máy ảo có thể phức tạp hơn hoặc kém hiệu quả hơn so với việc viết các mạch chuyên dụng cho một số chương trình, nhưng nó có ưu điểm là bất kỳ chương trình phức tạp nào cũng có thể được chứng minh bằng cách chứng minh rằng chương trình đó thực thi chính xác trong máy ảo. Các ý tưởng trong TinyRAM sau đó đã được cải tiến thông qua thiết kế của Cairo vm và các máy ảo tiếp theo như zk-evms hoặc zkvms cho mục đích chung. Việc sử dụng các hàm băm chống va chạm sẽ loại bỏ nhu cầu về các cài đặt đáng tin cậy hoặc các thao tác trên đường cong elip, nhưng phải trả giá bằng việc chứng minh lâu hơn.

TinyRAM (2013)

Trong SNARK cho C^[43], họ đã phát triển SNARK dựa trên PCP để chứng minh rằng các chương trình C được thực thi chính xác các thuộc tính, chương trình được biên dịch thành TinyRAM, một máy tính có tập lệnh rút gọn.

Lưu ý: PCP,  Bằng chứng có thể kiểm tra được bằng xác suất Bằng chứng có thể kiểm tra được bằng xác suất. Người xác minh chỉ cần đọc một phần nhỏ được chọn ngẫu nhiên của bằng chứng để kiểm tra bằng chứng với độ tin cậy cao. Hiệu quả. Không giống như các hệ thống chứng minh truyền thống nơi người xác minh cần kiểm tra toàn bộ bằng chứng, PCP chỉ yêu cầu tính ngẫu nhiên hạn chế để đạt được xác minh hiệu quả.

Máy tính sử dụng kiến ​​trúc Harvard với bộ nhớ truy cập ngẫu nhiên có thể định địa chỉ theo cấp độ byte. Tận dụng tính chất không xác định, kích thước của mạch tỷ lệ gần như tuyến tính với kích thước tính toán, cho phép xử lý hiệu quả mọi vòng lặp, luồng điều khiển và truy cập bộ nhớ liên quan đến dữ liệu.

STARKs (2018)

STARKs^[44] được đề xuất vào năm 2018 bởi Ben Sasson và cộng sự. Chúng đạt được kích thước bằng chứng 0(log^2 n), có trình kiểm chứng và trình xác minh nhanh, không yêu cầu thiết lập đáng tin cậy và được suy đoán là bảo mật sau lượng tử. Chúng lần đầu tiên được sử dụng bởi Starkware/Starknet, với Cairo vm. Những phần giới thiệu chính của nó bao gồm Biểu diễn trung gian đại số (AIR) và giao thức FRI ^[45] (Bằng chứng tiệm cận tương tác nhanh của Reed-Solomon Oracle). Nó cũng được sử dụng bởi các dự án khác (Polygon Miden, Risc0, Winterfell, Neptune) hoặc đã thấy sự điều chỉnh của một số thành phần (ZK-Sync's Boojum, Plonky2, Starky).

Ligero (2017)

Ligero^[46] đề xuất một hệ thống chứng minh đạt được kích thước chứng minh là O(√n), trong đó n là Kích thước của mạch điện. Nó sắp xếp các hệ số đa thức thành dạng ma trận và sử dụng mã tuyến tính. Brakedown^[47] được xây dựng trên Ligero và giới thiệu khái niệm về sơ đồ cam kết đa thức độc lập với miền.

Một số phát triển mới

Việc sử dụng các hệ thống chứng minh khác nhau trong sản xuất thể hiện ưu điểm của từng phương pháp và dẫn đến những phát triển mới. Ví dụ, số học plonkish cung cấp một cách dễ dàng để bao gồm các cổng tùy chỉnh và đối số tra cứu; FRI đã thể hiện hiệu suất tuyệt vời dưới dạng PCS, dẫn đến Plonky. Tương tự như vậy, việc sử dụng tính năng kiểm tra sản phẩm macro trong AIR (đưa AIR ngẫu nhiên được xử lý trước) sẽ cải thiện hiệu suất của nó và đơn giản hóa các tham số truy cập bộ nhớ. Những lời hứa dựa trên hàm băm trở nên phổ biến do tốc độ phần cứng của chúng hoặc sự ra đời của các hàm băm mới phù hợp với SNARK.

Các sơ đồ cam kết đa thức mới (2023)

Với sự xuất hiện của SNARK hiệu quả dựa trên đa thức nhiều biến, chẳng hạn như Spartan hoặc HyperPlonk, người ta quan tâm đến các sơ đồ cam kết mới phù hợp với các đa thức đó được tạo ra sự quan tâm lớn hơn. Binius^[48], Zeromorph^[49] và Basefold^[50] đều đề xuất các dạng cam kết mới đối với đa thức đa tuyến tính. Binius có lợi thế là không cần tốn chi phí trong việc biểu diễn các loại dữ liệu (trong khi nhiều hệ thống chứng minh sử dụng ít nhất các phần tử trường 32 bit để biểu diễn các bit riêng lẻ) và có thể hoạt động trên miền nhị phân. Sơ đồ cam kết này sử dụng phương pháp hãm lại, được thiết kế để không phụ thuộc vào miền. Basefold khái quát hóa FRI thành các mã khác ngoài Reed-Solomon, tạo ra một PCS độc lập với miền.

Lưu ý Độc lập với miền: Trong sơ đồ cam kết đa thức độc lập với miền, quy trình cam kết không phụ thuộc vào bất kỳ thuộc tính cụ thể nào của miền. Điều này có nghĩa là các cam kết có thể được thực hiện đối với các đa thức của bất kỳ cấu trúc đại số nào, chẳng hạn như trường hữu hạn, đường cong elip hoặc thậm chí là vành số nguyên.

Hệ thống ràng buộc có thể tùy chỉnh (2023)

CCS^[51] Tổng quát hóa R1CS trong khi thu thập R1CS, Plonkish và AIR Arithmetic mà không cần thêm chi phí. Việc sử dụng CCS kết hợp với Spartan IOP sẽ tạo ra SuperSpartan, hỗ trợ các ràng buộc nhiều chiều mà người chứng minh không cần phải chịu chi phí mật mã sẽ tăng theo quy mô khi chỉ số ràng buộc tăng lên. Đặc biệt, SuperSpartan cung cấp SNARK chứng minh thời gian tuyến tính cho AIR.

Kết luận

Bài viết này mô tả sự tiến bộ của SNARK kể từ giữa những năm 1980. Những tiến bộ trong khoa học máy tính, toán học và phần cứng cũng như sự ra đời của blockchain đã dẫn đến sự xuất hiện của SNARK mới và hiệu quả hơn, mở ra cánh cửa cho nhiều ứng dụng có thể thay đổi xã hội của chúng ta. Các nhà nghiên cứu và kỹ sư đã đề xuất cải tiến và điều chỉnh SNARK dựa trên nhu cầu của họ, tập trung vào kích thước bằng chứng, mức sử dụng bộ nhớ, cài đặt độ trong suốt, bảo mật sau lượng tử, thời gian chứng minh và thời gian xác minh. Mặc dù ban đầu có hai dòng chính (SNARK và STARK), ranh giới giữa hai dòng này đã bắt đầu biến mất trong nỗ lực kết hợp các ưu điểm của các hệ thống chứng minh khác nhau. Ví dụ: kết hợp các sơ đồ số học khác nhau với các sơ đồ cam kết đa thức mới. Chúng ta có thể kỳ vọng rằng các hệ thống thử nghiệm mới sẽ tiếp tục xuất hiện và hiệu suất sẽ được cải thiện, đồng thời sẽ khó theo kịp những phát triển này đối với một số hệ thống vốn sẽ mất một thời gian để thích ứng, trừ khi chúng ta có thể dễ dàng sử dụng các công cụ mà không cần thay đổi. .

Tài liệu tham khảo

[1]Liên kết: https://blog.lambdaclass.com/our-highly-subjective-view-on-the-history-of-zero-know-proofs/< /span>

[2] Kế hoạch dịch liên kết: https://github.com / lbc-team/Pioneer

[3]Nhóm dịch: https: / /learnblockchain.cn/people/412

[4]Chú gấu nhỏ:  ; https://learnblockchain.cn/people/15

[5]learnblockchain . cn/article…: https://learnblockchain.cn/article/7422

[6]Bài viết: https://blog.lambdaclass.com/transforming-the-future-with-zero-know-proofs-full-homomorphic-encryption-and-new-distributed-systems-algorithms/ < /span>

[7] Vụ nổ kỷ Cambri đã được chứng minh bằng mật mã: https:/ /medium.com /starkware/cambrian-explosion-of-cryptographic-proofs-5740a41cdbd2?ref=blog.lambdaclass.com

[8]Video sau: https://www.youtube.com/watch?v=uchjTIlPzFo&ref=blog.lambdaclass.com

< p style= "text-align: left;">[9]giao thức sumcheck: https://blog.lambdaclass.com/have-you-checked-your -sums/

[10]Lund, Fortnow, Karloff và Nisan:  ;https: //dl.acm.org/doi/pdf/10.1145/146585.146605?ref=blog.lambdaclass.com

[11]Giao thức GKR: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/2008-DelegatingComputation.pdf? ref=blog .lambdaclass.com

[12]Kate, Zaverucha và Goldberg :  https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf?ref=blog.lambdaclass.com

[13]EIP-4844: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md?ref=blog .lambdaclass. com

[14]Cầu Mina-Ethereum: https: //blog .lambdaclass.com/mina-to-ethereum-bridge/

[15] Pinocchio: https://eprint.iacr.org/2013/279?ref=blog.lambdaclass.com

< span style= "cỡ chữ: 14px;">[16]Groth: https://eprint.iacr.org/2016/260.pdf?ref=blog.lambdaclass.com

[17] Đối số kiến ​​thức mới với hiệu suất nâng cao: https://blog.lambdaclass.com/groth16 /

[18]Bootle et al.: https://eprint.iacr.org /2016/263?ref=blog.lambdaclass.com

[ 19]Sonic : https://eprint.iacr.org/2019/099?ref=blog.lambdaclass.com

[20]Plonk: https://eprint.iacr.org/2019/953?ref=blog.lambdaclass.com

[21]Marlin: https://eprint.iacr.org/2019/1047?ref=blog.lambdaclass.com

[22]Plonk: https://blog.lambdaclass.com/all -you-wanted-to-know-about-plonk/

[23] plookup: https://eprint.iacr.org/2020/315?ref=blog.lambdaclass.com

< span style= "cỡ chữ: 14px;">[24]Arya: https://eprint.iacr.org/2018/380?ref=blog.lambdaclass.com

[25]PlonkUp: https://eprint.iacr.org/2022/086?ref=blog.lambdaclass .com< /span>

[26]LogUp: https://eprint.iacr .org/ 2022/1530?ref=blog.lambdaclass.com

[27 ]Đa giác ZKEVM : https://toposware.medium.com/beyond-limits-pushing-the-boundaries-of-zk-evm-9dd0c5ec9fca?ref=blog.lambdaclass.com

< p style= "text-align: left;">[28]LogUp-GKR: https://eprint.iacr.org/2023/1284?ref= blog.lambdaclass .com

[29]Caulk: https:// eprint.iacr .org/2022/621?ref=blog.lambdaclass.com

[30 ]Baloo: https://eprint.iacr.org/2022/1565?ref=blog.lambdaclass.com

[31]flookup: https://eprint.iacr.org/2022/1447?ref=blog.lambdaclass.com

< p style= "text-align: left;">[32]cq: https://eprint.iacr.org/2022/1763?ref=blog. lambdaclass.com

[33]caulk+: https://eprint.iacr.org /2022/957?ref=blog.lambdaclass.com

[ 34]Lasso : https://eprint.iacr.org/2023/1216?ref=blog.lambdaclass.com

[35]Jolt: https://eprint.iacr.org/2023/1217?ref=blog.lambdaclass.com

[36]Spartan: https://eprint.iacr.org/2019/550?ref=blog.lambdaclass.com

[37]HyperPlonk: https://eprint.iacr.org/2022 /1355.pdf?ref=blog.lambdaclass.com

[ 38]Nova : https://eprint.iacr.org/2021/370?ref=blog.lambdaclass.com

[39]Valiant: https://https//iacr.org/archive/tcc2008/49480001/49480001.pdf?ref=blog.lambdaclass.com

[40]Siêu tân tinh: https://eprint.iacr.org/2022/1758 ?ref= blog.lambdaclass.com

[41]Halo: https :// eprint.iacr.org/2019/1021.pdf?ref=blog.lambdaclass.com

[42]Protostar: https://eprint.iacr.org/2023/620?ref=blog.lambdaclass.com

[43]SNARK dành cho C: https://eprint.iacr.org/2013/507?ref=blog.lambdaclass.com< /p>

[44]STARKs: https://eprint.iacr.org/2018 /046? ref=blog.lambdaclass.com

[45]Giao thức FRI:  https ://blog.lambdaclass.com/how-to-code-fri-from-scratch/

[46]Ligero: https://eprint.iacr.org/2022/1608?ref=blog.lambdaclass.com

[47]Brakedown: https://eprint.iacr.org/2021/1043?ref=blog.lambdaclass.com< /p>

[48]Binius: https://blog.lambdaclass.com/snarks -on- nhị phân-fields-binius/

[49]Zeromorph:  https:/ /eprint.iacr.org/2023/917?ref=blog.lambdaclass.com

[50]Basefold: https://blog.lambdaclass.com/how-does-basefold-polynomial-commitment-scheme-generalize-fri/

[51]CCS: https://eprint.iacr.org/2023/552?ref=blog.lambdaclass.com

[52]DeCert.me: https://decert.me /