Solana Builders: ZK Compression

Đặc tính

Trước khi đánh giá trong bối cảnh ZK-Compression, hãy liệt kê một số đặc tính của Solana mà chúng ta quan tâm:

1. Khả năng kết hợp nguyên tử đồng bộ
2. Tính đồng thời
3. Tính an toàn
4. Tính hoạt động
5. Khả năng chống kiểm duyệt

Các giả định tin cậy ban đầu

Chúng ta sẽ dùng thuật ngữ "không cần tin cậy" cho các giả định bảo mật của một nút đầy đủ. Định nghĩa này là mốc cơ sở. Bất kỳ điều gì mà một nút đầy đủ không thể tự thực hiện đều liên quan đến các giả định tin cậy bổ sung.

Một số kiến thức nền tảng

Tôi sẽ cố gắng trình bày ngắn gọn những kiến thức nền tảng cần thiết về Solana để hiểu ZK-Compression qua các gạch đầu dòng. 

• Trạng thái Solana được lưu trữ trên ổ đĩa của các nút đầy đủ trong “AccountsDB”
• Đơn vị lưu trữ được gọi là "tài khoản"
• Tài khoản có địa chỉ (mỗi địa chỉ 32 byte)
• Lượng dữ liệu mà một tài khoản có thể lưu trữ thay đổi từ 0 đến tối đa 10 MB
• Lưu trữ 10 MB trên Solana tốn khoảng 70 SOL, do người tạo tài khoản chi trả. Chi phí này gắn với dung lượng lưu trữ chứ không phải số lượng tài khoản — có thể là 1 tài khoản 10 MB hoặc 1.000 tài khoản 10 KB.
• Kích thước hiện tại của tất cả tài khoản trên Solana là 76 GB (đã nén)
• Mọi giao dịch Solana đều phải chỉ định tất cả tài khoản mà giao dịch đọc và ghi
• Giao dịch Solana hiện bị giới hạn ở 1.232 byte (đã có đề xuất tăng giới hạn này)
• Mỗi giao dịch Solana cần chỉ định một số nội dung
  • Chữ ký (mỗi chữ ký 64 byte)
  • Tài khoản (mỗi tài khoản 32 byte)
  • Dữ liệu chỉ thị (độ dài tùy ý)
  • Blockhash gần đây (32 byte)
  • Địa chỉ chương trình (mỗi địa chỉ 32 byte) (CPI: lệnh gọi liên chương trình)
• Giao dịch Solana chứa một “blockhash gần đây” dài 32 byte, phải được đưa vào trong vòng 150 khối gần nhất ) nếu không sẽ bị coi là không hợp lệ và cần được ký rồi gửi lại

Vòng đời của một giao dịch thông thường

Khi một giao dịch thông thường được thực thi, vòng đời diễn ra như sau:

1. Trước tiên, giao dịch được kiểm tra tuổi (chỉ các giao dịch gần đây mới hợp lệ), loại bỏ trùng lặp, xác minh cấu trúc, tính phí (gas) và kiểm tra chữ ký
2. Bytecode của chương trình được tải dựa trên địa chỉ chương trình và Solana Virtual Machine (SVM) được khởi tạo
3. Tất cả tài khoản được giao dịch tham chiếu đều được kiểm tra, tải từ bộ nhớ lưu trữ vào bộ nhớ và chuyển cho SVM
4. Bytecode của chương trình được thực thi
5. Mọi tài khoản đã sửa đổi được đồng bộ trở lại bộ nhớ lưu trữ ở trạng thái mới

Các động lực chính của ZK-Compression là:

• Trạng thái on-chain rất tốn kém. Ví dụ, một nghìn tài khoản tốn 70 SOL, vì vậy các sản phẩm như Drip Haus nhanh chóng trở nên đắt đỏ
• Ngay cả khi trạng thái chưa được Merkle hóa hoàn toàn, việc phải lưu nhiều tài khoản hơn trên ổ đĩa đồng nghĩa với snapshot lớn hơn, chỉ mục lớn hơn, v.v.
• Không phải tài khoản nào cũng được truy cập thường xuyên, vì vậy việc liên tục phát sinh chi phí tài nguyên là không cần thiết

Vậy cách đơn giản nhất để đạt được khả năng nén là gì?

