Bằng chứng không tri thức: Các ứng dụng trên Solana

Giới thiệu

Đây là bài viết thứ hai trong loạt bài nhập môn về bằng chứng không tri thức. Tôi đặc biệt khuyên bạn nên đọc Bằng chứng không tri thức: Giới thiệu về các nguyên lý nền tảng trước bài này vì nội dung đó cung cấp bối cảnh cần thiết về lý thuyết, toán học và mật mã học làm cơ sở cho phần phân tích tại đây. Bài viết này giả định bạn đã có kiến thức đó. Vì vậy, nếu chưa quen với bằng chứng không tri thức, tôi đặc biệt khuyên bạn nên đọc bài kia trước. Mục tiêu của bài viết là trang bị kiến thức cần thiết để bạn tham gia thảo luận về bằng chứng không tri thức trên Solana, thậm chí tiến tới phát triển các primitive không tri thức mới và sáng tạo.

Với kiến thức mới này, cuối cùng chúng ta có thể đặt câu hỏi: bằng chứng không tri thức là gì? Chúng được sử dụng trên Solana như thế nào?

Bằng chứng không tri thức là gì?

Giờ đây, khi đã nắm được nền tảng lý thuyết, toán học và mật mã học cần thiết, chúng ta có thể đặt câu hỏi: chính xác thì bằng chứng không tri thức là gì?

Bằng chứng không tri thức là một quy trình mật mã, trong đó một bên có thể chứng minh cho bên kia rằng một mệnh đề nhất định là đúng mà không tiết lộ thêm bất kỳ thông tin nào ngoài việc mệnh đề đó thực sự đúng. Những bằng chứng này phải đúng đắn về mặt thống kê, đầy đủ và an toàn trước nguy cơ rò rỉ thông tin.

Có hai loại mệnh đề mà người ta muốn chứng minh theo cách không tri thức. Xét ở cấp độ khái quát:

• Mệnh đề về sự thật (ví dụ: đồ thị cụ thể này có thể được tô bằng ba màu)
• Mệnh đề về tri thức (ví dụ: tôi biết cách phân tích N thành thừa số)

Mệnh đề thứ nhất về cơ bản liên quan đến một thuộc tính nội tại nào đó của vũ trụ — một điều đúng về bản chất, chẳng hạn 1 + 1 = 2. Mệnh đề thứ hai được gọi là bằng chứng tri thức. Nghĩa là nó vượt ra ngoài việc chỉ chứng minh điều gì đó là đúng và dựa vào những gì Bên chứng minh biết.

Như đã đề cập, để chứng minh các mệnh đề này, bằng chứng có thể mang tính tương tác hoặc không tương tác. Trong bằng chứng không tri thức tương tác, Bên chứng minh và Bên xác minh thực hiện nhiều vòng trao đổi cho đến khi Bên xác minh được thuyết phục ngoài mọi nghi ngờ hợp lý. Zcash sử dụng bằng chứng không tri thức không tương tác để cho phép người dùng thực hiện giao dịch ẩn danh. 

Ngược lại, với bằng chứng không tri thức không tương tác, bằng chứng được chuyển ngoại tuyến mà không có bất kỳ giao tiếp trực tiếp nào giữa Bên chứng minh và Bên xác minh. Ở đây, Bên chứng minh tạo ra một bằng chứng chứa toàn bộ thông tin cần thiết, còn Bên xác minh có thể xác minh độc lập mà không cần thêm tương tác. Filecoin sử dụng bằng chứng không tri thức không tương tác để chứng minh rằng người dùng đã lưu trữ dữ liệu mà không tiết lộ chính dữ liệu đó. 

 zk-SNARK và mạch

zk-SNARK là Succinct Non-interactive ARgument of Knowledge, tức lập luận tri thức ngắn gọn, không tương tác. Các bằng chứng không tri thức này đặc biệt hiệu quả và nhỏ gọn, hay ngắn gọn. Một bằng chứng được coi là ngắn gọn nếu cả kích thước bằng chứng lẫn thời gian xác minh đều tăng chậm hơn phép tính cần xác minh. Vì vậy, nếu muốn có bằng chứng ngắn gọn, ta không thể để bên xác minh thực hiện một lượng công việc trong mỗi vòng băm, nếu không thời gian xác minh sẽ tỷ lệ thuận với phép tính. Bằng chứng ngắn gọn có thể tồn tại nhờ đa thức và heuristic Fiat-Shamir.

Bất kể mệnh đề cần chứng minh phức tạp đến đâu, zk-SNARK vẫn giữ kích thước bằng chứng nhỏ và thời gian xác minh tương đối nhanh. Đây là điều khiến zk-SNARK đặc biệt hấp dẫn đối với rollup: ta có một phương pháp chứng minh mọi giao dịch trên một L2 nhất định đều hợp lệ, đồng thời bằng chứng đủ nhỏ để được xác minh trên L1. Các giao thức như Mina tiến thêm một bước khi sử dụng bằng chứng đệ quy, cho phép xác minh toàn bộ lịch sử chuỗi bằng một bằng chứng có kích thước không đổi. Pickles là hệ thống bằng chứng và bộ công cụ liên quan mới của Mina, đồng thời là zk-SNARK đầu tiên được triển khai có khả năng kết hợp đệ quy mà không cần thiết lập tin cậy. Lưu ý rằng khi nói đến kết hợp đệ quy, chúng ta đang đề cập đến mạch.

Mạch mô tả phép tính mà bạn muốn chứng minh. Đó là một chuỗi phép toán nhận một số đầu vào để tạo ra đầu ra. Mạch được sử dụng trong bằng chứng không tri thức để biểu diễn các phép tính đã được thực hiện chính xác mà không tiết lộ đầu vào của phép tính. Quy trình tổng quát như sau:

