Структура леджера и процесс закрытия
Как XRP Ledger организует состояние и историю в виде последовательных, неизменяемых версий леджера.
Версии леджера
История XRPL организована как последовательность пронумерованных версий леджера, каждая из которых представляет собой полный снимок балансов аккаунтов и состояния объектов на определённый момент времени, а также список транзакций, применённых для получения этой версии из предыдущей. Новая версия леджера производится примерно каждые 3–5 секунд через процесс консенсуса.
Что находится внутри версии леджера
Каждая закрытая версия леджера содержит:
- Заголовок леджера, включающий его номер последовательности, хеш, ссылающийся на предыдущий леджер, и временную метку.
- Дерево состояния, содержащее каждый аккаунт, его баланс, принадлежащие ему объекты (трастлайны, офферы, эскроу и так далее), закодированные в структуре, подобной дереву Меркла, так что любую часть состояния можно криптографически доказать.
- Дерево транзакций, перечисляющее каждую транзакцию, применённую в этой версии леджера, также в структуре, подобной дереву Меркла.
Процесс закрытия
«Закрытие» леджера — это момент, когда сеть достигает консенсуса по поводу следующей версии и фиксирует её. После закрытия:
- порядок транзакций внутри этого леджера зафиксирован и не может быть изменён;
- итоговые балансы аккаунтов и состояние финальны;
- следующая версия леджера начинает строиться поверх неё.
Поскольку финальность наступает в момент закрытия леджера, а не вероятностно на протяжении множества последующих блоков, здесь нет аналога ожиданию «подтверждений», как в Bitcoin, — транзакция, включённая в закрытый леджер, уже завершена.
Номера последовательности и защитная функция «last ledger sequence»
У каждого аккаунта есть номер последовательности, увеличивающийся с каждой отправляемой им транзакцией, что предотвращает повторное применение или изменение порядка собственных транзакций этого аккаунта. Транзакции также могут указывать значение LastLedgerSequence, после которого они автоматически считаются истёкшими и никогда не будут применены — это позволяет с уверенностью знать, что транзакция либо успешно исполнена, либо окончательно провалилась, а не застряла в подвешенном состоянии.
Полная история против текущего состояния
Для работы XRPL-сервера с полной историей требуется хранить каждую версию леджера вплоть до генезиса, что требует значительных объёмов данных; большинство валидаторов и узлов, обслуживающих API, вместо этого хранят недавнее скользящее окно истории леджера (плюс текущее состояние), если только они специально не настроены как узел с полной историей, — для исторических запросов доступны выделенные серверы полной истории и сторонние архивы.