Simple Serialize

Simple Serialize (SSZ) — это формат сериализации данных и схема хеширования, разработанный для использования в протоколе Ethereum 2.0 (сеть Beacon Chain). SSZ обеспечивает детерминированное представление сложных структур данных в виде последовательности байтов, а также служит основой для вычисления криптографических хешей (корней Меркла) и создания доказательств с нулевым разглашением. В отличие от более старых форматов, таких как RLP (Recursive Length Prefix), SSZ ориентирован на простоту реализации, эффективность обработки и однозначность при кодировании.

История

Разработка SSZ началась в 2018 году в рамках перехода Ethereum от алгоритма консенсуса Proof-of-Work (PoW) к Proof-of-Stake (PoS). Основной целью было создание формата, который бы позволял эффективно работать с большими наборами данных, характерными для Beacon Chain, где хранится информация о тысячах валидаторов и их голосованиях. Проект возглавили разработчики Ethereum Foundation, в частности Виталик Бутерин и Дэнни Райан. Первая спецификация SSZ была включена в черновик спецификации Eth2 (позже переименованного в Ethereum 2.0) в 2019 году. С момента запуска Beacon Chain 1 декабря 2020 года SSZ используется в качестве основного формата для всех сообщений, блоков и состояний сети.

Принципы работы

SSZ основан на двух ключевых концепциях: типизированном представлении данных и фиксированном размере полей. Каждый тип данных (число, массив, структура) имеет строго определённый способ кодирования, что исключает неоднозначность при десериализации. В отличие от JSON или XML, где порядок полей и типы могут быть произвольными, SSZ требует заранее заданной схемы (типа), что повышает предсказуемость и скорость обработки.

Типы данных

SSZ поддерживает следующие базовые типы:

• Целые числа (uintN): беззнаковые целые числа фиксированной длины (например, uint8, uint16, uint32, uint64, uint128, uint256). Кодируются в little-endian (от младшего байта к старшему).
• Логические значения (bool): кодируются как один байт (0x00 для false, 0x01 для true).
• Байтовые последовательности (bytesN): фиксированные массивы байтов длины N (например, bytes32 для хешей SHA-256).
• Адреса (address): 20-байтовые значения, эквивалентные bytes20.

Составные типы

• Векторы (Vector[T, N]): фиксированные массивы элементов одного типа T длиной N. Кодируются последовательным размещением элементов.
• Списки (List[T, N]): динамические массивы элементов одного типа T с максимальной длиной N. Кодируются как вектор, но с дополнительным префиксом длины (offset) в начале.
• Структуры (Container): именованные наборы полей разных типов. Кодируются последовательным размещением полей в порядке их объявления.
• Union: тип-объединение, позволяющий хранить один из нескольких вариантов. Кодируется с префиксом-идентификатором варианта (selector) и последующим телом.

Процесс сериализации

Сериализация объекта в SSZ выполняется в два этапа:

1. Линеаризация: все поля структуры или элементы массива преобразуются в последовательность байтов в соответствии с их типами.
2. Упаковка (для хеширования): байты группируются в чанки по 32 байта (размер хеша SHA-256), и к каждому чанку применяется хеш-функция для построения дерева Меркла.

Пример кодирования простой структуры

Рассмотрим структуру Validator с полями:

• pubkey (bytes48)
• withdrawal_credentials (bytes32)
• effective_balance (uint64)
• slashed (bool)
• activation_eligibility_epoch (uint64)

При сериализации поля кодируются в порядке объявления: сначала 48 байт pubkey, затем 32 байта withdrawal_credentials, затем 8 байт effective_balance (little-endian), затем 1 байт slashed, затем 8 байт activation_eligibility_epoch. Итоговая длина — 97 байт (48+32+8+1+8).

Хеширование и дерево Меркла

SSZ использует модифицированное дерево Меркла (Merkle tree) для вычисления корня (root) объекта. Процесс включает:

1. Разбиение на чанки: сериализованные данные делятся на блоки по 32 байта. Если последний блок неполный, он дополняется нулями.
2. Построение дерева: каждый чанк хешируется (SHA-256), затем пары хешей объединяются и хешируются рекурсивно до получения одного корневого хеша.
3. Использование смещений: для списков и структур с динамическими полями добавляются «смещения» (offset), которые указывают на начало данных. Это позволяет строить дерево Меркла даже для объектов с переменной длиной.

