feat(platform)!: identity nonce for Data Contract Create

[QuantumExplorer]

Issue being fixed or feature implemented

Tenderdash keeps in its recent memory a list of recent transaction hashes that the ABCI rejected. If a data contract creation was rejected by the ABCI application that data contract could not be reregistered.

Up till this Pull Request Data Contract Creation was using a random 32 byte number for entropy. This was to ensure that the id would be pseudorandom, since a hash of H(owner_id, random_32_bytes) would be random. A naive approach would be to just change the entropy we used to use each time between failed contract submissions. However this is not ideal for three reasons :

• The first is that doing so would change the id of the data contract. Hence making any offline documents signed and referring to that data contract invalid until they were fixed and resigned.
• The second is that there is no easy way to do a check_tx validation against replay attacks. Up till now, the way to prevent a replay attack on this specific state transition would have been to check to see if the contract existed. This would pull the entire data contract into memory (potentially could be solved)
• The third is that changing the entropy would allow the previous state transition to still be accepted at a later date (for example when the identity had enough balance). However with identity nonces, the identity nonce is saved so the previous state transitions creating the contract can never be replayed and seen as valid.

As a todo for a future PR: We should send back proofs of identity nonce insertion but of absence of data contract to prove to clients that they should retry their state transition.

What was done?

Entropy was removed from Data contract state transitions. This was replaced by the identity nonce.

How Has This Been Tested?

All tests passing.

Breaking Changes

This is a breaking change that removes entropy.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

[shumkov]

Isn't just introduction of identity nonce for Create Data Contract Transition solves the reply attack problem?

On check tx we do identity, signature and nonce validation. If nonce already taken - we just reject the ST.
On prepare proposal we do state validation where we make sure that such ID is not taken yet. If it's already taken then such state transition is invalid and user pays for validation.

That's how it currently works for documents. An additional change with using identity nonce as part of Data Contract ID doesn't affect the actual solution of the problem.

Currently, we use entropy for contracts, documents and probably other entities in future. It's done to enable offline-first applications that can create entities even offline and then sync local application state with the network when the app has connection with internet. It calls client side generated ID. If we introduce a nonce to ID then you won't be able to create entities without internet connection, or you will need to update somehow entity IDs when they "expire" (nonce will be incremented when you for example working from another device or browser tab). I don't think that offline-first frameworks have such capability.

In the essence, this special logic to create ID with nonce for Data Contracts:

1. Introduce additional complexity to the system
2. Harms developers experience who is building offline-first applications (this is a very trending and global division nowadays).

Could you please explain what are actual benefits of introducing nonce instead of entropy that worth that additional change to the system and these two downsides above?

I would recommend to extract in a separate PR actual solution of the problem (adding and validating nonce for Data Contract Create Transition) and merge it ASAP. I can prepare a branch for you pretty quick. If you don't agree or not willing to do that I'm not going to block merging this PR anyways.

Not going to block merging this PR anyways

[QuantumExplorer]

After a call between me and Ivan I think it is safe to say that we have a disagreement on this topic. I for one think this reduces complexity to the system and also allows a sure way to prove that a contract creation happened or did not, since we can prove existence or non existence of the item in conjunction with the the nonce that created it. If it does not exist we prove that we should use a new nonce and resubmit the contract create state transition.

If we were to use entropy then when we would get a proof that the item was in the state we would not be sure that it was the result of our state transition as it could have been created by a different state transition. Ivan argues that looking at the contents should suffice, but I argue that that's even more complicated and has edge cases.

In the end I believe this argument is a waste of time and that time would be better used continuing on more important tasks. I do not think users are going to want to use contracts in offline mode that haven't been submitted and validated by the network. And I believe that allowing users to do so is probably incorrect.

I am merging this one in.