Thay vì lưu trữ tài khoản trên ổ đĩa và đọc khi cần (bước 3 trong vòng đời thực thi giao dịch), giao dịch có thể chuyển dữ liệu tài khoản như một phần của payload, qua đó tiết kiệm chi phí liên quan đến việc lưu trữ on-chain. Nhưng điều này lại tạo ra một vấn đề mới — làm thế nào để thực thi quy tắc rằng người dùng không được khai báo sai về trạng thái?

Ví dụ, giả sử giá trị off-chain của một tài khoản lưu trữ số dư token là 1200 và trường chủ sở hữu của tài khoản đó là “BYixJwV32DjeuyRww72PwZMyKcaedN533GBrv7CDh4n9”.

Nếu bạn gửi một giao dịch với dữ liệu đó lên chuỗi, làm sao chuỗi biết được rằng bạn không khai báo sai số lượng token mà địa chỉ “BYixJwV32DjeuyRww72PwZMyKcaedN533GBrv7CDh4n9” sở hữu?

Xét cho cùng, nút đầy đủ xử lý giao dịch không có quyền truy cập vào dữ liệu off-chain — nút này trông đợi bạn cung cấp dữ liệu cùng với giao dịch.

Bạn có thể dùng bằng chứng Merkle cho việc này. Không đi sâu vào chi tiết về bằng chứng Merkle, có thể hiểu đây là một cách "cam kết" với một số dữ liệu theo cách có thể xác minh, đồng thời chỉ chiếm ít dung lượng lưu trữ on-chain. Tất cả nút đầy đủ được đồng bộ với chuỗi đều lưu "cam kết" nhỏ đó. Khi ai đó cung cấp dữ liệu trong một giao dịch, họ cũng có thể cung cấp một "bằng chứng" trong cùng giao dịch để xác minh dựa trên cam kết. Bằng chứng này được bảo mật bằng mật mã học.

Cách này có vấn đề gì không?

Vấn đề là bằng chứng Merkle có thể rất lớn. Nếu một cây chứa 100.000 tài khoản, kích thước bằng chứng cho một trong các tài khoản này là 17 * 32 = 544 byte. Nếu muốn cung cấp bằng chứng cho nhiều tài khoản, trong trường hợp xấu nhất, kích thước sẽ nhân lên theo số bằng chứng. Vì vậy, trong trường hợp xấu nhất, mười tài khoản sẽ cần 10 * 544 = 5.440 byte. Vấn đề không gian này đặc thù với Solana vì giao dịch Solana hiện bị giới hạn ở 1.232 byte, trong khi các chuỗi khác thường ít hạn chế hơn. Hãy xem phần trên, nơi chúng tôi liệt kê kích thước của từng thành phần — chương trình, chữ ký, blockhash gần đây, v.v. Vì vậy, ngay cả trong trường hợp tốt nhất, bạn cũng sử dụng một nửa kích thước giao dịch chỉ cho bằng chứng Merkle. 

Từ đây nảy sinh một số câu hỏi.

Nếu kích thước giao dịch là 1.232 byte, làm thế nào bạn gửi toàn bộ dữ liệu như một phần của giao dịch?

Đây là một câu hỏi rất hay. ZK Compression hữu ích cho một số lượng tài khoản rất lớn nếu mỗi tài khoản chỉ chứa lượng dữ liệu nhỏ. Số dư token (8 byte cho mỗi token), lượng nhỏ siêu dữ liệu cho NFT, v.v. — 100 byte dữ liệu có thể dễ dàng nằm trong một giao dịch. 1.000 byte thì khó vì giao dịch còn chứa những dữ liệu khác. Nếu tài khoản cần lưu trữ lượng dữ liệu lớn hơn, phương pháp này (và ZK Compression) sẽ không hoạt động.

Có một điểm cần lưu ý trong nhận định này: cùng một logic được dùng trong ZK Compression có thể được áp dụng cho các phần của trạng thái tài khoản. Điều này có nghĩa là dù không thể đưa toàn bộ dữ liệu của một tài khoản vào payload của một giao dịch duy nhất, vẫn có những cách xử lý — cụ thể là cam kết và cung cấp bằng chứng cho một phần dữ liệu.

Bằng chứng Merkle có phải là cách duy nhất để làm việc này không?

Không. Bằng chứng Merkle chỉ là một loại cam kết vector. Nó có kích thước cam kết là 32 byte và kích thước bằng chứng là Log2(N) * 32 byte, trong đó N là kích thước của vector mà bạn cam kết. Đó là lý do chúng ta có con số 17, vì Log2(100000) là 17. Tuy nhiên, cũng có những loại cam kết với kích thước bằng chứng cố định (KZG, Pedersen); trên thực tế, ZK-Compression sử dụng một phương pháp như vậy! 