• Viết và biên dịch mạch — Ta cần viết và biên dịch mạch. Việc này có thể đơn giản như tạo một mạch số học trên trường hữu hạn được xác định bởi số nguyên tố p = 7 và phép tính x * y = z. Ý tưởng chung là biểu diễn phép tính cần chứng minh dưới dạng một tập ràng buộc giữa các biến, rút gọn các ràng buộc này thành phương trình đa thức và viết mã ánh xạ tất cả giá trị theo một cách nhất định sang cấu trúc đại số mới (tức đồng cấu). Quá trình biên dịch sẽ tạo ra một số artifact, bao gồm tập ràng buộc do mạch xác định và một script hoặc tệp nhị phân dùng trong các bước tiếp theo
• Nghi thức thiết lập tin cậy — Tùy loại zk-SNARK dùng để tạo khóa chứng minh và khóa xác minh, có thể cần tiến hành một nghi thức
• Thực thi mạch — Mạch phải được thực thi bằng script hoặc tệp nhị phân tạo ra trong quá trình biên dịch, như thể đó là một loại chương trình. Người dùng nhập đầu vào công khai và riêng tư, sau đó hệ thống tính giá trị cho mọi biến trung gian và biến đầu ra. Witness, còn gọi là trace, là bản ghi toàn bộ các bước tính toán
• Tạo bằng chứng — Với khóa chứng minh ở bước hai và witness ở bước ba, bên chứng minh có thể tạo bằng chứng không tri thức rằng mọi ràng buộc được xác định trong mạch đều thỏa mãn, trong khi chỉ tiết lộ giá trị đầu ra. Bằng chứng này được gửi cho bên xác minh
• Xác minh bằng chứng — Bên xác minh sử dụng bằng chứng đã gửi và khóa xác minh để xác nhận bằng chứng là chính xác đối với đầu ra công khai

Một số loại zk-SNARK, chẳng hạn Groth16, yêu cầu thiết lập tin cậy cho từng mạch. Điều này có thể gây trở ngại vì bạn phải tiến hành một nghi thức mới cho mỗi chương trình mới. Các zk-SNARK khác, chẳng hạn PlonK, chỉ yêu cầu một thiết lập tin cậy phổ quát, giúp đơn giản hóa toàn bộ quy trình. Các loại bằng chứng không tri thức khác, chẳng hạn zk-STARK, loại bỏ hoàn toàn nhu cầu thiết lập tin cậy.

zk-STARK

zk-STARK là Scalable Transparent ARgument of Knowledge, tức lập luận tri thức minh bạch và có khả năng mở rộng. zk-STARK do StarkWare phát minh và được đề xuất lần đầu trong bài nghiên cứu năm 2018 này như một phương án thay thế cho zk-SNARK. Về cơ bản, chúng cho phép blockchain chuyển phép tính đến một Bên chứng minh STARK duy nhất ngoài chuỗi và xác minh tính toàn vẹn của các phép tính đó bằng Bên xác minh STARK trên chuỗi. 

zk-STARK được coi là không tri thức vì các đầu vào mà bên chứng minh ngoài chuỗi sử dụng không bị tiết lộ cho blockchain, qua đó duy trì quyền riêng tư của người dùng. zk-STARK có khả năng mở rộng vì việc chuyển phép tính ra ngoài chuỗi giúp giảm đáng kể chi phí xác minh trên L1. Bằng chứng của chúng cũng mở rộng tuyến tính, trong khi zk-SNARK chỉ mở rộng gần tuyến tính. Hơn nữa, zk-STARK không dựa vào các nghi thức thiết lập tin cậy phức tạp, vốn được cho là dễ bị ảnh hưởng bởi chất thải độc hại — các bằng chứng không hợp lệ có thể được bên xác minh chấp nhận nếu nghi thức không được tiến hành đúng cách. Thay vào đó, zk-STARK sử dụng tính ngẫu nhiên có thể xác minh công khai để thiết lập tương tác giữa bên chứng minh và bên xác minh. Ngoài ra, những bằng chứng này chỉ có thể được tạo bởi bên chứng minh ngoài chuỗi đã thực sự thực thi phép tính cùng với các đầu vào phụ trợ mà phép tính yêu cầu.

zk-STARK giải quyết các hạn chế của zk-SNARK bằng cách cung cấp các lập luận tri thức có khả năng mở rộng và minh bạch. Chúng cũng dựa trên các giả định mật mã đơn giản hơn nhiều, hoàn toàn tránh nhu cầu sử dụng các thành phần như đường cong elliptic. Thay vào đó, chúng chỉ dựa vào hàm băm và lý thuyết thông tin, nhờ đó kháng lượng tử. Tuy nhiên, kích thước bằng chứng có thể lên đến vài trăm kilobyte, làm hạn chế tính khả thi trong các môi trường có băng thông hoặc dung lượng lưu trữ hạn chế như blockchain. Lưu ý rằng một số cấu hình chứng minh và zkVM phức tạp hơn sẽ kết hợp việc chứng minh đệ quy các zk-STARK vào một zk-SNARK chỉ dành cho bước xác minh cuối cùng.

ZK Compression

Vấn đề tăng trưởng trạng thái

