Blockchain transaction issues

Blockchain transaction issues

This problem is a typical distributed transaction problem, since the blockchain belongs to the distributed category, so the blockchain also has a transaction problem.

Here I am going to analyze this problem from a programmer's point of view:

When doing business systems that interact with blockchain, such as Nodejs-based web3 tools and Etherum Ethereum only contract interactions, we often use asynchronous mechanisms such as ES6 promise to interact with the blockchain in an attempt to improve interaction efficiency. This is really a good practice, and it is worth noting that irrational use will bury a lot of bugs, and these bugs will appear randomly, sometimes explode, and sometimes not.

This unstable code, you can conclude that there is a certain probability because of irrational use of asynchronous requests caused.

For example, you write a business logic, and this business logic requires "transactional integrity" (that is, your code, either all successfully executed, or all failed or executed rollback).

The blockchain, in accordance with the CAP theory, satisfies the final consistency and partition fault tolerance, and does not have availability (each request will not be error-free, but is not guaranteed to be up to date)

So, when you initiate a request to the blockchain system, you either get the latest data or give an error.

So when you make a request, if you make an error, you have to try again until you succeed.

And we just said that if your code requires transactional integrity, this time, if the transaction executes half of the error, you can either retry the request several times in the error area until it succeeds, and then roll back your previous modifications.

But in any case, don't let the business run half-dead. Because Schrödinger's cat