MỚI: Helius mua lại Light Protocol
Bài phát biểu chính về ZK Compression: Breakpoint 2024
Blog/Kiến thức nền tảng

Bài phát biểu chính về ZK Compression: Breakpoint 2024

Nhà nghiên cứuLostin trên X
Đọc trong 13 phút

Sau đây là phần tổng quan và những điểm chính từ bài phát biểu về ZK Compression cùng phiên hỏi đáp tại hội nghị Breakpoint 2024, do Swen Schaeferjohann, đồng sáng lập Light Protocol, và Nicolas Pennie, đồng sáng lập Helius, trình bày. Bài thuyết trình khám phá ZK Compression—là gì, hoạt động như thế nào và quan trọng nhất là tại sao công nghệ này lại thiết yếu đối với tương lai của Solana.

Tải xuống các trang trình bày.

ZK Compression: Đưa về 0

Một điều mà các nhà phát triển nhanh chóng nhận ra khi làm việc trên Solana là dù chi phí tính toán tương đối thấp, chi phí lưu trữ dữ liệu lại cao. Ví dụ, với giá SOL là 150 USD, việc tạo 1.000 tài khoản token tốn khoảng 300 USD, còn tạo một triệu tài khoản sẽ tốn 300.000 USD. Điều này khiến việc mở rộng ứng dụng cho lượng người dùng lớn trở nên quá tốn kém, vì các chi phí này tăng theo giá SOL. Ngoài ra, sự tăng trưởng trạng thái là thách thức mà mọi blockchain có trạng thái đều phải đối mặt. Khi các tài khoản mới được tạo, cần trả phí thuê để duy trì chúng, gây ra chi phí đáng kể. Hiện tại, Solana có hơn 500 triệu tài khoản và mỗi ngày có thêm khoảng một triệu tài khoản mới.

ZK Compression giải quyết các vấn đề này bằng cách cung cấp:

  • Tài khoản rẻ hơn một nghìn lần
  • Giải pháp cho sự tăng trưởng trạng thái
  • Nền tảng cho tính toán ZK trên Solana

Nén trạng thái + ZK

Để hiểu ZK Compression, trước tiên hãy phân tích cơ chế nén trạng thái, xoay quanh năm giai đoạn chính:

  1. Hàng triệu tài khoản → “dấu vân tay”
  2. Lưu dấu vân tay trên chuỗi
  3. Lưu lịch sử tài khoản trên sổ cái Solana
  4. Lưu trạng thái tài khoản mới nhất vào bộ nhớ đệm bằng trình lập chỉ mục
  5. Xác minh trạng thái tài khoản đã nén qua “dấu vân tay” trên chuỗi

Chúng ta bắt đầu bằng cách nén hàng triệu tài khoản Solana và băm chúng thành một "dấu vân tay" nhỏ gọn. Dấu vân tay này được lưu trong một tài khoản trên chuỗi, trong khi toàn bộ dữ liệu tài khoản nền vẫn có thể truy cập trên sổ cái của Solana. Để đảm bảo tính hợp lệ của các tài khoản ngoài chuỗi này, chúng ta sử dụng một cơ chế chứng minh để xác minh tính toàn vẹn của chúng bằng dấu vân tay trên chuỗi. Bước cuối cùng của quy trình sử dụng SNARK không kiến thức, nền tảng của hệ thống bằng chứng chịu trách nhiệm xác minh tính toàn vẹn của các tài khoản này.

Tại sao nên dùng ZK Compression?

Một số tính năng chính khiến ZK Compression trở thành giải pháp lý tưởng cho việc nén trạng thái. Chẳng hạn, tài khoản đã nén hoạt động tương tự tài khoản Solana tiêu chuẩn, cho phép nhà phát triển tận dụng các kỹ năng và kỹ thuật phát triển hiện có mà không cần học quá nhiều kiến thức mới. Điều này hạ thấp rào cản gia nhập và giúp nhà phát triển dễ dàng áp dụng ZK Compression.