Một trong những vấn đề cấp bách nhất của Solana là vấn đề tăng trưởng trạng thái. Để hiểu bối cảnh, trạng thái của Solana được lưu trên ổ đĩa của các node đầy đủ trong Accounts DB. Đây là kho khóa-giá trị, trong đó mỗi mục nhập vào cơ sở dữ liệu được gọi là một tài khoản. Mỗi tài khoản có địa chỉ dài 32 byte và có thể lưu trữ từ 0 đến 10 MB dữ liệu. Hiện tại, lưu trữ 10 MB dữ liệu tốn khoảng 70 SOL, bất kể dữ liệu được phân bổ trong một tài khoản 10 MB hay một nghìn tài khoản 10 KB. Mỗi ngày, khoảng một triệu tài khoản mới được thêm vào chuỗi, nâng tổng trạng thái lên hơn 500 triệu tài khoản theo bài đăng của Toly về vấn đề tăng trưởng trạng thái. Điều này sẽ tạo ra một số thách thức khi Solana tiếp tục phát triển, cụ thể là kích thước snapshot không giới hạn, giới hạn băng thông PCI, lập chỉ mục tài khoản và chi phí quản lý bộ nhớ cùng ổ đĩa cao. 

Kích thước snapshot đầy đủ hiện tại vào khoảng 70 GB, vẫn có thể quản lý bằng phần cứng hiện nay. Tuy nhiên, tăng trưởng liên tục chắc chắn sẽ dẫn đến sự kém hiệu quả trong quản lý trạng thái và các điểm nghẽn tiềm ẩn. Khi kích thước snapshot tăng, thời gian cần thiết để khởi động nguội một hệ thống mới sau sự cố phần cứng sẽ kéo dài đáng kể, gây bất lợi khi mạng cần khởi động lại. 

Băng thông Peripheral Component Interconnect (PCI) là tốc độ truyền dữ liệu giữa CPU và các thiết bị ngoại vi như card đồ họa, card mạng và thiết bị lưu trữ. PCI Express (PCIe) là tiêu chuẩn giao diện tốc độ cao được thiết kế để thay thế tiêu chuẩn PCI cũ và cung cấp tốc độ truyền dữ liệu cao hơn. Băng thông PCI mới nhất có thể đạt 1 TB, hay 128 GB/s. Con số này nghe có vẻ lớn, nhưng không phải trong bối cảnh Solana. Nếu một giao dịch đọc hoặc ghi 128 MB, băng thông PCI 128 GB/s sẽ giới hạn Solana ở mức 1.000 giao dịch mỗi giây (TPS). Tuy nhiên, phần lớn giao dịch truy cập bộ nhớ gần đây đã được tải và lưu vào bộ nhớ đệm trong RAM của validator. Dù vậy, bộ nhớ trạng thái hiệu quả vẫn rất quan trọng để duy trì thông lượng cao khi Solana mở rộng; nếu không, băng thông này có thể nhanh chóng trở thành yếu tố giới hạn.

Mỗi validator cần duy trì chỉ mục của tất cả tài khoản hiện có. Lý do là việc tạo tài khoản mới đòi hỏi bằng chứng rằng tài khoản đó chưa tồn tại. Với tổng trạng thái hơn 500 triệu tài khoản, ngay cả một chỉ mục tối thiểu (tức một khóa 32 byte và một hàm băm dữ liệu 32 byte cho mỗi mục) cũng cần khoảng 32 GB RAM. Việc lưu trữ trạng thái này tốn kém và phải được quản lý cẩn thận để tránh suy giảm hiệu năng. Khi trạng thái của Solana tiếp tục tăng, sự khác biệt giữa việc sử dụng bộ nhớ nhanh, đắt tiền (tức RAM) cho một số thao tác và bộ nhớ chậm hơn, rẻ hơn (tức ổ đĩa) trở nên rất quan trọng.

Giao dịch và tăng trưởng trạng thái

Mọi giao dịch Solana đều cần chỉ định tất cả tài khoản mà nó đọc và ghi. Giao dịch hiện bị giới hạn ở 1.232 byte và phải bao gồm:

• Header (3 byte)
• Chữ ký (mỗi chữ ký 64 byte)
• Địa chỉ tài khoản (mỗi địa chỉ 32 byte)
• Dữ liệu instruction (kích thước tùy ý)
• Blockhash gần đây (32 byte)

Khi một giao dịch được thực thi, các bước sau diễn ra:

• Kiểm tra hợp lệ cơ bản — Chỉ các giao dịch gần đây mới hợp lệ; hệ thống thực hiện khử trùng lặp, xác minh cấu trúc, phí và chữ ký của giao dịch
• Tải chương trình — 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
• Tải tài khoản — Mọi 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
• Thực thi — Bytecode của chương trình được thực thi
• Đồng bộ hóa — Mọi tài khoản đã sửa đổi được đồng bộ trở lại bộ nhớ lưu trữ

Vòng đời này tạo ra một số thách thức khi trạng thái tiếp tục tăng. Cụ thể, trạng thái trên chuỗi rất tốn kém và việc lưu nhiều tài khoản hơn trên ổ đĩa dẫn đến snapshot cùng chỉ mục lớn hơn. Ngoài ra, không phải tài khoản nào cũng được truy cập thường xuyên, nên việc liên tục tiêu tốn tài nguyên cho chúng là không hiệu quả.

Đơn giản hóa quản lý trạng thái bằng ZK Compression

Thay vì lưu mọi tài khoản trên ổ đĩa và đọc chúng khi cần, giao dịch có thể truyền dữ liệu tài khoản như một phần của payload giao dịch. Ta có thể dùng cây Merkle để đảm bảo người dùng gửi giao dịch cung cấp đúng trạng thái. Bằng chứng Merkle là một cách cam kết cho dữ liệu. Nhờ đó, bằng chứng có thể được xác minh dựa trên cam kết để xác nhận rằng trạng thái chính xác đã được truyền vào và người dùng không gian dối về trạng thái đã cung cấp. 

