@JuanFuentes Hi Juan! Yes, that's not quite “ripe” enough for a question on the main site.

It's not quite clear to me what the goals of using a Blockchain would be here. At first approximation, a blockchain is a distributed database where every participant has access to the entire data + full history, and where the order of transactions/events can be cryptographically verified. This prevents undetected tampering with the history at a later point in time.

Here, the first questions would be what kind of data you'd store on the blockchain, and who the participants would be (who gets access to this data?). If you record your (user, type, points) records in a blockchain, should every other user have access to this info?

If your app's backend were the only participant on the blockchain, it's effectively a centralized system and blockchain has very limited value.

@amon Yes, every user should have access to the points. That's the main reason why I'm considering blockchain, I want the points system to transparent and auditable to the community

@JuanFuentes But who will participate on the blockchain and validate new blocks? Would users care enough to run their own nodes? Wouldn't it be trivial for you to mount a 51% attack and rewrite history as you see fit? In that case, wouldn't it be simpler to offer a publicly accessible API with all of this data, e.g. similar to SEDE here on StackExchange?

Didn't think about that, doesn't seem that much feasible anymore

Not all is lost. It is possible to provide some auditability also in a centralized scenario. But this depends on which properties you want to guarantee.

E.g. validating that only correct data is stored is a very difficult problem.

But validating that data once written was never changed/manipulated is much easier.

E.g. a central database broadcasts a checksum of the most recent transaction block. Other participants can record the sequence of checksums. Each block contains the previous hash, thus building a blockchain.

Other participant can record the stream of checksums, without recording the actual blocks (or maybe only keeping the N most recent blocks).

Later, participants can request a block B from the central database, and check that it (together with the previous hash) still match the expected checksum. This at least forces the central database to keep the original history on file, but of course doesn't ensure that this data is also being used for other computations.

Note that the Git version control system uses such a chain of checksums for its commit data structure. This makes it possible to perform integrity checks on a repository, though in the version control context bitrot is usually a bigger threat than malicious history changes.