Recently, the rise of blockchain technology is generating a high-demand for “blockchain application developers”. One might think that a blockchain application developer be typically a software developer with additional expertise in programming languages for smart contracts (e.g., Solidity, Golang) and libraries for posting transactions on a blockchain (e.g., bitcoinlib). Indeed, any software developer knows how to write programs that exchange messages over the network. Such skills can be ported seamlessly into the blockchain setting when the blockchain is abstracted simply as another communication channel. Therefore, one can fall into the naive conclusion that developing blockchain applications simply boils down to learning a new programming language and/or a library.
Unfortunately, the above natural and easy route could easily bring to a precipice.
Indeed, just like a competent software developer needs to know the mechanics of computation and network communication to develop software that does not stall/go in overflow or suffers of DoS attacks, a blockchain application developer should know the mechanics of the underlying non-trivial protocols used to read and write on a blockchain. Such protocols involve consensus protocols that rely on incentives and game-theoretic analysis on the behaviors of the participants to the computation. Unawareness of such details can lead to the development of unsafe blockchain applications.
To see what can go wrong in a sloppy view of the blockchain as a naive communication channel, consider the following toy example. Two players, Alice and Bob, would like to publicly compute a random bit. Blum proposed in  the following classical protocol for privately establishing a random bit. First of all, Alice commits to a random bit b that remains hidden to Bob, but that can not be changed anymore by her in the future.
Bob then sends to Alice a random bit c. Finally Alice reveals b to Bob and they consider the bit d = b XOR c as their shared random bit. A naive blockchain application programmer might be tempted to implement the above three steps through a smart contract and a software that Alice and Bob can use to generate the above three sequential transactions. The bad news is that the above implementation might end up in a disaster when transactions are played too fast. Indeed, notice that the above three transactions could appear in three consecutive blocks. Assume that the blockchain forks right after the block including the commitment of b, and that one of the two branches quickly reaches the computation of d. Now Bob would have a chance to decide whether to play the same or a different value for c in a different branch, therefore deciding completely the bit computed as output of the protocol in this other branch. Therefore such implementation of Blum’s protocol on a forking blockchain is a failure since the outcome could converge towards Bob’s desired output.
Notice that a blockchain application programmer that is also an expert of the details of the
underlying blockchain would know exactly after how many blocks a transaction can be considered confirmed and thus would add to the code of Alice some delays during the sequence of transactions. Indeed, Alice should reveal b only when c is final in the blockchain. This would prevent the above unfair behavior of Bob. One might argue that the entire execution of the code produced by such competent blockchain application developer can be very slow. While this is a legitimate concern, we note that this is a price that one might want to pay in order to get a robust implementation in terms of output distribution. Moreover, a recent work of Friolo et al.  shows how to get both efficiency and security in several blockchain applications (including the generation of a random bit) when running public transactions on forking blockchains.
The problem of ignoring the details of the underlying blockchain is not just about the subtlety of delayed confirmations of transactions. Several other traps can be around. Indeed in  Scafuro et al. have shown that some blockchain applications (i.e., publicly verifiable proofs) could be secure on some blockchains, but completely insecure in some other natural blockchains where honest players are willing to reveal their keys for revenues that are higher than the values of the coins stored in their wallets. Therefore this is another example where knowledge of the mechanisms that regulate the underlying blockchain significantly impacts on the design and implementation of blockchain applications.
In conclusion, the competence on software development and good knowledge of a specific programming language/library for smart contracts and blockchain transactions are important but still very insufficient when developing blockchain applications. Expertise on what blockchains are and how they work is a must and significant resources should be invested to educate and upgrade software developers in these new scenarios.
 Manuel Blum. Coin flipping by telephone a protocol for solving impossible problems. ACM SIGACT News - A special issue on cryptography. Volume 15 Issue 1, Winter-Spring 1983, Pages 23-27, ACM, New York, NY, USA.
 Vincenzo Botta, Daniele Friolo, Daniele Venturi, Ivan Visconti: The Rush Dilemma: Attacking and Repairing Smart Contracts on Forking Blockchains. IACR Cryptology ePrint Archive 2019: 891 (2019).
 Alessandra Scafuro, Luisa Siniscalchi, Ivan Visconti. Publicly Verifiable Proofs from Blockchains. In Proceedings of the 22nd IACR International Conference on Practice and Theory of Public-Key Cryptography, Beijing, China, April 14-17, 2019. Lecture Notes in Computer Science 11442, Pages 374-401, Springer 2019.
Written by Ivan Visconti, The University of Salerno