12:11:06 Greetings to all the people who helps making Monero such a great crypto. 12:11:06 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 12:11:08 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 12:11:10 t not without recompacting the whole database). Which is not the case for most of the blockchain data. 12:11:12 Thanks in advance. 12:14:21 ^ this has been done in cuprate 12:24:24 Just like DataHoarder said 12:24:25 see https://github.com/Cuprate/cuprate/pull/566 12:24:31 and https://github.com/Cuprate/Tapes/ 17:35:04 What’s the benefit of cup rate over the official node? 17:37:08 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. 17:39:44 DataHoarder: How does the db work on reorgs? Just drop everything up to a height and continue from there? 17:40:11 see above links. but the tape is append-only, but has random read 17:40:20 so you can just change your index lookups 17:41:49 (got some lag sry) 17:42:15 In darkfi we opted to write delta logic on top of our db so we do reverts 17:42:29 It's probably sacrificing some speed but it's very convenient 17:43:44 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 17:44:04 Both rewind and forward 17:47:37 https://github.com/parazyd/sled-overlay 18:08:23 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. 18:11:43 Yeah it makes sense for the Monero usecase 18:12:00 Your transactions don't "delete" any existing state 19:33:22 Isn’t most of the speed issue with syncing disk io? 19:39:19 For HDD, yes, however Cuprate is using LMDB too, the new db hasn't been merged, and we are still significantly faster. 19:40:05 Also will or does it implement identical API ? 19:41:30 The RPC is still a WIP but we aim to match monerod's API there as much as we can 19:41:42 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 19:42:51 How far off would you say it is for standard RPCs? 19:45:46 there's no RPC yet. if you need RPC don't use cuprate 19:48:25 Hard to say, I would hope we will have a release with full wallet support within the first few months of next year. 19:49:02 riceandbeans: you can interface with the C++ node with its JSON-RPC API 19:49:11 you don't necessarily need to leave your language 19:49:44 though cuprate's underlying code is good for some things you don't wanna waste a RPC call for 21:37:23 Like what? 21:37:50 Yeah I’ve got quite a lot of Rust written for my services