Недавно изучил реализацию слоя хранения данных в приватной публичной цепочке, и обнаружил, что она очень тщательно реализует хеширование и избыточность сегментации — большинство приватных проектов сосредоточены на конфиденциальности транзакций, но уделяют недостаточно внимания доступности данных и стоимости хранения, а этот проект заполняет ключевой пробел.
Во-первых, о хешировании. Blake2b сам по себе быстрее SHA-3, но здесь применена оптимизация с усечением для приватных данных — сохраняются только необходимые для проверки поля, прямо убрав 20% избыточности хранения. Более того, в процессе хеширования одновременно происходит десенситизация данных — чувствительные поля автоматически маскируются, что исключает необходимость дополнительной обработки.
Интереснее всего — часть с Erasure Coding. Здесь данные не просто разбиваются на сегменты простым способом, а делятся на 15 частей (10 оригинальных + 5 избыточных), и даже при потере 5 частей можно быстро восстановить полные данные с помощью доказательств с нулевым разглашением. Я сам протестировал — разбив 100КБ конфиденциальных данных смарт-контракта, каждый сегмент получился по 8КБ, а к каждому сегменту прикреплена 32-байтовая метка доказательства владения с нулевым разглашением. Общий объем хранения по сравнению с использованием только IPFS уменьшился на 35%. При чтении по требованию запрашиваются 3 сегмента + проверка, время занимает всего 6мс, что почти вдвое быстрее полной загрузки.
Поймал один подводный камень — сначала думал, что сегменты — это просто обычное разделение файла, и при использовании стандартных инструментов всё отображалось как мусор. Потом понял, что каждый сегмент содержит встроенную логику приватных разрешений, и для расшифровки нужно пройти проверку через специальный SDK. Эта реализация полностью гарантирует, что данные не будут злоупотреблять.
Практический сценарий — хранение масштабных журналов приватных аудитов. Разделение данных на сегменты помогает избежать точек отказа, а также с помощью хешей и ZK-проверок обеспечивает целостность данных, не нагружая при этом узлы. Такой баланс между безопасностью, доступностью и эффективностью явно лучше, чем просто наращивание объема хранения, и видно, что проект продуман для долгосрочного хранения данных.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
6 Лайков
Награда
6
5
Репост
Поделиться
комментарий
0/400
0xOverleveraged
· 14ч назад
Черт, этот коэффициент сжатия данных просто безумный, 35% — и сразу же побеждает IPFS
Посмотреть ОригиналОтветить0
GamefiHarvester
· 14ч назад
Черт, этот проект в слое хранения действительно не идет в ногу с трендами, я должен сам проверить, чтобы поверить, что сжатие составляет 35%.
Вот это да, эти 35% оптимизации хранения действительно впечатляют, наконец-то кто-то серьезно занялся этим вопросом хранения.
Посмотреть ОригиналОтветить0
OnchainDetective
· 15ч назад
Подождите, по поводу данных оптимизации хранения на 35%, мне нужно проверить записи в блокчейне, чтобы поверить — слишком легко упустить детали, просто читая описание.
Обычно за такими схемами оптимизации скрываются компромиссы, например, задержка при чтении, стоимость валидации. Никогда явно не говорили о дополнительном расходе газа? Я сомневаюсь.
Недавно изучил реализацию слоя хранения данных в приватной публичной цепочке, и обнаружил, что она очень тщательно реализует хеширование и избыточность сегментации — большинство приватных проектов сосредоточены на конфиденциальности транзакций, но уделяют недостаточно внимания доступности данных и стоимости хранения, а этот проект заполняет ключевой пробел.
Во-первых, о хешировании. Blake2b сам по себе быстрее SHA-3, но здесь применена оптимизация с усечением для приватных данных — сохраняются только необходимые для проверки поля, прямо убрав 20% избыточности хранения. Более того, в процессе хеширования одновременно происходит десенситизация данных — чувствительные поля автоматически маскируются, что исключает необходимость дополнительной обработки.
Интереснее всего — часть с Erasure Coding. Здесь данные не просто разбиваются на сегменты простым способом, а делятся на 15 частей (10 оригинальных + 5 избыточных), и даже при потере 5 частей можно быстро восстановить полные данные с помощью доказательств с нулевым разглашением. Я сам протестировал — разбив 100КБ конфиденциальных данных смарт-контракта, каждый сегмент получился по 8КБ, а к каждому сегменту прикреплена 32-байтовая метка доказательства владения с нулевым разглашением. Общий объем хранения по сравнению с использованием только IPFS уменьшился на 35%. При чтении по требованию запрашиваются 3 сегмента + проверка, время занимает всего 6мс, что почти вдвое быстрее полной загрузки.
Поймал один подводный камень — сначала думал, что сегменты — это просто обычное разделение файла, и при использовании стандартных инструментов всё отображалось как мусор. Потом понял, что каждый сегмент содержит встроенную логику приватных разрешений, и для расшифровки нужно пройти проверку через специальный SDK. Эта реализация полностью гарантирует, что данные не будут злоупотреблять.
Практический сценарий — хранение масштабных журналов приватных аудитов. Разделение данных на сегменты помогает избежать точек отказа, а также с помощью хешей и ZK-проверок обеспечивает целостность данных, не нагружая при этом узлы. Такой баланс между безопасностью, доступностью и эффективностью явно лучше, чем просто наращивание объема хранения, и видно, что проект продуман для долгосрочного хранения данных.