Dù an toàn, các bằng chứng này có thể khá lớn. Chẳng hạn, nếu một cây chứa 100 nghìn tài khoản, kích thước bằng chứng sẽ là 544 byte. Việc cung cấp bằng chứng cho nhiều tài khoản có thể nhanh chóng vượt quá giới hạn kích thước giao dịch 1.232 byte. May mắn thay, ta có thể khắc phục bằng cách sử dụng các hệ thống bằng chứng hiệu quả hơn. Việc dùng các cam kết có kích thước bằng chứng không đổi như cam kết KZG hoặc Pedersen sẽ giảm kích thước bằng chứng, giúp khả thi hơn khi đưa bằng chứng vào giới hạn kích thước giao dịch.

ZK Compression đơn giản là một cơ chế giải quyết vấn đề kích thước bằng chứng Merkle — đây là cách chứng minh một phép tính đã được thực hiện chính xác mà không phải chịu chi phí lưu trữ trên chuỗi liên quan, bằng cách tận dụng sổ cái của Solana.

ZK Compression là gì?

ZK Compression là một primitive mới cho phép nhà phát triển nén trạng thái trên chuỗi để giảm chi phí trạng thái theo nhiều bậc độ lớn mà vẫn duy trì tính bảo mật, hiệu năng và khả năng kết hợp. Ví dụ, hiện tại việc tạo 100 tài khoản token sẽ tốn ~0,2 SOL, trong khi với ZK Compression, chi phí giảm 5.000 lần xuống còn ~0,00004. 

ZK Compression tận dụng bằng chứng không tri thức để xác thực các chuyển đổi trạng thái mà không tiết lộ dữ liệu cơ sở. Cơ chế này nhóm nhiều tài khoản vào một gốc Merkle duy nhất có thể xác minh và được lưu trên chuỗi, còn dữ liệu cơ sở được lưu trên sổ cái. Bằng chứng hợp lệ là các bằng chứng không tri thức ngắn gọn được dùng để chứng minh sự tồn tại của n tài khoản dưới dạng lá trong m cây trạng thái, đồng thời duy trì kích thước bằng chứng cố định là 128 byte. Các bằng chứng này được tạo ngoài chuỗi và xác minh trên chuỗi, giúp giảm tổng gánh nặng tính toán cho Solana. ZK Compression sử dụng Groth16, một zk-SNARK dựa trên pairing nổi tiếng, cho hệ thống chứng minh của mình.

Tuy nhiên, các tài khoản này không phải là tài khoản Solana thông thường. Thay vào đó, chúng là tài khoản nén.

Mô hình tài khoản nén

Trạng thái nén ZK được lưu trong các tài khoản nén. Những tài khoản này tương tự tài khoản Solana thông thường nhưng có một số khác biệt chính giúp tăng hiệu quả và khả năng mở rộng:

• Nhận dạng bằng hàm băm — Có thể nhận dạng mỗi tài khoản nén bằng hàm băm của nó
• Hàm băm thay đổi khi ghi — Mọi thao tác ghi vào tài khoản nén đều làm thay đổi hàm băm của tài khoản
• Địa chỉ tùy chọn — Có thể tùy chọn đặt một địa chỉ làm ID duy nhất, vĩnh viễn của tài khoản nén. Điều này hữu ích cho một số trường hợp sử dụng như NFT. Trường này là tùy chọn để tránh chi phí tính toán bổ sung, vì tài khoản nén có thể được tham chiếu bằng hàm băm
• Cây trạng thái thưa — Mọi tài khoản nén được lưu trong cây Merkle, còn chỉ gốc trạng thái của cây (tức gốc Merkle) được lưu trong không gian tài khoản trên chuỗi. Cụ thể hơn, cây trạng thái là một cây Merkle đồng thời dựa trên hàm băm Poseidon

Có thể nhận dạng Địa chỉ dẫn xuất từ chương trình (PDA) đã nén bằng địa chỉ duy nhất và ổn định của chúng. Chúng có bố cục tương tự tài khoản PDA thông thường với các trường Data, Lamports, Owner và Address. Tuy nhiên, khác với PDA thông thường, trường Data chứa cấu trúc AccountData với các trường Discriminator, Data và DataHash.

Node

Nhiều loại node khác nhau đóng vai trò quan trọng trong việc hỗ trợ ZK Compression. Bất kỳ ai cũng có thể chạy node Photon RPC, node Prover hoặc node Light Forester để kết nối với Devnet và Mainnet-Beta. Đối với phát triển cục bộ, lệnh test-validator của ZK Compression CLI sẽ khởi động một cụm Solana một node với tất cả node liên quan (tức Photon RPC và Prover), cùng các chương trình hệ thống, tài khoản và tính năng runtime.

Các node Photon RPC lập chỉ mục các chương trình nén. Điều này cho phép client đọc và xây dựng giao dịch tương tác với trạng thái nén. Trình lập chỉ mục nén chính thức có tên Photon và do Helius cung cấp. Loại node này có thể chạy cục bộ với cấu hình tối thiểu và cần được trỏ đến một RPC hiện có. 

Các node Prover được dùng để tạo bằng chứng hợp lệ cho việc bao hàm trạng thái. Có thể dùng endpoint getValidityProof trong đặc tả ZK Compression RPC API để truy xuất bằng chứng. Node Prover có thể hoạt động độc lập hoặc được đóng gói cùng một RPC khác. Lưu ý rằng cách triển khai Photon RPC chính thức đã bao gồm một node Prover.

