Trong những ngày sau thông báo của Helius và Light Protocol về dự án ZK Compression (ZK) của họ trên Solana, đã có nhiều cuộc thảo luận về ZK Compression. Một phần đáng kể của cuộc trò chuyện đã tập trung vào danh pháp. Đây có phải là bản tổng hợp ZK không? Một L2? Hoặc một cái gì đó khác hoàn toàn?
Tại sao điều này lại quan trọng? Một số người trong hệ sinh thái Solana tin rằng những tranh luận xung quanh danh pháp là không cần thiết. Tôi đồng ý một phần rằng tên chúng tôi sử dụng không quan trọng bằng ý nghĩa của nó – nhưng nó vẫn quan trọng vì những cái tên đó đề cập đến các cấu trúc có thuộc tính cụ thể và nhóm chúng lại với nhau. Do đó, gọi nó là XYZ có thể cho chúng ta biết về các đặc tính và giả định về độ tin cậy của nó – cũng như những điều chúng ta nên quan tâm!
Nội dung bài viết
Thuộc tính nổi bật của Solana
Hãy liệt kê một số thuộc tính mà Solana có mà chúng tôi quan tâm trước khi đánh giá chúng trong bối cảnh ZK-Compression:
- Khả năng kết hợp nguyên tử đồng bộ
- Đồng thời
- Sự an toàn
- Sự sống động
- Chống kiểm duyệt
Giả định tin cậy ban đầu
Chúng tôi sẽ sử dụng thuật ngữ “không tin cậy” để áp dụng cho các giả định bảo mật của nút đầy đủ. Định nghĩa này là cơ sở của chúng tôi. Bất cứ điều gì mà một nút đầy đủ không thể thực hiện một mình đều liên quan đến các giả định về độ tin cậy bổ sung. (Lưu ý bên lề: nút đầy đủ là cách không cần tin cậy duy nhất để tương tác với một giao thức. Nếu ai đó cố gắng đưa ra các giả định tin cậy bổ sung – cầu nối, ủy ban, nhiều chữ ký, ZK, gian lận hoặc bất cứ điều gì và cho rằng nó không đáng tin cậy thì họ đã sai).
Một số thông tin cơ bản
Chúng tôi sẽ cố gắng cung cấp ngắn gọn thông tin cơ bản cần thiết về Solana để hiểu ZK-Compression bằng cách sử dụng các gạch đầu dòng nhanh.
- 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à “Account”
- Tài khoản có địa chỉ (mỗi tài khoản 32 byte)
- Lượng dữ liệu mà tài khoản có thể lưu trữ khác nhau – từ 0 đến 10 MB (tối đa)
– Việc lưu trữ 10 MB trong Solana tốn khoảng 70 SOL do người tạo tài khoản trả. Chi phí này liên quan đến dung lượng lưu trữ chứ không phải số lượng tài khoản – nó có thể là tài khoản 1x 10MB hoặc 1000x 10KB.
– Dung lượng hiện tại của tất cả các tài khoản trên Solana là 76GB (đã nén)
- Mọi giao dịch Solana cần chỉ định tất cả các tài khoản mà nó đọc và ghi vào
- Các giao dịch Solana hiện bị giới hạn ở mức 1232 byte (có một đề xuất để tăng điều này)
- Mỗi giao dịch Solana cần chỉ định một số văn bản
– Chữ ký (mỗi chữ ký 64 byte)
– Tài khoản (mỗi tài khoản 32 byte)
– Dữ liệu lệnh (độ 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 chương trình chéo)
- Các giao dịch Solana bao gồm “blockhash gần đây” 32 byte phải nằm trong 150 khối gần đây nhất) hoặc bị coi là không hợp lệ và cần phải được ký lại và 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 được thực hiện, vòng đời như sau:
- Kiểm tra tuổi (chỉ các giao dịch gần đây là hợp lệ), chống trùng lặp, xác minh cấu trúc, phí (gas) và kiểm tra chữ ký được thực hiện lần đầu tiên trên giao dịch
- Mã byte chương trình được tải dựa trên địa chỉ chương trình và Máy ảo Solana (SVM) được khởi tạo
- Tất cả các tài khoản được tham chiếu bởi giao dịch đều được kiểm tra, tải từ bộ nhớ vào bộ nhớ và chuyển đến SVM
- Mã byte chương trình được thực thi
- Mọi tài khoản đã sửa đổi đều được đồng bộ hóa trở lại bộ nhớ ở trạng thái cập nhật
Động lực chính của ZK-Compression là:
- Trạng thái trên chuỗi rất tốn kém. Ví dụ: một nghìn tài khoản có giá 70 SOL, vì vậy các sản phẩm như Drip Haus sẽ nhanh chóng trở nên đắt đỏ
- Ngay cả khi không có trạng thái Merkelization đầy đủ, nhiều tài khoản được lưu trữ trên đĩa hơn có nghĩa là ảnh chụp nhanh lớn hơn, chỉ mục lớn hơn…
- Không phải tất cả các tài khoản đều được truy cập thường xuyên, do đó việc phát sinh chi phí tài nguyên liên tục là không cần thiết
Vậy, cách đơn giản nhất để đạt được Compression là gì?
Thay vì lưu trữ tài khoản trên đĩa và đọc chúng khi cần (bước 3 trong vòng đời thực hiện giao dịch), một giao dịch có thể truyền dữ liệu tài khoản như một phần của tải trọng, tiết kiệm chi phí liên quan đến lưu trữ trên chuỗi. Nhưng điều này mở ra một vấn đề mới – làm thế nào bạn có thể thực thi quy tắc rằng người dùng không nói dối về trạng thái?
Ví dụ, giả sử giá trị ngoài chuỗi 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 nó có “BYixJwV32DjeuyRww72PwZMyKcaedN533GBrv7CDh4n9”. Nếu bạn gửi một giao dịch có dữ liệu đó đến chuỗi, thì làm thế nào chuỗi biết rằng bạn không nói dối về số lượng token mà địa chỉ “BYixJwV32DjeuyRww72PwZMyKcaedN533GBrv7CDh4n9” có? Rốt cuộc, nút đầy đủ xử lý giao dịch không có quyền truy cập vào dữ liệu ngoài chuỗi – nó mong đợi bạn cung cấp dữ liệu cùng với giao dịch.
Bạn có thể sử dụng Merkle Proofs cho mục đích này. Không đi sâu vào chi tiết về Merkle Proofs, hãy xem xét rằng chúng là một cách để “cam kết” với một số dữ liệu theo cách có thể xác minh được với dấu chân lưu trữ nhỏ trên chuỗi. Tất cả các nút đầy đủ được đồng bộ hóa với chuỗi lưu trữ “cam kết” nhỏ đó và khi ai đó cung cấp dữ liệu trong một giao dịch, họ cũng có thể cung cấp “bằng chứng” trong cùng một giao dịch có thể được xác minh so với cam kết. Bằng chứng này được bảo mật bằng mật mã.
Có vấn đề gì với điều này không? Vấn đề là Merkle Proofs có thể lớn. Nếu một Tree chứa 100.000 tài khoản, thì kích thước bằng chứng cho một trong những tài khoản này là 17 * 32 = 544 byte. Nếu bạn 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, nó sẽ nhân với kích thước bằng chứng, vì vậy mười tài khoản trong trường hợp xấu nhất sẽ là 10 * 544 = 5440 byte. Vấn đề không gian này chỉ dành riêng cho Solana vì giao dịch Solana hiện bị giới hạn ở 1232 byte, trong khi các chuỗi khác có xu hướng ít hạn chế hơn. Tham khảo 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ậy, ngay cả trong trường hợp tốt nhất, bạn vẫn sử dụng một nửa kích thước giao dịch chỉ dành cho Merkle Proofs.
Có một số câu hỏi phát sinh ở đây:
1. Nếu kích thước giao dịch là 1232 byte, bạn sẽ gửi toàn bộ dữ liệu như một phần của giao dịch như thế nào?
ZK Compression hữu ích cho một số lượng rất lớn các tài khoản nếu chúng bao gồm một lượng dữ liệu nhỏ. Số dư token (8 byte cho mỗi token), một lượng nhỏ siêu dữ liệu cho NFT… – 100 byte dữ liệu có thể dễ dàng phù hợp với một giao dịch. 1000 byte là khó, vì có những thứ khác đi vào đó. Nếu bạn cần tài khoản của mình lưu trữ lượng dữ liệu lớn hơn, phương pháp ZK Compression sẽ không hiệu quả.
Ngoài ra, cùng một logic được sử dụng trong ZK Compression có thể được sử 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à mặc dù không thể đưa toàn bộ dữ liệu của một tài khoản vào một tải trọng giao dịch duy nhất, nhưng vẫn có cách giải quyết – cụ thể là cam kết và cung cấp bằng chứng cho dữ liệu một phần.
2. Merkle Proofs có phải là cách duy nhất để thực hiện việc này không?
Không! Merkle Proofs chỉ là một loại cam kết vectơ. 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 vectơ mà bạn đang cam kết. Đó là nơi chúng ta có được 17 từ khi Log2(100000) là 17. Nhưng cũng có các cam kết kích thước bằng chứng không đổi (KZG, Pedersen); trên thực tế, ZK-Compression sử dụng một phương pháp như vậy!
3. Bạn nói rằng dữ liệu tài khoản thường được lưu trữ trên một node đầy đủ như một phần của trạng thái phải được cung cấp cùng với giao dịch. Dữ liệu đó được lưu trữ ở đâu?
Câu hỏi rất hay và ảnh hưởng đến các giả định và thuộc tính tin cậy của chúng tôi. Câu trả lời là – bất cứ đâu! Máy chủ RPC chuyên dụng có thể lưu trữ dữ liệu này; nó có thể là một phần của Filecoin hoặc IPFS hoặc người dùng thậm chí có thể lưu trữ nó trên máy của riêng họ. Điều quan trọng là miễn là tất cả các phần tử của vectơ được lưu trữ ở đâu đó, thì các bằng chứng có thể được tính toán ngay lập tức. Chúng tôi sẽ đề cập đến các hàm ý của nơi lưu trữ dữ liệu này trong phần thuộc tính.
4. Các chain khác có thể làm điều này không?
ZK-Compression yêu cầu xác minh zk-SNARK phải rẻ. Vì vậy, điều này hoạt động tốt trên Solana vì tính toán rẻ hơn lưu trữ. Khái niệm chung về việc sử dụng các cam kết vectơ và bằng chứng cho dữ liệu được cung cấp cho mỗi giao dịch có thể thực hiện được trên các chuỗi khác, nhưng tính toán đắt đỏ có nghĩa là sự đánh đổi ít nổi bật hơn so với Solana. Trên thực tế, chi phí khí xác minh liên tục so với SSTORE một lần thực sự đắt hơn trên các chuỗi dựa trên EVM.
ZK-Compression là gì?
- Nếu bạn không biết ZK Compression là gì, phần này sẽ đề cập đến điều đó
- Nếu bạn có ý tưởng mơ hồ về nó, tôi vẫn khuyên bạn nên đọc phần này vì có một số quan niệm sai lầm phổ biến
Nếu bạn hiểu phần trên, bạn đã hiểu 90% về ZK Compression. Vấn đề chính là kích thước Merkle Proofs, vì vậy tất cả những gì ZK Compression là sử dụng một lược đồ để chứng minh một phép tính.
Nếu bạn không biết ZK là gì, thì điều đó không quan trọng lắm. Tất cả những gì bạn cần biết là đó là cách chứng minh rằng bạn đã thực hiện một phép tính “đúng”. Một ví dụ đơn giản là bạn muốn chứng minh rằng bạn đã nhân hai số để có được số thứ 3. tức là 4*3 = 12
“Cách ZK” để chứng minh điều này là có hàm sau: f(x,y) = x*y
Nếu bạn tạo một mạch cho mã trên, trình chứng minh sẽ tạo ra bằng chứng về phép tính đúng. Bản thân mạch là cam kết, vì vậy mọi người đều biết “phép tính” 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 bạn chạy f(3,4), nó trả về 12 và “bằng chứng”. Bây giờ 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 MỘT SỐ hai số để có được 12. Họ không biết bạn đã thực hiện 4,3 hay 6,2, hoặc thậm chí là 12,1. Thực tế là bạn ẩn những con số đó và người khác vẫn có thể xác minh là nơi bạn nhận được phần “Zero-Knowledge”.
Tại sao tôi giải thích điều này? Khái niệm tổng quát này cực kỳ mạnh mẽ trong việc chứng minh rằng bạn đã thực hiện một phép tính nhất định và có được một kết quả nhất định. Khi ai đó có kết quả và bằng chứng, họ có thể xác minh xem bạn đã thực hiện đúng hay không mà không cần thực sự chạy phép tính. Và điều này đúng với BẤT KỲ phép tính tùy ý nào. Tôi vừa nhân hai số, nhưng bạn thậm chí có thể sử dụng nó để nói rằng, “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 các bằng chứng không kiến thức được sử dụng ngay cả khi bạn không cần “ẩn” thứ gì đó. Bởi vì bạn đang biến một vấn đề đòi hỏi phải chạy 1000 bước tính toán (hoặc thậm chí là một triệu) thành một vấn đề chỉ cần xác minh một bằng chứng để biết rằng phép tính đã được thực hiện chính xác. Lưu ý là việc tạo bằng chứng mất một thời gian.
ZK Compression sử dụng cùng công nghệ để chạy logic thành viên Merkle Tree thực tế. Vì vậy, nó có một mạch có thể lấy dữ liệu tài khoản, một bằng chứng (128 byte) và 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ều tiện lợi với các đường cong và điểm elliptic là nếu bạn biết đường cong, bạn chỉ cần một điểm để có được điểm thứ hai).
Điều này được thực hiện chủ yếu để giảm kích thước bằng chứng xuống còn 128 byte không đổi, vẫn để lại nhiều chỗ trống (tương đối) cho dữ liệu của các tài khoản nhỏ. Trong khi Merkle Proofs thông thường là Log2(N), ZK Compression luôn không đổi để bạn có thể có một số lượng lớn tài khoản trong một cam kết duy nhất. (Để tham khảo, một Merkle Proofs cho 100.000 tài khoản sẽ vào khoảng 550 byte, bằng một nửa tải trọng giao dịch)
Có thể tạo bằng chứng này ngoài chuỗi, nhưng phải xác minh bằng chứng này trên chuỗi 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 có thể cho phép thực thi. Cơ chế cơ bản để xác minh bằng chứng ZK phải có để thực hiện điều đó. Hệ thống chứng minh cụ thể mà ZK-Compression sử dụng được gọi là Groth16 và ngược lại, nó dựa vào syscall alt_bn128, hiện đang được tính năng hóa trong mạng chính và đang được thử nghiệm.
Điều tuyệt vời là cơ chế mà ZK-Compression sử dụng có thể được sử dụng để xác minh các phép tính tùy ý (không chỉ là “lá này có thuộc về 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 tất cả các đường ống để nhà phát triển không phải xử lý phần “ZK” chút nào. Theo quan điểm của nhà phát triển, họ coi nó như bất kỳ tài khoản nào khác có cùng các trường…, vì vậy bên trong chương trình, nó có thể được coi như một tài khoản thông thường. Có giá trị trong việc trừu tượng hóa hầu hết “phép thuật ZK” và không để nhà phát triển xử lý nó.
ZK Rollup
Không đi sâu vào chi tiết, ZK Rollup chủ yếu sử dụng cùng khái niệm mà ZK-Compression sử dụng. Điểm tương đồng 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 trong lớp cơ sở (Ethereum), đó là lý do tại sao có 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 như chương trình nhân mà chúng ta đã sử dụng làm ví dụ). Tất cả 100 giao dịch đều được xác minh (chữ ký, logic hợp đồng, kiểm tra loại bỏ trùng lặp…) và một bằng chứng duy nhất được tạo ra 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 sẽ cập nhật gốc trạng thái từ A đến B.
Tuy nhiên, trong ZK-Compression, mỗi giao dịch trong số 100 giao dịch đều chứa một bằng chứng chỉ cho bạn biết dữ liệu tài khoản là chính xác, nhưng các chuyển đổi trạng thái (do giao dịch tạo ra) thực sự được thực hiện trên chuỗi như một phần của chính SVM. Sau khi bằng chứng được xác thực, nó được coi là một tài khoản thông thường. Điều này rất quan trọng đối với thuộc tính khả năng kết hợp mà chúng ta sẽ thảo luận tiếp theo.
Xem lại các thuộc tính của Solana còn giữ lại
Bây giờ, chúng ta đến phần thú vị. Một số thuộc tính của Solana mà ZK-Compression giữ lại là gì?
- 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 ZK Compression và 10 tài khoản “bình thường”, thì nó không phá vỡ tính năng kết hợp. Một lệnh tham chiếu đến một tài khoản ZK Compression có thể gọi một lệnh/chương trình khác tham chiếu đến một tài khoản “bình thường” chưa nén. Tính năng này được giữ lại 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 lệnh không thành công, toàn bộ giao dịch sẽ được khôi phục (nguyên tử) và các thay đổi từ lệnh được gọi ở dòng 1 sẽ hiển thị ở dòng 2 (đồng bộ).
Điều này không đúng đối với các rollup vì các rollup ZK không thể gọi nhau theo cách đồng bộ hoặc nguyên tử (trừ khi chúng sử dụng khóa toàn cục và cho phép khôi phục rollup chéo)
- Parallelism
Tính năng này có một số tác động đến tính song song và mỗi trường hợp đều đáng để 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 đều đồng thời riêng. Đ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, họ 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 sẽ giống với logic mà Solana sử dụng để cập nhật Merkle Tree đồng thời trong cNFT
- Ghi vào cùng một tài khoản nén: Mỗi tài khoản nén không đồng thời. Nếu hai người dùng cố gắng ghi vào cùng một tài khoản nén, thì một trong các giao dịch sẽ không thành công bất kể thứ tự. Trong quá trình thực thi bình thường, các lệnh ghi vào một tài khoản từ lệnh trước đó sẽ khả dụng cho lệnh tiếp theo, nhưng với các tài khoản ZK Compression, bằng chứng về dữ liệu tài khoản sẽ không hợp lệ vì đó là bằng chứng về trạng thái trước đó
Một điểm cần lưu ý nữa là việc sử dụng đơn vị tính toán (CU) lớn để nén sẽ 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ể chiếm 12M đơn vị tính toán trên mỗi khối, với giới hạn CU của tài khoản.
(Lưu ý: Trong khi khả năng ghép nối nguyên tử đồng bộ là một vấn đề với hầu hết các bản tổng hợp, thì thuộc tính Parallelism được nêu rõ hơn để làm nổi bật không cần thêm thành phần nào để kích hoạt ZK Compression, chẳng hạn như trình sắp xếp, v.v. Việc thiếu trình sắp xếp có nghĩa là chuỗi cơ sở đang thực hiện việc sắp xếp. Bây giờ chúng ta có thể thảo luận về cách cùng một thuộc tính đúng đối với bản tổng hợp dựa trên, nhưng không đúng đối với hầu hết các bản tổng hợp vì chúng sử dụng trình sắp xếp tập trung để sắp xếp)
Giả định về độ tin cậy
Mặc dù bất kỳ ai cũng có thể lưu trữ tất cả dữ liệu thô cần thiết để tạo bằng chứng và gửi giao dịch, nhưng đây là một giả định về độ tin cậy bổ sung ảnh hưởng đến tính sống độ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ễ, thì bạn sẽ không thể gửi giao dịch trừ khi bạn tự lưu trữ dữ liệu. May mắn thay, đây là vấn đề được gọi là sự cố f+1 chứ không phải là sự cố 3f+1, đòi hỏi khả năng chịu lỗi Byzantine. Sự cố f+1 chỉ yêu cầu một nút trung thực cung cấp dữ liệu và vì bằng chứng “có thể tự xác minh” nên không có vấn đề “an toàn”. Về cơ bản, có vấn đề về “tính sống động” và vectơ 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 về tính hợp lệ. Nhưng 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 về tính hợp lệ, ZK Compression chỉ mã hóa “Dữ liệu tài khoản có chính xác không?” Vì vậy, các giả định về độ tin cậy ở đây hơi khác một chút. Trong trường hợp nén, các giả định về độ tin cậy chủ yếu dành cho quyền truy cập trạng thái (trong khi quá trình chuyển đổi trạng thái được thực hiện đầy đủ). Trong trường hợp tổng hợp, các giả định về độ tin cậy dành cho toàn bộ chức năng chuyển đổi trạng thái (theo quan điểm của lớp cơ sở). Các giả định về bảo mật liên quan đến số bit hoặc độ khó/tính khó giải quyết của vấn đề cơ bản là giống nhau (Giả định Diffie-Hellman song tuyến tính), nhưng *những gì* bạn tin tưởng vào mô hình bảo mật đó mới là điều khác biệt – quyền truy cập trạng thái so với thực thi. Tôi chỉ đề cập đến điều này vì điều quan trọng là phải biết các giả định về độ tin cậy bổ sung đang đượ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 ZK Compression có thể nâng cấp được, nhưng có thể không thay đổi hoặc đóng băng trong tương lai vì nó chỉ thực hiện một hoạt động rất cụ thể (mở Merkle Proofs), thực sự không yêu cầu nâng cấp liên tục.
Ngoài ra, nén trạng thái cũng có thể đạt được theo hai cách nữa.
- Một đề xuất để tăng kích thước giao dịch (kênh proj-3x-tx trong Solana discord) đang được phát triển. Khi nó hoạt động, bạn có thể sử dụng các Merkle Proofs thông thường nếu kích thước khả thi
- Khi syscall alt_bn128 hoạt động, nó cũng có thể được sử dụng cho một cam kết vectơ thông thường có kích thước bằng chứng không đổi (KZG hoạt động với bất kỳ đường cong nào thân thiện với cặp, bao gồm cả alt_bn128). Điều này không yêu cầu mạch ZK-prover
Chúng ta gọi đây là gì?
Thật không may, các thuật ngữ như Rollup, L2 và Validium đã được áp dụng rất lỏng lẻo đến mức một số rollup thậm chí không phải là rollup. Chúng không kế thừa tính sống động, tính an toàn hoặc khả năng chống kiểm duyệt của lớp cơ sở. Trong khi Helius bị cáo buộc sử dụng “thuật ngữ tiếp thị”, thì những người đó đã sử dụng “rollup” rất lỏng lẻo để chỉ các dự án mà họ đã đầu tư vì cùng lý do đó – tiếp thị. Trên thực tế, các non-rollup được gắn thẻ với các giai đoạn khác nhau chỉ để chúng có thể tiếp tục gọi mình là rollup.
Không phải ai cũng phạm lỗi này – một số người đã thành thật một cách tàn nhẫn về việc sử dụng thuật ngữ chính xác và đã dành nhiều tháng để tranh luận với những người sử dụng thuật ngữ không chính xác để đánh lừa người dùng (xin gửi lời cảm ơn đến Toghrul, người liên tục kêu gọi thuật ngữ chính xác từ *mọi người*).
Vì nó có một số thuộc tính và giả định về độ tin cậy khác với Rollup, nên việc gọi nó là Rollup có thể gây nhầm lẫn cho người dùng. Gọi nó là Validium cũng quá rộng vì nó bỏ qua thực tế là khả năng hợp nhất nguyên tử đồng bộ hoặc tính song song không bị hỏng, tính khả dụng của dữ liệu (DA) nằm trên chuỗi và chưa kể đến việc bản thân hàm chuyển đổi trạng thái không đáng tin cậy (vì các nút đầy đủ đang thực thi các chương trình thực tế đầy đủ chứ không chỉ xác minh bằng chứng hợp lệ cho chính quá trình thực thi).
Một số người có thể lập luận rằng ZK Proofs không đáng tin cậy, nhưng điều đó hoàn toàn không đúng – mặc dù chúng được giảm thiểu đáng kể độ tin cậy – về mặt toán học, các giả định về bảo mật không giống nhau (chúng có thể đủ cho 99% các trường hợp sử dụng, nhưng nó áp đặt một giả định tin cậy bổ sung đối với nút đầy đủ – ví dụ, Giả định Bilinear Diffie Hellman trong trường hợp đường cong ghép nối dựa trên zk-SNARK). Nhưng tất nhiên, vì ZK-Compression đang sử dụng snark để kiểm tra tính hợp lệ của chính tài khoản, nên có thể nói rằng ZK-Compression không phải là không đáng tin cậy — có những giả định tin cậy đối với các tài khoản ZK Compression không tồn tại đối với các tài khoản “bình thường”. Vậy thì nó nằm giữa trustless và một ZK Rollup hoàn chỉnh.
Hiểu đơn giản ZK Compression là việc nén những “bằng chứng” lại trong Rollup để đảm bảo về khả năng lưu trữ. Hy vọng những giải thích chi tiết trong bài viết đã giúp mọi người hiểu hơn về ZK Compression và Solana Blockchain.
Freelancer Marketing và Content Creator với gần 10 năm kinh nghiệm; trong đó có khoảng hơn 3 năm làm việc trong mảng Blockchain với vai trò Dịch Thuật và Copywriter.
Với kiến thức sâu rộng cùng khả năng diễn giải để những thuật ngữ công nghệ khó hiểu trở nên gần gũi hơn với người đọc. Lê Hoàng đảm nhiệm những bài viết trong chuyên mục "Từ Điển Crypto" và "Hướng Dẫn Người Mới" tại Fiahub Blog
