Kernel Ventures: Phân tích thiết kế lớp dữ liệu lịch sử và DA trong một bài viết
Tuyển chọn TechFlowTuyển chọn TechFlow
Kernel Ventures: Phân tích thiết kế lớp dữ liệu lịch sử và DA trong một bài viết
Khả năng của blockchain ngày càng trở nên phức tạp, dẫn đến nhu cầu không gian lưu trữ lớn hơn.
Chuyên sâu báo cáo Web3Tác giả: Jerry Luo – Kernel Ventures
Tóm tắt ngắn gọn (TL;DR)
-
Các blockchain giai đoạn đầu yêu cầu tất cả các nút trong mạng duy trì tính nhất quán dữ liệu để đảm bảo an toàn và phi tập trung. Tuy nhiên, khi hệ sinh thái blockchain phát triển, áp lực lưu trữ ngày càng tăng, dẫn đến xu hướng tập trung hóa trong vận hành nút. Hiện tại, Layer1 cấp thiết cần giải quyết vấn đề chi phí lưu trữ do sự gia tăng TPS gây ra.
-
Đối mặt với vấn đề này, các nhà phát triển cần đưa ra phương án lưu trữ dữ liệu lịch sử mới, cân nhắc đồng thời yếu tố an toàn, chi phí lưu trữ, tốc độ đọc dữ liệu và tính phổ quát của tầng DA.
-
Trong quá trình giải quyết vấn đề, nhiều công nghệ và ý tưởng mới đã xuất hiện, bao gồm Sharding, DAS, Cây Verkle, thành phần trung gian DA,... Các công nghệ này cố gắng tối ưu hóa phương án lưu trữ ở tầng DA bằng cách giảm dư thừa dữ liệu và nâng cao hiệu quả kiểm tra dữ liệu.
-
Hiện tại, các phương án DA được chia làm hai loại chính dựa trên vị trí lưu trữ dữ liệu: DA trên chuỗi chính và DA bên thứ ba. DA trên chuỗi chính giảm tải cho nút bằng cách định kỳ dọn dẹp dữ liệu hoặc chia nhỏ dữ liệu để lưu trữ. Trong khi đó, các giải pháp DA bên thứ ba được thiết kế chuyên biệt cho dịch vụ lưu trữ, có giải pháp hợp lý cho lượng dữ liệu lớn, do đó chủ yếu phải đánh đổi giữa khả năng tương thích đơn chuỗi và đa chuỗi, từ đó hình thành ba giải pháp: DA dành riêng cho chuỗi chính, DA mô-đun, và DA trên chuỗi lưu trữ.
-
Các blockchain thanh toán yêu cầu rất cao về an toàn dữ liệu lịch sử, phù hợp dùng chuỗi chính làm tầng DA. Tuy nhiên, đối với các blockchain hoạt động lâu dài với lượng lớn thợ đào, việc sử dụng DA bên thứ ba không ảnh hưởng đến tầng đồng thuận nhưng vẫn đảm bảo an toàn sẽ phù hợp hơn. Blockchain tổng hợp phù hợp hơn với DA dành riêng cho chuỗi chính — dung lượng dữ liệu lớn hơn, chi phí thấp hơn và vẫn đảm bảo an toàn. Tuy nhiên, nếu xét đến nhu cầu liên chuỗi, DA mô-đun cũng là lựa chọn tốt.
-
Nhìn chung, blockchain đang phát triển theo hướng giảm dư thừa dữ liệu và phân công chức năng giữa nhiều chuỗi.
1. Bối cảnh
Blockchain như một sổ cái phân tán, cần lưu trữ bản sao dữ liệu lịch sử tại mọi nút để đảm bảo an toàn và mức độ phi tập trung cao. Vì tính đúng đắn của mỗi thay đổi trạng thái đều phụ thuộc vào trạng thái trước đó (nguồn gốc giao dịch), để đảm bảo tính xác thực của giao dịch, về nguyên tắc một blockchain nên lưu trữ toàn bộ lịch sử từ giao dịch đầu tiên đến hiện tại. Ví dụ với Ethereum, ngay cả khi ước tính trung bình mỗi khối chỉ 20 KB, tổng kích thước khối hiện tại đã đạt 370 GB. Ngoài khối, một nút đầy đủ còn phải lưu trữ trạng thái và biên lai giao dịch. Khi tính thêm phần này, dung lượng lưu trữ của một nút đã vượt quá 1 TB, điều này khiến việc vận hành nút dần tập trung vào một nhóm nhỏ người.
Chiều cao khối mới nhất của Ethereum, nguồn ảnh: Etherscan
2. Chỉ số hiệu suất của DA
2.1 An toàn
So với cơ sở dữ liệu hay cấu trúc danh sách liên kết, tính bất biến của blockchain đến từ khả năng kiểm tra dữ liệu mới bằng dữ liệu lịch sử, do đó đảm bảo an toàn dữ liệu lịch sử là yếu tố hàng đầu cần xem xét trong lưu trữ tầng DA. Để đánh giá an toàn dữ liệu hệ thống blockchain, ta thường phân tích dựa trên số lượng dư thừa dữ liệu và phương thức kiểm tra tính sẵn sàng dữ liệu.
-
Số lượng dư thừa: Dư thừa dữ liệu trong hệ thống blockchain đóng vai trò quan trọng. Trước hết, khi mạng có càng nhiều bản sao, các trình xác thực khi cần kiểm tra trạng thái tài khoản trong một khối lịch sử nào đó để xác minh giao dịch hiện tại sẽ có nhiều mẫu tham khảo hơn, từ đó chọn ra dữ liệu được ghi nhận bởi đa số nút. Trái lại, trong cơ sở dữ liệu truyền thống, dữ liệu chỉ được lưu dạng cặp khóa-giá trị tại một nút, việc sửa đổi dữ liệu lịch sử chỉ cần thao tác tại nút đó, chi phí tấn công cực thấp. Về lý thuyết, số lượng dư thừa càng lớn thì độ tin cậy dữ liệu càng cao. Đồng thời, càng nhiều nút lưu trữ thì dữ liệu càng khó bị mất. Điều này có thể so sánh với máy chủ trung tâm của Web2, nếu toàn bộ máy chủ ngừng hoạt động, trò chơi sẽ đóng cửa hoàn toàn. Tuy nhiên, số lượng này không phải càng nhiều càng tốt vì mỗi bản sao đều tiêu tốn thêm không gian lưu trữ. Dư thừa dữ liệu quá mức sẽ tạo áp lực lớn lên hệ thống. Một tầng DA tốt cần tìm cách cân bằng giữa an toàn và hiệu quả lưu trữ.
-
Kiểm tra tính sẵn sàng dữ liệu: Số lượng dư thừa đảm bảo việc ghi nhận dữ liệu đầy đủ trong mạng, nhưng dữ liệu cần sử dụng vẫn phải được kiểm tra tính chính xác và toàn vẹn. Hiện nay, blockchain thường dùng thuật toán cam kết mật mã học: giữ lại một "cam kết mật mã" rất nhỏ để toàn mạng ghi nhận, cam kết này được tạo từ dữ liệu giao dịch. Khi kiểm tra tính xác thực của dữ liệu lịch sử, cần khôi phục lại cam kết mật mã từ dữ liệu đó rồi so sánh với bản ghi toàn mạng. Nếu trùng khớp thì xác thực thành công. Các thuật toán kiểm tra phổ biến gồm Merkle Root và Verkle Root. Thuật toán kiểm tra an toàn cao chỉ cần lượng dữ liệu kiểm tra nhỏ và có thể xác minh nhanh chóng.
2.2 Chi phí lưu trữ
Sau khi đảm bảo an toàn cơ bản, mục tiêu tiếp theo của tầng DA là giảm chi phí và tăng hiệu quả — cụ thể là giảm chi phí lưu trữ, tức là giảm dung lượng bộ nhớ chiếm dụng cho mỗi đơn vị dữ liệu (không tính khác biệt phần cứng). Cách phổ biến hiện nay là dùng kỹ thuật sharding và lưu trữ theo cơ chế thưởng để giảm số bản sao dữ liệu mà vẫn đảm bảo lưu trữ hiệu quả. Tuy nhiên, rõ ràng tồn tại sự đánh đổi giữa chi phí lưu trữ và an toàn dữ liệu: giảm dung lượng lưu trữ thường đi kèm giảm an toàn. Do đó, một tầng DA tốt cần cân bằng giữa chi phí và an toàn. Ngoài ra, nếu tầng DA là một blockchain riêng biệt, cần giảm thiểu các bước trung gian trong quá trình trao đổi dữ liệu để tiết kiệm chi phí. Mỗi lần chuyển tiếp đều để lại dữ liệu chỉ mục phục vụ truy vấn sau này, nên quy trình càng dài thì dữ liệu chỉ mục càng nhiều, làm tăng chi phí lưu trữ. Cuối cùng, chi phí lưu trữ gắn trực tiếp với độ bền dữ liệu: nói chung, chi phí lưu trữ càng cao thì blockchain càng khó duy trì lưu trữ lâu dài.
2.3 Tốc độ đọc dữ liệu
Sau khi giảm chi phí, bước tiếp theo là tăng hiệu quả — tức là khả năng nhanh chóng lấy dữ liệu từ tầng DA khi cần. Quá trình này gồm hai bước: đầu tiên là tìm nút lưu trữ dữ liệu, bước này chủ yếu dành cho các blockchain chưa đạt nhất quán dữ liệu toàn mạng; nếu dữ liệu đã đồng bộ trên mọi nút thì có thể bỏ qua bước này. Thứ hai, các hệ thống blockchain hiện đại như Bitcoin, Ethereum, Filecoin đều dùng cơ sở dữ liệu LevelDB để lưu trữ tại nút. Trong LevelDB, dữ liệu được lưu theo ba cách: dữ liệu ghi tức thời lưu trong file kiểu Memtable; khi Memtable đầy sẽ chuyển sang Immutable Memtable. Hai loại file này đều nằm trong bộ nhớ RAM, nhưng Immutable Memtable chỉ đọc được, không sửa được. Lưu trữ nóng (hot storage) trên mạng IPFS lưu dữ liệu ở đây để truy cập nhanh từ RAM, nhưng bộ nhớ RAM di động thông thường chỉ vài GB, dễ nhanh đầy, và dữ liệu trong RAM sẽ mất vĩnh viễn nếu nút gặp sự cố như sập nguồn. Muốn lưu trữ lâu dài, dữ liệu phải lưu dưới dạng file SST trên ổ SSD, nhưng khi đọc phải tải vào RAM trước, làm chậm đáng kể tốc độ truy xuất. Cuối cùng, với hệ thống dùng sharding, việc khôi phục dữ liệu cần gửi yêu cầu tới nhiều nút và khôi phục, quá trình này cũng làm chậm tốc độ đọc.
Cách lưu trữ dữ liệu LevelDB, nguồn ảnh: Leveldb-handbook
2.4 Tính phổ quát của tầng DA
Khi DeFi phát triển và CEX bộc lộ nhiều vấn đề, nhu cầu giao dịch tài sản liên chuỗi phi tập trung của người dùng ngày càng tăng. Dù dùng cơ chế khóa băm, bên chứng thực hay cầu nối (relay chain), việc xác định dữ liệu lịch sử trên cả hai chuỗi là điều không thể tránh khỏi. Vấn đề then chốt là dữ liệu hai chuỗi bị tách rời, các hệ thống phi tập trung khác nhau không thể giao tiếp trực tiếp. Do đó, hiện nay có giải pháp thay đổi cách lưu trữ tầng DA: lưu trữ dữ liệu lịch sử của nhiều blockchain lên một chuỗi đáng tin cậy duy nhất, khi xác minh chỉ cần truy xuất dữ liệu từ chuỗi này. Điều này đòi hỏi tầng DA phải thiết lập kênh giao tiếp an toàn với các loại blockchain khác nhau — tức là tầng DA phải có tính phổ quát cao.
3. Khám phá công nghệ liên quan đến DA
3.1 Sharding
-
Trong các hệ thống phân tán truyền thống, một tệp không được lưu nguyên vẹn tại một nút, mà được chia thành nhiều khối (blocks), mỗi nút lưu một khối. Mỗi khối thường không chỉ lưu tại một nút, mà còn có bản sao tại các nút khác — trong các hệ thống phân tán phổ biến hiện nay, số bản sao thường là 2. Cơ chế Sharding này giảm áp lực lưu trữ từng nút, mở rộng tổng dung lượng hệ thống thành tổng dung lượng lưu trữ của các nút, đồng thời đảm bảo an toàn nhờ dư thừa dữ liệu vừa phải. Phương án Sharding trong blockchain về cơ bản tương tự, nhưng có khác biệt chi tiết. Thứ nhất, do các nút trong blockchain mặc định không tin tưởng lẫn nhau, khi triển khai Sharding cần số lượng bản sao đủ lớn để sau này xác minh tính xác thực dữ liệu, nên số bản sao phải lớn hơn nhiều so với 2. Trong trường hợp lý tưởng, nếu tổng số nút xác thực là T và số mảnh là N, thì số bản sao nên là T/N. Thứ hai, về quá trình lưu trữ khối: hệ thống phân tán truyền thống có ít nút nên thường một nút lưu nhiều khối dữ liệu, dùng thuật toán băm nhất quán để ánh xạ dữ liệu lên vòng băm, mỗi nút lưu các khối trong một phạm vi nhất định, và chấp nhận có thể một nút không được giao nhiệm vụ lưu trữ trong một lần. Trong khi đó, blockchain đảm bảo mỗi nút chắc chắn được giao một khối để lưu trữ — mỗi nút chọn ngẫu nhiên một khối lưu trữ, quá trình này thực hiện bằng cách lấy băm của dữ liệu khối gốc kết hợp thông tin nút, rồi lấy dư cho số mảnh. Giả sử dữ liệu chia thành N khối, dung lượng lưu trữ thực tế mỗi nút chỉ còn 1/N. Bằng cách đặt N phù hợp, có thể cân bằng giữa TPS tăng trưởng và áp lực lưu trữ nút.
Cách lưu trữ dữ liệu sau Sharding, nguồn ảnh: Kernel Ventures
3.2 DAS (Mẫu Kiểm Tra Tính Sẵn Có Dữ Liệu - Data Availability Sampling)
DAS là bước tối ưu tiếp theo của Sharding về phương thức lưu trữ. Trong quá trình Sharding, do các nút lưu trữ ngẫu nhiên đơn giản, có thể xảy ra trường hợp một khối bị mất. Hơn nữa, khi khôi phục dữ liệu sau chia mảnh, việc xác nhận tính xác thực và toàn vẹn dữ liệu cũng rất quan trọng. DAS giải quyết hai vấn đề này bằng mã Erasure và cam kết đa thức KZG.
-
Mã Erasure: Với số lượng lớn nút xác thực Ethereum, xác suất một khối không được bất kỳ nút nào lưu trữ gần như bằng 0, nhưng về mặt lý thuyết vẫn có thể xảy ra. Để giảm mối đe dọa thiếu hụt lưu trữ, phương án này không chia dữ liệu gốc thành khối để lưu trữ, mà trước tiên ánh xạ dữ liệu gốc thành hệ số của một đa thức bậc n, rồi lấy 2n điểm trên đa thức đó, để các nút chọn ngẫu nhiên một điểm lưu trữ. Với đa thức bậc n, chỉ cần n+1 điểm là có thể khôi phục, do đó chỉ cần một nửa số khối được chọn, ta vẫn khôi phục được dữ liệu gốc. Nhờ mã Erasure, độ an toàn lưu trữ và khả năng phục hồi dữ liệu của mạng được nâng cao.
-
Cam kết đa thức KZG: Kiểm tra tính xác thực dữ liệu là khâu rất quan trọng. Trong mạng không dùng mã Erasure, có thể dùng nhiều phương pháp kiểm tra, nhưng nếu đã dùng mã Erasure để tăng an toàn, thì phương pháp phù hợp là cam kết đa thức KZG. Cam kết KZG có thể kiểm tra nội dung từng khối trực tiếp dưới dạng đa thức, loại bỏ bước khôi phục đa thức thành dữ liệu nhị phân. Cách xác minh tổng thể giống Merkle Tree, nhưng không cần dữ liệu nút đường dẫn cụ thể, chỉ cần KZG Root và dữ liệu khối là có thể xác minh thật/giả.
3.3 Phương thức kiểm tra dữ liệu tầng DA
Kiểm tra dữ liệu nhằm đảm bảo dữ liệu lấy từ nút chưa bị thay đổi và không bị mất mát. Để giảm thiểu lượng dữ liệu và chi phí tính toán trong quá trình kiểm tra, hiện nay tầng DA dùng cấu trúc cây làm phương pháp kiểm tra chính. Đơn giản nhất là dùng Cây Merkle, ghi theo dạng cây nhị phân hoàn chỉnh, chỉ cần lưu Merkle Root và giá trị băm của nút con bên kia trên đường dẫn là có thể xác minh, độ phức tạp thời gian là O(logN) (nếu logN không ghi cơ số thì mặc định là log₂(N)). Dù đã đơn giản hóa đáng kể, lượng dữ liệu kiểm tra vẫn tăng theo kích thước dữ liệu. Để giải quyết vấn đề lượng kiểm tra tăng, hiện nay có phương pháp xác minh khác: Cây Verkle. Trong Cây Verkle, mỗi nút ngoài lưu giá trị còn kèm theo một Vector Commitment, chỉ cần giá trị nút gốc và bằng chứng cam kết này là có thể nhanh chóng xác minh tính xác thực dữ liệu, không cần gọi dữ liệu nút chị em, khiến số lần tính toán mỗi lần xác minh chỉ phụ thuộc độ sâu Cây Verkle — là một hằng số cố định, từ đó tăng tốc đáng kể quá trình xác minh. Tuy nhiên, việc tính Vector Commitment cần sự tham gia của tất cả nút chị em cùng tầng, làm tăng đáng kể chi phí ghi và sửa dữ liệu. Nhưng với dữ liệu lịch sử — loại dữ liệu lưu trữ vĩnh viễn, không thể thay đổi, chỉ cần đọc chứ không cần ghi — Cây Verkle rất phù hợp. Ngoài ra, Cây Merkle và Cây Verkle còn có biến thể dạng K-ary, cơ chế triển khai tương tự, chỉ thay đổi số lượng nút con mỗi nút, so sánh hiệu suất cụ thể xem bảng dưới.
So sánh hiệu suất thời gian phương thức kiểm tra dữ liệu, nguồn ảnh: Verkle Trees
3.4 Thành phần trung gian DA phổ quát
Hệ sinh thái blockchain ngày càng mở rộng, kéo theo số lượng blockchain tăng liên tục. Do mỗi blockchain có lợi thế riêng và không thể thay thế trong lĩnh vực của mình, Layer1 gần như không thể thống nhất trong ngắn hạn. Tuy nhiên, cùng với sự phát triển của DeFi và những vấn đề của CEX, nhu cầu giao dịch tài sản liên chuỗi phi tập trung ngày càng tăng. Do đó, tầng DA lưu trữ dữ liệu đa chuỗi — có thể loại bỏ các vấn đề an toàn trong tương tác dữ liệu liên chuỗi — ngày càng được chú ý. Nhưng để chấp nhận dữ liệu lịch sử từ các blockchain khác nhau, tầng DA cần cung cấp giao thức phi tập trung chuẩn hóa luồng dữ liệu và xác minh, ví dụ như công cụ trung gian lưu trữ kvye dựa trên Arweave, chủ động thu thập dữ liệu từ chuỗi, lưu trữ dữ liệu mọi chuỗi lên Arweave theo dạng chuẩn, giảm thiểu khác biệt trong quá trình truyền dữ liệu. Ngược lại, các Layer2 cung cấp dịch vụ lưu trữ tầng DA riêng cho một blockchain cụ thể, dùng cách chia sẻ nút nội bộ để trao đổi dữ liệu, dù giảm chi phí và tăng an toàn, nhưng bị giới hạn lớn, chỉ phục vụ được blockchain cụ thể đó.
4. Phương án lưu trữ tầng DA
4.1 DA trên chuỗi chính
4.1.1 Loại DankSharding
Loại phương án lưu trữ này chưa có tên gọi chính thức, đại diện nổi bật nhất là DankSharding trên Ethereum, do đó bài viết dùng "loại DankSharding" để chỉ nhóm này. Phương án này chủ yếu dùng hai công nghệ lưu trữ DA đã nêu: Sharding và DAS. Đầu tiên dùng Sharding chia dữ liệu thành phần phù hợp, sau đó mỗi nút lưu trữ một khối dữ liệu theo hình thức DAS. Với số lượng nút đủ lớn, ta có thể chọn số mảnh N lớn, khi đó áp lực lưu trữ mỗi nút chỉ còn 1/N, từ đó mở rộng không gian lưu trữ tổng thể gấp N lần. Đồng thời, để tránh tình huống cực đoan một khối không được nút nào lưu trữ, DankSharding mã hóa dữ liệu bằng Eraser Code, chỉ cần một nửa dữ liệu là có thể khôi phục đầy đủ. Cuối cùng là quá trình kiểm tra dữ liệu, dùng cấu trúc Cây Verkle và cam kết đa thức, đạt được xác minh nhanh chóng.
4.1.2 Lưu trữ tạm thời
Với DA trên chuỗi chính, cách xử lý dữ liệu đơn giản nhất là lưu trữ tạm thời dữ liệu lịch sử. Về bản chất, blockchain đóng vai trò sổ cái công khai, thay đổi nội dung sổ cái dưới sự chứng kiến chung của toàn mạng, chứ không có nhu cầu lưu trữ vĩnh viễn. Ví dụ Solana, dù dữ liệu lịch sử được đồng bộ lên Arweave, nhưng nút chính chỉ giữ dữ liệu giao dịch gần hai ngày. Trên các blockchain dựa trên tài khoản, chỉ cần lưu trạng thái cuối cùng của tài khoản tại mỗi thời điểm là đủ để xác minh thay đổi thời điểm tiếp theo. Với các dự án đặc biệt cần dữ liệu trước khoảng thời gian đó, họ có thể tự lưu trữ trên blockchain phi tập trung khác hoặc giao cho bên thứ ba đáng tin. Nghĩa là ai cần dữ liệu thêm phải trả phí lưu trữ dữ liệu lịch sử.
4.2 DA bên thứ ba
4.2.1 DA dành riêng cho chuỗi chính: EthStorage
-
DA dành riêng cho chuỗi chính: Yếu tố quan trọng nhất của tầng DA là an toàn truyền dữ liệu, và an toàn cao nhất là DA trên chuỗi chính. Tuy nhiên, lưu trữ trên chuỗi chính bị giới hạn bởi không gian lưu trữ và cạnh tranh tài nguyên, nên khi lượng dữ liệu mạng tăng nhanh, nếu muốn lưu trữ dài hạn, DA bên thứ ba sẽ là lựa chọn tốt hơn. Nếu DA bên thứ ba có độ tương thích cao với mạng chính, có thể chia sẻ nút, thì trong trao đổi dữ liệu cũng có an toàn cao hơn. Do đó, xét về an toàn, DA dành riêng cho chuỗi chính có lợi thế lớn. Ví dụ Ethereum, yêu cầu cơ bản của DA dành riêng là tương thích với EVM, đảm bảo khả năng tương tác giữa dữ liệu và hợp đồng Ethereum. Các dự án tiêu biểu gồm Topia, EthStorage. Trong đó EthStorage hiện tại phát triển hoàn thiện nhất về tương thích, vì ngoài tương thích EVM, nó còn thiết lập giao diện riêng kết nối với các công cụ phát triển Ethereum như Remix, Hardhat, đạt được tương thích ở cấp độ công cụ phát triển.
-
EthStorage: EthStorage là một blockchain độc lập với Ethereum, nhưng các nút chạy trên nó là tập cha của nút Ethereum — nghĩa là nút chạy EthStorage cũng có thể chạy Ethereum đồng thời, và có thể thao tác trực tiếp EthStorage qua opcode trên Ethereum. Trong mô hình lưu trữ EthStorage, chỉ lưu một lượng nhỏ siêu dữ liệu (metadata) trên mạng chính Ethereum để làm chỉ mục, về bản chất là tạo một cơ sở dữ liệu phi tập trung cho Ethereum. Trong giải pháp hiện tại, EthStorage triển khai tương tác giữa mạng chính Ethereum và EthStorage bằng cách triển khai một Hợp đồng EthStorage trên mạng chính Ethereum. Nếu Ethereum muốn lưu dữ liệu, cần gọi hàm put() trong hợp đồng, nhập hai tham số kiểu byte: key và data, trong đó data là dữ liệu cần lưu, còn key là định danh trên mạng Ethereum, có thể coi như CID trong IPFS. Sau khi cặp (key, data) được lưu thành công vào mạng EthStorage, EthStorage sẽ sinh ra một kvldx trả về mạng chính Ethereum, tương ứng với key trên Ethereum, giá trị này tương ứng địa chỉ lưu trữ dữ liệu trên EthStorage. Như vậy, vấn đề trước đây có thể phải lưu lượng lớn dữ liệu nay trở thành lưu một cặp (key, kvldx) đơn lẻ, giảm đáng kể chi phí lưu trữ trên mạng chính Ethereum. Nếu cần truy xuất dữ liệu đã lưu, dùng hàm get() trong EthStorage, nhập tham số key, qua kvldx lưu trên Ethereum có thể nhanh chóng tìm kiếm dữ liệu trên EthStorage.
Hợp đồng EthStorage, nguồn ảnh: Kernel Ventures
-
Về cách lưu trữ cụ thể tại nút, EthStorage tham khảo mô hình Arweave. Trước hết, lượng lớn cặp (k,v) từ ETH được chia mảnh, mỗi mảnh chứa số lượng cố định cặp (k,v), đồng thời kích thước cụ thể mỗi cặp (k,v) cũng bị giới hạn, nhằm đảm bảo công bằng trong quá trình thưởng cho thợ đào về khối lượng công việc. Việc phát thưởng cần trước tiên xác minh nút có thực sự lưu trữ dữ liệu hay không. Trong quá trình này, EthStorage chia một mảnh (cỡ TB) thành rất nhiều chunk, và lưu một Merkle root trên mạng chính Ethereum để xác minh. Sau đó, thợ đào phải cung cấp một nonce kết hợp với băm khối trước đó trên EthStorage qua thuật toán ngẫu nhiên để sinh ra vài địa chỉ chunk, thợ đào cần cung cấp dữ liệu các chunk này để chứng minh thực sự lưu trữ toàn bộ mảnh. Tuy nhiên, nonce này không thể chọn tùy ý, nếu không nút có thể chọn nonce phù hợp chỉ tương ứng với chunk đã lưu để qua xác minh. Do đó, nonce phải đảm bảo chunk sinh ra sau khi trộn và băm phải có độ khó thỏa mãn yêu cầu mạng, và chỉ nút đầu tiên nộp nonce và bằng chứng truy cập ngẫu nhiên mới được thưởng.
4.2.2 DA mô-đun: Celestia
-
Các mô-đun blockchain: Hiện nay, các nhiệm vụ chính của Layer1 blockchain gồm bốn phần: (1) Thiết kế logic底层 mạng, chọn nút xác thực theo cách nào đó, ghi khối và phân thưởng cho người duy trì mạng; (2) Gói và xử lý giao dịch, công bố sự kiện liên quan; (3) Xác minh giao dịch sắp lên chuỗi và xác định trạng thái cuối cùng; (4) Lưu trữ và duy trì dữ liệu lịch sử trên blockchain. Dựa trên chức năng khác nhau, có thể chia blockchain thành bốn mô-đun: tầng đồng thuận, tầng thực thi, tầng thanh toán, và tầng tính sẵn có dữ liệu (tầng DA).
-
Thiết kế blockchain mô-đun: Trong thời gian dài, bốn mô-đun này đều được tích hợp vào một blockchain, gọi là blockchain đơn thể. Hình thức này ổn định và dễ duy trì hơn, nhưng gây áp lực lớn lên blockchain đơn lẻ. Trong vận hành thực tế, bốn mô-đun này ràng buộc và cạnh tranh tài nguyên tính toán và lưu trữ hạn chế của blockchain. Ví dụ, muốn tăng tốc độ xử lý tầng thực thi, sẽ gây áp lực lưu trữ lớn hơn lên tầng DA; muốn đảm bảo an toàn tầng thực thi cần cơ chế xác minh phức tạp hơn nhưng làm chậm tốc độ xử lý giao dịch. Do đó, việc phát triển blockchain thường phải đánh đổi giữa bốn mô-đun. Để phá vỡ giới hạn nâng cao hiệu suất này, các nhà phát triển đề xuất phương án blockchain mô-đun. Tư tưởng cốt lõi là tách một hoặc vài mô-đun ra, giao cho một blockchain riêng biệt thực hiện. Như vậy, blockchain đó có thể tập trung vào tăng tốc độ giao dịch hoặc khả năng lưu trữ, vượt qua giới hạn hiệu suất toàn hệ thống do hiệu ứng điểm nghẽn gây ra.
-
DA mô-đun: Việc tách riêng tầng DA khỏi nghiệp vụ blockchain và giao cho một blockchain riêng xử lý được xem là giải pháp khả thi trước áp lực dữ liệu lịch sử ngày càng tăng của Layer1. Hiện nay khám phá trong lĩnh vực này vẫn ở giai đoạn sơ khai, dự án tiêu biểu nhất hiện nay là Celestia. Về phương thức lưu trữ cụ thể, Celestia tham khảo phương pháp lưu trữ Danksharding, cũng chia dữ liệu thành nhiều khối, các nút chọn một phần lưu trữ và dùng cam kết đa thức KZG để xác minh tính toàn vẹn dữ liệu. Đồng thời, Celestia dùng mã sửa lỗi RS hai chiều tiên tiến, viết lại dữ liệu gốc dưới dạng ma trận k×k, cuối cùng chỉ cần 25% dữ liệu là có thể khôi phục dữ liệu gốc. Tuy nhiên, lưu trữ chia mảnh về bản chất chỉ nhân áp lực lưu trữ từng nút với một hệ số trên tổng dữ liệu, áp lực lưu trữ nút và lượng dữ liệu vẫn tăng tuyến tính. Cùng với việc Layer1 không ngừng cải thiện tốc độ giao dịch, một ngày nào đó áp lực lưu trữ nút có thể đạt đến mức tới giới hạn không thể chấp nhận. Để giải quyết vấn đề này, Celestia đưa vào thành phần IPLD xử lý. Dữ liệu trong ma trận k×k không được lưu trực tiếp trên Celestia, mà được lưu trên mạng LL-IPFS, chỉ lưu mã CID của dữ liệu đó trên IPFS tại nút. Khi người dùng yêu cầu một dữ liệu lịch sử, nút sẽ gửi CID tương ứng đến thành phần IPLD, qua CID này gọi dữ liệu gốc trên IPFS. Nếu dữ liệu tồn tại trên IPFS, sẽ được trả lại qua IPLD và nút; nếu không tồn tại thì không trả lại dữ liệu.
Cách đọc dữ liệu Celestia, nguồn ảnh: Celestia Core
-
Celestia: Lấy Celestia làm ví dụ, ta có thể thấy ứng dụng thực tế của blockchain mô-đun trong giải quyết vấn đề lưu trữ Ethereum. Nút Rollup sẽ gửi dữ liệu giao dịch đã gói và xác minh xong đến Celestia và lưu trữ dữ liệu trên Celestia, trong quá trình này Celestia chỉ lo lưu trữ dữ liệu mà không cần biết nhiều, cuối cùng nút Rollup sẽ trả token tia tương ứng cho Celestia theo dung lượng lưu trữ. Việc lưu trữ trên Celestia tận dụng DAS và mã sửa lỗi trong EIP4844, nhưng nâng cấp mã sửa lỗi đa thức trong EIP4844 thành mã sửa lỗi RS hai chiều, nâng cao thêm an toàn lưu trữ, chỉ cần 25% mảnh là có thể khôi phục toàn bộ dữ liệu giao dịch. Về bản chất, nó chỉ là một blockchain POS chi phí thấp, nếu muốn dùng để giải quyết vấn đề lưu trữ dữ liệu lịch sử Ethereum, cần nhiều mô-đun cụ thể khác phối hợp với Celestia.Ví dụ về phía Rollup, mô hình Rollup được trang web chính thức Celestia mạnh mẽ khuyến nghị là Sovereign Rollup. Khác với Rollup phổ biến trên Layer2, chỉ tính toán và xác minh giao dịch — tức hoàn thành thao tác tầng thực thi. Sovereign Rollup bao gồm toàn bộ quá trình thực thi và thanh toán, điều này tối thiểu hóa xử lý giao dịch trên Celestia, trong trường hợp an toàn tổng thể Celestia yếu hơn Ethereum, biện pháp này có thể tối đa hóa an toàn toàn bộ quá trình giao dịch. Về đảm bảo an toàn khi mạng chính Ethereum gọi dữ liệu từ Celestia, giải pháp phổ biến nhất hiện nay là hợp đồng thông minh Quantum Gravity Bridge. Đối với dữ liệu lưu trữ trên Celestia, nó sẽ sinh ra một Merkle Root (bằng chứng tính sẵn có dữ liệu) và giữ lại trên hợp đồng Quantum Gravity Bridge trên mạng chính Ethereum. Mỗi lần Ethereum gọi dữ liệu lịch sử trên Celestia, đều so sánh kết quả băm với Merkle Root, nếu khớp mới xác nhận là dữ liệu lịch sử thật sự.
4.2.3 DA trên chuỗi lưu trữ
Về nguyên lý công nghệ DA trên chuỗi chính, đã tham khảo nhiều kỹ thuật từ chuỗi lưu trữ như Sharding. Trong các giải pháp DA bên thứ ba, có những cái thậm chí trực tiếp dùng chuỗi lưu trữ hoàn thành một phần nhiệm vụ lưu trữ, ví dụ dữ liệu giao dịch cụ thể trong Celestia được đặt trên mạng LL-IPFS. Ngoài việc xây dựng một blockchain riêng để giải quyết vấn đề lưu trữ Layer1, một cách trực tiếp hơn là để chuỗi lưu trữ kết nối trực tiếp với Layer1, lưu trữ lượng lớn dữ liệu lịch sử từ Layer1. Với blockchain hiệu năng cao, khối lượng dữ liệu lịch sử càng lớn hơn, khi chạy tối đa, dữ liệu của blockchain hiệu năng cao Solana gần đạt 4 PG, hoàn toàn vượt quá khả năng lưu trữ của nút thông thường. Giải pháp Solana chọn là lưu dữ liệu lịch sử trên mạng lưu trữ phi tập trung Arweave, chỉ giữ dữ liệu 2 ngày trên nút mạng chính để xác minh. Để đảm bảo an toàn quá trình lưu trữ, Solana và Arweave tự thiết kế giao thức cầu nối lưu trữ Solar Bridge. Dữ liệu đã xác minh bởi nút Solana sẽ được đồng bộ lên Arweave và trả về tag tương ứng. Chỉ cần tag này, nút Solana có thể xem dữ liệu lịch sử bất kỳ thời điểm nào của blockchain Solana. Trên Arweave, không yêu cầu mọi nút duy trì nhất quán dữ liệu toàn mạng làm门槛 tham gia mạng, mà dùng cơ chế thưởng cho việc lưu trữ. Trước hết, Arweave không dùng cấu trúc chuỗi truyền thống để xây dựng khối, mà gần giống cấu trúc đồ thị. Trong Arweave, một khối mới không chỉ trỏ đến khối trước đó, mà còn trỏ ngẫu nhiên đến một khối đã tạo trước — Recall Block. Vị trí cụ thể Recall Block do kết quả băm của khối trước và chiều cao khối quyết định, trước khi khối trước được đào ra, vị trí Recall Block là chưa biết. Nhưng trong quá trình tạo khối mới, nút cần có dữ liệu Recall Block để dùng cơ chế POW tính băm đạt độ khó quy định, chỉ thợ đào đầu tiên tính ra băm phù hợp mới được thưởng, khuyến khích thợ đào lưu trữ càng nhiều dữ liệu lịch sử càng tốt. Đồng thời, càng ít người lưu một khối lịch sử cụ thể, khi tạo nonce đạt độ khó, nút sẽ có ít đối thủ cạnh tranh hơn, khuyến khích thợ đào lưu trữ các khối có bản sao ít trong mạng. Cuối cùng, để đảm bảo nút lưu trữ dữ liệu vĩnh viễn trên Arweave, nó đưa vào cơ chế xếp hạng nút WildFire. Các nút có xu hướng giao tiếp với nút nào cung cấp nhanh và nhiều dữ liệu lịch sử hơn, còn nút có điểm thấp thường không nhận được khối mới và dữ liệu giao dịch kịp thời, do đó không chiếm ưu thế trong cuộc đua POW.
Cách xây dựng khối Arweave, nguồn ảnh: Arweave Yellow-Paper
5. So sánh tổng hợp
Tiếp theo, chúng ta sẽ so sánh ưu nhược điểm của 5 phương án lưu trữ dựa trên bốn khía cạnh chỉ số hiệu suất DA.
-
An toàn: Nguồn rủi ro an toàn dữ liệu lớn nhất là mất dữ liệu do quá trình truyền và thay đổi ác ý từ nút không trung thực. Trong quá trình liên chuỗi, do tính độc lập và trạng thái không chia sẻ giữa hai blockchain, đây là vùng nguy hiểm về an toàn truyền dữ liệu. Ngoài ra, Layer1 hiện nay cần tầng DA chuyên biệt thường có cộng đồng đồng thuận mạnh, an toàn bản thân cao hơn nhiều so với chuỗi lưu trữ thông thường. Do đó, phương án DA trên chuỗi chính có an toàn cao hơn. Sau khi đảm bảo an toàn truyền dữ liệu, tiếp theo là đảm bảo an toàn dữ liệu truy xuất. Nếu chỉ xét dữ liệu lịch sử ngắn hạn dùng để xác minh giao dịch, cùng một dữ liệu trong mạng lưu trữ tạm thời được sao lưu chung toàn mạng, trong khi trong phương án loại DankSharding số bản sao trung bình mỗi dữ liệu chỉ là 1/N tổng số nút, dữ liệu dư thừa nhiều hơn khiến dữ liệu khó mất hơn, đồng thời cung cấp nhiều mẫu tham khảo hơn khi xác minh. Do đó, lưu trữ tạm thời có an toàn dữ liệu cao hơn tương đối. Trong các phương án DA bên thứ ba, DA dành riêng cho chuỗi chính do dùng chung nút với chuỗi chính, trong liên chuỗi dữ liệu có thể truyền trực tiếp qua các nút trung gian này, nên cũng có an toàn cao hơn tương đối so với các phương án DA khác.
-
Chi phí lưu trữ: Yếu tố ảnh hưởng lớn nhất đến chi phí lưu trữ là số lượng dư thừa dữ liệu. Trong phương án lưu trữ tạm thời trên chuỗi chính, dùng hình thức đồng bộ dữ liệu toàn mạng để lưu trữ, bất kỳ dữ liệu mới nào cũng cần sao lưu trên mọi nút mạng, do đó có chi phí lưu trữ cao nhất. Chi phí lưu trữ cao ngược lại quyết định rằng trong mạng TPS cao, phương thức này chỉ phù hợp làm lưu trữ tạm thời. Tiếp theo là phương thức lưu trữ Sharding, bao gồm Sharding trên chuỗi chính và Sharding trong DA bên thứ ba. Do chuỗi chính thường có nhiều nút hơn, nên một khối sẽ có nhiều bản sao hơn, do đó phương án Sharding trên chuỗi chính có chi phí cao hơn. Chi phí lưu trữ thấp nhất là DA trên chuỗi lưu trữ dùng cơ chế thưởng lưu trữ, trong phương án này số lượng dư thừa dữ liệu thường dao động quanh một hằng số cố định. Đồng thời, DA trên chuỗi lưu trữ còn đưa vào cơ chế điều chỉnh động, tăng thưởng để thu hút nút lưu trữ dữ liệu có bản sao ít, đảm bảo an toàn dữ liệu.
-
Tốc độ đọc dữ liệu: Tốc độ lưu trữ chủ yếu chịu ảnh hưởng bởi vị trí dữ liệu trong không gian lưu trữ, đường dẫn chỉ mục dữ liệu và phân bố dữ liệu tại các nút. Trong đó, vị trí lưu trữ tại nút ảnh hưởng lớn hơn đến tốc độ, vì lưu dữ liệu trong RAM hay SSD có thể chênh lệch tốc độ đọc tới hàng chục lần. DA trên chuỗi lưu trữ chủ yếu dùng lưu trữ SSD, vì tải trên chuỗi này không chỉ gồm dữ liệu tầng DA mà còn có dữ liệu cá nhân chiếm bộ nhớ cao như video, hình ảnh do người dùng tải lên. Nếu mạng không dùng SSD làm không gian lưu trữ, sẽ khó chịu đựng áp lực lưu trữ lớn và đáp ứng nhu cầu lưu trữ dài hạn. Thứ hai, với DA bên thứ ba và DA trên chuỗi chính dùng lưu trữ trạng thái bộ nhớ, DA bên thứ ba trước tiên cần tìm dữ liệu chỉ mục tương ứng trên chuỗi chính, sau đó truyền chỉ mục này liên chuỗi đến DA bên thứ ba, và qua cầu nối lưu trữ trả lại dữ liệu. Ngược lại, DA trên chuỗi chính có thể truy vấn dữ liệu trực tiếp từ nút, do đó có tốc độ truy xuất dữ liệu nhanh hơn. Cuối cùng, trong nội bộ DA trên chuỗi chính, phương án dùng Sharding cần gọi khối từ nhiều nút và khôi phục dữ liệu gốc. Do đó, so với phương án lưu trữ không chia mảnh (lưu trữ tạm thời), tốc độ sẽ chậm hơn.
-
Tính phổ quát của tầng DA: Tính phổ quát của DA trên chuỗi chính gần bằng không, vì không thể chuyển dữ liệu từ một blockchain thiếu không gian lưu trữ sang một blockchain khác cũng thiếu không gian lưu trữ. Trong DA bên thứ ba, tính phổ quát và độ tương thích với chuỗi chính cụ thể là hai chỉ số mâu thuẫn. Ví dụ, với phương án DA dành riêng cho chuỗi chính được thiết kế riêng, đã có nhiều cải tiến ở cấp độ loại nút và đồng thuận mạng để phù hợp chuỗi đó, do đó khi giao tiếp với các blockchain khác, những cải tiến này sẽ gây cản trở lớn. Trong nội bộ DA bên thứ ba, so với DA mô-đun, DA trên chuỗi lưu trữ thể hiện tốt hơn về tính phổ quát. DA trên chuỗi lưu trữ có cộng đồng nhà phát triển lớn hơn và nhiều tiện ích mở rộng hơn, có thể thích nghi với tình hình các blockchain khác nhau. Đồng thời, cách lấy dữ liệu của DA trên chuỗi lưu trữ chủ yếu là chủ động thu thập qua bắt gói, chứ không thụ động nhận thông tin truyền từ các blockchain khác. Do đó, nó có thể mã hóa dữ liệu theo cách riêng, thực hiện lưu trữ chuẩn hóa luồng dữ liệu, thuận tiện quản lý thông tin dữ liệu từ các chuỗi chính khác nhau và nâng cao hiệu quả lưu trữ.
So sánh hiệu suất phương án lưu trữ, nguồn ảnh: Kernel Ventures
6. Tổng kết
Hiện nay, blockchain đang trải qua quá trình chuyển đổi từ Crypto sang Web3 rộng rãi hơn, quá trình này không chỉ mang lại sự phong phú dự án trên blockchain. Để chứa được nhiều dự án như vậy chạy đồng thời trên Layer1, đồng thời đảm bảo trải nghiệm các dự án Gamefi và Socialfi, Layer1 đại diện như Ethereum dùng Rollup và Blobs để tăng TPS. Trong các blockchain mới, số lượng blockchain hiệu năng cao cũng không ngừng tăng. Tuy nhiên, TPS cao hơn không chỉ có nghĩa hiệu năng cao hơn, mà còn đồng nghĩa áp lực lưu trữ lớn hơn trong mạng. Đối với lượng lớn dữ liệu lịch sử, hiện nay có nhiều phương án DA trên chuỗi chính và bên thứ ba, nhằm thích ứng với sự gia tăng áp lực lưu trữ trên chuỗi. Các phương án cải tiến đều có ưu nhược điểm riêng, phù hợp trong các hoàn cảnh khác nhau.
Các blockchain chủ yếu thanh toán yêu cầu rất cao về an toàn dữ liệu lịch sử, không theo đuổi TPS đặc biệt cao. Nếu loại blockchain này còn đang trong giai đoạn chuẩn bị, có thể dùng phương án lưu trữ loại DankSharding, vừa đảm bảo an toàn vừa mở rộng dung lượng lưu trữ lớn. Nhưng nếu là Bitcoin — blockchain đã成型 với lượng lớn nút — việc cải tiến tầng đồng thuận liều lĩnh tiềm ẩn rủi ro lớn, do đó có thể dùng DA dành riêng cho chuỗi chính — có an toàn cao trong lưu trữ ngoài chuỗi — để cân bằng an toàn và vấn đề lưu trữ. Tuy nhiên, cần lưu ý rằng chức năng blockchain không bất biến mà luôn thay đổi. Ví dụ ban đầu Ethereum chủ yếu giới hạn ở thanh toán và tự động hóa đơn giản tài sản, giao dịch qua hợp đồng thông minh, nhưng khi bản đồ blockchain không ngừng mở rộng, Ethereum dần thêm nhiều dự án Socialfi và Defi, hướng đến phát triển tổng hợp hơn. Gần đây, cùng với sự bùng nổ hệ sinh thái inscription trên Bitcoin, phí giao dịch mạng Bitcoin từ tháng 8 tăng gần 20 lần, phản ánh tốc độ giao dịch hiện tại của mạng Bitcoin không đáp ứng được nhu cầu, người dùng chỉ có thể đẩy phí lên để giao dịch được xử lý nhanh. Hiện tại, cộng đồng Bitcoin cần đưa ra lựa chọn: chấp nhận phí cao và tốc độ giao dịch chậm, hay giảm an toàn mạng để tăng tốc độ giao dịch nhưng đi ngược mục đích hệ thống thanh toán. Nếu cộng đồng Bitcoin chọn phương án sau, thì trước áp lực dữ liệu tăng, phương án lưu trữ tương ứng cũng cần điều chỉnh.
Biến động phí giao dịch mạng chính Bitcoin, nguồn ảnh: OKLINK
Đối với blockchain chức năng tổng hợp, họ theo đuổi TPS cao hơn, sự gia tăng dữ liệu lịch sử càng lớn, phương án loại DankSharding về lâu dài khó thích ứng với sự tăng trưởng nhanh của TPS. Do đó, cách phù hợp hơn là chuyển dữ liệu sang DA bên thứ ba để lưu trữ. Trong đó, DA dành riêng cho chuỗi chính có độ tương thích cao nhất, nếu chỉ xét vấn đề lưu trữ một chuỗi đơn lẻ, có thể có lợi thế hơn. Nhưng trong bối cảnh Layer1 đa dạng hôm nay, chuyển tài sản liên chuỗi và trao đổi dữ liệu cũng trở thành nhu cầu phổ biến của cộng đồng blockchain. Nếu xét đến phát triển lâu dài toàn hệ sinh thái blockchain, lưu trữ dữ liệu lịch sử các chuỗi khác nhau trên một chuỗi duy nhất có thể loại bỏ nhiều vấn đề an toàn trong trao đổi và xác minh dữ liệu, do đó phương án DA mô-đun và DA trên chuỗi lưu trữ có thể là lựa chọn tốt hơn. Với tính phổ quát tương đương, DA mô-đun tập trung cung cấp dịch vụ tầng DA blockchain, đưa vào quản lý chỉ mục dữ liệu tinh vi hơn để phân loại hợp lý dữ liệu các chuỗi khác nhau, có lợi
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
Kernel Ventures
