I recently wrote a post for Threat Modeling Smart Contracts and I think blog post fits the dicussion
Threat Modeling Smart Contract Applications
Hello everyone 
- Why does smart contract development require a different mindset than regular programming?
- The consequences of a coding mistake in a smart contract are bigger than with web development: they can lead to the direct loss of user funds.
- By design smart contracts cannot be upgraded once deployed. Fixing issues in main net or turning off a contract is much more difficult than with server-based enterprise applications. The ability to halt a running contract or the ability to upgrade to a new version have to be designed and coded in advance into the smart contract.
- Because of those aspects the development approach is more like mission-critical software engineering than agile web development: longer iteration cycles, thorough testing, phased rollouts with a view to having zero bug in production.
- Argue with your own words why clarity in your code is more important than performance.
- one way to mitigate the risks associated with smart contracts development is to write very clear code. Advantages:
- it reduces the likelihood of coding mistakes by the programmer
- it makes it easier for the programmer to understand the code logic and prepare the tests around this logic.
- it makes peer-reviews more efficient because other programmers can easily read and understand the code in order to flag vulnerabilities.
- of course performance is important but in the end hacks and attacks are a bigger cause for concern than high transaction fees.
- 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?
- In solidity, private does not mean encrypted or invisible. Private means that you cannot access a contract variable from outside the contract. It is a language feature that improves encapsulation and reduces side effect and coding errors. However this private data exists on the Ethereum blockchain the same way public data does. It is therefore visible to anyone.
- The same goes for private functions. Private functions can be called only from other functions inside the same contrat and cannot be called from outside the contract. However the code inside a private function is visible to anyone.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
- The coding approach should be proportionate to the risks associated with each smart contract on a case by case basis. There are situations where security considerations clash with software engineering good practices (such as upgradability, code re-use and modular structure).
- For instance short-lived smart contracts might not need an upgrade mechanism.
- For high-risk contracts, a design that is very modular could increase the surface of attack and the chances of things going wrong.
- How to manage those tradeoffs should be discussed within the team, taking input from the more experienced devs.
1 Like
-
Blockchain platforms are considered new and highly experimental and therefore security best-practices are constantly evolving as new bugs are discovered. Therefore, we need to develop in a way that allows us to avoid bugs as much as possible and allow for upgrading when they are discovered.
-
The more complexity there is in a system, the greater chance there is for errors. By keeping contracts simple, they may not perform as well as more complex contracts, but the chances of there being a bug will be lower, and if there is a bug, clear simple code will allow us to find it quickly.
-
Private only means private to derived contracts and private data and functions in smart contracts are still viewable on the blockchain by anyone. If someone developed smart contracts with the mistaken assumption that private data and functions are not visible to end-users, they could expose data that is not meant for the end-user.
-
It is most likely because there is no perfect solution when it comes to smart contract security. Therefore, a person developing a smart contract system must identify the proper balance between these tradeoffs based on their priorities.
1 Like
-
Why does smart contract development require a different mindset than regular programming?
It is because of the high cost of failure and changes can be difficult to make -
Argue with your own words why clarity in your code is more important than performance.
Contract logic should be simple because it is easy to understand and makes fewer errors in the end. -
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?
Because blockchain is public, this means that even private data in smart contracts is also viewable by anyone. -
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
There is recommendation for any smart contract system is to identify the proper balance for fundamental tradeoffs. Some times security and software engineering best practices may not be aligned, and we have to find balance.
- The blockchain is append-only making upgrading harder. The stakes are also higher because the is dealing with high amount of money making an incentive for an attacker.
3)Someone might think private data can’t be read by others
- Those principles are contradictory. The immutability of the blockchain that makes it trustless is also what makes it vulnerable to attack. The security requirements make the code harder to process.
- Because it is a new type of programming in which the language, best practices, and uses are still being worked out.
- Clarity will allow anyone including yourself to read, understand, and implement your code. Sacrificing some performance to make it more readable could lead to catching errors sooner or more easily down the road. It can also allow for simpler upgrades of those errors.
- That data and functions which are marked private cannot be exploited as they are inaccessible. While it may take someone more intricate code and deeper understanding of how the contract functions to get to it they can reach it.
- Because this technology is still new and developing we don’t yet know what mix of performance vs security is ideal. Once we have more understanding of how our code and contracts will operate overtime we will be able to discover which blend is best.
- cost of failure can be high and it’s difficult to update contracts after it’s deployed on the blockchain
- A: because we want our code to be easily auditable
B: at the same time, we want to avoid any errors created by highly complex functions, which would be hard to debug and potentially easy to exploit - functions could be called with malicious code and private data (which is publicly available) could be used further malicious activity
- there is always a trade-off (security vs performance) in any software development/web development, etc. Since smart contracts deal with money, security must be prioritized
- Why does smart contract development require a different mindset than regular programming?
Primarily because the smart contract does direct financial transactions, the data is available and accessible.The infrastructure where smart contract is deployed is P2P which is fundamentally different than traditional client server architecture. - Argue with your own words why clarity in your code is more important than performance.
At any moment it is very important to understand the smart contract code and it should be easily readable so that in the future if it’s required to upgrade once can easily understand it. The traditional software development process focuses on performance because the software runs on its own client server network hence the performance is achieved by modular and reusable code which needs some time to understand. - 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?
Although the private functions are accessible only within the smart contract, they can be viewed publicly - Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Essentially smart contract directly deals with finance and data which can be viewed and exploited on p2p network, in such a circumstances the cost of errors and mistakes are high, hence security is the most important aspect of smart contract development.
-
Why does smart contract development require a different mindset than regular programming?
The cost of failure can be high, and change can be difficult, it therefore not enough to defend against know vulnerability. Instead, you will need to learn a new philosophy of development. -
Argue with your own words why clarity in your code is more important than performance.
keep contract complexity increase the likelihood of errors -
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?
-
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
All fundamental principles come down to trade offs because for contracts of various applications and durations priorities are balanced between what is required for the structure and security. The theoretical ideals do not line up with the practical ideals so an effective compromise must be established.
Why does smart contract development require a different mindset than regular programming?
- because the contracts handles money
Argue with your own words why clarity in your code is more important than performance.
- for easier debugging, and to let other people understand what the code does
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?
- maybe that the functions are hidden since they are private, but that only means that they cant be executed whenever you’d want.
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
- there is never a silver bullet, you always have to weigh your options and pick the one that makes the most sense for your contract.
1 Like
- Smart contracts are difficult to upgrade, and usually involve large amounts of money. Errors are costly and hard to repair.
- Clarity in the code makes it easier to understand, thus spot bugs.
- Someone might think that private fields in a smart contract are not visible from outside, but they are.
- Engineering is about tradeoffs; there are competing requirements, and a balance needs to be chosen.
1 Like
Answers
-
Smart contracts are the first form of programmable money. Every imperceptible bug into the code would cause catastrophic consequences in terms of money stolen or frozen. Once the code has been developed, it’s open to the entire world and it’s very difficult to upgrade, contrarily to web development thinking.
-
The goal with smart contracts is to obtain the best result with the less effort. We need to control the flow in a perfect way and we can do this only building simple structure. We have to know exactly what are we doing in all moments during the execution of the code, we have to manage external call function without overflowing data or get some other errors during the transactions’ execution. It’s preferable to stay up to date the ultimate official releases about data security and re-use all those functions or libraries the have been tested and have worked greatly until now.
-
For a newbie, it seems that something is private should be blind for others, except for the developer. But it’s just a false myth, blockchain is opened to the eyes of the world, everyone could see the code. The visibility “private” only means that particular function could only be executed by the within of the contract itself.
-
Everything in our lives is a tradeoff. It all depends on our goal. There are infinite possibilities to reach the same goal, what’s important is to think about the project and focus on the best suited way to reach that specific point.
1 Like
-
Because smart contracts are not easily upgradeable and there is a lot more risk when there is a bug in the code
-
Because clearer code is easier to understand and debug than complex code with more features and functionality
-
They might store private keys in private variables not knowing what the private visibility really means
-
As stated in the article smart contract development can be seen both as hardware programming/financial services, and also web/software development. Having different best practices from both fields, one must find a balance of which ones to use.
1 Like
- Why does smart contract development require a different mindset than regular programming?
Ethereum and complex blockchain programs are new and highly experimental.
- Argue with your own words why clarity in your code is more important than performance.
Complexity increases the likelihood of errors
- 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?
private helps to have usage encapsulation in code. But you should not think your data is private as long as it’s using blockchain.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
As with the other tradeoffs considered here, security best practices trend away from software engineering best practices in simple short-lived contracts and trend toward software engineering best practices in the case of more complex perpetual contract systems.
- Smart contract development requires a different mindset than that of regular programming because:
- The stakes are higher: we can now program money. People’s livelihoods are at stake when we program money. So we need to be extra precautious.
- Paradigm shift: crypto is a whole new ecosystem. As new attack vectors are discovered and new best practices implemented, we as developers need to constantly stay updated on the latest news.
- Bug fixes & Upgrades: the blockchain is "immutable". So when there is a bug in our code that needs fixing, or new best practices determine that we should upgrade our code, how will we do this? Well, in the pre-production phase, we would have to think about solutions in advance, to allow our code to be flexible. Investors and stakeholders in our project would then have to know about these accommodations so that they can determine whether the developers have the community’s best interests at heart when the contract inevitably has to be upgraded or be fixed. In that sense, some of the integrity of the blockchain is lost when we introduce this flexibility.
-
Clarity > Perfomance is paramount to writing smart contracts. It allows our code to be easy to test thoroughly because there will be simple logic to follow. Making the contracts as modular as possible also adds to the contract’s clarity.
-
To a newcomer in the crypto space, the terms “private data” and “private functions” may sound just that: private. But everything’s public on the blockchain, so they may develop smart contracts with sensitive data on them, thinking that as long as they label that data as “private”, then no one will be able to read it…
-
As mentioned in the linked article, here are the tradeoffs we make when developing smart contracts:
- Rigid vs Upgradeable
- Monolithic vs Modular
- Duplication vs Reuse
All these principles come down to tradeoffs because it depends what you want your smart contract to achieve. Bitcoin developers rejected the flexibility that Ethereum ended up using in its own contracts. In means that it’s unlikely we’ll see BTC being used as a means of value exchange down the road, but it’s good at what it does: being a store of value. So when building your own smart contracts, ask yourself: what is the goal of your contract?
1 Like
- The stakes are high because there is always money involved with smart contract functionality and smart contracts are not as easily updatable as other forms of software.
- Clarity is more important than performance because it is more important that your code is understandable than that it functions optimally. If the code is not understandable, then simple bugs can be missed that will cost money and trust in the future, at which point, it doesn’t matter how efficient your code was.
- Someone might store sensitive data in a smart contract because they think it is private, which would allow anyone to see that personal data and act maliciously with it.
- All the fundamental principles come down to tradeoffs because there are competing priorities at play. On the one hand we want our code to be efficient and we want it to do everything we need it to. On the other hand, we need it to be as secure as possible. So there are cases where we will need to minimize the functionality of our smart contract to ensure maximal security. In short, security outweighs all other priorities which may mean efficiency and other priorities are neglected in favor of security.
1 Like
-
Because they’re coding money
-
Because when code is easy to read, it is easier to debug as well when you or maybe even one of you colleagues stumble up on a possible hack opportunity
-
That is not readable so they put private info
-
Because you can’t implement it all at the same time all togehter
1 Like
- The risk is high because it’s programmable money that is involved. Also things are new in regards to smart contracts and their best practices.
- Clarity and simplicity can lead to less errors in the code.
- A false belief could be that private variable data is not viewable. Private variable data is viewable on the blockchain.
- Building smart contracts is complex and there are several ways to solve the same problem in smart contract code.
1 Like
1. Why does smart contract development require a different mindset than regular programming?
As a smart contract developer we develop software that handles public data and money. Therefore, we need to take extra precaution when going about engineering the software. For example should we be in the habit of checking for updates and bugs/bug-fixes for the platform we work on, on a daily basis.
2. Argue with your own words why clarity in your code is more important than performance.
When checking for vulnerability in the code of a smart contract, we will make our lives much easier by keeping the code as clean and simple as possible.
3. 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?
If one assumes that by declaring a function private, one could fall for the mis-belief that no one can see the functionality, the code, of this function. This could lead to carelessness in checking our code for vulnerabilities. Truth is, the complete code of every smart contract is viewable for everyone.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Producing a smart contract comes with the challenge of finding the right balance between software development best practices and security management best practices. In practice, we might f. e. find it to be the only way to go to limit the functionality of the contract to meet security requirements.
1 Like
- Why does smart contract development require a different mindset than regular programming?
- Argue with your own words why clarity in your code is more important than performance.
- 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?
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Answers:
1 - Because the cost of failure can be high, changes can be more difficult, also it is not enough to defend agains known and general vulnerabilities.
2 - The more simple your code is, the better. Also it is better to use maximum limit usage for money to avoid big failures, creating breaks if something goes wrong and also code as little and as simple that you can do. It is much easier to check things there rather then having a huge file where you can loose yourself in a minute. In other words Better safe than sorry.
3 - Even if you make private function, it is also viewable by everyone in the smart contract. Therefore somebody might save something in the private function which can result dangerous and high failure outcomes.
4 - Everything has pros and cons, no matter what are you using. In my opinion the best way is to learn both options, and choose the better one on each code/contract you are going to create. You cannot use the same thing over and over again in every contract you make.
1 Like