‍API do trình lập chỉ mục cung cấp gần như tương ứng hoàn toàn với các lệnh gọi RPC hiện có. Chẳng hạn, phương thức getAccountInfo ánh xạ trực tiếp đến getCompressedAccount, và ánh xạ một-một này áp dụng cho toàn bộ API RPC. Tính nhất quán này giúp đơn giản hóa việc tích hợp ZK Compression với các công cụ và quy trình làm việc Solana hiện có.

PDA đã nén

Một tính năng quan trọng của hệ thống này là hỗ trợ địa chỉ do chương trình tạo (PDA) đã nén. PDA là các địa chỉ tài khoản xác định, có thể được suy ra một cách nhất quán bằng địa chỉ chương trình và seed cụ thể. PDA đã nén giúp loại bỏ các vấn đề như điều kiện tranh chấp, xung đột địa chỉ hoặc vô tình tạo nhiều tài khoản cho cùng một tổ hợp địa chỉ chương trình và seed. Cải tiến này là một lý do quan trọng để chuyển từ hệ thống nén tài khoản SPL hiện có sang ZK Compression.

‍Với khả năng hỗ trợ đầy đủ ZK Compression, tác động tiềm năng đối với Solana là rất lớn. PDA và khả năng kết hợp các chương trình với nhau cho phép tạo ra những kiến trúc phức tạp hơn, gồm nhiều chương trình và các PDA khác nhau—tương tự trải nghiệm phát triển quen thuộc khi xây dựng ứng dụng truyền thống. Điều này có thể đạt được với chi phí chỉ bằng một phần nhỏ, giảm chi phí tài khoản tới một nghìn lần. Mức giảm chi phí đáng kể này sẽ mở ra những trường hợp sử dụng mới vốn không thể tiếp cận trước đây vì chi phí quá cao.

Cải thiện khả năng kết hợp

Mọi thứ đều chạy trực tiếp trên Solana—đây không phải L2 hay validium. Khả năng sẵn có của dữ liệu được sổ cái Solana tự động cung cấp, đảm bảo quá trình thực thi có thể xác minh và kết hợp hoàn toàn.

‍Bằng chứng không kiến thức giảm kích thước bằng chứng xuống mức cố định 128 byte, giải phóng thêm không gian trong mỗi giao dịch cho các hoạt động khác, nhờ đó giúp việc kết hợp dễ dàng hơn và tạo thêm sự linh hoạt cho các hoạt động bổ sung. Kích thước bằng chứng không đổi bất kể có bao nhiêu tài khoản được cập nhật, đọc hoặc ghi trong một giao dịch, hay cần chứng minh bao nhiêu trường hợp thuộc hoặc không thuộc. Điều này rất quan trọng vì kích thước giao dịch của Solana vốn nhỏ (1,2 kilobyte). Cần một hàm băm khác cho cây Merkle trạng thái để đạt thời gian tạo bằng chứng nhanh, đó là lý do chúng ta không thể sử dụng chương trình nén tài khoản SPL ban đầu.

Giải nén

Một tính năng quan trọng khác là giải nén, giúp tránh bị phụ thuộc và cho phép khả năng tương tác liền mạch giữa tài khoản “thông thường” và tài khoản đã nén. Mọi tài khoản Solana đều có thể được nén, cho phép bạn thu hồi chi phí thuê. Bạn cũng có thể giải nén tài khoản đã nén bất kỳ lúc nào, giúp dễ dàng chuyển đổi giữa hai dạng. Ví dụ, nếu có một token đã nén cần hoán đổi, bạn chỉ cần giải nén rồi sử dụng token đó với Jupiter để thực hiện giao dịch hoán đổi.