Các node Light Forester quản lý việc tạo, luân chuyển và cập nhật các cây trạng thái dùng chung cũng như thuộc sở hữu chương trình. Loại node này dành cho các nhà phát triển muốn các cây trạng thái thuộc sở hữu chương trình của riêng mình được một mạng lưới node Light Forester phục vụ.

Các giả định về độ tin cậy

Bất kỳ ai cũng có thể chạy một trong các node nói trên, đồng thời lưu trữ dữ liệu thô cần thiết để tạo bằng chứng và gửi giao dịch. Điều này đặt ra một giả định về độ tin cậy, ảnh hưởng đến khả năng hoạt động của trạng thái nén. Cụ thể, nếu dữ liệu bị mất hoặc chậm trễ, giao dịch không thể được gửi trừ khi dữ liệu được lưu trữ riêng. Vì chỉ cần một node trung thực cung cấp dữ liệu và các bằng chứng có thể tự xác minh, vấn đề nằm ở khả năng hoạt động và nguy cơ kiểm duyệt chứ không phải độ an toàn.

Ngoài ra, việc chương trình xác minh tài khoản nén hiện vẫn có thể nâng cấp tạo ra một giả định tin cậy khác. Điều này cho phép sửa đổi chương trình để khắc phục vấn đề hoặc điều chỉnh theo yêu cầu mới. Tuy nhiên, chương trình có thể được chuyển thành bất biến hoặc đóng băng trong tương lai khi đạt trạng thái ổn định và an toàn.

Một giả định khác về khả năng hoạt động là việc sử dụng các node Forester. Những node này duy trì quá trình tiến gốc trạng thái và quản lý hàng đợi nullifier bằng cách làm trống chúng rồi tiến gốc trạng thái theo cách bất đồng bộ. Tại đây, hàm băm tài khoản được thay bằng số không để vô hiệu hóa chúng. Việc tách riêng quá trình tiến và vô hiệu hóa này đảm bảo tính hoàn tất tức thì của các chuyển đổi trạng thái nén, đồng thời giữ giao dịch trong giới hạn kích thước của Solana. Vì hàng đợi nullifier có kích thước cố định, các node Forester rất cần thiết cho khả năng hoạt động của giao thức. Hàng đợi đầy sẽ gây lỗi hoạt động cho cây trạng thái liên quan. May mắn thay, các node Forester ngăn điều này bằng cách làm trống hàng đợi. Tuy nhiên, vẫn cần có người vận hành những node này để hỗ trợ tính toàn vẹn và khả năng hoạt động của giao thức. Nếu không có các node này, ZK Compression chỉ có thể hỗ trợ khoảng hai nghìn tài khoản/địa chỉ.

Hạn chế 

Ngay cả khi không cần che giấu điều gì, bằng chứng không tri thức vẫn biến những bài toán đòi hỏi nhiều bước tính toán thành bài toán chỉ cần xác minh một bằng chứng duy nhất để biết các phép tính đã được thực hiện chính xác. Những phép tính này không nhất thiết chỉ xoay quanh việc một lá cụ thể có thuộc một cây nhất định hay không — chúng có thể là bất kỳ phép tính tùy ý nào. Tuy nhiên, điều này đi kèm chi phí.

Trước khi sử dụng ZK Compression, hãy cân nhắc những điều sau:

• Kích thước giao dịch lớn hơn — ZK Compression cần 128 byte cho bằng chứng hợp lệ, cùng dữ liệu cần đọc/ghi trên chuỗi được gửi đi
• Mức sử dụng đơn vị tính toán cao hơn — ZK Compression làm tăng đáng kể mức sử dụng đơn vị tính toán (CU), vì cần ~100 nghìn CU để xác minh bằng chứng hợp lệ, ~100 nghìn CU cho hệ thống và ~6 nghìn CU cho mỗi tài khoản nén được đọc hoặc ghi
• Chi phí trạng thái trên mỗi giao dịch — Mỗi thao tác ghi phát sinh một chi phí mạng nhỏ vì phải vô hiệu hóa trạng thái tài khoản nén trước đó và thêm trạng thái nén mới vào cây trạng thái. Vì vậy, tổng chi phí trong vòng đời của một tài khoản nén hoàn toàn có thể vượt quá tài khoản không nén tương đương nếu tài khoản đó cần nhiều lần cập nhật trạng thái

Có thể nên sử dụng tài khoản thông thường nếu:

• Tài khoản được cập nhật thường xuyên
• Tổng số lần ghi vào tài khoản trong suốt vòng đời sẽ rất lớn (tức >1.000 lần)
• Tài khoản lưu trữ lượng lớn dữ liệu cần được truy cập trong các giao dịch trên chuỗi

Lợi ích

ZK Compression là một primitive có khả năng mở rộng, an toàn, hiệu quả và linh hoạt, trực tiếp giải quyết vấn đề tăng trưởng trạng thái của Solana, đồng thời hỗ trợ nhiều ứng dụng và trường hợp sử dụng. Có thể nói, ưu điểm dễ nhận thấy nhất là khả năng giảm chi phí trạng thái. ZK Compression cho phép ứng dụng dễ dàng mở rộng đến hàng triệu người dùng bằng cách lưu trữ trạng thái an toàn trong không gian sổ cái rẻ hơn, đồng thời giảm thiểu dung lượng lưu trữ trên chuỗi nhờ fingerprint trạng thái. Lấy ví dụ mint 10.000 tài khoản token và giả sử giá SOL là 130 USD, chi phí sẽ vào khoảng 2.600 USD. ZK Compression giảm con số này xuống chưa đến năm mươi xu.

