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.
ZK-0,03%
Xem bản gốc
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.
  • Phần thưởng
  • 5
  • Đăng lại
  • Retweed
Bình luận
0/400
0xOverleveragedvip
· 14giờ 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
GamefiHarvestervip
· 14giờ 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
Xem bản gốcTrả lời0
RumbleValidatorvip
· 14giờ trước
6ms读取延迟这数据真的击中我了,单点故障规避+ZK验证这套组合拳确实秀 分片冗余还能省35%存储,这逻辑比大多数项目狠多了,不是简单粱糙化 等等,那个权限校验逻辑是强制的吧?这意味着即便拿到分片也没法绕过去,架构设计角度确实考周全了 Blake2b这块截断优化砍20%冗余,小细节体现大差距啊 有个问题想问——这套方案在节点层面的验证成本怎么样?会不会因为ZK证明反而加重节点负担?
Trả lời0
BearWhisperGodvip
· 14giờ trước
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
OnchainDetectivevip
· 14giờ 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ờ.
Xem bản gốcTrả lời0
  • Ghim