LevelDB и триоподобные структуры, сохраненные в них, улучшают обход
В настоящее время я работаю над реализацией Modified PatriciaTree в Java-реализацию. Я нашел реализацию ethereum здесь: https://github.com/ethereumj/ethereumj/tree/master/ethereumj-core/src/main/java/org/ethereum/trie.
Я хочу сохранить сгенерированные значения ключей в хранилище значений ключей, а именно LevelDB. Но я наткнулся на вопрос, на который, похоже, не могу найти ответ.
Из-за внутренних свойств дерева Патриции, оно имеет большую O-поисковую запись O(log N). Но как, когда значения ключа дерева хранятся в хранилище значений ключа, LevelDB знает, что, когда выполняется первый поиск узла, он может пропустить x количество записей из-за того, что эти данные не имеют быть просмотренным из-за дерева Патриции, как структура данных, которая хранится в LevelDB? Я полагаю, что он этого не знает, и он просто снова начнет просматривать все хранилище LevelDB, но чем вы полностью потеряете возможности поиска по хранению данных в древовидной структуре Патрисии?
Как ethereum делает это, они создают полное дерево с нуля, просто получая данные из LevelDB и затем анализируя их в виде дерева, похожего на три, который работает в EVM?
Заранее спасибо.