Bạn nói dữ liệu tài khoản thường được lưu trữ trên một nút đầy đủ như một phần của trạng thái phải được cung cấp cùng giao dịch. Dữ liệu đó được lưu ở đâu?

Một câu hỏi rất hay, đồng thời ảnh hưởng đến các giả định tin cậy và đặc tính của hệ thống. Câu trả lời là — ở bất kỳ đâu! Các máy chủ RPC chuyên dụng có thể lưu dữ liệu này; dữ liệu có thể nằm trong Filecoin hoặc IPFS, thậm chí người dùng có thể lưu trên máy của riêng mình. Điều quan trọng là miễn mọi phần tử của vector được lưu ở đâu đó, các bằng chứng có thể được tính toán tức thời. Chúng ta sẽ xem xét những tác động từ nơi lưu trữ dữ liệu này trong phần đặc tính. 

Các chuỗi khác có thể làm điều này không?

ZK-Compression đặc biệt yêu cầu chi phí xác minh zk-SNARK phải thấp. Vì vậy, giải pháp này hoạt động hiệu quả trên Solana do chi phí tính toán thấp hơn chi phí lưu trữ. Khái niệm tổng quát về việc sử dụng cam kết vector và bằng chứng cho dữ liệu được cung cấp trong từng giao dịch có thể áp dụng trên các chuỗi khác, nhưng chi phí tính toán cao khiến sự đánh đổi này kém nổi bật hơn so với trên Solana. Trên thực tế, chi phí gas xác minh liên tục so với một lần SSTORE lại đắt hơn trên các chuỗi dựa trên EVM.

ZK Compression là gì?

• Nếu chưa biết ZK Compression là gì, phần này sẽ giải thích
• Nếu mới chỉ hiểu mơ hồ, tôi vẫn khuyên bạn đọc phần này vì có một số quan niệm sai lầm phổ biến
• Nếu biết chính xác nó là gì, tôi mong bạn vẫn đọc để có thể sửa cho tôi nếu có điểm nào đó sai :) 

Nếu đã hiểu phần trên, bạn đã hiểu 90% về ZK Compression. Vấn đề chính là kích thước bằng chứng Merkle, vì vậy ZK Compression về cơ bản chỉ là sử dụng một cơ chế để chứng minh một phép tính.

Nếu chưa biết ZK là gì thì cũng không quá quan trọng. Bạn chỉ cần biết rằng đây là một cách chứng minh mình đã thực hiện một phép tính "chính xác". Một ví dụ đơn giản là bạn muốn chứng minh mình nhân hai số để được số thứ ba, tức là 4*3 = 12

“Cách ZK” để chứng minh điều này là sử dụng hàm sau:

f(x,y) = x*y

Nếu tạo một mạch cho đoạn mã trên, bên chứng minh sẽ tạo ra bằng chứng rằng phép tính là chính xác. Bản thân mạch chính là cam kết, vì vậy mọi người đều biết "phép tính" mà bạn đang chạy là gì. Nhưng điều tuyệt vời là họ không cần biết các đầu vào. Sau khi chạy f(3,4), hàm trả về 12 và "bằng chứng". Giờ đây, bất kỳ ai cũng có thể lấy 12, "bằng chứng," và xác minh rằng bạn đã nhân HAI số NÀO ĐÓ để được 12. Họ không biết bạn đã dùng 4,3, 6,2, hay thậm chí 12,1. Việc bạn ẩn các số đó mà người khác vẫn có thể xác minh chính là nguồn gốc của phần “zero knowledge”.

Tại sao tôi lại giải thích điều này?

Khái niệm tổng quát này có sức mạnh đáng kinh ngạc trong việc chứng minh rằng bạn đã thực hiện một phép tính nhất định và thu được một kết quả nhất định. Khi có kết quả và bằng chứng, người khác có thể xác minh bạn đã thực hiện đúng hay chưa mà không cần thực sự chạy phép tính. Điều này đúng với BẤT KỲ phép tính tùy ý nào. Tôi chỉ nhân hai số, nhưng bạn thậm chí có thể dùng nó để nói: "Tôi đã xác minh mười chữ ký này và tất cả đều hợp lệ". Đây là lợi ích thứ hai và là một trong những lý do lớn nhất khiến bằng chứng zero-knowledge được sử dụng ngay cả khi bạn không cần “ẩn” điều gì. Bởi vì bạn đang biến một bài toán cần chạy 1.000 bước tính toán (hoặc thậm chí một triệu bước) thành bài toán chỉ cần xác minh một bằng chứng để biết phép tính đã được thực hiện chính xác. Điểm cần lưu ý là việc tạo bằng chứng cần một khoảng thời gian.