ZK Compression cũng tương thích tốt với các đặc tả Solana hiện tại. Ví dụ, cấu trúc của tài khoản nén gần như giống hệt tài khoản Solana thông thường. Nó cũng hỗ trợ các cải tiến đặc thù của Solana như xử lý song song. Cụ thể, hai giao dịch bất kỳ trong cùng một cây trạng thái (tức cam kết) truy cập các tài khoản nén khác nhau đều có thể được thực thi song song. Hơn nữa, ZK Compression củng cố khả năng kết hợp nguyên tử đồng bộ. Ví dụ, một giao dịch liệt kê n tài khoản nén và m tài khoản thông thường là một cấu hình hoàn toàn hợp lệ. Một instruction tham chiếu tài khoản nén có thể gọi một instruction hoặc chương trình khác tham chiếu tài khoản thông thường. Điều này vẫn đúng ngay cả khi các tài khoản được nén trong các cây trạng thái khác nhau. Nếu một instruction thất bại, toàn bộ giao dịch sẽ được hoàn tác và các thay đổi có thể được nhìn thấy từ instruction này sang instruction tiếp theo. Điều này khác với ZK rollup, nơi các rollup không thể gọi nhau đồng bộ hoặc nguyên tử trừ khi sử dụng khóa. Đương nhiên, điều này đòi hỏi phải so sánh ZK Compression với rollup.

ZK Compression không phải là rollup

ZK Compression không phải là rollup. Dù cả hai dựa trên cùng một công nghệ, cách triển khai của chúng khác nhau. Có hai loại rollup:

• Optimistic Rollup — Mọi giao dịch được giả định là hợp lệ trong một khoảng thời gian nhất định và bằng chứng gian lận được dùng để chứng minh các giao dịch sai trong khoảng thời gian này
• Zero-Knowledge Rollup — Giao dịch được chứng minh ngay lập tức là hợp lệ hoặc không hợp lệ bằng bằng chứng hợp lệ

Toàn bộ trạng thái của một zero-knowledge rollup được biểu diễn dưới dạng một gốc duy nhất trên lớp cơ sở (tức Ethereum). Điều này đã dẫn đến nhiều tuyên bố rằng ZK Compression thực chất là một rollup. Tuy nhiên, có một số khác biệt quan trọng.

Hãy xem xét một tình huống có 500 giao dịch trên một ZK rollup. Trong trường hợp này, toàn bộ rollup được xem như một mạch duy nhất. Cả 500 giao dịch được xác minh cùng nhau, tạo ra một bằng chứng duy nhất xác nhận rằng gốc trạng thái đã thay đổi từ A sang B. Sau khi bằng chứng này được xác minh, hợp đồng thông minh quản lý tương tác giữa L1 và L2 sẽ cập nhật gốc trạng thái tương ứng. Ngược lại, với ZK Compression, mỗi giao dịch trong số 500 giao dịch tạo ra bằng chứng riêng để xác minh tính chính xác của dữ liệu tài khoản. Các giao dịch này được chính SVM thực thi và tài khoản được xem như tài khoản “thông thường” sau khi từng bằng chứng được xác thực.

Nếu phân loại ZK Compression là một rollup, điều đó đồng nghĩa mọi gốc Merkle được lưu trên Solana đều có thể được xem là rollup dựa trên tính hợp lệ. Nếu xét tất cả các gốc cNFT nén hiện có trên Solana, sẽ có khoảng 4–5 nghìn rollup dựa trên tính hợp lệ, tùy vào việc có tính các cây Merkle chưa có lượt mint nào hay không.

Vì vậy, có thể thấy rõ ZK Compression là một giải pháp độc đáo được thiết kế riêng cho kiến trúc Solana. Đây là một primitive mới, khác với ZK rollup, giúp tăng khả năng mở rộng và hiệu quả mà không mang theo sự phức tạp và phân tách của rollup.

Tương lai của ZK trên Solana và khả năng tương tác

Hiện trạng ZK trên Solana

Một trong những nhiệm vụ viết bài đầu tiên của tôi tại Helius là trình bày về bản cập nhật v1.16 của Solana. Tôi vô cùng hào hứng khi biết về khả năng hỗ trợ runtime tốt hơn cho bằng chứng không tri thức và đã đề cập đến nội dung này trong bài viết. Tuy nhiên, các cải tiến đó đã bị trì hoãn. Tôi lại mắc sai lầm khi trình bày các cải tiến này chi tiết hơn trong bài viết về bản cập nhật v1.17, nhưng chúng lại tiếp tục bị trì hoãn. Tôi thậm chí không đề cập đến chúng trong bài viết về bản cập nhật v1.18. Đương nhiên, tôi đã thất vọng và những người khác cũng bày tỏ sự bức xúc. 

Bất chấp tâm lý đó, một cộng đồng nhà phát triển ZK tuy nhỏ nhưng đang dần hình thành trên Solana. Ban đầu, Light Protocol tập trung vào thực thi chương trình riêng tư dưới dạng PSP (Private Solana Programs) trước khi chuyển trọng tâm sang ZK Compression. Dark protocol cũng là một giao thức quyền riêng tư futarchy được xây dựng trên Solana. Giao thức này không có đội ngũ trung tâm và các đóng góp được thực hiện thông qua đề xuất. Arcium, trước đây có tên Elusiv, đang sử dụng Môi trường thực thi tính toán đa bên (MXE) để vận hành mạng điện toán bảo mật song song của riêng mình. Bonsol là một "đồng xử lý" không tri thức, cho phép nhà phát triển chạy bất kỳ risc0 image nào và xác minh trên Solana (tức phép tính ngoài chuỗi có thể xác minh). Các hướng dẫn và danh sách liên kết liên quan đến bằng chứng không tri thức cũng đã được chia sẻ.