Giải nén cho phép chuyển đổi liền mạch giữa trạng thái nóng và trạng thái lạnh. Chẳng hạn, nếu đang phát triển một trò chơi có nhiều thẻ và vật phẩm đã nén, bạn có thể giải nén chúng trong trận chiến để cho phép thay đổi trạng thái nhanh, sau đó nén lại để lưu kết quả cuối cùng, chẳng hạn như thay đổi về điểm sinh lực. Có một số hạn chế về khả năng xử lý đồng thời trong một cây duy nhất ở cùng một slot. Nên tránh nén nếu cần cập nhật cùng một tài khoản nhiều lần trong một block. Trong trường hợp đó, tốt hơn hết là giải nén vĩnh viễn tài khoản cụ thể ấy để tài khoản hoạt động như một tài khoản trên chuỗi thông thường. Ví dụ, tài khoản pool AMM sẽ phù hợp hơn với dạng này vì trạng thái của nó cần được cập nhật thường xuyên. Hệ thống đủ linh hoạt để tương tác với cả tài khoản đã nén và đã giải nén trong cùng một giao dịch.

Giải pháp tổng quát hoàn toàn này không bị giới hạn ở một chương trình, logic nghiệp vụ hay ứng dụng duy nhất. Tài khoản Solana có thể được nén với chi phí thấp và được tích hợp sẵn khả năng lập chỉ mục. Giải pháp hoàn toàn mã nguồn mở, sẵn sàng cho môi trường sản xuất và có thể thích ứng với nhiều trường hợp sử dụng.

Token đã nén

Token đã nén không tương thích trực tiếp với các sàn giao dịch và nền tảng DeFi trừ khi được những nền tảng đó hỗ trợ. Tuy nhiên, vấn đề này có thể dễ dàng được giải quyết bằng cách giải nén token đã nén thành token SPL tiêu chuẩn, sau đó có thể sử dụng trong DeFi và trên các sàn giao dịch như mọi token thông thường. Tính linh hoạt này đảm bảo không bị phụ thuộc và người dùng có thể chuyển đổi giữa token đã nén và token thông thường khi cần. Token đã nén phù hợp với các ứng dụng lạnh ít cần tương tác, còn tài khoản token thông thường phù hợp hơn với trạng thái nóng hoặc tài sản được sử dụng thường xuyên. Một trong những lợi thế chính của hệ thống này là khả năng giải quyết vấn đề tăng trưởng trạng thái bằng cách chuyển dữ liệu trạng thái lạnh sang bộ nhớ nén, duy trì mọi lợi ích trong khi quản lý trạng thái hiệu quả hơn.‍

‍Trong bản phát hành đầu tiên, chúng tôi giới thiệu các token đã nén được xây dựng bằng chính những công cụ bạn sẽ sử dụng cho mọi ứng dụng hỗ trợ nén. Chương trình token đã nén giống hệt chương trình token Solana, mang lại cùng trải nghiệm người dùng với chi phí thấp hơn một nghìn lần. Các tiện ích mở rộng token dự kiến sẽ hoạt động vào đầu năm 2025.

Với các tính năng như giải nén, bạn có thể airdrop lượng lớn token và nhanh chóng giải nén chúng khi cần cho các hoạt động DeFi. Mặc dù bằng chứng không kiến thức (ZK) thường được xem là Chén Thánh của các phép tính tốn kém, chúng tôi đã tối ưu hóa quy trình để các giao dịch chuyển tương tự giao dịch chuyển token SPL tiêu chuẩn, giảm thời gian tạo bằng chứng xuống còn vài mili giây. Điều này đưa ZK cấp độ sản xuất dành cho người tiêu dùng lên hàng đầu, đồng thời giảm đáng kể chi phí quản lý tài khoản token.

ZK Compression hoạt động như thế nào?

Toàn bộ hệ thống có năm thành phần chính: 

  • Một rừng cây trạng thái
  • Light System Program
  • Compressed Token Program
  • Nút Forester
  • Trình lập chỉ mục (Photon)

Một rừng cây trạng thái

