Высокопроизводительный публичный блокчейн — это нечто вроде кошмара: состояние взрывается.
Каждая цепочка с высоким TPS сталкивается с одной и той же проблемой: чтобы проверить транзакцию, узлы должны держать всё более мощное аппаратное обеспечение для хранения исторической книги, и в итоге контроль над валидацией всё больше концентрируется, а децентрализация постепенно превращается в лозунг. Ethereum пытался найти решение, например, предложение EIP-4444 предполагает обрезку исторических данных, но что делать с удалёнными данными? Неужели их нельзя просто исчезнуть?
Именно поэтому нужен специальный слой хранения. Когда мы разрабатываем новые цепочки приложений, мы используем простую, но эффективную стратегию: оставлять только последний корень состояния на уровне выполнения, а все исторические блоки и подтверждения транзакций полностью выгружать в Walrus. Благодаря модульной архитектуре взаимодействия мы на уровне выполнения храним только Blob ID Walrus в качестве указателя — легкий индекс.
Результат очевиден. Объем хранения для полного узла значительно снижается, слой консенсуса может работать быстрее, исторические данные не теряются, а возможность аудита сохраняется. Это не оптимизация какого-то компонента, а переосмысление всей архитектуры системы — сосредоточить вычисления на вычислениях, а хранение — на хранении, выполняя каждую функцию в своём месте. Жёсткий диск не должен находиться в центре вычислений, он должен играть свою роль в специально отведённом месте системы.
Отказ от ответственности: данная статья представляет только техническое мнение и не является инвестиционной рекомендацией.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Высокопроизводительный публичный блокчейн — это нечто вроде кошмара: состояние взрывается.
Каждая цепочка с высоким TPS сталкивается с одной и той же проблемой: чтобы проверить транзакцию, узлы должны держать всё более мощное аппаратное обеспечение для хранения исторической книги, и в итоге контроль над валидацией всё больше концентрируется, а децентрализация постепенно превращается в лозунг. Ethereum пытался найти решение, например, предложение EIP-4444 предполагает обрезку исторических данных, но что делать с удалёнными данными? Неужели их нельзя просто исчезнуть?
Именно поэтому нужен специальный слой хранения. Когда мы разрабатываем новые цепочки приложений, мы используем простую, но эффективную стратегию: оставлять только последний корень состояния на уровне выполнения, а все исторические блоки и подтверждения транзакций полностью выгружать в Walrus. Благодаря модульной архитектуре взаимодействия мы на уровне выполнения храним только Blob ID Walrus в качестве указателя — легкий индекс.
Результат очевиден. Объем хранения для полного узла значительно снижается, слой консенсуса может работать быстрее, исторические данные не теряются, а возможность аудита сохраняется. Это не оптимизация какого-то компонента, а переосмысление всей архитектуры системы — сосредоточить вычисления на вычислениях, а хранение — на хранении, выполняя каждую функцию в своём месте. Жёсткий диск не должен находиться в центре вычислений, он должен играть свою роль в специально отведённом месте системы.
Отказ от ответственности: данная статья представляет только техническое мнение и не является инвестиционной рекомендацией.