ZK Compression sử dụng cùng công nghệ để chạy logic xác minh tư cách thành viên của cây Merkle. Vì vậy, nó có một mạch có thể nhận dữ liệu tài khoản và một bằng chứng (128 byte), rồi xác minh rằng dữ liệu thực sự là một phần của "cam kết" trên chuỗi. (Bằng chứng thực tế là 256 byte, nhưng một điểm thuận tiện của đường cong elliptic và các điểm là nếu biết đường cong, bạn chỉ cần một điểm để tìm ra điểm thứ hai).

Mục đích chính của việc này là giảm kích thước bằng chứng xuống mức cố định 128 byte, nhờ đó vẫn còn nhiều không gian (xét tương đối) cho dữ liệu của các tài khoản nhỏ. Trong khi bằng chứng Merkle thông thường có kích thước Log2(N), ZK Compression luôn có kích thước cố định, nên bạn có thể có một số lượng tài khoản rất lớn dưới một cam kết duy nhất. (Để tham khảo, bằng chứng Merkle cho 100.000 tài khoản sẽ vào khoảng 550 byte, tức một nửa payload giao dịch) 

Bằng chứng này có thể được tạo off-chain, nhưng phải được xác minh on-chain vì chương trình cần biết rằng bạn đã cung cấp đúng dữ liệu cho một tài khoản trước khi cho phép tiếp tục thực thi. Do đó, phải có cơ chế cơ bản để xác minh bằng chứng ZK. Hệ thống chứng minh cụ thể mà ZK-Compression sử dụng được gọi là Groth16 và hệ thống này dựa vào syscall alt_bn128, hiện đang bị giới hạn bởi cờ tính năng trên mainnet và đang được thử nghiệm.

Điểm thú vị là cơ chế ZK-Compression sử dụng có thể xác minh các phép tính tùy ý (không chỉ là "lá này có thuộc cây có gốc này không?").

Một lợi ích chính của ZK Compression là nó cung cấp toàn bộ hạ tầng cần thiết để nhà phát triển hoàn toàn không phải xử lý phần "ZK”. Từ góc nhìn của nhà phát triển, họ coi nó như bất kỳ tài khoản nào khác với các trường tương tự, v.v., nên bên trong chương trình, nó có thể được xử lý như một tài khoản thông thường. Việc trừu tượng hóa phần lớn "phép màu ZK" để nhà phát triển không phải tự xử lý mang lại giá trị rõ ràng.

ZK Rollup

Không đi quá sâu vào chi tiết, ZK rollup chủ yếu sử dụng các khái niệm tương tự ZK-Compression. Điểm giống nhau chính là toàn bộ trạng thái rollup được biểu diễn dưới dạng một gốc duy nhất trên lớp cơ sở (Ethereum), đây là lý do xuất hiện một số tuyên bố rằng ZK-Compression là một rollup. Tuy nhiên, có những khác biệt quan trọng.

Hãy xem xét 100 giao dịch rollup.

Toàn bộ ZK rollup được coi là một mạch (giống chương trình nhân mà chúng ta đã dùng làm ví dụ). Cả 100 giao dịch đều được xác minh (chữ ký, logic hợp đồng, kiểm tra trùng lặp, v.v.) và một bằng chứng duy nhất được tạo cho

"Sau khi áp dụng 100 giao dịch, gốc trạng thái thay đổi từ A thành B". Sau khi bằng chứng được xác minh, hợp đồng thông minh cập nhật gốc trạng thái từ A thành B.

Tuy nhiên, trong ZK-Compression, mỗi giao dịch trong số 100 giao dịch chứa một bằng chứng chỉ đơn giản cho biết dữ liệu tài khoản là chính xác, còn các chuyển đổi trạng thái (do giao dịch tạo ra) thực sự được thực thi on-chain như một phần của chính SVM. Sau khi bằng chứng được xác thực, tài khoản được xử lý như một tài khoản thông thường. Điều này rất quan trọng đối với đặc tính khả năng kết hợp mà chúng ta sẽ thảo luận tiếp theo.

Xem xét lại các đặc tính

Giờ chúng ta đến với phần thú vị. ZK-Compression giữ lại những đặc tính nào của Solana

Khả năng kết hợp nguyên tử đồng bộ