Đầu tiên là các cây Merkle trạng thái mà chúng tôi gọi là “rừng cây Merkle trạng thái”. Cấu trúc này tạo ra một dấu vân tay mật mã duy nhất cho một tập hợp tài khoản để chúng ta có thể lưu trên chuỗi. Ví dụ, nếu có bốn tài khoản, bạn có thể băm đệ quy chúng thành một cấu trúc cây Merkle.

Giá trị băm 32 byte cuối cùng ở đỉnh cung cấp sự đảm bảo bằng mật mã về tính toàn vẹn của dữ liệu nền cho tất cả tài khoản. Điều này đảm bảo có thể dễ dàng xác minh trạng thái của bất kỳ tài khoản nào như một phần của cây Merkle bằng cách so sánh với gốc trạng thái. Chúng tôi dùng thuật ngữ "rừng" ở đây vì có nhiều cây Merkle, mỗi cây có một gốc riêng.

So sánh với cơ chế nén tài khoản SPL hiện có

Một cải tiến lớn của ZK Compression so với chương trình nén tài khoản SPL hiện có là khả năng chứng minh rằng một phần trạng thái thuộc một cây Merkle nhất định, qua đó đảm bảo tạo bằng chứng hiệu quả trong giới hạn kích thước giao dịch của Solana. Điều này cho phép chúng ta chứng minh tính duy nhất của một địa chỉ nhất định bằng cách quản lý cây địa chỉ, tương tự cây Merkle trạng thái nhưng có thêm một tính năng: chứng minh một phần tử nằm trong lá cũng đồng thời chứng minh một khoảng số cụ thể không thuộc cây. Nhờ đó, hệ thống có thể xử lý không gian địa chỉ 248 bit bằng các cây Merkle nhỏ hơn nhiều, đồng thời đảm bảo tính duy nhất của địa chỉ.

Có thể chứng minh M tài khoản trên N cây trong khi duy trì kích thước bằng chứng cố định 128 byte, nhờ đó phù hợp với giới hạn kích thước giao dịch 1,2kb của Solana. Việc tạo bằng chứng diễn ra ngoài chuỗi và tốn kém hơn so với chương trình nén tài khoản SPL hiện có. Tuy nhiên, việc xác minh bằng chứng diễn ra trên chuỗi vẫn có chi phí cố định và trong hầu hết trường hợp thường rẻ hơn chương trình nén hiện có.

Light System Program và Compressed Token Program

Giao thức gồm hai chương trình chính. Light System Program là một hợp đồng trên chuỗi mô phỏng Solana System Program. Chương trình tương tác với cây Merkle, thực thi mô hình tài khoản Solana tiêu chuẩn và xác minh tính duy nhất của PDA. Compressed Token Program mô phỏng chương trình token SPL, thực thi bố cục dữ liệu SPL trong mô hình tài khoản đã nén.

Nút Forester

Các nút Forester chịu trách nhiệm quản lý khu rừng nhẹ này. Khi bạn cập nhật một tài khoản đã nén, trạng thái tài khoản mới được thêm vào cây, còn trạng thái cũ được đặt về 0 hoặc vô hiệu hóa.

Cách tiếp cận này có hai hệ quả chính. Thứ nhất, mọi cập nhật trạng thái đều làm thay đổi gốc khi các sửa đổi lan truyền lên đỉnh cây Merkle đảo ngược. Thứ hai, các cây dần đầy và cuối cùng đạt giới hạn dung lượng, lúc này rừng cây nhẹ phát huy vai trò.

Các nút Forester chịu trách nhiệm duy trì gốc trạng thái. Chúng cập nhật gốc trạng thái theo cách bất đồng bộ và xử lý việc chuyển tiếp khi cây trạng thái đầy. Việc vận hành nút Forester cho các cây trạng thái của riêng bạn không cần cấp quyền và hoạt động tương tự như chạy RPC, cho phép bất kỳ ai quản lý các bản cập nhật trạng thái của mình. Là nhà phát triển ứng dụng, bạn có lợi ích trực tiếp trong việc duy trì trạng thái đã nén, tạo ra động lực tự nhiên để đảm bảo các cây trạng thái được quản lý đúng cách. Bạn có thể tự chạy nút để tự lưu trữ hoặc trả phí cho nhà cung cấp xử lý việc này.

