Trie values returning null after reboot?

[faustbrian]

Indeed me being dense the root has to be manually restored. Maybe this could be improved by introducing a decorator like new PersistedTrie(new SecureTrie()) which then takes care of writing the root to and reading the root from disk? Might be a nicer DX than everyone coming up with their own way of persisting the root and manually restoring it. Is there any mention in docs that it has to be restored manually?

---

So I'm attempting to use the trie package to store some persistent data that I need to access as soon as my application launches but something seems to be amiss here, probably me being dense. I'm creating a ClassicLevel instance that I pass to SecureTrie, then log that the value is null, then store key with a value of one and finally log that the value is one. That's all fine but then when I run the exact same script again key is again null instead of one as I would expect because in the first run we finished the script with key being one and we are using a LevelDB implementation with persistence.

const { SecureTrie, LevelDB } = require('@ethereumjs/trie')
const { ClassicLevel } = require('classic-level')

const level = new ClassicLevel('./db')
const root = new SecureTrie({ db: new LevelDB(level) })

async function test() {
  // the first time we run this script this should be 'null'
  // the second time we run this script it should be 'one' (because of the 'put' call) but it isn't
  console.log(await root.get(Buffer.from('key'))) // null

  await root.put(Buffer.from('key'), Buffer.from('one'))

  console.log((await root.get(Buffer.from('key'))).toString()) // one
}

test()

The value can be accessed directly via Level so it is in the database. I assume it's because the root is not set after relaunching so it falls back to the KECCAK256_RLP value but how would the root be initialised so that all data from previous runs is accessible? Should this happen automatically or do I need to manually restore the root?

try {
    console.log(await level.get(Buffer.from('401fb497d3e347e3d480e3137b1372491314d54a46f764e0bf00336649feb6c6', 'hex')));
} catch(e) {
    console.log(e)
}

I'm probably just being dense and not seeing what's wrong or is it right that key should be null when I run the script a second time even though the first run finished with persisting key with a value of one? Do I always have to manually restore the root?

[acolytec3]

From looking at the base trie class constructor, you need to pass in a root hash or it defaults to KECCAK256_RLP. There's no logic in the trie class for finding the previously set root in the DB at present.

[faustbrian]

Yeah figured that after taking a closer look. Maybe this could be improved by introducing a decorator like new PersistedTrie(new SecureTrie()) which then takes care of writing the root to and reading the root from disk? Might be a nicer DX than everyone coming up with their own way of persisting the root and manually restoring it. Is there any mention in docs that it has to be restored manually?

[g11tech]

yes, there is not a provision to save "head" root or so, but you may save the head root in the db with a key and recover (which i am sure you would be doing now)

[faustbrian]

Ended up storing it outside of the DB so that only the trie instance touches the DB but I think it would be nicer if there was some way for the trie itself to store and restore the root after every put and batch or by manually calling some method that persists it.

[acolytec3]

I don't see anything so thank you fro calling this out. I like the idea of adding a new flag to constructor options to persist the root to disk so will explore this route (as opposed to creating a whole separate subclass) as I can see this being a useful option across all trie based classes.

[faustbrian]

Let me know if you come up with anything that satisfies you in terms of architecture and I can take a look at implementing it.