Nếu tôi có một giao dịch tham chiếu đến 2 tài khoản được nén bằng ZK và 10 tài khoản "thông thường", khả năng kết hợp vẫn không bị phá vỡ. Một chỉ thị tham chiếu đến tài khoản được nén bằng ZK có thể gọi một chỉ thị/chương trình khác tham chiếu đến tài khoản "thông thường" không nén. Đặc tính này được giữ nguyên hoàn toàn ngay cả khi hai tài khoản được nén dưới các cây khác nhau. Nếu một chỉ thị thất bại, toàn bộ giao dịch sẽ được hoàn tác (nguyên tử), và các thay đổi từ một chỉ thị được gọi ở dòng 1 sẽ hiển thị với dòng 2 (đồng bộ).

Điều này không đúng với rollup vì các ZK rollup không thể gọi lẫn nhau theo cách đồng bộ hay nguyên tử (trừ khi chúng sử dụng khóa toàn cục và cho phép hoàn tác giữa các rollup)

Tính song song

Tính năng này có một số tác động đến tính song song và từng trường hợp đều đáng được xem xét:

Ghi vào nhiều tài khoản nén dưới cùng một cây

Mỗi cây tự hỗ trợ tính đồng thời. Điều này có nghĩa là nếu người dùng đang đọc/ghi từ hai tài khoản nén dưới cùng một gốc trạng thái, các thao tác có thể thực thi đồng thời và gốc trạng thái có thể được cập nhật đồng thời. Logic ở đây giống với logic Solana sử dụng để cập nhật cây Merkle đồng thời trong cNFTs

Ghi vào cùng một tài khoản nén

Mỗi tài khoản nén không hỗ trợ tính đồng thời. Nếu hai người dùng cố ghi vào cùng một tài khoản nén, một trong hai giao dịch sẽ thất bại bất kể thứ tự. Trong quá trình thực thi thông thường, dữ liệu ghi vào tài khoản từ chỉ thị trước sẽ khả dụng cho chỉ thị tiếp theo. Nhưng với tài khoản được nén bằng ZK, bằng chứng về dữ liệu tài khoản sẽ không hợp lệ vì đó là bằng chứng của trạng thái trước đó

Một điểm khác cần lưu ý là mức sử dụng đơn vị tính toán (CU) lớn của quá trình nén làm giảm mức đồng thời tối đa trên mỗi cây, vì mỗi tài khoản chỉ có thể sử dụng tối đa 12 triệu đơn vị tính toán trên mỗi khối theo giới hạn CU của tài khoản.

Các giả định tin cậy

Mặc dù bất kỳ ai cũng có thể lưu trữ toàn bộ dữ liệu thô cần thiết để tạo bằng chứng và gửi giao dịch, đây vẫn là một giả định tin cậy bổ sung ảnh hưởng đến tính hoạt động của trạng thái được nén. Nếu vì lý do nào đó dữ liệu bị "mất" hoặc có sự chậm trễ, bạn sẽ không thể gửi giao dịch trừ khi tự lưu trữ dữ liệu. May mắn thay, đây là bài toán f+1 chứ không phải bài toán 3f+1 vốn yêu cầu khả năng chịu lỗi Byzantine. Bài toán f+1 chỉ cần một nút trung thực cung cấp dữ liệu. Vì các bằng chứng có khả năng "tự xác minh", không có vấn đề về "tính an toàn". Vấn đề chủ yếu nằm ở "tính hoạt động" và nguy cơ kiểm duyệt.

Cả rollup thông thường và ZK-Compression đều yêu cầu cung cấp bằng chứng hợp lệ. Tuy nhiên, trong khi rollup mã hóa toàn bộ hàm chuyển đổi trạng thái bên trong bằng chứng hợp lệ, ZK-Compression chỉ mã hóa câu hỏi "Dữ liệu tài khoản có chính xác không?". Vì vậy, các giả định tin cậy ở đây hơi khác nhau. Trong trường hợp nén, các giả định tin cậy chủ yếu liên quan đến việc truy cập trạng thái (trong khi chuyển đổi trạng thái được thực hiện đầy đủ). Trong trường hợp rollup, các giả định tin cậy áp dụng cho toàn bộ hàm chuyển đổi trạng thái (từ góc nhìn của lớp cơ sở). Các giả định bảo mật liên quan đến số bit hoặc độ khó/không khả thi của bài toán nền tảng là như nhau (Giả định Diffie-Hellman song tuyến), nhưng điều khác biệt là *bạn đang dựa vào* mô hình bảo mật đó cho việc gì — truy cập trạng thái hay thực thi. Tôi chỉ đề cập điều này vì cần biết các giả định tin cậy bổ sung được thêm vào ở đâu và không được thêm vào ở đâu.

