Recent Cracks / Hacks on Ethereum

Let's be honest, I would not say much about the recent hacks which the websites are hacked and then a fake Ethereum address is given to the ICO buyers. These hacks are socially engineered, and while these are problems they are not as bad as the Infamous Cracks / Hacks that had happened to Ethereum.

Specifically the first DAO hack happened on June 2016. I believe that the many hacks that have happened after that may belong to this nature as well - the main thing to understand here is the concept of Semaphoring.

In a typical computer science degree course, the concept of semaphoring would have been covered. Basically it is a simple concept, when a process is working on a variable, the semaphore is turned on to lock any other potential concurrent access from any other processes that may change the value.

Why is that a problem? Let me illustrate with an example.

Let's define a simple example of transferring balance from account A to account B, of an amount of x. This is written in easy to read English pseudo code to widen the potential readership of this article.

transfer (A,B,x) {

1. confirm A has x ;
2. increase B's balance by x;
3. minus A's balance by x ;
   }

Now the problem is when this transfer function is executed multiple times concurrently especially without a semaphore to control the access, you have serious problem.

Assuming now x is a USD 1,000,000 and A does have USD 1,000,000 inside the account. If you can execute these few functions concurrently;

transfer (A, B, USD 1,000,000)
transfer (A, C, USD 1,000,000)
transfer (A, D, USD 1,000,000)
transfer (A, E, USD 1,000,000)
transfer (A, F, USD 1,000,000)

Technically it is possible to transfer USD 5,000,000 to accounts, B, C, D, E and F from account A that has only USD 1,000,000.

This problem is easily resolved and known by something that all undergrads of a typical computer science degree. It is called semaphoring.

transfer (A, B, x) {

1. check whether semaphore variable b is switched on.
2. if on(b) then sleep for a while, then goto 0 again.

else if (noton(b)) then proceed {

1. confirm A has x ;
2. increase B's balance by x;
3. minus A's balance by x ;
   }
   }

That is to implement semaphoring right into the function. However, to make it even more foolproof, the semaphoring is something to be enforced by the whole system. The whole system should not even require the programmer to remember to check for the semaphoring, it should have checked beforehand before any functions can access prized account information for the purpose of transferring balances.

What shocks me is that Ethereum does not have this! I certainly do not know whether this forced control has been implemented already, but it worries me that such a breach can go through. Rather than blaming the Solidity programmer for not remembering to check the semaphoring, the whole software framework should have restricted the concurrent access to a variable.

I would be happy to hear your thoughts on this matter. Thank you very much.