Photon

Trình lập chỉ mục Photon là một giải pháp mã nguồn mở được thiết kế để theo dõi và quản lý các bản cập nhật, hoạt động tạo mới, thay đổi và các sự kiện khác liên quan đến tài khoản đã nén trên blockchain. Photon lắng nghe hoạt động trên chuỗi và lưu trạng thái hiện tại của các tài khoản này vào bộ nhớ đệm. Ngoài ra, Photon còn tạo các bằng chứng mật mã có thể dùng để xác minh hoặc thay đổi dữ liệu.

‍Trình lập chỉ mục Photon sẵn sàng cho môi trường sản xuất tích hợp những cải tiến đáng kể dựa trên thông tin chuyên sâu thu được từ các phiên bản nén trước đó. Mục tiêu là trở nên thân thiện và dễ tiếp cận, dù bạn là nhà phát triển cá nhân, doanh nghiệp hay nhà cung cấp RPC.

Quá trình phát triển cục bộ đã trở nên đơn giản hơn đáng kể. Photon cung cấp công cụ CLI một cú nhấp, tích hợp liền mạch với môi trường cục bộ của bạn. Ngoài ra còn có một trình khám phá dành cho nhà phát triển, cung cấp giao diện trực quan để xem các tài khoản đã nén, theo dõi thay đổi và kiểm tra lịch sử giao dịch.

Photon tạo ảnh chụp nhanh hằng ngày, giúp tăng tốc quá trình phát triển và triển khai. Thay vì lập chỉ mục lại từ block khởi nguyên, nhà phát triển có thể bắt đầu từ một ảnh chụp nhanh, giảm thời gian khởi động xuống còn 15 phút hoặc ít hơn. Các ảnh chụp nhanh này cũng cải thiện khả năng sao chép, đảm bảo rằng nếu một nhà cung cấp RPC ngừng hỗ trợ nén, bạn có thể dễ dàng lấy ảnh chụp nhanh và tự vận hành trình lập chỉ mục. Nguy cơ mất dữ liệu được giảm thiểu nhờ các ảnh chụp nhanh, vốn có thể được lưu trữ trong các giải pháp phi tập trung như FileCoin.

Với Photon, bạn có thể linh hoạt chỉ lập chỉ mục một tập con dữ liệu, giúp giảm đáng kể yêu cầu phần cứng và kích thước cơ sở dữ liệu. Có thể thực hiện việc này bằng SQLite chỉ với một lệnh CLI duy nhất. Ngoài ra, nếu là nhà cung cấp RPC, bạn có thể chọn lập chỉ mục toàn bộ tập dữ liệu. Photon có sẵn trong mọi gói Helius; bạn cũng có thể tự vận hành hoặc yêu cầu một nhà cung cấp khác cung cấp dịch vụ này.

Do nhà phát triển xây dựng, dành cho nhà phát triển

Chúng tôi hoàn toàn tập trung vào nhà phát triển và đang tích cực triển khai ba cải tiến lớn được thiết kế riêng để nâng cao trải nghiệm phát triển.

Web3.js dành cho cơ chế nén

SDK được thiết kế để hoạt động tương tự Solana web3.js nhưng hỗ trợ đầy đủ cơ chế nén. Để bắt đầu chuyển token đã nén, trước tiên bạn tìm nạp các tài khoản token đã nén, sau đó dùng các tài khoản đó để lấy bằng chứng hợp lệ từ RPC hoặc nút chứng minh chuyên dụng. Tiếp theo, bạn xây dựng các chỉ thị giống như với chương trình token SPL, chỉ định nội dung muốn gửi, số lượng, mint và người nhận—qua đó tạo một giao dịch Solana thông thường.

‍Môi trường phát triển cục bộ đầy đủ