Корень SSZ используется для:

• Верификации целостности данных (например, при проверке блоков).
• Создания доказательств Меркла (Merkle proofs), которые позволяют подтвердить наличие определённого значения в структуре без раскрытия всей структуры.
• Генерации хешей для подписей и голосов валидаторов.

Применение в Ethereum 2.0

SSZ является неотъемлемой частью протокола Ethereum 2.0. Он используется для:

• Кодирования блоков Beacon Chain: каждый блок содержит заголовок, тело и доказательства, все в формате SSZ.
• Хранения состояния: состояние Beacon Chain (информация о валидаторах, балансах, исторических данных) сериализуется в SSZ и хешируется для быстрой проверки.
• Создания подписей: валидаторы подписывают корни SSZ своих сообщений, что гарантирует неизменность данных.
• Реализации протокола Casper FFG: при голосовании за финализацию эпох валидаторы используют корни SSZ для указания на целевые блоки.
• Работы с доказательствами: SSZ позволяет создавать компактные доказательства Меркла для проверки отдельных элементов состояния (например, баланса конкретного валидатора) без загрузки всего состояния.

Преимущества и недостатки

Преимущества

• Детерминированность: одинаковые данные всегда дают одинаковую последовательность байтов, что критично для консенсуса.
• Эффективность: фиксированный размер полей ускоряет сериализацию и десериализацию, особенно для больших массивов.
• Интеграция с хешированием: SSZ напрямую поддерживает построение деревьев Меркла, что упрощает реализацию доказательств.
• Простота: спецификация SSZ относительно компактна и легко реализуется на разных языках программирования (Python, Rust, Go, C++).

Недостатки

• Отсутствие гибкости: SSZ требует строгой типизации, что делает его менее удобным для произвольных данных, чем JSON или CBOR.
• Размер: для некоторых типов данных (например, списков с множеством пустых элементов) SSZ может быть менее компактным, чем специализированные форматы.
• Сложность отладки: из-за бинарного формата отладка данных в SSZ требует специальных инструментов (например, sszdecode).

Сравнение с другими форматами

SSZ выделяется тем, что он специально спроектирован для работы с криптографическими доказательствами, что делает его предпочтительным для блокчейн-приложений, где важна верифицируемость данных.

Интересные факты

• Название «Simple Serialize» подчёркивает философию минимализма: спецификация SSZ занимает всего несколько десятков страниц, в отличие от сложных стандартов вроде ASN.1.
• SSZ используется не только в Ethereum 2.0, но и в других проектах, таких как Lighthouse (клиент Beacon Chain на Rust) и Prysm (клиент на Go).
• В 2021 году была предложена спецификация SSZ для Ethereum 1.0 (Execution Layer), но она не была принята из-за обратной совместимости с существующим форматом RLP.
• Алгоритм хеширования SSZ (SHA-256) был выбран из-за его широкой поддержки и криптостойкости, хотя в будущем возможен переход на более эффективные хеш-функции (например, BLAKE3).

Критика

Основные критические замечания в адрес SSZ связаны с его жёсткой привязкой к Ethereum 2.0. Некоторые разработчики отмечают, что SSZ избыточен для простых приложений и требует дополнительных библиотек для работы. Кроме того, отсутствие поддержки сжатия данных (например, gzip) может приводить к увеличению размера передаваемых сообщений. Однако для задач, решаемых Ethereum 2.0, эти недостатки считаются приемлемыми.

Источники

• Ethereum Foundation. «Ethereum 2.0 Specifications: Simple Serialize (SSZ)». GitHub, 2020.
• Buterin, Vitalik. «Ethereum 2.0: A Technical Overview». Ethereum Foundation, 2019.
• Ryan, Danny. «Beacon Chain Specification». Ethereum Foundation, 2020.
• «SSZ: Simple Serialize». Ethereum Wiki, 2021.
• Lighthouse Team. «Lighthouse: Ethereum 2.0 Client Documentation». Sigma Prime, 2022.