- Why does smart contract development require a different mindset than regular programming?
Smart contracts are publicly visible and bugs are more difficult to fix than with regular software. So a bug could easily be exploited and while being hard to fix. That’s a dangerous situation. Furthermore are smart contracts in control of money, so the rist is also quire large.
- Argue with your own words why clarity in your code is more important than performance.
Blockchain technology should not be used if performance is your key aspect. Blockchain is much better at security though. In order to keep the smart contracts as secure as possible, they should be easy to read (for other developers, or maybe users who are looking for transparency), easy to test, easy to debug and fix. In order to do so, responsibilities of functions and contracts should be as small as possible and really clear.
- As the article says, all data and functions are public in a smart contract. What false beliefs might someone have around private data and private functions in a smart contract that could have dangerous consequences?
One might think that private functions are not visible to the outside world at all. So someone who thinks like that might store valuable information like secret keys in a private function, which is really bad since those functions ARE publicly visible.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
When writing a smart contract, sometimes one has to make trade-offs between security and software architecture. Most of the times these 2 principles will align and better code structure means a more secure smart contract. However, sometimes, one might have to stray away from the best practices in software engineering to allow a more secure contract.