Đáng chú ý nhất, ZK Token Proof Program xác minh một số bằng chứng không tri thức được thiết kế để hoạt động với cam kết Pedersen và Mã hóa Twisted ElGamal trên curve25519. Chương trình này hỗ trợ Confidential Transfers, sử dụng bằng chứng không tri thức để mã hóa số dư và số lượng giao dịch của token SPL. Mục tiêu là tính bảo mật chứ không phải tính ẩn danh. Mã hóa đồng cấu cho phép thực hiện phép tính trên dữ liệu đã mã hóa mà không cần giải mã. Để làm điều này, Confidential Transfers sử dụng Mã hóa Twisted ElGamal cho các phép toán ẩn trên bản mã và Giao thức Sigma để xác thực các giao dịch chuyển mà không tiết lộ thông tin nhạy cảm. Chỉ chủ tài khoản có khóa giải mã mới có thể xem số dư đã mã hóa của mình. Tuy nhiên, Global Auditor System cho phép truy cập đọc có chọn lọc phục vụ tuân thủ và kiểm toán thông qua các khóa giải mã riêng. 

ZK Token Proof Program hiện là một tính năng bị chặn do SIMD-0153: ZK ElGamal Proof Program được thông qua. SIMD mới này nhằm ngừng sử dụng ZK Token Proof Program hiện tại, vốn được thiết kế riêng cho SPL Token program, và thay thế bằng một chương trình bằng chứng không tri thức tổng quát hơn, độc lập với bất kỳ ứng dụng cụ thể nào. SIMD đã được hợp nhất với sự hỗ trợ của cả Anza và đội ngũ Firedancer.

Tuy nhiên, tình thế đang bắt đầu thay đổi. Solana đang dần trở thành một thế lực ZK hùng mạnh khi những cải tiến này cuối cùng cũng được đưa lên Devnet và Mainnet-Beta. Hiện đã có ba syscall ZK hoạt động trên Solana.

Syscall Poseidon

Poseidon là một họ hàm băm được thiết kế riêng cho bằng chứng không tri thức và được sử dụng trong các dự án như Zcash, Mina và Light Protocol. Poseidon hiệu quả hơn về mặt tính toán đối với bằng chứng không tri thức so với các hàm băm truyền thống, đa dụng như SHA-256. 

Các hàm băm Poseidon thân thiện với zero-knowledge vì chúng:

• Thực hiện hiệu quả các phép toán số học
• Cần ít bước hơn để tạo bằng chứng (tức có độ phức tạp mạch thấp hơn) nhờ thiết kế thân thiện với số học, S-box được tối ưu hóa và số vòng thấp
• Sử dụng các thuật toán xử lý chuỗi bit có độ dài bất kỳ, nhờ đó cực kỳ linh hoạt

Trước đây, việc tính hàm băm Poseidon trong một giao dịch quá tốn kém. Tuy nhiên, điều này thay đổi từ epoch 644 với việc kích hoạt syscall Poseidon (tức một lời gọi hệ thống nhận đầu vào là một lát cắt byte 2D và tính hàm băm Poseidon tương ứng làm đầu ra). Đây là một bước tiến thú vị vì ZK Compression dựa vào hàm băm Poseidon cho các cây trạng thái.

Syscall Poseidon tính toán hàm băm bằng đường cong BN254 với các tham số sau:

• S-box — Hộp thay thế x5
• Đầu vào — 1 ≤ n ≤ 12
• Độ rộng — 2 ≤ t ≤ 13
• Số vòng — 8 vòng đầy đủ và số vòng từng phần tùy theo t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Đầu ra sẽ là kết quả hàm băm Posiedon được mã hóa thành 32 byte theo thứ tự byte đã chỉ định.

Lưu ý rằng biến thể cụ thể được dùng cho syscall ở đây là Poseidon với S-box x5 và các tham số được điều chỉnh cho đường cong BN254. Crate light-poseidon sẽ hỗ trợ việc tính các hàm băm này. Bản thân crate đã được kiểm toán và tương thích với Circom.

Syscall alt_bn128

alt_bn128 đề cập đến cách triển khai đường cong elliptic Barreto-Naehrig (BN-128), một đường cong thân thiện với pairing cho phép thực hiện hiệu quả các bằng chứng và phép tính zk-SNARK. Đường cong này rất quan trọng đối với nhiều hệ thống bằng chứng không tri thức, bao gồm Groth16, hệ thống mà ZK Compression dựa vào để xác thực các chuyển đổi trạng thái. Syscall này giảm đáng kể không gian cần thiết cho mỗi bằng chứng, mang lại khả năng tối ưu hóa quan trọng về không gian và thời gian cho các bằng chứng hiệu quả trên chuỗi. 

Các syscall sol_alt_bn128_group_op tính toán các phép toán trên đường cong alt_bn128, bao gồm cộng điểm trong G1 (G1 đơn giản là một nhóm điểm trên một đường cong elliptic nhất định), nhân vô hướng trong G1 và pairing:

• Đầu vào — Các điểm và vô hướng được tuần tự hóa theo định dạng big endian
• Phép toán — Cộng điểm trong G1, nhân vô hướng trong G1, pairing (1 điểm trong G1 và 1 điểm trong G2)
• Đầu ra — Các điểm trong G1 hoặc kết quả pairing được tuần tự hóa dưới dạng số nguyên 256 bit

Các syscall sol_alt_bn128_compression nén hoặc giải nén các điểm trong nhóm G1 hoặc G2 trên đường cong alt_bn128 và trả về các điểm theo định dạng big endian tiêu chuẩn.

