4 ms·

See https://github.com/pixelspark/catena https://github.com/pixelspark/catena for a SQLite-on-blockchain implementation

• api 7y ago
  We found stuff like this while researching before creating LF. I remember finding this exact project and a few others like it. This is in the ballpark but has numerous issues in a federated or fully decentralized use case, such as who sets database schema and what happens when you need to change it. It also lacks any privacy protections. All keys and values are visible to everyone all the time. That opens up a ton of attack surface that has to be specifically mitigated on a case-by-case basis. Better to have data be blind. LF isn't a wrapper around SQLite at all. It just uses SQLite for meta-data and index information because it happens to be a very capable database and because the ability to do relational queries saves a ton of time vs. hand-rolling such queries on top of something like LevelDB. The last issue is something I've never understood about cryptocurrency code bases. Why do they insist on implementing a slow ad-hoc relational model on top of a simple KV store when they could just use SQLite? I assume it's because they assumed SQLite would be slow, but it's really not unless you are doing massive numbers of writes.