Нещодавно досліджував реалізацію рівня зберігання даних приватної публічної блокчейн-мережі і виявив, що вона дуже детально опрацьовує хешування та冗余 розбиття — більшість проектів приватності зосереджуються на конфіденційності транзакцій, але щодо доступності даних і вартості зберігання — менш уважні, а цей проект заповнює цю ключову прогалину.



Перш за все, про хешування. Blake2b сам по собі швидший за SHA-3, але тут зроблено оптимізацію з обмеженням для приватних даних — зберігаються лише необхідні для валідації поля, видаляючи 20%冗余 зберігання. Що ще цікавіше, під час процесу хешування одночасно виконується десенситизація даних — чутливі поля автоматично приховуються, що позбавляє від додаткової логіки обробки.

Ще більш цікава частина — Erasure Coding. Це не просто грубе розбиття даних, а розбиття на 15 частин (10 оригінальних + 5冗余них), навіть при втраті 5 частин можна швидко відновити цілісність даних за допомогою доказів нульової знаності. Я сам протестував — розбивши 100КБ конфіденційних контрактних даних, кожна частина має лише 8КБ, і кожна з них містить 32-байтовий доказ власності за допомогою ZK. Загальний об’єм зберігання порівняно з простим IPFS зменшився на 35%. При читанні потрібно запитати 3 частини + перевірити — час всього 6мс, що майже вдвічі швидше за повне завантаження.

Зіткнувся з однією проблемою — спочатку думав, що розбиття — це просто звичайне розділення файлу, і при використанні стандартних інструментів отримував лише набір символів. Потім зрозумів, що кожна частина містить вбудовану логіку приватного доступу, і для розшифрування потрібно пройти авторизацію через спеціальний SDK. Цей дизайн гарантує, що дані не будуть зловживані.

Практичний приклад — зберігання масштабних журналів приватних аудитів. Розбиття зберігання ускладнює точкові збої, а також за допомогою хешів і ZK можна перевірити цілісність даних, не навантажуючи вузли. Такий баланс між безпекою, доступністю і ефективністю явно краще, ніж просто накопичувати зберігання, і свідчить про серйозний підхід до довгострокового збереження даних.
ZK0,13%
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 5
  • Репост
  • Поділіться
Прокоментувати
0/400
0xOverleveragedvip
· 13год тому
Блін, цей коефіцієнт стиснення даних просто неймовірний, 35% — і миттєво переважає IPFS
Переглянути оригіналвідповісти на0
GamefiHarvestervip
· 13год тому
Вау, цей проект у шарі зберігання справді не йде в ногу з часом, 35% ступінь стиснення — я повірю, якщо сам це перевірю.
Переглянути оригіналвідповісти на0
RumbleValidatorvip
· 13год тому
6ms读取延迟這數據真的擊中我了,單點故障規避+ZK驗證這套組合拳確實秀 分片冗餘還能省35%存儲,這邏輯比大多數項目狠多了,不是簡單粱糙化 等等,那個權限校驗邏輯是強制的吧?這意味著即便拿到分片也沒法繞過去,架構設計角度確實考周全了 Blake2b這塊截斷優化砍20%冗餘,小細節體現大差距啊 有個問題想問——這套方案在節點層面的驗證成本怎麼樣?會不會因為ZK證明反而加重節點負擔?
Переглянути оригіналвідповісти на0
BearWhisperGodvip
· 14год тому
Вау, ця 35% оптимізації зберігання дійсно вражає, нарешті хтось серйозно взявся за цю сферу
Переглянути оригіналвідповісти на0
OnchainDetectivevip
· 14год тому
Зачекайте, щодо даних оптимізації зберігання 35%, мені потрібно перевірити записи в ланцюгу, щоб переконатися — лише за текстовим описом дуже легко пропустити деталі. Зазвичай за такими оптимізаційними рішеннями приховані компроміси, наприклад, затримка читання, вартість валідації, чи є додаткові витрати газу — про це ніколи прямо не говорили. Маю сумніви.
Переглянути оригіналвідповісти на0
  • Закріпити