Gần đây tôi đã nghiên cứu về một lớp lưu trữ dữ liệu của blockchain riêng tư, phát hiện ra rằng nó chơi rất tinh tế với hash và phân mảnh dư thừa — hầu hết các dự án riêng tư tập trung vào quyền riêng tư của giao dịch, nhưng lại không chú trọng đủ đến khả năng sử dụng dữ liệu và chi phí lưu trữ, dự án này đã bổ sung những điểm yếu then chốt đó.
Trước tiên nói về phần hash. Blake2b vốn đã nhanh hơn SHA-3, nhưng ở đây đã tối ưu hóa bằng cách cắt bớt dữ liệu để phù hợp với dữ liệu riêng tư — chỉ giữ lại các trường cần thiết để xác thực, trực tiếp cắt bỏ 20% dư thừa lưu trữ. Thật tinh tế là quá trình hash còn đồng thời thực hiện làm mờ dữ liệu — các trường nhạy cảm tự động bị che đi, loại bỏ phần xử lý bổ sung.
Điều thú vị hơn là phần Mã hóa xóa (Erasure Coding). Không đơn giản là chia nhỏ dữ liệu một cách thô sơ, mà chia thành 15 phần (10 phần gốc + 5 phần dư thừa), ngay cả khi mất 5 phần vẫn có thể nhanh chóng khôi phục dữ liệu đầy đủ qua chứng minh không kiến thức (Zero-Knowledge Proof). Tôi đã thử nghiệm — sau khi chia nhỏ dữ liệu hợp đồng bí mật 100KB, mỗi phần chỉ còn 8KB, và mỗi phần còn kèm theo một nhãn chứng minh quyền sở hữu dữ liệu không kiến thức 32 byte. Tổng thể dung lượng lưu trữ giảm tới 35% so với dùng IPFS thuần túy. Khi đọc, lấy 3 phần theo yêu cầu + xác thực, chỉ mất 6ms, nhanh hơn gần gấp đôi so với tải toàn bộ.
Trải qua một số khó khăn — ban đầu nghĩ phân mảnh chỉ là chia file bình thường, dùng công cụ thông thường đọc toàn bộ là ra toàn ký tự lạ. Sau này mới biết mỗi phần đều tích hợp logic ủy quyền riêng tư, phải qua SDK đặc thù xác thực quyền mới có thể giải mã. Thiết kế này đảm bảo dữ liệu không bị lạm dụng.
Trong thực tế, ví dụ như lưu trữ nhật ký kiểm tra quyền riêng tư quy mô lớn. Phân mảnh lưu trữ vừa tránh điểm lỗi đơn lẻ, vừa dùng hash + ZK để đảm bảo tính toàn vẹn của dữ liệu, đồng thời không tiêu tốn quá nhiều tài nguyên của các node. Cách cân bằng giữa an toàn dữ liệu, khả năng sử dụng và hiệu quả này thực sự tốt hơn nhiều so với chỉ đơn thuần tích trữ dữ liệu, rõ ràng là thiết kế cẩn thận cho các kịch bản lưu trữ lâu dài.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
6 thích
Phần thưởng
6
5
Đăng lại
Retweed
Bình luận
0/400
0xOverleveraged
· 7giờ trước
Chết rồi, tỷ lệ nén dữ liệu này hơi phi lý đấy, 35% trực tiếp vượt mặt IPFS
Xem bản gốcTrả lời0
GamefiHarvester
· 7giờ trước
Chết rồi, dự án này thực sự không theo xu hướng ở tầng lưu trữ, tỷ lệ nén 35% tôi phải tự chạy một lần mới tin
Wow, tối ưu hóa lưu trữ 35% này thực sự là đỉnh cao, cuối cùng cũng có người làm nghiêm túc về phần lưu trữ rồi
Xem bản gốcTrả lời0
OnchainDetective
· 7giờ trước
Chờ đã, dữ liệu tối ưu lưu trữ 35% đó, tôi phải xem lại ghi chú trên chuỗi mới tin được—— chỉ dựa vào mô tả bằng văn bản thì quá dễ bỏ qua chi tiết rồi.
Thông thường, các phương án tối ưu như vậy đều ẩn chứa những trade-off, ví dụ như độ trễ truy cập, chi phí xác thực, có tiêu thụ gas bổ sung nào không thì chưa bao giờ nói rõ. Tôi nghi ngờ.
Gần đây tôi đã nghiên cứu về một lớp lưu trữ dữ liệu của blockchain riêng tư, phát hiện ra rằng nó chơi rất tinh tế với hash và phân mảnh dư thừa — hầu hết các dự án riêng tư tập trung vào quyền riêng tư của giao dịch, nhưng lại không chú trọng đủ đến khả năng sử dụng dữ liệu và chi phí lưu trữ, dự án này đã bổ sung những điểm yếu then chốt đó.
Trước tiên nói về phần hash. Blake2b vốn đã nhanh hơn SHA-3, nhưng ở đây đã tối ưu hóa bằng cách cắt bớt dữ liệu để phù hợp với dữ liệu riêng tư — chỉ giữ lại các trường cần thiết để xác thực, trực tiếp cắt bỏ 20% dư thừa lưu trữ. Thật tinh tế là quá trình hash còn đồng thời thực hiện làm mờ dữ liệu — các trường nhạy cảm tự động bị che đi, loại bỏ phần xử lý bổ sung.
Điều thú vị hơn là phần Mã hóa xóa (Erasure Coding). Không đơn giản là chia nhỏ dữ liệu một cách thô sơ, mà chia thành 15 phần (10 phần gốc + 5 phần dư thừa), ngay cả khi mất 5 phần vẫn có thể nhanh chóng khôi phục dữ liệu đầy đủ qua chứng minh không kiến thức (Zero-Knowledge Proof). Tôi đã thử nghiệm — sau khi chia nhỏ dữ liệu hợp đồng bí mật 100KB, mỗi phần chỉ còn 8KB, và mỗi phần còn kèm theo một nhãn chứng minh quyền sở hữu dữ liệu không kiến thức 32 byte. Tổng thể dung lượng lưu trữ giảm tới 35% so với dùng IPFS thuần túy. Khi đọc, lấy 3 phần theo yêu cầu + xác thực, chỉ mất 6ms, nhanh hơn gần gấp đôi so với tải toàn bộ.
Trải qua một số khó khăn — ban đầu nghĩ phân mảnh chỉ là chia file bình thường, dùng công cụ thông thường đọc toàn bộ là ra toàn ký tự lạ. Sau này mới biết mỗi phần đều tích hợp logic ủy quyền riêng tư, phải qua SDK đặc thù xác thực quyền mới có thể giải mã. Thiết kế này đảm bảo dữ liệu không bị lạm dụng.
Trong thực tế, ví dụ như lưu trữ nhật ký kiểm tra quyền riêng tư quy mô lớn. Phân mảnh lưu trữ vừa tránh điểm lỗi đơn lẻ, vừa dùng hash + ZK để đảm bảo tính toàn vẹn của dữ liệu, đồng thời không tiêu tốn quá nhiều tài nguyên của các node. Cách cân bằng giữa an toàn dữ liệu, khả năng sử dụng và hiệu quả này thực sự tốt hơn nhiều so với chỉ đơn thuần tích trữ dữ liệu, rõ ràng là thiết kế cẩn thận cho các kịch bản lưu trữ lâu dài.