Chúng tôi cung cấp một trình xác thực thử nghiệm được cấu hình sẵn với mọi thành phần cần thiết cho quá trình phát triển cục bộ, bao gồm tất cả chương trình bắt buộc, trình lập chỉ mục Photon và một nút chứng minh cục bộ. Điều này đảm bảo quy trình thiết lập được tinh gọn cho nhà phát triển.

Macro Anchor

Với những người đã quen phát triển chương trình Solana bằng Anchor, mục tiêu của chúng tôi là giúp làm việc với tài khoản đã nén liền mạch như với tài khoản thông thường. Nếu từng viết chương trình Anchor, bạn sẽ ngay lập tức nhận ra trải nghiệm phát triển quen thuộc. Macro Anchor hiện vẫn đang được phát triển.

Airship

Airship cho phép nhà phát triển tận dụng ZK Compression ngay hôm nay bằng công cụ airdrop token hàng loạt vừa dễ dùng vừa tiết kiệm chi phí. Công cụ cung cấp cả giao diện người dùng và CLI. Vì hoàn toàn là mã nguồn mở, nhà phát triển có thể fork và sửa đổi cho phù hợp với nhu cầu. Khi có thêm nhiều nhà phát triển airdrop token đã nén, hệ sinh thái sẽ bắt đầu áp dụng chúng trên nhiều ứng dụng. Tuy nhiên, nếu muốn chuyển đổi ngay lập tức, nhà phát triển có thể giải nén token ngay, đảm bảo Airship là công cụ airdrop sẵn sàng sử dụng cho token thông thường ngay hôm nay.

‍Công cụ tự động hỗ trợ airdrop cho người sở hữu Solana mobile, người sở hữu token cụ thể hoặc người sở hữu bộ sưu tập NFT. Nếu có danh sách người nhận được tạo sẵn, bạn cũng có thể nhập tệp CSV rồi chỉ định token và số lượng cần airdrop. Cả CLI và giao diện người dùng đều cho phép tiếp tục đợt airdrop từ trạng thái được lưu gần nhất nếu gặp vấn đề như mất kết nối Internet. Tính năng này đặc biệt hữu ích với các đợt airdrop lớn, có thể mất từ 30 đến 45 phút khi phân phối token cho một danh sách dài các địa chỉ.

Không gian thiết kế mới cho ứng dụng

ZK Compression giải quyết vấn đề tăng trưởng trạng thái bằng cách chỉ lưu giá trị băm gốc cuối cùng của tất cả tài khoản trong bộ nhớ của trình xác thực đang hoạt động. Cách tiếp cận này giảm thiểu hiệu quả các vấn đề về tăng trưởng trạng thái. Hơn nữa, ZK Compression mở ra những khả năng thiết kế ứng dụng mới. Sau đây chỉ là một vài trường hợp sử dụng tiềm năng:

  • Trình nén token SPL
  • Một tỷ meme coin
  • Thị trường dự đoán cho các bài đăng trên Twitter
  • PDA định danh cho các nút trong mạng DePin
  • Tính toán và phân phối phần thưởng có thể xác minh
  • Cầu nối giảm thiểu yêu cầu đặt niềm tin
  • Giao thức danh tính ZK

Tài liệu còn cung cấp thêm nhiều ý tưởng.

ZK Compression hiện đã hoạt động trên mainnet và devnet! Bạn có thể bắt đầu bằng cách đọc tài liệu và thực hành theo các ví dụ. Ngoài ra, chúng tôi đang tổ chức một hackathon với tổng giải thưởng lên tới 45.000 USD.

Nếu muốn tìm hiểu sâu hơn về ZK, hãy xem các bài viết trước đây trên blog Helius để khám phá chuyên sâu các nguyên lý cơ bản của bằng chứng không kiến thức và ứng dụng của chúng trên Solana.

‍

Đăng ký nhận tin từ Helius

Luôn cập nhật những thông tin mới nhất về phát triển Solana và nhận thông báo khi chúng tôi đăng bài

Hình ảnh phóng to