Các syscall này hiện đang hoạt động trên testnet và dường như sẽ có mặt trên Devnet sau khi các lỗi trong giai đoạn biên dịch lại chương trình đã tải được giải quyết, theo SIMD-0075: Secp256r1 Precompile. Đề xuất này nhằm tinh giản mã lỗi cho các syscall alt_bn128 cũng như syscall Poseidon, bảo đảm tính nhất quán và giảm nguy cơ lỗi đồng thuận do các validator trả về mã lỗi khác nhau.

Các syscall alt_bn128 có thể được dùng cho cam kết vector thông thường với kích thước bằng chứng không đổi, chẳng hạn cam kết KZG. Vì vậy, chúng sẽ hoạt động với mọi đường cong thân thiện với pairing và không yêu cầu mạch ZK-prover. 

Khả năng tương tác

Solana là một chuỗi ZK. Đây là blockchain Layer 1 có hiệu năng cao, phí thấp và hỗ trợ runtime cho các phép toán đường cong elliptic. Việc triển khai và hỗ trợ các syscall liên quan đến bằng chứng không tri thức thúc đẩy đổi mới, cho phép xây dựng các primitive và ứng dụng mới như ZK Compression trên Solana.

Việc giới thiệu các syscall alt_bn128 thu hẹp khoảng cách về khả năng kết hợp giữa Solana và các hợp đồng dựa trên Solidity vốn sử dụng hợp đồng biên dịch sẵn cho các phép toán đường cong elliptic được quy định trong EIP-196, EIP-197 và EIP-198. Những phép toán này hỗ trợ xác minh bằng chứng zk-SNARK trong giới hạn gas của Ethereum. Vì vậy, các hợp đồng Solidity dựa vào những phép toán đường cong elliptic này giờ đây có thể dễ dàng chuyển sang, hoặc thậm chí tương tác với, Solana hơn.

SIMD-0075 rất quan trọng đối với các giải pháp tương tác. Sau khi được triển khai đầy đủ, SIMD này sẽ cho phép các dự án như blobsream-solana sắp ra mắt (truyền DA từ Celestia sang Solana) sử dụng việc tạo bằng chứng ngoài chuỗi và xác minh trên chuỗi để lưu trữ các cam kết Merkle. Nếu không có các syscall này, việc xác minh bằng chứng Groth16 trên Solana sẽ không thể thực hiện. Hơn nữa, các syscall này cải thiện hoạt động bridge giảm thiểu yêu cầu tin cậy và khả năng tương tác, cho phép các blockchain khác tương tác liền mạch và an toàn với Solana.  

Toly nói đúng — với tất cả những cải tiến này đối với runtime của Solana, Solana là một Ethereum L2. Chẳng bao lâu nữa, sẽ không có gì ngăn bạn gửi tất cả block của Solana vào một hợp đồng bridge xác thực dữ liệu nào đó trên Ethereum. Ngược lại, cũng sẽ không có gì ngăn bạn gửi tất cả block của Ethereum vào một chương trình bridge xác thực dữ liệu nào đó trên Solana. Khả năng tương tác hai chiều, được thúc đẩy bằng bằng chứng không tri thức thay vì các bridge lỗi thời, là một tương lai tươi sáng và đầy triển vọng cho Solana.

Kết luận

Không nghi ngờ gì nữa, bằng chứng không tri thức là một trong những primitive mạnh mẽ nhất, nếu không muốn nói là mạnh mẽ nhất, do các nhà mật mã học phát triển. Khi xem xét lý thuyết, toán học và mật mã học làm nền tảng cho khái niệm này trong bài viết đầu tiên, bắt đầu từ các nguyên lý cơ bản, điều đó trở nên hiển nhiên. Các ứng dụng tiềm năng là vô tận, từ cơ chế sương mù chiến tranh thực sự cho trò chơi trên chuỗi đến việc chứng minh một tập giao dịch trên L2 đã tạo ra một chuyển đổi trạng thái cụ thể.

Loạt bài hai phần này hoàn toàn có thể dài thêm hơn năm mươi trang, trình bày những điểm phức tạp của mã hóa đồng cấu, lập trình mạch trong Circom và phân tích các cơ chế cam kết khác nhau. Tuy nhiên, mục tiêu của các bài viết là giúp người đọc hiểu những nguyên lý cơ bản của bằng chứng không tri thức, để họ có thể dùng kiến thức mới này và áp dụng vào Solana. 

Solana đang dần trở thành một thế lực ZK hùng mạnh. Từ việc phát hành ZK Compression đến các syscall khác nhau sắp được kích hoạt, tầm quan trọng của những bước tiến này là không thể xem nhẹ. Trong khi các primitive như ZK Compression trừu tượng hóa mọi sự phức tạp của bằng chứng không tri thức cho nhà phát triển thông thường, việc hiểu các nguyên lý cơ bản vẫn vô cùng quý giá để thúc đẩy thảo luận và phát triển công nghệ này trên Solana. 

Nếu đã đọc đến đây, cảm ơn bạn, anon! Hãy nhập địa chỉ email bên dưới để không bỏ lỡ bất kỳ cập nhật nào về những điều mới trên Solana. Sẵn sàng tìm hiểu sâu hơn? Hãy khám phá các bài viết mới nhất trên blog Helius và tiếp tục hành trình Solana của bạn ngay hôm nay.

Tài nguyên bổ sung

• Giới thiệu khái quát về cách zk-SNARK có thể tồn tại của Vitalik
• POSEIDON: Hàm băm mới cho các hệ thống bằng chứng không tri thức (Phiên bản cập nhật)
• SIMD-0075: Secp256r1 Precompile
• Tìm hiểu sự khác biệt giữa zk-SNARK và zk-STARK
• Tài liệu ZK Compression