BlockchainInterface abstraction and its "fly in the ointment" #782

Excursion: There is a course with the BlockchainInterface trait we need to strive to maintain straight. It bears on the widest range of possibilities to be held for implementations of that interface on different, and possibly even fundamentally different, chains. We do not want to allow it tied up with bonds to the Web3 standards. That would stub our visionary. The other chains and their architecture, terminology, simply their interface, won't match the same principles as it works in Web3. For these specific, very own features of any chain, our trait must represent a mask that can let you interact with them all, pointing out their commonalities and abstracting the details away.

As a reference to the above, I noticed a thing on the BlockchainInterface that has an issue with the rules. Although this takes also its method .contract(), that is a milder example of it as opposed to the other method called .get_transaction_receipt(). That one uses complex data structures from the web3 library as the return type. It is going to cause certain troubles. Unlike to that, we should have our own structure that could convey the same kind of information we take from the current complex structure. All we might need is actually a boolean saying if the particular transaction can give us enough confidence to marking it as complete. One can imagine a translation of any chain-native type of various complexity into an enum of three variants (Pending|Complete|Failed).

Remember you'll have to keep track of the transaction hash so that it is clear what transaction the confirmation belongs to.

In the light of what was just said, it quite makes sense that even the name of the method could undergo some changes.
Thinking of the ultimate purpose, it only is to confirm the transaction being a firm part of the blockchain, and therefore the money transfer as done. .get_transaction_confirmed seems like a solid attempt. However, there is another thing, the design of this method is rather poor in overall, we actually want to request multiple confirmations in a single RPC, because asking one by one is obviously non-economical, also it's not good in terms of our activity monitored by the blockchain service endpoint in use, and to get rate-limited might be theoretically achievable. There is a card that discuss this a bit further: #708. Consider merging these two cards if you thing the response should contain all the discoveries inside a single struct or you can play them separately, planning on taking hold of a vector: Vec<ConfirmationStatus>.

Mentioned before, the method .contract() also brings a risk as the type it returns is directly from the web3 library. Consider to take some actions here too.