<j​airbolsonaro:nope.chat> Greetings to all the people who helps making Monero such a great crypto.

<j​airbolsonaro:nope.chat> I have a question about Monero's database choice. As said by some valuable contributors in the #monero channel, LMDB has a lot of write amplification for this specific use case. Since most blockchain data is immutable (as an example key:block hash value:block data blob), why not just creating an append-only database file for immutable data (that's the majority of data stored in da<clipped message>

<j​airbolsonaro:nope.chat> tabase, as far as I know) that contains all the values, and keeping a simple index that saves the keys and the position of their values in the append-only file? It would have literally no write amplification and the best performance possible with purely sequential writes, the only downside is that values can't be deleted efficiently or modified (their length can't change) (at leas<clipped message>

<j​airbolsonaro:nope.chat> t not without recompacting the whole database). Which is not the case for most of the blockchain data.

<j​airbolsonaro:nope.chat> Thanks in advance.

^ this has been done in cuprate

<s​yntheticbird:monero.social> Just like DataHoarder said

<s​yntheticbird:monero.social> see Cuprate/cuprate #566

<s​yntheticbird:monero.social> and github.com/Cuprate/Tapes

<r​iceandbeans:matrix.org> What’s the benefit of cup rate over the official node?

Much more modern code. There are good chances it's quite a bit faster in some respects, e.g. sync from genesis / full blockchain download.

DataHoarder: How does the db work on reorgs? Just drop everything up to a height and continue from there?

see above links. but the tape is append-only, but has random read

so you can just change your index lookups

(got some lag sry)

In darkfi we opted to write delta logic on top of our db so we do reverts

It's probably sacrificing some speed but it's very convenient

We have to maintain a lot more state since each smart contract can have an arbitrary number of its own k/v trees, and the deltas allow us atomic commits

Both rewind and forward

<b​oog900:monero.social> We would first pop the blocks by changing the lengths of the tapes in the metadata then commit, then we have to wait for readers still reading the old blocks, once all readers have finished/have seen the pop we overwrite the old data.

Yeah it makes sense for the Monero usecase

Your transactions don't "delete" any existing state

<r​iceandbeans:matrix.org> Isn’t most of the speed issue with syncing disk io?

<b​oog900:monero.social> For HDD, yes, however Cuprate is using LMDB too, the new db hasn't been merged, and we are still significantly faster.

<r​iceandbeans:matrix.org> Also will or does it implement identical API ?

<b​oog900:monero.social> The RPC is still a WIP but we aim to match monerod's API there as much as we can

<r​iceandbeans:matrix.org> I was planning on standing up a few nodes for accepting and validating receiving xmr as payment and personally I’m more of a Rust than C++ guy but if I can’t interface to it in the same way then I’m not sure I can use it

<r​iceandbeans:matrix.org> How far off would you say it is for standard RPCs?

<j​airbolsonaro:nope.chat> there's no RPC yet. if you need RPC don't use cuprate

<b​oog900:monero.social> Hard to say, I would hope we will have a release with full wallet support within the first few months of next year.

riceandbeans: you can interface with the C++ node with its JSON-RPC API

you don't necessarily need to leave your language

though cuprate's underlying code is good for some things you don't wanna waste a RPC call for

<r​iceandbeans:matrix.org> Like what?

<r​iceandbeans:matrix.org> Yeah I’ve got quite a lot of Rust written for my services