Hiện tại, chương trình xác minh các tài khoản được nén bằng ZK có thể nâng cấp, nhưng trong tương lai có thể chuyển thành bất biến hoặc bị đóng băng vì chương trình chỉ thực hiện một thao tác rất cụ thể (mở bằng chứng Merkle), vốn không thực sự cần nâng cấp liên tục.

Ngoài ra, nén trạng thái cũng có thể được thực hiện theo hai cách khác.

1. Một đề xuất tăng kích thước giao dịch (kênh proj-3x-tx trong Discord của Solana) đang được phát triển. Khi đi vào hoạt động, bạn có thể sử dụng bằng chứng Merkle thông thường nếu kích thước cho phép
2. Khi syscall alt_bn128 đi vào hoạt động, syscall này cũng có thể được dùng cho cam kết vector thông thường với kích thước bằng chứng cố định (KZG hoạt động với mọi đường cong thân thiện với phép ghép cặp, bao gồm alt_bn128). Cách này không yêu cầu mạch ZK-prover

Chúng ta gọi nó là gì?

Đáng tiếc là các thuật ngữ như rollup, L2 và Validium đã được sử dụng quá tùy tiện, đến mức một số rollup thậm chí không thực sự là rollup. Chúng không kế thừa tính hoạt động, tính an toàn hay khả năng chống kiểm duyệt của lớp cơ sở. Mặc dù Helius bị cáo buộc sử dụng một "thuật ngữ tiếp thị", chính những người đó cũng sử dụng từ "rollup" rất tùy tiện để chỉ các dự án mà họ đã đầu tư vì cùng một lý do — tiếp thị. Trên thực tế, những dự án không phải rollup được gắn các giai đoạn khác nhau chỉ để chúng có thể tiếp tục tự gọi mình là rollup.

Không phải ai cũng như vậy — một số người đã cực kỳ thẳng thắn trong việc sử dụng thuật ngữ chính xác và dành nhiều tháng công sức để tranh luận với những người dùng thuật ngữ thiếu chính xác nhằm đánh lừa người dùng (xin ghi nhận Toghrul, người luôn kêu gọi *tất cả mọi người* sử dụng thuật ngữ chính xác).

Vì nó có một số đặc tính và giả định tin cậy khác với rollup, việc gọi nó là rollup có thể khiến người dùng nhầm lẫn. Gọi nó là Validium cũng quá rộng vì cách gọi đó bỏ qua thực tế rằng khả năng kết hợp nguyên tử đồng bộ hay tính song song không bị phá vỡ, tính khả dụng của dữ liệu (DA) nằm on-chain, chưa kể bản thân hàm chuyển đổi trạng thái là không cần tin cậy (vì các nút đầy đủ thực sự thực thi toàn bộ chương trình, chứ không chỉ xác minh một bằng chứng hợp lệ cho chính quá trình thực thi). Một số người có thể cho rằng bằng chứng ZK là không cần tin cậy, nhưng điều đó đơn giản là không đúng — dù chúng giảm thiểu nhu cầu tin cậy ở mức đáng kể, về mặt toán học, các giả định bảo mật không giống nhau (chúng có thể đủ cho 99% trường hợp sử dụng, nhưng vẫn áp đặt một giả định tin cậy bổ sung so với nút đầy đủ — ví dụ: Giả định Diffie Hellman song tuyến trong trường hợp zk-SNARK dựa trên đường cong ghép cặp). Nhưng tất nhiên, vì ZK-Compression sử dụng snark để kiểm tra tính hợp lệ của chính tài khoản, có thể nói rằng ZK-Compression không phải là không cần tin cậy — các tài khoản được nén bằng ZK có những giả định tin cậy không tồn tại ở tài khoản "thông thường". Vì vậy, nó nằm đâu đó giữa một hệ thống không cần tin cậy và một ZK rollup hoàn chỉnh.

Nếu sử dụng tên gọi để suy ra các đặc tính, tôi cho rằng việc gọi nó là "rollup" không truyền tải được sự hiện diện của những đặc tính hoặc giả định tin cậy đó. Có lẽ nên đặt một tên mới? ZK-Compression hoàn toàn ổn, miễn là các giả định tin cậy được trình bày rõ ràng.