I was thinking about the custom_json part yes.
You could make it a linked list so you could even query it from the chain quickly (each new posted record references the block and tx id of the last record).
That wouldn't require for them to store it in a DB and wouldn't require smart contracts.
That's a good point. And actually, all you need is the referenced
block_num
and you can infer that it contains at least one related transaction. You would avoid storing thetrx_id
to save oncustom_json
op size, which is pretty cramped right now.I guess the only problem with that is if you write records asynchronously with more than one thread. Even if there's only one thread, if that thread crashes after successfully broadcasting a valid record, but before storing the current state, that valid record will become an orphan in the list.
Yeah, the only problem is parallelism. You'd have to enforce serialization on the server which does the writing.
You don't even have to use the tx_id, you could use the tx number in the block.