🤯 Cognitarium: Prevent blank nodes conflicts

[amimart]

When inserting triples, avoid same blank nodes being reused across insertions.

Issue description

Blank nodes allowing to create edges in graphs at insertion, their meaning is only linked to the set of triples being inserted and shall be ensured unique per insertion. Allowing to define same blank nodes across multiples insertions could affect previous ones and therefore alter unintentionally the data contained.

When inserting blank nodes, they shall be ensured unique scoped per insert message execution.

Proposal

In order to provide unique blank nodes at insertion, their identifier shall be formed with the context of this particular execution. I propose so to prefix alter their ids before writing by prefixing them with a hash representing the execution context, which shall carry the block height, the index of the transaction the message come from, and the insert message itself.

[ccamel]

I complement what I've commented here: #494 (comment)

I agree with defining a method for generating blank node identifiers that ensures: uniqueness,determinism and efficiency.

Yet, I have reservations about employing hashing for this purpose. Why not opt for a straightforward counter for blank nodes, using a uint64? Since there is no need to reuse identifiers once they are freed, this approach seems more straightforward. It would be more efficient, require less computational effort, and use less storage space (8 bytes for a uint64 versus 32 bytes for a sha256 hash).

[amimart]

I complement what I've commented here: #494 (comment)

It is indeed way more appropriate to use a simple counter for that purpose. As a matter of consistency maybe we should use uint128 as for namespaces (i.e. https://github.com/okp4/contracts/blob/9a7d145ce9aefbacf33cb34e51da7781cef5e95b/contracts/okp4-cognitarium/src/state/namespaces.rs#L10) ?

[ccamel]

@amimart yes that's perfect. 😌