-
The blockchain ecosystem is new, experimental and evolving rapidly. As a result, smart contract developers need to keep up-to-date with changing security requirements and the latest best practices, in order to effectively manage new security risks and provide adequate protection against the latest bugs. Smart contracts manage money, meaning that the financial risk, and the associated cost of failure, is much higher than with regular programming. Once deployed, smart contracts can only be modified to the extent to which this has already been provided for within the code. This makes responding to future, as-yet-unknown bugs and vulnerabilities much more of a challenge, and requires extremely careful and thoughtful development, and extensive testing prior to mainnet deployment.
-
Due to the high cost of failure, smart contract security is of higher importance than performance. Clearer code in terms of simplicity, modularity and the use of libraries, also results in securer code, and is less likely to contain vulnerabilities than code that is more complex. Performance is obviously important in order to provide a satisfactory and competitive user experience and overall product. However, a reduction in performance is more likely to be tolerated by the user if the trade-off is a high level of safety and guaranteed security of their funds; whereas a higher level of performance with an increased risk of financial loss would be unacceptable.
-
A function with private visibility can only be called from within the same smart contract, and a state variable with private visibility can only be accessed from code within the same contract. It doesn’t mean that the data stored in these state variables, or output from these functions, is private, confidential, and cannot be viewed publicly. This would be a false belief, because, once deployed on the blockchain, all of a smart contract’s code and the data stored in its state variables can be viewed publicly. In addition, if a function with public visibility, and within the same contract, either calls a function marked private or accesses data from a variable marked private, then the data can still be retrieved by making an external function call to this public “wrapper” function. This false belief about private visibility could have dangerous consequences if it leads to developers writing smart contracts which can store, process and output sensitive data that does not need to be stored on a decentralised, public blockchain, but which instead should be stored confidentially on private servers. It could also lead to developers paying less attention to best practices in terms of security and risk management, because they may incorrectly believe that certain data stored in their smart contract is protected by a privacy that in fact does not exist.
-
Each fundamental principle of software development mentioned in the article (upgradeability, modular structure and code reuse) has an opposite (rigidity, monolithic structure and code duplication). The smart contract developer needs to decide where the trade-off (i.e. balance) lies between each pair of contrasting approaches in order to best manage security risk. Each smart contract use-case is unique in terms of the degree to which certain characteristics are present, and the different types and levels of security risk which therefore need to be managed. For example, complex smart contracts containing extensive functionality, and which are expected to be deployed over an open-ended period of time, will require a more upgradeable and modular approach. In contrast, simple smart contracts with limited functionality, and which will be deployed over a short, set time-period, can afford to focus less on upgradeability and modular code without compromising security (i.e. they can be more rigid and monolithic). Where a developer reuses their own tried-and-tested code, this is considered less of a security risk. Reuse of code shared by other developers in libraries depends on the level of trust built up in a particular library. Where more funds are at risk in a smart contract, code duplication becomes more of a priority where there isn’t a high level of trust in the code available for reuse, and where extensive testing of this reused code is also less likely to be performed.
-
Why does smart contract development require a different mindset than regular programming?
The cost of failure can be high, change is difficult to make. -
Argue with your own words why clarity in your code is more important than performance.
Clarity is more important than performance because it is much easier to fix bug or failures in the smart contract when the code is simple and understandable than it is to fix a high performance contract that is complicated in design.
Clear and simple code also helps other developers to help or build on an existing contract. -
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 conventional software development, private functions and data are actually private.
The consequences of not keeping in mind that all data and functions are public in a smart contract is that one might expose the contract to vulnerability by storing sensitive data in it. -
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
One must decide when designing a smart contract, what are the goals to be achieved, and what are the priorities in achieving the goal.
There will always be tradeoffs needed to be made, and it’s up to the designer to decide the best balance(rigid vs upgradeable, monolithic vs modular, duplication vs reuse).
1. Why does smart contract development require a different mindset than regular programming?
Because in regular programming you can get away with having bugs in your code since one can go back to their code, fix the bug and redeploy. Whereas in smart contract development you cannot fix any bugs from your code since the contract itself is immutable, once it is deployed onto the blockchain.
Additionally, the code you write is highly critical in smart contract development because it may be responsible for managing people’s money. The code is also public on the blockchain for everyone to see which makes it possible for hackers to maliciously try to operate the contract in a way which inflicts damage to the contract creator and its stakeholders directly/indirectly.
2. Argue with your own words why clarity in your code is more important than performance.
Because having clear and concise code will not only make it easier to read for yourself and for other developers but also make it easier to test and manage since clear code naturally leads to one of its core properties being modularisation. Additionally it makes it easier to discover and isolate bugs than if you had not so much clear code.
In blockchain one could also argue that performance isn’t that important since there’s so much computing power available to run any smart contract. (Let me know if you that is not the case)
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?
They may believe that private functions and data can’t be viewed on the blockchain.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Because it is a balancing act for developers to try and write code that is clear, readable, re-usable, non-monolithic…etc… The trade-offs at a security and readability standpoint can depend on the use-case developers are trying to achieve which can lead to new code being written. As a result, amplifying the complexity of the smart-contract as it becomes more difficult to make clear, readable, re-usable through modularisation and to test etc…
- Why does smart contract development require a different mindset than regular programming?
High cost of failure and not so easily upgradable.
- Argue with your own words why clarity in your code is more important than performance.
An exploitable contract is worthless - no matter how well it performs. So keep it simple and readable.- 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 he comes from Object oriented programming, he might assume, that private variables and functions are not viewable for potential hackers.- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
It’s a balance between usability, cost & convenience and contract security.
- The cost of a mistake can be high, and amendment may be difficult to make once the contract is launched.
- Clarity is more important because it will facility any future upgrade or to trace any bug.
- Private functions can be seen by anyone, therefore can be use by a hacker.
- The benefits of immutability on the contract, come down to a tradeoffs by making difficult to change an existing function in the contract, the benefits of being public and gain from the wider use, comes with the risk of someone being able to extract information. It has it positives and its negatives.
Q1. Why does smart contract development require a different mindset than regular programming?
Smart contract development is new and evolving. New bugs are discovered resulting in frequent changes in security landscape and development of new best practices.
The cost of failure of smart contracts can be high. The changes (bug fixes) can be difficult to make as compared to regular software projects due to the immutable nature of smart contracts(deploying on public blockchain).
Q2. Argue with your own words why clarity in your code is more important than performance.
Keeping code simple and modular will contribute to improved smart contract security which is important than performance. The code logic should be simple (easy to understand), modular so that it can be easily upgraded/maintained.
Complexity in code could increase likelihood of errors and vulnerabilities in the smart contract.
Q3. 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?
The private data and functions are also viewable by everyone and open to malicious attacks through public functions which can access them.
Q4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
The developers have to consider tradeoff on fundamental principles to improve smart contract a) security b) upgradability c) code reuse (from self-owned previously deployed contracts)
-
Blockchain development is new and so the new bugs, best practices etc are constantly upgraded. Once the contract is deployed it’s immutable, so it’s not possible to fix bugs. As the smart contract code manages money, there is a very high risk of managing money.
-
Having clear code with make it easier for the developer and other developers to read and work with the code. Clear code will result in modular code which makes it easier to test code or identify bugs or upgrade the smart contract.
-
Private data or functions are not viewable on the blockchain.
-
Depending on the use case of a smart contract- writing code (which is clear, upgradable, non-monolithic etc) will require some trade-offs
1. Why does smart contract development require a different mindset than regular programming?
High cost of failure , changes can be difficult because of immutable nature of blockchain.
2. Argue with your own words why clarity in your code is more important than performance.
Clear and easy to read code, will help you when it come to tests and identifying bugs.
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?
That private data is viewable on the blockchain this same as public.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
The balance between writing upgradable, modular and reusable code versus rigid and monolithic and duplicative depends on specific needs of the developer when writing particular contract and achieve equilibrium between practices.
1. Why does smart contract development require a different mindset than regular programming?
Solidity programs are new and highly experimental. We should expect constant changes in the security landscape. As usually values are involved, the cost of failure can be high. because of the immutabillity of a blockchain, changing a smart contract that is already in use can be difficult.
2. Argue with your own words why clarity in your code is more important than performance.
Complex code increases the likelihood of errors. Modular code and clean code principles makes the smart contract easier to understand, to test and to perform security audits.
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?
The private data in smart contracts is also viewable by anyone. So it should not contain anything secret.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
An ideal smart contract system from a software engineering bias is modular, reuses code instead of duplicating it, and supports upgradeable components. An ideal smart contract system from a secure architecture bias may share this mindset, especially in the case of more complex smart contract systems. But …
- malleability patterns by definition add complexity and potential attack surfaces
- a monolithic self-contained contract keeps all knowledge locally identifiable and readable
- duplication is frequently relied upon in cases where self-owned previously-deployed contracts are not available and any contract security audits must include any re-used code that has not previously established a level of trust commensurate with the funds at risk in the target smart contract system
1.In general, the development of smart contracts is very different from regular programming , raising new problems and challenges. For instance, on the one hand, developers must ensure code security for smart contracts due to the immutability of blockchain and the sensitiveness of digital information often managed, on the other hand they must pay special attention to gas consumption, as the execution of smart contracts in blockchain platforms like Ethereum is implemented through the gas mechanism . It should be considered that the blockchain technology requires specific constraints and characteristics of the applications that will run on it, the product lifecycle and the development software process of smart contracts and blockchain-based applications.
-
A clear code is better than a clever code! So it would be much closer to find and avoid bugs.
-
There are many points here, for example: private functions are not visible to the outside, or that it could be accessible only by that particular smart contract, or the actual data is not visible.
-
Because this world is always changeable, nothing is stable, everything could be changed in a moment, so are the softwares, the subject of security and performanse requires a continuous work and effort, to fid the perfect balance is almost impossible, so the work concentrates over to find the best approach to get the closeted results of the aim to the target, so it is always like calculating what we have in hand to get the best possible results
-
Why does smart contract development require a different mindset than regular programming?
Because the cost of failure can be high and it is difficult to make changes or fix issues after a smart contract goes live. -
Argue with your own words why clarity in your code is more important than performance.
Clarity in code (simple, small, modular, reusable) is easier to read and test while 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?
The false belief that because a function is made private, it cannot be exploited by other means and it doesn’t need to be focused on during testing. -
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Based on the article, there are tradeoffs that need to be made between code rigid versus upgradeability, monolithic versus modular, and duplication versus reuse. It depends on the developer team to determine the best balance between these principles for their use-case.
1. Why does smart contract development require a different mindset than regular programming?
Smart contracts handle money and information on a public platform. The stakes are higher.
2. Argue with your own words why clarity in your code is more important than performance.
Code which is complex and hard to follow are prone to bugs and hacker attacks, which can be severe when developing smart contract.
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?
That information is private because the state variables and functions are set to private.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Unfortunately there will often be tradeoffs. If you wish to have more security it may be at the cost of upgradeability. You have to find a balance
Its hard and sometimes impossible to satisfy all the requirements while having a performant, simple, clean and secure code. Sometimes we must sacrifice some requirement (ie : performance) for the sake of security or code clarity.
- 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?
1.Because you have increased risk of failure:
-
Code manages money,
-
All informations have Public access,
-
Ethereum is a new ecosystem that needs more well-known best practices.
2 . Because you need to be able to foresee any known and unknown issues or bug that might occur with a greater probablility if you can’t see through your own complexe logic.
3 . People can have a wrong understanding of the “private” parameter of a function or of some data that does not mean “privacy” or “opaqueness”.
4 . Because the Language is a high level programming tool that have intrinsic security features that programmers need to understand to not impede with the wrong mindset which necessarily implies trade-offs on multiple levels.
Thank you.
1. Why does smart contract development require a different mindset than regular programming?
Smart contracts are immutable and even if it’s done in upgradable manner as soon as you have auditory using your contact, you won’t be able to freely upgrade your contract to fix some bug. All blockchain information is public, it has to be taken into account when designing. Working with smart contracts is like working with financial applications, you need to put a lot of efforts into testing and still accept that something is not taken into account.
2. Argue with your own words why clarity in your code is more important than performance.
Code readability is always welcome in any programming language. Complex code gives room for mistakes. Plus if you want support from community, it’s better to have code self explaining.
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?
Private helps to have usage encapsulation in code. But you should not think your data is private as long as it’s using blockchain.
4. Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Security vs upgradability, gas efficiency vs readability, etc.
-
Why does smart contract development require a different mindset than regular programming?
The high cost of failure and the difficulty of changing makes a different mind set a must. Smart contracts can be seen as mission critical code, which can have severe consequences if the code breaks. All Information in a smart contract is public and the code can manage money due to this sensitive areas, a certain wariness has to be used when creating the code. -
Argue with your own words why clarity in your code is more important than performance.
Clarity provides a better oversight about the code and its inner workings. It also allows to spot easier and faster potential bugs or weaknesses. Furthermore third parties can easier verify the code and makes code audits easier. -
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 in smart contracts only takes care of the access to the functions but does not hide or encrypt any of the data or code within the contract. The data still can be extracted and be used maliciously. -
Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
As some of the points contradict each other. By achieving one of the principles another may become unachievable or only limited achievable. Therefore the best balance between the two sides has to be chosen, hence the tradeoffs.
- Why does smart contract development require a different mindset than regular programming?
Risks are high as you are managing money. smart contracts are also difficult to change. - Argue with your own words why clarity in your code is more important than performance.
Your contract should be easy to understand and reason about. It will be easier to verify the logic and test that it works as expected. - 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?
They might assume that private data is not visible by everyone, when in fact it is! - Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
Strictly following traditional software engineering principals might lead to less secure smart contracts, so both need to be balanced and a find a suitable tradeoff if/when needs be.
- Why does smart contract development require a different mindset than regular programming?
- New ecosystem. The existing solutions are generally less tested and more prone to failure or hacking.
- High cost of failure. A smart contract operates with funds of other people or even companies.
- Difficult upgradeability. When a smart contract is deployed, it is on the blockchain. Upgrading means taking it down and deploying again. If the SC has funds in it, they have to be withdrawn. Each transaction costs money.
- Argue with your own words why clarity in your code is more important than performance.
- The simpler the code, the less possibility there is for failure or hack. Easier testing. Easier troubleshooting and upgrading.
- 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?
- Confusion between anonymous and pseudonymous. On Ethereum, a user is pseudonymous. They are hiding behind some account number, but all interactions with that account are publicly seen.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
- To sum it up, it is a scale between simplicity and functionality. Simplicity and security. Cost and security.
- Why does smart contract development require a different mindset than regular programming?
Smart contracts manage money, Ethereum and complex blockchain programs are new and highly experimental. Therefore, we should expect constant changes in the security landscape, as new bugs and security risks are discovered, and new best practices are developed.
The cost of failure can be high, and change can be difficult, making it in some ways more similar to hardware programming or financial services programming than web or mobile development. It is therefore not enough to defend against known vulnerabilities. Instead, we will need to learn a new philosophy of development.
- Argue with your own words why clarity in your code is more important than performance.
At this point we should make clear that besides threat modeling, or as part of threat modeling, formal verification should be mandatory. When coding smart contracts, a process called formal verification, should be mandatory (or the next best thing, which is visual/automated inspection of code correctness). Formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics. In a few words is crucial for the code to do what is supposed to do.
- 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 data and private functions in a smart contract accept direct user supplied input and are restrict only by the account address (e.g. the smart contract owner address etc.). That means that anyone can attempt to interact with private functions and modify private data. Dapps can be bypassed using Web proxies for example or someone can directly start interface with the smart contract.
- Why do you think all the fundamental principles mentioned in the article comes down to tradeoffs?
there are multiple fundamental trade-offs to consider when assessing the structure and security of a smart contract system. The general recommendation for any smart contract system is to identify the proper balance for these fundamental trade-offs. However, there are important exceptions where security and software engineering best practices may not be aligned.